Harness Engineering：AI Agent 真正落地的关键，不只是模型

过去一段时间，我越来越强烈地感受到：AI Agent 的上限可能由模型决定，但它能不能稳定交付，往往取决于模型外面的那套系统。

很多时候，我们会把 Agent 表现不好归因于模型不够强、提示词没写好、上下文没塞够。但在真实项目里，问题经常不在这些显眼的位置。真正让 Agent 从“偶尔惊艳”走向“稳定可用”的，往往是任务如何拆解、状态如何管理、关键步骤如何校验、失败之后如何恢复。

这套围绕模型搭建的运行、编排、监督和纠偏系统，就是我理解的 Harness Engineering。

一句话理解 Harness Engineering

Prompt Engineering 解决的是“怎么把任务讲清楚”。

Context Engineering 解决的是“怎么把信息给正确”。

Harness Engineering 解决的是“怎么让模型在真实执行中持续做对”。

如果说 Prompt 和 Context 主要处理模型的输入侧，那么 Harness 处理的是整个任务执行过程：工具、状态、流程、检查、观测、约束、失败恢复，以及如何让 Agent 在长链路任务里不跑偏。

为什么只靠模型和提示词不够

一个常见场景是：团队已经换上了很强的模型，提示词也反复打磨了很多版，但 Agent 一进真实业务场景还是不稳定。

它有时很聪明，有时又莫名跑偏；有时步骤看起来合理，结果却交付不了；有时工具调用成功了，但模型误解了工具返回；有时任务跑到一半，上下文开始混乱，前面确认过的结论又被忘掉。

这类问题继续靠“把提示词写得更长”通常不会根治。因为问题已经不只是“模型有没有听懂”，而是“系统有没有让模型在复杂环境里持续工作”。

稳定的 Agent 不是一个裸模型加一段提示词，而是一套完整的工作环境。模型负责推理和生成，Harness 负责给它轨道、边界、反馈和恢复能力。

AI 工程的三次重心迁移

我会把近几年的 AI 应用工程粗略分成三个阶段：Prompt Engineering、Context Engineering、Harness Engineering。

这三个阶段不是互相替代，而是边界一层层往外扩。

第一阶段：Prompt Engineering

大模型刚开始被广泛使用时，大家最直接的感受是：同一个模型，换一种问法，输出质量可能差很多。

于是 Prompt Engineering 成了第一波核心能力。角色设定、风格约束、few-shot 示例、输出格式、任务拆解、反例约束，这些方法都在解决一个问题：让模型更准确地理解当前任务，并沿着我们期望的方向生成。

Prompt Engineering 的本质不是命令模型，而是塑造一个局部的概率空间。你给它身份，它会沿着身份回答；你给它样例，它会沿着样例补全；你强调约束，它会把那些约束放到更高优先级。

但 Prompt 有天花板。它可以把任务讲清楚，却不能凭空补齐事实；它可以激发模型已有能力，却很难管理动态信息和长链路状态。

第二阶段：Context Engineering

当任务从单轮问答走向真实工作流时，模型需要的不再只是一段清楚的指令。

它还需要当前文档、历史记录、业务规范、用户偏好、工具返回、中间产物、系统规则、安全约束，以及其他 Agent 传来的结构化结果。

这就是 Context Engineering 的价值：在正确的时机，把正确的信息，以合适的形式送给模型。

这里的 Context 不只是几段背景资料，而是所有会影响模型当前决策的信息总和。

RAG 是 Context Engineering 的典型实践，但成熟的 Context Engineering 不止是检索。它还包括文档怎么切块、结果怎么排序、长文怎么压缩、历史对话什么时候保留、什么时候摘要、工具返回要不要全部暴露、多 Agent 之间传原文还是传结构化字段。

我觉得 Agent Skills 也是一种很典型的上下文工程实践。它背后的思想是渐进式披露：不要一开始就把所有工具说明、所有参数、所有 SOP 全塞给模型，而是先给最少必要信息，等模型真的需要某种能力时，再加载对应的详细说明、参考资料和脚本。

上下文不是越多越好。上下文窗口是稀缺资源，信息太多，注意力反而会被稀释。

第三阶段：Harness Engineering

Prompt 讲清楚了，Context 给正确了，复杂任务仍然可能失败。

因为真实任务不是一次回答，而是一条执行链路。模型需要连续行动、调用工具、读取反馈、更新计划、管理状态、修正错误，最后交付结果。

这时最关键的问题变成：当模型开始连续行动时，谁来监督它、约束它、校验它、纠偏它？

Harness Engineering 关注的就是这个问题。

它不是替代 Prompt，也不是替代 Context，而是在更大的系统边界里把二者都包含进来。Prompt 是 Harness 的一部分，Context 也是 Harness 的一部分，但 Harness 还要负责执行编排、工具治理、状态管理、评估观测和失败恢复。

一个简单类比

假设你要派一个新人去完成一次重要客户拜访。

Prompt Engineering 是把任务讲清楚：见面先寒暄，再介绍方案，问清需求，最后确认下一步。

Context Engineering 是把资料准备齐：客户背景、过往沟通记录、产品报价、竞品情况、会议目标。

Harness Engineering 是给他一整套可执行的工作系统：带着 checklist 去，关键节点实时汇报，会后核对纪要和录音，发现偏差及时纠正，最后按明确标准验收结果。

前两者解决“说清楚”和“信息齐”，Harness 解决“过程稳”。

成熟 Harness 的六层结构

如果把 Harness 拆开看，我会把它分成六层。

第一层：上下文边界

模型能不能稳定发挥，很多时候不只取决于它聪不聪明，还取决于它看到了什么。

Harness 首先要确保模型在正确的信息边界里思考：

当前角色是什么
任务目标是什么
成功标准是什么
哪些信息必须保留
哪些信息应该裁剪
固定规则、当前任务、运行状态、外部证据分别放在哪里

信息结构一旦混乱，模型就容易漏重点、忘约束，甚至被无关信息污染。

第二层：工具系统

没有工具时，大模型主要还是文本预测器。接上工具之后，它才真正能接触外部世界，比如搜索网页、读取文档、写代码、调 API、查数据库。

但 Harness 不是简单地把工具全部挂上去，而是要回答三个问题：

给模型什么工具
什么时候允许它调用工具
工具结果如何筛选、提炼并重新喂回模型

工具太少，能力不够；工具太多，模型容易乱用。工具返回也不应该原样塞回上下文，而要经过结构化、过滤和压缩。

第三层：执行编排

很多 Agent 的问题不是某一步不会，而是不会把所有步骤稳定串起来。

它可能会搜索，也会总结，也会写代码，但整个过程想到哪做到哪，最后产出一堆半成品。

一个完整任务通常需要一条清晰轨道：

理解目标
判断信息是否足够
不足则继续补充
基于已有信息分析
生成输出
检查输出
不满足要求则修正或重试

人类靠经验维持流程，Agent 靠 Harness 提供流程。

第四层：记忆和状态

没有状态管理的 Agent，每一轮都像失忆一样。

它不知道自己刚做了什么，不知道哪些结论已经确认，也不知道哪些问题还没解决。长任务一旦跑起来，很容易上下文混杂、状态漂移、重复劳动。

至少要区分三类状态：

当前任务状态
会话中的中间结果
长期记忆和用户偏好

这三类东西如果混在一起，系统会越来越乱。分清之后，Agent 才能像一个稳定的协作者，而不是一个每轮重启的聊天框。

第五层：评估和观测

很多 AI 系统不是生成不出来，而是生成完之后不知道自己做得好不好。

如果没有独立的评估和观测，Agent 很容易停留在“自我感觉良好”的状态。

成熟 Harness 需要包含：

输出验收
环境验证
自动测试
日志和指标
错误归因

系统不只要会做，还要知道自己有没有真的做对。

第六层：约束、校验和失败恢复

真实环境中，失败不是例外，而是常态。

搜索可能不准，API 可能超时，文档格式可能混乱，模型可能误解任务，外部系统也可能返回异常。

如果没有恢复机制，Agent 每次出错就只能从头再来，甚至在错误路径上越走越远。

这一层需要处理：

哪些事情能做，哪些不能做
输出前后如何检查
失败后如何重试
什么情况下回滚
如何把任务交接到干净状态继续执行

这一层往往决定系统能不能真正上线。

两个值得借鉴的工程原则

1. Context Reset：不要无限压缩脏上下文

长任务运行久了，上下文会越来越满。很多系统会做 context compaction，也就是把历史上下文压缩后继续跑。

但有时压缩不够。压缩只是变短了，不代表上下文负担真的消失了。模型可能仍然带着旧上下文里的噪声、偏差和混乱状态继续工作。

更激进的做法是 context reset：启动一个干净的新 Agent，把必要状态交接过去，让新 Agent 在更清爽的上下文里继续任务。

这有点像工程里遇到内存泄漏时，不是继续清缓存，而是重启进程，再恢复必要状态。

2. 生产和验收要分离

让同一个模型先干活，再给自己的结果打分，往往会偏乐观。

尤其是产品体验、设计完整度、代码质量这类没有唯一标准答案的任务，模型自评很容易放过问题。

更稳的方式是拆角色：

Planner：把模糊需求扩展成规格
Generator：负责实现
Evaluator：像 QA 一样真实验证

关键是 Evaluator 不只是读输出，而是要进入真实环境里验证。比如打开页面、点击交互、运行测试、检查日志、观察指标。

生成、检查、修复、再检查，这个闭环比一次性生成可靠得多。

对 AI 编程的启发

把 Harness Engineering 放到 AI 编程里，我觉得会得到一个很重要的视角：不要只把 AI 编程看成“让模型写代码”，而要把它看成“给模型搭一个能交付软件的工作环境”。

一个稳定的 AI 编程工作流，至少应该让 Agent 看到真实反馈：

能运行测试
能打开浏览器
能截图和点击页面
能读取日志
能查询监控
能在隔离环境中修改和验证
能根据失败结果继续修复

如果 Agent 写完代码就宣布完成，但没有运行、没有验证、没有观察结果，那只是文本生成，不是工程交付。

还有一个很实用的原则：当 Agent 失败时，不要只要求它“再认真一点”。更应该问：它缺了什么结构性能力？

也许是缺少测试入口，也许是缺少日志可见性，也许是上下文组织太乱，也许是任务拆得太大，也许是没有明确验收标准，也许是工具返回没有被结构化。

修复 Agent，很多时候不是修复模型，而是修复环境。

我会如何设计一个 Agent Harness

如果我要设计一个真正可用的 AI 编程 Agent，我会从这几个问题开始检查：

目标是否被拆成明确阶段？
每个阶段的成功标准是什么？
当前阶段需要哪些上下文？
哪些上下文应该延迟加载？
工具列表是否足够少、足够明确？
工具调用是否有边界？
工具返回是否经过筛选和结构化？
当前任务状态、中间产物、长期记忆是否分开管理？
是否有独立评估者或自动验收流程？
是否能真实运行并观察结果，而不是只看文本输出？
日志、指标、错误归因是否可查？
失败后是简单重试，还是有恢复、回滚、交接机制？
规则是否能指导修复，而不只是指出错误？

这些问题看起来琐碎，但它们决定了 Agent 是玩具，还是工程系统。

几个关键概念

Prompt Engineering：通过任务描述、角色设定、示例和格式约束，让模型更好理解和生成。
Context Engineering：在正确时机给模型提供正确上下文，包括知识、状态、规则、工具返回和中间产物。
Harness Engineering：围绕模型搭建执行、编排、工具、状态、评估、约束和恢复系统，让模型在真实任务中稳定工作。
Context Compaction：把长上下文压缩后继续运行。
Context Reset：启动干净的新 Agent，并把必要状态交接过去。
渐进式披露：先给模型最少必要信息，需要时再加载详细规则、文档、脚本或 SOP。
生产验收分离：让负责生成的 Agent 和负责验证的 Agent 分离，形成生成、检查、修复、再检查的闭环。

结语

AI 落地的核心挑战，正在从“让模型看起来更聪明”，转向“让模型在真实世界里稳定工作”。

Prompt 决定模型是否理解任务，Context 决定模型是否拿到信息，而 Harness 决定模型能否在长链路、可执行、低容错的真实场景中持续交付。

所以，同样的模型在不同产品里表现差距巨大，并不奇怪。

模型决定上限，Harness 决定落地。