Agent 变强，往往不是换模型，是换了 Harness

发布时间：2026/7/22 16:50:42

有人拿同一模型换脚手架，编码基准能差出好几倍。也有人不动权重，只改系统提示、加自检钩子，Terminal-Bench 再涨十几个点。我看这些实验，越来越怀疑：线上 Agent 干不干活，常常不是模型够不够聪明，而是外面那层运行系统有没有搭好。

这层东西，现在很多人叫 Agent Harness。2026 年有篇综述 Agent Harness Engineering: A Survey，把它单独拎出来讲，还给了一套七层分类 ETCLOVG。下面按这篇综述的说法，把词掰开。

Prompt、Context、Harness 三层工程范围：从单次调用到闭环运行系统

从单次调用到闭环运行系统

一、Harness 到底指什么

Harness 原意是挽具。套在马上，力往哪传、跑偏怎么勒，都靠它。套到 LLM Agent 上，意思差不多：模型还是那个模型，外面多了一套约束它怎么跑的设施。

具体管什么？上下文怎么进窗口；工具用什么协议发现和调用；代码在哪类沙箱里跑；状态跨步骤怎么存；失败了重试还是停；轨迹能不能看；结果怎么验收；权限、审计、人工审批卡在哪。框架名里有没有「Agent」不重要，这些事有没有人负责才重要。

它和旁边几个词容易糊在一起。

Agent Framework 多半是开发时的抽象：怎么声明 Agent、挂工具、画流程图。Harness 更偏运行时——这一次任务实际被哪些边界箍着跑完。Prompt 和 Context Engineering 管模型这一步看见什么、被怎么吩咐；Harness 还要管看见之后去哪执行、有没有权限、失败怎么回来、谁签字验收。模型能力是智力上限；Harness 决定这份智力在真实环境里能兑现多少，会不会半夜把仓库改崩。

更早有工作把单个 harness 拆成六块：执行环、工具注册表、上下文、状态库、生命周期钩子、评估接口。ETCLOVG 换了切法：按工程界面分层，把可观测性和治理从「钩子的副作用」里拆出来。生产里这两块常常有自己的工具栈，也常归不同团队，硬塞进 lifecycle 钩子里讲不清楚。

二、从写提示，到管上下文，再到管整机

范围是一层包一层，不是三代产品互相踢掉上一代。

写 prompt，管的是单次调用：系统提示、示例、输出格式、推理模板。做 context，管的是信息状态：检索什么、记忆怎么取、历史怎么压、顺序怎么排——窗口当工作内存用，别当无限聊天记录。做 harness，还要把执行环境、工具协议、持久状态、编排、观测、验证、治理接进闭环。模型吐出一句话之后，它会不会变成一次写文件、一次删库？环境结果怎么喂回去？什么时候必须人批？这些都在这层定。

AutoGPT、BabyAGI 那阵子的老毛病——跑飞、上下文爆、状态丢、副作用没人看——当时不少人怪提示词。现在回头看，更像基础设施没跟上。

ETCLOVG 七层：结构核心 E/T/C/L 与控制平面 O/V/G

结构核心 E/T/C/L 与控制平面 O/V/G

三、ETCLOVG：一张表够用了

综述把 harness 切成七层。前四层是结构核心，后三层更像控制平面。表能扫一眼就行，不必背缩写。

层	名字	它在问
E	Execution	代码跑在哪？沙箱边界是什么？
T	Tooling	外部能力怎么描述、发现、调用？
C	Context	短会话、跨会话状态、长期记忆谁管？
L	Lifecycle	单环、多 Agent、Issue 到 PR 怎么编排？
O	Observability	轨迹、成本、故障看得见、分得清吗？
V	Verification	跑前检查、跑中采集、跑后评判和回归？
G	Governance	权限、策略、审计、人工兜底放哪？

我自己记这张表，靠的是出事时会不会卡住。沙箱是容器还是本机裸跑？工具菜单是不是大到选不过来？一百轮后它脑子里的任务状态还对不对？子 Agent 回来是带回产物和未决问题，还是一段没法恢复的闲聊？trace 里分得清模型蠢、工具说明骗人，还是环境缺包？权限是写明的，还是嘴上说「别乱来」？

综述扫了 170 多个开源项目，开源侧更密的是执行、工具、编排、验证；可观测和治理更薄，多半在商业平台或内部工程文章里。Demo 能跑、上线就慌，缺的常常是后两块。

四、难的是层和层会打架

七层背下来没用。综述后半截更刺的是跨层矛盾。

沙箱越强越安全，也更慢更贵；上下文越厚越连贯，token 烧得越凶；评估越深越好查因，迭代越拖。线上谈「质量」，其实是在问：哪些风险值得付这套贵控制。

工具菜单开大，能干的事变多，选错和提示注入面也变大；记忆留得久，过期和隐私麻烦跟着来；沙箱放得松，自主性上来，一次误操作的杀伤半径也上来。这些不是上线后补的安全附录，设计阶段就得拍板。

还有耦合。改沙箱会改评测分数；工具描述会挤占上下文；trace 里没有身份和权限粒度，就很难当治理证据；评测如果奖励某种重试，编排就会养成对应坏习惯。只改提示词、只换记忆库，局部好看、整体变差的情况很常见。测 harness，得按系统变更来测。

「换更强模型」有时像开挂，有时几乎没感觉，多半因为瓶颈不在同一层。沙箱保真度、工具契约、状态漂移这些控制问题，加智力解决不了；推理真不够时，换模型才对路。

五、两个场景，比清单好用

场景一：编码 Agent 通宵改仓库。先问三件事：它能不能rm -rf、能不能推保护分支、写文件是在沙箱还是你本机。这三条没钉死，模型再强我也当定时炸弹。再看工具和上下文：是不是把半个 npm 生态都挂成工具，搜索结果原样灌进窗口？长任务里每隔几十轮，它还记不记得「别动支付模块」这种约束——不记得，多半不是窗口太小，是状态在漂。子任务派出去再收回来，如果只剩一段聊天摘要，第二天你基本没法接手。

场景二：演示很稳，一上真实流量就花。看板里 span 花花绿绿，却说不清这次失败该怪模型、工具契约，还是评测环境缺依赖。更糟的是：生产异常看过就算了，没有落成回归用例，下周同一类锅再来一遍。这种时候别急着换模型。先把「看得见」和「判得对」接上——O 和 V 不通，你只是在看热闹。

选型或自研时，我通常按这个顺序抠：先执行和治理，再工具与上下文预算，再交接与编排，最后才把观测和回归闭环。模型变强了记得做减法。Anthropic 提过，对更强模型，某些上下文重置反而变成多余成本；脚手架证伪了就拆，别只增不减。