折腾半天Agent，最后还是手写Shell最管用

说实话，我本以为2025年Agent这东西已经没啥好聊的了。

OpenClaw火了小半年，朋友圈三天两头有人晒截图，GitHub上Star数刷得飞起。一堆人喊着"AI自己写代码自己部署"，好像明天就要取代全人类了。

但我真上手试了试，发现一个问题——这东西根本养不起。

参考文章里那哥们的经历跟我一模一样。今年一月，他头回接触OpenClaw，新鲜劲儿上来就开干。结果呢？"两天时间就花了60块钱"。讲真，这就是真实成本，不是什么未来愿景。你让普通开发者一个月花900块养一个常常失忆的Agent？做梦呢。

更扯的是，"OpenClaw还是全VibeCoding的，一天上百个提交"。说白了，项目自己都不稳定，你指望它稳定干活？

---

真正值得看的，是这个人的解决方案

他后来做了个叫NinoClaw的东西。我仔细翻了翻他的设计和代码，说实话，这才是懂行的人该有的思路。

核心就三条：

"不必要或不重要的功能不添加。能使用系统原生的功能就不要自己管理。"

这话听起来像废话，但你看看现在市面上那些Agent项目——Web界面、可视化配置、拖拽式工作流…全是花架子。一个命令行工具，你给我整什么配置界面？直接改配置文件不行吗？

这哥们只写了三个接口给Agent用：

- [TASK] — 主控台发任务，自然语言传
- [COMMAND] — 子助手执行Shell命令
- [RESULT] — 返回结果

没了。不是他懒，而是他想明白了：一切Skill都可以通过Shell调用，你只需要手动添加别名。

看看那些动不动把每个功能都封装成一个API的项目——一个天气接口、一个网络接口、一个文件操作接口…通通是多余的。你把alias web "python /path/to/web.py"写在Shell配置里，然后让Agent直接[COMMAND] web，效果一样，代码量减90%。

这是个被低估的亮点。他意识到"上下文是LLM的稀缺资源，上下文越多模型就越笨"，所以搞了个双Agent结构：

主控台跟用户聊天，子助手干活。子助手每次干完活，上下文清空，只把结果返回主控台。

"大量无用的上下文被清空了"——说白了，效率翻倍，成本腰斩。

---

为什么Shell别名比API封装强？

我知道有人会说："Shell命令谁不会？凭什么说封装API就是多余？"

讲真，这个问题问得对，但也恰恰暴露了很多人没想明白的点。

Shell别名复用的是系统原生能力。 你写alias web "python /path/to/web.py"，底层用的就是操作系统自带的进程管理、权限控制、错误处理。你写个[COMMAND] web，系统自己帮你管理进程生命周期、处理退出码、捕获标准错误。

但你自己封装API呢？ 你得自己写进程调度逻辑，自己处理异常捕获，自己设计错误码体系，自己管理超时重试——说白了，你是在重新实现操作系统已经做了十年的东西。

这就回到那哥们的设计方针了："能使用系统原生的功能就不要自己管理。"不是因为他懒，是因为系统的实现比你稳、比你快、比你少Bug。

举个例子：你要让Agent调用一个Python脚本抓天气数据。用API封装的方式，你得写天气接口的调用函数、处理网络异常、定义返回格式、写错误处理逻辑…起码几十行。用Shell别名？一行alias weather "python /path/to/weather.py"，然后Agent直接[COMMAND] weather，所有异常、输出、错误信息全由Shell帮你兜底。

这就是"不要重新实现操作系统"。 Shell才是那个终极的抽象层，你已经有了电脑上最强的自动化工具，为什么非要再封装一层？

---

实际用起来怎么样？

他项目架构是这样的：

database/
home/
lib/
  core.py
  database.py
  terminal.py
  prompt_template/
    exec.md
    yume.md
main.py
env.json
config.json

不复杂。你配置好模型接口（兼容OpenAI API格式的），跑python main.py就行。

但注意，他说了："自带的Skill也不一定是开箱即用的，请检查每个Skill代码。"

这才是实话。任何号称"开箱即用"的Agent项目，要么是吹牛，要么是功能少到不值得用。

---

给你三个行动建议

如果你真想用Agent干活，先试试NinoClaw这种思路——用系统原生的东西，不要自己实现一遍。你需要的是一个"命令执行器"，不是"另一个操作系统"。

怎么判断一个Agent项目是不是过度设计？给你一个土办法：去看它的核心代码，如果超过500行，先问自己一个问题——这些抽象是真的必要，还是在重复造系统已有的轮子？

大部分时候，答案都是后者。

任何还需要你单独写API接口去调用系统工具的Agent，基本上是过度设计了。学会写几个alias，比学一个新框架值多了。你花三天学一个Agent框架，不如花三小时把Shell配置写好——前者的能力边界是框架设计者定的，后者的能力边界是操作系统定的。

那哥们两天花60块，虽然这是早期数据，但逻辑是成立的：Agent的上下文就是钱，上下文越多，调用越贵。你上线一个Agent，如果连成本都算不清楚，那就不是在做产品，是在烧钱。

用"主控台-子助手"这种架构清空无用上下文，本质上是成本控制。省下来的不只是一个月的几百块，省下来的是你的项目能跑多久。

---

最后说一句。

Agent这东西，技术上早就不是瓶颈了。瓶颈是你愿不愿意做减法，愿不愿意承认"够用就行"。

2025年，别再折腾那些"一天几百个提交"的项目了。找个能稳定跑两天的，比什么都强。

---