【Harness Engineering】为什么需要 Harness Engineering？从Claude Code源码里扒出的真相：智能体不乱来，全靠这5层“枷锁”！
AI技术研习社 从Claude Code源码揭示：智能体稳定运行的5层约束机制
AI工程实践中普遍面临的核心矛盾：智能体被宣传为“能写代码、调工具的见习工程师”，但一旦接触终端、文件系统或Git仓库，极易因指令失误导致代码丢失、仓库损坏或权限泄露，轻则耗时回滚，重则引发生产事故。
智能体的核心价值并非“会做事”，而是“能可控地做事”。解决这一问题的关键在于约束工程（Harness Engineering），而非单纯的提示工程（Prompt Engineering）——前者构建系统化控制逻辑，明确“怎么做”与“禁止行为”；后者仅优化话术技巧。
分析Claude Code开源源码可见，其稳定落地的真正关键并非模型能力，而是5层严密约束体系。每层针对具体工程风险，践行“先约束，再执行”原则。
智能体为何必须“戴枷锁”？
模型本质是“输出概率分布的文本生成器”，仅追求“最可能正确”而非“绝对安全”。当脱离纯文本交互、接触shell或Git时，技术误操作（如误删配置、越权访问）会从话术问题升级为执行灾难——这是模型固有局限，非偶然失误。
约束工程实为“控制平面”，并非限制智能体功能，而是划定安全边界使其按规则执行。Claude Code源码的核心逻辑即构建这一约束系统，使其能在真实工程环境落地，而非停留于Demo阶段。
Claude Code的5层约束机制解析
源码（prompts.ts至toolOrchestration.ts）将约束系统化为5层，形成完整风险控制闭环：
第一层：受约束的会话系统
突破常规Prompt的“人格化修辞”，将其转化为结构化控制规则。例如源码中prompts.ts文件：身份定义、工具权限说明、工程约束（如“禁止虚构抽象”）严格分段组织；并通过getSystemPrompt()函数实现动态内容拼装与优先级管理（默认规则 < 自定义规则 < 代理规则）。
这体现工程本质——Prompt应作为分层控制模块，避免逻辑冲突，而非堆砌冗长话术。
第二层：代理依赖持续循环
query.ts中queryLoop()函数构建状态机，明确管理消息流、工具上下文及轮次计数。关键逻辑在于承认“单次执行不可靠”：错误状态（如工具调用失败）将传递至下一轮处理，上下文自动压缩而非崩溃。
每轮执行前主动校验（消息裁剪、工具调用预算等），将控制权牢牢掌握在运行时，这是约束工程与提示工程的本质区别。
第三层：工具调用服从调度
针对80%的风险源（工具调用），在toolOrchestration.ts中通过partitionToolCalls()实现精细化调度：按工具Schema判断并发安全性；冲突工具（如文件操作）强制顺序执行，并通过上下文修饰器按原始顺序回放，避免执行冲突。
工具被视为“受管执行单元”而非能力延伸，纪律性优先于灵活性。
第四层：高风险工具的极细粒度约束
以Bash为例，源码中prompt.ts设置严苛操作规则：禁止随意修改git config、跳过hooks或使用git add .，默认禁用提交推送等。规则细化到每步操作，直指“能力越强，约束越细”的核心原则。
在工程场景中，安全权重远高于操作灵活度——一次误执行可能导致不可逆损失。
第五层：错误纳入主执行路径
query.ts将上下文膨胀、token超限等视为常态问题，而非异常分支。自动压缩、重试机制、阻断逻辑（如autocompact）深度集成于主循环，确保系统按预设路径恢复而非临场发挥。
约束型智能体的成熟标志：非“出错后道歉”，而是“预设中止/重试点，保证可控恢复”。
约束工程的核心原则与工程常识
Harness Engineering的本质是“用结构化设计直面模型缺陷”，核心原则在于：代理系统的价值不取决于“聪明程度”，而在于“约束执行能力”。
-
-
-
-
-
-
智能体落地的关键从来不是“话术多精妙”，而是“结构多可靠”。Harness Engineering正是平衡能力与风险的核心工程方法论。
