Duolingo 的生产级 Agent 平台架构解析
Duolingo 如何用 Temporal 工作流引擎和声明式 Agent 定义，构建支持多运行时的共享 Agent 平台，解决团队重复造基础设施的问题。
TL;DR — Duolingo 的工程团队发现每个 Agent 项目都在重建相同的基础设施——重试、持久化、可观测性、评估。他们的解决方案：一个共享平台，你只需用声明式规范定义 Agent，平台负责执行、编排、观测和评估。核心架构决策：把 Agent 运行当作持久化的 Temporal 工作流，而不是一次性进程。这使得 Agent 定义与执行运行时完全解耦，团队可以在 Claude Agents SDK、Codex CLI、OpenAI Agents SDK 之间自由切换。
问题的原点：每个团队都在造同一个轮子
我在大厂待过，看着三个不同团队在同一个季度里各自实现了一套 Agent 重试逻辑。代码不同，bug 不同，但解决的是完全相同的问题。这种浪费让人肉疼。
Duolingo 在 2026 年 8 月 4 日发布的工程博客里坦率地讲了他们遇到的同样困境。他们的 AI 团队分布在内容生成、课程评估、本地化等方向，每个方向都在独立构建 Agent 系统。单看每个项目都很成功，但从组织层面看，大量基础设施在被重复建设：
- 持久执行：运行几分钟到几小时的 Agent，怎么扛住进程重启和网络抖动？
- 可观测性：Agent 现在在干什么？调了哪些工具？每一步花了多少钱？
- 编排协调：怎么把 Agent 和上下游系统、人工审批环节串起来？
- 评估体系：这个 Agent 到底好不好用？怎么持续度量而不是上线时测一次就忘？
- 成本追踪：凌晨三点哪个团队的 Agent 烧掉了 400 美元 API 调用？
常见的应对方式是「写个公共库」。Duolingo 走得更远——他们建了一个平台。
核心设计：声明式定义 + 平台运行时
Duolingo 平台的核心理念是把「Agent 是什么」和「Agent 怎么跑」彻底分开。
Agent 定义是一份声明式规范：
name: curriculum-evaluator
description: "评估课程序列的教学连贯性和难度递进"
system_prompt: |
你是语言教学法和课程设计专家。
请评估提供的课程序列...
model: claude-sonnet-4-20250514
mcp_servers:
- curriculum-api
- learner-data
output_type: structured注意这里面没有什么：没有重试逻辑、没有状态管理、没有可观测性接线、没有部署配置。Agent 作者只关心 Agent 应该做什么——身份、工具、输出契约。其他一切交给平台。
这个思路和 Kubernetes 一脉相承：声明你想要什么，系统搞定怎么运行。只不过 Kubernetes 编排的是容器，Duolingo 的平台编排的是 Agent 运行。
架构核心：Temporal 工作流引擎
平台的执行引擎选了 Temporal。如果你不熟悉 Temporal，一句话概括：它让你写看起来像普通顺序代码的逻辑，但实际上是持久的——进程崩了，重启后从断点继续。
为什么 Temporal 适合 Agent 编排：
| Agent 需求 | Temporal 能力 |
|---|---|
| Agent 运行不怕崩溃 | 持久执行 + 自动重放 |
| 工具调用失败要重试 | 内置活动级重试策略 |
| 长时间运行（分钟到小时） | 工作流定时器和心跳 |
| 和外部系统协调 | Signal 和 Query API |
| 查看 Agent 执行进度 | 事件历史和工作流状态 |
| 超时和预算控制 | 工作流和活动超时 |
平台定义了一个 AgentWorkflow，生命周期如下：
AgentWorkflow: 加载定义 → 准备环境 → 运行 Agent → 返回输出展开看：
- 加载定义 — 从注册中心拉取声明式 Agent 规范
- 准备环境 — 启动 MCP 服务器、建立连接、通过 LLM Gateway 配置模型端点
- 运行 Agent — 用对应的运行时执行 Agent
- 返回输出 — 按声明的
output_type校验输出，持久化结果，发送指标
每一步都是 Temporal Activity，意味着每一步有独立的重试策略、超时和可观测性。MCP 服务器暂时不可用？Temporal 指数退避重试。LLM 调用超时？重试。整个工作流被部署中断？从断点恢复。
这和传统的「启动进程，祈祷它跑完」完全是两回事。正如我们在生产 Agent 为什么需要运行时层中讨论的，demo 到生产之间的鸿沟，恰恰就是这类持久执行基础设施。
多运行时支持：面向未来的赌注
Duolingo 没有绑死一个 Agent 执行运行时，而是同时支持多个：
- OpenAI Agents SDK — 大多数生产 Agent 的主力运行时
- Claude Agents SDK — 适合 Anthropic 模型优势场景的 Agent
- Codex CLI — 代码生成和仓库操作类 Agent
声明式定义和运行时无关。平台根据定义里的 model 字段和配置决定用哪个运行时。换模型？改一行定义，平台搞定剩下的。
这个解耦在快速变化的领域至关重要。2024 年绑死一个 SDK，六个月后出了更好的就得重写。Duolingo 的架构让他们无需修改 Agent 定义就能引入新运行时。新供应商出了工具调用性能更强的 SDK？加个运行时适配器，所有 Agent 立刻受益。
OpenAI Agents SDK 集成细节
博客深入讲了 OpenAI Agents SDK 的集成，因为这是他们用得最多的运行时。两个细节值得注意：
MCP 工具调用作为 Temporal Activity。 Agent 调用 MCP 工具（比如查询课程 API）时，这个调用不只是一次函数执行——它是一个 Temporal Activity。这意味着每次工具调用都有：
- 独立重试 + 可配置退避
- 超时强制执行
- 在 Temporal UI 中完整可观测（耗时、结果、错误）
- 工作流重启时自动重放
这种运维粒度，裸进程里跑 Agent 是做不到的。
LLM Gateway 代理做成本和用量追踪。 所有模型调用都经过 Duolingo 内部的 LLM Gateway，作为 Agent 运行时和模型供应商之间的代理层。Gateway 负责：
- 按团队、按 Agent 的成本归属
- 用量配额和限流
- 模型路由（A/B 测试不同模型）
- 请求/响应日志用于调试
组织里 Agent 一多，「谁烧的钱」就变成刚需。Gateway 一层解决。
Agent 评估：持续的，不是一次性的
大多数团队在开发时评估一次 Agent，上线后就靠祈祷。Duolingo 把评估做成了平台的一等公民。
他们的评估流程：
- 编写场景 — 定义测试用例，指定输入和期望行为
- 运行真实 Agent — 执行实际的 Agent（不是 mock），面对这些场景
- 捕获输出和 diff — 记录 Agent 产出，包括文件变更和状态变化
- 结构化断言评分 — 用确定性检查和 LLM-as-judge 两种方式评估输出
关键原则：评估跑的是真实 Agent，在真实环境中。不 mock，不 stub，不简化。这意味着评估能捕获单测漏掉的问题——比如 MCP 服务器返回异常数据，或者模型产出了格式正确但内容错误的结构化输出。
评估按计划运行，也在每次 Agent 定义变更时运行。模型供应商更新模型时，评估在用户感知之前就能发现回归。
关键设计模式总结
| 模式 | 含义 | 价值 |
|---|---|---|
| 声明式定义 | Agent 规范是数据，不是代码 | 支持工具化、校验、版本控制、非工程师编写 |
| 持久化工作流 | Agent 运行能扛住故障 | Agent 可以跑几小时不担心丢进度 |
| 运行时抽象 | 定义 ≠ 执行 | 换 SDK 不用重写 Agent；渐进式引入新能力 |
| 工具调用即活动 | 每次工具调用独立管理 | 工具级别的重试、超时和观测 |
| 网关代理的 LLM 访问 | 所有模型调用经代理 | 成本归属、限流、路由、日志一站式 |
| 持续评估 | 评估是自动化基础设施，不是手动测试 | 捕获模型更新、prompt 漂移和数据变化的回归 |
对行业的启示
Duolingo 的平台验证了一个趋势：生产 Agent 的未来不在于更好的框架，而在于更好的基础设施。 模型够好了，框架够好了，缺的是让 Agent 在组织规模下可靠、可观测、可维护的生产层。
这和 Web 开发走过的路一样。单个开发者不需要 Kubernetes，但运行上百个服务的组织需要。同理，造一个 Agent 的开发者不需要平台，但多个团队跑几十个 Agent 的组织绝对需要。
具体的技术选型——Temporal 做持久化、声明式定义做关注点分离、多运行时做灵活性——不是唯一有效的选择。但这个模式——把定义和执行解耦、把 Agent 运行当作持久化工作流而非一次性进程——会成为标准做法。如果你正在探索开源 Agent 框架，值得考虑它们如何与这类基础设施层组合。
常见问题
问：一定要用 Temporal 吗？
不一定。Temporal 是持久工作流执行的选项之一，替代品包括 Restate、Inngest、Hatchet。核心需求是活动级重试和可观测的持久执行。Temporal 的优势在于大规模验证过（Uber、Netflix、Snap），这在你把 Agent 基础设施押注在上面时很重要。
问：这和 LangGraph / CrewAI 有什么区别？
LangGraph 处理的是单个 Agent 推理循环内部的编排。Duolingo 的平台处理的是 Agent 周围的编排——生命周期管理、重试、评估、成本追踪、多运行时支持。两者是互补的层。你完全可以把 LangGraph 作为这种平台内的一个运行时来用。
问：小团队能从中获益吗？
完整平台对只有一两个 Agent 的团队来说是杀鸡用牛刀。但核心洞察——把 Agent 运行当持久化工作流而非脚本——在任何规模都适用。即使单个 Agent，只要它运行超过几分钟或调用不可靠的外部服务，Temporal 式的持久化就有价值。
问：MCP 服务器的密钥和凭证怎么处理？
博客提到环境准备阶段（AgentWorkflow 第二步）负责凭证注入。Agent 定义只按名字引用 MCP 服务器；平台在运行时把名字解析为带有合适凭证的运行实例。Agent 作者永远不直接处理密钥。
问：启动一个 Agent 的冷启动时间是多少？
文章没给精确数字，但提到常用 Agent 的 MCP 服务器池会保持预热。低频 Agent 在「准备环境」阶段会有几秒的启动成本。
结语
Duolingo 的 Agent 平台在任何单一维度上都不算革命性。Temporal 不新，声明式定义不新，多运行时支持不新。真正有价值的是这些成熟模式的组合：把经过验证的基础设施理念应用到组织规模运行 AI Agent 这个具体问题上。
核心洞察值得内化：把 Agent 运行当作持久化工作流，而非一次性进程。 声明式定义、多运行时支持、持续评估——所有这些都从这个基础决策中自然生长出来。一旦你决定 Agent 运行是必须持久、可观测、可恢复的工作流，架构的其余部分就会自己浮现。
如果你所在的组织里多个团队在造 Agent，而且你看到相同的基础设施被反复重建——Duolingo 刚给你发布了路线图。
