最近整理了一下 Biny Agent 的工具系统。

给 Agent 增加一个工具其实不难：定义参数 Schema，注册工具，再实现执行函数。但接入 MCP、插件和各种扩展以后，工具数量越来越多，问题就变了。

只读一个文件，有必要把上百个工具的定义都交给模型吗？缺少能力时，模型能不能自己找到工具？不同来源的调用，能不能共用一套权限和执行机制？如果一次写入中途断线，又该不该重试？

我现在更关心的是，工具从被发现到真正产生副作用，中间的每一步能不能说清楚。

这篇文章就沿着这条链路，聊聊我在 Biny 中的实现和取舍。

最近 GPT-6.1 Sol 实在是有点慢，想着既然要等那么久，不如换 Kimi 试试，刚好搭配 Kimi Code 用了一下。

用的过程中发现，Kimi Code 的 Edit 设计和 Codex 不太一样。

Codex 主要采用 apply_patch，让模型通过 Patch 描述文件修改；而 Kimi Code 用的是传统的 old_string → new_string 字符串替换。

另外还有一个让我感兴趣的设计：Codex 在 GPT-6 Astra 上就已经使用 Code Mode 编排工具调用，GPT-6.1 Sol 也沿用了这种方式。 这并不是 Sol 才出现的新特性。

我个人感觉，这可能和模型能力的提升有关。模型越来越擅长编写代码和处理复杂的工具调用，Harness 也开始让模型承担更多的编排工作。

当然，Code Mode 和 Patch 并不是互相替代的关系，一个负责工具编排，一个负责文件编辑。

之前设计 Biny-Agent 的 Edit 时，我其实就思考过这些方案。借着这次使用 Kimi Code，重新翻了一遍源码，也顺便整理一下目前几个 Coding Agent 的设计区别。