字节跳动的一篇新论文，把大模型的一个隐藏短板摆上了台面：LLM能给自己造工具了，但造出来的工具，水平极其不稳定。

论文让每个"创作者模型"从一个近乎空白的运行时出发，自己搭建执行循环、工具调用、上下文处理、错误恢复和验证机制——相当于让AI从零开始给自己盖一套完整的工作台。

打开网易新闻 查看精彩图片

结果很有意思：系统确实能跑起来，但效果在不同任务上差距大到离谱。

同一模型，两个极端分数

论文里最扎眼的一组数据来自Opus 4.8。在写作任务上，它自建的工具链得分84.6，甚至超过了外部精选参考方案的83.7。但在BrowseComp这个任务上，它只拿到52.4，而外部参考方案高达92.2。

将近40分的差距，说明这套自建系统在部分场景下已经能用，但在另一些场景下几乎等于没搭。论文原话是"生成系统已经有用，但按领域划分极度不均衡"。

这种偏科不是偶然，而是当前自建harness模式的系统性特征。

换了个执行模型，分数直接腰斩

更麻烦的问题是迁移性。论文测试了一个场景：用Opus 4.8写的代码harness，在SWE-Pro任务上由Opus自己执行时，得分69.3。但换成Gemini 3.1 Pro来执行同一套代码，分数掉到33.0——直接腰斩还多。

这说明什么？说明这套工具链在设计时，已经深度适配了创造它的那个模型。它不是在做一个通用的、干净的软件层，而是在跟特定模型的脾气秉性"共同进化"。

论文对此的总结很克制：harness设计可以针对单一模型协同适配，但离成为可复用的软件层还有距离。

为什么迁移这么难

拆开看，问题出在自建harness的每个环节都带着"创作者"的烙印。执行循环的节奏、工具调用的偏好、上下文窗口的使用方式、错误恢复的策略——这些都是在特定模型的推理习惯下长出来的。

换一个模型来跑，等于让一个习惯右手的人突然改用左手，所有动作都要重新校准。

这跟人类程序员写代码不太一样。人写的工具链追求通用性，因为要给别人用。但LLM自建harness时，没有"别人"的概念——它服务的对象就是自己，所以天然会往"私人定制"的方向走。

实用价值已经出现，但路还长

尽管问题不少，论文也确认了自建harness的实用价值。在写作这类任务上，它已经能跟精心挑选的外部方案打平甚至略胜。这意味着在某些垂直场景里，让AI自己搭工具可能比人工配置更高效。

但跨模型迁移这道坎，短期内看不到解法。如果每套harness都只能服务一个模型，那它的复用价值就大打折扣——每次换模型都要重新生成一套，成本并不低。

论文地址在arxiv.org/abs/2609.01437，感兴趣的可以去看完整实验设置。这个方向刚起步，偏科和迁移问题都是第一代产品的正常症状，后续怎么解决，值得盯着看。