Managed Agents 进入长任务阶段：Background、Remote MCP 和凭证续期背后的可靠性协议
把 Agent 放进一个隔离 Linux 沙箱，只解决了“在哪里运行”。当任务持续几十分钟、HTTP 连接中断、凭证过期、工具服务暂时不可用时，系统还要回答：任务是否仍在执行，客户端怎样重连，副作用会不会重复，失败能否从检查点恢复。
Google 近期为 Gemini API Managed Agents 增加 background execution、remote MCP、custom functions 和跨 interaction 刷新凭证。表面是 API 功能补齐，背后是 Agent 平台从同步模型调用走向 durable runtime。
Background 不是把请求丢到队列就结束
同步 HTTP 适合秒级调用，不适合长任务。连接保持几十分钟会经过浏览器、负载均衡、网关、移动网络和客户端进程，任意一层断开都可能让用户误以为任务失败。
background 模式返回 interaction id，客户端稍后查询状态、流式读取进度或重新连接。但一个生产状态机不能只有 running 和 done，至少需要：
| 状态 | 含义 | 客户端动作 |
|---|---|---|
| queued | 尚未获得执行资源 | 等待或取消 |
| running | Agent 正在推理或调用工具 | 读取进度 |
| waiting | 等凭证、审批、限流或外部依赖 | 提供输入或等待 |
| succeeded | 目标完成且证据已持久化 | 读取产物 |
| failed | 已进入不可自动恢复错误 | 查看原因、决定重试 |
| canceled | 用户或策略终止 | 确认副作用与清理 |
| expired | 状态或沙箱超过保留期 | 从外部检查点重建 |
进度事件还要有单调递增序号。客户端重连时从 last_event_id 继续，避免漏事件或重复展示。最终产物必须独立于流式连接持久化，不能只存在于 SSE 缓冲区。
Exactly-once 很难，幂等才是现实答案
考虑一个 Agent 创建 PR 的过程：GitHub 已经创建成功，但响应返回前沙箱断线。系统如果整轮重试，可能创建第二个 PR；如果直接标记失败，又会丢失已经发生的副作用。
分布式系统很难对所有外部工具保证 exactly-once，更现实的目标是 at-least-once 执行配合幂等：
- 每个副作用生成 operation id；
- 工具服务按 id 去重并返回旧结果；
- 执行后立刻保存外部 resource id；
- 恢复前查询真实状态，而不是重放语言计划；
- 无法幂等的动作使用 prepare / commit 两阶段。
Agent runtime 要把“模型说已完成”和“外部系统确认已生效”分开记录。
Remote MCP 把工具接入变简单，也扩大了信任边界
远程 MCP 让 Agent 通过标准协议访问观测、代码、工单、数据库或内部服务。它减少每个工具的专用 SDK，却把安全边界从一个 API 扩展为：模型、托管沙箱、MCP 客户端、远程 MCP 服务、下游数据源和凭证系统。
上线前至少要回答：
- MCP server 身份怎样验证，是否固定域名和证书。
- 每个 tool 的输入、输出和副作用是否有 schema。
- 沙箱可访问哪些域名，是否默认拒绝外网。
- 凭证作用域是否按任务、工具和资源收窄。
- tool description 是否可能被远端内容注入修改。
- 敏感输出是否会进入模型上下文、日志和长期状态。
远程 MCP 不是“Agent 能连上就可以用”。最小权限、allowlist、审计和数据分级仍然要由调用方定义。
凭证续期不是便利功能，而是长任务存活条件
短期访问 token 常常只有几十分钟寿命，长任务不应通过发放超长期密钥解决。更安全的方式是：任务持有环境 identity，真正的 access token 按需下发、短期有效，到期后由受信任控制面刷新。
续期流程需要限制：
- 新 token 的权限不得比初始授权更大；
- 刷新必须绑定同一 environment id 和 task id；
- refresh token 不暴露给模型文本和工具输出；
- 任务被取消、风险升级或人员离职时立即撤销；
- 凭证刷新事件进入不可篡改审计日志。
如果任务需要新增权限，应该暂停到 waiting-for-approval，而不是让模型自行请求更广 scope。
长任务需要双层状态
托管沙箱内有工作状态：临时文件、依赖、终端输出和当前计划。平台外还要有 durable state：目标、检查点、已发生副作用、证据位置和审批记录。
只依赖沙箱会产生平台锁定和恢复风险。沙箱被回收、供应商故障或任务跨区迁移时，关键状态必须能重建。建议每完成一个可验证阶段就写外部检查点：
- 运行和模型版本；
- 输入数据版本与哈希；
- 文件或 commit 产物；
- 工具调用及外部 resource id；
- 验证结果、剩余任务和预算；
- 能否安全重放的标记。
这也让团队能够在不同 Agent 平台之间迁移，而不是把项目记忆锁在某个 interaction 中。
取消必须有语义，不能只是关闭 UI
用户点击 Cancel 后，系统要处理正在运行的模型、子进程、工具调用和外部动作。正确的取消协议包括：
- 控制面写入 cancellation requested。
- Agent 停止启动新的工具调用。
- 可中断任务收到信号并退出。
- 不可中断外部调用等待结果并记录真实状态。
- 清理临时凭证和沙箱资源。
- 生成取消报告，列出已完成、未完成和可能仍生效的副作用。
如果取消后无法回答“刚才是否已经发出邮件或提交变更”，这个 runtime 就不具备高风险任务能力。
观测指标要从模型调用上升到任务运行
除了 token、延迟和错误码，还要看：
| 指标 | 作用 |
|---|---|
| checkpoint age | 任务崩溃后最多丢多少进度 |
| recovery success | 中断后能否继续而非从头重跑 |
| duplicate side effects | 幂等设计是否失效 |
| waiting ratio | 时间消耗在模型还是外部依赖 |
| human intervention | 自动化是否真的减少审查负担 |
| verified task cost | 一个被验收结果的总成本 |
| stale credential events | 续期和撤销是否及时 |
长任务系统最可怕的不是一次报错，而是“看似还在跑，却没有产生新的可验证进展”。因此应设置 progress watchdog：状态、证据和外部动作长时间无变化时，暂停并诊断，而不是继续烧预算。
托管 Agent 和自建 Runtime 怎样选择
托管平台适合快速获得隔离执行、模型集成和统一 API；自建适合网络、合规、数据驻留和控制面要求很高的任务。实际可以混合：托管 Agent 做公开研究、代码分析和低风险草案，自有环境执行内部测试、数据访问与生产发布。
选择时不要只比较模型能力，还要验证：
- 状态和产物能否导出；
- 是否支持私网、域名 allowlist 和客户密钥；
- 失败、取消和过期的语义是否清楚；
- 审计日志是否覆盖远程工具和凭证；
- 能否设置时间、成本、并发和副作用预算。
Agent API 正在变成分布式系统 API
Background、Remote MCP 和凭证续期说明：长时 Agent 的竞争不再只是谁的模型更聪明，而是谁能把不可靠网络、短期凭证、外部副作用和中断恢复包成可解释的运行契约。
一个成熟 Agent runtime 应允许用户离开页面，也不会让任务失去身份；允许连接中断，也不会重复写入；允许凭证过期，也不会扩大权限；允许失败，也能从最近证据继续。这些能力听起来不像 AI 魔法，却决定 Agent 能不能真的接管长任务。