同样的模型，别人做出来的 agent 能连续跑很久、成功率很高，到自己手里却总是差强人意。决定差距的那套”模型之外”的系统，最近被统一叫作 Harness Engineering——《最近爆火的 Harness Engineering 到底是啥？一期讲透！》 围绕这个概念的演进、结构和一线实践讲了一遍。
三次重心迁移
过去两年 AI 工程经历了三次明显的重心迁移：Prompt Engineering → Context Engineering → Harness Engineering。这不是术语轮换，而是对应了系统发展的三个阶段性问题——模型有没有听懂你在说什么、有没有拿到足够且正确的信息、在真实执行里能不能持续做对。问题一层比一层往外扩。
Prompt 阶段解决的是表达。大模型是对上下文高度敏感的概率生成系统，给它一个身份它就沿着那个身份回答，给它一批范例它就沿着范式补全。Prompt 工程的本质不是命令模型，而是塑造一个局部的概率空间。核心能力是语言设计，不是系统设计。
但提示词很快碰到天花板：很多任务不是”说清楚就行”，而是”你真的得知道”。让模型分析一份公司内部文档、回答产品最新配置、按长规范写代码，再漂亮的提示词也替代不了事实本身。Prompt 解决的是表达问题，不是信息问题。
Context 阶段解决的是信息供给。当任务从一次回答变成进到真实环境里执行，模型需要的已经不只是几段背景资料。工程意义上的 context 是”所有影响当前决策的信息的总和”：用户输入、历史对话、检索结果、工具返回、当前状态、中间产物、系统规则、安全约束、其他 agent 传回的结构化数据。Prompt 只是 context 的一个子集。
RAG（Retrieval-Augmented Generation，检索增强生成）是这一层的典型实践，但成熟的 context 工程不止于检索——它关心文档怎么切块、结果怎么排序、长文怎么压缩、历史对话何时保留何时摘要、工具返回要不要全量暴露、多个 agent 之间传原文还是结构化字段。
最近火的 Agent Skills 其实也是 context 工程的高级形态。如果把十几个工具的全部说明和参数定义一上来就塞给模型，理论上”知道得更多”，实际效果反而更糟——上下文窗口是稀缺资源，信息一多注意力就涣散。Skills 采用渐进式披露（progressive disclosure）：开始只给模型看最少的元信息，真正要触发某项能力时再把 SOP、参考资料、脚本动态加载进来。上下文优化的关键不是”给得更多”，而是”按需给、分层给、在正确的时机给”。
Context 还不是终点。信息给对了模型也不一定能稳定执行：计划做得很好但执行跑偏，工具调对了但结果理解错了，在长链路里一步步偏航而系统浑然不觉。Prompt 和 context 主要都在优化输入，可一旦模型开始连续行动，谁来监督、约束、纠偏？这就是第三阶段——Harness Engineering。
什么是 harness
Harness 原意是缰绳、马具、约束装置。放到 AI 系统里的含义很朴素：当模型从”回答问题”走向”执行任务”，系统不只要喂信息，还要能驾驭整个过程。如果前两代工程关注”怎么让模型更会想”，harness 关注的是”怎么让它别跑偏、跑得稳、出错了还能拉回来”。
用派新人做重要客户拜访这个场景类比三者：
- Prompt：把任务流程讲清楚——见面先寒暄，再介绍方案，承接需求，最后确认下一步。重点是把话说明白。
- Context：把资料备齐——客户背景、过往沟通记录、产品报价、竞品情况、本次会议目标。重点是把信息给对。
- Harness：带 checklist 去、关键节点实时汇报、会后核实纪要和录音、发现偏差立刻纠正、按明确标准验收结果。重点不再是说没说清、资料齐没齐，而是有没有一套持续观测、持续纠偏、最终验收的机制。
三者是包含关系而不是替代关系。Prompt 是对指令的工程化，context 是对输入环境的工程化，harness 是对整个运行系统的工程化——边界一层比一层大。LongChain 工程师给出的典型定义：agent = model + harness，所以 harness = agent - model。一个 agent 系统里除了模型本身以外，几乎所有决定能否稳定交付的部分都算进 harness。
成熟 harness 的六层
-
上下文组织。从 harness 视角重新审视 context：角色与目标定义（模型要知道自己是谁、任务是什么、成功标准是什么）、信息裁剪与选择（不是越多越好，是越相关越好）、结构化组织（固定规则、当前任务、运行状态、外部证据分层放置）。信息一乱，模型就会漏重点、忘约束、甚至自我污染。
-
工具系统。没工具时模型只是文本预测器，挂上工具才能真正做事。关键不是简单挂上去，而是三件事：给什么工具（太少能力不够、太多会乱用）、什么时候该调（该查的别硬答、不该查的别乱查）、结果怎么回喂（几十条搜索结果不能原封塞回，要提炼筛选、保持任务相关性）。
-
执行编排。解决”下一步该做什么”。很多 agent 的问题不是某一步不会，而是不会把步骤串起来，想到哪做到哪，交付出一堆半成品。完整任务需要的轨道大致是：理解目标 → 判断信息够不够 → 不够就补 → 基于结果继续分析 → 生成输出 → 检查 → 不满足就修正或重来。非常接近人在工作的样子，区别在于人靠经验，agent 靠 harness。
-
记忆与状态。没状态的 agent 每轮都像失忆，不知道自己刚做了什么、哪些结论确认了、哪些问题还没解决。至少要分清三类：当前任务状态、会话中间结果、长期记忆与用户偏好。三类混在一起系统会越来越乱。
-
评估与观测。很多团队最容易忽视这一层——系统不是生成不出来，而是生成完根本不知道做得好不好。没有独立的评估和观测，agent 就长期停留在”自我感觉良好”。这一层包括输出验收、环境验证、自动测试、日志与指标、错误归因。会做之外，还要知道自己有没有真的做对。
-
约束、校验、失败恢复。真实环境里失败是常态不是例外：搜索不准、API 超时、文档格式混乱、模型误解任务。没有恢复机制，agent 每次出错就只能从头再来。成熟 harness 三件事必备：约束（哪些能做哪些不能做）、校验（输出前后怎么检查）、恢复（失败后从哪里续上、怎么回滚到稳定状态）。
三个量化参照
Harness 这个词最近突然火，是因为它已经被做进产品和工程体系，不再是空谈方法论：
- LongChain：底层模型完全不变，只迭代 harness，自家的智能体在榜单上从 30 开外杀到前五。
- OpenAI：一支只有几名人类工程师的团队，靠 agent 从零构建了超百万行代码的生产级应用，100% 代码由 agent 编写，耗时是纯人工的 1/10。
- Anthropic：他们的系统能凭一句自然语言需求，在无人干预下连续运行数小时，做出完整的游戏或数字音频工作站。
Anthropic：两个典型难题
上下文一长就装不下。任务时间拉长，上下文越来越满，模型开始丢细节、丢重点，甚至会出现一种有趣现象——它好像知道自己快装不下了，于是着急收尾。常见做法是 context compaction（上下文压缩），把历史压一压继续跑。但 Anthropic 发现对某些模型这还不够，压缩只是变短了，那种”负担感”并没有真的消失。于是他们做了更激进的 context reset：不在原上下文里继续压，而是换一个全新干净的 agent，把工作交接过去。思路像极了工程里遇到内存泄漏——不是继续清缓存，而是直接重启进程再恢复状态。
自评失真。让模型干活再让它自己打分，会偏乐观；尤其在设计体验、产品完整度这类没标准答案的任务上偏差更明显。他们的解法是把干活的和验收的分开：planner 把模糊需求扩展成完整规格，generator 逐步实现，evaluator 像 QA 一样真实地测试——不只看代码，而是真实操作页面、看交互、检查实际结果。背后的原则很硬：生产和验收必须分离。只要评估者足够独立，系统就能形成”生成 → 检查 → 修复 → 再检查”的有效循环。
OpenAI：重新定义 agent 时代的工程师
人不写代码，只设计环境。工程师的工作变成三件事：把产品目标拆解成 agent 能理解的小任务；agent 失败时不是让它更努力，而是问”环境里缺了什么能力”；建立反馈链路，让 agent 真正看到自己的工作结果。一句话很关键：agent 出问题时，修复方案几乎从来不是”再努力一点”，而是看看它缺了什么结构性的能力。
渐进式披露他们也交过学费。早期写过一份巨大的 AGENTS.md，把所有规范、框架、约定全塞进去，结果 agent 更糊涂了——窗口塞满等于什么都没说。后来改成”目录页”：顶层只保留核心索引，架构文档、设计文档、执行计划、质量评分、安全规则细节全放到子文档里，agent 先看目录，需要时再钻进去。和 Skills 是同一个思路。
让 agent 自己验收。产出速度上来之后，瓶颈不再是生成而是验收，人类盯不过来。于是给 agent 接浏览器（能截图、能模拟用户真实操作）、接日志系统和指标系统（能查 log 查监控），每个任务跑在独立隔离的环境里互不影响。agent 不再是”写完就说写完”，而是真正跑起来看结果、发现 bug、修 bug、再验证——把执行编排、评估观测、约束恢复三件事落成一套完整的工程系统。
把资深经验编码成系统规则。code review 靠人类兜底也来不及——agent 提交速度太快。于是把资深工程师的经验直接写成规则：模块怎么分层、哪一层不能依赖哪一层、什么情况必须拦截、发现问题应该怎么修。关键是这些规则不只负责报错，还会把”怎么修”一起反馈给 agent 进入下一轮上下文。这已经不是传统代码规范，而是一套可持续运行的自动治理系统。
为什么现在要重视 harness
任务简单单轮生成时 prompt 最重要；依赖外部知识和动态信息时 context 成为关键；一旦进入长链路、可执行、低容错的真实场景，harness 几乎不可避免。
同样的模型在不同产品里表现差距巨大，原因很直白：决定上限的是模型，决定能不能落地、能不能稳定交付的是 harness。AI 落地的核心挑战正在从”让模型看起来更聪明”转向”让模型在真实世界里稳定工作”。