推文 · 热度

宝玉 @dotey

“你们应该多用 Bash。”

过去几周，Anthropic 的 Thariq 和几十家做通用智能体的公司开了电话会议。邮件助手、客服机器人、日程管理——各种产品形态都有。聊完一圈，他发现自己反复在说同一句话。

Bash？那不是程序员用的命令行工具吗，和这些产品有什么关系？

先看一个具体场景。

假设你有一个邮件 Agent，你问它：“这周我在打车上花了多少钱？”

传统做法是这样的：Agent 调用 API 拉取邮件，可能一次性取回 100 封，然后让模型从里面找 Uber、Lyft 的收据，加总金额。

问题在于 100 封邮件塞进上下文，模型要同时记住这些内容，从中筛选、计算。这对大语言模型来说并不轻松。容易漏，容易错，而且你没法验证它到底看了哪些邮件。

这就是典型的模型舒适区问题：数据量不算大到需要专门写程序处理，但又超出了模型一次性硬算的能力范围。夹在中间，很尴尬。

Thariq 的方案是：给 Agent 一个 Bash 工具，让它把中间结果存成文件。

听起来很简单，但背后的逻辑很有意思。

传统的工具调用是这样的流程：

工具 → 模型处理 → 输出结果

所有中间状态都在模型的“脑子”里，你看不见，也没法检查。

换成 Bash 之后，流程变了：

工具 → 存文件 → 搜索/过滤 → 模型处理 → 输出结果

模型可以先把 100 封邮件存到一个文件里，然后用 grep 搜“Uber”，再 grep“Lyft”，分别统计。每一步都有迹可查，最后加总的时候，它还能回头检查自己的中间结果。

这带来三个能力升级：

可复现。同样的命令再跑一遍，结果一样。你可以调试，可以排查问题。

可验证。模型不是凭“记忆”给你答案，而是基于实际文件里的数据。你信不过的话，自己也能打开文件看一眼。

可组合。一个命令的输出可以作为下一个命令的输入，管道一接，复杂任务就能拆成简单步骤。

Bash 让 Agent 从“脑算”变成了“打草稿”。草稿可以留痕，可以检查，可以改。这对需要准确性的任务来说太重要了。

邮件搜索只是最直观的例子。Bash 的能力边界其实很宽。

链式 API 调用是个常见需求。比如“把这周我发过邮件的联系人都找出来”，这需要先拉邮件列表，提取收件人，去重，再逐个查询联系人详情。一连串操作用 Tool calls 来做，调用次数多，中间状态难管理。用 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 具备可验证、可复现、可审计能力的关键一环。

nekocode @nekocode_cn

一点心得，harness engineering 的本质是「熵减」。

而代码优于 prompt 约束，尽量把所有流程、约束，收敛到更稳定、有序的代码层去实现。

这也是 skills（agent 时代的 app）原生支持 scripts 的核心逻辑所在。

nekocode @nekocode_cn

提问: AI 创业的话，Agent as a Service 可行不？🤔

shinnyChen @shinny__Chen

别说，还真是

nekocode @nekocode_cn

关于这里，我的看法不一样 👀

在我看来 subagent 要解决的，还是「上下文」这个老难题。因为 llm 的上下文容量和注意力都是有限的，用不同的上下文来处理不同的任务是目前工程上的最优解。

而 subagent 在这里的核心价值就是上下文隔离，也是原 up 说到的，防止不同任务之间上下文互相污染。因为某段上下文对某个任务来说可能非常有用，但是对另一个任务来说可能就是噪音了。

你提到的类比成 thread/coroutine/worker，我感觉表象上确实是这样，但是核心要解决的问题可能不一样。

lcomplete @xlcomplete

有趣，太有趣了。

这个思路太棒了，让 Agent 访问数据库比访问文件系统更高效。

一看到这条推文，我的脑回路立刻就被激活，思路一下子打开了。

1、很早之前就被 Agent 从数据库查数据的能力给震惊过，Agent 只要能连对应的数据库，不需要提供表名等信息就能找到你想要的东西，也能轻松搞定数据统计和分析。
2、我在实现 huntly 的知识库对话功能时想过两个方案：markdown 和 mcp，却从来没想过让 agent 直接去数据库里查。

要让「知识库对话」更顺畅一些，只需要再结合时下流行的 skills，写一个 markdown，大致让 AI 知道 huntly 数据库是干嘛用的，以及一些关键数据要怎么查询就可以了。

换个角度，整个事情变得如此简单。

用我最近常说的句式来收尾，huntly 的含金量又变高了。😋

A2GUI @A2GUI

@buaaxhm 不可能。GPU都没人给他