服了，怎么 AI 圈每过一段时间就造几个新词出来？本来我以为自己已经搞懂了 Agent Loop 和 Harness 是怎么回事了，结果最近在折腾时，又冒出来一个 Loop Engineering，真的把我给整不会了。

坦白讲，刚开始写 Demo 时，我真觉得这三者就是同一个概念的三个马甲。毕竟在不到一百行的 Python 脚本里，你用 while True 包裹一个大模型 API，模型吐出工具调用，你用 Python 执行一下再塞回上下文，这不就搞定了？但当想把 Agent 搬进更复杂一点的环境，去处理复杂的 Bug 修复或日常运维时，原先的小作坊瞬间就塌了。这时候发现，还是需要把它们剥离开来。

最近我自己动手设计并开发了两个相关的开源项目：一个是面向代码仓库的轻量本地 AI 助手 CodeRover，另一个是为多智能体协作设计的本地任务队列底座 tq。在亲自踩坑和架构重构的真实过程中，我对这三者的边界和工程演进有了全新的分析和切身认知。

第一部分，Agent Loop：那个不停运转的 CPU 执行周期

简单来说，Agent Loop 就是循环本身。如果把 Agent 比作一台虚拟计算机，那么 Agent Loop 就是它的 CPU 执行周期，也就是获取、解码、执行。它只关心一个核心逻辑：观察状态，决策行动，执行工具，接收反馈，再次观察。

这是一个不断往复的呼吸过程。模型在每一轮的循环中其实并不知道它的终极目标还有多远，它只是根据当前塞入提示词的上下文，决定下一步是要读取文件、运行测试，还是宣布任务完成。

比如在开发 CodeRover 的时候，我的目标是让它直接跑在终端里。当你在命令行让它排查测试失败并提出修复方案时，它底层的 Loop 轨迹往往是这样推进的：先读报错日志，接着搜相关文件，然后修改代码，再去跑 npm run test 测试命令。如果发现测试没过，它会继续看新的报错，重新修代码。

只要模型没有输出结束的信号，或者没达到硬性轮数上限，这个 Loop 就会一直转下去。它是 Agent 最底层、最基本的行动机制。

第二部分，Harness：干脏活累活的操作系统与沙箱

如果 Agent Loop 是心跳，那 Harness 就是承载心跳的整个肉体。它不负责思考，但负责让思考能够安全、稳定地落地。

写 Demo 时，Harness 可能只是一个简单的 while 循环加上进程调用。但在生产环境里，Harness 成了最重、最杂的工程壁垒。它是 Agent 的运行环境、安全边界和外部感官。

在做 tq 这个任务队列引擎时，我发现这部分工作量极大。一个成熟的 Harness，需要打理无数琐碎又致命的细节：

比如沙箱隔离，怎么保证模型不会在一时糊涂时删库跑路？你必须用容器或虚拟机把它的执行环境隔离起来。
比如工具与协议对接，模型想调用外部服务谁来翻译？
比如安全与权限控制，遇到敏感操作，Harness 必须拦截并弹出人工审批。
还有资源与预算兜底，限制 Token 消耗、设置单次任务的时间上限、捕获 API 超时，防止 Agent 陷入死循环把信用卡刷爆。
最后是观测性，你需要记录每一步的执行轨迹，把提示词、工具输入输出、模型耗时统统存进日志，方便复盘。所以在 CodeRover 里，我会把每次运行的会话和工件都妥善保存在本地目录中。

简而言之，Harness 提供了 Agent 行动的边界与底线。Agent Loop 甚至不需要知道 Harness 的存在，它只需要在温室里做决定就行。tq 项目本身就是一个典型的 Harness 底座，它提供了基于 SQLite 的任务队列、状态流转、多种模型执行器，甚至还有终端实时面板。做完 tq 我才彻底明白，Harness 就是把乱七八糟的运行细节都封装好的大后勤。

第三部分，Loop Engineering：从调教提示词转向设计反馈控制系统

明白前两点后，我才真正意识到了第三个概念的份量。Loop Engineering，也就是循环工程，它不是某段代码，而是一套方法论。它关心的是如何设计、调优这个闭环，让它能真正解决问题，而不是陷入死循环或无功而返。

以前我们折腾大模型，重点都在提示词工程，挖空心思去写“你是一个资深的程序员，请一步步思考”。但单次提示词就像扔飞镖，准不准全看运气。

Loop Engineering 则是把 Agent 当成一个反馈控制系统来设计。它要回答的是这些纯正的工程问题：

控制流怎么设计？在让模型直接改代码前，要不要强迫它在第一轮必须写出设计文档？
信息过滤机制怎么做？当编译报错时，我们是把上千行的堆栈信息全部塞给模型导致上下文爆炸，还是写个脚本过滤出最核心的几行报错？
是否需要构建创造者加审查者的模式？这是我在 tq 项目里构建 Apage 引擎时用到的核心策略。Apage 的目标是让模型生成不需要人工微调的网页。为了做到这点，不仅要有模型去生成 HTML 作为创造者，还要有专门的传感器流水线去跑无头浏览器、做辅助功能测试和灯塔跑分，用这些前沿传感器作为审查者去做后置的校验和结构化反馈，然后再把错误扔回给下一次迭代。
退出策略与回滚机制在哪？如果模型连续三次尝试修复同一个 Bug 都失败了，它是该继续死磕，还是主动回滚提交并宣布失败？
状态如何压缩？当 Loop 跑了二三十轮、上下文已经逼近极限时，怎么对之前的历史进行摘要压缩，避免模型注意力涣散？

Loop Engineering 让我们不再迷信大模型会自己搞定一切，而是像传统的软件架构师一样，去设计一套可以自我纠错、自我演进的闭环系统。

最后做个总结，看看这三位一体的 Agent 架构：

Agent Loop 就像 CPU 运行循环，核心关注点是动作决策和上下文追加，解决的是智能体如何持续行动的问题。
Harness 就像操作系统与沙箱，核心关注点是安全边界、接口对接和日志，解决的是智能体在什么系统里行动的问题。
Loop Engineering 就像系统架构设计，核心关注点是反馈设计、纠错机制和多智能体协同，解决的是怎样设计行动闭环才更有效的问题。

决定一个 Agent 系统在生产环境中好不好用的，往往不是大模型单次推理的智商，而是这个循环的反馈机制设计得是否巧妙，Harness 提供的沙箱和工具链是否足够稳固，以及 Loop Engineering 所做出的那些工程权衡是否切中要害。