学习何时使用代理循环才是合理的、如何约束其行动，以及如何在 FDE 面试中讨论规划、故障恢复和可观测性。
一旦模型能够使用工具，你就可以把它放进一个循环中：让它围绕一个目标进行推理、调用工具、读取结果、决定下一步，然后重复直到完成。这个循环就是一个 Agent。它是最令人兴奋的构建模块，也是被过度使用最多的。这里的高级技能，既在于知道如何构建，也在于知道何时不该构建。
在亲眼观察一次运行之前，循环是抽象的。下面是一次有约束的运行的样子：一个被要求查明夜间数据同步为何失败的 Agent，预算为五步（示意轨迹）：
goal: find out why last night's data sync failed [illustrative]
step 1 call read_log("sync.log")
obs ERROR: timeout connecting to vendor API
step 2 call check_status("vendor-api")
obs vendor reports healthy — the timeout is on our side
step 3 call read_config("sync/network.yaml") ← replanned from step 2's observation
obs proxy points at gateway host "gw-old"
step 4 call read_config("sync/network.yaml") ← same call, same plan: the confused-loop smell
obs (unchanged)
step 5 call read_config("sync/network.yaml")
obs (unchanged)
step budget (5) reached → stop, return partial result + trace从轨迹中可以读出两种形态。健康的步骤会因上一次观察的内容而改变：第三步放弃供应商假设并转而检查本地配置，正是因为第二步排除了供应商。退化的步骤则在没有新信息、也没有修订计划的情况下重复同一动作。第四步和第五步就是这种失败——一个陷入困惑的 Agent 从外部看起来的样子——而更多的步骤只会带来更多同样的结果。这就是为什么生产环境的答案是“预算加返回轨迹”：运行在已知成本下结束，留下部分发现和可回放的记录，这正是本页其余部分将展开阐述的有界自主姿态。
为什么克制是高级能力的信号
一旦你知道 Agent 的存在，本能反应就是把一切都做成 Agent。请抵制这种冲动。Anthropic 的工程指南很直白：它建议"寻找尽可能简单的方案，只在需要时才增加复杂性"。工作流（由你编排的固定、可预测的序列）适合定义明确的任务，而 Agent 适合真正需要模型驱动灵活性的开放式问题，且代理系统"以延迟和成本换取更好的任务表现"（Anthropic，2024）。当一个两步流水线就够用时，FDE 却选择多 Agent 系统，就是在没有收益的情况下增加了延迟、成本和故障模式。在面试中，提出最简单可行的方案比提出最自主的方案是更强的信号。
在继续阅读之前： 一位客户想要“从上传的 PDF 中提取发票号、日期和总额。”你会构建一个 Agent 吗？在读下一行之前先作答。
不会。这是一个固定的、定义明确的任务：一个带结构化输出的提取步骤，也许再加一个验证步骤。这是一个工作流。在这里使用自主循环只会带来不可预测性和成本，没有任何好处。把 Agent 留给那些你确实无法预先规划步骤的任务。
工作流还是 Agent？——决策
- 使用工作流：当你能写下具体步骤时——路径是可预测的，因此编排一个固定序列（检索 → 生成 → 验证）。它更便宜、更快，也更容易测试和调试。
- 使用 Agent：当步骤取决于过程中发现的内容时——顺着线索展开的研究、形成并验证假设的调试、需要无法预测的可变次数工具调用的任务。在这里，模型的灵活性才配得上它的成本。
- 拿不准时，先从工作流开始，只有当真正的限制迫使你时，才转向 Agent。
如果你确实要构建 Agent，请给它设限
一个可以自主行动的循环，正是 guardrails 页面所讨论的系统。设限不是可选项：
- 步骤预算：对迭代次数设置硬性上限，让困惑的 Agent 停下来并报告，而不是永远循环。
- 对不可逆操作设置检查点：循环在可逆步骤上自由运行，而在任何具有现实世界影响范围的操作之前暂停，等待人工确认。
- 可观测性：记录 Agent 的推理过程和每个操作的 trace，这样当它出错时，你可以精确回放是哪里出了问题。
- 成本和延迟上限：每一步都是一次额外的模型调用，因此 Agent 的账单和耗时都会随循环增长。
多 Agent 系统（多个专门化的 Agent 相互协调）也存在，偶尔某些任务确实需要它们。但它们会把上述每一项成本都成倍放大，因此使用它们的门槛更高。
差 / 良 / 优——“你会在这里使用 Agent 吗？”
差——“是的，我会构建一个自主 Agent 来处理整件事。” 默认追求最大自主性。在可预测的任务上，这只会增加成本、延迟和失败模式；面试官听到的是一个读过 Agent 相关文章、却没有实际运维过 Agent 的人。
良——“这取决于步骤是否可预测；如果不可预测，就用带工具的 Agent。” 提出了正确的问题，这已经成功了大半。差距在于：没有提到给循环设限，也没有明确倾向于更简单的方案。
优——“我会默认选择最简单的方案：如果步骤是可知的，就用固定工作流，它更便宜且可测试。只有当任务真正需要我无法用脚本写死的、由模型驱动的步骤时，我才会使用 Agent——而且我会给它设限：步骤预算、对不可逆操作设置人工检查点、用于调试的 trace，以及成本上限。自主性是一种成本，只有任务需要时我才支付。” 你以克制开场，点明了决策依据，并给循环设了限。面试官听到的是一个把自主性当作需要论证的成本来对待的人——这正是这道题想要寻找的直觉。
面试中要带上的要点
当提示词邀请使用 Agent 时，考验的是判断力。明确说明工作流与 Agent 之间的取舍，默认选择更简单的方案；如果确实采用 Agent 方式，就要把循环的边界说清楚：步骤、检查点、追踪、成本。选择能解决问题的最简单架构，并对你授予的自主性加以限制，这正是 Anthropic 官方指南所指向的原则。
下一篇： 模型上下文协议（MCP） —— 这是将所有这些工具和数据源连接到模型的标准，无需每次都做定制集成。