現代人工智慧代理協作架構研究：Claude Skills、提示工程、子代理工作流、Claude Projects 與模型

2026/01/09 更新2026/01/09 發佈閱讀 29 分鐘

人工智慧領域正經歷從單一的大型語言模型（LLM）對話介面，向具備高度自主性、可擴展性且能與外部環境深度整合的「代理式系統」（Agentic Systems）轉型。在這一技術演進的過程中，Anthropic 所構建的 Claude 生態系統展現出了一種精密的工程設計邏輯，其核心在於如何有效地管理上下文、標準化外部工具的連接，以及實現多層級的代理協作。本研究報告旨在深入探討 Claude Skills、提示工程（Prompt Engineering）、子代理（Sub-agents）、Claude Projects 以及模型上下文協議（Model Context Protocol, MCP）這五大核心支柱，分析其底層技術架構、運行機制及其在複雜企業級工作流中的協同作用。

模型上下文協議 (MCP)：構建 AI 工具的通用插槽

模型上下文協議（MCP）的出現，旨在解決人工智慧生態系統中長期存在的「M × N 整合難題」，即 M 個模型與 N 個工具之間因缺乏統一標準而導致的重複開發與高度耦合 1。MCP 被業界比喻為人工智慧工具的「USB-C 介面」，它提供了一種開放、標準化的方式，使 AI 應用程式能安全地連接到外部數據源、工具和工作流程，而無需為每個特定整合編寫繁瑣的膠合代碼 3。

MCP 的架構與組件定義

MCP 採用了清晰的客端—服務端—主機（Client-Server-Host）三層架構。在這一體系中，「主機」（Host）是用戶直接互動的頂層應用程式，如 Claude Desktop 或整合開發環境（IDE），負責整體用戶體驗的調度；「客端」（Client）則是主機內部的協議層組件，負責與特定的 MCP 伺服器建立並管理通訊對話；而「伺服器」（Server）則直接暴露外部工具、資源和提示模板 2。這種架構實現了邏輯與資料的徹底解耦，主機只需實作一套 MCP 客端邏輯，便能與無數遵循協議的伺服器進行對接。

在 MCP 的規範下，伺服器提供的三類主要對象構成了代理能力的基礎：資源是指如本地文件、資料庫行或 URL 等唯讀內容；工具是具有明確 Schema 的可執行函數，如「建立工單」或「執行 SQL 查詢」；提示則是伺服器託管的、可重複使用的提示模板，主機可請求模板並填充變量 5。這種結構化的能力展現方式，使得 LLM 能夠在運行時動態發現並正確調用所需的外部能力。

協議生命週期與傳輸機制

MCP 的通訊基於 JSON-RPC 2.0 規範，確保了訊息交換的確定性與結構化。每一場 MCP 互動都遵循嚴格的生命週期，包括初始化（Initialization）、操作（Operation）與關閉（Shutdown）三個階段 1。在初始化階段，客端與伺服器進行握手（Handshake），交換各自支援的協議版本與能力清單（Capabilities Exchange）；在操作階段，訊息以非同步方式進行傳遞，支援工具發現、資源同步及進度通知；關閉階段則確保所有子進程被正確終止且資源被釋放 1。

本協議目前定義了兩種標準傳輸機制。標準 I/O（stdio）主要用於本地場景，主機將伺服器作為子進程啟動，通過 stdin 與 stdout 進行資料交換，這種方式繼承了主機進程的權限設定，且不需複雜的網路配置 7。而可串流 HTTP（Streamable HTTP）則適用於遠程或基於 Web 的部署，結合了 HTTP POST 請求（用於客端傳送訊息）與伺服器發送事件（SSE）（用於伺服器串流回覆），這種雙向通訊模式雖然實作較複雜，但具備跨網路邊界的能力並支援多客端連接 7。

此外，MCP 引入了「根目錄」（Roots）機制來定義文件系統的存取邊界，幫助伺服器理解其操作範圍 6。雖然協議要求伺服器「應當」（SHOULD）遵守這些邊界，但最終的安全控制仍掌握在客端手中，通常需要用戶對涉及敏感路徑的操作進行明確核准 6。另一項關鍵特性是「取樣」（Sampling），它允許伺服器通過客端請求 LLM 生成內容，從而實現更複雜的代理工作流，伺服器本身無需直接整合 AI 模型 API，只需透過客端間接獲得推理能力 6。

Claude Agent Skills：程序化知識的模組化封裝

Agent Skills 是 Anthropic 為 Claude 系統設計的一種新型擴展機制，旨在將人類的專業知識與組織背景轉化為代理可直接載入的資源。這不僅僅是簡單的系統指令，而是一個包含指令、腳本和資源的模組化目錄結構 11。透過將「如何做」的知識封裝在 Skill 中，開發者能將通用代理轉換為特定領域的專家，如專門審查 PR 的代理或分析財務報表的代理 11。

Skill 的目錄結構與技術核心

一個 Skill 本質上是一個包含 SKILL.md 文件的操作系統目錄。SKILL.md 是 Skill 的入口點，必須以 YAML Frontmatter 開頭，定義其名稱（name）與描述（description） 11。描述字段至關重要，因為它是代理在啟動時唯一預先載入的資訊，Claude 依據此描述來判斷該 Skill 是否與當前任務相關 11。

這種設計遵循了「漸進式披露」（Progressive Disclosure）原則，將 context 管理分為三個層級。第一層是探索（Discovery），代理僅持有所有安裝 Skill 的元數據，這將每個 Skill 的開銷降至約 100 個 token 12。第二層是激活（Activation），當用戶請求觸發 Skill 時，代理讀取完整的 SKILL.md（通常小於 5,000 token） 12。第三層是執行（Execution），代理根據需要進一步讀取目錄內的參考資料或執行腳本 12。

程式碼執行與確定性操作

與純文本提示詞不同，Skills 允許整合程式碼以執行需要確定性結果的任務，如排序、PDF 欄位提取或複雜的數學運算。藉由程式碼執行工具（Code Execution Tool），Claude 可以運行 Skill 目錄內的腳本而無需將腳本本身或大型源文件（如 50MB 的 PDF）載入 context 視窗 12。代理僅接收腳本的標準輸出（stdout），這極大地優化了 context 的利用率，並確保了任務的重複性與精確度 12。

在 API 整合方面，開發者需在 Message API 請求中指定 beta 標頭，包括 code-execution-2025-08-25、skills-2025-10-02 以及 files-api-2025-04-14 12。Skills 可由 Anthropic 託管（如專門處理 docx、pdf 的 Skill）或由用戶上傳自定義 Skill，兩者在 API 層面的調用結構是一致的，均通過 container 參數指定 skill_id 13。

多代理協作架構：子代理的任務分解與決策路徑

當任務規模超出單一代理的有效管理範圍時，Claude Code 與 Agent SDK 引入了「子代理」（Sub-agents）架構。這是一種階層式的決策體系，由一個主要的「管理者」或「編排者」代理（Orchestrator）根據任務的專業需求，將子任務分派給具備獨立 context 視窗、特定工具集和專屬系統提示詞的專門化代理 14。

子代理的核心優勢與運行環境

子代理的設計初衷是為了解決 context 污染、併行處理效率以及工具選擇準確性等問題。每個子代理運行在一個與主對話隔離的 context 視窗中，這意味著其內部的中間步驟或長篇搜索結果不會干擾主對話的清晰度 15。此外，每個子代理的執行均會分配一個唯一的 agentId，其對話歷程會被存儲在獨立的轉錄文件（如 agent-{agentId}.jsonl）中，這使得系統能夠恢復先前的子代理對話，實現跨 session 的狀態連貫性 15。

子代理的委派邏輯遵循專業性匹配。在 Claude Code 中，系統會掃描現有的子代理描述，當遇到與該描述匹配的子任務時（例如「請檢查代碼中的安全漏洞」），系統會自動委派給專門的子代理。這種「工具化子代理」的模式，使得主代理可以將子代理視為一種強大的、可交談的工具 15。

協作模式：新聞編輯室工作流示例

一個經典的子代理協作案例是「新聞編輯室」模式。在這個工作流中，一位「管理者代理」負責定義主題並將任務拆解，隨後將其分派給五個不同的子代理：編劇（Writer）負責撰寫初稿，事實查核者（Fact Checker）驗證聲明，編輯（Editor）改進結構，校對（Copy Editor）負責格式化。管理者不僅僅是轉發訊息，還會根據事實查核者的反饋要求編劇進行修訂，形成一個自動化的閉環反饋機制 14。這種模式極大地減少了人類在中間環節的介入，並利用不同角色的相互制衡來提高產出質量 14。

在技術實現上，子代理的定義通常存放在 .claude/agents/（專案級別）或 ~/.claude/agents/（用戶級別）目錄下。用戶可以透過 /agents 命令進行互動式管理，包括建立、編輯或刪除子代理，以及配置其專屬的工具權限 15。值得注意的是，子代理並不會自動繼承父代理的 Skills，需在配置中明確指定其所需的資源集 15。

Claude Projects：知識庫持續性與 RAG 的深度整合

Claude.ai Projects 是針對專業協作與長週期任務設計的封閉式工作空間。它整合了獨立的聊天歷史、自定義指令以及具備檢索增強生成（RAG）能力的知識庫 17。這使得團隊能夠圍繞特定主題（如「產品發布規劃」或「法律合規審查」）構建一個具有持久記憶的 AI 夥伴。

知識庫限制與 RAG 自動化機制

項目的核心功能是其知識庫（Knowledge Base），用戶可上傳 PDF、Word、Excel、代碼文件及各類文本資料（單一文件限制 30MB）。與一般對話不同，上傳至項目的文件會對該項目內的所有聊天 thread 可見，減少了重複上傳的負擔 17。當項目的知識內容接近 context 視窗的飽和點（對於付費用戶，這通常伴隨著 200K 至 500K token 的基準線）時，Claude 會自動啟用 RAG 模式 20。

RAG 模式的運作是無縫的。當系統監測到數據量過大時，它不再嘗試將所有內容一次性載入推理視窗，而是建立索引，在用戶提問時檢索最相關的片段進行回答。這種機制使得項目能夠承載數百萬 token 的背景資料而不會導致模型出現幻覺或反應遲鈍 20。對於付費用戶，這種自動擴展能力是維持生產力的關鍵技術保障。

項目記憶與企業級安全

Claude 的記憶機制在項目中得到了細分。除了單次對話內的「對話記憶」外，項目具備「項目記憶」（Project Memory），它會隨著對話的演進自動生成「項目摘要」，記錄進行中的工作細節、技術風格偏好及團隊溝通慣例 19。這種記憶是隔離的，項目的 context 絕不會與非項目聊天或其他項目共享，確保了資料的私密性與安全性 20。

在企業環境中，項目的共享層級被嚴格控制。擁有者可以設置為「私有」或「全組織共享」，並分配「僅可使用」（Can use）或「可編輯」（Can edit）權限。管理員擁有最高權限，可隨時禁用組織內的記憶合成功能，這將立即永久刪除所有現有的記憶摘要數據，符合嚴格的合規性要求 20。

提示工程的演進：從 Claude 3.5 到 4.5 的技術最優解

隨著模型能力的提升，提示工程的焦點已從「引導模型嘗試」轉向「精確指令控制」。Claude 4.5 模型的推出標誌著一個重要轉折：該模型在遵循指令方面變得更為精確，但也更為「字面化」，它不再傾向於進行「好心的猜測」，而是嚴格執行明確要求的行為 21。

XML 標籤與結構化提示的標準化

XML 標籤是 Claude 提示工程中的「一等公民」。模型經過專門微調，能夠對 XML 結構（如 <context>、<instructions>、<example>）給予高度關注 24。這種結構化方法解決了長文本中的指令漂移問題。當輸入超過 10,000 token 時，使用標籤來區分背景知識與具體指令，能有效防止模型將參考資料誤認為待執行的任務 22。

從 3.5 到 4.5 的遷移與行為轉變

從 Claude 3.5（或 3.7）遷移至 4.5 時，開發者必須進行「隱含假設審查」。過去模型可能會自動為「儀表板」添加過濾器，但 4.5 可能只會生成數據表。因此，提示必須變得「極其具體」 22。此外，4.5 模型具備「Context 覺察能力」，它會在每次工具調用後獲取剩餘的 token 預算資訊，這使其能更有效地管理長任務，例如在視窗快滿時主動保存進度至本地文件並建議啟動新視窗 23。

「延伸思考」（Extended Thinking）是 4.5 的另一項核心功能。對於數學、邏輯規劃或跨文件代碼修改等任務，開發者應配置 thinking 預算（如 10,000 tokens）。這允許模型在產生輸出前進行廣泛的內部驗證與路徑探索，顯著降低了複雜問題中的錯誤率 21。值得注意的是，這會增加延遲，因此應根據任務的重要性而非速度來選擇是否啟用。

工具使用的進階技術：動態搜索與程式化編排

為了進一步優化大規模代理系統的性能，Anthropic 引入了「工具搜索工具」（Tool Search Tool）與「程式化工具調用」（Programmatic Tool Calling）兩項進階功能 31。

工具搜索工具的按需發現

傳統做法是在系統提示中塞入所有工具定義，這在連接多個 MCP 伺服器時會迅速耗盡 context。透過將工具標記為 defer_loading: true，開發者可以僅加載一小部分核心工具。當 Claude 需要特定功能時，它會調用「工具搜索工具」來從數千個定義中檢索匹配項，隨後才將具體定義展開至當前 context 中 31。這種「按需加載」模式能將 context 佔用率降低高達 95%，保留更多空間供推理使用 31。

程式化調用與 Context 污染防治

「程式化工具調用」則代表了從「語言驅動」向「代碼驅動」的轉向。Claude 不再需要與每個工具進行單獨的 API 往返，而是撰寫一段 Python 腳本來在沙盒中一次性執行多個工具 31。這對於處理大型數據集尤為有效。例如，當需要處理數千條日誌時，Claude 撰寫腳本讀取、過濾並計算統計結果，最終僅將「最終摘要」返回至其主要的 context 視窗中。這不僅減少了高達 37% 的 token 開銷，更消除了大量的推理開銷與延遲 29。

系統性整合與企業代理未來展望

在本研究所探討的五大組件中，我們可以看到一條清晰的技術整合路徑。模型上下文協議（MCP）解決了底層的連通性與標準化問題；Agent Skills 提供了專業化知識的封裝框架；子代理架構實現了複雜任務的層級化管理；Claude Projects 則為這些活動提供了持久的協作環境；而演進中的提示工程則充當了指揮這一切的精確語言引擎。

未來的代理系統將不再是孤立的對話框，而是具備「跨 session 連貫性」的自主實體。Claude 4.5 系列所展現的長時程自主運行能力（長達數小時的專注工作），結合其對自身資源（token 預算）的實時監控，預示著 AI 將從「輔助工具」演變為「虛擬員工」 29。在資安補丁自動化、連續性財務分析以及端到端軟體開發等場景中，這種由 Skills、MCP 與子代理共同驅動的體系結構，將成為企業提升生產力的核心競爭力。

本報告分析的技術目前多處於 Beta 或快速迭代階段，開發者在實施時應密切關注 claude-sonnet-4-5-20250929 等最新模型的行為變化，並在建構系統時遵循「從簡到繁」的原則。優先利用強大的提示工程與 XML 結構建立穩定基礎，再逐步引入 MCP 伺服器與子代理層級，以確保系統的可解釋性、安全性與執行效率 16。代理式人工智慧的未來已不限於文字的生成，而在於透過結構化的協議與模組化的知識，實現對現實物理世界與數位世界的精準操控。