MCP on KnightLi的博客

Claude Code 也有插件市場了：能裝什麼、怎麼裝、要注意什麼

Sat, 23 May 2026 19:03:30 +0800

anthropics/claude-plugins-official 是 Anthropic 管理的 Claude Code 官方插件目錄。它不是一個普通程式碼庫，而是一個可被 Claude Code 插件系統直接使用的 marketplace，集中放置由 Anthropic 維護或篩選的 Claude Code 插件。

這個倉庫值得關注，是因為 Claude Code 正在從「一個 AI 編程命令列工具」變成「可擴展的開發環境」。插件可以把 Skills、Agents、Hooks、MCP servers、LSP servers、後台監控和預設設定打包起來，讓團隊或社群用統一方式分發。

這個倉庫是什麼

倉庫 README 對它的定位很直接：這是一個高品質 Claude Code 插件的 curated directory。

目錄主要分成兩塊：

/plugins：Anthropic 內部開發和維護的插件。
/external_plugins：來自合作夥伴和社群的第三方插件。

也就是說，它既包含官方能力，也包含經過收錄的外部生態入口。對普通使用者來說，最直接的意義是可以透過 Claude Code 的 /plugin 系統發現和安裝插件；對開發者來說，它提供了觀察 Claude Code 插件格式和生態方向的窗口。

如何安裝插件

README 給出的安裝方式很簡單。可以直接透過 Claude Code 的插件系統安裝：

`1`	`/plugin install {plugin-name}@claude-plugins-official`

也可以在 Claude Code 裡打開插件發現入口：

`1`	`/plugin > Discover`

這裡的關鍵點是 @claude-plugins-official。它代表官方插件目錄這個 marketplace。根據 Claude Code 文件，claude-plugins-official 是 Anthropic 維護的官方 marketplace，並且會在 Claude Code 安裝中預設可用。

插件長什麼樣

倉庫 README 給出了標準插件結構：

plugin-name/
├── .claude-plugin/
│   └── plugin.json
├── .mcp.json
├── commands/
├── agents/
├── skills/
└── README.md

其中 .claude-plugin/plugin.json 是插件元資料檔案，通常用來宣告插件名、描述、版本、作者等資訊。其他目錄則按需存在：

skills/：放 Claude 可自動呼叫的技能說明。
commands/：放 slash commands。
agents/：放自訂 agent 定義。
hooks/：放事件觸發邏輯。
.mcp.json：配置 MCP server。
.lsp.json：配置語言伺服器。
monitors/：配置後台監控。
settings.json：給插件附帶預設設定。

這說明 Claude Code 插件不是單一類型擴展，而是一種打包格式。它可以只是一個小命令，也可以是一整套面向某個技術棧的工作流。

官方目錄裡已經有哪些方向

從 /plugins 目錄看，官方維護插件覆蓋了不少開發場景，包括：

LSP 類插件：typescript-lsp、pyright-lsp、rust-analyzer-lsp、gopls-lsp、clangd-lsp、csharp-lsp、jdtls-lsp、kotlin-lsp、lua-lsp、php-lsp、ruby-lsp、swift-lsp。
編程工作流：code-review、feature-dev、code-modernization、code-simplifier、commit-commands、pr-review-toolkit。
Claude Code 配置和插件開發：claude-code-setup、claude-md-management、plugin-dev、skill-creator、mcp-server-dev。
輸出風格和專項能力：explanatory-output-style、learning-output-style、security-guidance、session-report、math-olympiad。

/external_plugins 裡則能看到更多第三方工具和服務方向，例如 github、gitlab、linear、asana、firebase、playwright、terraform、context7、serena、telegram、discord 等。

這組插件透露出一個趨勢：Claude Code 不只是想幫你改檔案，還想接入程式碼智能、專案管理、雲服務、測試、基礎設施和團隊協作工具。

為什麼插件系統重要

過去很多 Claude Code 自訂能力都可能散落在專案裡的 .claude/ 目錄中，比如 commands、agents、skills 或 hooks。這種方式適合個人或單一專案，但不方便跨專案複用，也不方便團隊統一分發和更新。

插件解決的是可複用和可分發問題：

同一套配置可以跨多個專案安裝。
命令和技能有命名空間，減少衝突。
插件可以透過 marketplace 發布和更新。
團隊可以把內部最佳實踐打包成標準插件。
社群可以圍繞某個框架、語言或服務維護專門擴展。

這和 VS Code 插件、JetBrains 插件、瀏覽器擴展的思路類似：當一個工具開始有穩定插件生態，它就不再只是單一產品，而是在形成平台。

對開發者有什麼用

如果你只是 Claude Code 使用者，這個倉庫最實用的地方是找插件。比如需要 TypeScript、Python、Rust 或 Go 的 LSP 能力，可以先看官方目錄裡是否已有對應插件；需要 PR review、commit、程式碼現代化等工作流，也可以從官方插件開始試。

如果你是插件開發者，這個倉庫更像樣板庫。你可以參考它的目錄組織、plugin.json 寫法、README 說明方式，以及 Anthropic 如何把 skills、agents、MCP、LSP 和 hooks 組合起來。

Claude Code 文件也明確建議：如果只是單專案自訂，可以先用 .claude/；如果需要分享給團隊、跨專案複用、版本化發布，或者進入 marketplace，就應該做成插件。

安全邊界不能忽略

倉庫 README 在開頭就提醒：安裝、更新或使用插件前必須信任該插件。原因很簡單，插件可能包含 MCP server、檔案、腳本或其他軟體。Anthropic 維護目錄，不等於能保證每個插件在你的本地環境中都按你預期執行。

實際使用時建議至少做幾件事：

安裝前看插件主頁和 README。
檢查是否包含 .mcp.json、hooks、可執行腳本或後台監控。
對需要存取帳號、程式碼倉庫、聊天工具、雲服務的插件格外謹慎。
在重要專案中啟用插件前，先在測試倉庫驗證。
團隊環境最好統一審核插件來源和版本。

AI 編程插件的權限往往比普通編輯器主題高得多。它可能能讀專案檔案、呼叫外部服務、啟動本地命令，甚至影響提交和部署流程，所以信任邊界要比「裝一個小工具」更嚴格。

和社群 marketplace 的關係

Claude Code 文件提到，Anthropic 維護兩個公開插件 marketplace：

claude-plugins-official：Anthropic 維護的 curated 插件集合。
claude-community：第三方提交後進入審查流程的社群插件目錄。

這兩者的定位不同。社群插件可以透過提交表單進入 review；官方目錄則由 Anthropic 自行決定是否收錄，沒有普通申請流程。換句話說，claude-plugins-official 更像官方精選目錄，claude-community 更像開放社群目錄。

小結

anthropics/claude-plugins-official 的意義不只是「多了一個 GitHub 倉庫」。它說明 Claude Code 的擴展機制正在平台化：Skills、Agents、Hooks、MCP、LSP、後台監控和預設設定都可以被打包、安裝、更新和分發。

對個人開發者來說，官方插件目錄能降低配置 Claude Code 的門檻。對團隊來說，它提供了把內部流程標準化的路徑。對插件開發者來說，它給出了 Anthropic 認可的插件結構和生態方向。

接下來值得關注的不是某一個插件本身，而是 Claude Code 插件生態會不會形成穩定分層：官方精選、社群插件、團隊私有 marketplace，以及圍繞主流語言、框架和 SaaS 服務的專門擴展。如果這條路線走通，Claude Code 會越來越像一個可編排的 AI 開發平台，而不只是一個命令列助手。

參考資料：

GitHub 專案：https://github.com/anthropics/claude-plugins-official
Claude Code 插件文件：https://code.claude.com/docs/en/plugins

Graphify 解決 Claude Code 最大局限：把程式碼庫變成 AI 可查詢知識圖譜

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify 是一個面向 AI 編程助手的知識圖譜工具。它的目標很直接：把一個專案目錄裡的程式碼、文件、SQL schema、腳本、論文、圖片、影片和音訊，整理成可查詢的知識圖譜，讓 AI 助手不再只靠 grep、全文閱讀或臨時搜尋來理解專案。

專案地址：safishamsi/graphify

截至本文整理時，GitHub 頁面顯示專案約有 50.2k stars、5.4k forks，授權為 MIT。README 對它的描述是：在 AI 編程助手裡輸入 /graphify，它就會把整個專案映射成一個可以查詢的知識圖譜。

它解決的核心問題

AI 編程助手越來越強，但在真實程式碼庫裡仍然經常遇到幾個問題：

不知道關鍵模組之間怎麼連接。
讀了很多檔案，但沒形成整體架構地圖。
搜尋命中了文字，卻不知道上下游依賴。
程式碼、資料庫 schema、文件和基礎設施設定分散在不同地方。
多人協作時，每個人對專案結構的理解不一致。

Graphify 想做的是給專案生成一層「記憶層」。它把程式碼實體、文件概念、資料庫表、設定、設計說明和跨檔案關係連接起來，讓 AI 助手可以按圖譜查詢，而不是每次從零開始掃檔案。

最小使用方式

Graphify 的最小用法非常簡單。安裝後，在 AI 編程助手裡輸入：

`1`	`/graphify .`

在 PowerShell 裡要注意，前導 / 會被當成路徑分隔符，所以 Windows PowerShell 下應使用：

`1`	`graphify .`

執行後會生成 graphify-out/ 目錄，核心檔案包括：

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

這三個檔案分工不同：

graph.html：瀏覽器裡打開的互動式圖譜，可以點擊節點、過濾和搜尋。
GRAPH_REPORT.md：專案亮點、關鍵概念、意外連接和推薦問題。
graph.json：完整圖譜，後續可以直接查詢，不必重新讀所有檔案。

如果想生成更可讀的架構頁面和 Mermaid 呼叫流程圖，可以執行：

`1`	`graphify export callflow-html`

安裝和平台支援

Graphify 的 PyPI 包名是 graphifyy，注意是雙 y。README 特別提醒，PyPI 上其他 graphify* 包並不屬於該專案，但 CLI 命令仍然叫 graphify。

推薦安裝方式是：

`1`	`uv tool install graphifyy`

也可以使用：

1
2

pipx install graphifyy
pip install graphifyy

安裝後註冊到 AI 助手：

`1`	`graphify install`

專案支援的平台很多，包括 Claude Code、Codex、OpenCode、GitHub Copilot CLI、VS Code Copilot Chat、Aider、Cursor、Gemini CLI、Kimi Code、Kiro、Google Antigravity 等。不同平台可以用不同安裝命令，例如：

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Codex 使用者還需要在 ~/.codex/config.toml 的 [features] 下加入：

`1`	`multi_agent = true`

README 也說明，Codex 使用 $graphify，不是 /graphify。

它能處理哪些檔案

Graphify 覆蓋的輸入類型很廣。

程式碼方面，它支援 31 種語言，包括 Python、TypeScript、JavaScript、Go、Rust、Java、C/C++、Ruby、C#、Kotlin、Scala、PHP、Swift、Lua、Zig、PowerShell、SQL、Shell、JSON 等。

文件方面，它支援：

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

還可以透過可選依賴擴展更多類型：

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

其中，pdf 用於 PDF 提取，office 用於 .docx 和 .xlsx，video 用於影片和音訊轉寫，mcp 用於 MCP stdio server，neo4j 用於推送到 Neo4j，sql 用於 SQL schema 提取。

生成的報告有什麼價值

GRAPH_REPORT.md 不是普通摘要，它會把專案裡更值得 AI 助手關注的關係挑出來。

README 裡提到的報告內容包括：

God nodes：專案裡連接最多的核心概念。
Surprising connections：跨檔案、跨模組的意外連接。
The why：從註解、docstring、設計文件裡提取出的設計理由。
Suggested questions：圖譜特別適合回答的問題。
Confidence tags：關係會標記為 EXTRACTED、INFERRED 或 AMBIGUOUS。

這點很關鍵。普通搜尋只能告訴你「哪裡出現了這個詞」，而圖譜可以回答「這個概念和哪些模組、設定、表、文件有關」。對大型程式碼庫來說，這比單純全文檢索更接近架構理解。

常用命令

Graphify 的常見命令包括：

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

也可以把論文或影片加入圖譜：

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

如果要做 PR 輔助分析，還可以使用：

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

這類命令適合程式碼評審場景：看 PR 影響了哪些圖譜社群、是否和其他 PR 有衝突風險、哪些 review queue 更值得優先處理。

和 MCP、Neo4j、CI 的關係

Graphify 不只是生成 HTML 圖。它也可以把圖譜暴露給 AI 助手反覆呼叫。

例如可以啟動 MCP server：

`1`	`python -m graphify.serve graphify-out/graph.json`

MCP server 提供的能力包括 query_graph、get_node、get_neighbors、shortest_path、list_prs、get_pr_impact、triage_prs 等。

它也支援 Neo4j 匯出或推送：

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

團隊協作上，README 建議可以提交 graphify-out/，讓團隊每個人拉取後都能共享同一份專案地圖。還可以執行：

`1`	`graphify hook install`

這樣每次 git commit 後自動重建圖譜，並設定 merge driver，避免 graph.json 在多人並行提交時留下衝突標記。

隱私和成本要怎麼看

Graphify 的 README 對隱私邊界寫得比較清楚。

程式碼檔案會透過 tree-sitter 在本地解析，不會發出 API 呼叫。影片和音訊可以透過 faster-whisper 本地轉寫。文件、PDF、圖片這類語義提取內容，則會透過你的 AI 助手模型 API 處理。

如果用 headless graphify extract，可能需要設定這些環境變數：

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

本地 Ollama、AWS Bedrock、Claude Code CLI 等也可以作為 backend。README 還寫明專案沒有 telemetry、usage tracking 和 analytics。

實際使用時要注意：程式碼本地解析不等於所有內容都不出網。涉及文件、PDF、圖片或雲端模型時，仍然要看 backend、API key、企業合規和資料邊界。

適合哪些場景

Graphify 適合幾類使用者：

想讓 Claude Code、Codex、Cursor、Gemini CLI 更懂專案結構的開發者。
需要快速理解大型陌生程式碼庫的人。
需要把程式碼、SQL schema、文件、設定放在一起分析的團隊。
做架構審查、PR review、重構影響分析的人。
希望把專案知識暴露成 MCP 工具給 Agent 使用的人。
想為團隊保留「專案地圖」的技術負責人。

它不一定適合所有專案。小型腳本、一次性 demo、結構非常簡單的倉庫，用普通搜尋和 README 可能已經夠用。Graphify 的價值更容易出現在模組多、文件多、團隊協作多、AI 助手頻繁參與開發的大專案裡。

小結

Graphify 的意義在於，它把 AI 編程助手的上下文從「臨時讀取檔案」推進到「長期可查詢的專案知識圖譜」。

對開發者來說，它不是替代 IDE、搜尋或 LSP，而是給 AI 助手補一層結構化記憶：哪些模組重要、哪些概念連接緊密、哪些文件解釋了設計理由、某個 PR 會影響哪些社群。隨著 Codex、Claude Code、Gemini CLI、Antigravity 這類 Agent 工具繼續普及，這類「專案圖譜層」會越來越有用。

參考來源：

GitHub：safishamsi/graphify

agentmemory 項目解析：給 Claude Code、Codex 和 Cursor 加持久記憶

Tue, 19 May 2026 10:56:50 +0800

rohitg00/agentmemory 是一個面向 AI 編程 Agent 的持久記憶系統。它的目標很明確：讓 Claude Code、Codex CLI、Cursor、Gemini CLI、OpenCode 等工具不必每次都重新理解項目背景、架構決策和歷史問題。

項目地址：https://github.com/rohitg00/agentmemory

截至寫作時，GitHub API 顯示這個倉庫已有約 1.3 萬 star，主要語言是 TypeScript，許可證爲 Apache-2.0。README 的描述是“Persistent memory for AI coding agents”。

它解決什麼問題

AI 編程 Agent 的常見痛點是記憶斷裂。今天讓 Agent 修了一個認證問題，明天再開新會話，它可能又不知道：

認證中間件在哪個文件。
項目爲什麼選擇某個庫。
哪些測試已經覆蓋。
哪些 bug 曾經修過。
團隊偏好的實現方式是什麼。

傳統做法是寫 CLAUDE.md、.cursorrules 或項目說明。但這類靜態文件需要人工維護，而且越寫越長，最後容易變成“所有內容都塞進上下文”。

agentmemory 的思路是：後臺記錄 Agent 的觀察、工具調用和會話內容，壓縮成可搜索記憶，再在後續會話中按需取回相關上下文。

支持哪些 Agent

README 中列出的支持範圍很廣，包括：

Claude Code
Codex CLI
Cursor
Gemini CLI
OpenClaw
Hermes
OpenCode
Cline
Goose
Roo Code
Windsurf
Aider

它的連接方式主要包括 hooks、MCP 和 REST API。只要客戶端支持 MCP 或 HTTP，就有機會接入同一個 memory server。

快速啓動

README 給出的基本安裝方式：

npm install -g @agentmemory/agentmemory
agentmemory
agentmemory demo
agentmemory connect claude-code

也可以直接用 npx：

`1`	`npx @agentmemory/agentmemory`

默認服務端口包括：

API：3111
實時 viewer：3113

打開：

`1`	`http://localhost:3113`

可以看到 memory 構建過程、session、知識圖譜、健康狀態等信息。

和靜態記憶文件有什麼不同

靜態記憶文件適合保存規則，比如編碼風格、命令、目錄說明。agentmemory 更偏運行時記憶，適合保存 Agent 實際做過什麼、查過什麼、修過什麼。

README 中強調了幾類能力：

自動捕獲會話和工具調用。
BM25 + Vector + Graph 混合搜索。
MCP 工具暴露。
實時 viewer。
session replay。
本地運行，不依賴外部數據庫。
支持多個 Agent 共享同一套記憶服務。

它不是替代所有項目文檔，而是補上“會話歷史和工作流記憶”這一層。

典型場景

第一，長期維護同一個代碼庫。Agent 可以記住以前修過的模塊、測試策略和關鍵文件。

第二，多工具混用。比如平時用 Claude Code，有時用 Codex CLI 或 Cursor。如果這些工具都接入同一個 memory server，就能共享部分上下文。

第三，複雜任務拆分。長任務中間被壓縮或換會話時，記憶系統可以幫助恢復關鍵狀態。

第四，團隊內沉澱經驗。重複出現的 bug、架構取捨和操作步驟可以沉澱成可檢索信息。

使用時要注意什麼

第一，自動記憶不是越多越好。需要關注隱私、密鑰、客戶數據和敏感代碼，不要把不該記錄的內容放進長期記憶。

第二，記憶召回有誤差。即使 README 給出了基準測試結果，實際項目裏仍然要把召回內容當作參考，而不是事實來源。

第三，多個 Agent 共用記憶時，要設計好隔離邊界。個人項目、公司項目、客戶項目不應該混在同一個無隔離 memory 空間裏。

第四，MCP 工具數量很多時，要注意工具暴露面。只開放實際需要的能力，避免讓 Agent 獲得過寬的寫入、刪除或導出權限。

適合誰

agentmemory 適合已經重度使用 AI 編程 Agent 的用戶。尤其是：

長期維護一個項目的獨立開發者。
經常切換 Claude Code、Codex、Cursor 的用戶。
想研究 MCP、hooks 和 Agent 工作流的開發者。
希望把會話歷史變成可檢索資產的小團隊。

如果只是偶爾讓 AI 改一個小腳本，靜態說明文件就夠了。如果已經把 AI Agent 當作日常開發搭檔，持久記憶系統會更有意義。

小結

agentmemory 解決的是 AI 編程中的“重新解釋成本”。它把會話、工具調用和項目經驗沉澱爲可搜索記憶，讓後續 Agent 更容易接上上下文。

這類工具的方向很重要，但也要謹慎使用。記憶系統越強，越需要重視數據邊界、權限控制和清理機制。真正落地時，建議先在個人項目或非敏感代碼庫裏試用，再逐步擴大範圍。

參考項目：https://github.com/rohitg00/agentmemory

內容發太多平臺太累？AiToEarn 想用 AI Agent 幫創作者省點事

Tue, 19 May 2026 10:56:50 +0800

yikart/AiToEarn 是一個面向創作者、品牌和一人公司的 AI 內容營銷項目。它試圖把內容創作、發佈、互動運營和變現放到同一套 Agent 工作流裏，覆蓋抖音、小紅書、快手、B 站、視頻號、TikTok、YouTube、Facebook、Instagram、Threads、X、Pinterest、LinkedIn 等平臺。

項目地址：https://github.com/yikart/AiToEarn

官網地址：https://aitoearn.ai/

截至寫作時，GitHub API 顯示這個倉庫已有約 1.5 萬 star，主要語言是 TypeScript，許可證爲 MIT。README 把它描述爲一個給 OPC（一人公司）、創作者、品牌和企業使用的內容營銷智能體平臺。

它的定位

AiToEarn 不是單一的文案生成工具，也不只是定時發佈工具。它把內容營銷拆成四類 Agent 能力：

Monetize：內容變現。
Publish：跨平臺內容發佈。
Engage：內容互動運營。
Create：內容創作。

這個定位很適合現在的創作者工作流。很多內容團隊的問題不在於“能不能生成一段文案”，而是生成之後還要排期、分發、互動、覆盤，還要把內容和商業任務連接起來。

核心功能

Monetize：內容賺錢

AiToEarn 提供面向推廣任務的內容變現能力。README 中提到三種結算模式：

結算模式	全稱	含義
CPS	Cost Per Sale	按成交額結算
CPE	Cost Per Engagement	按互動量結算
CPM	Cost Per Mille	按播放量結算

這部分更像一個內容任務市場，把品牌推廣需求和創作者內容分發連接起來。

Publish：內容發佈 Agent

Publish 負責把內容分發到多個平臺，減少逐個平臺手動發佈的重複勞動。README 中列出的覆蓋範圍包括國內外主流短視頻、圖文和社交平臺。

它的實用點在於統一排期和統一管理。對矩陣賬號、跨平臺分發、出海內容團隊來說，這類能力比單點 AI 文案更有價值。

Engage：內容互動 Agent

Engage 通過瀏覽器插件實現自動化互動運營，例如點贊、收藏、關注、評論回覆和品牌監測。

使用這類能力時要注意平臺規則。自動化互動很容易觸及平臺風控，正式使用前應確認賬號權限、頻率控制、平臺條款和團隊合規要求。

Create：內容創作 Agent

Create 負責內容生成。README 中提到視頻生成模型、視頻翻譯、視頻剪輯、圖片生成和批量創作任務。

這部分適合大規模內容生產，但仍然需要人工審校。尤其是品牌內容、廣告素材和跨語言內容，不能只看生成速度，還要看事實準確性、版權風險和調性一致性。

五種使用方式

AiToEarn README 給了五種入口：

方式	適合誰	是否需要部署
打開網站直接用	所有用戶	不需要
在 OpenClaw 中用	OpenClaw 用戶	不需要
在 Claude / Cursor 等 AI 助手中用	AI 工具用戶	不需要
Docker 一鍵部署	想私有化部署的團隊	需要服務器
源碼開發	開發者	需要開發環境

其中，MCP 支持是一個值得關注的點。它意味着 Claude、Cursor 或其它兼容 MCP 的 Agent 可以把 AiToEarn 當作一個外部能力來調用。

通用 MCP 配置裏常見的信息包括：

1
2

MCP 地址：https://aitoearn.ai/api/unified/mcp
認證 Header：x-api-key: 你的API-Key

自部署用戶則需要替換爲自己的服務地址。

Docker 部署

README 中給出的 Docker 啓動方式比較直接：

1
2
3

git clone https://github.com/yikart/AiToEarn.git
cd AiToEarn
docker compose up -d

啓動後打開：

`1`	`http://localhost:8080`

如果要做內容發佈，README 建議配置 Relay，因爲社交平臺 OAuth 登錄通常需要開發者憑據。Relay 的作用是借用官方憑據完成授權流程，減少自己申請各平臺開發者賬號的複雜度。

適合誰

AiToEarn 更適合這些用戶：

做多平臺內容分發的創作者。
有矩陣賬號運營需求的小團隊。
想把 AI Agent 接入內容營銷流程的一人公司。
需要私有化部署內容發佈系統的團隊。
想研究 MCP 與內容平臺結合方式的開發者。

如果只是偶爾寫一篇文案，普通 AI 聊天工具就夠了。如果你的工作流包括創作、排期、發佈、互動、任務結算，AiToEarn 這類一體化平臺更值得看。

使用前的注意點

第一，內容變現不等於穩定收益。CPS、CPE、CPM 都依賴平臺流量、內容質量、商家需求和結算規則。

第二，跨平臺發佈和互動自動化要遵守平臺規則。尤其是點贊、關注、評論和批量發佈，不同平臺都有風控策略。

第三，AI 生成內容要經過人工審覈。廣告法、版權、品牌安全、事實準確性都不能交給模型自動判斷。

第四，私有化部署前要評估賬號授權、數據安全、密鑰管理和平臺 API 限制。

小結

AiToEarn 的價值在於把內容營銷從“生成素材”往後推進了一步：發佈、互動、任務和變現都納入 Agent 工作流。它更像一個 AI 內容運營平臺，而不是單純的 AI 寫作工具。

對創作者和小團隊來說，它值得關注；但真正上線前，仍然要把平臺合規、賬號安全、內容審覈和收益預期放在前面。

參考項目：https://github.com/yikart/AiToEarn

讓 AI 自己操作電腦？UI-TARS-desktop 把桌面、瀏覽器和工具都接了起來

Tue, 19 May 2026 10:56:50 +0800

bytedance/UI-TARS-desktop 是字節開源的多模態 AI Agent 項目。它不是單一桌面應用，而是一套 Agent 棧，當前 README 中主要包含兩個方向：Agent TARS 和 UI-TARS Desktop。

項目地址：https://github.com/bytedance/UI-TARS-desktop

官網地址：https://agent-tars.com

截至寫作時，GitHub API 顯示這個倉庫已有約 3.4 萬 star，主要語言是 TypeScript，許可證爲 Apache-2.0。README 對它的描述是“Open-Source Multimodal AI Agent Stack”。

Agent TARS 和 UI-TARS Desktop 的區別

README 把兩個項目放在同一個表格裏：

Agent TARS：通用多模態 AI Agent 棧，把 GUI Agent、視覺能力、終端、瀏覽器和產品工作流連接起來。
UI-TARS Desktop：桌面應用，基於 UI-TARS 模型提供原生 GUI Agent 能力，可以操作本地或遠程電腦、瀏覽器。

簡單說，Agent TARS 更像通用 Agent 運行棧，UI-TARS Desktop 更像桌面端 GUI 操作入口。

Agent TARS 能做什麼

Agent TARS 主要提供 CLI 和 Web UI。它的目標是讓多模態模型通過 MCP 和各種工具完成更接近真人的任務流。

README 中列出的核心能力包括：

一鍵啓動 CLI，支持 headful Web UI 和 headless server。
混合瀏覽器 Agent，可以用 GUI Agent、DOM 或混合策略控制瀏覽器。
Event Stream，用於數據流追蹤和調試。
MCP 集成，可以掛載 MCP Server 接入真實工具。

快速啓動示例：

`1`	`npx @agent-tars/cli@latest`

也可以全局安裝：

`1`	`npm install @agent-tars/cli@latest -g`

使用模型提供商運行：

1
2

agent-tars --provider volcengine --model doubao-1-5-thinking-vision-pro-250428 --apiKey your-api-key
agent-tars --provider anthropic --model claude-3-7-sonnet-latest --apiKey your-api-key

UI-TARS Desktop 能做什麼

UI-TARS Desktop 是桌面 GUI Agent。它基於 UI-TARS 和 Seed-1.5-VL / 1.6 系列模型，重點是讓模型看懂屏幕並執行鼠標、鍵盤操作。

README 中列出的能力包括：

自然語言控制。
截圖和視覺識別。
精確鼠標與鍵盤控制。
跨平臺支持：Windows、macOS、Browser。
實時反饋和狀態顯示。
本地處理，強調隱私和安全。

示例任務包括修改 VS Code 設置、查看 GitHub issue、遠程控制電腦或瀏覽器等。

爲什麼 GUI Agent 重要

傳統自動化依賴 API、DOM 或腳本。GUI Agent 的目標是直接面對屏幕：看見按鈕、輸入框、菜單和狀態，再通過鼠標鍵盤完成操作。

這有兩個價值：

第一，很多軟件沒有穩定 API，或者 API 覆蓋不到完整流程。GUI Agent 可以像人一樣從界面入手。

第二，多模態模型可以處理截圖、文檔、網頁和應用界面，把視覺理解和操作結合起來。

但它也有侷限。GUI 操作容易受分辨率、語言、佈局變化、彈窗、網絡延遲影響。對生產流程來說，仍然需要權限控制、執行確認和錯誤回滾。

和 MCP 的關係

Agent TARS 強調 MCP 集成。MCP 的價值在於把瀏覽器、文件、命令行、數據庫、內部服務等工具統一給 Agent 調用。

對複雜任務來說，單靠 GUI 點擊不夠穩定。更好的方式往往是：

能用 API 的地方走 API。
需要看頁面狀態時用視覺。
需要真實網頁交互時用瀏覽器。
需要本地軟件操作時用 GUI Agent。

UI-TARS-desktop 這類項目正在探索的，就是把這些能力放到同一個 Agent 棧裏。

使用前要注意什麼

第一，桌面 Agent 有執行風險。它能操作鼠標、鍵盤和瀏覽器，就必須限制權限，避免誤操作文件、賬號、支付或生產系統。

第二，遠程電腦和遠程瀏覽器操作要注意安全邊界。不要把未認證的控制入口暴露到公網。

第三，多模態模型可能誤識別界面。關鍵操作前最好有人確認，尤其是刪除、提交、支付、發帖、交易等不可逆操作。

第四，模型供應商、API key 和本地數據要分開管理，不要把敏感憑據寫進公開配置。

適合誰

UI-TARS-desktop 適合這些場景：

想研究 GUI Agent 和 Computer Use 的開發者。
需要讓 AI 操作桌面應用或瀏覽器的團隊。
想把 MCP 工具、瀏覽器操作和視覺模型組合起來的 Agent 開發者。
需要遠程電腦 / 遠程瀏覽器操作實驗環境的用戶。

如果只是簡單網頁自動化，普通 Playwright 或 Selenium 可能更直接。如果任務涉及桌面軟件、多模態理解和複雜工具鏈，UI-TARS-desktop 更值得看。

小結

UI-TARS-desktop 的看點在於它不是隻做一個“會點按鈕”的桌面助手，而是把 GUI Agent、視覺模型、瀏覽器、CLI、MCP 和遠程操作放進同一套多模態 Agent 棧。

這類項目代表了 AI Agent 的一個重要方向：從文本對話走向真實軟件環境。但越接近真實操作，越需要權限管理、執行審計和人工確認。試用時建議先從低風險任務開始。

參考項目：https://github.com/bytedance/UI-TARS-desktop

Claude Code 省 Token 指南：模型、MCP、CLAUDE.md 和 Skills 怎麼影響快取

Mon, 18 May 2026 18:30:24 +0800

Claude Code 長任務裡，Prompt Cache 命中率會直接影響成本和速度。很多人只知道「快取能省 Token」，但不清楚哪些操作會讓快取突然失效。

理解它並不難：每次請求都可以看成一條從左到右的上下文鏈條：

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

越靠左的內容越穩定，快取收益越大；越靠左的內容一變，後面的快取也更容易跟著失效。反過來，越靠右的內容變化，影響範圍越小。

所以優化 Claude Code 的 Prompt Cache，不是靠玄學，而是靠一個原則：任務開始前把模型、MCP、Skills、CLAUDE.md 等基礎上下文準備好，任務中途盡量不要改。

Prompt Cache 快取的不是文字本身

Prompt Cache 不是簡單地把提示詞字串存起來。對 Transformer 模型來說，更關鍵的是前綴上下文經過注意力層計算後的 Key/Value 狀態，也就是常說的 KV cache。

這意味著兩個事實：

同一段上下文，只要前綴保持穩定，就可以在後續請求中複用一部分計算結果。
如果模型、工具定義、系統提示詞或前綴訊息發生變化，之前的快取就可能無法複用。

Anthropic 官方文件也把失效層級概括為 tools -> system -> messages。工具定義變化會影響整段快取，系統層變化會影響 system 和 messages，messages 層變化則主要影響訊息快取。

Claude Code 裡還會額外涉及 CLAUDE.md、Skills、MCP、外掛和子代理等上下文，所以實際使用時更容易踩到快取失效點。

快取殺手一：中途切換模型

切模型是影響最大的操作。

Prompt Cache 是按模型隔離的。Opus、Sonnet、Haiku 這類模型的結構和權重不同，同一段文字算出來的 KV cache 也不同。你在 Opus 裡跑了很長上下文，再切到 Sonnet，並不能讓 Sonnet 複用 Opus 的快取。

這會帶來一個反直覺結果：中途為了省錢切模型，可能反而讓前面已經累積的快取全部失效。原本可以按 cache read 價格讀取的上下文，需要重新寫入和計算。

更穩妥的做法是：

主對話盡量固定一個模型。
需要便宜模型處理支線任務時，用 subagent 隔離出去。
讓支線代理完成搜尋、探索、整理，再把結果摘要交回主對話。

這樣主對話的長上下文盡量不動，快取命中率更穩定。

快取殺手二：中途新增 MCP 或重載外掛

MCP 會向 Claude Code 提供工具。新增 MCP 伺服器後，工具列表會變化，而工具定義處在上下文鏈條最左側。

從 Prompt Cache 的角度看，工具列表一變，後面的 system 和 messages 都可能需要重新計算。尤其是 MCP 很多時，工具定義本身就可能占用大量 Token，快取失效的代價會很明顯。

不過有一個細節：Claude Code 通常在會話啟動時讀取 MCP 配置。你中途改了配置，當前 session 不一定立刻受影響。真正需要小心的是觸發重新載入的動作，例如重啟、恢復會話、重新載入外掛或讓工具列表重新組裝。

建議是：

開始長任務前，一次性裝好需要的 MCP。
不要做一半才發現缺工具，再安裝並重載。
對大型 MCP 工具集，優先考慮按需載入或減少預設啟用數量。
不常用的 MCP 不要長期掛在預設配置裡。

如果工具定義穩定，Prompt Cache 才有長期命中的基礎。

快取殺手三：中途修改 CLAUDE.md

CLAUDE.md 是 Claude Code 的專案記憶文件，適合放構建命令、測試命令、架構約定、程式碼風格和專案注意事項。

它對 Claude Code 很有用，但也會進入上下文。官方說明指出，CLAUDE.md 會在 session 開始時讀取，並作為使用者訊息提供給 Claude；它也會使用 Anthropic 的 Prompt Cache。首次請求會按完整輸入計費，後續請求如果在快取有效期內命中，就按更低的 cache read 成本處理。

問題在於：CLAUDE.md 是內容定址的。你一改文件內容，舊快取就對不上了。

所以不要在長任務中途頻繁改 CLAUDE.md。更好的方式是：

任務開始前先檢查 CLAUDE.md 是否夠用。
把穩定規則寫進去，把臨時指令放在目前對話裡。
如果只是一次性任務，不要為了臨時需求修改長期記憶文件。
如果必須改，最好在一個階段結束後再開始新 session。

CLAUDE.md 應該是穩定的專案說明，而不是每輪任務都改的便條。

快取殺手四：中途安裝或更新 Skills

Skills 也是上下文的一部分。安裝新 Skill、更新 Skill，或者讓 Skill 列表發生變化，都會讓注入到會話裡的上下文不同。

這類變化通常不會在目前 session 裡立刻完整生效，而是在重新載入、恢復會話或新開會話時體現出來。問題是，一旦重新組裝 messages，舊快取就可能命中不了。

建議和 MCP 類似：

開始任務前先確認需要哪些 Skills。
同一類任務盡量固定 Skill 集合。
不要在一個長任務中途邊做邊裝 Skill。
如果安裝了新 Skill，最好把它當成新階段的開始。

對經常做內容生產、程式碼審查、部署、翻譯的工作流，可以把常用 Skills 固定下來，讓上下文結構盡量穩定。

快取殺手五：空閒時間超過 TTL

Prompt Cache 不是永久保存。常見預設有效期是幾分鐘級別，Anthropic 文件和 Claude Code 相關說明裡都提到過 5 分鐘左右的快取窗口。超過 TTL 後，即使你發送完全一樣的請求，服務端也可能已經清掉快取。

這也是很多長任務使用者的體感來源：剛才還很省，去喝杯咖啡回來，再發下一步，Token 又突然漲上去了。

長任務尤其容易遇到這個問題。你可能要看 Claude Code 的輸出、檢查文件、跑測試、思考下一步，這些操作一不小心就超過 5 分鐘。

如果你的使用環境支援，可以在長任務前啟用 1 小時 Prompt Cache TTL：

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

在 Windows PowerShell 裡可以寫成：

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

需要注意的是，1 小時快取寫入成本通常會高於 5 分鐘快取寫入成本。它不適合所有短任務，但對大型程式碼庫、長對話、複雜多步驟開發任務，往往比頻繁快取過期更划算。

怎麼安排一次更省 Token 的 Claude Code 長任務

比較穩的流程可以這樣做：

任務開始前選定模型，不要中途頻繁切換。
提前啟用需要的 MCP，不用的 MCP 先關掉。
檢查 CLAUDE.md，只保留穩定、關鍵、長期有效的規則。
提前準備好本次任務需要的 Skills。
如果是複雜任務，考慮啟用 1 小時 TTL。
把大任務拆成幾個階段，但每個階段內部盡量保持上下文結構穩定。
需要探索支線問題時，用 subagent 或單獨 session，不要污染主對話。

這套做法的目標不是絕對不讓快取失效，而是避免那些代價最高、最容易被忽略的失效。

一個簡單判斷標準

你可以用一句話判斷某個操作是否危險：

這個操作會不會改變模型、工具定義、系統上下文或會話開頭的固定訊息？

如果答案是會，那它大概率會影響 Prompt Cache。越靠近上下文鏈條左側，影響越大。

常見操作可以這樣理解：

切模型：高風險，模型快取隔離。
新增 MCP 或重載外掛：高風險，工具列表變化。
修改 CLAUDE.md：中高風險，專案記憶變化。
安裝 Skills：中高風險，注入上下文變化。
普通對話繼續追問：低風險，主要追加 messages。
空閒超過 TTL：高風險，服務端快取過期。

小結

Claude Code 的 Prompt Cache 優化，關鍵不是背參數，而是讓會話前綴穩定。

模型不要隨便切，MCP 和 Skills 不要邊做邊裝，CLAUDE.md 不要當臨時草稿頻繁改，複雜任務盡量延長 TTL。只要這些基礎動作穩定下來，Claude Code 在長任務裡的 Token 成本和回應速度都會更可控。

最實用的一句話是：開始前配好，開始後少動。

參考資料

easy-vibe：給 Vibe Coding 初學者的一張學習地圖

Sat, 16 May 2026 22:44:43 +0800

easy-vibe 是 Datawhale 開源的 Vibe Coding 學習專案。它面向的不是已經熟練使用 AI 編程工具的開發者，而是剛開始接觸 Vibe Coding 的學生、產品經理、設計師、營運、獨立開發者和普通技術愛好者。

這個專案的價值不在於又列出一批 AI 工具，而是把「怎麼開始用 AI 做專案」拆成了更容易理解的學習路徑。對很多新手來說，真正困難的不是不知道有 Claude Code、Cursor、MCP 或 Agent，而是不知道應該先學什麼、怎麼練、什麼時候進入進階工具。

Vibe Coding 新手最缺的是路徑

Vibe Coding 這幾年很紅，但它對新手並不友好。

表面上看，只要會描述需求，就可以讓 AI 寫程式。實際上，只要任務稍微複雜一點，問題就會出現：需求說不清，模型改錯檔案，專案結構看不懂，錯誤不會處理，依賴裝不上，提示詞越寫越亂，最後只能回到「複製程式碼到聊天框」的狀態。

所以 Vibe Coding 入門不能只教「怎麼寫提示詞」。它至少要解決幾件事：

如何把想法拆成可執行任務；
如何讓 AI 理解專案結構；
如何看懂模型生成的程式碼；
如何處理錯誤和迭代；
如何使用終端和本地開發環境；
如何從網頁聊天過渡到真正的 AI 編程工具。

easy-vibe 的意義就在這裡：它試圖把這些內容整理成一條學習路線，而不是讓新手自己在工具、教程和術語裡迷路。

它不是單點教程，而是路線圖

從專案介紹看，easy-vibe 覆蓋了基礎教程、互動式練習、視覺化內容、RAG、終端工具、AI 編程工具，以及更進階的 Claude Code、MCP、Skills、Agent Teams 等主題。

這類組織方式比較適合初學者。因為 AI 編程不是一個單獨技能，而是一組能力的組合：

會描述需求；
會拆任務；
會讀專案；
會讓模型改程式碼；
會執行和驗證；
會根據錯誤繼續迭代；
會把常用流程沉澱成工具或技能。

如果只學某一個工具，很容易被工具介面限制住。換一個模型、換一個編輯器、換一個 CLI，就又不知道怎麼做。路線圖的好處是先建立工作方式，再把工具放到合適的位置。

對非程式設計師尤其有用

Vibe Coding 最大的吸引力，是讓非專業程式設計師也能做出原型。

產品經理可以把產品想法變成可互動 demo，設計師可以驗證互動邏輯，營運可以寫內部工具，學生可以快速做課程專案，創業者可以在早期驗證需求。這些人不一定要成為傳統意義上的全職工程師，但需要掌握一套「讓 AI 幫我把想法落地」的方法。

這也是 easy-vibe 適合中文社群的原因。很多中文使用者已經知道 AI 能寫程式，但還缺少系統入門材料：從開發環境、提示詞、專案結構、除錯方法到 Agent 工具使用，最好能用中文解釋清楚，並配合練習逐步推進。

對這類使用者來說，最重要的不是一上來學複雜框架，而是先跑通完整閉環：提出需求、生成專案、執行起來、發現問題、繼續修改、最終得到一個可用版本。

進階部分開始靠近真實 AI 開發工作流

easy-vibe 裡提到的 Claude Code、MCP、Skills、Agent Teams，已經不只是入門概念。

Claude Code 代表的是終端編程 Agent：模型可以進入本地專案，讀取檔案、修改程式碼、執行命令。MCP 解決的是工具和資料來源接入，讓模型不只停留在聊天框裡。Skills 則把可複用流程沉澱下來，例如固定的專案生成、文件整理、測試檢查或內容生產流程。Agent Teams 進一步把任務拆給多個智能體協作。

這些內容對新手來說可能有點遠，但它們值得提前了解。因為 Vibe Coding 的發展方向已經很清楚：從「讓 AI 寫一段程式碼」，走向「讓 AI 參與一個完整專案流程」。

如果學習路線只停留在提示詞層面，很快就會跟不上工具演進。反過來，如果一開始就把所有高階概念塞給新手，又會讓人無從下手。easy-vibe 的合理價值，是把這些內容放在一條逐步升級的路徑裡。

學習時要避免兩個誤區

第一個誤區，是以為 Vibe Coding 等於不會程式也能完全不管程式。

AI 可以生成很多內容，但使用者仍然需要判斷結果是否正確。至少要能看懂專案結構、知道怎麼執行、知道錯誤大概發生在哪裡。即使不寫複雜程式，也要具備基本的工程常識。

第二個誤區，是以為工具越高階越好。

新手不一定一開始就需要 Claude Code、MCP 或多 Agent。更好的順序是先用簡單專案建立回饋循環，再逐步引入終端、版本管理、測試、工具調用和自動化流程。工具要跟任務複雜度匹配，否則很容易變成「看起來很強，但不知道用來做什麼」。

適合怎麼用

如果你剛接觸 Vibe Coding，可以把 easy-vibe 當作學習清單來用。

先從基礎概念和簡單練習開始，不急著追所有工具。做一個小專案，例如個人首頁、資料看板、表單工具、自動化腳本或知識庫 demo。過程中重點觀察 AI 在哪些地方幫得上忙，哪些地方需要你自己確認。

等你能穩定完成小專案，再開始學習更複雜的內容：

用終端工具處理本地專案；
用 Git 管理每次修改；
用 RAG 接入自己的資料；
用 MCP 連接外部工具；
用 Skills 固化重複流程；
用 Agent Teams 拆分複雜任務。

這樣學出來的 Vibe Coding 才不只是會問 AI，而是能把 AI 放進自己的工作流程裡。

總結

easy-vibe 適合被看作 Vibe Coding 的中文入門地圖。它把零散的 AI 編程概念、工具和練習組織成一條路徑，讓新手更容易從「聽說 AI 能寫程式」走到「我能用 AI 做出一個專案」。

Vibe Coding 真正有價值的地方，不是讓人跳過所有學習，而是降低從想法到原型的門檻。你仍然需要理解需求、組織任務、驗證結果和控制風險，但很多重複、枯燥、容易卡住的步驟，可以交給 AI 協助完成。

如果你想系統入門 AI 編程，又不想一開始就陷入工具名詞和複雜工程配置，easy-vibe 是一個值得收藏的起點。

Anthropic financial-services：把金融 Agent 場景做成可複用模板

Sat, 16 May 2026 22:43:08 +0800

anthropics/financial-services 是 Anthropic 面向金融服務產業發布的參考專案。它不是一個單一應用，而是一組可以拆開學習和複用的示例：Agents、Plugins、Skills、MCP 連接器，以及圍繞金融工作流設計的提示詞和整合方式。

這個專案值得關注，不是因為它提供了某個「萬能金融助手」，而是因為它把金融產業裡常見的 AI 落地問題拆成了更具體的組件：不同職位需要什麼 Agent、哪些資料來源需要接入、哪些任務可以自動化、哪些環節仍然需要人工判斷。

它更像金融 Agent 的樣板間

很多企業談 AI Agent 時，容易停留在抽象層面：能讀檔案、能查資料、能寫報告、能調用工具。但真正進入金融場景後，問題會變得具體得多。

投行分析師需要整理公司資料、生成交易簡報、比對可比公司；股票研究需要讀財報、看新聞、做估值和風險分析；私募和資管團隊要篩項目、寫 memo、追蹤投資組合公司；財富管理要把客戶画像、市場資訊和投資建議放在一個合規框架裡。

這些場景不能只靠一個通用聊天框完成。它們需要角色、流程、資料來源、輸出格式和權限邊界。Anthropic 這個倉庫的價值就在這裡：它把金融服務產業裡的多個典型職位和任務拆成可以參考的 Agent 模板。

為什麼要同時提供 Agents、Plugins、Skills 和 MCP

從專案結構看，Anthropic 沒有只給一套提示詞，而是同時提供了多種組件。這背後其實對應了企業落地 Agent 的幾層需求。

Agents 更像面向角色或任務的工作單元。它定義「這個智能體要做什麼、怎樣做、何時調用工具、如何輸出結果」。

Plugins 更像外部能力擴展。金融工作很少只發生在模型內部，往往要連接資料庫、文件系統、市場資料、CRM、研究庫和內部流程系統。

Skills 更像可複用的專業能力包。比如固定格式的分析框架、報告結構、檢查清單、資料處理方法，都可以沉澱成技能，而不是每次重新寫提示詞。

MCP 連接器則解決工具接入和上下文標準化問題。對企業來說，工具越多，越需要一個相對統一的連接方式，否則每個系統都要單獨適配，維護成本會很高。

這幾個部分組合起來，才更接近真實企業裡的 AI 工作流。

金融產業為什麼適合做 Agent 示例

金融服務是很適合展示 Agent 的產業，因為它同時具備三個特點。

第一，資訊密度高。金融工作大量依賴財報、公告、會議紀要、研究報告、交易資料、客戶資料和監管文件。模型如果只靠通用知識，很快就會失效，必須接入真實資料來源。

第二，輸出格式穩定。投資備忘錄、公司簡介、KYC 文件、研究摘要、客戶簡報、基金營運報告，都有相對固定的結構。這讓 Agent 更容易形成可驗證的工作流。

第三，風險邊界清楚。金融產業對合規、稽核、權限和可追溯性要求很高。AI 不能隨意給投資建議，也不能繞過審批流程。這反而逼著 Agent 設計得更工程化：要保留引用、區分事實和推斷、記錄工具調用、限制可執行操作。

所以這個專案不只是給金融公司看的。任何想做企業級 Agent 的團隊，都可以從裡面觀察 Anthropic 如何拆解產業場景。

它覆蓋了哪些典型流程

從專案說明看，這個倉庫覆蓋了多個金融服務方向，包括：

投資銀行；
股票研究；
私募股權；
財富管理；
基金營運；
KYC 和合規相關流程。

這些流程的共同點是：都需要大量閱讀、整理、比對和生成結構化材料。AI 在這裡最適合做的，不是直接替人拍板，而是減少資訊處理和文件生產的時間。

例如，投行場景裡，Agent 可以幫忙整理目標公司資料、抽取關鍵財務指標、生成初版交易摘要。研究場景裡，它可以先讀財報和新聞，列出關鍵變化和待確認問題。KYC 場景裡，它可以輔助檢查資料是否完整、是否存在異常線索。

最終判斷仍然應該由專業人員負責。Agent 的角色更像助理、分析員和流程加速器。

對企業落地的啟發

這個倉庫最有參考價值的地方，是它把「模型能力」轉成了「業務組件」。

企業內部做 AI 專案時，經常會遇到一個問題：模型演示很好看，但真正接入業務後很難複用。一個團隊寫了一套提示詞，另一個團隊又重新寫一套；一個系統接了資料庫，另一個系統又重新做介面；安全和稽核要求也散落在各處。

更穩妥的方式是把能力拆成幾類資產：

面向職位的 Agent；
面向流程的 Skills；
面向系統接入的 MCP 連接器；
面向權限和稽核的執行規則；
面向業務輸出的模板和檢查清單。

這樣做的好處是，企業不會每次都從「寫一個聊天機器人」開始，而是逐步積累可維護的 AI 工作流資產。

不能忽視合規和責任邊界

金融 Agent 最容易被誤解的一點，是把「能生成分析」誤認為「可以替代決策」。

在金融服務裡，AI 輸出通常只能作為輔助材料。它可以整理事實、生成草稿、提示風險、補全文檔，但不能繞過投研、風控、法務、合規和客戶適當性要求。尤其是涉及投資建議、交易決策、客戶資產配置和身份審查時，人工審批和責任鏈必須保留。

這也是為什麼企業級 Agent 不能只看模型回答品質。它還要看：

資料來源是否可靠；
引用和證據是否可追溯；
工具調用是否有記錄；
敏感資料是否被限制；
輸出是否經過人工確認；
錯誤結果能否被發現和回滾。

這些問題不解決，Agent 越自動化，風險半徑就越大。

總結

anthropics/financial-services 更像一套金融 Agent 參考實作，而不是一個開箱即用的金融產品。它展示了 Anthropic 對企業 AI 落地的一種思路：不要只做通用聊天助手，而是圍繞具體職位、具體流程、具體資料來源和具體權限邊界來組織 Agent。

對金融機構來說，它可以作為內部 AI 工作流設計的參考。對開發者來說，它提供了一個觀察企業級 Agent 架構的樣本：Agents 負責角色和任務，Skills 沉澱專業流程，Plugins 和 MCP 負責連接外部系統，最終讓模型進入真實業務流程。

如果說早期 AI 工具解決的是「怎麼讓模型回答問題」，這類專案更關心的是「怎麼讓模型在受控邊界內參與工作」。這才是企業級 Agent 真正難的地方。

AI Agent 到底怎麼進化的？2022-2026 五代演進完整梳理

Sat, 16 May 2026 19:19:52 +0800

AI Agent 的發展不是一夜之間發生的。

2022 年底，ChatGPT 還只是會聊天的視窗。到 2026 年，Agent 已經開始具備工具調用、文件操作、電腦控制、長期記憶、遠端協作和常駐執行能力。四年時間裡，它從「回答問題的模型」逐步變成「能推進任務的數位工作者」。

如果按時間線看，AI Agent 大致經歷了五代演進。每一代都解決了上一代的核心缺陷，也製造了新的泡沫和新的安全問題。

總覽：五代 Agent 時間線

階段	時間	關鍵詞	能力變化	核心問題
第零代	2022 年末 - 2023 年初	對話框	會生成文本，但不能行動	模型和現實世界斷裂
第一代	2023 年中 - 2023 年末	工具調用	能輸出結構化調用，接入 API 和 RAG	開環執行、任務迷路
第二代	2023 年末 - 2024 年	工程化工作流	有規劃、狀態、反思和多 Agent 協作	工作流易複製，低代碼泡沫
第三代	2024 年 - 2025 年	Computer Use	能看螢幕、點滑鼠、操作 GUI	權限、安全和誤操作風險
第四代	2025 年 - 2026 年	MCP / Skills / 常駐	有工具網路、長期上下文和專業技能	常駐執行擴大風險半徑
第五代前瞻	2026 年之後	閉環與世界模型	可能擁有更強記憶、驗證和物理行動能力	治理難度繼續上升

2022 年末：第零代，ChatGPT 對話框時代

第零代的起點，是 2022 年 11 月 30 日 ChatGPT 發布。

這一代 AI 還不能算真正的 Agent。它有很強的語言生成能力，但主要被困在對話框裡。它可以寫一段 Python 代碼，卻不能在你的電腦上執行；可以規劃旅行，卻不能打開網站訂票；可以告訴你文件應該怎麼改，卻不能進入文件系統執行修改。

這一代的能力邊界很清楚：

能理解自然語言；
能生成文章、問答、代碼和方案；
不能主動訪問最新資料；
不能穩定讀取企業內部資料；
不能執行外部動作；
不能管理長期任務狀態。

所以第零代最核心的問題是：模型能力和現實世界之間斷裂。它能想、能說，但不能行動。

這一階段也出現了第一波泡沫：提示詞工程師、提示詞模板市場、提示詞課程和提示詞認證。早期模型確實對 prompt 很敏感，但市場把一個臨時補丁誤解成了長期護城河。

後來 GPT-4 級別模型、系統提示、函數調用和產品預設引導逐漸成熟，大量提示詞模板失去稀缺性。這個現象後來反覆出現：新能力出現時，中間層爆發；下一代系統把能力內化後，中間層蒸發。

2023 年中：第一代，工具調用覺醒

第一代 Agent 的關鍵詞是工具調用。

2023 年 6 月，OpenAI 發布 function calling。它允許開發者向模型描述函數名、用途、參數類型和 JSON Schema。模型理解用戶請求後，可以不再輸出普通自然語言，而是輸出一個結構化 JSON 調用，再由外部系統執行。

這一步的架構意義很大：模型開始從「只會說話的大腦」，變成可以驅動外部工具的大腦。

第一代的關鍵能力包括：

根據用戶意圖選擇工具；
輸出結構化參數；
調用外部 API；
把 API 結果帶回模型繼續推理；
通過 RAG 接入外部知識；
通過插件和知識庫形成早期 persona。

同一時期，RAG 和向量資料庫流行起來。它們解決的是模型不知道最新資訊、企業私有資料和內部知識的問題。系統先檢索相關文檔片段，再把材料放進上下文，讓模型基於這些材料回答。

於是第一代 Agent 的基本結構出現了：

你是誰：系統提示和 persona；
你知道什麼：知識庫、RAG、私有文檔；
你能做什麼：函數調用、插件、外部 API。

這一代最典型的泡沫是 AutoGPT。它展示了一個很誘人的想法：用戶只給一個宏大目標，AI 自己拆解任務、搜索、寫文件、評估、循環，直到它認為完成。

但 AutoGPT 很快暴露問題。它缺少狀態約束、終止條件和可靠反饋，經常陷入錯誤方向，反覆調用錯誤參數，或者燒掉大量 API 請求。第一代的教訓很直接：工具加死循環，不等於生產級 Agent。

2023 年末到 2024 年：第二代，工程化工作流

AutoGPT 的失敗讓行業意識到，不能只靠模型自由發揮。複雜任務需要結構化流程。

第二代 Agent 的關鍵詞是工程化工作流。Agent 不再只是一次模型調用，而是一個有狀態、有控制流、有評估機制的軟體系統。

這一代的關鍵能力包括：

任務規劃：把大目標拆成步驟；
狀態管理：記錄任務進行到哪裡；
反思修正：生成後自評，再修改；
工具編排：在不同工具之間切換；
人機協作：在關鍵節點讓人確認；
多 Agent 協作：讓不同角色分工。

典型範式是 ReAct，也就是 Reasoning + Acting。模型先推理，再調用工具，再根據觀察結果進入下一輪推理。這樣 Agent 不再盲目行動，而是每一步都有可審計的邏輯和反饋。

第二代的價值，是把模型能力放進可控流程裡。一個設計好的 workflow，有時能讓較小模型完成比單次大模型調用更穩定的結果。

但這一代也帶來低代碼 Agent 平台泡沫。很多平台用拖拽方式組合 prompt、RAG、插件和流程，確實降低了搭建門檻。但如果一個流程可以被低成本複製，平台本身就很難形成護城河。

低代碼工具能吃到早期紅利，但紅利不等於壁壘。

2024 到 2025 年：第三代，Computer Use 進入真實界面

第三代 Agent 的關鍵詞是 Computer Use。

此前的工具調用主要依賴 API，能做什麼取決於開發者提前接好什麼接口。但現實世界裡，大量軟體沒有理想 API，或者 API 不開放、不完整、不統一。

Computer Use 類能力讓模型開始看螢幕、點滑鼠、操作 GUI。它把通用電腦界面本身變成工具。

第三代的關鍵能力包括：

識別螢幕內容；
點擊按鈕、輸入文本、切換視窗；
操作網頁和桌面軟體；
讀倉庫、改文件、跑測試；
查看終端輸出和錯誤資訊；
更接近真實工程助手。

這一步把 Agent 從「調用已接好的工具」，推進到「像人一樣操作軟體界面」。它也讓 coding agent 更接近真實工作流：讀專案、改代碼、運行測試、根據報錯繼續修。

但信任邊界也擴大了。AI 操作電腦，意味著它可能誤點、誤刪、誤提交，也可能被網頁、文檔或界面文字誘導。提示注入不再只是聊天問題，而可能變成文件操作、權限和系統安全問題。

第三代的核心教訓是：越接近真實操作，越需要沙箱、審批、回滾和最小權限。

2025 到 2026 年：第四代，MCP、Skills 和常駐數位員工

第四代 Agent 的關鍵詞是常駐、連接、記憶和專業化。

這一代的重點不只是單次任務更強，而是 Agent 開始擁有長期上下文、工具網路、專業技能和時間感。它不再只是一次聊天裡的助手，而更像一個能持續工作的數位員工。

MCP 解決的是工具連接問題。它讓 Agent 用標準方式連接文件系統、資料庫、瀏覽器、設計工具、專案管理工具和企業系統。協議一旦穩定，很多只做「工具連接中間層」的專案就會被壓縮。

Skills 解決的是專業方法問題。工具告訴 Agent 能做什麼，技能告訴 Agent 應該怎麼做。一個好的 skill 不只是 prompt，而是把領域流程、約束、檢查方式、常見坑和工具調用順序封裝起來。

第四代的關鍵能力包括：

長期記憶：保存用戶偏好、專案規則和歷史任務；
專案上下文：讓 Agent 理解代碼庫、文檔和工作規範；
工具網路：通過 MCP、API、瀏覽器和文件系統連接外部世界；
專業技能：用 Skills 封裝任務方法；
常駐執行：可以等待、喚醒、提醒和繼續跟進；
遠端協作：用戶可以從不同設備回來審批和調整。

這一代 Agent 開始有「員工感」：有身份和職責邊界，有長期上下文，有專業工作方法，有時間感，有工具權限，也能在無人盯著時繼續推進任務。

但能力越像員工，風險半徑也越像員工。長期執行、讀取本地資料、持有密鑰、調用工具、處理任務，都讓安全問題從邊緣變成中心。

尤其要注意一點：文本也是攻擊面。如果 Agent 會讀取並遵循 Markdown、說明文檔、技能包、網頁內容，那麼惡意文本就可能改變它的行為。提示注入不再只是聊天問題，而是供應鏈問題、權限問題和執行安全問題。

第四代的核心教訓是：常駐 Agent 不只需要能力，還需要治理。

2026 之後：第五代前瞻，閉環、內在記憶和世界模型

第五代還不是確定歷史，更像是沿著前面四年的演進邏輯繼續外推。

成熟 Agent 至少需要三層閉環：

執行閉環：每一步操作後驗證結果，不符合預期就回滾、修正、重試；
時間閉環：跨多個喚醒週期追蹤長期目標，而不是做完一次動作就結束；
認知閉環：知道哪些資訊確定，哪些只是猜測，哪些已經過期。

第二個方向是內在記憶。過去的記憶大多在模型外部：RAG、向量庫、會話記錄、本地文件、memory.md。如果未來模型架構本身支援跨會話持久狀態，Agent 的記憶系統會被重構。

第三個方向是世界模型。今天很多 Agent 仍是反應式的：觀察、響應、再觀察。真正高風險任務需要模型能預演行動後果。

第四個方向是具身化。前幾代主要發生在數位空間：API、螢幕、文件、瀏覽器、企業工具。下一步可能是把 Agent 的行動能力延伸到物理世界。

第五代真正要解決的問題，是如何讓 Agent 不只會執行任務，還能理解行動後果、管理長期狀態，並在更大風險半徑內保持可靠。

這條時間線背後的六條規律

第一，基座模型能力仍然是天花板。Agent 不是大模型之外的魔法，而是大模型能力通過工程系統釋放出來的方式。

第二，工程化架構會放大模型能力。規劃、驗證、反思、修正、評估和權限控制，比單次生成更接近可交付結果。

第三，開放協議會重塑價值分配。MCP、Skills、專案上下文規範一旦穩定，競爭焦點會從「誰先接了工具」轉向「誰沉澱了真實領域能力」。

第四，Agent 演化的隱含主線是人機信任邊界擴展。從信任文本，到信任 API 調用，到信任複雜工作流，到信任電腦操作，再到信任常駐執行，每一代都把風險半徑往外推。

第五，每一代事故都會變成下一代鐵律。AutoGPT 的無限循環推動結構化編排，vibe coding 的失控推動評估驅動開發，誤刪生產環境推動最小權限和沙箱，技能投毒推動供應鏈安全。

第六，Agent 生態會反覆經歷爆發和滅絕。能力升級會創造臨時中間層，模型或平台內化後又會消滅這些中間層。把時間窗口誤判成護城河，是 AI 創業裡很危險的錯覺。

真正的護城河

AI Agent 領域真正的護城河，不是搶先包裝某個新能力。

更可靠的護城河大概有三類。

第一，垂直領域深度。你是否真的理解一個行業的流程、風險、異常和責任邊界。

第二，資料飛輪。你是否能從真實使用中積累高品質反饋，不斷改進流程、評估、微調和產品判斷。

第三，用戶信任。用戶是否願意把更高價值、更長期、更有風險的任務交給你，而不是只把你當成一次性工具。

當某項能力被平台或基座模型吞噬之後，仍然能沉澱流程、反饋、責任邊界和信任的產品，才更可能留下來。

最後

從 2022 年到 2026 年，AI Agent 的演進不是「模型越來越會聊天」，而是「人類願意交給 AI 的事情越來越多」。

真正成熟的 Agent，不是最敢自動執行的系統，而是知道何時執行、何時驗證、何時暫停、何時請人確認的系統。

如果要判斷一個 Agent 產品是否有長期價值，可以問一個問題：當這個能力被下一代模型或平台內置後，它還剩下什麼？

答案如果是領域流程、真實資料、可驗證結果和用戶信任，那才可能是長期價值。

Claude 連接 Fusion 360：用 AI 修改 STEP 模型的一個實例

Thu, 14 May 2026 20:58:04 +0800

Claude 連接 Fusion 360 之後，可以不只是「講思路」，而是直接參與 CAD 模型修改。一個典型場景是：打開已有的 STEP 檔案，讓 Claude 讀取當前模型、分析結構衝突、規劃尺寸，再透過 Fusion 外掛執行建模修改。

下面用一個行星齒輪分度器的修改過程，整理 Claude + Fusion 360 的基本使用方法。

先啟用 Fusion 360 的 API/MCP 服務

在 Fusion 360 裡先做一次基礎設定：

打開右上角的 Preferences。
進入 General 或「通用」設定。
找到 API 選項。
打開 MCP server。
記下端口號，預設示例是 27182。

然後回到 Claude，進入 Connectors，找到 Fusion 連接器，填入 Fusion 360 的地址和端口。端口一般使用預設的 27182 即可。

連接成功後，Claude 就可以透過 Fusion 插件和當前打開的模型互動。

打開 STEP 檔案並明確修改目標

這次要修改的是行星齒輪分度器裡的一個齒輪。原始設計裡，這個齒輪透過一顆螺絲作為中心軸固定在支架上。

目標是把它改成軸承結構：

中心孔需要適配軸承；
周圍螺絲孔不能和擴大的中心孔干涉；
支架上的自攻螺絲孔位也要調整為適合軸承旋轉的軸心結構；
最終模型要能導入切片軟體並用於 3D 列印。

這裡的關鍵是，不要只告訴 Claude「幫我改一下」。要把用途、裝配方式、材料和製造工藝說清楚。

Claude 可以透過截圖理解當前模型

之前有人會擔心 Fusion 插件只能執行命令，不能讓 Claude 看到模型。實際測試裡，Claude 可以透過截圖方式識別當前模型狀態。

在這個案例裡，Claude 能看到齒輪結構，並完成幾件事：

識別齒輪和中心孔；
測量或估算相關尺寸；
推薦軸承尺寸；
判斷哪些結構會影響軸承安裝；
發現中心孔擴大後，周圍螺絲孔可能發生幾何干涉。

這一步很重要。它說明 Claude 不只是按文字指令盲改，而是可以結合當前模型視圖做結構判斷。

材料和加工方式必須提前說明

如果模型最終用於 3D 列印，必須明確告訴 Claude 材料和工藝。

例如使用 PLA 列印時，軸承孔不能完全按 CNC 金屬加工的公差來設計。直徑為 6mm 的軸承，如果需要壓入配合，可以考慮把孔徑設為約 6.1mm。這個尺寸是否合適，還要結合列印機精度、材料收縮、切片參數和實際測試調整。

如果不說明材料，Claude 可能預設按 CNC 加工思路給尺寸。這樣得到的孔徑對 3D 列印來說可能偏小，後續裝配會很難。

建議在提示裡寫清楚：

1
2
3

這個模型用於 FDM 3D 列印，材料是 PLA。
目標是安裝直徑 6mm 的軸承，需要考慮列印公差和壓入配合。
請不要按 CNC 金屬加工公差處理。

讓 Claude 修改齒輪結構

明確目標後，可以讓 Claude 執行具體修改：

擴大中心孔；
調整周圍干涉的螺絲孔；
增加軸承安裝座；
對邊緣加倒角；
保持齒輪主體和關鍵嚙合結構不變。

在這個案例裡，Claude 會先給出規劃，再調用 Fusion 360 完成建模操作。比如它發現原有螺絲孔和中心孔衝突後，會把孔位向外移一點，避免軸承安裝空間被破壞。

修改完成後，可以檢查模型：

中心軸承座是否成型；
周圍孔位是否還保留功能；
齒輪結構是否被誤傷；
倒角是否影響裝配；
是否存在懸空、薄壁或切片風險。

支架也要一起修改

只改齒輪還不夠。原支架上原本是自攻螺絲安裝孔，如果齒輪中心改為軸承，支架也要配合改成軸承軸心結構。

可以讓 Claude 對支架執行類似修改：

保留整體安裝位置；
把原來的自攻螺絲孔改為柱狀軸心；
控制軸心直徑和高度；
給軸承旋轉預留空間；
避免和支架其他結構干涉。

這樣列印出來後，齒輪可以順利壓入軸承，支架也能提供新的旋轉中心。最終效果是原本靠螺絲固定的結構，變成更順滑的軸承旋轉結構。

導出、切片和列印驗證

CAD 修改完成後，還需要進入實際製造流程：

從 Fusion 360 導出修改後的模型。
導入切片軟體。
檢查孔洞、薄壁、懸垂和支撐。
列印齒輪和支架。
實際壓入軸承。
檢查旋轉是否順滑。

AI 修改 CAD 的結果不能只看螢幕上的模型是否漂亮，必須列印驗證。尤其是軸承、孔位、卡扣、齒輪這類機械結構，0.1mm 級別的誤差就可能決定能不能裝上、轉得順不順。

使用建議

Claude + Fusion 360 適合做這類任務：

在已有 STEP 模型上做局部改造；
調整孔位、倒角、支架、安裝座；
把螺絲固定改成軸承、卡扣或插銷結構；
給 3D 列印模型做公差修正；
快速生成多個改版方案。

但它不適合完全不檢查地直接出最終件。更穩妥的流程是：

人先定義裝配目標和材料工藝。
Claude 負責分析結構並提出修改方案。
Claude 調用 Fusion 執行建模。
人檢查關鍵尺寸和干涉。
列印小樣驗證。
根據實物結果再迭代。

小結

Claude 連接 Fusion 360 的價值，不在於替代 CAD 基礎知識，而在於把「已有模型的局部修改」變得更快。

只要把目標、材料、尺寸、公差和裝配方式說清楚，它可以幫你讀模型、找干涉、改結構、加倒角，再把模型推進到可列印狀態。對於 3D 列印、開源機械件改造和個人工作室的小批量迭代來說，這類 AI CAD 工作流已經很實用。

goose：桌面端、CLI 和 API 一體的開源 AI Agent

Fri, 08 May 2026 13:41:15 +0800

goose 是一個執行在本機的開源 AI Agent。它不只面向程式碼補全，而是希望覆蓋程式碼、研究、寫作、自動化、資料分析等更廣的任務。README 的定位很清楚：提供桌面端、CLI 和 API，既可給普通使用者使用，也可嵌入自訂工作流。

專案已從 block/goose 遷移到 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）。目前倉庫是：

`1`	`https://github.com/aaif-goose/goose`

goose 主要由 Rust 和 TypeScript 編寫，授權為 Apache-2.0。GitHub 描述稱它是一個開源、可擴展的 AI agent，不只給出程式碼建議，還能安裝、執行、編輯和測試，並可接入任意 LLM。

解決什麼問題

許多 AI 編程工具只停留在建議或局部改碼。goose 的目標更廣：讓 AI agent 直接在你的機器上完成任務。

它可用於：

程式碼修改和測試。
本地自動化。
資料研究和寫作。
資料分析。
多步驟工作流。
透過 API 嵌入其他系統。
透過 MCP 擴展工具能力。

如果只是 IDE 補全，Copilot 類工具已足夠。goose 更適合把 AI 放進本機任務執行鏈。

桌面端、CLI、API

goose 提供三種入口。

桌面端支援 macOS、Linux 和 Windows，適合偏好可視化互動的使用者。

CLI 適合終端工作流和本地開發自動化。

API 可作為可嵌入的 agent runtime，供其他系統或內部工具呼叫。

個人使用可先從桌面端或 CLI 開始；團隊內部工具和 agent 平台則應關注 API 與自訂分發。

安裝方式

桌面端：

`1`	`https://goose-docs.ai/docs/getting-started/installation`

CLI：

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases 提供多平台構建。這裡查到的 latest release 是 v1.33.1，發布於 2026-04-29，包含 macOS、Linux、Windows、deb、rpm、Flatpak 等資產。

安裝後建議先按官方 Quickstart 配置 provider，並從低風險目錄開始測試。

Provider

goose 支援 15+ provider，包括 Anthropic、OpenAI、Google、Ollama、OpenRouter、Azure、Bedrock 和其他雲端或 OpenAI-compatible provider。

它可使用 API key，也可透過 ACP 使用已有的 Claude、ChatGPT 或 Gemini 訂閱。

ACP 值得關注，因為很多使用者已有訂閱，但工具未必能直接復用。goose 透過 ACP provider 把訂閱接入 agent 工作流。

使用前仍要確認 provider 條款、額度限制，以及是否適合公司程式碼或敏感資料。

MCP 擴展

goose 支援 Model Context Protocol 擴展。README 提到可連接 70+ extensions。

MCP 的價值在於讓 agent 不只聊天和改檔案，還能透過標準協議接入文件、資料庫、瀏覽器、內部系統、搜尋服務、設計工具或專案管理工具。

對團隊來說，MCP 也可作為更安全的整合層，把內部能力包成明確介面。

和程式碼助手的區別

goose 不只是補全工具，而更像本機 agent runtime。

程式碼助手通常聚焦補全、解釋、生成函式和編輯器局部修改。goose 更強調本地任務執行、多步驟工作流、provider 切換、擴展、桌面端和 CLI、可嵌入 API，以及非程式碼任務。

這也意味著你需要認真處理模型配置、權限、擴展、工作目錄、日誌和憑據管理。

自訂分發

倉庫提供 CUSTOM_DISTROS.md，可構建自己的 goose distro，預配置 provider、extensions 和 branding。

團隊可用它預置允許的 provider、連接內部 MCP server、設定安全策略、限制外部服務，並加入自己的品牌和引導。

使用建議

先安裝桌面端或 CLI。
配置一個確定可用的 provider。
在測試目錄執行簡單任務。
觀察它讀取哪些檔案、執行哪些動作。
再接入 MCP extension。
最後嘗試複雜倉庫或自動化流程。

保持幾個習慣：重要改動前先提交 git，不把 API key 寫進專案檔案，高權限模式只用於可信 workspace，公司資料先確認合規與 provider 政策，自動化結果保留人工 review。

小結

goose 是 AAIF/Linux Foundation 旗下的開源 AI Agent，提供桌面端、CLI 和 API，支援 15+ provider、ACP 訂閱接入和 70+ MCP extensions。

它的價值不只是能寫程式碼，而是把模型、工具、擴展和本機執行環境放進同一個 agent 框架。

參考資料

CC Switch：一個桌面工具統一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw

Wed, 06 May 2026 09:03:08 +0800

CC Switch 是一個面向 AI 程式設計重度使用者的桌面管理工具。它要解決的問題很直接：現在很多人同時使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw，但每個工具都有自己的設定格式、Provider 寫法、MCP 設定和 Skills 管理方式。

當你只用一個工具時，手動改設定還能忍；一旦多個工具混用，再加上官方帳號、第三方 API、中轉服務、本地模型和團隊共享設定，手動編輯 JSON、TOML、.env 很快就會變成一件很煩的事。

CC Switch 的定位，就是把這些分散設定收進一個跨平台桌面應用裡。

它解決什麼問題

現代 AI 程式設計工具越來越像「命令列裡的開發同事」，但每個工具的生態還沒有完全統一。

常見痛點包括：

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 設定格式不同。
切換 API Provider 時，要反覆改設定檔。
MCP server 在不同工具之間重複設定。
CLAUDE.md、AGENTS.md、GEMINI.md 這類提示檔案難以統一維護。
Skills 安裝、同步、備份和解除安裝缺少一個集中入口。
多個帳號、多個 relay、多個模型服務切換很容易搞混。
設定檔手動修改出錯後，排查成本很高。

CC Switch 的思路是：不要讓使用者記住每個工具的設定細節，而是用一個統一介面管理 Provider、MCP、Prompts、Skills、Sessions 和代理。

支援哪些工具

README 中列出的核心支援對象包括五類：

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

這幾個工具本身定位相近，都是圍繞 AI 程式設計、Agent 工作流和命令列協作展開。但它們的設定體系不同，CC Switch 的價值就在於把這些差異包裝起來。

對經常比較不同 AI 程式設計工具的人來說，這比每次手動翻設定檔省心很多。

Provider 管理

CC Switch 的第一層能力是 Provider 管理。

它內建了 50 多個 Provider 預設，README 中提到的方向包括 AWS Bedrock、NVIDIA NIM，以及各種社群 relay。使用者可以複製 API key，一鍵匯入，然後在介面中切換。

實用點主要有幾個：

一鍵新增 Provider。
Provider 拖曳排序。
系統匣快速切換。
Provider 匯入和匯出。
部分通用 Provider 可同步到多個應用。

對很多人來說，這個功能已經足夠有吸引力。因為 AI 程式設計工具的日常使用，經常不是「模型不會用」，而是「今天這個 key 用哪個工具、哪個 endpoint、哪個帳號」容易亂。

本地代理與故障切換

除了寫設定檔，CC Switch 還提供本地代理模式。

這個能力的重點是：

熱切換 Provider。
格式轉換。
自動故障轉移。
熔斷器。
Provider 健康檢查。
請求修正。

簡單說，它不只是把設定寫進目標工具，還可以在中間加一層本地代理，讓不同工具透過代理存取模型服務。

這對多 Provider 使用者很有用：一個服務掛了，可以切到另一個；一個模型貴，可以換成更便宜的；某個請求格式不相容，也可以透過代理層做適配。

MCP、Prompts 和 Skills

CC Switch 比較重要的第二層能力，是統一管理 MCP、Prompts 和 Skills。

MCP

它提供統一 MCP 面板，可以在多個應用之間管理 MCP server，並支援雙向同步和 Deep Link 匯入。

這對正在用 MCP 的使用者很實用。因為 MCP server 一多，設定很容易分散在不同客戶端裡。統一面板可以減少重複設定，也方便遷移。

Prompts

Prompts 部分支援 Markdown 編輯，並且可以在不同工具之間同步對應檔案，例如：

CLAUDE.md
AGENTS.md
GEMINI.md

這些檔案本質上都是給 Agent 的專案說明書。統一管理後，可以更容易維護團隊規則、專案約定和全域提示。

Skills

Skills 支援從 GitHub 倉庫或 ZIP 檔案一鍵安裝，也支援自訂倉庫管理、符號連結和檔案複製。

如果你同時使用 Claude Code、Codex、OpenClaw 這類工具，Skills 很容易變成一堆散落在不同目錄的檔案。CC Switch 把它們集中起來，能降低維護成本。

會話與工作區

README 還提到 Session Manager 和 Workspace 相關能力。

它可以瀏覽、搜尋和恢復多個應用裡的會話歷史。對長期使用 AI 程式設計工具的人來說，會話管理其實很重要：很多有價值的上下文、除錯過程、方案比較，都埋在舊對話裡。

此外，它還為 OpenClaw 提供 Workspace editor，可以編輯 AGENTS.md、SOUL.md 等 agent 檔案，並帶 Markdown 預覽。

這說明 CC Switch 不只是一個「切換 key 的小工具」，而是在往 AI Agent 工作台方向擴展。

雲同步與資料儲存

CC Switch 支援透過 Dropbox、OneDrive、iCloud、NAS 或 WebDAV 同步 Provider 資料。

本地資料儲存方式也比較清楚：

資料庫：~/.cc-switch/cc-switch.db
本地設定：~/.cc-switch/settings.json
自動備份：~/.cc-switch/backups/
Skills：~/.cc-switch/skills/
Skill 備份：~/.cc-switch/skill-backups/

它使用 SQLite 作為主要資料源，並強調原子寫入和自動備份，目標是避免設定檔在切換或寫入時損壞。

這個設計對重度使用者很關鍵。因為一旦設定管理工具本身把設定寫壞，影響的是所有 AI 程式設計工具。

安裝方式

CC Switch 是跨平台桌面應用，基於 Tauri 2 建構。

系統要求大致如下：

Windows：Windows 10 及以上
macOS：macOS 12 Monterey 及以上
Linux：Ubuntu 22.04+、Debian 11+、Fedora 34+ 等主流發行版

Windows 使用者可以下載 .msi 安裝包或可攜版壓縮包。

macOS 使用者可以用 Homebrew：

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

更新：

`1`	`brew upgrade --cask cc-switch`

Linux 使用者可以選擇 .deb、.rpm 或 AppImage。Arch Linux 使用者也可以透過 paru -S cc-switch-bin 安裝。

截至 2026 年 5 月 6 日，倉庫頁面顯示最新 release 為 CC Switch v3.14.1，發布時間是 2026 年 4 月 23 日。

技術棧

從倉庫結構看，CC Switch 是典型的 Tauri 桌面應用：

前端：React 18、TypeScript、Vite、TailwindCSS、TanStack Query、shadcn/ui
後端：Tauri 2、Rust、SQLite、Tokio
測試：Vitest、MSW、Testing Library

核心設計模式包括：

SQLite 作為 Single Source of Truth。
JSON 保存裝置級本地設定。
切換時寫入目標工具的 live config。
編輯當前 Provider 時從 live config 回填。
使用臨時檔案加 rename 的方式做原子寫入。
資料庫連線加鎖，避免並發寫入問題。

這類架構說明專案並不是簡單腳本，而是按長期桌面工具來設計的。

適合誰用

CC Switch 適合下面幾類使用者：

同時使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw。
經常切換官方帳號、第三方 relay、本地模型或團隊 Provider。
已經開始大量使用 MCP。
想統一維護 CLAUDE.md、AGENTS.md、GEMINI.md。
經常安裝、測試和遷移 Skills。
想看不同工具的會話歷史和使用情況。

如果你只用一個 AI 程式設計工具，而且一直走官方登入，不怎麼折騰 Provider、MCP 和 Skills，那它的價值可能沒那麼明顯。

但如果你已經進入「多工具、多帳號、多 Provider、多專案」的狀態，它能省掉很多瑣碎設定工作。

需要注意什麼

這類工具很方便，但也要注意邊界。

第一，它會管理多個 AI CLI 的設定，因此要確認自己信任這個工具和它的寫入邏輯。

第二，API key、relay endpoint、MCP server 都屬於敏感設定。開啟雲同步前，要確認同步目錄和 WebDAV 服務本身安全可靠。

第三，切換 Provider 後，多數工具仍然需要重啟終端或 CLI 才能生效。README 中提到，Claude Code 對 Provider 資料支援熱切換，但其他工具通常仍需要重啟。

第四，切回官方登入時，最好按專案說明新增 official provider，再重新走對應工具的登入流程。

小結

CC Switch 的價值不在於又做了一個 AI 程式設計工具，而在於它承認了一個現實：AI 程式設計生態已經進入多工具並存階段。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 各有自己的設定系統，MCP、Skills、Prompts、Provider 又在快速擴展。繼續靠手動改設定，遲早會變成負擔。

CC Switch 把這些東西收進一個桌面應用裡，讓使用者可以更輕鬆地切換 Provider、同步 MCP、管理 Skills、維護提示檔案和查看會話。對重度 AI 程式設計使用者來說，這類工具很可能會從「可選小工具」變成「日常基礎設施」。

參考資料

farion1231/cc-switch

Codex App 保姆級上手：安裝、沙箱、並行任務、Skills 與 MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App 可以理解成一個面向 AI 編程的任務工作台。它不是傳統 IDE，也不是單純聊天視窗，而是把多任務、專案管理、沙箱權限、Git、雲端執行、外掛、Skills、MCP 和自動化集中到一個介面裡。

如果你已經在用 Codex CLI、Claude Code、Cursor 或其他 coding agent，Codex App 最值得關注的地方，是它把「多個 agent 並行幹活」做成了更清楚的桌面工作流。

Codex App 適合做什麼

Codex App 的核心價值不是讓 AI 回答問題，而是讓 AI 在專案目錄裡持續執行任務：

修改程式碼、執行命令、啟動開發服務。
管理多個專案和多個任務。
在本地或雲端執行長任務。
呼叫外掛、Skills 和 MCP 擴展能力。
透過 Git、worktree 和 PR 管理改動。

OpenAI 官方也把 Codex App 定位成一個用於管理多個 coding agent 的介面。它適合需要同時推進多個程式碼任務的人，尤其適合前端頁面、腳本工具、小型應用、文件整理和自動化工作流。

安裝前準備

使用 Codex App 前，建議先準備好三個基礎工具：

Git
Node.js
VS Code 或你常用的 IDE

Codex App 支援 macOS 和 Windows。安裝後使用 ChatGPT 帳號登入，首次進入時可以選擇主要使用場景，例如編程或日常工作。Codex 會根據選擇預裝一部分外掛和 Skills，後續也可以在設定和外掛市場裡調整。

Windows 和 macOS 的主要功能大體一致，但部分電腦自動化能力可能依賴具體平台和外掛支援，實際以你目前版本顯示為準。

介面結構：專案、任務和對話

Codex App 是典型的三欄布局：

左側：專案、任務、歷史對話、外掛和自動化入口。
中間：目前對話視窗。
右側：檔案、瀏覽器、終端機、執行結果等多功能區域。

一個專案通常對應一個本地資料夾。你可以在同一個專案裡開多個對話，也可以同時打開多個專案，讓不同 agent 並行執行任務。

任務列表會顯示不同狀態：

正在執行：agent 仍在執行。
等待批准：需要你確認權限、連網、安裝依賴或執行高風險操作。
已完成：任務已經結束，可以查看結果或繼續追問。

這比在多個終端視窗裡來回切換更直觀，也更適合同時管理多個 AI 任務。

沙箱與權限控制

Codex App 的權限體系圍繞沙箱展開。預設情況下，目前專案資料夾會成為 agent 的主要工作範圍。

常見權限邊界包括：

可以讀取和修改專案目錄內的檔案。
預設不能隨意修改專案外檔案。
預設會限制連網或高風險命令。
需要越權時，會向使用者申請批准。

比較實用的模式是「自動審查」：低風險操作由系統自動放行，高風險操作再交給使用者確認。這樣既能減少頻繁彈窗，又能避免 agent 在不知情的情況下執行危險操作。

「完全存取」要謹慎開啟。它適合你明確知道 agent 要做什麼，並且專案已經有 Git 備份、重要檔案也有額外備份的場景。日常使用不建議長期保持完全存取。

上下文、模型和額度

Codex App 會顯示目前對話的上下文使用情況。對話越長，歷史內容越多，模型需要處理的上下文也越大。

實用建議是：

一個任務完成後，優先開新對話。
長對話可以手動壓縮，但不要把壓縮當成萬能記憶。
複雜任務先寫清楚目標、邊界和驗收標準。
不要把大量無關日誌、報錯和檔案一次性塞進對話。

模型選擇上，可以根據任務複雜度調整思考強度。簡單修改、文案整理、重複任務不一定需要最高規格模型；架構遷移、疑難 bug、跨檔案重構則更適合使用更強模型。

如果介面裡有快速模式，也要注意它通常會帶來更高的額度消耗。趕時間時可以開，日常不必預設開啟。

圖片生成與多模態輸入

Codex App 可以接收圖片和檔案作為上下文，也可以在合適場景中呼叫圖像生成能力。

這對前端和內容類專案很有用。例如你可以讓 Codex：

根據截圖修正頁面樣式。
替換網頁中的不合適配圖。
生成產品圖、輪播圖或頁面素材。
根據 UI 截圖指出需要修改的位置。

更高效的用法是：不要只說「改好看一點」，而是結合截圖指出具體問題，例如「這個卡片間距太大」「這裡的圖和服務場景不匹配」「把地圖區域做得更清楚」。

Steer：任務執行中及時糾偏

Steer 可以理解成「執行中接管方向」。當 agent 已經開始執行，但你發現它理解錯了方向，不應該等它全部跑完再改。

這時可以使用引導功能，把新的指令插入目前執行流程，讓 Codex 及時修正路線。

適合使用 Steer 的場景包括：

agent 誤解了需求。
生成的頁面風格明顯不對。
正在執行的方案成本太高。
你臨時補充了關鍵約束。

一般建議保留預設排隊行為，只在確實需要干預時手動使用 Steer。這樣既不會打亂正常任務，也能在關鍵時刻把方向拉回來。

計劃模式和內建瀏覽器

複雜任務建議先開計劃模式。計劃模式下，Codex 不會馬上改程式碼，而是先輸出方案，必要時還會用卡片形式追問關鍵選擇。

適合開計劃模式的任務：

框架遷移，例如從普通 React 專案遷到 Next.js。
大範圍重構。
涉及資料庫、認證、部署的功能。
你還沒想清楚技術路線的需求。

Codex App 的右側區域可以打開內建瀏覽器，用來預覽本地開發服務。你可以在頁面上做批註，讓 Codex 按具體 UI 位置修改問題。這種「看頁面、點位置、讓 AI 改」的流程，比純文字描述更適合前端除錯。

Git、IDE 和程式碼回滾

Codex App 不是完整 IDE。它可以查看程式碼、批註程式碼，但真正的手寫編輯仍然更適合交給 VS Code、Cursor、Windsurf 等 IDE。

建議每個 Codex 專案都盡早初始化 Git：

讓 Codex 建立或檢查 .gitignore。
在完成一個可用狀態後提交一次。
每次大改前確保有乾淨提交點。
不滿意時用 Git 回滾程式碼。

如果只回滾對話歷史，程式碼不會自動跟著回滾。比較穩的做法是：對話層面回到合適節點，程式碼層面用 Git commit hash 回到對應狀態。

Worktree：並行開發多個方向

git worktree 是 Codex App 裡非常適合並行 agent 的能力。

它的本質是：基於同一個倉庫建立多個獨立工作目錄，每個目錄對應不同分支。這樣你可以讓不同 agent 在不同資料夾裡同時開發，不互相覆蓋。

典型用法：

一個 worktree 優化客戶評價元件。
一個 worktree 調整門店資訊和地圖布局。
兩個任務完成後分別合併回主幹。
合併完成後刪除臨時 worktree。

這比在同一個目錄裡讓多個 agent 同時改程式碼穩得多。遇到衝突時，也可以按正常 Git 流程 review 和合併。

雲端執行環境

Codex 不只能在本機工作，也可以把任務委託到雲端環境執行。

雲端執行適合這些場景：

出門在外，手邊只有手機。
希望 agent 在背景跑長任務。
程式碼已經同步到 GitHub，需要讓 Codex 基於遠端倉庫修改。
希望透過 PR 形式審查和合併改動。

典型流程是：先把本地程式碼推到 GitHub，再讓 Codex 在雲端環境中拉取倉庫、執行任務、生成改動，最後以 PR 或 diff 的方式交給你審核。

本地繼續開發時，要記得把遠端最新改動同步回來。

記憶系統：寫好 AGENTS.md

新對話預設沒有完整歷史記憶。專案一複雜，如果每次都重新解釋背景，會很浪費。

最通用的做法，是在專案根目錄維護 AGENTS.md。這個檔案可以記錄：

專案目標和主要技術棧。
常用命令。
目錄結構說明。
程式碼風格和命名約定。
禁止事項，例如不要批量刪除檔案。
測試、建置和部署規則。

你也可以讓 Codex 先通讀專案，再生成一版 AGENTS.md，然後人工審一遍。複雜專案裡，這個檔案非常值得維護。

全域規則也要謹慎。適合寫入所有專案都通用的安全約束，例如「不要遞迴刪除目錄」「執行破壞性操作前必須確認」。不要把某個專案的細節寫進全域規則，否則會污染其他專案。

外掛和自動化

外掛用於把外部服務接入 Codex，例如 GitHub、Gmail、Google Drive、資料庫、部署平台等。

外掛的價值在於減少複製貼上。比如你可以讓 Codex：

查看某個 GitHub 倉庫的 star 趨勢。
整理郵件內容並發給自己。
定期執行某個檢查任務。
把結果寫成摘要。

自動化則適合重複任務。例如每週五下午檢查一次倉庫資料，並發送郵件報告。簡單自動化任務通常不需要最高規格模型，選擇較輕量的模型即可。

Skills：把工作流變成可複用能力

Skills 是 Codex 的「專業說明書」。它不是單次提示詞，而是把某類任務的流程、規範、腳本和注意事項沉澱下來，讓 Codex 後續穩定複用。

常見來源有三類：

官方 Skills。
第三方 Skills。
自己編寫的 Skills。

適合做成 Skill 的工作：

把字幕整理成圖文筆記。
按公司規範寫週報。
批量處理圖片或文件。
固定格式的程式碼審查。
特定框架的專案初始化。

如果某個提示詞你已經複製貼上了很多次，就值得考慮把它做成 Skill。

MCP：接入外部工具和資料庫

MCP 可以理解成給大模型使用的標準化工具協議。透過 MCP，Codex 可以呼叫外部服務完成更具體的任務。

例如接入 Supabase 後，可以讓 Codex：

建立資料表。
讀取資料庫結構。
修改後端接口。
把前端表單提交到資料庫。
根據資料庫狀態除錯問題。

這類能力很強，但也要注意權限邊界。資料庫、生產環境、部署平台、郵件帳號都屬於高風險資源。第一次接入時，最好使用測試專案和低權限帳號。

部署外掛

部署平台外掛可以讓 Codex 直接完成建置和發布，例如把前端專案部署到 Netlify 一類平台。

這類外掛適合小型網站、原型頁面、內部工具和展示專案。實際使用時建議注意：

部署前先跑本地建置。
環境變數不要直接寫進程式碼。
發布後檢查頁面是否能正常訪問。
生產專案要保留人工 review。

AI 可以幫你打通發布流程，但發布權限仍然要謹慎管理。

電腦自動化

在支援的平台和外掛環境裡，Codex 還可以操作瀏覽器或桌面應用，完成更接近 RPA 的任務。

例如：

打開聊天軟體並準備一條訊息。
瀏覽專案看板，彙總任務狀態。
生成英文簡報。
在你確認後發送給指定對象。
把這套流程做成定時自動化。

這類功能很有想像力，但也最需要安全邊界。凡是涉及發訊息、發郵件、提交表單、付款、刪除資料的操作，都應該保留人工確認。

使用建議

Codex App 的正確打開方式，不是讓它一次性全自動接管一切，而是把任務拆清楚，讓它在受控環境裡高效執行。

推薦習慣：

每個專案先初始化 Git。
複雜任務先開計劃模式。
並行任務優先用 worktree。
專案規則寫進 AGENTS.md。
高風險操作保留人工確認。
重複流程沉澱成 Skill 或自動化。
外掛和 MCP 先在測試環境驗證。

參考資料

小結

Codex App 的重點不是「多一個 AI 聊天視窗」，而是把 AI 編程變成一個可管理的工作台：本地專案、雲端任務、Git、worktree、外掛、Skills、MCP 和自動化都能串起來。

真正用好它的關鍵，是在「放權」和「控制」之間找到平衡。小任務可以大膽交給 Codex，複雜任務先讓它計劃，高風險動作必須確認。這樣它才會從一個會寫程式碼的助手，變成可以長期協作的工程工具。

Claude for Creative Work：Anthropic 把 Claude 接進 Adobe、Blender、Ableton 和 SketchUp

Fri, 01 May 2026 05:52:14 +0800

Anthropic 在 2026 年 4 月 28 日發布了 Claude for Creative Work，重點不是再談一個新的聊天機器人，而是把 Claude 接進創意產業已經在使用的軟體裡。

這次合作名單很有代表性：Blender、Autodesk、Adobe、Ableton、Splice，還包括 Affinity by Canva、Resolume、SketchUp 等工具生態。

簡單說，Anthropic 想做的是：讓 Claude 不只在聊天框裡給建議，而是進入設計、3D、音樂、影片和現場視覺這些具體工作流程。

Claude 不能取代審美，但可以取代很多苦工

Anthropic 在公告裡的態度比較克制：Claude 不能取代創作者的品味和想像力。

這個判斷是對的。創意工作的關鍵往往不是「生成一個東西」，而是判斷哪個方向值得繼續、哪個細節需要保留、哪個方案符合專案氣質。

但創意流程裡也有大量重複勞動：

批次調整圖片
替圖層改名
匯出不同格式檔案
整理素材
查軟體文件
寫腳本修改場景
在多個工具之間轉換格式
把一個想法快速做成可看的草稿

這些環節不一定需要「靈感」，但很消耗時間。Claude 的作用更像是把創作者從這些機械步驟裡釋放出來。

Connectors 是這次的核心

這次發布的關鍵是 connectors。

connectors 可以理解為 Claude 連接外部平台和軟體的橋。使用者不是把需求複製到 Claude，再手動回到軟體裡操作，而是讓 Claude 直接理解工具、呼叫能力或讀取相關文件。

Anthropic 公告裡提到的連接方向包括：

Ableton：讓 Claude 基於 Live 和 Push 的官方文件回答問題。
Adobe for creativity：連接 Creative Cloud 中的 50 多個工具，涵蓋 Photoshop、Premiere、Express 等。
Affinity by Canva：自動化專業創意工作流裡的重複生產任務，例如批次圖片調整、圖層重新命名和檔案匯出。
Autodesk Fusion：讓有 Fusion 訂閱的設計師和工程師透過對話建立和修改 3D 模型。
Blender：透過自然語言使用 Blender 的 Python API，協助理解複雜場景、存取文件和擴充功能。
Resolume Arena 和 Resolume Wire：讓 VJ 和現場視覺藝術家用自然語言即時控制 Arena、Avenue 和 Wire。
SketchUp：把與 Claude 的對話變成 3D 建模起點，例如描述房間、家具或場地概念，再到 SketchUp 裡繼續細化。
Splice：讓音樂製作人直接從 Claude 裡搜尋免版稅採樣庫。

這些整合涵蓋了設計、音訊、3D、影片、現場演出和工程建模。它們不是單一方向的小實驗，而是 Anthropic 明確在往「創意軟體工作台」前進。

對創意工作有什麼用

從公告來看，Claude 在創意工作裡的用途可以分成幾類。

第一類是學習複雜工具。

很多創意軟體很強，但學習曲線也很陡。Blender、Ableton、Fusion、Premiere 都是典型例子。使用者可以讓 Claude 解釋某個 modifier stack、講一個合成技巧、示範某個陌生功能，而不是在搜尋結果、論壇和官方文件之間來回跳。

第二類是寫腳本和外掛。

創意軟體都有大量可自動化空間。Claude Code 可以幫使用者寫腳本、外掛、shader、程序化動畫或參數化模型。對會一點技術但不想一直查 API 的創作者來說，這個價值很實際。

第三類是打通工具鏈。

真實專案通常不是一個軟體完成的。設計可能在 Adobe，3D 在 Blender 或 SketchUp，音訊在 Ableton，素材來自 Splice，最後還要進入影片或演出系統。Claude 可以協助轉換格式、重組資料、同步素材，減少手工交接。

第四類是快速探索和交付。

Anthropic 還提到 Claude Design，這是 Anthropic Labs 的一個新產品，用於探索軟體體驗想法。它可以根據回饋迭代視覺方案，並且設計結果可以匯出到其他工具，起點是 Canva。

第五類是減少重複生產工作。

例如批次處理素材、搭建專案結構、批次調整場景物件、自動化匯出。很多創作者並不是不會做，而是不想把一個下午浪費在重複點擊上。

Blender 是最值得注意的一環

這次公告裡，Blender 的位置很特別。

Blender 是免費開源的 3D 創作套件，涵蓋獨立遊戲、動態影像、建築視覺化、影視製作等場景。它本身就有強大的 Python API，也有大量複雜工作流。

Blender 開發者已經建立了一個 MCP connector，現在可以在 Claude 中正式使用。

這個連接器能做的事情包括：

分析和除錯整個 Blender 場景
批次修改場景裡的物件
使用 Blender Python API 寫自訂腳本
把新工具直接加到 Blender 介面裡
幫使用者理解複雜設定和文件

更重要的是，Anthropic 加入了 Blender Development Fund，成為 Blender 專案的 patron，用來支持 Blender 繼續發展 Python API。

這件事有兩個信號。

第一，Anthropic 不只是想接入商業軟體，也在押注開源創作工具。

第二，這個 connector 基於 MCP，理論上不只 Claude 能用，其他大型模型也可以接入。這和 Blender 的開源與互操作方向比較一致。

這不是「AI 取代設計師」，而是「AI 進入工具層」

這次發布最值得關注的地方，不是 Claude 能不能生成一張圖、一段音樂或一個 3D 模型。

更關鍵的是：AI 正在從聊天框進入工具層。

過去很多 AI 創作工具的體驗是：

在 AI 工具裡描述需求。
得到一個結果。
下載或複製出來。
回到專業軟體裡手動修改。

現在的方向更像是：

Claude 理解你的創意軟體。
Claude 讀取相關文件或專案上下文。
Claude 生成腳本、操作工具、整理素材或建立草稿。
創作者在熟悉的軟體裡繼續判斷和精修。

這對專業使用者更有吸引力，因為他們不想離開原本的工具鏈，也不想把所有工作遷移到一個全新的 AI 平台。

對學生和創意教育的影響

Anthropic 也提到正在和藝術與設計專案合作，支持包含 creative computation 的課程。

首批專案包括：

Rhode Island School of Design 的 Art and Computation
Ringling College of Art and Design 的 Fundamentals of AI for Creatives
Goldsmiths, University of London 的 MA/MFA Computational Arts

學生和教師會獲得 Claude 以及新 connectors 的存取權限，他們的回饋會幫助 Anthropic 理解創意實踐者真正需要什麼。

這點也很有意思。AI 創作能力如果只停留在「生成素材」，很容易變成炫技。但進入課程後，更重要的問題會變成：

學生如何理解工具背後的過程
如何把 AI 作為探索和原型工具
如何保留自己的判斷力
如何用程式碼和自動化擴展創作邊界
如何避免所有作品都變成同一種 AI 味道

這些問題比單純討論「AI 會不會取代創作者」更實際。

誰最適合關注這次發布

這次 Claude for Creative Work 對幾類人尤其值得關注：

使用 Blender、SketchUp、Fusion 做 3D 建模的人
使用 Adobe、Affinity 做設計和影片生產的人
使用 Ableton、Splice 做音樂製作的人
需要把多個創意工具串成工作流的人
會一點腳本，希望自動化創意軟體的人
正在做創意教育、互動設計、計算藝術課程的人

如果只是偶爾讓 AI 生成圖片，這次發布未必馬上改變體驗。

但如果你已經在專業軟體裡工作，並且經常遇到「我知道要做什麼，但這些步驟太繁瑣」的情況，connectors 會很有價值。

需要注意的邊界

這類工具也不是萬能的。

第一，Claude 仍然需要使用者判斷結果是否符合審美、品牌和專案目標。

第二，自動化操作專業軟體時，最好從小範圍任務開始，不要一上來就讓它批次修改不可恢復的專案檔案。

第三，連接器品質很關鍵。如果 connector 只能查文件，和能真實操作軟體，是兩種完全不同的體驗。

第四，創意軟體專案往往有複雜檔案、素材依賴和版本管理。AI 參與之後，更需要備份和可回滾流程。

第五，版權、授權和素材來源仍然要自己把關。比如 Splice 強調的是 royalty-free samples，但實際專案使用時仍要確認具體授權條件。

小結

Claude for Creative Work 不是一次單點功能更新，而是 Anthropic 把 Claude 推進創意軟體生態的一步。

它的重點不是讓 Claude 變成創作者，而是讓 Claude 成為創作者身邊的工具助手：查文件、寫腳本、批次處理、連通軟體、生成草稿、減少重複勞動。

真正有長期價值的地方，是 Claude 開始進入 Blender、Adobe、Ableton、SketchUp 這些創作者每天使用的環境裡。

當 AI 不再只是一個單獨網頁，而是能理解和呼叫專業工具時，創意工作流會發生更實際的變化。

參考連結：

Claude for Creative Work - Anthropic

qmd：給 AI Agent 使用的本地 Markdown 文件搜尋工具

Fri, 01 May 2026 03:12:57 +0800

qmd 是一個面向本地 Markdown 文件的搜尋工具，重點服務對象是 AI Agent。

它解決的問題很具體：當你的專案裡有大量 .md 文件時，AI 編程助手經常不知道該讀哪一份、該引用哪一段、哪些說明才是最新的。靠全文 grep 可以找到關鍵詞，但很難理解語義；直接把整套文件塞進上下文，又浪費視窗，還容易混入無關內容。

qmd 的思路是先為 Markdown 文件建立索引，再透過搜尋介面把最相關的片段交給 AI 使用。它既可以作為命令列工具使用，也可以透過 SDK 整合，還可以作為 MCP Server 接入支援 MCP 的客戶端。

它解決什麼問題

真實專案裡的文件通常不是一兩篇 README。

你可能會有：

架構說明
API 文件
開發規範
部署流程
設計決策記錄
故障排查筆記
需求文件
AI 使用說明
各種工具鏈備忘錄

人類查文件時可以順著目錄慢慢看，但 AI Agent 更需要一個明確的檢索入口。否則它可能會：

讀錯文件
漏掉關鍵約束
使用過時說明
把不相關內容塞進上下文
在回答裡憑經驗補全不存在的規則

qmd 的價值就在這裡：它把本地 Markdown 文件變成可檢索的知識源，讓 AI 在需要上下文時先搜尋，再基於匹配片段回答或執行任務。

搜尋方式有什麼特點

README 中提到，qmd 使用了多種檢索方式組合：

BM25 關鍵詞搜尋
向量搜尋
LLM reranking

BM25 適合處理明確關鍵詞。比如你搜尋某個函式名稱、配置項、錯誤碼、檔案名稱，它通常很直接。

向量搜尋更適合語義問題。比如你問「這個專案怎麼處理權限校驗」，文件裡未必正好寫了「權限校驗」四個字，但可能有相關的認證、存取控制、角色判斷說明。

LLM reranking 則用於重新排序候選結果。前兩步先把可能相關的內容找出來，再讓模型判斷哪些片段更符合當前問題。

這種組合比單純關鍵詞搜尋更適合 AI Agent。因為 Agent 的問題往往不是固定關鍵詞，而是任務意圖。

為什麼是 Markdown

Markdown 是開發專案裡最常見的文件格式。

它足夠簡單，可以放進 Git；也足夠結構化，有標題、列表、程式碼區塊、連結和表格。對 AI 來說，Markdown 也比 PDF、網頁快照或截圖更容易解析。

qmd 專注 Markdown，意味著它可以圍繞開發文件做更直接的處理：

按標題和段落切分內容
保留程式碼區塊
保留文件路徑
返回適合引用的片段
讓 Agent 知道答案來自哪份文件

這比讓 AI 隨機掃描倉庫更穩，也比把所有文件一次性塞進 prompt 更省上下文。

三種使用入口

qmd 提供 CLI、SDK 和 MCP Server 三種入口。

1. CLI

CLI 適合直接在終端裡使用，也適合放進腳本。

你可以把文件目錄索引起來，然後用命令搜尋相關內容。對開發者來說，CLI 是最容易驗證效果的入口：先看它能不能搜到正確文件，再考慮接入更複雜的工作流。

這類工具放在本地專案裡很有用。比如你可以在改程式碼前先搜尋設計文件，在排錯前先查故障筆記，在寫介面時先查 API 約定。

2. SDK

SDK 適合把 qmd 接入自己的工具。

如果你正在做內部開發助手、文件問答系統、程式碼審查機器人或專案知識庫，可以透過 SDK 呼叫搜尋能力，而不是讓使用者直接敲命令。

SDK 的好處是可以更自由地控制：

搜尋目錄
查詢內容
返回數量
結果格式
後續是否交給模型總結

這適合需要深度整合的場景。

3. MCP Server

MCP 是 qmd 對 AI Agent 最有價值的入口。

透過 MCP Server，支援 MCP 的客戶端可以把 qmd 當作一個文件搜尋工具來呼叫。這樣 Agent 在執行任務時，不必猜專案規則，而是可以先檢索本地 Markdown 文件。

典型流程可以是：

使用者要求 AI 修改某個功能
AI 先呼叫 qmd 搜尋相關設計文件
qmd 返回最相關的 Markdown 片段
AI 基於文件約束再修改程式碼

這比「開新會話時手動把所有規則貼進去」更自然，也更適合長期專案。

適合什麼場景

qmd 適合這些場景：

專案裡有大量 Markdown 文件
AI Agent 經常需要查專案規則
團隊希望 AI 回答時引用本地文件
文件分散在多個目錄裡
需要在 CLI、SDK、MCP 之間複用同一套檢索能力
想減少 AI 編程助手憑空猜測專案約定
想把本地知識庫接入 Claude Desktop、Claude Code 或其他 MCP 客戶端

如果你的專案只有一份很短的 README，直接讓 AI 讀取檔案就夠了。

但如果文件已經增長到幾十篇、幾百篇，或者你希望 Agent 每次先查文件再行動，這類索引工具就有意義。

和 grep 有什麼區別

grep、rg 這類工具非常適合精確搜尋。

比如你知道要找 DATABASE_URL、authMiddleware、404、docker compose，直接搜關鍵詞通常最快。

qmd 更適合你不知道精確詞的情況。

例如你想問：

這個專案的發布流程是什麼
新增 API 時要遵守哪些規範
之前有沒有記錄過快取策略
AI 修改程式碼前應該讀哪些文件
某個模組的設計背景在哪裡

這些問題往往需要語義檢索，而不是只匹配一個詞。qmd 的 BM25 + 向量 + reranking 組合，就是為了讓這類問題更容易找到正確上下文。

和 RAG 有什麼關係

qmd 可以看作一個面向 Markdown 文件的輕量 RAG 元件。

它不試圖替你完成整套問答系統，而是專注在「把相關文件片段找出來」這一步。至於後續怎麼使用這些片段，可以交給 CLI、SDK、MCP 客戶端或你自己的 Agent 流程。

這種定位比較實用。很多專案並不需要一個龐大的知識庫系統，只需要讓 AI 在本地文件裡查得準一點、快一點，並且能把結果帶回當前任務。

使用時要注意

第一，文件品質仍然重要。

檢索工具只能幫你找到已有內容。如果文件本身過時、重複、互相矛盾，AI 仍然可能拿到錯誤上下文。把 qmd 接入 Agent 之前，最好先清理關鍵文件。

第二，索引範圍不要過寬。

把整個倉庫所有 Markdown 都塞進去不一定更好。比如依賴包文件、臨時記錄、舊方案草稿可能會污染結果。更好的做法是明確哪些目錄是可信文件源。

第三，搜尋結果需要保留來源。

AI 使用文件片段時，最好知道它來自哪份檔案、哪個章節。這樣人類複核時才能追溯，也能減少「看起來像文件結論，其實只是模型總結」的問題。

第四，不要完全替代人工判斷。

qmd 能提高上下文召回品質，但它不是專案真理源的替代品。重要變更仍然要看當前程式碼、測試結果和最新需求。

適合怎樣的團隊

如果你的團隊已經開始把 AI Agent 放進日常開發流程，qmd 這類工具會很有價值。

尤其是下面幾種團隊：

文件寫得比較多
專案歷史比較長
新人和 AI 都需要快速理解背景
經常維護架構決策記錄
有大量 Markdown 規範文件
希望 AI 修改程式碼前先查規則

它的目標不是讓 AI「全知全能」，而是讓 AI 少猜一點，多查一點。

參考

tobi/qmd

最後一句

qmd 的價值，是把本地 Markdown 文件變成 AI Agent 能穩定呼叫的搜尋入口。

當專案文件從「給人看的說明」變成「給人和 AI 都能檢索的上下文源」，AI 編程助手才更容易按專案規則做事。

Prompt Optimizer：開源提示詞優化、測試與 MCP 工具

Fri, 01 May 2026 03:09:07 +0800

Prompt Optimizer 是一個開源的提示詞優化工具，目標很直接：幫助你把一段粗糙的提示詞改得更清楚、更穩定，也更容易被大型語言模型執行。

它不只是一個「幫我潤飾 prompt」的頁面。專案同時提供提示詞優化、結果測試、對比評估、多模型接入、圖像生成提示詞處理，以及 MCP 整合。對經常寫系統提示詞、使用者提示詞、AI 工作流模板的人來說，它更像一個專門用來打磨提示詞的工作台。

它解決什麼問題

很多人使用 AI 時都會遇到類似問題：

提示詞越寫越長，但模型輸出沒有明顯變好
同一個需求換個模型就表現不穩定
系統提示詞和使用者提示詞混在一起，很難拆開除錯
改了一版 prompt，不知道是不是真的比上一版更好
想複用變數模板，但每次都要手動替換和測試
想把提示詞優化能力接入其他 AI 工具，卻缺少標準介面

Prompt Optimizer 主要圍繞這些問題設計。它把「寫 prompt」拆成優化、測試、評估、對比、迭代幾個環節，讓提示詞不再只靠感覺調整。

主要功能

1. 優化系統提示詞和使用者提示詞

提示詞並不只有一種。

系統提示詞通常負責定義角色、目標、邊界、輸出規範和工作方法；使用者提示詞則更接近一次具體任務的輸入。兩者混在一起時，模型容易抓不住重點，後續複用也困難。

Prompt Optimizer 支援系統提示詞優化和使用者提示詞優化。你可以分別處理長期複用的角色設定，也可以處理某次具體任務的輸入表達。

這對下面幾類場景比較有用：

寫 AI 編程助手的工作規則
寫客服、審稿、翻譯、分析類角色提示詞
優化文生圖提示詞
把臨時需求整理成可複用模板
為不同模型準備不同風格的 prompt

2. 測試和對比輸出

只優化提示詞還不夠，關鍵是要知道優化後有沒有變好。

專案支援分析、單結果評估、多結果對比評估。也就是說，你可以把原始提示詞和優化後的提示詞放到同一個任務裡跑，看模型輸出是否更準確、更穩定、更符合目標。

這比單純「看起來更專業」的 prompt 更實用。因為很多提示詞表面上寫得完整，實際輸出卻可能更囉嗦、更僵硬，甚至把模型引向錯誤方向。對比測試能幫助你盡早發現這種問題。

3. 支援多模型

README 中提到專案支援 OpenAI、Gemini、DeepSeek、智譜 AI、SiliconFlow 等模型服務，也支援自訂 OpenAI 相容介面。

這點很重要。提示詞效果和模型強相關，同一段 prompt 在不同模型上的表現可能差別很大。多模型測試可以幫助你判斷：

是提示詞本身寫得不好
還是某個模型不適合這個任務
是否需要為不同模型準備不同版本
小模型能否透過更清楚的提示詞接近可用效果

如果你在本地使用 Ollama，或者公司內部有相容 OpenAI 介面的模型服務，也可以透過自訂介面接入。

4. 高級測試模式

專案提供上下文變數管理、多輪會話測試和 Function Calling 支援。

變數管理適合模板化任務。比如你有一套二手交易回覆、商品描述、郵件回覆、程式碼審查或文件生成提示詞，只需要替換商品、價格、語氣、目標使用者等變數，就能快速測試不同輸入下的表現。

多輪會話測試適合驗證長期對話能力。很多 prompt 在單輪問答裡看起來不錯，一旦進入多輪追問，就會忘記約束、偏離角色或重複解釋。多輪測試可以更接近真實使用場景。

Function Calling 支援則適合更工程化的 AI 應用。它能幫助你驗證模型在工具呼叫、參數生成和結構化輸出上的表現。

5. 圖像生成提示詞

Prompt Optimizer 也支援文生圖和圖生圖相關能力，README 中提到整合 Gemini、Seedream 等圖像模型。

文生圖提示詞的優化重點和文字任務不同。它更關注主體、構圖、空間關係、風格、材質、光線、情緒和限制條件。把一句很模糊的想法拆成更可控的視覺描述，通常比單純加長提示詞更有價值。

如果你經常需要生成產品圖、封面、插畫、主視覺或風格參考圖，這類優化會比較實用。

使用方式

專案提供多種入口：

線上版本
Vercel 自部署
桌面應用
Chrome 擴充功能
Docker 部署
Docker Compose 部署
MCP Server

線上版本適合快速體驗。專案說明中提到它是純前端應用，資料儲存在瀏覽器本地，並直接與 AI 服務商互動。

桌面應用適合需要直接連接各種模型 API 的使用者。瀏覽器環境容易遇到跨域限制，桌面應用可以繞過這類問題，尤其適合連接本地 Ollama 或一些跨域策略嚴格的商業 API。

Docker 部署適合放在自己的伺服器或內網環境裡使用。README 給出的基礎命令如下：

`1`	`docker run -d -p 8081:80 --restart unless-stopped --name prompt-optimizer linshen/prompt-optimizer`

如果要配置 API 金鑰和存取密碼，可以透過環境變數傳入：

docker run -d -p 8081:80 \
  -e VITE_OPENAI_API_KEY=your_key \
  -e ACCESS_USERNAME=your_username \
  -e ACCESS_PASSWORD=your_password \
  --restart unless-stopped \
  --name prompt-optimizer \
  linshen/prompt-optimizer

國內存取 Docker Hub 較慢時，專案也提供了阿里雲映像地址，可按 README 中的說明替換映像名稱。

MCP 能做什麼

Prompt Optimizer 支援 Model Context Protocol，也就是 MCP。

透過 Docker 執行時，MCP 服務可以和 Web 應用一起啟動，並透過 /mcp 路徑存取。這樣它就不只是一個網頁工具，而是可以被 Claude Desktop 等支援 MCP 的應用呼叫。

README 中列出的 MCP 工具包括：

optimize-user-prompt：優化使用者提示詞
optimize-system-prompt：優化系統提示詞
iterate-prompt：對已有提示詞做定向迭代

這類介面很適合放進 AI 工作流裡。比如你在寫複雜任務提示詞時，可以讓支援 MCP 的客戶端直接呼叫提示詞優化能力，而不必每次打開網頁手動複製。

和普通聊天工具有什麼區別

普通聊天工具當然也能幫你改 prompt，但它通常缺少幾個環節：

不方便保存和對比多個版本
不方便同時測試多個模型
不方便把變數模板化
不方便做多輪會話驗證
不方便接入 MCP 或部署到自己的環境

Prompt Optimizer 的價值在於把提示詞優化做成一個可重複的流程。它不只是給你一版「看起來更完整」的文字，而是讓你圍繞實際輸出持續調整。

適合誰使用

如果你符合下面幾種情況，可以重點關注這個專案：

經常寫系統提示詞
經常為 AI 應用設計角色和輸出格式
需要比較不同模型的輸出效果
想把 prompt 做成可複用模板
需要測試多輪對話或工具呼叫
想把提示詞優化能力接入 MCP 工作流
希望在本地或內網部署提示詞工具

如果你只是偶爾問 AI 一個簡單問題，用普通聊天頁面就夠了。這個工具更適合那些把提示詞當成可維護資產的人。

使用時要注意什麼

第一，不要把優化結果當成絕對正確。

提示詞優化工具可以提高表達品質，但不能保證模型一定不會誤解。重要任務仍然需要測試樣例、人工檢查和版本對比。

第二，不要只追求更長。

好的 prompt 不一定更長。它應該更清楚地表達目標、邊界、輸入輸出格式和判斷標準。無意義的規則堆疊反而會讓模型抓不住重點。

第三，要按模型調 prompt。

不同模型對角色設定、格式約束、推理步驟和範例的敏感度不同。一個在大模型上表現很好的提示詞，不一定適合小模型。多模型測試正是這個工具值得使用的原因之一。

第四，部署時要考慮金鑰和存取控制。

如果你把它部署到公網，應該配置存取密碼，並謹慎處理 API key。專案支援透過環境變數配置存取控制，不要把敏感配置直接寫到公開倉庫裡。

參考

linshenkx/prompt-optimizer

最後一句

Prompt Optimizer 適合用來把提示詞從「臨時手寫的一段話」整理成「可以測試、可以比較、可以迭代的工作資產」。

當你開始在多個模型、多個場景、多個版本之間維護 prompt 時，這類工具會比普通聊天視窗更順手。

AI 名詞解釋：用白話講清楚 Agent、MCP、RAG 和 Token

Thu, 23 Apr 2026 13:13:40 +0800

剛開始接觸 AI，最容易讓人卻步的通常不是模型本身，而是討論裡那些一串一串的名詞。Agent、MCP、RAG、AIGC、Token 看起來都很常見，但如果沒有人先用白話講一遍，很多人其實只是「看過」，不是真的懂。

這篇就順著一組常見入門解釋的思路，把 10 個高頻 AI 名詞壓縮成一套更容易記住的意思。目標不是講得多學術，而是先幫你建立一個能跟上日常 AI 討論的基本框架。

10 個常見 AI 名詞，分別是什麼意思

1. Agent：不只會聊天的執行型 AI

Agent 可以先理解成「會做事的 AI 助手」。

一般聊天機器人比較像是你問一句、它答一句；Agent 則更進一步，它會把任務拆開、安排步驟、調用工具，最後把結果交回來。比如你叫它整理資料、查資訊、生成文件，它不只是給建議，而是可能直接把這些動作串起來完成。

所以 Agent 的重點，不在「會不會說」，而在「能不能做」。

2. OpenClaw：駐留在電腦裡的 AI 助手

這裡的 OpenClaw 被形容成一種住在你電腦裡的 AI 助手。

你可以把這類工具理解成更貼近桌面操作的 AI 幫手。它不只是接收文字，也可能直接觀察介面、調用本地工具、按流程執行任務。和一般網頁聊天相比，這類工具更強調實際操作能力。

如果說 Agent 是抽象層面的執行型 AI，那這種桌面型助手就是它在個人電腦上的一種具體落地形式。

3. Skills：替 Agent 裝上的能力包

Skills 可以理解成 Agent 的功能模組或操作說明。

同一個 Agent，裝上不同的 Skills，就會展現出不同的專長。有些偏文案，有些偏資料整理，有些偏程式處理。它們有點像手機裡的 App，也有點像一套套可重複利用的工作流程。

所以很多時候，不是模型突然變聰明了，而是它背後多了一組更明確的規則、工具和步驟。

4. MCP：AI 連接外部工具的統一方式

MCP 全稱是 Model Context Protocol。

如果用生活化的比喻，它有點像 AI 世界裡的 Type-C 介面。以前模型要接不同工具，往往得一套一套分開整合；有了統一協議之後，接入方式就會更標準，也更容易重複使用。

對大多數使用者來說，最值得記住的一點是：MCP 解決的不是模型會不會回答，而是模型怎麼安全、穩定地接上外部工具和資源。

5. 抽卡：AI 生成結果本來就有隨機性

「抽卡」這個說法常見於 AI 繪圖、影片生成和內容創作場景。

意思很簡單。就算是同樣的提示詞、同樣的大方向，每次生成出來的結果也可能不同。有時候效果很好，有時候明顯翻車，所以很多人會把反覆生成這件事形容成像遊戲裡抽卡。

它真正提醒我們的是：AI 生成不是固定公式，而是一個帶有機率波動的過程。

6. API：應用和模型之間的連接方式

API 全稱是 Application Programming Interface，也就是應用程式介面。

你可以把它理解成程式之間溝通的標準入口。當你在自己的應用、腳本或編輯器裡呼叫模型服務時，本質上就是透過 API 發送請求，再拿回結果。

如果把模型服務比作一家餐廳，那麼：

菜單像 API 文件
點餐像發起 API 請求
廚房出餐像模型回傳結果

所以很多工具表面看起來不一樣，但底層其實都在呼叫某種 API。

7. 多模態：AI 不只會處理文字

「多模態」說的是 AI 不再只會讀寫文字，而是可以同時處理多種形式的資訊。

例如它可以看圖、聽語音、理解影片、生成圖片，甚至支援即時語音和視訊互動。和早期只能處理文字的模型相比，多模態模型更接近同時具備「看、聽、說、寫」的能力。

這也是為什麼現在很多 AI 產品，已經不再只圍繞一個文字輸入框來設計。

8. RAG：先找資料，再組織答案

RAG 是 Retrieval-Augmented Generation，通常譯作檢索增強生成。

它適合用來解決一個很實際的問題：模型的訓練資料有時間邊界，也不會自動知道你公司最新的文件、客服紀錄或業務規則。RAG 的做法是先從指定資料裡找出相關內容，再根據這些內容生成回答。

它的價值通常體現在三點：

答案更容易貼近真實資料
可以追溯答案依據來自哪裡
新文件加入後，知識也能快速更新

所以很多企業知識庫、AI 客服和內部問答系統，底層都會用到 RAG。

9. AIGC：AI 生成內容的總稱

AIGC 是 AI Generated Content 的縮寫。

它不是某一個單獨工具，而是一個總稱，泛指 AI 生成出來的內容，包括文字、圖片、音訊、影片等各種形式。你看到的 AI 寫稿、AI 製圖、AI 做短影片、AI 配音，都可以放進 AIGC 這個大框架裡理解。

這個詞真正重要的地方在於，它描述的是一種內容生產方式，而不是某一個具體模型。

10. Token：模型處理內容時的計量單位

Token 可以理解成模型處理文字時使用的基本計量單位。

它不完全等於「一個字」或「一個單詞」，但在實際使用時，你可以先把它當成模型計算和計費的通用單位。你的輸入會消耗 Token，模型輸出的內容會消耗 Token，上下文裡保留的歷史內容同樣也會占用 Token。

所以為什麼很多模型服務一直強調上下文長度、成本控制和提示詞壓縮，本質上都和 Token 有關。

Claude Code 額度省著用：模型選擇、上下文、快取與 /compact

Sun, 19 Apr 2026 15:29:06 +0800

最近很多人在用 Claude Code 或 Claude Max 時會遇到一個問題：明明買了 Pro、Max 5x，甚至 Max 20x，結果沒跑多久就提示額度快滿，或者直接需要等重置。尤其是在大專案裡讓 Claude Code 讀很多檔案、修複雜 bug、跑長任務時，這種感覺會更明顯。

這裡先說結論：額度不是按「時間」線性扣的，而是和模型、上下文長度、附件、程式碼庫規模、對話歷史、工具呼叫和目前容量都有關係。同樣 5 小時視窗，有的人能用很久，有的人十幾分鐘就耗盡，通常不是帳號壞了，而是每次請求都太重。

這篇整理一套比較實用的省額度習慣。

01 先理解 Claude 的用量視窗

Claude Pro 和 Max 都有使用限制，Claude Code 的使用量會和 Claude 網頁、桌面、行動端共享同一套訂閱額度。官方說明裡提到，訊息數量會受到訊息長度、附件大小、目前對話長度、所用模型或功能影響；Claude Code 還會受到專案複雜度、程式碼庫大小、自動接受設定等影響。

大致可以這樣理解：

Pro：適合輕量使用和小專案。
Max 5x：適合更頻繁使用和較大的程式碼庫。
Max 20x：適合更重度、日常高頻協作。
用量視窗按 5 小時會話重置。
長訊息、長對話、大檔案、複雜任務會更快消耗額度。
Opus 這類更強模型會比 Sonnet 更快觸發限制。

所以「我只用了 20 分鐘」這個說法不一定能說明問題。真正重要的是這 20 分鐘裡 Claude 讀了多少上下文、用了什麼模型、是否反覆處理大檔案、是否在同一個長對話裡繼續加任務。

02 第一件事：不要預設一直用最貴模型

Claude 系列裡常見的定位是：

Opus：能力最強，適合複雜推理、架構決策、疑難 bug。
Sonnet：能力和成本比較均衡，適合大部分日常編碼任務。
Haiku：更輕量，適合簡單分類、摘要、格式轉換等任務。

日常寫腳本、改小 bug、整理文件、解釋程式碼，大多數時候 Sonnet 已經夠用。Opus 更適合留給這些場景：

複雜架構設計。
多檔案深度重構。
難復現的 bug。
需要長鏈路推理的排障。
普通模型明顯卡住的任務。

Claude Code 裡可以用 /model 切換模型，也可以在 /config 裡設定預設模型。比較穩的習慣是：預設 Sonnet，關鍵節點再切 Opus，而不是整場任務都用 Opus 扛。

03 第二件事：控制上下文，不要讓舊任務拖著走

上下文越長，Claude 每次處理要看的內容越多，額度消耗也越高。Claude Code 官方文件明確建議主動管理上下文：

換到不相關任務時，用 /clear 清空歷史。
目前任務做完一個階段但還要保留重點時，用 /compact 壓縮。
想知道上下文裡什麼佔空間，用 /context。
想持續看到狀態，可以設定 status line。

一個好用的節奏是：

小階段完成：/compact
大任務結束：/clear
切換無關專案：/clear
上下文接近很高佔用：提前 /compact

/compact 會把前面的對話壓成摘要，保留關鍵任務狀態、結論、檔案路徑、待辦事項，但減少後續每次請求要攜帶的歷史。你也可以給它補一句重點：

`1`	`/compact 保留已修改檔案、測試結果、剩餘待辦和關鍵設計決策`

不要等自動壓縮才處理。官方文件提到，Claude Code 會在上下文接近容量上限時自動壓縮，但手動在階段邊界壓縮，通常更可控。

04 第三件事：長對話和大檔案會讓每次請求變貴

很多人以為「我只是繼續問一句」，應該很便宜。但在長對話裡，這一句背後可能帶著大量歷史、檔案摘要、工具定義和系統規則。

特別容易漲上下文的東西包括：

一直不清理的長對話。
讓 Claude 讀完整大檔案。
貼很長日誌、建置輸出、測試輸出。
一次性塞很多截圖或圖片。
讓它反覆掃描整個倉庫。
過長的 CLAUDE.md。
開了很多 MCP server。

比較省的做法是：日誌只貼關鍵報錯，測試輸出只給失敗部分，大檔案讓它先用 rg、head、tail、符號搜尋定位，再讀必要片段。能用命令列過濾的內容，不要整包塞進上下文。

05 第四件事：理解快取，但不要迷信快取

Anthropic 的 Prompt Caching 會快取重複的 prompt 前綴。預設快取生命週期是 5 分鐘，也支援 1 小時快取。快取命中時，重複的大段上下文不需要完整重新處理，有助於降低成本和改善額度利用。

但快取有幾個限制：

需要內容完全匹配，文字和圖片都要一致。
預設快取是短生命週期。
改模型、改工具、改系統提示、改上下文結構，都可能降低命中。
輸出 token 不會因為快取而消失，該生成的回答仍然要生成。
Claude Code 具體如何利用快取，是產品層實作細節，不要把它當成永遠穩定的「免費記憶」。

實際使用裡，最重要的不是研究快取細節，而是保持會話穩定：

同一階段盡量別頻繁切模型。
不要中途反覆改大量規則。
不要在同一任務裡不停貼新圖片。
長任務中間不要閒置太久後又繼續塞大請求。
階段結束主動 /compact。

這樣更容易讓重複上下文保持可複用，也能降低後續請求負擔。

06 關於尖峰時段：能避開就避開，但不要當固定公式

網路上常有人說某些時段額度會更緊。官方幫助中心的表述更謹慎：可發送數量會受到 Claude 目前容量、對話長度、附件、模型和功能影響。也就是說，尖峰容量確實可能影響體驗，但不要把某個地區的某個時間段當成永久固定規則。

實用建議是：

大重構、大批次分析盡量放到自己網路和服務都穩定的時段。
不要在快到休息時開啟一個超長任務。
預計會離開很久時，先 /compact 或 /clear。
如果只是小改動，不要開 Opus 加長上下文硬跑。

這比記一個固定「幾點到幾點不能用」的規則更可靠。

07 精簡 CLAUDE.md、rules、MCP 和 skills

Claude Code 會在會話中載入專案規則、工具資訊和一部分環境上下文。官方文件也建議把通用規則和專用規則分開，避免每次啟動都帶著一大包不相關內容。

比較推薦的拆法：

CLAUDE.md：只放全域都適用的核心規則。
rules：放特定路徑、特定檔案類型才需要的規則。
skills：放特定工作流，例如發文章、部署、生成圖片、提交程式碼。
MCP：只啟用目前任務真的會用到的 server。

如果 CLAUDE.md 寫了幾百上千行，每次會話都要帶進去。更好的方式是把「偶爾才用」的流程移到 skill 裡，需要時再呼叫。

MCP 也是一樣。工具多不等於效率高。Claude Code 文件提到可以用 /mcp 查看並停用不需要的 server，也可以用 /context 看是什麼佔用了上下文空間。

08 實用指令清單

日常最常用的是這幾個：

/model

切換模型。預設建議用 Sonnet，複雜推理再用 Opus。

/clear

清空目前上下文。換無關任務時用，最省。

`1`	`/compact`

壓縮歷史上下文。一個階段完成但還要繼續同一任務時用。

`1`	`/context`

查看上下文佔用，排查是什麼吃掉空間。

/status

查看目前訂閱或額度相關狀態。官方幫助中心也建議用它監控剩餘額度。

/mcp

查看和管理 MCP server，關閉目前不用的工具。

如果你用 API 計費模式，還可以關注 /cost；但如果是 Pro/Max 訂閱，官方文件說明 /cost 的美元估算不適合作為訂閱帳單依據，訂閱使用者更應該看 /stats 和 /status 這類使用資訊。

09 一套省額度工作流

比較順手的流程可以是這樣：

新任務開始前先 /clear。
預設用 Sonnet。
先讓 Claude 讀專案結構和關鍵檔案，不要一口氣讀全倉庫。
每做完一個小階段就 /compact。
複雜卡點再切 Opus。
日誌、報錯、測試輸出先過濾再給。
任務完成後 /clear，不要拖著舊上下文開新活。
定期檢查 CLAUDE.md、MCP 和 skills，把常駐上下文壓小。

這個流程的核心是：讓 Claude 每次只看目前真正需要看的東西。

10 小結

Claude Code 額度快速耗盡，通常不是單一原因，而是幾個因素疊加：用了高成本模型、長對話一直不清、檔案和日誌塞太多、MCP 和規則常駐過重、快取命中變差，再加上尖峰容量波動。

省額度的核心也很簡單：

日常任務優先 Sonnet。
Opus 留給真正複雜的問題。
階段完成用 /compact。
換任務用 /clear。
用 /context 找上下文佔用來源。
精簡 CLAUDE.md、rules、MCP 和 skills。
不要把整倉庫、整日誌、整圖片包都丟進去。

同樣的 Pro 或 Max 方案，能做多少事，很大程度取決於你怎麼管理上下文。把上下文變小、任務邊界變清楚，Claude Code 的可用時間和穩定性都會明顯好很多。

參考連結

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

Firecrawl 專案整理：給 AI Agent 用的網頁搜尋、抓取與互動 API

Wed, 15 Apr 2026 13:45:03 +0800

Firecrawl 的定位很明確：把網頁變成 AI Agent 更容易消費的資料。它不是單純的爬蟲腳本，而是把搜尋、單頁抓取、整站遍歷、頁面互動、結構化擷取和 Agent 工作流封裝成 API，讓模型或自動化系統少處理網頁裡的雜訊。

01 它解決什麼問題

很多 AI 應用需要讀網頁，但真實網頁並不友善：頁面有 JavaScript 渲染、彈窗、分頁、登入狀態、反爬限制、PDF 或 DOCX 等非 HTML 內容，還有大量和正文無關的導覽、廣告、腳本和樣式。

Firecrawl 想解決的是中間層問題：應用只提出「我要這個頁面/這個站點/這個主題的資料」，它負責把網頁打開、抓取、清洗，再輸出成更適合 LLM 使用的 Markdown、HTML、截圖或 JSON。

這類工具的價值不在於「能不能請求一個 URL」，而在於能不能穩定地把複雜網頁處理成可用資料。對於 RAG、AI 搜尋、競品研究、自動化資料收集、網頁內容監控來說，這一層很容易成為工程裡的髒活。

02 核心功能

Firecrawl README 裡把能力分成幾類：

Search：搜尋網頁，並返回結果頁的完整內容。
Scrape：把單個 URL 轉換成 Markdown、HTML、截圖或結構化 JSON。
Interact：先抓取頁面，再透過提示詞或程式碼執行點擊、捲動、輸入、等待等操作。
Agent：直接描述你要找什麼，由 Agent 自動搜尋、導航並返回結果。
Crawl：抓取一個網站下的多頁內容。
Map：快速發現一個網站中的 URL。
Batch Scrape：非同步批次抓取大量 URL。

如果只看名字，它像是「爬蟲服務」。但從功能組合看，它更接近 AI 應用的資料入口：搜尋負責發現，抓取負責清洗，互動負責處理動態頁面，Agent 負責把「找資料」這件事進一步自動化。

03 為什麼適合 AI Agent

傳統爬蟲通常假設你已經知道 URL，也知道頁面結構。但 Agent 場景經常不是這樣：使用者只會問一個任務，比如「找出某家公司最新價格頁裡的套餐差異」，系統需要自己搜尋、打開頁面、比較內容，再把來源帶回來。

Firecrawl 的 Agent 介面正是為這類任務設計的。它可以只接收自然語言提示，也可以限制在指定 URL 範圍內工作；如果需要結構化結果，還可以配合 schema 輸出固定欄位。

這對應用層有兩個好處：

不必為每個網站單獨寫解析器。
返回結果更容易進入 LLM、資料庫或後續自動化流程。

當然，這並不意味著它能替代所有客製爬蟲。對於強約束、高頻、大規模、欄位非常穩定的抓取任務，專門寫解析邏輯仍然可能更便宜、更可控。Firecrawl 更適合網頁來源多、頁面結構變化大、需要快速接入 AI 工作流的場景。

04 MCP、CLI 與整合

Firecrawl 也明顯在向 Agent 工具鏈靠攏。README 中提供了 MCP Server 的接入方式，也提供了面向 AI coding agent 的 Skill/CLI 初始化命令。

這說明它不只是給後端服務呼叫，也希望直接進入 Claude Code、OpenCode、Antigravity、MCP 客戶端等工作流。對於經常讓 Agent 查資料、抓網頁、整理內容的人來說，這種整合方式比手寫 API 呼叫更輕。

它還列出了 Zapier、n8n、Lovable 等平台整合。這個方向很實用：網頁資料不一定只進程式碼，也可能進入自動化表格、低程式碼流程、內容生產系統或內部知識庫。

05 開源、自託管與授權邊界

Firecrawl 是開源專案，主倉庫以 AGPL-3.0 為主；README 也說明 SDK 和部分 UI 元件使用 MIT 授權，具體要看對應目錄裡的 LICENSE 檔案。

這點需要注意：如果只是使用它的雲端服務，主要關心 API 成本、穩定性和合規邊界；如果準備自託管並對外提供服務，AGPL-3.0 的義務就需要認真評估。

README 還提醒使用者要尊重網站政策、隱私政策和使用條款，並說明預設會遵守 robots.txt。這類工具越強，越需要把合規和抓取邊界寫進系統設計裡，而不是等上線後再補。

06 適合哪些場景

我會把 Firecrawl 放在這些場景裡優先考慮：

給 RAG 系統抓取網頁資料，並希望直接得到乾淨 Markdown。
做 AI 搜尋或研究助手，需要搜尋後讀取完整頁面。
抓取 JavaScript 較重的網站，不想自己維護瀏覽器叢集。
做競品、價格、文件、新聞、招聘頁等公開資訊監控。
給 MCP 客戶端或 AI coding agent 增加即時網頁讀取能力。
需要快速驗證一個網頁資料產品，而不是先搭一套爬蟲基礎設施。

不太適合的情況也很清楚：

目標網站欄位極少、結構穩定，用簡單腳本就能完成。
抓取量巨大，成本比開發維護成本更敏感。
業務對資料來源、重試策略、反爬行為和稽核要求非常細。
授權或合規要求不允許引入 AGPL 元件或外部雲端服務。

07 簡短判斷

Firecrawl 的核心價值，是把「網頁到 AI 可用資料」這段麻煩流程產品化。它把搜尋、抓取、清洗、互動、批次處理和 Agent 式資料收集放在同一套介面裡，對 AI 應用開發者很省心。

如果你的專案經常需要讓模型讀取真實網頁，尤其是頁面來源分散、結構不穩定、還要接入 MCP 或 Agent 工作流，Firecrawl 值得放進工具箱。反過來，如果任務只是固定網站的低成本批次採集，傳統爬蟲或專用解析器仍然更合適。

Hermes Agent 是什麼：簡介、優點、快速上手與 OpenClaw 對比

Sun, 12 Apr 2026 14:07:58 +0800

如果你最近在關注開源 AI Agent，Hermes Agent 是一個很值得看一眼的新專案。它由 Nous Research 推出，核心賣點不是「再做一個聊天殼子」，而是把長期記憶、技能沉澱、上下文檔案、MCP 擴充、訊息閘道與子代理並行這些能力，盡量收斂進同一個 agent 執行環境裡。

從官方 README 的描述來看，Hermes Agent 的目標很明確：它既可以像本地 CLI 助手一樣在終端裡工作，也可以像一個常駐雲端的個人助理一樣，透過 Telegram、Discord、Slack、WhatsApp、Signal 等管道持續和你對話。對於想把「程式碼助手」「自動化助手」「個人 AI 工作台」合併成同一套系統的使用者來說，這個定位很有吸引力。

01 Hermes Agent 簡介

Hermes Agent 是 Nous Research 開源的自我改進型 AI Agent。它支援多種模型提供方，包括 Nous Portal、OpenRouter、OpenAI，以及自訂的 OpenAI 相容端點；也支援在本地終端、Docker、SSH、Daytona、Modal 等不同執行後端上運作。

它和許多「會呼叫工具的聊天機器人」最大的差別在於，Hermes 不是只強調單次會話裡的工具呼叫，而是更重視跨會話的持續能力建設。官方文件把這種思路拆成幾塊：

持久記憶：透過 MEMORY.md 和 USER.md 保存關於環境、專案、使用者偏好的關鍵資訊。
技能系統：把複雜任務中學到的流程沉澱成技能，之後按需載入。
上下文檔案：自動讀取 AGENTS.md、SOUL.md、.cursorrules 等檔案，把專案約定直接注入會話。
MCP 整合：可以接入任何相容 MCP 的工具伺服器，擴充資料庫、GitHub、檔案系統、抓取等能力。
訊息閘道：除了 CLI，還能透過 Telegram、Discord、Slack、WhatsApp、Signal、Email 等入口使用。

如果只用一句話概括，Hermes Agent 更像是一個「帶記憶、帶技能、可擴充、可多端接入的通用 Agent 操作層」。

02 它的優點在哪裡

1. 同時覆蓋 CLI 工作流與訊息工作流

很多 agent 專案要嘛偏向「終端內開發助手」，要嘛偏向「聊天平台機器人」。Hermes 想做的是把這兩件事合併起來。你可以直接在終端裡執行 hermes，也可以啟動 gateway 後，從 Telegram 或 Discord 繼續同一個助手。

這種設計的好處是，Hermes 不侷限於「坐在電腦前才有用」。如果你把它部署在雲端或 VPS 上，它可以變成一個持續在線的個人 AI 助理。

2. 對「長期使用」考慮得更完整

Hermes 不只是會聊天和調工具，它也強調長期積累：

有邊界的持久記憶，而不是無限堆上下文。
有技能系統，可以把成功流程保存下來重複使用。
能搜尋過去會話，做跨會話召回。
能讀取專案中的上下文檔案，減少每次重複解釋相同背景。

對於經常在固定程式碼庫、固定工作流、固定團隊規範裡反覆工作的人，這一點很重要。它意味著 agent 不只是「這次幫你做點事」，而是會逐漸更懂你的環境。

3. MCP 支援讓擴充性很強

Hermes 官方文件明確支援 MCP，並說明了 stdio 與 HTTP 兩種接入方式。也就是說，只要某個外部系統已經有 MCP server，Hermes 理論上就能以更低的成本接進去。

這比每次為單一系統各自撰寫外掛更靈活。對於已經在 MCP 生態裡累積了一批工具的人來說，Hermes 的接入成本會低很多。

4. 對 OpenClaw 使用者很友善

這一點很有意思。Hermes README 裡直接提供了 hermes claw migrate，並寫明可以從 OpenClaw 匯入設定、記憶、技能、API key、訊息平台設定等內容。

這說明它並不是完全無視既有生態重新造輪子，而是明確把一部分 OpenClaw 使用者視為潛在遷移對象。

03 怎麼快速上手

Hermes Agent 官方推薦的安裝方式非常直接：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

官方說明支援 Linux、macOS、WSL2，以及 Android 的 Termux。需要注意的是，README 裡明確寫了原生 Windows 暫不支援，Windows 使用者建議改走 WSL2。

安裝完成後，通常先刷新 shell：

`1`	`source ~/.bashrc`

然後就可以直接啟動：

hermes

如果你想一步一步完成完整初始化，最省心的命令是：

`1`	`hermes setup`

根據官方文件和 README，第一次上手可以按下面這個順序來：

執行 hermes setup，完成基礎設定。
用 hermes model 選擇模型提供方與模型。
用 hermes tools 開關需要的工具集。
直接執行 hermes，進入互動式 CLI。
如果你想接 Telegram、Discord 之類的管道，再繼續設定 hermes gateway。

如果你本來就是 OpenClaw 使用者，也可以先看一下遷移命令：

`1`	`hermes claw migrate --dry-run`

它會先預覽可遷移的內容，再決定要不要正式匯入。

04 和 OpenClaw 怎麼看

從官方文件與 README 來看，Hermes Agent 與 OpenClaw 並不是簡單的「誰取代誰」，而是定位有明顯重疊，但側重點不同。

Hermes Agent 更像什麼

Hermes 更像一個偏 agent 內核與工作流系統的產品。它強調的是：

CLI 體驗
記憶與技能沉澱
專案上下文檔案
MCP 擴充
子代理並行
在本地、容器、遠端、serverless 環境之間切換執行後端

如果你的主要訴求是「讓 agent 更懂專案、更能持續複用能力、更方便接 MCP 與開發工作流」，Hermes 的方向會更順手。

OpenClaw 更像什麼

OpenClaw 則更像一個以個人 AI 助手與訊息閘道為中心的平台。它強調：

非常豐富的訊息管道接入
常駐運作的 Gateway
瀏覽器裡的 Control UI
裝置配對、遠端存取、狀態管理
語音、行動端、Canvas 等更強的助手形態

如果你的核心需求是「把一個個人 AI 助手穩定地掛在各種聊天管道與裝置上」，並且希望用控制面板統一管理，OpenClaw 的產品感會更強。

一個更實用的選擇建議

可以把兩者簡單理解成：

Hermes Agent：更偏「會成長的通用 agent 工作台」
OpenClaw：更偏「多管道常駐型個人 AI 助手平台」

當然，這個區分不是絕對的，因為兩邊都還在持續擴充能力，而且 Hermes 也提供了從 OpenClaw 遷移的路徑。但至少從目前公開資料看，Hermes 在「記憶、技能、上下文、MCP、開發工作流」這條線上更突出；OpenClaw 在「閘道、多管道、Control UI、裝置接入」這條線上更成熟。

05 適合誰嘗試

如果你屬於下面幾類人，Hermes Agent 值得優先試一下：

你已經在終端裡大量使用 AI 工具，希望 agent 更懂程式碼庫和專案規則。
你想把 AGENTS.md、技能、記憶、MCP 這些能力組合到一起。
你不想被單一模型廠商綁死，希望可以靈活切換 provider。
你原本就在用 OpenClaw，現在想試試一個更偏 agent 工作流的方向。

如果你更看重的是行動端觸達、各種 IM 平台接入、瀏覽器控制台，以及「始終在線的個人助理感」，那 OpenClaw 仍然很有吸引力。

參考連結

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
Hermes Agent 文件: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

該放棄 MCP 嗎？為什麼 CLI 正在成為 Agent 的預設工具層

Fri, 10 Apr 2026 21:55:12 +0800

過去一年，關於 Agent 工具鏈的爭論越來越集中在一個問題上：

MCP（Model Context Protocol）是讓工具調用更簡單，還是把原本簡單的事情變複雜？

在大多數日常開發任務中，CLI 正在成為更實用的預設方案。

成本差異不是「體驗問題」，而是數量級問題

MCP 最大的現實壓力是 token 開銷。

在常見場景裡，MCP 在真正執行任務前，往往需要先載入大量工具 schema。以 GitHub MCP Server 為例，初始化就可能消耗數萬 tokens。對長任務而言，這會直接擠壓上下文預算。

社群基準測試也反覆指向同一個結論：

MCP 單次調用成本常見是 CLI 的數倍到數十倍
失敗重試成本也更高（要重建連線、重新載入上下文）

這不是「慢一點」的差距，而是會放大成 API 成本、延遲與穩定性問題。

為什麼模型天然更「會用 CLI」

一個常被忽略的事實是訓練分布。

LLM 在訓練中看過海量終端文本：命令、輸出、報錯、腳本、man page。也就是說，CLI 互動模式本來就接近模型的「母語輸入」。

相對地，MCP 的 JSON-RPC 與 tool schema 是近兩年才大規模出現的新範式。模型當然能學會，但熟悉度與壓縮效率通常仍不如 CLI 這類歷史語料。

這也解釋了為什麼很多時候：

同樣目標，CLI 指令更短
輸出更適合直接持續推理
錯誤恢復路徑更穩定

安全與隔離：MCP 還有補課空間

MCP 不是不能做安全，而是生態還在早期。

當前常見擔憂包括：

工具描述投毒（Tool Poisoning）
服務行為漂移（Rug Pull）
同名工具覆蓋（Shadowing）

CLI 當然也有安全問題（注入、越權、路徑風險），但它的進程模型、權限邊界、審計鏈路已經過數十年工程實踐驗證。對生產環境而言，這種「可預期性」很重要。

這不等於 MCP 沒價值

我不認為 MCP 應該被拋棄。

更合理的定位是：

CLI 負責執行層（本地、低延遲、高頻調用）
MCP 負責連接層（遠端服務發現、統一認證、審計與多租戶）

也就是常說的混合架構：CLI + MCP Gateway。

在需要對接大量遠端系統、做統一權限治理與合規審計時，MCP 仍然有明顯價值；但在「讓 Agent 快速完成開發任務」這件事上，CLI-first 往往更符合當前模型能力邊界。

在今天的工程現實裡，CLI 更像 Agent 的工作母語；MCP 更適合作為連接協議，而不是唯一執行協議。