Agent 不是会聊天的 AI：把一次回答变成一个能收工的循环

让模型回答“项目里可能有哪些过时 API”，和让它真的检查仓库，是两件事。

前者只需要生成文字。后者至少要读取文件、搜索调用位置、核实上下文，再把证据整理出来。若任务还包含改代码，风险又升一级。Agent 之所以有用，正是因为它能把一次回答扩成多步工作；也正因如此，我们必须问：它凭什么继续，什么时候该停？

循环比“智能体”这个名字更重要

以 OpenAI Agents SDK 的运行说明为例，一次运行大致会经历：把准备好的输入交给模型、检查输出、执行模型请求的工具调用并继续；如果发生交接，就换到相应的 Agent；等得到最终输出且没有待处理的工具工作时才返回。

换成不绑定任何 SDK 的伪代码，大概是这样：

输入目标和上下文
在步数预算内重复：
    让模型决定下一步
    如果是最终回答：返回
    如果是工具请求：校验权限 → 执行 → 把结果放回上下文
    如果请求人工确认：暂停并等待
    如果出错：按策略重试、改道或停止
超过预算：停止并说明做到哪里

这段是帮助理解的伪代码，不是某个框架可直接运行的 API。实际 SDK 会替你管理其中一部分，自己搭建时则要明确每一步由谁负责。

循环里的“结果”很重要。模型请求搜索文件，不代表文件已成功读取；工具返回“没有权限”，也不该被模型补写成“检查完成”。Agent 需要把工具的真实观察带回上下文，才能决定是否继续。

第一道是步数边界。 如果 Agent 不断查询、总结、再查询，就可能永远兜圈子，也可能烧掉预算。设置最大轮数或时间限制，让它在预算耗尽时收尾并报告未完成项。

第二道是动作边界。 搜索和读取通常比写入风险低；改文件、开工单、发邮件、删数据会产生副作用。给工具分级，先从只读权限开始。高影响动作应要求确认，或由确定性的业务规则拦截。

第三道是证据边界。 最终回答要区分“我查到了什么”和“我推测可能是什么”。错误、空结果、被拒绝的调用都属于过程证据，不能被一段自信的总结覆盖。

在刚才的假设任务中，一个安全的第一版可以只让 Agent 搜索并列出可疑位置，不写回文件。等验证输出质量后，再增加补丁草稿；是否应用补丁仍由开发者确认。这种递进方式比一开始就给仓库写权限容易调试，也更容易判断到底哪一环出错。

工具出错、达到最大轮数、验证不通过，都是正常的运行结果。等待人工审批也不是“卡死”：它是一个暂停点，批准后从保存的状态继续，比重新开一轮并丢掉上下文更清晰。

可以把每轮记录成一条简短轨迹：模型提出什么动作、系统实际调用了什么、工具返回什么、为何继续或结束。没有这条轨迹，出问题时只能盯着最终答案猜；有了它，才有机会区分模型判断错误、工具本身失败还是权限配置不当。

因此，Agent 的工程质量不只看它答得像不像人，还要看它是否能在有限预算内完成工作、如实报告失败，并把危险动作留在可控边界内。

下一篇我们把镜头从“运行时循环”移到“可复用流程”：Skill 如何把团队的做事方式交给 Agent，而不只是塞给它一段更长的 Prompt？