CLI is ALL you need

作者：Deterministic.AI
日期：2026年2月25日 下午4:43
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

CLI先係AI Agent嘅自然語言，MCP只係過渡方案

整理版摘要

呢篇文從Obsidian CLI發布講起，指出CLI先係AI Agent嘅自然語言，而家當紅嘅MCP只係過渡方案。作者係一位關注AI Agent工具設計嘅開發者，佢見到OpenClaw爆火帶動notesmd-cli項目Star激增，Obsidian官方順勢推出CLI，認為呢個係AI助理浪潮嘅重要信號。

作者想解決嘅問題係：點解明明CLI咁適合Agent，但大家反而追捧MCP？佢對比咗兩者：CLI文本輸入輸出，唔使多模態Token，成本低、不確定性細；MCP佔用大量Context，工具之間易衝突，而且做唔到流程編排。結論係我哋唔需要新瓶裝舊酒，應該改進CLI設計，而唔係另起爐灶。

整體嚟講，呢篇文章提供咗一個務實嘅視角：Agent時代唔係拋棄CLI，而係要為CLI建立清晰層級、符合直覺嘅命令風格同穩定結構化輸出，等Agent可以高效調用。作者仲提出咗冪等、併發控制、可觀測性等實用建議。

  • Obsidian CLI發布係AI助理浪潮嘅重要信號，OpenClaw爆火令notesmd-cli項目Star激增
  • CLI係AI Agent嘅自然語言，因為文本輸入輸出節省Token，唔似MCP咁佔用大量Context
  • MCP做唔到流程編排同條件分支，CLI可以輕易組成鏈式或決策樹
  • Agent時代嘅CLI設計要跟從三個原則：清晰層級、直覺命令風格、穩定結構化輸出
  • 寫操作要支持冪等或--dry-run，複雜功能要具備可觀測性，以便Agent調試
結構示例

結構示例

結構示例 text 
# 打開每日筆記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與AI助理浪潮

老牌知識管理軟件Obsidian最近官宣咗命令行工具Obsidian CLI，目前喺v1.12預覽版已經可以用。佢提供咗同GUI完全對等嘅功能，包括筆記檢索、編輯、任務管理，甚至插件管理、截圖、JS代碼執行、Chrome開發者工具協議等。

Obsidian CLI同GUI完全對等

作者指出，Obsidian官方呢個時間點發布CLI，明顯係睇到notesmd-cli項目背後嘅潛力。notesmd-cli喺2026年之後Star爆發式增長，正係因為佢係OpenClaw默認配置嘅工具之一。OpenClaw呢隻大龍蝦引發嘅AI浪潮，令CLI工具重新獲得關注。

  1. 1 obsidian daily — 打開每日筆記
  2. 2 obsidian daily:append content="- [ ] Buy groceries" — 添加任務到每日筆記
  3. 3 obsidian search query="meeting notes" — 搜索筆記
  4. 4 obsidian create name="Trip to Paris" template=Travel — 從模板創建新筆記
  5. 5 obsidian dev:screenshot path=screenshot.png — 截圖
整理重點

CLI vs MCP：點解CLI更適合Agent

作者認為CLI就係AI Agent嘅自然語言。因為主流LLM都具備完善嘅工具調用能力，而命令行調用係最基礎最重要嘅一種。一個Agent只要有咗CLI能力，就可以用cat讀文件、grep搜關鍵詞、sed修改文件、curl訪問網頁、git管理代碼等等。

CLI就係AI Agent嘅自然語言

相比之下，多模態LLM用Computer Use方式控制瀏覽器，需要消耗更多Token，而且操作正確性同結果獲取都唔保證。命令行完全唔依賴多模態，文本輸入輸出，自然得多。

  • MCP係Agent專用，人類用戶直接用唔到；CLI人類同Agent都用得
  • MCP描述佔用大量Context，同時上百個MCP會消耗上萬Token；CLI靠--help自解釋，佔用Token少好多
  • MCP目前做唔到流程編排；CLI可以組合成鏈式或決策樹，實現複雜處理
  • 所有MCP做到嘅嘢，CLI都得，因為兩者只係唔同用戶界面
整理重點

Agent時代嘅CLI設計原則

作者提出Agent時代CLI設計三個核心原則。第一個係清晰合理嘅層級結構：幫助信息應該結構分明，等Agent可以按需加載工具上下文，提高Context利用效率。

清晰合理嘅層級結構

第二係符合直覺嘅命令風格：同類資源用同類動詞，選項命名跟習慣用法。作者話：「諗下你會點用自然語言（英文）描述呢個命令？一套同自然語言貼合嘅命令體系，自然令Agent所想即所見。」

符合直覺嘅命令風格

第三係穩定可讀嘅結構化輸出：輸出可以用--json或--yaml格式，有明確退出碼同可解析錯誤字段。Agent可以輕鬆提取信息同編排流程。

  1. 1 寫操作盡可能支持冪等或--dry-run，方便Agent預覽調試
  2. 2 面向多agent架構要考慮併發控制，例如文件鎖避免寫衝突
  3. 3 複雜功能要有可觀測性，方便Agent排查問題
整理重點

結語與啟示

Obsidian官方CLI工具嘅發布，係OpenClaw掀起嘅AI助理浪潮中一個重要信號。當MCP嘅熱潮漸漸歸於平靜，我哋會發現陪伴幾十年嘅CLI一直喺度。

我哋也許並唔需要一個新瓶

作者嘅核心觀點係：與其追捧MCP呢個新瓶，不如改進現有嘅CLI設計，令佢更加適合Agent使用。呢個先係務實嘅方向。

由 Obsidian CLI 講起

唔係好耐之前，老牌知識管理軟件 Obsidian 正式公佈咗命令行工具 Obsidian CLI，而家喺 v1.12 嘅預覽版本中已經用得。Obsidian CLI 提供咗同 Obsidian GUI 版本完全對等嘅功能：由基本嘅筆記檢索、編輯同任務管理，到進階嘅開發者功能，例如插件管理、截圖、JS 代碼執行、Chrome 開發者工具協議（CDP）、控制枱消息處理、DOM 元素檢索等，都喺 Obsidian CLI 入面得到支援。

圖片

圖 1 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 數據庫進行操作嘅命令行工具。

圖片

圖 2 notesmd-cli 項目 Star 趨勢圖

從 notesmd-cli 嘅 Star 趨勢圖我哋可以好明顯咁睇到，項目誕生後嘅 Star 增長一直相對穩定，而喺進入 2026 年之後，呢個項目嘅 Star 數量出現咗爆發式嘅增長。

呢個增長嘅驅動力係好明顯嘅：OpenClaw🦞嘅爆紅。呢隻大龍蝦引發咗 2026 年以嚟 AI 圈嘅最大浪潮。而 notesmd-cli 作為 OpenClaw 默認配置嘅工具之一，自然搭咗 OpenClaw 嘅順風車。

圖片

圖 3 OpenClaw 進化史（Clawdbot -> Moltbot -> 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 可以調用外部工具，而無需知道工具嘅具體實現細節。

圖片

圖 4 MCP 架構示意圖（圖源：modelcontextprotocol.io）

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 一直都喺嗰度。

圖片

圖 5 我哋或者並唔需要一個新瓶

從 Obsidian CLI 說起

不久前，老牌知識管理軟件 Obsidian 官宣了命令行工具 Obsidian CLI，目前在 v1.12 的預覽版本中已經可用。Obsidian CLI 提供了和 Obsidian GUI 版本完全對等的功能：從基本的筆記檢索、編輯和任務管理，到進階的開發者功能，如插件管理、截圖、JS 代碼執行、Chrome 開發者工具協議（CDP）、控制枱消息處理、DOM 元素檢索等，都在 Obsidian CLI 中得到了支持。

圖片

圖 1 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 數據庫進行操作的命令行工具。

圖片

圖 2 notesmd-cli 項目 Star 趨勢圖

從 notesmd-cli 的 Star 趨勢圖我們可以非常明顯地看到，項目誕生後的 Star 增長一直相對穩定，而在進入 2026 年之後，該項目的 Star 數量出現了爆發式的增長。

這一增長的驅動力是顯而易見的：OpenClaw🦞的爆火。這隻大龍蝦引發了 2026 年以來 AI 圈的最大浪潮。而 notesmd-cli 作為 OpenClaw 默認配置的工具之一，自然乘上了 OpenClaw 的東風。

圖片

圖 3 OpenClaw 進化史（Clawdbot -> Moltbot -> 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 可以調用外部工具，而無需知道工具的具體實現細節。

圖片

圖 4 MCP 架構示意圖（圖源：modelcontextprotocol.io）

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 一直就在那裏。

圖片

圖 5 我們也許並不需要一個新瓶