Google Cloud 在 Agentic Enterprise 的文章里反复提到一个词，Agent Runtime。它把部署、弹性、会话、记忆、追踪、日志、监控、网关这些东西放到同一条生产链路里。这个方向对企业团队很现实，因为 Agent 从演示环境进生产环境后，麻烦通常不在模型调用本身。
麻烦在谁能调用它，它拿什么身份访问系统，它把上下文放到哪里，失败后谁看日志，工具权限开大了谁负责收口。
先把 Agent 当成线上服务
很多团队做 Agent 试点时，习惯把它看成一个更聪明的聊天入口。上线后就会发现，它更像一个会主动调用工具的线上服务。线上服务该有的台账，它也要有。
至少要记录这些内容。Agent 名称、负责人、运行环境、调用的模型、可用工具、数据源、外部出口、用户身份映射、日志保存位置、回滚方式。表格看起来土，但半夜出故障时，工程师找的就是这些土东西。
身份边界要写得足够细
Google Cloud 文档里把 agent identity、service account、API key、OAuth client 分开讲，这个拆法很值得企业照着做。一个 Agent 不该直接继承开发者的权限，也不该共用一个万能服务账号。
比较稳的做法是按场景拆身份。查询知识库用只读账号，触发工单用受限账号，访问业务库走单独审批。工具调用要能从日志里追到具体用户、具体 Agent、具体动作。追不到，审计时就只能靠猜。
会话和记忆要有保质期
生产 Agent 最容易被低估的是状态。用户连续问几轮，系统要记住上下文。用户跨天回来，系统又可能需要长期偏好。Google Cloud 把 Sessions 和 Memory Bank 拆出来，说明状态已经不是临时变量那么简单。
企业落地时要提前定规则。哪些内容只在会话里保留，哪些内容能进长期记忆，哪些字段不能写入记忆，用户要求删除时怎么清理。别等客服、销售、售后都开始喂数据了，再回头讨论这些问题。那时候清账会很难看。
网关不是摆设
Agent Gateway 和远程 MCP 的价值，不在于多了一个入口，而在于把外部工具访问变成可治理的连接。企业内部系统一多，Agent 很快会连到 CRM、知识库、工单、文件、数据仓库。每个连接都绕过网关，权限会碎成一地。
优易云做企业系统集成时，一般会把 Agent 工具调用放进三层清单。可读资源、可写资源、高风险动作。高风险动作要有人工确认或审批记录，哪怕只是改一个客户状态，也不能让 Agent 悄悄做完。
观测要看一次完整执行
只看最终回复没什么用。工程师需要看到一次请求从用户输入到模型选择、工具调用、外部响应、重试、输出过滤的完整轨迹。Google Cloud 文档里列出 tracing、logging、monitoring，这几项要一起做，拆开做容易漏。
我更建议给 Agent 单独做运行看板。失败率、工具调用耗时、超时分布、人工接管次数、敏感动作拦截次数、单用户成本。看板不用漂亮，能定位问题就行。
试点结束前补一份退出方案
Agent 项目容易只写上线方案，不写退出方案。模型换了怎么办，工具接口撤了怎么办，记忆数据怎么迁出，用户入口怎么回退，人工流程怎么接住，这些都要在试点结束前写清楚。
托管 Runtime 能省掉不少基础设施工作，但它省不掉企业自己的工程纪律。把身份、状态、工具、观测、退出方案补齐，Agent 才算从演示台走进了运维台。
