Agent的瓶颈不在模型，在harness

今天在HN上看到一个叫Artifex的项目，作者自己写了个基于图结构的GPU harness，在TerminalBench上把Gemini-3排到了前面。我盯着这个项目看了半天，脑子里转的是另一个问题：为什么模型参数越堆越多，Agent跑起来还是跟纸糊的一样？

做芯片的人对"harness"这个词不陌生。测试芯片要加测试环，做SoC要在核外面包一层电源管理和时钟树。模型外面的这套东西，道理一样。NVIDIA那篇讲"six agent harness capabilities"的文章我扫了一遍，它列的渲染上下文、执行动作、管理状态、决策何时完成，跟我当年做基带协议栈的分层思路几乎是一个模子。这年头连NVIDIA都开始讲"架构围绕模型"了，说明单靠模型本身的好日子确实过去了。

Artifex这个项目有意思的地方在"graph based"。它构建代码的图表示，在运行时动态决定节点的连接方式，不同于传统Agent那种线性的chain。我第一反应是，这不就是时序电路和组合逻辑的区别么。组合逻辑一路推过去，任何一个信号变了整条链都有可能翻转；时序电路有状态，有反馈回路，每一步都踩在时钟沿上。传统的Agent编排就是组合逻辑，模型推理一次，工具调用一次，结果拿到再推下一次。看起来顺，但任何一步出错，后面全乱。

图结构的好处是能回退，能并行，能在某个节点判定结果不满足预期时改走另一条分支。这跟我在展锐调功耗的时候心态很像，没有全局调度，什么动态电压频率调整都是空话。但是，图结构的第一性代价是复杂性的转移。有人做过对比说graph harness在真实业务场景里跑得比纯LLM agent好，我信。问题是这个图的解析、维护、状态同步，这些开销算谁的。GPU harness这个名字起得挺准，我这边测下来，绝大多数调用方的中间状态在模型上下文和外部存储之间来回倒腾，光序列化反序列化就能吃掉不少时间。

NVIDIA那篇博客我仔细看了，它提的六个能力里有几条确实切中要害。一条是渲染上下文。现在的Agent上下文管理普遍做得糙，博客里能塞一大坨，关键信息反而被淹了。另一个是"决定任务何时完成"。这句话翻译成工程语言就是迟滞比较器，结果质量低于阈值就得继续跑，高于阈值就收工。这玩意儿做深了就是一套贝叶斯决策，做浅了就是拍脑袋设个轮数上限。

不过我得说一句泼冷水的话。NVIDIA讲harness，天然有立场。它卖GPU，卖NeMo，卖整套企业级平台。harness越复杂，平台绑定越深。HN上这个独行侠作者，自己憋出来一个开源的东西，能打通TerminalBench，这件事本身说明了领域还没有被大厂彻底圈死。我现在比较好奇的是这个趋势往哪走：harness会不会变成Agent时代的操作系统，把模型变成一个换什么都能跑的指令集；还是说最终演变成当年我们做基带时候的DSP固件，各家闭源，互相不兼容。

这几天我刚摸到模型路由这个概念，回头再看harness，感觉这其实是同一件事的两面。路由解决的是"哪个模型干这个活"，harness解决的是"活怎么拆、状态怎么管、结果怎么验收"。两个东西叠在一起，才是Agent真正跑得动的底座。

有个问题我一直没想清楚，写出来当个结尾吧。做芯片的人想的是怎么用最少的晶体管实现需求，做Agent harness的人是不是也该想，怎么用最少的上下文和调用次数完成任务。优化目标要是定错了，整个架构从第一天起就是歪的。

---

本文编译自 Hacker News，原文：Loading...
版权归原作者所有，本文为基于公开报道的编译与独立分析。