同样的大模型，为什么别人的 Agent 能稳跑 6 小时，你的 30 分钟就“胡言乱语“？秘密就在 Harness 里。

你可能已经发现了——同样的模型别人的Agent能连续跑6小时不出错你的跑30分钟就开始胡言乱语。问题不在模型。01 三次中心迁移你在哪一层过去两年AI工程经历了三次中心迁移Prompt Engineering → Context Engineering → Harness Engineering。很多人觉得这就是换了个时髦词。但你如果真这么想就完全低估了这件事。这三个词分别对应了AI系统发展的三层核心问题阶段核心问题解决什么Prompt Engineering模型有没有听懂你把话说清楚Context Engineering模型有没有拿到正确的信息把信息给对Harness Engineering模型在真实执行中能不能持续做对让整个过程跑稳一个问题比一个难一层比一层往外扩。举个通俗的例子你派一个新人去见重要客户。Prompt——告诉他任务怎么拆先寒暄再介绍方案再确认下一步。核心是把话说明白。Context——让他把资料备齐客户背景、历史沟通、竞品情况、会议目标。核心是把信息给对。Harness——如果这个会真的很重要你还会做更多让他带checklist关键节点实时汇报会后核实纪要发现偏差立刻纠偏按明确标准验收。核心是有没有一套持续观测、持续纠偏、最终验收的机制。三者不是替代关系是包含关系。Prompt是对指令的工程化Context是对输入环境的工程化Harness是对整个运行系统的工程化。下面我们逐层来看——每一层解决了什么问题又撞上了什么天花板。02 Prompt的天花板说清楚 ≠ 做对大模型刚火的时候同一个模型换个说法结果差很多。于是大家疯狂研究提示词——角色设定、Few-shot示例、输出格式约束……Prompt的本质不是命令模型而是塑造一个局部的概率空间。你给什么身份模型就沿那个身份回答给什么样例模型就沿那个范式补全——Few-shot之所以有效本质上是因为大模型是上下文学习的机器你展示的每一条样例都在调整它下一个token的采样概率。这个阶段最重要的能力是语言的设计。但很快撞墙了。因为很多任务不是你说清楚就行而是你真的得知道。让模型分析内部文档、按复杂规范写代码、在多个工具之间协调任务——提示词写得再漂亮也替代不了事实本身。Prompt擅长长期任务约束输出、激发模型已有能力。Prompt不擅长凭空弥补缺失的知识、管理大量动态信息、处理长链路任务里的状态。说白了Prompt解决的是表达的问题不是信息的问题。03 Context的边界信息给对了 ≠ 执行不出错Agent时代来了模型不只是回答问题而是要进到真实环境里做事——多轮对话、调浏览器、写代码、操作数据库工具之间还要传递中间结果还要根据外部反馈修订计划。问题变了不是一次回答对不对而是整条链路能不能跑通。Context Engineering的核心变成一句话模型未必知道所有信息系统必须在合适的时机把正确的信息送进去。这里的Context不只是几段背景资料。在工程意义上它代表所有影响模型当前决策的信息总和——用户输入、历史对话、检索结果、工具返回、任务状态、中间产物、系统规则、安全约束、其他Agent传来的结构化结果。RAG算是Context Engineering的典型实践但真正成熟的Context Engineering关注的是完整链路文档怎么切块、结果怎么排序、长文怎么压缩、历史对话何时保留何时摘要、工具返回要不要全暴露、多Agent之间传原文还是结构化字段。最近大火的Agent Skills本质上是Context Engineering的高级形态——渐进式披露不是一开始就把所有能力全给模型看而是只给最少的元信息等真正要触发时再动态加载详细SOP和参考信息。核心洞察上下文优化不是给更多而是按需给、分层给、在正确的时机给。但Context也有边界。就算信息给对了模型也不一定能稳定地执行正确——计划做得好但执行跑偏调了工具但理解错了长链路里已经偏航系统却没发现。Prompt和Context主要解决的还是输入侧的问题——把话说清楚、把信息给对。但Agent一旦开始连续行动就进入了执行侧——谁来监督它、约束它、纠偏它这就是第三次中心迁移的出发点。04 Harness从能说会道到能干活Harness这个词原意是缰绳、马具。放到AI系统里就是在提醒一件朴素的事当模型从回答问题走向执行任务系统不只要能喂信息还要能驾驭整个过程。术语溯源HashiCorp联合创始人、Terraform创造者Mitchell Hashimoto在2026年2月公开提出这个概念。随后OpenAI的Ryan Lopopolo发表《Harness Engineering: Leveraging Codex in an Agent-First World》系统化阐述使其在AI工程圈迅速走红。用一个公式表达Agent Model Harness这是LangChain团队提出的定义。他们在Terminal Bench 2.0上做了一个非常有说服力的实验——全程用同一个模型GPT-5.2-Codex只改Harness通过率从52.8%提升到66.5%排名从30开外杀进Top 5。13.7个百分点的提升模型一行没换。这说明什么在当前阶段很多系统的瓶颈不在模型而在基础设施。但在我看来这个公式需要两处修正——第一用号容易让人觉得Model和Harness可以独立替换实际上两者是联合优化的关系。模型的能力边界直接决定Harness该怎么设计——Anthropic发现升级到Claude Opus 4.5后上下文焦虑大大缓解不再需要Context Reset这种重型机制。模型变强了Harness就可以变简单。不是简单叠加而是协同调优。第二也是更重要的——这个公式少了一个维度人在回路中的动态驾驭。Harness负责的是预设的静态约束规则、架构、验证管道但有些问题不是预设规则能完全覆盖的——架构可能被污染、目标可能漂移、模型可能误报完成了。这些需要人的实时判断和介入。更完整的表述应该是Agent f(Model, Harness, Human-in-the-Loop)Harness修路人握方向盘。两者合在一起才是完整的驾驭Agent。这个驾驭到底有多重有团队分析了某头部AI实验室的Agent项目源码发现一个数据特别震撼在512K行代码的项目中query()主循环16个步骤里只有1个是调用模型其余15个全是验证和修复逻辑。在这个项目里95%的代码全是Harness。换句话说真正让Agent跑稳的不是模型那5%而是外面那95%。05 六大工程支柱Harness到底管什么综合OpenAI、Anthropic、LangChain及国内多家团队的多方实践一个成熟的Harness至少包含六层。这六层不是随便列的有依赖关系——上下文架构地基——模型能看到什么决定了它能不能做对架构约束在地基上建围栏——能看到的里面哪些能做哪些不能做自验证循环围栏上的监控——做了之后怎么知道做对了上下文隔离监控的延伸——多Agent协作时一个出了问题别把别的也带崩熵治理对抗时间——系统跑久了会自然变乱必须有机制收拾可拆卸性对抗变化——模型在迭代Harness不能跟模型绑死第一层上下文架构——让模型在正确的边界内思考研究表明上下文窗口利用率超过40%时模型推理质量显著下滑——因为注意力机制要在越来越长的序列里分配权重信息一多关键信号的信噪比就下降了。所以Harness的第一职责不是塞更多东西而是精准设计进入模型上下文的信息。核心手段渐进式披露AGENTS.md控制在~100行做索引详细内容按需加载。OpenAI早期犯过典型错误——把所有规范塞进一个巨型AGENTS.md结果Agent更糊涂了。当一切都很重要时一切都不重要了。四级压缩管道Snip Compact零API调用最轻量→ Micro Compact缓存编辑→ Context Collapse读时投影→ Auto CompactLLM生成摘要最后手段。逐级降级能轻不重。分层记忆长期记忆知识库、经验文档→ 溢出区会话中断的存档/读档→ 工作记忆运行时对话上下文。三层各司其职。实战提示上下文窗口是稀缺资源。不要一上来就把所有工具说明、参数定义全塞进去。实践证明信息一多注意力反而涣散。Skills的渐进式披露思路——只给元信息触发时再加载——是目前公认的最佳实践。第二层架构约束——用代码强制执行规则这是Harness最核心的哲学转变用硬约束替代软约束。Prompt里写5000字DO NOT——这只是口头嘱咐长链路中容易被遗忘。 Harness的做法是把规则变成代码Linter、CI检查、Schema校验模型绕不过去。关键实践Fail-Closed默认值工具的默认权限全部偏向最保守。is_concurrency_safe默认Falseis_read_only默认False。忘了设置就走最受限路径。遗漏不是漏洞是特性。自定义Lint即修复指引不是简单地报Forbidden import而是告诉AgentLayer 0的包不能依赖Layer 2修复方法是把依赖逻辑上移或者通过参数传入。约束和修复指引绑在同一条反馈链路里。五层纵深防御权限体系Deny Rules不可见→ Tool-level Permissions自检→ Generic Rules规则匹配→ Permission Mode模式判断→ Auto Classifier分类器兜底。层层递进。为什么需要五层因为单层防御一定会被绕过——Deny Rules让模型看不见危险工具但如果有人在Prompt里提到工具名呢Tool-level自检能拦住直接调用但如果场景特殊呢Generic Rules做模式匹配但匹配不到的边缘case呢每一层都是上一层的兜底单一检查点永远不够。实战提示一个实操性很强的建议——故意引入一个违规测试你的Lint能不能抓到。比如加一个跨层import确认能被检测。如果检测不到说明你的Harness是摆设。第三层自验证循环——不让Agent自我感觉良好模型最大的问题之一是自评失真——自己干活自己打分往往偏乐观。尤其是在体验、完整度这类没有标准答案的问题上偏差更明显。Anthropic的解法是GAN风格的架构Planner把1-4句模糊需求扩展成完整的产品规格Generator逐步实现每个Sprint结束后自评再交接给QAEvaluator通过Playwright MCP真实操作页面、点击交互、检查结果——不是抽象的代码审查是带环境的真实验证这背后的工程原则很清晰生成与验收必须分离。只要评估者足够独立系统就能形成有效循环——生成、检查、修复、再检查。在实际的企业运营场景中更进一步的做法是三层递进验证体系层级验证方式能检测什么L1Go结构体反序列化校验语法错误、字段类型不匹配、字段遗漏L2API数据断言数据库写入正确性L3Playwright前端验证用户可见层正确性L1能拦的不拖到L2L2能拦的不拖到L3。每一层只关注自己能验证的事。实战提示一个真实运营活动的案例特别有参考价值——在生成配置阶段就内置了10项自检清单其中5项标注了下一步无法检测必须在此阶段拦截。这个思路叫前置拦截修复代价从10次tool call降到2次。第四层上下文隔离——防级联故障多Agent协作时最大的风险是跨边界信息污染。一个Agent的幻觉顺着共享上下文扩散给其他Agent形成级联故障。三层隔离设计进程级隔离子Agent拥有完全独立的上下文窗口、消息历史和AbortController。子Agent的错误不会传播到父级。通信接口化Agent之间通过SendMessageTool传递结构化消息不共享原始上下文。控制面/数据面分离协调器只有3个工具委派、停止、发消息不能自己动手写代码。Worker有完整工具集。协调器只管决策分配不管执行。有实践总结出一个简洁的判断规则任务类型执行方式一句话能描述且不含和字直接做改typo、加日志需要清单跟踪改了哪些地方委派子Agent需要设计决策和权衡子Agent Git Worktree隔离实战提示中等复杂度以上的任务协调者绝不写代码。协调者只管规划、委派、汇总任务完成后只保留摘要丢弃详细上下文。每个子Agent从干净的上下文开始干完就释放。当然小团队做快速原型时协调者偶尔下场写代码是合理的——但要知道这是在拿上下文污染的风险换速度。第五层熵治理——对抗系统的自然腐烂系统运行久了上下文会混乱记忆会碎片化文档会腐烂。这是系统状态的自然熵增不治理就会越来越糟。熵治理面对两种不同的问题需要不同的机制第一种单次任务太长一轮对话跑不完。Ralph Loop就是解决这个问题的——状态通过文件系统传递非对话上下文Agent每轮读取state.json了解进度每轮Prompt相同Agent不知道自己在循环中。完成条件由Agent自主判断未完成就自动重新注入原始Prompt继续跑。这本质上是把长任务拆成多轮短任务每轮从文件系统恢复状态而不是依赖越来越长的对话历史。第二种同类任务反复执行每次都在重复劳动。轨迹编译解决的是这个问题——当同一类任务被成功执行3次以上且步骤高度一致时编译成确定性脚本如make add-endpoint NAMEfoo脚本失败再回退到Agent模式。棘轮效应系统运行成本越来越低能力越来越强。Ralph Loop治的是单次跑不完轨迹编译治的是每次重新跑——一个解决深度一个解决效率。自动熵治理方面某头部AI实验室的AutoDream系统灵感来自认知科学的记忆巩固理论人类在REM睡眠阶段重播白天经历将短期记忆转化为长期记忆。AutoDream四阶段流程——Orient定位→ Gather收集→ Consolidate整合→ Prune Index修剪索引三重门控24h 5 sessions 文件锁自动在后台整理AI的记忆。实战提示不要指望定期手动清理。多家团队的实践都证明熵治理必须自动化。不管是AutoDream式的后台整合还是轨迹编译式的脚本固化关键是让系统自己维护自己。第六层可拆卸性——别跟模型绑定死模型迭代越来越快今天最强的模型半年后可能就不是了。如果Harness跟特定模型深度耦合换模型就得重写整套系统。三个层面的解耦依赖注入核心引擎的QueryDeps只有4个字段callModel, microcompact, autocompact, uuid。替换模型只需替换callModel一个字段。Skills Markdown技能定义不绑定特定模型或API一个Markdown文件可在不同模型上通用。定义的是流程不是调用方式。MCP标准协议外部工具通过Model Context Protocol接入独立于内部实现可用任何语言编写。模型选择策略也有讲究任务类型推荐模型理由快速执行类改typo、简单重命名轻量模型快、便宜深度推理类复杂重构、架构变更旗舰模型质量优先代码检索类定位相关文件速度型模型速度第一交叉Review时用不同模型避免同一模型的思维盲区。成本约为编码的10-20%。06 一线公司的实战账本光说不练假把式。看账本。LangChain不换模型13.7个百分点的提升这是最能说明Harness价值的案例——全程没有换过模型。LangChain全程使用GPT-5.2-Codex只改造Harness在Terminal Bench 2.0上从52.8%提升到66.5%排名从30开外杀进Top 5。核心是4层中间件LocalContextMiddleware启动时预注入环境信息避免环境发现错误LoopDetectionMiddleware同一文件编辑5次以上强制退一步重新考虑打破死循环ReasoningSandwichMiddleware规划和验证阶段用高推理预算实现阶段用中档。反直觉发现——全程最高推理反而不行超时太多三明治策略最优PreCompletionChecklistMiddleware完成前必须通过验证清单防止过早自批准实战提示LangChain的三明治推理值得记住。很多人以为推理预算越高越好实际上规划阶段确实需要深度思考但实现阶段过度推理反而导致超时和过度设计。在不同阶段分配不同推理预算才是工程化的思路。不过要注意这个结论在有时间约束的场景如基准测试下成立在不受时间限制的离线任务中高推理预算的收益可能更大。OpenAI7个人100万行代码0手写OpenAI的Frontier团队从3人起步后扩到7人用Codex Agent从零构建了一个约百万行代码的内部产品5个月合并约1500个PR零行手写代码耗时约为纯人工的1/10。他们的核心做法人类不写代码只设计环境——拆任务、补能力、建反馈链路AGENTS.md从千页手册瘦身到100行索引加文档园丁Agent自动扫过时文档提PR通过Chrome DevTools Protocol接浏览器、接临时可观测性栈LogQL/PromQL/TraceQL让Agent自己看结果业务域严格按Types → Config → Repo → Service → Runtime → UI分层跨层依赖机械禁止Codex单次运行经常持续6小时以上当Agent出了问题修复方案几乎从来不是要它更努力而是确定环境里缺了什么结构性能力。如果OpenAI的案例让你觉得这是大厂才玩得起的那Anthropic的案例会让你改变想法——他们用3个Agent就做出了一个完整的数字音频工作站。Anthropic3个Agent4小时做出一个完整DAWAnthropic构建了Planner-Generator-Evaluator三Agent架构一句自然语言需求无需人类干预连续运行数小时做出了完整的2D复古游戏制作器含关卡编辑器、像素画编辑器、实体行为系统和浏览器端数字音频工作站含编曲视图、混音器、AI作曲代理。完整的DAW项目运行约4小时成本约$125。他们发现的两个关键问题上下文焦虑上下文快满时模型开始着急收尾。常规做法是Context Compaction——压缩历史上下文继续跑轻量且通常是首选。但Compaction只是变短了某些模型那种负担感并没有真正消失。所以更激进的解法是Context Reset——换一个干净的新Agent把工作交接过去。就像遇到内存泄漏轻度场景清缓存就行重度场景直接重启进程再恢复状态。而Anthropic发现升级到Claude Opus 4.5后Compaction就够了不再需要Reset。模型能力提升后Harness的复杂度也应该相应简化。自评失真模型自己打分偏乐观。解法是把干活和验收分开Evaluator通过Playwright真实操作页面验收。07 多方实践的收敛不是巧合是必然前面讲了很多案例最值得关注的现象是这些团队在不同场景下独立实践最后演化出了高度一致的架构设计。Anthropic用生成/验收分离对抗自评失真OpenAI用Lint即修复对抗规范违反LangChain用死循环检测对抗Agent失控国内团队用前置拦截和轨迹编译对抗熵增——表面看各不相同底层逻辑完全一致上下文稀缺性是底层物理约束——模型能看到的信息是有限的必须精打细算渐进式披露是应对它的最优解——不是一次性全给而是按需给机械化强制执行是长期可持续的必要条件——规则写在Prompt里会遗忘写在Linter里不会08 从0到1怎么落地别一上来就想搭完整体系。多家团队的实践都指向同一条路——最小起步逐步加码。下面的节奏跟前面六层支柱是对应的前两步对应上下文架构和架构约束第三步对应自验证循环后面的逐步覆盖隔离、熵治理、可拆卸性。今天创建一个AGENTS.md控制在~100行以内。写清三件事项目是什么、代码结构是什么、最重要的约束是什么。一个极简模板长这样# 项目名 ## 这是什么 一句话说清楚项目目标和当前状态。 ## 代码结构 src/ ├── types/ # 类型定义Layer 0不依赖任何内部包 ├── config/ # 配置Layer 1 ├── services/ # 业务逻辑Layer 2 ├── api/ # HTTP handlerLayer 3 └── ui/ # 前端Layer 4 ## 硬约束 - 高层可以import低层反过来不行 - 新文件先看放在哪一层再写代码 - 所有API必须有错误处理不允许可选参数默认None然后不检查 ## 常见坑 - macOS下/var是/private/var的符号链接路径处理注意 - config里日期格式用冒号分隔2026:01:01不是短横线 ## 更多细节 详见 docs/architecture.md 和 docs/conventions.md本周加一个依赖方向检查脚本lint-deps。把层级规则定下来哪些包不能import哪些包。故意引入一个违规确认能被检测到。本月搭完整的验证管道build → lint-arch → test → verify。关键思路——在执行前先验证这个动作合不合规如verify_action.py层级违反在写代码前拦截。之后逐步覆盖剩下的三层上下文隔离多Agent任务时加进程级隔离和通信接口化→熵治理对重复任务做轨迹编译对长任务加Ralph Loop→可拆卸性用依赖注入解耦模型用MCP协议解耦工具。当验证管道跑起来之后开启Critic → Refiner反馈循环Agent执行 → 验证抓到问题 → Critic分析模式 → Refiner更新规则 → 下一个Agent受益。让Harness自己进化。关键原则永远不要禁用Lint规则来解决问题——应该改代码而不是改规则3轮修复循环后仍失败停下来交给人——避免上下文爆炸测试不需要每次跑全量——executor支持只跑受影响的包协调者绝不写代码——中等复杂度以上任务人只管决策和验收不是所有场景都需要Harness——一次性脚本、简单问答、单轮生成Prompt就够了。过度工程化也是浪费。当你的任务单轮就能完成不需要搭Harness09 程序员的角色正在迁移前面说了更完整的公式是Agent f(Model, Harness, Human-in-the-Loop)。那Human-in-the-Loop到底在干什么答案很清楚——从执行者到控盘者。Harness负责静态约束修路人负责动态驾驭握方向盘。以前人写代码AI辅助补全。 现在人设计系统架构、约束、验证规则Agent在系统内执行人在关键节点做判断。但这不等于像老板一样甩活就行。角色迁移的具体形态是你从写代码的人变成了设计Agent运行环境的人——写AGENTS.md而不是写业务逻辑写Lint规则而不是做代码审查写验证脚本而不是手动测试。更准确的说法你可以不再亲手写大量代码但你不能放弃技术判断。必须亲自接管的四个时刻架构主线可能被污染时阶段目标开始漂移时运行时日志暴露系统性异常时模型把阶段完成误报成全局完成时环境设计的投入回报远高于Prompt调优。竞争优势不再是Prompt而是Trajectory——这些积累换个模型复制不来。10 一句话总结从Prompt到Context到Harness三次中心迁移的逻辑其实很清晰AI落地的核心挑战正在从让模型看起来更聪明转向让模型在真实世界里稳定地工作。Prompt解决表达Context解决信息Harness解决执行稳定性。三者包含而非替代。真正决定能不能落地、能不能稳定交付的不是模型是Harness。而Harness之外人的动态驾驭同样不可替代。同样的模型Harness的差距可以带来13.7个百分点的提升。在某头部AI实验室的512K行Agent项目里95%的代码全是Harness。这不是理论是账本。回到开头那个比喻——你派新人去见客户告诉他怎么说Prompt、让他备齐资料Context、给他checklist和验收标准Harness。但最终那个在关键时刻判断这个客户不对劲我得亲自上的人还是你。