agent 的账单，
是编排层定的
不是模型定的
优化 agent 成本，多数人盯着换模型、等 per-token 降价。Writer 的一个对照实验把这条路堵死了：锁死任务和模型不动，只换 harness（编排层），成本降 33% 到 61%。而在基线下从最贵的模型换到最便宜的，也只省 36%。
花钱的是编排层，不是那次模型调用
一个 agentic 任务从来不是一次模型调用。论文开篇的例子是「把这两份合同对一遍、起草一份修订备忘录」，这样一句请求会展开成十几个回合：系统提示、工具定义、检索结果、中间推理、工具输出。而在朴素实现里，上面这些每一个后续回合都要整份重放一遍。
任务的 token 账单，是这个循环的总和；而循环由模型周围的软件决定，不由模型决定。论文把这层软件叫做 harness（编排层）：它决定什么进入上下文窗口、哪些工具可见、什么时候检索、什么时候重试、什么时候委派、什么时候停下。
论文观察到，面对 agent 能力要求上升，行业的默认反应是花更多 token：推理模型每个答案输出几千个思考 token，agent 框架把对话历史按回合数二次方地重放，工具生态把每个定义塞进每次调用。论文给这条发展轨迹起了个名字，token maxing（用 token 买能力）。
"buying capability with tokens — longer reasoning traces, more agent turns, wider tool payloads, larger replayed contexts — so that tokens per task grow faster than task value."
用更长的推理链、更多的 agent 回合、更宽的工具负载、更大的重放上下文来买能力，结果是每任务的 token 涨得比任务价值还快。
论文指出 per-token 降价只是遮住这个问题、没有治好它，总花费照涨。它把这称为一个典型的 Jevons 动态（textbook Jevons dynamic，资源利用效率提升反而拉高总消费量）：单价一降，团队就把 token 当成边际近乎免费，把用量放大到匹配。论文的判断是，真正能对付 token maxing 的杠杆是 harness，因为每任务输入 token 的五项里有四项加上重试，全是代码拼的、不是模型定的。
锁死任务和模型，只换 harness 这一个变量
分层架构给了论文一个自然实验：把任务和模型都锁定，只换编排层。团队在六个基础模型上跑同一批 22 个锁定的评测任务，对比两套编排层：一套是常规生产 agent loop（作为基线），一套是 Writer Agent Harness。每个任务、提示、模型、评委、价格表完全一致，唯一变量是编排代码。
六个模型横跨五家厂商、三个重量级：Claude Sonnet 4.6、Gemini 3.1、Gemini Flash 3.5、Qwen 3.6、GLM 5.1、Palmyra X6。论文强调这个跨度是刻意的：核心主张是关于模型之上那一层，所以必须跨重量级和厂商测，不能只押一个旗舰。
| 维度 | 基线 | Harness | 变化 | 论文读法 |
|---|---|---|---|---|
| 质量（任务完成度） | 0.78 | 0.81 | +0.03 | n=22 下算打平 |
| 每任务成本 | $0.21 | $0.12 | −41% | 决定性 |
| 每任务时延（中位） | 48 秒 | 27 秒 | −44% | 决定性（快 1.8 倍） |
| 每任务 token | 14.2k | 8.8k | −38% | 决定性 |
| 每美元质量 η$ | 3.71 | 6.75 | +82% | 推导值 |
| 每百万 token 完成数 | 54.9 | 92.0 | +68% | 推导值 |
论文对两类结果的处理态度不同：在 n=22 这个样本量下，质量差异只是方向性的、不具统计显著性，所以 +0.03 报为「打平」而非「提升」；而成本、token、时延的差异很大，在全部 22 个提示和全部六个模型上符号一致，因此在这个样本量下是决定性的。
最硬的一条是每任务成本的降幅在模型之间的分布：每个模型都便宜了，降幅从 −33%（Gemini 3.1）到 −61%（Flash 3.5），一个例外都没有。
"moving from the most to the least expensive model under the baseline saves 36%, while keeping any model and adopting the harness saves 33% to 61%."
在基线下从最贵的模型换到最便宜的模型省 36%，而保持任意模型不变、只上这套 harness 省 33% 到 61%。也就是说，在这个工作负载上，编排层是比选模型更大的成本杠杆。
最大的相对收益落在快速档：Flash 3.5 成本降 61%、时延降 55%。论文用成本分解解释这一点：对又小又便宜的模型，harness 开销（重放的历史、广播的工具定义）在总账单里占比更大，所以移除它移除的比例也更大。
为什么 harness 能决定账单：把钱写成公式
论文没有停在「能省钱」的结论上，而是把账单写成了公式。一个任务当成 k 回合的 agent 循环，每回合提交输入 token、收到输出 token。钱失控的根在一处：朴素 harness 每回合都把整份历史重放一遍。
输入侧拆成 harness 拼出来的五项：系统提示、历史、工具定义、检索、用户这回合。这五项里，系统提示是被重放还是缓存、历史是被重放还是压缩、工具定义是广播还是限定、检索负载多大、重试是否触发，全由 harness 决定。
如果每回合重放整份历史，总输入 token 会随回合数二次方增长：第 10 回合在重放前 9 回合，第 50 回合在重放前 49 回合，历史像滚雪球。一个 harness 只要会压缩历史、缓存不变前缀、把大块工具输出移出、把检索截到最小证据量，就能把这个二次方项压成近似线性。论文强调：模型一点没变，账单变了。
论文再补一个关键事实，让账单更精确：输入 token 的单价不是一个数。供应商对「重复了此前提示前缀」的 token 按缓存价收费，约是标价的 0.1 倍（便宜十倍）。如果输入里绝大部分是缓存读，那占多数的那一项就只付十分之一的价。论文点破的关键在这句：
"Crucially, h is neither a model property nor a provider favor: it is a function of prompt byte-stability across turns, which is set entirely by how the orchestration layer assembles context."
缓存命中率 h 既不是模型属性、也不是供应商的恩惠，它是提示跨回合字节稳定性的函数，完全由编排层怎么拼上下文决定。
于是 harness 同时控制了账单的两个因子：提交多少 token，以及占多数的那批 token 按什么价计费。逃出 token maxing 的路不是更便宜的 token，是更少的 token 完成同样的工作；而这条路稳稳落在 harness 里。
省的钱具体从哪来：六大机制
论文把观测到的降幅映射回成本公式，省的钱必然来自 harness 重写的那几项。设计目标一句话能说清：让尽量高比例的 token 满足三条：被缓存、与决策相关、花在能恢复的工作里，并且用结构而不是模型自觉去强制。六个机制逐条拆开，各配一个场景画面。
两区提示：把不变的焊在前面
把每个提示切成两段。上半段「信头」永远一字不变：工具定义、系统提示、已发生的对话记录（只往后追加）。下半段「信尾」每回合重写：当前时间、文件列表、临时提醒。
规则严格到什么程度：任何每回合会变的东西，结构上禁止放进上半段，缓存标记逻辑拒绝在第一条会变的消息处打断点。最多钉四个供应商断点（schema 目录后、系统提示后、沿两条最新持久消息滑动），且按 session 锁定一小时保留，策略不会跑到一半翻脸。因为供应商只对「和上次一模一样的前缀」按缓存价计费，约是标价的十分之一。
不删历史，把它压成一张摘要卡
对话历史越滚越大。到了模型输入预算的 80%，harness 不粗暴砍旧历史，而是把它折进一张「存档卡」：关键决策和约束、一份八段式进度摘要、用户原话需求、用到的能力引用。最近 4 到 12 条消息保持原样。
两个巧思：摘要用便宜的辅助模型在旁边跑，不占付费主循环；存档卡是持久行，折叠完重建出来的提示又成了新的可缓存前缀。所以压缩和缓存不冲突，这就是把二次方雪球压成线性的那一步。还有两道保险：空的或劣化的摘要会让这次压缩直接中止、不落盘；实在放不下，一条确定性阶梯（先缩活尾巴、再中段截断并提示模型复述要点）保证请求一定发得出去。
信息够得着，但不占地方
一族招数让信息保持可用、却不留在上下文里。子 agent 当「防火墙」：它在自己的上下文里读大量资料，只回一份 ≤8KB 的摘要，引用挂在父模型根本不读的边车上；委派有深度上限、重试下幂等，子 agent 的探索撑不大父循环。能力文档用渐进披露：提示里只带一张名字加描述的表，完整文档只在真被调用时才读。
大块工具输出溢出到文件：shell 输出超 20K 字符就只给首尾预览、完整的写进工作区文件，还附一条横幅、禁止模型从预览推断执行成功。计划状态每回合只投影一次紧凑渲染，顺带充当目标复述、对抗长任务跑偏。一句话概括：文件系统是无限内存，上下文只放指针。
等待不烧钱，崩溃不重买
agent 干到一半要等人审批、或等一个跑很久的后台任务。朴素做法是原地循环轮询（每问一次「好了吗」烧一回合 token）。这里的做法是持久挂起，零成本睡着，等事件来了再醒。
同一套持久层还防灾难：每个事件先写进预写日志再发出去，崩溃或被抢占的运行在世代围栏（generation fencing）下从下一个序列号精确恢复，工具结果也先落盘再展示。论文原话是："一次丢掉 40 回合运行的崩溃，朴素系统意味着重新买 40 回合的 token，这里只意味着从持久状态恢复。"
把「重试和死循环」这个烧钱乘数框死
agent 会失败、会重试、会卡进死循环，这些是账单上的乘数，per-token 降价治不了它。这条机制给失败立规则：每个失败先归类（限流/卡死/超时/流损坏/供应商宕机/永久六类），只有白名单里的类别才允许换下一家供应商重试。
断路器会在模型第三次发出字节完全相同的失败工具调用时掐断，并提示它「要么改参数要么退避」。中途失败作废，且作废的尝试不许留下副作用，这正是通用库的 fallback 漏掉的缺陷：编排库的流式故障切换，文档写明只在第一个 chunk 之前有效。
换任何模型，都能享有这层地板
换模型时代码不该跟着改。这里「用哪个模型、经哪些供应商、按什么顺序退避」是一份数据配置，循环代码里从不写「如果模型是 X」这种分支；每家供应商的返回流先被统一成一个标准格式，循环才看到。
还替弱模型兜底：定义里的引用自动展开、双重编码的 JSON 参数自动修复、报错里的框架内部信息擦掉、被弱模型误用的过载 schema 会被拆开。论文收尾一句："the harness fixes the floor; the model sets the ceiling"：harness 定地板，模型定天花板。正是这条让「只换 harness 省 33–61%」对每个模型都成立。
论文点出六个机制的贯穿主线：token 经济和输出质量是同一根杠杆、拉一次。又长又充满干扰的上下文会实测拉低每一个测过的前沿模型；一个移除陈旧或臃肿 token 的机制，同时在削账单和清理模型的工作集。
「这些不都是已知做法吗」：论文自己回答了
缓存前缀、压缩历史、子 agent 隔离，单拎出来每一条圈内都眼熟，论文没有回避这一点，还专门用一张表回应。它把六个广泛使用的 agent 系统对着这六个机制家族逐格核对（基于公开文档和一次设计期源码研究、不是头对头实测），主张很窄也很经济：在这些系统里，token 经济没有一处是一等的、公开的契约。知道一个做法和把它写成结构强制、再接一个每任务核算面，是两回事。
| 系统 | 部署类别 | 跨模型 | 结构化缓存策略 | 压缩契约 | 防火墙式委派 | 零 token 等待 | 每任务核算 |
|---|---|---|---|---|---|---|---|
| Claude Code / Cowork | 单用户客户端 | 否 | 有 | 有 | 部分 | 无 | 无 |
| LangGraph | 库 | 是 | 留给应用 | 留给应用 | 留给应用 | 部分 | 无 |
| CrewAI | 框架 | 是 | 留给应用 | 部分 | 无 | 无 | 无 |
| AutoGen / AG2 | 框架 | 是 | 留给应用 | 留给应用 | 无 | 部分 | 无 |
| Hermes Agent | 个人 agent | 是 | 部分 | 有 | 有 | 部分 | 无 |
| Writer Harness | 多租户运行时 | 是 | 有 | 有 | 有 | 有 | 有 |
逐类看论文的判词。Claude Code 和 Claude Cowork 被称为「部署最广的系统里最成熟的 harness 之一」，本 harness 的几个模式（缓存断点锁定、字节稳定前缀、子 agent 任务拆分）就是从它们那里采纳或对照验证的；差别在部署类别和契约：单用户客户端、绑一家模型厂商，内部 token 管理不作为每任务核算面暴露。LangGraph 提供优秀的底层原语（图编排、检查点、中断），但把缓存策略、压缩、卸载、失败治理刻意留给应用，token 经济就成了应用团队没人做预算的责任。CrewAI 和 AutoGen 一脉的共享记录多 agent 对话，按构造就是 token 乘数：每个参与 agent 重读增长中的对话、各带自己的角色前言，论文引 Anthropic 自己的公开测量：agent 约 4 倍于聊天的 token、多 agent 系统约 15 倍。Hermes Agent 是真正跨模型的开源 harness、子 agent 隔离做得好，但设计期源码研究发现它没把工具 schema 放进缓存前缀，在输入主导的负载上放弃了单笔最大的折扣。
表的最后一列是全文的缩影：没有内建在编排层的每任务核算，token maxing 就不可观测；不可观测的东西，无法被管理。
一个反直觉的边界：harness 会挑模型
效率的收益是无条件的，质量的收益却要看模型能力。论文把每个模型在八项能力上的平均质量增益，对着它的基线强度画出来，关系近乎线性（r = 0.99，六个点、论文自己标为「提示性而非结论性」）。论文给这个斜率起名 harness leverage：一个模型把编排结构转成质量的速率。
| 模型 | 质量增益 | sub-agent 委派完成度 |
|---|---|---|
| Palmyra X6 | +0.079 | 0.86 · 过门槛 |
| Sonnet 4.6 | +0.073 | 0.85 · 过门槛 |
| Gemini 3.1 | +0.050 | 0.70 · 退化 |
| GLM 5.1 | +0.028 | 0.58 · 退化 |
| Flash 3.5 | +0.010 | 0.45 · 不可靠 |
| Qwen 3.6 | −0.031 | 0.42 · 不可靠 |
在 48 个能力×模型的格子里，30 个改善、11 个持平、7 个退化，而且全部 7 个退化都发生在三个较小的模型上（Flash 3.5、Qwen 3.6、GLM 5.1），集中在最考验编排的能力上（工具使用、多步流程、演示文稿生成）。
"The same richer harness that a strong model converts into quality, a weaker model experiences as load."
同一套更丰富的 harness，强模型把它转成质量、弱模型把它当成负载。
这个不对称有个推论：一个弱模型上了 harness 照样拿到它那 44% 到 61% 的成本削减，只是不会同时变得更好。这就把「升级 harness」的两个理由解耦了，各自单独定价。harness 带来的唯一一个全新能力（把工作委派给孵出的子 agent）把这个边界摆到了最锋利的位置：委派任务的完成度只在两个最强模型上过了可用门槛，在快速档上还不可靠。论文称之为 capability floor（能力地板）：一个编排特性带着一条能力地板，在它之下暴露这个特性，产出的是失败而不是功能。
论文由此给路由研究提了一条方向：请求应该按功能需求路由、不只按提示难度。一个会动用子 agent 的请求属于最强模型，不管它的文本看起来多简单；而一个有依据的问答请求可以走便宜 61% 的快速档、没有质量损失。
"Token maxing is invisible in benchmark tables, which report quality, and painfully visible in cloud invoices, which report tokens."
benchmark 表格只报质量，看不见 token maxing；云账单只报 token，看得清清楚楚。
Writer · The Harness Effect · arXiv 2607.06906
两个旁证：从另一头印证同一件事
以下是旁证，不是论文主体。两份来自实践方的数据，从「AI 编码」和「多 agent」两个具体场景，印证论文「负载输入主导、编排决定账单」的判断。
Cursor 数据 第三方 · 产品方自报
Cursor 基于两年聚合使用数据的报告，最直接一条：90% 的 token 用量是输入 token，大部分花在读现有代码库和文档，输出代码只占少数。这呼应了《Clean Code》里「读代码 vs 写代码」远超 10:1 的老观察，也从数据侧对上了论文的输入主导。
缓存的作用被 Cursor 量化得最彻底：不做缓存的话 token 成本会高 10 倍；计入缓存后，输出 token 只占 0.6%，剩下 99% 拆成 cache read 90% / cache write 2.5% / input 7%。作者 Gergely Orosz 的原话把这跟自建 harness 直接挂钩："if you roll your own agent harness, you also need to put an efficient caching layer in place to match the efficiency of tools like Cursor."（自建 harness 就得自己搭一套高效缓存层，才能匹配 Cursor 这类工具的效率。）这正是论文机制一想说的事。
这份数据是 Cursor 产品方自报，且 Cursor 对自家 Composer 模型有利益倾向，本节数据按此口径引用。
Factory 多 agent 复盘 第三方 · 厂商演讲自报
Factory 展示了一个跑生产代码的多 agent 系统，从「编排、约束、边界决定可靠性和成本」这个角度印证论文。它的核心判断跟论文一致：agent 不是问题，协调才是问题。生产架构按认知模式（生成 / 批判 / 协调）而非任务类型拆成三个 agent：Drafter 只看任务和代码、看不到自己的失败历史；Reviewer 纯批判、从没见过任务原始规格，用不同上下文结构性消除自审偏误；Integrator 有最宽的上下文但最窄的动作空间，能合并能拒绝但不能自己写代码。
约束消灭故障是它反复强调的：每加一条约束就消灭一类失败。经济学上，它反驳「多 agent 更贵」的误解：多 agent 每任务成本约为单 agent 的 2.3 倍，但成功率高 3.1 倍、返工率低 74%，算上工程师重做失败工作的成本，多 agent 每成功完成任务约便宜 40%。需要明确标注：其中 91%、2%、2.3x、3.1x、盈亏平衡成功率 +15% 等数字来自 Factory 的厂商演讲、属自报，第三方存疑。
| 成本口径 | 单 agent | 多 agent |
|---|---|---|
| 每任务成本 | $0.12 | $0.28（2.3×） |
| 首轮成功率 | 31% | 96% |
| 每成功完成任务成本 | $0.39 | $0.29 |
盈亏平衡点约在成功率提升 15%，3 到 5 个专项 agent 的配置在「每成功完成成本」上持续跑赢单 agent。数字为 Factory 生产系统 2026 初自报。