AI Agent 要變強，有兩條完全不同的路。 一條是Skill，也就是給自己裝技能，把新能力直接塞進腦中。 另一條是SubAgent，就像派小弟去工作，自己只看報告。 這兩條路聽起來都能讓Agent 更厲害，但適用的場景還是有所不同，用錯了的話，你的Agent 可能反而會越用越慢、越用越亂。 Skills，就像是給主Agent 裝插件。 例如你的Agent 原本只會聊天，現在你想讓它能寫PPT。 Skills 的做法是：把寫PPT 的能力說明、工具呼叫方式、注意事項，全都塞進主Agent 的上下文中。主Agent 透過上下文學會了這項技能，它可以自己來寫PPT。 第二種叫SubAgent，就像是委託外包。 同樣是寫PPT，SubAgent 的做法是：主Agent 把任務派給一個專門寫PPT 的SubAgent，SubAgent 獨立完成後把結果交回來。主Agent 全程不參與具體執行，只負責派活和驗收。 一個是內化能力，一個是外包能力。聽起來都能搞定任務，差別在哪？ 區別在上下文管理，上下文就是AI 的記憶。 你可以把AI 的上下文想像成一張工作桌。桌子大小是固定的，你放的東西越多，就越難找到需要的那份文件。這就是上下文容量的問題。 Skills 模式下，所有能力說明都鋪在同一張桌上。好處是資訊互通，主Agent 能看到所有中間結果，推理過程連貫。壞處是桌子很快就亂了，Prompt 越來越長，能力之間可能打架，AI 開始犯糊塗。 SubAgent 模式下，SubAgent 在另一張桌子上工作。乾完把結果遞過來，過程中產生的草稿、中間文件全留在那邊。主Agent 的桌面保持乾淨。代價是訊息傳遞要設計好，不然關鍵訊息可能在交接時遺失了。 這就是上下文污染問題，這裡的污染不是誇張的比喻，是真實的工程瓶頸。 什麼時候用哪一種？ 判斷標準其實很簡單：子任務有多複雜，以及你需要不需要完成任務過程中產生的資訊。 Skills 適合的場景：任務本身較不複雜，或是你需要主Agent 全程掌控。 例如讓Agent 充當入口路由，根據用戶請求載入不同的“場景模式”，像是進入YouTube 總結模式、進入寫入報告模式。這時候Skills 的懶加載特性很香：先只載入能力名字和簡介，真正要用時才載入完整說明。不像MCP 那樣一股腦把所有工具的詳細文件全塞進上下文。 SubAgent 適合的場景：子任務很重、很耗時、中間過程很囉嗦。 最典型的例子是瀏覽器偵錯工具。 Chrome DevTools 的MCP 功能很強，但工具說明太臃腫，放進主Agent 會嚴重佔用上下文。把它封裝成SubAgent，你只需要說“去查日誌、截圖、分析一下”，它跑完把分析結論遞回來。中間那些截圖、DOM 樹、網路請求細節，全都留在SubAgent 那邊，不污染主Agent 的上下文。 進階玩法 有趣的是，Skills 和SubAgent 這兩種模式可以結合。這技巧是從@yan5xu 那裡學來的（https://t.co/uSkwSUvNiJ）。 第一種想法叫做「先展開再壓縮」。 打個比方：你開了一個兩小時的腦力激盪會，白板上寫滿了草稿、爭論、被否決的方案。但最後寫進會議紀要的只有三個結論。那些中間過程對得出結論很重要，但對後續執行的人來說是噪音。 Agent 也可以這樣操作。主Agent 發現需要某個Skill，載入進來，一通操作拿到結果。然後把從「加載Skill」到「拿到結果」這整段過程折掉，只保留最終結論。對後續推理來說，就像開了一個會但只留下了會議紀錄。 第二種想法是用檔案系統做「中繼站」。 想像你管理一個外包團隊。你不會把所有需求細節都塞進一條微信訊息裡，而是說「需求文件在這個鏈接，去看」。外包團隊交付時也不會把原始碼複製貼上給你，而是說「程式碼在這個倉庫，部署文件在這裡」。 Agent 之間也可以這樣協作。主Agent 委託任務時，不把冗長的背景資料直接寫入指令，而是存成文檔，只傳一個位址。 SubAgent 回來時也是一樣：交付一個簡短的狀態摘要——「完成了/卡住了/需要你決策」——加上一個詳細記錄的文檔地址。主Agent 根據狀況決定要不要點進去看細節。這樣雙方的上下文都保持精簡。 第三種是Claude Code 裡的實戰技巧。 上下文快見底時，請Claude 把目前完成的工作總結成一份文件。然後用rewind 功能回滾到任務開始前的狀態，告訴它：“這件事我已經做完了，記錄在這個文件裡。” 相當於什麼？相當於你跑了一場馬拉松，快到終點時發現體力不支。於是你把已經跑過的路線畫成地圖存檔，然後「瞬移」回起點，精力充沛地說「我知道怎麼走了，地圖在這」。上下文被清除了，但成果保留了下來。用這個方法能在上下文耗盡前搶救一把。 最後 Agent 的競爭正在從「能調用多少工具」轉向「怎麼優雅地管理這些工具」。 很多人追逐最新的Agent 框架、最花俏的能力擴展，卻忽略了最基礎的問題：AI 的工作記憶是有限的，你怎麼組織它，決定了它能做多複雜的事。 Skills 和SubAgent 不是非此即彼的選擇，而是兩種工具，用對場景才能發揮價值。 說到底，Agent 架構設計和軟體架構設計還是有許多相通之處。 是把邏輯寫在一個巨型函數裡，還是拆成模組化的微服務？ 是共享全域變數圖省事，還是嚴格隔離狀態保持乾淨？ 這些老問題換了個皮，又回來了。
