01 任务与运行·第 4/25 课·20 min 阅读·最后更新 2026-09-11

Agent 为什么能连续做十几步？

Agent Loop 是一条重复运行的工作链：模型判断下一步，工具执行动作，结果回到上下文，系统再决定继续、等待用户还是结束。

任务是：登录超时测试偶发失败，请找到原因、修复代码，并运行相关测试证明修好了。用户只说了一句话，Agent 却会读取项目、搜索代码、比较配置、请求修改、运行测试，再交付 Diff。

这里没有神秘魔法。每一轮只有四步：模型根据当前证据判断下一步；工具进入真实环境行动；结果回到系统成为新证据；系统检查应该继续、等待用户还是结束。这条反复运行的链路就是 Agent Loop。

模型说“修好了”不能让任务结束。系统还要确认文件真的变更、测试真实通过、修改没有越过批准范围。用户看到的状态统一为：运行中、等待确认、完成、受阻或失败、已取消。

一次 Turn 内可以包含多轮模型推理和工具调用。模型请求动作，Harness 校验并执行，结果作为 Observation 回到上下文；结束条件由最终回答、限制策略或人工控制共同决定。

Agent 循环（Agent Loop）状态机

系统为什么继续，又为什么停下？

每一轮只做四件事。真正决定终态的不是模型说“完成”，而是权限、工具结果、完成证据和用户控制。

1
判断下一步
任务目标 + 最新工具结果（Observation）
2
调用工具
先过参数、权限与沙箱检查
3
读取结果
内容、退出码、错误和外部回执
4
继续还是停止？
用完成条件检查当前证据

证据不足或出现可恢复错误，把新事实送回第 1 步。

证据通过已完成（Completed）

改动对比符合预期，18/18 测试通过。

需要人决定等待批准（Awaiting approval）

暂停在动作之前，保留当前状态。

无法继续被阻断或失败（Blocked / Failed）

缺少必要输入时进入“被阻断”；不可恢复错误进入“失败”，并说明已尝试动作。

用户终止已取消（Cancelled）

停止新动作，保存已有证据和副作用。

从第一步走到下一步

第一轮，模型只知道用户描述的现象，于是请求搜索 login、session 和 timeout。搜索工具返回八个候选文件。第二轮，模型根据搜索结果选择最相关的实现和测试继续读取。第三轮，它发现客户端三秒超时早于服务端最长五秒响应，形成一个可以被测试推翻的原因假设。

搜索结果不是旁白，而是下一轮的新输入。没有工具结果回填，模型只能重复猜测；没有状态记录，用户也无法知道它为什么从一个文件跳到另一个文件。

官方事实 · Unrolling the Codex agent loop · 见文末依据

行动之前，先处理权限和失败

本课的教学规则是：读取和搜索在限定目录内自动进行；修改两个文件会产生真实副作用，因此系统先展示文件范围、改动目的和准备运行的测试。用户批准后，循环从暂停处继续，而不是重新猜一遍任务。

如果测试失败，失败结果也会回到下一轮。Agent 可以根据新错误补读文件、缩小修改或撤回假设；如果连续得到同样错误却重复同一动作，系统应停止空转并告诉用户阻塞在哪里。

官方事实 · How Claude Code works · 见文末依据

有外部证据，任务才真正结束

这次任务的完成证据很具体：两个文件产生预期 Diff，18 项相关测试全部通过，公开 API 没有变化。只有这些检查成立，系统才把状态从“正在验证”改成“完成”。

如果只有 17 项通过，状态是“受阻或失败”，但仍要交付已经完成的 Diff 和剩余失败；如果还没获得写入许可，状态是“等待确认”；如果用户取消，则保存已有证据并标记“已取消”。不同结局不能都包装成绿色的“完成”。

固定源码观察 · Hermes Agent tool loop (fixed commit) · 见文末依据

产品经理要设计的不是思维链，而是可检查事件

用户不需要看到模型全部内部推理，但应看到它正在读什么、准备改什么、为什么暂停、测试是否通过、最终影响了哪些文件。每个事件都要能回答：谁做了什么，环境返回了什么，任务状态为什么改变。

这条任务记录把模型判断、系统执行和用户控制分开，便于逐项检查每一方是否尽责。

固定源码观察 · Hermes Agent turn finalizer (fixed commit) · 见文末依据

真实产品里怎么做

一次任务为什么会继续，又为什么会结束

会话循环调度命令、队列和完成事件；Turn 将工具结果重新送回模型，直到满足终止条件或进入受限终态。

产品经理要决定：Agent 的核心不是模型多说几轮，而是 Harness 拥有可观察的状态机、预算、暂停点和完成合同。

查看 Grok Build 官方仓库中的对应实现提交 a5727c596045 · 核验 2026-07-23＋

证据边界：源码能证明循环与终止机制的实现合同；不能仅凭这些文件证明真实任务成功率或用户价值。

实现对照 · DeepSeek Harness

一句需求，怎样成为连续工作的系统？

“正在运行”“被阻断”“被取消”和“发生错误”是不同状态。源码会在轮次结束时记录原因，也支持在停止检查点接住尚未完成的工作。模型输出一段最终回答，不足以证明业务目标已经达到。

产品判断：设计继续和停止的条件，同时设计停止后用户还能拿到什么。

固定源码观察 · 核验 2026-09-11。业务迁移为本站分析。

阅读完整系统研究 →核对官方依据 ↗

本课术语，放回情境理解

Agent Loop: 模型判断、工具行动、环境观察和状态调整反复发生，直到进入明确终态。
状态机: 列出系统允许的状态以及状态之间可发生的转换。
预算: 对时间、费用、Token、工具次数或风险暴露设置的运行上限。
终止候选: 模型建议停止，但仍需 Harness 用完成证据判断是否真的成功。
进展检测: 判断新一轮是否获得了新信息或改变了任务状态，用于阻止无效重复。
降级交付: 无法完成全部目标时，保留已验证产物并明确未完成范围。

正在载入本课完整案例、模板与标准答案…

本课依据与证据边界

正文引用对应下面的具体结论。厂商资料、固定版本实现与本站解释分别标识。

[1]
OpenAI 对 Codex 的公开拆解说明模型会在工具调用和工具结果之间循环，直到产生最终输出或被系统条件打断。
官方事实OPUnrolling the Codex agent loop官方工程文章 · 核验 2026-07-14
[2]
Anthropic 将 Claude Code 的工作描述为收集上下文、采取行动与验证结果，并明确这些阶段会交织发生。
官方事实ANHow Claude Code works官方文档 · 核验 2026-07-14
[3]
Hermes 固定提交源码展示了工具调用校验、修复、去重、执行与结果回填；这些确定性处理都发生在模型之外。
固定源码观察NOHermes Agent tool loop (fixed commit)官方源码 · 核验 2026-07-14
[4]
Hermes 固定提交的 Turn Finalizer 会区分预算、失败与完成，保存轨迹并持久化会话，说明循环结束还需要系统关账。
固定源码观察NOHermes Agent turn finalizer (fixed commit)官方源码 · 核验 2026-07-14
[5]
Anthropic 的可信 Agent 研究强调在现实部署中管理自主性、监控、错误与人类控制。
官方事实ANTrustworthy agents in practice官方研究 · 核验 2026-07-14
[6]
本站四类终态、事件名称和透明模拟器是教学状态机，不代表 Codex 或 Claude Code 的内部枚举。
本站推演OPUnrolling the Codex agent loop官方工程文章 · 核验 2026-07-14

按需查阅的原始材料

Building effective agents ↗Anthropic · 核验 2026-07-23
How Claude Code works ↗Anthropic · 核验 2026-07-23
Unrolling the Codex agent loop ↗OpenAI · 核验 2026-07-23
Grok Build is Now Open Source ↗xAI · 核验 2026-07-16
Grok Build repository map（固定提交） ↗xAI · 核验 2026-07-23
Grok Build session orchestration loop（固定提交） ↗xAI · 核验 2026-07-23
Grok Build tool ports notice（固定提交） ↗xAI · 核验 2026-07-23
Hermes Agent tool-call validation and recovery ↗Nous Research · 核验 2026-07-23
Hermes Agent tool execution and guardrail handoff ↗Nous Research · 核验 2026-07-23
Hermes Agent budget, completion and cleanup finalization ↗Nous Research · 核验 2026-07-23
Hermes Agent durable session finalization ↗Nous Research · 核验 2026-07-23

接下来

理解了循环，再判断什么时候需要一份计划，以及新证据如何改变计划。

用面试题验收

本课对应面试题

01 任务与运行·第 4/25 课·20 min 阅读·最后更新 2026-09-11

Agent 为什么能连续做十几步？

Agent Loop 是一条重复运行的工作链：模型判断下一步，工具执行动作，结果回到上下文，系统再决定继续、等待用户还是结束。

Agent 循环（Agent Loop）状态机

系统为什么继续，又为什么停下？

每一轮只做四件事。真正决定终态的不是模型说“完成”，而是权限、工具结果、完成证据和用户控制。

1
判断下一步
任务目标 + 最新工具结果（Observation）
2
调用工具
先过参数、权限与沙箱检查
3
读取结果
内容、退出码、错误和外部回执
4
继续还是停止？
用完成条件检查当前证据

证据不足或出现可恢复错误，把新事实送回第 1 步。

证据通过已完成（Completed）

改动对比符合预期，18/18 测试通过。

需要人决定等待批准（Awaiting approval）

暂停在动作之前，保留当前状态。

无法继续被阻断或失败（Blocked / Failed）

缺少必要输入时进入“被阻断”；不可恢复错误进入“失败”，并说明已尝试动作。

用户终止已取消（Cancelled）

停止新动作，保存已有证据和副作用。

从第一步走到下一步

官方事实 · Unrolling the Codex agent loop · 见文末依据

行动之前，先处理权限和失败

官方事实 · How Claude Code works · 见文末依据

有外部证据，任务才真正结束

固定源码观察 · Hermes Agent tool loop (fixed commit) · 见文末依据

产品经理要设计的不是思维链，而是可检查事件

这条任务记录把模型判断、系统执行和用户控制分开，便于逐项检查每一方是否尽责。

固定源码观察 · Hermes Agent turn finalizer (fixed commit) · 见文末依据

真实产品里怎么做

一次任务为什么会继续，又为什么会结束

会话循环调度命令、队列和完成事件；Turn 将工具结果重新送回模型，直到满足终止条件或进入受限终态。

产品经理要决定：Agent 的核心不是模型多说几轮，而是 Harness 拥有可观察的状态机、预算、暂停点和完成合同。

查看 Grok Build 官方仓库中的对应实现提交 a5727c596045 · 核验 2026-07-23＋

证据边界：源码能证明循环与终止机制的实现合同；不能仅凭这些文件证明真实任务成功率或用户价值。

实现对照 · DeepSeek Harness

一句需求，怎样成为连续工作的系统？

产品判断：设计继续和停止的条件，同时设计停止后用户还能拿到什么。

固定源码观察 · 核验 2026-09-11。业务迁移为本站分析。

阅读完整系统研究 →核对官方依据 ↗

本课术语，放回情境理解

Agent Loop: 模型判断、工具行动、环境观察和状态调整反复发生，直到进入明确终态。
状态机: 列出系统允许的状态以及状态之间可发生的转换。
预算: 对时间、费用、Token、工具次数或风险暴露设置的运行上限。
终止候选: 模型建议停止，但仍需 Harness 用完成证据判断是否真的成功。
进展检测: 判断新一轮是否获得了新信息或改变了任务状态，用于阻止无效重复。
降级交付: 无法完成全部目标时，保留已验证产物并明确未完成范围。

作品里程碑 · 里程碑 2 · 任务契约与完整 Trace

登录超时修复的完整 Agent Trace

45 分钟

先读给定材料，按模板完成一版，再与下方完整参考案例逐项核对。掌握以后，把这套方法用到自己的业务里。

本课给定案例 · 教学假数据

测试第一次失败后，循环怎样继续

Agent 要修复登录超时问题。它先发现客户端超时早于服务端响应，修改后首次测试仍有一个 Mock 失败；系统应把失败当作新证据继续工作，而不是假完成，也不能无条件重复同一动作。

教学案例：人物、公司、数据与运行结果均为虚构；带官方链接的岗位与产品事实除外。

目标文件为 auth/session.ts 与 auth/session.test.ts；读取和搜索自动允许，修改这两个文件前必须等待一次用户确认。
预算为最多 12 次工具调用和 10 分钟；同一命令连续两次返回相同错误且没有新信息时必须停止空转。
首次修改后测试结果为 17/18，失败项指向旧的三秒 Mock；调整后第二次测试为 18/18。
完成必须满足两个文件的 Diff 符合批准范围、18/18 测试通过且公开 API 未变化；用户可以随时取消。

你要完成的任务

把登录超时修复写成至少十个按序事件的 Agent Trace，并补齐等待确认、测试失败、用户取消、重复检测和可信完成分支。

标准模板

1
至少 10 个按序事件
写出不少于十个事件，每个说明谁做了什么，以及环境返回了什么。
2
每轮新增的证据与状态变化
标出每轮新增证据、剩余工具预算和任务状态为什么改变。
3
等待确认、失败和取消分支
分别写出等待确认、测试失败后恢复、用户取消和无法继续四条分支。
4
停止理由与最终验证证据
定义重复检测、预算终止和完成条件，并列出最终交付给用户的证据。

交付标准

写作时按这四点检查，标准答案会逐项展示依据。

循环清楚
判断、行动、结果回传和完成检查能够逐轮对应
状态一致
明确使用完成、等待确认、受阻或失败、已取消
停止可信
完成绑定目标 Diff 和 18/18 测试，而不是模型自述

完整标准案例与参考答案

标准案例 · 教学假数据

测试第一次失败后，循环怎样继续

至少 10 个按序事件

01 task.created：界面记录登录超时任务；02 context.ready：Harness 装入项目规则、工具和 12 次预算；03 model.requested_search：模型请求搜索 timeout；04 tool.returned_matches：搜索返回两个实现文件和一个测试文件。
05 model.requested_read：模型请求读取 session 实现与测试；06 tool.returned_files：工具返回客户端 3 秒、服务端最长 5 秒及三秒测试 Mock；07 model.proposed_patch：模型提出统一为 5 秒并更新 Mock。
08 permission.requested：系统展示 auth/session.ts、auth/session.test.ts 和测试计划；09 permission.approved：用户仅本次允许；10 tool.applied_patch：编辑工具返回两个文件的 Diff。
11 test.returned：测试返回 17/18，旧 Mock 仍失败；12 model.requested_read：模型读取失败用例；13 tool.returned_file：返回遗漏的三秒断言；14 tool.applied_patch：在已批准文件内修正断言；15 test.returned：18/18 通过；16 completion.checked：Diff、测试和 API 检查通过；17 task.completed：界面交付根因和证据。

每轮新增的证据与状态变化

初始状态为运行中、预算 12；搜索、读取、两次修改、补读失败用例和两次测试共消耗 7 次工具调用，结束时剩余 5 次。
事件 08 后状态是等待确认，用户同意后恢复运行；17/18 不是结束，而是新增“测试 Mock 仍使用三秒”的证据，推动下一轮补读和修改。

等待确认、失败和取消分支

等待确认分支停在事件 08，不执行修改；用户拒绝后交付根因和建议，状态为受阻或失败，不伪装成完成。
测试失败分支把 17/18 写回下一轮，经补读和新修改恢复；用户在任一工具完成后取消，状态为已取消，并保留已读文件、Diff 和最后测试结果。
如果依赖缺失且当前权限无法安装，系统交付错误、已完成检查和所需条件，状态为受阻或失败。

停止理由与最终验证证据

Harness 用 tool_name、规范化参数、文件版本和错误结果形成重复指纹；同一指纹连续两次且没有新证据时停止，并要求换路径或交给用户。
12 次工具预算用尽或 10 分钟超时都进入受阻或失败；只有两个文件的 Diff 在批准范围内、18/18 测试通过且公开 API 未变化时才进入完成。
最终交付包含根因、两个文件的 Diff、首次 17/18 到最终 18/18 的恢复过程、测试退出码和剩余风险；模型的“已完成”不能单独作为证据。

为什么这份答案达标

循环清楚: Trace 中判断、行动、结果回传和完成检查可以逐轮对应，并覆盖等待确认、受阻或失败、已取消。
状态一致: 17/18 测试明确改变下一轮动作，重复检测也要求新条件或新证据，不允许空转。
停止可信: 完成绑定批准范围内的 Diff、18/18 测试与 API 检查，终止由外部证据证明。

离开前再确认一个判断

模型不再请求工具并返回最终回答，是否等于登录超时任务已完成？

参考回答

不等于。系统仍需检查目标文件的 Diff、18/18 测试结果和批准范围；证据不足时只能等待确认、受阻或失败，或由用户取消。

正在载入本课完整案例、模板与标准答案…

本课依据与证据边界

正文引用对应下面的具体结论。厂商资料、固定版本实现与本站解释分别标识。

[1]
OpenAI 对 Codex 的公开拆解说明模型会在工具调用和工具结果之间循环，直到产生最终输出或被系统条件打断。
官方事实OPUnrolling the Codex agent loop官方工程文章 · 核验 2026-07-14
[2]
Anthropic 将 Claude Code 的工作描述为收集上下文、采取行动与验证结果，并明确这些阶段会交织发生。
官方事实ANHow Claude Code works官方文档 · 核验 2026-07-14
[3]
Hermes 固定提交源码展示了工具调用校验、修复、去重、执行与结果回填；这些确定性处理都发生在模型之外。
固定源码观察NOHermes Agent tool loop (fixed commit)官方源码 · 核验 2026-07-14
[4]
Hermes 固定提交的 Turn Finalizer 会区分预算、失败与完成，保存轨迹并持久化会话，说明循环结束还需要系统关账。
固定源码观察NOHermes Agent turn finalizer (fixed commit)官方源码 · 核验 2026-07-14
[5]
Anthropic 的可信 Agent 研究强调在现实部署中管理自主性、监控、错误与人类控制。
官方事实ANTrustworthy agents in practice官方研究 · 核验 2026-07-14
[6]
本站四类终态、事件名称和透明模拟器是教学状态机，不代表 Codex 或 Claude Code 的内部枚举。
本站推演OPUnrolling the Codex agent loop官方工程文章 · 核验 2026-07-14

按需查阅的原始材料

Building effective agents ↗Anthropic · 核验 2026-07-23
How Claude Code works ↗Anthropic · 核验 2026-07-23
Unrolling the Codex agent loop ↗OpenAI · 核验 2026-07-23
Grok Build is Now Open Source ↗xAI · 核验 2026-07-16
Grok Build repository map（固定提交） ↗xAI · 核验 2026-07-23
Grok Build session orchestration loop（固定提交） ↗xAI · 核验 2026-07-23
Grok Build tool ports notice（固定提交） ↗xAI · 核验 2026-07-23
Hermes Agent tool-call validation and recovery ↗Nous Research · 核验 2026-07-23
Hermes Agent tool execution and guardrail handoff ↗Nous Research · 核验 2026-07-23
Hermes Agent budget, completion and cleanup finalization ↗Nous Research · 核验 2026-07-23
Hermes Agent durable session finalization ↗Nous Research · 核验 2026-07-23

接下来

理解了循环，再判断什么时候需要一份计划，以及新证据如何改变计划。

用面试题验收