从 Obsidian CLI 说起
不久前，老牌知识管理软件 Obsidian 官宣了命令行工具 Obsidian CLI，目前在 v1.12 的预览版本中已经可用。Obsidian CLI 提供了和 Obsidian GUI 版本完全对等的功能：从基本的笔记检索、编辑和任务管理，到进阶的开发者功能，如插件管理、截图、JS 代码执行、Chrome 开发者工具协议（CDP）、控制台消息处理、DOM 元素检索等，都在 Obsidian CLI 中得到了支持。
Obsidian CLI 的一些常见命令如下：
# 打开每日笔记
obsidian daily
# 添加任务到每日笔记
obsidian daily:append content="- [ ] Buy groceries"
# 搜索笔记
obsidian search query="meeting notes"
# 列出每日任务
obsidian tasks daily
# 从模板创建新笔记
obsidian create name="Trip to Paris" template=Travel
# 列出所有标签及其数量
obsidian tags counts
# 截图
obsidian dev:screenshot path=screenshot.png
# 执行 JavaScript 代码``
obsidian eval code="app.vault.getFiles().length"
为什么是现在？
Obsidian 拥有庞大的插件和主题生态，但长期以来并没有推出官方的 CLI 工具。三年前，社区诞生了notesmd-cli（原名 obsidian-cli，在官方发布 CLI 后改名），这是一款可以在不打开 Obsidian 程序的情况下，对 Obsidian 数据库进行操作的命令行工具。
从 notesmd-cli 的 Star 趋势图我们可以非常明显地看到，项目诞生后的 Star 增长一直相对稳定，而在进入 2026 年之后，该项目的 Star 数量出现了爆发式的增长。
这一增长的驱动力是显而易见的：OpenClaw🦞的爆火。这只大龙虾引发了 2026 年以来 AI 圈的最大浪潮。而 notesmd-cli 作为 OpenClaw 默认配置的工具之一，自然乘上了 OpenClaw 的东风。
Obsidian 官方在此时发布 CLI，无疑是看到了 notesmd-cli 项目背后蕴藏的巨大潜力。Obsidian 的知识管理和任务追踪体系，完美适配了 OpenClaw 这一类的 AI 助理的需求。与朴素的 MEMORY.md 和 memory/ 文件夹相比，用 Obsidian 作为 AI 助理的记忆库，绝对是一次生产工具的跃升。而 Obsidian 社区超过 2,000 个插件提供的扩展能力，则在此基础上提供了更多可能。
为什么是 CLI？
那么，为什么是 CLI 呢？
因为 CLI 就是 AI Agent 的自然语言。目前的主流 LLM 都具备完善的工具调用能力，而命令行调用是 LLM 工具中最为基础也最为重要的一个。当一个 AI Agent有了命令行调用能力，它就有能力做到任何事：
- 用
cat读文件 - 用
grep搜关键词 - 用
sed修改文件 - 用
curl访问网页或调用 API - 用
git管理代码 - 用
ssh远程访问 - ……
事实上，这就是人类早期使用计算机的方式。不需要复杂的图形界面，不需要花哨的交互方式，一个终端，一块键盘，就可以让一个程序员觉得世界就在他手中。
同样，当一个 OpenClaw bot 拥有了上百个 CLI 工具的使用权限，它也就真正从一个聊天机器人，变成了一个无所不能的 AI 助理。
诚然，当下的多模态 LLM 已经具备了强大的图片和视频理解能力，并可以利用这些能力去控制浏览器和其他桌面程序，但这样的 Computer Use 方式需要消耗更多的 Token，同时也具有更大的不确定性。操作的正确性无法保证；而操作结果的正确获取也同样困难（需要再一次截图并解析）。相比之下，命令行的调用完全不依赖 LLM 的多模态能力，文本输入，文本输出，一切都显得无比自然。
为什么不是 MCP？
模型上下文协议（Model Context Protocol, MCP）是 Anthropic 在 2024 年 11 月提出的一种协议，旨在为 LLM 提供一种标准化的方式来调用外部工具。通过 MCP，LLM 可以调用外部工具，而无需知道工具的具体实现细节。
MCP 很好，但 MCP 也存在不少问题，与 CLI 对比：
- MCP 是一个 Agent 专用的功能，对于人类用户没有直接的使用价值。大量已有软件都需要专门的包装才能进入 MCP 体系。而 CLI 与计算机系统相伴而生，是人类与计算机交互的最基础方式。
- MCP 描述直接占用 Context。如果同时启用了上百个 MCP，就意味着在系统提示词阶段消耗了上万个 Token，这会直接增加 API 调用成本，拖慢响应时间。并且，这些 MCP 对于当前的任务并不总是有用的，而 MCP 之间还可能存在冲突，这都会影响 Agent 的执行精度。一些资深用户会对每个项目使用的 MCP 进行精细控制，但这也带来了额外的工作量和心智负担。相比之下，CLI 通过
--help选项提供了自解释性，需要固定占用的 Token 数量远少于 MCP。 - 目前还没有方便的 MCP 描述重插入机制（写成 skill 是一种可能的解法），这导致 Context 增长之后，Agent 对 MCP 的调用可能失准。而 CLI 的相关信息用户可以随时插入当前对话末尾（比如简单说一句“请你用
xxx命令”），从而确保 Agent 始终具备相关信息。
我们不妨再想一想，有什么是 MCP 做得到，而 CLI 做不到的？
答案是很明确的：所有能通过 MCP 做到的事情，也都可以通过 CLI 做到。因为 MCP 和 CLI 本质上说只是两种不同的用户界面而已。
而 CLI 天然还具备 MCP 所不具备的一个重要特性：CLI 调用本质上是运行 Shell 脚本，所以可以轻易组成链式或决策树式的流程以实现复杂的处理；而 MCP 目前还只能是单次调用得到单个结果，想要实现基于条件的流程控制，必须依赖 LLM 的自主设计，并且过程中需要多次 MCP 调用，增加了复杂度和不确定性。
Agent 时代的 CLI 设计
但为什么相比 CLI，MCP 在 AI 时代得到了更多追捧呢？一方面是人的逐新本能：MCP 是 AI 时代的新产物，而 CLI 是已经存在数十年的“老古董”；另一方面则是因为 CLI 长期以来缺少一套严格的规范体系。我们有的只是一些零散的约定：
-
-x这样的单字符短命令 -
--execute这样的长命令 -
-h|--help帮助选项 - 空格分隔的参数
- ……
与 MCP 的严格规范相比，CLI 的自由松散成了阻碍其被 Agent 广泛使用的拦路虎。
问题的关键并不是 CLI 本身不如 MCP，而是传统的 CLI 设计在 Agent 时代必须作出改变。这里笔者提出 Agent 时代 CLI 设计的三个核心原则：
清晰合理的层级结构
一个好的 CLI 工具，其帮助信息就应该是一份结构清晰、层次分明的文档。我们知道，目前 Agent 应用的核心就在于上下文工程。合理的层级设计可以帮助 Agent 在几次 --help 调用之后按需加载当前任务所需要的工具上下文，从而达到更好的 Context 利用效率。。
符合直觉的命令风格
- 同类资源使用同类动词；
- 同类动词遵循同类参数顺序；
- 全局选项（如
--verbose、--dry-run、--output等）保持一致语义； - 选项命名尽可能遵循习惯用法，不要自创词汇。
做到以上这几条，Agent 就可以在不查看帮助文档（从而节约 Context）的情况下，以较高的准确度执行命令调用。
一个简单的设计思路：想想你会如何用自然语言（英文）来描述这个命令？一套与自然语言高度贴合的命令体系，自然能让 Agent 所想即所见，所见即所得。
稳定可读的结构化输出
Agent 时代的 CLI 工具面向的用户从人类变为 AI Agent，所以其输出也必须遵循面向 Agent 的设计原则，必须具有稳定的结构：
- 可以是
--json、--yaml这样的格式，一些情况下也可以是格式稳定的文本结构（如编译器等）； - 具有明确的退出码和可解析的错误字段。
结构化输出让 Agent 可以轻松地进行信息提取（配合 jq 等工具）以及流程编排，从而充分发挥 CLI 的强大能力。
除了这三个核心原则，还有一些值得注意的细节：
- 写操作应该尽可能支持幂等或
--dry-run选项，以便 Agent 可以进行预览和调试； - 面向多 agent 和 subagent 架构，需要考虑 CLI 的并发控制。一个最简单的文件锁，就可以避免很多写冲突的问题。
- 复杂的功能最好具备可观测性，以便 Agent 在调用遇到问题时可以更好地排查原因。
结语
Obsidian 官方 CLI 工具的发布，是 OpenClaw 掀起的这波 AI 助理浪潮中的一个重要信号。当 MCP 的热潮渐渐归于平静，蓦然回首，陪伴我们几十年的 CLI 一直就在那里。
