夜雨聆风最近，一篇来自卡内基梅隆大学、耶鲁大学、霍普金斯大学等九所院校的联合论文在AI圈引发热议。
论文标题很直白：《Agent Harness Engineering: A Survey》。
核心观点只有一个——
真正决定AI Agent可靠性的，不是模型本身，而是裹在模型外面的那层"基础设施"。
这层基础设施，被论文正式命名为 "Agent Execution Harness"（Agent执行挽具），简称 Harness。
01 我们都在犯同一个错
过去几年，整个行业都在追问一个相同的问题：
"这个模型够不够聪明？"
于是我们追逐每一个新模型，问Claude和GPT谁更强，看Llama又出了什么新版本，比来比去争Leaderboard排名。
但这篇论文告诉我们：这个方向可能走偏了。
论文给出了三个核心主张——
主张一：Harness是一个独立系统层
现实生产环境中的可靠性，更多取决于执行控制、反馈循环、治理和运营设计——而不仅仅是模型能力本身。
这意味着什么？你花大价钱换了最新模型，但如果 Harness 写得烂，Agent 执行到第50步就开始"跑偏"、上下文爆炸、执行失控。换了模型根本解决不了。
主张二：从Prompt到Context再到Harness，工程重心在迁移
论文梳理了2022年到2026年AI Agent工程的三个阶段：
| 阶段 | 时间 | 核心问题 |
|---|---|---|
| Prompt工程 | 2022–2024 | 输入什么文本？ |
| Context工程 | 2025 | 每一步该让模型看到什么？ |
| Harness工程 | 2026– | 如何管理完整的基础设施包装？ |
每一个新阶段都不是替代上一阶段，而是覆盖了更完整的工程问题域。
主张三：开源生态暴露了大量Gap
论文将170多个开源Agent Harness项目映射到自己的分类体系里，发现：Execution（执行环境）、Tooling（工具接口）、Lifecycle（生命周期编排）、Verification（验证评估） 这四层开源项目最密集；而 Observability（可观测性）和Governance（治理安全） 在开源中严重不足，更多存在于商业平台内部。
这说明：大家在造"轮子"，但在运维和治理上还没准备好。
02 ETCLOVG：给Harness的七层解剖刀
论文最硬核的贡献，是提出了一个叫 ETCLOVG 的七层分类体系，把Agent Harness拆成了七个各司其职的结构层。
你可以把这个结构理解为——
模型是CPU，Harness是操作系统。 操作系统 curates context、处理引导序列、提供标准驱动（工具调用）。而Agent本身，是跑在操作系统上的应用程序。
七层分别是：
E – Execution（执行环境 & 沙箱）
Agent代码在哪跑？跑的时候有什么边界约束？
这层包含托管沙箱、微VM、代码专用运行时、浏览器沙箱、操作系统权限模型等。打个比方：你的代码能不能跑在Docker里、有没有网络权限、能不能写文件——都归这层管。
T – Tooling（工具接口 & 协议）
外部能力怎么描述、发现和调用？
这里包括协议标准（MCP、A2A）、工具描述与选择、工具增强训练、会话管理。AutoGPT时代那套简单的"while循环+工具分发表"，就属于这层没做好的后果。
C – Context & Memory（上下文 & 记忆管理）
模型在每一步能看到什么信息？
包括短期、会话级和持久化的记忆管理，以及上下文压缩、上下文漂移 mitigation 等。Context窗口是"RAM"，用着用着就满了——这层解决的是如何管理这个有限资源。
L – Lifecycle & Orchestration（生命周期 & 编排）
控制流如何组织？从单Agent内部循环到多Agent模式，再到完整的"issue→PR"任务流水线——这层都有涉及。
O – Observability & Operations（可观测性 & 运营）
Tracing、成本追踪、故障信号捕获。OpenAI、Anthropic、LangChain在生产环境里积累的运营经验，大量来自这层。
V – Verification & Evaluation（验证 & 评估）
把任务和轨迹变成可评分、可归因、可回归测试的数据。SWE-bench、WebArena、GAIA 这些Benchmark，本质上都在干这事——给Harness的输出打分。
G – Governance & Security（治理 & 安全）
模型级、系统级、组织级的权限模型、生命周期钩子、组件加固、声明式章程和审计基础设施。这一层在开源生态里最薄，却是生产部署里最不能忽视的。
03 一个改变认知的比喻
论文里有一个比喻，我看完之后印象很深——
作者把Harness比作操作系统：
模型 = CPU：提供原始算力 Context窗口 = RAM：有限、易失的工作内存 Harness = 操作系统：管理上下文、处理引导、提供标准驱动 Agent = 应用程序：跑在系统上的具体业务逻辑
CPU再强，如果操作系统写得烂，整机性能照样拉胯。同样地，模型再强，如果 Harness 没做好，Agent 执行长任务时的可靠性就是会崩。
这个比喻也解释了为什么AutoGPT在2023年那么"耀眼"却最终暴露了大量工程问题——不是模型不够强，而是 Harness 没有为长期运行设计。
04 一个令人不安的实验
这篇论文还引用了一些实验证据，其中最扎眼的结论是：
"Improving 15 LLMs at Coding in One Afternoon. Only the Harness Changed."
同一个任务，只改Harness，不换模型，15个LLM在Coding任务上的表现可以在一下午内大幅提升。
这和Rich Sutton那篇著名的"The Bitter Lesson"呼应了——
通用方法利用算力总会打败手工人类知识。 现在这套教训正在Agent开发领域重演：复杂的手写流程设计，正在被简单而强大的Harness配置所替代。
Manus在六个月内重构了五次Harness；Vercel砍掉了80%的Agent工具，结果步数更少、token更省、响应更快——这些案例都在指向同一个事实：
你的竞争优势不再是对 prompt 的精心设计，而是 Harness 所捕获的轨迹数据（trajectories）。
每一条Agent在第100步失败、跑偏、违反指令的轨迹，都是下一代模型的训练语料。
05 普通开发者现在该怎么办
这篇论文对普通开发者的实操意义，我总结了三条——
第一，不要急着搭"复杂控制流"
论文的核心忠告是：让模型做计划，提供稳健的原子工具，加上 guardrails、retry 和 verification 就够了。
你不需要从零写一个复杂的执行引擎。把控制流写轻，让Harness去处理那些你本来要手写的东西。
第二，"Build to Delete"（建的时候就想着要删）
论文说：2024年需要复杂手写流水线才能实现的能力，到2026年可能就是一条 context-window prompt 的事。
所以架构要模块化，时刻准备把"昨天觉得很聪明的逻辑"整个拔掉。换模型的时候，你的Harness得能接得住。
第三，可观测性要提前布局
论文指出，开源世界里 Observability 和 Governance 是两个最大Gap。如果你在做 Agent 平台或长期运营类产品，现在投入可观测性建设，不是可选项，而是竞争优势。
结语
这篇论文的核心洞察用一句话就能说清楚——
AI Agent的生产可靠性，更多取决于Harness的质量，而不是模型的能力。
2022年我们以为只要prompt写得好就能用好AI；2025年我们发现context管理才是关键；2026年了，是时候正视Harness工程这个被长期忽视的系统层了。
它不是框架，不是工具，是一整套把模型变成可用系统的工程能力。
谁先重视它，谁就在这轮竞争中赢得先手。
论文主页：https://picrew.github.io/LLM-Harness[1]
引用链接
[1]https://picrew.github.io/LLM-Harness
