"工程返璞归真"：LLM 的原生语言，其实是 50 年前的 Unix 命令行

做 AI Agent 的开发者，几乎都经历过这个阶段：

刚开始很兴奋，按官方文档的套路写 Function Calling，定义 JSON Schema，给每个工具写描述，精心设计参数。工具库越来越丰富，代码越写越多。然后发现 Agent 的行为越来越奇怪——它会在三个工具之间死循环，会传错参数，会不知道什么时候该用哪个工具。

调试起来痛苦至极。你不知道 LLM 脑子里在想什么，只能靠猜。

有人干了整整两年，最后给出了一个答案：把 Function Calling 全扔了。

···

这个人叫 Morro Hsu，曾任 Manus 后端技术负责人。Manus 是去年大火的 AI Agent 创业公司，你可能还记得它刚发布时的刷屏。

Hsu 上周在 Reddit 上发了一篇长文，分享了他两年来构建 AI Agent 后得出的一个反直觉结论：

LLM 的原生语言，不是你精心设计的 JSON Schema，而是 50 年前的 Unix 命令行。

这话听起来像在开玩笑。但他用了大量具体案例说明，这不是怀旧，而是一种更深层的工程哲学。

Function Calling 的隐藏成本

表面上看，Function Calling 优雅极了。你定义工具，模型理解意图，精准调用，返回结构化数据。OpenAI、Google、Anthropic 的官方文档都把它当作 Agent 开发的标准范式。

但 Hsu 发现，这套范式有几个隐藏成本，会随着工具数量的增加线性放大：

第一，Context 爆炸。每个工具都要塞进 System Prompt——名称、描述、参数定义、使用示例。十个工具还好，五十个工具就开始让你抓狂。而 Agent 在任意时刻可能只会用到其中两三个，但所有工具的描述都在消耗宝贵的 Context 窗口。

第二，错误恢复困难。当工具调用失败，返回的是机器友好的错误代码，不是 Agent 友好的导航信息。LLM 不知道下一步该怎么做，开始盲目重试。Hsu 分享了一个真实案例：因为 stderr（标准错误流）被静默，他们的 Agent 为了安装一个包，在 pip、uv、apt 三个命令之间来回尝试，一共盲目重试了 10 次，浪费了大量时间和 token。

第三，LLM 在装自己不熟的东西。你设计的 JSON Schema 是新的，LLM 没见过，每次调用都要靠提示词来"教"它。但它在训练数据里见过海量的 Unix 命令——ls、cat、grep、pipe，它对这些的理解深入骨髓。

···

一个工具替代所有

Hsu 的解决方案极简：

run(command="...") 

就这一个工具。

你需要读文件？run(command="cat README.md") 你需要搜索内容？run(command="grep -r 'error' ./logs | tail -20") 你需要安装依赖？run(command="pip install requests || apt-get install python3-requests") 你需要处理数据？run(command="jq '.users[] | select(.age > 18)' data.json")

LLM 不需要学习新工具，它本来就会这些。它把整个 Unix 环境当作一个巨大的工具库，按需组合，随用随取。

但光是把 Function Calling 换成 shell 命令，还不够。Hsu 提炼出了三条让这套方案真正好用的工程洞察。

三条工程洞察

洞察一：渐进式 --help 发现

传统做法：把所有工具的文档全塞进 System Prompt，Agent 一次性获得所有信息。

问题：Context 浪费严重，而且 LLM 不一定记得住。

Hsu 的做法：让 Agent 像人类一样探索。

你不会在开始一个任务前，先把整本工具手册背下来。你会先执行 git --help 看看有什么命令，发现你要用 git log，再执行 git log --help 看具体参数。

把这个模式内化进 Agent 的行为里：它不需要一次性知道所有工具的用法，按需探索，用到哪里学到哪里。Context 只消耗真正用到的部分。

这个设计还有一个意外收获：Agent 会主动去探索工具的边界，而不是被动地等你告诉它能做什么。

洞察二：错误信息是最好的导航

这条洞察看起来最"小"，但 Hsu 认为是最关键的。

传统的 CLI 遇到错误会返回让人头大的英文报错，或者干脆静默失败。这对人类已经够折磨的了，对 AI Agent 更是噩梦。

Hsu 的设计：把错误信息改造成下一步行动的指引。

比如，Agent 用 cat 命令试图读取一张 PNG 图片：

传统输出：cat: binary image file: cannot read

Hsu 的输出：[error] cat: binary image file. Use: see photo.png

一行错误，直接告诉 Agent 下一步怎么做。不需要额外的逻辑，不需要工具调用，错误本身就是导航。

回到那个 10 次盲目重试的案例：如果 stderr 没有被静默，第一次 pip install 失败时，错误信息里就会有"permission denied, try sudo"或者"package not found, try apt-get"这样的提示。Agent 第一次就能走对路。

stderr 是 Agent 最需要的信息，却往往是最容易被忽视的部分。

洞察三：执行层和表现层分离

这是最有工程深度的一条。

你的 Agent 系统里，命令的执行和命令返回给 LLM 的结果，必须是两个独立的层。

执行层：追求 Unix 管道的原汁原味。命令怎么跑就怎么跑，数据无损传递。不要在执行层做任何过滤或转换。

表现层：为 LLM 服务。负责三件事：

1. 截断：把超长输出截断，但附上完整输出的路径。LLM 看到的是"输出已截断，完整内容在 /tmp/output_full.txt，共 2847 行"，而不是把 2847 行都塞进 Context。
2. 转换：把二进制文件替换成对 LLM 有意义的提示信息。不是报错，是有效信息。
3. 元数据：在每次命令结果后附加 [exit:0 | 127ms] 这样的元数据。

最后这一条看起来不起眼，其实很关键。知道一个命令跑了多少毫秒，LLM 会逐渐学会"这个命令很慢，能不用就不用"，"这个命令很快，可以多调用几次做验证"。它在建立一种对计算资源的直觉。

为什么这套方案有效

不只是因为"Unix 命令简单"。更深的原因是训练数据的吻合度。

LLM 是在大量代码、技术文档、Stack Overflow 问答上训练的。这些数据里充满了 Unix 命令、Shell 脚本、管道操作。它见过的 grep | awk | sed 组合，比见过任何一个特定工具的 JSON Schema 都多得多。

你在用 LLM "最擅长的语言"和它交流。

另一个优势是可组合性。Unix 的 pipe 哲学——每个命令做一件小事，通过管道组合成复杂操作——和 LLM 的任务分解思路天然吻合。cat error.log | grep "ERROR" | sort | uniq -c | sort -rn，这一行命令里包含了四个原子操作的组合，LLM 既能读懂，又能自己写出来。

Hsu 说得很直接：Shell 是超集。你永远可以从 Shell 里调用 Python，但在纯 Python 环境里调用 Shell，本质上是给自己多绕了一段路。

什么情况下还需要 Function Calling

这不是说 Function Calling 一无是处。

有些场景它仍然是更好的选择：

• 调用外部 API：HTTP 请求、第三方服务、需要鉴权的接口，CLI 不擅长这个
• 强类型约束：当你需要 LLM 输出严格符合特定 JSON 结构时
• 安全隔离：不希望 Agent 执行任意命令的场景
• 非技术用户：最终用户不是开发者，不能暴露 Shell 环境

一个实用的判断标准：如果你的 Agent 主要在做"技术操作"——读写文件、处理数据、调试代码、管理环境——用 Unix CLI 方案。如果主要在做"业务集成"——对接 CRM、发邮件、查订单——用 Function Calling。

写在最后

有意思的是，这个"新发现"其实建立在五十年前的设计智慧上。Unix 的那一批工程师设计管道的时候，根本不知道 LLM 是什么。但他们造了一套可组合、可探索、失败友好的工具体系，恰好和今天 LLM Agent 的需求高度吻合。

这种"工程返璞归真"的路径，在 AI 领域正在越来越常见。不是让 AI 去适应人类设计的接口，而是找到 AI 天然擅长的交互方式。

Function Calling 的出现解决了很多问题，但它的复杂性被严重低估了。Hsu 这篇帖子，表面是一个技术选择，底下是对"Agent 应该和工具怎么沟通"这个问题的重新思考。

你在做 Agent 吗？这套 Unix CLI 方案你觉得实用吗？在评论区聊聊你的经验。

···

参考资料：Reddit r/LocalLLaMA，作者：Morro Hsu（前 Manus 后端技术负责人）