超越 VSCode 的多代理系統：一種模式浮現

三個不同團隊——Microsoft 的 VSCode 工程師、Microsoft Research（AutoGen）以及建構 Agentic SDLC 系統的企業 AI 實踐者——獨立地達到了極為相似的解決方案。這不是巧合，而是收斂演化揭示了可靠、可擴展 AI 系統的基本模式。

模式：專門化代理 + 結構化交接

這個新興的多代理模式核心包含四個關鍵組成部分：

1. 專門化代理，具有明確界定的責任範圍
2. 工具限制，與每個代理的角色相符
3. 結構化交接，明確地在代理間轉移上下文
4. 人工關卡，設於關鍵決策點

這種模式在不同實作中持續出現，從 VSCode 新推出的自訂代理功能（v1.106）到 Microsoft Research 的 AutoGen 框架，再到實際的 Agentic SDLC 部署。讓我們探討為何這種架構有效以及何時應該使用它。

VSCode 自訂代理：為開發者設計的交接機制

VSCode 1.106 引入了自訂代理——這個功能將 GitHub Copilot 從單一助手轉變為專門化團隊。不再是一個代理試圖做所有事情，你可以為不同任務創建專注的代理：研究、寫作、程式碼審查、測試。

架構深度解析

自訂代理定義在 .github/agents/ 目錄中的 .agent.md 檔案：

---
name: researcher
description: 蒐集主題的全面資訊
tools: ["fetch", "search", "githubRepo"] # 唯讀工具
handoffs:
  - label: 產生想法
    agent: ideas-generator
    prompt: "根據上述研究，產生 3-5 個部落格文章想法"
    send: false # 需要人工批准
---
# 研究代理

你是一個徹底的研究者，蒐集準確且有來源的資訊。

你的責任：
- 搜尋文件與程式碼儲存庫
- 取得相關網路資源
- 將發現組織成結構化報告
- 引用所有來源以供驗證

不要撰寫程式碼或編輯檔案。純粹專注於資訊蒐集。

神奇的地方在於交接配置。當研究者完成任務時，聊天介面會出現「產生想法」按鈕。點擊它，你會自動切換到 ideas-generator 代理，研究上下文已預先填入。人類保持控制權——在繼續之前審查每個轉換。

實際範例：部落格生成管道

考慮一個 5 代理內容創作工作流程：

研究者 → 想法產生器 → 部落格寫手 → 事實查核 → 翻譯者

每個代理精確擁有它所需的工具：

• 研究者：['fetch', 'search', 'githubRepo'] — 不會意外編輯檔案
• 想法產生器：['search'] — 專注於綜合分析而無程式碼存取權
• 部落格寫手：['edit', 'runCommands', 'problems'] — 完整編輯能力
• 事實查核：['fetch', 'githubRepo', 'search'] — 驗證但不更改
• 翻譯者：['edit', 'search', 'problems'] — 創建本地化版本

這實作了最小權限原則：每個代理獲得其角色所需的最小權限。研究者不會意外覆寫你的程式碼。寫手不會無意中觸發生產部署。

交接機制

交接創建明確的工作流程轉換：

handoffs:
  - label: "撰寫部落格文章" # 顯示給使用者的按鈕文字
    agent: blog-writer # 目標代理 ID
    prompt: "根據大綱 #{{N}} 撰寫完整部落格文章"
    send: false # false = 人工審查，true = 自動提交

當 send: false 時，提示會預先填入但不會發送——人類可以審查並修改它。當 send: true 時，它會自動提交以進行完全自動化的工作流程。這給你一個調節自動化與監督的旋鈕。

AutoGen：事件驅動的多代理框架

VSCode 專注於面向開發者的工作流程，而 Microsoft Research 的 AutoGen 則處理建構複雜、分散式多代理系統的更廣泛問題。

架構哲學

AutoGen v0.4（2024-2025 年釋出）使用非同步、事件驅動架構：

from autogen import Agent, Sequential, ConversableAgent

# 定義專門化代理
researcher = ConversableAgent(
    name="researcher",
    system_message="你從多個來源蒐集資訊...",
    llm_config={"model": "gpt-4"},
)

analyzer = ConversableAgent(
    name="analyzer",
    system_message="你分析研究並識別模式...",
    llm_config={"model": "claude-sonnet-4"},
)

# 創建帶轉換的工作流程
workflow = Sequential([researcher, analyzer])
await workflow.run("研究多代理模式")

與 VSCode 方法的主要差異：

進階功能

AutoGen 在複雜場景中表現出色：

1. 非同步訊息傳遞：代理透過事件溝通，支援請求/回應和發布/訂閱模式
2. 跨語言支援：代理可以用 Python、.NET 或其他語言撰寫，仍然可以互操作
3. 內建可觀測性：OpenTelemetry 整合用於追蹤代理互動
4. 模組化元件：可插拔的工具、記憶體系統和模型後端
5. 分散式執行：代理可以跨組織邊界執行

當你需要長期執行、具企業可觀測性需求的生產級多代理系統時，AutoGen 提供了 VSCode 更簡單模型不嘗試的基礎設施。

Agentic SDLC：大規模人在回路

超越框架，實際部署揭示了企業如何將多代理模式應用於軟體開發本身。

基於角色的觀點

不是將代理對應到職稱（產品經理、工程師、QA），而是圍繞觀點組織它們：

願景/策略代理
    ↓
設計/架構代理
    ↓
執行代理
    ↓
風險與合規代理
    ↓
可觀測性代理

一個統籌者協調這些代理，打包證據供人類審查，並管理升級。

人在回路關卡

關鍵創新：人類審查證據包，而非完整產物。

傳統程式碼審查：「請審查這個 500 行的 pull request。」

Agentic SDLC：「請審查這個證據包：

• 變更摘要：在 API 閘道增加快取層
• 影響分析：影響 3 個下游服務，向後相容
• 測試證據：覆蓋率從 78% 增加到 84%，所有整合測試通過
• 安全掃描：無新漏洞，相依套件授權 OK
• 回滾計畫：已測試功能旗標切換，30 秒回滾時間」

人類基於綜合證據做決策，而非閱讀每一行程式碼。這在不成為瓶頸的情況下擴展人工監督。

基於風險的路由

不是所有變更都需要人工批准。使用風險分數來路由決策：

風險 = 關鍵性(1-5) × 變更大小(1-5)
       + 覆蓋率缺口%(0-5)
       + 變動率(0-3)
       + 新穎性(0-3)

路由政策：

• 高風險（≥10）：需要人工審查
• 中風險（6-9）：同儕代理審查
• 低風險（≤5）：自動合併搭配 10-20% 隨機抽樣

這允許低風險工作的自動化，同時保留人類判斷用於高影響決策。

HITL 關卡範例

1. 願景關卡：人類批准業務目標、KPI、限制。代理呈現選項與權衡。

2. 需求承諾關卡：1-3 天可交付的薄切片凍結。變更產生新切片並附影響分析。

3. 高風險設計關卡：對於模式變更、外部合約或影響 SLO 的設計。人類審查 ADR 摘要 + 威脅模型摘要。

4. 程式碼變更關卡：風險分數決定路徑（見上述路由政策）。

5. 釋出關卡：人類批准推出策略（功能旗標、金絲雀、回滾計畫），不一定是完整差異。

6. 事件關卡：SLO 違反觸發統籌者打包日誌/追蹤與建議修復，供人類主導的無責審查。

7. 模型/工具變更關卡：對 AI 堆疊本身的每個變更都是高風險且需要人工簽核。

這創建了一個漸進自主模型：例行工作自動流動，例外案例升級給人類並附預先打包的證據。

收斂設計：為何這種模式有效

三個獨立實作收斂到相似架構，因為它們解決了基本問題：

1. 認知負荷降低

單一代理受「試圖做所有事」症候群之苦。它們需要同時：

• 研究與綜合資訊
• 以適當風格撰寫程式碼
• 考慮安全性影響
• 思考測試策略
• 記錄它們的決策

這種認知負荷導致：

• 所有維度的平庸結果
• 根據提示措辭而不一致的品質
• 除錯困難（哪部分失敗？）

多代理解決方案：每個代理專注於一件事。研究者不擔心程式碼風格。安全審查者不產生文件。狹窄範圍 = 更好的性能。

2. 透過限制實現安全

工具限制防止整類失敗：

• 具唯讀存取權的研究代理不會意外刪除生產資料
• 沒有網路存取的程式碼產生代理不能外洩秘密
• 沒有部署權限的測試代理不能推送到生產

這是最小權限原則應用於 AI——與使 Unix 權限、IAM 政策和網路分段有效的概念相同。

3. 可審計性與除錯

當單代理會話出錯時，對話是研究、撰寫、回溯和修正的混亂。找到失敗點是考古學。

多代理交接創建自然的審計邊界：

[研究者完成] → 交接 → [想法產生器開始]
[想法產生器完成] → 交接 → [寫手開始]
[寫手完成] → 交接 → [事實查核開始]
[事實查核：發現 3 個問題] → 交接 → [寫手重新開始並附回饋]

每個轉換都是檢查點。交接時的日誌準確顯示出錯的位置以及當時可用的上下文。

4. 可組合性與重用

在單代理架構中，你無法輕易提取並在不同上下文中重用「好的研究提示」。它埋藏在特定對話中。

多代理架構使代理成為建構區塊：

# 研究工作流程
研究者 → 分析者 → 報告者

# 內容工作流程
研究者 → 想法產生器 → 寫手

# 程式碼工作流程
程式碼閱讀器 → 架構師 → 程式碼產生器

研究者 代理可跨工作流程重用。改進其提示一次，所有工作流程受益。

5. 靈活編排

不同任務需要不同的代理序列：

低風險內容：自動發送通過整個管道

研究（自動）→ 想法（自動）→ 寫作（自動）→ 發布

高風險程式碼：關鍵點的人工關卡

研究（自動）→ 設計（HITL）→ 程式碼（自動）→ 安全審查（HITL）→ 部署

迭代改進：循環直到達到品質閾值

產生 → 測試 → （通過？退出：附回饋產生）

單一代理無法優雅地處理這些變化。具可配置交接的多代理系統可以。

何時使用多代理 vs. 單代理

這種模式並非總是正確選擇。這裡有個決策框架：

單代理足夠

使用單代理當：

• 簡單、單步驟任務：「解釋這個錯誤訊息」
• 低風險：錯誤答案後果最小
• 快速迭代：重新提示比建構工作流程更快
• 探索性：你還在摸索需要什麼

多代理更好

使用多個代理當：

• 複雜工作流程：具不同關注點的多個明確步驟
• 需要角色分離：研究不應編輯，編輯者不應部署
• 安全需求：需要工具限制或批准關卡
• 可重用性：相同代理在多個工作流程中有用
• 團隊使用：多人使用相同模式
• 可審計性：需要清楚的決策與轉換記錄

決策矩陣

多代理系統的設計原則

如果你正在建構多代理系統，遵循這些原則：

1. 最小權限原則

給每個代理其角色所需的最小工具：

# ❌ 不好：太多工具
researcher:
  tools: ['fetch', 'search', 'edit', 'runCommands', 'deploy']

# ✅ 好：只有所需的
researcher:
  tools: ['fetch', 'search']

2. 明確轉換

絕不允許隱式代理切換。每個轉換應該：

• 可見：使用者看到交接發生
• 記錄：代理變更的審計追蹤
• 可控：使用者可以批准/拒絕/修改

# ❌ 不好：隱藏代理切換
agent-a:
  instructions: "如果你需要程式碼，直接呼叫 code-writer 代理"

# ✅ 好：明確交接
agent-a:
  handoffs:
    - agent: code-writer
      label: "產生程式碼"

3. 預設人在回路

從 send: false（需人工批准）開始。只在以下情況後移至 send: true（自動提交）：

• 工作流程經證實穩定
• 風險明顯低
• 存在回滾機制

這是安全優先方法：在證明安全後選擇自動化，不要在事件發生後選擇退出安全。

4. 證據優於產物

設計代理產生決策就緒摘要，而非僅原始輸出：

# ❌ 不好：原始輸出

這裡是 47 頁的研究報告...

# ✅ 好：證據包

## 研究摘要

- **關鍵發現**：模式 X 在 3/3 實作中出現
- **信心**：高（主要來源，多重確認）
- **缺口**：大規模性能的有限資料
- **建議**：進行試點，監控指標
- **來源**：[1] VSCode 文件，[2] AutoGen 論文，[3] 企業案例研究

5. 可組合性

將代理設計為獨立、可重用單元：

# ❌ 不好：緊密耦合
blog-researcher-for-technical-posts:
  instructions: "研究技術主題的部落格文章..."

# ✅ 好：通用且可重用
researcher:
  instructions: "徹底研究任何主題..."
# 在多個上下文中使用：
# - 部落格工作流程：researcher → blog-writer
# - 文件工作流程：researcher → doc-writer
# - 規劃工作流程：researcher → strategist

實作模式

實作多代理模式的三種常見方法：

模式 1：基於檔案（VSCode 風格）

最適合：開發者工具、團隊工作流程、版本控制配置

.github/agents/
├── researcher.agent.md
├── writer.agent.md
└── reviewer.agent.md

優點：

• Git 版本控制
• 非技術使用者可編輯
• 簡單發現（檔案系統）
• 無執行時相依

缺點：

• 較不動態
• 需要檔案系統存取
• 限於靜態配置

模式 2：基於程式碼（AutoGen 風格）

最適合：生產系統、複雜邏輯、程式化控制

def create_research_workflow(topic: str):
    researcher = Agent(
        name="researcher",
        system_message=f"研究 {topic}...",
        tools=[fetch_tool, search_tool]
    )

    analyzer = Agent(
        name="analyzer",
        system_message="分析研究...",
        tools=[analysis_tool]
    )

    return Sequential([researcher, analyzer])

優點：

• 完全動態
• 程式化控制
• 易於測試
• 豐富生態系統（Python/JS 函式庫）

缺點：

• 需要編碼技能
• 部署複雜性
• 對非開發者較困難

模式 3：基於服務（企業）

最適合：多租戶系統、集中治理、熱重載

POST /api/workflows
{
  "workflow_id": "research-pipeline",
  "agents": [
    {
      "id": "researcher",
      "instructions": "...",
      "tools": ["fetch", "search"],
      "handoffs": [{"target": "analyzer"}]
    }
  ]
}

優點：

• 語言無關
• 無需重啟的熱重載
• 集中管理
• 多租戶隔離

缺點：

• 基礎設施開銷
• 網路延遲
• 營運複雜性

未來：標準模式浮現

VSCode、AutoGen 和企業 SDLC 之間的收斂並非偶然。我們正見證 AI 編排標準模式的出現，類似於 REST API、微服務和事件驅動架構如何成為傳統軟體的標準模式。

新興標準

1. AGENTS.md：統一指令格式（Google、OpenAI、Sourcegraph 和 20+ 工具支持）
2. 交接協定：具人工關卡的明確轉換機制
3. 工具限制模型：基於權限的代理能力
4. 基於證據的 HITL：審查摘要，非完整產物
5. 風險評分路由：自動化低風險，人工高風險

接下來會發生什麼

1. 學習型交接：基於任務特徵決定最佳代理轉換的 ML 模型
2. 動態代理綜合：為新任務按需產生專門代理的系統
3. 跨組織工作流程：跨公司邊界的聯邦代理網路，具驗證交接
4. 可驗證審計追蹤：代理動作和人類批准的區塊鏈或密碼學證明
5. 自然語言編排：「為我建構一個代理工作流程來分析客戶回饋並產生產品洞察」

開始使用

準備應用多代理模式？從這裡開始：

第一週：繪製你的工作流程

1. 列出你要求 AI 做的明確任務
2. 按相似性分組（研究、寫作、審查、分析等）
3. 識別每組的工具需求
4. 注意哪些步驟需要人工監督

第二週：建構第一個代理對

1. 選擇最高價值工作流程（例如程式碼審查）
2. 創建兩個代理：分析者 → 建議者
3. 配置它們之間的交接
4. 用實際任務測試
5. 蒐集回饋

第三週：擴展與改進

1. 新增互補代理（例如安全審查者）
2. 根據輸出品質調整指令
3. 如果過於限制/寬鬆，調整工具權限
4. 記錄有效的模式

第四週：測量與迭代

追蹤指標：

• 品質：交接時的人工批准率
• 效率：相比手動方法節省的時間
• 安全：工具限制防止的事件
• 採用：團隊使用頻率

使用資料來：

• 識別哪些代理需要改進
• 決定哪些交接可以自動化（send: true）
• 找出缺失的代理（工作流程中的缺口）
• 優化代理指令

結論

多代理交接模式不再是實驗性的——它正成為可靠、可擴展 AI 系統的標準架構。從 VSCode 對開發者友善的自訂代理到 AutoGen 的企業級框架，再到實際的 Agentic SDLC 部署，相同的原則浮現：

• 圍繞清楚的責任專門化代理
• 限制工具以匹配每個角色
• 透過結構化交接使轉換明確
• 在關鍵決策點新增人工關卡
• 審查證據，非完整產物

這不是萬靈丹。簡單任務仍然用單代理就好。但對於需要安全、可審計性和團隊協作的複雜工作流程，多代理模式提供了經證實的前進道路。

從小開始。建構兩個代理與一個交接。學習在你的情境中什麼有效。然後系統化擴展。多個團隊的收斂演化表明你不是在實驗——你正在採用一個新興標準。

AI 輔助工作的未來不是單一超級智慧代理。而是專門化代理協同工作，人類在決策關卡審查證據。那個未來已經到來。模式已經證實。是時候實作它了。

**你正在建構什麼多代理工作流程？**在評論中分享你的經驗或在 Twitter/X 上聯繫我。我特別對內容創作和程式碼審查之外的新應用感興趣——你如何在你的領域應用這種模式？