生产级 Agent 怎么设计：从 OpenAI 与 Anthropic 的公开实践看架构边界

Agent 可以检索资料、调用工具、修改环境，再依据结果决定下一步。生产系统还必须回答：它实际完成了什么，失败后从哪里继续，谁有权批准操作，成本是否可控。模型能力、执行框架和业务正确性是相互关联的三个层次。

本文以截至 2026-10-11 可核对的一手资料为依据。OpenAI 与 Anthropic 的工程文章提供公开实现经验；SDK 文档描述产品契约；研究论文提供特定实验环境下的证据。下文标为“工程推导”的设计是本文综合建议，不代表两家公司所有内部系统的实现。

从研究问题开始：为什么需要执行循环

ReAct 论文^[1]研究了推理与环境动作交替进行的方法：模型依据观察修正后续行动。它解释了 Agent 的一种基本组织方式，但没有证明一套通用生产架构，也不意味着今天的推理模型必须向用户展示完整思维链。

工程上，这个循环可以简化为：读取任务与证据 → 请求模型 → 得到最终输出或工具请求 → 校验并执行工具 → 写入观察 → 继续。关键在于“观察”来自执行结果，而不是模型对成功的自述。数据库状态、测试结果或受控产物才是完成任务的证据。

OpenAI：公开的 agent loop 与三种接入层次

Unrolling the Codex agent loop^[2]公开说明了 Codex 如何围绕 Responses API 组织模型与工具往返，并把上下文管理纳入执行框架。它描述的是 Codex 的公开设计，不能直接推导 ChatGPT 所有功能的内部架构。

开发者至少要区分以下层次：

截至核对时，Agents SDK^[3]还提供隔离工作空间与可恢复 sandbox session；Agents API 的发布说明^[4]则介绍托管 harness、可选择执行环境、上下文压缩与工具发现。这些能力的存在，不能被简化成“SDK 都不保存状态”，也不能被反向理解为“用了托管服务就自动保证业务事务”。两种产品的契约与可用范围需要分别确认。

Anthropic：从最简单的工作流，到拆开执行框架与环境

Building effective agents^[5]区分预先定义路径的 workflow 与由模型动态决定路径的 agent，强调从简单方案起步。固定的提取、校验、写入流程通常不需要把所有步骤交给模型决策。

2026 年的 Managed Agents 工程报告^[6]进一步公开了三个可独立替换的部分：session 保存事件，harness 组织模型与工具循环，sandbox 提供执行环境。其会话日志位于上下文窗口之外，运行框架和环境可以分别恢复；报告还讨论了把凭据隔离在受控代理之外的做法。

这里的启发是把可恢复的记录与当前一次模型能看到的内容分开。压缩上下文可以节省 token，但不应顺便销毁审计、恢复或验收仍需要的原始事件。具体日志留存仍受隐私、成本与删除要求约束。

怎样比较两家：按职责，避免只比框架名字

这是对公开资料的职责归纳，不是跨产品统一基准。文章中的架构相似性，也不构成两家产品具有相同 SLA、恢复语义或数据政策的证据。

工程推导：一个有边界的最小生产架构

图 1 · 本文综合设计。箭头表示受控调用与事件回写；业务数据库、任务记录和模型上下文承担不同职责。

先把“帮我处理请求”写成任务契约：输入是什么、成功如何确认、哪些动作可自动执行、何时需要审批、预算与截止时间多少、证据不足怎样退出。例如资料分析 Agent 的成功可以是“生成包含来源定位的报告”，而不是“输出一段流畅总结”；处理工单还要验证授权状态变更实际生效。

最小实现可以保持一个部署单元，但分清四条边界：

1. 入口与任务管理：鉴权、租户隔离、幂等接收、配额和任务状态。
2. 执行循环：根据任务状态构造上下文，限制轮数、时间、费用与工具并发。
3. 工具与环境：schema 校验之后再做权限与业务校验，限制文件、网络和副作用。
4. 证据与验收：记录执行事件、版本和受控产物，依据最终结果决定完成或失败。

模块边界不要求立即拆成微服务。先用内部接口和清晰数据所有权隔离；当资源、故障、权限或独立扩容需求出现时，再拆部署。过早增加网络调用会引入新的超时、认证和一致性问题。

状态机：暂停、失败与“结果未知”怎么继续

accepted → queued → running → verifying → completed
                         ↘ awaiting_approval → running
                         ↘ retry_wait → queued
                         ↘ reconciling → running / failed
                         ↘ cancelled / failed

以上是业务状态示意，不是厂商 API 的枚举。每次执行保存任务 ID、尝试 ID、当前步骤、已确认工具结果、版本和剩余预算。审批必须绑定具体参数与对象版本；内容改变后旧审批不能继续生效。

最棘手的情况是外部写入成功，但响应丢失。此时不能直接认定失败并创建新操作：先按稳定业务操作 ID 查询或对账；支持幂等的上游复用同一键；不支持查询或去重时转入人工确认。可恢复执行仍需要处理副作用的不确定性。 详见并发与状态篇。

安全检查也有执行位置。OpenAI guardrails 文档^[7]明确：并行输入检查可能在判定前已经让 Agent 消耗 token 或执行工具。高影响动作应在执行前有阻断检查、工具侧授权或审批；最终输出检查无法撤销已经发生的外部修改。

优化研究：先找失败来源，再增加复杂度

单 Agent 加工具是有用的基线。只在任务确实可分解、结果可合并时比较多 Agent；只有检索证据缺失时，才优先修解析、召回与重排；工具误选则先检查描述、重叠接口与结果体积。更复杂的规划器不能自动修复权限错误或错误资料。

怎样读厂商报告的优化数字

Managed Agents 原始报告^[6]称，将推理与执行容器解耦、按需启动容器后，其系统 p50 TTFT 下降约 60%，p95 下降超过 90%。这是报告中的架构优化结果，不是“模型能力提高 90%”，也不是所有 Agent 服务都能复制的收益。

工程推导：先用 trace 验证自己的首响应是否被环境启动阻塞，再比较按需与预启动的负载、环境费用、任务完成时间和失败率。若大部分任务立即需要 sandbox，启动成本可能只是被推迟到后面，首 token 更快仍需要与完整任务体验一起判断。

这些是本文提出的实验，不是已测得的收益。用相同任务集记录逐任务差异，多次运行观察稳定性；把检索、模型、工具与验收耗时拆开。优化目标可使用“每个验收成功任务的总成本”，把失败、重试、压缩、审核与基础设施计入，避免仅因回答缩短就宣布成功。

从方案到上线：交付需要留下哪些证据

一次完整交付至少包括：需求与验收表、接口和权限契约、状态恢复设计、离线评测结果、容量与故障演练、版本化发布包、灰度观测和回滚流程。模型或 prompt 的变化应与代码一样可追踪；外部工具、知识库与安全策略变化也可能引起回归。

继续阅读Prompt 与上下文工程、观测与交付和评测闭环。能解释这条证据链，才真正解释了 Agent 从能力演示到生产服务的过程。

参考资料