在过去的几周时间里，Anthropic公司的Thariq，和几十家从事通用智能体制作的公司，举行了电话会议，这些公司所涉及的产品形态多样，有邮件助手，有客服机器人，还有日程管理等。在完成这一圈交流之后，他发觉自己不断地重复说着相同的一句话。
巴什？那难道不是供程序员所使用的命令行工具呀，跟这些产品究竟有着什么样的关系呢？
先看一个具体场景。
要是假定你存在一个邮件代理，你向它发问，这周你于打车这件事上耗费了多少金钱？
按传统做法来讲，是这样的，Agent会去调用API来拉取邮件，有可能会一次性把100封邮件给取回，之后让模型从这些邮件当中去找出Uber、Lyft的收据，并且对金额进行加总。
这个问题是，将100封邮件放入上下文里后，模型需要同时把这些内容记住，接着从中进行筛选，还要做到计算。对于大语言模型而言，这可不是件轻松的事。它很容易出现遗漏，也容易产生错误，并且你没办法去验证它究竟看了哪些邮件。
这属于那种典型的模型舒适区有关的问题，数据量并非大到非得专门去写程序来处理的程度，然而却又超出了模型能一次性直接硬算的能力范畴，处于这样的状况之间，着实很是尴尬。
Thariq所提出的方案是，给予Agent一个Bash工具，使得它能够将中间结果存储成为文件。
听起来很简单，但背后的逻辑很有意思。
传统的工具调用是这样的流程：
工具 → 模型处理 → 输出结果
所有中间状态都在模型的“脑子”里，你看不见，也没法检查。
换成 Bash 之后，流程变了：
工具，进行存文件这项操作，之后开展搜索或是过滤，再接着进行模型处理，最后得出输出结果。
模型能够先将100封邮件存储至一个文件之中，接着运用grep搜索“Uber”，随后再运用grep搜索“Lyft”，并分别进行统计。每一个步骤都存在可循的踪迹，在最后进行加总之时，它还能够回过头去检查自身的中间结果。
这带来三个能力升级：
能够进行复现，把相同的命令再次运行一回，所得到的结果是相同的，你能够开展调试工作，能够去排查存在的问题。
它是能够被验证的，模型并非借着“记忆”来给予你答案，而是依据实际文件当中的数据，倘若你不信任的话，你自己也是能够将文件打开瞧一瞧的。
可以组合，一个命令所产生的输出能够当作下一个命令所需的输入，管道连接之后，复杂的任务便能够被拆解成为多个简单步骤。
Bash促使那么个Agent，硬是从那种“脑算”的状态，转变成为了“打草稿”。这“打草稿”呢，能够留下痕迹，能够对此去进行检查，还能够加以修改。而这对于那些有着准确性需求的任务来讲，实在是太具重要意义了。
邮件搜索只是最直观的例子。Bash 的能力边界其实很宽。
链式 API 调用属于常见需求，像“找出这周我发送过邮件的联系人”这种情况，要先拉取邮件列表，接着提取收件人，然后进行去重，之后再逐个查询联系人详情。这一连串操作若用 Tool calls 来做，调用次数众多，中间状态难以管理。而用 Bash 脚本串起来，逻辑会清晰许多。
视频处理是Bash的强项之所在，文件处理同样也是Bash的强项之所在。ffmpeg这个工具是命令行工具，在模型方面使用起来能够让使用者感觉得心应手。寻找视频里的某个片段，进行裁剪操作，进行转码操作，通过一行命令便能够将这些操作搞定。
有的是定时任务，于Agent运行的容器当中，借助cronjob或者at命令，能够去创建定时执行的任务，用户称“每天早上8点给我发一份新闻摘要”，Agent能够自行设定好闹钟。
这些场景存在着一个共同之处，这个共同之处体现为：一方面有着要求多部连续性序次操作的情况，另一方面有着需要留存中间过程状态这样的状况，同时还存在着超越单次工具运用调用所具备的能力范畴的情形。
但 Bash 是把双刃剑。
意味着能做诸多事才表明能将命令予以执行，意味着能做诸多危险之事同样表明能把命令予以执行，但 rm ，rf ，一不小心便会将整个目录毫无保留地删得一文不剩。要是 Agent 遭受恶意提示词展开的攻击，那后果极有可能会变得相当严重。
Anthropic明显是把这一点给考虑到了，他们于Claude Agent SDK当中制作了一套权限系统，该系统涵盖了Bash命令解析器以及分级权限控制，对于哪些命令能够直接去执行，哪些命令是需要用户进行确认的，哪些命令是完全被禁止的，这些情况都是能够进行配置的。
关乎我运用 Claude Code 的所感所得而言矣，此一整套权限体系实实在在削减了心理层面的负担，它于执行敏感类操作之前会向你进行询问，并非一味地闷头径直去做，然而安全防护的这一手段并非是包治百病的万应良药，权限系统自身兴许存在着漏洞，Bash 解析器同样有可能被设法绕过。
安全护栏是必需品，但不能因此就觉得万事大吉。
强调 Bash 的好处，也得说清楚它的边界。
要是任务足够简易，就别采用，像“今天天气怎么样”这般一次性的查询，直接去调用 API 进而返回结果便可以，并没有必要去存储文件之后再予以处理，用杀只鸡的方式却动用杀牛的刀反而更加迟缓。
要是环境属于Serverless这种类型，那就没法使用了。好多云函数运行的时候，并没有能够进行持久化操作的文件系统。如此一来，Bash所具备的那种“存储中间结果”的优势也就不复存在了。
要是对于安全方面的要求极其高，那就得谨慎去使用。命令注入所存在的风险没办法完全消除掉，金融、医疗这类场景或许更适宜采用白名单样式的专用工具，而不是通用的Bash。
场景决定工具的选择，而非工具自身的强弱状况所决定。Bash具备很强的能力，然而并非在所有的场合之中都应当被采用。
当我们回过头去看的时候，Thariq所提出的这条建议，其真正具备的价值并非是“Bash很强”这样的一个结论，而是在这个结论背后所蕴含的思维方式：
让 Agent 的思考过程“落地”到可检查的中间产物。
过往一贯的 Agent 设计做法是，将啥都一股脑儿地塞到模型的上下文里，搞的是一次性的交易。而 Bash 给出了迥异的另一途径，它是把繁杂艰巨的任务进行拆分，每一个步骤都会留存下踪迹，既能够加以验证，还能够进行回溯。
想想看，这跟人类去处理复杂问题的方式是多么相像啊。我们在执行复杂计算这个行为的时候，会采用列竖式这种做法，当着手去写长文章之际，会先拟定提纲。在面对处理大量信息这种情况之时，会去做笔记。并非是由于脑子没办法记住，而是因为放置到纸上会显得更为可靠，并且更加易于进行检查。
同理，Agent 也是如此。并非是模型无法处理，而是有着中间产物的流程更具可信度。我运用 Agent 来辅助写作，所有的中间产物都会被保存为文件，这其中包括网络检索的资料、提纲、不同版本的草稿以及画图的提示词。这些被保存下来的内容便于后续进行灵活的组合。
Bash 并非仅仅是程序员所使用的工具，它更是促使 Agent 拥有可验证能力的关键部分，还是让 Agent 具备可复现能力的关键环节，更是使得 Agent 拥有可审计能力的关键要点。