前Manus后端负责人：我干了两年AI Agent，最后把Function Calling全扔了

peterll

【前Manus后端负责人：我干了两年AI Agent，最后把Function Calling全扔了】


快速导读：前Meta收购公司Manus的后端技术负责人，在构建AI Agent两年后得出惊人结论：别再用复杂的Function Calling了。LLM的原生语言其实是诞生于50年前的Unix命令行。本文揭示了为什么一个简单的`run(command)`工具，比庞大的专用工具库更高效、更符合LLM的“思维模式”。

---

前Manus（后被Meta收购）的后端技术负责人Morro Hsu，最近分享了一个他干了两年AI Agent后得出的、足以颠覆许多开发者常识的结论：他已经完全抛弃了主流的Function Calling。

取而代之的，是一个简单的`run(command=“...”)`工具，配上最古老的Unix命令行。

这听起来很反直觉。在OpenAI、Google等大厂的官方文档里，精细的、结构化的Function Calling/Tool Calling被奉为圭臬。你以为，给AI Agent的工具库越丰富、越结构化，它就越强大。

但现实是，LLM早已在数十亿行代码的训练数据中，把Unix命令行玩得炉火纯青。当你需要“读取日志文件，筛选出错误行，并计算总数”时，Function Calling的思路是三次调用：`read_file()` -

Hsu把这种模式总结为“启发式设计”，核心是三点：

1.  渐进式`--help`发现：Agent不需要一次性加载所有工具文档。它会像人类一样，先调用`memory`空命令看看用法，再用`memory search`探索具体参数。LLM按需探索，极大节省了宝贵的Context。

2.  把错误信息当导航：当Agent用`cat`命令试图读取一张图片时，传统的CLI只会报错。但Hsu的设计会返回：`[error] cat: binary image file. Use: see photo.png`。错误信息直接指明了正确的路，Agent下一步就知道该怎么做，而不是原地打转、盲目重试。他分享了一个惨痛案例：因为stderr（标准错误流）被静默，一个Agent为了安装一个包，在`pip`, `uv`, `apt`等命令间盲目重试了10次，浪费了大量时间和token。

3.  两层架构：这是最关键的工程洞察。命令的执行（执行层）和返回给LLM看的结果（表现层）必须分开。执行层追求Unix管道的原汁原味，数据无损传递。而表现层则为LLM服务：自动截断超长内容并告知其完整路径、将二进制文件替换为提示信息、附加上`[exit:0 | 12ms]`这样的元数据。这能防止LLM的Context被垃圾信息污染，并让它逐渐学会评估每个命令的成本。

这个思路不是要给Agent一个完整的Linux系统，而是要用LLM最熟悉、最原生的“语言”和它沟通。就像Hsu在讨论中回应的那样：Shell是超集。你永远可以从Shell里调用Python代码，但反过来，在一个纯代码环境里调用Shell命令，本质上只是给自己多绕了一段路。

---

简评：

这篇分享最牛的地方，是把一个看似“退步”的技术选择（用50年前的CLI代替时髦的Function Calling），升华成了一种更深刻、更符合AI第一性的设计哲学。它没有停留在“CLI更好用”的表面，而是解剖了“为什么好用”（训练数据吻合度、可组合性）和“如何才能好用”（渐进式帮助、导航式报错、分层架构）。其中“stderr是Agent最需要的信息”和“Shell是超集”这两个论断，堪称金句，点醒了无数还在工具集里打转的开发者。这是一种工程上的返璞归真。

---

ref: www.reddit.com/r/LocalLLaMA/comm ... ter_building_agents

##