夜雨聆风导语
最近读到一篇论文，标题很学术——《Agent Harness Engineering: A Survey》。放在平时我可能扫一眼摘要就关掉了。
但这次我读完了一整遍。因为它回答了一个我一直没想清楚的问题。
你有没有过这种经历：你跟一个 AI 编程助手说「帮我重构这个模块」，它开始工作了。前五分钟一切顺利——代码生成、测试通过、提交。然后第六分钟，它突然开始改一个跟你任务完全无关的文件，或者陷入了一个死循环，或者用了一个已经被废弃的 API。
你看着屏幕想：明明模型能力够了，为什么还是翻车？
这篇论文给出的答案是：因为你只关注了「司机」够不够聪明，没关注「安全带」「刹车」「仪表盘」装没装好。
在 AI Agent 的世界里，模型是司机。而包裹在模型外面的那一整套基础设施——工具调用、上下文管理、执行追踪、错误恢复——叫 Harness（挽具/安全带）。论文的核心判断只有一句话：
The harness is becoming the binding constraint.
Agent 执行框架成了卡脖子的关键短板。
什么是 Harness？一个帮你理解的比喻
想象你在教一个天才小孩开车。
这个小孩智商 200，能背整本交通法规，能在模拟器上跑出完美成绩。但当你真的把他放在驾驶座上——
他不知道怎么调后视镜（Context） 他不会判断什么时候该踩刹车（Lifecycle） 他开错路了不知道回头（Error Recovery） 你坐在副驾上完全看不到他在干什么（Observability） 他甚至可能把车开进河里而你拦不住（Governance）
这个天才小孩就是你的大模型。Harness 就是车上除了发动机之外的一切。
论文把这「一切」拆成了七个层次，给了它一个缩写：ETCLOVG。
你不需要记住全称。但你值得理解每一层在干什么——因为这就是你的 AI Agent 每天在翻车的地方。
七层拆解：你的 Agent 每天都在哪里摔跤
E · Execution（执行层）
这是最底层。Agent 怎么「跑」起来——是单步调用还是循环？是有状态还是无状态？是同步还是异步？
翻车现场：一个 Agent 循环跑了 200 轮还没停下来，因为你没设最大步数。
T · Tooling（工具层）
Agent 能调什么工具——搜索 API、数据库、文件系统、浏览器。以及工具的注册、发现、调用协议。
翻车现场：Agent 写了一个 SQL 查询，但数据库表名写错了。因为你没在工具描述里写清楚 schema。
C · Context（上下文层）
Agent 能看到什么信息——历史对话、中间步骤、工具返回结果。以及如何管理这些信息的生命周期。
翻车现场：Agent 处理到第 30 步时忘了前 5 步做了什么。因为你的上下文窗口装不下这么长的轨迹，而你没做压缩或摘要。
L · Lifecycle（生命周期层）
Agent 从启动到结束的完整状态机——什么时候开始、什么时候暂停、什么时候终止。
翻车现场：Agent 遇到一个错误后没有降级策略，直接 crash 了整个流程。因为它不知道「出错了应该怎么优雅退出」。
O · Observability（可观测层）
你能看到 Agent 在干什么——日志、追踪、成本监控、性能指标。
翻车现场：Agent 跑了两个小时，你不知道它在哪一步、花了多少钱、为什么停住了。因为你没有 tracing。
V · Verification（验证层）
怎么判断 Agent 做对了还是做错了——基准测试、回归检查、人工评审、自动评估。
翻车现场：Agent 说「任务已完成」，但产物实际上有一半是错的。你没有验证循环，只是信了它的话。
最后这层最容易被忽略——因为它不出事的时候你感觉不到它的存在。一旦出事，就是大事。
G · Governance（治理层）
安全边界、权限控制、审计追踪、合规约束。
翻车现场：Agent 在你的生产数据库上跑了 DELETE 语句。因为你没给它设只读权限。
我的三个心得
读完这篇论文，我有三个感触想分享。
心得一：大多数人（包括我）在 Agent 翻车时骂错了对象
以前 Agent 出问题，我的第一反应永远是「这模型还是不够强」。
读完这篇文章我意识到，很多翻车跟模型能力没关系。是你的 harness 少了某个关键层。
你没设最大步数，Agent 跑到天荒地老——这是 Execution 层的问题，不是模型的问题。
你没写清楚工具的参数约束，Agent 传了一个非法值——这是 Tooling 层的问题，不是模型的问题。
你没加验证步骤，Agent 产出了一个幻觉满满的结果——这是 Verification 层的问题，不是模型的问题。
模型能力在涨，但 harness 的复杂度也在涨。 以前一个 ReAct 循环就够用了。现在要管理几百个并行子 Agent、几十个工具、上百万 token 的上下文——harness 不进化，模型再强也白搭。
心得二：ETCLOVG 是一个诊断框架，不是一个技术栈
这是我读这篇论文最受益的地方。
它不是让你去买七个工具。而是给你一张检查表。下次你的 Agent 翻车了，你不需要凭直觉猜原因。你只需要按 E→T→C→L→O→V→G 走一遍：
它执行对了吗？→ 检查 E 它用对工具了吗？→ 检查 T 它记得上下文吗？→ 检查 C 它知道什么时候停吗？→ 检查 L 你能看到它在干什么吗？→ 检查 O 它的结果被验证了吗？→ 检查 V 它有越权的可能吗？→ 检查 G
七个问题问完，你大概率已经定位到根因了。这比「再换个更贵的模型试试」有效得多。
这七个问题，我从去年到今天问了不下几十次。每次问完，都有一个意外的发现——翻车的根因，十次里有七八次不在模型，在 harness。
这个发现最大的价值不是帮你省了切换模型的成本。而是帮你从一种被动的「受害者心态」切换到主动的「诊断师心态」。你不是在等下一个更聪明的模型来救你。你手里已经有了一张能定位问题的地图。
心得三：「Agent 的瓶颈在 harness」这句话会越来越值钱
论文里有一段历史回顾，我觉得值得单独拿出来：
2022-2023 年的 ReAct 时代：一个 while 循环 + 一段 prompt + 一个小工具调度表。暴露的失败——执行失控、上下文爆炸、状态丢失——被逐渐识别为基础设施问题而非 prompt 问题。
2023-2024 年的工具集成和多 Agent 协调时代：出现了标准化的呼声。
到 2025-2026 年，「harness engineering」开始被作为一个独立学科命名。
注意最后一句。当一件事被独立命名了，说明它已经足够复杂、足够重要、也足够痛了。
这跟 DevOps 的历史一模一样。十年前没人叫「DevOps 工程师」。现在它是年薪百万的岗位。
我猜「Harness 工程师」也会走同样的路。因为模型越来越强，越来越便宜——但把模型变成可用的产品这件事，不会被模型自己搞定。
结语
这篇文章不是教你搭一个 Agent 的教程。它是一个帮你弄清楚「Agent 为什么总是差一口气」的心智模型。
下次你的 AI 助手又翻车了，别急着说「模型不行」。打开 ETCLOVG 这张检查表，你可能会发现——不是司机不行，是安全带没系好。
如果你现在就有一个正在跑的 Agent，按这个顺序先查三层：
1. 先查 E（执行）——它有没有设最大步数？超时策略是什么？这是 90% 的「跑飞了」问题的根因。
2. 再查 O（可观测）——你能不能在 30 秒内搞清楚 Agent 当前在第几步？如果不能，先补 tracing。
3. 最后查 V（验证）——Agent 说「完成了」的时候，你有没有一个不依赖 Agent 自己的方式来验证它真的完成了？
这三层补好，你的 Agent 已经比绝大多数人的 Agent 靠谱了。
以上，既然看到这里了，如果觉得文章对你有帮助，记得点.赞.转.发.收.藏喔！如果想第一时间收到推送，也可以给我个关注。
