← [ BACK_TO_NOTES ]

Agent 执行闭环

把 planning loop、tool use、runtime、ground truth feedback、stopping conditions 和 approval checkpoints 放在一条执行链里理解。

#ai #synthesis #growing

[!info] related notes

所属 MOC: Agent MOC, Coding Agent MOC

相关概念: Agent, Agent 中的 Planning Loop, Agent 中的 Tool Use, Agent Runtime, Agent 中的 Ground Truth Feedback, Agent 中的 Stopping Conditions, Agent 中的 Approval Checkpoints

易混淆概念: Agent Loop, Prompt Chaining, Orchestration

相关资源: claude-code, opencode, openai-codex

Agent 执行闭环

范围

这篇关系笔记不单独解释某一个组件，而是把 agent 真正在运行时怎么形成闭环放到一张图里理解。

为什么要放在一起理解

很多人会分别讨论 planning、tools、runtime、feedback，但真正的系统稳定性来自它们被串起来之后的行为：

只会规划，不会可靠执行，任务推进不下去
只会调工具，不会读反馈，系统会盲走
只会循环，不设停止条件，系统会失控
只会自动执行，不设审批点，系统会在高风险动作上越界

所以 agent 不是若干能力的清单，而是一条受控制的执行闭环。

依赖路径 / 调用链 / 演进链

可以把一个典型 agent loop 粗略理解成：

接收目标
进入 planning loop
在 loop 中选择并执行 tool use
这些动作由 runtime 负责真正运行和回填结果
通过 ground truth feedback 判断是否继续、修正或切换路径
遇到高风险动作时进入 approval checkpoints
命中成功条件、失败条件或 stopping conditions 后退出

从工程视角看，planning -> action -> observation -> control 才是 agent 的最小执行骨架。

对比与易混淆点

Agent Loop 是 runtime 内部“模型调用 → tool call → tool result → 下一轮”的原子循环；本文是 synthesis，解释 planning、runtime、feedback、approval 与 stopping condition 如何共同构成受控执行闭环。
Orchestration 更偏系统层“怎么组织流程和角色”；这篇更偏单个 agent 在执行中的闭环。
Prompt Chaining 可以有多步，但通常路径预定义；agent execution loop 更强调反馈驱动和动态重规划。
不是所有 agent 都需要很长的 loop，但只要它能根据环境反馈决定下一步，它就已经进入了 execution loop 的范畴。

学习检查

不看正文回答：

Agent 执行闭环与一次普通 LLM Call 的根本差异是什么？
Planning、Tool Use、Observation / Ground Truth Feedback 分别在闭环里承担什么职责？
Runtime 为什么必须保存状态，而不能只靠模型聊天历史？
Stopping Condition 为什么是 Agent 正确性的一部分？
Approval Checkpoint 应放在什么类型的动作边界前？
Tool 执行失败后，系统需要哪些信息才能决定 retry、repair、fallback 或停止？
画出一个 coding agent 从“理解任务”到“测试通过并停止”的最小闭环。