1. 前言
当我们观察一辆高性能赛车时，驾驶员的技术固然重要，但更关键的是整套车辆工程系统——转向系统、刹车系统、悬挂系统、仪表盘——这些围绕引擎构建的系统，才是赛车能够高速安全行驶的根本保障。
AI Agent 开发面临同样的本质问题：模型本身的智能能力是"引擎"，但引擎再强劲，若缺乏指引方向的"指南针"和确保安全的"刹车系统"，最终的结果往往是在高速行驶中迷失方向或失控。
Agent
这正是 Harness Engineering（驾驭工程） 诞生的背景。
2. 什么是 Harness Engineering
Harness Engineering （驾驭工程）是 AI Agent 开发领域中一个关键的工程方法论，其核心理念是：
通过优化模型周围的系统，而非频繁更换模型本身，来提升 Agent 的可靠性。
这一理念可以用一个简洁的等式来表达：
Agent = Model + Harness
Harness
其中：
汽车比喻在这里尤为贴切： 模型是引擎， Harness 是指南针和刹车系统 。一辆没有方向盘和刹车的跑车，无论引擎功率多大，都是一场灾难。同样，一个缺乏 Harness 工程保障的 AI Agent ，无论模型能力多强，在真实复杂场景中都将面临不可预测的失败。
3. 技术背景与问题由来
在 AI Agent 开发初期，大多数工程师将精力集中在两件事上：选择更好的模型，以及优化 prompt （提示词）。这种"模型中心论"的开发范式带来了显著的局限性：
prompt
问题一：上下文窗口的性能墙与焦虑
研究发现，当大模型的上下文窗口利用率超过 40% 时，模型的推理质量会出现明显下滑。在长时间运行的 Agent 任务中，上下文会不断积累历史对话、工具调用记录、中间结果，最终导致模型"信息过载"，输出质量大幅下降。
更隐蔽的问题是 上下文焦虑 （ Context Anxiety ）：部分模型在感知到上下文窗口即将耗尽时，会主动提前收尾、跳过尚未完成的步骤，表现得好像自己已经完成了全部工作。与普通的性能下降不同，上下文焦虑不产生任何错误信号，而是静默地输出不完整的结果，在缺乏外部验证机制的情况下极难发现。
问题二：prompt 的脆弱性
通过 prompt 要求模型遵守规则，本质上是在依赖模型的"自律性"。而大模型在复杂场景中是天然不稳定的——同样的规则描述，在不同的上下文状态下可能产生截然不同的执行效果。
问题三：多Agent协作的污染效应
当多个 Agent 协作完成任务时，不同 Agent 的上下文互相污染，导致决策偏差、责任边界模糊、调试极其困难。
问题四：无终止的执行循环
Agent 在执行复杂任务时容易陷入无意义的循环：反复重试失败操作、跳过关键验证步骤、在无进展状态下持续消耗 token 。
问题五：系统熵增导致的维护危机
随着 Agent 系统不断演进，上下文状态、配置规则、工具约束逐渐积累成难以维护的复杂混乱状态，最终导致系统不可预测性急剧上升。
Harness Engineering 正是为了系统性解决上述问题而提出的工程方法论。
4. 六大支柱
Harness Engineering 的实践体系由六大核心支柱构成，每个支柱针对不同层面的可靠性挑战。
4.1 上下文架构（Context Architecture）
核心理念 ：精准设计进入模型上下文的信息，避免信息过载。
上下文架构是 Harness Engineering 最基础也最关键的支柱。研究表明，模型上下文窗口利用率超过 40% 后，推理质量开始显著下降。这意味着让模型"少想"有时比让模型"多看"更重要。
上下文生命周期管理
上下文架构的核心是为上下文建立完整的生命周期管理机制，而非被动等待模型性能劣化。完整的生命周期包含以下四个阶段：
Claude Code实践参考
Claude Code 在上下文架构上的设计是业内较为完善的参考实现：
Claude Code
4.2 架构约束（Architectural Constraints）
核心理念 ：用工具和代码强制执行规则，而非依赖 prompt 软约束。
这是 Harness Engineering 最反直觉的一个原则。当我们在 prompt 中写下"请不要删除用户数据"时，我们是在用语言劝说一个随机采样系统。而架构约束的做法是： 代码层面根本不提供删除功能，或在工具定义时强制要求二次确认 。
Pydantic
TypeScript
架构约束的工具落地
架构约束的核心在于用工程手段替代 prompt 劝说。落地时应遵循以下设计原则：
工具设计的约束原则
Claude Code 将架构约束设计为核心的权限模型，是该支柱最直接的工程实现：
分级权限模式 ：内置四种权限模式，通过 Shift+Tab 循环切换，将操作风险与授权级别强制绑定：
default
acceptEdits
plan
bypassPermissions
4.3 自验证循环（Self-Validation Loops）
核心理念 ：在 Agent 执行流程中内置验证检查点，防止死循环与静默失败。
Agent 在无人监督的情况下执行复杂任务时，最危险的两种状态是：
自验证循环通过在每个重要操作节点插入验证逻辑来解决这两个问题。
自验证循环设计要素
自验证循环的设计方法
有效的自验证循环需要明确回答三个设计问题：
① 如何判断"有进展"？
不能仅凭 Agent 是否产生输出来判断进展，而应通过 状态指纹比对 来检测。每次执行后对关键状态（任务完成度、已解锁资源、已修改文件等）计算摘要，连续多轮摘要无变化即为停滞循环，应触发升级或中止。
② 如何设置终止边界？
应以"预算"而非"无限循环"的心态设计 Agent 执行边界：
③ 错误后如何处理？
自验证循环要求 Agent 不允许静默忽略错误。当步骤后验证失败时应依次尝试：自我校正（重新分析并修正当前步骤）→ 换策略重试 → 升级到人工确认 → 彻底中止并生成诊断报告。
④ 为何必须将生成者与评估者分离？
Anthropic 的工程实践揭示了一个关键问题： 大模型在评估自身产出时存在系统性乐观偏见 。当要求 Agent 对自己生成的内容打分时，即便产出质量在人类观察者看来明显欠佳，模型也倾向于给出积极评价。更棘手的是，即使模型在评估过程中识别出了真实存在的问题，它也容易"自我说服"这些问题不算严重，最终仍然通过验证。
这一问题的工程解法受 生成对抗网络 （ GAN ）启发——将生成与评估分离为两个独立 Agent ： 生成者Agent 负责产出内容， 评估者Agent 负责批判性审查。分离本身并不能立即消除评估者的乐观倾向，但它使得单独针对评估者进行"偏向严格"的调优成为可能，而这比让生成者"批判自己的作品"在工程上要容易得多。
评估者的调优是一个迭代过程，需要反复审查评估日志、找出评估判断与预期存在偏差的具体案例，并迭代更新评估 prompt 。值得注意的是，有效的评估者还需具备 主动探测能力 ——不能仅凭静态截图打分，而应像真实用户一样主动操作界面、调用 API 、验证边界条件，才能发现被动查看无法暴露的深层缺陷。
Claude Code 的智能体循环（ Agentic Loop ）本质上就是一个自然的自验证循环——执行工具、观察结果、调整策略，循环迭代直至任务完成：
4.4 上下文隔离（Context Isolation）
核心理念 ：多 Agent 协作时，保持每个 Agent 上下文的纯净性，防止跨越边界的信息污染。
在多 Agent 架构（如协调者-执行者模式、流水线模式）中，上下文污染是可靠性的头号杀手。当一个 Agent 的内部状态、中间推理或错误信息渗漏到另一个 Agent 的上下文中时，会引发一系列难以调试的级联问题。
典型污染场景
隔离后的正确模式
Claude Code 通过 SubAgents （子代理）和 Agent Teams （代理团队）机制，在工具层面提供了上下文隔离能力：
4.5 熵治理（Entropy Governance）
核心理念 ：建立自维护机制，对抗 Agent 系统中上下文和状态的自然熵增趋势。
热力学第二定律告诉我们，孤立系统的熵（无序度）只会增加。 Agent 系统也不例外——随着任务执行，上下文不断积累，规则不断叠加，工具调用记录不断增长，系统状态越来越复杂，最终变得难以预测和维护。
熵治理的目标是建立 自维护的闭环机制 ，让系统能够定期清理、压缩、重组自身状态，保持长期健康。
熵的来源分析
上下文熵增的来源： - 持续累积的对话历史 - 工具调用轨迹与中间结果 - 随时间叠加的矛盾指令 - 死亡状态引用（已不存在的任务） - 大量重复信息挤占上下文空间
上下文熵增的来源：
熵治理的设计方法
熵治理需要建立系统性的"清洁维护"机制，类似于数据库的定期 VACUUM 操作，保持系统状态的持续整洁。
上下文蒸馏设计
上下文蒸馏是熵治理最核心的手段，其设计原则是： 保留决策结论，丢弃推理过程 。蒸馏时应明确区分需要保留和可以丢弃的信息：
关键检查点设计
在 Agent 系统设计阶段应预先规划"熵控检查点"，即阶段性任务边界在完成时自动触发以下清理动作：
Claude Code 的记忆体系是熵治理思想的直接落地——通过分层记忆机制和自维护闭环，对抗上下文熵增：
4.6 可拆卸性（Detachability）
核心理念 ：以模块化设计构建 Harness 系统，使其能够随着模型的迭代进化而优雅适配。
AI 模型迭代速度极快。今天针对 GPT-4.5 精调的 Harness 系统，明天可能需要适配 Claude 4.5 的能力特性，后天又需要对接开源模型。如果 Harness 与特定模型深度耦合，每次模型更换都意味着大规模重构。
可拆卸性原则要求将 Harness 系统中与模型强相关的部分设计为 可插拔的适配层 。
可拆卸性架构
可拆卸性的工程落地方法
实现可拆卸性的核心工程手段是 在 Harness 核心层与模型适配层之间建立明确的接口契约 ，确保模型相关的适配逻辑不渗透进业务层。
具体落地时，建议将 Harness 系统明确分为三个层次，并为每个层次建立独立的配置、部署和演进机制：
关键实践 ：将 prompt 模板从代码中外置为独立的配置文件（ YAML / TOML 格式），每个模型对应一套模板配置，切换模型时只需切换配置文件，无需修改业务逻辑。
Claude Code 的整个配置体系设计本身就是可拆卸性原则的体现——指令、技能、规则均以独立文件形式存在，与底层模型版本解耦：
5. 六大支柱的内在联系
六个支柱并非相互独立，而是形成了一个相互支撑的整体工程体系：
6. Harness Engineering最佳实践
6.1 以问题为导向，不要过度预防
Harness 设计具有"复利效应"——早期的工程投入会在 Agent 系统运行中持续产生收益。但也正因如此，容易让工程团队陷入"预防一切可能问题"的过度设计陷阱。
推荐原则 ： 聚焦已经发生的问题，而非假想的问题。
当 Agent 系统在生产环境中出现具体失败时，分析根本原因，针对性地补强对应的 Harness 支柱。这种由实际问题驱动的迭代方式，比预先设计所有防护机制效率高得多，也能避免过度工程化。
6.2 工具质量胜于工具数量
Agent 的能力边界取决于其可用工具的质量。与其提供二十个功能模糊的工具，不如提供五个边界清晰、文档完善的工具。
Anthropic 的工程实践表明：在 SWE-bench 测试中，工程师在工具设计上花费的时间远远超过在 prompt 调优上的时间，最终带来了更好的 Agent 可靠性。
6.3 监控可观测性是Harness的基础设施
Harness Engineering 强调的工程质量需要通过可观测性来验证和持续改进。良好的 Harness 可观测性体系应覆盖以下六大核心指标维度：
以上指标应与 Prometheus + Grafana 或云厂商的 APM 平台对接，建立实时监控仪表盘。在 Agent 系统上线早期，重点关注 上下文利用率 和 迭代次数异常 两类指标，能够快速发现绝大多数可靠性问题。
6.4 先简单再复杂，随模型演进动态调整
Harness Engineering 不倡导一上来就构建完整的六支柱系统。建议的渐进路径：
反向同样成立：随着模型能力提升，主动精简 Harness 。
Harness 中的每一个组件，本质上都是对"当前模型无法独立完成某件事"这一假设的编码。正因如此，当底层模型版本升级时，应主动逐一审视每个 Harness 组件是否仍然必要——移除某个组件，观察对输出质量的实际影响；若移除后质量不受影响，说明该组件已成为无效的工程负担，应当裁撤。
过于复杂的 Harness 不仅增加成本和调用延迟，还会掩盖模型的真实能力上限，阻碍工程团队感知模型升级所带来的实际收益。 Anthropic 在其内部维护的长时任务 Harness 中，正是通过这种"逐组件移除并评估"的方法，在新模型发布后系统性地精简了前一代模型时代积累的脚手架。
7. 与其他工程方法论的关系
8. 小结
Harness Engineering 提供了一套系统性的 AI Agent 可靠性工程框架，其核心洞见是： Agent 的可靠性瓶颈往往不在于模型本身的智能程度，而在于围绕模型构建的工程系统质量。
六大支柱各司其职 ：
这六大支柱共同构成了 Agent 系统的"指南针和刹车系统"。随着 AI Agent 在生产环境中承担越来越关键的任务， Harness Engineering 的工程投入，将成为区分可靠产品与失控系统的核心差异。
9. 参考资料
