Gemini API 的 Managed Agents 更新：背景任務與遠端 MCP 的實務意義

摘要： Google 在 2026 年 7 月 7 日為 Gemini API 的 Managed Agents 加入背景任務與遠端 MCP 支援，讓 agent 從同步問答轉向可在伺服器端持續執行的 worker。同一批更新還有自訂函式呼叫；文中提醒執行上限、認證與監控細節仍需開發者自行補齊。

Google 在 2026 年 7 月 7 日替 Gemini API 旗下的 Managed Agents 增添了一批新能力，重心落在兩處：背景任務（background tasks），以及遠端 MCP（Model Context Protocol）支援。對要把 agent 納入自家產品的人來說，這波改動不能只當成功能清單多了兩個項目——它其實是基礎架構層級的一次挪移：agent 的角色不再是單純回答問題的工具，而是能夠長時間運轉、橫跨不同系統執行任務的單元。

背景任務：把 agent 從同步等待中解放出來

過去透過 Gemini API 叫用 agent，流程多半是同步的一來一往：請求送出後得一直等到回應傳回，互動才算結束。但真實產品裡有大量工作根本不可能在幾秒內收尾——文件批次處理、網站爬取、報表產出全是典型。這次新增的背景任務把執行過程移到伺服器端、以非同步方式進行，開發者不必再為了等結果而掛著一條連線不放。

站在產品建構者的立場，agent 從此可以照「非同步 worker」的思路來設計。譬如使用者上傳一份合約，系統隨即在背景開任務去分析條款，完成後才通知使用者。這一步改寫了 agent 的互動模型，架構樣貌也越來越像傳統的 job queue。不過新機制伴隨新的課題：任務生命週期怎麼管理、錯誤怎麼處理、結果又要用什麼方式交回使用者手上，都得自行規劃。文件雖指出這類任務的狀態可透過 API 查詢，至於輪詢或 webhook 的具體機制，官方部落格並未多作說明。

官方部落格以 @google/genai JavaScript SDK 寫了一份精簡示範：建立 interaction 的當下傳入 background: true，API 隨即回傳一組 ID，之後就靠 client.interactions.get() 反覆追蹤進度：

import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({});

// 1. Start a long-running analysis in the background
const interaction = await client.interactions.create({
  agent: "antigravity-preview-05-2026",
  input: "Clone https://github.com/googleapis/js-genai, find all TODO comments in the source code, and categorize them by module and priority in a markdown report.",
  environment: "remote",
  background: true,
});

console.log(`Background task started. Interaction ID: ${interaction.id}`);

// 2. Poll asynchronously without blocking an open HTTP socket
let result = interaction;
while (result.status === "in_progress") {
  await new Promise((resolve) => setTimeout(resolve, 5000));
  result = await client.interactions.get(interaction.id);
}

if (result.status === "completed") {
  console.log("Task Completed:\n", result.output_text);
} else {
  console.error(`Task ended with status: ${result.status}`);
}

遠端 MCP：agent 的工具連線向外延伸

談到 agent 與外部工具的銜接，MCP 已然是主流協定，但過往的應用多半困在本地或同一個環境裡。Google 這回補上的遠端 MCP 支援，使 agent 能夠透過網路連往其他伺服器上的 MCP 工具。企業場景受惠最深，畢竟企業的工具往往分屬不同部門、各種雲端環境。

放進實務來看，內部 CRM、資料庫或第三方服務都能包裝成 MCP server 交給 Gemini agent 取用，所有邏輯再也不必硬塞進同一份程式碼庫。只不過公告雖然寫明「remote MCP」，認證與安全相關的著墨卻相當少。對準備上線的產品來說，這塊空缺正好得靠自己補齊：遠端連線的授權怎麼設計、流量怎麼加密、prompt injection 怎麼防範，都該在規劃 agent 時一併想清楚。

官方部落格的示範，是建立 interaction 的同時附上 mcp_server 工具，讓 agent 留在安全沙盒裡向內部 observability server 查詢，接著把延遲尖峰與 git commits 拿來交叉比對：

import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({});

const interaction = await client.interactions.create({
  agent: "antigravity-preview-05-2026",
  input: "Check our internal observability server for recent latency spikes in the auth service and correlate them with git commits.",
  environment: "remote",
  tools: [
    { type: "google_search" },
    { type: "code_execution" },
    {
      type: "mcp_server",
      name: "internal_telemetry",
      url: "https://mcp.internal.example.com/mcp",
    },
  ],
});

console.log(interaction.output_text);

同一批更新裡還有自訂函式呼叫（custom function calling）：內建的沙盒工具全權交給伺服器端自動跑完，自訂函式則會令 interaction 進入 requires_action 狀態，此時就輪到你的客戶端出手，執行本地端的商業邏輯。官方部落格用 get_weather 函式示範這條流程：

import { GoogleGenAI } from "@google/genai";

const client = new GoogleGenAI({});

// 1. Define a custom domain function
const getWeatherTool = {
  type: "function",
  name: "get_weather",
  description: "Gets the current weather for a given location.",
  parameters: {
    type: "object",
    properties: {
      location: {
        type: "string",
        description: "The city and country, e.g. San Francisco, USA",
      },
    },
    required: ["location"],
  },
};

// 2. Invoke the agent with both built-in code execution and custom functions
const interaction = await client.interactions.create({
  agent: "antigravity-preview-05-2026",
  input: "Check the weather in Tokyo, write a Python script to convert the temperature to Fahrenheit, and save the result to weather.txt.",
  environment: "remote",
  tools: [
    { type: "code_execution" },
    getWeatherTool,
  ],
});

// 3. Handle custom function execution cleanly
if (interaction.status === "requires_action") {
  // Filesystem and sandbox tools execute automatically and produce a result
}

這對產品架構意味著什麼

兩項更新放在一起解讀，Google 的盤算一目了然：agent 要脫離「單次對話」的型態，朝「持續運轉的服務」靠攏。對產品建構者而言，衝擊集中在三個層面：

把非同步當成設計預設：agent 只要得處理長時任務，使用者體驗就必須整個重想。與其叫使用者枯等，不如讓他們先收到「任務已受理」的確認，完成後再接獲通知。
工具串接走向標準化：遠端 MCP 讓工具整合變得更模組化，但連線設定與權限的管理也得跟著收緊。
監控與除錯的擔子更重：背景任務疊上遠端連線，系統複雜度跟著上升。logging 與追蹤機制若不夠完整，agent 實際上做了什麼，你將無從掌握。

這波改動的重量，不在於「多了幾個功能可以呼叫」，而在 agent 的基礎建設整體日趨成熟。對開發者來說，好消息是相關能力已經直接做進 Gemini API，排程器與連線層不必自己從零搭起；壞消息則是抽象層愈墊愈高，底層行為愈難看穿，除錯時對平台工具的依賴也跟著加深。

目前還缺什麼，以及建議的走法

公告指出了大方向，細節卻留了不少空白：背景任務最長能跑多久、並發上限訂在哪裡、遠端 MCP 用哪種認證方式，官方部落格一概沒提。如果已經決定導入，穩當的做法是先把 API 文件從頭到尾讀一遍，接著做小規模的概念驗證探探路，安全性與可靠性務必列為優先檢驗項目。

還在挑選 agent 平台的團隊，會發現這波更新讓 Gemini API 的候選份量更足；但能不能做出成果，關鍵仍在 agent 的任務流程與錯誤處理設計得夠不夠周全。工具本身只是原料，產品真正的價值，來自它替使用者解掉了哪些問題。

資料來源

Expanding Managed Agents in Gemini API: background tasks, remote MCP and more