Harness Engineering：AI Agent 真正的工程核心
AI Agent = LLM + Harness Engineering
这个公式看起来简单，但很多人第一次听到 Harness 这个词都会有些困惑。它不是一个框架，也不是某种工具，而是一种工程设计思路。本文试图从工程师的视角，说清楚 Harness 是什么、怎么做、以及它和 MCP、Tools、Skills 这些概念的关系。
一、Harness 是什么
Harness 这个词来自英语，原意是「挽具」——给马套上挽具，它才能拉车，而不是乱跑。
放到 AI Agent 的语境里：
Harness 是围绕 LLM 搭建的编排结构，让模型能在真实环境里稳定、持续地完成超出其单次能力边界的任务。
LLM 本身很聪明，但有两个根本局限：
局限一：上下文窗口有限。 对话长了之后，模型开始忘事、前后矛盾，甚至产生「上下文焦虑」——在接近窗口上限时提前收尾，而不是继续工作。
局限二：自我评估失真。 当你让模型检查自己写的代码或设计，它几乎总是说「很好」。即使问题显而易见，它也倾向于为自己辩护。
Harness Engineering 就是在工程层面解决这两个问题：通过合理的架构设计，让模型的实际交付质量远超它「单独跑」的水平。
Anthropic 工程团队在一篇文章里描述了他们的实验：同一个一句话的需求，单 Agent 跑了 20 分钟花了 9 美元，核心功能还是坏的；加上精心设计的 Harness 之后，跑了 6 小时花了 200 美元，但最终交付了一个真正可玩的完整应用。
这就是 Harness 的价值。
二、Harness 的四层结构
如果要把 Harness 拆开来看，它由四层组成：
编排层：决定谁做什么
编排层是 Harness 的大脑，负责任务分解和角色分工。
任务分解解决的是：复杂任务不能一次性扔给模型。一个「做完整电商系统」的需求，模型会开始写，写到一半上下文满了，开始乱编。正确的做法是把它拆成若干个可验证的子任务，每次只做一个。
角色分工解决的是自我评估失真问题。Anthropic 的实验结论非常明确：把生成和评估分给两个不同的 Agent，效果远好于让同一个 Agent 又做又评。
典型的三角色结构是：
- Planner：把用户的一句话扩展成完整规格
- Generator：按规格逐步实现
- Evaluator：像挑剔的 QA 工程师一样找 Bug
关键在于，Evaluator 要被调教成「默认认为有问题」的模式，而不是「默认认为没问题」。
执行层：真正和外部世界交互
执行层是 Agent 的「手」，负责调用工具操作真实环境。这包括读写文件、执行代码、操作浏览器、查询数据库、调用 API 等。
执行层依赖的不是框架，而是工具生态。MCP（Model Context Protocol）是目前的行业标准，提供了大量即插即用的工具服务器。代码执行用 E2B 或 Docker 做安全隔离。浏览器操作用 Playwright MCP，让 Evaluator 可以真正「点击」应用来验收。
反馈层：把「好不好」变成可执行的意见
反馈层解决的核心问题是：评估结果必须具体到 Generator 知道该改哪里。
反馈分两种：
硬反馈有客观答案——代码跑起来了吗？测试通过了吗？这类反馈直接来自测试框架或代码执行结果。
软反馈没有标准答案，比如「设计好不好」、「文档清不清楚」。处理软反馈的关键是把抽象问题拆成具体维度。Anthropic 团队用四个标准来评估前端设计：设计质量、原创性、工艺完成度、功能可用性。每个维度单独打分，低于阈值才触发重做。
这种「把主观评估量化」的工作，是反馈层设计里最难也最有价值的部分。
记忆层：在正确时机注入正确上下文
记忆层解决的是「模型如何跨越上下文限制持续工作」的问题。
记忆有四种类型，各有对应的存储方式：
| 类型 | 内容 | 存储方案 |
|---|---|---|
| 工作记忆 | 当前对话历史 | messages 列表 |
| 情节记忆 | 用户历史偏好、跨会话信息 | Redis / KV Store |
| 语义记忆 | 领域知识、公司文档 | 向量数据库（Qdrant / Chroma） |
| 程序记忆 | 操作流程、最佳实践 | Skill 文件系统 |
注入的时机同样重要：语义记忆在 System Prompt 顶部，情节记忆在底部，工作记忆作为对话历史传入，程序记忆由 Skill 机制自动触发。
三、Harness 与现有 Agent 框架的区别
说到 AI Agent，很多人会想到 LangChain、LangGraph、CrewAI 这些框架。Harness 和它们是什么关系？
框架是实现 Harness 的工具，Harness 是你要实现的设计。
LangGraph 是实现编排层的优秀工具，但它本身不能告诉你是否需要三个 Agent、Evaluator 要怎么调教、上下文满了该怎么办。这些都是 Harness Engineering 的决策，框架只是执行这些决策的手段。
更本质的区别在于两种思维方式：
框架思维：我用哪个框架？它支持哪些功能？我怎么配置它？
Harness 思维：模型在这个任务上的瓶颈是什么？是上下文焦虑还是自我评估偏差？任务需要分解成几个阶段？生成和评估应该分离吗？反馈够不够具体？
框架解决的是「怎么写代码」，Harness 解决的是「怎么设计系统」。
四、Harness 与 MCP、Tools、Skills 的关系
这几个概念常常被混淆，但它们其实在不同层面工作：
MCP 和 Tools：执行层的基础设施
MCP（Model Context Protocol）是 Anthropic 推出的工具接入标准协议，解决的问题是：如何让 LLM 安全、标准地调用外部工具？
Tools（工具）是执行层的基本单元——文件读写、代码执行、数据库查询、API 调用，每个都是一个 Tool。
在 Harness 的四层结构里，MCP 和 Tools 属于执行层。它们回答的是「Agent 能做什么」，而不是「Agent 该怎么做」。
一个没有 Harness 的 Agent 即使有很多 MCP 工具，也可能在复杂任务上跑偏。工具是手，Harness 是大脑。
Skills：程序记忆的文件化表达
Skills 是 Anthropic Agent SDK 里的一个概念，本质是一个 SKILL.md 文件，里面写着「遇到这类任务应该怎么做」。
在 Harness 的四层结构里，Skills 属于记忆层，具体是程序记忆。
Skills 和 Tools 的根本区别：
- Tools 是「做某件事的能力」（比如调用 API）
- Skills 是「做某类任务的知识」（比如处理发票的标准流程）
换个比喻：Tools 是员工的技能证书，Skills 是公司的操作手册。都很重要，解决不同的问题。
三者在 Harness 里的位置
编排层（LangGraph / CrewAI）
↓ 调度任务
执行层（MCP Tools / Playwright） ← 工具在这里
↓ 产出结果
反馈层（LLM Evaluator / pytest）
↓ 存储反馈
记忆层（Redis / Qdrant / Skills） ← Skills 在这里
↑ 上下文注入
编排层
MCP Tools 让 Agent 能干活，Skills 让 Agent 知道怎么干好，Harness 把整个流程串起来并确保质量。
五、Harness Engineering 的核心原则
从 Anthropic 的实践经验里，可以提炼出几个关键原则：
原则一：每个组件都是对模型能力的一个假设。 你加一个 Context Reset 机制，是因为你认为模型在长任务里会产生上下文焦虑。你加 Evaluator，是因为你认为模型无法客观评估自己。模型升级之后，这些假设可能不再成立——要定期审查并移除不再需要的组件。
原则二：能简则简，需要才加。 Anthropic 的建议是「find the simplest solution possible, and only increase complexity when needed」。Harness 的复杂度要和任务的难度匹配，过度工程化是常见陷阱。
原则三：Harness 的空间随模型能力移动，而不是缩小。 旧模型需要 Sprint 分解和频繁 Context Reset，新模型自己能处理了。但新模型的能力边界在更复杂的地方，新的 Harness 设计空间随之打开。AI 工程师的工作不会消失，只是问题变了。
原则四：读 Trace，不要只看结果。 要真正优化 Harness，必须仔细阅读 Agent 的执行日志。Evaluator 在哪里手软放行了？Generator 在哪里开始跑偏？问题在日志里，不在结果里。
结语
AI Agent = LLM + Harness Engineering。
LLM 决定了能力的天花板，Harness 决定了你能用出多少。
同一个模型，有没有 Harness、Harness 设计好不好，最终交付物的差距可以是天壤之别。这也是为什么「AI 工程师」这个岗位有其独立价值——不是训练模型，而是设计让模型真正能干活的系统。
MCP 给了 Agent 工具，Skills 给了 Agent 知识，框架给了 Agent 执行环境，而 Harness Engineering 把这一切组织成一个能稳定交付价值的整体。
这才是 AI Agent 工程的核心。
【Harness design for long-running application development】www.anthropic.com/engineering…
