全部 · 2026-07-08

Anthropic 的开发者公开了他们内部怎么用多智能体省钱，核心思路就一条：别啥事都让最贵的模型上。第一种 Advisor 模式，让便宜的 Sonnet 5 当主力写代码，碰到难题才通过工具调用去问贵的 Fable 5。在 SWE-bench Pro 的 482 道题上，这套组合拿了 84% 的分数，花了 1.40 美元；纯用 Fable 5 是 91.5% 但得花 2.25 美元。相当于用 92% 的性能，省了 37% 的钱。第二种 Orchestrator 模式，让 Fable 5 当指挥，把任务拆开分给多个 Sonnet 5 工人并行干。在 BrowseComp 测试上，这套编排方案拿到 86.8%，花 18.53 美元；全 Fable 5 是 90.8% 但成本高达 40.56 美元，省了一半还多。 这两组数字挺实在的，直接告诉你省了多少、掉了多少。不过要注意，测试集是 SWE-bench Pro 和 BrowseComp，都是代码和浏览类任务，其他场景能不能复现这个省钱比例，正文没提。另外，Orchestrator 模式里 Fable 5 怎么拆任务、Sonnet 5 之间怎么协调，细节也没展开，实际落地时调度逻辑写不好可能反而增加延迟。

周俊在 AICon 上给了一个很直观的比喻：万亿参数模型跑 15 分钟，算力成本抵一辆特斯拉。这个说法把大模型烧钱的程度讲清楚了。他们没去继续堆 Token 数量，而是提了一个“Token 密度”的概念，核心是让模型少说废话、多干正事。 技术实现上，他们用 7 份 Lightning Attention 加 1 份 MLA 搭了一套混合线性注意力架构，把 256K 长上下文的计算开销从指数级拉回到线性级。省下来的算力可以留给推理环节。Kpop 算法把工具调用的 Token 和自然语言 Token 分开处理，再配合思维链剪枝和自蒸馏，Token 输出量减少约 4 倍，但能力没降。千亿参数模型在 BFCL 等 Agent 基准上跑赢了部分更大的模型，小模型 flash 吞吐提到 2.4 倍，五轮对话成本降了 10 倍以上。 这些数字如果属实，对做 Agent 落地的人挺有吸引力，尤其是长上下文和工具调用频繁的场景。但正文没披露具体测试环境、对比基线的细节，也没看到开源权重或第三方验证。演讲里的数据先打个折看，等有公开复现报告再下结论。

这条消息对做模型部署的人来说是个实打实的好事。以前想让模型在 vLLM 上跑得快，得专门为它写一套推理代码，现在只要加个 --model-impl transformers 参数就行。Hugging Face 官方拿 Qwen3 的三个不同规格模型做了对比测试，从 4B 单卡到 235B 的 MoE 模型跨 8 张 H100，新的 transformers 后端吞吐量都追平甚至超过了 vLLM 手写的原生实现。 不过要注意，这个结论目前只基于 Qwen3 这一个模型系列的测试，其他架构表现如何正文没给数据。另外，用了线性注意力的模型暂时还不支持，自己上传到 Hub 上的自定义模型如果代码写得不够规范也可能跑不起来。如果你用的正好是主流架构，这个更新基本等于零成本提速，值得立刻升级 vLLM 包试一下。

这篇论文最值得关注的是它把可解释性工具的成本打下来了。Jacobian Lens 不需要像 SAE 那样训练外部网络和人工标注，它利用模型自带的“字典”，通过反向传播算出每个词在每一层的对应方向。这意味着你可以在单张显卡上几小时内复现，直接看到模型在某一层到底在“想”哪些词。 实验里最扎眼的数字是干预效果：用这套方法在激活层做反向位移，能把模型的虚构率从 0.25 压到 0.07，欺诈率从 0.38 压到 0.05。而且消融掉相关方向后，这些指标会立刻反弹，说明找到的方向确实在起作用。 不过得打个折。这个方法依赖单 token 预测，在模型深层会抓到不少噪声。论文里提到的 workspace 只占状态方差不到 10%，剩下 90% 在干嘛，正文没细说。另外，它读到的只是“准备说”的词，离真正理解模型的复杂推理链条还有距离。

这篇文章点出了一个很实际的工程问题：给智能体接上几十个工具后，用户一句简单提问会被工具定义、日志和抓取数据淹没。它把问题从“缺上下文”推进到了“上下文治理”，这个判断是准的。 文章引用的几个案例挺说明问题。Anthropic 的 MCP 沙箱能把 15 万 token 的工具定义压缩到约 2000 token 的高信号输入，这直接关系到单次调用的成本和模型注意力。Manus 披露的生产环境输入输出 token 比约 100:1，这个数字解释了为什么前缀缓存命中率会决定系统的经济可行性。他们用固定工具调用格式保缓存、在窗口末尾重写任务看板对抗“中段迷失”，都是很具体的工程手段。 不过，文章对 Headroom 这类独立压缩中间件的评价比较克制，指出它缺乏大规模验证，在紧凑代码或短对话场景可能反而增加延迟。这点很关键，说明“压缩”不是万能药。整体来看，文章把 RAG 定位为基础数据接入层，把文件系统、状态管理和缓存策略视为更上层的运行时治理，这个分层思路对做 agent 系统的开发者有参考价值。但正文没给出这些方案在复杂编程任务上的具体成功率对比，实际选型时还需要自己测。

Tunguz 这套架构的核心是把记忆和推理拆开。他建了一个约 90 个技能的长期库，智能体接到任务后先做“预检”，只把匹配的技能装进上下文窗口，而不是把全部资料塞进去。这相当于让模型带着小抄上考场，能省下不少上下文空间。日常任务里，80% 由本地跑的 Ornith 35B 模型处理，只有硬骨头才转给更强的模型，听起来能省不少调用大模型的费用。 系统里还有个“看门狗”，会记下每次决策，晚上做异步推理，自动建议新技能或把部分技能转成确定性代码，比如用 Rust 处理日历排期，而不是让大模型去比空闲时段。昨天是它第一次没提改进建议，可能说明系统到了平台期，只有遇到真正的新异常才需要人插手。 不过，这篇文章是个人实验分享，不是产品发布。正文没披露这套系统的实际延迟、单次任务成本，也没给准确率数据。90 个技能听着不少，但能不能覆盖复杂业务场景也未知。整体思路值得参考，但落地效果还得看具体数字。