我们复核了智能体成本相差28倍的实验，真正的决策层是 Harness
MCP 并不是 AI 智能体成本的首要决策项。本文结合覆盖七种 harness、五种模型的受控实验，以及我自己实测的工具定义载荷字节数与失败支出占比，说明真正决定成本、可靠性与可审计性的究竟是哪一层。
一个做 AI 智能体的团队问我：砍掉 MCP 能不能把运维成本降下来。我把一份关于 MCP 与 CLI 的受控实验，和我自己对 MCP 工具定义体积的实测放在一起看了一遍。结论很明确：MCP 确实会往每一轮请求里塞进常驻的上下文重量，但决定成本结构的是 Harness；只换接口，回收不了那笔钱。
如果你是要签批智能体平台的 CTO，或是正在运营它的技术负责人，眼下该做的事只有两件。先做 Harness 横评，再谈工具标准化；然后把访问控制放到 Harness 下面那一层，那里才真的能强制执行。
贵的那个决定，往往在调用工具之前就已经做完了
智能体落地时反复出现的管理失误，是把模型、工具协议、执行系统当成同一笔采购来批。它们根本不在同一层。
模型产出 token。CLI 或 MCP 这类接口，负责表达"有哪些动作可用"。而 Harness 决定的是：每一轮请求里，哪些指令、哪些工具 schema、多长的对话历史、几次重试、几道审批、多少次文件读取、多少轮校验，是必须在场的。所以，把一个漂亮的 demo 推向两种命运的，正是这一层——要么成为可控的运营系统，要么成为无法预测的成本黑洞。
这份受控实验只用了一个固定任务：针对一个私有远程 git 仓库的六个操作，跑遍七种智能体 Harness 与五个语言模型。完成与否，靠检查仓库状态判定，而不是听智能体自己说"我做完了"。这个区别很要紧。把自我报告当完成率统计的团队，测的不是交付出来的工作，而是被评测的那个系统自己生成的一句未经核实的陈述。
论文的核心结论写得很直白：
"The dominant effect was the scaffolding."
如果你们的智能体工作量本来就落在 git、构建、文件系统、Linter、包管理、图片转换这类成熟的 CLI 界面上，那起点就得改。别一上来就注册 MCP 服务器。先拿同一个真实任务、同一套基于状态的验收标准，做一次小规模的 Harness 对比。
Harness 策略为什么会在每一轮把开销乘一遍
实现可以很复杂，单位经济学并不复杂。
每一轮的输入成本，来自系统提示词、常驻的工具定义、累积的对话历史，以及 Harness 自己决定重发的那些重复上下文。总成本则是这个输入乘上完成、重试、检查、校验所需的轮数。
而这些项全都归 Harness 管：
- 工具 schema 是不是每轮都常驻；
- 历史是全量回放还是压缩；
- 智能体会不会把同一个文件反复读；
- 一次动作失败后，触发的是窄范围修复循环，还是把整个上下文重新摸一遍的大循环；
- 完成判定是对着系统状态查一次，还是从模型输出里反复猜。
工具接口只改变这几项里其中一项的表达形式。它决定不了那个把这些项一轮一轮抬着往前走的策略。
我自己跑了一个最小的 JSON-RPC stdio 探针，对两个 MCP 服务器依次发 initialize、notifications/initialized、tools/list，然后只把响应里的 tools 数组做最小化序列化，统计字节数。一个服务器暴露 2 个工具，1,451 字节。另一个暴露 29 个工具，23,257 字节。也就是说，仅仅因为你注册的是这台而不是那台服务器，常驻工具定义的字节数就差了 16 倍。指令文件在每一轮里如何被重新读取，我在同一仓库实测 AGENTS.md 与 CLAUDE.md 加载里记过。
绝对 token 数只能算近似值，因为我用的是字符数除以四，不是生产环境的分词器。但倍数是按字节算的，不受这个近似影响。更要紧的一点：这不是对论文那个七乘五矩阵的复现。它只锁定了一个平台团队立刻就能管住的事实——当工具 schema 被塞进每一个请求时，它不是抽象的元数据，而是一笔每一轮都要重付的输入成本。
这也解释了为什么 MCP 的失败在财务上会不一样，即便失败次数并没有更多。实验里两种接口的失败频率相当，重复跑也一样。可 MCP 那一侧花掉的钱有 12.9% 没换来任何完成的工作，CLI 侧只有 2.2%。差别出在系统走到失败之前已经烧掉的那部分。模型单价之外，智能体的钱究竟流向哪里，可以看运营 8 个智能体与人工成本的对照记录。
一块只显示总花费和成功率、却不显示"失败工作占了多少钱"的平台看板，正好会把这个模式藏起来。
28倍是真数字，但它被引用错了
论文里最诱人的标题数字，是 5.0 倍到 28 倍的成本差。它不能被拿来证明"MCP 本身比 CLI 贵 28 倍"。
那组对比，是两个不支持 MCP 的 Harness 对五个支持 MCP 的 Harness，而且只比 CLI 的运行，全程任何一处都没有挂载 MCP 服务器。它证明的是：即便把接口固定在 CLI，Harness 的选择依然能拉开巨大的成本差。它不构成砍掉 MCP 的依据。
Harness 这条线上更硬的发现，是那个 270 亿参数的本地模型。它在不同 Harness 之间的成本差了 139 倍，而它在每一个 Harness 下都把任务做完了。同一个模型，同一个任务，同样都做完了，执行经济学却完全是两回事。
论文还给了 13 组严格配对的 MCP 对 CLI 比值，从 0.43 倍散到 29 倍，两头都有异常值。作者自己明确写下：他们本想做的那个接口对比是不稳定的。对一个高管级决策来说，这就是正确的读法——配对证据给不出稳定方向时，别把接口层面的断言写进投资备忘录。
还有一条方法论警告，值得带进你们内部的每一次评测。智能体经常无视分配给它的接口。一份标着"MCP 运行"或"CLI 运行"的报告，如果没有核实实际行为，那它没有用。否则团队量到的，是可用工具、回退行为、提示词理解和 Harness 策略搅在一起的一团东西。
最强的反驳在 MCP 这点上是对的，但它指错了下一步该看哪儿
最有力的反方论证，值得原封不动地摆出来。
任务是六个 git 操作。git 是工程界最成熟的 CLI 界面之一：几十年沉淀的命令约定、可组合的输出、可预期的退出码、丰富的文档、成型的运维习惯。发现智能体能靠 CLI 完成这类活儿，不是对 MCP 的普遍判决。这个结果是被一个 CLI 本来就极其能干的领域塑造出来的。
5.0 倍到 28 倍这个数字，同样撑不起一个"清退 MCP"的项目，因为它没有把挂载 MCP 的运行和纯 CLI 的运行放在一起比。那组对比里根本没挂 MCP 服务器。任何把它讲成"MCP 贵 28 倍的铁证"的高管汇报，都是读错了证据。
对于任何关于"哪个接口更优"的宽泛断言，这条反驳都成立。一个任务不构成一套普适的工具经济。一个 CLI 成熟的代码仓库，不等于客户数据系统、不等于某个自研 SaaS 流程、不等于设计平台、也不等于受治理的业务数据环境。那些不稳定的配对比值，进一步框住了适用范围。
我承认这一点，也就等于承认我不能拿这篇论文去谈接口选型。但反驳并不能抹掉 Harness 那个结果。把接口标签放到一边，主导性的 Harness 效应仍然在。139 倍那个数，仍然是在任务固定、结果同样是完成的前提下，纯粹由 Harness 造成的差异。这才是值得据此行动的决策信号。
对一个只跟 git、构建系统、文件系统操作、包管理打交道的团队，起步阶段不上 MCP 是合理的，因为可行的 CLI 路径本来就在。而对一个必须去查同意记录、客户分群、内部台账或自研 SaaS 对象、且这些东西根本没有像样 CLI 的团队，MCP 可能是唯一能走的路。这时候要问的不是 MCP 在架构美学上是否优雅，而是它的 schema 体积、授权设计和失败成本画像，有没有被预算过、被管住。
先把落地流程标准化，再谈协议标准化
平台侧第一个该定的东西，是一套可重复的评测流程，不是一份工具清单。
先挑两到三个 Harness，把同一个有代表性的任务分别跑一遍。模型、验收标准、权限、可访问的数据全部保持一致。完成判定要落在仓库状态、数据库行、响应码，或者别的能独立查验的状态上。别让智能体的最后一句话成为成功标准。
论文把 Harness、任务、验证方法和完整数据集都开源了。这在运营上很实用：团队不用等某家厂商的基准测试才能动手。可以先把纪律抄过来——固定任务、受控配置、状态校验、保留执行证据。
接下来，把 MCP 注册变成一次受治理的工程变更。
每一个注册 MCP 服务器的 PR，都应当写明 tools/list 的载荷体积和工具数量。CI 可以跑上面那个基础探针，并对单服务器和整仓库设置载荷预算。目的不是一刀切地禁止大工具面，而是要求有人出来说清：为什么这一组常驻的 29 个工具必须出现在每一次智能体上下文里，而不是拆开、限定作用域，或者按需加载。这道审查里也得有安全项，MCP 配置文件泄露 2900 万个密钥的事已经说明了原因。
再往运营看板上加一个指标：失败工作花费占比。单看成功率，分不出"早早失败、花得很少"和"上下文反复膨胀、调了一堆工具、重试几轮之后才失败"这两种情况。这是一个直接的单位经济学度量——智能体花的钱里，有多少比例没买到完成的工作？
最后，把工具可用性和执行权限拆开。一个 MCP 服务器可以描述某个有用的动作。这不等于每个智能体、每个任务、每个环境、每个被派下去的子智能体都该被允许执行它。
安全管控不能放在一个天生要被改的层里
Harness 是承载任务策略、上下文策略、审批流程和使用体验的正确位置。它是承载最终安全保证的错误位置。
Harness 的可编程性是设计出来的。团队会去改它：加工具、调提示词、改重试、支持新的智能体、提升吞吐。这份灵活性很有价值，但它同时意味着，Harness 没资格成为"证明某个敏感动作不可能发生"的权威。
NVIDIA 对智能体技术栈的梳理把这层含义说透了：
"This programmability makes the harness a poor place for a security guarantee: a layer designed to be modified cannot reliably enforce controls against its own modification."
当智能体走出代码仓库、开始接触客户、会员、财务或同意相关的数据时，这一点尤其要紧。一句"不要访问受限字段"的提示词能引导行为，却强制不了行为。一个智能体可以选择不去调用的工具，也同样不是管控。执行点必须落在运行时或基础设施边界上，给出智能体和 Harness 都越不过去的上限。
具体一点说，访问策略应该绑在凭据、数据作用域、网络路径、执行身份和运行时策略上。派下去的子智能体应当拿到上限更窄的子运行时。审计记录要能说明是哪个身份、在哪条策略下、访问了哪个资源，而不只是记下 Harness 配置里出现过哪句指令。
这不是给安全打的补丁。这是"能演示的流程"和"能过审计的流程"之间的分界。
业务界面没有 CLI 的地方，MCP 仍然是必需品
从一条成熟的工程流程里拆掉 MCP，能减少活动部件。而从一条业务流程里拆掉它、又没有替代方案，那就是把通往可用自动化的唯一路径一起拆了。
企业里大多数数据界面本来是给人用的：应用、看板、审批流、领域专用 API。它们不会暴露一套智能体能安全组合起来的连贯 CLI。客户数据查询、同意状态复核、内部 SaaS 操作、设计系统流程，通常都属于这一类。
OpenAI 的平台方向反映了这个现实。它把 Codex 定位为一个可复用的 Harness，负责上下文管理、工具使用和审批流程，而 MCP 工具归应用方所有。
"Codex can then use the application's MCP tools to fetch current data before recommending."
对这些团队来说，MCP 不是成本优化的靶子，而是一条集成路线。有纪律的做法是接受这条路线，同时管住它的成本和风险：
- 工具定义限定在最小的运营面上；
- 别默认注册一整包工具集合；
- 上生产前先量一遍常驻的 schema 载荷；
- 用权威系统状态校验结果，别用模型的自述；
- 把失败工作花费和完成工作花费分开记；
- 数据访问和动作上限，交给运行时与基础设施层强制执行。
这跟"到处都上 MCP"和"哪儿都不上 MCP"都是实质不同的策略。它从业务界面出发，再套上架构纪律。
下一个评审周期里，CEO 和 CTO 该改什么
第一，在运营议程上，把 Harness 选型排到模型重新议价之前。模型合同当然重要，但实测出来的 139 倍 Harness 差异说明，模型选型不可能是高管评审台面上唯一的成本杠杆。执行层决定模型多久收到一次上下文、每次收到多少、以及在校验之前要先烧掉几轮贵的对话。
第二，把失败工作花费列为智能体试点的批准指标。一个试点若报出很高的完成率，同时悄悄把大块预算耗在没成功的运行上，那它没到可以铺开的时候。完成率回答的是这套系统有时候能不能干成事。失败工作花费回答的是它的运营模型在经济上撑不撑得住。
第三，把 MCP 注册当容量规划来做。一台服务器的工具定义占用上下文容量，就像一个服务依赖占用延迟和可靠性预算一样。合适的治理产物是一个 PR：附上实测载荷、归属人、上线理由、访问范围和回滚条件。
第四，把钱花在运行时边界的强制执行上，而不是花在可编辑的 Harness 指令里。这是合规投入从一堆善意的提示词文本，变成可审计的运营能力的地方。
我的判断很简单：CLI 已经成熟的工程类工作，在同任务 Harness 横评证明新增工具面确有必要之前，一台 MCP 服务器都不要注册；没有 CLI 的业务界面，就用 MCP，但要把它当成一个计量、并由运行时治理的集成层来管。
要我改这个判断，得看到这样的证据：在 Harness 策略、工具载荷、运行时权限都固定的前提下，跨非 CLI 的企业任务做受控、状态校验的基准测试，挂载 MCP 的配置能稳定降低完成工作的单位成本。