退出条件优先规则：为什么你的 AI Agent 在首次工具调用前需要一个 Done-State

Source: Dev.to

循环陷阱

如果没有退出条件，会发生以下情况：

• 代理开始任务
• 代理取得进展
• 代理用尽明显的下一步
• 代理循环——不断细化、重新检查、重新执行
• 任务结束的方式：令牌上限到达、超时触发，或有人手动停止

这些都不是完成，而是中断。

被中断的代理不可靠，成本高且不可预测。

先写完成状态

在编写任何工具调用或系统提示之前，先回答三个问题：

1. 成功的样子是什么？
   不能模糊。必须可观察。“文件已写入 output/report.json，状态为：complete”是可观察的。“任务已完成”则不是。

2. 最低可接受的输出是什么？
   这可以防止完美主义循环。代理在达到最低要求时应停止——而不是不断迭代以追求理论上的最大值。

3. 何时应停止并询问，而不是继续？
   歧义加上不可逆性等于必须暂停。如果代理无法确定走哪条路且该操作不可撤销，它应将歧义写入 outbox.json 并停止。

完成状态模式

在你的 current-task.json 中加入以下内容：

{
  "task": "Generate weekly performance report",
  "done_when": "report.json exists and contains status: complete",
  "stop_if": "data source unavailable after 3 retries",
  "minimum_viable_output": "report.json with at least 3 of 5 sections populated",
  "max_iterations": 10
}

代理在每次操作后检查 done_when。如果为真，就停止。若触发 stop_if，则写入 outbox.json 并等待。若在未完成的情况下达到 max_iterations，则记录已完成的内容并干净退出。

为什么这能改变一切

有了明确的完成状态后：

• 成本变得可预测。 循环会终止。你大致知道一个任务需要多少次工具调用。
• 失败变得可见。 如果代理在未达到 done_when 的情况下触发 max_iterations，这就是一个信号——而不是无声的失控。
• 恢复成为可能。 带部分输出的干净退出是可以恢复的。循环中途崩溃则不行。

我合作的一个团队仅通过在任务文件中添加 max_iterations 和 done_when，就将每任务成本降低了 34%。模型相同，工具相同，停止方式更好。

审核问题

对于你现在运行的每个代理，问自己：“如果我让它运行 6 小时，它会自行停止吗？”

如果答案是否定的——或者你不确定——说明没有退出条件。那只是一种期待。

在优化其他任何东西之前先解决这个问题。

The Library at has real current-task.json templates with done‑states built in — for cron agents, multi‑agent teams, and single‑task automations. Updated from production configs, not theory.