让 Agent 更可靠：从 Responses API 到 Agents SDK 的四个工程落点

本文根据 OpenAI 的公开文章《New tools for building agents》做中文改写与实践解读。原文地址：openai[dot]com / index / new-tools-for-building-agents /

1. 先把模型调用统一起来

构建 Agent 时，第一步不是堆叠更多提示词，而是把模型调用、上下文和工具结果放进一条可追踪的请求链。Responses API 将多轮响应、工具调用和输出组织到统一接口里，便于在同一个执行循环中保留上下文，也便于后续替换模型或增加工具。

2. 工具边界要显式

浏览器、搜索、文件处理和业务 API 都应该被包装成清晰的工具：输入参数有约束，输出结构稳定，失败时返回可读的错误。工具说明越具体，Agent 越少“猜接口”，测试也越容易覆盖。涉及写入、删除和对外发送的工具，最好再增加权限检查和人工兜底。

3. 编排逻辑保持可读

简单任务可以由一个 Agent 顺序调用工具；复杂任务再拆成规划、执行和校验几个阶段。每一步都记录目标、输入、输出与失败原因，避免让一个超长提示词承担全部控制逻辑。需要多 Agent 协作时，优先用明确的状态转移和结束条件，少用隐式的互相转发。

4. 追踪与评测和功能同等重要

Agent 的问题往往不是“完全不能运行”，而是偶尔选错工具、引用过期资料或在边界条件下循环。为每次运行保留 trace，记录模型、工具、耗时和结果，再用一组固定案例做回归评测，才能知道改动究竟提升还是损害了可靠性。评测集应覆盖正常路径、空结果、权限拒绝和工具超时。

5. 失败处理也要成为产品能力

工具超时、权限不足、参数不完整时，Agent 应返回下一步可执行的提示，而不是继续猜测。可以给每个工具定义超时、重试和降级策略，记录错误码并在界面展示简洁原因。对于不可逆操作，先生成预览或计划，等权限校验通过后再执行。

6. 让评测集贴近真实工作

固定评测不应只有“标准答案”，还要包含模糊请求、冲突信息、空检索结果和用户中途改口等情况。除了最终答案，还要检查工具选择、引用来源、耗时和是否按约束停止。把这些结果作为持续集成的一部分，能在模型或提示词升级时及时发现回归。

7. 一个轻量落地顺序

可以按“统一模型调用 → 封装少量工具 → 加入状态和日志 → 建立评测集 → 扩展多 Agent”的顺序推进。这样既能尽快交付可用版本，也能让风险随着复杂度逐步暴露，而不是在最后一次性排查。

来源：OpenAI《New tools for building agents》，网址：openai[dot]com / index / new-tools-for-building-agents /。