Agent 实践
Responses API 与 Agents SDK 首发复盘：从模型调用到可审计 Agent 运行时
以 2025 年 3 月 11 日至 13 日的一手资料为边界，分析 Responses API、内置工具、Agents SDK 与 tracing 如何改变 Agent 工程，并给出状态、权限、评测和商业验收方法。
时间与证据
本文研究的是 OpenAI 在 2025 年 3 月 11 日发布 Responses API、web search、file search、computer use、Agents SDK 与 tracing 工具的事件，信息边界截止到 3 月 13 日。文章发布日期与更新日期见页首。首发公告会继续更新，因此本文把当前官方页与 3 月 12 日的 id_ 固定快照配对；同期判断只使用快照中当时已经出现的能力、可用范围和迁移说明。
首发页把 Agent 定义为可以代表用户独立完成任务的系统，并把发布内容分为两层：Responses API 是统一模型与内置工具调用的 API 原语；Agents SDK 负责单 Agent、多 Agent 编排与执行跟踪。web search、file search 和 computer use 是内置工具，而 tracing 用来检查工作流运行。它们同日出现，不等于已经形成一套替企业处理身份、审批、业务事务和事故恢复的完整运行时。
公告还说明 Responses API 当日向所有开发者开放，API 本身不另收费用，模型 token 与工具按当时定价计费；Chat Completions 仍会继续支持，Responses API 被推荐用于新的 Agent 集成。公告对 Assistants API 的退场只给出未来计划，不能把后来实际迁移进度倒填为 3 月 11 日已经完成。
本文证据等级是 sourced。我核验了官方首发页与同期固定快照，但没有在 2025 年的原始模型、价格、SDK 和工具版本上重放请求，也没有获得可比的真实企业任务日志。因此文中没有本站工具成功率、延迟或成本结果，所有数字门槛都是未来试点的验收条件，不是实验结论。
当时发生了什么
从聊天消息转向执行项
Chat Completions 的核心抽象是输入消息与模型输出；Agent 任务还包含搜索、文件检索、计算机操作、函数调用、工具返回、错误和中间状态。Responses API 首发页强调统一的 item-based design、流式事件和 response.output_text 等 SDK 助手。重要变化不是字段名称，而是一次运行可以包含不同类型的输入、输出与工具步骤，应用不必把所有过程压成一段文本。
统一原语能减少模型供应层的胶水代码，却没有消除业务层。模型返回一个 function call，只能证明模型提出了调用意图，不能证明当前用户有权限执行、参数属于正确租户、库存版本仍然有效或上一次超时调用没有已经成功。工具结果也只是外部数据，可能包含过期内容、提示注入或与 schema 不符的字段。
内置工具降低接入成本，也改变责任边界
web search 提供带来源链接的及时信息，file search 提供文件检索、查询优化、元数据过滤和重排，computer use 允许模型通过界面执行任务。首发公告将这些工具定位为 Responses API 中可组合的能力。对开发团队来说，它们把搜索引擎、向量检索和浏览器操作的一部分集成成本交给平台。
但托管不等于免责。搜索引用要检查是否真正支撑结论；文件检索必须在检索前按租户和角色过滤；计算机操作必须在提交订单、发送消息、修改权限等有副作用动作前停下来。若系统只在最终答案阶段做权限判断，敏感文档可能已经在检索阶段泄露，浏览器也可能已经改变外部状态。
SDK 与 tracing 是编排工具，不是业务真相
Agents SDK 让开发者组织单 Agent 和多 Agent 工作流，并通过 tracing 观察执行。Tracing 能回答模型调用了什么工具、耗时多久、在哪一步失败，却不能单独回答退款是否真正到账、邮件是否重复发送或数据库是否提交。权威状态仍在支付、订单、CRM、数据库与审计系统中。
因此生产 Agent 至少有三条不同的记录链：模型轨迹用于调试，业务事件用于恢复与对账，安全审计用于证明谁以什么权限触发了什么动作。把完整 prompt、客户文档和密钥参数无差别写进 tracing，还会制造新的隐私与泄露面。
任务判断
假设一家 B2B SaaS 公司希望处理“账单争议初审”。客户提交工单后，系统要读取合同与发票、查询支付状态、检索当时政策、生成处理建议；低风险错误可创建修正草稿，高金额退款必须由财务确认。输入跨越文件、数据库和网页，输出也不只是回答，而是带证据、风险等级与下一步动作的业务任务。
这类任务适合验证 Responses API 的组合能力，但不适合一开始全自动退款。首个范围应是只读调查和候选方案：模型可以调用 file search 找合同条款、调用内部只读函数取支付记录、使用 web search 查公开政策更新，然后生成结构化建议。任何写操作都进入独立执行服务，并由确定性权限与金额规则决定是否要求人工批准。
评测集应来自去标识化历史工单，至少覆盖正常重复扣费、合同例外、跨租户同名客户、缺失附件、过期政策、恶意文档提示、工具超时、支付状态未知和需要拒绝处理的高风险请求。每个样本保存业务断言：必须引用哪份合同、允许读取哪些对象、期望风险等级、是否可以创建草稿，以及最终不得发生什么副作用。
核心指标不是“回答像不像专家”，而是：证据支持率、权限违规率、工具参数 schema 通过率、首次完成率、人工修改分钟、未知终态比例、P95 完成时间和单位合格任务成本。
单位合格任务成本
=（模型 token + 搜索/检索/计算机工具 + 重试与队列
+ 人工复核分钟 × 人工单价 + 事故期望损失）
/ 通过权限、证据和业务断言的任务数
如果只把成功请求计入分母，最难和最贵的失败会被隐藏。所有拒绝、超时、转人工和最终状态未知的任务都要保留在同一批次中。
工程影响
运行状态必须由业务系统保存
我会把一次 Agent 运行建模为显式状态机，而不是依赖一串聊天记录：
accepted -> gathering -> planning -> waiting_tool
-> needs_approval -> executing -> verifying
-> completed | failed | cancelled | unknown
每次迁移保存 run_id、调用者、租户、策略版本、输入摘要、模型版本、工具名、参数 hash、前后业务版本和结果引用。unknown 是必要终态：客户端超时或网络断开时，外部退款可能已经完成，系统不能因为没收到响应就自动重放。它应先根据支付平台的幂等键或业务记录对账，再决定完成、失败或转人工。
Responses API 的响应对象可以帮助延续模型上下文，但不能替代自己的任务表、outbox、幂等记录和事务边界。供应商侧记录被删除、接口迁移或模型行为变化时，业务仍要能够解释并恢复运行。
身份不能由模型参数声明
工具处理器从可信会话或服务身份获得 principal、tenant 与 scope，不接受模型在 JSON 中提交的 user_id 作为授权依据。检索在召回前过滤租户；写操作将审批绑定到调用者、工具、规范化参数、策略版本、业务对象版本和过期时间，并且一次性消费。
模型生成的工具参数要通过 JSON Schema、业务规则和资源级授权。工具注释如“只读”只能帮助模型规划，不能作为安全策略。对数据库更新、消息发送和退款，执行服务还要使用 expected version 或等价的乐观并发控制，避免批准后对象已经变化。
Tracing 要可用，也要最小化
建议把观察数据分层：运行层记录步骤、token、延迟、错误码和模型版本；业务层记录权威对象与状态变化；安全层记录策略决定和审批。原始合同、支付信息、cookie、Authorization、完整工具参数和模型隐藏推理默认不进入通用 trace，只保存受控引用、字段级脱敏结果或不可逆 hash。
每次上线固定一组回归任务与工具模拟器，注入 429、超时、格式错误、空检索、重复回调和提交后断线。真正要验证的是系统是否有限重试、是否错误地重复副作用、是否能从权威状态恢复，而不是 happy path 是否能跑通。
多 Agent 不是默认升级
SDK 支持 handoff 或多 Agent 编排不意味着任务应拆成多个角色。每增加一个 Agent，就增加一次模型决定、上下文传递、权限面和故障点。只有当子任务有不同工具权限、独立评测标准或可并行缩短关键路径时，拆分才可能成立。
账单争议可以把“证据收集”和“财务审批”隔离，但审批本身不应交给另一个自然语言角色。它应是业务规则和真人负责的控制点。对于短任务，单 Agent 加确定性工具通常更容易测试和追责。
商业价值
可能付费的买家不是想要一个更会聊天的窗口，而是拥有大量跨系统重复调查、又能明确验收结果的运营团队，例如客户支持、法务检索、销售运营、采购和内部 IT。Responses API 与内置工具降低了首次集成成本，Agents SDK 与 tracing 缩短调试周期；真正可售卖的仍是接入企业数据、权限策略、评测、人工工作台和持续运营。
收益可能来自减少切换系统与收集证据的时间、提高一次处理完整度、缩短工单等待并让高级人员集中处理例外。成本则来自模型与工具费用、数据接入、索引维护、身份映射、人工复核、审计存储、失败恢复和供应商迁移。内置工具的单价只是总成本的一部分。
建议进行 8 周试点：前 2 周建立历史基线与失败分类；第 3 至 5 周影子运行，只生成建议；第 6 至 8 周只允许创建可撤销草稿。扩大流量前预先约定：权限违规必须为 0，最终状态未知必须全部在时限内对账，证据支持率不低于人工基线，人工处理分钟至少下降 20%，单位合格任务成本低于节省的人工与等待成本。这些是可证伪门槛，不是本站已经取得的结果。
不应采用的场景包括：任务没有可定义的正确结果；必须在毫秒级返回；数据不能离开现有边界；错误会立即造成不可逆高额损失；现有规则引擎已经稳定低价完成；或团队没有能力维护权限、评测和事件响应。此时增加 Agent 只会把确定问题改造成概率问题。
局限与风险
第一，本文没有复现 Responses API、工具或 Agents SDK 的首发行为，公告中的产品描述与案例均是厂商材料。第二，web search 的引用可能不完整，file search 的召回可能漏掉关键条款，computer use 会受页面变化、登录状态和提示注入影响；三者都需要任务级失败样本。
第三，统一 API 容易形成平台锁定。业务层应保存供应商中立的 task、tool call、approval 和 result 模型，并把平台响应转换为内部事件，避免核心事务只能从某个 response 对象恢复。第四，托管 tracing 与文件存储会扩大数据驻留和删除治理范围。
第五，多 Agent 的自然语言 handoff 可能丢失约束、重复调用或让身份边界变模糊。第六，模型升级、搜索索引更新和工具实现变更都可能让同一输入产生不同路径，回归必须固定模型标识、工具版本、策略版本、数据集 hash 与评测器。
最后，Agent 轨迹不是合规证据本身。它可以帮助解释模型做了什么，但权威证明来自身份系统、审批记录、业务数据库、外部提供方回执和不可篡改审计事件。
面试表达
30 秒结论： 2025 年 3 月 11 日的 Responses API 把模型、web search、file search、computer use 与统一输出放进一个 Agent 原语，Agents SDK 补上编排和 tracing。它降低了接入成本，但没有替代业务状态、权限、幂等和验证。我的设计会把模型调用与有副作用执行分开，以可信身份和一次性审批授权，并从权威业务状态处理超时后的 unknown。
3 分钟展开： 我会先选一个证据可检查、写操作可撤销的任务，用去标识化历史样本建立基线。运行时保存显式状态机，工具参数经过 schema、租户与资源授权；检索在召回前做权限过滤，退款等动作使用幂等键和 expected version。Tracing 只记录必要元数据，业务事件另存。评测同时看证据支持率、权限违规、未知终态、P95、人工分钟和单位合格任务成本，而不是只看模型回答。
如果追问“有 tracing 为什么还需要任务表”，答案是 tracing 面向模型执行观察，任务表面向业务恢复和事务。上游超时不代表动作失败，模型轨迹也不能证明支付平台最终状态；只有本地状态机与权威系统对账能决定是否重试。
复盘
站在 2026 年回看，这次发布的重要信号不是又出现一个 Agent 框架，而是模型平台开始提供统一执行原语、托管工具与观察能力。Agent 开发从 prompt 拼接逐步转向运行时工程，但最难的部分仍留在企业自己手中：身份、数据边界、状态、审批、评测和事故责任。
当时最容易犯的错误是把“只需一次 API 调用使用多个工具”理解成“一次调用即可上线”。平台可以减少协议适配，却不能知道企业合同的权威版本、谁能退款、重复提交如何处理、失败多久必须人工接管。系统能力要以最终业务状态验收，而不是以上游返回 completed 验收。
下一步应把本站已有的 MCP 权限网关与 Agent 未知终态实验接入同一运行模型，增加 Responses API 适配器后，用固定工单集比较托管工具与自建工具的正确率、延迟、数据边界和成本。只有取得可重复原始结果，本文才能从 sourced 升级为 reproduced。
方法披露
本文使用 AI 工具辅助整理首发页结构、检查文章契约和形成初稿；事件日期、T+1 archive、首发可用范围、事实与判断边界由作者逐项核验。本文未调用 2025 年首发版本的 Responses API、内置工具或 Agents SDK，所有架构、指标与试点门槛均明确写为工程方案。
修订记录
2025-03-15：初版发布；固定 2025-03-11 至 03-13 的首发信息边界，补充业务状态机、可信身份、幂等执行、最小化 tracing、单位合格任务成本和可证伪试点条件。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论