偉龍blog

從多 Agent 協作開始:用角色分工打造會團隊作戰的 AI 應用實戰指南

—

由

Edwin
于

上一篇〈從 AI Agent 開始〉我們讓大模型透過 Function Calling 學會了「動手做事」:一個 Agent、一個迴圈、幾個工具,就能把任務拆解執行。但當你真的把這套架構搬進專案,很快就會撞到牆——工具越加越多,模型開始選錯;System Prompt 越寫越長,行為越來越難預測;一個 Agent 又當分析師又當寫手,上下文塞爆後表現直線下滑。

這就像公司只有一個「全能員工」:接電話、寫程式、掃地、報稅全都來。任務一雜,效率和品質都崩盤。真正的解法不是繼續壓榨這位員工,而是組一個團隊——這就是今天的主題:多 Agent 協作(Multi-Agent)。這也是「大模型應用」系列的第四課。

一、為什麼單 Agent 會不夠用

  • 工具選擇熵增:可選工具超過十幾個後,模型選對工具的機率明顯下降——就像菜單厚到像字典,點菜反而更慢。
  • 上下文汙染:所有歷史對話、工具回傳結果都堆在同一個視窗裡,雜訊會擠掉真正重要的指令。
  • 職責衝突:一個 Prompt 同時要求「嚴謹求證」和「活潑文案」,兩種人格互相打架,輸出品質不穩。

重點:多 Agent 的本質不是「更多模型」,而是用分工換取每個 Agent 的簡單與可靠。

二、三種常見編排模式

  • Planner–Executor(主管派工):一個「主管 Agent」負責理解需求、拆解任務、分派給專家 Agent,再彙整結果。結構清晰,最適合入門。
  • Handoff 流水線(接力棒):Agent A 做完把上下文交給 Agent B,像客服轉接專線。適合流程固定的場景(先檢索、後撰寫、再審校)。
  • 群聊黑板(共用上下文):多個 Agent 圍繞同一份共用狀態各自發言、互相修正。最靈活,但成本與除錯難度最高。

特別注意:入門階段建議從 Planner–Executor 開始,而且把編排邏輯寫在程式碼裡,而不是交給模型自由發揮——可控性是生產環境的第一優先。

三、實戰:最小可用的 Planner–Executor

我們用 TypeScript 實作一個最小多 Agent 系統:一個「路由主管」加兩個專家(天氣 Agent、數學 Agent)。沿用上一篇的 Function Calling 寫法,只需要多一層分發。

步驟 1:定義專家 Agent——每個專家 = 專屬 System Prompt + 專屬工具

type Agent = {
  name: string;
  systemPrompt: string;
  tools: Tool[];          // 只掛這個專家需要的工具
  run: (input: string) => Promise<string>;
};

const weatherAgent: Agent = {
  name: "weather",
  systemPrompt: "你只負責天氣查詢,回答簡短。",
  tools: [getWeatherTool],
  run: (input) => agentLoop(weatherAgent, input),
};

const mathAgent: Agent = {
  name: "math",
  systemPrompt: "你只負責數學計算,先列式再計算。",
  tools: [calculatorTool],
  run: (input) => agentLoop(mathAgent, input),
};

步驟 2:實作主管路由——主管只有一個工具:決定轉交給哪位專家

const routerAgent = {
  systemPrompt: `你是任務主管。根據使用者需求,呼叫 assignAgent
    把任務轉交給合適的專家。可用專家:weather(天氣)、math(數學)。
    收到專家結果後,用一句話總結給使用者。`,
  tools: [{
    name: "assignAgent",
    parameters: { agent: "weather | math", task: "string" },
  }],
};

async function execute(task: string): Promise<string> {
  const decision = await llm.chat(routerAgent, task);
  if (decision.tool !== "assignAgent") return decision.text;

  const expert = agents[decision.args.agent];   // 程式碼分發,不靠模型自由發揮
  const result = await expert.run(decision.args.task);
  return llm.chat(routerAgent, `專家回覆:${result}`);
}

步驟 3:跑通迴圈並驗證邊界

用三個案例測試:「東京明天會下雨嗎」應路由到 weather;「17% 的 234 是多少」應路由到 math;「幫我寫一首詩」兩個專家都不合適,主管應該直接婉拒而不是硬派工。

重點:一定要替「沒有合適專家」的情況設計出口,否則主管會亂點鴛鴦譜。

四、多 Agent 的三條紀律

  • 工具最小權限:每個專家只掛必要的工具,天氣 Agent 不該摸到計算機。
  • 上下文隔離:專家之間只傳遞「任務與結果」,不共用完整對話史,避免雜訊跨 Agent 擴散。
  • 成本看板:Agent 數量 × 迴圈深度會讓 Token 消耗乘方級放大,務必記錄每次呼叫的用量並設定上限。

「大模型應用」系列到這裡集滿四塊拼圖:接模型(LLM API)、餵知識(RAG)、給工具(AI Agent)、組團隊(本篇)。下次不妨把這套架構接上自己的業務——先從「一個主管 + 兩個專家」開始,跑通了再加人。

互動話題:你最想讓哪兩個「AI 專家」組隊幫你幹活?是「程式碼審查員 + 修復工程師」,還是「資料分析師 + 圖表產生器」?留言聊聊你的夢幻團隊!