工作流 on KnightLi的博客

subagent 會多花多少 token？多 agent 成本與使用策略

Sun, 31 May 2026 14:17:42 +0800

使用 subagent 或多 agent 工作流，通常都會增加 token 用量。差別不在於「會不會增加」，而在於增加多少、換來的並行效率和穩定性是否值得。

如果任務很小，直接讓主 agent 完成通常更省。只有當任務可以清楚拆分，或需要獨立複查時，subagent 才更容易體現價值。

subagent 不是更便宜的並行執行緒

很多人第一次看到 subagent，會下意識把它理解成「並行執行緒」：主 agent 做一部分，subagent 做另一部分，速度變快，所以應該更划算。

實際不是這樣。subagent 本質上也是一個獨立的模型呼叫。它需要讀任務說明、理解上下文、讀取檔案、分析問題，再輸出結果。也就是說，它不是主 agent 的免費副本，而是額外啟動了一條推理鏈路。

所以使用 subagent 的核心判斷不是「能不能並行」，而是「並行帶來的時間節省、品質提升，是否值得額外 token 成本」。

為什麼會增加 token

一次 subagent 呼叫通常會額外消耗這些 token：

主 agent 寫給 subagent 的任務說明；
傳遞給 subagent 的上下文；
subagent 自己讀取檔案和分析問題；
subagent 產生結果或修改說明；
主 agent 回收結果後的複查、整合和驗證。

如果多個 agent 讀取同一批大檔案，重複消耗會更明顯。尤其是程式碼庫分析、長文件翻譯、批量內容整理這類任務，如果拆分不好，token 會花在重複理解上下文上。

重複讀取上下文是最大的 token 浪費

subagent 真正浪費 token 的地方，往往不是「多開了一個 agent」，而是多個 agent 反覆讀同一批材料。

例如一個任務要處理 6 篇文章，如果 4 個 agent 都先讀完整站點結構、完整技能文件、完整文章列表，再各自處理一小塊內容，那麼並行會很貴。更好的做法是先由主 agent 確定邊界，再讓每個 subagent 只讀自己負責的文章目錄。

更省 token 的拆法通常是：

每個 agent 只負責一個明確目錄；
給 subagent 的上下文越短越好；
不讓多個 agent 重複做同一類探索；
主 agent 最後統一複查，而不是讓每個 agent 都做全量複查；
能用腳本統一檢查的部分，不交給多個 agent 反覆檢查。

換句話說，subagent 的成本控制重點是邊界，而不是數量。

大概會增加多少

下面是一個粗略估算，實際消耗取決於上下文長度、檔案大小、任務複雜度和 agent 數量。

場景	token 增加
單個 subagent 處理一個小任務	約 `1.2x - 2x`
2-4 個 agent 並行處理可拆分任務	約 `2x - 5x`
多個 agent 各自讀取大量檔案、做長分析	可能 `5x+`
主 agent 和 subagent 重複讀同一批大檔案	浪費最明顯

這不是精確計費公式，只是經驗範圍。真正的消耗還要看每個 agent 是否需要讀完整檔案、是否需要長推理、是否會反覆等待和補充上下文。

如何給 subagent 寫更省 token 的任務說明

任務說明越寬泛，subagent 越容易自己去探索上下文，token 消耗也越高。更省的寫法是把邊界寫清楚。

一個好的 subagent 任務說明應該包含：

只允許處理哪些檔案或目錄；
哪些檔案只能讀，哪些檔案可以寫；
已有檔案是否允許覆蓋；
需要保留哪些欄位，比如 date、slug、aliases；
輸出時只回報什麼結果；
不需要做哪些事情，比如不要跑完整建置、不要改無關檔案。

例如，處理翻譯時，不要只寫「把文章翻譯成多語言」。更省 token 的寫法是：「只處理 content/post/2026/05/240，讀取 index.zh-cn.md，只建立缺失的 index.en.md、index.zh-tw.md、index.ja.md、index.es.md，已存在則跳過，保留 date 和 slug。」

這種說明更長一點，但能減少 subagent 自行猜測和重複探索，整體通常更省。

按檔案/目錄拆分，比按語言/步驟拆分更省

如果是批量文章翻譯，按「文章目錄」拆通常比按「語言」拆更好。

例如要翻譯 6 篇文章，每篇都要產生英文、繁體、日文、西語。更推薦讓一個 agent 負責一篇文章目錄內的所有語言，而不是讓一個 agent 負責所有英文、另一個負責所有日文。

原因很簡單：一篇文章的 front matter、程式碼區塊、連結、表格和語義上下文只需要讀一次。如果按語言拆，多個 agent 會重複讀取同一篇源文，token 會被放大。

同樣的邏輯也適用於程式碼任務。優先按模組、目錄、元件拆分，而不是按「先分析、再實作、再測試」這種步驟拆分。步驟拆分很容易讓每個 agent 都重新讀一遍上下文。

什麼情況下值得用

subagent 的價值主要在兩點：並行和獨立視角。

適合使用的場景包括：

多篇文章批量翻譯；
多個目錄可以獨立修改；
前端、後端、測試可以明確分工；
一個 agent 寫實作，另一個 agent 做風險複查；
高風險修改需要第二視角檢查。

這類任務裡，token 會增加，但總耗時可能明顯下降，而且每個 agent 只盯一塊內容，注意力更集中。

什麼時候值得用一個 agent 做複查

複查型 agent 不一定總值得用。它適合風險高、影響面大、主 agent 容易遺漏細節的任務。

比較值得加複查 agent 的情況包括：

修改涉及登入、支付、權限、資料刪除；
多語言內容會影響分類、URL、站內連結；
大範圍重構後需要獨立找回歸風險；
使用者明確要求 code review 或風險審查；
主 agent 已經做了實作，但需要第二視角看邊界條件。

不值得加複查 agent 的情況也很明確：單檔小改、標題微調、簡單 front matter 修正、只跑一個命令。這些任務主 agent 自查就夠了。

什麼情況下不值得用

不適合使用 subagent 的場景很常見：

單檔小改；
簡單問答；
只需要跑一個命令；
改動範圍很小；
任務不能清楚拆分；
subagent 必須反覆等待主 agent 提供上下文。

這類任務用 subagent 往往只是增加開銷。主 agent 直接處理更快，也更省 token。

我的預設策略：省 token 優先，風險任務才加複查

如果目標是盡量節省 token，可以採用下面這套策略：

小任務：不用 subagent。
中等任務：不用 subagent。
大批量任務：預設也不用 subagent，除非使用者明確要並行提速。
高風險任務：可以多用一個 agent 做複查，用 token 換穩定性。

這套策略更偏保守。它犧牲了一部分並行速度，但能減少重複讀取上下文和重複推理帶來的 token 消耗。

如果任務很大但不高風險，我也會優先考慮腳本、批量檢查和本地結構化處理。只有當拆分非常清楚，或者使用者明確希望並行提速時，才更適合引入多個 agent。

更均衡的策略

如果既想控制成本，又不想完全放棄並行，可以採用折衷方案：

預設主 agent 直接做；
只有任務能按檔案或目錄明確拆分時才考慮 subagent；
subagent 只讀取自己負責的檔案；
不讓多個 agent 同時讀同一批大檔案；
主 agent 最後統一複查關鍵欄位、測試結果和 Git diff；
高風險任務才增加一個獨立複查 agent。

這能避免「為了並行而並行」。subagent 應該服務於明確的效率或品質目標，而不是成為預設動作。

小結

subagent 和多 agent 一定會增加 token 用量。單個 subagent 可能只是增加一點，多個 agent 並行時則可能成倍增加。

是否值得用，取決於任務本身：如果任務能清楚拆分，或者風險高到需要獨立複查，額外 token 可能是值得的；如果只是單檔小改、簡單問答或常規檢查，直接由主 agent 完成更省。

一句話總結：小任務省 token，大任務看拆分，高風險才用額外 agent 換穩定性。

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

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 更像一個了解專案歷史的助手。

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 裡的 ~/.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，然後開新會話

使用 Agent Skills 取代 VS Code 中 Copilot 的「生成提交訊息」功能

Mon, 06 Apr 2026 13:09:49 +0800

VS Code 的 GitHub Copilot「生成提交訊息」是一個非常實用的功能。配額用盡後，重置週期通常會比較長。本文提供一個實作方案：使用本地 Agent Skills 取代這個功能。

問題與目標

本文目標是提供一套可直接落地的替代方案：使用 git-commit-push-zh skill agents 完成標準化提交與推送。

替代方案：`git-commit-push-zh`

該 skill 將「目前改動」收斂為固定流程：

檢查變更狀態。
確認目前分支。
暫存改動。
生成中文提交訊息。
執行 commit。
推送到遠端分支。

對應命令如下：

git status --short
git branch --show-current
git add -A
git commit -m "<中文提交信息>"
git push origin <当前分支>

提交訊息建議規範

建議統一格式：

`1`	`<类型>(<范围>): <中文摘要>`

類型示例：

feat：新增功能
fix：修復問題
docs：文件更新
refactor：程式重構
chore：維護性改動

示例：

feat(site): 新增全站 head 广告脚本注入
fix(i18n): 修正 relref 相关文章链接路径
chore(content): 合并 AI 工作流分类到 AI工具

常見失敗場景

nothing to commit：目前無可提交改動，停止推送即可。
push 失敗：優先檢查權限、遠端分支狀態與衝突。
SSH/權限異常：確認憑證與權限後再重試。

附錄：原始 `SKILL.md`

以下內容為 git-commit-push-zh 的原始文件，原樣保留，便於後續復用與維護。

---
name: git-commit-push-zh
description: 在当前 Git 仓库中将“当前更改”完成一次标准提交流程：检查状态、暂存变更、生成中文提交信息、执行 commit 并 push 到当前分支对应远端。用户提出“提交代码”“提交当前更改”“生成中文提交信息并推送”“git commit push 中文说明”等请求时使用。
---

# 中文提交并推送

使用此技能将当前仓库改动一次性提交并推送到远端。

## 工作流程

1. 查看变更状态：`git status --short`。
2. 确认当前分支：`git branch --show-current`。
3. 暂存当前变更：`git add -A`。
4. 生成中文提交信息（简洁、可检索）。
5. 执行提交：`git commit -m "<中文提交信息>"`。
6. 执行推送：`git push origin <当前分支>`。

## 提交信息规范（中文）

1. 建议格式：`<类型>(<范围>): <中文摘要>`。
2. 类型示例：`feat`、`fix`、`chore`、`docs`、`refactor`。
3. 摘要要求：准确描述本次改动，不写空话。
4. 若仅少量变更，也保持可读性与可检索性。

示例：

- `feat(site): 新增全站 head 广告脚本注入`
- `fix(i18n): 修正 relref 相关文章链接路径`
- `chore(content): 合并 AI 工作流分类到 AI工具`

## 错误处理

1. 若无可提交变更（nothing to commit），明确告知并停止 push。
2. 若 push 失败，先回报关键错误（权限、远端不存在、冲突等）。
3. 常见 SSH/权限问题可在用户确认后重试高权限环境。

## 输出约定

1. 汇报提交哈希、分支名、提交信息。
2. 汇报 push 结果（成功或失败原因）。
3. 仅在确有失败时提供下一步最小操作建议。

工作流 on KnightLi的博客

subagent 會多花多少 token？多 agent 成本與使用策略

subagent 不是更便宜的並行執行緒

為什麼會增加 token

重複讀取上下文是最大的 token 浪費

大概會增加多少

如何給 subagent 寫更省 token 的任務說明

按檔案/目錄拆分，比按語言/步驟拆分更省

什麼情況下值得用

什麼時候值得用一個 agent 做複查

什麼情況下不值得用

我的預設策略：省 token 優先，風險任務才加複查

更均衡的策略

小結

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

domain skills 是什麼

它不是讓 Agent 盲目點擊

它記錄的是站點級知識

例子：Amazon 商品搜尋

例子：LinkedIn 邀請管理

例子：Shopify Admin

例子：Browser Use Cloud

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

團隊可以怎麼用

需要注意的邊界

簡單結論

Claude-Mem：給 Claude Code 加上跨會話長期記憶

它解決什麼問題

工作方式

適合什麼場景

安裝和啟動

mem-search 怎麼用

和普通專案文件有什麼區別

使用時要注意什麼

為什麼這類工具值得關注

適合誰嘗試

參考

最後一句

Codex 開始控制電腦，對以後意味著什麼？

這個功能是什麼

為什麼這件事重要

它能改變哪些工作流

1. 跨軟體搬運

2. 多個 AI 工具協同

3. 辦公軟體自動化

對普通使用者意味著什麼

對軟體形態的影響

現在還不能過度樂觀

最後一句

Codex 裡的 ~/.codex/skills 和 專案/.codex/skills 有什麼差別

兩者的差別

~/.codex/skills

專案/.codex/skills

什麼時候放全域，什麼時候放專案裡

當前這個倉庫是什麼情況

為什麼磁碟裡有，當前會話裡卻不一定顯示

怎樣讓 skill 被當前會話暴露

1. 目錄放對

2. SKILL.md 頭部可識別

3. 新建或修改後，開新會話

4. 專案 skill 最好提前放好

最後一句

使用 Agent Skills 取代 VS Code 中 Copilot 的「生成提交訊息」功能

問題與目標

替代方案：git-commit-push-zh

提交訊息建議規範

常見失敗場景

附錄：原始 SKILL.md

`mem-search` 怎麼用

Codex 裡的 ~/.codex/skills 和專案/.codex/skills 有什麼差別

`~/.codex/skills`

`專案/.codex/skills`

2. `SKILL.md` 頭部可識別

替代方案：`git-commit-push-zh`

附錄：原始 `SKILL.md`