企业把智能体接进生产系统，绕不开一个被反复提起却少有人正面解决的尴尬：智能体要干活，就得调那些早就跑在生产的 API，可这些 API 本来是给可信的人类开发者用的。一次查客户姓名，返回的往往不止姓名，还有地址、账单、内部备注——多出来的字段既白白烧 token，又可能把本不该暴露的数据塞进模型的上下文。更糟的是，安全团队想问「营销 Agent 能不能看到客户 PII」时，得去逐个翻工具定义；想追某个异常流量，又得从 API key 反查到某个人。大多数公司的智能体项目，不是卡在能力，而是卡在上生产前的那道评审。
在智能体与企业系统之间插一层网关
Apollo 在 10 月 7 日的 Apollo Summit 上，把 GraphOS Agent Services 推到公开预览。它的位置很直白：坐在智能体和企业系统中间，把每次 Agent 请求翻译成正确的 API 调用、代发每个上游凭据、再按字段级策略决定「这个人/这个 Agent 现在能看什么、能做什么」。它给 GraphOS 加了四个能力——Search 让 Agent 从领域模型里找到对的数据和工具；Identity 管理 Agent 自己的身份、并携带使用者的身份；Policy 把可见与可为之控细化到单个字段；Audit 把发生的一切记成可审计的日志。
这里最关键的取舍，是判定回路里没有模型。Policy 引擎做每一个允许或拒绝的决定，而不是让 LLM「看着办」。GraphOS 今天每月编排超过 2 万亿次操作，底层是 Wayfair、Expedia、Indeed 这类公司已经在用的那张图。Intuit 已经在生产里试点，其营销团队用 Agent 实时比对投放与结果、提出调整建议，理由正是「只给它需要的，并留下全程审计」——否则他们不会放心交出这种权限。Apollo 给 MCP 的定位也很清楚：MCP 服务器把 GraphQL API 暴露成 Agent 可调用的工具，而 Agent Services 是架在它上方的访问控制层，管的是「谁被允许看和做」。
它赌的是「中性的桥」，不是某个应用的功能
把这件事放进更大的图景里看会更有意思。同一周里，Google 想让一个 Agent 站到所有应用前面，Cisco 想让对话本身成为那个前门，SAP 想让 Joule 成为 SAP 流程里的单一体验。Apollo 的打法不一样：它不抢界面，也不绑某个业务系统，而是赌「智能体与企业数据、权限之间的那座受治理的桥」会是一层中性的基础设施。Gartner 有个判断常被引用——到 2028 年，至少八成的未授权智能体交易，源于企业内部政策在信息过度共享、不当使用或失准行为上的违规，而不是外部恶意攻击。这话反过来印证了 Apollo 的假设：风险主要在「该拦没拦」，而拦得住的前提是有一张能逐字段说理的域模型。
它补上了什么，又带来了什么新负担
和已经被反复写过的那些「企业 Agent 平台」相比，Apollo 的增量很克制：别人在卖智能，它在卖那道不起眼的控制面。字段级策略意味着敏感字段可以根本不进 Agent 上下文，而 Agent 仍能拿到授权使用的部分；每次交互都有身份、有策略、有审计。对受监管行业，这比「模型很安全」的承诺实在得多。但代价也真实：你得先把系统建模进那张域模型里，否则策略无处附着——这本身是一份持续的治理功课，不是接上就完事。而且它目前仍是公开预览，官方文档里入网还要和 Apollo 团队一起做，可用性要打折扣看。
所以更公允的判断是：Agent Services 不是又一个「更聪明的 Agent」，而是把「谁能看、能做什么、出了事谁担」这件事，从开发者的经验里抽出来、写成确定性的图规则。当行业还在比谁的演示更炫时，Apollo 把这道题重新定义成了工程问题。它未必适合所有团队，但对那些 API 散落、权限敏感、又想让几十个 Agent 同时跑起来的企业，这座「中性的桥」很可能比再训一个大模型更决定能否上生产。