AI Agent 执行循环怎么运行？Plan、Task、Subagent 与动态工作图
AI Agent 执行循环如何跨越多轮任务？本文拆解 Plan、Task、Subagent、Attempt、Submission 与 Goal continuation 的协作方式。
本文内容
图 1：执行循环把模型的局部行动、宿主的状态检查和 Goal 的跨轮续跑接在一起。图中为机制示意。
AI Agent Loop 通常被描述成“思考、行动、观察、再思考”。这个说法适合解释模型在一轮里怎样使用工具，但不足以说明一个长任务怎样跨越多轮、多个 Agent 和多次返工。
Nexus 的执行循环有三层：模型循环负责当前行动，工作循环负责提交与返工，Goal continuation 负责跨轮继续或停下。 动态工作图把三层循环连接到同一组持久状态。
这不是把模型放进一个没有边界的 while 循环。每一层循环都有不同的结束条件：当前行动可以因为工具完成而结束，工作循环要等提交被处理，Goal continuation 则要判断目标是否已经完成、是否缺少输入，或者是否到了必须停下的边界。把这三件事混成一个“继续执行”按钮，系统就无法解释为什么还要跑、为什么应该等待。
第一层：一轮内部的模型循环
在一次 Agent round 里，模型可能会：
- 读取当前 Goal、Execution 和 Work Item 状态；
- 判断本轮应该调查、实现、验证还是提交；
- 调用文件、浏览器、代码或其他工具；
- 根据返回结果调整局部步骤；
- 必要时启动受管的 Subagent；
- 形成结果并决定是否提交。
这一层允许模型灵活地安排步骤。比如实现导出接口时，它可以先阅读现有 API，再修改代码，运行测试，最后整理交付说明。
但模型循环本身不是业务状态机。工具返回成功，不等于 Work Item 已经完成；Agent 回复“完成”，也不等于 Submission 已经被接受。
第二层：工作循环
工作循环把一次行动变成可追踪的交付：
读取当前责任
↓
执行 Attempt
↓
提交 Submission
↓
Review / Acceptance
├── accepted → 解锁下游
├── changes_requested → 新 Attempt 返工
└── blocked → 等待输入或外部条件
以生产级 CSV 导出为例，服务端 Agent 可能已经完成接口，但兼容性 Agent 发现 UTF-8 文件在目标软件中乱码。此时系统不会把旧结果覆盖掉，而是保留原 Submission、评审意见和对应 Attempt，再让负责人开始新的 Attempt。
这样，每次返工都可以回答具体问题：哪份提交被退回，退回原因是什么，新结果是否已经通过，哪些下游仍然被锁住。
第三层：Goal continuation
如果一轮结束时 Goal 尚未完成，宿主会检查：
- 当前目标版本是否仍然有效；
- 是否还有未完成的 Work Item；
- 是否存在已验收、可以解锁的新交付；
- 是否正在等待用户、Reviewer 或外部系统；
- 是否达到预算、期限、租约或无进展边界。
满足继续条件时，Nexus 先保存下一轮的安排，再启动新的 Agent round。新一轮不会只依赖上一轮的聊天，而是重新读取当前的 Goal、计划版本、责任、阻塞和交付事实。
需要用户输入、外部结果或人工确认时，系统应当进入阻塞等待。Block/Resume 是等待，不是失败重试。 只有在结果被判断为需要重新执行时，才创建新的 Attempt。
一次长任务会怎样走过三层循环？
仍然用 CSV 导出来观察会更清楚。下面只保留会改变任务状态的几个检查点，省略其余工具调用。
| 阶段 | 模型循环做什么 | 工作循环留下什么 | Goal continuation 如何处理 |
|---|---|---|---|
| 首轮实现 | 阅读接口、修改服务端、运行权限测试 | 一个服务端 Submission，等待 Review | 发现客户端和验证仍未解锁，安排后续工作 |
| 首轮验证 | 检查中文、规模和取消行为 | 记录乱码反馈，原 Submission 进入 changes requested | 创建新的 Attempt，沿原责任返工 |
| 信息不足 | 发现没有目标软件版本，停止猜测 | 保存 blocker 和所需输入 | 暂停续跑，等待用户补充 |
| 最终收口 | 对照当前 Goal 检查所有条件 | 形成 Acceptance 和最终审计依据 | 满足停止条件后结束 Goal |
这张表说明了三层循环的分工。模型循环处理当前一轮的判断，工作循环把判断转成责任和交付事实，Goal continuation 决定这些事实是否足以支持下一轮。任何一层缺失，长任务都会退化成“模型不断回复，用户自己记进度”。
续跑时为什么不能只把上一轮摘要塞回来？
摘要适合帮助模型快速进入上下文，却不能替代状态真相。摘要可能遗漏一份被退回的 Submission，也可能把“请求已发出”写成“外部系统已成功”。更不能让旧轮次的描述覆盖用户后来修改过的目标版本。
Nexus 的做法是先由宿主读取当前的 Goal、计划版本、责任、阻塞和交付事实，再把与本轮有关的上下文投影给模型。摘要可以解释背景，结构化状态负责决定能不能操作。这个顺序让“模型知道什么”和“系统允许什么”保持区分。
Plan、Task、Work Item 和 Subagent 怎么协作？
| 对象 | 在循环中的位置 | 例子 |
|---|---|---|
| Plan | 组织责任和依赖 | 服务端与客户端可以并行，集成验收等待两者 |
| Work Item | 持久化交付责任 | “提供带权限校验的导出接口” |
| Task | 当前 Agent 的局部步骤 | 阅读路由、修改 handler、运行接口测试 |
| Subagent | 受管的子执行 | 独立检查大数据量性能 |
| Attempt | 一次真实执行 | 第一次性能测试超时，第二次调整后重跑 |
| Submission | 可检查的交付候选 | 测试结果、代码变更和验证说明 |
Subagent 可以返回调查结果或局部产出，但它不会自动取得父 Work Item 的完成资格。负责人仍然需要判断结果是否满足责任，宿主则检查它是否属于正确的父执行和权限范围。
模型决定什么，宿主决定什么？
Agent 适合判断代码怎么改、哪种方案更合理，也适合分析反馈说明了什么、是否需要补充验证。
宿主负责检查：这次操作属于哪个 Goal 和 Execution，当前 Agent 是否有权处理这项责任，计划和目标版本是否仍然有效，状态变化是否允许写入，提交是否对应正确的 Attempt。
在 Nexus 内部，Goal、Execution、Plan、Assignment 和 Submission 的控制变化通过本轮绑定的结构化 nexus.command 进入宿主。身份、执行范围和关键引用由运行上下文提供，不能靠普通聊天文本自行声明。
这条边界保留了 Agent 的判断空间，也避免模型通过一句“我负责这项任务”改变系统事实。
什么时候需要重新规划？
执行循环中的返工和计划变化需要分开：
- 同一责任、同一依赖：保留工作图结构，创建新的 Attempt；
- 新增独立责任：创建新的 Plan revision；
- 当前信息不足：阻塞等待，而不是反复猜测；
- 外部副作用未知：先对账，不能直接重放；
- 目标本身变化：推进 Goal 版本，重新检查旧交付是否仍然适用。
这让动态工作图不会因为每个失败都重画，也不会因为每个新需求都悄悄改写旧历史。
继续阅读AI Agent 如何判断任务完成：提交、验收与失败恢复。
本文描述 Nexus 的执行循环设计。循环示例使用产品交付场景和示例数据，不代表某次真实运行记录。