Google Cloud 把 Gemini Enterprise Agent Platform 暴露成远程 MCP server，最该被企业软件团队记住的不是 MCP 这个缩写。真正有用的是，外部 AI 客户端想调用企业 agent 时，终于有机会走一条带身份、权限和目录的通道。
官方材料里提到，Gemini CLI、ChatGPT、Claude 以及自建应用都可以通过这个入口发现和调用 Agent Platform 里的 agent。平台侧保留 IAM、Agent Registry、Agent Engine、Agent Space 这些管理面。也就是说，agent 不再只是某个团队藏在脚本里的能力，它可以被登记、授权、调用和复盘。
远程 MCP 不是万能插座
我看很多团队聊 MCP，会很快滑到工具越多越好。这个方向有点危险。企业环境里，工具接得越顺，误调用的代价也越高。一个外部客户端能查知识库还好，如果它还能触发报价、改工单、读客户资料，权限边界就得写清楚。
Google Cloud 这次把入口放在 Agent Platform 上，给了一个比较务实的做法。先把 agent 当成受管资源，再让客户端来连接。客户端可以多，治理面最好别散。
目录比聊天入口更要紧
企业一旦有十几个 agent，员工最先遇到的麻烦往往不是不会问，而是不知道该用哪一个。销售有线索评分 agent，客服有工单归类 agent，研发有日志排障 agent，名字都差不多，权限也差不多，出错后很难追。
Agent Registry 的价值就在这里。每个 agent 要有说明、拥有者、适用范围、输入输出、权限级别和停用策略。优易云在给企业做流程系统时，也会把这类目录放在后台管理里，不让业务人员靠群消息找入口。
授权要按动作拆
很多 AI 项目只做用户能不能访问 agent 这一层。真上线时不够。一个工单 agent 至少有读取客户、读取设备、生成草稿、写入工单、关闭工单几类动作。不同动作的风险不一样，权限也该分开。
更稳的设计是让 agent 默认只读。生成内容可以进草稿池，写入业务系统前要拿到人工确认。高风险动作还可以要求二次确认或主管审批。别怕流程看起来慢，企业系统里，慢一点通常比批量写错好救。
日志要能回答三个问题
agent 调用业务系统后，日志不能只存一次请求成功。排查时真正要问的是，谁发起的，agent 拿到了哪些上下文，哪一步把结果写回了系统。少一个字段，事故复盘就会变成猜谜。
MCP 入口还会带来跨客户端调用。员工可能从 Claude 发起，也可能从内部页面发起。后台日志要把客户端、用户、agent 版本和业务对象串起来。这样出了问题，技术团队不用翻一堆散文件。
先挑低风险流程试水
如果企业准备接远程 MCP，我不建议一上来就连财务审批或合同盖章。可以先从只读检索、草稿生成、异常归类这类流程开始。它们有业务价值，出错后也比较容易拦住。
优易云更关心的是这些 agent 怎么进企业软件的日常界面。一个按钮、一个任务状态、一个可回滚的操作记录，比一段神奇提示词更能让项目活下来。
