Gemini API Managed Agents 更新：后台任务和远程 MCP 让 Agent 不再卡死长连接

一句话结论

Google AI 官方博客今天发布了 Gemini API Managed Agents 的能力扩展：Managed Agents 开始支持后台执行、远程 MCP 连接、自定义函数和凭据刷新等能力。

公开来源：Google AI 官方博客《Expanding Managed Agents in Gemini API: background tasks, remote MCP and more》
来源 URL：https://blog.google/innovation-and-ai/technology/developers-tools/expanding-managed-agents-gemini-api/

这条新闻值得关注，不是因为“又多了一个 Agent 名词”，而是因为它击中了 Agent 工程化里的一个老问题：Agent 任务越来越长、工具越来越多、状态越来越复杂，但很多应用仍然把它当成一次普通 HTTP 请求来处理。

短问答可以同步返回。真正的 Agent 工作流不行。

当一个 Agent 需要查资料、跑代码、访问内部工具、等待外部系统、生成报告时，它可能跑几十秒、几分钟，甚至更久。如果前端或业务服务一直傻等同一个连接，体验和稳定性都会很糟。

所以这次更新的关键词不是“更会聊天”，而是“更像一个后台工人”。

问题现象：为什么 Agent 一跑长任务就容易翻车？

很多团队第一次接入 Agent 时，架构大概长这样：

1
2
3
4
5
6
7
8
9

用户点击按钮
  ↓
业务服务发起一次 HTTP 请求
  ↓
模型或 Agent 开始处理
  ↓
业务服务等待结果
  ↓
把结果返回给用户

这个流程对普通聊天没问题。

但 Agent 不是普通聊天。它可能要拆任务、调用工具、读取资料、执行代码、重试失败步骤，还要在中间不断更新进度。于是问题就来了：

1. 连接容易超时：网关、浏览器、负载均衡、业务服务都可能设置超时时间。
2. 用户体验差：页面一直转圈，用户不知道是还在跑，还是已经挂了。
3. 恢复能力弱：用户刷新页面、网络断开、服务重启后，任务状态很难接回来。
4. 资源占用高：大量长连接堆在业务服务上，会拖慢其他请求。
5. 工具接入麻烦：Agent 想访问外部系统时，开发者往往要自己写代理层、鉴权层和安全隔离。

换成生活里的比喻：你让同事帮你办一件复杂的事，却要求他全程举着电话不能挂断，办完才能说话。对方去复印、盖章、排队、找人签字，你这边电话一直占线。稍微走到信号差的地方，整件事就断了。

更合理的方式应该是：同事先给你一个工单号，然后自己去跑流程；你可以随时查进度，也可以稍后回来继续看结果。

这就是后台任务的价值。

官方更新重点：后台执行、远程 MCP、自定义函数、凭据刷新

根据官方博客，这次 Gemini API Managed Agents 主要补强了几类生产化能力。

后台执行：长任务不再绑死 HTTP 连接

官方提到，长时间保持 HTTP 连接是脆弱的。新的后台执行能力允许开发者把交互作为异步任务提交到服务器端运行。API 会先返回一个 ID，应用可以用这个 ID 轮询状态、流式读取进度，或者稍后重新连接。

这意味着开发者可以把 Agent 当作“远程后台 worker”，而不是“必须立刻返回的同步函数”。

典型流程可以变成：

1

提交任务 → 获得任务 ID → 前端显示进度 → 断线可重连 → 完成后读取结果

这对报告生成、代码分析、数据整理、批量排查这类任务非常关键。

远程 MCP：把工具连接标准化

MCP，也就是 Model Context Protocol，近一年已经成为 Agent 工具连接领域的重要协议之一。它的价值在于把“模型怎么调用外部工具”这件事标准化。

这次更新里，Managed Agents 可以连接远程 MCP 服务。开发者不必为每个私有数据库、内部接口或业务系统单独写一套临时代理，而是可以把工具通过 MCP 方式暴露给 Agent。

更重要的是，官方强调这些远程工具可以和内置沙箱能力一起使用，比如搜索、代码执行等。这说明 Managed Agents 正在从“模型接口”变成“可组合的执行环境”。

自定义函数和凭据刷新：从 Demo 走向生产

很多 Agent Demo 在演示时很丝滑，一到生产环境就卡在两个问题上：

• 工具不够灵活，需要业务自定义函数；
• 凭据会过期，需要安全地刷新和续期。

自定义函数解决的是“能不能接入业务动作”的问题，凭据刷新解决的是“能不能长期稳定运行”的问题。

如果没有凭据刷新，Agent 跑一半发现 token 过期，体验就很尴尬。就像外卖骑手已经到小区门口了，门禁二维码却失效了，只能重新联系你开门。

解决方案：把 Agent 长任务改成异步工单模型

这条新闻给普通开发者最直接的启发是：不要再把复杂 Agent 工作流强行塞进同步请求里。

推荐的工程模型如下。

一键架构模板

1
2
3
4
5
6
7
8
9

前端/调用方
  ↓ 提交任务
业务 API 层
  ↓ 创建 task_id，记录用户、参数、状态
Agent Runtime / Managed Agents
  ↓ 后台执行，持续写入事件流
状态存储 / 事件存储
  ↓
前端轮询、SSE、WebSocket 或重新连接读取进度

如果使用支持后台任务的 Managed Agents，业务侧可以少维护一部分 worker 逻辑，但仍然建议保留自己的任务表。原因很简单：用户权限、业务参数、审计日志、配额限制、失败重试策略，通常还是业务系统自己最清楚。

伪代码示例

下面是一个不绑定具体 SDK 的伪代码，核心思想是“提交即返回，结果稍后取”：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

# 1. 提交 Agent 任务
job = managed_agent.interactions.create(
    agent_id="agent_xxx",
    mode="background",
    input={
        "task": "分析这批日志并给出修复建议",
        "files": ["sanitized-log-1.txt", "sanitized-log-2.txt"],
    },
    tools=[
        {"type": "remote_mcp", "server": "mcp-tools"},
        {"type": "code_execution"},
    ],
)

# 2. 立即把任务 ID 返回给前端
return {"task_id": job.id, "status": "running"}

# 3. 前端或后端稍后查询状态
status = managed_agent.interactions.get(job.id)

# 4. 完成后读取结果
if status.state == "completed":
    result = managed_agent.interactions.result(job.id)

真实接入时还要补上鉴权、输入校验、敏感信息脱敏、超时策略和审计日志，但模型本身就是这么简单。

排查过程：如果你的 Agent 长任务经常失败，先看这几项

如果你已经在做 Agent 应用，并且遇到“跑久一点就失败”的问题，可以按下面顺序排查。

检查一：是不是同步连接超时

现象通常是：任务本身可能还在跑，但调用方已经报超时。排查重点包括：

1
2
3
4

# 检查反向代理超时时间
# 检查业务服务 HTTP client timeout
# 检查前端请求超时时间
# 检查平台网关的最长请求限制

如果任何一层超时时间小于 Agent 平均执行时间，就应该改成异步模式。

检查二：有没有任务状态表

没有状态表的 Agent 系统，很难做恢复。

最少也应该保存：

1
2
3
4
5
6
7
8

task_id
user_id
status: queued/running/succeeded/failed/cancelled
created_at
updated_at
input_digest
result_location
error_message

注意不要把完整敏感输入直接塞进日志或数据库。能存摘要就存摘要，需要留原文时也要做权限控制和过期清理。

检查三：工具调用是否标准化

如果每接一个工具都要写一套临时代码，后期维护会很痛苦。可以考虑 MCP 这类协议，把工具描述、参数、返回值和权限边界统一起来。

检查四：凭据是否会过期

很多问题不是模型能力不够，而是工具凭据半路失效。

建议为 Agent 工具调用设计单独的凭据生命周期：

• 短期 token 用于具体任务；
• 长期密钥不要直接暴露给模型；
• 过期前可刷新；
• 刷新失败要能暂停任务并给出明确错误。

Q&A

Q1：后台任务是不是一定比同步请求好？

不是。短问答、简单分类、快速摘要继续同步就可以。后台任务适合执行时间不稳定、需要工具调用、可能断线重连、需要进度展示的场景。

Q2：有了 Managed Agents，还需要自己写任务系统吗？

通常仍然需要一层轻量任务系统。Managed Agents 负责执行，业务系统负责用户、权限、审计、配额、计费和结果展示。两者分工不同。

Q3：远程 MCP 会不会带来安全风险？

会，所以要做边界控制。MCP 服务不应该把所有内部能力无脑暴露给 Agent。建议按最小权限原则拆分工具，并对高风险动作增加审批或二次确认。

Q4：凭据刷新为什么重要？

因为生产任务可能跑很久，也可能调用多个外部系统。如果凭据过期后不能恢复，Agent 就会在中途失败。凭据刷新本质上是在给长任务补“续航能力”。

Q5：这次更新对国内开发者有什么参考价值？

即使暂时不使用 Gemini API，这条更新也说明了一个趋势：Agent 平台正在从“模型调用”走向“任务执行平台”。后台执行、工具协议、沙箱、凭据管理、进度恢复，会成为 Agent 工程化的基础设施。

总结

这次 Gemini API Managed Agents 更新的重点，不是让模型回答得更漂亮，而是让 Agent 更像一个可靠的工程组件。

对于开发者来说，最值得带走的实践是：

1. 长任务不要绑死同步 HTTP 连接；
2. 用任务 ID、状态表和事件流管理执行过程；
3. 用 MCP 这类协议标准化工具连接；
4. 凭据刷新和最小权限要尽早设计；
5. 把 Agent 当后台工人，而不是聊天窗口里的“聪明输入框”。

今天我在本机也正好处理了一个自动化流程迁移的小问题：任务本身不复杂，但只要涉及定时、日志、发布顺序和失败重试，就必须把流程设计得更像后台工单，而不是一次性脚本。

AI 应用越往生产走，越会回到这些朴素问题：能不能恢复、能不能追踪、能不能安全地连工具、能不能在失败时给出清楚原因。

这才是 Agent 真正从 Demo 走向日常工作的分水岭。

作者：小六，一个在上海努力生存的普通打工人