Agent Loop 入门：AI Agent 如何从“会回答”变成“会做事”

目录

• 一、为什么我们需要 Agent Loop？
• 二、Agent Loop 的最小结构
• 三、Goal：目标
• 四、Plan：计划
• 五、Act：行动
• 六、Observe：观察
• 七、Update：更新上下文
• 八、Stop：停止条件
• 九、一个复杂例子：Agent 自动修复代码 Bug
• 十、一个更简单的例子：改错别字
• 十一、再举一个生活例子：点外卖
• 十二、Agent Loop 和自动化脚本有什么区别？
• 十三、Agent Loop 的核心组件
• 十四、Agent Loop 和 Agent Improvement Loop 的区别
• 十五、AGENTS.md：给 Agent 看的项目说明书
• 十六、Agent Loop 容易失败的地方
• 十七、什么是 Loop Engineer？
• 十八、一个好的 Agent Loop 应该长什么样？
• 十九、给初学者的最小实践
• 二十、最简单的类比
• 二十一、总结
• 参考资料

---

最近看 AI Agent、Codex、Claude Code、自动写代码、自动修 Bug、自动操作浏览器这些方向时，经常会遇到一个词：Agent Loop。

它听起来很工程化，但本质并不复杂。

一句话解释：

Agent Loop，就是让 AI 在“理解目标、制定计划、调用工具、观察结果、修正动作、验证结果”之间不断循环，直到任务完成、失败，或者需要人类介入。

普通聊天机器人更像是：

用户提问 -> 模型回答

而 Agent 更像是：

用户给目标
-> AI 理解任务
-> 制定下一步
-> 调用工具
-> 观察工具结果
-> 更新判断
-> 再调用工具
-> 验证结果
-> 完成任务或请求帮助

这就是 Agent Loop 的基本形状。

OpenAI 在《Unrolling the Codex agent loop》中讲过，Codex 的核心并不只是一个模型，而是一个协调“用户、模型、工具、上下文”的循环系统。Anthropic 的 Claude Code Agent SDK 文档里，也把 agent loop、工具调用和上下文管理视为构建代码 Agent 的基础能力。

所以，Agent Loop 不是某个单独产品的名字，而是一类 AI Agent 系统的核心运行方式。

如果说大语言模型是“大脑”，那么 Agent Loop 就是让这个大脑持续做事的工作节奏。

---

一、为什么我们需要 Agent Loop？

先看一个很普通的问题。

你对 AI 说：

帮我检查这个项目有没有 Bug。

如果是普通聊天模型，它可能会回答：

你可以运行测试、检查日志、阅读关键模块，并重点关注异常处理。

这个回答没错，但它只是建议。

真正的 Agent 会更进一步：

1. 读取项目结构
2. 找到测试命令
3. 运行测试
4. 看到失败日志
5. 打开相关文件
6. 推断错误原因
7. 修改代码
8. 再运行测试
9. 如果测试仍然失败，继续分析
10. 如果测试通过，汇报修改内容

这就是“回答问题”和“完成任务”的区别。

AI Agent 的关键变化，不是它会说“我可以帮你”，而是它真的能在一个环境里采取行动。

比如：

读文件
写文件
运行命令
搜索网页
调用 API
操作浏览器
查询数据库
生成报告
运行测试
根据失败结果继续修正

这些动作不可能靠一次性回答完成。它们需要一个循环来组织。

这就是 Agent Loop 的意义。

---

二、Agent Loop 的最小结构

一个最小的 Agent Loop，可以拆成六个步骤：

Goal -> Plan -> Act -> Observe -> Update -> Stop / Continue

也就是：

目标 -> 计划 -> 行动 -> 观察 -> 更新 -> 停止或继续

如果写成伪代码，大概是这样：

context = [user_goal]

while not done:
    next_action = model.decide(context)
    result = execute(next_action)
    context.append(result)
    done = check_if_finished(context)

再通俗一点：

先想一下要做什么
然后做一步
看看结果怎么样
根据结果再想下一步
重复这个过程
直到完成

这就是 Agent Loop 的核心。

下面我们逐个拆开。

---

三、Goal：目标

Agent Loop 的第一步是目标。

目标就是用户真正想完成的事情。

例如：

帮我修复登录页面在 Safari 浏览器里点击提交没有反应的问题。

这个目标比下面这种说法清楚得多：

帮我看看登录页面。

一个好的目标，最好包含四类信息：

1. 要解决什么问题
2. 问题出现在哪里
3. 希望怎么验证
4. 最后需要什么交付

例如：

帮我修复登录页面在 Safari 上点击提交没有反应的问题。
修完后请运行前端测试，并说明你改了哪些文件。

这个目标就比较清楚：

问题范围：登录页面
触发条件：Safari 点击提交
验证方式：运行前端测试
交付要求：说明修改文件

目标越清楚，Agent Loop 越稳定。

目标越模糊，Agent 就越容易乱跑。

比如：

帮我优化一下这个项目。

这个目标就太宽了。优化什么？性能？代码结构？UI？构建速度？测试覆盖率？

更好的写法是：

帮我优化首页首屏加载速度，重点检查不必要的图片和 JS 加载。
完成后请运行构建，并说明主要改动。

这会让 Agent 更容易进入有效循环。

---

四、Plan：计划

有了目标之后，Agent 通常需要制定计划。

计划不是为了看起来聪明，而是为了避免盲目行动。

一个好的计划会回答三个问题：

我要先看什么？
我要改哪里？
我要怎么验证？

比如你让 Agent 修复登录 Bug，它可能会先计划：

1. 先复现登录失败问题
2. 检查表单提交事件
3. 检查 Safari 兼容性相关代码
4. 修改最小范围
5. 运行测试和手动验证

这很像一个工程师排查问题时的思路。

没有计划的 Agent，容易变成：

看到一个文件就改一个文件
看到一个报错就猜一个原因
测试没过就继续乱改

有计划的 Agent，则会更像：

先确认问题
再定位原因
再做小范围修改
最后验证结果

计划的作用，不是把所有未来步骤都写死，而是给 Agent 一个方向感。

---

五、Act：行动

行动，就是 Agent 调用工具。

普通聊天模型只能生成文字。
Agent 不一样，它可以借助工具接触外部世界。

常见工具包括：

文件读取工具
文件写入工具
命令行工具
浏览器工具
搜索工具
数据库工具
API 工具
测试工具
截图工具
代码编辑工具

比如，Agent 可以执行：

npm test

然后看到测试结果。

也可以执行：

rg "login" src/

搜索项目里的登录相关代码。

还可以打开浏览器，访问本地页面，点击按钮，观察页面是否正常。

这一步非常关键。

因为模型本身不知道真实项目现在是什么状态。
它必须通过工具去看、去试、去验证。

这也是 Agent 和普通聊天模型最大的区别之一：

普通模型：根据已有知识回答
Agent：进入环境，调用工具，基于真实反馈行动

---

六、Observe：观察

行动之后，必须观察结果。

这是 Agent Loop 里最重要、也最容易被低估的一步。

比如 Agent 运行测试后，看到：

TypeError: Cannot read property 'token' of undefined
at src/auth/session.ts:42

这就是观察结果。

又比如，Agent 点击网页按钮后发现：

点击提交按钮后没有发送任何网络请求。

这也是观察结果。

观察的意义在于：它会改变 Agent 的下一步。

没有观察，Agent 就只能凭空猜。
有观察，Agent 才能修正方向。

Agent Loop 不是：

想 -> 做 -> 结束

而是：

想 -> 做 -> 看结果 -> 再想 -> 再做

这才是闭环。

---

七、Update：更新上下文

观察到结果后，Agent 要更新自己的上下文。

上下文可以理解成 Agent 当前知道的一切。

包括：

用户的原始需求
系统规则
项目说明
已经读过的文件
工具返回结果
测试日志
之前尝试过的方法
哪些方法失败了
当前任务是否接近完成

上下文管理非常重要。

如果上下文太少，Agent 会“失忆”。
如果上下文太多，Agent 会被噪音淹没。

比如测试日志可能有几千行，但真正重要的只有：

错误文件：src/auth/session.ts
错误行号：42
错误原因：token 为 undefined

一个好的 Agent 不应该把所有日志都机械塞进下一轮，而应该提炼关键事实。

这也是为什么真实的 Agent 系统经常需要：

摘要
记忆
历史压缩
错误归因
关键信息筛选

上下文不是越多越好，而是越相关越好。

---

八、Stop：停止条件

Agent Loop 不能无限循环。

一个成熟的 Agent 必须知道什么时候停。

常见停止条件有四种：

1. 任务完成
2. 验证通过
3. 需要用户确认
4. 连续失败，继续尝试没有新信息

例如，修代码时：

测试通过
构建通过
用户要求的功能完成

这时 Agent 可以停止，并汇报结果。

但如果遇到这种情况：

连续两次测试都失败
失败原因都指向缺少数据库连接配置
Agent 无法自己补齐这个配置

那它就不应该继续乱试，而应该停下来说明：

我尝试了两种修复方式，但都被同一个问题阻塞：缺少测试数据库配置。
下一步需要你提供数据库连接，或者允许我改成 mock 测试。

这也是一个好 Agent 和一个危险 Agent 的区别。

好 Agent 不只是会继续行动，也知道什么时候该停。

---

九、一个复杂例子：Agent 自动修复代码 Bug

现在看一个完整一点的例子。

假设你有一个前端项目，用户反馈：

登录页面在 Safari 浏览器中点击提交按钮没有反应。

你让 Agent 处理：

请帮我修复登录页面在 Safari 上点击提交没有反应的问题。
修完后运行测试，并说明改动内容。

Agent Loop 可能会这样运行。

第 1 轮：理解目标

Agent 先理解任务：

目标：修复 Safari 登录提交问题
范围：登录页面
验证：运行测试，必要时浏览器验证
输出：说明修改文件和原因

然后制定计划：

1. 找到登录页面代码
2. 找到表单提交逻辑
3. 检查 Safari 兼容性问题
4. 运行相关测试
5. 修改最小范围
6. 再次验证

第 2 轮：读取项目

Agent 调用工具：

rg "login" src/

观察结果：

src/pages/Login.tsx
src/components/LoginForm.tsx
src/api/auth.ts

然后读取 LoginForm.tsx，发现：

<button onClick={handleSubmit}>
  登录
</button>

继续查看 handleSubmit：

const handleSubmit = async () => {
  const formData = new FormData(event.target)
  await login(formData)
}

这里出现一个问题：event 没有从函数参数传入，而是依赖全局 event。

某些浏览器可能还能工作，但 Safari 下可能不稳定。

第 3 轮：推断原因

Agent 根据观察结果判断：

问题可能是 handleSubmit 没有显式接收事件对象。
Safari 中 window.event 不可靠，因此点击后提交逻辑失败。

于是准备修改。

第 4 轮：执行修改

Agent 把代码从：

const handleSubmit = async () => {
  const formData = new FormData(event.target)
  await login(formData)
}

<button onClick={handleSubmit}>
  登录
</button>

改成：

const handleSubmit = async (event: React.FormEvent<HTMLFormElement>) => {
  event.preventDefault()

  const formData = new FormData(event.currentTarget)
  await login(formData)
}

<form onSubmit={handleSubmit}>
  <button type="submit">
    登录
  </button>
</form>

这个修改有几个好处：

1. 不依赖全局 event
2. 使用 form 的 onSubmit，更符合表单语义
3. 显式 preventDefault，避免页面刷新
4. button 使用 type="submit"

第 5 轮：运行验证

Agent 运行：

npm test

观察结果：

测试失败：LoginForm.test.tsx 中仍然使用 fireEvent.click(button)

这说明业务代码可能已经修了，但测试还在使用旧交互方式。

第 6 轮：修复测试

Agent 打开测试文件，看到：

fireEvent.click(screen.getByText("登录"))

它改成更接近真实用户行为的方式：

fireEvent.click(screen.getByRole("button", { name: "登录" }))

并确保断言仍然有效。

第 7 轮：再次验证

Agent 再次运行：

npm test

观察结果：

所有测试通过。

如果项目有浏览器验证，Agent 还可以启动本地服务，用浏览器打开页面，模拟点击登录按钮。

第 8 轮：停止并汇报

Agent 最后汇报：

已修复 Safari 登录按钮无响应问题。
主要原因是原逻辑依赖全局 event，在 Safari 中不稳定。

修改内容：
1. LoginForm.tsx：改为 form onSubmit，并显式接收事件对象
2. LoginForm.test.tsx：更新测试交互方式

验证：
npm test 已通过

这就是一个完整的 Agent Loop。

它不是一次性生成答案，而是经历了：

理解目标
-> 搜索代码
-> 阅读文件
-> 推断原因
-> 修改代码
-> 运行测试
-> 观察失败
-> 修改测试
-> 再验证
-> 完成汇报

这就是 AI Agent 真正“会做事”的原因。

---

十、一个更简单的例子：改错别字

复杂例子看完，我们换一个非常简单的。

你有一句话：

我今天学习了 agnet loop 的基本概念。

目标是改错别字。

普通模型可能直接回答：

agnet 应该改成 agent。

如果用 Agent Loop 来理解，它其实也可以拆成：

Goal：修正文案
Plan：检查拼写错误
Act：读取文本
Observe：发现 agnet 拼错
Update：准备替换
Act：把 agnet 改成 agent
Stop：没有其他错误，完成

最后结果：

我今天学习了 agent loop 的基本概念。

这个例子很小，但它说明了一件事：

Agent Loop 不一定很复杂。只要 AI 在“行动之后观察结果，再决定下一步”，它就在运行某种形式的 Loop。

小任务可能一轮就结束。
大任务可能需要几十轮。

区别只是循环长度不同。

---

十一、再举一个生活例子：点外卖

假设你让 AI 帮你点外卖：

帮我点一份 50 元以内、不辣、30 分钟内能送到的晚餐。

一个普通聊天模型可能说：

你可以考虑点盖饭、馄饨或者轻食。

但 Agent 如果真的要完成任务，需要这样循环：

1. 理解约束：50 元以内、不辣、30 分钟内
2. 打开外卖平台
3. 搜索附近餐厅
4. 查看配送时间
5. 查看价格
6. 排除辣菜
7. 比较评分
8. 选出几个候选项
9. 询问用户确认
10. 用户确认后再下单

这里有一个重要边界：

查询菜单：可以自动做
筛选候选：可以自动做
付款下单：最好需要用户确认

这说明 Agent Loop 不只是技术循环，也涉及权限和风险控制。

越接近真实世界的高风险操作，越需要确认。

比如：

低风险：搜索资料、读取文档、整理摘要
中风险：修改代码、生成文件、发送草稿
高风险：付款、删库、发正式邮件、改生产配置

好的 Agent Loop 应该根据风险设置不同权限。

---

十二、Agent Loop 和自动化脚本有什么区别？

很多人第一次听 Agent Loop，会觉得：

这不就是自动化脚本吗？

它们确实有相似之处，但不完全一样。

传统脚本更适合确定流程：

A -> B -> C -> D

比如：

下载文件
-> 解压文件
-> 转换格式
-> 上传结果

每一步都提前写死。

而 Agent Loop 更适合不确定任务：

A -> 看情况决定 B 或 C
-> 如果失败就尝试 D
-> 如果权限不足就问用户

比如：

修 Bug
迁移代码
分析报错
整理复杂资料
操作陌生网页
研究一个新技术

这些任务很难提前写死所有步骤。

一句话区分：

脚本：提前写好每一步
Agent Loop：边做边判断下一步

脚本适合稳定、重复、规则明确的任务。
Agent Loop 适合目标明确但路径不确定的任务。

---

十三、Agent Loop 的核心组件

一个完整的 Agent Loop 系统，通常包含六个核心组件。

1. 模型

模型负责理解、推理、规划和生成下一步动作。

它要回答：

用户真正想要什么？
当前信息够不够？
下一步该调用什么工具？
工具结果说明了什么？
现在是否可以结束？

模型是 Agent 的“大脑”。

但只有大脑还不够。

2. 工具

工具让 Agent 能接触外部世界。

常见工具包括：

文件系统
命令行
浏览器
搜索引擎
数据库
API
代码编辑器
测试框架
截图工具

没有工具，模型只能说。
有了工具，模型才能做。

3. 上下文管理

上下文管理决定模型每一轮能看到什么。

它需要处理：

用户目标
系统规则
历史消息
工具结果
关键错误
已完成步骤
失败尝试
项目约束

上下文管理不好，Agent 很容易出现两类问题：

1. 忘记用户要求
2. 被无关信息干扰

所以成熟的 Agent 系统会做摘要、压缩和关键信息提取。

4. 权限系统

权限系统决定 Agent 可以做什么，不能做什么。

比如：

可以读取文件
可以修改测试文件
可以运行本地测试
不能删除数据库
不能自动付款
不能把代码推到生产环境

权限不是麻烦，而是安全边界。

Agent 越强，权限设计越重要。

5. 验证系统

验证系统负责判断 Agent 是否真的完成了任务。

在代码场景里，验证可以是：

单元测试通过
类型检查通过
构建通过
Lint 通过
浏览器截图正常

在文档场景里，验证可以是：

链接有效
示例可运行
格式正确
术语一致

在业务场景里，验证可以是：

金额正确
审批通过
数据完整
权限合规
日志可追溯

没有验证的 Agent Loop，很容易变成：

AI 自信地说完成了，但其实没有完成。

验证是 Agent Loop 里非常关键的一环。

6. 追踪与日志

一个 Agent 做了什么，必须能被记录下来。

这类记录通常叫 trace。

Trace 里可以包含：

用户输入
Agent 的计划
调用了哪些工具
工具返回了什么
哪里失败了
最后如何完成

这些记录有两个作用：

1. 出问题时可以排查
2. 可以用来改进 Agent

OpenAI Cookbook 中提到的 Agent Improvement Loop，就是基于 traces、evals 和反馈来持续改进 Agent。

---

十四、Agent Loop 和 Agent Improvement Loop 的区别

这里有一个容易混淆的点。

Agent Loop 是 Agent 完成一次任务时的循环：

计划 -> 行动 -> 观察 -> 修正 -> 验证 -> 完成

Agent Improvement Loop 是改进 Agent 本身的循环：

收集运行记录
-> 找出失败案例
-> 加入人工反馈或模型反馈
-> 生成评测
-> 修改提示词、工具或流程
-> 再测试

前者是在做任务。
后者是在改进做任务的系统。

举个例子：

Agent Loop：
帮我修复一个登录 Bug。

Agent Improvement Loop：
发现 Agent 经常修登录 Bug 时忘记跑 Safari 测试，于是给它增加一条规则和一个评测用例。

这两个 Loop 经常一起出现。

成熟的 Agent 系统，不仅要能完成任务，还要能从失败中变得更可靠。

---

十五、AGENTS.md：给 Agent 看的项目说明书

在 Codex 这类代码 Agent 中，经常会用到 AGENTS.md。

你可以把它理解成：

给 AI Agent 看的 README

普通 README 通常是给人看的。
AGENTS.md 则是专门告诉 Agent：

这个项目怎么运行？
应该遵守什么规则？
哪些文件不能动？
修改后怎么验证？
失败时怎么处理？

例如：

# AGENTS.md

## 项目规则

- 使用 pnpm，不要使用 npm
- 修改代码后运行 pnpm test
- 不要改动 generated/ 目录
- UI 组件遵循 src/components/ui 的已有风格

## 验证方式

- 前端测试：pnpm test
- 类型检查：pnpm typecheck
- 构建：pnpm build

## 工作要求

- 每次修改后说明改动文件
- 如果测试没有运行成功，必须说明原因
- 不要做与任务无关的大规模重构

这类文件会让 Agent Loop 稳定很多。

因为 Agent 不用每次都重新猜项目规则。

---

十六、Agent Loop 容易失败的地方

Agent Loop 很强，但也有很多容易失败的地方。

1. 目标太模糊

比如：

帮我优化一下。

这个目标太宽。

Agent 不知道优化什么，也不知道做到什么程度算完成。

更好的方式是：

帮我优化首页首屏加载速度，目标是减少不必要的图片加载。
完成后请运行构建，并说明主要改动。

2. 工具太多

工具越多，Agent 的选择空间越大。

如果没有边界，Agent 可能会浪费很多轮在无关探索上。

好的工具设计应该是：

工具够用
权限明确
结果清晰
失败可解释

不是工具越多越好。

3. 观察结果太乱

如果一个命令返回几千行日志，Agent 可能抓不住重点。

更好的工具返回应该更结构化：

{
  "status": "failed",
  "file": "src/auth/session.ts",
  "line": 42,
  "message": "Cannot read property 'token' of undefined"
}

结构化结果更容易让 Agent 判断下一步。

4. 没有验证

Agent 改完代码后直接说完成，但没有测试。
这很危险。

好的 Agent 应该明确说明：

我运行了哪些验证
验证是否通过
如果没有验证，原因是什么

5. 无限重试

如果同一个问题失败两次，而且没有新信息，Agent 不应该继续盲目尝试。

更好的行为是：

我尝试了 A 和 B，都失败了。
共同阻塞点是缺少数据库配置。
下一步最好提供测试数据库，或允许我使用 mock。

这比继续乱改更可靠。

---

十七、什么是 Loop Engineer？

前面讲的是 Agent Loop。那是不是应该说 Loop Engineer 呢？

我认为要分清楚两个层级。

Agent Loop：技术机制 / 系统结构
Loop Engineer：设计这些循环的人，或者一种能力角色

现在行业里更常见的岗位说法可能是：

AI Agent Engineer
Agent Engineer
AI Engineer
Agentic Workflow Engineer
AI Automation Engineer
Eval Engineer

“Loop Engineer”还不是一个非常标准的岗位名称。

但它可以作为一个很有意思的概念。

过去大家常说 Prompt Engineer，重点是：

怎么把问题问好
怎么写提示词
怎么让模型输出更稳定

但到了 Agent 时代，只会写 Prompt 可能不够了。

更重要的是设计整个循环：

目标怎么定义
工具怎么选择
上下文怎么管理
失败怎么处理
权限怎么控制
结果怎么验证
什么时候继续
什么时候停止
什么时候问人

从这个角度看，未来真正重要的能力，可能不是单纯的 Prompt Engineering，而是 Loop Engineering。

也就是：

不只是会和模型对话，而是会设计一个能持续行动、持续观察、持续修正的系统。

这就是我理解的 Loop Engineer。

---

十八、一个好的 Agent Loop 应该长什么样？

我认为，一个好的 Agent Loop 至少要满足六个条件：

1. 目标清楚
2. 每一步可解释
3. 工具调用有边界
4. 观察结果能改变下一步
5. 有明确验证机制
6. 知道什么时候停止

可以把它想象成一个靠谱的工程师：

不会只说“我觉得可以”
会去看代码
会跑测试
会读报错
会小心修改
会验证结果
遇到权限问题会问你
不会在没有把握时继续乱改

Agent Loop 的目标不是让 AI 看起来像魔法。

它真正的价值是让 AI 的工作过程变得：

可检查
可纠正
可追踪
可验证
可交付

---

十九、给初学者的最小实践

如果你想自己设计一个简单 Agent Loop，可以从这个版本开始。

输入：用户目标
工具：搜索、读文件、写文件、运行测试
循环：
1. 让模型决定下一步
2. 如果需要工具，就调用工具
3. 把工具结果加入上下文
4. 判断是否完成
5. 最多循环 N 次
输出：结果 + 验证情况

伪代码如下：

context = [user_goal]

for step in range(max_steps):
    action = model.decide_next_action(context)

    if action.type == "final_answer":
        return action.message

    if action.type == "tool_call":
        result = run_tool(action.tool_name, action.arguments)
        context.append({
            "action": action,
            "result": result
        })

    if task_is_verified(context):
        return summarize_success(context)

return summarize_incomplete(context)

这里有两个细节很重要。

第一，必须有 max_steps。

因为真实系统不能无限循环。

第二，必须有 task_is_verified。

因为 Agent 不能只靠自己说“完成了”，还要有外部验证。

---

二十、最简单的类比

如果上面的内容太工程化，可以记住这个类比：

普通聊天模型：坐在桌前回答问题的人
Agent Loop：会站起来查资料、翻文件、运行工具、回来汇报的人

再简单一点：

聊天模型：想完就说
Agent Loop：想一下，做一下，看结果，再想一下

这就是核心。

---

二十一、总结

Agent Loop 是 AI Agent 的基本工作机制。

它让 AI 从一次性回答，变成持续推进任务：

理解目标
-> 制定计划
-> 调用工具
-> 观察结果
-> 更新上下文
-> 验证输出
-> 完成或求助

OpenAI Codex、Claude Code 这类工具之所以看起来像“会干活的 AI”，不是因为它们只是换了一个更强的模型，而是因为它们把模型放进了一个能读环境、调工具、看反馈、继续修正的循环系统里。

未来很多软件可能都会从：

人点击按钮

变成：

人设定目标，Agent 执行过程

而 Agent Loop，就是这个变化背后的基础结构。

真正值得关注的，不是 AI 会不会说“我可以帮你”，而是它能不能：

知道目标
采取行动
看到反馈
承认失败
修正路线
完成验证
在该停的时候停下来

这才是 Agent Loop 最重要的地方。

---

参考资料

• OpenAI：《Unrolling the Codex agent loop》
  https://openai.com/index/unrolling-the-codex-agent-loop/

• OpenAI Cookbook：《Build iterative repair loops with Codex》
  https://developers.openai.com/cookbook/examples/codex/build_iterative_repair_loops_with_codex

• OpenAI Cookbook：《Build an Agent Improvement Loop with Traces, Evals, and Codex》
  https://developers.openai.com/cookbook/examples/agents_sdk/agent_improvement_loop

• OpenAI Developers：《Codex best practices》
  https://developers.openai.com/codex/learn/best-practices

• OpenAI Developers：《Custom instructions with AGENTS.md》
  https://developers.openai.com/codex/guides/agents-md

• Anthropic：《Claude Code Agent SDK》
  https://docs.anthropic.com/en/docs/claude-code/sdk

• Anthropic：《Tool use with Claude》
  https://docs.anthropic.com/en/docs/build-with-claude/tool-use/overview