Harness Engineering 深度解构:从三代演进到 L5 成熟度模型
本文基于对 Anthropic(3 篇)、OpenAI Codex 团队、Vercel、LangChain、Stripe、Manus、arXiv/OpenDev、Redis、METR 等 14 个来源的深度调研,结合我们运行 AI 信息系统 30 天积累的 8 份事故报告撰写。完整调研报告 见 GitHub。
三代演进:从 Prompt 到 Harness
2026 年的 AI 工程正在经历第三次范式转移。理解这三代演进是理解 Harness 的前提。
| 代际 | 时期 | 核心关注 | 比喻 |
|---|---|---|---|
| Prompt Engineering | 2022-2024 | 完美的单次指令 | 写完美的邮件 |
| Context Engineering | 2025 | 动态构建的上下文窗口 | 给邮件附上所有相关文件 |
| Harness Engineering | 2026 | Agent 的运行环境和治理体系 | 设计整个办公室 |
Mitchell Hashimoto(Terraform 创始人)给出了 Harness 最简洁的定义:
“每次你发现 Agent 犯了错误,你花时间设计一个方案,让它永远不可能再犯同样的错误。”
Philschmid 用操作系统做比喻:Model = CPU,Context Window = RAM,Harness = 操作系统,Agent = 应用程序。
而 OpenAI Codex 团队在用 Agent 从零生成百万行代码后,总结为一句话:“Agents aren’t hard; the Harness is hard.”
驱动这次转变的底层数据是:LangChain 只改变 Harness(模型不变),其 coding agent 在 Terminal Bench 2.0 上从第 30 名跳到了第 5 名(52.8% → 66.5%)。Manus 在六个月内重构了五次 Harness,每次都显著提升了 Agent 表现。Harness 的杠杆比模型大。
六大支柱
综合所有来源,我们梳理出 Harness Engineering 的六大支柱。每个支柱都有行业验证和我们自己的事故佐证。
支柱一:Generator 和 Evaluator 必须分离
Anthropic 2026 年 3 月论文的核心发现:
“Agent 被要求评估自己的工作时,倾向于自信地赞美它——即使质量明显平庸。”
这是结构性问题,不是偶发现象。Anthropic 的解法是 GAN 式架构:Generator 生成、Evaluator 评分、反馈循环驱动迭代。Evaluator 使用 Playwright 实际操作页面(不是看代码),像真实用户一样验证。
关键设计细节:Evaluator 被调教为怀疑论者——不是”看起来不错”,而是”证明给我看没有问题”。Anthropic 发现,让独立 Evaluator 变严格,比让 Generator 自我批评要容易得多。
LangChain 的做法更具可操作性。他们加了 PreCompletionChecklistMiddleware——在 Agent 退出前拦截,强制它对照原始需求做一遍验证。他们发现最常见的失败是:Agent 写了方案 → 重读自己的代码 → 说”没问题” → 停止。它根本没有测试。
我们的事故验证: AI 专题 v2 项目中,subagent 报告”12 个项目完成,JSON 合法,构建通过”,主 Agent 确认”没问题”。上线后 Owner 说”数据全是错的”——混入了量化交易项目。主 Agent 作为检查者太宽容了。
支柱二:增量工作 + 结构化交接
Anthropic 让 Initializer Agent 生成 JSON 格式的 Feature List(200+ 功能点),每个标记 passes: false。用 JSON 而不是 Markdown,因为模型不太会篡改 JSON 结构。用强措辞:“It is unacceptable to remove or edit tests.”
每次只做一个功能,做完 git commit,代码库必须处于”可以合并到主分支”的状态。
OpenAI Codex 团队加了更硬的规则:
- 仓库是 Agent 的唯一真理源——不存在聊天记录或人脑里的知识
- 架构约束用 Linter 强制执行,不用 Prompt 请求
- 如果一个 PR 需要大量人工干预,不是 Agent 的问题——是 Harness 的问题
支柱三:Context Reset 优于 Compaction
Anthropic 发现 Sonnet 4.5 有”上下文焦虑”——感觉 context 快满时提前结束工作。Context Reset(完全清空上下文,用文件传递状态)比 Compaction(在原有对话中总结压缩)效果更好。
但 Opus 4.5 “largely removed that behavior on its own”——模型层面的改进也在消除这个问题。
arXiv 上的 OpenDev 论文提出了更精细的方案:
- Adaptive Compaction:渐进式减少旧观察的详细程度(不是一刀切)
- Automated Memory System:跨 session 积累项目知识
- Event-driven System Reminders:对抗”指令淡出”(长时间运行后模型忘记初始指令)
支柱四:确定性工作从 LLM 剥离
Vercel 的生产数据是最有说服力的证据。
Vercel 内部的 text-to-SQL Agent(d0)从 15 个专用工具砍到 1 个(bash 执行)。结果:
| 指标 | v1 (15+ tools) | v2 (1 tool) | 变化 |
|---|---|---|---|
| 执行时间 | 274.8s | 77.4s | 3.5x 快 |
| 成功率 | 80% | 100% | +20% |
| Token 消耗 | ~102K | ~61K | -37% |
| 步骤数 | ~12 | ~7 | -42% |
v1 最差情况:724 秒,100 步,145K token,失败。v2 同一查询:141 秒,19 步,67K token,成功。
Vercel 的核心教训:
“Don’t fight gravity. Grep is 50 years old and still does exactly what we need. We were building custom tools for what Unix already solves.”
“We were constraining reasoning because we didn’t trust the model to reason. With Opus 4.5, that constraint became a liability.”
“Build for the model you’ll have in six months, not the one you have today.”
Philschmid 引用了更多数据:Manus 6 个月重构 5 次 Harness 来移除僵化假设。LangChain 一年内三次重构研究 Agent。每一代新模型都会让你之前写的”聪明逻辑”变得多余。
支柱五:Build to Delete
Philschmid 的三条规则:
- Start Simple — 不要建庞大的控制流。提供健壮的原子工具,让模型做计划。
- Build to Delete — 架构模块化。新模型会替代你的逻辑,你必须准备好删代码。
- The Harness is the Dataset — 竞争优势不是 prompt,而是 Harness 捕获的轨迹。Agent 每次失败都是训练下一代的数据。
支柱六:Multi-Agent 编排
| 架构 | Agent 角色 | 来源 |
|---|---|---|
| Planner + Generator + Evaluator | 规划、执行、质检 | Anthropic |
| Planning Agent + Execution Agent | 规划、执行 | OpenDev |
| Conductor + Workers | 编排、并行执行 | AgenticEngineer |
| Narrowly Scoped Tasks | 极小任务、大量并行 | Stripe Minions(每周 1000+ PR) |
超越六大支柱:前沿架构
协议栈:MCP + ACP + A2A
2026 年的 Agent 协议已形成三层栈:
┌──────────────────────────┐
│ A2A (Agent-to-Agent) │ Agent 之间通信(Google)
├──────────────────────────┤
│ ACP (Agent Connect) │ Agent 连接管理(Anthropic)
├──────────────────────────┤
│ MCP (Model Context) │ Agent 连接工具(82K+ stars)
└──────────────────────────┘
MCP 解决 Agent→Tool,A2A 解决 Agent→Agent。两者互补不冲突。
Memory 三层架构
从认知科学的 Tulving 分类(1972)直接移植到 Agent 设计:
| 类型 | 人类等价 | Agent 实现 |
|---|---|---|
| Short-term | 工作记忆 | Context window + session state |
| Episodic | 特定事件记忆 | 带时间戳的事件日志 |
| Semantic | 知识/事实 | 知识图谱 + 向量数据库 |
| Procedural | 怎么做某事 | Skills + tools + 学到的 workflow |
一个关键发现:纯文件系统的 memory 在基准测试中得分 74%,击败了大多数专用向量数据库 memory 库(Letta 的测试)。简单不等于差。
“Reflect” 模式(session 结束时的学习循环)正在成为标准实践——Agent 在每次工作结束后反思什么做对了、什么做错了,写入长期记忆。
Self-Healing 四层体系
生产环境中的自愈架构:
| 层 | 功能 | 效果 |
|---|---|---|
| Health Monitoring | 质量评分 + 漂移检测 | 实时发现问题 |
| Failure Detection | Pre-flight check(每个动作前检查) | 在失败级联前拦截 |
| Automatic Recovery | 重试 → 简化任务 → 升级给人 | 85% 自动恢复 |
| Learning from Failures | 每次失败记录 + 反馈循环 | 失败率 23%→3% |
Self-Improving Agents:最前沿
METR 的数据:AI Agent 能自主完成的任务时长每 4 个月翻一倍。当前 50% 可靠时限约 50 分钟。
HyperAgents(Meta+UBC+Oxford+NYU, 2026.03)跨越了元认知门槛:Agent 不只改善任务行为,还改善自己的改善过程。在全新领域击败了人类手工设计的系统。
但有一个硬约束:自我改进只在结果可客观验证的领域有效(代码、数学)。在营销文案、战略规划等主观领域不可靠——因为没有清晰的”更好”信号。
L0-L5 成熟度模型
综合所有调研,我们提出一个 Harness 成熟度模型:
| 等级 | 名称 | 关键能力 | 代表 |
|---|---|---|---|
| L0 | 裸模型 | 单次 prompt→response | ChatGPT 直接用 |
| L1 | 基础 Harness | System prompt + 工具集 + 基本 memory | 大多数 AI 应用 |
| L2 | 结构化 Harness | Context Reset + 增量工作 + 文件交接 + 确定性剥离 | 早期生产系统 |
| L3 | 验证式 Harness | Self-verify loop + Evaluator 分离 + Loop detection + Observability | Anthropic / LangChain |
| L4 | 自愈式 Harness | Health monitoring + Auto recovery + Trace analysis + Sandbox 隔离 | Stripe / Vercel |
| L5 | 自进化 Harness | 元认知 + Agent 改进 Harness 本身 + Harness as Dataset | HyperAgents(研究阶段) |
大多数团队在 L1-L2。Anthropic 和 LangChain 在 L3。Stripe 和 Vercel 的部分系统达到 L4。L5 目前还在研究阶段。
从 L2 到 L3 的关键跳跃
L2 到 L3 的跳跃需要三个核心能力:
- Self-Verify Loop:Agent 退出前必须对照原始需求做验证(不是对照自己的代码)
- 独立 Evaluator:做事的 Agent 和评价的 Agent 分离
- Observability:不是监控系统指标,而是理解 Agent 决策了什么、为什么这样决策
从 L3 到 L4 的关键跳跃
L3 到 L4 需要:
- Pre-flight Check:每个重要动作前检查前置条件
- Automatic Recovery:失败后自动重试 → 简化 → 升级
- Sandbox 隔离:Agent 代码执行在隔离环境中(E2B/Daytona 用 Firecracker microVM)
- Trace Analysis:自动化分析失败轨迹,类似 Boosting
给从业者的行动建议
L1 → L2(大多数团队的当务之急)
- 让 Agent 记住上一次做了什么。 一个 200 token 的状态文件(
TASK-STATUS.md)的 ROI 比任何优化都高。 - 确定性工作立刻脚本化。 任何你能写成
if-then的操作都不该放在 Prompt 里。 - 每个 session 只做一件事,做完提交。
L2 → L3(追求可靠性的团队)
- 引入独立 Evaluator。 一个被调教为”默认怀疑”的 Agent 就够了。
- 加 Self-Verify Loop。 Agent 退出前强制对照需求验证。LangChain 的
PreCompletionChecklistMiddleware是好的参考。 - 部署 Observability。 LangSmith、Arize Phoenix 或自建 tracing。
L3 → L4(追求生产级稳定的团队)
- 加 Pre-flight Check 和 Auto Recovery。
- 用 Sandbox 隔离代码执行。 E2B 或 Daytona 的 Firecracker microVM。
- 自动化 Trace Analysis。 LangChain 的 Trace Analyzer Skill 是可参考的模式。
通用原则
- Build to Delete。 你今天写的逻辑,下个月的新模型可能一句 prompt 就替代了。
- Build for the model you’ll have in 6 months。 Vercel 的教训。
- The Harness is the Dataset。 每次 Agent 的轨迹、每次失败、每次人工修正,都是未来优化的原材料。
结语
Harness Engineering 不是一个框架或产品,而是一种思维转变:从”怎么让模型更聪明”到”怎么让聪明的模型可靠地工作”。
模型会继续进步——Anthropic 已经发现 Opus 4.5 减少了上下文焦虑,Vercel 发现约束反而成了瓶颈。今天需要复杂 Harness 解决的问题,明天可能被模型原生能力消除。
但 Harness 的核心价值——可靠性、可追溯性、可迭代性——不会过时。用 OpenAI Codex 团队的话结束:
“如果一个 PR 需要大量人工干预,不是 Agent 的问题——是 Harness 的问题。”
把责任从 Agent 移到 Harness。这就是 Harness Engineering 的精髓。
参考文献:
- Anthropic. Harness design for long-running application development. Mar 2026.
- Anthropic. Effective harnesses for long-running agents. Nov 2025.
- Anthropic. Effective context engineering for AI agents. Sep 2025.
- Vercel. We removed 80% of our agent’s tools. Dec 2025.
- LangChain. Improving Deep Agents with harness engineering. Feb 2026.
- Philschmid. The importance of Agent Harness in 2026. Jan 2026.
- Epsilla. The Third Evolution: Why Harness Engineering Replaced Prompting. Mar 2026.
- Bui, Nghi. Building Effective AI Coding Agents for the Terminal. arXiv, Mar 2026.
- AgenticEngineer. Top 2% Agentic Engineering Roadmap. 2026.
- Redis. AI Agent Architecture: Build Systems That Work in 2026. 2026.
- renschni. Manus AI Agent Technical Analysis. 2026.
- spikelab. Memory Systems for AI Agents. Feb 2026.
- o-mega. Self-Improving AI Agents: The 2026 Guide. Mar 2026.
- METR. Measuring AI ability to complete long tasks. 2025-2026.
加入讨论
分享您的想法,与其他读者交流。评论通过 GitHub 管理,确保安全可靠。
请遵守我们的 评论政策,共同维护良好的讨论环境