很多人以为，AI最大的问题是不够聪明。

但现实正好相反——AI 现在最大的问题，是"太能干，但没人管"。

它能写代码、改合同、跑流程，甚至可以连续执行复杂任务。问题不再是"它说得对不对"，而是：它做的事，能不能被控制？

这也是为什么，最近行业内都在讨论一个词：Harness。

2026年2月5日，HashiCorp 联合创始人 Mitchell Hashimoto 首次正式提出了"Harness Engineering"这一概念。六天后，OpenAI 在百万行代码实验报告中正式采用了这一术语。随后 Martin Fowler 撰文深度分析，一个月内，"驾驭工程"成为全球开发者社区的高频词。

Mitchell Hashimoto 的原始定义简洁而精准：

"Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future."

（每当 Agent 犯了一个错误，你就花时间设计一个解决方案，使它永远不再犯同样的错误。）

也就是说：Agent 的每一次失败，都是环境设计不完善的信号。正确的回应不是换一个更强的模型，而是重新设计它运行的环境。

Anthropic 在《Harness design for long-running application development》中进一步阐释：Harness 不是单一算法，而是支撑复杂 AI 智能体运行的外部框架、控制结构与编排系统—— 一整套工程化的"脚手架"。

很多人以为 Harness 是新概念，其实不是。调度系统（Airflow）、工作流引擎（Camunda）、权限与审计系统、沙箱环境——这些能力一直存在。

真正的变化只有一个：

大模型，让“执行主体”发生了改变。

• 过去：系统执行流程，人做判断

• 现在：AI做判断，系统必须“管住AI”

👉 所谓 Harness，本质就是这套“管住AI”的系统。

1. 模型能力跨过了"可用阈值"

从 GPT-4o、Claude 到 Codex，AI 开始具备多步推理、工具调用、长任务执行的能力。AI 从建议者变成了执行者。

问题随之改变：不再是它说得对不对，而是"它做的事能不能被控制"。

2. Agent需要“运行制度”

Agent倾向于在一个会话里把所有功能都做完，写完代码就标记"Done"，却没做完整的测试。单元测试通过了不代表功能真正可用，Agent失败的根本原因，不是AI不够强，而是没有"运行制度"。

于是行业开始反思：

• Prompt 不够 → 加上下文

• 上下文不够 → 加记忆

• 记忆不够 → 加系统

最终走到：必须有一层"统一控制系统"——Harness

3. AI开始"独立产出结果"

OpenAI 用 Codex Agent 几个月生成百万行代码，人类没有参与执行过程。这带来三个治理问题：

• 谁定义目标？

• 谁控制过程？

• 谁承担责任？

而 Harness，正是"AI时代的治理基础设施"。

它是 Prompt Engineering（提示词工程）之上的更高级抽象。

Prompt 决定了单次对话的质量，而 Harness 决定了多轮、多智能体、长时任务的执行流程和可靠性。

Harness 的核心作用是解决 AI 在完成复杂、耗时任务时的“失控”问题，通过外部控制机制弥补模型内在的缺陷（如上下文焦虑、自我美化）。

用更底层的话来说：

Harness 解决的不是"AI怎么用"，而是"AI如何被约束"。

就像马需要缰绳才能拉车，AI 需要 Harness 才能在企业里可靠干活。

我们可以把它拆成三个"控制权问题"：

用法律语言总结就是：权限 + 流程 + 证据链

结合Anthropic和OpenAI的工程实践来看，Agent的常见错误在合同管理场景中同样普遍存在。相应地，Harness 在合同管理中可构建为四层管控结构，层层递进、闭环管控：

第一层：记忆层

问题：LLM 每次对话都是白板一张，记不住制度、偏好、情况等等。

Harness 做法：

• 把《合同管理制度》《各类业务指引》《供应商档案》写成结构化知识库

• 自动加载历史情况，不用重复交代"这是什么业务、关注什么风险"

• 理解不同业务线的风险重点

效果：从每次重建上下文变成"系统自动加载上下文"

第二层：执行层

问题：AI 只会给意见，无法基于完整信息进行判断。

Harness 做法：

• 调用合同库、案例库、业务数据

• 自动比对历史合同

• 结合财务、履约信息判断条款合理性

效果：AI 不只是"给你一段意见"，而是"基于真实数据做判断"

第三层：反馈层（核心）

问题：AI 输出是概率性的，这次对，下次可能错。怎么确定它是对的？

Harness 做法：

找到合同管理中的"编译器"——确定性的验证机制：

• 格式校验：输出必须符合标准合同模板或审查意见模板

• 规则校验：用清单逐项核对，不漏项、不误判

• 冲突检测：本次意见与历史案例、公司制度是否矛盾等

• 人工抽检：高风险合同或异常进入人工复核队列

关键洞察：代码领域 Harness 先行，是因为有编译器（跑不通就报错）。合同管理也要找到自己的编译器——条款库、审批规则、履行监控指标、风险预警阈值。

第四层：编排层（复杂任务拆解）

问题：合同流程涉及多个角色与环节，容易出现信息断层和遗漏。

将任务拆解为多个子模块协同完成，主 Agent负责统筹输出最终意见。

效果：专业化分工，每份合同都经过完整的质检。

很多人还停留在"AI帮我审合同"、"AI帮我改条款"。但真正的变化其实是：合同本身正在"系统化"。

具体体现在三个方面：

1. 从“文本合同” → “可执行规则”

条款不再只是描述，而可以被系统自动识别和执行。

2. 从“审查一次” → “持续控制”

合同从签署扩展到执行、监控与反馈。

3. 从“人承担责任” → “系统参与责任链”

Harness 具备日志、回溯与记录能力，AI行为首次可以被纳入责任分析框架。

这意味着，未来法律人可能需要面对：

• AI决策的合规性问题

• AI执行的责任归属问题

• AI系统的审计标准问题

说到这里，这套管控结构听起来像是工程理想。但实际上，幂律智能正在做的，就是为法律人搭建这套 Harness。它在法律场景中的真正难点，其实并不在于技术组件的堆砌，而在于如何把法律人的规则、经验与风险判断，转化为一套可以被机器执行、并且可持续演进的约束体系。

第一层：把经验变成规则

传统的合同管理高度依赖个体经验，哪类条款需要重点关注、哪些风险可以接受、哪些必须升级审批。这些判断往往存在于资深法务的大脑中，而非系统里。幂律智能所做的，是将这些隐性经验编码为结构化的决策边界，让审查标准具备可复用、可更新、可被系统执行的特性。

第二层：把信息变成上下文能力

过去，合同相关信息是分散的：历史合同躺在档案室、履约情况在ERP里、供应商风险在风控报告中、财务记录又在另一套系统。即便存在，也很难在审查时被实时调用。我们所做的，是把这些离散信息转化为可实时调用的上下文与证据链。当 AI 审查一份采购合同时，它调用的不仅是当前文档，还包括该供应商的历史履约评分、同类合同的实际付款节点分布、以及特定行业的监管红线，让判断从基于当前输入升级为基于组织的完整知识。

第三层：把判断纳入约束与验证体系（Verification Layer）

AI 的本质问题不是能力，而是不确定性。幂律智能的核心设计不是无限增强模型参数，而是在模型之外建立确定性的约束机制：模板与格式校验确保输出符合企业标准；审查清单引擎逐项核对，不漏项、不误判；制度冲突检测识别 AI 建议与既有判例或公司制度的矛盾；风险等级判定与人工复核机制确保高风险事项必须经由人类确认。让 AI 的输出从"概率结果"变成可验证、可解释、可追责的决策过程。

第四层：把流程变成可编排的执行系统（Orchestration Layer）

合同本质上是一个跨角色、多阶段的复杂流程，信息断层和遗漏是常态。我们所做的，是将其转化为可编排的多Agent协同执行体系。每个子模块有明确输入输出、有规则约束、有状态记录，主Agent统筹全局，最终形成一条可回溯、可重放的完整合同执行链路。

如果用一句话概括：幂律智能做的不是"让 AI 更聪明地写合同"，而是构建一套 AI 时代的合同治理与执行系统——让 AI 在法律人的规则之下稳定运行，让每一次 AI 决策都可被审计、被回溯、被归责。我们向企业交付的，不是一个能生成文本的工具，而是一套让 AI 可以被信任、被风控体系接纳、被监管机构认可的基础设施。

技术的发展正在以周为单位迭代。从大模型基础能力到Agent自主决策，再到多Agent协同，法律科技的成熟度曲线正在迅速爬升。

面对"全自动AI智能化管理"这些字眼，很多法律人第一反应不是兴奋，而是下意识的抵触；怕被取代，怕AI不靠谱捅娄子，怕又要学新工具增加负担，更怕那种"非黑即白"的焦虑感。

先别急着说"不"。换个角度想：这也许是你夺回时间主权的机会。

法律工作的痛苦从不是"不够忙"，而是处理大量的dirty work。法律工作容错率极低，与其搞大跃进式的变革，不如先从基础能力建设开始，让技术慢慢长出你熟悉的模样。

1.写好 AGENTS.md

给 AI 的"入职手册"：公司合同分类、每类关注重点、输出格式要求、禁止事项。写进文件，不是每次口头交代。

2.建立机械化约束

哪些动作 AI 可以自动做（读文件、查模板），哪些必须人工确认（改条款、发审批），提前定好规则。

3.找到你的"编译器"

合同审查不像代码有编译器，但可以有：审查清单核对、标准条款匹配、历史案例比对、风险等级自动判定。

4.上 Eval 和日志

记录 AI 每次审查了什么、漏了什么、为什么错。用数据改进，不是碰运气。

总结

如果说大模型解决的是"AI能不能思考"，那么Harness解决的是"AI能不能被信任"。

整体来说：

• Prompt Engineering 解决的是“怎么说”

• Context Engineering 解决的是“给什么”

• Harness Engineering 解决的是“怎么让它持续做下去”

过去大家在调一句 Prompt，现在大家开始调一整套 Agent 运行系统。

这不是因为Prompt不重要了，而是因为AI应用已经从"回答问题"走到了"连续执行任务"的阶段。

对法律人而言，这不是一个技术概念，而是一套正在成型的——AI时代的"行为约束与责任体系"。

法律人一直在做一件事：用规则约束行为，用流程控制风险，用证据链确定责任。

真正的变化，从来不是技术概念的堆砌，而是工程重心的转移——从“用好AI”，到“管好AI”。