微软与CMU企业级Agent实测：不是工具越细越好，一个纯Bash最高涨分24点还省72%Token
Is Bash All You Need? An Empirical Study of Tool Interfaces for Enterprise Digital Worker Agents
在为企业级智能体（Digital Worker Agents）构建基础设施时，工程界长期存在一种直觉：针对企业日常使用的内部系统、即时通讯工具、云盘和专业文档，应当设计一套类型明确、语义严谨的结构化工具目录（Typed Tool Catalog）。开发者倾向于把每一个具体操作包装成类似 OpenAPI 或 JSON Schema 的独立函数，以此限制模型的行为边界，并保证调用的确定性。然而，来自卡耐基梅隆大学（CMU）与微软研究院的最新实证研究，却给这种传统设计打出了一个巨大的问号。
ArXiv URL：https://arxiv.org/abs/2609.11999
这项研究直接切入当前智能体系统设计的核心矛盾：在处理涵盖跨应用协调、代码维护、投资银行财务建模以及法律合同分析等复杂的真实企业工作流时，究竟是精细定制的专属工具目录更好，还是直接给大模型一个最基础的通用命令行环境（Bash Shell）更管用？
研究人员在两个高难度企业工作流基准测试中，使用最顶尖的前沿模型（Claude-3.7-Sonnet 级别演进的 Opus-4.8 与 OpenAI GPT-5.5）系统评测了五种不同的工具接口架构。实验给出了极为反直觉却一致的结论：仅仅给大模型提供一个纯粹的 Bash 终端，其最终任务完成质量就全面碾压了传统的类型化工具目录。在软件工程与办公协作基准 TheAgentCompany 上，纯 Bash 接口将任务得分拉升了 21.8 到 24.5 个百分点；在专业金融与法律咨询基准 APEX-Agents 上，也实现了 4.8 到 7.4 个百分点的提升。更关键的是，纯 Bash 方案在大幅提高得分的同时，总 Token 消耗量降低了 19% 到 72%。而行业内备受追捧的“持久化工具自合成（Tool Synthesis）”或“给 Bash 搭配额外工具”，在统计上均未带来任何显著的超额收益。
五种工具接口的真实对决
为了厘清大模型与环境交互的最佳介质，该研究定义了五种主流交互范式，并在保持底层模型推理级别、停止条件以及初始提示词完全一致的前提下进行了受控对照。
第一种是行业最通用的纯类型工具接口（Tool-only）。环境向模型暴露一套严格类型化的 JSON 格式工具库，模型每次想要执行动作，必须生成标准的参数化函数调用，环境返回执行结果后再进入下一轮推理。
第二种是Bash 结合类型工具（Bash+Tool）。模型既拥有任意执行命令的 Shell，又保留了原先的结构化工具目录，试图探究“既要自由度、又要专业封装”能否实现强强联合。
第三种是纯 Shell 接口（Bash-only）。系统彻底剥离任何专门注册的工具函数，模型面对的是一个纯净的 Linux 命令行环境。无论是抓取企业内网聊天记录、读取特定格式表格，还是跨服务通信，大模型都必须自行调用系统原生命令（如 curl、jq、awk、grep）或就地编写执行脚本。
第四种是带持久化工具合成的 Shell 接口（Bash+Synthesis）。模型不仅有 Bash 权限，还被赋予了一个跨任务持久化的工具代码目录。系统在提示词中鼓励模型将可复用的逻辑沉淀为脚本，希望在后续任务中直接调用以减少重复试错的认知负荷。
第五种是当下主流大模型厂商（如 Anthropic 与 OpenAI）近期主推的受限编程式工具调用（Programmatic Tool Calling，简称 PTC）。PTC 试图在安全与效率之间寻找折中：它不给模型任意执行 Bash 的高危权限，而是允许模型用 Python 编写控制流代码（包含循环、分支与数据聚合），但在运行时环境中，所有对外的环境操作仍然被严格限制在类型化工具目录内。
这些接口并不是在玩具用例中测试，而是直接推向了两个极具代表性的企业仿真场景。
TheAgentCompany 模拟了一个完整的软件科技公司内部生态。智能体需要使用 Git 管理代码库、与基于大模型模拟的跨职能同事就产品需求在聊天频道里异步沟通、调用内网服务、诊断持续集成流水线故障。
APEX-Agents 则覆盖了投资银行、管理咨询与大型企业法务部门的高难度专业分析。智能体必须在一个包含数十个复杂业务文件的共享工作空间内穿梭，编写高难度财务三张表建模、审计合同中的违约条款、跨多个工作簿合并财报，并生成格式严苛的交付物。
纯命令行何以全面碾压类型化工具？
在两套基准和两个基座模型的完全交叉评测中，纯 Bash 方案在每一组对照中都稳定击败了无 Shell 的接口。
这种优势不仅体现在得分的大幅提升上，更直观反映在端到端的工程效率中。在 TheAgentCompany 测试中，纯 Bash 方案直接把类型工具接口打得毫无还手之力，平均得分拉开了 20 多个百分点的断层差距；在 APEX-Agents 这种长文档与复杂文件处理场景中，纯 Bash 依然稳步提升了近 5 到 7 个百分点。与此同时，纯 Bash 智能体的推断成本（基于 GitHub Copilot 官方标价估算）全面下降，整体耗时明显压缩。
为什么最原始的命令行，反而能把精细定义的 API 打得落花流水？通过深入追踪模型调用轨迹，研究人员发现了底层交互机制的根本差异。
核心瓶颈在于交互轮次膨胀与上下文污染。在传统的 Tool-only 模式下，大模型想要完成一系列连贯操作，必须经历机械的“模型输出调用请求 $\to$ 环境返回结果 $\to$ 结果塞入上下文 $\to$ 下一轮模型推理”循环。比如，为了从一份包含数万行数据的日志中提取特定错误，Tool-only 必须调用一次文件读取接口，把可能长达数千 Token 的原始文本强行塞回上下文窗口，再由模型二次思考发起下一次调用。
这就导致 Tool-only 接口展现出了全场最高的“完全重复调用率（Exact-repeat Rate）”：模型极易因为前序返回内容冗长而在后续步骤中陷入局部死循环，多次发起一模一样的调用。
相比之下，前沿大模型早已在海量预训练中将 Bash 掌握为其原生“行动语言”。在拥有 Bash 权限后，大模型展现出了极其强大的组合执行能力：
- 在代码与服务协作场景中，大模型会频繁使用 Linux 管道、逻辑运算符（如
&&与||）、条件重定向以及组合工具链。它可以通过一行curl ... | jq ... | grep ...在系统底层就把无关字段过滤干净，最终只把几行关键诊断结果带入后续上下文。 - 在金融和法律场景中，大模型则倾向于在 Bash 中直接生成多行嵌入式 Python 分析脚本，直接把数个工作簿在本地加载进内存完成交叉核对，最后仅仅输出一个总结性的指标。
这种就地消化中间状态的能力，直接斩断了上下文滚雪球的恶性循环。TheAgentCompany 上的统计数据显示，纯 Bash 智能体的工具调用次数和调用占用的 Token 量比 Tool-only 缩减了一半以上。模型不用再反复被冗余的 API 响应结果稀释注意力，推理的连贯性自然水涨船高。
工具合成与混合接口的幻觉破灭
除了证明 Bash 的强悍，这项研究的另一个重大突破在于打破了学术界与工业界对两类“高级方案”的迷信：工具自合成（Tool Synthesis）与混合接口（Bash+Tool）。
近年来不少智能体本文提出，让智能体像人类工程师一样具备“沉淀经验”的能力：将常见子任务写成工具脚本存进持久化目录，后续任务直接复用，从而形成技能库闭环。
然而，严谨的双盲统计表明，在 Bash 基础上增加持久化工具合成，在汇总指标上完全没有带来任何统计显著的质量收益。
深入分析任务复用链路后可以发现，大模型确实能够自主封装工具，并且在当前任务的生命周期内会大量调用这些工具。然而，一旦进入后续的新任务，跨任务复用的比例就会发生断崖式下跌。在需要极强定制化策略的企业分析场景中，绝大多数任务的业务逻辑、数据边界、边缘异常完全不同，模型往往需要先花费宝贵的上下文去“理解自己之前写了哪些工具、参数要求是什么”。
这种重新探索和适配遗留工具的开销，不仅抵消了复用带来的微弱好处，甚至还经常因为早期工具写得不够鲁棒而将错误引入后续任务。事实上，当把任务按“是否真正跨任务调用了合成工具”进行子集切分时，使用自合成工具的子集往往伴随着更长的调试过程与更高的总 Token 消耗，最终在解题率上与纯 Bash 没有任何实质区别。
同样的尴尬也发生在混合接口（Bash+Tool）身上。原本工程团队设想，既有 Bash 自由发挥，又有精心封装的高阶 API 备用，智能体应该如虎添翼。但实验结果显示，Bash+Tool 的总得分不仅没有超越纯 Bash，反而由于同时将类型化工具的 Schema 与 Bash 指令集塞给模型，增加了指令路由阶段的决策熵。大模型经常在“我是该直接用 Shell 一行搞定，还是该规规矩矩构造一个复杂 JSON 参数去调那个专业工具”之间犹豫试错，平白浪费了步数与推理预算。
受限编程式调用的定位：安全合规的兜底妥协
如果纯 Bash 在效果与成本上具有压倒性优势，那是否意味着所有面向企业的智能体产品都应该直接开放 Shell？
答案是否定的。企业级数字员工的部署核心瓶颈从来不单单是学术基准分数，更是安全边界与合规性（Security & Compliance）。任意 Bash 执行意味着智能体在宿主环境里拥有极高的破坏潜力，包括未经审计的网络外发、底层文件系统的误删除、恶意代码注入以及跨租户越权。即便在严格的 Docker 容器中隔离，对绝大多数金融、医疗与企业核心法务系统而言，开放无受限 Shell 依然是安全团队不可逾越的红线。
这正是受限编程式工具调用（PTC）展现战略价值的地方。
PTC 的设计理念是不给 Shell 交互渠道，所有外部操作全部封装在合规审计通过的类型化函数内部；但同时，它允许智能体在受限沙箱里写一段 Python 代码来组织这些函数。比如在面对“遍历 50 家供应商的开票信息”时，Tool-only 必须让模型发起 50 次独立的网络往返调用，而 PTC 允许模型写一个 for 循环在运行时内部依次调用批准的只读函数，并将汇总结果一次性返回。
实验数据充分证实了 PTC 的工程妥协价值：
-
对比 Tool-only：PTC 展现出了肉眼可见的 Token 压缩效应。由于代码层面在沙箱内就地完成了过滤与控制流分发，大量中间数据没有漏入模型的提示词上下文，未命中缓存的输入 Token 和缓存读取 Token 均出现显著暴跌，同时完全排除了传统 Tool-only 容易出现的重复死循环现象。
-
对比 Bash-only：PTC 的综合任务得分和实际执行灵活性依然弱于纯 Bash，但它成功守住了安全防线——所有对环境的修改全部走过严格审计的类型化工具网关。
走向现实的工程决策框架
这项来自 CMU 与微软的实证研究，为今后企业级智能体系统的架构选型扫清了大量迷雾。面对具体业务场景，架构师不应再盲目追求“封装全套内部微服务 API”或“自研花哨的技能库自动沉淀系统”，而是应当建立极其务实的二元决策机制：
如果业务场景能够实现高度可靠的执行隔离——例如分配了临时不可变沙箱环境的离线编码任务、一次性投行研报草拟、企业离线数据归档清洗——纯 Bash 终端是目前最具性价比、得分最高且最优雅的底座接口。直接让前沿大模型调动 Linux 工具链去探索环境，效果远好于人类工程师预先定义的任何专有 API。
如果业务场景面临严苛的安全、权限隔离与合规审计约束——例如在线财务划转、客户生产环境敏感数据巡检、高权限人事信息变更——开发团队应当坚决放弃低效的传统单步 JSON 工具调用，全面转向受限编程式工具调用（PTC）。通过允许智能体在受限沙箱中以代码逻辑批量调度白名单工具，既能堵住任意命令执行的安全漏洞，又最大程度挽救了传统工具调用方案低下的上下文利用率。
在智能体演进的下半场，工具接口的设计哲学正在发生倒转：最先进的模型往往不需要人类事无巨细地为它铺设窄轨，一个古老、开放且通用的命令行 Shell，依然是大模型在这个数字世界里最得心应手的瑞士军刀。