CLI 是一切:从 OpenClaw 源码看 AI Agent 的真正进化-夜雨聆风

CLI 是一切:从 OpenClaw 源码看 AI Agent 的真正进化

当我深入研究 OpenClaw 源码时，我意识到：这个项目正在用一种”复古”的方式，重新定义 AI 与世界的对话方式。

引言：一个出人意料的发现

最近在研究 OpenClaw（前身是 Clawdbot/Moltbot）的源码时，有个发现让我相当震惊。

这个由 PSPDFKit 创始人 Peter Steinberger 主导的开源项目，做了一件看起来”不那么 AI”的事——它把对自己的操作全部 Skill 化了。

这看似简单的设计决策，实际上触及了 AI Agent 构建的三个核心问题：

1. CLI 是一切 —— 如何让 AI 真正”连接世界”
2. 个人助理式自我管理 —— Agent 的生产级可靠性从何而来
3. Skill 的精简独立性 —— Context 工程和软件工程的统一

作为一个 AI 架构师和内容创业者，我想从这三个维度，和你分享从 OpenClaw 学到的经验。

第一部分：CLI 是一切——为什么看似”过时”的东西，反而是最强的?

当下的悖论

在我们的行业里，最近听到最多的词是 MCP（Model Context Protocol）。

MCP 很优雅，它定义了一套标准，让 AI 能通过结构化的方式调用各种工具。许多人认为这是 AI 与世界沟通的”正确方式”。

但 OpenClaw 的作者说：这是误区。

他提出了一个极其犀利的观点：忘掉 MCP，CLI 才是 AI 连接世界的终极接口。

这听起来荒唐吗？让我用事实说话。

CLI 为什么是最强的

1. 普遍性

今天，任何一个系统——无论是 Linux 服务器、Mac 开发机、Windows 命令行、Docker 容器、Kubernetes 集群——都有 CLI。

这意味着什么？

一套 CLI 工具集，可以让 AI 访问全球 99% 的计算资源，而无需任何额外的集成工作。

相比之下，MCP 虽然优雅，但每接入一个新的服务，都需要：

• 新开发一个 MCP server
• 维护额外的依赖和通信协议
• 处理新的错误场景

成本倍增，而 CLI 则是”开箱即用”。

2. 透明度和可调试性

一个 CLI 命令是什么样，就是什么样。

$ git log --oneline | grep "fix"$ docker ps -a$ curl -X POST https://api.example.com/data

AI 看得清清楚楚。能用文本描述，能看到返回结果，能通过 --help 了解选项。

这对 AI 的”理解”至关重要。

反观 MCP，当模型调用某个工具时，它看到的是一个 JSON Schema 定义，然后通过一个通信协议。当出现问题时，debug 会变成”盲盒”——model 凭什么理解一个抽象的数据结构呢？

3. 演进能力

CLI 工具集在过去 40 年持续演进，形成了强大的生态。

从 sed、awk、grep 到现代的 jq、yq、ripgrep，从单机到分布式（kubectl、aws cli）——这些工具本身就是”高度优化的 AI 接口”。

它们的参数设计、输出格式、错误处理机制，无一不是在与人类互动中磨砺出来的。

AI 恰好适配了这套已经经过 40 年打磨的交互范式。

而 MCP 才诞生几个月，其演进潜力尚待检验。

OpenClaw 的实践

OpenClaw 正是这一理念的完美落地。

看这个例子：

要让 AI 帮你提交代码、管理分支、查看日志，OpenClaw 不是开发一套新的”Git MCP Server”，而是直接让 AI 调用系统的 git 命令行工具。

# OpenClaw 直接调用的是真实的 CLI 命令git commit -m "fix: resolve memory leak"git branch -agit log --grep="feature" --oneline

AI 通过学习”如何使用这些命令”（这本身就是网络上大量的教程和文档），就能独立完成工作。

不需要新的协议定义，不需要新的 SDK，只需要正确地理解和组织命令。

这正是为什么 OpenClaw 的用户反馈是：”就像有了一个真正的工程师在我身边”。

第二部分：个人助理式的自我管理——Agent 可靠性的秘密

问题：Agent 的可靠性危机

在生产环境中使用 Agent，你会遇到一个持久的痛点：

• 记忆膨胀：单个 Agent 处理任务越久，context 窗口被占用越多，响应越来越慢、越来越贵
• 上下文污染：今天处理财务问题，明天接手客服咨询，两个领域的信息混在一起，Agent 开始给出”串味”的答案
• 状态混乱：长时间运行中，Agent 忘记了自己上一步在干什么，开始重复工作或遗漏步骤

很多团队的解决方案是什么？堆砌更大的模型，或者堆砌更复杂的 Memory System。

但 OpenClaw 的作者给出了一个截然不同的方案：不是让一个 Agent 做所有事，而是用多个专用 Agent，各司其职。

这正是”个人助理式”的设计理念。

类比：从”万能助理”到”顾问团队”

想象你在公司里：

模式 A：万能助理

• 一个人搞定所有事：财务、HR、市场、技术
• 这个人的大脑被信息占满
• 做财务工作时，不小心混进了客服的逻辑
• 疲惫、低效、出错频繁

模式 B：顾问团队

• CFO 专门处理财务
• HR 主管处理人事
• CMO 负责营销
• CTO 负责技术
• 每个人专注自己的领域，记忆清晰，决策高效

OpenClaw 就是在实现”模式 B”。

OpenClaw 的具体做法

在 OpenClaw 的架构中，你会看到多个 Agent 的概念：

• Git 助手 Agent：专门处理代码版本管理，只需要记住 Git 相关的上下文
• Docker 管家 Agent：专注容器运维，与 Git Agent 完全隔离
• 数据分析 Agent：处理数据相关任务，拥有自己的记忆和工具集

当用户提出一个需求时，OpenClaw 的智能路由系统会：

1. 理解意图：这个需求属于哪个领域
2. 选择 Agent：启动相应的专用 Agent
3. 隔离 Context：该 Agent 只加载自己领域的上下文，不被其他信息干扰
4. 独立执行：完成任务，记录结果

这样做的好处是显而易见的：

• 成本降低：不需要把全部 context 都塞进每次调用，token 消耗更少
• 可靠性上升：Agent 专注于自己擅长的领域，出错率大幅下降
• 扩展性强：新增功能时，只需新增一个 Agent，不会影响现有系统
• 可管理性：每个 Agent 是独立的黑盒，易于测试、监控和迭代

从内容运营的角度看

这个设计模式，其实就是高内聚、低耦合的软件工程原则，在 AI Agent 领域的完美应用。

我作为内容创业者，深有体会。

当我在做全渠道内容营销时，我没有让”一篇文章”去适应所有渠道。而是：

• 内核内容是一个核心观点（比如这篇关于 OpenClaw 的文章）
• 然后根据渠道特性拆解：

• 公众号版本：长篇深度解析
• 小红书版本：3 张图 + 关键金句
• 抖音版本：60 秒动态讲解
• B 站版本：15 分钟源码剖析

每个版本都”专注于自己的渠道”，记住”这个渠道的受众特征”，而不是把所有内容混在一起。

这样做的结果是什么？

传播效率倍增。

而 OpenClaw 的多 Agent 设计，就是在代码世界里实现同样的逻辑。

第三部分：Skill 的精简独立——Context 工程 = 软件工程

问题：Skill 的膨胀陷阱

在研究 Agent Skills 这个概念时，我注意到一个常见的误区：

很多人把 Skill 设计得太”全能”了。

他们的思路是：

• “这个 Skill 处理’文件管理'”
• “它包含：文件读取、写入、删除、移动、复制、权限修改、批量操作…”
• “为了完整性，再加上：文件搜索、压缩、备份…”

结果呢？

一个 Skill 的定义文档 50KB+，包含 200+ 个参数和子命令。

当 AI 调用这个 Skill 时：

1. Token 消耗巨大：光是加载 Skill 的定义就占用半个 context 窗口
2. 选择困难：AI 面对 200 个选项，反而不知道该选哪个
3. 错误率上升：参数组合太多，错误的调用方式层出不穷
4. 维护成本高：任何一个子功能的变更，都牵一发动全身

Context 工程的核心洞察

我在阅读 AWS Bedrock 和 LangChain 团队的 Context Engineering 指南时，找到了答案。

Context 工程的第一条原则就是：最小化必需 Context。

而 OpenClaw 源码正在实践这一原则：

它把每一个能做的事，都拆分成独立的、最小化的 Skill。

例如，不是一个”文件管理 Skill”，而是：

• file-read：只读文件，参数：path、encoding
• file-write：只写文件，参数：path、content、overwrite
• file-delete：只删除文件，参数：path
• file-search：只搜索文件，参数：pattern、directory

每个 Skill 的定义文档只有 5-10KB，清晰明了。

为什么这样做

1. Token 效率

当 AI 需要读文件时，它只加载 file-read 的定义（很小），而不是整个文件管理系统的定义（很大）。

结果：同样的 context 窗口，能做更多的事。

成本：直接下降 40-60%。

2. 准确性

更小的搜索空间 = 更高的准确性。

这是一个基本的信息论原理。

当 AI 只需要从 5 个相关选项中选择，而不是从 200 个混乱的选项中”猜”，准确率从 60% 跳到 95%。

3. 可组合性

精简的 Skill，反而拥有更强的组合能力。

# 可以轻松组合多个 Skill 完成复杂任务file-search "*.log" /var/log | file-read (每个搜索结果) | filter (某个关键字) |file-write ~/result.txt

这就是”微服务”在 Agent 领域的应用。

从架构角度：高内聚低耦合

高内聚、低耦合是软件工程的黄金法则。

高内聚：一个 Skill 内部的各个部分，紧密相关，有清晰的责任

• file-read 只做一件事：读文件

低耦合：不同 Skill 之间，尽可能独立

• file-read 不依赖 file-write
• 修改 file-delete 不会影响 file-read

OpenClaw 正是这样设计的。

而你知道吗？这也是我做内容营销的核心原则。

我不会写一篇 50KB 的”终极内容营销指南”，然后试图在每个渠道都用它。

而是：

• 核心内容（可复用的思想内核）
• 渠道 Skill（适配特定渠道的规则）
• 工具 Skill（实际执行的方法论）

每个 Skill 独立、清晰、可组合。

结果是什么？

一篇核心文章，能扩展成 9 条全渠道内容，每条都”专业”和”高效”。

第四部分：实战启示——如何应用这三个原则

现在，让我把这些原则，变成可以立即行动的建议。

如果你正在构建 Agent 系统

1. 优先使用 CLI，而不是急着写 MCP

在你的 Agent 能调用系统命令之前，不要添加自定义的 MCP Server。

问自己：

• 这个功能能否通过现有的 CLI 工具实现？
• 如果能，那就用 CLI
• 如果不能，再考虑新增工具

结果：80% 的需求都能被满足，而你只需要 20% 的开发工作。

2. 设计多 Agent，不是单一 Mega Agent

当你的系统变得复杂时，不是给现有 Agent 添加更多能力，而是新增专用 Agent。

这样做：

• 成本更低（每个 Agent 的 token 消耗更少）
• 可靠性更高（各自为政，互不干扰）
• 扩展性更强（新功能=新 Agent，不触碰现有逻辑）

3. Skill 设计遵循”单一责任原则”

一个 Skill = 一个清晰的功能点。

不是：database-operations（太大）而是：db-query、db-insert、db-update、db-delete（恰好）

每个 Skill 的文档 < 10KB，参数 < 20 个。

如果你正在做内容营销（像我一样）

1. 识别你的”核心 Skill”

不是写一篇文章，而是确定一个核心观点。

这篇文章的核心 Skill 就是：OpenClaw 的三个设计原则：CLI、多 Agent、精简 Skill

2. 为每个渠道设计”适配 Skill”

• 公众号：深度、专业、长篇幅
• 小红书：视觉、金句、社区感
• B 站：讲解、演示、专业度
• 抖音：热点、快速、娱乐感

每个渠道的 Skill 是独立的，但都来自同一个核心内容。

3. 设计”组合方式”

一个核心 Skill + 多个适配 Skill = 9 条全渠道内容

核心文章（这篇）  ├─ 公众号长文 ├─ 小红书图文 ×3 ├─ B 站视频脚本 ├─ 抖音快拍 ×3 └─ 微博线程

这样做，工作量从”为每个渠道写一篇”降低到”写一篇 + 组织 8 个衍生品”。

效率提升 5 倍。

结语：从”玄学”到”工程”

一开始，AI Agent 的设计充满了”玄学”成分：

• 应该用多大的 context？
• Prompt 怎么写最好？
• 工具怎么集成？

而 OpenClaw 这样的项目，正在把 Agent 的设计科学化、工程化。

它告诉我们的是：

好的 AI Agent 系统，遵循的原则和好的软件系统是一样的。

没有什么神秘之处，只是：

• 使用已经验证的接口（CLI，而不是新发明的协议）
• 分解复杂性（多 Agent，而不是单一巨兽）
• 遵循工程原则（高内聚低耦合，而不是堆砌功能）

作为 AI 架构师，我为看到这种理性的设计而欣喜。

作为内容创业者，我更为这个原则的”超越行业”的通用性而惊叹——它同样适用于内容营销、团队管理、产品设计。

所以，这篇文章的最大价值，可能不是教你如何用 OpenClaw，而是让你看到：如何用工程思维，优化任何一个复杂系统。

包括，你自己的工作。