谷歌为Gemini API托管代理推出后台任务、远程MCP等新功能

传统方式有多脆弱？

　　对抗长任务的第一种反方经验是让客户端死扛连接。比如用SSE或WebSocket维持一个HTTP连接，等任务跑完再返回结果。问题是网络波动、客户端休眠、服务端超时，任何一个都能让连接断开。一旦断开，任务进度就没了，开发者还得额外写一套重试和状态恢复逻辑。

　　如果任务需要访问内网数据库或内部API，更常见的做法是自己搭一层代理中间件。代理接收代理发来的请求，做鉴权后转发到内部服务，再原路返回。这套模式运维成本高，每接入一个新数据源就得修改中间件，且安全边界很模糊——代理本质上是把内网访问权限交给了外部调用方。

　　凭据过期也是长期运行代理的经典翻车点。OAuth token、短时效API密钥一过期，代理就会变成“断联工人”，除非手动重启整个会话，否则无法继续访问依赖外部服务的工具。而重启往往意味着丢失沙箱里的文件系统状态和已安装的依赖，相当于每次过期都要从零开始搭环境。

托管代理的解法：把脆弱点扔给服务端

　　新引入的后台执行直接打破了“必须保持连接”的假设。开发者在调用交互时只需传入background: true，API会立刻返回一个会话ID，整个交互在服务端异步运行。客户端可以用这个ID主动轮询状态变化、流式获取进度，或者在几小时后再重新连接。连接断了又如何？任务在服务端安稳跑着，沙箱状态不会丢。这种设计把代理从“同步请求-响应”模式彻底切换成了“提交任务-异步查询”模式。

　　远程MCP服务器集成则直接干掉了代理中间件的理由。以前连接内部服务要自己写代理，现在你可以把一个远程MCP服务器作为工具直接注册给托管代理，和内置的Google搜索、代码执行工具并列使用。代理在沙箱内发起调用时，工具流量会通过标准MCP协议直达你指定的端点。安全边界清晰了——访问权限仍然由MCP服务器控制，而不是暴露在中间件配置里。

　　有意思的是工具混用机制。你可以同时传入一个远程MCP工具、一个代码执行工具和一个自定义本地函数。API使用步骤匹配来决定由谁执行：内置的沙箱工具自动在服务端跑，自定义函数则会把交互状态切换为requires_action，把执行权交还给客户端。也就是说，代理可以根据任务进度灵活切换执行位置，而不需要开发者硬编码复杂的路由逻辑。

　　凭据刷新同样处理得干净。当访问令牌或API密钥即将过期，你不需要销毁原来的环境。只要在下一次交互调用时，沿用之前的environment_id并传入一套新的网络配置（比如更新后的认证头或密钥），旧的规则会被立刻替换。沙箱里的文件系统、已安装的包、克隆的仓库，全都原样保留。这相当于让代理获得了“无缝换令牌”的能力，长期运行的门槛大幅降低。

这些更新改变了什么？

　　表面上看，这是四个技术特性的加法。但放在一起看，它们改变了托管代理的定位：从一个需要你时刻盯着的“同步执行器”变成一个可以在背后默默干活的“异步工人”。过去代理更像是开发者的影子，离开连接就消失；现在它有了自己的独立运行空间，任务的启动、暂停、恢复、凭据轮换都可以发生在开发者并不在线的时间里。

　　对于已经用上AI编码代理的团队，这组更新带来了一个很具体的操作变化。如果你让AI编码代理帮你在Gemini Interactions API上构建功能，可以直接让它安装官方技能包：npx skills add google-gemini/gemini-skills --skill gemini-interactions-api。换句话说，产品团队不但提供了API，还为AI代理准备了可被机器消费的技能定义，这本身就折射出他们对“代理构建代理”这个链路的重视。

　　从开发者反馈的角度看，这次更新没有去发明什么新概念，而是在解决已经存在的摩擦。长时间的代码执行需要后台化，内部服务集成需要去中间件化，凭据过期需要无感化——每一项都对应着生产环境里真实踩过的坑。比起继续堆砌模型能力，这种“把代理运行环境做扎实”的路线反而更稀缺。

　　当然，全托管带来的控制权让渡问题依然存在。后台执行意味着你无法像同步模式那样立即中断一个跑偏的任务，只能通过API去查询和终止；远程MCP连接虽然减少了中间件，但也要求你信任沙箱内的工具调用逻辑不会触发非预期的数据访问。这些新的信任边界，会是下一阶段开发者讨论的焦点。

　　想马上动手的话，文档里已经提供了JavaScript SDK的例子（@google/genai），Python和cURL用户可以查阅Antigravity代理文档。快速入门指南会带你走过自定义代理定义、环境配置、网络规则和高级流式模式。无论你属于“先用再想”的行动派还是“看明白再动手”的谨慎派，这套工具的多层抽象都给出了足够灵活的入口。