比 Function Calling 更重要的，是给 Agent 一条能自我修正的命令行

这条讨论串最容易被错误转述成一句口号：别做 function calling 了，直接给 Agent 一个 run(command="...")。如果只看标题，这个结论确实很像立场宣言；但把原帖和评论区一起看完，它更像一次接口设计复盘。

我自己的压缩版本是：原帖证明了统一命令入口、可组合操作和可恢复错误，对 Agent 非常重要；评论区补上的则是，别把这件事偷换成“typed tool 无用”。

原帖的核心论证其实很集中。第一，Unix 风格接口天然围绕文本、管道、退出码和 stderr 展开，而 LLM 最擅长处理的也是文本与模式组合。第二，与其让模型在一长串 typed functions 里做选择题，不如给它一个统一的命令入口，让它在同一套语义里继续组合和修正。第三，真正起作用的不只是 shell 本身，而是围绕 shell 设计出的 Agent 友好层。

作者提到的几个细节都说明了这点：让命令支持渐进式 --help，让报错本身给出下一步方向，把 exit code、耗时和 stderr 以稳定格式暴露出来，再把真正的执行层和面向模型的展示层拆开。这样做的目的，不是让 CLI 变酷，而是让 Agent 失败后仍然待在同一个心智模型里继续修。

换句话说，原帖真正反对的不是 typed interface，而是那种让模型不停切换上下文、又在失败后拿不到修正线索的接口。

评论区里最有价值的补充有三类，而且都在给原帖降温。

第一类补充认为“更少的工具”大概率是对的，但“只保留一个 run”未必必要。有人提到他们把 40 多个 typed functions 收缩到个位数后，多步任务的成功率就明显变好了。这说明真正的问题可能是工具数量和语义重叠，而不一定非要退回单一 shell。

第二类补充针对安全。有人分享过给 Agent 直接 shell 权限后很快踩坑的经历，连最普通的清理命令都可能因为路径判断错误而越界。评论区比较现实的折中方案是：对外暴露少量高层 typed tools，但工具内部仍然可以调用 shell，把组合性留在系统内部，把 blast radius 控制在隔离层里。

第三类补充针对原帖里那些“CLI 独有优势”。不少评论指出，原帖夸的很多能力并不一定只能通过 shell 获得。带方向感的错误信息、渐进式子命令发现、长输出分页续取、稳定元数据返回，这些都可以设计进 MCP server 或 typed tool。真正落后的不是 function calling 这条路线，而是很多工具接口只对后端程序友好，对 Agent 却缺少引导、恢复路径和组合感。

还有个很具体的保留意见也值得记下来：即使把耗时信息打印出来，模型也未必就会稳定学会并发规划或减少等待。也就是说，统一输出格式当然有帮助，但它更像给模型提供可利用信号，不等于模型一定会把这些信号转成更优策略。

这串讨论最有价值的地方，是把“接口长什么样”降成了次要问题。我自己的结论有四条。

1. 先压缩工具数量，消灭语义重复，让模型少做工具选择题。
2. 再给接口补组合能力，让多步任务可以在一个稳定语义里推进。
3. 把错误恢复设计成一等公民，help、stderr、替代建议和分页续取都要能指导下一步。
4. 默认按高风险系统设计隔离、权限、预算和可中断机制。

这四条如果成立，外层到底更像 CLI 还是更像 typed tool，其实没有口号里说得那么重要。原帖说对了一半：很多 Agent 确实更适合统一命令入口；评论区补完的另一半是，typed tool 只要按 Agent 的工作方式重做，一样可以吸收 CLI 的优点。

所以这篇帖子真正该留下来的判断不是“放弃 function calling”，而是：先把接口做成统一、可组合、可恢复的形态，再讨论它是不是 shell。