很多人第一次用 AI Agent，都会把重点放在 prompt 上。

比如：

帮我修这个 bug。
帮我总结这些 issue。
帮我分析这段日志。

Agent 回答之后，你再继续追问。
它出错了，你把错误贴回去。
它修完了，你再让它跑测试。
测试失败了，你再把新的报错发给它。

看起来是 Agent 在工作，其实很多时候，是你一直在旁边当“调度员”。

你决定它什么时候开始。
你告诉它下一步做什么。
你检查它有没有做对。
你发现它跑偏了，再把它拉回来。

所以，Agent 开发里真正关键的问题不是：

怎么写一个更厉害的 prompt？

而是：

能不能设计一个系统，让 Agent 自己持续推进任务？

这就是 Loop Engineering。

---

先用一个餐厅例子讲清楚

可以把 Agent 想象成一家餐厅里的厨师。

最开始，你可能只是对厨师说：

帮我做一道适合今晚聚餐的菜。

这就像普通的 Prompt。

你给一个指令，厨师做一次回应。
如果做得不满意，你再补充要求：

不要太辣。
客人里有人不吃牛肉。
最好 30 分钟内做好。

这就是很多人使用 Agent 的方式：不断补充 prompt，不断纠正，不断追问。

但如果你真的要经营一家餐厅，只靠“临时喊厨师做菜”是不够的。

你还需要三样东西。

---

1. Prompt：你这次想让厨师做什么

Prompt 解决的是“这一轮怎么问”。

比如：

做一道不辣、适合 4 个人吃、30 分钟内能完成的晚餐。

在 Agent 开发里，prompt 就是你给模型的任务说明。

它很重要，但它只解决单次任务。

它不能自动决定什么时候开始。
不能自动检查库存。
不能自动安排下一桌客人。
也不能自动判断这道菜是否该端出去。

所以，只靠 prompt，就像你一直站在厨房门口指挥厨师。

---

2. Harness：厨房里的规则和工具

餐厅不能只靠厨师自由发挥，还要有厨房制度。

比如：

• 哪些食材可以用；

• 哪些设备可以开；

• 生熟菜板要分开；

• 过敏原必须标记；

• 没检查的菜不能端给客人；

• 厨师不能随便改菜单价格；

• 高风险操作要经理确认。

这就是 Harness。

在 Agent 开发里，Harness 可以理解成 Agent 的工具和安全护栏。

它决定 Agent 能做什么、不能做什么。

比如：

Agent 可以：

• 读取文件；

• 修改相关代码；

• 运行测试；

• 查询日志；

• 生成报告。

但不应该随便允许它：

• 删除数据库；

• 修改生产配置；

• 直接合并 main 分支；

• 自动给客户发邮件；

• 执行高风险命令。

Harness 的作用不是限制 Agent，而是让 Agent 在安全范围内行动。

没有 Harness 的 Agent，就像一个没有厨房规则的厨师，能力越强，越可能闯祸。

---

3. Loop：让餐厅自己运转起来

真正的餐厅不是客人来一桌，老板就跑去厨房喊一次：

现在做菜！
现在上菜！
现在检查库存！
现在去收拾桌子！

一家成熟的餐厅应该有自己的运转流程：

客人下单后，系统把订单传到厨房。
厨房根据菜单和库存开始做菜。
做完后有人检查。
检查通过后服务员上菜。
库存不足时自动提醒采购。
客诉出现时记录原因。
每天结束后复盘哪些菜卖得好、哪些菜被退回。

这就是 Loop。

Loop 解决的是：

系统如何自己持续推进任务？

在 Agent 开发里，一个 Loop 通常是这样：

观察当前状态
→ 判断下一步要做什么
→ 调用工具执行
→ 检查结果
→ 记录状态
→ 决定继续、停止，还是找人

比如 CI 失败时：

系统自动读取日志。
Agent 分析失败原因。
Agent 尝试最小修复。
系统运行测试。
测试通过就生成总结。
连续失败几次就停止并交给人。

这就不是“问 AI 一个问题”了。
这是在设计一个能持续工作的系统。

---

Prompt、Harness、Loop 的区别

用餐厅例子总结一下：

Prompt 像你对厨师说的一句话。
它解决“这次做什么”。

Harness 像厨房规则、工具和权限。
它解决“厨师能怎么做、不能怎么做”。

Loop 像餐厅的运营流程。
它解决“餐厅如何持续运转”。

对应到 Agent 开发里：

Prompt 决定这一轮任务怎么描述。
Harness 决定 Agent 可以调用哪些工具、有哪些限制。
Loop 决定 Agent 如何在多轮任务中持续推进。

所以，Agent 工程化的重点，不只是写一个好 prompt，而是把 prompt、harness 和 loop 组合起来。

---

一个好 Loop 需要什么？

不用想得太复杂。
一个实用的 Agent Loop，通常需要六个部分。

---

1. 触发器：什么时候开始？

Loop 需要知道什么时候启动。

比如：

• 每天早上 9 点整理新增 issue；

• CI 失败时自动分析原因；

• 新 PR 创建时检查代码风险；

• 线上报警出现时生成排查报告。

没有触发器，Agent 只能等人叫它。
有了触发器，Agent 才能主动进入工作流。

---

2. 上下文：Agent 需要知道什么？

Agent 不是神。

你不给它足够的信息，它就只能猜。

比如让 Agent 修 bug，最好给它：

• bug 描述；

• 报错日志；

• 相关代码；

• 复现步骤；

• 测试命令；

• 项目规范；

• 之前尝试过的方法。

上下文太少，Agent 容易胡猜。
上下文太多，Agent 容易抓不住重点。

所以，上下文设计的重点是：

让 Agent 看到刚好需要的信息。

---

3. 工具和护栏：Agent 能做什么？

Agent 只有建议能力时，风险不大。
但当它可以修改代码、执行命令、调用接口时，就必须加限制。

比如：

可以允许 Agent：

• 读取文件；

• 修改当前任务相关代码；

• 运行测试；

• 运行 lint；

• 生成报告。

但不应该随便允许它：

• 删除数据；

• 修改生产配置；

• 直接合并 main；

• 自动发客户邮件；

• 执行高风险命令。

工具越强，护栏越重要。

一个好的 Loop 不是让 Agent 想做什么就做什么，而是让它在安全范围内行动。

---

4. 状态：系统怎么记住进度？

Loop 会运行很多轮。

如果没有状态记录，Agent 很容易忘记自己做过什么。

它可能会反复尝试同一个失败方案，也可能忘记上次测试结果。

所以，Loop 需要记录状态。

比如：

目标：修复当前 PR 的 CI 失败问题

当前状态：
- CI 失败
- 失败测试：auth.test.ts

已尝试：
1. 修改 token mock，失败
2. 调整测试 fixture，部分通过

验证结果：
- auth.test.ts 通过
- build 未验证

下一步：
运行完整测试

状态记录不一定复杂。
哪怕只是一个 Markdown 文件，也能让 Agent 的工作变得可追踪。

---

5. 验证器：怎么判断做对了？

不要只让 Agent 自己说“我完成了”。

它可能很自信，但不一定真的对。

在开发场景里，验证方式可以是：

• 单元测试；

• 集成测试；

• lint；

• 类型检查；

• build；

• 另一个 Agent 做 review；

• 人类最终确认。

一个好 Loop 不应该只问：

Agent 说完成了吗？

而应该问：

有什么证据证明它完成了？

---

6. 停止条件：什么时候停下来？

Loop 必须知道什么时候停止。

否则它可能一直重试、一直改代码、一直消耗 token。

常见停止条件有三类。

成功时停止：

• 测试通过；

• CI 变绿；

• 报告生成完成；

• 用户确认通过。

失败时停止：

• 连续失败三次；

• 超过预算；

• 修改范围太大；

• 遇到权限不足；

• Agent 无法解释下一步。

需要人时停止：

• 涉及生产环境；

• 涉及客户承诺；

• 涉及安全风险；

• 需要产品或架构判断。

Loop Engineering 里很重要的一点是：

不只是让 Agent 会做事，还要让它知道什么时候不该继续做。

---

Loop 最大的风险是什么？

Loop 的强大之处在于它会自动运行。
它的危险也在这里。

如果第一轮判断错了，后面几轮可能会沿着错误方向继续跑。

如果没有日志，人可能不知道它到底做了什么。

如果权限太大，它可能把小问题改成大事故。

所以，设计 Loop 时一定要记住三件事：

第一，要能看见过程。
每一轮做了什么，为什么做，都要有记录。

第二，要能验证结果。
不能只听 Agent 自己说完成了，要有测试、检查或人工确认。

第三，要能及时停下。
连续失败、高风险操作、不确定判断，都应该交给人。

结语：未来不是写更长的 Prompt，而是设计更可靠的 Loop

Prompt 当然重要。
但只会写 prompt，还不够。

当 Agent 开始进入真实工作流，真正重要的是：

如何让它在安全、清晰、可验证的循环里持续工作。

Prompt 决定这一轮怎么说。
Harness 决定 Agent 能怎么做。
Loop 决定系统如何持续推进。

Loop Engineering 的核心不是“让 AI 完全自己干”。

而是：

设计一个你敢让 AI 自己运行的系统。

这才是 Agent 从聊天工具走向工程系统的关键一步。