Google 把 Gemini API 里的 Managed Agents 往生产运行时推了一步。背景执行、远程 MCP、函数回调、凭据刷新，这几项放在一起看，重点已经从模型会不会写代码，转到 Agent 能不能像一段后台服务那样被调度、暂停、恢复和追账。
后台执行先改的是故障处理
长任务最怕绑在一条 HTTP 连接上。浏览器断开、网关超时、用户关掉页面，任务状态就变得难看。Google 的新接口让调用方拿到一个交互 ID，再用轮询、流式进度或重连继续查看结果。这个设计对企业系统很实用，跑报表、改代码、查资料、生成交付物，都不该靠一个前端连接吊着。
工程团队要补的不是按钮，而是状态机。任务创建、运行中、等待人工动作、失败、取消、已完成，每个状态都要能落库。超时后谁接手，重试会不会重复写入，用户刷新页面后看到哪一版结果，这些细节不处理，Agent 跑得越久，排障越痛苦。
远程 MCP 把内部系统接进来
远程 MCP 的吸引力很明显。企业不用给 Agent 写一堆临时代理，就能把数据库、工单、知识库、配置平台这类工具挂进去。问题也在这里，工具一旦接上，Agent 就不只是生成文本，它会碰到真实业务对象。
接入前要把边界写清楚。哪些工具只读，哪些工具能改状态，哪些动作必须等人工确认，哪些参数要走白名单。MCP server 的权限也要按场景拆开，不要拿一个万能 token 伺候所有 Agent。凌晨排障时最难解释的事故，往往来自这种省事。
函数回调要当成业务事务
文档里的 requires_action 状态很关键。内置沙箱工具可以在远端自动执行，业务函数会回到调用方本地执行。这个分界让企业能保留关键动作的控制权，但也要求客户端写得像事务协调器。
比如 Agent 要查库存、开工单、发通知。查库存可以自动跑，开工单也许要校验项目归属，发通知可能要做敏感词和收件人检查。每个函数都要有幂等键、参数审计和结果回写。不要只把它当成一次函数调用，它已经进入业务流程了。
凭据刷新别靠人工补救
短期 token 和临时密钥会过期，这在生产里是常态。Google 提到可以用已有 environment_id 刷新网络配置，沙箱里的文件、依赖和仓库状态保留下来。这个能力解决了一个很实际的问题，任务跑到一半，访问凭据换了，不能让工程师手工重开一轮。
企业实现时要把凭据刷新和权限收缩一起做。Agent 任务进入不同阶段，访问范围也应该变窄。生成计划时能读文档，执行变更时只能碰目标仓库，交付后关掉外部访问。凭据生命周期跟着任务生命周期走，审计才说得清。
优易云的落地建议
先挑一个低风险流程试跑，例如内部知识库问答加工单草稿。把交互 ID、状态、工具调用、函数参数、人工确认、输出版本全部记下来。每次工具调用都要能回放，哪怕回放时只展示脱敏参数。
再做一轮故障演练。断开前端连接，撤掉某个工具权限，让 MCP server 返回慢响应，让本地函数抛错。系统能恢复、能提示、能停止，就可以往更重的业务流推进。Agent 工程的成熟度，不在演示视频里，在这些不顺的时候。
