[{"data":1,"prerenderedAt":796},["ShallowReactive",2],{"article:production-agent-design":3},{"meta":4,"raw":17,"references":18,"prev":51,"next":60,"body":68,"toc":782},{"slug":5,"title":6,"date":7,"updated":7,"tags":8,"summary":13,"draft":14,"lang":15,"minutes":16},"production-agent-design","生产级 Agent 怎么设计：从 OpenAI 与 Anthropic 的公开实践看架构边界","2026-10-11",[9,10,11,12],"Agent","OpenAI","Anthropic","生产架构","对照 Codex agent loop、Agents SDK\u002FAPI 与 Claude Managed Agents，解释模型、执行框架、会话和业务状态的职责；从成功标准出发，设计可恢复执行、权限边界与优化实验。",false,"zh-CN",9,"Agent 可以检索资料、调用工具、修改环境，再依据结果决定下一步。生产系统还必须回答：它实际完成了什么，失败后从哪里继续，谁有权批准操作，成本是否可控。**模型能力、执行框架和业务正确性是相互关联的三个层次。**\n\n本文以截至 2026-10-11 可核对的一手资料为依据。OpenAI 与 Anthropic 的工程文章提供公开实现经验；SDK 文档描述产品契约；研究论文提供特定实验环境下的证据。下文标为“工程推导”的设计是本文综合建议，不代表两家公司所有内部系统的实现。\n\n## 从研究问题开始：为什么需要执行循环\n\n[ReAct 论文](https:\u002F\u002Farxiv.org\u002Fabs\u002F2210.03629)研究了推理与环境动作交替进行的方法：模型依据观察修正后续行动。它解释了 Agent 的一种基本组织方式，但没有证明一套通用生产架构，也不意味着今天的推理模型必须向用户展示完整思维链。\n\n工程上，这个循环可以简化为：读取任务与证据 → 请求模型 → 得到最终输出或工具请求 → 校验并执行工具 → 写入观察 → 继续。关键在于“观察”来自执行结果，而不是模型对成功的自述。数据库状态、测试结果或受控产物才是完成任务的证据。\n\n## OpenAI：公开的 agent loop 与三种接入层次\n\n[Unrolling the Codex agent loop](https:\u002F\u002Fopenai.com\u002Findex\u002Funrolling-the-codex-agent-loop\u002F)公开说明了 Codex 如何围绕 Responses API 组织模型与工具往返，并把上下文管理纳入执行框架。它描述的是 Codex 的公开设计，不能直接推导 ChatGPT 所有功能的内部架构。\n\n开发者至少要区分以下层次：\n\n| 接入方式 | 得到什么 | 应用需要明确什么 |\n| --- | --- | --- |\n| 模型 API \u002F Responses | 推理、工具调用请求与 API 提供的状态能力 | 自己控制的循环、错误处理、业务授权与完成判定 |\n| Agents SDK | 运行循环、工具、handoff、guardrails、tracing 等组件 | 部署方式、业务状态、外部工具权限、幂等与验收 |\n| 托管 Agents API | 厂商运行的 Codex harness 与配套云端执行能力 | 环境选择、业务集成、数据约束、权限与结果验证 |\n\n截至核对时，[Agents SDK](https:\u002F\u002Fopenai.github.io\u002Fopenai-agents-python\u002F)还提供隔离工作空间与可恢复 sandbox session；[Agents API 的发布说明](https:\u002F\u002Fopenai.com\u002Findex\u002Fintroducing-the-agents-api\u002F)则介绍托管 harness、可选择执行环境、上下文压缩与工具发现。这些能力的存在，不能被简化成“SDK 都不保存状态”，也不能被反向理解为“用了托管服务就自动保证业务事务”。两种产品的契约与可用范围需要分别确认。\n\n## Anthropic：从最简单的工作流，到拆开执行框架与环境\n\n[Building effective agents](https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fbuilding-effective-agents)区分预先定义路径的 workflow 与由模型动态决定路径的 agent，强调从简单方案起步。固定的提取、校验、写入流程通常不需要把所有步骤交给模型决策。\n\n2026 年的 [Managed Agents 工程报告](https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fmanaged-agents)进一步公开了三个可独立替换的部分：session 保存事件，harness 组织模型与工具循环，sandbox 提供执行环境。其会话日志位于上下文窗口之外，运行框架和环境可以分别恢复；报告还讨论了把凭据隔离在受控代理之外的做法。\n\n这里的启发是把**可恢复的记录**与**当前一次模型能看到的内容**分开。压缩上下文可以节省 token，但不应顺便销毁审计、恢复或验收仍需要的原始事件。具体日志留存仍受隐私、成本与删除要求约束。\n\n## 怎样比较两家：按职责，避免只比框架名字\n\n| 研究维度 | OpenAI 公开资料 | Anthropic 公开资料 | 生产选型要验证的问题 |\n| --- | --- | --- | --- |\n| 执行循环 | Codex loop、SDK 运行器、托管 harness | workflow\u002Fagent 模式、Managed Agents harness | 谁负责恢复、退出和版本兼容？ |\n| 状态 | SDK 会话、运行状态与 sandbox session 等不同能力 | 上下文之外的 session 事件日志 | 外部写入结果在哪里确认？ |\n| 执行环境 | SDK sandbox 或托管 API 的环境选项 | 与 harness 解耦的 sandbox \u002F tools | 权限、网络、凭据与资源怎样约束？ |\n| 编排 | tools、manager 与 handoff 等方式 | 固定流程、动态编排与多 Agent 实验 | 增加编排后，净收益是否超过延迟和费用？ |\n\n这是对公开资料的职责归纳，不是跨产品统一基准。文章中的架构相似性，也不构成两家产品具有相同 SLA、恢复语义或数据政策的证据。\n\n## 工程推导：一个有边界的最小生产架构\n\n![生产 Agent 的职责边界：入口与任务状态、执行循环、工具环境、事件和验收](\u002Fdiagrams\u002Fproduction-agent-design.svg)\n\n*图 1 · 本文综合设计。箭头表示受控调用与事件回写；业务数据库、任务记录和模型上下文承担不同职责。*\n\n先把“帮我处理请求”写成任务契约：输入是什么、成功如何确认、哪些动作可自动执行、何时需要审批、预算与截止时间多少、证据不足怎样退出。例如资料分析 Agent 的成功可以是“生成包含来源定位的报告”，而不是“输出一段流畅总结”；处理工单还要验证授权状态变更实际生效。\n\n最小实现可以保持一个部署单元，但分清四条边界：\n\n1. **入口与任务管理**：鉴权、租户隔离、幂等接收、配额和任务状态。\n2. **执行循环**：根据任务状态构造上下文，限制轮数、时间、费用与工具并发。\n3. **工具与环境**：schema 校验之后再做权限与业务校验，限制文件、网络和副作用。\n4. **证据与验收**：记录执行事件、版本和受控产物，依据最终结果决定完成或失败。\n\n模块边界不要求立即拆成微服务。先用内部接口和清晰数据所有权隔离；当资源、故障、权限或独立扩容需求出现时，再拆部署。过早增加网络调用会引入新的超时、认证和一致性问题。\n\n## 状态机：暂停、失败与“结果未知”怎么继续\n\n```text\naccepted → queued → running → verifying → completed\n                         ↘ awaiting_approval → running\n                         ↘ retry_wait → queued\n                         ↘ reconciling → running \u002F failed\n                         ↘ cancelled \u002F failed\n```\n\n以上是业务状态示意，不是厂商 API 的枚举。每次执行保存任务 ID、尝试 ID、当前步骤、已确认工具结果、版本和剩余预算。审批必须绑定具体参数与对象版本；内容改变后旧审批不能继续生效。\n\n最棘手的情况是外部写入成功，但响应丢失。此时不能直接认定失败并创建新操作：先按稳定业务操作 ID 查询或对账；支持幂等的上游复用同一键；不支持查询或去重时转入人工确认。**可恢复执行仍需要处理副作用的不确定性。** 详见[并发与状态篇](\u002Farticles\u002Fagent-concurrency-state)。\n\n安全检查也有执行位置。[OpenAI guardrails 文档](https:\u002F\u002Fopenai.github.io\u002Fopenai-agents-python\u002Fguardrails\u002F)明确：并行输入检查可能在判定前已经让 Agent 消耗 token 或执行工具。高影响动作应在执行前有阻断检查、工具侧授权或审批；最终输出检查无法撤销已经发生的外部修改。\n\n## 优化研究：先找失败来源，再增加复杂度\n\n单 Agent 加工具是有用的基线。只在任务确实可分解、结果可合并时比较多 Agent；只有检索证据缺失时，才优先修解析、召回与重排；工具误选则先检查描述、重叠接口与结果体积。更复杂的规划器不能自动修复权限错误或错误资料。\n\n| 待验证假设 | 控制变量与改动 | 观测指标 | 可能的反效果 |\n| --- | --- | --- | --- |\n| 工具太多导致误选 | 固定模型与任务，只按需加载工具 | 工具选择准确率、调用次数、输入 token | 漏加载工具，增加发现轮次 |\n| 大工具结果分散注意力 | 比较完整结果与摘要加可追溯引用 | 任务成功率、证据召回、p95、费用 | 摘要丢失关键字段 |\n| 独立调查可并行 | 比较串行单 Agent 与有上限的并行分工 | 验收成功率、尾延迟、总 token | 合并冲突、重复工作、限流 |\n| 执行环境冷启动拖慢响应 | 比较预启动与按需启动 | 首个有用结果时间、环境费用、失败率 | 重任务把启动成本推到后段 |\n\n### 怎样读厂商报告的优化数字\n\n[Managed Agents 原始报告](https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fmanaged-agents)称，将推理与执行容器解耦、按需启动容器后，其系统 p50 TTFT 下降约 60%，p95 下降超过 90%。这是报告中的架构优化结果，不是“模型能力提高 90%”，也不是所有 Agent 服务都能复制的收益。\n\n工程推导：先用 trace 验证自己的首响应是否被环境启动阻塞，再比较按需与预启动的负载、环境费用、任务完成时间和失败率。若大部分任务立即需要 sandbox，启动成本可能只是被推迟到后面，首 token 更快仍需要与完整任务体验一起判断。\n\n这些是本文提出的实验，不是已测得的收益。用相同任务集记录逐任务差异，多次运行观察稳定性；把检索、模型、工具与验收耗时拆开。优化目标可使用“**每个验收成功任务的总成本**”，把失败、重试、压缩、审核与基础设施计入，避免仅因回答缩短就宣布成功。\n\n## 从方案到上线：交付需要留下哪些证据\n\n一次完整交付至少包括：需求与验收表、接口和权限契约、状态恢复设计、离线评测结果、容量与故障演练、版本化发布包、灰度观测和回滚流程。模型或 prompt 的变化应与代码一样可追踪；外部工具、知识库与安全策略变化也可能引起回归。\n\n继续阅读[Prompt 与上下文工程](\u002Farticles\u002Fprompt-context-engineering)、[观测与交付](\u002Farticles\u002Fagent-observability-delivery)和[评测闭环](\u002Farticles\u002Fllm-eval-loop)。能解释这条证据链，才真正解释了 Agent 从能力演示到生产服务的过程。\n\n## 参考资料\n\n- [ReAct — Synergizing Reasoning and Acting in Language Models](https:\u002F\u002Farxiv.org\u002Fabs\u002F2210.03629)\n- [OpenAI — Unrolling the Codex agent loop](https:\u002F\u002Fopenai.com\u002Findex\u002Funrolling-the-codex-agent-loop\u002F)\n- [OpenAI — Agents SDK](https:\u002F\u002Fopenai.github.io\u002Fopenai-agents-python\u002F)\n- [OpenAI — Introducing the Agents API](https:\u002F\u002Fopenai.com\u002Findex\u002Fintroducing-the-agents-api\u002F)\n- [Anthropic — Building effective agents](https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fbuilding-effective-agents)\n- [Anthropic — Scaling Managed Agents](https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fmanaged-agents)\n- [OpenAI Agents SDK — Guardrails](https:\u002F\u002Fopenai.github.io\u002Fopenai-agents-python\u002Fguardrails\u002F)",[19,24,29,34,39,43,47],{"title":20,"url":21,"type":22,"note":23,"checked":7},"ReAct — Synergizing Reasoning and Acting in Language Models","https:\u002F\u002Farxiv.org\u002Fabs\u002F2210.03629","研究论文","ReAct 中推理与动作交替的研究方法；不提供完整生产事务或安全架构。",{"title":25,"url":26,"type":27,"note":28,"checked":7},"OpenAI — Unrolling the Codex agent loop","https:\u002F\u002Fopenai.com\u002Findex\u002Funrolling-the-codex-agent-loop\u002F","工程报告","Codex 的模型、工具往返与上下文构建；不能推导所有 OpenAI 产品的内部实现。",{"title":30,"url":31,"type":32,"note":33,"checked":7},"OpenAI — Agents SDK","https:\u002F\u002Fopenai.github.io\u002Fopenai-agents-python\u002F","官方文档","SDK 执行、工具、sandbox 等当前能力；业务正确性与部署约束另行验证。",{"title":35,"url":36,"type":37,"note":38,"checked":7},"OpenAI — Introducing the Agents API","https:\u002F\u002Fopenai.com\u002Findex\u002Fintroducing-the-agents-api\u002F","产品发布说明","托管 Codex harness、执行环境与上下文\u002F工具能力的产品发布说明；不等于所有应用的 SLA。",{"title":40,"url":41,"type":27,"note":42,"checked":7},"Anthropic — Building effective agents","https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fbuilding-effective-agents","workflow \u002F agent 区分与组合模式；从简单基线起步并按任务评测。",{"title":44,"url":45,"type":27,"note":46,"checked":7},"Anthropic — Scaling Managed Agents","https:\u002F\u002Fwww.anthropic.com\u002Fengineering\u002Fmanaged-agents","session、harness、sandbox 解耦及恢复设计的公开报告；不定义所有外部工具的幂等语义。",{"title":48,"url":49,"type":32,"note":50,"checked":7},"OpenAI Agents SDK — Guardrails","https:\u002F\u002Fopenai.github.io\u002Fopenai-agents-python\u002Fguardrails\u002F","输入、输出与工具检查的执行位置；并行检查可能在判定前执行工具。",{"slug":52,"title":53,"date":7,"updated":7,"tags":54,"summary":58,"draft":14,"lang":15,"minutes":59},"agent-observability-delivery","Agent 怎么持续优化与上线：Trace、评测、SLO 和灰度交付的证据链",[9,55,56,57],"可观测性","评测","CI\u002FCD","对照 OpenAI tracing 与 harness 实践、Anthropic 长任务和评测方法，建立跨模型、工具、队列的观测链；解释 SLO、费用归因、Docker\u002FK8s 发布和可回滚的优化实验。",8,{"slug":61,"title":62,"date":7,"updated":7,"tags":63,"summary":66,"draft":14,"lang":15,"minutes":67},"prompt-context-engineering","Prompt 与上下文工程：OpenAI、Anthropic 的方法，版本发布与优化实验",[64,65,10,11],"Prompt","上下文工程","从官方提示实践与长上下文研究出发，解释指令、证据、历史和工具如何组合；用版本化发布包、受控实验、影子验证与灰度回滚，把 prompt 优化纳入工程流程。",7,{"type":69,"children":70},"root",[71,85,90,97,110,115,121,132,137,224,244,250,261,274,293,299,423,428,434,443,452,457,462,506,511,517,530,535,555,568,574,579,703,709,720,725,737,743,748,777],{"type":72,"tag":73,"props":74,"children":75},"element","p",{},[76,79],{"type":77,"value":78},"text","Agent 可以检索资料、调用工具、修改环境，再依据结果决定下一步。生产系统还必须回答：它实际完成了什么，失败后从哪里继续，谁有权批准操作，成本是否可控。",{"type":72,"tag":80,"props":81,"children":82},"strong",{},[83],{"type":77,"value":84},"模型能力、执行框架和业务正确性是相互关联的三个层次。",{"type":72,"tag":73,"props":86,"children":87},{},[88],{"type":77,"value":89},"本文以截至 2026-10-11 可核对的一手资料为依据。OpenAI 与 Anthropic 的工程文章提供公开实现经验；SDK 文档描述产品契约；研究论文提供特定实验环境下的证据。下文标为“工程推导”的设计是本文综合建议，不代表两家公司所有内部系统的实现。",{"type":72,"tag":91,"props":92,"children":94},"h2",{"id":93},"从研究问题开始为什么需要执行循环",[95],{"type":77,"value":96},"从研究问题开始：为什么需要执行循环",{"type":72,"tag":73,"props":98,"children":99},{},[100,108],{"type":72,"tag":101,"props":102,"children":105},"a",{"href":21,"rel":103},[104],"nofollow",[106],{"type":77,"value":107},"ReAct 论文",{"type":77,"value":109},"研究了推理与环境动作交替进行的方法：模型依据观察修正后续行动。它解释了 Agent 的一种基本组织方式，但没有证明一套通用生产架构，也不意味着今天的推理模型必须向用户展示完整思维链。",{"type":72,"tag":73,"props":111,"children":112},{},[113],{"type":77,"value":114},"工程上，这个循环可以简化为：读取任务与证据 → 请求模型 → 得到最终输出或工具请求 → 校验并执行工具 → 写入观察 → 继续。关键在于“观察”来自执行结果，而不是模型对成功的自述。数据库状态、测试结果或受控产物才是完成任务的证据。",{"type":72,"tag":91,"props":116,"children":118},{"id":117},"openai公开的-agent-loop-与三种接入层次",[119],{"type":77,"value":120},"OpenAI：公开的 agent loop 与三种接入层次",{"type":72,"tag":73,"props":122,"children":123},{},[124,130],{"type":72,"tag":101,"props":125,"children":127},{"href":26,"rel":126},[104],[128],{"type":77,"value":129},"Unrolling the Codex agent loop",{"type":77,"value":131},"公开说明了 Codex 如何围绕 Responses API 组织模型与工具往返，并把上下文管理纳入执行框架。它描述的是 Codex 的公开设计，不能直接推导 ChatGPT 所有功能的内部架构。",{"type":72,"tag":73,"props":133,"children":134},{},[135],{"type":77,"value":136},"开发者至少要区分以下层次：",{"type":72,"tag":138,"props":139,"children":140},"table",{},[141,165],{"type":72,"tag":142,"props":143,"children":144},"thead",{},[145],{"type":72,"tag":146,"props":147,"children":148},"tr",{},[149,155,160],{"type":72,"tag":150,"props":151,"children":152},"th",{},[153],{"type":77,"value":154},"接入方式",{"type":72,"tag":150,"props":156,"children":157},{},[158],{"type":77,"value":159},"得到什么",{"type":72,"tag":150,"props":161,"children":162},{},[163],{"type":77,"value":164},"应用需要明确什么",{"type":72,"tag":166,"props":167,"children":168},"tbody",{},[169,188,206],{"type":72,"tag":146,"props":170,"children":171},{},[172,178,183],{"type":72,"tag":173,"props":174,"children":175},"td",{},[176],{"type":77,"value":177},"模型 API \u002F Responses",{"type":72,"tag":173,"props":179,"children":180},{},[181],{"type":77,"value":182},"推理、工具调用请求与 API 提供的状态能力",{"type":72,"tag":173,"props":184,"children":185},{},[186],{"type":77,"value":187},"自己控制的循环、错误处理、业务授权与完成判定",{"type":72,"tag":146,"props":189,"children":190},{},[191,196,201],{"type":72,"tag":173,"props":192,"children":193},{},[194],{"type":77,"value":195},"Agents SDK",{"type":72,"tag":173,"props":197,"children":198},{},[199],{"type":77,"value":200},"运行循环、工具、handoff、guardrails、tracing 等组件",{"type":72,"tag":173,"props":202,"children":203},{},[204],{"type":77,"value":205},"部署方式、业务状态、外部工具权限、幂等与验收",{"type":72,"tag":146,"props":207,"children":208},{},[209,214,219],{"type":72,"tag":173,"props":210,"children":211},{},[212],{"type":77,"value":213},"托管 Agents API",{"type":72,"tag":173,"props":215,"children":216},{},[217],{"type":77,"value":218},"厂商运行的 Codex harness 与配套云端执行能力",{"type":72,"tag":173,"props":220,"children":221},{},[222],{"type":77,"value":223},"环境选择、业务集成、数据约束、权限与结果验证",{"type":72,"tag":73,"props":225,"children":226},{},[227,229,234,236,242],{"type":77,"value":228},"截至核对时，",{"type":72,"tag":101,"props":230,"children":232},{"href":31,"rel":231},[104],[233],{"type":77,"value":195},{"type":77,"value":235},"还提供隔离工作空间与可恢复 sandbox session；",{"type":72,"tag":101,"props":237,"children":239},{"href":36,"rel":238},[104],[240],{"type":77,"value":241},"Agents API 的发布说明",{"type":77,"value":243},"则介绍托管 harness、可选择执行环境、上下文压缩与工具发现。这些能力的存在，不能被简化成“SDK 都不保存状态”，也不能被反向理解为“用了托管服务就自动保证业务事务”。两种产品的契约与可用范围需要分别确认。",{"type":72,"tag":91,"props":245,"children":247},{"id":246},"anthropic从最简单的工作流到拆开执行框架与环境",[248],{"type":77,"value":249},"Anthropic：从最简单的工作流，到拆开执行框架与环境",{"type":72,"tag":73,"props":251,"children":252},{},[253,259],{"type":72,"tag":101,"props":254,"children":256},{"href":41,"rel":255},[104],[257],{"type":77,"value":258},"Building effective agents",{"type":77,"value":260},"区分预先定义路径的 workflow 与由模型动态决定路径的 agent，强调从简单方案起步。固定的提取、校验、写入流程通常不需要把所有步骤交给模型决策。",{"type":72,"tag":73,"props":262,"children":263},{},[264,266,272],{"type":77,"value":265},"2026 年的 ",{"type":72,"tag":101,"props":267,"children":269},{"href":45,"rel":268},[104],[270],{"type":77,"value":271},"Managed Agents 工程报告",{"type":77,"value":273},"进一步公开了三个可独立替换的部分：session 保存事件，harness 组织模型与工具循环，sandbox 提供执行环境。其会话日志位于上下文窗口之外，运行框架和环境可以分别恢复；报告还讨论了把凭据隔离在受控代理之外的做法。",{"type":72,"tag":73,"props":275,"children":276},{},[277,279,284,286,291],{"type":77,"value":278},"这里的启发是把",{"type":72,"tag":80,"props":280,"children":281},{},[282],{"type":77,"value":283},"可恢复的记录",{"type":77,"value":285},"与",{"type":72,"tag":80,"props":287,"children":288},{},[289],{"type":77,"value":290},"当前一次模型能看到的内容",{"type":77,"value":292},"分开。压缩上下文可以节省 token，但不应顺便销毁审计、恢复或验收仍需要的原始事件。具体日志留存仍受隐私、成本与删除要求约束。",{"type":72,"tag":91,"props":294,"children":296},{"id":295},"怎样比较两家按职责避免只比框架名字",[297],{"type":77,"value":298},"怎样比较两家：按职责，避免只比框架名字",{"type":72,"tag":138,"props":300,"children":301},{},[302,328],{"type":72,"tag":142,"props":303,"children":304},{},[305],{"type":72,"tag":146,"props":306,"children":307},{},[308,313,318,323],{"type":72,"tag":150,"props":309,"children":310},{},[311],{"type":77,"value":312},"研究维度",{"type":72,"tag":150,"props":314,"children":315},{},[316],{"type":77,"value":317},"OpenAI 公开资料",{"type":72,"tag":150,"props":319,"children":320},{},[321],{"type":77,"value":322},"Anthropic 公开资料",{"type":72,"tag":150,"props":324,"children":325},{},[326],{"type":77,"value":327},"生产选型要验证的问题",{"type":72,"tag":166,"props":329,"children":330},{},[331,354,377,400],{"type":72,"tag":146,"props":332,"children":333},{},[334,339,344,349],{"type":72,"tag":173,"props":335,"children":336},{},[337],{"type":77,"value":338},"执行循环",{"type":72,"tag":173,"props":340,"children":341},{},[342],{"type":77,"value":343},"Codex loop、SDK 运行器、托管 harness",{"type":72,"tag":173,"props":345,"children":346},{},[347],{"type":77,"value":348},"workflow\u002Fagent 模式、Managed Agents harness",{"type":72,"tag":173,"props":350,"children":351},{},[352],{"type":77,"value":353},"谁负责恢复、退出和版本兼容？",{"type":72,"tag":146,"props":355,"children":356},{},[357,362,367,372],{"type":72,"tag":173,"props":358,"children":359},{},[360],{"type":77,"value":361},"状态",{"type":72,"tag":173,"props":363,"children":364},{},[365],{"type":77,"value":366},"SDK 会话、运行状态与 sandbox session 等不同能力",{"type":72,"tag":173,"props":368,"children":369},{},[370],{"type":77,"value":371},"上下文之外的 session 事件日志",{"type":72,"tag":173,"props":373,"children":374},{},[375],{"type":77,"value":376},"外部写入结果在哪里确认？",{"type":72,"tag":146,"props":378,"children":379},{},[380,385,390,395],{"type":72,"tag":173,"props":381,"children":382},{},[383],{"type":77,"value":384},"执行环境",{"type":72,"tag":173,"props":386,"children":387},{},[388],{"type":77,"value":389},"SDK sandbox 或托管 API 的环境选项",{"type":72,"tag":173,"props":391,"children":392},{},[393],{"type":77,"value":394},"与 harness 解耦的 sandbox \u002F tools",{"type":72,"tag":173,"props":396,"children":397},{},[398],{"type":77,"value":399},"权限、网络、凭据与资源怎样约束？",{"type":72,"tag":146,"props":401,"children":402},{},[403,408,413,418],{"type":72,"tag":173,"props":404,"children":405},{},[406],{"type":77,"value":407},"编排",{"type":72,"tag":173,"props":409,"children":410},{},[411],{"type":77,"value":412},"tools、manager 与 handoff 等方式",{"type":72,"tag":173,"props":414,"children":415},{},[416],{"type":77,"value":417},"固定流程、动态编排与多 Agent 实验",{"type":72,"tag":173,"props":419,"children":420},{},[421],{"type":77,"value":422},"增加编排后，净收益是否超过延迟和费用？",{"type":72,"tag":73,"props":424,"children":425},{},[426],{"type":77,"value":427},"这是对公开资料的职责归纳，不是跨产品统一基准。文章中的架构相似性，也不构成两家产品具有相同 SLA、恢复语义或数据政策的证据。",{"type":72,"tag":91,"props":429,"children":431},{"id":430},"工程推导一个有边界的最小生产架构",[432],{"type":77,"value":433},"工程推导：一个有边界的最小生产架构",{"type":72,"tag":73,"props":435,"children":436},{},[437],{"type":72,"tag":438,"props":439,"children":442},"img",{"alt":440,"src":441},"生产 Agent 的职责边界：入口与任务状态、执行循环、工具环境、事件和验收","\u002Fdiagrams\u002Fproduction-agent-design.svg",[],{"type":72,"tag":73,"props":444,"children":445},{},[446],{"type":72,"tag":447,"props":448,"children":449},"em",{},[450],{"type":77,"value":451},"图 1 · 本文综合设计。箭头表示受控调用与事件回写；业务数据库、任务记录和模型上下文承担不同职责。",{"type":72,"tag":73,"props":453,"children":454},{},[455],{"type":77,"value":456},"先把“帮我处理请求”写成任务契约：输入是什么、成功如何确认、哪些动作可自动执行、何时需要审批、预算与截止时间多少、证据不足怎样退出。例如资料分析 Agent 的成功可以是“生成包含来源定位的报告”，而不是“输出一段流畅总结”；处理工单还要验证授权状态变更实际生效。",{"type":72,"tag":73,"props":458,"children":459},{},[460],{"type":77,"value":461},"最小实现可以保持一个部署单元，但分清四条边界：",{"type":72,"tag":463,"props":464,"children":465},"ol",{},[466,477,486,496],{"type":72,"tag":467,"props":468,"children":469},"li",{},[470,475],{"type":72,"tag":80,"props":471,"children":472},{},[473],{"type":77,"value":474},"入口与任务管理",{"type":77,"value":476},"：鉴权、租户隔离、幂等接收、配额和任务状态。",{"type":72,"tag":467,"props":478,"children":479},{},[480,484],{"type":72,"tag":80,"props":481,"children":482},{},[483],{"type":77,"value":338},{"type":77,"value":485},"：根据任务状态构造上下文，限制轮数、时间、费用与工具并发。",{"type":72,"tag":467,"props":487,"children":488},{},[489,494],{"type":72,"tag":80,"props":490,"children":491},{},[492],{"type":77,"value":493},"工具与环境",{"type":77,"value":495},"：schema 校验之后再做权限与业务校验，限制文件、网络和副作用。",{"type":72,"tag":467,"props":497,"children":498},{},[499,504],{"type":72,"tag":80,"props":500,"children":501},{},[502],{"type":77,"value":503},"证据与验收",{"type":77,"value":505},"：记录执行事件、版本和受控产物，依据最终结果决定完成或失败。",{"type":72,"tag":73,"props":507,"children":508},{},[509],{"type":77,"value":510},"模块边界不要求立即拆成微服务。先用内部接口和清晰数据所有权隔离；当资源、故障、权限或独立扩容需求出现时，再拆部署。过早增加网络调用会引入新的超时、认证和一致性问题。",{"type":72,"tag":91,"props":512,"children":514},{"id":513},"状态机暂停失败与结果未知怎么继续",[515],{"type":77,"value":516},"状态机：暂停、失败与“结果未知”怎么继续",{"type":72,"tag":518,"props":519,"children":524},"pre",{"className":520,"code":522,"language":77,"meta":523},[521],"language-text","accepted → queued → running → verifying → completed\n                         ↘ awaiting_approval → running\n                         ↘ retry_wait → queued\n                         ↘ reconciling → running \u002F failed\n                         ↘ cancelled \u002F failed\n","",[525],{"type":72,"tag":526,"props":527,"children":528},"code",{"__ignoreMap":523},[529],{"type":77,"value":522},{"type":72,"tag":73,"props":531,"children":532},{},[533],{"type":77,"value":534},"以上是业务状态示意，不是厂商 API 的枚举。每次执行保存任务 ID、尝试 ID、当前步骤、已确认工具结果、版本和剩余预算。审批必须绑定具体参数与对象版本；内容改变后旧审批不能继续生效。",{"type":72,"tag":73,"props":536,"children":537},{},[538,540,545,547,553],{"type":77,"value":539},"最棘手的情况是外部写入成功，但响应丢失。此时不能直接认定失败并创建新操作：先按稳定业务操作 ID 查询或对账；支持幂等的上游复用同一键；不支持查询或去重时转入人工确认。",{"type":72,"tag":80,"props":541,"children":542},{},[543],{"type":77,"value":544},"可恢复执行仍需要处理副作用的不确定性。",{"type":77,"value":546}," 详见",{"type":72,"tag":101,"props":548,"children":550},{"href":549},"\u002Farticles\u002Fagent-concurrency-state",[551],{"type":77,"value":552},"并发与状态篇",{"type":77,"value":554},"。",{"type":72,"tag":73,"props":556,"children":557},{},[558,560,566],{"type":77,"value":559},"安全检查也有执行位置。",{"type":72,"tag":101,"props":561,"children":563},{"href":49,"rel":562},[104],[564],{"type":77,"value":565},"OpenAI guardrails 文档",{"type":77,"value":567},"明确：并行输入检查可能在判定前已经让 Agent 消耗 token 或执行工具。高影响动作应在执行前有阻断检查、工具侧授权或审批；最终输出检查无法撤销已经发生的外部修改。",{"type":72,"tag":91,"props":569,"children":571},{"id":570},"优化研究先找失败来源再增加复杂度",[572],{"type":77,"value":573},"优化研究：先找失败来源，再增加复杂度",{"type":72,"tag":73,"props":575,"children":576},{},[577],{"type":77,"value":578},"单 Agent 加工具是有用的基线。只在任务确实可分解、结果可合并时比较多 Agent；只有检索证据缺失时，才优先修解析、召回与重排；工具误选则先检查描述、重叠接口与结果体积。更复杂的规划器不能自动修复权限错误或错误资料。",{"type":72,"tag":138,"props":580,"children":581},{},[582,608],{"type":72,"tag":142,"props":583,"children":584},{},[585],{"type":72,"tag":146,"props":586,"children":587},{},[588,593,598,603],{"type":72,"tag":150,"props":589,"children":590},{},[591],{"type":77,"value":592},"待验证假设",{"type":72,"tag":150,"props":594,"children":595},{},[596],{"type":77,"value":597},"控制变量与改动",{"type":72,"tag":150,"props":599,"children":600},{},[601],{"type":77,"value":602},"观测指标",{"type":72,"tag":150,"props":604,"children":605},{},[606],{"type":77,"value":607},"可能的反效果",{"type":72,"tag":166,"props":609,"children":610},{},[611,634,657,680],{"type":72,"tag":146,"props":612,"children":613},{},[614,619,624,629],{"type":72,"tag":173,"props":615,"children":616},{},[617],{"type":77,"value":618},"工具太多导致误选",{"type":72,"tag":173,"props":620,"children":621},{},[622],{"type":77,"value":623},"固定模型与任务，只按需加载工具",{"type":72,"tag":173,"props":625,"children":626},{},[627],{"type":77,"value":628},"工具选择准确率、调用次数、输入 token",{"type":72,"tag":173,"props":630,"children":631},{},[632],{"type":77,"value":633},"漏加载工具，增加发现轮次",{"type":72,"tag":146,"props":635,"children":636},{},[637,642,647,652],{"type":72,"tag":173,"props":638,"children":639},{},[640],{"type":77,"value":641},"大工具结果分散注意力",{"type":72,"tag":173,"props":643,"children":644},{},[645],{"type":77,"value":646},"比较完整结果与摘要加可追溯引用",{"type":72,"tag":173,"props":648,"children":649},{},[650],{"type":77,"value":651},"任务成功率、证据召回、p95、费用",{"type":72,"tag":173,"props":653,"children":654},{},[655],{"type":77,"value":656},"摘要丢失关键字段",{"type":72,"tag":146,"props":658,"children":659},{},[660,665,670,675],{"type":72,"tag":173,"props":661,"children":662},{},[663],{"type":77,"value":664},"独立调查可并行",{"type":72,"tag":173,"props":666,"children":667},{},[668],{"type":77,"value":669},"比较串行单 Agent 与有上限的并行分工",{"type":72,"tag":173,"props":671,"children":672},{},[673],{"type":77,"value":674},"验收成功率、尾延迟、总 token",{"type":72,"tag":173,"props":676,"children":677},{},[678],{"type":77,"value":679},"合并冲突、重复工作、限流",{"type":72,"tag":146,"props":681,"children":682},{},[683,688,693,698],{"type":72,"tag":173,"props":684,"children":685},{},[686],{"type":77,"value":687},"执行环境冷启动拖慢响应",{"type":72,"tag":173,"props":689,"children":690},{},[691],{"type":77,"value":692},"比较预启动与按需启动",{"type":72,"tag":173,"props":694,"children":695},{},[696],{"type":77,"value":697},"首个有用结果时间、环境费用、失败率",{"type":72,"tag":173,"props":699,"children":700},{},[701],{"type":77,"value":702},"重任务把启动成本推到后段",{"type":72,"tag":704,"props":705,"children":707},"h3",{"id":706},"怎样读厂商报告的优化数字",[708],{"type":77,"value":706},{"type":72,"tag":73,"props":710,"children":711},{},[712,718],{"type":72,"tag":101,"props":713,"children":715},{"href":45,"rel":714},[104],[716],{"type":77,"value":717},"Managed Agents 原始报告",{"type":77,"value":719},"称，将推理与执行容器解耦、按需启动容器后，其系统 p50 TTFT 下降约 60%，p95 下降超过 90%。这是报告中的架构优化结果，不是“模型能力提高 90%”，也不是所有 Agent 服务都能复制的收益。",{"type":72,"tag":73,"props":721,"children":722},{},[723],{"type":77,"value":724},"工程推导：先用 trace 验证自己的首响应是否被环境启动阻塞，再比较按需与预启动的负载、环境费用、任务完成时间和失败率。若大部分任务立即需要 sandbox，启动成本可能只是被推迟到后面，首 token 更快仍需要与完整任务体验一起判断。",{"type":72,"tag":73,"props":726,"children":727},{},[728,730,735],{"type":77,"value":729},"这些是本文提出的实验，不是已测得的收益。用相同任务集记录逐任务差异，多次运行观察稳定性；把检索、模型、工具与验收耗时拆开。优化目标可使用“",{"type":72,"tag":80,"props":731,"children":732},{},[733],{"type":77,"value":734},"每个验收成功任务的总成本",{"type":77,"value":736},"”，把失败、重试、压缩、审核与基础设施计入，避免仅因回答缩短就宣布成功。",{"type":72,"tag":91,"props":738,"children":740},{"id":739},"从方案到上线交付需要留下哪些证据",[741],{"type":77,"value":742},"从方案到上线：交付需要留下哪些证据",{"type":72,"tag":73,"props":744,"children":745},{},[746],{"type":77,"value":747},"一次完整交付至少包括：需求与验收表、接口和权限契约、状态恢复设计、离线评测结果、容量与故障演练、版本化发布包、灰度观测和回滚流程。模型或 prompt 的变化应与代码一样可追踪；外部工具、知识库与安全策略变化也可能引起回归。",{"type":72,"tag":73,"props":749,"children":750},{},[751,753,759,761,767,769,775],{"type":77,"value":752},"继续阅读",{"type":72,"tag":101,"props":754,"children":756},{"href":755},"\u002Farticles\u002Fprompt-context-engineering",[757],{"type":77,"value":758},"Prompt 与上下文工程",{"type":77,"value":760},"、",{"type":72,"tag":101,"props":762,"children":764},{"href":763},"\u002Farticles\u002Fagent-observability-delivery",[765],{"type":77,"value":766},"观测与交付",{"type":77,"value":768},"和",{"type":72,"tag":101,"props":770,"children":772},{"href":771},"\u002Farticles\u002Fllm-eval-loop",[773],{"type":77,"value":774},"评测闭环",{"type":77,"value":776},"。能解释这条证据链，才真正解释了 Agent 从能力演示到生产服务的过程。",{"type":72,"tag":91,"props":778,"children":780},{"id":779},"参考资料",[781],{"type":77,"value":779},[783,785,786,787,788,789,790,794,795],{"id":93,"depth":784,"text":96},2,{"id":117,"depth":784,"text":120},{"id":246,"depth":784,"text":249},{"id":295,"depth":784,"text":298},{"id":430,"depth":784,"text":433},{"id":513,"depth":784,"text":516},{"id":570,"depth":784,"text":573,"children":791},[792],{"id":706,"depth":793,"text":706},3,{"id":739,"depth":784,"text":742},{"id":779,"depth":784,"text":779},1792400815607]