Harness Engineering：给Agent 一副好马鞍

本文来自微信公众号： 陆三金 ，作者：陆三金，原文标题：《Harness Engineering：给 Agent 一副好马鞍》

最近你可能看到过这个词，Harness Engineering。

你的第一反应可能是，什么鬼？

Prompt Engineering还在学，Context Engineering还没搞懂，怎么又来了个Harness Engineering。

而且这玩意怎么翻译？

Harness，原意是马具，这怎么看和AI都不搭。

先不急，我给你一张图，你看了就会明白。

也就说，你给模型构建的这一系列，tools、文件、提示词、hooks、记忆系统等等，在一起统称Harness。

模型本是一匹野马，这一套Harness下去之后，你让它干啥它干啥。

先讲一个让人意外的实验结果。2026年2月，LangChain团队拿自家coding agent做了一次测试。他们用同一个模型GPT-5.2-Codex，只是改了改外围的"套具"（harness），Terminal Bench 2.0的分数就从52.8飙升到66.5，排名从Top 30直接冲进Top 5。

你没看错。马还是那匹马，换了个马鞍，速度完全不一样了。

这就是Harness Engineering正在展现的力量。

如果把AI agent比作一匹烈马，那么过去几年的技术演进，就是骑手们逐渐明白一个道理：驯马术有极限，马鞍工艺才是决定能跑多远的关键。

2020年到2023年，是Prompt Engineering的黄金时代。所有人都在研究怎么写提示词——用什么样的措辞、什么样的格式、什么样的示例，能让GPT-3或GPT-4给出更好的回答。那时候，prompt几乎等同于AI应用的全部工程工作。

但到了2024年，情况变了。模型变得越来越强，应用场景也从单次问答转向多轮对话、长时间任务。Anthropic的研究团队提出了一个新概念：Context Engineering（上下文工程）。他们认为，随着模型能力提升，构建AI应用的核心问题已经从"怎么写提示词"变成了"什么配置最可能产生期望的行为"。

Context指的是模型采样时获取的所有token——系统提示、工具定义、外部数据、消息历史等等。Context Engineering就是在这个不断膨胀的信息宇宙中，筛选出最小但最高信号的那部分token。

而Harness Engineering，则是Context Engineering的自然延伸。它不仅关心"给模型看什么"，更关心"如何让模型在看的过程中保持专注、自我纠正、持续前进"。OpenAI、Anthropic、LangChain，几乎所有头部玩家都在2025年到2026年间加大了对harness的投入。

这就像马术史上的一个转折点：人们发现，与其不断训练马匹的极限速度，不如设计更好的马鞍、缰绳和马蹄铁，让马跑得既快又稳。

说实话，这个时候，我真的想听李宏毅来讲一堂Harness Engineering课程，他的课程中往往有一句经典话术：「本课程中，没有模型被训练」，安全感满满。我们不动模型，但是我们让模型更听我们的话。

那么，一副好的" harness"到底包含什么？

首先是Context Engineering的基础设施。Manus团队在他们那篇经典的《AI代理的上下文工程：构建Manus的经验教训》博客中分享了一个关键洞察：现代AI agent的输入输出token比例可以达到100:1。也就是说，模型每输出一个token，可能要处理100个输入token。这让KV缓存（Key-Value Cache）变得至关重要——使用缓存后，Claude Sonnet的输入成本可以从3美元/百万token降到0.3美元，相差整整10倍。

为了最大化缓存命中率，Manus团队总结了三条铁律：保持提示前缀稳定、让上下文只追加不修改、在关键位置明确标记缓存断点。这些看似琐碎的工程细节，决定了代理运行的成本和速度。

其次是Progressive Disclosure（渐进式披露）。这个概念最早来自1990年代Nielsen Norman Group的可用性研究——不要一次性给用户所有信息，而是按需逐步展示。三十年后，这个原则在AI代理中找到了新生命。

Anthropic的Claude Code提供了一个经典实现。它的Skills功能采用三层架构：

• •第一层只加载技能的名称和描述（元数据）

  
  

• •第二层在匹配到用户需求时才加载完整技能内容

  
  

• •第三层则在执行过程中按需引用支持文件。这种方式让代理可以拥有数十个技能，但只为实际使用的那些付费。

  
  

这就像去图书馆查资料。笨办法是把整个图书馆搬到桌子上，然后翻找；聪明的办法是先看书目索引，找到可能相关的书，再一本本取阅。代理也需要这样的"索引系统"。

第三是Self-Verification（自我验证）。LangChain团队发现，模型最常见的失败模式是：写完代码，自己看一遍觉得"嗯，不错"，然后就停了。没有测试，没有验证，没有对比需求文档检查。

他们的解决方案是在harness中强制加入验证循环：Plan（规划）→Build（构建）→Verify（验证）→Fix（修复）。更巧妙的是，他们在模型准备退出时插入一个PreCompletionChecklistMiddleware，强制提醒代理"先别急着结束，跑一遍测试看看"。这个简单的钩子，大幅降低了"自以为完成了"的幻觉。

最后是长时间运行的支撑架构。当代理需要工作几个小时甚至几天时，单个上下文窗口显然不够。Anthropic的解决方案是双代理架构：Initializer Agent负责搭建环境——创建feature list、写init.sh脚本、做第一次git提交；Coding Agent则负责在每个会话中做增量推进，留下清晰的进度记录和git commit。

feature list的设计尤其精妙。Initializer Agent会把用户需求拆解成200多个具体功能点，全部标记为"未完成"。每个Coding Agent会话开始时，都要读取这个列表，选择最高优先级的未完成项来工作。这就避免了代理"一次性想做完所有事"或者"看了眼代码觉得差不多就宣布胜利"的两种常见失败模式。

Harness Engineering的崛起，标志着AI工程正在进入一个新阶段。

过去，人们把模型当作黑盒魔法，以为只要模型够强，一切问题都会迎刃而解。但现在，行业逐渐认识到一个事实：模型的原生智能是"尖刺状的"（spiky）——在某些任务上表现出色，在另一些任务上莫名其妙地失败。Harness Engineering的目标，就是打磨这些尖刺，让模型的能力更平滑、更可控、更可靠。

这有点像摄影术的历史。19世纪的摄影师痴迷于镜头工艺，追求更清晰的玻璃、更精准的焦距。但到了20世纪，真正改变摄影的是哈苏的模块化设计、宝丽来的即拍即得、数码相机的传感器优化。相机还是那个相机，但"如何使用它"的工程学让它走进了千家万户。

AI代理正在经历类似的转变。当GPT-5、Claude 4、Gemini 3这些基础模型趋于成熟时，竞争的焦点正在从"谁的模型更强"转向"谁的harness更精巧"。

那么，Harness Engineering会走向何方？

我认为有几种可能。

一种可能是标准化。就像Docker容器统一了应用部署一样，未来可能会出现Harness的标准格式——定义如何组织系统提示、如何管理工具、如何实现验证循环、如何跨会话保持状态。不同团队开发的代理可以共享harness组件，形成一个生态。

另一种可能是模型化。既然harness的设计如此依赖具体任务和模型特性，为什么不让AI自己来优化harness？我们可以想象一个元学习循环：代理执行任务，产生轨迹，另一个"harness优化代理"分析这些轨迹，提出harness改进建议，甚至自动生成新的中间件。这有点像编译器优化——人类写代码，编译器决定如何翻译成机器指令。

还有一种可能是领域分化。代码生成、科学研究、金融建模、创意设计——每个领域的harness可能走向完全不同的方向。写代码需要严格的验证循环和测试覆盖，做科研需要文献检索和假设追踪，搞金融需要风险评估和合规检查。没有一套harness能通吃所有场景。

回到开头的那个比喻。

好马需要好鞍。这不是对马的束缚，而是让它跑得更远的工具。Harness Engineering的本质，是承认AI不是黑盒魔法，而是需要被理解、被引导、被约束的智能体。

当AI代理从几分钟的对话走向几小时甚至几天的自主工作时，harness的质量将决定一切。它决定了代理会不会在半路迷失方向，会不会自以为完成了任务，会不会在跨会话时忘记之前做过什么。

LangChain用实验证明了：同样的马，换副鞍，能从Top 30冲进Top 5。

这个差距，就是Harness Engineering的价值。