Gemini Managed Agents 多代理系統實戰與治理

📌 本文重點

Managed Agents 讓多代理 workflow 更可控可審計

背景任務與長流程能安全持續運行

remote MCP + 沙盒工具提升協作與安全

憑證輪替支援零信任長連線場景

Gemini Managed Agents 的最新更新，直接解決了多代理系統在實務上的四個痛點：長流程容易中斷、背景任務難管理、多代理協作缺乏控制平面、工具執行缺乏安全邊界、長連線憑證管理容易出事。如果你目前只是在做「單模型聊天 + 幾個工具」，這批能力讓你可以往「有審計、有重試、有觀測性」的多代理 workflow 進化，而且不需要自己再搭一層任務編排框架。

重點說明

1. 背景任務與長流程編排：從同步聊天到任務隊列

新的 Managed Agents 支援在代理內啟動 背景任務（background tasks），並維持任務狀態。

關鍵好處：

可以把耗時操作（例如 ETL、長時間 API 輪詢、批次報表）移到背景，不阻塞前端對話。
每個背景任務都有 狀態與 ID，便於你實作自家任務隊列、重試策略與恢復機制。
代理本身幫你維護「對話上下文 + 任務上下文」，你只需在外層規劃任務生命週期。

💡 關鍵： 把長流程變成有狀態、可重試的背景任務，是從「聊天玩具」升級成「可靠工作流系統」的關鍵一步。

典型設計：

前端對話 → 由主 Agent 判斷是否需要啟動背景任務。
使用 Agents API 建立 task，狀態儲存在 Managed Agents 內部或你自己的 DB。
外部有一個「任務監控 worker」定期查詢任務狀態、做重試或告警。

2. remote MCP / 多代理協作：控制平面 vs 應用層 SDK

Managed Agents 現在可以直接連到 remote MCP。實務上有兩種典型 architecture：

控制平面導向（Control Plane first）：
多個工具 / 子代理掛在 MCP server（例如一個 operations MCP、一個 data MCP）。
Managed Agent 只要知道 MCP endpoint，就能呼叫裡面的工具。
適合大型企業，把權限、審計、資源配額集中放在 MCP 層。
應用層 SDK 導向（SDK first）：
你在應用程式碼中透過 SDK 把工具包成 Gemini Tool / Functions，再掛到 Managed Agents。
權限管理偏向 app side，例如每個 tenant 對應一組工具設定。

關鍵差異在 權限與隔離：

控制平面模式：透過 MCP 做 RBAC、租戶隔離、審計；Managed Agent 像「智慧前端」。
SDK 模式：更靈活，適合快速迭代，但要自己補一套完整審計與 resource control。

3. 安全沙盒內整合自定義工具與函式

更新後的 Managed Agents 允許在 安全沙盒（sandbox） 同時使用：

官方 sandbox 工具（如瀏覽器、code executor）。
你自定義的 functions / tools。

好處：

你可以在受控環境內執行「可能有副作用」的操作，例如 DB query、檔案處理，而不直接暴露到外部系統。
工具執行與 LLM 推理同樣有 超時與資源配額 控制，避免單一任務吃光整個 pod。

設計重點：

每個工具要有明確的 作用範圍（只讀 / 可寫），把「刪除、修改」操作拆成獨立工具並 預設關閉。
在工具層做 輸入驗證與錯誤處理，避免 LLM 亂塞參數導致意外副作用。

4. 憑證刷新與長連線安全：token 旋轉 + 零信任

Managed Agents 支援在 不丟失 state 的情況下刷新憑證：

代理可以維持長流程（幾小時到幾天）的狀態，同時你的服務端可以定期輪替 API token、OIDC access token。
這讓零信任架構更好落地：
不再有「因為流程長，只好給超長效 token」的妥協。
可以要求所有外部呼叫都透過短效憑證 + 中央驗證服務。

💡 關鍵： 「長流程 + 短效憑證」的組合，讓零信任不再與實務需求衝突。

實作範例

以下用一個從「單模型聊天」升級成「有背景任務 + 多代理協作 + 審計」的簡化範例示意（以 Node.js 伺服器 + Gemini API 為例，為示意用虛擬碼）。

1. 建立核心 Managed Agent

import { AgentsClient } from "@google-ai/gemini";

const agents = new AgentsClient({
  projectId: process.env.GCP_PROJECT_ID,
  location: "global",
});

// 建立主 Agent：負責對話 + 任務編排
async function createMainAgent() {
  const [agent] = await agents.createAgent({
    parent: "projects/xxx/locations/global",
    agent: {
      displayName: "orchestrator-agent",
      model: "gemini-2.0-pro",
      // 掛上 MCP 與工具
      tools: [
        { mcpServer: { endpoint: process.env.MCP_OPS_URL } },
        { mcpServer: { endpoint: process.env.MCP_DATA_URL } },
        { functionDeclarations: [
          {
            name: "schedule_background_job",
            description: "Create a background task for long-running workflow",
            parameters: {
              type: "object",
              properties: {
                jobType: { type: "string" },
                payload: { type: "object" },
              },
              required: ["jobType", "payload"],
            },
          },
        ]},
      ],
      // 安全設定：限制可寫操作
      safetySettings: {
        allowWriteOps: false,
      },
    },
  });

  return agent.name; // 用來後續呼叫
}

重點：

用 AgentsClient.createAgent 建立主 Agent，掛上多個 MCP 伺服器 與自定義 function。
safetySettings 示意限制寫入操作，實務上可自訂更細。

2. 前端對話：從「單次聊天」變成可啟動背景任務

// 使用者傳入訊息，主 Agent 可能決定啟動背景任務
async function handleUserMessage(agentName: string, sessionId: string, text: string) {
  const [response] = await agents.generateMessage({
    name: agentName,
    // sessionId 用你自己的，方便日後審計與追蹤
    session: { id: sessionId },
    prompt: { text },
  });

  // 若 LLM 觸發工具呼叫，可能是 schedule_background_job
  if (response.toolCall) {
    const call = response.toolCall;
    if (call.name === "schedule_background_job") {
      const taskId = await createBackgroundTask(call.args);
      // 把 taskId 回寫到對話，讓使用者可以查詢
      return { reply: `已建立背景任務，ID: ${taskId}` };
    }
  }

  return { reply: response.outputText };
}

這裡用 generateMessage（或官方實際命名類似方法）示意：

你自己維護 sessionId，不要依賴傳輸層的 session 概念，以免遇到像 MCP 無狀態 變更就斷鏈。
工具呼叫觸發後，交給應用層建立背景任務。

3. 背景任務隊列與重試設計

// 簡化版任務建立
async function createBackgroundTask({ jobType, payload }) {
  const taskId = crypto.randomUUID();

  await db.tasks.insert({
    id: taskId,
    type: jobType,
    payload,
    status: "pending",
    retryCount: 0,
  });

  return taskId;
}

// 任務 worker：定期跑
async function taskWorkerLoop() {
  const tasks = await db.tasks.find({
    status: { $in: ["pending", "retry"] },
  }).limit(50);

  for (const task of tasks) {
    try {
      await runTask(task); // 實際呼叫 MCP 或其他工具
      await db.tasks.update(task.id, { status: "done" });
    } catch (err) {
      const nextRetry = task.retryCount + 1;
      if (nextRetry > 3) {
        await db.tasks.update(task.id, { status: "failed" });
      } else {
        await db.tasks.update(task.id, {
          status: "retry",
          retryCount: nextRetry,
        });
      }
    }
  }
}

重點：

背景任務管理放在你的應用層，但任務內容可以是對 Managed Agents / MCP 工具 的呼叫。
任務狀態與重試策略明確放在 DB，避免「背景任務孤兒進程」沒人管。

4. 憑證刷新與零信任示意

// 透過中介層取得短效 token，供 AgentsClient 使用
async function getAgentsClient() {
  const token = await authService.getRotatingToken(); // 有效期 15 分鐘
  return new AgentsClient({
    authToken: token,
    projectId: process.env.GCP_PROJECT_ID,
  });
}

// 每次呼叫都用最新 token
async function safeGenerateMessage(agentName, sessionId, text) {
  const client = await getAgentsClient();
  const [response] = await client.generateMessage({
    name: agentName,
    session: { id: sessionId },
    prompt: { text },
  });
  return response;
}

這種做法搭配 Managed Agents 的「不丟 state 憑證刷新」能力，可以在維持長流程的同時，讓底層 token 持續輪替。

建議與注意事項

1. 防止 Agent 自動刪庫型事故

所有「修改 / 刪除」類工具：
預設不掛到主 Agent，改掛到專門的「ops Agent」，再用人工或嚴格策略觸發。
在工具層做 白名單 / 黑名單 檢查，例如禁止 DROP TABLE、限制影響範圍。
所有高風險操作應要求：
二次確認（LLM 生成計畫 → 使用者或守門服務審核 → 才執行）。

2. 審計與回溯：不要把責任丟給 MCP

MCP 轉為 stateless 之後，如果你沒自己建立 trace id，就會遇到：

同一條資金轉帳流程，log 看起來是四個不相干的事件，無法證明「誰觸發了什麼」。

建議：

在應用層產生 correlationId / traceId，寫入：
所有 Agents API 呼叫
MCP 請求的 metadata
DB 任務表與 log 系統
在出事時可以把「對話 → Agent 決策 → MCP 工具呼叫 → DB 操作」串回一條 timeline。

3. 背景任務治理：避免孤兒進程與資源爆炸

每個任務必須有：
明確 status（pending / running / retry / failed / done）。
最大重試次數與 退避策略（exponential backoff）。
超時與最大執行時間限制。
週期性 job 清理：
清掉超過 SLA 的 pending 任務，標記為 timeout_failed。
對高失敗率任務發告警，不要無限重試打爆外部 API。

4. 多代理協作架構選型

團隊偏「平台 / SRE」：建議 控制平面模式，用 MCP 集中治理，Managed Agents 做業務邏輯。
團隊偏「產品 /快速迭代」：先用 SDK 模式，在 app 層掛工具，後續再逐步抽到 MCP。

5. Observability：為多代理 workflow 補上眼睛

最低限度：
每次 Agent 呼叫記錄：agentName、sessionId、traceId、使用工具列表、執行結果。
建議導入：
分散追蹤（如 OpenTelemetry），把 Agents / MCP / DB 統一進 tracing system。
守門 dashboard：顯示背景任務隊列狀態、失敗率、平均耗時。

結論：Gemini Managed Agents 的背景任務、remote MCP、安全沙盒工具與憑證刷新能力，讓你可以在現有專案裡自然從「單模型聊天」過渡到「可控、可審計的多代理 workflow」。核心心法是：把任務編排與審計留在應用層，讓 Managed Agents 專心做協作與自動化，並以零信任與資源治理觀點設計整體架構。

🚀 你現在可以做的事

在現有聊天應用中加入 sessionId、traceId 與簡單任務表，開始嘗試背景任務編排

盤點現有工具，決定哪些適合掛在 MCP、哪些用 SDK 模式直接掛到 Managed Agents

規劃短效 token 取得流程，實作一個中介層 authService.getRotatingToken() 來配合 Managed Agents 使用

用 Gemini Managed Agents 搭建可控多代理系統

重點說明

1. 背景任務與長流程編排：從同步聊天到任務隊列

2. remote MCP / 多代理協作：控制平面 vs 應用層 SDK

3. 安全沙盒內整合自定義工具與函式

4. 憑證刷新與長連線安全：token 旋轉 + 零信任

實作範例

1. 建立核心 Managed Agent

2. 前端對話：從「單次聊天」變成可啟動背景任務

3. 背景任務隊列與重試設計

4. 憑證刷新與零信任示意

建議與注意事項

1. 防止 Agent 自動刪庫型事故

2. 審計與回溯：不要把責任丟給 MCP

3. 背景任務治理：避免孤兒進程與資源爆炸

4. 多代理協作架構選型

5. Observability：為多代理 workflow 補上眼睛

留言

發佈留言 取消回覆

更多文章

Qwen3.8-Max 長任務實戰與部署攻略

用 loopx＋Cloudflare computer 組一支 AI 遠端團隊

用手機跑 128K AI 小助手：LFM2.5 實戰

Google 把手機交給 Gemini，是升級還是賭博？

發佈留言取消回覆