最小 Agent 闭环：思考、行动、观察、修正

今天先记住

Agent 不是一次性“想出答案”，而是在目标没有完成前反复走一个小闭环：判断下一步、执行动作、读取结果、修正计划。没有观察和修正，所谓 Agent 很容易只是把自动脚本外面包了一层模型。

它在大地图里的位置

先把大图再压成一条线：

txt

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

今天讲的是中间最核心的一圈：规划、工具、观察、修正。它决定 Agent 是“说完就结束”，还是能把任务一步步推进到可验证状态。

它到底是什么

最小 Agent loop 可以写成四个词：

txt

Think -> Act -> Observe -> Revise
思考 -> 行动 -> 观察 -> 修正

“思考”不是神秘推理，而是选择下一步：该查文件、调用接口、问用户，还是直接输出。

“行动”是对外部世界产生影响：读文件、写文档、跑构建、发请求、调用工具。

“观察”是拿到动作结果：命令是否成功、文件是否存在、接口返回了什么、权限是否被拒绝。

“修正”是根据观察结果改变下一步：构建失败就读错误并改文件；资料查不到就换来源；动作风险太高就停下来请求确认。

为什么 Agent 里会用到它

Agent 系统面对的常常不是“生成一段文本”，而是“把一个目标推进到完成”。目标推进最怕的不是模型不会说，而是它不知道刚才做的事有没有真的成功。

比如文档发布任务里，模型写出 Markdown 只是第一步。真正的系统还要确认文件路径正确、构建通过、Git 提交只包含相关文件、push 成功。每一个结果都会影响下一步。

所以 Agent loop 的价值不该说成“提升效率”，而应该说清楚：它把不可见的中间过程变成可观察的状态转移，让系统能在失败点停住、重试或换路。

怎么判断它有没有用

如果任务只有一次输入和一次文本输出，loop 可能是多余的。

如果任务需要外部工具，而且工具结果会改变下一步，就应该显式设计 loop。

如果失败不是罕见异常，而是常态，比如网络失败、构建失败、权限不足、数据缺失，就必须让系统能观察失败原因，而不是只给用户一句“处理失败”。

如果一个动作会产生真实后果，比如提交代码、发消息、改配置，修正步骤里还要包含权限判断：能不能自动继续，还是必须让人确认。

一个小例子

txt

Input:
生成并发布今天的 AI Agent Daily lesson。

Process:
1. Think: 读取已有课程，判断今天该讲“最小 Agent 闭环”。
2. Act: 写入 docs/ai-agent/2026-07-13.md。
3. Observe: 运行 npm run docs:build，读取是否构建通过。
4. Revise: 如果构建失败，根据报错修 Markdown 或配置；如果通过，再提交并 push。

Output:
状态从“今天没有课程”变成“课程文件存在、构建通过、Git 已推送、URL 可访问”。

这个例子里，最关键的不是模型会写文章，而是每一步都有状态证据。你可以用文件、构建结果和 Git 提交去验证它，而不是只能相信一句“我已经完成了”。

常见误区

以为 loop 越长越像 Agent。循环次数不是重点，能否根据观察改变下一步才是重点。
以为 Think 必须暴露完整推理。工程里更需要的是可执行计划、工具选择和状态记录。
以为工具调用成功就等于任务成功。工具成功只说明一个动作完成，不代表用户目标完成。
以为失败后自动重试就够了。没有区分失败原因的重试，可能只是更快地重复同一个错误。

今天自测

一个 Agent loop 里，为什么 Observe 比 Act 更容易被低估？
如果构建失败，Agent 应该记录哪些信息才能进入 Revise？
对“自动发微信消息”这种动作，修正步骤里应该加入什么权限判断？

最小 Agent 闭环：思考、行动、观察、修正 ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​