Agent 也有它偏爱的工具

很多人使用编码代理，比如软件工程师（对于各种各样的事情事实证明，并采用一种与人类打交道的思维方式来理解这种工作原理。如果一个模型有一个有用的工具，而你给它另一个有用的工具，那么它就能从两者中获得能力。

总体来说，这似乎......不对吗？你可以让某个工具可用，但模型必须决定是否使用它，而模型往往不会这么做。我最近的情况与LSP的纠结我直接遇到了这个问题。

接着我试试 Python 部分SWE-Bench ProMax，一个围绕大型协调重构构建的基准测试。这正是 LSP 所从事的工作类型find references应该会派上用场。

很有帮助的是，亚伦·波拉克给我指了个地方CodeAnchor论文，作者们也遇到了几乎相同的问题。他们试图给经纪人一个呼叫图工具，然后......

“我们观察到工具使用率很低：该药剂通常依赖普通的格雷普。”

他们没有重新训练模型，而是将调用图上下文放入相关代码中，添加如下注释“used by: foo, bar” 在定义附近。我尝试了一种变体，不是标注代码，而是grep结果：当代理搜索符号时，LSP会找到引用并附加到grep输出中。

从失败的跟踪中可以看出注释是正常工作的。他们显示的99个文件中，全部打开了，92个被打补丁。这减少了转数，似乎有助于减少每次运行的偏差，这也是CodeAnchor团队看到的好处：带注释时跑失控的次数比没有注释时少。

但最常见的失败是重构不完整。模型会很快找到核心修复，正确编辑，然后遗漏其他同样需要修改的文件。这些错误是LSP并不能真正帮助解决的：主要是关于是否符合冗长且曲折的规范。

可以使用LSP工具来帮助解决这些问题，但模型没有做到。

注入工具衍生的上下文解决了采用问题，但怎么会这样该模型的行为仍受其学习的工具使用政策驱动。

关于工具使用作为行为政策的观点，有一些有趣的学术和非学术研究，而且这种做法出乎意料地可预测。偏见破坏者显示模型在功能等效工具之间有强烈偏好。

AutoTool发现工具调用倾向于遵循可预测的序列，并利用之前的代理轨迹预测下一个工具，完全绕过部分推断。在非学术方面，史蒂夫·耶格在构建Beads CLI时，他让代理们产生幻觉，然后直接添加这些参数，所以工具自然符合模型已有的预期。

你可以替换形状大致与模型相似的工具，也可以给熟悉的工具添加输出，提供更多信息。但让模型使用新工具，或者以不同方式使用工具，似乎要复杂得多。

实验室的答案似乎依然是：那就更强化吧。

DeepSeek 的V4.1-闪存技术报告，我们讨论过昨天对此尤其明确。他们的训练后处理方法相当标准：先SFT，再是强化学习，最后是策略内提炼。

新颖的是自动生成任务和环境来训练代理。他们从内部代理会话中获取这些，这些会话显示模型性能不佳，以及流行的GitHub仓库：

“内部员工和外部合作伙伴的编码代理会话......[以及]符合星级计数阈值的公共GitHub仓库。”

如果你想让模特在你的工具上变得更好：确保它们真的很受欢迎，或者去实验室工作但经常失败。