Boris Cherny——Claude Code 的构建者——说过一句话：“我已经不 prompt Claude 了。我有在跑的 Loop。我的工作是写 Loop。”
这句话不算夸张。构建着这个星球上最受欢迎的 coding agent 之一的人，自己不再手动推它。那他在做什么？
这就是 Loop Engineering 的全部含义。而它比看起来难得多。
先把 Loop 本身说清楚
Agent 不是什么魔法盒子。剥到底，就是一个朴素的循环：
while True:
response = model(context)
if response.has_tool_calls():
results = run_tools(response.tool_calls)
context += results
else:
break模型读了上下文，请求调用工具，你跑工具把结果喂回去，模型再读再请求——重复直到它不再要工具为止。
Model → tools → context → repeat。
让人意外的是：这个循环本身早就被解决了。 所有正经 agent 框架的 while 循环都长这样。没人在这六行代码上较劲。
那大家都在工程化什么？
重心已经从模型身上移开了
AI 的中心不断偏离模型本身。注意力沿着这几个层次往外扩张：
- Prompt Engineering——你发给模型的那段话
- Context Engineering——模型看到的一切，不止是提示词
- Harness Engineering——围绕模型的代码：跑工具、跟踪状态、处理错误
- Loop Engineering——驱动整个系统朝目标前进的自主循环
每一层包裹着前一层。你不是不再关心 Prompt 了，你只是意识到它只是一个大系统里的一小块。
LangChain 把这点说得很清楚：Agent = Model + Harness。 你不是模型，你就是 Harness。
而现在有一个值得重新排优先级的事实：Harness 现在比模型本身更重要。已经有一些团队把模型保持不变，只改了围绕它的代码，就从榜单中段跳进了前五。同一个大脑，不同的循环。
Loop Engineering 的核心命题就是：构建这台大脑运行的整套环境。
下面拆开四个最容易翻车的地方。
难点一：什么时候该停
Agent 不再调用工具的时候，它结束的是自己的回合。这不等于它完成了任务。
想象一个 coding agent：写了点代码，扫了一眼周围，觉得进度不错，宣布完成。测试还是红的。它照样宣告胜利。
把”回合结束”当”任务完成”，是 Loop 翻车最常见的方式。
好的 Loop 会叠好几道刹车：
- 最大迭代次数。 硬上限，让卡住的 agent 不会永远跑下去。
- 预算和时限。 token、钱、时间的上限。
- 无进展检测。 如果上一轮和这一轮做了完全一样的事，那就是在空转。
- 真正的完成检查。 一个自动条件来证明任务做完了。
最后这条承担所有分量。“完成”应当意味着测试通过，不是 agent 对自己的作品感觉良好。
难点二：上下文在腐烂
长 Loop 会从内部烂掉。
Agent 轮次越多，上下文中堆积的垃圾也越多：旧的工具输出、走进的死胡同、过时的推理。随着垃圾堆增大，模型表现下降。这个现象叫上下文腐烂（context rot）。
更糟的是它会形成恶性循环——腐烂的上下文产出更差的决策，更差的决策堆进更多噪音，噪音继续加速腐烂。你感受过这个：agent 跑得越久越傻。
对抗上下文腐烂，得把上下文当成预算来用，而不是当成垃圾桶：
- 压缩。 对话太长时做摘要，拿摘要继续。
- 卸载。 把大输出推到文件里，只保留你需要的那一截。
- 子 Agent。 把脏乱的子任务丢给独立 agent，只让干净的结果回来。
本能是保留一切，以防万一。本事是知道该扔掉什么。
难点三：Agent 真能用的工具
一个 Loop 的上限，是它里面工具的上限。
堆上一百个工具，agent 反而不知道该伸哪只手。Anthropic 有一条很准的经验：如果一个人类工程师不能确定该用哪个工具，agent 更不可能。
有两件事比人们想的更重要：
让写操作可以安全重试。 Loop 会重试。如果重复调用”创建客户”生成了两个客户，等着你的就是重复记录和双重账单。任何改变状态的操作，都要可以安全调用两次。
给 agent 写的错误信息，不是给人看的。 一个好的错误信息，应该告诉 agent 下一步做什么。在工具上线之前，先问一句：一个 LLM 读到这个错误，知道该往哪走吗？
在 Loop 里，错误不是终点，是下一条指令。
难点四：需要一个能说不的东西
自主 Loop 有一个安静的失败模式。没有人看着的 agent，倾向于自我认同。
整个讨论中最尖锐的评论点明了要害：设计 Loop 是一半的活，另一半是在 Loop 里放一个能说不的东西——测试、类型检查、一个真正的错误。
没有批评者的 Loop，只不过是 agent 在对自己画的图点头。
解法是把制作者和检查者分开。一个模型干活，另一个不同的检查——通常是独立的模型或硬测试——来打分。干活的别给自己改作业。
思维转变
现在 Cherny 那句话说得通了。
Prompting 是你一步一步手把手推着 agent 走。Loop Engineering 是你建造那个推着它走的系统，然后退出来。
你的工作从给出指令，变成设计三样东西：
- 目标——写成 agent 自己能检查的成功标准
- 循环——带上合理的刹车，能好好停下来
- 验证器——让”完成”是被证明的，不是被宣布的
Andrej Karpathy 抓到了这套思路的精髓：别告诉模型做什么，给它成功标准然后看它跑。他整夜开着研究 Loop——改脚本、测试、保留有效的、丢弃无效的——自己完全不在 Loop 里。他编排一次，然后点击启动。
这就是整套动作：你不再做那双手，而是变成设计机器的那个脑子。
五步起步
你不需要第一天就搞出一个通宵跑的自主 agent。分步来：
- 从基础循环开始， 立刻加上最大迭代上限、超时和成本上限。
- 把”完成”定义成自动化检查， 在开始之前就写好，不是做完之后凭感觉。
- 保护好上下文。 长跑做压缩，大输出卸载，脏活丢进子 agent。
- 审核你的工具。 少而聚焦，写操作安全可重试，错误信息改到 agent 能行动。
- 把批评者放进循环。 只有当你相信那个说不的东西了，才真正放手。
Loop Engineering 不是一个框架、不是一个能安装的工具。它是一种你把力气往哪里使的转向。
模型正在变成常规品。围绕它的循环，才是现在真正的主战场。
最优秀的构建者不再问”我该怎么告诉 agent 去做什么”。他们在问”什么样的系统不需要我，也能做成这件事”。
把这个问题回答好，你也就不再需要手动 prompt 了。
如果你关注 AI Agent、开发工具和软件工程实践，可以关注 Aide Hub。这里会继续分享能落地的工具教程、技术观察和项目经验。