AI Agent on KnightLi的博客

OpenAI Symphony 是什麼？Codex 編排、Issue 驅動與 AI Agent 開發工作流

Mon, 25 May 2026 00:17:32 +0800

OpenAI 最近開源了一個很有意思的 Codex 編排規範：Symphony。

它不是另一個聊天式編程助手，也不是一個完整的新 IDE。更準確地說，Symphony 是一套面向 Codex 的「工作編排方式」：把類似 Linear 的 issue tracker 變成編程智能體的控制平面，讓每一個未關閉的任務都能對應一個持續運行的 Agent。

官方文章裡有一句話很能概括它的方向：過去工程師要同時盯著多個 Codex 會話，不斷分配任務、審查輸出、糾偏和重啟；Symphony 想解決的，正是這個上下文切換瓶頸。

Symphony 解決的不是寫代碼，而是管理 Agent

單個 Codex 會話適合互動式開發：你給它一個任務，它修改代碼，你 review，再繼續追問。但當團隊開始同時使用多個 Agent 時，問題會從「代碼能不能寫出來」變成「誰在做哪件事、做到哪一步、失敗後誰來接手」。

OpenAI 的做法是把工作重心從「會話」切到「任務」：

issue 是真正的工作單元；
每個未關閉 issue 都可以映射到一個獨立 Agent 工作空間；
Symphony 負責持續輪詢任務看板，決定哪些任務需要啟動、重試、停止或回收；
Codex 在工作空間裡執行實作、測試、提交、建立 PR、更新狀態等動作；
人類不再微操每個會話，而是審查結果、調整目標和維護邊界。

這背後的變化很關鍵：Agent 不再只是一個被人類臨時喚起的工具，而是開發流程裡持續運行的一類執行者。

為什麼是 issue tracker？

因為團隊已經用 issue tracker 管理真實工作。

需求、bug、重構、遷移、調研、優先級、阻塞關係、負責人、里程碑，這些資訊本來就沉澱在 Linear、GitHub Issues 或類似系統裡。Symphony 沒有重新發明一個龐大的控制台，而是把這些現有系統當作 Agent 的任務入口。

這樣做有幾個好處：

工作不必從 issue 複製到聊天視窗裡。
人類可以繼續按熟悉的方式建立、拆分、排期和關閉任務。
Agent 的狀態變化能回寫到同一個工作系統裡，方便團隊非同步協作。
任務依賴可以自然形成 DAG，讓未阻塞的任務並行推進。

如果把傳統 CI 看成「代碼提交後的自動化」，Symphony 更像是「issue 建立後的自動化」。

它的核心工作流

一個典型的 Symphony 流程可以理解為：

创建 issue
  -> Symphony 轮询到可执行任务
  -> 为该 issue 创建独立 workspace
  -> 启动 Codex agent session
  -> Agent 阅读任务、修改代码、运行测试
  -> 创建或更新 PR
  -> 写回任务状态、评论、证据和交付物
  -> 人类 review、合并或要求修改

官方規範裡還強調了幾個工程化點：

每個 issue 使用獨立工作空間，降低相互污染；
編排器維護重試、並發和恢復狀態；
工作流策略放在倉庫內的 WORKFLOW.md，讓團隊把 Agent 應該如何處理任務寫成可版本化的規則；
實作需要保留可觀測性，至少要有結構化日誌；
成功狀態不一定是 Done，也可以是交給人類 review 的中間狀態。

這說明 Symphony 不是簡單地「讓 AI 自動寫代碼」，而是在定義一套可運行、可恢復、可審計的 Agent 工作系統。

目標驅動，而不是死板狀態機

OpenAI 在文章裡提到一個重要轉變：早期他們嘗試把很多動作寫死在外層 harness 裡，例如提交代碼、跑測試、處理 GitHub 流程。但隨著 Codex 能力增強，這種方式反而限制了 Agent。

後來的方向是給 Agent 設定目標，而不是把每一步都寫成固定狀態轉換。

比如，一個任務的目標可以是「完成 Vite 遷移並確保 CI 通過」。Agent 可以自己判斷是否需要改配置、修測試、讀 CI 日誌、處理 review feedback，甚至拆出新的後續 issue。Symphony 負責提供邊界、上下文和運行框架，而不是替 Agent 規定每一個動作。

這也是它和傳統自動化腳本的區別：腳本擅長重複確定流程；Symphony 面向的是帶有不確定性的工程任務。

和普通 Codex 使用方式有什麼不同？

普通 Codex 會話更像「人帶著 AI 寫代碼」：

人類打開會話；
人類描述任務；
人類觀察輸出；
人類隨時糾偏；
任務結束後再開下一個會話。

Symphony 更像「團隊把任務池交給一組 Agent 執行」：

人類寫清楚 issue；
系統持續發現可執行任務；
Agent 在獨立環境裡推進；
結果以 PR、評論、測試狀態、影片或分析報告的形式返回；
人類在關鍵節點做 review。

這不是替代工程師，而是把工程師從「同時照看多個會話」的負擔裡解放出來。OpenAI 在官方文章中提到，在部分團隊中，合併到主分支的 PR 數量有明顯提升；但更值得注意的是工作方式的變化：試驗一個想法、發起一次重構、驗證一個假設的啟動成本變低了。

適合哪些場景？

Symphony 更適合這些任務：

常規功能實作；
已有代碼庫裡的小型重構；
基礎設施遷移；
依賴升級；
測試補齊；
CI 修復；
調研後生成實作計劃；
根據 review feedback 繼續修改 PR。

它不一定適合高度模糊、需要強業務判斷或架構拍板的任務。對這類問題，互動式 Codex 會話仍然更自然，因為人類需要在過程中持續參與。

風險和邊界

Symphony 的吸引力很強，但真正落地時不能只看「自動化」這一面。

幾個邊界要提前想清楚：

issue 必須寫清楚，否則 Agent 會把模糊需求放大成錯誤實作；
Agent 的權限要收斂，尤其是倉庫、密鑰、生產環境和第三方服務訪問；
每個工作空間要隔離，避免多個任務相互污染；
CI、測試、lint 和 review 仍然是必須的質量門；
任務狀態、PR 連結、日誌和失敗原因要可追蹤；
人類 review 不能省，尤其是涉及安全、計費、資料遷移和權限邏輯的改動。

官方倉庫也把 Symphony 定位為 trusted environment 裡的工程預覽和參考實作，而不是一個拿來就能無腦替代研發流程的成品平台。

我對 Symphony 的理解

Symphony 最有價值的地方，不在於它用了 Linear，也不在於參考實作選擇了 Elixir，而在於它重新定義了編程 Agent 的入口。

過去我們習慣從聊天視窗啟動 AI 編程：這很靈活，但規模一大，人類注意力就成了瓶頸。Symphony 把入口放回 issue tracker，讓 Agent 圍繞真實任務持續工作。這樣一來，AI 編程從「個人效率工具」開始向「團隊工作流基礎設施」靠近。

如果你已經在使用 Codex、Claude Code、Cursor Agent 或類似工具，Symphony 值得關注的不是某個具體實作，而是它背後的模式：

不要只管理 Agent 會話，要管理需要完成的工作。

這可能會成為下一階段 AI 編程工具的關鍵分水嶺。

參考連結

browser-harness 的 domain skills 機制：讓 AI Agent 不再重複踩網頁自動化的坑

Sun, 24 May 2026 23:43:35 +0800

browser-use/browser-harness 最有意思的地方，不只是讓 AI Agent 能控制真實 Chrome，而是它把網頁操作中的經驗變成了可以重用的 domain skills。

這件事很關鍵。瀏覽器自動化真正困難的地方，往往不是「能不能點擊按鈕」，而是每個網站都有自己的細節：

哪些頁面必須登入。
哪些資料可以直接走 API。
哪些按鈕用普通 DOM 點擊無效。
哪些 iframe、shadow DOM、彈窗會擋住流程。
哪些選擇器穩定，哪些只是臨時 class。
哪些操作涉及帳號、支付或不可逆變更，必須讓人確認。

如果這些經驗只留在一次任務日誌裡，Agent 下次還會重新踩坑。domain skills 的作用，就是把這些經驗沉澱下來，讓 Agent 不必每次都像第一次打開網站。

domain skills 是什麼

可以把 domain skills 理解成「給 Agent 看的站點操作手冊」。

它不是普通的使用者文件，也不是一次性腳本。它更像一組經過實測的站點級知識：

這個站點適不適合用瀏覽器。
如果有 API，應該優先用哪個 API。
如果必須操作網頁，應該從哪個 URL 進入。
哪些 DOM 結構、aria-label、按鈕行為經過驗證。
哪些常見寫法會失敗。
哪些場景要停止並請求人類介入。

這類內容既能被人類審查，也能被 Agent 在任務中讀取。它把「臨場摸索」變成「可維護經驗」。

它不是讓 Agent 盲目點擊

一個好的瀏覽器 Agent，不應該把所有問題都變成打開網頁、看截圖、點按鈕。

domain skills 裡很重要的一類經驗，恰恰是在告訴 Agent：什麼時候不要用瀏覽器。

比如 ArXiv 這類站點，論文搜尋、元資料和摘要可以透過 Atom API 或 HTML meta 標籤直接拿到。用 HTTP 請求通常比打開瀏覽器更快、更穩，也更容易解析。

GitHub 也是類似思路。倉庫、使用者、release 資料優先用 REST API；檔案內容優先讀 raw.githubusercontent.com；只有 GitHub Trending 這類沒有等價 API 的頁面，才需要進入瀏覽器。

這說明 browser-harness 的思路不是「瀏覽器萬能」，而是把瀏覽器放在正確位置：當 API、HTTP、靜態頁面無法解決問題時，再讓 Agent 操作真實頁面。

它記錄的是站點級知識

傳統自動化腳本通常圍繞一次任務寫，比如：

`1`	`打開頁面 -> 輸入關鍵詞 -> 點擊按鈕 -> 下載文件`

這種腳本可以完成任務，但經驗很容易散落在程式碼裡。站點一改版，腳本失效；換一個任務，很多經驗也沒法重用。

domain skills 的粒度更接近站點級知識庫。它關心的是：

Amazon 搜尋結果裡哪個容器選擇器穩定。
GitHub 哪些資料應該走 REST API。
LinkedIn 邀請管理頁的按鈕 aria-label 有什麼差異。
Shopify Admin 裡哪些頁面是嵌入式 app。
Shopify Polaris 輸入框為什麼不能只用普通 JS 設定 value。
Browser Use Cloud 的瀏覽器實例如何建立、列出和清理。

這些經驗不是一次任務的步驟，而是以後很多任務都會用到的判斷依據。

例子：Amazon 商品搜尋

Amazon 商品搜尋的經驗，重點不只是「怎麼搜尋商品」，而是哪些路徑更穩定。

比較可靠的做法是直接使用搜尋 URL，而不是每次都打開首頁再模擬輸入。搜尋結果可以從 [data-component-type="s-search-result"] 這樣的容器中提取。欄位提取也有細節：標題、價格、評分、評論數、是否贊助，都有各自更穩的 DOM 來源。

這種經驗對 Agent 很有價值。沒有它時，Agent 可能會從截圖裡猜按鈕、反覆嘗試選擇器；有了它之後，Agent 可以直接進入更穩定的資料提取路徑。

更重要的是，這類 skill 還會記錄陷阱。例如某些看似可用的選擇器，在贊助結果或交叉推薦區域裡會誤讀。這種坑只有實測過才知道。

例子：LinkedIn 邀請管理

LinkedIn 這類站點更接近真實帳號工作流，風險也更高。

在邀請管理頁裡，Accept 和 Ignore 按鈕的 aria-label 格式不同，不能簡單地從一個推導另一個。有些邀請卡片裡的 Accept 控件甚至不是 <button>，而是 <a>，普通 CDP 點擊不一定能觸發接受動作。

這種細節說明，真實網頁自動化不是「定位到元素就結束」。按鈕標籤、事件綁定、軟導航、元件實作方式，都會影響操作是否真的生效。

對 Agent 來說，這類經驗還有一個安全含義：涉及社交帳號、邀請、消息、發文的操作，不應該完全託管。skill 可以記錄路徑和陷阱，但批量接受邀請、對外發送內容、修改帳號資料這類動作，最好保留人工確認。

例子：Shopify Admin

Shopify Admin 的經驗說明了另一個問題：後台系統往往不是一個頁面，而是一堆嵌入式應用和複雜元件的組合。

很多 Shopify app 會運行在 iframe 裡。Polaris React 輸入框、Web Components、嵌入式 app 的互動方式也不同。某些輸入框不能只用 element.value = ...，需要使用更接近真實鍵盤輸入的 CDP keystrokes。

這類 skill 的價值在於，它讓 Agent 先判斷目前頁面屬於哪類 UI，再選擇合適的操作方式。

同時，Shopify 的經驗也強調「能不用瀏覽器就不用瀏覽器」：

唯讀商品和庫存資料，優先用 Storefront API。
有 Admin API token 時，優先用 Admin API。
編輯主題程式碼時，優先用 Shopify CLI。
只有沒有 API、一次性設定、探索後台時，才適合讓瀏覽器介入。

這才是成熟的 Agent 工具選擇邏輯。

例子：Browser Use Cloud

domain skills 不只服務網頁點擊，也可以記錄圍繞瀏覽器執行環境的 API 經驗。

Browser Use Cloud 的經驗裡，會記錄如何透過 REST API 建立 cloud browser、列出正在運行的瀏覽器、清理 zombie browser、取得 liveUrl 和 cdpUrl 等資訊。

這說明 skill 的邊界並不侷限於「某個網頁按鈕怎麼點」。只要某類任務會反覆出現，而且有穩定做法，就可以沉澱成 skill：

API 呼叫方式。
鑑權頭格式。
請求和回應結構。
已驗證狀態碼。
常見失敗模式。
清理和回收資源的方法。

對 Agent 來說，這些都是可重用能力。

為什麼這比臨場推理更可靠

很多人期待大模型每次都能「自己看懂網頁」。但真實任務裡，只靠臨場推理並不穩定。

原因很簡單：

網頁 UI 經常變化。
同一按鈕可能有多種實作。
看得見不代表點得動。
能點擊不代表操作真的生效。
有些任務本來就應該用 API，而不是瀏覽器。
有些操作需要人類確認，不能讓模型自己決定。

domain skills 把這些經驗寫成文件後，有幾個好處：

人類可以 review。
錯誤經驗可以修正。
同一站點的經驗可以持續積累。
新 Agent 可以直接繼承舊經驗。
臨時任務發現可以變成長期知識。

這比把一切都塞進 prompt 或聊天上下文更穩。

團隊可以怎麼用

如果把 browser-harness 用在團隊裡，domain skills 可以變成一種輕量自動化知識庫。

比較適合沉澱的內容包括：

內部後台的登入後路徑。
報表匯出流程。
常見彈窗處理方式。
哪些按鈕需要人工確認。
哪些頁面有 API 替代方案。
哪些選擇器經過實測可靠。
哪些任務不允許 Agent 自動執行。

這類知識不必一開始就很完整。更實際的做法是從低風險、高頻、可回復的流程開始：先讓 Agent 做唯讀、下載、整理、檢查類任務。等流程穩定後，再把經驗整理成 skill。

對團隊管理者來說，skill 文件還有一個好處：它讓自動化邊界變得可見。你可以審查 Agent 知道什麼、能做什麼、應該停在哪裡。

需要注意的邊界

domain skills 能提高 Agent 成功率，但它不應該讓高風險操作完全自動化。

幾個邊界要守住：

不記錄密碼、Cookie、token、客戶資料和內部敏感 URL。
支付、刪除、批量提交、帳號變更、對外發布內容，要保留人工確認。
skill 要寫明驗證日期和適用範圍。
站點改版後，要允許 skill 失效並重新驗證。
不要把繞過風控、規避平台限制當成目標。

換句話說，domain skill 是讓 Agent 更穩，不是讓 Agent 無限制地做事。

簡單結論

browser-harness 的 domain skills 機制說明了一件事：AI Agent 的瀏覽器自動化，不能只靠模型臨場發揮。

一個可用的瀏覽器 Agent，至少需要三層能力：

底層控制能力：截圖、點擊、輸入、下載、CDP、HTTP。
站點級知識：API 優先級、穩定選擇器、元件陷阱、登入邊界。
人類安全規則：憑據不交給模型，高風險操作要確認，敏感資訊不寫進 skill。

domain skills 補的是第二層。它讓 Agent 帶著驗證過的經驗進入網頁任務，而不是每次都重新摸索。

參考資料：

browser-harness domain skills：https://github.com/browser-use/browser-harness/tree/main/agent-workspace/domain-skills
Amazon product-search skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/amazon/product-search.md
ArXiv scraping skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/arxiv/scraping.md
GitHub scraping skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/github/scraping.md
LinkedIn invitation-manager skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/linkedin/invitation-manager.md
Shopify admin skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/shopify-admin/README.md
Browser Use Cloud skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/browser-use-cloud/cloud.md

browser-harness、Playwright、Puppeteer 怎麼選？瀏覽器自動化工具對比

Sun, 24 May 2026 17:51:28 +0800

在瀏覽器自動化和自動化測試領域，Playwright 和 Puppeteer 是最常被拿來比較的兩個工具。它們都可以控制瀏覽器、點擊頁面、抓取內容、產生截圖或 PDF，也都和 Chrome DevTools Protocol 有很深關係。

但如果把 browser-use/browser-harness 放進來，問題就不只是「哪個測試框架更強」，而是變成兩類工具的對比：

Playwright / Puppeteer：面向人類工程師寫確定性腳本。
browser-harness：面向 AI Agent 操作真實瀏覽器。

前者適合測試、爬蟲和工程化自動化；後者更像給 Claude Code、Codex CLI、Gemini 這類 Agent 準備的瀏覽器控制層。

Playwright 和 Puppeteer 的關係

Puppeteer 最早由 Google Chrome 團隊推出，天然服務於 Chromium 和 Chrome 自動化。它的 API 簡潔，生態成熟，特別適合圍繞 Chrome 做截圖、PDF、頁面抓取和輕量自動化。

Playwright 由 Microsoft 維護，背後團隊和早期 Puppeteer 有很深淵源。它吸收了 Puppeteer 的很多經驗，同時把跨瀏覽器、自動等待、上下文隔離、測試報告和調試工具鏈做得更完整。

簡單說：

只圍繞 Chrome 做輕量任務，Puppeteer 仍然很順手。
做跨瀏覽器 E2E 測試、複雜 SPA 自動化和團隊測試工程，Playwright 通常更合適。

核心區別總覽

維度	Puppeteer	Playwright
主導方	Google	Microsoft
瀏覽器支援	主要面向 Chrome / Chromium	Chromium、Firefox、WebKit
語言支援	主要是 JavaScript / TypeScript	JavaScript / TypeScript、Python、Java、.NET
自動等待	需要更多顯式等待	Locator 和 auto-waiting 更完整
多上下文隔離	支援，但不是最突出的優勢	BrowserContext 體驗很強
工具鏈	簡潔、成熟、偏基礎	Codegen、Trace Viewer、測試報告更完整
典型場景	Chrome 自動化、截圖、PDF、輕量抓取	跨瀏覽器 E2E 測試、複雜前端應用自動化

瀏覽器支援

Puppeteer 的優勢在 Chrome。它和 Chromium 結合緊密，如果你的目標就是控制 Chrome、產生 PDF、截圖、跑簡單爬蟲，Puppeteer 的心智負擔很低。

Playwright 的優勢在跨瀏覽器。它原生支援 Chromium、Firefox 和 WebKit。WebKit 這一點很關鍵，因為很多 Safari 相關問題不能只靠 Chrome 測出來。對需要覆蓋桌面端、行動端和不同瀏覽器核心的應用來說，Playwright 更適合作為主力工具。

這也是兩者選擇的第一道分界線：只看 Chrome，可以用 Puppeteer；要認真做跨瀏覽器測試，優先 Playwright。

自動等待與穩定性

瀏覽器自動化最煩人的問題，往往不是「不會點擊」，而是頁面還沒準備好。元素可能還沒掛到 DOM，可能被遮擋，可能正在動畫中，可能按鈕還是 disabled。

Puppeteer 裡經常會寫：

1
2

await page.waitForSelector('#submit-btn');
await page.click('#submit-btn');

這沒有問題，但等待邏輯需要工程師自己想清楚。頁面越複雜，腳本裡越容易出現各種 waitForSelector、waitForTimeout 和重試邏輯。

Playwright 的 Locator 機制和自動等待更完整：

`1`	`await page.locator('#submit-btn').click();`

在點擊之前，Playwright 會自動檢查元素是否可見、可操作、穩定、沒有被遮擋，並在合理時間內重試。這對 React、Vue、Next.js 這類非同步渲染很多的現代 Web 應用尤其重要，可以明顯減少 flaky test。

多帳號和上下文隔離

如果你要模擬多個使用者，或者想讓多個任務共享同一個瀏覽器行程但隔離 Cookie、LocalStorage 和 Session，BrowserContext 就很重要。

Puppeteer 也支援上下文隔離，但 Playwright 把這件事做成了核心能力。你可以在一個瀏覽器實例裡快速建立多個獨立 context，每個 context 像一個乾淨的瀏覽器環境，卻不需要反覆啟動完整瀏覽器行程。

這對這些場景很有價值：

多帳號並發測試。
多角色協作流程測試。
電商、IM、協作文檔等多使用者場景。
需要隔離 Cookie 和登入狀態的爬取任務。

工具鏈差異

Playwright 是更工程化的方案。它內建了很多測試開發會用到的工具：

codegen：在網頁上操作，自動產生腳本。
Trace Viewer：失敗後回看每一步的截圖、DOM、網路請求和 console 日誌。
Test Runner：支援斷言、並行、重試、報告和專案矩陣。
Locator：支援按文字、角色、label、test id 等方式定位元素。

Puppeteer 則更像一個輕量瀏覽器控制庫。它不臃腫，API 直接，適合嵌入腳本、服務端任務和自定義自動化流程。

如果你要搭企業級測試體系，Playwright 的配套工具會省很多事。如果你只是要寫一個 Node.js 腳本，把網頁轉 PDF 或定時截圖，Puppeteer 反而更乾脆。

browser-harness 放在哪裡

browser-harness 和 Playwright、Puppeteer 不是同一類工具。

Playwright 和 Puppeteer 主要假設「人類寫腳本」。人類工程師要決定選擇器、等待條件、斷言邏輯和異常處理。它們追求的是確定性：同樣的腳本，在同樣的頁面狀態下，應該給出同樣的結果。

browser-harness 主要假設「AI Agent 操作瀏覽器」。它的目標不是提供一套巨大的高階 API，而是透過 CDP 連接真實 Chrome，把截圖、座標點擊、DOM、網路請求和 helper 暴露給 Agent。Agent 可以觀察頁面、判斷下一步、遇到缺能力時補 helper，再把站點經驗沉澱成 skill。

這就讓它更適合開放任務：

登入後台後下載帳單。
在內部系統裡填一組表單。
處理經常改版的 OA 或 SaaS 頁面。
按使用者目標探索頁面，而不是執行固定腳本。
讓 Claude Code、Codex CLI 這類工具擁有瀏覽器操作能力。

三者核心對比

維度	Puppeteer	Playwright	browser-harness
面向對象	人類工程師	人類工程師和測試團隊	AI Agent
主要目標	控制 Chrome	穩定跨瀏覽器自動化	讓 Agent 操作真實瀏覽器
腳本方式	手寫 JS/TS 自動化	手寫腳本 + 測試框架	使用者下目標，Agent 分步執行
元素定位	CSS、XPath、DOM API	Locator、文字、角色、CSS	截圖視覺、座標、DOM、CDP
等待機制	更多手動控制	自動等待很強	由 Agent 觀察和調整
瀏覽器環境	通常啟動自動化瀏覽器	通常啟動測試瀏覽器	常連接真實 Chrome
最適合	Chrome 腳本、截圖、PDF、輕量抓取	E2E 測試、跨瀏覽器驗證、複雜 SPA	AI 助手、開放網頁任務、真實帳號工作流

程式碼體感對比

Puppeteer 更像直接控制 Chrome：

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.waitForSelector('#submit-btn');
  await page.click('#submit-btn');

  await browser.close();
})();

Playwright 更強調 Locator 和自動等待：

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.locator('#submit-btn').click();

  await browser.close();
})();

browser-harness 的使用體感則完全不同。你通常不是寫完整腳本，而是在 Agent 環境裡下達目標：

`1`	`幫我打開後台，下載上個月的帳單，並整理成報銷用的文件。`

Agent 會借助 browser-harness 反覆執行類似流程：

截圖，理解目前頁面。
點擊某個座標或定位某個元素。
輸入文字、上傳檔案、下載檔案。
遇到彈窗時判斷如何關閉。
缺少 helper 時補充程式碼。
把可重用流程沉澱為 domain skill。

這不是傳統測試腳本的寫法，而是瀏覽器 Agent 的工作方式。

怎麼選

選擇 Puppeteer，通常是因為：

專案主要跑在 Node.js 裡。
只需要 Chrome 或 Chromium。
任務是截圖、PDF、簡單頁面抓取或輕量自動化。
你希望 API 簡潔、依賴少，自己控制更多細節。
你對 Chrome DevTools Protocol 有較深依賴。

選擇 Playwright，通常是因為：

你要做標準 UI 自動化或 E2E 測試。
需要覆蓋 Chromium、Firefox 和 WebKit。
團隊主語言可能是 Python、Java 或 C#。
頁面是複雜 SPA，非同步狀態多，容易出現 flaky test。
你需要 codegen、Trace Viewer、測試報告和並行測試。

選擇 browser-harness，通常是因為：

你在開發或使用 AI Agent。
你希望模型像人一樣操作真實瀏覽器。
任務步驟不固定，需要邊看頁面邊判斷。
目標網站經常改版，或者彈窗、iframe、shadow DOM 很多。
你想把真實網頁工作流交給 Claude Code、Codex CLI 等工具處理。

簡單結論

Playwright 和 Puppeteer 是瀏覽器自動化工具，核心是讓人寫出可靠腳本。兩者相比，Puppeteer 更輕、更貼近 Chrome；Playwright 更完整、更適合跨瀏覽器測試和複雜前端應用。

browser-harness 則是另一個方向：它不是為了取代 Playwright 或 Puppeteer 寫測試，而是為了讓 AI Agent 接管真實瀏覽器。它犧牲了一部分傳統腳本的確定性，換來更強的開放任務適應能力。

所以答案不是三選一，而是按任務分層：

測試工程：優先 Playwright。
Chrome 輕量腳本：Puppeteer 很合適。
AI Agent 上網辦事：看 browser-harness。

參考資料：

browser-use/browser-harness：https://github.com/browser-use/browser-harness
Playwright 官方文件：https://playwright.dev/
Puppeteer 官方文件：https://pptr.dev/
Chrome DevTools Protocol：https://chromedevtools.github.io/devtools-protocol/

browser-harness 是什麼？讓 AI Agent 接管真實 Chrome 的瀏覽器自動化工具

Sun, 24 May 2026 17:19:54 +0800

browser-use/browser-harness 是一個面向 AI Agent 的瀏覽器控制工具。它的目標不是再做一層複雜的自動化框架，而是把大模型直接連到真實 Chrome，透過 CDP 完成瀏覽、點擊、截圖、下載、上傳和表單操作。

專案 README 對自己的定位很明確：用一層很薄、可編輯的 CDP harness，讓 LLM 直接連接真實瀏覽器；當任務中缺少 helper 時，Agent 可以在執行過程中補上程式碼，並把可重用經驗沉澱成 domain skills。

這類工具值得關注，是因為瀏覽器仍然是很多真實工作的入口：後台系統、SaaS 面板、電商頁面、招聘網站、CRM、報銷系統、雲控制台、文件平台，往往沒有穩定 API，或者 API 權限比網頁權限更難拿到。讓 Agent 能可靠操作瀏覽器，本質上是在補齊自動化的最後一段距離。

browser-harness 是什麼

從結構看，browser-harness 更像一個給 Agent 用的瀏覽器執行環境，而不是普通使用者手動點擊的瀏覽器外掛。

它的核心思路有幾個：

直接連接 Chrome 或 Chromium。
透過 CDP WebSocket 操作頁面。
讓 Agent 組合截圖、座標點擊、DOM、網路請求和原始 CDP 完成任務。
把任務相關 helper 放在 agent-workspace/agent_helpers.py。
把站點相關經驗沉澱到 agent-workspace/domain-skills/。
保持核心很薄，避免做成龐大的自動化平台。

README 提到，專案核心架構大約是 4 個核心檔案、約 1000 行程式碼，主要包括 install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/。

這種設計的重點不是內建所有網站能力，而是給 Agent 一個足夠貼近真實瀏覽器的操作層，讓它在具體任務裡補齊缺失能力。

它和傳統瀏覽器自動化有什麼不同

傳統瀏覽器自動化通常圍繞測試框架展開，例如 Playwright、Selenium 或 Puppeteer。它們適合寫確定性的測試腳本：打開頁面、定位元素、點擊、斷言結果。

browser-harness 面向的是另一類任務：使用者說一句目標，Agent 自己探索頁面、判斷狀態、處理彈窗、補 helper、複用站點經驗。它強調的是互動過程中的適應性。

差異可以這樣理解：

Playwright 更適合人寫腳本，Agent 執行腳本。
browser-harness 更適合 Agent 邊看頁面邊行動。
傳統自動化偏固定流程。
browser-harness 偏開放任務。
傳統腳本常依賴選擇器。
browser-harness 鼓勵先截圖、再按可見介面行動，必要時再回到 DOM 或 CDP。

這不表示它要取代 Playwright。對穩定測試來說，Playwright 仍然更成熟。browser-harness 的價值在於把真實網頁變成 Agent 可操作的環境，尤其適合頁面結構複雜、步驟不固定、需要臨場判斷的任務。

為什麼強調真實 Chrome

很多瀏覽器 Agent 工具會使用隔離的無頭瀏覽器。這樣部署簡單，也適合批量任務，但它有一個現實問題：使用者真實工作裡的登入狀態、擴充功能、歷史記錄、書籤和日常瀏覽器環境，不一定能直接複用。

browser-harness 支援連接本機 Chrome，也支援 Browser Use cloud browser。對本機瀏覽器，它提供兩種方式：

透過 chrome://inspect/#remote-debugging 允許目前 Chrome 實例被連接。
用 --remote-debugging-port=9222 --user-data-dir=... 啟動一個隔離 profile。

如果要讓 Agent 幫你處理真實帳號裡的任務，專案文件更傾向第一種方式，因為它能複用日常 Chrome 的登入狀態、擴充功能和書籤。如果要做無人值守自動化，或者不希望被彈窗打斷，則更適合使用隔離 profile 或雲瀏覽器。

這裡的取捨很清楚：真實瀏覽器更貼近使用者工作流，但安全邊界也更敏感；隔離瀏覽器更適合自動化，但需要重新處理登入和環境。

可編輯 helper 與 domain skills

browser-harness 最有意思的地方，是它把「Agent 會學到什麼」設計進了專案結構。

agent-workspace/agent_helpers.py 用來放任務中臨時補出的 helper。比如 Agent 做檔案上傳時發現現有能力不夠，可以補一個穩定的上傳函式；下次再遇到類似頁面，就不用從零開始。

agent-workspace/domain-skills/ 則用來放站點級經驗。README 裡舉的方向包括 LinkedIn outreach、Amazon 下單、報銷系統等。專案建議不要手寫這些 skill，而是讓 Agent 在真實任務中發現可重用流程後再生成，這樣更貼近實際頁面行為。

這個思路很適合瀏覽器自動化。因為網頁自動化的難點往往不是「怎麼點擊按鈕」，而是：

某個網站的登入後頁面怎麼跳轉。
哪些彈窗會擋住主流程。
哪些 selector 穩定，哪些只是臨時樣式名。
上傳、下載、iframe、shadow DOM、跨域元件怎麼處理。
某個後台系統有哪些隱藏等待和非同步狀態。

這些知識如果只留在一次執行日誌裡，很快就會丟掉。把它們沉澱成 domain skills，才可能讓 Agent 越用越順。

適合哪些場景

browser-harness 更適合以下任務：

幫使用者操作真實網頁後台。
在沒有 API 的系統裡完成重複流程。
登入狀態依賴強的個人或企業網頁任務。
需要截圖判斷頁面狀態的複雜互動。
Agent 需要在執行中補工具、補站點經驗。
多個子 Agent 各自使用獨立瀏覽器執行任務。
研究瀏覽器 Agent 的執行環境設計。

具體例子包括：整理網頁表格、提交內部系統表單、下載帳單、上傳檔案、處理報銷流程、檢查訂單狀態、在 SaaS 控制台裡配置資源、從登入後的網頁提取資訊。

如果任務只是抓取靜態網頁，未必需要瀏覽器。專案自己的 SKILL.md 也提到，靜態頁面可以直接用 HTTP 批量取得；瀏覽器應該留給真正需要頁面狀態、登入狀態和互動的場景。

需要注意的風險

讓 AI Agent 接管真實 Chrome，很強，也很危險。

第一，權限邊界要清楚。真實 Chrome 裡可能有信箱、支付後台、雲控制台、公司系統和個人帳號。Agent 一旦能操作瀏覽器，就等於獲得了這些網頁權限的一部分。

第二，不要把憑證交給模型。遇到登入頁、支付驗證、二次確認等敏感步驟，應該讓使用者自己處理。Agent 可以等待登入完成，但不應該從截圖裡讀取或輸入密碼、驗證碼、支付資訊。

第三，自動化不等於可託管。很多網頁任務看似簡單，但中間可能出現風控、誤點擊、資料刪除、批量提交、不可逆操作。適合先從唯讀、低風險、可回復的流程開始。

第四，domain skills 需要避免洩露隱私。站點經驗可以公開，但不要把帳號、內部 URL、客戶資料、座標流水或一次性任務細節寫進去。

第五，真實瀏覽器連接方式要謹慎選擇。如果要複用日常登入狀態，使用目前 Chrome 很方便；如果要跑長時間自動化，隔離 profile 或雲瀏覽器更可控。

對 AI Agent 工具的意義

browser-harness 代表了一種很務實的 Agent 工具路線：少做平台，多給模型一個可以直接觸達真實環境的介面。

過去很多 Agent 失敗在兩端。一端是模型會推理，但摸不到真實頁面；另一端是自動化框架很強，但需要人先把流程寫死。browser-harness 試圖把這兩端接起來：瀏覽器負責真實世界的狀態，Agent 負責觀察、判斷和補工具。

這也是「自我改進 harness」的意義。它不是說 Agent 會神奇地變聰明，而是把可重用的操作經驗放到專案結構裡，讓下一次任務少走彎路。

對開發者來說，browser-harness 的價值主要在三個層面：

作為個人 Agent 的瀏覽器控制層。
作為研究瀏覽器自動化和 Agent 工作流的樣本。
作為把網頁流程變成可重用技能的實驗框架。

它不是所有瀏覽器自動化問題的答案，但它給出了一個清晰方向：當 Agent 真正要幫人做事時，工具層不只要能呼叫 API，也要能理解和操作人類每天使用的網頁介面。

簡單結論

browser-use/browser-harness 值得關注，不是因為它包裝了多少高階功能，而是因為它把瀏覽器 Agent 的幾個關鍵問題擺在了台面上：真實 Chrome、CDP、截圖驅動、可編輯 helper、站點技能沉澱，以及使用者權限邊界。

如果你只是寫穩定端到端測試，繼續用 Playwright 或 Selenium 就很好。如果你想讓 Codex、Claude Code 這類 Agent 直接幫你處理真實網頁任務，browser-harness 提供了一個更貼近 Agent 工作方式的入口。

真正使用時，建議從低風險任務開始：先讓它讀頁面、截圖、提取資訊，再逐步嘗試點擊和提交。等你確認它能穩定識別頁面狀態，再考慮讓它接管更長的流程。

參考資料：

GitHub 專案：https://github.com/browser-use/browser-harness
README：https://github.com/browser-use/browser-harness/blob/main/README.md
安裝文件：https://github.com/browser-use/browser-harness/blob/main/install.md
使用說明：https://github.com/browser-use/browser-harness/blob/main/SKILL.md

GitHub AI 開源專案分類整理：從 Coding Agent 到 RAG 知識庫

Thu, 21 May 2026 08:53:13 +0800

這裡按應用方向列出 GitHub AI 專案，覆蓋 AI 程式設計與 Coding Agent、Agent 技能與工作流、RAG 與知識庫、多模態創作、本地模型與推理、垂直應用與自動化、AI 應用開發基礎設施等方向。後續新增專案時，也可以繼續按這個結構補充。

分類合計

分類	專案數	適合先看的人
AI程式設計與 Coding Agent	22	經常使用 Claude Code、Codex、Cursor、終端 Agent 或程式碼庫自動化的人
Agent 技能與工作流	7	想把 AI 程式設計、科研、創作流程標準化的人
RAG、知識庫與記憶	7	需要文件檢索、知識庫、長期記憶、網頁抓取和結構化抽取的人
垂直應用與自動化	7	想看金融、交易、閒魚監控、桌面操作、瀏覽器自動化等落地場景的人
多模態與內容創作	5	做圖片、影片、語音轉寫、提示詞庫和內容分發的人
AI 應用開發基礎設施	5	構建 AI 應用、瀏覽器自動化、Prompt/MCP 工具鏈的人
本地模型與推理	1	關心本地 DeepSeek、推理引擎和硬體適配的人

這個分佈可以看出當前 AI 開源專案的幾個高頻方向：AI 程式設計工具明顯最多，其次是 Agent 工作流、RAG 知識庫和具體應用場景。純模型推理專案數量不多，因為很多本地部署內容並不是單獨介紹某個 GitHub 專案，而是圍繞模型、顯示卡或部署方案展開。

AI程式設計與 Coding Agent

這一類聚焦程式碼理解、程式碼修改、工程流程和終端 Agent，是數量最多的一組。共 22 個專案。

專案	文章	GitHub	核心用途	適合人群
Ralph	Ralph 是什麼：把 Claude Code 和 Amp 變成可迴圈執行的自主開發流程	snarktank/ralph	讓 Claude Code / Amp 按 PRD、計劃、執行、評審迴圈推進任務	想把 Agent 程式設計流程拉直的人
Claude-Mem	Claude-Mem：給 Claude Code 加上跨會話長期記憶	thedotmack/claude-mem	為 Claude Code 增加跨會話記憶	高頻使用 Claude Code 的開發者
Claude Code Hooks Mastery	Claude Code Hooks Mastery：13 個 Hooks 生命週期與自動化控制入門	disler/claude-code-hooks-mastery	學習 Claude Code Hooks 生命週期和自動化控制	想定製 Claude Code 流程的人
Compound Engineering Plugin	Compound Engineering Plugin：把 AI 程式設計變成計劃、執行、評審的工程迴圈	EveryInc/compound-engineering-plugin	把 AI 程式設計拆成計劃、執行、評審迴圈	關注工程化 AI 程式設計的人
free-claude-code	free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型	Alishahryar1/free-claude-code	透過代理把 Claude Code 接到不同模型後端	想降低 Claude Code 使用成本的人
Hermes Agent	Hermes Agent 是什麼：簡介、優點、快速上手與 OpenClaw 對比	NousResearch/hermes-agent	本地 Agent 框架，支援工具呼叫和任務執行	想跑本地 Agent 的使用者
OpenHarness	OpenHarness 是什麼：這個開源 Agent Harness 能做什麼	HKUDS/OpenHarness	Agent Harness 與多 Agent 執行框架	研究 Agent 編排的人
CodexBridge	Codex 怎麼接入國產大模型？OpenAI 相容介面與 CodexBridge 使用思路	begonia599/CodexBridge	幫 Codex 接入 OpenAI 相容模型介面	想把 Codex 接到國產模型的人
ccx	Codex 怎麼接入國產大模型？用 CCX 統一管理 OpenAI 相容 API	BenedictKing/ccx	統一管理 Claude、Codex、Gemini 等 API 代理	多模型切換使用者
cc-haha	cc-haha 是什麼？一個把 Claude Code 做成桌面工作臺的專案	NanmiCoder/cc-haha	Claude Code 桌面工作臺與 Computer Use 入口	喜歡圖形介面的 Claude Code 使用者
DeepSeek-TUI	DeepSeek-TUI：把 DeepSeek V4 變成終端裡的程式設計智慧體	Hmbown/DeepSeek-TUI	在終端裡執行 DeepSeek 程式設計 Agent	DeepSeek 與命令列使用者
Open Design	Open Design 專案解析：把 Claude Code、Codex 變成 AI 設計工具	nexu-io/open-design	讓 Claude Code / Codex 參與設計生成	想用 Agent 做設計原型的人
agentmemory	agentmemory 專案解析：給 Claude Code、Codex 和 Cursor 加持久記憶	rohitg00/agentmemory	給 Coding Agent 增加持久記憶層	長期維護專案的開發者
Graphify	Graphify 解決 Claude Code 最大侷限：把程式碼庫變成 AI 可查詢知識圖譜	safishamsi/graphify	把程式碼庫轉成知識圖譜，降低 Agent 重複讀檔案成本	大型程式碼庫使用者
oh-my-pi	oh-my-pi 是什麼？一個把終端、IDE 和偵錯器打通的 AI 編程助手	can1357/oh-my-pi	把終端、IDE、LSP 和偵錯器連接起來，作為本機 AI 編程控制台	想把命令列和 IDE 工作流打通的開發者
Claude Plugins Official	Claude Code 也有外掛市場了：能裝什麼、怎麼裝、要注意什麼	anthropics/claude-plugins-official	Claude Code 官方外掛目錄和安裝入口	想給 Claude Code 擴展能力的使用者
CodeGraph	CodeGraph 是什麼？給 Claude Code、Codex 和 Cursor 加一個本機程式碼地圖	colbymchenry/codegraph	為程式碼庫生成本機索引和關係圖，幫助 Coding Agent 理解專案	維護中大型程式碼庫的開發者
CC Switch	CC Switch：一個桌面工具統一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw	farion1231/cc-switch	管理多個 AI CLI 工具和賬號/配置切換	同時使用多套 CLI 的人
Warp	Warp 開源：從終端到 Agentic Development Environment	warpdotdev/warp	Agentic 終端與開發環境	終端重度使用者
opencode	opencode、Claude Code、Codex 有什麼區別？開源 AI 程式設計工具使用指南	anomalyco/opencode	開源 AI 程式設計 Agent	想找 Claude Code / Codex 替代品的人
9Router	9Router：把 Claude Code、Codex、Cursor 接到同一個 AI 路由器	decolua/9router	AI 程式設計模型路由與 token 成本控制	多工具、多模型使用者
goose	goose：桌面端、CLI 和 API 一體的開源 AI Agent	aaif-goose/goose	桌面、CLI、API 一體的開源 Agent	想要通用 Agent 工作臺的人

Agent 技能與工作流

這一類更關注把 AI 能力固化成可重複的技能、流程和規格。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
mattpocock/skills	拒絕 Vibe Coding：Matt Pocock 的 skills 倉庫給 AI 程式設計補上工程約束	mattpocock/skills	用 Skills 約束 AI 程式設計流程	想給 Agent 加工程規範的人
Superpowers	Superpowers：把 Coding Agent 拉回工程流程的技能框架	obra/superpowers	Agentic skills framework 與軟體開發方法論	想系統化使用 Coding Agent 的人
Prompt-Vault	Prompt-Vault：一個適合測試 AI 程式設計能力的 Prompt 規格庫	w512/Prompt-Vault	收集可測試 AI 程式設計能力的 prompt 規格	做模型/工具評測的人
web-video-presentation	web-video-presentation：把文章做成可錄屏網頁影片的 Agent Skill	ConardLi/garden-skills	把文章轉成可錄屏網頁影片的 Skill	內容創作者和自動化製作使用者
nuwa-skill	nuwa-skill：把“蒸餾一個人”從靈感變成可執行流程	alchaincyf/nuwa-skill	用 Skill 復刻人物表達和思維流程	做風格化 Agent 的人
Scientific Agent Skills	Scientific Agent Skills：把科研工作流交給 AI Agent 的技能庫	K-Dense-AI/scientific-agent-skills	科研工作流 Skill 集合	科研、資料分析和技術寫作使用者
easy-vibe	easy-vibe：給 Vibe Coding 初學者的一張學習地圖	datawhalechina/easy-vibe	Vibe Coding 入門學習地圖	AI 程式設計新手

RAG、知識庫與記憶

這一類主要解決文件檢索、知識庫構建、長期記憶和結構化抽取問題。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
LangExtract	Google LangExtract：用 LLM 從長文字里抽取結構化資料	google/langextract	從長文字中抽取結構化資訊	做資訊抽取和資料處理的人
qmd	qmd：給 AI Agent 使用的本地 Markdown 文件搜尋工具	tobi/qmd	本地 Markdown 文件搜尋	用 Markdown 管理知識庫的人
Firecrawl	Firecrawl 專案整理：給 AI Agent 用的網頁搜尋、抓取與互動 API	firecrawl/firecrawl	網頁抓取、搜尋和結構化資料入口	做 RAG 和 Agent 資料入口的人
RAGFlow	RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法	infiniflow/ragflow	開源 RAG 引擎	企業知識庫和文件問答使用者
OpenHuman	OpenHuman 速讀：開源個人 AI Agent 的桌面化路線	tinyhumansai/openhuman	本地優先的個人 AI Agent 與記憶層	想整合個人資料的人
OpenKB	OpenKB：把文件編譯成可持續更新的 LLM 知識庫	VectifyAI/OpenKB	把文件編譯成可更新知識庫	文件知識庫維護者
PageIndex	PageIndex 是什麼？不用向量庫的推理式 RAG 文件索引解析	VectifyAI/PageIndex	不依賴向量庫的推理式文件索引	關注 RAG 新路線的人

多模態與內容創作

這一類面向圖片、影片、語音轉寫和內容分發等創作場景。共 5 個專案。

專案	文章	GitHub	核心用途	適合人群
rembg	rembg 專案整理：本地圖片背景移除工具	danielgatis/rembg	本地圖片背景移除	電商、美工和圖片處理使用者
awesome-gpt-image-2-prompts	GPT-Image 2 提示詞寶庫：電商、海報、人像、UI 全收錄	EvoLinkAI/awesome-gpt-image-2-prompts	GPT-Image 2 提示詞和案例庫	AI 繪圖和提示詞使用者
faster-whisper	faster-whisper：更快的 Whisper 轉寫引擎	SYSTRAN/faster-whisper	高效能語音轉文字	做字幕、轉寫和語音處理的人
Pixelle-Video	Pixelle-Video：一句主題生成短影片的開源 AI 引擎	AIDC-AI/Pixelle-Video	一句話生成短影片工作流	短影片和 AIGC 內容創作者
AiToEarn	內容發太多平臺太累？AiToEarn 想用 AI Agent 幫創作者省點事	yikart/AiToEarn	多平臺內容分發與創作者自動化	內容運營和創作者

本地模型與推理

這一類關注本地模型執行和推理實驗，當前數量較少。共 1 個專案。

專案	文章	GitHub	核心用途	適合人群
ds4	本地執行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的嘗試	antirez/ds4	在 Apple Silicon 上嘗試執行 DeepSeek 4	本地模型和推理實驗使用者

垂直應用與自動化

這一類是把 Agent 或 AI 能力落到金融、交易、瀏覽器、桌面和電商監控等具體場景。共 7 個專案。

專案	文章	GitHub	核心用途	適合人群
TradingAgents-CN	TradingAgents-CN：面向中文使用者的多智慧體金融交易研究框架	hsliuping/TradingAgents-CN	多智慧體金融交易研究框架	量化、金融和 Agent 研究者
FinceptTerminal	FinceptTerminal：開源金融終端、量化研究和 AI Agent 工作臺	Fincept-Corporation/FinceptTerminal	金融終端、量化研究和 AI Agent 工作臺	金融分析和量化使用者
Anthropic financial-services	Anthropic financial-services：把金融 Agent 場景做成可複用模板	anthropics/financial-services	金融服務 Agent 模板	做金融 AI 方案的人
ai-goofish-monitor	ai-goofish-monitor：用 AI 自動盯閒魚商品的開源監控系統	Usagi-org/ai-goofish-monitor	AI 商品監控和閒魚自動化	二手交易監控使用者
CloakBrowser	CloakBrowser 是什麼？給 Playwright 和 Puppeteer 換一個更像真實使用者的瀏覽器	CloakHQ/CloakBrowser	更像真實使用者的瀏覽器自動化環境	瀏覽器自動化和 Agent 操作場景
UI-TARS-desktop	讓 AI 自己操作電腦？UI-TARS-desktop 把桌面、瀏覽器和工具都接了起來	bytedance/UI-TARS-desktop	桌面、瀏覽器和工具操作 Agent	想讓 AI 操作電腦的人
AI-Trader	AI-Trader 是什麼？一個讓 AI Agent 釋出交易訊號、做模擬交易的平臺	HKUDS/AI-Trader	AI Agent 交易訊號和模擬交易平臺	金融 Agent 與交易研究使用者

AI 應用開發基礎設施

這一類提供構建 AI 應用和 Agent 工具鏈所需的基礎元件。共 5 個專案。

專案	文章	GitHub	核心用途	適合人群
Prompt Optimizer	Prompt Optimizer：開源提示詞最佳化、測試與 MCP 工具	linshenkx/prompt-optimizer	提示詞最佳化、測試和 MCP 工具	做 prompt 工程和應用調參的人
Playwright CLI	Playwright CLI 使用入門：安裝、Skills、會話管理與常用命令	microsoft/playwright-cli	面向 coding agent 的瀏覽器自動化 CLI	需要瀏覽器操作能力的 Agent 使用者
Vercel AI SDK	Vercel AI SDK 是什麼？TypeScript 開發者構建 AI 應用的統一工具包	vercel/ai	TypeScript AI 應用開發 SDK	前端和全棧開發者
CLIProxyAPI	CLIProxyAPI：把 Codex、Claude Code、Gemini CLI 統一封裝成 API	router-for-me/CLIProxyAPI	把多個 AI CLI 和 OAuth 登入狀態封裝成相容 API	想統一接入 Codex、Claude Code、Gemini CLI 的使用者
CLIProxyAPI Management Center	CLIProxyAPI Management Center：給 CLIProxyAPI 配一個視覺化管理後台	router-for-me/Cli-Proxy-API-Management-Center	CLIProxyAPI 的 Web 管理介面，管理設定、帳號、日誌和 OAuth	把 CLIProxyAPI 當團隊閘道或帳號池使用的人

Google I/O 2026 主要內容總結：Gemini 3.5、Omni、Antigravity 與系統級 Agent

Thu, 21 May 2026 00:07:06 +0800

Google I/O 2026 的主線很清楚：Google 正在把 Gemini 從「模型」和「聊天助手」推進到一個更完整的 Agent 生態。它不只是回答問題，而是要進入搜尋、Android、開發工具、影片創作、購物、Workspace、硬體和企業平台，幫助使用者完成更長鏈路的任務。

本文按官方發布資訊和開發者視角，整理 Google I/O 2026 的主要內容。實際開發時仍應以 Google、Android Developers 和 Gemini API 官方文件為準。

一句話總結

Google I/O 2026 的關鍵詞是 agentic Gemini era。

Google 發布或強化了幾條線：

Gemini 3.5 Flash：強調速度、行動能力和 Agent 工作流。
Gemini Omni：從任意輸入生成內容，重點從影片創作和編輯開始。
Gemini app：從聊天助手走向主動、全天候、可執行任務的個人 Agent。
Google Antigravity 2.0：從 AI 編程工具升級為 Agent 優先的開發平台。
Gemini API Managed Agents：透過 API 建立能推理、用工具、執行程式碼的託管 Agent。
Google AI Studio：擴展到行動端、Android 原生支援和專案匯出到 Antigravity。
Search、Shopping、YouTube、Workspace、Android：都在接入更強的 Gemini 和 Agent 能力。

換句話說，Google 不再只展示「模型有多聰明」，而是在展示「模型如何進入產品、工具和系統，真正替使用者執行任務」。

Gemini 3.5 Flash：從提示詞走向行動

Gemini 3.5 是 Google 在 I/O 2026 推出的新一代模型系列，首個公開重點是 Gemini 3.5 Flash。

Google 對它的定位不是單純「更快的聊天模型」，而是用於真實 Agent 工作流的高速引擎。官方開發者文章提到，3.5 Flash 結合前沿智能和高速度，用來支撐從 prompt 到 action 的轉變。

它的主要意義在於：

面向 Agent 和 coding 場景最佳化。
支援更長鏈路任務和工具呼叫。
在 Antigravity、Gemini API、Google AI Studio、Android Studio、Gemini Enterprise 等入口提供。
更適合需要快速回應、多輪執行和頻繁工具呼叫的應用。

對開發者來說，Gemini 3.5 Flash 不只是一個模型選項，而是 Google 新 Agent 工具鏈的預設動力源之一。

Gemini Omni：影片和世界模型能力成為重點

Gemini Omni 是 I/O 2026 另一個核心發布。Google 對它的描述是：從任意輸入創作內容，目前重點從影片開始。

它的看點主要有三類：

多模態輸入：文字、圖像、影片、音訊等都可以作為參考。
影片編輯：使用者可以用自然語言多輪修改影片，而不是一次性生成後就結束。
世界理解：強調物理、場景、動作、敘事和視聽一致性。

這意味著 AI 影片工具的方向正在從「輸入一句提示詞生成短片」走向「像和剪輯師溝通一樣逐輪修改」。對創作者來說，真正有價值的不是一次生成，而是可控、可追蹤、可迭代的編輯流程。

Gemini App：從聊天助手變成全天候個人 Agent

Google 也把 Gemini app 明確推向更 Agent 化的方向。官方文章提到，Gemini app 正在變得更主動，提供日常簡報和全天候幫助。

幾個重點包括：

Gemini 3.5 Flash 進入 Gemini app。
新 UI 和更動態的互動體驗。
Gemini Spark 這類個人 AI Agent 概念。
Proactive daily briefs，主動整理使用者每天需要關注的資訊。
更強調 7×24 小時背景協助，而不是使用者每次都主動發起聊天。

這部分對普通使用者影響最大。過去 Gemini 更像「你問我答」的助手；I/O 2026 之後，Google 想讓它更像能持續跟進任務、主動提醒、跨產品協同的個人智能體。

Antigravity 2.0：開發者工具轉向 Agent 優先

開發者側最重要的發布之一是 Google Antigravity 2.0。

Google 將 Antigravity 定位為 agent-first development platform。I/O 2026 之後，它不只是幫助寫程式碼，而是要幫助開發者從想法、原型、Agent 編排到生產應用交付。

官方列出的核心變化包括：

Antigravity 2.0 獨立桌面應用。
支援多 Agent 並行編排。
支援動態 subagents。
支援背景定時任務。
與 Google AI Studio、Android、Firebase 等生態整合。
提供 Antigravity CLI，面向終端機使用者。
提供 Antigravity SDK，用於自訂 Agent 行為和部署。

這說明 AI 編程工具正在從「程式碼補全 / 對話生成」進入下一階段：開發者要管理的是多個可執行 Agent，而不只是一個聊天視窗。

Gemini API Managed Agents：把 Agent 託管成 API 能力

Google 還推出了 Managed Agents in the Gemini API。

官方描述中，這類 Agent 可以透過一次 API 呼叫建立，具備推理、工具使用和在隔離 Linux 環境中執行程式碼的能力，並且由 Antigravity agent harness 提供支援。

這件事對開發者很關鍵：

不必自己搭完整 Agent 執行環境。
可以獲得持久、隔離的執行環境。
多輪互動可以保留檔案和狀態。
可以用 markdown 技能、自訂指令和模板擴展 Agent。
可透過 Interactions API 和 Google AI Studio 使用。

如果這條線成熟，Agent 平台會越來越像雲服務：開發者不再只呼叫模型，而是呼叫一個帶狀態、工具、執行環境和安全邊界的 Agent。

Google AI Studio：從 prompt playground 走向應用生成入口

I/O 2026 中，Google AI Studio 的定位也更進一步。

重點變化包括：

Google AI Studio mobile app，可在行動端捕捉想法和生成原型。
Workspace API 整合，讓 Agent 能更自然地接入 Google Workspace。
專案可匯出到 Antigravity，帶著上下文繼續本地開發和生產化。
增加 Android 原生支援，可以用 prompt 構建 Android 應用。
支援對接 Google Play Console，把應用發布到測試軌道。

這讓 AI Studio 從「調提示詞和試模型」變成「從想法到應用」的入口。它和 Antigravity 的關係也更清楚：AI Studio 適合快速構思和生成，Antigravity 適合繼續開發、編排、除錯和交付。

Android 與 AppFunctions：行動端 Agent 的關鍵接口

Android 系統級 Agent 是這次值得單獨看的方向，但需要用更準確的接口和產品邊界來理解。

目前最值得關注的是 Android 官方的 AppFunctions。官方文件說明，AppFunctions 是一種 Android 平台 API，並帶有 Jetpack 庫，可以讓應用把自身能力暴露給智能體、助手和其他有權限的呼叫方。它還簡化了 Android MCP 整合。

它的意義在於：行動端自動化不再只能依賴截圖、OCR、模擬點擊和 UI 控件定位。

傳統行動端自動化路徑是：

識別螢幕。
找按鈕。
模擬點擊。
等待頁面變化。
出錯後重試。

AppFunctions 的方向是：

應用聲明自己能做什麼。
Agent 在授權下呼叫這些能力。
系統負責權限、呼叫邊界和安全約束。

這會影響 Android 應用設計。未來應用不只要做給人看的 UI，還要把核心功能設計成可被 Agent 呼叫的能力接口。

Search、購物和內容產品也在 Agent 化

Google I/O 2026 的變化不只在模型和開發者工具裡，搜尋和消費產品也在同步變化。

官方 I/O 彙總中提到：

Search 進入新的 AI Search 階段。
Information agents 出現在搜尋場景中。
Gemini Spark 和 Daily Brief 進入 Gemini app。
Universal Cart 讓購物車更智能。
Ask YouTube 讓影片內容可以被對話式查詢和跳轉。
Gemini 能力繼續擴展到更多產品和形態。

這些發布說明 Google 的 Agent 方向不是單點產品，而是橫向鋪到搜尋、影片、購物、辦公、行動和硬體場景中。

對開發者的實際影響

Google I/O 2026 對開發者最大的影響，不是「又多了一個模型」，而是開發對象變了。

以前開發者主要構建：

App。
網站。
API。
外掛。
自動化腳本。

接下來還要構建：

可被 Agent 呼叫的應用能力。
多 Agent 工作流。
有狀態的工具執行環境。
可稽核的自動化流程。
人在回路確認機制。
與 MCP、AppFunctions、Workspace API、Playwright、Firebase 等工具的整合。

軟體會越來越像「能力集合」，而不僅是「介面集合」。誰能把自己的能力清晰、可靠、安全地開放給 Agent，誰就更容易進入使用者的自動化任務鏈。

對行動端自動化的影響

行動端自動化會從「GUI 優先」逐步變成「接口優先，GUI 兜底」。

短期看，截圖識別、OCR、模擬點擊、瀏覽器自動化仍然有價值，因為大量舊應用沒有標準接口。

長期看，只要 Android AppFunctions、MCP 和系統級權限模型成熟，穩定的任務執行會更偏向：

優先呼叫應用聲明的能力。
必要時呼叫系統接口。
再必要時用 GUI 自動化兜底。

這會改變 RPA、行動端 Agent、測試工具和應用生態。應用越願意開放能力，越容易被系統級 Agent 呼叫；不開放能力的應用，可能仍然只能被「看螢幕、點螢幕」的舊方式操作。

安全、權限和稽核會成為硬約束

Agent 能力越強，風險越大。

如果 Agent 可以跨應用執行任務、呼叫支付、修改設定、存取檔案和讀取上下文，就必須有清晰的安全邊界：

權限分級。
使用者明確授權。
敏感操作二次確認。
沙箱隔離。
操作日誌。
可撤銷和可回滾。
企業稽核與合規。

這也是為什麼 Google 會強調託管 Agent 的隔離環境、AppFunctions 的權限要求、企業平台和可控部署。Agent 的未來不是「無所不能」，而是在安全邊界內可執行、可追蹤、可治理。

小結

Google I/O 2026 的主要內容可以概括為一句話：Google 正在把 Gemini 打造成橫跨模型、應用、系統、開發工具和硬體的 Agent 平台。

Gemini 3.5 Flash 提供速度和行動能力，Gemini Omni 把多模態創作推向影片和世界理解，Gemini app 走向主動個人助手，Antigravity 2.0 和 Managed Agents 把開發者工具推向 Agent 原生，AppFunctions 則讓 Android 應用開始為智能體暴露能力。

對開發者來說，接下來要關注的不只是模型參數，而是：如何把應用能力結構化、如何接入 Agent 工具鏈、如何設計權限和稽核，以及如何讓自己的產品在系統級 Agent 生態裡被安全可靠地呼叫。

參考來源：

PageIndex 是什麼？不用向量庫的推理式 RAG 文件索引解析

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex 是一個很有意思的 RAG 專案。它不從「再建一個向量庫」開始，而是把長文件先整理成類似目錄的樹狀結構，再讓 LLM 沿著這棵樹做推理式檢索。

專案地址：VectifyAI/PageIndex

截至本文整理時，GitHub 頁面顯示專案約有 31.8k stars、2.7k forks，授權為 MIT。README 給它的定位是：Vectorless, Reasoning-based RAG，也就是無向量庫、基於推理的 RAG。

它想解決什麼問題

傳統 RAG 的常見路徑是：切塊、向量化、寫入向量資料庫，再用相似度搜尋召回片段。這套方法簡單、通用，也很成熟，但在長篇專業文件裡容易遇到幾個問題：

相似度不等於真正相關。
文件結構被切塊打散，章節關係丟失。
召回結果可解釋性弱，很難說明為什麼命中這一段。
對財報、監管文件、法律文書、技術手冊這類材料，問題往往需要跨章節推理。

PageIndex 的思路是反過來：先把文件組織成語義樹，再讓模型像人類讀目錄、翻章節、逐層定位一樣查找相關內容。

PageIndex 的基本工作流

README 裡把 PageIndex 的檢索分成兩步：

為文件生成類似 Table-of-Contents 的樹狀結構索引。
透過樹搜尋做 reasoning-based retrieval。

這棵樹不是簡單的檔案目錄，而是面向 LLM 使用的文件結構。節點裡會有標題、頁碼範圍、摘要、子節點等資訊。這樣模型在回答問題時，不必一開始就面對大量零散 chunk，而是可以先判斷應該進入哪個章節，再繼續向下搜尋。

這種方式更適合結構清晰但內容很長的文件，例如：

金融報告和 SEC filings。
監管材料和合規文件。
學術教材和論文。
法律文件。
技術手冊和產品文件。
超過模型上下文視窗的大型 PDF。

和傳統向量 RAG 的差異

PageIndex 的主要賣點可以概括成五點。

第一，不需要 Vector DB。它依賴文件結構和 LLM 推理來定位內容，而不是只做向量相似度搜尋。

第二，不做傳統 chunking。文件會按自然章節組織，而不是被切成固定長度片段。

第三，可解釋性更強。檢索路徑可以對應到頁碼、章節和樹節點，比「向量相似度命中某段文字」更容易追蹤。

第四，檢索是上下文感知的。問題、對話歷史、領域背景都可以影響樹搜尋路徑。

第五，更接近人類專家讀文件的方式。人通常不是把整份文件切成小塊再算相似度，而是先看目錄，再定位章節，最後讀細節。

這並不意味著向量庫沒有價值。更準確的說法是：PageIndex 適合那些「語義相似不夠，需要結構和推理參與」的長文件場景。

本地怎麼跑

README 提供了本地自託管方式。先安裝依賴：

`1`	`pip3 install --upgrade -r requirements.txt`

然後在專案根目錄建立 .env，寫入 LLM API key。專案透過 LiteLLM 支援多模型：

`1`	`OPENAI_API_KEY=your_openai_key_here`

對 PDF 生成 PageIndex 結構：

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

也可以處理 Markdown：

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

常見可選參數包括：

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

README 裡也提醒，本地開源版本使用標準 PDF 解析。如果是複雜 PDF，專案方的雲服務會提供增強 OCR、樹構建和檢索流程。

Agentic Vectorless RAG 示例

專案還提供了一個 agentic vectorless RAG 示例，使用自託管 PageIndex 和 OpenAI Agents SDK。安裝可選依賴後執行：

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

這個示例的價值在於，它把 PageIndex 從「生成文件樹」推進到「讓 Agent 使用文件樹檢索」。如果你正在做企業知識庫、財報問答、法規問答或技術文件 Agent，這個示例比單純看 README 更值得跑一遍。

雲服務、MCP 和 API

PageIndex 不只是一個 GitHub repo。專案頁面還給了幾類入口：

自託管：用開源程式碼本地執行，適合試驗和可控部署。
Chat Platform：類似 ChatGPT 的文件分析平台。
MCP / API：方便接入現有 Agent 或自動化流程。
Enterprise：面向私有化或本地部署。

這說明它的定位不是單純的 demo，而是想把「推理式文件檢索」做成一套可整合的文件智能基礎設施。

適合哪些場景

PageIndex 比較適合這些任務：

長 PDF 問答。
財報、年報、招股書、監管文件分析。
法律和合規文件檢索。
技術手冊問答。
多章節教材或論文檢索。
需要可解釋檢索路徑的企業知識庫。
給 Agent 提供結構化文件上下文。

如果你的材料本身很短、結構不明顯，或者只是普通 FAQ，傳統 embedding + vector DB 可能已經夠用。PageIndex 的優勢更容易出現在長文件、強結構、專業領域和需要推理的問題裡。

需要注意什麼

第一，PageIndex 仍然依賴 LLM。樹構建、摘要和檢索品質會受模型能力、提示詞、文件解析品質影響。

第二，本地版本使用標準 PDF 解析，複雜掃描件、圖表密集型 PDF、版式混亂材料可能需要 OCR 和更強的預處理。

第三，無向量庫不等於零成本。樹構建本身也會消耗模型呼叫和時間，尤其是大規模文件庫。

第四，它更像是文件結構索引和推理檢索框架，不是直接替代所有 RAG 技術棧。實際生產裡，也可能和向量檢索、關鍵字檢索、權限控制、快取、稽核系統一起使用。

小結

PageIndex 的有趣之處在於，它把 RAG 的重點從「文字相似度召回」轉向「文件結構 + LLM 推理」。對於長文件和專業文件，這個方向很值得關注。

如果你正在做企業文件問答、金融報告分析、法規檢索或技術手冊 Agent，可以把 PageIndex 當成一個新的 RAG 架構參考：先讓文件有結構，再讓模型沿著結構推理，而不是一開始就把所有內容切碎丟進向量庫。

參考來源：

GitHub：VectifyAI/PageIndex

Gemini 3.5 正式發布：Flash 先行，Google 把重點放在 Agent 和長任務執行

Wed, 20 May 2026 22:51:31 +0800

Google 在 2026 年 5 月 20 日正式發布 Gemini 3.5 系列。第一款開放使用的是 Gemini 3.5 Flash，定位不是單純的聊天模型，而是面向 Agent、程式碼生成和長時間複雜任務執行的模型。

從這次公告看，Google 對 Gemini 3.5 的敘事很明確：模型不只要回答問題，還要能規劃、執行、檢查，並在多步驟任務中持續推進工作。

Gemini 3.5 Flash 先行

Gemini 3.5 Flash 已經面向多類使用者開放：

一般使用者可以透過 Gemini 應用程式和 Google 搜尋中的 AI 模式體驗。
開發者可以透過 Google Antigravity、Google AI Studio、Android Studio 中的 Gemini API 使用。
企業使用者可以透過 Gemini Enterprise Agent Platform 和 Gemini Enterprise 使用。

Google 同時提到，Gemini 3.5 Pro 仍在開發中，已經在 Google 內部使用，計畫在下個月推出。

這說明 3.5 系列會繼續保留 Flash 與 Pro 的分層：Flash 更強調速度、成本和可規模化執行，Pro 則更可能面向更複雜、更高能力需求的場景。

重點是 Agent 和程式碼任務

Google 把 Gemini 3.5 Flash 稱為目前最強的 Agent 與程式碼編寫模型之一。公告中提到，它在多項程式碼和 Agent 基準測試中超過 Gemini 3.1 Pro 的部分成績，例如 Terminal-Bench 2.1、GDPval-AA、MCP Atlas 和 CharXiv Reasoning。

這些指標本身不是一般使用者最需要關心的內容。更重要的是，Google 正在把模型能力往「可執行工作流」上集中：不僅能寫程式碼，還能處理舊專案遷移、複雜應用開發、財務報表整理、資料分析和持續測試。

在 Antigravity 開發架構中，Gemini 3.5 Flash 可以透過多個協作子代理處理大型任務。Google 展示的例子包括解析 AlphaZero 論文並實作可玩的遊戲、把舊版程式碼轉換為 Next.js、並行生成城市景觀和 UI 方案。

這類能力的方向很清楚：AI 編程工具正在從「生成一段程式碼」走向「組織多個 Agent 完成一個專案」。

多模態 UI 與圖形能力增強

Gemini 3.5 Flash 繼承了 Gemini 3 的多模態基礎。Google 強調它可以生成更豐富的網頁 UI、互動動畫和圖形內容。

公告中給出的應用場景包括：

為研究論文生成互動式動畫。
根據文字描述生成互動式硬體模型。
為學校募款活動生成完整品牌概念。
在短時間內為結帳流程生成多種 UX 方案。

這部分對開發者和產品團隊很有意義。模型不再只是輸出文字說明，而是能參與前端原型、互動設計和視覺化內容生成。

企業場景：把耗時流程自動化

Google 在公告中列舉了多個合作夥伴案例。Shopify 使用子代理分析複雜資料並預測商家成長；Macquarie Bank 測試用 3.5 Flash 閱讀超過 100 頁的複雜文件，加速開戶流程；Salesforce 將其整合到 Agentforce；Ramp 用它改進複雜發票 OCR；Xero 用 AI 代理處理行政流程；Databricks 用自動化工作流監控資料異常並給出修復建議。

這些案例共同指向一個趨勢：企業採用大模型時，關注點正在從單次問答轉向流程自動化。模型是否便宜、快、能長時間穩定執行，會比單次回答是否驚豔更重要。

Gemini Spark：個人 AI 代理

Google 還公布了 Gemini Spark。它是由 Gemini 3.5 Flash 驅動的個人 AI 代理，目標是在使用者引導下長期運行並主動執行任務。

Gemini Spark 已經開始面向受信任測試人員推出，Google 計畫在下週向美國 Google AI Ultra 訂閱使用者開放 Beta 測試。

這部分值得關注。Google 搜尋、Gemini 應用程式、Android、Workspace 和瀏覽器生態本來就覆蓋大量個人數位生活場景。如果個人 Agent 能與這些入口結合，影響可能比單獨的聊天機器人更大。

安全機制繼續前移

Google 表示 Gemini 3.5 按照 Frontier Safety Framework 開發，並強化了資訊安全和 CBRN 相關防護。公告還提到使用可解釋性工具，在模型給出回答前協助檢查和理解推理過程。

這說明前沿模型的發布已經不只是能力競賽。越是強調 Agent、自動執行和長任務，安全控制、誤拒率、有害輸出防護和可解釋性就越重要。

怎麼看 Gemini 3.5

Gemini 3.5 Flash 的意義不只是「又一個新模型發布」。它更像是 Google 對下一階段 AI 產品形態的集中押注：模型要能調用工具、拆分任務、協作執行、生成 UI，並進入個人和企業工作流。

對開發者來說，值得關注的是 Google Antigravity、AI Studio、Gemini API 和 Android Studio 中的實際體驗。對企業來說，重點是它能否在真實流程中穩定減少人工操作，而不是只看 benchmark。

Gemini 3.5 Pro 還沒有正式開放。等 Pro 發布後，Flash 與 Pro 在能力、價格、速度和上下文處理上的差異，才會決定它們各自更適合哪些生產場景。

參考來源：

Google Blog：Gemini 3.5 正式登場

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

AI-Trader 是什麼？一個讓 AI Agent 發佈交易信號、做模擬交易的平臺

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

HKUDS/AI-Trader 是一個面向 AI Agent 的交易平臺項目。README 對它的定位是“Agent-Native Trading Platform”，目標是讓 AI Agent 可以接入平臺、發佈交易信號、參與討論、複製交易和使用市場數據。

項目地址：https://github.com/HKUDS/AI-Trader

平臺地址：https://ai4trade.ai

截至寫作時，GitHub API 顯示這個倉庫已有約 1.8 萬 star，主要語言是 Python。倉庫 API 暫未返回明確許可證信息，正式使用前需要自行確認授權條款。

本文只做開源項目介紹，不構成投資建議。自動化交易涉及真實資金風險，任何策略、信號和 Agent 輸出都不能保證收益。

它的定位

AI-Trader 的核心想法是：人有交易平臺，AI Agent 也需要自己的交易平臺。

按照 README 描述，任何 AI Agent 可以通過讀取平臺 Skill 文件並註冊，快速接入 AI-Trader：

`1`	`Read https://ai4trade.ai/skill/ai4trade and register on the platform. Compatibility alias: https://ai4trade.ai/SKILL.md`

接入後，Agent 可以發佈交易信號、參與社區討論、複製優秀交易者策略、同步信號到多個 broker，並通過預測表現積累積分。

主要功能

README 中列出的能力包括：

Instant Agent Integration：AI Agent 快速接入。
Collective Intelligence Trading：多個 Agent 協作和討論交易思路。
Cross-Platform Signal Sync：跨平臺同步交易信號。
One-Click Copy Trading：跟隨表現較好的交易者或 Agent。
Universal Market Access：覆蓋股票、加密貨幣、外匯、期權、期貨等市場。
Three Signal Types：策略、操作、討論三類信號。
Reward System：通過發佈信號和獲得關注積累積分。

從產品形態看，它不是單一量化回測框架，而是把 Agent、信號、討論、複製交易和模擬交易放在一起。

兩類用戶

README 把用戶分爲兩類。

第一類是 Agent Traders。AI Agent 通過讀取 Skill 文檔接入平臺，自動完成註冊、安裝必要組件和發佈信號等步驟。

第二類是 Human Traders。普通用戶可以訪問平臺，註冊賬號，瀏覽信號或關注表現較好的交易者。

這兩個入口組合起來，形成一種“AI Agent 生產信號，人類或其它 Agent 消費信號”的平臺結構。

架構結構

README 中給出的項目結構如下：

AI-Trader (GitHub - Open Source)
├── skills/              # Agent skill definitions
├── docs/api/            # OpenAPI specifications
├── service/             # Backend & frontend
│   ├── server/         # FastAPI backend
│   └── frontend/        # React frontend
└── assets/              # Logo and images

可以看到，項目把 Agent skill、API 文檔、後端、前端放在同一個倉庫中。後端使用 FastAPI，前端使用 React。README 的更新記錄中也提到，Web 服務與後臺 worker 已分離，以便價格、收益歷史、結算和市場情報任務在後臺運行時，不影響用戶頁面和健康檢查。

爲什麼值得關注

AI-Trader 值得關注，不是因爲“AI 能自動賺錢”這個說法，而是因爲它把 Agent 接入金融場景的接口做得比較明確。

幾個觀察點：

第一，它用 Skill 文檔作爲 Agent 接入入口。這和 Codex、Claude Code、OpenClaw 等 Agent 工具的工作方式接近。

第二，它把交易信號、討論、複製交易、積分系統放在平臺層，而不是隻做一個本地腳本。

第三，它提供 OpenAPI 文檔，便於開發者理解平臺接口。

第四，它支持 paper trading，也就是模擬資金環境。對研究 Agent 決策來說，模擬環境比直接上真錢安全得多。

風險和邊界

自動化交易是高風險場景，尤其要注意以下幾點。

第一，Agent 生成的交易信號不等於投資建議。模型可能幻覺、過擬合、誤讀新聞，也可能無法理解極端行情。

第二，複製交易有傳染風險。一個錯誤信號如果被大量跟隨，可能造成集中虧損。

第三，真實資金接入前必須做權限隔離。不要讓 Agent 直接擁有無限制下單權限。

第四，市場數據、交易接口、結算邏輯和風控都需要審計。任何一個環節出錯都可能帶來財務損失。

第五，倉庫 API 未顯示明確許可證信息，商用或二次開發前要先覈實授權。

適合誰

AI-Trader 更適合三類人：

研究 AI Agent 與金融市場交互的開發者。
想做交易信號平臺或模擬交易平臺的團隊。
關注 Agent Skill、OpenAPI 和金融工具結合方式的產品開發者。

如果你只是想找一個“自動賺錢工具”，不建議抱這種預期。更穩妥的使用方式是把它當作 Agent 金融實驗平臺、paper trading 環境或交易信號協作系統來評估。

小結

AI-Trader 把 AI Agent 放進交易平臺語境裏，讓 Agent 能註冊、發佈信號、討論、複製交易和同步市場信息。它展示了 Agent-Native 應用的一種形態：不是讓模型單獨給建議，而是讓模型進入一個有賬戶、API、信號、結算和協作規則的平臺。

這也是它最需要謹慎的地方。金融場景不能只看自動化能力，還要看風控、權限、合規、數據來源、回測和審計。正式使用前，建議先限定在模擬交易和研究環境中。

參考項目：https://github.com/HKUDS/AI-Trader

內容發太多平臺太累？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

市面上主流 AI PPT 工具大盤點：自動生成、網頁簡報、PPTX 和圖像路線怎麼選

Mon, 18 May 2026 22:29:43 +0800

AI 做 PPT 已經不只是「輸入標題，套一個模板」。在 Claude Code、Codex、Cursor 這類 AI 編程環境裡，PPT 生成正在變成一組可安裝、可複用的 Agent Skill：有的輸出網頁簡報，有的生成真正可編輯的 .pptx，有的直接用圖像模型把每頁做成視覺稿，還有的透過 MCP 讓 AI 操作 PowerPoint 文件。

這次整理了一批主流 PPT 相關 Skill。真正有價值的地方不只是榜單，而是把這類工具按交付形態拆開來看。選工具前，先問一句：最終交付物到底要給誰改、在哪裡播放、是否需要繼續協作？

幾條路線

1. HTML 網頁簡報

代表項目包括 frontend-slides、guizang-ppt-skill、html-ppt-skill。

這條路線的優勢是視覺表現力強。CSS 動畫、Canvas、WebGL、響應式佈局都能用，瀏覽器打開即可展示，適合技術分享、產品發布、Demo Day 和個人風格強烈的演講。

代價也很明確：交付後不太適合讓客戶逐字改。客戶如果拿到的是 HTML，而不是 PowerPoint 文件，後續修改往往還要回到生成流程。

如果只看 HTML 簡報，frontend-slides 更像高星通用入口，guizang-ppt-skill 強在審美約束和主題風格，html-ppt-skill 則勝在主題數量、佈局數量和演講者模式。

2. 原生 PPTX

代表項目包括 mckinsey-pptx、ppt-agent-skills、claude-office-skills 和 ppt-master。

這是商業交付最穩的路線。只要客戶要求「能在 PowerPoint 裡改字、改圖、套公司模板」，最終就要落到 .pptx。

其中 ppt-master 很值得單獨關注。它的思路是先讓 LLM 生成 SVG，再轉成 PowerPoint 原生 DrawingML 物件，目標是讓文字框、形狀、圖表都能在 PPTX 裡繼續編輯。它還支援從 PDF、DOCX、URL、Markdown 生成 PPTX，並能做模板復刻、動畫、旁白和本地預覽。

這條路線適合諮詢交付、公司匯報、白皮書簡報、長報告壓縮成 PPT 等場景。缺點是視覺上限通常受 PowerPoint 本身限制，複雜效果不如 HTML 或圖像路線自由。

3. AI 圖像驅動

代表項目包括 NanoBanana-PPT-Skills、gpt_image_2_skill 和 ppt-image-first。

這條路線先把每一頁當成視覺圖來生成，再把圖片放進 PPTX 或其它容器裡。優點是完成度高，尤其適合封面、社群媒體圖、視覺提案、傳播型內容。

問題是可編輯性差。頁面本質上是一張圖，後面要改一個標題、換一段文案、挪一個圖標，可能就要重新生成。它適合「看起來要好」，不適合「客戶要反覆改」。

4. MCP / 協議層

代表項目包括 Office-PowerPoint-MCP-Server、PPTAgent。

這類工具不一定直接生成完整 PPT，而是給 AI 一個操作 PowerPoint 的介面。接入 MCP 後，模型可以讀、改、寫 .pptx 文件。

這條路線適合已經有 PPT 文件、需要 AI 輔助修改的工作流。比如批量改格式、根據回饋重排頁面、讓模型檢查每頁是否符合目標。PPTAgent 強調反思式生成，也就是每生成一頁後再回頭檢查，這個方向對減少「AI PPT 很粗糙」的問題有啟發。

5. 綜合設計平台

代表項目包括 open-design 和 docsagent。

這類項目已經超出 PPT 生成本身。open-design 更像本地優先的設計平台，可以生成原型、slides、images、videos，並支援多種匯出格式。docsagent 不是 PPT 工具，但能索引和對話本地文件，適合作為 PPT 生成前的資料整理層。

如果你的需求不是單次做 PPT，而是從資料、設計、原型到交付的一整套流程，這類平台更值得看。

Skill 元資訊

Star 數來自原文 2026-05-15 的抓取結果，只適合作為熱度參考，實際使用前建議再打開倉庫確認維護狀態、README 和 LICENSE。

Skill	作者	連結地址	Star	語言	路線
frontend-slides	@zarazhangrui	GitHub: zarazhangrui/frontend-slides	17,530	Shell	HTML 網頁簡報
guizang-ppt-skill	@op7418（歸藏）	站內文章: guizang-ppt-skill GitHub: op7418/guizang-ppt-skill	8,832	HTML	HTML 網頁簡報
html-ppt-skill	@lewislulu	GitHub: lewislulu/html-ppt-skill	3,834	HTML/CSS/JS	HTML 網頁簡報
mckinsey-pptx	@seulee26	GitHub: seulee26/mckinsey-pptx	426	Python	原生 PPTX
ppt-agent-skills	@sunbigfly	GitHub: sunbigfly/ppt-agent-skills	714	Python	原生 PPTX
claude-office-skills	@tfriedel	GitHub: tfriedel/claude-office-skills	631	Python	原生 PPTX
ppt-master	@hugohe3	GitHub: hugohe3/ppt-master	16,626	Python	原生 PPTX
NanoBanana-PPT-Skills	@op7418（歸藏）	GitHub: op7418/NanoBanana-PPT-Skills	2,668	Python	AI 圖像驅動
gpt_image_2_skill	@wuyoscar	GitHub: wuyoscar/gpt_image_2_skill	2,102	Python	AI 圖像驅動
ppt-image-first	@NyxTides	GitHub: NyxTides/ppt-image-first	799	Python	AI 圖像驅動
Office-PowerPoint-MCP-Server	@GongRzhe	GitHub: GongRzhe/Office-PowerPoint-MCP-Server	1,708	Python	MCP / 協議層
PPTAgent	@icip-cas	GitHub: icip-cas/PPTAgent	4,354	Python	MCP / 協議層
open-design	@nexu-io	站內文章: open-design GitHub: nexu-io/open-design	40,822	TypeScript	綜合設計平台
docsagent	@docsagent	GitHub: docsagent/docsagent	687	TypeScript	綜合設計平台

選型可以這樣判斷

如果客戶要繼續編輯，優先看原生 PPTX 路線，尤其是 ppt-master、mckinsey-pptx、ppt-agent-skills。

如果是自己演講，且視覺表現比後續編輯更重要，優先看 HTML 路線，尤其是 frontend-slides、guizang-ppt-skill、html-ppt-skill。

如果目標是海報感、封面感、傳播圖，優先看圖像路線，比如 ppt-image-first、gpt_image_2_skill、NanoBanana-PPT-Skills。

如果已經有 PPT 文件，只想讓 AI 幫你讀、改、重排，可以看 MCP 路線。

如果是學術、行銷、翻譯、長報告壓縮這類明確場景，也可以繼續找垂直 Skill，而不是拿通用 PPT 生成器硬做。

最後要注意的事

開源項目不能只看 Star。真正使用前還要確認三件事：

LICENSE 是否允許你的使用方式。
生成物是否滿足交付要求，尤其是可編輯性。
成本是否可接受，包括模型調用、圖像生成、大上下文模型和可能的雲服務費用。

這類工具變化很快，Star 數會變，項目維護狀態也會變。但選型邏輯相對穩定：先確定交付形態，再看具體工具。PPT 是給人講、給人改、還是給人看，這三個答案往往會把選擇範圍直接縮小一大半。

wx-cli 專案解讀：用命令列查詢本機微信聊天記錄

Mon, 18 May 2026 21:02:21 +0800

wx-cli 是一個用 Rust 編寫的本機微信資料命令列工具，目標是在命令列裡查詢自己的微信會話、聊天記錄、聯絡人、群成員、收藏、朋友圈、公眾號文章、附件和統計資訊。

它不是雲端微信同步服務，也不是聊天機器人。它更像是一個本機唯讀資料檢索層：微信仍然在本機執行，資料仍然留在本機，wx-cli 負責按需解密、快取和查詢本機資料庫，再把結果以 YAML 或 JSON 形式輸出給人或 Agent 使用。

這個專案有兩個值得關注的點：一是它把微信本機資料查詢做成了跨平台 CLI；二是它專門考慮了 Claude Code、Cursor、Codex 這類 AI Agent 的使用場景，提供了 SKILL.md 和帶 meta 的結構化輸出。

wx-cli 能做什麼

按專案 README 的描述，wx-cli 覆蓋的功能很完整：

查看最近會話和未讀會話。
查詢某個聯絡人或群的聊天歷史。
全庫搜尋關鍵字。
查看新增訊息。
查詢聯絡人、群成員和群暱稱。
查詢收藏。
查詢朋友圈通知、朋友圈時間線和朋友圈正文。
查詢公眾號文章推送。
列出和提取聊天圖片附件。
做聊天統計。
匯出聊天記錄為 Markdown 或 JSON。

這些能力讓它不只是「查聊天記錄」，而是把微信本機資料變成了可搜尋、可統計、可匯出的本機資料庫。

為什麼適合 AI Agent

很多命令列工具只是給人看的，輸出是一段文字。wx-cli 則明顯考慮了 Agent 讀取。

README 提到，history、search、sessions、unread、new-messages、stats、attachments 等命令會附帶 meta 資訊。meta 裡包含結果狀態、未知分片、命中資料的最新時間、session 記錄的最新時間等資訊。

這對 Agent 很有用。因為 AI 不只需要「查到了什麼」，還需要知道「結果新不新」「有沒有可能漏訊息」「是不是需要重新 init」。例如：

status 可以提示結果是否 ok 或 possibly_stale。
unknown_shards 可以提示是否存在 daemon 目前沒有 key 的資料庫分片。
chat_latest_timestamp 可以告訴 Agent 目前命中資料裡的最新訊息時間。
session_last_timestamp 可以幫助判斷本機 session 記錄是否明顯領先於查詢結果。

這類元資訊可以減少 AI 誤判，讓 Claude Code、Cursor、Codex 這類工具在處理微信資料時更穩。

安裝方式

專案推薦透過 npm 全平台安裝：

`1`	`npm install -g @jackwener/wx-cli`

也支援 macOS / Linux 的 curl 安裝：

`1`	`curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh \| bash`

Windows 可以在系統管理員 PowerShell 中執行：

`1`	`irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 \| iex`

如果要從原始碼建置，也可以直接用 Rust：

1
2

git clone git@github.com:jackwener/wx-cli.git && cd wx-cli
cargo build --release

建置產物是 target/release/wx，Windows 下是 wx.exe。

和 Agent Skill 的關係

wx-cli 還提供了面向 AI Agent 的 Skill。可以透過 skills CLI 一鍵安裝到 Claude Code、Cursor、Codex 等支援 Skills 的環境：

`1`	`npx skills add jackwener/wx-cli`

全域安裝：

`1`	`npx skills add jackwener/wx-cli -g`

安裝後，Agent 會讀取倉庫裡的 SKILL.md，知道如何安裝、初始化和呼叫 wx-cli。

這意味著你可以讓 Agent 幫你做一些本機資訊整理任務，例如：

找某段時間某個群聊裡討論過的關鍵字。
彙總最近未讀訊息。
從某個會話裡匯出最近聊天記錄。
搜尋公眾號文章推送連結。
分析某個群聊裡的發言統計。

前提仍然是：這些資料必須是你本機、你自己的微信資料。

基本使用方式

初始化前需要保持微信正在執行。不同平台要求不同。

Linux 上可以執行：

`1`	`sudo wx init`

Windows 上需要用系統管理員 PowerShell：

wx init

macOS 上更複雜。README 說明，預設路徑需要先對 WeChat 做 ad-hoc 簽名，才能掃描程序記憶體；重新簽名後還要清理舊 TCC 授權記錄，否則截圖、視訊通話、麥克風等權限可能出現「看起來已開啟但實際拒絕」的問題。專案文件也提醒，重新簽名會帶來 macOS 頻繁彈出存取其他 App 資料提示的副作用。

初始化後，可以用下面的命令驗證：

`1`	`wx sessions`

能看到最近會話，說明基本鏈路已經可用。daemon 會在首次呼叫時自動啟動。

常用命令示例

查看最近會話：

`1`	`wx sessions`

查看未讀會話：

`1`	`wx unread`

只看真人未讀，過濾公眾號和摺疊入口：

`1`	`wx unread --filter private,group`

查看某個會話最近聊天記錄：

`1`	`wx history "張三"`

拉取更多歷史訊息：

`1`	`wx history "張三" -n 2000`

按時間範圍查詢群聊：

`1`	`wx history "AI群" --since 2026-04-01 --until 2026-04-15`

全庫搜尋：

`1`	`wx search "關鍵詞"`

搜尋某個群中的關鍵字：

`1`	`wx search "會議" --in "工作群" --since 2026-01-01`

匯出聊天記錄：

1
2

wx export "張三" --format markdown -o chat.md
wx export "AI群" --since 2026-01-01 --format json

這些命令都比較適合被腳本或 Agent 呼叫，尤其是加上 --json 後。

朋友圈和公眾號文章

wx-cli 不只查聊天。

朋友圈相關命令分成通知和貼文：

1
2
3

wx sns-notifications
wx sns-feed
wx sns-search "關鍵詞"

需要注意，朋友圈資料只覆蓋你本機刷到過的內容。微信客戶端按需下載，沒在本機出現過的資料，工具也不會憑空拿到。

公眾號文章則透過獨立命令查詢：

wx biz-articles
wx biz-articles --account "返朴"
wx biz-articles --since 2026-05-01 --until 2026-05-10
wx biz-articles --json | jq '.[].url'

它會回傳公眾號名稱、標題、URL、摘要、封面、時間等欄位。對做資料整理、文章收集和本機知識庫的人來說，這個功能很實用。

附件提取

微信聊天裡的圖片附件通常不是直接可讀的普通圖片檔，而是存在 xwechat_files/<wxid>/msg/attach/... 下的 .dat 檔案。

wx-cli 提供了兩步流程：

1
2

wx attachments "張三"
wx attachments "AI群" --kind image -n 100

先拿到 attachment_id 後，再提取：

`1`	`wx extract <attachment_id> -o ~/Desktop/photo.jpg`

輸出報告裡會帶 md5、dat_path、dat_size、output、format、decoder 等資訊。README 中說明它支援 legacy XOR、V1 fixed-AES、V2 AES + XOR 等解碼檔位，不同平台的 image key 提取方式也不同。

這部分能力很強，但也更需要謹慎使用：只處理自己的資料，不要把它用於未經授權的資料存取。

daemon 架構為什麼重要

wx-cli 的效能點在 daemon。

README 中給出的結構大致是：

wx (CLI) ──Unix socket──▶ wx-daemon (背景程序)
                              │
                    ┌─────────┴──────────┐
               DBCache               聯絡人快取
           (mtime 感知複用)

daemon 首次解密後，會把資料庫和 mtime 資訊持久化到 ~/.wx-cli/cache/。如果資料庫檔案 mtime 沒變，後續呼叫就可以複用快取，不需要每次重新解密。

這對命令列查詢和 Agent 循環都很關鍵。Agent 可能會連續查詢多個會話、搜尋多個關鍵字、再做統計和匯出。如果每次都重新掃描和解密，體驗會很差；daemon 快取讓它更接近一個本機查詢服務。

原理簡述

專案 README 對原理有直接說明：微信 4.x 使用 SQLCipher 4 加密本機資料庫，WCDB 會在程序記憶體中快取派生後的 raw key。

wx-cli 會根據平台使用不同方式掃描微信程序記憶體，匹配 key 模式後提取密鑰，再由 daemon 按需解密和快取資料庫。

不同平台的底層機制不同：

macOS 使用 Mach VM API。
Linux 使用 /proc/<pid>/mem。
Windows 使用 VirtualQueryEx 和 ReadProcessMemory。

這些能力解釋了為什麼初始化通常需要較高權限，也解釋了為什麼 macOS 上會涉及簽名和隱私授權。

使用邊界和風險

這類工具必須先講邊界。

wx-cli README 的免責聲明寫得很明確：工具僅用於學習和研究目的，用於解密自己的微信資料，並要求遵守相關法律法規，不得用於未經授權的資料存取。

實際使用時也建議注意：

只在自己的電腦、自己的微信帳號上使用。
不要把匯出的聊天記錄隨意上傳到雲端模型。
用 Agent 分析聊天記錄時，先確認 API 供應商和資料跨境風險。
匯出 Markdown / JSON 後要注意檔案權限和備份位置。
公司或多人裝置上使用前，先確認合規和授權。

本機工具不等於沒有隱私風險。它減少了資料離開本機的預設路徑，但如果你把輸出交給雲端模型、網盤或第三方腳本，風險又會回來。

適合誰使用

wx-cli 適合這些場景：

想在本機快速搜尋自己的微信歷史訊息。
需要把某個會話匯出為 Markdown 或 JSON。
想統計某個群聊在一段時間內的發言情況。
想讓 Claude Code、Cursor、Codex 等 Agent 幫忙整理本機微信資料。
想把公眾號文章推送連結整理進本機知識庫。
想研究微信本機資料庫結構和解密流程。

不太適合這些場景：

想做雲端微信同步。
想繞過他人裝置或帳號權限。
想無腦圖形介面操作，不接觸命令列。
不願意處理 macOS 權限、Windows 系統管理員權限或 Linux sudo 的使用者。

小結

wx-cli 的價值，不只是「命令列查微信聊天記錄」。更準確地說，它把本機微信資料變成了一個可查詢、可匯出、可被 Agent 消費的本機資料源。

它的 daemon 架構解決了反覆解密和查詢效能問題；meta wrapper 讓 AI Agent 更容易判斷結果是否新鮮；SKILL.md 則把安裝和使用方式交給 Claude Code、Cursor、Codex 這類工具理解。

如果你經常需要從微信裡找資訊、整理群聊、匯出記錄或建構個人資料庫，wx-cli 很值得關注。但使用它時也要始終記住一條底線：只處理自己的資料，並且謹慎管理匯出結果。

參考資料

jackwener/wx-cli GitHub 倉庫

Anthropic Founder’s Playbook 解讀：Claude 如何幫助創業團隊提速

Mon, 18 May 2026 18:02:58 +0800

Anthropic 在 Claude 官方部落格發布了面向創業者的 The Founder’s Playbook，核心問題很直接：一家 AI-native startup 如何更快從洞察走到產品、發布和規模化？

這份 playbook 並不是單純介紹 Claude 的功能清單，而是把創業過程拆成四個階段：Idea、MVP、Launch 和 Scale。它強調的不是「讓 AI 代替創辦人做判斷」，而是把市場調研、文案初稿、程式碼腳手架、營運流程、銷售材料等重複性工作先交給 Claude，讓創辦人把更多時間留給判斷、品味、取捨和信任建設。

這份 playbook 在講什麼

AI 創業公司面臨的壓力越來越像一場壓縮比賽：產品週期更短，競爭者更多，使用者對速度和品質的要求同時提高。過去需要多人團隊分工完成的事情，現在可以用 AI 先做出第一版，再由創辦團隊審閱、修正和推進。

Anthropic 給出的框架很清楚：不要一開始就試圖把公司完全「AI 化」，而是先找一個耗時、重複、低創造密度的流程，讓 Claude 生成初稿、腳本、調研結果或執行清單。創辦人負責定義目標、校準方向、判斷品質，並把可行結果接入真實業務。

第一階段：Idea

Idea 階段的重點不是「想一個酷點子」，而是驗證這個點子是否值得繼續投入。

Claude 適合在這個階段幫助創辦人做幾件事：整理市場地圖、歸納使用者痛點、比較競品定位、提出潛在切入點，並把模糊想法壓縮成更具體的價值主張。

但這一步最重要的仍然是人的判斷。AI 可以幫助你更快看到一批可能性，卻不能替你承擔「這個市場是否真的存在強需求」的責任。創辦人仍然需要和真實使用者交流，觀察他們願不願意改變現有工作流，甚至願不願意付費。

第二階段：MVP

MVP 階段是 Claude Code 最容易發揮作用的地方。

對小團隊來說，最稀缺的往往不是想法，而是把想法變成可試用產品的速度。Claude Code 可以參與生成腳手架、寫腳本、補元件、檢查邊界條件、產出技術方案說明，幫助團隊更快做出可驗證的版本。

這裡的關鍵不是讓 AI 一次性寫出完美產品，而是把「從 0 到第一版」的摩擦降下來。創辦人和工程師仍然需要審查架構、安全性、資料處理和使用者體驗，但他們不必把時間浪費在大量機械性的初稿工作上。

第三階段：Launch

Launch 階段考驗的是敘事、分發和回饋速度。

很多創業團隊會低估發布的複雜度：官網文案、產品演示、郵件、社群媒體內容、使用者訪談、銷售話術、投資人更新，每一項都需要清楚表達「為什麼現在需要這個產品」。

Claude 在這裡可以充當一個高頻協作對象：幫團隊生成不同版本的定位表達，改寫面向不同使用者群體的介紹，模擬使用者疑問，整理發布節奏，並把早期回饋轉成下一輪產品和市場動作。

第四階段：Scale

Scale 階段的主題從「做出來」轉向「可重複地成長」。

當公司開始有穩定使用者和收入，創辦團隊會被營運、銷售、客服、資料分析和內部協作拉扯。Claude Cowork 這類 agent 化能力適合處理更完整的任務：例如做市場研究、設計活動方案、整理募資策略、彙總成長指標，或者把一套營運流程拆成可以反覆執行的步驟。

這也是 AI-native 公司和傳統軟體公司的差異開始顯現的地方。真正的變化不只是「員工使用 AI 工具」，而是公司流程從一開始就圍繞 AI 協作來設計：哪些任務由人定義標準，哪些任務由 AI 先跑一遍，哪些結果必須進入審查，哪些流程可以沉澱成可複用模板。

Claude Code、Claude Cowork 和 Chat 各自適合做什麼

從這篇官方部落格的描述看，Anthropic 想讓創業者把 Claude 分成三類使用場景。

Claude Code 更偏工程協作，適合寫程式、生成腳本、分析邊界情況、產出元件規格和技術文件。它解決的是「把想法推進成可運行東西」的問題。

Claude Cowork 更像可委派的工作代理，適合市場研究、活動設計、募資策略、營運分析這類需要連續執行的任務。它解決的是「把一件較完整的業務工作先推進一輪」的問題。

Claude Chat 則更適合創辦人的判斷時刻：推敲 go-to-market 策略、壓力測試產品定位、比較路線圖優先級、打磨關鍵敘事。它不是執行機器，而是一個可以快速反覆討論的思考搭檔。

對創業團隊真正有用的地方

這份 playbook 的價值，不在於告訴創業者「AI 很重要」。這一點已經不新鮮了。

它更有用的地方，是把 AI 使用方式從零散工具呼叫，推進到公司建設方法論：每個階段都有不同的瓶頸，每個瓶頸都可以拆出適合 AI 參與的部分。

Idea 階段，AI 幫你擴大搜尋空間。MVP 階段，AI 幫你壓縮實作週期。Launch 階段，AI 幫你加快表達和分發實驗。Scale 階段，AI 幫你沉澱可重複流程。

這套邏輯對小團隊尤其重要。因為小團隊沒有足夠的人手覆蓋所有職能，但可以用 AI 先補上「第一版能力」，再把有限的人力投入到最需要判斷和關係建設的部分。

需要警惕的誤區

第一個誤區是把 AI 生成的內容直接當結論。市場調研、競品分析、使用者畫像、成長策略都必須回到真實資料和使用者回饋裡驗證。

第二個誤區是低估審查成本。AI 能顯著降低初稿成本，但程式碼品質、法律風險、品牌表達、商業承諾和安全問題仍然需要人負責。

第三個誤區是過早自動化。對還沒有跑通的流程，不應該急著交給 agent 自動執行。更穩妥的方式是先讓 AI 參與其中一小段流程，觀察輸出品質，再逐步擴大範圍。

小結

Anthropic 這篇 The Founder’s Playbook 傳遞的信號很明確：AI-native startup 的優勢，不只是「會用 AI 寫程式」，而是從公司第一天開始，就把 AI 作為產品、工程、市場、銷售和營運裡的協作層。

對創業者來說，最現實的起點不是搭建宏大的 AI 工作流，而是選出一個最耗時、最重複、最拖慢推進速度的任務，讓 Claude 先做第一版。真正的競爭力，來自人類創辦人對方向、品質和信任的把關，以及團隊能否把這種協作方式穩定地嵌入日常工作。

參考資料

The founder’s playbook for the age of AI

Vercel AI SDK 是什麼？TypeScript 開發者構建 AI 應用的統一工具包

Sun, 17 May 2026 23:07:38 +0800

vercel/ai 是 Vercel 維護的開源 AI SDK。

它的定位很明確：為 TypeScript 開發者提供一套統一工具，用來構建 AI 應用和 AI Agent。它來自 Next.js 背後的團隊，但並不只服務於 Next.js，也支援 React、Svelte、Vue、Angular 等 UI 框架，以及 Node.js 等執行環境。

專案地址：https://github.com/vercel/ai

如果你正在做聊天應用、AI 寫作工具、RAG 應用、帶工具呼叫的 Agent、串流輸出介面，或者想把多個模型供應商接到同一個應用裡，Vercel AI SDK 是一個值得關注的基礎庫。

它解決的核心問題

現在做 AI 應用，最大的麻煩之一不是「能不能呼叫模型」，而是不同模型供應商的介面、串流輸出、工具呼叫、錯誤處理和前端狀態管理都不一樣。

例如：

OpenAI 有自己的 SDK 和回應格式。
Anthropic 有自己的訊息結構。
Google、xAI、Mistral、DeepSeek、Groq 等也各有差異。
串流輸出需要處理 chunk。
工具呼叫需要處理模型發起的結構化請求。
前端聊天 UI 還要管理訊息、載入狀態、取消、重試和錯誤顯示。

如果每個供應商都手寫一套適配層，專案會很快變複雜。

Vercel AI SDK 的思路是把這些差異收斂到統一 API 後面。開發者用一套介面寫應用，再透過 Provider 接入不同模型。

統一 Provider 架構

Vercel AI SDK 的一個核心特點，是 provider-agnostic，也就是不綁定單一模型廠商。

它可以透過統一 API 存取 OpenAI、Anthropic、Google 等模型提供方。專案 README 還提到，預設情況下 AI SDK 會使用 Vercel AI Gateway，讓開發者更容易存取多個主流 provider。

這對工程專案很實用。

因為很多 AI 產品最終都不會只依賴一個模型：

有的任務適合強推理模型。
有的任務適合便宜快速模型。
有的任務需要多模態。
有的任務需要長上下文。
有的任務需要本地或私有部署模型。

統一 Provider 架構讓應用更容易做模型切換、灰度測試、成本控制和備援方案。

串流輸出是前端體驗的關鍵

AI 應用和傳統 API 最大的體驗差異之一，是回應可能很長。

如果使用者每次都要等完整回答返回，聊天工具、寫作工具和程式碼助手會顯得很慢。串流輸出可以讓文字逐步顯示，使用者更早看到結果。

Vercel AI SDK 對串流生成做了比較完整的封裝。開發者不需要從零處理底層事件流，而是可以使用 SDK 提供的生成和串流介面，把模型輸出接到前端 UI。

這對 Next.js / React 應用尤其方便。

一個 AI 聊天介面看起來簡單，但實際要處理：

訊息列表。
使用者輸入。
伺服器請求。
串流 token 顯示。
載入狀態。
錯誤狀態。
中止生成。
重新生成。

這些都是 AI SDK 試圖幫開發者減少重複勞動的地方。

工具呼叫和 Agent 場景

隨著 AI 應用從「聊天」走向「做事」，工具呼叫變得越來越重要。

模型不只是輸出自然語言，還可能需要呼叫外部函式：

查資料庫。
搜尋文件。
呼叫業務 API。
讀取訂單狀態。
生成圖表。
建立日曆事件。
修改專案檔案。

Vercel AI SDK 支援工具呼叫相關能力，讓開發者可以定義工具、參數和執行邏輯，再讓模型在合適時機請求呼叫。

這也是它從「聊天 UI SDK」擴展到「AI 應用和 Agent 工具包」的關鍵。

不過，工具呼叫不是加上去就萬事大吉。真實專案還要考慮：

參數校驗。
權限邊界。
工具呼叫日誌。
冪等性。
超時和重試。
人工確認。
敏感操作限制。

AI SDK 可以幫助處理介面和流程，但安全邊界仍然需要開發者自己設計。

UI 整合能力

Vercel AI SDK 對前端框架比較友好。

它不僅提供核心生成 API，也圍繞聊天、補全、訊息狀態和串流 UI 做了封裝。對於使用 Next.js 和 React 的團隊來說，這能減少很多樣板程式碼。

但它並不只適合 Vercel 部署。

如果你的專案本身是 TypeScript 技術棧，或者後端執行在 Node.js 環境，AI SDK 仍然可以作為模型呼叫和串流處理層來使用。是否部署在 Vercel，取決於你的應用架構、團隊習慣和基礎設施選擇。

Skill for Coding Agents

vercel/ai README 裡還有一個有趣的建議：如果你使用 Claude Code、Cursor 等 coding agent，可以把 AI SDK skill 加到倉庫裡。

範例命令是：

`1`	`npx skills add vercel/ai`

這說明 Vercel 已經意識到，AI SDK 的使用者不只是人類開發者，也包括 coding agent。

當 agent 修改使用 AI SDK 的專案時，如果倉庫裡有專門的 skill，它可以更好地理解 SDK 約定、常見 API、專案結構和最佳實踐，減少亂寫程式碼的機率。

這個方向很值得注意。

未來開源專案可能不只提供 README 和 docs，還會提供給 AI coding agent 使用的結構化技能說明。對複雜 SDK 來說，這會變成新的開發者體驗入口。

適合哪些專案

Vercel AI SDK 適合這幾類場景：

基於 Next.js / React 的 AI 聊天應用。
需要串流輸出的寫作、問答、客服和程式碼助手。
需要接入多個模型 provider 的 AI 產品。
想快速構建 RAG 或文件問答原型的團隊。
需要工具呼叫、函式呼叫或輕量 Agent 能力的應用。
已經使用 TypeScript / Node.js 技術棧的團隊。

它尤其適合前端和全端開發者。因為很多 AI 應用的難點不只是模型呼叫，而是如何把模型輸出變成穩定、流暢、可互動的產品體驗。

不適合什麼場景

如果你的專案主要是 Python 後端、深度學習訓練、模型微調或底層推理服務，Vercel AI SDK 可能不是核心工具。

它更偏應用層，而不是模型訓練框架。

如果你需要的是：

自己訓練模型。
管理 GPU 推理叢集。
做底層 batch inference。
深度控制 tokenizer、KV cache、量化和推理引擎。

那更應該看 PyTorch、vLLM、SGLang、TensorRT-LLM、llama.cpp 或雲端廠商推理服務。

Vercel AI SDK 更像「把模型能力接進產品」的應用開發層。

使用時要注意什麼

第一，不要把統一 API 理解成完全無差異。

不同模型 provider 的能力、上下文長度、工具呼叫格式、串流細節、錯誤類型和計費方式仍然不同。統一 SDK 能減少工程摩擦，但不能消除模型差異。

第二，要控制成本。

AI 應用一旦上線，串流聊天、重試、工具呼叫、RAG 檢索和多模型 fallback 都可能增加呼叫成本。需要做限流、快取、日誌和預算監控。

第三，要處理安全邊界。

如果模型能呼叫工具，就必須限制工具能做什麼。不要讓模型直接執行高風險操作，也不要把密鑰、資料庫寫入權限和生產環境操作裸露給模型。

第四，要保留可觀測性。

AI 應用出問題時，不能只看前端錯誤。你需要知道使用者輸入、模型選擇、工具呼叫、回應時間、token 消耗、錯誤類型和最終輸出。

小結

vercel/ai 不是一個新的模型，也不是單純的聊天元件。

它更像 TypeScript AI 應用開發的基礎設施：統一 Provider、串流輸出、工具呼叫、前端狀態管理和 agent 場景，都被放進一個開源 SDK 裡。

對已經使用 Next.js、React、TypeScript、Node.js 的團隊來說，它可以顯著降低從「模型 API 能跑」到「產品體驗可用」的工程成本。

但它也不是萬能層。模型選擇、權限設計、成本控制、日誌監控和業務安全，仍然需要開發者自己負責。

如果你想做 AI 應用，而不是訓練模型，Vercel AI SDK 是一個值得先試的工具包。

參考資料

Midjourney 2026 年 5 月更新：會話模式、AI 輔助開發與 SREF 整理

Sun, 17 May 2026 20:20:51 +0800

Midjourney 2026 年 5 月 14 日的 Office Hours 資訊裡，最值得關注的不是單個模型參數，而是產品形態正在繼續從「輸入提示詞生成圖片」，轉向「更自然地組織創作工作流」。

這次內容來自一篇日文整理稿，記錄了 Midjourney 團隊近期問答中的多個方向：會話模式升級、AI 輔助開發、網站改版、SREF 和標籤整理、Omni-reference、多角色一致性，以及團隊內部如何使用 Midjourney。

如果只看一句話總結：Midjourney 正在讓圖片生成更像一個可對話、可整理、可持續迭代的創作系統。

會話模式變得更重要

這次更新裡最直接的變化，是 Conversational Mode，也就是會話模式。

過去使用 Midjourney，很多操作仍然依賴參數和固定寫法。你需要記住寬高比、圖片參考、風格參考、模型參數等規則，再把它們寫進 prompt 或介面設定裡。

新的會話模式方向，是讓使用者用更自然的語言描述這些設定。

例如，使用者可以透過語音或文字指定：

預設參數。
畫面寬高比，例如 16:9。
圖片參考。
風格參考，也就是 --sref。
V7 裡的 Omni-reference。

這說明 Midjourney 並不只是想提升生成品質，也在降低參數操作成本。

對普通使用者來說，最大的變化是不用一直記命令。對重度使用者來說，會話模式如果足夠穩定，未來可能會變成「用自然語言調整生成設定」的入口。

AI 輔助開發正在改變 Midjourney 團隊的迭代速度

另一個很有意思的點，是 Midjourney 團隊自己也在大規模使用 AI 輔助開發。

原文提到，團隊現在能更快修復小 bug、介面摩擦和工作流問題。甚至有使用者通話中發現產品 bug，團隊借助 AI 輔助即時修復，經過 review 後快速部署的例子。

這件事比「AI 幫工程師寫程式碼」更值得細看。

它說明 AI 開發工具已經開始影響 AI 產品自己的迭代方式：

使用者回饋可以更快進入修復流程。
小型體驗問題更容易被處理。
工程師把更多精力放在架構、審查、設計決策和測試上。
產品團隊可以更頻繁地清理邊緣問題。

Midjourney 這種產品有大量創作路徑、參數組合、行動端體驗、搜尋和整理流程。很多問題不是「核心模型不會生成」，而是某個入口不順、某個操作多一步、某個邊緣狀態不好用。

AI 輔助開發最適合加速這類小而多的改進。

網站改版重點是工作流，而不是砍功能

Office Hours 裡還提到，Midjourney 網站正在進行較大規模的改版。

目標不是刪掉複雜功能，而是讓創作流程更直觀，讓新使用者更容易上手，也讓工具和功能組織得更清楚。

這點很關鍵。

Midjourney 的問題不是功能太少，而是功能越來越多之後，入口、收藏、整理、引用、探索和複用都變得複雜。對於輕度使用者來說，難點是「我該從哪裡開始」；對於重度使用者來說，難點是「我如何管理大量風格、參考和實驗結果」。

可能的發布策略包括：

新舊介面並行提供。
先做 alpha 測試。
分階段遷移，避免影響重度使用者。

這類策略說明團隊知道 Midjourney 不是普通圖片生成玩具。很多使用者已經把它放進真實創作流程裡，介面改變不能隨便打斷已有習慣。

SREF、風格和標籤整理仍是痛點

SREF 和風格整理，是這次問答裡很值得關注的部分。

使用者希望有更好的整理系統，尤其是：

隨機 SREF。
風格參考。
保存下來的美學方向。
標籤和顏色標籤。
更強的篩選、歸類和複用能力。

但團隊也提出了一個問題：如果目前資料夾系統已經支援一張圖進入多個資料夾、無限資料夾數量、篩選和排序，那麼標籤到底提供了哪些資料夾不能解決的能力？

這個問題很現實。

很多產品加標籤，是因為使用者說想要標籤。但標籤系統一旦做不好，就會變成另一套混亂的分類。資料夾、標籤、收藏、搜尋、篩選、專案、風格庫之間如果邊界不清，使用者反而更難管理。

所以 Midjourney 團隊現在更想收集具體工作流案例：使用者到底在哪個場景下需要標籤？資料夾為什麼不夠？是為了快速組合風格，還是為了跨專案複用，還是為了按主題、色調、攝影風格、角色關係做篩選？

對 Midjourney 來說，整理系統可能和生成模型一樣重要。因為一旦使用者開始長期創作，真正難的不是生成一張圖，而是管理上千張圖、數百個風格方向和反覆試驗的結果。

Omni-reference 指向更複雜的角色控制

原文還提到，未來的 Omni-reference / subject reference 系統，可能支援同時處理多個角色參考，並更好地分離不同主體。

這正好對應 AI 圖像生成的長期痛點：角色一致性和多角色關係。

單個角色保持一致已經不容易，多角色更難。常見問題包括：

A 角色的特徵跑到 B 角色身上。
多個人物之間身份混淆。
服裝、髮型、面部特徵在不同圖裡不穩定。
參考圖對整體風格影響過強，而不是只控制主體。

如果 Omni-reference 能更好地處理主體分離，那麼 Midjourney 會更適合漫畫、分鏡、廣告視覺、角色設定、遊戲概念圖和連續敘事。

這也是 V7 之後值得持續關注的方向。

Midjourney 正在重新理解 prompt

這次整理稿裡還有一個很有意思的觀點：語言是想像力的壓縮層。

這句話很適合解釋 Midjourney 的產品方向。

很多使用者以為 AI 繪圖的核心是寫更長、更精確的 prompt。但實際創作裡，圖像參考、風格參考、moodboard、SREF、變體、重新生成和後期修圖，往往比一段超長文字更有用。

Midjourney 團隊成員 Duncan 的工作流也體現了這一點：他會把 Midjourney 當成 sketchbook，用 moodboard、SREF、少量文字、高 --r 再生成、強弱變體、Photoshop 修圖和外部放大流程組合起來。

這說明 Midjourney 的成熟使用者並不是只靠「神奇提示詞」工作。

更真實的流程是：

用少量語言給方向。
用圖片參考提供視覺語境。
用 SREF 收斂風格。
用大量變體探索空間。
用人工審美選擇結果。
用外部工具做後期處理。

Prompt 仍然重要，但它不是全部。

對使用者來說意味著什麼

如果你只是偶爾生成圖片，這次更新最直接的影響是會話模式更好用。未來你可能可以更自然地說出想要的比例、參考圖、風格和參數，而不是記一堆命令。

如果你是重度使用者，更值得關注的是三個方向。

第一，整理系統。

SREF、風格、資料夾、收藏和標籤如何演進，會直接影響長期創作效率。

第二，網站改版。

新介面如果能把探索、整理、複用和匯出串起來，Midjourney 會更像專業創作工具，而不是單一生成器。

第三，角色和主體參考。

Omni-reference 如果能穩定處理多角色和主體分離，會讓 Midjourney 更適合連續專案，而不是只適合單張圖。

小結

Midjourney 2026 年 5 月這次 Office Hours 的重點，不是某一個炫酷參數，而是產品正在繼續向「創作系統」進化。

會話模式降低輸入門檻，AI 輔助開發提高迭代速度，網站改版試圖重組工作流，SREF 和標籤討論指向長期資產管理，Omni-reference 則關係到角色一致性和複雜主體控制。

對 AI 圖像生成工具來說，模型能力當然重要。但當生成品質達到一定水準後，真正決定使用者是否長期留下來的，往往是工作流、整理能力、可控性和迭代速度。

Midjourney 正在把這些部分補起來。

參考資料

Midjourney 最新ニュース（2026年5月14 日）｜アキスケ

OpenClaw 作者 Peter Steinberger 如何看 AI 軟體開發？從 OpenClaw 到閉環編程

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger 的經歷很適合用來觀察 AI 軟體開發正在發生什麼變化。

他不是「突然被 AI 帶火的新人」。在 OpenClaw 之前，他已經是 PSPDFKit 的創辦人，長期做 PDF 渲染、文件處理和開發者工具。這類產品很難靠概念包裝取勝，必須面對效能、相容性、API 設計、企業客戶和長期維護。

所以，當 Steinberger 後來用 AI 工具做出 OpenClaw，並圍繞 AI Agent、個人自動化和 AI 編程發表觀點時，重點不只是「一個人寫了很多程式碼」。更值得看的，是他把多年軟體工程經驗和新一代 AI coding agent 結合後，對開發流程的重新理解。

AI 編程不是魔法按鈕

很多人討論 AI 編程時，會把它簡化成兩個極端。

一種說法是：AI 已經能寫程式碼，程式設計師快沒用了。

另一種說法是：AI 寫的程式碼不可靠，真正工程還是得靠人手寫。

Steinberger 的經驗更接近第三種：AI 讓軟體開發的操作單位變了，但沒有取消工程判斷。

過去，開發者主要以「編輯程式碼」為中心工作。需求拆解、架構判斷、寫實作、跑測試、修 bug，都圍繞人工修改程式碼展開。

AI coding agent 介入後，開發者越來越像在管理一個執行系統：

說明目標。
提供上下文。
約束邊界。
讓 agent 修改程式碼。
執行測試和檢查。
根據結果繼續迭代。

這不是簡單把鍵盤交給模型，而是把人從「每一行都親手敲」轉到「定義方向、設計回饋、判斷結果」。

為什麼他不喜歡把這叫 vibe coding

圍繞 Steinberger 的討論裡，一個高頻詞是 vibe coding。

這個詞原本用來形容一種新開發方式：開發者用自然語言描述想法，讓 AI 生成大量程式碼，再透過執行結果和回饋不斷調整。

但 Steinberger 對這個詞並不完全買帳。公開報導中提到，他認為 vibe coding 容易變成一種貶義表達，暗示 AI 輔助開發只是「憑感覺亂生成」，忽視了背後的技能、判斷和經驗。

這個批評有道理。

真正有效的 AI 編程並不是隨便輸入一句話，然後相信模型輸出。它需要：

能把模糊需求拆成可執行任務。
能識別模型是否誤解了目標。
能設計測試和驗收標準。
能判斷程式碼結構是否會影響長期維護。
能知道什麼時候應該停止生成、轉向人工審查。

換句話說，AI 降低了寫程式碼的摩擦，但沒有降低理解系統的責任。

閉環才是關鍵

Steinberger 相關訪談和文章裡，經常被總結出的一個核心思路是「閉環」。

只讓 AI 生成程式碼，是開環。

讓 AI 生成程式碼、執行程式碼、讀取錯誤、修復問題、再執行測試，才更接近閉環。

這個差別非常重要。

開環生成很容易製造表面可用的軟體。頁面能打開，功能看起來有，程式碼也不少，但一旦進入真實場景，就會暴露狀態管理、權限、異常處理、邊界條件和部署問題。

閉環開發要求輸出必須被回饋約束。最簡單的閉環是：

寫清楚目標。
讓 AI 修改程式碼。
自動執行測試、型別檢查、lint 或構建。
把錯誤回饋給 AI。
重複直到通過。
最後由人審查關鍵路徑。

這也是 AI 軟體開發真正能提高效率的地方。不是因為模型一次就寫對，而是因為它可以快速參與「生成、驗證、修復」的循環。

經驗越多，越能用好 AI

AI 編程最容易產生的誤解之一，是「經驗不重要了」。

Steinberger 的案例反而說明，經驗會變得更重要，只是作用方式變了。

一個有經驗的工程師更容易判斷：

哪些任務適合交給 agent。
哪些模組需要先寫測試。
哪些改動風險太高，不該讓 AI 大範圍重構。
哪些生成程式碼只是看起來合理。
哪些問題應該透過架構調整解決，而不是繼續補丁式修復。

AI 可以生成大量候選方案，但候選方案越多，越需要判斷力。沒有經驗的人可能會被「能跑起來」迷惑，有經驗的人更會追問：能不能維護？能不能擴展？會不會破壞安全邊界？出了問題能不能定位？

這也是為什麼 AI coding agent 並沒有讓軟體工程變成純聊天。它更像把一部分執行勞動外包出去，同時放大了規劃、審查、驗證和取捨的重要性。

OpenClaw 的意義不只是專案本身

OpenClaw 被關注，不只是因為它是一個開源 AI agent，也不只是因為它的增長速度快。

它更像一個信號：開發者開始希望 AI 不只回答問題，而是能接入真實工具，完成真實動作。

傳統聊天機器人停留在對話框裡。它可以解釋程式碼、寫草稿、給建議，但很多時候還需要人複製、貼上、打開軟體、執行命令。

Agent 的方向是把模型接到工具上：

檔案系統。
瀏覽器。
終端。
郵件。
日曆。
第三方服務。
專案倉庫。

一旦模型能使用這些工具，軟體開發的邊界就會變化。AI 不再只是「程式碼補全」，而會參與專案閱讀、任務拆解、檔案修改、測試執行、PR 整理和工作流自動化。

這也是 Steinberger 加入 OpenAI 後被關注的原因。他代表的不是單個開發者故事，而是一種產品方向：個人 agent 會從演示玩具走向日常工作層。

這對普通開發者意味著什麼

對普通開發者來說，Steinberger 的經驗不一定能直接複製。

不是每個人都能同時管理多個 agent，不是每個專案都適合高強度 AI 生成，也不是每個團隊都能接受「先生成再快速迭代」的節奏。

但有幾件事值得學。

第一，先把任務寫清楚。

AI 對含糊目標很敏感。你說「優化一下」，它可能改風格、改結構、加功能、刪邏輯。你說「把登入失敗時的錯誤提示從英文改成中文，不改變認證流程」，結果通常更可控。

第二，把驗證命令固定下來。

如果一個專案沒有測試、沒有構建命令、沒有 lint，AI 就很難形成閉環。哪怕只是最基礎的 npm test、go test ./...、pytest、hugo，也比完全靠肉眼檢查強。

第三，控制改動範圍。

一次只讓 AI 處理一個模組、一個 bug、一個頁面，通常比讓它「重構整個專案」更可靠。

第四，保留人工審查。

尤其是認證、支付、權限、資料刪除、部署腳本、資料庫遷移、安全配置這些地方，不要因為程式碼是 AI 生成的就降低審查標準。

第五，復盤 prompt 和失敗模式。

如果 AI 經常誤解某類任務，就把約束寫進專案規則、agent instructions 或技能檔案。AI 編程能力不是只來自模型，也來自你給它搭建的工作環境。

AI 軟體開發會走向哪裡

Steinberger 的故事說明，AI 軟體開發正在從「輔助寫程式碼」走向「組織軟體生產流程」。

早期 AI 編程工具的價值主要是補全函式、解釋報錯、生成模板。現在的變化是，agent 可以跨檔案工作，可以呼叫工具，可以執行檢查，可以根據回饋繼續修復。

這會帶來幾個趨勢：

第一，個人開發者的產能上限會提高。

一個人可以同時推進更多原型、腳本、內部工具和小型產品。但產能提高不等於品質自動提高。越快生成，越需要驗證。

第二，專案結構會更重要。

程式碼越清晰，測試越明確，文件越完整，AI 越容易正確修改。混亂專案對人難，對 AI 也難。

第三，軟體工程師會更像工作流設計者。

未來重要的不只是會不會寫某門語言，而是能否把需求、上下文、工具、測試、部署和權限組織成一個可控循環。

第四，安全邊界會更敏感。

Agent 能做事，就可能做錯事。它能讀檔案、執行命令、存取服務，也意味著權限、審計和回滾會成為 AI 開發環境的基礎設施。

小結

Peter Steinberger 的 AI 軟體開發觀，最有價值的地方不是「AI 生成了多少程式碼」，而是他展示了一種新的開發姿勢。

人不再只是在編輯器裡逐行輸入，而是在設計目標、管理 agent、構造回饋迴路、審查結果和調整系統。程式碼仍然重要，但程式碼不再是唯一的勞動中心。

如果說傳統軟體開發強調「把程式碼寫對」，AI 軟體開發會更強調「讓系統持續產出可驗證的正確結果」。

這不是降低工程門檻那麼簡單。它是在改變工程能力的形態：從手工實作，轉向任務分解、上下文管理、工具編排、自動驗證和最終判斷。

參考資料

Google Gemini Spark 爆料解讀：一個 24 小時在線的 Gemini Agent 可能要來了

Sun, 17 May 2026 11:58:08 +0800

Google 還沒有正式發布 Gemini Spark。

目前關於它的資訊，主要來自 Gemini Web 內部測試介面、社群截圖、TestingCatalog 報導，以及 36Kr / 新智元對相關爆料的整理。比較一致的說法是：Gemini Spark BETA 可能是 Google 正在準備的全天候 AI Agent，定位不再只是聊天助手，而是能在後台處理郵件、線上任務和多步驟工作流的「日常 AI 代理」。

所以這篇文章先把邊界說清楚：這是爆料解讀，不是 Google 官方發布稿。所有功能、命名和上線時間，都要等 Google 正式公告確認。

先說結論

從目前曝光的資訊看，Gemini Spark 有三個重點：

它可能是 Gemini 體系裡的 24 小時在線 Agent，而不是普通聊天模型。
它會調用更廣泛的個人上下文，包括 Google 應用、聊天記錄、任務、登入網站和位置資訊等。
它的風險和吸引力一樣大，因為它可能涉及資訊分享、遠端瀏覽器資料、購買動作和第三方服務調用。

如果 Google 真把 Spark 推出來，Gemini 的定位會發生變化：從「回答問題的 AI」變成「替你持續處理事務的 AI」。

Gemini Spark 是什麼

TestingCatalog 在 2026 年 5 月 14 日報導，Google 正在 Gemini Web 中測試 Gemini Spark BETA。曝光的歡迎文案把它描述成一個 everyday AI agent，可以 24/7 幫使用者處理 inbox、online tasks 和更多多步驟工作。

36Kr / 新智元的文章也提到，Spark 被扒出後，外界看到的是一個「全時 Agent」方向：它可以全天候待命，處理收件匣、執行線上任務，甚至可能涉及購買和資訊分享。

這意味著 Spark 不是一個單純的新模型名。它更像是 Gemini 產品層的一次升級：讓 Gemini 從對話窗口裡走出來，進入使用者的郵件、網頁、日程、任務和跨應用工作流。

它可能怎麼工作

根據 TestingCatalog 披露的隱藏 onboarding 文案，Gemini Spark 會從多種來源取得上下文，包括：

Connected Apps。
skills。
chats。
tasks。
使用者登入過的網站。
Personal intelligence。
location。

這些資訊會幫助 Spark 理解使用者想完成什麼，並在執行任務時調用必要的上下文。文案還提到，為了完成某些動作，Gemini 可能會把必要資訊分享給第三方，例如姓名、聯絡方式、文件、偏好，以及使用者可能認為敏感的資訊。

如果這些描述最終屬實，Spark 的工作方式會更接近「帶上下文的代理系統」，而不是一次性問答。它不是只看當前一句 prompt，而是可能綜合長期偏好、連接應用、瀏覽器狀態和任務歷史。

為什麼它重要

Gemini Spark 的關鍵，不在於多一個聊天入口，而在於 Google 有天然的生態入口。

OpenAI 和 Anthropic 可以做很強的 Agent，但它們很難天然擁有 Gmail、Calendar、Drive、Chrome、Android、Workspace 這條完整鏈路。Google 如果把 Spark 接進這些產品，使用者不需要額外搭建太多工作流，就能讓 Agent 進入日常事務。

這會帶來三個變化。

第一，Gemini 會從被動問答變成主動執行。使用者不再只是問「幫我總結這封郵件」，而是可能讓它持續整理 inbox、追蹤任務和執行後續動作。

第二，Agent 會更依賴個人上下文。它越懂你的郵件、日程、文件、瀏覽器狀態和偏好，越可能給出有用結果。

第三，權限邊界會變得更敏感。能做更多事，也意味著需要更清楚地知道它什麼時候能做、能做到哪一步、是否需要確認。

風險點在哪裡

TestingCatalog 披露的文案裡，有幾處很值得關注。

第一，Spark 是 experimental。也就是說，即便它上線，也不應被當成完全成熟、無需監督的系統。

第二，雖然系統設計上會在敏感操作前徵求許可，但文案也提示，它可能會在未經詢問的情況下分享資訊或完成購買。

第三，為了保持會話連續性，Gemini 會保存 remote browser data，比如登入細節和 remote code execution data。使用者可以在 Settings 中清除這些資料，也可以關閉 Connected Apps 和 Personal intelligence 相關能力。

這幾個點合在一起，說明 Spark 的產品方向很激進：它要做真正能執行任務的 Agent，而不是只生成建議。但越接近真實執行，越需要嚴格的權限、稽核、確認和回滾機制。

和 Remy、AI Ultra 的關係

TestingCatalog 提到，Spark 可能是此前內部代號 Remy 的 agentic Gemini upgrade 的重命名版本，也與面向 Google AI Ultra 訂閱使用者的 Gemini Agent 方向有關。

如果這個線索成立，Spark 可能不是憑空出現的新專案，而是 Google 把此前較高階、較封閉的 Agent 能力重新包裝，並準備推向更大範圍使用者。

36Kr / 新智元也把它描述成從 “Remy” 到 “Spark” 的升級：Gemini Agent 不再只是一個功能，而是要走向 24/7 的數位生活管家。

不過這仍然是基於爆料資訊的判斷。Google 是否會使用 Spark 這個正式名稱、是否只面向 AI Ultra、是否推出更輕量訂閱層，還要等官方確認。

MCP、skills 和工具生態

同一批社群截圖裡，還出現了 MCP Tool Testing 這類模型選擇器入口。36Kr 文章認為，這可能暗示新 Gemini 會原生支援 MCP 第三方工具接入，Thinking 模式也會重構。

這條線索和 Spark 放在一起看，很有意思。

如果 Spark 只是「會聊天的助手」，skills 和 MCP 的意義有限。但如果 Spark 是一個長期運行的 Agent，它就需要可靠地調用工具、存取網頁、執行任務、讀寫上下文，並把結果交付給使用者。

也就是說，Spark 可能不是單點功能，而是 Google Agent 工具生態的一部分：模型負責理解和規劃，skills / MCP / connected apps 負責執行和擴展。

對普通使用者意味著什麼

如果 Gemini Spark 真的發布，普通使用者最直接的變化可能是：

郵件不只是被總結，而是可以被分類、跟進和轉成任務。
網頁任務不只是給建議，而是可能在遠端瀏覽器中持續執行。
日程、位置、偏好和歷史對話會變成 Agent 的長期上下文。
購買、預訂、表單填寫等動作可能進入 AI 執行範圍。

這聽起來很方便，但使用者需要建立新的習慣：不再只看 AI 說了什麼，還要看 AI 準備做什麼、已經做了什麼、能不能撤回、有沒有記錄。

未來 AI Agent 的體驗好不好，可能不只取決於模型聰不聰明，還取決於權限提示是否清楚、任務日誌是否可查、錯誤操作能不能恢復。

對開發者和團隊意味著什麼

對開發者來說，Spark 的意義在於 Google 可能正在把 Agent 從「展示產品」推向真實工作流平台。

如果 Spark 能穩定連接 Google 應用、第三方工具和瀏覽器狀態，那麼開發者會關心：

API 或擴展機制是否開放。
MCP 或 skills 是否可由第三方接入。
企業管理員能否控制權限、資料留存和稽核。
Agent 執行失敗時是否有可追蹤日誌。
是否支援沙盒、審批流和敏感操作確認。

對團隊來說，Spark 可能會先從 Gmail、Calendar、Docs、Drive、Chrome 這類高頻場景切入。它未必一開始就適合完全自動化高風險業務，但很適合作為 inbox triage、會議跟進、資料整理、市場研究和輕量營運任務的助手。

現在應該怎麼看

這條消息適合用「高可信方向，低確定細節」來理解。

高可信方向是：Google 確實在推進更主動、更長期運行、更深度接入生態的 Gemini Agent。TestingCatalog 報導的 Gemini Web 測試文案、社群截圖和 36Kr 整理的多方爆料，都指向同一個方向。

低確定細節是：正式名稱、上線時間、權限規則、訂閱層級、可用地區、是否開放 API、是否真的叫 Gemini Spark，都還不能下結論。

所以現在最穩妥的判斷是：

不要把 Spark 當成已經發布的正式產品。
可以把它視為 Google 下一階段 AI Agent 路線的強訊號。
真正值得等的是官方如何解釋權限、隱私、第三方資料分享和遠端瀏覽器資料保存。

總結

Gemini Spark 如果最終發布，可能會是 Gemini 從聊天助手走向全天候 Agent 的關鍵一步。它不只是換一個模型，而是把 Gemini 放進 Google 生態的郵件、網頁、任務、位置、個人智能和第三方服務裡。

它的潛力很大：更主動、更貼近真實工作流，也更容易借助 Google 的生態分發給大量使用者。它的風險也同樣大：一旦 AI 能分享資訊、保存瀏覽器狀態、執行購買和調用第三方服務，權限邊界就必須非常清楚。

所以 Gemini Spark 最值得關注的不是「它有多聰明」，而是 Google 準備怎樣讓一個 24 小時在線的 AI Agent 變得可控、可稽核、可信任。

參考連結：

Gemini 3.5 Pro 曝光：代號 Cappuccino，Google 想在編程和 Agent 上追回節奏

Sun, 17 May 2026 11:47:27 +0800

Google 還沒有正式發布 Gemini 3.5 Pro。

目前能看到的資訊，主要來自開發者社群截圖、匿名跑分、爆料人消息和媒體轉述。36Kr / 新智元在 2026 年 5 月 15 日整理稱，新一代 Gemini 檢查點內部代號可能是 Cappuccino，相關模型已經在社群和評測平台中提前曝光。

這類資訊還不能等同於官方發布，但它透露出一個清晰方向：Google 正在試圖同時補上兩塊短板，一塊是編程和推理能力，另一塊是全天候 AI Agent。

先說結論

這次爆料可以拆成三層來看：

Gemini 3.5 Pro 尚未正式發布，Cappuccino 更像是內部檢查點或候選版本代號。
曝光資訊顯示，新 Gemini 在程式碼生成、SVG / 互動式 Web 生成、多模態輸出上有明顯提升。
Google 同步測試的 Gemini Spark，可能比模型本身更關鍵，因為它指向 24 小時運行的個人 AI Agent。

換句話說，這不是一條簡單的「模型跑分新聞」。它更像是 Google 在 I/O 前釋放出的產品路線訊號：模型要追趕 GPT-5.5，Agent 要搶占使用者工作流入口。

Cappuccino 是什麼

36Kr 文章提到，網友 Lentils 放出的消息顯示，代號 Cappuccino 的 Gemini 3.5 Pro 檢查點已經開始產出。此前社群還在討論 Gemini 3.2，但最新曝光直接跳到了 3.5。

如果這個命名最終屬實，說明 Google 可能希望把下一代 Gemini 包裝成一次更大的版本躍遷，而不是普通小版本更新。

需要注意的是，Cappuccino 現在仍應被視為爆料中的內部代號。它不等於 Google 已經公開上線的正式模型，也不代表最終發布名一定就是 Gemini 3.5 Pro。

編程能力為什麼是焦點

這次爆料裡最受關注的點，是新 Gemini 的編程能力。

36Kr 引述的社群截圖和跑分資訊顯示，新模型在以下任務上表現更強：

生成 SVG 與視覺元件。
生成互動式 Web 應用。
處理動畫、3D、可調參數面板等複雜前端輸出。
邏輯推理和程式碼生成能力有所提升。

文章還提到，Abacus.AI CEO Bindu Reddy 轉述的說法是，3.2 Flash 在編碼和推理上接近 GPT-5.5 的水準，同時成本更低。另有媒體信源則認為，新款 Gemini 的整體性能大致追平 GPT-5.5，但未必能帶來質變。

這也是為什麼要謹慎看待「追平 GPT-5.5」這句話。它更像是不同爆料源和匿名評測中的相對判斷，而不是 Google 官方給出的基準測試結論。

為什麼 Google 急著補編程

AI 編程已經從開發者工具變成了大模型競爭的核心戰場。

OpenAI 有 Codex，Anthropic 有 Claude Code。它們不只服務工程師，也在把產品經理、設計師、營運人員帶進「自然語言生成可運行產品」的工作流裡。

相比之下，Google 雖然有 Gemini 和 Antigravity，但在開發者心智裡一直沒有形成同等強度的預設入口。36Kr 文章也提到，Antigravity 在外部市場還沒有真正突圍，定價、額度提醒和體驗穩定性都曾引發社群討論。

所以新 Gemini 如果要證明自己，編程會是最直接的戰場。它不一定只比拼「會不會寫程式碼」，還要比拼能不能穩定產出完整介面、理解複雜需求、調用工具、修復錯誤並融入真實開發流程。

Spark 可能比 3.5 Pro 更重要

同一波爆料裡，Gemini Spark BETA 也被扒出。

根據 TestingCatalog 等資訊源的說法，Spark 的定位接近「全天候 AI Agent」：它可以處理收件匣、執行線上任務、管理多步驟工作流，並連接 Google 應用、技能模組、聊天記錄、定時任務、登入網站、位置資訊等上下文。

這意味著 Spark 不是一個普通聊天入口，而是一個可能長期在線、持續讀取上下文並替使用者執行任務的系統。

它的吸引力很明顯：如果 Google 能把 Gmail、Calendar、Chrome、Android、Workspace 和 Gemini 串起來，Spark 會天然擁有 OpenAI 和 Anthropic 很難複製的分發優勢。

但風險也同樣明顯。36Kr 文章提到，Spark 相關說明中出現了「可能在未經詢問的情況下分享資訊或完成購買」的表述。哪怕系統設計上會在敏感操作前徵求許可，這類 Agent 仍然會帶來隱私、授權邊界和誤操作風險。

這對普通使用者意味著什麼

如果你只是普通 Gemini 使用者，這次爆料真正值得關注的不是模型名，而是三個變化：

第一，Google 可能會繼續強化「生成完整結果」的能力。以前使用者經常吐槽 Gemini 在視覺生成、SVG、前端頁面上容易偷懶，如果新模型能一次給出多個完整方案，體驗會明顯改善。

第二，編程能力會繼續下放到更輕量的模型。爆料裡反覆提到 Flash 版本在編碼、推理和互動式生成上的提升，這意味著未來不一定只有 Pro 模型才能處理複雜任務。

第三，Agent 會變得更主動。Spark 如果發布，Gemini 可能不再只是回答問題，而是開始長期接管郵件、網頁、購買、日程和跨應用任務。

這對效率是好消息，對權限管理則是新挑戰。

這對開發者意味著什麼

開發者更應該關注兩個問題。

第一個問題是工具生態。36Kr 文章提到，社群從模型選擇器裡看到了 MCP Tool Testing 這類未公開入口。如果 Gemini 原生支援 MCP 或第三方工具測試，那麼它會更容易接入開發者自己的工具鏈。

第二個問題是成本和穩定性。即便新 Gemini 在某些基準上追平 GPT-5.5，開發者最終還是會看三件事：實際程式碼品質、上下文穩定性、價格和額度是否可預期。

過去一年，AI 編程工具競爭已經證明，模型能力只是門票。真正讓開發者留下來的，是能不能在日常專案裡持續可靠地改程式碼、跑測試、讀上下文、處理邊界條件。

現在應該如何看待這條消息

這條消息適合用「強訊號、弱確認」來理解。

強訊號在於：多個社群線索都指向 Google 正在準備更強的新 Gemini，以及更主動的 Gemini Spark Agent。

弱確認在於：Gemini 3.5 Pro 還沒有官方發布，Cappuccino 仍是爆料代號，所謂「追平 GPT-5.5」的說法也需要等 Google 官方基準、第三方評測和真實使用者測試來驗證。

所以現在最穩妥的判斷是：

不要把它當成已發布產品。
可以把它當成 Google 下一階段 Gemini 路線的提前預告。
重點關注 I/O 或後續官方活動中是否會確認模型命名、API 可用性、價格、上下文窗口、工具調用和 Agent 權限邊界。

總結

Gemini 3.5 Pro / Cappuccino 的曝光說明，Google 可能正在為下一代 Gemini 做一次更強勢的版本推進。它要補的不是單一能力，而是整個 AI 工作流：模型要更會寫程式碼、生成介面和處理複雜推理，Spark 則要把 Gemini 推向全天候 Agent。

但在官方發布前，所有跑分和截圖都只能作為線索。真正決定 Gemini 3.5 Pro 能否翻身的，不是代號是否好聽，而是它能否在真實開發、真實辦公和真實多步驟任務裡穩定勝出。

參考連結：

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 真正難的地方。

DeepSeek-TUI：把 DeepSeek V4 變成終端裡的編程智能體

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI 是一個把 DeepSeek V4 接入終端開發流程的開源專案。它不是普通聊天外殼，而是更接近 Claude Code、Codex CLI 這類「命令列編程智能體」：能看檔案、改程式碼、執行命令、調用工具，並在終端裡用 TUI 方式持續推進任務。

如果你已經習慣在編輯器和終端之間切換，這類工具的價值很直接：不用把程式碼來回複製到網頁對話框裡，也不用手動描述完整專案結構。你把任務交給它，它可以在目前工作區裡讀取上下文、規劃步驟、執行修改，再把結果交還給你審查。

它解決的是 DeepSeek 的使用入口問題

DeepSeek 模型本身提供了很強的推理和程式能力，但模型能力要落到真實開發流程裡，還需要一層工程化外殼。

網頁聊天適合問問題，不適合長時間改專案。API 適合接入系統，但一般開發者還要自己寫工具調用、上下文管理、檔案讀寫和權限控制。DeepSeek-TUI 想補上的正是這一層：把 DeepSeek V4 包成一個可以在終端裡工作的 Agent。

從專案介紹看，它的重點能力包括：

終端 TUI 介面；
面向 DeepSeek V4 的對話與任務執行；
工具調用和檔案操作；
1M 上下文支援；
Auto 模式；
子智能體；
沙箱執行；
持久化任務佇列。

這些功能組合起來，目標不是「讓模型回答得更像人」，而是讓模型更容易進入開發現場。

TUI 比純命令列更適合長任務

很多 AI CLI 工具一開始都是純文字互動：輸入提示詞，等待輸出，再複製命令或補充上下文。這種方式簡單，但任務一長就容易混亂。

TUI 的好處是能把會話、檔案、執行結果、任務狀態放在一個更穩定的介面裡。對編程 Agent 來說，這很重要。因為一次程式任務往往不是一問一答，而是包含：

理解專案結構；
查找相關檔案；
修改程式碼；
執行測試或命令；
根據錯誤繼續修復；
總結變更。

如果介面只是一串日誌，使用者很難快速判斷 Agent 走到了哪一步。TUI 至少給了一個更適合觀察和接管的入口。

Auto 模式適合明確邊界的任務

DeepSeek-TUI 提到的 Auto 模式，適合用在邊界比較清楚的工作裡。例如修一個小 bug、補一個腳本、改一段配置、整理一組文件、實作一個局部功能。

這類任務的共同點是：目標清楚，檢查方式明確，影響範圍可控。Agent 可以自己查檔案、改檔案、跑命令，然後把結果交給使用者確認。

但 Auto 模式不適合無限放權。尤其是在真實專案裡，刪除檔案、批量重構、資料庫遷移、部署命令都應該有明確確認。編程 Agent 的效率來自自動化，但風險也來自自動化。越是能執行命令的工具，越需要沙箱、權限邊界和人工審查。

子智能體的意義在於拆任務

子智能體不是新概念，但放在程式場景裡很有用。

一個稍複雜的任務，通常會同時需要幾類工作：有人負責讀程式碼，有人負責改實作，有人負責檢查測試，有人負責整理文件。傳統多 Agent 系統經常顯得花俏，是因為它們沒有真實工具和真實工作區，只是在對話裡互相討論。

如果子智能體能結合檔案系統、命令執行和任務佇列，它就更像一種任務拆分機制。比如一個子智能體專門分析依賴關係，另一個負責修改某個模組，主智能體再整合結果。這樣可以減少單一上下文裡堆太多無關資訊的問題。

當然，子智能體也會帶來額外成本：更多 token、更複雜的狀態、更難追蹤的責任邊界。所以它適合中等複雜度以上的任務，不一定適合每一次小修改。

1M 上下文不是萬能，但很適合讀專案

1M 上下文聽起來很誇張，但在編程場景裡並不只是行銷數字。

真實程式庫的上下文很碎：README、設定檔、型別定義、測試、調用鏈、歷史約定、錯誤日誌，都可能影響一次修改。更長上下文能減少「只看局部就動手」的問題，也能讓模型保留更多專案約束。

不過，上下文長不等於判斷一定更準。程式任務仍然需要檢索、篩選和驗證。把整個專案塞進上下文並不一定比精準讀取相關檔案更好。好的編程 Agent 應該把長上下文當作緩衝區，而不是把它當成替代工程判斷的捷徑。

更適合哪些使用者

DeepSeek-TUI 更適合幾類人：

想在終端裡使用 DeepSeek 做程式任務的開發者；
不想自己搭工具調用和檔案操作框架的人；
已經熟悉 Claude Code、Codex CLI，但想嘗試 DeepSeek 模型入口的人；
需要本地專案上下文，而不是只在網頁裡問程式片段的人；
想把 AI 編程流程放進命令列環境的人。

如果你只是偶爾問一個函式怎麼寫，網頁聊天已經夠用。如果你希望模型直接參與專案修改，終端 Agent 才更有意義。

需要關注的風險

這類工具最需要關注三件事。

第一是權限。只要工具能讀寫檔案、執行命令，就要確認它預設能存取哪裡、能不能刪除檔案、能不能連網、危險命令是否需要確認。

第二是可回滾。使用前最好保持 Git 工作區乾淨，讓每次 Agent 修改都能被 git diff 清楚看到。不要在一堆未提交改動裡讓 Agent 自動改專案。

第三是驗證。Agent 寫完程式不代表任務完成。測試、構建、lint、人工 review 仍然要保留。AI 編程工具可以提高推進速度，但不能替代最後的工程確認。

總結

DeepSeek-TUI 的意義不在於又多了一個聊天客戶端，而在於它把 DeepSeek V4 放進了更接近真實開發工作的終端環境裡。

對開發者來說，模型能力只是第一步。真正影響體驗的是：它能不能讀專案、能不能安全改檔案、能不能執行驗證命令、能不能在長任務裡保持狀態、能不能讓使用者隨時接管。

如果你想把 DeepSeek 用在日常程式修改、專案閱讀和自動化開發任務裡，DeepSeek-TUI 值得關注。它代表的方向也很清楚：AI 編程工具正在從「回答程式問題」轉向「參與專案執行」。

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 產品是否有長期價值，可以問一個問題：當這個能力被下一代模型或平台內置後，它還剩下什麼？

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

Gemini 3.5 Pro 提前曝光：Google 想用 Spark Agent 搶回 AI 編程入口

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro 還沒正式發布，相關爆料已經開始升溫。

這輪資訊裡有幾個關鍵詞：Gemini 3.5 Pro、代號 Cappuccino、Gemini Spark、AI 編程、MCP 工具接入。它們指向同一個方向：Google 不只是想更新一個聊天模型，而是想把模型、工具、Agent 和 Google 生態入口重新綁在一起。

不過，在正式發布前，這些資訊都應該按「爆料」看待。真正值得關注的不是某一張截圖或某一個跑分，而是 Google 接下來可能要補的幾塊短板。

Gemini 3.5 Pro 為什麼值得關注

從曝光資訊看，Gemini 3.5 Pro 可能是一次跳級命名。

此前外界還在討論 Gemini 3.2，隨後又出現 Gemini 3.5 Pro 的說法。如果命名屬實，說明 Google 想在新一輪發布裡講一個更大的版本故事，而不是只做常規小更新。

目前流出的重點主要集中在三方面：

編程和推理能力繼續提升；
SVG、互動式頁面、動畫和 3D 生成能力增強；
新的 Agent 產品 Gemini Spark 可能進入前台。

這些方向並不意外。Gemini 系列一直強調多模態，Google 也有足夠強的分發渠道。真正的問題是，它能不能在開發者工具和 Agent 工作流上趕上 OpenAI、Anthropic 的節奏。

編程能力是 Google 最需要補的課

大模型競爭進入 2026 年後，編程已經不只是「模型能力測試項」，而是最直接的產品入口。

原因很簡單：AI 編程工具有高頻使用場景，也能產生大量可回饋的資料。開發者每天讓模型讀程式碼、改程式碼、跑測試、修 bug，這些互動天然會推動下一代模型和工具鏈繼續進化。

過去一年，Claude Code 在開發者群體裡聲量很高，OpenAI 也持續強化 Codex 與 ChatGPT 的協同。相比之下，Google 雖然有 Antigravity 等產品，但外部存在感並不算強。

這也是 Gemini 3.5 Pro 被重點觀察的原因。如果它只是聊天更強、回答更快，意義有限；如果它能真正改善程式碼理解、跨檔案修改、工具呼叫和長任務執行，才可能改變開發者工作流。

Gemini Spark 可能是更大的變數

比模型本身更激進的，是傳聞中的 Gemini Spark。

按照曝光描述，Spark 的定位不是普通聊天助手，而是全天候運行的 AI Agent。它可能接入郵件、日程、網頁、任務、帳號狀態和個人上下文，幫助使用者處理多步驟工作流。

這類產品的想像空間很大。比如：

自動整理收件箱；
幫使用者跟進任務；
在網頁上執行操作；
處理跨應用流程；
根據個人偏好安排日常事務。

但風險也同樣明顯。一個全天候 Agent 如果能存取登入狀態、瀏覽器資料、檔案、位置和第三方服務，就必須回答幾個問題：什麼時候需要使用者確認？哪些操作必須禁止自動執行？資料會不會被分享給第三方？遠端瀏覽器和憑證如何隔離？

所以 Spark 真正的看點，不只是「能不能幫你幹活」，而是 Google 能否把權限、稽核、確認機制和使用者控制做得足夠清楚。

MCP 工具接入說明什麼

爆料裡還提到，新的 Gemini 選擇器可能出現 MCP 相關模型或測試入口。

如果這部分最終落地，說明 Google 也在把模型從「問答系統」推向「工具操作系統」。模型不再只是生成文字，而是要能呼叫外部工具、存取業務系統、讀寫檔案、執行命令，並在多個步驟之間保持任務狀態。

這和 OpenAI、Anthropic 的方向是一致的。誰能讓模型更穩定地呼叫工具，誰就更容易把 AI 嵌進真實工作流。

不過，MCP 接入本身不是終點。真正難的是穩定性：

模型能否正確選擇工具；
參數是否可靠；
失敗後能不能恢復；
權限邊界是否明確；
使用者能不能追蹤每一步操作。

如果這些問題沒解決，工具越多，出錯面也越大。

多模態仍然是 Google 的優勢牌

Google 最有機會打出差異化的地方，仍然是多模態。

從曝光的 SVG、互動式頁面、動畫和視覺生成案例看，Gemini 可能繼續強化「從提示詞生成可互動內容」的能力。相比單純寫一段程式碼，這更接近產品原型生成：使用者描述一個想法，模型直接給出可操作、可調節、可預覽的介面。

這條路線很適合 Google。它既能承接 Gemini 的多模態能力，也能和 Android、Chrome、Workspace、搜尋、廣告、雲服務等入口結合。

如果 Google 想避免只在「誰的程式碼模型更強」上硬拼，它很可能會把重點放到更完整的多模態 Agent 系統上。

三家公司的打法正在分化

現在的大模型競爭已經不是單一模型排行榜競爭。

OpenAI 的優勢在產品迭代和分發節奏，Codex、ChatGPT、企業工具和 API 之間的聯動越來越緊。

Anthropic 的優勢在開發者心智和程式碼模型品質，Claude Code 已經成了很多人預設的 AI 編程入口。

Google 的優勢則是生態入口。Gmail、Docs、Chrome、Android、搜尋、YouTube、地圖和雲服務構成了一個巨大的個人與企業資料網路。只要 Agent 能安全接入這些入口，Google 就有機會從「模型追趕者」變成「工作流入口控制者」。

這也是 Gemini Spark 值得關注的原因。它不一定需要在所有基準測試上第一，但只要能進入日常工作流，就可能形成自己的護城河。

普通使用者該怎麼看

對普通使用者來說，短期不必被每一次爆料牽著走。

更實用的觀察點有三個：

Gemini 3.5 Pro 的編程能力是否真的改善，尤其是複雜倉庫、長上下文和工具呼叫。
Gemini Spark 是否預設安全，敏感操作前是否有明確確認和可追蹤記錄。
Google 是否給出清晰價格、額度和企業權限管理，而不是只展示演示效果。

如果只是生成幾張漂亮截圖，價值有限。能不能穩定接入真實工作流，才是這一輪 AI Agent 產品的分水嶺。

對開發者意味著什麼

開發者最應該關注的不是「哪個模型贏了」，而是自己的工作流是否可遷移。

現在 Claude Code、Codex、Gemini、Antigravity、Cursor、Windsurf 等工具都在搶入口。如果把所有流程都綁死在某一個平台上，未來成本、額度、模型策略或權限規則一變，遷移會很痛。

更穩妥的做法是：

重要專案保留標準 Git 工作流；
自動修改後必須看 diff；
關鍵任務用測試和 CI 兜底；
不把生產憑證交給不透明 Agent；
能用開放協議接工具時，優先選擇可替換方案。

模型會繼續變強，但工程紀律不會過時。

小結

Gemini 3.5 Pro 的爆料說明，Google 正在加速補齊 AI 編程和 Agent 入口。模型能力提升是一部分，Gemini Spark 這類全天候 Agent 可能才是更大的戰略動作。

但越是能幫使用者「自動幹活」的系統，越需要嚴格的權限邊界和可驗證流程。對 Google 來說，真正的挑戰不只是追上 GPT-5.5 或 Claude，而是把強模型、安全機制和生態入口組合成一個可信的日常工作流。

如果這一步做成，Gemini 不一定要在每個榜單上第一，也可能重新拿回一部分 AI 入口主動權。

OpenHuman 速讀：開源個人 AI Agent 的桌面化路線

Fri, 15 May 2026 14:52:31 +0800

OpenHuman 是 tinyhumansai 推出的開源個人 AI Agent 專案。它的目標不是再做一個聊天視窗，而是把桌面應用、個人記憶、第三方整合、語音、編碼工具和本機知識庫放進同一個 agent harness 裡，讓 AI 更快理解你的日常工作上下文。

專案 README 給它的定位是 “Personal AI super intelligence”，官網也強調 private、simple 和 extremely powerful。這個說法很有野心，但更適合拆開看：OpenHuman 真正值得關注的地方，是它試圖把「個人上下文」作為產品核心，而不是把模型呼叫、外掛設定和文件檢索留給使用者自己拼。

截至本文查看時，GitHub 倉庫約有 7.8k stars、629 forks，最新 release 顯示為 OpenHuman v0.53.43，時間是 2026 年 5 月 13 日。專案仍處在 Early Beta，README 明確提醒正在活躍開發中，應該預期會有粗糙邊緣。

它想解決什麼問題

很多 AI 助手的問題不是模型不夠強，而是上下文太冷。你每次都要重新解釋專案背景、最近郵件、日程、程式碼倉庫、文件、任務和偏好；一旦跨到 Gmail、Notion、GitHub、Slack、Calendar、Drive、Linear、Jira 這些系統，資訊又被拆散到不同工具裡。

OpenHuman 的思路是：先把這些資料接進來，再透過自動抓取、壓縮、摘要和本機知識庫，構建一個可以持續更新的個人記憶層。這樣 agent 不是只記得當前對話，而是能圍繞你的工作流形成長期上下文。

這也是它和普通聊天機器人最大的差異。聊天機器人往往圍繞 prompt 工作；OpenHuman 更像一個桌面端個人操作系統入口，試圖把連接器、記憶、工具和模型路由都預先打包。

主要能力

OpenHuman README 裡列出的核心能力包括：

桌面優先的 UI 和較短的上手路徑，不要求使用者先從終端設定開始。
一個帶「臉」的桌面 mascot，可以說話、響應環境，並參與 Google Meet。
118+ 第三方整合，覆蓋 Gmail、Notion、GitHub、Slack、Stripe、Calendar、Drive、Linear、Jira 等工具。
自動抓取機制：專案描述中提到每 20 分鐘遍歷活躍連接，把新資料拉入 memory tree。
Memory Tree：把連接資料和活動資訊壓縮成 Markdown 區塊，並存入本機 SQLite。
Obsidian-compatible vault：把知識區塊落成 .md 檔案，使用者可以用 Obsidian 打開、瀏覽和編輯。
內建搜尋、網頁抓取、編碼工具、檔案系統、git、lint、test、grep、語音輸入輸出等能力。
Model routing：按任務把請求路由到不同模型類型。
TokenJuice：在工具結果、網頁抓取、郵件正文、搜尋結果進入 LLM 前做 token 壓縮。
可選 Ollama，用於本機 AI 工作負載。

這些能力聽起來很多，真正的重點可以歸納成兩條：一是減少設定和外掛拼裝；二是把你的個人資料變成 agent 可檢索、可壓縮、可持續更新的記憶。

安裝方式

專案提供網站下載入口，也給了終端安裝命令。

macOS 或 Linux x64：

`1`	`curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh \| bash`

Windows：

`1`	`irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 \| iex`

如果是日常主力機，建議先從官網下載安裝包，或者至少先打開安裝腳本檢查內容，再決定是否直接執行遠端腳本。OpenHuman 涉及郵箱、文件、程式碼倉庫、日曆和本機檔案權限，安裝和授權都應該比普通小工具更謹慎。

開源和技術棧

OpenHuman 倉庫採用 GPL-3.0 license。倉庫語言占比顯示 Rust 為主，TypeScript 次之，另外還有 JavaScript、Shell、CSS 和 PowerShell。README 的貢獻說明要求 Node.js 24+、pnpm 10.10.0、Rust 1.93.0、CMake，以及平台相關桌面構建依賴。

本機開發的大致路徑是：

git submodule update --init --recursive
pnpm install
pnpm dev
pnpm --filter openhuman-app dev:app

提交前推薦跑 focused checks，例如：

1
2
3

pnpm typecheck
pnpm format:check
cargo check -p openhuman --lib

從目錄結構看，它不是一個輕量腳本專案，而是包含桌面應用、前端、Rust 後端、文件、測試、示例和構建腳本的完整產品型倉庫。

Memory Tree 和 Obsidian vault 為什麼重要

OpenHuman 裡最值得單獨看的概念是 Memory Tree。README 描述它會把連接進來的資料標準化成不超過約 3k token 的 Markdown chunks，打分後折疊進層級摘要樹，並存入本機 SQLite。相同內容也會進入 Obsidian 相容 vault。

這條路線有幾個好處：

使用者可以直接看到 agent 的知識庫，而不是只能相信黑盒記憶。
Markdown 檔案方便搜尋、備份、版本管理和人工修訂。
SQLite 適合本機索引和快速查詢。
層級摘要比一堆平鋪文件更適合長期上下文壓縮。

但它也有現實挑戰：資料同步是否穩定、摘要是否會丟關鍵細節、權限邊界是否足夠清晰、刪除和撤銷是否完整、不同連接器的語義是否能被一致處理。這些都不是 README 裡一句 “remembers everything” 就能解決的，需要長期使用和審計才能判斷。

TokenJuice：成本和延遲的中間層

OpenHuman 還強調 TokenJuice。它的作用是在網頁、郵件、搜尋結果和工具呼叫結果進入模型前做壓縮，例如把 HTML 轉成 Markdown、縮短長 URL、移除部分非必要字元等。README 宣稱這可以減少成本和延遲，最高降低 80% token 使用。

這個方向是合理的。Agent 系統真正燒錢的地方，往往不是一次聊天，而是後台抓取、工具呼叫、搜尋、網頁解析和長上下文注入。把資料先清洗再交給模型，通常比直接塞原始內容更穩。

不過壓縮層也會帶來新問題：它會決定哪些資訊被保留，哪些被丟棄。如果你用它處理合約、帳單、醫學記錄、合規材料或生產事故日誌，就不能只看 token 節省，還要看可追溯性、原文回查和壓縮誤差。

隱私：賣點也是審查重點

OpenHuman 的賣點之一是 private。官網提到本機 AI 模型可處理低階任務，README 也強調 workflow data stays on device、encrypted locally、treated as yours。

這類設計方向很吸引人，因為個人 AI Agent 一旦接入 Gmail、Drive、Calendar、Slack、GitHub，就會碰到最敏感的工作資料。相比完全雲端的助手，本機優先的記憶層和可見的 Markdown vault 至少給了使用者更多控制感。

但也要把話說完整：OpenHuman 同時提到 one subscription、30+ providers、model routing、ElevenLabs TTS、OAuth integrations 等能力。這意味著它不是純離線工具。真正評估隱私時，需要看每個連接器、每類模型呼叫、每個語音和搜尋能力分別把什麼資料送到哪裡。

適合誰關注

OpenHuman 現在更適合三類人：

想要個人 AI 操作台，而不是單點聊天機器人的使用者。
願意嘗試 Early Beta，並能接受功能變化和粗糙邊緣的開發者。
關注本機記憶、Obsidian 工作流、agent connector 和上下文壓縮的人。

如果你只是想找一個穩定、輕量、隱私邊界極簡的離線助手，那它目前可能太重。如果你想研究下一代個人 AI Agent 會如何整合桌面、連接器、記憶和工具，OpenHuman 則是一個值得跟蹤的開源樣本。

我的建議是先把它當成「產品型開源實驗」觀察：看 release 節奏、issue 品質、連接器權限、資料匯出能力、刪除機制和本機 vault 的可讀性。個人 AI 的關鍵不只是能不能回答問題，而是它是否能長期、透明、可控地承載你的上下文。

參考連結

Token Efficiency 是什麼？從 DeepSeek V4 看大模型規劃、小模型執行

Fri, 15 May 2026 08:59:33 +0800

AI 編程接下來真正重要的指標，可能不是誰的模型最強，而是誰能用更少 token、更低成本、更穩定的流程，完成更多可驗收的工作。

這就是 Token Efficiency 的價值。

很多人理解 Token Efficiency，只想到模型便宜、上下文變長、快取命中更低價。但這些只是底層條件。真正能把它變成生產力的，是模型分工、任務編排、上下文預算和評估體系。

換句話說，Token Efficiency 不是省錢技巧，而是一套把 token 轉換成產出的工程方法。

DeepSeek V4 的定位：把大小模型分工產品化

DeepSeek V4 不是單純發布一個更強模型，而是把 Token Efficiency 需要的兩層能力拆成 V4 Pro 和 V4 Flash。V4 Pro 更適合規劃、推理、架構判斷和關鍵審查；V4 Flash 更適合高頻執行、批量改寫、程式碼補全、資料整理和 agent 循環裡的普通節點。

這正好對應 AI 編程裡的兩個角色：

V4 Pro：作為 planner / consultant，用在需求拆解、技術方案、複雜 bug 根因、架構審查和最終驗收。
V4 Flash：作為 executor，用在檔案掃描、簡單實作、測試補齊、文件整理、候選方案生成和重複性任務。

DeepSeek 官方 API 文件顯示，V4 Flash 和 V4 Pro 都支援 1M 上下文、JSON Output、Tool Calls、Chat Prefix Completion 和 FIM Completion；價格頁也把快取命中輸入單獨計價，並說明全模型 input cache hit 價格已降到發布價的十分之一。

1M 上下文解決複雜 agent 任務容易被壓縮的問題；低快取命中價格降低長 system prompt、專案文件、程式碼片段和歷史狀態反覆進入上下文的成本；Flash / Pro 雙模型形態解決「每一步都用旗艦模型太貴、每一步都用小模型又不穩」的分工問題。

所以 DeepSeek V4 的優勢不只是便宜或上下文長，而是執行層便宜、判斷層可用、長鏈路友好。它給「顧問模型 + 執行模型 + harness 編排」提供了更現實的成本結構。

不要讓最強模型幹所有活

過去使用 AI，常見做法是找最聰明的模型，讓它從需求分析、程式碼實作、測試、總結一路幹到底。

這很簡單，但不一定高效。很多任務不需要最高等級推理能力。真正昂貴的模型，更應該像顧問、架構師或規劃員，只在關鍵決策點介入。

更合理的結構是：

大模型負責拆問題、定方向、做關鍵判斷。
小模型負責執行、批量處理、重複修改。
工具和 harness 負責流程、狀態、上下文和驗證。
人負責定義產品、驗收結果和決定取捨。

這樣前沿推理能力不會被浪費在機械執行上。

上下文不是越大越好

長上下文對 coding agent 很重要，因為程式碼、文件、歷史對話、測試輸出和錯誤日誌都會吃掉上下文。上下文接近上限後，模型容易壓縮、遺忘或誤判。

但長上下文不等於可以無限塞資料。

Token Efficiency 的關鍵，是讓每個任務都能在清楚、可控的上下文窗口內完成：

只帶必要檔案。
背景文件只帶決策相關部分。
歷史資訊只保留當前階段需要的狀態。
每個節點有明確輸入和輸出。
完成後把結果壓縮成結構化摘要，交給下一個節點。

上下文越便宜，越要警惕浪費。噪音不會讓模型更聰明。

Harness 比單個模型更重要

如果只是把 Claude Code、Codex 或其他 coding agent 接到便宜模型上，效果未必好。小模型容易在長鏈路任務裡跑偏，需要更強流程控制。

真正讓小模型發揮價值的是 harness。它像一套調度系統，決定任務怎麼拆、節點怎麼跑、模型怎麼選、結果怎麼驗收、失敗怎麼重試、上下文怎麼傳遞。

沒有這層軟體，小模型只是便宜；有了這層軟體，小模型才可能變成槓桿。

用 DAG 拆任務

一個有效思路，是把複雜任務拆成有向無環圖，也就是 DAG。

例如功能開發可以拆成需求澄清、方案設計、任務拆分、編碼實作、測試補齊、Code Review、修復問題、提交 PR。

每個節點都可以是獨立 agent，有自己的角色、prompt、工具權限和輸出格式。節點之間不靠長篇聊天傳遞資訊，而是靠預先定義好的結構化結果。

這讓單個節點更短，也讓流程更可測。

任務可以跑多個副本

當 token 足夠便宜，同一任務不一定只跑一次。可以讓同一任務用不同模型、不同 prompt、不同編排跑多個副本，再選最好結果或合併有效部分。

適合多副本的任務包括方案設計、文案生成、測試用例補全、bug 根因假設、重構方案比較和 Code Review。不適合盲目多副本的，是會修改共享狀態、產生外部副作用或驗收標準不清楚的任務。

多跑幾次不是碰運氣，而是獲得可比較樣本，反過來優化編排、模型選擇和節點技能。

必須建立評估體系

Token Efficiency 不能只看價格。便宜但失敗率高，最後會吞掉人的時間。

可以先記錄任務完成率、人工介入次數、工具調用失敗率、測試通過率、review 問題數、單任務 token 成本、耗時、返工次數和不同模型組合差異。

有了這些資料，才知道哪些任務適合小模型，哪些必須上大模型，哪些應該交給人判斷。

業務流程要原子化

普通使用者不一定要自己寫完整 harness，但可以先把業務流程拆成原子節點。

內容生產可以拆成選題、資料收集、提綱、初稿、事實核查、風格改寫、SEO 標題、多語言翻譯、發布檢查。

軟體開發可以拆成需求確認、技術方案、資料結構、介面變更、單元測試、實作、遷移腳本、文件、Review。

每個節點都要盡量做到輸入明確、輸出明確、驗收明確、上下文可控。這樣等 harness 工具成熟時，流程可以直接接上。

硬體不是第一優先級

很多人聊 Token Efficiency，很快就聊到本地部署和顯卡。但對大多數人來說，第一選擇仍然應該是 API。

在沒有跑通經濟模型前，本地硬體只是成本前置。更穩的順序是：先用 API 跑通流程，建立評估和成本統計，找到穩定高頻節點，再考慮哪些值得本地化，最後計算硬體、電費、維護和折舊。

小結

Token Efficiency 的本質，不是用便宜模型替代貴模型，而是重新設計 AI 工作流。

大模型負責關鍵判斷，小模型負責批量執行，harness 負責調度和驗證，人負責定義目標和驗收結果。只有這四層配合起來，token 才能穩定變成生產力。

未來的差距，很可能不在誰調用了最強模型，而在誰能用同樣的 token 撬動更多真實產出。

Superpowers：把 Coding Agent 拉回工程流程的技能框架

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers 是一個給 coding agent 使用的技能框架，也是一套軟體開發方法論。它的目標不是再寫一個萬能 prompt，而是把 agent 的工作流程固定下來：先澄清目標，再產出設計，再拆計畫，再按測試驅動開發推進，最後做 review 和收尾。

專案地址：https://github.com/obra/superpowers

寫作時，GitHub API 顯示這個倉庫已有超過 19 萬 star，授權為 MIT，最近仍在更新。README 對它的描述很直接：An agentic skills framework & software development methodology that works.

它想解決什麼問題

現在很多 AI 編程工具的問題，不是「不會寫程式碼」，而是太容易直接寫程式碼。

使用者剛說一個模糊需求，agent 就開始改檔案；改完看似完成，其實邊界沒對齊、測試沒補、架構沒想清楚。短任務可能沒事，複雜專案裡就會變成返工和技術債。

Superpowers 的思路是：讓 agent 在動手前先進入流程。

README 描述的核心路徑大致是：

發現使用者要做東西時，先追問目標。
從對話中整理規格，分段給使用者確認。
設計通過後，生成清楚的實施計畫。
使用者說 “go” 之後，再進入實作。
實作時強調 TDD、YAGNI、DRY，並透過 review 檢查結果。

這套流程不新，但放到 coding agent 裡很關鍵。AI 的執行速度越快，前置澄清和中途驗證越重要。

支援哪些工具

Superpowers 不是只面向一個 agent。README 列出的安裝入口包括 Claude Code、Codex CLI、Codex App、Factory Droid、Gemini CLI、OpenCode、Cursor 和 GitHub Copilot CLI。

這說明它更像跨 harness 的工作流層，而不是綁定某一家模型或某一個命令列工具。

基礎工作流

第一步是 brainstorming。它會在寫程式碼前觸發，透過問題把粗糙想法整理成可執行設計，並分段確認。

第二步是 using-git-worktrees。設計確認後建立隔離工作區和新分支，先確認安裝和測試基線乾淨。

第三步是 writing-plans。把設計拆成短小任務，每個任務有明確檔案路徑、程式碼範圍和驗證步驟。

第四步是實作。可以用 subagent-driven-development 派發子任務，也可以用 executing-plans 分批執行。重點是每個任務都能檢查、review、繼續推進。

第五步是 test-driven-development。它強調真正的 RED-GREEN-REFACTOR：先寫失敗測試，確認失敗，再寫最小實作，確認通過，然後重構。

第六步是 requesting-code-review。任務之間做 review，Critical 問題會阻塞繼續推進。

最後是 finishing-a-development-branch。任務結束後驗證測試，給出合併、發 PR、保留或丟棄 worktree 的選擇。

Skills Library 裡有什麼

測試類主要是 test-driven-development。

除錯類包括 systematic-debugging 和 verification-before-completion，要求先復現、最小化、提出假設、驗證，再修復；也要求沒有驗證前不要宣布完成。

協作類包括：

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

元技能包括 writing-skills 和 using-superpowers。這些技能組合起來，像是給 agent 裝上一套工程習慣。

和普通 prompt 最大的區別

普通 prompt 往往把規則堆在一段 system prompt 裡：不要亂改、先思考、要測試、要簡潔。規則越堆越多，複雜任務裡模型越容易選擇性遺忘。

Superpowers 更像把規則拆成可觸發的流程模組。不同任務階段使用不同技能，每個技能只負責一段工作。這讓規則更短、目標更集中，也讓複雜流程能被檢查。

它最值得參考的地方是：不要只追求更聰明的模型，還要給模型一套可重複的工作方式。

適合誰用

Superpowers 更適合已經在真實專案裡使用 coding agent 的開發者，尤其是任務不只單檔修改、希望 agent 先設計再實作、需要 TDD 或驗證、常常並行多個分支、想把團隊流程寫成可重用技能的場景。

如果只是改一行設定，它可能偏重。但一旦任務涉及多檔案、多階段、多輪確認，流程約束就會變得有價值。

使用時要注意什麼

不要把它理解成自動駕駛。Superpowers 能讓 agent 更有流程感，但需求邊界、設計取捨和最終驗收仍然需要人負責。

TDD 和 review 會增加前期成本。小任務可能變慢，但複雜任務通常能減少返工。

子代理並行不是越多越好。它適合邊界清楚、寫入範圍不重疊的任務；如果需求還沒想清楚，並行只會放大混亂。

團隊也要維護自己的技能品質。過時流程、模糊指令和互相衝突的規則，都會拖累 agent。

小結

Superpowers 的價值，不在於某個單獨技能多神奇，而在於它把 coding agent 從「接到需求就寫程式碼」拉回軟體工程流程。

AI 編程真正缺的往往不是生成速度，而是澄清、計畫、驗證、review 和收尾。模型越強，這些流程越不能省。

如果你已經在用 Codex、Claude Code、Cursor 或 Gemini CLI 做真實專案，Superpowers 值得看一眼。即使不直接安裝，它的技能拆分方式也很適合拿來改造自己的 agent 工作流。

Codex /goal vs Claude Code /goal：讓長任務自動跑到完成

Thu, 14 May 2026 22:25:31 +0800

/goal 正在變成 AI 編程工具裡的一個重要命令。

它解決的不是「讓模型多寫幾行程式碼」，而是另一個更實際的問題：當任務有明確完成條件時，能不能讓 Agent 持續推進，直到條件滿足，而不是每完成一輪就停下來等使用者繼續催。

Codex CLI 已經在官方文件裡加入了實驗性的 /goal。Claude Code 也上線了自己的 /goal 文件，而且把它描述成一種可以跨多輪持續工作的自動化能力。兩者名字一樣，但產品取向並不完全一樣。

`/goal` 到底解決什麼問題

普通 AI 編程對話通常是「一問一答」：

使用者提出任務。
Agent 分析、改程式碼、跑測試。
Agent 回報結果。
使用者再決定下一步。

這個流程適合短任務，但遇到遷移、重構、測試修復、issue backlog 清理時，就會變得很碎。Agent 可能每次只推進一小段，然後停下來等你輸入「繼續」。

/goal 的思路是把任務從「下一步做什麼」改成「最終什麼狀態算完成」。例如：

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

這類目標天然適合長任務，因為它有清楚的終點：測試通過、建置成功、檔案拆分完成、佇列清空、驗收條件滿足。

Codex 的 `/goal`：實驗功能，綁定目前執行緒

OpenAI 的 Codex CLI 文件把 /goal 標為實驗功能。它不是預設穩定能力，需要先開啟 features.goals。

開啟方式有兩種：

`1`	`/experimental`

或者在 config.toml 裡加入：

1
2

[features]
goals = true

啟用後，可以這樣使用：

`1`	`/goal Finish the migration and keep tests green`

常用命令包括：

/goal
/goal pause
/goal resume
/goal clear

按照 OpenAI 文件的說法，Codex 會把 goal 附著在目前 active thread 上，在更大的任務執行過程中持續追蹤這個目標。

這裡要注意一個細節：官方文件對 Codex /goal 的措辭比較克制。它強調「給長任務設定實驗性目標」「把目標附著到目前執行緒」，但沒有像 Claude Code 文件那樣展開說明每一輪結束後由獨立 evaluator 自動判斷並繼續下一輪。所以現在使用 Codex /goal 時，最好仍把它看作實驗中的長任務目標機制，而不是完全穩定的無人值守執行模式。

Claude Code 的 `/goal`：完成條件驅動的多輪執行

Claude Code 的 /goal 文件寫得更明確：使用者設定 completion condition 後，Claude 會跨 turn 持續工作，直到條件滿足。

示例：

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code 的機制大致是：

目前 turn 完成後，不直接把控制權還給使用者。
一個小型快速模型會檢查目標條件是否已經滿足。
如果沒有滿足，Claude 自動開始下一輪。
如果滿足，goal 自動清除，並在 transcript 裡記錄完成狀態。

這意味著 Claude Code 的 /goal 更像「按完成條件自動續跑」。它不只是把目標掛在會話裡，而是把「是否繼續下一輪」交給一個獨立評估步驟。

Claude Code 還支援直接查看狀態：

/goal

狀態裡會顯示目標條件、執行時間、已評估 turn 數、token 消耗，以及 evaluator 最近一次給出的原因。

如果要提前停止，可以使用：

`1`	`/goal clear`

stop、off、reset、none、cancel 也可以作為清除別名。開啟目標後，如果會話中斷，之後透過 --resume 或 --continue 恢復時，仍然 active 的 goal 可以被帶回來；但計時、turn 數和 token 基線會重新計算。

兩者最大的差異

Codex 和 Claude Code 都在把 AI 編程從「單輪回答」推向「長任務執行」，但 /goal 的定位有差異。

對比項	Codex CLI `/goal`	Claude Code `/goal`
狀態	experimental	官方文件單獨成頁說明
啟用方式	需要開啟 `features.goals`	可直接在受信任 workspace 使用
目標作用域	目前 active thread	目前 session
常用操作	set / view / pause / resume / clear	set / view / clear
自動判斷	文件強調目標附著與追蹤	明確說明每輪後由 evaluator 判斷
自動續跑	文件表述較克制	條件未滿足時自動下一輪
適合場景	想在 Codex 長任務裡保持目標上下文	想按完成條件讓 Claude Code 持續推進

簡單說，Codex 的 /goal 更像「給目前執行緒掛一個實驗性的長期目標」；Claude Code 的 /goal 更像「給目前會話設定一個可驗證的停止條件，讓它自動做到滿足為止」。

寫好 `/goal` 的關鍵

不管使用哪一個工具，/goal 都不適合寫成模糊願望。

不太好的寫法：

`1`	`/goal 把项目优化一下`

更好的寫法：

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

一個好目標通常包含三點：

明確的完成狀態。
可執行的驗證方式。
必須遵守的邊界。

如果目標太大，還應該加上停止條件：

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

這很重要。/goal 越強，越需要邊界。否則 Agent 可能會為了追求「完成」而改動過多檔案、跑太久、消耗太多 token，甚至把原本該停下來詢問的問題繼續往前推。

什麼時候適合用 `/goal`

適合：

測試修復：直到指定測試通過。
程式碼遷移：直到所有呼叫點改完並編譯成功。
批量清理：直到某類 lint 或型別錯誤清零。
文件補齊：直到所有指定模組都有說明。
issue 佇列處理：直到某個標籤下的問題都被處理或明確分類。

不適合：

需求本身還沒想清楚。
需要頻繁產品判斷。
涉及高風險刪除、資料遷移或權限變更。
驗收條件只能靠主觀判斷。
任務會跨越大量無關模組。

一個實用原則是：如果你能寫出「跑哪個命令、看到什麼結果、哪些檔案不能碰」，就適合用 /goal。如果只能寫「幫我做得更好」，那還是先用普通對話、計畫模式或人工評審更穩。

對 AI 編程工具的影響

/goal 代表一個很明顯的方向：AI 編程工具正在從「互動式助手」變成「可持續執行的工作單元」。

過去我們讓 Agent 做任務，經常要在旁邊守著。它卡住了要提示，測完了要繼續，報錯了要再下命令。/goal 把這部分互動壓縮成一個完成條件，讓 Agent 自己決定下一輪該做什麼。

但這也帶來新的要求。以後寫 prompt 不只是描述任務，還要寫驗收條件、驗證命令、修改邊界和停止規則。換句話說，使用者的工作從「催它繼續」變成「定義什麼叫完成」。

Codex 和 Claude Code 走到 /goal 這一步，說明長任務 Agent 已經不再只是背景任務或雲端佇列的專利。終端裡的本地編程工具，也開始需要更強的自主推進能力。

總結

Codex CLI 和 Claude Code 都有了 /goal，但現階段不要把它們簡單看成同一個功能。

Codex 的 /goal 仍是實驗能力，需要開啟 features.goals，更適合在 Codex 目前執行緒裡維持長期目標。Claude Code 的 /goal 則更明確地把「完成條件」和「自動續跑」連在一起，透過獨立 evaluator 判斷是否繼續。

對日常開發來說，這類命令最適合處理有明確驗收標準的工程任務。它不會替代需求判斷，也不會消除程式碼審查，但能減少長任務裡大量重複的「繼續」「再跑一次」「修到測試通過」。

真正要學會的不是某個命令本身，而是如何把任務寫成清楚、可驗證、可停止的目標。

參考資料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal 文件：https://code.claude.com/docs/en/goal

AI 編程工具這一輪，DeepSeek 為何成了省錢關鍵？

Mon, 11 May 2026 04:59:00 +0800

這一輪 AI 編程工具的競爭，表面上是在比模型能力、插件生態和 agent 自動化程度，真正用起來以後，最先撞上的問題卻是成本。

Claude Code、Codex、OpenClaw、Superpowers 這類工具都很好用，但它們有一個共同特點：一旦進入複雜任務，就會非常吃 token。它們要讀項目、建計劃、調用工具、總結上下文、反覆檢查結果，還可能拉起多個子任務。模型越聰明，工作流越自動化，帳單也越容易悄悄變大。

所以 DeepSeek 在這一輪裡變得很關鍵，不只是因為它能寫程式碼，而是因為它在長上下文和快取成本上，剛好打中了 AI 編程工具最燒錢的地方。

Agent 工具為什麼特別費 token

傳統聊天式編程助手，通常是一問一答。你問一個函式怎麼寫，它回答一段程式碼。這個模式消耗不小，但還算可控。

Agent 工具不一樣。它不是只回答問題，而是要像一個臨時工程師一樣進入項目：

先掃描目錄和關鍵檔案；
再理解需求和現有架構；
然後制定計劃；
修改檔案；
執行命令或測試；
根據報錯繼續修；
最後總結改了什麼。

這個過程裡，模型反覆讀取同一批上下文。項目說明、程式碼片段、工具結果、歷史對話、計劃和錯誤日誌都會被塞回上下文。任務稍微複雜一點，幾十萬 token 很快就出去了。

如果再裝一些更激進的插件，成本會更明顯。比如有些 OpenCode 或 Claude Code 增強工具，會預設組織一整套 agent 團隊。你只是想改一個小功能，它也可能啟動規劃、審查、執行、復盤等多個環節。任務當然顯得更「智慧」，但 token 也會一路往上跑。

Superpowers 的好處是按需觸發

Superpowers 這類工具的一個優點，是它不會在所有任務裡都強行拉起完整 agent 流程。

平時你還是可以讓 Claude Code、OpenCode 或 Codex 按原來的方式工作。只有當你明確調用某個 skill，比如頭腦風暴、寫計劃、執行計劃、做復盤時，它才進入更重的自動化流程。

這對成本很重要。

AI 編程不應該所有任務都用重武器。改一行設定、查一個報錯、寫一個小腳本，用普通對話就夠了；只有複雜重構、跨檔案修改、長文件處理、多輪驗證，才值得上完整 agent 流程。

工具越強，越要學會控制觸發條件。否則自動化越多，浪費越多。

DeepSeek 的關鍵優勢是快取便宜

DeepSeek 適合接這類 agent 工具，一個很重要的原因是快取命中成本低。

AI 編程任務裡有大量重複前綴。比如專案背景、系統提示詞、工具說明、檔案內容、前幾輪對話，經常會在後續請求裡反覆出現。如果模型服務支援 prompt cache，這些重複內容命中快取後，成本會明顯下降。

很多模型的快取命中價只是比未命中便宜一些，比如便宜到三分之一左右。DeepSeek 的優勢在於，命中快取後的價格差距可以大很多。對長上下文、多輪調用、重複讀取項目的 agent 工作流來說，這個差距會直接反映到帳單上。

也就是說，DeepSeek 不是每一次回答都一定最強，而是在「長任務、多輪任務、反覆讀上下文」的場景裡，成本結構特別適合 AI 編程。

長上下文讓 Claude Code 更好用

把 Claude Code 或類似工具接到 DeepSeek V4 時，另一個明顯優勢是長上下文。

AI 編程工具最怕上下文不夠。上下文一不夠，就要頻繁壓縮；壓縮一多，前面讀過的細節就可能丟失。模型開始忘記專案結構、忘記約束、忘記某個檔案為什麼這麼改，後續品質就會下降。

DeepSeek V4 系列的長上下文能力，讓它更適合處理程式碼倉庫、文檔批處理、字幕翻譯、站點文章整理這類任務。特別是接入 Claude Code、OpenClaw 這類工具時，如果配置得當，可以讓它盡量晚一點進入上下文壓縮，讓模型保留更多專案細節。

這也是為什麼有些任務用 DeepSeek 會顯得「很耐用」：它不一定每一步都驚艷，但能承受長時間、低成本、反覆調用。

V4 Pro 和 V4 Flash 怎麼分工

DeepSeek V4 Pro 和 V4 Flash 不應該混著用。

簡單任務用 DeepSeek V4 Flash 更合適。它速度快、成本低，用在下面這些場景通常足夠：

翻譯字幕；
整理文檔；
生成普通腳本；
修改小範圍程式碼；
跑 OpenClaw 裡的輕量任務；
做簡單的站點內容處理。

複雜任務再考慮 DeepSeek V4 Pro：

大規模重構；
多模組程式碼理解；
複雜推理；
長鏈路 agent 任務；
高風險程式碼修改；
需要更強規劃能力的工程任務。

很多人一上來就想掛最強模型，這反而不划算。AI 編程工具最現實的玩法，是把任務分層：便宜模型吃掉大量常規工作，貴模型只處理關鍵節點。

MiniMax、豆包和 DeepSeek 的位置不同

國產模型和套餐裡，MiniMax、豆包、Kimi、DeepSeek 各有位置。

MiniMax 的優勢是量大、便宜、功能全。它未必是最聰明的編程模型，但拿來做翻譯、輕量整理、批處理，很划算。比如批量處理字幕、改格式、做簡單校對，MiniMax 這類套餐很耐用。

豆包的優勢是生態工具比較全，圖片、影片、搜尋、TTS、可能的 STT 和 embedding 都能接在一起。它更像綜合型工具箱。

DeepSeek 的位置更明確：文本、程式碼、長上下文、低成本快取。它沒有完整的圖像生成、語音、影片生態，短板很明顯；但在 AI 編程和長文本 agent 工作流裡，它的長板足夠長。

所以不是誰替代誰，而是任務拆開以後各用各的。

省錢的關鍵不是只找便宜模型

AI 編程想省錢，不是簡單把所有請求都換成便宜模型。

真正有效的省錢方式有幾條：

簡單任務不要啟動重 agent。
能用 Flash 的任務不要上 Pro。
長任務盡量利用快取。
重複上下文要穩定，避免無意義改動導致快取失效。
大任務先讓便宜模型做草稿和批處理，再讓強模型做關鍵審查。
明確告訴 agent 不要重複描述事實，不要反覆總結同一件事。

尤其是最後一點很重要。AI 工具很容易囉嗦，囉嗦不只是閱讀體驗問題，也是成本問題。提示詞裡明確要求「事實只描述一次，觀點只表達一次」，能同時改善文章品質和 token 消耗。

DeepSeek 適合哪類 AI 編程工作流

DeepSeek 最適合這些任務：

長程式碼倉庫閱讀；
多檔案輕量修改；
批量文檔整理；
批量字幕翻譯；
Hugo 文章整理；
agent 計劃執行；
大量重複上下文的低成本自動化。

它不一定適合所有任務。如果要做特別強的前端審美、複雜產品判斷、跨模態創作，可能還要搭配 Claude、GPT、Gemini、豆包或其他工具。

但只要任務是「長文本、長上下文、反覆調用、成本敏感」，DeepSeek 就很容易變成首選。

小結

AI 編程工具這一輪，DeepSeek 的價值不只是「國產模型能寫程式碼」，而是它解決了 agent 工具最現實的痛點：長任務太燒錢。

Claude Code、OpenClaw、Superpowers 這類工具會讓開發流程越來越自動化，但自動化的背後是大量上下文讀寫和多輪調用。誰能把這部分成本壓下來，誰就能讓 AI 編程從「偶爾爽一下」變成「天天用得起」。

DeepSeek 的長上下文、低快取成本和 V4 Flash / V4 Pro 分層使用，正好讓它站在這個位置上。

這一輪真正省錢的關鍵，不是不用好模型，而是把好模型、便宜模型、快取和 agent 流程搭配好。能把這套帳算明白，AI 編程工具才真的會變成生產力，而不是一個漂亮但昂貴的玩具。

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 框架。

參考資料

Claude Code 24 個使用技巧：計劃模式、回滾、CLAUDE.md、Skills、Agents 和插件

Fri, 08 May 2026 08:54:14 +0800

Claude Code 不只是一個聊天框。它更像一個能進入專案目錄、讀寫檔案、執行命令、維護上下文的編程 Agent。

如果只是把需求丟進去讓它生成程式碼，很快會遇到幾個問題：計劃不夠清楚、權限反覆確認、上下文越來越長、生成結果不滿意、不知道怎麼回滾，也不知道怎麼把專案規則長期保存下來。

下面整理一組常用操作，適合剛開始使用 Claude Code 的開發者快速建立工作流。

先在專案目錄啟動

Claude Code 最好在專案目錄裡啟動，而不是隨便打開一個終端就開始用。

可以先建立一個資料夾作為專案目錄，進入目錄後打開命令列，再啟動 Claude Code：

claude

首次進入專案時，如果 Claude Code 詢問是否信任目前資料夾，確認後再繼續。這樣它才能圍繞目前專案讀取檔案、建立檔案和執行後續操作。

一個簡單的練習方式是讓它建立一個攝影師個人網站。這個任務足夠直觀：能看到頁面效果，也能練習檔案生成、命令執行、回滾和後續重構。

計劃模式先把方向想清楚

Claude Code 在面對較複雜任務時會進入計劃模式。計劃模式的作用是先討論需求、拆解步驟，再讓使用者決定是否批准執行。

當它給出計劃後，通常會出現幾類選擇：

批准計劃，並允許後續自動使用編輯工具。
批准計劃，但後續編輯仍然需要手動確認。
暫停執行，繼續和 Claude Code 討論計劃。

如果任務比較明確，可以批准計劃並繼續。如果任務還不清楚，建議先讓它繼續補充方案，比如頁面風格、技術棧、目錄結構、互動效果和驗收標準。

計劃模式的好處是減少返工。直接讓 Agent 動手，可能很快生成一堆檔案；但如果方向錯了，後面越改越亂。

用 Shift + Tab 切換模式

在 Claude Code 中，可以用 Shift + Tab 在不同工作模式之間切換。常見用途是進入計劃模式，或者切換到自動同意編輯工具的模式。

建議的習慣是：

新專案、新功能、大改動：先進入計劃模式。
小改動、明確修復：可以直接執行。
涉及刪除、批量替換、安裝依賴：保持人工確認。

計劃模式下，Claude Code 可能會主動詢問專案細節。可以用方向鍵選擇選項，用回車確認。提交回饋後，它會根據你的選擇更新計劃。

權限確認不要一律放開

Claude Code 執行命令、編輯檔案或啟動程式時，可能會申請權限。

常見選擇包括：

只同意本次使用。
在目前會話中以後都同意同類命令。
拒絕或暫停。

如果只是啟動本地頁面、運行開發伺服器、查看檔案，可以根據需要允許。但不要為了省事長期使用「自動同意所有權限」的啟動方式。

全自動權限適合非常確定、風險很低、專案已經有 Git 備份的場景。日常使用中，涉及刪除檔案、覆蓋目錄、安裝依賴、聯網、提交程式碼、執行腳本時，最好保留人工確認。

用終端模式執行本地命令

Claude Code 裡可以進入終端命令模式，直接執行一些本地命令。

例如頁面生成後，可以用系統命令打開 HTML 檔案：

`1`	`start index.html`

這裡的 start 是 Windows 下打開檔案的命令，後面接檔名。這樣可以快速查看生成頁面，而不用手動去資源管理器裡找檔案。

終端模式適合執行這些輕量操作：

打開生成的頁面。
查看目錄內容。
啟動本地開發伺服器。
運行測試或構建命令。

但高風險命令仍然要謹慎，比如遞歸刪除、移動目錄、批量覆蓋和修改系統環境。

回滾：結果不滿意時及時退回

如果 Claude Code 做出的頁面或程式碼不是你想要的，而且越改越亂，就應該及時回滾。

回滾功能可以把對話或程式碼退回到某個節點。常見選項包括：

同時回滾程式碼和對話。
只回滾對話。
只回滾程式碼。
把某個節點之前的內容壓縮成摘要。
取消操作。

更推薦在明顯走偏時選擇「同時回滾程式碼和對話」。這樣可以讓上下文和檔案狀態一起回到較乾淨的位置。

需要注意：Claude Code 的回滾通常只能覆蓋它透過內建工具建立或修改的檔案。如果檔案是透過外部命令生成的，未必能完整回滾。因此重要專案仍然要配合 Git 使用。

長提示詞用編輯器寫

複雜需求不要全擠在一行輸入框裡。

如果系統支援在文字編輯器中編輯長提示詞，可以打開編輯器，把需求寫完整後保存，再發送給 Claude Code。

長提示詞裡建議寫清楚：

目標是什麼。
使用什麼技術棧。
不要做什麼。
需要保留哪些檔案。
完成後如何驗證。
頁面或功能的驗收標準。

例如讓 Claude Code 把一個普通 HTML 頁面重構成更現代的技術棧時，不要只寫「重構一下」。可以說明希望使用元件化結構、保留視覺內容、增加響應式布局，並要求它運行構建檢查。

退出後用歷史恢復會話

如果中途需要退出 Claude Code，可以正常退出。之後回到同一個專案目錄，再次啟動：

claude

如果發現前面的記錄沒有直接顯示，可以使用歷史相關命令查看最近會話，並載入之前的會話。

這個功能適合中斷後繼續工作。不過不要把會話歷史當成唯一記憶。專案規則、技術棧、常用命令和注意事項，最好寫進專案檔案裡。

用 CLAUDE.md 保存專案規則

CLAUDE.md 是 Claude Code 很重要的記憶檔案。它通常放在專案根目錄，用來告訴 Claude Code 專案規則、技術棧、目錄結構和協作約束。

可以讓 Claude Code 初始化這個檔案：

/init

CLAUDE.md 適合記錄：

專案目標。
技術棧。
常用啟動、測試、構建命令。
目錄說明。
程式碼風格。
不允許執行的操作。
提交和部署規則。

每次對話時，Claude Code 會把這類規則作為上下文的一部分使用。你可以把它理解成「專案說明書」。

一個簡單驗證方式是：在 CLAUDE.md 裡加入一條明顯規則，然後再向 Claude Code 提問。如果回答遵循了這條規則，就說明它確實讀到了專案記憶。

用 @ 引用檔案

在輸入框中使用 @，可以選擇檔案或 Agent，把指定內容加入目前對話上下文。

這適合幾類場景：

讓 Claude Code 閱讀某個配置檔案。
讓它修改某個指定頁面。
讓它根據 CLAUDE.md 或其他文件繼續工作。
明確告訴它「只看這個檔案，不要猜專案結構」。

相比把檔案內容複製到輸入框裡，@ 引用更清楚，也更不容易漏內容。

查看和壓縮上下文

長時間對話後，上下文會越來越大。上下文太長時，模型可能變慢，也可能開始忽略早期細節。

可以使用上下文查看命令了解目前占用情況：

`1`	`/context`

如果上下文已經很長，可以壓縮歷史：

`1`	`/compact`

如果壓縮後效果仍然不好，可以考慮清空目前上下文：

/clear

清空上下文後，Claude Code 仍然可以透過專案檔案、CLAUDE.md 和目前目錄重新理解一部分專案情況，但不會保留完整對話歷史。

實用建議是：一個任務完成後就開新會話；專案級規則寫進 CLAUDE.md；臨時討論不要無限堆在一個聊天裡。

Skills：把固定流程做成說明書

Skills 可以理解為 Claude Code 的工作說明書。它不是一次性提示詞，而是一套可複用的任務流程。

例如你經常要生成週報，就可以建立一個週報 Skill，裡面寫清楚：

輸入需要哪些資訊。
輸出格式是什麼。
語氣和結構怎麼控制。
哪些內容必須保留。
哪些內容不能編造。

Skills 通常由 name、description 和具體指令組成。安裝到全域 Skills 目錄後，Claude Code 在遇到相關任務時可以識別並載入。

這適合處理重複工作：

週報。
程式碼審查模板。
文件整理。
圖片批次處理。
固定格式文章。
專案初始化流程。

如果你發現自己反覆複製同一段提示詞，就可以考慮把它做成 Skill。

Agents：把子任務交給獨立助手

Agents 和 Skills 不一樣。

Skill 更像說明書，告訴 Claude Code 怎麼做某類任務；Agent 更像一個獨立助手，可以在目前主會話之外執行任務，完成後把結果返回。

Agents 的價值在於隔離上下文。比如做程式碼巡檢時，可以建立一個唯讀 Agent，讓它只讀取專案並輸出報告，不直接修改檔案。這樣不會污染主會話，也能降低誤操作風險。

建立 Agent 時通常要考慮：

是專案級 Agent，還是使用者級 Agent。
是否需要 Claude Code 幫你生成配置。
允許哪些工具權限。
使用哪個模型。
是否保存記憶。
Agent 的提示詞是否足夠明確。

對於程式碼巡檢類 Agent，建議只給讀取權限，不給寫入權限。先讓它輸出報告，再由主會話決定是否修改程式碼。

插件：打包 Skills、Agents、MCP 和 Hooks

插件可以理解為更完整的能力包。它可能同時包含：

Skills
Agents
MCP
Hooks

相比單獨安裝一個 Skill，插件更適合成套能力。例如前端設計插件可能會把頁面審美、布局規則、元件習慣和相關 Agent 一起打包。

安裝插件時通常會有幾個位置選項：

如果是個人常用能力，可以放在使用者目錄；如果是團隊專案約定，可以放進專案目錄；如果只是臨時測試，放本地專案目錄更穩。

插件能明顯改善特定任務效果

在前端頁面生成這類任務裡，插件往往比裸提示詞更穩定。

例如同樣是「製作一個攝影師個人網頁」，只用普通提示詞可能生成一個能看的頁面；如果明確使用前端設計插件，頁面結構、視覺層次、間距、配色和整體完成度通常會更好。

這並不意味著插件能替代人工審美。更合理的用法是：先讓插件生成一個更好的初稿，再由人做細節微調。

一套更穩的 Claude Code 工作流

把上面這些技巧組合起來，可以形成一套比較穩的流程：

在專案目錄啟動 claude。
先用計劃模式討論需求。
批准計劃前確認技術棧和驗收標準。
涉及高風險操作時保留手動確認。
用終端模式執行本地預覽和測試。
結果走偏時及時回滾。
把專案規則寫進 CLAUDE.md。
長對話定期查看和壓縮上下文。
重複流程沉澱成 Skills。
巡檢、研究、分析類任務交給唯讀 Agents。
特定領域任務優先用插件。
重要專案始終配合 Git 提交點。

這樣使用 Claude Code，會比單純「發一句需求等它生成」穩定得多。

小結

Claude Code 的效率不只來自模型能力，也來自工作流控制。

計劃模式決定方向，權限確認控制風險，回滾減少返工，CLAUDE.md 保存專案規則，/context、/compact 和 /clear 管理上下文，Skills 複用固定流程，Agents 隔離複雜子任務，插件則把成套能力打包進專案。

真正好用的 Claude Code 工作方式，是讓它在清楚邊界內持續推進任務，而不是把整個專案一次性交給它自由發揮。

opencode、Claude Code、Codex 有什麼區別？開源 AI 編程工具使用指南

Fri, 08 May 2026 08:33:37 +0800

opencode 是 anomalyco 開源的 AI Coding Agent。它的定位很直接：讓開發者在終端裡使用一個可程式化、可擴充、可接入多家模型的程式碼助手。

如果把它和 Claude Code、Codex 放在一起看，三者解決的是同一類問題：讓 AI 進入真實程式碼庫，理解上下文，修改檔案，執行命令和測試。但它們的產品取向不一樣。

opencode 更強調開源、多模型和終端 TUI；Claude Code 更強調 Anthropic 模型生態和本地工程協作；Codex 則是 OpenAI 的 AI coding agent，可以在終端、IDE、Codex app 和雲端任務裡使用。

opencode 適合誰

opencode 更適合這幾類開發者：

想在終端裡完成程式碼修改、專案分析和工程任務的人。
希望 AI Coding Agent 不綁定單一模型提供商的人。
偏好開源工具，想自己審計、擴充或二次開發的人。
已經習慣 Neovim、TUI、命令列工作流的人。
希望以後用桌面端、行動端或其他客戶端遠端驅動同一個編碼代理的人。

它的重點不是做一個聊天視窗，而是把 AI 編程能力放進開發者原本使用的終端和專案目錄裡。

安裝方式

官方 README 提供了多種安裝方式。

# 直接安裝
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS 和 Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# 其他方式
mise use -g opencode
nix run nixpkgs#opencode

官方也提醒，安裝前最好先移除 0.1.x 之前的舊版本，避免舊版本殘留造成問題。

安裝腳本會按優先級選擇安裝目錄：

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

如果需要指定路徑，可以這樣寫：

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

桌面應用還在 Beta

除了命令列工具，opencode 也提供桌面應用，目前仍處於 Beta。可以從 GitHub Releases 或 opencode.ai/download 下載。

桌面端覆蓋這些平台：

平台	檔案
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` 或 `.AppImage`

macOS 和 Windows 也可以透過套件管理器安裝桌面端。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

兩種內建 Agent 模式

opencode 內建兩種 Agent，可以透過 Tab 鍵切換。

build 是預設模式，擁有完整開發權限，適合直接修改程式碼、執行命令和推進工程任務。

plan 是唯讀模式，更適合分析陌生程式碼庫、理解專案結構、制定修改方案。它預設拒絕檔案編輯，並且在執行 bash 命令前會詢問。

另外，opencode 還帶有一個 general 子 Agent，用於複雜搜尋和多步驟任務。使用者可以在訊息中輸入 @general 呼叫。

這個設計比較實用：真正動手前先用 plan 看清楚專案，需要改程式碼時再切到 build。對於大型倉庫，讀寫權限分開能減少誤操作。

Codex 是什麼

Codex 是 OpenAI 的 AI coding agent，用來幫助開發者寫程式碼、審查程式碼、修復 bug 和交付工程任務。

和單純的程式碼補全工具不同，Codex 更接近一個可以操作程式碼庫的 Agent。它可以在本地工具裡和你結對，也可以把任務委託到雲端執行。OpenAI 官方資料裡提到，Codex 可以透過 CLI、IDE、Codex app、ChatGPT/Codex 雲端等不同入口使用。

對開發者來說，Codex 的重點有幾處：

可以讀取程式碼庫、編輯檔案、執行命令和測試。
支援終端、IDE、應用和雲端等多種使用介面。
適合修 bug、寫功能、重構、遷移、程式碼審查和測試補齊。
更偏 OpenAI 帳號、模型和 Codex 產品體系。
雲端任務適合並行處理多個相對清晰的工程任務。

如果 opencode 更像一個開放的終端代理框架，Codex 更像 OpenAI 提供的一整套 AI 編程工作台：本地可以結對，雲端可以委託，團隊可以把它接入更長的工程流程。

三者核心區別

opencode、Claude Code、Codex 都是 AI 編程工具，但選擇時可以先看這幾個維度。

工具	核心定位	主要優勢	更適合
`opencode`	開源 AI Coding Agent	開源、多模型、TUI、客戶端/伺服器架構	想要開放工具鏈、可替換模型、偏終端工作流的開發者
`Claude Code`	Anthropic 的命令列編程工具	Claude 模型體驗、程式碼理解、長上下文、工程任務協作	已經使用 Claude/Anthropic 生態，希望本地推進程式碼任務的開發者
`Codex`	OpenAI 的 AI coding agent	CLI、IDE、Codex app、雲端任務、多 Agent 工作流	已經使用 ChatGPT/OpenAI，希望本地結對和雲端委託並用的團隊

簡單說，opencode 的關鍵詞是「開源和可替換」，Claude Code 的關鍵詞是「Claude 生態和本地工程代理」，Codex 的關鍵詞是「OpenAI 生態和多入口協作」。

和 Claude Code 的區別

opencode 的官方 FAQ 直接把 Claude Code 拿來對比。兩者能力上很接近，但差異主要在這幾處。

第一，opencode 是 100% 開源專案，程式碼託管在 GitHub，並使用 MIT license。

第二，opencode 不綁定單一模型提供商。它推薦 OpenCode Zen 提供的模型，但也可以搭配 Claude、OpenAI、Google 或本地模型。對開發者來說，這意味著模型成本、能力和可用性變化時，不必被某一個平台鎖住。

第三，opencode 內建可選的 LSP 支援。對程式碼補全、跳轉、診斷和專案理解來說，LSP 是非常關鍵的基礎能力。

第四，opencode 更強調 TUI。它由 Neovim 使用者和 terminal.shop 的建立者打造，產品重心明顯放在終端體驗上。

第五，opencode 採用客戶端/伺服器架構。也就是說，opencode 可以在你的電腦上執行，未來由 TUI、桌面端、行動端或其他客戶端來控制。TUI 只是其中一種前端形態。

什麼時候選 opencode、Claude Code 或 Codex

如果你已經在使用 Claude Code 或 Codex，opencode 不一定是立刻替換它們的工具。更合理的看法是：它提供了一個開源、可替換模型、偏終端的選擇。

可以優先考慮 opencode 的場景包括：

你希望 AI 編程工具盡量開源。
你不想把工作流綁定在某個模型供應商上。
你希望用同一個工具測試 Claude、OpenAI、Google 或本地模型。
你喜歡 TUI，不希望主要工作流被桌面應用或網頁應用打斷。
你關注客戶端/伺服器架構帶來的遠端控制能力。

可以優先考慮 Claude Code 的場景包括：

你主要使用 Claude 模型。
你重視長上下文、程式碼理解和複雜工程任務協作。
你希望在本地倉庫中持續推進修改、測試和重構。
你更信任 Anthropic 對 Claude Code 的預設產品體驗。

可以優先考慮 Codex 的場景包括：

你已經在使用 ChatGPT 或 OpenAI 帳號體系。
你希望同一個 coding agent 覆蓋終端、IDE、桌面應用和雲端任務。
你想把較清晰的 bug 修復、功能開發、遷移、測試補齊交給雲端並行處理。
你需要程式碼審查、背景任務、團隊協作和多 Agent 工作流。

如果你更看重官方閉環體驗、模型預設配置、企業管理和現成整合，Claude Code 或 Codex 可能更省心；如果你更看重可控性、開放性和 provider-agnostic，opencode 更值得關注。

需要注意的地方

opencode、Claude Code 和 Codex 都發展很快，GitHub release、安裝命令、桌面端檔名、模型可用性和方案權限都可能變化。實際安裝和選型前，最好直接查看各自官方 README、文件和發布頁面。

另外，它的桌面應用仍然標註為 Beta，不適合預設當作穩定生產工具。對於日常工程任務，終端版仍然是更主要的入口。

從工具趨勢看，opencode 代表的是 AI Coding Agent 的開放工具鏈方向：模型可以替換，客戶端可以替換，核心代理能力盡量開放。Codex 和 Claude Code 則更像模型公司把 coding agent 做成完整產品入口。對開發者來說，這兩條路線會長期並存。

參考連結

opencode GitHub：https://github.com/anomalyco/opencode
opencode 官網：https://opencode.ai
opencode 文件：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Warp 開源：從終端到 Agentic Development Environment

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp 是 Warp 的開源客戶端倉庫。Warp 官方現在把它定位為一個「從終端生長出來的 agentic development environment」，也就是以終端為基礎，但把 AI coding agent、程式碼庫索引、任務管理和開發工作流放進同一個環境裡。

這不是一個普通的終端模擬器開源倉庫。它更像是在回答一個問題：當 Claude Code、Codex、Gemini CLI 這類 agent 越來越常見時，終端本身要不要變成一個能調度、觀察和管理 agent 的開發環境？

Warp 的答案是：要。

這個倉庫現在是什麼狀態

截至 2026 年 5 月 7 日查看，warpdotdev/warp 是公開倉庫，GitHub 頁面顯示約 56k stars、4.1k forks。倉庫 README 說明，Warp 的客戶端程式碼已經開源，並歡迎社群貢獻。

倉庫的主語言是 Rust。GitHub 語言統計裡，Rust 占比超過 98%。這和 Warp 的定位一致：它不是網頁殼，而是一個跨平台的原生開發工具。

README 中有幾個資訊點很重要：

Warp 是一個 agentic development environment, born out of the terminal。
它可以使用內建 coding agent，也可以接入 Claude Code、Codex、Gemini CLI 等外部 CLI agent。
OpenAI 是新開源 Warp 倉庫的 founding sponsor。
倉庫中的 agentic management workflows 由 GPT models 驅動。
Warp UI framework 相關 crate 使用 MIT license，其餘程式碼使用 AGPL v3。

這些資訊說明，Warp 開源不是單純把一個終端放出來，而是把它作為「agent 工作流實驗場」來營運。

Warp 不只是終端

傳統終端主要解決三個問題：

啟動 shell。
執行命令。
顯示輸出。

Warp 早期的差異化，是讓終端更現代：命令區塊、補全、歷史、協作、UI 化互動、跨平台體驗。現在它的重心繼續往前走，開始圍繞 AI agent 組織開發流程。

從 README 看，Warp 不再只強調「更好用的 terminal」，而是強調：

內建 coding agent。
支援外部 CLI agent。
issue triage。
spec 編寫。
PR review。
contributor coordination。
可觀察的 agent sessions。

也就是說，Warp 想把終端從「你輸入命令的地方」，變成「你和多個 agent 一起工作的地方」。

Oz 和開源專案管理

README 裡多次提到 Oz。

Warp 的貢獻概覽頁面可以看到成千上萬個 Oz agents 在做 issue triage、寫 specs、實作改動、review PR。這個設計很有意思，因為它把 AI agent 從「幫個人寫程式碼」擴展到了「幫開源專案管理協作」。

傳統開源專案最難的不是寫程式碼，而是維護：

issue 太多，沒人分類。
bug 和 feature request 混在一起。
新貢獻者不知道哪些任務能做。
PR review 壓力大。
維護者很難持續跟進社群討論。

Warp 的思路是，讓 agent 先承擔一部分專案管理和協作工作。README 中還提到 Oz for OSS，這是面向維護者的合作計畫，用於把類似 agentic open-source management workflows 帶到其他開源倉庫。

這說明 Warp 的野心不只是終端產品本身，也包括探索 AI 時代開源維護的新模式。

倉庫結構和技術棧

從倉庫結構看，Warp 是一個大型 Rust 專案。

根目錄裡能看到：

app/：主應用相關程式碼。
crates/：核心 Rust crates。
assets/：資源檔案。
command-signatures-v2/：命令簽名相關內容。
docker/、script/、resources/、specs/ 等工程目錄。
.claude/、.warp/、.agents/skills 等 agent 相關配置。

WARP.md 裡給出了更詳細的工程說明。它提到 Warp 是 Rust-based terminal emulator，並使用一個自研 UI framework WarpUI。

主要模組可以粗略理解為：

app/：終端模擬、shell 管理、AI 整合、Drive、認證、設定、workspace 和 session。
crates/warp_core/：核心工具和平台抽象。
crates/editor/：文字編輯功能。
crates/warpui/ 和 crates/warpui_core/：自研 UI framework。
crates/ipc/：行程間通訊。
crates/graphql/：GraphQL client 和 schema。

WARP.md 還提到幾個架構特點：

Entity-Handle system。
模組化 workspace 結構。
macOS、Windows、Linux 跨平台，以及 WASM target。
AI integration，包含 Agent Mode、上下文感知和程式碼庫索引。
Warp Drive 雲端同步。

這說明 Warp 的複雜度已經接近一個完整 IDE，而不是傳統意義上的輕量 terminal。

本地建置方式

README 給出的本地建置方式很簡潔：

1
2
3

./script/bootstrap
./script/run
./script/presubmit

其中：

./script/bootstrap：執行平台相關初始化。
./script/run：建置並執行 Warp。
./script/presubmit：執行格式化、clippy 和測試等提交前檢查。

WARP.md 裡還列出了更細的命令：

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

如果要給 Warp 提交程式碼，./script/presubmit 基本是必須跑的。

貢獻流程

Warp 的貢獻流程不是簡單「發 PR 就行」。

README 描述了一個從 issue 到 PR 的輕量流程：

先搜尋已有 issue。
沒有重複再提交 bug 或 feature request。
維護者會 review issue，並可能打上 readiness label。
ready-to-spec 表示設計可以被貢獻者展開成 spec。
ready-to-implement 表示設計已相對明確，可以開始寫程式碼 PR。
貢獻者可以認領帶標籤的 issue。

這個流程適合大型開源專案。它把「想法」「設計」「實作」拆開，減少貢獻者一上來就寫錯方向的風險。

對 AI agent 來說，這也很適合。agent 可以先整理 issue、寫 spec、補測試，再進入實作。Warp 自己也在用這種方式展示 agentic project management。

授權：MIT + AGPL v3

Warp 採用雙授權結構。

README 說明：

Warp UI framework，也就是 warpui_core 和 warpui crates，使用 MIT license。
倉庫其餘程式碼使用 AGPL v3。

這點很重要。AGPL v3 對網路服務和分發有更強的開源要求。如果你只是學習、研究、貢獻程式碼，問題不大；但如果想把 Warp 程式碼用於商業產品或閉源衍生專案，就必須認真讀 license，必要時諮詢法律意見。

簡單說，Warp 是開源了，但不是「隨便拿去閉源商用」的寬鬆授權。

值得關注的地方

第一，Warp 把終端、agent、專案管理放在一起。

很多 AI coding 工具仍然是 CLI 或編輯器外掛。Warp 試圖從終端入口出發，把 agent 任務、程式碼執行、命令輸出、PR 工作流和團隊協作整合起來。

第二，Warp 的開源方式很適合觀察 agent 工作流。

它不只是發布程式碼，還把貢獻概覽、agent session、issue triage 和 spec 流程公開出來。對於想研究 AI 如何參與開源協作的人，這個倉庫本身就是樣本。

第三，Warp 是一個複雜 Rust 桌面應用。

如果你想學習 Rust GUI、終端模擬器、跨平台應用、GraphQL client、雲端同步和 AI 整合，Warp 倉庫有不少可看的結構。但它不是小專案，新貢獻者需要先讀文件和 issue 流程。

第四，Warp 支援「自帶 agent」和「bring your own CLI agent」兩條線。

這點很現實。開發者不會只用一個 agent。Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 等工具會長期共存。Warp 如果能成為它們的工作台，就比單一終端更有價值。

適合誰關注

如果你是普通終端使用者，關注 Warp 的意義在於：終端可能正在從命令列工具變成 AI 工作台。

如果你是 AI coding agent 重度使用者，Warp 值得關注，因為它試圖管理多個 agent，而不是只做一個聊天入口。

如果你是開源維護者，可以關注 Oz for OSS 這條線。它試圖用 agent 做 issue triage、PR review、社群協作和貢獻者引導。

如果你是 Rust 開發者，Warp 是一個大型真實桌面應用樣本，可以研究它如何組織 UI、終端、雲端同步、AI 整合和跨平台程式碼。

如果你只是想找一個能馬上替代傳統終端的工具，建議先下載正式版使用，再決定是否研究源碼。直接從源碼建置更適合貢獻者和深度玩家。

簡短判斷

Warp 開源的重點，不只是「一個現代終端開源了」。

更準確地說，Warp 正在把終端升級成 agentic development environment：終端負責連接 shell、程式碼庫、命令執行、agent、issue、PR 和協作流程。

在 AI coding agent 持續增長的背景下，開發環境的入口可能會發生變化。過去是 IDE 統治開發體驗，終端負責命令執行；現在終端可能反過來成為 agent 協作的中心。Warp 這個倉庫，正是在探索這種可能性。

Hermes + Qwen3.6：本地 Agent 的一套低成本部署方案

Mon, 04 May 2026 06:40:30 +0800

這篇記錄整理一套本地 Agent 部署方案：用 llama.cpp 在 WSL2 中運行 Qwen3.6 GGUF 模型，再把 Hermes Agent 接到本地 OpenAI-compatible API。這樣可以在自己的電腦上獲得一個可長期在線的本地 AI 助手，不再按在線服務的 Token 額度計費。

這套方案適合想體驗本地 AI Agent、又希望保留資料隱私和長期可控性的使用者。它可以用於日常問答、寫作、程式碼輔助、資料整理和簡單自動化任務。需要注意的是，模型規模越大，對顯存要求越高；原文示例使用的是 Qwen3.6-27B，顯存 24GB 更穩。如果顯存較小，應選擇更小尺寸或更低量化的模型。

方案結構

整體鏈路很簡單：

Windows 上安裝 WSL2 和 Ubuntu 24.04。
在 WSL2 中安裝 CUDA Toolkit、編譯 llama.cpp。
下載 Qwen3.6 GGUF 模型。
用 llama-server 啟動本地模型服務。
安裝 Hermes Agent，並把它配置到 http://localhost:8080/v1。
可選：寫啟動腳本，讓 WSL2 打開時自動啟動模型服務。

Hermes 負責 Agent 能力，Qwen3.6 負責本地大模型能力。兩者組合後，可以把電腦變成一個本地私有 AI 助理。

安裝 WSL2 和 Ubuntu

在 Windows PowerShell 管理員視窗中執行：

1
2

wsl --install
wsl --set-default-version 2

重啟後安裝 Ubuntu 24.04：

`1`	`wsl --install -d Ubuntu-24.04`

安裝完成後，Ubuntu 會提示設定使用者名稱和密碼。進入 Ubuntu 後，先檢查 NVIDIA GPU 是否能在 WSL2 中正常識別：

`1`	`nvidia-smi`

如果無法識別 GPU，通常需要先更新 Windows 端的 NVIDIA 顯示卡驅動。WSL2 會繼承 Windows 驅動，但 CUDA Toolkit 仍需要在 WSL2 內單獨安裝。

安裝 Python 和基礎工具

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

後續還需要編譯工具、Git 和 CMake：

`1`	`sudo apt install -y cmake build-essential git`

編譯 llama.cpp

先拉取源碼：

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

如果 WSL2 中已經有可用 CUDA 環境，可以直接編譯：

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 適合 Ada 架構顯示卡，例如 RTX 40 系列。其他顯示卡應按實際架構調整。

如果編譯時報 CUDA Toolkit 缺失，先在 WSL2 中安裝 CUDA Toolkit：

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

安裝完成後配置環境變數：

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

然後重新編譯：

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

下載 Qwen3.6 GGUF 模型

原文示例使用 unsloth/Qwen3.6-27B-GGUF 中的 Qwen3.6-27B-UD-Q4_K_XL.gguf：

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

這個文件約 17GB。如果 Hugging Face 下載慢，可以換 ModelScope 等國內鏡像。顯存不足時不要硬上 27B，可以換更小模型或更低量化版本。

啟動本地模型服務

根據自己的模型文件名啟動 llama-server：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

啟動成功後，在 Windows 瀏覽器訪問：

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

如果要讓 Hermes Agent 或其他 OpenAI-compatible 客戶端調用，API 地址通常是：

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

Thinking 模式取捨

Qwen3.6 預設可能啟用 Thinking 模式。它適合複雜推理、複雜程式碼問題、多步驟分析，但速度會慢一些。

如果想關閉 Thinking 模式，可以停止服務後增加 --chat-template-kwargs 參數：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

關閉 Thinking 後，簡單問答、寫作、程式碼補全和解釋程式碼會更快；但複雜演算法設計、疑難 Debug 和架構分析仍建議開啟 Thinking。

安裝 Hermes Agent

保持 llama-server 運行，再新開一個 WSL2 終端安裝 Hermes Agent：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

安裝腳本會處理 Python、Node.js、ripgrep、ffmpeg 等依賴。配置模型端點時選擇自訂 endpoint：

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: 自動識別

API Key 對本地 llama-server 來說可以隨便填一個佔位值。配置完成後，可以繼續接 Telegram、微信、QQ、Discord 等聊天工具，讓 Hermes Agent 透過這些入口調用本地模型並執行任務。

自動啟動模型服務

可以寫一個啟動腳本，讓 WSL2 終端打開時自動啟動模型服務。

創建腳本：

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

寫入 .bashrc：

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

這樣每次打開 WSL2 終端時，如果 llama-server 沒有運行，就會自動啟動；如果已經在運行，就會跳過，避免重複啟動。

注意事項

27B 模型對顯存要求較高，24GB 顯存體驗更穩；顯存較小時應換小模型。
--ctx-size 65536 會顯著增加顯存和記憶體壓力，不穩定時先降到 32768 或更低。
WSL2 中 CUDA Toolkit 和 Windows 顯示卡驅動都要正常，缺一邊都可能導致 CUDA 編譯或運行失敗。
Hermes Agent 接本地服務時，本質上是調用 OpenAI-compatible API，關鍵是 http://localhost:8080/v1 能正常回應。
如果要從手機或其他設備訪問，需要額外處理 Windows 防火牆、區域網地址和安全隔離，不要把本地模型服務直接暴露到公網。

如何在 Cline 中呼叫 DeepSeek V4 Pro

Fri, 01 May 2026 20:59:06 +0800

Cline 本身已經支援 OpenAI Compatible Provider。 DeepSeek API 也相容 OpenAI SDK 風格的呼叫方式，所以把 deepseek-v4-pro 接到 Cline 裡並不複雜：選 OpenAI Compatible，填 DeepSeek 的 Base URL、API Key 和模型名即可。

下面按 VS Code 外掛介面和 Cline CLI 兩種方式整理。

準備 DeepSeek API Key

先到 DeepSeek 開放平台建立 API Key。

需要準備三個值：

項目	填寫內容
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

DeepSeek 官方文件說明，V4 系列使用既有 OpenAI 相容介面，base_url 保持為 https://api.deepseek.com，呼叫時把 model 設定為 deepseek-v4-pro 或 deepseek-v4-flash。

在 Cline 外掛裡設定

如果你用的是 VS Code 裡的 Cline 外掛，可以按這個路徑設定：

打開 VS Code 側邊欄裡的 Cline。
進入 Cline 的設定或模型設定頁面。
Provider 選擇 OpenAI Compatible。
API Key 填入 DeepSeek API Key。
Base URL 填：

`1`	`https://api.deepseek.com`

Model ID 填：

`1`	`deepseek-v4-pro`

儲存設定，回到 Cline 對話框測試一次簡單任務。

可以先讓 Cline 做一個低風險測試：

`1`	`請讀取目前專案目錄結構，並總結這個專案是什麼類型，不要修改任何檔案。`

如果能正常讀取和回答，說明模型鏈路已經通了。

在 Cline CLI 中設定

如果你使用 Cline CLI，可以用 cline provider configure openai-compatible 進入互動式設定。

範例：

`1`	`cline provider configure openai-compatible`

互動時填寫：

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

設定完成後，可以用一個只讀任務測試：

`1`	`cline "Summarize this repository structure without changing files."`

如果你希望先降低成本，也可以把 Model ID 臨時改成：

`1`	`deepseek-v4-flash`

等遇到複雜規劃、事實核查、多工具協作或高風險程式碼修改時，再切回 deepseek-v4-pro。

上下文長度怎麼填

DeepSeek V4 Pro 和 Flash 都支援很長上下文。在 Cline 裡如果需要手動填寫 context window，可以按 DeepSeek 官方模型頁給出的 1M 上下文來理解。

實際使用時不建議一開始就把所有檔案都塞進上下文。 Cline 會按任務讀取檔案，通常更好的方式是：

先讓它看目錄結構；
再讓它定位相關檔案；
最後只圍繞目標檔案執行修改。

這樣更省 Token，也更容易保持任務邊界清晰。

常見問題

1. 提示模型不存在

先檢查 Model ID 是否寫成：

`1`	`deepseek-v4-pro`

不要寫成 DeepSeek V4 Pro、deepseek-v4 或其他顯示名稱。

2. 提示 401 或認證失敗

檢查 API Key：

是否複製完整；
是否帶了多餘空格；
是否填到了 Cline 目前正在使用的 provider 設定裡；
DeepSeek 帳戶是否有可用額度。

3. 提示連線失敗

檢查 Base URL：

`1`	`https://api.deepseek.com`

不要在末尾額外拼 /v1/chat/completions。 Cline 的 OpenAI Compatible Provider 會自己按相容介面組織請求。

4. Cline 呼叫很貴怎麼辦

可以先把日常任務切到 deepseek-v4-flash，只在複雜任務裡使用 deepseek-v4-pro。

另外，盡量把任務描述寫清楚：

`1`	`只修改登入頁相關檔案，不要重構無關模組。先給出計畫，確認後再改程式碼。`

Agent 任務最怕邊界不清。邊界越清楚，讀檔案越少，工具呼叫越少，成本也越可控。

5. 報錯 reasoning_content must be passed back

如果你看到類似錯誤：

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

這通常不是 Key、額度或 Base URL 的問題，而是 DeepSeek V4 Pro 的 thinking mode 和目前客戶端的多輪工具呼叫記錄沒有對齊。

DeepSeek 官方文件說明：

thinking mode 預設是 enabled；
thinking mode 下會返回 reasoning_content；
如果某一輪發生了 tool call，後續請求必須把該輪 assistant message 裡的 reasoning_content 一起傳回 API；
如果客戶端沒有正確回傳，就會返回 400。

Cline 透過 OpenAI Compatible Provider 接入時，如果目前版本沒有完整保留並回傳 DeepSeek 的 reasoning_content，就可能在第二輪或工具呼叫後觸發這個錯誤。

可嘗試的處理順序：

先升級 Cline 到最新版；
確認使用的是 OpenAI Compatible，而不是普通 OpenAI provider；
如果 Cline 支援自訂 request body，嘗試關閉 thinking mode：

{
  "thinking": {
    "type": "disabled"
  }
}

如果 Cline 不支援額外 body 參數，暫時改用不觸發該問題的模型或服務中轉；
等 Cline 適配 DeepSeek V4 的 reasoning_content 回傳後，再切回 deepseek-v4-pro。

需要注意：關閉 thinking mode 會犧牲一部分複雜推理能力，但可以繞開客戶端沒有回傳 reasoning_content 的相容性問題。

一個可直接複製的設定清單

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

如果要低成本模式：

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

小結

在 Cline 中呼叫 DeepSeek V4 Pro 的關鍵只有三步：

Provider 選擇 OpenAI Compatible；
Base URL 填 https://api.deepseek.com；
Model ID 填 deepseek-v4-pro。

設定完成後，建議先用只讀任務測試，再逐步交給它執行真實程式碼修改。如果你經常跑 Agent 任務，可以把 Flash 和 Pro 分開用：Flash 負責高頻輕量任務，Pro 負責複雜判斷和兜底。

參考來源：

DeepSeek V4 降價如何改寫 AI Agent 的成本模型

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 發布時沒有製造出特別誇張的聲量。沒有大型發布會，也沒有一眼碾壓所有對手的跑分敘事。但幾天之後，它真正影響行業的地方開始顯現：連續降價。

這次變化的重點不是「模型強了一點」，而是「使用成本被打到另一個層級」。當 Token 價格低到普通 Agent 任務幾毛錢、一兩塊錢就能跑完時，很多 Coding Plan、Token Plan 的商業邏輯都會被重新審視。

發布當天沒有炸場

DeepSeek V4 的第一波反饋並不算熱烈。很多人期待它像 R1 那樣帶來強烈衝擊：跑分全面領先、國產算力驗證、多模態和 Agent 能力一起爆發。但真正發布後，大家發現它更像一次穩健升級。

V4 Pro 確實是強模型，尤其在程式碼、數學、長上下文和 agentic coding 上表現不錯。但它不是那種讓所有同類模型瞬間失色的產品。所以發布當天，輿論一度有些尷尬：想誇，但很難找到一個足夠爆炸的角度。

真正的轉折點不是發布當天，而是後續價格調整。

連續降價才是關鍵

DeepSeek V4 發布後，價格開始連續下探。按照 DeepSeek 官方價格頁和原文整理的資訊，當時的大致價格是：

DeepSeek V4 Flash：輸入 100 萬 Token 約 1 元；快取命中後 100 萬 Token 約 2 分錢；
DeepSeek V4 Pro：輸入 100 萬 Token 約 3 元；快取命中後 100 萬 Token 約 2.5 分；
全系列模型輸入快取命中價格降到首發價格的 1/10；
V4 Pro 曾處在 2.5 折優惠期，優惠延長到 2026 年 5 月 31 日 23:59。

如果按美元 API 價格看，會更直觀：

模型	快取命中輸入	非快取輸入	輸出	上下文
`deepseek-v4-flash`	$0.0028 / 100萬 Token	$0.14 / 100萬 Token	$0.28 / 100萬 Token	1M
`deepseek-v4-pro` 促銷價	$0.003625 / 100萬 Token	$0.435 / 100萬 Token	$0.87 / 100萬 Token	1M
`deepseek-v4-pro` 原價	$0.0145 / 100萬 Token	$1.74 / 100萬 Token	$3.48 / 100萬 Token	1M

這裡要注意兩個點。

第一，V4 Pro 的 $0.435 / $0.87 是促銷價，不是長期原價。 DeepSeek 官方說明裡，這個 75% 折扣延長到 2026 年 5 月 31 日 15:59 UTC。

第二，快取命中價格才是 Agent 成本模型裡的關鍵。 Flash 的快取命中輸入低到 $0.0028 / 100萬 Token，Pro 促銷期快取命中輸入是 $0.003625 / 100萬 Token。這意味著大量重複專案上下文、工具定義、系統提示詞和歷史摘要，不再按完整輸入價格計費。

這個價格最重要的地方，是它讓很多任務的 Token 成本變得「不敏感」。過去開發者會擔心一次 Agent 任務吃掉大量上下文、反覆讀寫程式碼、頻繁呼叫工具。現在只要快取命中率足夠高，成本會被壓得很低。

和 GPT、Claude 的價格對比

只看 DeepSeek 自己的價格，還不容易感受到差距。把它和同期常見的閉源模型放在一起，對比會更明顯。

模型	輸入	快取輸入	輸出	適合場景
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	高頻 Agent、常規 coding、批量任務
`deepseek-v4-pro` 促銷價	$0.435 / M	$0.003625 / M	$0.87 / M	複雜 coding、規劃、事實核查
`deepseek-v4-pro` 原價	$1.74 / M	$0.0145 / M	$3.48 / M	促銷結束後的 Pro 成本基準
GPT-5.5	$5 / M	$0.50 / M	$30 / M	高品質複雜任務、通用推理
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	程式設計和專業任務的中檔選擇
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	成本更低的通用/子任務模型
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	高品質寫作、複雜推理、長任務
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	程式設計、Agent、綜合任務
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	輕量任務、摘要、分類

這張表裡最刺眼的是輸出價格。 Agent 不只讀上下文，還會不斷生成計畫、補丁、解釋、日誌和下一步動作。如果輸出很多，DeepSeek V4 Pro 促銷價的 $0.87 / M 和 GPT-5.5 的 $30 / M、Claude Sonnet 4.6 的 $15 / M 相比，差距會被不斷放大。

即使按 V4 Pro 原價 $3.48 / M 輸出算，它也明顯低於 GPT-5.4、GPT-5.5 和 Claude Sonnet / Opus。如果任務可以用 Flash 承擔，輸出價會進一步降到 $0.28 / M。

快取輸入差距更誇張。 DeepSeek V4 Flash 的快取輸入是 $0.0028 / M，而 GPT-5.5 和 Claude Opus 4.7 的快取輸入都是 $0.50 / M。這不是同一個數量級。對反覆讀取同一程式碼倉庫的 Agent 來說，這個差距比普通聊天更重要。

Agent 任務為什麼特別受影響

AI Agent 和普通聊天不一樣。普通聊天通常是一問一答，輸入上下文相對有限。 Agent 任務會反覆讀取專案檔案、生成計畫、呼叫工具、檢查結果、再修改程式碼。

這類任務有兩個特點：

Token 消耗大；
重複上下文多。

第二點很關鍵。在程式碼專案裡，模型會反覆讀取同一批檔案、目錄結構、錯誤日誌和修改結果。如果平台支援快取命中，重複輸入的成本會大幅下降。

原文裡提到一次實際體驗：把 DeepSeek V4 Pro 和 Flash 接到 Claude Code 一類工具中，讓它拉取一個提示詞倉庫並做成本地搜尋網站。任務最終完成，總成本大約 8 毛多，其中 Pro 快取命中率達到 98.7%。

這個例子說明了一個現實問題：Agent 任務越像「圍繞同一個專案反覆工作」，快取命中越有價值。如果一次生成網站、修 bug、改前端只花幾毛錢到幾塊錢，訂閱套餐的吸引力就會下降。

可以用一個簡化任務估算差距。假設一次 coding agent 任務包含：

50 萬 Token 輸入，其中 80% 能命中快取；
5 萬 Token 輸出；
不計算工具呼叫、搜尋和平台加價，只看模型 Token 成本。

大致成本如下：

模型	估算成本
DeepSeek V4 Flash	約 $0.03
DeepSeek V4 Pro 促銷價	約 $0.09
DeepSeek V4 Pro 原價	約 $0.36
GPT-5.4 mini	約 $0.30
GPT-5.4	約 $1.01
GPT-5.5	約 $1.75
Claude Sonnet 4.6	約 $1.11
Claude Opus 4.7	約 $1.65

這個估算不是說 DeepSeek 在所有任務上都更好。模型品質、工具呼叫穩定性、長上下文檢索能力、程式碼風格和事實可靠性都要單獨評估。但從成本上看，DeepSeek V4 把「讓 Agent 多跑幾輪」的邊際成本壓得很低。這會鼓勵開發者設計更長流程、更頻繁的自檢和更多候選方案，而不是每次都擔心 Token 帳單。

Coding Plan 和 Token Plan 的差別

很多 AI 產品現在會提供兩類套餐：Coding Plan 和 Token Plan。

它們的差別大致是：

Coding Plan 通常主要面向程式設計；
Token Plan 通常覆蓋更多能力，例如 STT、TTS、繪圖、搜尋、embedding、RAG；
STT 是語音轉文字；
TTS 是文字轉語音；
Coding Plan 往往把使用者限制在程式設計場景裡，其他能力還需要另買。

從商業角度看，Coding Plan 更像自助餐。使用者預先付一筆固定費用，廠商賭的是大多數人不會把額度用滿。有人用得多，有人用得少，平均下來平台仍然能賺錢。

但如果按量 Token 價格足夠低，使用者就會開始計算：我為什麼一定要買套餐？如果一個月真實使用成本只有幾塊錢、十幾塊錢，買 40 元、200 元的套餐就不一定划算。

降價為什麼會衝擊套餐模式

訂閱套餐的成立，需要一個前提：使用者覺得單次使用很貴，或者不想計算每次呼叫成本。當 Token 價格高時，套餐看起來更安心。當 Token 價格低到幾乎無感時，按量付費反而更自然。

DeepSeek V4 的降價相當於把底牌亮出來：

Agent 任務可以很便宜；
長上下文不一定貴到不能用；
快取命中可以顯著降低成本；
普通開發者不一定需要固定訂閱；
模型入口可以從「套餐平台」轉向「低價 API」。

這會讓做 Coding Plan 的平台不舒服。如果使用者發現按量呼叫更便宜、更自由，就沒必要為了一個平台的套餐被綁定。

Flash 和 Pro 怎麼選

DeepSeek V4 的一個實用思路，是把 Flash 和 Pro 分工使用。

Flash 適合高頻、輕量、可重複的任務：

改 bug；
寫前端；
寫腳本；
做常規程式碼理解；
處理較長上下文裡的普通資訊整理；
跑大量子任務。

Flash 便宜，速度快，而且同樣支援很長上下文。對日常 coding agent 來說，很多任務不需要一上來就用 Pro。

Pro 更適合複雜判斷和兜底任務：

多輪規劃；
複雜 Agent 流程；
多次 function call；
事實核查；
財經研究；
需要更強知識和判斷力的內容生產；
高風險程式碼修改。

一個合理配置是：Flash 負責跑量，Pro 負責兜底。普通任務先用 Flash，遇到長程規劃、複雜判斷、事實核查或多工具協作時再切 Pro。這樣既能控制成本，也能保留模型品質。

DeepSeek 為什麼可以這麼定價

DeepSeek 和很多大廠的業務結構不同。它沒有電商、社交、短影片、雲計算、手機、汽車、辦公套件、作業系統、瀏覽器或大規模企業 SaaS 生態。

這意味著它不需要把使用者鎖在一個完整平台裡。它可以只賣文字模型能力：你在這裡用便宜的文字模型，其他能力要呼叫誰都可以。

大廠的邏輯通常不同。如果你買了它的 Coding Plan 或 Token Plan，就會被拉進它的雲、搜尋、繪圖、語音、資料庫和開發工具生態。套餐不是單純賣模型，而是在爭奪使用者入口。

DeepSeek 的打法更直接：把文字模型價格壓低，爭取成為 Agent 的預設模型入口。只要預設入口被占住，很多開發者和工具鏈就會自然圍繞它適配。

開源模型和預設入口

DeepSeek V4 如果保持開放模型路線，第三方雲廠商和平台很可能會自行部署並提供服務。這對 DeepSeek 來說既是傳播，也可能是分流。

低價官方 API 的意義就在這裡。如果官方價格已經足夠低，其他平台即使能部署，也很難在價格上明顯更有優勢。使用者會傾向於直接使用預設、便宜、穩定的入口。

對 Agent 工具尤其如此。 Agent 任務依賴長上下文、快取、工具呼叫和穩定吞吐。一旦某個模型在這些場景裡成本足夠低，它就有機會成為預設選項。

Coding Plan 仍然不是完全沒用

這並不意味著 Coding Plan 會馬上消失。它仍然有適合的人群。

如果某些使用者真的是高強度使用者，每天把套餐額度打滿，那麼固定訂閱可能仍然划算。就像自助餐，如果完全沒有人能吃回本，使用者也不會願意買。

但問題在於，絕大多數使用者不是這種極端高頻使用者。低頻使用者、輕量開發者、偶爾寫腳本或改專案的人，更適合按量付費。當 DeepSeek 把按量成本壓低後，套餐的吸引力會被削弱。

未來更可能出現的是分層選擇：

高頻重度使用者繼續買 Coding Plan；
普通使用者轉向低價 API；
Agent 工具根據任務自動選擇 Flash / Pro；
平台套餐需要提供更多非模型價值，例如工作流、IDE 整合、部署、團隊管理和安全稽核。

小結

DeepSeek V4 的發布並沒有靠跑分製造最大衝擊。真正改變行業預期的是後續降價。

當輸入 Token 和快取命中價格被壓到很低時，AI Agent 的使用成本會發生變化。過去看起來昂貴的長上下文、程式碼專案分析、多輪工具呼叫，現在可能變成幾毛錢到幾塊錢的日常消耗。

這會直接衝擊 Coding Plan 和 Token Plan 的商業邏輯。如果使用者可以按量付費、自由組合模型和工具，而且成本足夠低，就不一定願意被綁定在某個平台套餐裡。

DeepSeek V4 這次真正動到的，不只是模型能力排名，而是 AI Agent 的成本結構和預設入口之爭。

參考來源：

NVIDIA 發布 Nemotron 3 Nano Omni：面向智慧體的開放全模態推理模型

Fri, 01 May 2026 12:07:15 +0800

NVIDIA 發布了 Nemotron 3 Nano Omni，這是一款面向智慧體工作流的開放式全模態推理模型。它的重點不是只做文字問答，而是把語言、視覺、音訊放進同一個推理框架裡，讓模型能夠處理更接近真實工作流的輸入。

從定位看，Nemotron 3 Nano Omni 更像是給 AI Agent 準備的底層模型。它可以理解螢幕、文件、圖片、語音和影片中的資訊，並把這些資訊轉成可執行的推理結果。這類能力適合電腦操作、文件智慧、影片理解、語音互動、客服、教育和企業流程自動化。

模型規格

Nemotron 3 Nano Omni 採用 MoE 架構。 NVIDIA 給出的核心規格是：

項目	資訊
模型名稱	`Nemotron 3 Nano Omni`
架構	MoE
參數規模	30B total / 3B active
模態	文字、圖像、音訊、影片
上下文長度	256K token
授權	Apache 2.0
主要部署方向	AI Agent、多模態推理、企業智慧體

這裡最值得注意的是 30B-A3B。它代表模型總參數規模約 30B，但每次推理只啟用約 3B 參數。這能在能力和推理成本之間做一個折衷：模型保留較大的專家容量，同時執行時只使用其中一部分。

不過，MoE 的 active params 不等於顯存只按 3B 模型估算。完整部署仍然要考慮專家權重、KV cache、視覺/音訊編碼模組、上下文長度和推理框架開銷。

它解決的不是單一模態問題

傳統大語言模型主要處理文字。多模態模型進一步支援圖片理解。而 Nemotron 3 Nano Omni 的目標更寬：它強調全模態輸入，也就是把文字、圖像、音訊和影片統一納入推理。

這對 Agent 很關鍵。真正的智慧體任務往往不是「給一段文字，生成一段文字」，而是：

看螢幕上的按鈕、表格和視窗；
讀 PDF、截圖、圖表和網頁；
聽語音說明或會議錄音；
理解影片中的動作、場景和時序；
把這些資訊綜合成下一步操作。

如果模型只能處理單一模態，Agent 就需要額外拼接多個專用模型。全模態模型的價值在於減少這種拼接成本，讓同一個模型直接處理更複雜的環境輸入。

面向電腦操作和文件智慧

NVIDIA 特別提到，Nemotron 3 Nano Omni 可用於電腦操作相關任務。這類任務通常要求模型理解使用者介面：

螢幕上有哪些控制項；
目前視窗處於什麼狀態；
哪個按鈕或選單是下一步目標；
表格、彈窗、輸入框中的內容意味著什麼。

這也是現在 AI Agent 落地時很難繞開的能力。如果智慧體要幫人操作辦公軟體、瀏覽器、企業後台或開發工具，它必須能看懂介面，而不是只讀 API 文件。

文件智慧也是類似邏輯。企業資料經常混合文字、表格、圖像、掃描頁和圖表。全模態模型可以把這些內容放在同一個上下文裡理解，適合做合約審閱、報表分析、票據處理、知識庫問答和流程自動化。

音訊和影片讓 Agent 更接近真實場景

音訊和影片輸入會讓 Agent 的應用範圍明顯擴大。

音訊場景包括：

會議錄音總結；
客服通話分析；
語音指令理解；
教育和培訓內容整理。

影片場景包括：

教學影片理解；
安防和工業巡檢；
螢幕錄製分析；
操作流程複盤；
多步驟任務中的時序判斷。

這些任務如果只靠文字轉寫，會丟掉很多視覺和時序資訊。全模態模型可以直接把聲音、畫面和文字線索結合起來，給 Agent 更完整的環境感知。

部署與生態

NVIDIA 將 Nemotron 3 Nano Omni 放進開放生態裡，模型採用 Apache 2.0 授權。這對開發者和企業很重要，因為它降低了試驗、整合和二次開發的授權門檻。

從 NVIDIA 的介紹看，這個模型也和其推理生態綁定緊密。對企業使用者來說，真正部署時通常會關注這些問題：

是否能在 NVIDIA GPU 上高效推理；
是否支援長上下文和多模態輸入；
是否能接入現有 Agent 框架；
是否能處理企業內部文件、音影片和介面截圖；
是否可以在私有環境裡部署。

NVIDIA 強調該模型在吞吐方面有明顯優勢，並稱其最高可達到同類開放全模態推理模型的 9 倍。這個數字的實際價值，還要結合具體硬體、上下文長度、輸入模態和推理框架來看。但方向很明確：NVIDIA 想把開放多模態模型和自己的推理基礎設施一起推向企業 Agent 場景。

適合哪些場景

Nemotron 3 Nano Omni 更適合下面這些任務：

需要同時理解文字、圖片、音訊和影片的 Agent；
企業內部文件智慧和知識庫問答；
基於螢幕截圖或網頁介面的電腦操作；
會議、客服、教學內容的多模態分析；
影片理解、流程複盤和時序判斷；
對開放授權和私有化部署有要求的團隊。

它不一定適合所有普通使用者。如果只是本地聊天、程式碼補全或簡單問答，單模態語言模型可能更輕、更快、更省資源。 Nemotron 3 Nano Omni 的價值主要體現在複雜輸入和多模態 Agent 工作流裡。

這對 AI Agent 意味著什麼

AI Agent 要真正進入工作場景，不能只會寫文字。它需要看得懂介面，聽得懂語音，讀得懂文件，理解影片裡的變化，還要把這些資訊轉成下一步行動。

Nemotron 3 Nano Omni 的意義就在這裡。它不是單純把模型參數做大，而是把 Agent 需要面對的多種輸入統一到一個推理模型裡。這會讓開發者更容易構建面向真實任務的智慧體，而不是只圍繞聊天視窗做應用。

從這個角度看，NVIDIA 發布這款模型的重點不只是「又一個多模態模型」，而是繼續把開放模型、GPU 推理、企業 Agent 和私有部署連接起來。未來真正值得關注的是，它在具體 Agent 框架、企業工作流和本地部署中的實際表現。

參考來源：

NVIDIA 技術部落格：NVIDIA Nemotron 3 Nano Omni

FinceptTerminal：開源金融終端、量化研究和 AI Agent 工作台

Fri, 01 May 2026 03:47:18 +0800

FinceptTerminal 是 Fincept Corporation 開源的金融終端專案。

從 README 的描述看，它不是一個簡單行情面板，而是一個面向金融分析、量化研究、交易工作流和 AI Agent 的綜合桌面平台。專案 v4 使用 C++20 和 Qt6 構建原生桌面應用，同時嵌入 Python 生態，用來支援分析、腳本、機器學習和金融建模。

如果要類比，它更接近一個開源金融研究工作台：一邊連接資料源，一邊做圖表、組合、量化、交易、情報分析和自動化工作流。

需要先說明：這類工具可以用於研究、分析、教育和內部工具建設，但不能把任何輸出直接當成投資建議。金融市場有風險，資料、模型、策略和執行都需要獨立驗證。

它解決什麼問題

金融研究經常被拆散在很多工具裡：

行情資料在一個軟體裡
研究程式碼在 Jupyter 裡
圖表在另一個工具裡
組合分析在表格裡
交易記錄在券商系統裡
新聞和情報在瀏覽器裡
AI 分析又在聊天視窗裡

這種方式能用，但協作和復現很困難。

FinceptTerminal 想解決的是把這些能力整合到一個桌面終端裡，讓使用者可以在同一個環境中完成資料接入、分析、建模、視覺化、Agent 協作和交易相關流程。

它的目標不是替代所有專業系統，而是提供一個可擴展的開源金融終端底座。

技術架構

README 中提到 v4 採用 C++20 和 Qt6。

這意味著它不是純 Web 面板，而是原生桌面應用。對金融終端來說，原生應用有幾個優勢：

UI 回應更穩定
更適合複雜視窗和多面板布局
更容易處理本地檔案和系統資源
可以嵌入高效能元件
適合長期執行的桌面工作流

同時，專案也嵌入 Python。

這點很關鍵。金融研究和量化分析裡，Python 是事實上的主流語言之一。資料分析、機器學習、統計、回測、圖表、金融建模都離不開 Python 生態。C++/Qt 負責應用框架和桌面體驗，Python 負責研究與擴展能力，這是一種很實用的組合。

資料連接器

README 中提到專案提供 100+ 資料連接器。

金融終端的價值很大程度取決於資料接入。沒有資料，再好的 UI 和模型都只是空殼。

這類連接器通常可以覆蓋不同來源：

市場行情
總體經濟資料
公司財務
新聞與情報
交易所資料
加密資產資料
研究資料源
內部或自訂 API

對使用者來說，資料連接器的意義是減少「下載 CSV、手動整理、再匯入」的流程，讓分析更接近即時和自動化。

不過也要注意，金融資料的品質、授權、延遲、覆蓋範圍和費用都很關鍵。使用任何資料源前，都要確認許可和用途邊界。

AI Agents 模組

專案強調 AI Agents，這也是它和傳統金融終端不同的地方。

傳統終端更多是人操作介面，人看資料，人做判斷。加入 AI Agent 後，工具可以承擔更多輔助任務：

彙總市場資訊
解釋財報和公告
生成研究摘要
幫助篩選資料
輔助編寫分析腳本
組織交易或研究工作流
在多個模組之間傳遞上下文

這不代表 AI 可以替代研究員或交易員。

更合理的定位是：AI Agent 幫你減少重複整理工作，提供初步分析和互動式查詢，但重要結論仍然需要資料驗證、模型驗證和人工判斷。

量化研究能力

FinceptTerminal 也面向量化研究。

量化研究通常包括：

資料清洗
因子構建
策略假設
回測
風險評估
組合最佳化
交易成本估計
結果視覺化

如果一個終端能把資料連接、Python 分析、圖表和工作流整合起來，對量化研究會很有幫助。研究者可以在一個環境裡從資料到策略驗證逐步推進。

不過，量化研究最怕「看起來有效」。一個策略如果沒有嚴格處理樣本外驗證、交易成本、滑點、倖存者偏差、過擬合和資料洩漏，回測再漂亮也不可靠。

所以這類工具應該被當作研究平台，而不是自動賺錢機器。

QuantLib 和金融建模

README 中提到 QuantLib 相關能力。

QuantLib 是金融工程裡很常見的開源庫，常用於利率、債券、期權、衍生品定價、曲線構建和風險計算等方向。

這說明 FinceptTerminal 不只是看股票行情，也試圖覆蓋更專業的金融建模場景。

這類能力適合：

金融工程學習
衍生品定價實驗
曲線與風險指標計算
投資組合風險分析
研究模型原型驗證

但金融建模本身門檻很高。模型參數、市場假設、資料來源和定價邏輯都會影響結果。工具能降低操作成本，不能替代專業判斷。

節點工作流

README 中還提到節點式工作流。

節點工作流適合把複雜任務拆成視覺化流程：

讀取資料
清洗資料
執行模型
生成圖表
觸發 AI 分析
輸出報告
發送通知

對金融場景來說，這種方式有兩個優點。

第一，流程視覺化。複雜分析不再只藏在一堆腳本裡，使用者可以看到資料如何流動。

第二，適合自動化。重複研究流程可以被保存、複用和調整。

如果後續能和 Python 腳本、資料連接器、Agent、報告系統結合，這類節點工作流會成為金融終端裡很有價值的模組。

交易與組合管理

專案也提到交易和組合相關能力。

這類功能最需要謹慎。

組合管理可以幫助使用者理解資產暴露、收益、回撤、波動、相關性和風險集中度。交易模組則可能涉及訂單、帳戶、執行和記錄。

但只要觸及真實交易，就必須考慮：

資料延遲
訂單執行風險
API 權限
交易成本
滑點
流動性
風控限制
稽核和日誌
策略誤觸發

開發和研究環境裡的交易功能，不應直接等同於生產級交易系統。真正接入實盤前，需要嚴格測試、權限隔離、風控機制和人工審核。

和 Bloomberg Terminal 有什麼區別

很多金融終端專案都會被拿來和 Bloomberg Terminal 對比。

但兩者定位不同。

Bloomberg Terminal 的價值不僅是軟體介面，還包括：

資料覆蓋
資料授權
新聞網路
交易生態
客戶支援
金融機構工作流
長期積累的行業信任

FinceptTerminal 更像一個開源金融終端框架和研究平台。它的優勢在於可擴展、可定製、可本地化、可與 Python 和 AI 工作流結合。

它不應該被簡單理解成 Bloomberg 的免費替代品。

更合理的看法是：如果你想研究金融終端怎麼構建，或者想搭建自己的金融分析工作台，FinceptTerminal 提供了一個開源起點。

授權和商業邊界

README 中提到專案使用 AGPL 和商業授權模式。

AGPL 對網路服務和衍生作品有明確要求。如果你只是學習、研究或個人實驗，問題通常不大。但如果準備把它改造成商業產品、內部平台或對外服務，就需要認真閱讀許可證。

特別是金融工具常常會進入企業內部系統。這個時候，開源協議、商業授權、資料授權、模型授權都要一起看，而不是只看程式碼能不能執行。

適合什麼人關注

FinceptTerminal 適合這些人：

想研究金融終端架構的開發者
做量化研究或金融工程實驗的人
想把 Python 分析能力嵌入桌面工具的人
想探索 AI Agent + 金融工作流的人
想搭建內部金融分析平台的團隊
想學習 C++/Qt 金融應用開發的人

如果你只是想看幾隻股票的行情，普通行情軟體可能更簡單。

如果你想理解一個金融終端如何把資料、圖表、模型、Agent、交易和工作流整合起來，這個專案就更值得研究。

使用時要注意

第一，先區分研究和交易。

研究環境可以容忍實驗和失敗，交易環境不能。不要把研究工具未經驗證就接入真實帳戶。

第二，重視資料授權。

金融資料不是隨便抓來就能商用。不同資料源有不同授權條款，尤其是行情、新聞、財務和交易所資料。

第三，不要迷信 AI Agent。

AI 可以輔助整理資訊，但金融結論必須回到資料、模型、風險和事實驗證。

第四，關注安全。

如果工具連接帳戶、API key、交易介面或內部資料，必須處理好金鑰管理、權限隔離、日誌和網路邊界。

第五，理解開源協議。

AGPL 對商業使用和服務化有重要影響。準備做產品化前，應該先處理授權問題。

參考

Fincept-Corporation/FinceptTerminal

最後一句

FinceptTerminal 值得關注的地方，是它把金融終端、Python 量化研究、AI Agents、資料連接器和節點工作流放進了同一個開源桌面平台設想裡。

它更適合作為金融技術研究和內部工具建設的起點，而不是被當成可以直接替代專業金融終端或實盤交易系統的成品。

mattpocock/skills：給 AI 編程 Agent 準備的實用技能集合

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills 是 Matt Pocock 公開的一組 AI 編程 agent skills。

它不是一個完整的應用，也不是一個新的聊天客戶端，而是一套可以給 AI 編程助手使用的工作技能。它的思路很實用：把 AI 編程裡經常出現的問題拆成一個個小技能，讓 Agent 在合適的任務裡呼叫，而不是每次都靠一大段提示詞硬撐。

如果你經常使用 Claude Code、Codex、Cursor 或類似的 AI 編程工具，這類 skills 很值得關注。因為真正影響 AI 編程體驗的，往往不是「模型會不會寫程式碼」，而是它能不能按你的工作方式推進任務。

它解決什麼問題

AI 編程助手很強，但也很容易出問題。

常見情況包括：

還沒理解需求就開始改程式碼
一次性改太多檔案
輸出解釋很多，真正有用的行動很少
遇到錯誤後盲目嘗試
沒有及時執行測試或檢查
忽略專案裡已有模式
為了完成任務引入不必要的抽象
寫完程式碼後沒有真正 review 風險

這些問題不一定是模型能力不夠，而是工作流沒有被約束好。

mattpocock/skills 的價值在於，把這些常見失敗模式拆成可以複用的操作方式，讓 Agent 在不同場景下更像一個有經驗的工程協作者。

Skills 是什麼

在 AI Agent 語境裡，skill 可以理解成一段可複用的任務說明、工作方法或專業流程。

它不一定是程式碼插件，也不一定必須呼叫外部服務。很多時候，一個 skill 就是一套明確規則：

什麼時候使用
先做什麼
不要做什麼
需要輸出什麼
怎麼判斷任務完成

這和普通提示詞模板有點像，但粒度更接近「任務能力」。

普通提示詞模板通常是使用者每次臨時複製貼上；skills 則更適合作為 agent 工具箱的一部分，讓 Agent 根據任務選擇合適流程。

為什麼要小而可組合

README 中強調這些 skills 是小而可組合的。

這個方向很重要。

如果一個 skill 試圖包辦所有事情，它很快就會變成新的大提示詞：又長、又模糊、又難維護。小技能的優勢是邊界清楚。

比如一個 skill 專門負責：

先做計劃
修復 TypeScript 錯誤
執行測試並根據結果修復
做程式碼 review
總結專案約定
改進提示詞
清理無用抽象

這些技能可以按任務組合使用。簡單任務只用一個技能，複雜任務再串起來。

這更接近真實工程工作：你不會用同一套流程處理所有問題，而是根據問題選擇工具。

保留工程師控制權

這個倉庫的一個重要取向，是讓工程師仍然掌握控制權。

AI 編程很容易滑向兩種極端：

第一種是完全手動。AI 只是幫你寫幾行程式碼，所有上下文、計劃、驗證都靠你自己盯。

第二種是完全放手。你把任務丟給 Agent，讓它自己大改一通，最後再面對一堆難以審查的 diff。

skills 的作用是在中間找一個更穩的位置。

它讓 AI 承擔更多重複流程，但仍然用規則限制它：

先理解任務再動手
先閱讀相關檔案再改
修改範圍要可控
出現不確定時要回報
改完要驗證
不能為了炫技重構無關程式碼

這不是削弱 AI，而是讓 AI 的行動更容易被人類審查和接管。

對齊問題

AI 編程失敗的第一類問題通常是對齊失敗。

使用者想要的是一個很具體的改動，但 Agent 可能理解成一個更大的重構；使用者只想修 Bug，它卻順手改了樣式；使用者希望遵守現有架構，它卻引入新模式。

Skills 可以在任務開始階段幫助 Agent 做幾件事：

重述目標
找出影響範圍
識別已有實現模式
給出計劃
明確不做哪些事情

這一步很像工程師開工前的自檢。

如果 Agent 連任務邊界都沒說清楚，就直接寫程式碼，後面很容易越走越偏。

回饋循環問題

AI 寫程式碼不能只靠一次生成。

真實開發裡，回饋循環很重要：

改一小步
跑測試或型別檢查
看錯誤
修正
再驗證

很多 Agent 失敗，是因為它跳過了中間回饋。它一次性改很多內容，然後憑感覺總結「應該可以工作」。

Skills 可以把回饋循環顯式寫進流程裡。比如要求 Agent：

修改後執行相關檢查
如果檢查失敗，先讀錯誤訊息
不要盲目改無關檔案
每輪修復後重新驗證
最後報告驗證結果

這會讓 AI 編程更像真實除錯，而不是一次性作文。

架構控制問題

AI 很擅長生成抽象，也很擅長過度生成抽象。

為了完成一個小需求，它可能新建服務層、工具函式、配置物件、型別包裝、適配器，最後讓程式碼比需求本身複雜得多。

這類問題在大型專案裡尤其危險。因為 AI 生成的抽象看起來很「專業」，但它可能不符合專案已有風格，也可能增加維護成本。

好的 skills 會提醒 Agent：

優先沿用現有模式
不引入沒有必要的新抽象
不順手重構無關區域
修改要和任務規模匹配
先理解程式碼再設計結構

這能減少「看起來很工程化，實際上更難維護」的輸出。

Review 技能為什麼重要

寫程式碼和 review 程式碼是兩種不同狀態。

Agent 在寫程式碼時，通常會傾向於證明自己的實現成立。它會解釋為什麼這樣改可以工作，但不一定主動找風險。

Review skill 的意義，是讓 Agent 切換角色：

找潛在 Bug
找行為回歸
找遺漏測試
找邊界條件
找複雜度上升
找和現有約定不一致的地方

這對 AI 編程很重要。因為 AI 生成程式碼的速度很快，如果沒有 review，使用者很容易被大量 diff 淹沒。

一個好的 review 輸出應該優先列問題，而不是先誇實現。它要幫助工程師判斷這次改動能不能合併。

和普通 rules 檔案有什麼區別

很多 AI 編程工具都支援 rules、instructions 或 memory。

這些檔案通常記錄長期規則，比如：

專案技術棧
命名規範
測試命令
不要修改哪些目錄
回答風格偏好

Skills 更偏任務流程。

rules 告訴 Agent「長期應該怎麼做」，skills 告訴 Agent「面對某類任務時應該怎麼執行」。

兩者最好一起用。

比如 rules 裡寫專案用 pnpm test，review skill 裡要求改完後檢查測試覆蓋。這樣 Agent 不僅知道命令，也知道什麼時候該用。

適合什麼場景

mattpocock/skills 這類倉庫適合這些場景：

高頻使用 AI 編程工具
經常讓 Agent 處理真實程式碼庫
想減少 AI 越界修改
想讓 Agent 更主動地驗證結果
想把自己的工程習慣沉澱成技能
想學習別人如何設計 agent workflows
想把一堆臨時提示詞整理成可維護的技能集合

如果你只是偶爾讓 AI 寫一個小函式，可能不需要專門維護 skills。

但如果你已經把 AI 當成長期開發夥伴，skills 會逐漸變得重要。它們相當於給 Agent 配了一套可複用的工作方法。

怎麼借鑑這個倉庫

即使你不直接使用其中的每個 skill，也可以從這個倉庫學到幾件事。

第一，把失敗模式寫下來。

不要只在 AI 出錯時臨時抱怨。把它經常出錯的模式整理成規則，下一次讓 skill 提前防住。

第二，技能要短。

一個 skill 最好解決一個明確問題。越短越容易被正確呼叫，也越容易維護。

第三，輸出格式要清楚。

如果你希望 Agent 先列計劃、再執行、最後總結驗證結果，就把輸出結構寫清楚。模糊要求通常會得到模糊結果。

第四，保留人工接管點。

好的 skill 不應該讓 AI 獨自跑到很遠。遇到不確定、影響範圍擴大、測試失敗或需要產品判斷時，應該讓它停下來說明情況。

使用時要注意

第一，不要把所有事情都技能化。

太多 skills 會讓系統變複雜，Agent 也可能不知道該選哪個。先從最高頻、最痛的幾個場景開始。

第二，skills 需要迭代。

第一次寫出來的 skill 不一定好。看 AI 實際執行效果，再逐步刪減、補充和改寫。

第三，不要讓 skill 替代工程判斷。

Skill 可以改善流程，但不能保證實現正確。測試、review、構建檢查和人類判斷仍然重要。

第四，注意不同 Agent 的差異。

Claude Code、Codex、Cursor、Copilot 對 instructions、skills、rules 的支援方式不同。同一套思想可以複用，但具體格式要按工具調整。

參考

mattpocock/skills

最後一句

mattpocock/skills 值得關注的地方，不是裡面某一個神奇提示詞，而是它展示了一種更實用的 AI 編程思路：把工程經驗拆成小技能，再讓 Agent 按場景組合使用。

當 AI 編程從偶爾輔助變成日常工作流，skills 會成為約束 Agent、保留工程師控制權和提升回饋品質的重要工具。

free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型

Fri, 01 May 2026 03:41:49 +0800

free-claude-code 是一個給 Claude Code 使用的 Anthropic-compatible proxy。

它的思路不是破解 Claude Code，也不是提供官方免費的 Claude 服務，而是在本地啟動一個相容 Anthropic API 形狀的代理服務，把 Claude Code 發出的請求轉發到其他模型後端。README 中提到的後端包括 NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp 和 Ollama。

簡單說，它想解決的是：你喜歡 Claude Code 的終端體驗，但希望把模型請求接到別的 provider 或本地模型上。

它解決什麼問題

Claude Code 的互動體驗很適合開發任務。

它可以在終端裡閱讀程式碼、修改檔案、執行命令、根據專案上下文推進任務。問題是，很多使用者並不一定想始終使用同一個模型後端：

想試試 OpenRouter 上的不同模型
想用 DeepSeek 這類模型降低成本
想把請求接到本地 Ollama
想用 LM Studio 或 llama.cpp 跑本地模型
想在開發環境裡統一走一個代理入口
想比較不同模型在 Claude Code 工作流裡的表現

free-claude-code 的定位，就是在 Claude Code 和這些模型服務之間加一層相容代理。

這樣 Claude Code 仍然按 Anthropic 風格發請求，代理負責把請求適配到不同後端。

工作方式

可以把它理解成三層：

前端是 Claude Code
中間是 free-claude-code 代理
後端是 OpenRouter、DeepSeek、本地模型或其他模型服務

Claude Code 以為自己在存取一個 Anthropic-compatible API。

代理收到請求後，根據配置選擇目標 provider，轉換必要欄位，再把回應返回給 Claude Code。

這類結構的好處是，你不用改 Claude Code 本身，也不用讓每個模型服務都原生支援 Claude Code。只要代理能把介面對齊，就能把更多模型接進同一個工作流。

支援哪些後端

README 中列出的方向包括：

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

這些後端代表了幾類不同使用方式。

OpenRouter 更像模型聚合入口，可以測試不同商業和開源模型。

DeepSeek 適合關注中文能力、程式碼能力和成本的人。

LM Studio、llama.cpp、Ollama 則偏本地模型路線。它們適合在自己的機器或內網環境裡執行模型，減少外部 API 依賴，也方便做離線實驗。

NVIDIA NIM 則更偏企業和 GPU 推理部署場景。

為什麼是 Anthropic-compatible proxy

Claude Code 本來圍繞 Anthropic 的介面和模型習慣設計。

如果你想讓它接入其他模型，最直接的問題就是介面不一致：

請求欄位不同
模型名稱不同
streaming 格式不同
tool use 表達不同
錯誤返回格式不同
token 和上下文限制不同

代理層的價值就在這裡。

它把 Claude Code 這邊看到的介面維持在接近 Anthropic 的形狀，再在後端做適配。對使用者來說，配置一次代理後，就可以在相同 Claude Code 工作流裡測試不同模型。

適合什麼場景

free-claude-code 適合這些場景：

想用 Claude Code 的終端工作流
想測試非 Anthropic 模型在 Claude Code 裡的表現
想降低模型呼叫成本
想把 Claude Code 接到 OpenRouter
想接入 DeepSeek 等相容模型服務
想用 Ollama、LM Studio、llama.cpp 跑本地模型
想為團隊統一配置一個模型代理入口

如果你只是正常使用官方 Claude Code，並且對模型提供方、成本和本地部署沒有特殊需求，那不一定需要這類代理。

但如果你經常比較模型，或者希望讓 Claude Code 接入本地和第三方模型，這類工具會很有用。

和直接用 OpenRouter 或 Ollama 有什麼區別

直接用 OpenRouter、Ollama 或 LM Studio，通常只是和模型聊天，或者透過 API 呼叫模型。

free-claude-code 的重點不是替代這些服務，而是把它們接到 Claude Code 這個開發工作流裡。

區別在於：

你仍然使用 Claude Code 的終端體驗
AI 可以圍繞程式碼倉庫執行任務
模型後端可以換成其他 provider
本地模型也有機會進入 Claude Code 工作流
配置集中在代理層，而不是每個工具單獨改

所以它更像橋接器，而不是新的聊天客戶端。

本地模型要注意什麼

把 Claude Code 接到本地模型很有吸引力，但也要注意現實限制。

第一，模型能力差距。

Claude Code 的任務通常不只是聊天，還包括理解程式碼、規劃修改、編輯檔案、處理命令輸出。本地小模型不一定能穩定完成這些任務。

第二，上下文視窗。

程式碼任務很吃上下文。模型上下文太小，會導致它讀不全檔案、漏掉約束，或者在多輪任務裡丟失背景。

第三，tool use 相容性。

Claude Code 工作流依賴工具呼叫和結構化行為。後端模型即使能聊天，也未必擅長遵循工具呼叫協議。

第四，速度和硬體。

本地模型的速度取決於機器配置、量化方式和模型大小。程式碼任務如果回應太慢，體驗會明顯下降。

所以，本地模型更適合實驗、低風險任務和特定場景。真正複雜的程式碼任務，仍然要根據模型能力謹慎選擇。

使用邊界

這類專案很容易被標題誤解，所以邊界要說清楚。

第一，它不是官方 Claude Code 免費額度。

它只是把 Claude Code 的請求轉發到其他模型後端。你使用 OpenRouter、DeepSeek、NVIDIA NIM 或其他 API 時，仍然需要遵守對應服務的價格、額度和使用條款。

第二，它不是繞過授權的工具。

使用任何代理工具時，都應該遵守 Claude Code、模型服務商和專案本身的授權協議。不要把它理解成規避官方限制的方式。

第三，代理會處理你的請求內容。

程式碼、命令輸出、專案上下文可能會經過代理和後端服務。部署時要考慮日誌、金鑰、網路和隱私邊界。涉及公司程式碼或敏感專案時，最好使用受控環境。

第四，不同模型表現差異會很大。

同樣的 Claude Code 操作，換一個模型後可能出現完全不同的行為。不要預設所有模型都能替代 Claude。

和 LiteLLM 這類代理有什麼關係

從思路上看，free-claude-code 屬於「相容介面代理」這一類工具。

這類工具的共同目標是減少上層應用和底層模型服務之間的耦合。上層應用只需要面對一個相對統一的介面，底層 provider 可以按配置切換。

不同專案的側重點不同。有的更偏通用模型閘道，有的更偏 OpenAI-compatible API，有的專門為 Claude Code 這類工具做適配。

free-claude-code 值得關注的地方，是它把目標場景直接放在 Claude Code 上，而不是做一個泛泛的聊天代理。

適合怎樣的使用者

它更適合有一定折騰能力的使用者：

熟悉 Claude Code
知道 API key 和模型 provider 怎麼配置
能理解代理服務的啟動和環境變數
能排查網路、連接埠、模型名稱和 streaming 問題
願意比較不同模型在程式碼任務裡的表現

如果你只想開箱即用，官方配置通常更省心。

如果你願意搭代理、換模型、調參數，並且想讓 Claude Code 進入更多模型環境，這個專案就值得研究。

參考

Alishahryar1/free-claude-code

最後一句

free-claude-code 的價值，不在於「免費」這個詞，而在於它把 Claude Code 和更多模型後端之間接了一座橋。

當你想保留 Claude Code 的開發體驗，同時測試 OpenRouter、DeepSeek、本地模型或企業推理服務時，這類 Anthropic-compatible proxy 就有了用武之地。

Compound Engineering Plugin：把 AI 編程變成計劃、執行、評審的工程循環

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin 是 Every Inc 開源的一個 AI 編程工作流插件。

它關注的不是「讓 AI 更快寫一段程式碼」，而是把 AI 編程放進一個更像工程團隊的循環裡：先計劃，再實現，再評審，再把經驗沉澱下來。對經常使用 Claude Code、Codex、Cursor、Copilot 這類工具的人來說，這類插件解決的是工作流問題，而不只是提示詞問題。

AI 編程工具越來越強，但真實專案裡最難的往往不是生成程式碼，而是讓它持續按專案規則做事、理解任務邊界、避免重複犯錯，並在多輪迭代中積累上下文。

它解決什麼問題

很多人使用 AI 編程助手時，流程大概是這樣：

直接描述需求
讓 AI 改程式碼
看結果是否能跑
出錯後繼續補充說明
下次新任務再從頭解釋一遍

這種方式能完成小任務，但在複雜專案裡很容易遇到問題：

需求沒有先拆清楚，AI 直接開始改
改完程式碼後缺少系統性 review
專案規範靠使用者反覆提醒
同類錯誤下次仍然出現
多個 Agent 工具之間缺少統一工作方法
經驗沒有沉澱成可複用規則

Compound Engineering Plugin 想解決的就是這類問題。它把 AI 編程拆成多個階段，讓 Agent 不只是執行命令，而是參與一個更完整的工程流程。

什麼是 Compound Engineering

從專案 README 的描述看，Compound Engineering 可以理解為一種 AI 輔助軟體開發方法。

它強調一個循環：

計劃：先理解目標、拆分任務、確認路徑
執行：按計劃修改程式碼、執行命令、處理問題
評審：檢查實現品質、風險和測試覆蓋
學習：把經驗沉澱成後續可複用的規則

這個循環很像真實工程團隊的工作方式。

一個可靠的工程師不會拿到需求就立刻亂改，也不會改完就直接交差。他會先判斷影響範圍，再動手實現，之後檢查風險和測試結果，最後把踩過的坑記錄下來。AI Agent 也需要類似約束。

為什麼需要插件

提示詞可以告訴 AI「請先計劃再執行」，但提示詞本身不一定穩定。

一旦會話變長、上下文變複雜，模型可能會跳過計劃、忽略規則，或者為了完成任務而過度自信。插件的價值在於把流程固化下來，讓不同 Agent 環境都能遵循類似方法。

這類插件通常會把工作流拆成命令、規則、模板或子流程。使用者不需要每次手寫完整提示詞，而是透過固定入口觸發某個階段。

比如：

先讓 Agent 生成計劃
再按計劃逐步實現
改完後觸發 review
發現問題後返回修正
把值得保留的經驗寫入記憶或規則

這會讓 AI 編程更像「受控協作」，而不是一次性聊天。

支援哪些 Agent 環境

README 中提到，專案支援多個 AI 編程環境，包括：

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

這點值得注意。

很多工作流工具只綁定一個客戶端，換工具後規則就不能複用。Compound Engineering Plugin 更像一套跨 Agent 的工程方法，把類似的計劃、執行、評審流程帶到不同工具裡。

如果你同時使用多個 AI 編程助手，這類統一工作流會更有價值。不同工具能力不同，但專案規範、評審習慣和任務拆解方法應該盡量一致。

計劃階段有什麼用

計劃階段的價值，是防止 AI 過早動手。

複雜任務裡，真正重要的問題通常是：

要改哪些檔案
哪些模組可能受影響
現有模式是什麼
有沒有測試
風險點在哪裡
是否需要先閱讀文件
能不能拆成更小步驟

如果 Agent 沒有先想清楚這些問題，就直接開始寫程式碼，很容易做出看似完成、實際偏離專案結構的實現。

計劃並不一定要很長。好的計劃應該短、具體、可執行。它的目的不是製造文件，而是讓後續實現有邊界。

執行階段要避免什麼

AI 執行程式碼任務時，最容易出現幾類問題：

順手重構無關程式碼
覆蓋使用者已有修改
只改 happy path
忽略錯誤處理
不按專案已有風格寫
沒有執行必要驗證
遇到錯誤後盲目嘗試

工作流插件無法保證這些問題完全消失，但可以透過規則和階段約束減少發生機率。

比如，執行階段可以要求 Agent 按計劃逐步推進；遇到超出計劃範圍的發現時，先說明風險；修改共享模組時，補充測試或至少執行相關驗證。

這種約束對大型程式碼庫尤其重要。AI 寫程式碼越快，越需要流程來限制它的慣性。

評審階段為什麼重要

很多 AI 編程失敗，不是因為程式碼完全不能執行，而是因為細節有問題：

邊界條件沒處理
狀態更新不一致
API 合約被悄悄改了
測試覆蓋不到關鍵路徑
錯誤提示不清楚
效能或安全風險沒有被提到

評審階段就是把 Agent 從「作者模式」切換到「審查模式」。

作者模式容易為自己的實現找理由；審查模式則要主動找漏洞、回歸風險和遺漏測試。把這兩個階段分開，會比讓同一個回覆裡同時完成實現和自我審查更可靠。

對使用者來說，評審輸出也更有價值。它能幫助你快速判斷這次修改是否值得合併，還是需要繼續返工。

學習和記憶的意義

專案名字裡的 “Compound” 暗示了一個重要想法：工程經驗應該複利增長。

如果 AI 每次犯錯後只是當場修好，下次又犯同樣錯誤，效率提升就很有限。更好的方式是把有價值的經驗沉澱下來：

這個專案的目錄約定
某類錯誤的排查方法
測試命令和注意事項
不要觸碰的生成檔案
程式碼風格偏好
常見實現模式

這些經驗可以變成規則、記憶、文件或模板。後續任務中，Agent 先讀取這些沉澱，再開始工作。

這就是 AI 編程從「單次問答」走向「長期協作」的關鍵。

適合什麼場景

Compound Engineering Plugin 適合這些場景：

長期使用 AI Agent 寫程式碼
一個專案會被多次、多輪修改
希望 AI 先計劃再實現
希望改完後自動進入 review 思維
團隊想統一 AI 編程流程
同時使用 Claude Code、Codex、Cursor 等多個工具
希望把專案經驗沉澱成可複用規則

如果只是偶爾讓 AI 寫一個小腳本，完整流程可能顯得偏重。

但如果你正在把 AI 編程助手當成日常開發夥伴，計劃、執行、評審、學習這套循環就會明顯有用。

和普通提示詞模板有什麼區別

普通提示詞模板通常解決的是「怎麼說清楚任務」。

比如：

請一步步思考
請先閱讀檔案
請保持程式碼風格一致
請執行測試
請總結修改內容

這些提示當然有用，但它們還是依賴使用者每次正確使用。

Compound Engineering Plugin 更偏工作流層。它把這些要求組織成可重複的過程，並適配不同 Agent 工具。這樣你不是每次從零寫提示詞，而是在一套流程裡推進任務。

簡單說，提示詞模板像提醒，工作流插件像制度。

使用時要注意

第一，不要把流程變成負擔。

小任務不一定需要完整計劃和長篇評審。好的工作流應該能根據任務複雜度調整，簡單問題快速處理，複雜問題再走完整循環。

第二，評審不能替代測試。

Agent review 能發現很多問題，但它仍然可能漏掉真實執行時錯誤。最終判斷還要看測試、型別檢查、構建結果和人工審查。

第三，規則要持續清理。

沉澱經驗很重要，但規則越積越多也會變成噪音。過時規則、重複規則、只適合某次任務的臨時經驗，都應該定期整理。

第四，跨工具一致不等於完全相同。

Claude Code、Codex、Cursor、Copilot 等工具能力和互動方式不同。統一的是工作方法，不一定是每個命令、每個配置細節都完全一樣。

適合怎樣的團隊

如果一個團隊已經允許 AI Agent 修改真實程式碼，那麼只討論「哪個模型更強」是不夠的。

更應該關心：

AI 修改前是否理解任務
AI 修改中是否遵守專案邊界
AI 修改後是否主動審查風險
AI 是否能從歷史錯誤中學習
團隊是否有統一的 Agent 使用規範

Compound Engineering Plugin 這類專案的意義就在這裡。它把 AI 編程從個人技巧，往團隊可複用流程推進了一步。

參考

EveryInc/compound-engineering-plugin

最後一句

Compound Engineering Plugin 值得關注的地方，不是多一個 AI 編程命令，而是把 AI 編程組織成可循環改進的工程流程。

當 AI Agent 開始參與真實專案，計劃、執行、評審和經驗沉澱會比單次生成程式碼更重要。

TradingAgents-CN：面向中文使用者的多智能體金融交易研究框架

Fri, 01 May 2026 03:14:15 +0800

TradingAgents-CN 是一個面向中文使用者的多智能體金融交易研究框架。

它的目標不是給出「買哪隻股票」的簡單答案，而是用多個 AI Agent 模擬一個更完整的金融分析團隊：有人看基本面，有人看技術面，有人關注新聞和情緒，也有人負責風險和最終決策。對想研究 LLM + Agent + 金融分析的人來說，這類專案很適合作為實驗入口。

需要先說清楚：這類工具適合學習、研究和輔助分析，不應該被當成實盤交易建議。金融市場有風險，模型輸出也可能出錯、滯後或過度自信。

它解決什麼問題

普通聊天模型當然也能分析股票。

你可以直接問：「幫我分析某某公司能不能買。」模型會給出一段看起來完整的回答。但這種方式有幾個問題：

分析鏈路不透明
不同維度容易混在一起
缺少角色分工
缺少正反觀點碰撞
風險提示可能流於形式
很難復現同一套分析流程

TradingAgents-CN 的思路是把金融分析拆成多個角色，讓不同 Agent 負責不同角度，再透過協作、討論和總結形成分析結果。

這更接近真實投研流程。一個投資判斷通常不會只看一條新聞或一個技術指標，而是要結合公司基本面、市場環境、價格走勢、資金情緒、政策風險和倉位控制。

多智能體分析是什麼意思

多智能體不是簡單地讓多個模型輪流說話。

更有價值的做法，是給不同 Agent 分配清楚職責。比如：

市場分析 Agent：關注行情走勢、價格變化和市場環境
基本面分析 Agent：關注公司業務、財務資料和長期價值
新聞分析 Agent：關注公告、新聞、輿情和事件影響
技術分析 Agent：關注趨勢、指標、支撐阻力和交易訊號
風險管理 Agent：關注波動、回撤、倉位和不確定性
決策 Agent：綜合不同意見，形成最終判斷

這樣的結構可以減少單個模型「一口氣說完所有結論」的問題。

當不同角色圍繞同一個標的展開分析時，系統更容易呈現出多維度判斷，也更容易暴露分歧。對學習者來說，這比只看一段總結更有啟發。

為什麼需要中文版本

金融分析和語言環境關係很深。

中文使用者關注的資料來源、市場習慣、股票名稱、交易制度、新聞表達和常見術語，都和英文環境不同。直接使用英文框架，經常會遇到幾類問題：

中文股票名稱和代碼處理不順
A 股、港股、美股語境混雜
中文財經新聞理解不穩定
國內資料源接入不方便
輸出風格不符合中文使用者閱讀習慣

TradingAgents-CN 的意義在於把這套多智能體金融分析流程面向中文使用者做了適配。它讓中文使用者更容易搭建、執行和理解整個交易分析實驗流程。

可以用來做什麼

這個專案更適合做研究和輔助分析，而不是自動下單。

比較合適的用途包括：

學習多智能體系統如何協作
研究 LLM 在金融分析中的表現
對股票進行多角度資訊整理
比較不同模型在投研任務中的差異
搭建自己的金融分析 Agent 原型
複盤某個標的的歷史資訊和風險點
練習把投研流程拆成可執行任務

如果你正在學習量化交易、金融工程、AI Agent 或 LLM 應用開發，這類專案可以幫助你理解「AI 投研助手」背後的工程結構。

不適合做什麼

它不適合被直接當成穩賺工具。

尤其不適合：

直接根據輸出滿倉買賣
用模型結論替代自己的風險判斷
把短期價格預測當成確定結果
忽略交易成本、滑點和流動性
不做回測就接入真實帳戶
用單次分析結論替代長期投資策略

LLM 擅長整理資訊、生成解釋、模擬推理流程，但它並不天然擁有穩定預測市場的能力。金融市場裡，資訊噪音、突發事件和行為博弈都很強，模型輸出只能作為參考材料之一。

和普通量化框架有什麼區別

傳統量化框架更關注資料、因子、回測、組合優化和交易執行。

比如你會定義策略規則：

均線突破
動量因子
價值因子
波動率過濾
止損止盈
倉位管理

然後用歷史資料回測策略表現。

TradingAgents-CN 更偏向「智能體分析框架」。它關注的是如何讓多個 LLM Agent 圍繞金融任務協作，如何模擬投研討論，如何把新聞、基本面、技術面和風險判斷組織起來。

兩者不是替代關係。

更現實的用法是：傳統量化系統負責可驗證的規則和回測，Agent 系統負責資訊整理、報告生成、觀點對比和輔助決策。最終能不能進入真實交易，還要經過嚴謹回測、風控和人工審核。

和直接問 ChatGPT 有什麼區別

直接問模型的門檻最低，但流程很鬆散。

你問一次，它答一次。換個問法，結論可能就變了。你很難保證它每次都從同樣的維度分析，也很難讓它穩定扮演多個互相制衡的角色。

TradingAgents-CN 的價值是把分析流程結構化：

角色更明確
步驟更可復現
資訊來源更容易組織
觀點碰撞更自然
風險檢查更容易單獨處理
輸出更像一份投研流程結果

這對學習和研究很有用。你可以觀察不同 Agent 如何影響最終結論，也可以替換模型、調整提示詞、修改角色分工，比較結果變化。

使用時要關注哪些風險

第一，資料品質。

金融分析非常依賴資料。如果行情、財報、新聞或公告資料不完整、不及時，Agent 分析再流暢也可能建立在錯誤基礎上。

第二，模型幻覺。

LLM 可能編造不存在的事實、誤解資料含義，或者把舊資訊當成新資訊。涉及具體股票時，必須回到資料源核對。

第三，過度解釋。

模型很擅長給出「看起來合理」的解釋，但市場價格變化未必真的來自它列出的原因。不要把事後解釋誤當成因果證明。

第四，回測和實盤差距。

即便某個策略在歷史資料中表現不錯，真實交易中仍然會遇到滑點、手續費、流動性、停牌、漲跌停、極端行情等問題。

第五，許可證和商用邊界。

README 中提到專案採用混合許可證。個人學習研究和商業使用的條件可能不同。如果準備把它放進商業產品或服務，需要先仔細閱讀專案許可證說明。

適合怎樣的人研究

TradingAgents-CN 適合這些人：

想學習 AI Agent 架構的開發者
想研究 LLM 金融分析能力的人
做量化交易但想加入自然語言分析的人
想搭建投研輔助工具的團隊
想了解多角色協作如何影響決策的人
希望用中文環境實驗交易 Agent 的使用者

如果你的目標只是獲得一個簡單的買賣建議，這個專案反而不是最合適的打開方式。它更值得關注的是流程、角色、協作和風險控制，而不是某一次輸出的結論。

可以怎麼擴展

這類框架後續有很多可擴展方向：

接入更多可靠資料源
增加本地模型支援
加入回測模組
細化 A 股、港股、美股不同市場規則
增加產業分析 Agent
增加組合管理和倉位控制
加強報告引用和資料溯源
把 Agent 結論和傳統量化訊號結合

真正有價值的金融 AI 系統，通常不是讓模型單獨決定一切，而是讓它嵌入一個可驗證、可追蹤、可風控的流程裡。

參考

hsliuping/TradingAgents-CN

最後一句

TradingAgents-CN 值得關注的地方，不是它能不能預測下一根 K 線，而是它把金融分析拆成了一個多智能體協作流程。

把它當作學習和研究工具，會比把它當作自動賺錢機器更合理。

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 編程助手才更容易按專案規則做事。

Claude Code Hooks Mastery：13 個 Hooks 生命週期與自動化控制入門

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery 是一個圍繞 Claude Code Hooks 的學習專案。

它不是只給幾個零散腳本，而是把 Claude Code 的 hooks 生命週期、配置方式、腳本寫法和常見自動化場景放在一起講清楚。對想讓 Claude Code 更可控、更像工程化助手的人來說，這類資料很值得看。

Claude Code 預設已經能讀程式碼、改檔案、跑命令。但如果你想讓它在特定時機自動檢查權限、攔截危險操作、注入專案規範、執行測試、提醒團隊規則，單靠聊天指令就不夠穩定。Hooks 的價值就在這裡：把「每次都要提醒 AI 的規則」變成可執行的流程。

Hooks 解決什麼問題

使用 Claude Code 一段時間後，常見痛點大概有這些：

每次新會話都要重複告訴它專案規則
擔心它執行不該執行的命令
希望檔案修改前後自動做檢查
想在提交前自動跑格式化、測試或安全掃描
想把團隊規範寫成固定流程，而不是靠口頭提醒
想在工具呼叫前後拿到上下文，做記錄或攔截
希望複雜任務可以觸發子代理或專門腳本處理

Hooks 就是為這些「固定時機的自動動作」準備的。

你可以把它理解成 Claude Code 工作流裡的事件鉤子：當會話開始、使用者提交提示詞、模型準備呼叫工具、工具呼叫完成、代理即將結束等節點發生時，Claude Code 可以執行你配置的腳本。

13 個 Hooks 生命週期

專案 README 的重點之一，是系統整理了 Claude Code 的 13 個 hook 事件。

這些事件覆蓋了從會話開始到工具呼叫、從使用者輸入到代理結束的多個節點。按用途可以粗略分成幾類：

會話啟動相關：用於初始化環境、注入專案上下文
使用者輸入相關：用於檢查提示詞、補充規則、做稽核
工具呼叫前相關：用於權限判斷、命令攔截、安全檢查
工具呼叫後相關：用於記錄結果、觸發格式化、執行驗證
任務結束相關：用於總結、清理、通知或保存狀態

這種生命週期設計讓你不必把所有規則都寫進一個超長提示詞裡。

比如，權限控制應該發生在工具呼叫前；格式化檢查更適合發生在檔案修改後；專案規範注入適合發生在會話開始或使用者輸入後。把規則放到正確的 hook 節點，通常比把所有內容塞進 system prompt 更可靠。

配置檔案在哪裡

Claude Code 的 hooks 通常透過設定檔配置。

常見位置包括：

使用者級配置：~/.claude/settings.json
專案級配置：.claude/settings.json

使用者級配置適合放個人偏好，比如通用安全規則、命令攔截、日誌路徑。

專案級配置適合放倉庫相關規則，比如這個專案必須跑什麼測試、哪些目錄不能改、生成檔案怎麼處理、提交前要做哪些檢查。

如果你在團隊裡使用 Claude Code，更推薦把專案級配置放進倉庫。這樣每個人打開專案時，拿到的是同一套 AI 協作約束，而不是各自憑記憶提醒。

單檔案腳本為什麼重要

專案裡強調了 UV 單檔案腳本的寫法。

這類腳本的好處是部署簡單。一個 Python 檔案就可以宣告依賴並執行，不必為了一個 hook 單獨維護複雜環境。對 hooks 來說，這很合適，因為很多 hook 只是做一件小事：

檢查命令是否允許執行
判斷檔案路徑是否安全
讀取專案規範並返回給 Claude
掃描輸出中是否包含敏感資訊
在修改後執行格式化或測試
把事件寫入日誌

Hook 腳本越小，越容易維護，也越不容易變成新的複雜系統。

可以做哪些自動化

claude-code-hooks-mastery 展示的方向比較多，實際工作中最常見的是下面幾類。

1. 權限和安全控制

這是 hooks 最直接的用途。

比如在 Claude Code 準備執行命令之前，先檢查命令內容。如果命令包含刪除、重置、清空、覆蓋等高風險動作，就阻止執行或要求人工確認。

類似規則還可以用於檔案路徑：

不允許修改生產配置
不允許寫入金鑰檔案
不允許刪除遷移腳本
不允許觸碰指定目錄
不允許執行未批准的網路命令

這類保護放在工具呼叫前，比寫一句「不要做危險操作」更可靠。

2. 上下文注入

很多專案都有固定背景：

技術棧
編碼規範
測試命令
分支策略
目錄結構
禁止事項
生成檔案處理規則

這些內容每次手動告訴 Claude Code 很麻煩，也容易漏。Hooks 可以在會話開始或使用者提交提示詞後，把必要上下文自動注入進去。

這相當於給 Claude Code 配一個專案級的工作說明書。它不會替代 README 或開發文件，但能讓 AI 在執行任務前更快進入正確狀態。

3. 修改後的驗證

當 Claude Code 修改檔案後，可以透過 hook 自動觸發檢查。

常見動作包括：

執行格式化
執行 lint
執行單元測試
檢查型別錯誤
掃描生成檔案
校驗 Markdown 或 JSON 格式

這對減少低級錯誤很有幫助。尤其是 AI 改動多個檔案時，修改後自動跑一輪輕量驗證，可以更早發現問題。

不過也要注意，hook 裡不適合預設塞太重的任務。每次檔案改動都跑完整測試套件，可能會讓體驗變得很慢。更實用的做法是按檔案類型、目錄和任務風險選擇檢查範圍。

4. 團隊規則驗證

如果團隊已經有明確約定，可以把一部分約定放進 hooks。

比如：

提交訊息格式
程式碼風格規則
禁止直接修改某些生成檔案
文件必須同步更新
API 變更必須改測試
某些目錄只能用指定工具生成

這會讓 Claude Code 更像團隊流程的一部分，而不是一個不受約束的外部助手。

當然，hooks 不應該替代 CI。它更適合做本地快速提醒和前置攔截，真正的最終驗證仍然應該交給 CI、review 和測試系統。

5. 子代理和專門任務

README 裡還提到子代理相關內容。

這類用法適合把複雜任務拆給更專門的流程處理。比如主會話負責理解需求，hook 或配置觸發專門的檢查、稽核、總結、文件整理任務。

對個人使用者來說，最先值得做的不是複雜代理編排，而是把重複、明確、低風險的動作交給 hooks。等規則穩定後，再考慮更複雜的自動化。

Statusline 和輸出樣式

專案還覆蓋了狀態列和輸出樣式。

這部分看起來像體驗細節，但對長期使用 Claude Code 很有意義。狀態列可以展示當前上下文、任務狀態、環境資訊或提示資訊；輸出樣式則可以讓 Claude Code 的回答更符合你的工作習慣。

如果你每天都在同一個終端裡和 AI 協作，這些細節會影響效率。好的狀態提示能減少誤操作，也能讓你更快判斷當前會話是否處在正確專案、正確分支、正確環境裡。

不要把 hooks 寫得過重

Hooks 很強，但不適合什麼都往裡面塞。

比較好的規則是：

高頻動作要快
安全攔截要明確
輸出要短
失敗原因要可讀
腳本盡量單一職責
重型檢查交給顯式命令或 CI

如果一個 hook 每次都執行十幾秒，使用者很快就會想關掉它。如果一個 hook 攔截規則含糊不清，Claude Code 和使用者都會難以理解下一步該怎麼做。

Hooks 最適合處理那些邊界清楚的事情：允許或拒絕、補充上下文、記錄日誌、執行輕量檢查、提示下一步。

適合怎樣的使用者

如果你只是偶爾讓 Claude Code 改一小段程式碼，可能暫時不需要深入 hooks。

但如果你符合下面幾種情況，就很適合研究這個專案：

高頻使用 Claude Code
經常讓 AI 修改真實專案程式碼
擔心 AI 執行危險命令
想把團隊規範自動注入 AI 工作流
希望修改後自動跑檢查
想把重複提醒變成配置
正在搭建更穩定的 AI 編程流程

尤其是多人協作專案，hooks 的意義會更明顯。它可以把一部分團隊經驗沉澱成腳本，而不是靠每個人臨時提醒 AI。

使用時要注意

第一，先從安全類 hook 開始。

相比複雜自動化，命令攔截、路徑保護、敏感檔案檢查更容易落地，也更能立刻降低風險。

第二，專案級規則要謹慎提交。

.claude/settings.json 會影響所有使用這個倉庫的人。把規則提交前，最好確認它不會過度限制正常開發，也不會依賴只有你本機才存在的路徑。

第三，hook 輸出要簡潔。

Claude Code 會消費這些輸出。輸出太長，會污染上下文；輸出太模糊，又起不到指導作用。最好只返回必要判斷和下一步建議。

第四，保持可除錯。

Hooks 一旦變多，問題可能出在配置、腳本、權限、路徑、依賴或 Claude Code 本身。給腳本留下清楚日誌，會讓後續排查輕鬆很多。

參考

disler/claude-code-hooks-mastery

最後一句

Claude Code Hooks 的價值，是把「希望 AI 每次都記住的規矩」變成真正會執行的流程。

如果你已經開始把 Claude Code 用在真實專案裡，hooks 會是從「會聊天的編程助手」走向「可約束的工程協作者」的關鍵一步。

Claude-Mem：給 Claude Code 加上跨會話長期記憶

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem 是一個給 Claude Code 使用的持久化記憶系統。

它想解決的問題很具體：AI 編程助手每次開新會話時，往往會忘記之前討論過的架構決策、踩過的坑、專案偏好和實作背景。
如果一個專案做得久，每次都重新解釋上下文，非常浪費時間。

Claude-Mem 的思路是：把 Claude Code 的會話內容壓縮成記憶，存進本地資料庫和向量庫，之後再透過搜尋工具找回來。

它解決什麼問題

Claude Code 很適合處理程式碼任務，但會話上下文畢竟有限。

常見痛點包括：

新會話不知道舊會話做過什麼
專案裡的設計決策需要反覆解釋
曾經排查過的問題容易重複踩
長期任務缺少連續記憶
多次對話之間很難沉澱專案知識

Claude-Mem 就是圍繞這些問題設計的。

它不是簡單保存聊天記錄，而是把會話壓縮成更容易檢索的記憶片段。這樣後續需要時，可以透過語義搜尋把相關上下文找回來。

工作方式

從 README 的設計看，Claude-Mem 主要由幾部分組成。

第一部分是 hooks。

它會接入 Claude Code 的會話流程，在合適的時機捕獲會話資料。

第二部分是後台 worker。

worker 負責把原始會話內容處理成更短、更可檢索的記憶。

第三部分是本地儲存。

專案使用 SQLite 保存結構化元資料，用 Chroma 保存向量索引。這樣既能保留會話記錄的基本資訊，也能支援語義檢索。

第四部分是 mem-search。

這是給 Claude Code 使用的查詢入口。需要找回舊上下文時，可以透過它搜尋相關記憶。

整體流程可以理解為：

Claude Code 會話產生內容
hooks 捕獲會話資料
worker 非同步壓縮和整理
記憶寫入 SQLite 與 Chroma
後續透過 mem-search 檢索

適合什麼場景

Claude-Mem 適合長期專案，而不是一次性小任務。

比如：

一個倉庫持續開發很多天
程式碼結構複雜，背景說明很多
需要記住專案約定、命名習慣和架構選擇
經常讓 Claude Code 修 Bug、寫功能、整理文件
希望 AI 能記住「之前為什麼這麼改」

如果你只是臨時讓 Claude Code 改一行程式碼，長期記憶意義不大。
但如果你把 Claude Code 當作長期協作者，它就會變得有用。

安裝和啟動

README 中給出的安裝方式很直接：

1
2

npm install -g claude-mem
claude-mem install

啟動時可以使用：

`1`	`claude-mem start`

查看狀態：

`1`	`claude-mem status`

如果需要停止：

`1`	`claude-mem stop`

這些命令背後的目標，是把記憶系統作為一個長期執行的本地服務接到 Claude Code 工作流裡。

`mem-search` 怎麼用

mem-search 是找回記憶的關鍵入口。

它的用途不是替代普通搜尋，而是讓 Claude Code 能按語義查詢過去會話中的內容。

比如你可以讓 Claude Code 查詢：

某個模組之前為什麼這樣設計
某個 Bug 當時怎麼排查
專案裡約定的命名規則
之前討論過的技術取捨
某次重構的背景原因

這種查詢和簡單關鍵字搜尋不同。
如果記憶壓縮和向量索引做得好，即使你不記得原話，也能找回相近語義的內容。

和普通專案文件有什麼區別

專案文件適合記錄穩定結論。

比如：

架構說明
部署流程
API 約定
資料庫結構
開發規範

Claude-Mem 更適合記錄會話過程中產生的上下文。

比如：

為什麼某個方案被放棄
某個臨時問題怎麼繞過
某個實作背後的討論過程
還沒來得及寫進文件的專案偏好
多次對話裡積累出的任務背景

兩者不是互相替代。
比較好的方式是：穩定知識寫進專案文件，過程性上下文交給記憶系統輔助檢索。

使用時要注意什麼

第一，長期記憶不是越多越好。

如果所有對話都無差別保存，後續檢索可能會變得嘈雜。真正有價值的是專案決策、實作背景、問題排查和長期偏好。

第二，記憶不能替代程式碼和文件。

AI 搜到的舊上下文只能作為參考。最終判斷仍然要看目前程式碼、測試結果和最新需求。

第三，隱私和本地資料要注意。

既然它會保存會話內容，就要清楚哪些專案適合接入，哪些敏感資訊不應該進入對話。

第四，記憶系統需要維護。

隨著專案推進，舊記憶可能過時。過時的上下文如果被誤用，反而會誤導後續任務。

為什麼這類工具值得關注

AI 編程工具正在從「單次問答」走向「長期協作」。

單次問答裡，模型只要回答目前問題就夠了。
長期協作裡，它需要知道專案歷史、之前的決策、團隊偏好和已經踩過的坑。

Claude-Mem 這類工具的意義就在這裡：它把「記住上下文」從臨時聊天能力，變成一個可以安裝、執行、檢索的本地系統。

對真實工程專案來說，這比單純讓模型上下文窗口變長更實用。
因為很多資訊不是一次性塞進上下文就好，而是需要在合適的時候被找回來。

適合誰嘗試

如果你符合下面幾種情況，可以考慮試試：

高頻使用 Claude Code
經常跨天處理同一個專案
專案上下文比較複雜
經常需要向 AI 重複解釋背景
想把會話裡的經驗沉澱下來

如果你只是偶爾使用 Claude Code，或者專案很小，暫時不一定需要這類系統。

參考

thedotmack/claude-mem

最後一句

Claude-Mem 的重點不是「保存聊天記錄」，而是讓 Claude Code 能在後續任務裡找回有用上下文。

當 AI 編程從一次性任務變成長期專案協作，記憶系統會越來越重要。
它不能替代文件和測試，但可以減少重複解釋，讓 AI 更像一個了解專案歷史的助手。

Claude.md 不是越長越好：AI 編程全域記憶文件該怎麼寫

Wed, 29 Apr 2026 21:07:37 +0800

最近看到一個關於 AI 編程全域記憶文件的討論：專案裡使用 Claude.md、AGENTS.md 這類文件之後，效果不一定會變好，甚至可能讓成功率下降，同時推理成本還會上升。

這件事乍看有點反直覺。我們通常會覺得，給 AI 更多專案背景、更多規則、更多說明，它應該更容易寫對程式碼。
但實際問題在於：Claude.md 不是普通文件，而是每次對話都會被塞進上下文的全域記憶。它寫得越多，模型每次都要讀得越多；它寫得越含糊，模型每次都要多做判斷；它寫進了不該寫的流程，模型還可能在不相關的任務裡觸發多餘動作。

所以，Claude.md 真正難寫的地方，不是怎麼把內容寫全，而是怎麼判斷哪些內容值得長期佔用上下文。

Claude.md 到底是什麼

在 AI 編程工具裡，Claude.md、AGENTS.md 這類文件本質上都是全域記憶文件。

普通對話會進入上下文，但上下文長度有限。對話長了以後，歷史內容會被壓縮，部分細節會丟失。全域記憶文件的作用，是把一些重要規則固定下來，讓模型在每次任務開始時都能看到。

這意味著兩件事：

寫進去的內容更不容易被遺忘
寫進去的內容也會在每次任務裡產生成本

它不像一份 README，只在需要時被閱讀。它更像一套長期有效的工作約束。只要放進去，就預設每次都會影響模型的判斷。

因此，Claude.md 不是專案介紹，也不是經驗合集，更不是把所有開發流程都塞進去的地方。它應該只存放那些模型如果不知道，就容易反覆犯錯的規則。

為什麼寫了反而可能變差

全域記憶文件寫得不好，主要會帶來三類問題。

第一，它會佔用上下文。

如果 Claude.md 有一千行，那麼這些內容會長期進入模型上下文。真正與當前任務有關的程式碼、錯誤資訊、需求說明，反而會被擠壓。上下文不是免費的空間，越大的全域規則，越容易稀釋當前任務的重點。

第二，它會觸發多餘行為。

比如在全域文件裡寫：

1
2

每次開始任務前，都要完整閱讀專案目錄。
每次修改後，都要執行完整鏈路測試。

這些話看起來很負責，但放在全域記憶裡就會變成「所有任務都預設執行」。哪怕只是改一行文案，模型也可能因為這條規則去做不必要的探索和測試。結果就是任務變慢、成本變高，甚至引入新的干擾。

第三，它會增加判斷負擔。

像「保持程式碼優雅、簡潔、可維護、可擴展」這類話，聽起來正確，但實際約束很弱。模型每次生成程式碼時都要判斷什麼叫優雅、什麼叫可擴展，卻沒有得到明確邊界。

更好的寫法不是堆抽象美德，而是寫具體禁令或反例。比如：

1
2
3

不要為了單個調用點新增通用抽象。
不要在沒有測試覆蓋的情況下改動共享解析邏輯。
不要把臨時腳本放進業務源碼目錄。

這些規則更具體，也更容易被執行。

應該寫什麼

判斷一條內容要不要寫進 Claude.md，可以用一個簡單標準：

如果不寫，AI 就會反覆犯同一種錯誤，那它值得寫進去。

適合寫進全域記憶文件的內容，通常有這些特點：

長期有效
與當前倉庫強相關
無法從程式碼結構自然推斷
能明確改變模型行為
最好是約束、禁令、路徑規則或固定命令

比如：

所有 Hugo 文章只改 index.zh-cn.md，不自動生成其他語言版本。
文章 front matter 必須包含 title/date/draft/tags/categories/slug/description。
不要修改 public/ 目錄裡的構建產物。
PowerShell 下執行部署時使用 scripts/deploy.ps1。

這些內容不是泛泛而談，而是和倉庫的真實工作方式綁定。模型如果不知道，就可能做錯；模型知道以後，確實能減少誤操作。

不該寫什麼

很多人容易把 Claude.md 寫成專案說明書，這通常沒有必要。

不太適合寫進去的內容包括：

專案願景和背景介紹
大段目錄結構說明
臨時任務計畫
一次性的除錯步驟
抽象的程式碼審美要求
只在少數情況下才需要執行的長流程

比如「這是一個電商專案，包含商品、訂單、使用者模組」這種描述，對模型完成具體編程任務幫助有限。真正開發時，模型應該根據當前需求、規格文件、程式碼結構和測試來判斷，而不是靠全域記憶裡的粗略介紹。

目錄結構也是類似。除非某個目錄有特殊約定，比如「共享元件只能從這個目錄引用」，否則沒必要把整個樹狀結構都寫進去。模型可以自己讀取專案目錄，硬塞一份靜態目錄說明反而容易過期。

流程更適合做成技能或命令

如果一段內容是「第一步做什麼、第二步做什麼、第三步做什麼」，它未必適合放進 Claude.md。

長期流程可以沉澱成技能、腳本或命令。這樣做的好處是：全域記憶裡只需要保留名稱和觸發條件，真正的詳細步驟只在需要時載入。

比如：

1
2

當使用者要求翻譯 Hugo 文章時，使用 post-translate 技能。
當使用者要求部署站點時，執行 hugo-rsync-deploy 流程。

這比把完整翻譯流程、部署流程都寫進 Claude.md 更輕。全域記憶保持短，具體流程交給可觸發的工具。

Claude 最近的初始化流程也在往這個方向走：不只是生成一個 Claude.md，還會嘗試把可複用流程拆成 skills，把固定事件拆成 hooks。這個變化背後的思路很清楚：全域記憶只做入口，細節按需載入。

Claude.md 需要持續迭代

Claude.md 不應該一次寫完就不管。

更合理的方式是先保持簡短，讓模型在真實任務裡暴露問題。某個錯誤出現一次，可以先人工處理；如果同類錯誤出現兩次以上，就說明它可能值得沉澱為全域規則。

這類迭代比一開始寫一大堆規則更有效。因為一開始你不知道哪些規則真的有用，也不知道哪些內容會變成噪音。隨著專案變大、協作變多、模型行為逐漸穩定，再慢慢把高頻問題寫進去。

還有一個重要趨勢：模型越強，全域記憶文件反而應該越短。

以前很多需要寫進提示詞的要求，現在模型已經能自然做到。繼續把這些基礎要求塞進 Claude.md，只會增加上下文負擔。全域記憶應該隨著模型能力提升而收縮，只保留這個倉庫獨有、模型無法自動推斷的部分。

一個更實用的寫法

寫 Claude.md 時，可以按這個順序思考：

這個倉庫有什麼特殊約定？
哪些錯誤模型已經犯過不止一次？
哪些目錄、文件或命令絕對不能誤用？
哪些流程應該改成技能、腳本或命令，而不是常駐上下文？
哪些內容只是介紹，可以刪掉？

最後得到的文件，可能只有幾十行。它不需要完整解釋專案，而是要精確約束行為。

一個好的 Claude.md，應該像這樣：

# 工作規則

- 只改與當前任務相關的文件。
- 不要修改 public/、resources/ 這類構建產物目錄。
- Hugo 文章改寫只處理 index.zh-cn.md，不生成其他語言版本。
- 如果涉及部署，先執行 hugo 構建，再執行既有 rsync 腳本。
- 遇到已有使用者改動時，不要回滾，必須基於現狀繼續修改。

它短，但每一條都能影響實際行為。這樣的內容才值得長期佔用上下文。

最後一句

Claude.md 的價值不在於讓 AI「知道更多」，而在於讓 AI「少犯固定錯誤」。

它不是知識庫，也不是專案百科，而是 AI 編程過程裡的長期約束文件。
寫得越具體、越短、越貼近真實錯誤，它越有用；寫得越泛、越長、越像專案介紹，它越可能拖慢模型，甚至讓結果變差。

把全域記憶當成稀缺資源，而不是無限草稿紙。這大概就是寫好 Claude.md 最重要的一條原則。

Codex 開始控制電腦，對以後意味著什麼？

Wed, 29 Apr 2026 11:28:25 +0800

Codex 這次最值得關注的變化，不是又多了一個普通按鈕，而是它開始往「控制電腦」這個方向走。

以前我們使用 AI，更多是在聊天框裡提問、複製、貼上、再手動操作軟體。
現在這個邊界開始往外擴：AI 不只是回答你，而是可以根據你的目標去操作桌面應用。

這件事短期看是一個新功能，長期看可能會改變很多人使用電腦的方式。

這個功能是什麼

簡單說，Codex 的電腦使用能力，就是讓它能接觸並操作桌面環境。

它可以做的事包括：

可以選擇並控制某個應用
可以用自然語言下達任務
可以打開瀏覽器、AI 工具、本地文件或其他軟體
可以輸入內容、點擊按鈕、等待結果
可以把多個步驟串成一個任務
可以在後台繼續執行，不需要使用者每一步都手動跟著

它的定位不是單純替你寫一段文字，而是替你完成一段操作流程。

這就是 Agent 和普通聊天機器人的關鍵差別：
聊天機器人主要給答案，Agent 更接近「拿到目標後去執行」。

為什麼這件事重要

過去很多自動化都要求你會寫腳本。

比如你想完成一個跨軟體流程：

打開網頁
找資料
複製內容
交給另一個 AI 工具處理
保存文件
再打開本地目錄檢查結果

如果要自動化這件事，傳統做法可能是寫瀏覽器腳本、調用 API、寫本地程序，甚至還要處理各種軟體窗口。

但很多普通使用者不會寫這些東西。
就算會寫，也未必值得為一個臨時任務專門寫腳本。

電腦使用能力的意義就在這裡：它把「腳本能力」往自然語言方向推了一步。

你不一定要告訴它每一步怎麼點。
你可以告訴它你要什麼結果，讓它自己去嘗試完成。

它能改變哪些工作流

我覺得最先被改變的，不會是特別嚴肅、特別高風險的工作，而是那些「煩、雜、重複、但又不值得專門寫程序」的流程。

1. 跨軟體搬運

最典型的就是在多個軟體之間搬資訊。

以前你可能要在瀏覽器、文檔、聊天窗口、本地資料夾之間來回切。
以後可以把這類任務交給 Agent：

去找某類資料
匯總成文檔
保存到指定目錄
打開結果給你確認

這類工作不難，但很耗注意力。
Agent 的價值就是把這些碎操作吃掉。

2. 多個 AI 工具協同

現在很多人的真實工作流已經不是只用一個 AI。

可能是：

一個工具寫程式碼
一個工具查資料
一個工具生成圖片
一個工具整理文檔

以前這些工具之間靠人手複製貼上。
以後 Agent 可以成為中間層：它負責打開工具、傳遞上下文、等待輸出、整理結果。

這會讓「多個 AI 協同」從手工流程變成半自動流程。

3. 辦公軟體自動化

表格、PPT、文檔、郵件，這些軟體都有一個共同特點：功能很強，但很多操作很碎。

如果 Agent 能穩定控制這些軟體，以後的辦公自動化門檻會明顯下降。

你不用記選單在哪裡，也不用學複雜快捷鍵。
你只需要說清楚目標，比如：

把這份表格整理成月報
根據這份文檔做一頁總結
把這些資料合併成一個結構清楚的說明

真正麻煩的按鈕操作，會逐漸被隱藏到自然語言後面。

對普通使用者意味著什麼

對普通使用者來說，這類功能的影響可能比「模型又聰明了一點」更直接。

因為它降低的不是知識門檻，而是操作門檻。

很多人不是不會表達需求，而是不知道軟體裡該點哪裡、怎麼組合功能。
Agent 如果能接管這部分，人使用電腦的方式就會變成：

1
2
3

我描述目標
Agent 操作軟體
我檢查結果

這比單純聊天更接近真實生產力。

對軟體形態的影響

如果這類 Agent 能力繼續成熟，軟體本身也會被反向影響。

過去軟體設計主要服務人類點擊。
以後軟體可能還要服務 Agent 操作。

這意味著：

介面元素需要更清晰
操作回饋需要更穩定
本地權限需要更細
軟體可能會提供更適合 Agent 調用的介面
使用者會更在意「能不能被 AI 順利操作」

長期看，應用之間的邊界可能會變薄。
使用者關心的不再是「我打開哪個軟體」，而是「我要完成什麼任務」。

現在還不能過度樂觀

當然，現在還不到完全放手的時候。

這類能力目前還有幾個明顯限制：

穩定性還需要觀察
複雜任務可能中途出錯
權限邊界必須謹慎
涉及帳號、支付、刪除文件等操作不能隨便放權
額度消耗也不是完全可以忽略

所以現階段最合適的用法，不是讓它完全接管電腦，而是讓它處理低風險、可檢查、步驟繁瑣的任務。

比如：

整理資料
生成草稿
跨工具搬運內容
打開和檢查文件
做一些可以人工複核的半自動流程

最後一句

Codex 這次更新真正重要的地方，是它把 AI 從「回答問題」推向了「操作環境」。

短期看，它是一個電腦使用功能。
長期看，它可能是個人電腦互動方式的一次轉向。

以後我們使用電腦，可能會越來越少地記按鈕、找選單、切窗口。
更多時候，我們只需要說清楚目標，然後讓 Agent 去執行，再由人做最後判斷。

Codex Skill 明明在目錄裡，為什麼就是不顯示？

Wed, 29 Apr 2026 11:18:00 +0800

這次遇到的問題很隱蔽：~/.codex/skills 裡明明已經放好了多個 skill，新開 Codex 執行緒之後，側邊欄卻還是只能看到少數幾個。

一開始看起來像是快取或索引問題，但實際原因更具體：幾個 SKILL.md 文件開頭帶了 UTF-8 BOM，Codex 0.111.0 的 skill loader 沒有跳過這個位元組，於是誤判文件沒有合法的 YAML front matter。

現象

本地目錄裡有這些 skill：

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

但新開執行緒時，實際暴露出來的只有：

1
2

bilibili-speech-transcriber
product-cutout-normalize

也就是說，文件存在不等於當前會話一定能載入成功。Codex 會先解析每個 SKILL.md 的 front matter，解析失敗的 skill 會直接被排除。

排查

用 codex exec 啟動一個新會話時，可以看到更直接的錯誤。在 VS Code 等 IDE 中，可能看不到這些 log：

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

這些文件肉眼看起來都有正常的開頭：

---
name: post-rewrite
description: ...
---

真正的問題在位元組層面。

失敗文件的開頭是：

`1`	`EF-BB-BF-2D-2D-2D`

能正常載入的文件開頭是：

`1`	`2D-2D-2D`

2D-2D-2D 就是 ---。前面的 EF-BB-BF 是 UTF-8 BOM。

原因

Codex 0.111.0 的 skill loader 目前要求 SKILL.md 文件第一個位元組就是 --- 的第一個 -。

如果文件前面帶了 UTF-8 BOM，那麼文件實際開頭就不再是 ---，而是：

`1`	`BOM + ---`

於是 loader 會認為它沒有以前置資料分隔符開頭，最後報：

`1`	`missing YAML frontmatter delimited by ---`

這不是 skill 內容寫錯了，也不是目錄放錯了，而是編碼細節讓解析器沒認出來。

修復

把出問題的 SKILL.md 轉成無 BOM 的 UTF-8 即可。

PowerShell 可以這樣處理：

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

處理後再檢查文件頭，應該從：

`1`	`EF-BB-BF-2D-2D-2D`

變成：

`1`	`2D-2D-2D`

驗證

重新啟動一個 Codex 會話後，可見 skill 恢復為：

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

如果側邊欄仍然只顯示舊的列表，可以退出當前 Codex sidebar 或窗口，再重新打開專案。skill 列表通常在會話啟動時載入，中途改文件不一定會立刻刷新到當前執行緒。

最後一句

這類問題最容易誤判成「Codex 沒重新索引」或「skill 沒安裝好」。

實際排查時可以先看三件事：

SKILL.md 是否真的在正確目錄
文件頭部是否有合法的 --- front matter
文件是否是無 BOM 的 UTF-8

這次的關鍵就是第三點：文件看起來沒問題，但第一個位元組不是 -，Codex 就沒有把它當作一個有效 skill。

Codex 裡的 ~/.codex/skills 和專案/.codex/skills 有什麼差別

Wed, 29 Apr 2026 11:08:00 +0800

很多人整理 Codex skills 時，最容易卡住的問題就兩個：

~/.codex/skills 和 專案/.codex/skills 有什麼差別
為什麼 skill 明明在目錄裡，當前會話裡卻不一定顯示

這篇就直接說結論。

兩者的差別

先記最短版本：

~/.codex/skills 是你的全域技能庫
專案/.codex/skills 是這個倉庫的本地技能庫

`~/.codex/skills`

適合放：

你自己跨專案反覆會用的 skill
跟具體倉庫無關的通用流程
很明顯屬於你個人習慣的工作流

比如：

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

這類 skill 的特點就是：離開當前專案也還能用。

`專案/.codex/skills`

適合放：

只對這個倉庫成立的流程
跟當前專案目錄結構、腳本、模板綁定很深的規則
需要讓團隊一起共享的 skill

比如：

這個倉庫特有的發布流程
只能在這個專案裡用的生成模板
跟專案私有腳本強綁定的自動化步驟

這類 skill 的特點是：離開這個倉庫就沒意義。

什麼時候放全域，什麼時候放專案裡

直接這樣判斷就夠了：

跟你個人習慣有關，放 ~/.codex/skills
跟倉庫規則有關，放 專案/.codex/skills
能跨專案複用，優先放全域
要多人共享、跟倉庫一起演進，優先放專案裡

當前這個倉庫是什麼情況

按我現在看到的實際狀態：

你的本機裡有 ~/.codex/skills
當前倉庫裡沒有 .codex/skills

所以你現在主要依賴的是全域 skills。

也就是說，像 post-rewrite、post-translate、git-commit-push 這些流程，現在更多是你個人工作流的一部分，不是這個倉庫顯式自帶的一部分。

為什麼磁碟裡有，當前會話裡卻不一定顯示

這裡要分清兩件事：

磁碟存在：說明 skill 文件在本地目錄裡
會話暴露：說明當前會話把它註冊進了可用 skill 列表

這兩者不是一回事。

所以會出現這種情況：

~/.codex/skills 裡已經有 skill
但 / 後面的列表裡沒有顯示

這通常不代表 skill 壞了，更常見的原因是：當前會話沒有把它重新索引進去。

怎樣讓 skill 被當前會話暴露

最實用的步驟就這幾條：

1. 目錄放對

全域：

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

專案級：

`1`	`專案/.codex/skills/<skill-name>/SKILL.md`

2. `SKILL.md` 頭部可識別

最少要有：

---
name: your-skill-name
description: 這個 skill 是做什麼的
---

3. 新建或修改後，開新會話

很多時候 skill 沒顯示，不是文件有問題，而是當前會話啟動時就已經把可用 skill 列表定下來了。

所以你中途新建 skill，磁碟裡雖然已經有了，這次會話也未必會重新認。

最穩的做法就是：

放好 skill
結束當前會話
重新進入專案
開一個新會話
再看 / 裡有沒有出現

4. 專案 skill 最好提前放好

如果你想讓 專案/.codex/skills 更穩定地被識別，最好在進入倉庫、啟動會話之前，就把這些 skill 放進專案裡。

最後一句

最短結論就是：

~/.codex/skills 是你的個人技能庫
專案/.codex/skills 是倉庫的本地規則庫
skill 在目錄裡，不等於當前會話一定會顯示
想讓它顯示，最常見的辦法就是放對目錄、寫好 SKILL.md，然後開新會話

Ralph 和多智能體協同：怎麼讓 AI 長時間穩定工作

Mon, 27 Apr 2026 08:19:02 +0800

如果你最近在折騰 coding agent，很快就會遇到一個現實問題：AI 當然能幹活，但怎麼讓它連續幹幾個小時，還不在中途跑偏、忘要求、返工一堆？

圍繞 Ralph 和多智能體協同的這類討論，真正值得看的也正是這個問題。它不是單純比較某個模型有多強，而是把重點放在一層更實際的東西上：怎麼設計工作流，才能讓 AI 在長任務裡保持穩定輸出。

把這個問題拆開看，常見的路線主要有兩條：

Ralph 方案：不斷啟動新會話，透過檔案系統銜接上下文
多智能體方案：主 Agent 做協調，子 Agent 分工執行

如果把它壓成一句更好理解的話，這裡討論的其實不是「哪個模型更厲害」，而是「怎麼把 AI 組織起來，讓它更像一個能持續交付的小團隊」。

01 為什麼長時任務容易失控

短任務裡，很多問題不明顯。你給一句指令，模型讀幾份檔案，改幾行程式碼，事情也就結束了。

但任務一旦拉長，問題會集中冒出來：

會話越來越長，上下文開始膨脹
早先的要求被新資訊擠掉
一個 Agent 既要想方案，又要寫程式碼，還要自己測，容易顧不過來
沒有明確驗收環節時，看起來「做完了」，其實只是「說自己做完了」

所以長時間運行 AI，真正考驗的往往不是模型單次輸出能力，而是 任務拆分、狀態銜接、角色分工和回饋回路。

02 Ralph 方案：把長任務拆成很多短回合

Ralph 的思路很適合先解決「上下文越跑越髒」這個問題。

它的核心做法是：

用循環不斷啟動新的 agent 會話
每輪只處理一個足夠小的任務
把跨輪狀態放到檔案裡，而不是全壓在同一個對話上下文裡

這樣做的好處很直接：每次都是 fresh context，單輪會更聚焦，也更不容易被歷史訊息拖慢。

如果你已經看過 Ralph 相關專案，會發現這套方法背後的邏輯很一致：

當前任務寫在結構化檔案裡
中間經驗寫到進度檔案裡
程式碼變化留在 git 歷史裡

換句話說，Ralph 不是試圖讓一個 Agent「永遠記住所有事」，而是主動把記憶外置，讓會話本身保持輕一點。

這類方案特別適合下面幾種情況：

任務已經能拆成一組小 story
每個 story 都能在單個上下文視窗裡完成
專案裡已經有測試、typecheck 或其他檢查機制

它解決的是「如何讓 AI 一輪一輪穩定推進」。

03 多智能體方案：把一個人做不完的事分出去

另一條路線是多智能體協同。

從這類工作流設計思路來看，更值得推薦的通常是這種方式：主 Agent 不直接埋頭幹活，而是負責協調；子 Agent 各自處理開發、測試、檢查、驗收等不同任務。

這和 Ralph 的區別在於：

Ralph 更像串行迭代
多智能體更像並行分工

如果任務裡天然有不同角色，多智能體會更順手。比如：

一個 Agent 負責拆任務和寫執行計畫
一個 Agent 負責具體實作
一個 Agent 負責測試和驗證
一個 Agent 負責回看結果是不是符合最初需求

這樣做的價值不是「多開幾個視窗顯得很高級」，而是讓不同工作職責分離開。原來塞在一個 Agent 身上的幾件事，現在可以拆成幾個更明確的環節。

一旦角色邊界清楚，很多問題都會變輕：

寫的人不必同時當審的人
跑測試的人不必重新推導整套需求
主 Agent 不會被實作細節淹沒

它解決的是「如何讓 AI 像一個小團隊那樣配合」。

04 真正關鍵的，不是多開，而是怎麼拆

無論是 Ralph 還是多智能體，最容易被忽略的一點都是：流程設計比多開幾個 Agent 更重要。

如果任務拆分不對，就算開再多 Agent，也只是把混亂並行化。

比較穩的拆法通常有幾個特點：

一個任務只對應一個明確目標
一個角色只負責一類輸出
每輪都有清楚的完成標準
上一輪的結果能被下一輪直接消費

比如比起給 AI 一個「把整個功能做完」的大指令，更穩的方式往往是：

先拆出需求和邊界
再拆實作
再拆測試
最後單獨做驗收

這類拆法的好處是，問題一旦出現，更容易知道是出在理解、實作、測試，還是交付標準上。

05 為什麼驗收環節特別重要

很多 AI 工作流失敗，不是因為前面完全沒做事，而是因為最後缺了一個真正獨立的確認動作。

在長任務裡，「已經生成結果」和「結果真的可用」之間，經常隔著一整層差距。

這裡有個很值得重視的方向，就是把開發和驗收拆開看。哪怕不做到特別複雜，至少也應該把這些問題單獨問一遍：

它真的完成了最初那條任務嗎
有沒有只改表面、沒解決根因
測試是不是只驗證了最順利的路徑
有沒有把上游要求悄悄改掉

只要這層檢查缺位，AI 很容易在長流程裡不斷「自我宣布成功」。

06 兩條路線怎麼選

如果只是想快速判斷，可以先這麼理解：

你最痛的是上下文膨脹和長會話失焦，先看 Ralph
你最痛的是一個 Agent 身兼多職、任務之間互相打架，先看多智能體

再具體一點：

Ralph 更適合流程清楚、任務細碎、可以按回合推進的工作
多智能體更適合角色明顯、需要並行和交叉驗證的工作

很多時候，這兩條路也不是非此即彼。比較成熟的做法，反而可能是把它們組合起來：

外層用 Ralph 這種迭代循環推進大任務
內層在單輪裡再用多智能體處理研究、實作、測試和驗收

這樣既能控制長上下文，又能提高單輪內部的協作效率。

07 一句話總結

這類方法最值得看的地方，不是單獨推薦了 Ralph 或多智能體，而是把一個很現實的問題講清楚了：讓 AI 長時間穩定工作，關鍵從來不只是模型本身，而是你有沒有把上下文、任務、角色和驗收設計好。

如果你已經開始讓 Claude Code、Codex 或其他 coding agent 處理更長的真實任務，這類工作流思路會比「再換一個更強模型」更值得優先補課。

Ralph 是什麼：把 Claude Code 和 Amp 變成可循環執行的自主開發流程

Mon, 27 Apr 2026 08:08:55 +0800

如果你最近在關注 coding agent 的長流程執行，snarktank/ralph 是個很值得看一眼的小專案。它不是再做一個新的模型外殼，也不是再包一層聊天介面，而是把 Claude Code 或 Amp 組織成一個可以反覆運行的 autonomous loop，讓 AI 按 PRD 裡的 story 一項一項往前做，直到全部完成。

它的核心思路其實很直接：不要讓同一個 agent 在一個越來越長、越來越髒的上下文裡硬撐，而是每輪都重新啟動一個全新的 AI coding session。 這樣做的好處是，上下文不會一路膨脹，任務邊界也更清楚。

01 Ralph 是什麼

Ralph 的官方定位很明確：它是一個 autonomous AI agent loop，會反覆呼叫 AI coding tool，直到 PRD 裡的項目都做完。

目前倉庫支援兩種工具：

Amp CLI
Claude Code

每一輪迭代都會啟動一個 fresh instance。也就是說，它不依賴「同一個會話一直聊下去」，而是依賴這些外部狀態來保存記憶：

git 歷史
progress.txt
prd.json

這點非常關鍵。很多人讓 agent 跑長任務時，最大的痛點不是模型不會寫，而是會話越跑越重，最後開始漏掉上下文、忘記要求、反覆返工。Ralph 的設計，基本就是衝著這個問題去的。

02 它怎麼工作

Ralph 的工作流分成三步：

1. 先寫 PRD

README 建議先用配套的 prd skill 生成需求文件，把功能拆成比較細的 story。

2. 再把 PRD 轉成 `prd.json`

然後用 ralph skill，把 Markdown 版 PRD 轉成結構化的 prd.json。這個檔案裡會保存 user stories，以及每一項是不是已經通過。

3. 執行循環腳本

真正執行的是 ralph.sh。命令大致是：

1
2

./scripts/ralph/ralph.sh [max_iterations]
./scripts/ralph/ralph.sh --tool claude [max_iterations]

預設是 10 輪。每一輪大致會做這些事：

從 branchName 建立分支
選擇優先級最高、passes: false 的 story
只實作這一項
跑品質檢查，比如 typecheck 和 tests
檢查通過後提交程式碼
更新 prd.json
把經驗追加到 progress.txt
繼續下一輪

也就是說，Ralph 並不追求「一口氣把整件事做完」，而是把任務壓縮成很多個能在單個上下文視窗裡完成的小閉環。

03 Ralph 最有意思的地方

1. 每輪都是 fresh context

這是 Ralph 最核心的設計點。README 強調，每次迭代都是一個新的 AI instance，跨輪記憶只靠 git、progress.txt 和 prd.json。

這和很多人平常直接在一個長對話裡讓 Claude Code 或其他工具連續工作很不一樣。後者在任務變大後，很容易被歷史訊息拖慢，還會逐漸失去焦點。Ralph 則是主動接受「單輪記不住全部」，然後把記憶放到外部檔案裡。

2. 強制把任務拆小

倉庫文件特別強調，單個 PRD item 必須小到能在一個 context window 裡完成。像「加一個篩選器」「改一個 server action」「補一欄資料庫欄位」這種粒度比較合適；而「重構整個 API」「做完整 dashboard」這種就太大了。

這個約束其實很現實。很多 autonomous agent 跑崩，不是 loop 本身有問題，而是任務切分太粗，讓模型一輪裡就背了過量目標。

3. 不只是程式碼，連經驗也要沉澱

除了 progress.txt，README 還特別強調要更新 AGENTS.md。原因也很實際：未來迭代和未來開發者都會讀這些說明，所以每輪發現的模式、坑點、約定，最好都落到專案文件裡。

換句話說，Ralph 不只是讓 agent 連續寫程式，也想讓它連續累積對程式碼庫的工作記憶。

04 它適合什麼場景

如果你的任務具備這些特徵，Ralph 會比較對路：

已經能拆成一組明確的 user stories
程式碼庫裡有比較可靠的回饋回路，比如測試、typecheck、CI
你希望 agent 持續推進，但不想把所有事壓在單個長對話裡
你接受它按迭代方式一點點完成，而不是一次性全做完

反過來說，如果你的需求還很模糊，或者任務本身高度依賴來回討論、頻繁改方向，那 Ralph 可能還不是第一選擇。它更適合「需求已經整理好，現在需要穩定推進執行」的階段。

05 它和一般 Claude Code 用法有什麼不同

如果平常直接用 Claude Code，常見模式是你開一個會話，讓它持續讀程式碼、改程式碼、跑命令。這個方式在中小任務上很好用，但在大任務上容易碰到兩個問題：

上下文越來越長
中間決策不容易結構化沉澱

Ralph 的做法更像把 Claude Code 或 Amp 變成一個「批次執行器」：

任務來源不是臨時聊天，而是 prd.json
每輪只認一個 story
完成狀態寫回檔案
經驗寫進 progress.txt
程式碼提交進 git

所以它更像是「給 coding agent 加了一層迭代控制器」，而不是換了一個新的 AI assistant。

06 一個值得注意的前提

Ralph 能不能跑順，關鍵不在 loop 本身，而在回饋回路夠不夠好。README 寫得很直接：如果沒有 typecheck、tests、CI 這些機制，錯誤會在後續迭代裡不斷累積。

對前端任務來說，倉庫甚至明確建議把「用瀏覽器驗證」寫進 acceptance criteria。因為如果沒有實際驗證，agent 很容易把「看起來寫完了」和「真的可用」混在一起。

這點很重要。Ralph 不是 magical automation，它更像是把你現有的工程紀律放大。如果你的專案本來就有清晰任務拆分和可靠檢查，它會更有價值；如果這些基礎還沒有，loop 只會把混亂重複很多次。

07 一句話總結

Ralph 最值得看的地方，不是它寫了多少新基礎設施，而是它把一個樸素但很有用的思路落成了現成流程：讓 Claude Code 或 Amp 每輪只做一個足夠小的 story，用 fresh context 保持專注，再靠 git、prd.json 和 progress.txt 維持跨輪連續性。

如果你已經開始把 coding agent 用到真實專案裡，並且正被「長任務怎麼穩定推進」這個問題困住，Ralph 這套方法很值得參考。

參考連結

GitHub 倉庫：https://github.com/snarktank/ralph
互動式流程圖：https://snarktank.github.io

nuwa-skill：把「蒸餾一個人」從靈感變成可執行流程

Wed, 22 Apr 2026 16:20:00 +0800

[alchaincyf/nuwa-skill](https://github.com/alchaincyf/nuwa-skill) 很容易先讓人想到一件事：用 AI 模仿名人的口吻回答問題。但它真正有意思的地方，不在於「像不像」，而在於它試圖把「蒸餾一個人的思維方式」做成一條可重複執行的流程。

這件事一旦成立，價值就不只是做幾個好玩的角色 prompt，而是把某個人的判斷框架、關注重點、常見啟發式與表達習慣，沉澱成一個可以反覆調用的 skill。你要的不是一句像某人會說出的話，而是一個更接近「如果他來分析這件事，會先看哪裡、怎麼取捨、會質疑什麼」的工作介面。

它解決的不是「模仿」，而是「建模」

很多所謂的人物 prompt，本質上只是風格貼皮。

它們通常會要求模型：

用某個人的語氣說話
多引用這個人的經典句式
盡量模仿他公開表達裡的措辭

這樣做在展示裡很吸睛，但一到真實任務就很容易露餡。原因也很簡單：語氣是表層，判斷結構才是核心。一個人物之所以有辨識度，不是因為他愛說哪幾個詞，而是因為他在面對問題時，總會用某些穩定的方法切入。

nuwa-skill 的方向更像是把這種「穩定的方法」提取出來。換句話說，它在意的不是「怎麼說得像」，而是「怎麼想得像」。

一個更完整的工作流

從倉庫說明來看，nuwa-skill 想做的是一套端到端流程：輸入一個人名，然後自動完成調研、提煉、驗證，再把結果組織成能在 Claude Code 裡調用的 skill。

這背後有幾個很關鍵的變化。

第一，它預設蒸餾對象可以不是你團隊裡的同事。很多人第一次接觸這類能力，會先想到「把優秀同事的方法論沉澱下來」。這當然有價值，但邊界也很明顯：可學習樣本有限，而且往往只覆蓋團隊內部經驗。nuwa-skill 直接把對象擴展到更廣的人群，例如創業者、投資人、科學家、產品經理、寫作者。

第二，它強調的是「自動完成」，而不是讓使用者手工拼 prompt。真正讓這類能力能落地的，不是 prompt 文案寫得多華麗，而是你能不能穩定完成資料蒐集、觀點歸納、模式抽取與結果校驗。只要其中某一步完全依賴手工，重用成本就會迅速上升。

第三，它試圖把產物變成一個 skill，而不是一段一次性的對話。前者可以被多次調用、組合、迭代；後者往往只在當前上下文裡有效，過幾輪就散掉了。

為什麼這個方向值得關注

如果把 AI 當成問答機，最自然的用法是「給我一個答案」。但如果把 AI 當成工作台，問題就會變成「給我一種看問題的方法」。

nuwa-skill 的價值，更偏向後者。

例如你面對一個產品決策，想要的未必是一個標準答案，而是幾種截然不同的分析框架：

有人會先看長期複利
有人會先看資源約束
有人會先看使用者體驗的一致性
有人會先看市場進入時機

如果這些框架能被穩定封裝出來，AI 的角色就會從「替你寫一段話」變成「幫你快速切換視角」。這比單純模仿名人語錄有用得多，因為它直接作用在決策品質上。

它最打動人的地方：把隱性知識變成可調用資產

很多高價值能力，本來就很難寫成 SOP。

一個人為什麼判斷比別人準，往往不是因為他掌握了更多顯性規則，而是因為他在長期實踐裡形成了一套隱性的篩選機制：

什麼訊號值得優先關注
什麼噪音應該直接忽略
哪些問題要拆開看
哪些問題要反過來問
哪些結論必須等待更多證據

這類能力平時很難沉澱，因為它不一定總能被本人完整說清楚。也正因如此，一旦能被結構化提取，價值會很高。nuwa-skill 吸引人的地方就在這裡：它想處理的不是表面知識搬運，而是認知習慣的再組織。

適合什麼場景

我覺得這類 skill 最適合以下幾種場景。

1. 決策前的多視角審視

當你已經有一個方案，但擔心自己只是在沿著熟悉的路徑思考時，切換到不同「人物視角」去審視同一個問題，會比讓模型繼續順著你的原話擴寫更有價值。

2. 學習某類高手的判斷框架

很多人學習高手，習慣收藏語錄、看訪談、抄摘要，但最後往往只記住幾句漂亮話。把思維模式做成 skill 之後，學習方式會更接近「帶著問題反覆調用」，而不是「做一堆靜態摘抄」。

3. 讓團隊共享一種分析方式

團隊裡真正稀缺的，不只是知識文件，而是「我們遇到問題時通常怎麼想」。如果未來這套流程成熟，它也可以反過來用於沉澱組織內部高手的方法論，只是它顯然不打算把這個能力局限在組織內部。

這類專案真正難的地方

當然，方向有吸引力，不代表問題已經解決。

這類專案最難的，從來不是安裝一個 skill，而是下面幾件事：

資料來源是否足夠可靠
提煉出的模式是不是穩定，而不是偶然語料帶來的錯覺
模型是在使用人物框架分析，還是只是在重複常見印象
不同人物之間的邊界會不會被模型自動抹平

也就是說，最關鍵的不是「能不能生成一段像樣的話」，而是「這個 skill 產出的認知框架是否經得起多任務重用」。如果未來它在驗證環節繼續做深，這類專案的可信度會明顯提高。

為什麼它比「提示詞模板庫」更進一步

過去不少專案會把這類能力做成模板庫：一個人物對應一段 prompt，使用者複製進去就能用。問題是模板庫本質上還是靜態資產，更新慢、驗證弱，而且很難形成完整的生產流程。

nuwa-skill 更進一步的地方，是它把「人物蒸餾」從一個模板問題，推進成一個流程問題。

一旦工作重心從「寫一段 prompt」轉到「如何系統生成、校驗、迭代一個人物 skill」，這件事就更像工程，而不是靈感。對真正想長期使用的人來說，後者顯然更重要。

結語

nuwa-skill 有意思，不是因為它把 AI 變成了名人模仿秀，而是因為它把「如何學習一個人的思考方式」這件事，往可執行、可重用、可迭代的方向推進了一步。

如果說很多人物 prompt 解決的是「像誰說話」，那它想解決的，是「像誰那樣看問題」。前者適合展示，後者才更接近生產力工具。

參考連結

GitHub 倉庫：https://github.com/alchaincyf/nuwa-skill
專案說明：https://github.com/alchaincyf/nuwa-skill/blob/main/README.md
Skill 定義：https://github.com/alchaincyf/nuwa-skill/blob/main/SKILL.md

RAGFlow 專案整理：開源 RAG 引擎的功能與使用方法

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow 是 infiniflow 開源的 RAG（Retrieval-Augmented Generation，檢索增強生成）引擎。它的目標不是只做一個「上傳文件然後問答」的知識庫外殼，而是把文件解析、切分、檢索、重排、引用溯源、模型配置、Agent 能力和 API 整合放進一套完整工作流裡。

如果你正在做企業知識庫、文件問答、客服助手、內部資料檢索，或者想給 LLM 加一層更可靠的上下文來源，RAGFlow 屬於值得重點看的開源方案。

01 RAGFlow 解決什麼問題

普通 RAG 系統最容易遇到的問題有三個：

文件解析品質不穩定，尤其是 PDF、掃描件、表格、圖片、複雜排版文件。
切分策略不透明，命中結果看起來像是「搜到了」，但上下文並不完整。
回答缺少可靠引用，使用者很難判斷答案來自哪裡。

RAGFlow 的重點正好放在這些地方。專案 README 裡強調了 Deep document understanding、模板化切分、可視化 chunk、引用溯源和多路召回加重排。換句話說，它更關注「高品質資料進入，高品質答案輸出」，而不是只把向量資料庫和聊天框接起來。

02 核心功能

1. 深度文件理解

RAGFlow 支援從複雜格式的非結構化資料中抽取知識。README 中列出的資料類型包括 Word、PPT、Excel、TXT、圖片、掃描件、結構化資料、網頁等。

這對企業知識庫很關鍵。真實資料通常不是乾淨的 Markdown，而是合約、報告、表格、掃描 PDF、產品手冊、截圖和網頁混在一起。如果解析品質不夠，後面的向量檢索和 LLM 回答都會被拖垮。

2. 模板化切分

RAGFlow 提供模板化 chunking。它的價值在於：切分策略不是黑盒，可以根據文件類型選擇更合適的方式。

例如普通文章、論文、表格、問答文件、圖片說明、合約條款，對 chunk 的粒度和邊界要求都不一樣。模板化切分可以減少「句子被切碎」「表格上下文丟失」「標題和正文分離」這類問題。

3. 可追溯引用

RAGFlow 強調 grounded citations，也就是回答要能追溯到來源片段。它還提供 chunk 可視化，方便人工干預解析和切分結果。

這點對生產環境尤其重要。企業內部問答不是只要「看起來像答案」，還要能查證來源。對於政策、合規、財務、技術文件、客戶支持資料來說，引用和溯源幾乎是剛需。

4. 自動化 RAG 工作流

RAGFlow 把 RAG 流程做成相對完整的鏈路：

建立知識庫
上傳或同步資料
解析文件
查看和干預 chunk
配置 LLM 與 embedding 模型
執行多路召回與重排
建立聊天助手
透過 API 整合到業務系統

這讓它更像一個 RAG 平台，而不是單點工具庫。對團隊來說，UI、可視化和 API 都有價值：非研發人員可以維護知識庫，研發人員可以把能力接入既有系統。

5. Agent、MCP 與工作流能力

RAGFlow 的近期更新裡已經包含 Agentic workflow、MCP、Agent Memory、程式碼執行元件等內容。這說明它不只想做傳統知識庫問答，也在向 Agent 場景延伸。

典型方向是：Agent 在執行任務時，可以把 RAGFlow 作為可靠的企業知識上下文層；需要查資料時從知識庫召回，生成回答時保留引用，必要時再組合工具呼叫或工作流。

03 基本使用流程

按照官方快速開始文件，RAGFlow 的常見使用路徑可以概括成下面幾步。

1. 準備執行環境

官方 README 給出的基礎要求是：

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

如果要使用程式碼執行器的沙箱功能，還需要 gVisor。另外要注意，官方 Docker 映像主要面向 x86 平台；如果是 ARM64，需要依照官方說明自行建置映像。

2. 拉取專案

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. 檢查 `vm.max_map_count`

RAGFlow 部署會依賴 Elasticsearch / OpenSearch 這類元件，因此在 Linux 上通常需要確認：

`1`	`sysctl vm.max_map_count`

如果數值低於 262144，可以暫時設定：

`1`	`sudo sysctl -w vm.max_map_count=262144`

如果希望重開機後仍然生效，需要寫入 /etc/sysctl.conf。

4. 使用 Docker Compose 啟動

CPU 模式可以直接啟動：

`1`	`docker compose -f docker-compose.yml up -d`

如果要用 GPU 加速 DeepDoc 任務，README 中給出的方式是在 .env 中啟用 DEVICE=gpu 後再啟動：

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

啟動後查看日誌：

`1`	`docker logs -f docker-ragflow-cpu-1`

看到服務啟動完成後，再透過瀏覽器訪問伺服器地址。預設配置下，通常可以直接訪問：

`1`	`http://IP_OF_YOUR_MACHINE`

5. 配置模型 API Key

RAGFlow 需要配置 LLM 和 embedding 模型。README 提到可以在 service_conf.yaml.template 中選擇預設 LLM factory，並更新對應的 API_KEY。

實際使用時，你需要根據自己的模型供應商配置：

聊天模型
embedding 模型
rerank 模型
多模態模型（如果要理解 PDF / DOCX 中的圖片）

6. 建立知識庫並上傳文件

服務啟動後，典型操作是：

登入 Web UI。
建立 dataset / knowledge base。
上傳文件或配置資料源同步。
等待解析完成。
查看 chunk 結果，必要時人工調整。
建立聊天助手，選擇知識庫。
測試問答效果和引用來源。

如果要接入業務系統，可以繼續使用 RAGFlow 的 API 或 SDK，把知識庫檢索和聊天能力接到自己的應用裡。

04 適合哪些場景

RAGFlow 適合這些需求：

企業內部知識庫問答
產品手冊、技術文件、FAQ 檢索
客服助手和售前支持助手
合約、報告、制度文件的可追溯問答
多格式資料統一整理
需要 UI 維護知識庫，同時又要 API 整合的團隊
想把 RAG 能力作為 Agent 上下文層的系統

它尤其適合文件格式複雜、需要引用溯源、希望人工干預解析結果的場景。

05 使用時要注意什麼

第一，RAGFlow 不是輕量腳本。它對機器資源有要求，官方建議至少 4 核 CPU、16GB 記憶體和 50GB 磁碟。如果只是給少量 Markdown 做問答，可能沒必要上這麼完整的平台。

第二，文件品質仍然重要。RAGFlow 能改善解析和切分，但不能讓低品質、過期、互相矛盾的資料自動變得可靠。真正上線前，知識庫治理仍然要做。

第三，模型配置會直接影響效果。embedding、rerank、聊天模型、多模態模型的選擇，都會影響召回和回答品質。RAGFlow 提供了工作流，但效果仍然要靠資料、模型和參數一起調。

第四，生產環境要關注權限和資料安全。企業知識庫裡往往有內部資料，部署方式、訪問控制、日誌、API Key、模型供應商資料策略都要提前設計。

06 簡短判斷

RAGFlow 的優勢在於把 RAG 裡最麻煩的部分做成了平台化能力：複雜文件解析、可解釋切分、引用溯源、多路召回、重排、模型配置、Web UI、API 和 Agent 擴展。

如果你要做的是可驗證、可維護、可接入業務系統的企業知識庫，RAGFlow 比「向量庫 + 簡單聊天 UI」的方案更完整。反過來，如果只是個人小規模資料問答，或者資料格式非常簡單，輕量 RAG 框架可能更省資源。

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 值得放進工具箱。反過來，如果任務只是固定網站的低成本批次採集，傳統爬蟲或專用解析器仍然更合適。

OpenHarness 是什麼：這個開源 Agent Harness 能做什麼

Sun, 12 Apr 2026 23:45:00 +0800

如果你最近在關注開源 AI Agent 工具，HKUDS/OpenHarness 是一個很值得留意的新專案。它不是單純再做一個「會聊天的外殼」，而是把一套可運行、可擴展、可治理的 Agent 基礎設施單獨抽出來，做成一個開源的 Agent Harness。

按照官方 README 的說法，OpenHarness 主要提供的是一整套輕量級 Agent 基礎能力，包括工具調用、技能載入、記憶機制、權限治理以及多 Agent 協調；而它附帶的 ohmo，則是建立在這套基礎設施之上的個人 AI 助手應用。

01 OpenHarness 是什麼

可以把 OpenHarness 理解成「給大模型裝上手腳、記憶與邊界」的運行層。

大模型本身擅長推理與生成，但如果你想讓它真正成為一個可以長期工作的 Agent，通常還需要這些外圍能力：

調用工具，而不只是輸出文字
讀寫檔案、執行命令、使用搜尋與網頁能力
在長會話中保留上下文與記憶
對危險操作做權限控制
把大型任務拆給多個子 Agent 並行處理

OpenHarness 的目標，就是把這部分「圍繞模型的工程層」做成一個清晰、開源、可檢查的 Python 實作。它更像是一個 Agent 運行底座，而不是單獨強調某一種模型或某一個聊天介面。

02 這個專案的基本功能

從目前 GitHub 首頁與 README 來看，OpenHarness 的核心能力主要集中在下面幾塊。

1. Agent Loop

這是 Agent 能持續工作的核心執行循環。官方列出的重點包括：

串流式工具調用循環
API 重試與指數退避
並行工具執行
Token 統計與成本追蹤

這部分的意義在於，Agent 不只是「一問一答」，而是可以在一次任務裡持續觀察、思考、調用工具、讀取結果，再進入下一步。

2. 工具、Skills 與外掛體系

OpenHarness 把工具層做得相當完整。專案首頁提到它已經內建檔案、Shell、搜尋、網頁、MCP 等多類工具，並支援按需載入 Markdown 技能檔案。

它的價值不只是「工具很多」，更重要的是組合方式比較開放：

可以直接使用內建工具
可以依任務載入 skills
可以透過外掛擴展 hooks、skills 與 agents
相容 anthropics/skills 與相關外掛生態

如果你希望把某些固定流程沉澱成可重用能力，而不是每次都靠 prompt 臨時描述，這一層會很有用。

3. 上下文與記憶

這部分是 OpenHarness 很重要的差異點。官方給出的關鍵詞包括：

CLAUDE.md 發現與注入
自動上下文壓縮
MEMORY.md 持久記憶
會話恢復與歷史延續

這代表它不只是處理當前這一輪輸入，而是會盡量把「專案約定」「歷史任務」「長期偏好」保留下來，讓 Agent 更適合持續工作，而不是每次都從零開始。

4. 權限治理與安全邊界

Agent 真正進入檔案系統、終端與網路之後，治理就變得非常重要。OpenHarness 在這部分提供了：

多級權限模式
基於路徑與命令的規則控制
PreToolUse / PostToolUse hooks
互動式審批彈窗

簡單來說，它不只是讓 Agent「能做事」，也考慮了「哪些事可以直接做，哪些事必須先經過確認」。

5. 多 Agent 協調

OpenHarness 也支援把任務拆給子 Agent 處理。目前公開資料裡提到的能力包括：

子 Agent 建立與委派
團隊註冊與任務管理
背景任務生命週期管理

對複雜任務來說，這代表它可以不只靠一個 Agent 串行推進，而是嘗試進行並行協作。

6. 多 Provider 工作流

OpenHarness 目前並不把 provider 只當成底層 API 名稱，而是抽象成 workflow + profile。根據 README，目前支援的方向包括：

Claude / Anthropic-compatible
OpenAI-compatible
Codex Subscription
GitHub Copilot
Moonshot(Kimi)、GLM、MiniMax 等相容後端

這讓它更像一個「多模型、多入口」的 Agent 運行框架，而不是綁定某一家服務商。

7. React TUI 與非互動模式

OpenHarness 內建終端互動介面，執行 oh 後可以進入 React/Ink TUI。官方 README 提到它支援：

命令選擇器
權限確認
模型切換
Provider 切換
會話恢復

如果你不想進入互動介面，也可以用非互動模式直接執行單次任務，例如把結果輸出到標準輸出、JSON 或串流 JSON，適合腳本化與自動化場景。

03 `ohmo` 是什麼

如果說 OpenHarness 是底層基礎設施，ohmo 就是建立在這套基礎設施之上的「個人 Agent 應用」。

專案首頁對 ohmo 的定位很明確：它不是一般聊天機器人，而是一個可以在長會話中持續工作的個人助手。官方描述裡提到，它可以在 Feishu、Slack、Telegram、Discord 等渠道與你互動，並執行像是：

fork 分支
寫程式碼
跑測試
發起 PR

另外，README 還特別強調：ohmo 可以運行在你現有的 Claude Code 或 Codex 訂閱之上，不一定要求額外申請新的 API key。對已經在使用這些訂閱工具的人來說，這一點門檻比較低。

04 它適合什麼場景

從這個專案目前公開出來的能力來看，OpenHarness 比較適合下面幾類人：

想研究生產級 Agent 到底由哪些基礎模組構成
想自己搭建一個可擴展的開源 Agent 運行層
想把工具、技能、記憶、權限、多 Agent 協調放進同一個框架裡
不希望被單一模型廠商或單一客戶端形態綁定
想基於現成架構繼續做垂直領域 Agent 或個人助手

如果你的目標只是「找一個能直接聊天的成品助手」，那 OpenHarness 本體可能不是最輕量的選擇；但如果你更關心 Agent 基礎設施、工程可控性與後續擴展，這個專案就很值得研究。

05 快速理解它的定位

一句話總結：

OpenHarness 負責把大模型變成真正可執行任務的 Agent，ohmo 負責把這套能力包裝成一個可以長期陪你工作的個人助手。

也可以把它拆成兩層來看：

OpenHarness：開源 Agent Harness，本質是基礎設施
ohmo：基於這套基礎設施構建的 personal-agent app

截至 2026 年 4 月 12 日，專案 GitHub 首頁顯示它的更新已經推進到 v0.1.6（2026 年 4 月 10 日），重點持續放在自動上下文壓縮、MCP 傳輸能力、React TUI 與多 Agent 運行穩定性上。這表示它目前仍處於快速演進階段，但方向已經非常清晰。

參考連結

GitHub 專案首頁：https://github.com/HKUDS/OpenHarness
英文 README：https://github.com/HKUDS/OpenHarness/blob/main/README.md
中文 README：https://github.com/HKUDS/OpenHarness/blob/main/README.zh-CN.md

Playwright CLI 使用入門：安裝、Skills、Session 管理與常用命令

Sun, 12 Apr 2026 14:36:58 +0800

如果你最近在用 Claude Code、GitHub Copilot 或其他 coding agent 做瀏覽器自動化，microsoft/playwright-cli 是一個很值得關注的新工具。它不是傳統意義上那種「給人手動敲命令用」的瀏覽器小工具，而是一個面向 coding agent 的 Playwright CLI，強調的是更低的 token 開銷、更輕量的命令介面，以及和 Skills 工作流的結合。

從官方 README 來看，Playwright CLI 的核心思路很明確：相比 MCP 把大量工具 schema 和頁面結構塞進模型上下文，CLI 命令方式更緊湊，也更適合在大程式碼庫、測試任務與瀏覽器自動化之間來回切換的 agent 工作流。

01 Playwright CLI 是什麼

playwright-cli 是微軟開源的一個 Playwright 命令列工具，官方描述是「CLI for common Playwright actions」。它主要用來完成這些事情：

開啟頁面並驅動瀏覽器
錄製與生成 Playwright 程式碼
抓取頁面快照，取得元素引用
截圖、匯出 PDF
搭配 coding agent 進行自動化測試與網頁操作

目前 GitHub README 對它的定位說得非常清楚：如果你正在使用 coding agents，CLI 往往比 Playwright MCP 更合適；如果你更需要持久狀態、豐富的 introspection 與長時間的 agentic loop，MCP 仍然有它的價值。

換句話說，Playwright CLI 更像是「替 AI 編碼助手準備的瀏覽器自動化介面」，而不只是給人類工程師手動點網頁的工具。

02 它的優點在哪裡

1. 更適合 agent 工作流

官方 README 把第一個優點直接寫成 Token-efficient。它不會強制把整頁資料都塞進 LLM 上下文，而是透過更短、更專用的命令讓 agent 操作瀏覽器。

這對 coding agent 很重要。因為在真實專案裡，agent 不只是跑瀏覽器，還要讀程式碼、改檔案、跑測試、看日誌。如果瀏覽器工具本身就很「吃上下文」，整體效率會明顯下降。

2. 能和 Skills 一起工作

README 裡特別強調了 playwright-cli install --skills。這代表官方不是把它當成單純的 shell 工具，而是設計成可以被 Claude Code、GitHub Copilot 等 agent 直接使用的技能入口。

如果你的工作流本來就建立在 Skills 之上，那 Playwright CLI 的接入會更自然。

3. Session 管理做得比較完整

Playwright CLI 支援 session。預設情況下，瀏覽器 profile 保存在記憶體裡，同一個 session 內的 cookies 和 storage 會在多次 CLI 呼叫之間保留；如果加上 --persistent，還可以把 profile 落到磁碟，跨瀏覽器重啟繼續使用。

這讓它比「一條命令開瀏覽器，跑完就丟掉」的玩具型工具更實用，也更適合持續除錯與 agent 長流程執行。

4. 自帶可視化監控面板

README 裡提供了 playwright-cli show，用來打開一個 dashboard，觀察和控制所有執行中的瀏覽器 session。對於 agent 在背景跑自動化任務的場景，這一點很有價值，因為你可以隨時接手、觀察、排錯，而不是只能盲跑。

03 安裝與環境要求

根據目前 GitHub README，Playwright CLI 的基本要求是：

Node.js 18 或更高版本
Claude Code、GitHub Copilot 或其他 coding agent

安裝命令如下：

1
2

npm install -g @playwright/cli@latest
playwright-cli --help

這裡有一個很容易踩坑的點要特別注意：

官方目前推薦安裝的是 @playwright/cli
不要把它和 npm 上歷史遺留、已廢棄的舊包 playwright-cli 混為一談

也就是說，真正該安裝的是 scoped package，而不是舊時代的同名歷史包。

04 如何開始用

1. 安裝 skills

如果你希望讓 coding agent 直接使用 Playwright CLI，官方建議先安裝 skills：

`1`	`playwright-cli install --skills`

README 裡明確寫到，Claude Code、GitHub Copilot 等工具會使用本地安裝的 skills。

2. 直接讓 agent 呼叫 CLI

如果你不想先處理 skills，也可以直接讓 agent 讀取 CLI 的說明資訊：

1
2

Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.

官方把這種方式叫做「Skills-less operation」。意思是即使沒有預先安裝 skill，也可以透過 CLI 的自描述能力來驅動 agent。

3. 手動體驗一遍最小流程

README 裡給了一組很適合入門的 TodoMVC 範例：

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli type "Water flowers"
playwright-cli press Enter
playwright-cli check e21
playwright-cli check e35
playwright-cli screenshot

這組命令的價值在於，它能讓你很快理解 Playwright CLI 的互動方式：

open 負責開頁面
type 和 press 負責輸入
check 用元素引用操作核取方塊
screenshot 保存結果

05 `--headed`、session 與監控面板

`--headed`

Playwright CLI 預設是 headless 的。如果你想直接看到瀏覽器視窗，需要在 open 時明確加上 --headed：

`1`	`playwright-cli open https://playwright.dev --headed`

這對除錯選擇器、登入流程，或觀察互動細節都會更方便。

session

官方 README 很強調 session 的用法。你可以用不同 session 把不同專案或網站隔離開來：

1
2
3

playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list

如果你是讓 agent 長時間工作，也可以直接透過環境變數指定 session：

`1`	`PLAYWRIGHT_CLI_SESSION=todo-app claude .`

常用的 session 管理命令包括：

1
2
3

playwright-cli list
playwright-cli close-all
playwright-cli kill-all

其中：

list 用來列出所有 session
close-all 用來正常關閉所有瀏覽器
kill-all 用來強制結束所有瀏覽器程序

監控面板

如果你想看 agent 現在到底在瀏覽器裡做了什麼，可以執行：

`1`	`playwright-cli show`

根據 README 的說明，這個 dashboard 主要有兩種視圖：

Session grid：依 workspace 查看所有活動 session，附即時畫面、URL 和頁面標題
Session detail：查看單個 session 的即時介面，還能接管滑鼠與鍵盤

這讓 Playwright CLI 不只是「命令列可用」，而是具備了比較成熟的可觀測性。

06 常用命令先記住哪些

如果你是第一次接觸 Playwright CLI，不需要一開始就把所有命令背下來。先記住下面這些最核心的就夠了：

頁面與互動

playwright-cli open [url]
playwright-cli goto <url>
playwright-cli click <ref>
playwright-cli fill <ref> <text>
playwright-cli type <text>
playwright-cli hover <ref>
playwright-cli press <key>

取得頁面結構

playwright-cli snapshot
playwright-cli snapshot <ref>
playwright-cli snapshot --depth=N
playwright-cli eval <func> [ref]

snapshot 很關鍵，因為很多後續操作都依賴元素引用 ref。通常你會先抓一次快照，再用回傳的元素編號去點擊、填寫、勾選或截圖。

輸出結果

1
2

playwright-cli screenshot
playwright-cli pdf

分頁

playwright-cli tab-list
playwright-cli tab-new [url]
playwright-cli tab-close [index]
playwright-cli tab-select <index>

07 它適合誰

如果你屬於下面這些場景，Playwright CLI 很值得試：

你在用 Claude Code、Copilot 或其他 coding agent 做 E2E 測試
你希望瀏覽器自動化介面更輕量，不想把大量頁面結構塞進上下文
你希望同一個瀏覽器 session 能跨多次命令持續存在
你想在 agent 自動跑網頁任務時，隨時打開監控面板觀察進度

如果你的重點是「瀏覽器自動化如何和 coding agent 高效配合」，Playwright CLI 很可能會比傳統的人類手動除錯方式更順手。

參考連結

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

OpenClaw 類腦記憶演算法 Dreaming：機器開始做夢，人類卻在失眠

Sun, 12 Apr 2026 12:41:34 +0800

大模型的長期記憶一直是個老問題。上下文越積越多，資訊就越容易混亂。智能體看似什麼都記得，實際上卻越來越難判斷什麼重要、什麼該忘。

4 月 5 日，OpenClaw 在新版本中上線了一項實驗功能：Dreaming。它不是一個花俏名稱，而是一套模仿人類睡眠過程的背景記憶整理機制，目標很直接，就是讓智能體醒來之後記得更準。

01 睡眠演算法：把記憶整理拆成三個階段

Dreaming 並不只是做索引，而是把記憶整理拆成三個邏輯階段，對應人類睡眠中的不同功能。

淺睡階段（Light Sleep）：系統先掃描近期對話與召回紀錄，做去重與初步篩選，建立候選內容。這個階段只做暫存，不會直接改動核心記憶檔案 MEMORY.md。

深睡階段（Deep Sleep）：系統開始依規則篩選高價值資訊。只有同時達到最低評分、最低召回次數與最低獨特查詢次數的內容，才會進入下一步。寫入前還會重新比對最新日誌，剔除過時內容，最後把結果追加到 MEMORY.md，並在 DREAMS.md 中留下深睡摘要。

快速動眼階段（REM）：在記憶固化之後，系統會進一步分析短期行為痕跡，尋找不同資訊之間的潛在關聯，生成模式總結與反思內容。這部分會寫入專門的 REM 區塊，幫助智能體在處理複雜任務時更容易掌握全局。

除了給機器自己使用的記憶整理機制，Dreaming 還會順手生成一份更適合人類閱讀的「夢境日記」。當素材累積到一定程度，背景子智能體會呼叫預設模型，在 DREAMS.md 中追加一段簡潔說明。

02 評分機制：決定什麼該留下，什麼該被忘掉

Dreaming 的關鍵不只是「整理」，更是「篩選」。OpenClaw 沒有繼續沿用粗放式的全量保存，而是用一套加權評分機制判斷哪些資訊值得進入長期記憶。

這套機制主要看六個維度：

相關性權重（30%）：衡量資訊在被檢索時到底有沒有用。
頻率權重（24%）：統計某條資訊被反覆提及的次數。
查詢多樣性（15%）：看它是否在不同問題與情境中都出現過。
時效性權重（15%）：讓近期資訊擁有更高優先級。
整合度權重（10%）：看資訊是否能跨多天穩定出現。
概念豐富度（6%）：判斷它背後的關聯概念是否足夠豐富。

這代表系統不是把所有內容一股腦塞進長期記憶，而是優先保留那些反覆出現、能解決問題、又不過時的資訊。

03 為什麼它會讓人想到 Claude 的「做夢」思路

有開發者認為，OpenClaw 這次 Dreaming 升級的思路，很像 Claude Code 洩露程式碼中提到的 KAIROS 自動做夢機制。過去那種反覆讀寫整個 MEMORY.md 的做法，到了後期很容易讓記憶系統愈來愈臃腫；而 Dreaming 把流程拆成淺睡整合、深睡固化、REM 關聯，邏輯明顯更清楚，也更接近「先整理、再沉澱、再提煉」的設計。

也有人從神經科學角度肯定這套設計。因為 Dreaming、淺睡、深睡與 REM 這些概念並不是隨便取的名字，而是明確借用了人類睡眠鞏固記憶的模型。

OpenClaw 現有的 IDENTITY.md、USER.md 和 HEARTBEAT.md 已經提供了智能體的人設、使用者上下文與運行連續性，而 DREAMS.md 補上的，正是「哪些記憶該留下」的能力。

04 最諷刺的一幕：機器學會做夢，人卻睡不著

Dreaming 的真正價值，不是讓 AI 什麼都記住，而是讓它學會回顧短期記憶、提取底層模式、過濾噪音。一個真正好用的智能體，不應該像移動硬碟一樣死記硬背，而應該越來越懂使用者的偏好、目標與背景。

從工程角度看，這套機制最值得注意的地方，在於它並不神祕。它不是黑盒魔法，而是一套有階段、有門檻、有反思，也有遺忘規則的背景流程。這種設計讓 AI 的記憶機制第一次看起來更像「可控的系統」，而不只是「無限堆上下文」。

但也正因如此，整件事才顯得有些諷刺：我們正投入大量資源，教機器如何像人一樣做夢；與此同時，許多人卻因為擔心被這些越來越聰明的系統取代而失眠。

該放棄 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 更適合作為連接協議，而不是唯一執行協議。

OpenClaw 與 Agent Harness：為什麼它看起來像 AGI

Fri, 10 Apr 2026 09:16:17 +0800

很多人第一次接觸 OpenClaw，會覺得它「比聊天機器人更像一個會做事的同事」。

這種感覺並不神祕。關鍵在於：OpenClaw 不是單一模型能力的躍遷，而是一套完整的 Agent Harness。

先給結論

OpenClaw 的本質可以概括為：

模型負責理解與決策
Harness 負責記憶、工具、觸發、執行與輸出
兩者透過循環協作，形成「持續行動」的體驗

所以它「像 AGI」的核心原因，不是模型突然變成全能，而是系統工程把模型的可執行性放大了。

什麼是 Harness

可以把 Harness 理解為「給模型穿上的外骨骼」。

單獨的 LLM 通常只能在一次請求裡給出回答，而 Harness 會補齊這些能力：

會話與狀態管理：把多輪任務串起來
記憶機制：保存並按需召回上下文
工具系統：調用瀏覽器、終端、檔案與外部 API
觸發機制：由定時器或事件喚醒，不必每次都等人提問
輸出通道：把結果寫回系統，而不只是回一段文字

當這些能力被接入同一個循環時，模型就從「回答器」變成「執行器」。

OpenClaw 為什麼顯得不一樣

傳統聊天機器人是「問一次，答一次」。

OpenClaw 更像「觀察 -> 調工具 -> 看結果 -> 再決策」的閉環。閉環一旦成立，就會表現出持續推進任務的能力。

這也是 OpenClaw 最值得學習的地方：

它證明了 Agent 體驗主要來自架構設計
它把「自治」拆成了可工程化的模組

價值與邊界

OpenClaw 的優勢是通用、靈活，但代價也明顯：

上下文與工具定義越多，成本越高
系統越通用，調試和治理越複雜

在生產場景裡，很多團隊會選擇更小、更專的 Agent，而不是一個「全能智慧體」。

Anthropic 與 OpenClaw 事件時間線：完整過程

Wed, 08 Apr 2026 19:48:42 +0800

事件背景

2026 年 4 月 4 日，Anthropic 宣布切斷 Claude 訂閱對 OpenClaw 等第三方工具的覆蓋。

對使用者層面的直接影響是：原先依賴訂閱路徑接入 Claude 的第三方流程，需要改為其他接入方式或切換到其他模型。

時間線（2026 年 1 月至 4 月）

2026 年 1 月

根據公開報導，Anthropic 要求當時名為 Clawdbot 的專案調整名稱，理由是發音與 Claude 接近。

同一階段，社群開始出現關於第三方透過訂閱憑證調用能力受限的回饋。

2026 年 2 月

相關限制被寫入服務條款，訂閱與第三方自動化調用之間的邊界進一步明確。

同月，OpenClaw 發布 v4.0，底層架構改為可插拔模型後端。也就是說，模型不再是單一固定入口，而是可以在多個模型供應方之間切換。

2026 年 3 月

Anthropic 發布 Claude Dispatch 與 Computer Use，覆蓋遠端任務執行與桌面操作等能力。

OpenClaw 在後續更新中持續推進相容層，統一不同模型在認證方式、工具調用格式與回傳資料結構上的差異，降低切換模型時的遷移成本。

公開報導也提到，OpenClaw 團隊與 Anthropic 在 3 月下旬有過溝通，但最終策略方向未發生改變。

2026 年 4 月 4 日

Anthropic 正式執行對第三方工具的訂閱覆蓋切斷。

這標誌著此前數月策略調整進入執行階段。

2026 年 4 月 5 日

OpenClaw 發布 v4.5，主要動作包括：

在引導流程中調整模型入口優先順序
接入 GPT-5.4 等替代模型路徑
持續針對任務流程與互動體驗進行適配

從發布時間看，OpenClaw 的切換能力並非完全臨時建構，而是建立在 2 月以來的多模型架構改造基礎上。

過程中的兩個並行方向

按時間線看，雙方在同一時期分別推進了不同方向：

Anthropic：收緊訂閱邊界，推動官方產品能力整合
OpenClaw：強化模型可替換性，提升跨模型相容能力

這兩條路線並不矛盾，但會在「入口歸屬」與「使用者工作流沉澱位置」上產生競爭關係。

目前狀態（截至 2026 年 4 月）

基於已公開資訊，可以確認以下事實：

訂閱覆蓋切斷已執行
OpenClaw 已完成主要模型路徑切換並持續版本迭代
使用者是否感知明顯變化，取決於其原有工作流對單一模型能力的依賴程度

後續觀察點

接下來更值得關注的，不是單次事件本身，而是三件事：

訂閱方案與 API 調用邊界是否持續細化
多模型 Agent 在穩定性、成本與體驗上的長期表現
使用者工作流最終沉澱在模型層、工具層，還是兩者之間的混合層

模型	適合場景
`deepseek-v4-flash`	日常程式碼閱讀、批量改小問題、生成腳本、整理上下文、低風險前端修改
`deepseek-v4-pro`	架構規劃、複雜 bug、跨檔案重構、事實核查、多工具呼叫、高風險改動