我们为什么彻底移除了编码模式：让模型自己挑选工具

Agent! 的早期版本有几种模式：编码、自动化和标准。这个想法听起来很合理。编码任务用不到 Accessibility 工具，“点击这个按钮”这类任务也用不到 Xcode。把无关的工具藏起来，模型看到的工具列表更短，消耗的 token 更少，选错工具的情况也更少。

2026 年 4 月 7 日，提交 7ea44c0d 删除了整套模式系统。下面讲讲促成这一决定的 bug，以及它留给我们的原则。

模式是如何工作的

在任务的第二轮，运行框架会查看你的请求，并将其与两份关键词列表进行匹配。build、compile、edit、fix 和 refactor 这类词代表编码；click、button、window、photo 和 accessibility 这类词代表自动化。随后它会切换一个标志位，即 codingModeEnabled 或 automationModeEnabled，并把模型可见的工具收窄到该模式对应的工具组。模型也可以通过 mode 工具自行切换模式。

Bug：编码模式下的 Photo Booth

问题报告只有一句话：“accessibility 坏了。”原因用提交信息里的原话来说就是：自动切换逻辑把 open -a Photo Booth 视为未知信号，于是默认切换到了编码模式。编码模式排除了 Auto 工具组，而 accessibility 工具恰恰就在 Auto 组里。

于是，模型被要求拍一张照片，而唯一一个专门用来按下快门按钮的工具却在任务进行到一半时消失了。它做了一个能干的模型在剩余工具下会做的事：退而通过 shell 调用 osascript，结果不断失败，报错 "Can't get toolbar 1 of window 1."

模型本身没有问题，accessibility 工具也没有问题。是运行框架猜错了用户意图，并悄无声息地拿走了正确答案。

并不是修复的修复

最显而易见的补丁是把 open -a 加进自动化关键词里。提交信息直接指出了这一点：那只会是“一长串创可贴中的又一张”。基于关键词的意图识别是一场注定失败的游戏。每一个新应用、每一种新说法、每一门新语言都会带来新的漏洞，而每一次漏判都会以最令人困惑的方式失败：模型突然无法完成一件上一轮还能做到的事。

取而代之的是：什么都没有

整个模式系统被移除：涉及 13 个文件，删除 141 行，新增 39 行。其中包括：

• codingModeEnabled 和 automationModeEnabled 标志位及其工具组列表
• 主任务循环和标签页任务中的第二轮自动切换
• predictToolGroups()，即根据提示词猜测工具组的函数
• Claude 及 OpenAI 兼容服务中针对本地端点的工具列表收窄
• 子代理的 coding 和 automation 别名（现在改为直接传入真实的工具组名称）

现在，工具仅由你自己的开关在设置（ToolPreferencesService）中进行过滤。你启用的每个工具在每一轮都可用，由模型自行挑选所需的工具。

有两个小细节体现了这类删除工作中的用心。mode 工具并没有被直接移除，而是变成了一个空操作，回复 "mode switching has been removed"，因为上下文中带着旧对话的模型可能仍会调用它，一个明确的回答总比“未知工具”错误要好。此外，系统提示词的修订版本号从 71 升到了 72，这样磁盘上保存的任何提及模式的提示词都会被重新同步。

结果

不再有 "Coding mode auto-enabled" 日志刷屏。不再有工具在任务中途消失。工具列表也不再在各轮之间来回变动。

原则

这个决定深刻影响了后续的许多设计，因此值得明确地说出来：

运行框架应当强制保障安全，而不是去猜测意图。

Agent! 在有客观标准的地方非常严格。它会拒绝灾难性的 shell 命令、拒绝编辑模型尚未读取过的文件，也会拒绝没有证据的“完成”。这些都是可以核查的事实。而一个任务需要哪个工具，则是一种判断，模型在这方面比关键词列表更擅长。当运行框架在判断问题上否决模型时，它会以静默且令人困惑的方式失败；而当它执行可核查的规则时，失败会是明确的，并且附带原因。

如果你正在构建一个代理，你可能会忍不住想通过精简选项来“帮助”模型。请先做测量。稍长一点的工具列表只会多花几个 token，而缺少一个工具可能会让你赔上整个任务。