!封面
Harness Engineering 是2026年AI圈冒出来的一个新词。它回答了一个我们每天都在撞上的问题：怎么让AI稳定地干活，而不是偶尔惊喜、偶尔惊吓。
一、从两个"前任"说起
你第一次用AI写法律文书时，大概率经历过这种事：让它检索一条法条，它信誓旦旦地给出了条文编号和内容。你拿去一查，根本不存在。
不是模型"笨"。是你没给它装缰绳。
在讲缰绳之前，先看AI圈已经走完的两步路。
第一步：Prompt Engineering，把话说清楚。
Prompt 就是你发给大模型的那句话。Prompt Engineering 研究怎么把这句话说得更准。你问"帮我写一份合同"，AI给你一份不知所云的东西。你换成"帮我起草一份商铺租赁合同，出租方为个人、承租方为餐饮企业，租期5年，需包含营业额提成租金条款"，结果就靠谱了。
说白了就是学会给AI下指令。跟你带实习律师一样：指令模糊，他只能猜。指令清晰，他才干得明白。
现在很少有人单独提 Prompt Engineering 了。门槛太低，模型本身也变强了，很多时候不用精心调 prompt 也能拿到不错的回答。
第二步：Context Engineering，把材料给到位。
你跟AI聊了好几轮，从合同条款聊到违约责任，从违约责任聊到诉讼策略。当你问"这个案子胜诉概率多大"时，AI需要知道"这个案子"指什么。你不能只发这一句话，得把前面的对话历史一起发过去。
发给AI的所有信息——你的指令、对话历史、可用工具列表、系统规则，统称为 Context（上下文）。Context 有容量上限，不能无止境地往里塞。Context Engineering 研究的就是：在有限空间里，放什么、不放什么、什么时候放、以什么形式放。
举个例子：你跟AI聊了50轮合同谈判，对话历史已经很长了。Context Engineering 的处理方式是，在接近上限时自动把前40轮压缩成一段摘要，腾出空间给最新最关键的信息。这跟律师写代理词一样，你不能把整个案卷塞进去，你得挑选、浓缩、组织。
到这里，Prompt Engineering 解决了"怎么问"，Context Engineering 解决了"怎么给信息"。按说该够了吧？
不够。Prompt 给对了，Context 给够了，AI还是可能在关键时刻跑偏。
因为AI像一个极度聪明但没有任何纪律的助手。你给了清晰的指令和充足的材料，它却可能在执行中注意力漂移、偷工减料、编造事实。你需要的不只是"说清楚"和"给到位"。你需要一整套控制系统。
这套系统，叫 Harness。
二、马具的隐喻
Harness 这个词，本意是马具。缰绳、头套、鞍具的总称。
一匹马非常强壮。没有马具，你骑不上去，更控制不了方向。马具的作用就一个：让马的强大力量，稳定地、持续地为人所用。
平移到大模型：
- 马 = 大模型（GPT、Claude Opus，能力极强，但天然发散、会产生幻觉）
- 马具 = Harness（围绕模型搭建的整个控制系统：规则、工具、流程、权限、质量检查）
脱了马具的马，就是没有任何约束的大模型。它会像脱缰的野马一样发散，产生严重幻觉，最终根本没法稳定交付结果。
AI圈最近形成了一个基本共识，用公式表达：
Harness = Agent - Model
一个完整的 AI Agent（能自主完成任务的AI系统），减去里面的大模型，剩下的全是 Harness。
举个你每天都在用的例子：Claude Code。Claude 模型本身只是其中一个组件。除此之外的所有东西——CLAUDE.md 里写的规则、可以调用的 MCP 工具、文件读写权限、定时调度机制、Skill 系统——统统属于 Harness。
┌─────────────────────────────────────────┐
│ Agent (AI 智能体) │
│ ┌─────────────────────────────────────┐│
│ │ Harness（马具层） ││
│ │ ┌──────┐ ┌──────┐ ┌────────────┐ ││
│ │ │ 规则 │ │ 工具 │ │ 质量检查 │ ││
│ │ └──────┘ └──────┘ └────────────┘ ││
│ │ ┌──────┐ ┌──────┐ ┌────────────┐ ││
│ │ │ 权限 │ │ 流程 │ │ 记忆系统 │ ││
│ │ └──────┘ └──────┘ └────────────┘ ││
│ │ ┌───────────┐ ││
│ │ │ 大模型(马) │ ││
│ │ └───────────┘ ││
│ └─────────────────────────────────────┘│
└─────────────────────────────────────────┘法律人对这个逻辑天然理解。法律是社会行为的 Harness，再强大的商业力量，没有规则约束就会走向无序。诉讼程序是纠纷解决的 Harness，再激烈的对抗，没有程序规则就变成丛林法则。
你不需要成为程序员才能理解这件事。你只需要理解一句话：让一个强大的东西稳定输出，关键不在它本身有多强，而在你给它套上了什么样的缰绳。
三、三个同心圆：从问问题到搭系统
把这三个概念放在一起，关系就清楚了：
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 380">
<defs>
<marker id="arrow" markerWidth="8" markerHeight="6" refX="8" refY="3" orient="auto">
<path d="M0,0 L8,3 L0,6 Z" fill="#555"/>
</marker>
</defs>
<rect width="600" height="380" fill="#fff" rx="6"/>
<circle cx="300" cy="190" r="160" fill="#f0f4ff" stroke="#3b6cb4" stroke-width="2"/>
<circle cx="300" cy="190" r="105" fill="#e8f0fe" stroke="#5b8fd4" stroke-width="1.5"/>
<circle cx="300" cy="190" r="55" fill="#dce8fa" stroke="#7aa8e0" stroke-width="1.5"/>
<text x="300" y="70" text-anchor="middle" font-size="14" font-weight="700" fill="#3b6cb4">Harness Engineering</text>
<text x="300" y="88" text-anchor="middle" font-size="11" fill="#556">研究怎么搭建系统</text>
<text x="300" y="140" text-anchor="middle" font-size="13" font-weight="700" fill="#5b8fd4">Context Engineering</text>
<text x="300" y="157" text-anchor="middle" font-size="10.5" fill="#667">研究怎么给信息</text>
<text x="300" y="182" text-anchor="middle" font-size="12" font-weight="700" fill="#7aa8e0">Prompt</text>
<text x="300" y="197" text-anchor="middle" font-size="12" font-weight="700" fill="#7aa8e0">Engineering</text>
<text x="300" y="212" text-anchor="middle" font-size="10" fill="#778">研究怎么问问题</text>
<text x="470" y="250" font-size="10" fill="#999">研究范围</text>
<line x1="470" y1="255" x2="470" y2="310" stroke="#999" stroke-width="1" marker-end="url(#arrow)"/>
<text x="470" y="325" font-size="10" fill="#999">不断扩大</text>
</svg>- Prompt Engineering 研究"怎么把问题说清楚"。最内圈，对象是你发出去的那段话。
- Context Engineering 研究"怎么把信息组织好"。中圈，对象包括对话历史、工具列表、系统指令等所有发给模型的信息。
- Harness Engineering 研究"怎么把系统搭稳"。最外圈，覆盖除模型本身之外的一切：规则体系、工具链、质量检查、权限管控、流程编排。
这是一个研究范围不断向外扩展的过程。一开始大家盯着几句提示词调来调去。后来发现光调提示词不够，得管理整个上下文。再后来发现光管理上下文也不够，得从头设计一套让AI稳定运行的完整系统。
Harness Engineering 不是又一个 buzzword。它是这个演进逻辑走到今天的必然产物。
四、大厂是怎么做的
Harness Engineering 太新了，业界还没有公认的体系。不如直接看两个顶级AI公司实际做了什么。
4.1 OpenAI：给 AI 搭一个靠谱的工地
2025年8月，OpenAI 启动了一个实验：用 AI 从零开始写一个真实的、有用户在生产环境中使用的软件产品。所有组成部分——业务逻辑、测试、CI配置、文档、内部工具——全部由 AI 生成。
结果：5个月，近100万行代码，团队从3人扩到7人。 开发效率大约是纯人工的10倍。
开头并不顺利。Agent 经常走错方向，甚至重复犯同一个错误。OpenAI 发现问题不在模型不够聪明，而在 Harness 没搭好。
他们把优化归为三类。
第一类：信息充足，别让AI"不知道"。
最初 OpenAI 把所有项目规范塞进一个超大文件，随用户问题一起发给模型。结果适得其反。信息太多，模型反而抓不住重点，就像第一天入职的实习生被砸了一本500页员工手册，完全不知道从哪看起。而且文件没人维护，时间一长成了过时信息的垃圾堆。
后来他们改了：把核心指引压缩到100行左右，只做目录。具体文档按模块分开放，用到哪块再加载哪块。跟律所的知识管理一个道理，你不会把全部案卷材料扔给一个新人，你会按专题、按项目、按阶段分门别类整理好，需要什么取什么。
他们还强制要求：所有重要决策和约定必须搬进代码仓库，让仓库成为唯一的事实来源。散落在微信聊天记录里、飞书文档里的信息，对 AI 来说等于不存在。这个教训法律人应该特别有共鸣。
第二类：验证反馈，让AI能"自己检查"。
AI 写完了代码，怎么验证对不对？OpenAI 给 AI 配上了足够完善的工具：接入 Chrome DevTools，AI 可以自己截图、查看页面结构、模拟用户操作，验证 UI 是否符合要求；接入日志和指标系统，AI 可以自己读日志、排查问题、做性能调优。
他们还用 Linter（代码规范检查工具）建立了自动闭环：AI 生成代码 → Linter 检测是否合规 → 不合规则报错 → 报错信息发回 AI → AI 修改 → 再检测 → 循环直到通过。
这个流程的精妙之处：完全不需要人插手。 人只定规则，AI 在规则约束下自己跑、自己查、自己改。
第三类：技术债清理，不让垃圾积累。
大规模生成代码，必然引入重复代码、偏离规范的写法、不一致的命名。就像律所里，每个律师都按自己习惯起草文件，时间长了文档库一定一团乱。
OpenAI 设置后台 AI 任务，定期扫描整个代码库，自动找出偏离规范的地方并修复。文档也做同样的事，定期扫描，发现过时文档自动更新。
OpenAI 干的事情，本质上不是写代码，而是给 AI 构建一个能稳定干活的环境。他们自己总结了一句话，我认为是整篇文章的灵魂：
Humans steer. Agents execute.
人掌舵，AI 干活。
4.2 Anthropic：用三个 AI 互相监督
Anthropic（Claude 的创造者）的核心思路比 OpenAI 更进一步：不让一个 AI 包揽所有事情，把不同角色拆给不同的 AI，让它们互相监督。
他们发现，只靠一个 Agent 独立完成所有工作（Solo 方案），效果很差。AI 急于求成，做到一半上下文满了就抛下烂摊子，下一个接手的 AI 完全不知道前面发生了什么，只能靠猜。
于是他们搞了一个三 Agent 架构（Full Harness 方案）：
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 600 400">
<defs>
<marker id="arrow" markerWidth="8" markerHeight="6" refX="8" refY="3" orient="auto">
<path d="M0,0 L8,3 L0,6 Z" fill="#555"/>
</marker>
</defs>
<rect width="600" height="400" fill="#fff" rx="6"/>
<text x="300" y="30" text-anchor="middle" font-size="16" font-weight="700" fill="#333">Anthropic Full Harness 三 Agent 架构</text>
<rect x="60" y="65" width="130" height="55" rx="6" fill="#e8f0fe" stroke="#3b6cb4" stroke-width="1.5"/>
<text x="125" y="87" text-anchor="middle" font-size="13" font-weight="700" fill="#3b6cb4">📋 Planner</text>
<text x="125" y="106" text-anchor="middle" font-size="10" fill="#556">拆解需求→功能清单</text>
<rect x="235" y="65" width="130" height="55" rx="6" fill="#fef3e2" stroke="#e8962e" stroke-width="1.5"/>
<text x="300" y="87" text-anchor="middle" font-size="13" font-weight="700" fill="#c77d1a">⚙️ Generator</text>
<text x="300" y="106" text-anchor="middle" font-size="10" fill="#556">逐项实现功能</text>
<rect x="410" y="65" width="130" height="55" rx="6" fill="#e6f5ee" stroke="#2e8b57" stroke-width="1.5"/>
<text x="475" y="87" text-anchor="middle" font-size="13" font-weight="700" fill="#2e8b57">✅ Evaluator</text>
<text x="475" y="106" text-anchor="middle" font-size="10" fill="#556">独立质量评估</text>
<line x1="190" y1="92" x2="233" y2="92" stroke="#555" stroke-width="1.2" marker-end="url(#arrow)"/>
<text x="211" y="84" text-anchor="middle" font-size="9" fill="#777">功能清单</text>
<line x1="365" y1="80" x2="408" y2="80" stroke="#555" stroke-width="1.2" marker-end="url(#arrow)"/>
<text x="387" y="72" text-anchor="middle" font-size="9" fill="#777">交付标准协商</text>
<line x1="408" y1="105" x2="365" y2="105" stroke="#555" stroke-width="1.2" marker-end="url(#arrow)"/>
<text x="387" y="118" text-anchor="middle" font-size="9" fill="#777">评估反馈/修改</text>
<line x1="30" y1="150" x2="570" y2="150" stroke="#ddd" stroke-width="1"/>
<text x="300" y="180" text-anchor="middle" font-size="13" font-weight="700" fill="#555">—— 法律人看一眼就懂 ——</text>
<rect x="40" y="200" width="155" height="140" rx="4" fill="#fafafa" stroke="#ddd" stroke-width="1"/>
<text x="117" y="222" text-anchor="middle" font-size="12" font-weight="700" fill="#3b6cb4">Planner = 主办律师</text>
<text x="117" y="245" text-anchor="middle" font-size="10" fill="#666">接到客户需求后</text>
<text x="117" y="262" text-anchor="middle" font-size="10" fill="#666">拆解为具体任务清单：</text>
<text x="117" y="282" text-anchor="middle" font-size="10" fill="#666">① 检索类案</text>
<text x="117" y="299" text-anchor="middle" font-size="10" fill="#666">② 梳理证据</text>
<text x="117" y="316" text-anchor="middle" font-size="10" fill="#666">③ 起草诉状</text>
<rect x="220" y="200" width="155" height="140" rx="4" fill="#fafafa" stroke="#ddd" stroke-width="1"/>
<text x="297" y="222" text-anchor="middle" font-size="12" font-weight="700" fill="#c77d1a">Generator = 承办律师</text>
<text x="297" y="245" text-anchor="middle" font-size="10" fill="#666">拿着任务清单</text>
<text x="297" y="262" text-anchor="middle" font-size="10" fill="#666">逐项推进执行</text>
<text x="297" y="285" text-anchor="middle" font-size="10" fill="#666">做完一项标记一项</text>
<text x="297" y="305" text-anchor="middle" font-size="10" fill="#666">稳扎稳打不跳步</text>
<rect x="400" y="200" width="155" height="140" rx="4" fill="#fafafa" stroke="#ddd" stroke-width="1"/>
<text x="477" y="222" text-anchor="middle" font-size="12" font-weight="700" fill="#2e8b57">Evaluator = 合伙人复核</text>
<text x="477" y="245" text-anchor="middle" font-size="10" fill="#666">独立第三方视角</text>
<text x="477" y="262" text-anchor="middle" font-size="10" fill="#666">不参与具体执行</text>
<text x="477" y="285" text-anchor="middle" font-size="10" fill="#666">只负责挑毛病：</text>
<text x="477" y="305" text-anchor="middle" font-size="10" fill="#666">"这个论证不充分"</text>
<text x="477" y="322" text-anchor="middle" font-size="10" fill="#666">"那条法条引用过时了"</text>
</svg>三个角色：
- Planner（规划者）：拿到模糊需求后拆解为详细功能清单。比如"做一个游戏制作工具"拆成界面布局、素材管理、交互逻辑、导出功能等十几个功能点。
- Generator（生成者）：逐项实现。做完一个标记一个，再拿下一个。稳扎稳打，不跳步。
- Evaluator（评估者）：独立第三方，不参与生成，只负责评估 Generator 的产出。发现问题发回修改，直到通过。
Anthropic 发现了一个关键事实：让 AI 自己评估自己的产出，行不通。 这就是"王婆卖瓜，自卖自夸"。AI 对自己做的东西有天然滤镜，即使有明显 bug 也能视而不见，给自己打个高分就收工了。
这个发现有一个绝佳的法律类比。为什么律师行业要有合伙人复核？为什么法院设二审？为什么重大交易需要独立法律意见？因为自我审查的可靠性有天然上限。 质量保障的核心不是"更认真"，是"换一双眼睛"。
Anthropic 用一个具体任务做了验证：做一个游戏制作工具。Solo 方案做出来的布局混乱、逻辑难懂、bug 到处都是，基本没法用。Full Harness 方案布局合理、逻辑清晰，达到可用水准。
代价呢？Solo：20分钟，9美元。Full Harness：6小时，200美元。精雕细琢有精雕细琢的代价。考60分可能复习3天，考90分得复习一个月。这个道理，法律人也懂。
五、是噱头吗？
Harness Engineering 火起来之后，争议跟着来了。批评者的论点很直接：
"所有技术都是旧的。Linter 早就有，任务拆解早就有，质量评估早就有。新瓶装旧酒，造个概念炒作。"
前半句，说得对。
Harness Engineering 确实没发明任何新技术。OpenAI 的 Linter 自动检查、Anthropic 的 Planner-Generator-Evaluator 拆分，这些技术元素在传统软件工程中早就存在。Anthropic 自己在文章里也承认，模型从 Sonnet 4.5 升级到 Opus 4.6 后，很多原来必须靠 Harness 约束的事情，模型自己就能搞定。
但"新瓶装旧酒"这个批评，值得认真琢磨一下。
法律人应该比任何人都更理解这件事。请求权基础分析方法发明了任何一条新法条吗？没有。它做的就是把分散的法律规范、裁判规则和论证路径，组织成一套可以系统适用、反复操作的分析框架。但正是这套框架，让法律分析从依赖个人经验的手艺活，变成了可以传授、可以检验、可以优化的方法论。
工程领域的真正进步，往往不是发明新技术。是找到一种方式，把零散的能力组织成可以系统设计、持续优化的整体方案。
Harness Engineering 的价值就在这里。在它出现之前，大家也在做规则配置、工具管理、质量检查，但都是零散的、凭经验的、不可复制的。Harness Engineering 提供了一个统一视角：把除模型之外的所有东西，都视为一个需要系统设计的整体。这个视角本身就是进步。
但我也得说：Harness Engineering 大概率不是终局。
模型能力在持续增强。今天这些用来约束模型、纠正模型、给模型兜底的系统设计，很多可能会被模型自身逐步吸收。到那时候，Harness 可能退化成单纯的底层接口，你只需要给它配最基础的工具（读写文件、联网搜索），剩下的99%它自己搞定。
所以更诚实的定位是：Harness Engineering 是一个过渡期的关键技术。不是未来的终极答案，是当下最现实的答案。
今天，模型依然会犯错、依然有幻觉、依然在复杂任务中偏离轨道。谁把 Harness 搭得更稳，谁就能更早把 AI 的能力变成真正的生产力。
六、法律人为什么要关心这件事？
你可能会想：这是软件工程师的事，跟律师有什么关系？
三个理由。
第一，你已经在做这件事了，只是没意识到。
你用 Claude Code 写文章时，CLAUDE.md 里的规则、配置的 MCP 工具、建的 Skill 系统，这些都是 Harness。你决定"合同审核必须走七步流程"、设置"法律研究必须先检索法条再输出结论"，这些决策不是 Prompt Engineering，是 Harness Engineering。你已经在干了，了解这个概念能让你干得更自觉、更系统。
第二，法律AI的核心壁垒不在模型，在 Harness。
大家用的模型是同一批：GPT、Claude、Gemini。模型层面的能力差异会越来越小。但怎么给模型配置规则体系、怎么设计质量检查流程、怎么让多个AI互相监督，这些 Harness 层面的差异会越来越大，而且直接决定输出质量的差距。
用法律行业的话说：同样的法条（模型），不同的程序（Harness），产出完全不同的结果。
第三，法律人对 Harness 有天然的理解优势。
法律人的整个职业生涯都在跟控制系统打交道。法律是社会的 Harness，约束强者、保护弱者、让复杂博弈在可预期框架内进行。诉讼程序是纠纷解决的 Harness，对抗可以激烈，但必须在规则内。合同是交易的 Harness，商业条款再复杂，也要落到权利义务的框架里。
约束强大力量、建立制衡机制、设计可预期流程，这是法律人的看家本领。把这些能力迁移到 AI 系统设计上，法律人有独特的优势。
七、三个行动建议
如果你现在就想开始搭建自己的 Harness，可以从这三件事做起：
1. 把"说清楚"升级为"写下来"。
调 prompt 是一次性的，写规则是可复用的。把你反复用到的指令模板、审查checklist、质量标准，写成结构化的规则文件。一次写完，每次AI干活时自动加载。
2. 建立"双人复核"机制。
不要让一个AI既负责产出又负责评估。关键任务上，用一个AI生成初稿，用另一个独立的AI（同一个模型但独立会话也行）来做质量检查。换一双眼睛，比你想象的重要得多。
3. 定期做"垃圾回收"。
你的AI工具配置、Skill库、规则文件会慢慢腐化。有些规则过时了，有些工具不再需要了，有些配置互相冲突了。定期花半小时扫描和清理，跟维护你的法律知识库一样。
八、结语
用法律人最能理解的方式总结 Harness Engineering：
大模型是一匹千里马。马跑得再快，没有缰绳也到不了目的地。给马配缰绳这件事，本身就是一个专业领域。
这个领域可能不会永远存在。当马足够聪明，自己认得路、懂交通规则、会避险，缰绳自然就松了。但在那之前，区别就在于：有人还在反复调 prompt，有人已经在系统性地搭 Harness。
后者是更早拿到结果的人。
作者简介： 陈石律师，浙江海泰律师事务所副主任、高级合伙人、房地产与建设工程部主任，宁波市律师协会副秘书长、第七届宁波仲裁委员会仲裁员，聚焦建筑房地产、投融资、并购重组及商事争议解决。曾获多家法律媒体与专业机构认可，荣登 LegalOne 2025 中国区建工及房地产实务先锋 45 强、律新社 2025 年度管理合伙人 20 佳（华东），入选《商法》The A-List 法律精英，获评 ALB China 区域市场十五佳长三角地区律师新星，并获律新社 2024 年度并购领域品牌之星。长期为万科、华润置地、信达地产、保利置业、招商蛇口、中海地产等企业提供法律服务，承办"首宗百亿地王""长春第一高楼""台州第一高楼"等代表性项目，累计服务项目投资额超千亿。近年来持续推动 AI 与法律实务融合，强调以结构化方法打通技术逻辑、法律判断与商业场景；著有《赋能法律人：AI 底层思维与应用范式》，并在多地开展相关主题讲座与分享。四明山法师 AI 夜校（legalAGI.cn）发起人。