Glean CEO Arvind Jain 写了一篇看似财务、实则工程的长文，核心命题只有一句：你花的 token 钱，大部分问题不在模型上，在模型周围的架构上。
钱在飞，价值没在飞
数据先摆出来：
- McKinsey：超过半数企业把 21%–50% 的数字化预算投向 AI，平均 36%
- Menlo Ventures：月均 AI 支出同比增长 4 倍
- The Information：Uber 把 2026 全年的 AI 编程工具预算，4 个月烧完了
而 Arvind 跟大量企业领导对话的体感是：token 消耗在快速上升，业务价值没在同步上升。
这意味着企业 AI 进入了一个新约束阶段——不再是"有没有用"，而是"产出的有用结果能不能 cover 掉花的 token 钱"。
引入指标：Token Yield
Arvind 提出的新指标叫 token yield——单位 token 消耗下产出的有用结果。
为什么需要这个指标？因为 raw token usage 几乎从来不是"模型单挑出来的"，它由围绕模型的整套系统决定：
- 上下文怎么检索
- 工具怎么暴露
- 工作怎么分解
- 模型怎么路由
- 历史执行怎么被复用
架构一烂，token 账单就飞涨——和质量提升毫无关系。
用户写的 prompt 是冰山尖
很多人以为"prompt 越短，token 越省"。Arvind 拿了一个真实例子打脸：
"Analyze churn risk for these accounts and create follow-up tasks."
这句话本身很短。但它触发的实际 token 负载通常包括：
- 系统指令
- 工具 schema
- 检索回来的文档
- 中间推理
- 执行轨迹
- 记忆召回
在很多企业系统里，大部分 token 不是用户写的，是模型脚手架自己生成的。 浪费不是发生在某一条 prompt 里，是发生在系统设计上。
四个架构杠杆
Arvind 列出四个直接决定 token 效率的工程杠杆。
1. 上下文质量
企业 AI 大部分失败都从上下文开始。
模型自己不知道哪段上下文重要——它处理你塞给它的全部内容。上下文越长，模型"注意力的成本"就越高。检索噪声大，模型就会把推理预算花在错误信号上。
Glean 自家数据：在一个 Claude Cowork 风格的任务 benchmark 上，Glean 的集中式索引比开箱即用的 MCP 工具多 2.5 倍胜率，同时少消耗 30% token。更说明问题的是——当 MCP 工具赢在正确性上时，它用了 83k token，Glean 只用 43k。
结论：弱检索逼系统用更多工具调用、更多推理循环、更多 over-fetching 来补偿。 这就是差上下文的隐藏税。
2. 模型路由
不是 agentic 工作流里每一步都需要 frontier 推理。
企业 AI 大量工作是操作性任务：搜索、检索规划、工具选择、验证、执行管理。这些环节重要，但不一定需要栈里最贵的模型。
多模型架构的目标不是"到处用便宜模型"，是"按需分配智力"。
如果每一步默认走 frontier，等于用 frontier 价格买 routine 工作。right-size 模型使用，是提升 token yield 最直接的杠杆之一。
3. 持续学习
企业 AI 系统不该每次从头解决同类问题。
每次执行都产生信号：哪些工具有用、哪条检索路径 work、哪些步骤多余、哪些输出真帮用户把事做完了。
人类也这样——做完值得复用的工作，就写文档，下次不重造。企业 AI 应当照做。 累积的 trace 数据应当帮系统跳过冗余探索、避开失败路径、收敛到对的工作流。
没这个机制，系统每次都重复付同样的探索成本。
反过来说，能从历史执行学习的系统：减少冗余推理、跳过失败路径、更快收敛。结果不只是质量高，是重复工作的成本越来越低。最好的企业 AI 系统会这样复利。
4. Harness 设计
agents 承担越来越长、越来越多步的工作时，harness 就成了质量和成本的主要决定项。
naive harness 让 active context window 持续膨胀——每一步多带指令、多带工具、多带 state、多带中间输出。成本随工作流增长，可靠性通常同时下滑。
好的 harness 反过来：把上下文当作"需要管理"的东西，而不是"需要累积"的东西。
具体做法：把工具 scope 到当前步骤、必要时把工作分发给专业化 agent、externalize 中间 state、给每个模型只发它要的 working set。目标不只是支持更复杂的任务，是在上下文不爆炸的前提下支持它们。
真正的护城河：执行效率
Arvind 在文末画了一条非常清晰的边界：
模型提供智能，架构提供纪律。
过去两年，行业押注"模型越来越聪明 = 一切问题自动解决"。现在发现：模型再强，围在它周围的检索、路由、记忆、harness 任何一个漏出来，账单就飞。
下一步真正能拉开差距的，不是再用上更大模型，而是把每一次 token 消耗变成更多业务结果。
核心 takeaway
- Token yield > token 消耗——后者是 cost，前者是 ROI
- 用户写的 prompt 是冰山尖，系统 prompt + 工具 schema + 检索 + 推理 + 记忆才是冰山
- 四个杠杆：上下文质量 / 模型路由 / 持续学习 / harness 设计——前两个直接省 token，后两个让系统复利
- 下次账单异常飞涨，先查架构，再查模型