AI时代变化太快了,还没搞懂什么是 Harness Engineering ,就来了 Loop Engineering 。
到底是新概念,还是老瓶装新酒?只是为了方便传播?
什么是 Loop Engineering?
2026 年 6 月初,Claude Code 的创始人 Boris Cherny 在一次对话里描述了他自己工作方式的演变:最早是直接写代码,后来是用 AI 辅助写,再后来是同时开十几个 Claude 会话、自己给每个会话发指令,而现在,"我不再提示 Claude 了。我有 Loop 在跑,是它们在提示 Claude。我的工作是写 Loop。"
这句话很快被开发者社区引爆。Addy Osmani(Chrome DevTools 的负责人)把这个模式命名为 Loop Engineering,给出了最简洁的定义:你不再是那个给智能体发指令的人,你设计一个系统来替你做这件事。
不是手动发每一条指令,而是你搭了一个小系统, 自己发现工作、分派、检查结果、记录进度、决定下一步。 你设计一次,它就跑起来,直到任务完成。
这个系统大概由五样东西组成:
定时触发器(Automations)让任务自己启动;
工作隔离(Worktrees)让多个任务并行跑、互不干扰;
技能库(Skills)把你验证过的流程固化成可复用的模块;
连接器(Connectors)让智能体接外部系统取数据;
子智能体(Sub-agents)把大任务拆给多个专门的小智能体同时处理,最后汇总。
五样东西不是五个独立功能,是一个系统里的分工。
但这背后有一个真正让人头疼的问题:系统怎么知道什么叫"完成了"?
这就是停止条件(Stop Condition)。 Loop 不能无限跑,它需要一个可验证的完成标准。 不是"审完了",而是"全部 23 个条款都有风险评级,且没有未回答的内嵌引用"。停止条件写得越清楚,Loop 才越值得信任。
和 Prompt Engineering、Harness Engineering 有什么区别?
这几个概念不是替代关系,是层叠关系。
最底层是 Prompt Engineering ,一次对话里你怎么写那条指令。它只管一个回合。
第二层是 Context Engineering ,智能体执行任务时"能看到什么":相关文件有没有传进去、历史对话保留多少、哪些工具定义要放进来。
第三层是 Harness Engineering 。Harness 是围绕单个智能体搭的那套运行环境:工具权限、错误处理、日志记录。Anthropic 工程师 Birgitta Böckeler 的说法很干净:智能体 = 模型 + Harness,Harness 是让智能体从一个会说话的东西变成一个可依赖的系统的那层东西。
Loop Engineering 在最上面,它不关心单个对话怎么写、单个智能体怎么运行,它关心的是整个 Harness 怎么在时间轴上自动运转:什么时候触发、触发谁、结果够不够用来判断下一步、什么时候真的可以停下来。
比如说你告诉助理"审一下这份合同,重点看违约条款",一次发指令,这是 Prompt Engineering。
你给他准备了相关判例、审查模板和之前案子的记录,再说那句话,你在管"他能看到什么",这是 Context Engineering。
你给他搭了完整的工作台:收件箱、审查流程、存档规则,你在管"他怎么运行",这是 Harness Engineering。
最后,你订了一套规程让系统每周一自动扫描新合同、走模板、发报告,整个过程你不出现,你管的是"谁来驱动这一切",这是 Loop Engineering。
四层叠起来,才是一个真正在跑的系统。完美取代你的审合同助理。
Loop Engineering 在法律 AI 插件里长什么样?
理论说完了,来看一个真实的例子。
Anthropic 开源的法律 AI 插件 claude-for-legal 是目前能看到的最系统的法律智能体工程案例。我翻了它的架构设计,Loop Engineering 的五个构建块在里面几乎都有对应。
定时触发这块:插件里有一个叫 renewal-watcher 的 Agent,定时扫描合同库,自动计算到期日、识别续约截止窗口、写入告警日志,时间到了它自己跑。还有 deal-debrief ,每周一自动汇总上周签署的合同、与标准条款比对、标记偏差,然后停下来等你确认。
技能库这块:每类合同(NDA、MSA、劳动合同)都有自己的 Skill,里面是你验证过的审查框架和风险评级逻辑。Loop 调用 Skill,不需要每次重新写指令,这也是为什么"先搭好 Skill 再设计 Loop"是正确的顺序。
子智能体这块, diligence-grid 尽职调查 Agent 最典型。它把审查拆成三层:Reader 只读文件,Analyzer 做规则分析,Writer 写报告,三层并行跑、互相隔离、最后汇总。不是一个智能体串行处理,而是分工并发。
连接器这块, .mcp.json 里接了合同管理系统(Ironclad)、电子签名(DocuSign)、案例数据库(CourtListener)。智能体自己去取数据,不需要你复制粘贴进对话框。
停止条件这块最有意思。 deal-debrief 的工作流里有一个明确的"等待确认"步骤:Agent 做完分析之后,不自动写入结论,先把结果呈现给你,等你补充背景、确认判断,再继续。这不是软件里的"测试通过/失败",而是一个专业判断节点,系统主动留出来的空间。
法律场景里的停止条件不能全靠 AI 自判。 "到了需要专业判断的地方,系统停下来等人",这个设计才是对的。
结语:Loop 是一种思想
Loop Engineering 这个词是 2026 年 6 月才出来的,背后的想法其实很简单:在你让 AI 深度介入一件工作之前,先想清楚"谁来驱动这个循环"。
不是每个任务都值得搭 Loop。 一次性的事情,搭 Loop 的成本远超收益;不确定性太高的事情,自动触发反而会跑偏。
但有一类工作值得用这个框架来想: 结构固定、会反复出现、结果能验证的工作。 法律事务里这类工作不少,合同审查、到期监控、尽职调查,都是候选项。
在把 AI 嵌入这类工作之前,先问几个问题:触发条件是什么?完成的标准是什么?哪个环节必须是我来判断的,哪个可以不是?这几个问题能答清楚,你就已经在做 Loop Engineering 了,不管用什么工具,也不管这个词存不存在。
Addy Osmani 说得直白:Loop Engineering 让你从循环里的人,变成设计循环的人。
法律人的时间太贵,不应该困在循环里。