模型在花钱，Harness 在控预算
Agent 架构本质是不确定性下的有界资源分配。模型在花钱，Harness 在控预算。
定义
模型是一个开放型支出者——花上下文窗口、花 token、花延迟、花副作用、花钱。 Harness 是工程上设的天花板，决定模型可以花什么、花多少、什么时候花、谁授权花。 真正的设计工作发生在 Harness 里，不在 prompt 里。
它命名了什么问题
过去两年的 Agent 生产事故有一个反复出现的形状：失败几乎全部来自 Harness 缺位，而不是 prompt 写错。 工程师把绝大多数注意力放在 prompt 上——因为 prompt 是 IDE 里能看到、能改、能立刻看到效果的东西。 但事故真的发生时，复盘报告写出来基本上是同一组句子：
- 一个客户问题触发了 retry loop，单次对话烧掉了原本一周的 token 预算。没有 budget 上限。
- Agent 被授予
bash工具用来"做代码分析"，在某次任务中执行了rm -rf。没有 tool scope。 - 数据修复 Agent 拿到生产数据库写权限，半小时内污染三张表。没有 human-in-loop 卡在 destructive 操作上。
- 长跑 Agent 上下文涨到 180k token，推理开始漂移。没有 auto-compaction 或 reset 政策。
- Agent 在某一步幻觉了一个 tool 返回结果，下游所有动作基于虚构数据，6 小时后才被发现。没有 side-channel 校验或 anomaly detection。
把这些事故并排看，模式很清楚：调过的部分没出事，没调的部分全出事。 Prompt 被反复 iterate 过，所以 prompt 层的失败被提前消化了。 Harness 的几个关键边界——预算、scope、blast radius、escalation、observability——因为不在 IDE 里可见，所以从来没被显式设计，事故就从这里漏出。
这是一个有先例的范式失衡。Web 工程早期，工程师调 CSS 和 JS，而 production outage 全部来自缺失的 observability。 DBA 调查询，而 prod 事故来自没设的连接池上限。能被看到的工作被精修，作为基础设施的工作被忽略，直到它在凌晨 3 点把人叫起来。 Agent 系统现在正处在同一个阶段。这条主张要命名的，正是这个失衡。
它如何改变设计决策
一旦接受"模型是支出者"，每一个架构决策就都变成了预算决策。 上下文窗口不是"模型能读多少"，而是"我怎么把稀缺的 token 容量分配到相互竞争的输入上"。 工具 scope 不是"agent 能做什么"，而是"我愿意让它碰什么表面"。 推理深度不是质量旋钮，是成本旋钮。 Harness 的工作是在模型决定之前把这些天花板设好。
谱系
这不是新东西。在系统工程的几十年里，这个模式反复出现：
- OS 进程调度——进程都想要全部 CPU，调度器决定谁能拿多少
- JVM 垃圾回收——应用自由分配，GC 来控制暂停时间和堆容量
- CDN 限流——客户端想要无限带宽，边缘节点设定每租户上限
- Linux cgroups——工作负载共享主机，内核执行 CPU / 内存 / IO 预算
- SRE Error Budget——团队想自由发布，预算决定发布速度
Agent 时代的版本是：LLM 是工作负载，Harness 是 kernel。
它不是什么
- 不是在批评 LLM。模型作为支出者是它设计的事实，不是失败。
- 不是"Harness 取代模型"。没有要控的支出，Harness 无意义；没有要控的东西，模型很危险。
- 不只是可观测性。可观测性告诉你花了什么。预算决定允许花什么。
- 不是 prompt 工程。Prompt 坐在 Harness 的一格里，Harness 设计的是这一格本身。
在哪里展开
- 立场论文：arXiv:2605.13850
- 书：Designing AI Agents（Manning, 2026）—— 全书贯穿，Ch1 / Ch7 治理层 / Ch10 生产 Harness 显式展开
- 具体模式：G2 爆炸半径控制 · G5 可观测性 · P1 上下文分诊
引用格式：黄佳 (2026). 模型在花钱，Harness 在控预算. kage-ai.com/zh/concepts/model-spends-harness-budgets/