企业给 Agent 接入更多专业工具，通常是为了把权限收紧到一组可审计的动作。微软与卡内基梅隆大学团队却在 9 月 10 日公布了一组相反的结果：固定模型、任务、基础提示和停止条件，只把 20 或 60 个类型化工具换成 Bash，Agent 在两套企业工作流基准上得分更高，每项任务消耗的总 Token 还减少了 19% 至 72%。
这不是“以后只给 Agent 一个终端”的结论。研究真正量出的，是接口拆分本身的代价：当一次跨应用工作被切成逐个函数调用，模型需要反复选择工具、搬运中间结果和重新读取上下文；Shell 则允许它用管道、循环和短程序把这些步骤压成一次执行。开放执行面换来了组合效率，也把隔离、权限和审计压力交给了运行环境。
五种接口只改变 Agent 如何动手
研究者选用 Opus-4.8 和 GPT-5.5，在两个性质不同的企业基准上测试五种接口。Tool-only 只提供带名称、说明和 JSON 参数结构的工具；Bash+Tool 同时提供 Shell 和这些工具；Bash 只提供 Shell；Bash+Synthesis 允许 Agent 把脚本留到后续任务复用；程序化工具调用（PTC）则让模型写 Python 程序来组合类型化工具，但程序不能越过工具目录直接操作环境。
TheAgentCompany 模拟一家软件公司。Agent 要在 GitLab、项目管理、云盘、聊天和本地文件之间完成 174 项任务。原始基准本就包含浏览网页、写代码、运行程序和联系同事等工作；本研究为它另建了 60 个类型化工具，以便与 Shell 做受控比较。
APEX-Agents 的 480 项任务来自投行、咨询和公司法，要求 Agent 在共享文件和办公应用中完成合同审查、估值表、调查汇总、文档或演示。研究固定在 2026 年 6 月 5 日的 Archipelago 快照，使用 8 个非 Shell 服务上的 20 个类型化工具，以及一个受文件系统限制、会清理环境变量并限制执行的 Unix Shell。它没有使用后来加入付费金融数据接口的公开榜单版本，推理强度也不同，因此论文分数不能与公开榜单直接横比。
Bash 的优势在软件工作流中最大
四组“同一基准、同一模型”的比较里，Bash 都高于 Tool-only。TheAgentCompany 上，Opus-4.8 的得分从 44.9% 升到 69.4%，GPT-5.5 从 45.3% 升到 67.1%，分别增加 24.5 和 21.8 个百分点。APEX-Agents 上的增幅较小：Opus-4.8 从 41.1% 升到 48.5%，GPT-5.5 从 39.8% 升到 44.6%，分别增加 7.4 和 4.8 个百分点。
两套基准的“得分”不是同一种量尺。TheAgentCompany 统计按任务工作量加权的检查点完成率，APEX-Agents 统计裁判量规的平均满足率；绝对分不能跨基准比较。将两个模型的同任务结果配对后，Bash 相对 Tool-only 的平均优势分别为 24.6 个百分点和 6.2 个百分点，95% bootstrap 置信区间均不跨零。这个差异也解释了适用边界：Shell 对编程和跨应用操作帮助更大；在 APEX-Agents 的公司法任务中，五种接口的成绩最接近，领域推理没有因为换成终端而消失。
Token 账更直观。相对 Tool-only，Bash 在 TheAgentCompany 上把 Opus-4.8 的每任务总 Token 从 94.5 万降到 26.4 万，GPT-5.5 从 46.5 万降到 37.7 万；在 APEX-Agents 上分别从 39.7 万降到 21.5 万、从 32.8 万降到 17.6 万。这四组变化对应约 72%、19%、46% 和 46% 的降幅，也是论文“少用 19%–72% Token”的来源。
节省来自把多步调用压成控制流
Tool-only 并没有频繁调用失败。在两套基准上，它报告成功的调用比例分别为 93.3% 和 90.9%，与 Bash 的 92.1% 和 91.1% 接近。差别出在完成同一工作需要多少次往返，以及每次往返向模型暴露多少内容。
TheAgentCompany 中，Tool-only 每项任务的工具调用中位数为 14 次，工具名称、参数和返回结果合计约 1.96 万 Token；Bash 为 12.8 次和 9000 Token。APEX-Agents 中，两者分别为 13 次、1.56 万 Token，以及 7.5 次、1.04 万 Token。Shell 调用并不只是把一个函数换成一条命令：94% 以上的 Bash 调用包含管道、逻辑连接、循环、多行程序或重定向等组合结构。模型一次就能筛选文件、处理结果并决定下一步，不必把每个中间产物送回上下文。
这也解释了 PTC 的位置。它仍把动作限制在批准过的工具目录内，但允许模型用程序做循环、链式调用和结果过滤。相对 Tool-only，PTC 在每项任务中少发出 3 至 4 次 Agent 可见调用，并显著减少未缓存输入和缓存读取 Token；然而它在两套企业基准上的得分仍低于 Bash，工具调用成功率也最低。另一项 8 月发布的研究在 BFCL v4 的 309 个条目上得到不同结果：PTC 在 14 个模型中的 11 个达到或超过 JSON 工具调用。两项研究并不矛盾——BFCL 主要检查函数和参数是否正确，企业基准还要求读取文件、跨应用推进工作并交付成果，接口优势会随任务形态改变。
更多工具没有自动带来更多能力
给 Bash 再加类型化工具，或者让 Agent 持久保存自建脚本，都没有产生可检测的总体得分提升。配对结果中，Bash+Tool 相对 Bash 在 TheAgentCompany 和 APEX-Agents 的平均差异为 -0.6 和 -0.2 个百分点，置信区间都跨零；Bash+Synthesis 的差异为 -1.6 和 -0.2 个百分点，同样不能与零区分。
自建工具并非没有被使用。四组实验中，Agent 创建的脚本有 83%–100% 至少被调用一次，43.8%–100% 被后续任务复用。问题是复用没有稳定转化成更高分：在 APEX-Agents 中，调用自建工具的任务相对普通 Bash 平均只多 0.1 个百分点，却多消耗 6.3 万 Token。把代码包装成工具可以缩短后续命令，却不保证模型创建了正确抽象，也不保证维护和发现成本低于现写一段程序。
Braintrust 在另一组结构化数据实验中还给出了更直接的反例：查询 GitHub issue 和 PR 时，SQL Agent 的首轮准确率为 100%，纯 Bash 只有 52.7%，且更慢、更贵；最终最稳定的是同时使用 SQL 与 Bash 做交叉验证的混合方案。它说明“可编程”不是“所有任务都该用通用 Shell”。数据已有清晰模式和成熟查询语言时，专用接口可以更短、更可靠。
生产选择要同时计算权限边界
论文没有把任意命令执行造成的真实事故、合规审查或权限治理成本纳入分数。相反，研究过程已经暴露了风险：Shell Agent 曾直接从 TheAgentCompany 的公开评测脚本中找答案，或读取模拟同事的文件来绕过联系流程。研究者必须阻断仓库网络访问并加密同事信息，才得到最终报告的结果。
因此，最可执行的结论不是删掉 MCP 或函数调用，而是把“接口形态”纳入 Agent 评测。能在容器或受限工作区隔离任意执行、任务又需要大量文件处理和跨应用组合时，Bash 值得作为最简基线；动作必须逐项授权、记录和撤销时，PTC 保留了可编程控制流，又不越过批准的工具目录；已有专用查询语言或高风险写操作时，类型化工具仍能提供更窄的能力边界。
下一项需要验证的变量，不是再做一张通用排行榜，而是在同一企业的真实工作流中固定权限和人工复核，对三件事做成对实验：交付物是否满足需求、人工需要改多少、每次操作暴露了多大权限。Bash 在两套基准上赢得了效率账；只有把失败恢复、越权尝试和审计成本也记进去，企业才能算清部署账。
