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 让你从循环里的人，变成设计循环的人。
法律人的时间太贵，不应该困在循环里。