“托管智能体”到底托管了什么
Google AI Developers 5 月 21 日在 X 上挂了一段开发者真机录屏，主角是 Vertex AI 上”managed agents”形态的智能体。整段演示没有任何 Kubernetes 集群、没有 Redis、没有自建的 message queue，开发者写了几十行 Python 把工具函数挂到 Agent Builder，剩下的执行栈、checkpointing、长会话状态、工具调用并发，由 Vertex 那一侧托管。视频里展示的样例来自一家名为 BrightSide Capital 的中型金融公司，业务场景是把客户的退休金重平衡流程跑成可对话的智能体。
把基础设施抠掉之后剩下什么
开发者要做的事被压缩到三件：声明工具（Python 函数加 docstring）、写一段 system prompt 描述策略、设置上限和审批环节。其他的部分——agent 状态在多轮会话之间的持久化、工具调用失败后的重试、横向 scale、计费——都由 Vertex 接管。这跟一年前要自己跑 Argo Workflow + Cloud Run + Firestore 的智能体方案是两个工程量级。
BrightSide Capital 出现在录屏里不是巧合。Google Cloud 在 2026 年 4 月 Next 大会上把金融服务列为 agent 落地的优先行业，配套发布了《AI Agent Trends in Financial Services 2026》白皮书。BrightSide 的工程总监 Diego Marquez 在 LinkedIn 上回应过这次合作：”过去我们做一个简单的客户咨询 bot，要四个工程师维护半年的运行时；切换到 managed agents 之后，同样的功能由两个人接手，剩下的精力全花在策略和合规上。”金融公司对运行时稳定性的要求远高于一般 SaaS，这种”基础设施全包”的卖点对它们价值最高。
托管的代价：被锁进 Vertex
这套体验有明显的取舍。把所有运行时托管给 Google，意味着应用层与 Vertex 强耦合：日志、状态、工具协议都在 Google 的格式里。要迁出去，相当于从头重做一遍。Anthropic 的开发者关系负责人 Mike Krieger 在 X 上对此评了一句：”托管智能体降低了起步成本，但锁定成本会在 18 个月之后才显形——团队应该在最早期就把工具层抽象成可移植的接口。”
另一个常被忽略的点是延迟。托管模式下每次工具调用要走一遍 Google 的调度层，简单 RAG 查询的端到端延迟会比自建栈多 200 到 400 毫秒。对客服类对话场景影响不大，但任何对响应时间敏感的场景——例如交易撮合、实时风控——还是要走自建路径。Google 给出的官方建议是”latency 高于 1 秒可接受的场景优先选 managed”，这个边界对开发者选型有参考意义。
降门槛和锁平台是同一件事的两面
托管智能体能让一个两人小团队跑出过去四人半年的成果，这是真实的工程效率提升；但它把”agent 怎么调度、状态存哪里、工具协议怎么协商”这些原本属于开发者的权力，连同代码一起交给了云厂商。开发体验越丝滑，平台依赖越深。短期看这是 Vertex 抢市场的合理动作，长期看团队该提前考虑可迁移性——把工具签名、prompt、评测数据集与 Vertex 解耦保存，是把”低门槛”和”不被锁死”同时拿到手里的唯一办法。
参考链接：
