智能体治理层：网关、记忆与轨迹审计的新战场
如果最近在做智能体的生产上线评审，真正难回答的往往不是“模型够不够聪明”，而是三个更具体的问题：谁在调用、调用了什么、留下了什么证据。
2026 年 9 月底，Onehouse、MongoDB、Kong、Sigma 相继发布了与智能体运行、网关或管理相关的新产品。形态各不相同，却都在补同一块能力：给生产环境里的智能体增加一层运行时治理（runtime governance）。它不直接判断模型说得对不对，而是约束智能体以谁的身份访问哪些数据、消耗多少资源，以及如何留下可追溯的记录。
过去，这些能力常被视为数据库权限或应用管理的一部分。现在，它们正在被抽出来，成为可以独立部署、独立计费的产品层。企业支付的不再只有推理费用，还包括“知道智能体做过什么”的成本。
由此可以观察到一个变化：智能体进入生产后，竞争正在从模型能力向治理入口延伸。谁把身份传递、预算控制和轨迹审计做成默认基础设施，谁就占据了一个更靠近企业数据、也更难替换的位置。
治理层解决的不是内容问题
先把边界划清楚。
护栏关注“模型说了什么”，主要处理内容过滤和输出安全；治理层关注“智能体做了什么”，主要处理访问控制、资源计量和行为留痕。
它也不等同于传统权限。RBAC 回答的是“谁可以看这张表”；治理层还要回答“这一次调用代表谁、按哪条策略执行、消耗了多少、留下哪条证据”。前者提供相对稳定的权限边界，后者把这些边界带入每一次动态调用。
它和 APM 式的可观测性同样有交集，但关注点不同：可观测性主要关心延迟、错误率和资源状态，治理层更关心身份、授权和责任归属。两者可能共享同一条调用链，却回答不同的问题。
这件事现在变得紧迫，核心原因是调用方式变了。人类手动操作时，一次授权往往可以覆盖一段稳定流程；智能体可能连续触发几十次工具调用，下一步还会根据前一步结果动态变化。原本面向“人和应用”的静态权限，需要被延伸为面向“每一次调用”的动态控制。
五个治理要素，贯穿一次调用
把几份产品公告拆开看，形态虽然包括网关、运行时、BI 应用和开发平台，治理能力却集中在五个方面。它们并非严格的五个顺序步骤：身份和鉴权发生在调用之前，计量与审计贯穿调用过程，记忆治理则跨越多次调用持续存在。
身份传递。 智能体调用不再统一使用一个万能服务账号，而是把“代表谁执行”这个身份带入调用链。Sigma 表示调用会继承调用者权限和行级安全；MongoDB 强调以真实的人或智能体身份执行。关键不在于具体采用哪种令牌机制，而在于下游能够识别这次操作最终代表谁。
调用前鉴权。 工具真正执行之前，需要由策略决策点完成最小权限检查。MongoDB 强调执行前授权和隔离运行；Onehouse 则通过内置的 MCP 服务器调用下游查询引擎，复用表上已经存在的权限策略。治理层通常不是重建一套权限系统，而是把数据库已有的 ACL 和行级安全重新接到智能体入口上。底层没有细粒度权限，上层也就没有可靠的策略可以继承。
预算与计量。 Onehouse 按调用者和模型统计延迟与预估花费，MongoDB 在组织级设置成本控制，Sigma 的管理页展示每个智能体的 token 用量和负责人。因为调用量难以提前准确预测，控制方式也从一次性审批转向持续计量、配额和告警。
轨迹审计。 它记录模型调用、工具调用和记忆访问，尝试还原完整的决策链路。这是信息密度最高、成本也最容易增长的一部分。后文会单独讨论，因为它同时具有审计证据和数据资产两种属性。
记忆治理。 这是它与传统数据治理差异最大的一点。MongoDB 把记忆分成语义、情景、分类和程序四类，并将记忆访问列为需要追踪的事件。智能体记住的内容可能包含个人信息或业务机密，却未必经过传统的表、行、列权限检查。记忆因此不只是功能组件，也成为需要授权、审计和删除的新资源。
这五个要素要形成独立的治理层，至少需要三个前提：底层存在可复用的细粒度权限；智能体调用经过统一、可拦截的协议入口；调用规模已经超出人工审批能够处理的范围。缺少其中任何一项，治理层都容易退化为一组零散的管理功能。
三条路线之争：治理层该长在哪一层
共同机制逐渐清晰之后，分歧落在另一个问题上：治理层应该位于哪里？这不仅决定系统如何集成，也决定身份、日志和计费最终由谁掌握。
路线一：长在数据平台里
MongoDB Atlas Agent Engine 代表的是贴近数据的一条路线。治理与存储、查询引擎共享身份和权限体系，集成链路短，也少一道信任边界。代价是覆盖范围通常局限在本平台内，轨迹格式、存储方式和计费也更容易与平台绑定。
路线二：长在中立网关上
Onehouse AI Gateway 试图在模型、工具和数据源之间建立统一入口。它的优势是可以跨平台执行身份传递、预算控制和审计，并强调开放格式与自托管。问题在于，网关一旦成为所有调用的必经之路，也会形成新的关键依赖。
路线三：长在应用或开发平台里
Sigma Agents、Kong Volcano 选择把治理能力放进应用或开发平台，尽量复用已有的用户、权限和工作流。它离实际使用场景最近，部署和使用更直接；但治理范围通常止于本平台，跨应用的一致审计仍然需要额外整合。
三条路线没有绝对优劣。数据平台内置的优势是“离数据近”，中立网关的优势是“跨平台”，应用平台一体化的优势是“离工作流近”。真正的分歧在于：企业愿意把统一拦截点交给谁。
这里也存在一个结构性悖论：中立网关原本是为了降低单一数据平台的锁定，但它一旦成为唯一入口，自己也可能成为新的锁定点。治理层解决了分散控制的问题，却天然带来了集中依赖。
轨迹日志：合规的副产品，正在变成新资产
治理层掌握统一入口之后，会自然产生一种新的数据：轨迹日志。它有点像监控录像，最初是为了留证，积累之后却可以用于质量评估、行为排查、成本分摊和模型改进。
Onehouse 给出过一组测算：某平台通过 Inference Tables 记录推理请求，基础价格为每 GB 0.10 美元，开启额外的用量追踪后费用继续增加。在它设定的持续 100MB/s 日志流场景中，每月约产生 262,800 GB 数据，仅按基础单价计算就约为 26,280 美元。
这不是一组可以直接用于采购决策的数字。它来自 Onehouse 的单方测算，目的是说明自身开放格式和自托管方案的优势；其自建成本也没有完整计入存储、运维和人力。不过，它揭示的问题仍然成立：调用规模增长之后，记录本身也会成为一笔可观的成本。
轨迹记录越细，审计价值越高，存储和查询成本也越高。 如果日志格式与平台内部的表结构、查询工具和计费方式深度绑定，审计数据本身也会成为迁移障碍。竞争的重点因此不只是“谁记录得更全”，还包括“记录下来的数据能否被企业真正掌握和带走”。
轨迹日志的另一面是风险。提示词、查询内容、工具返回结果都可能包含个人信息或商业机密。它既是“全程留痕”的证据，也可能成为数据泄露时最集中的暴露点。日志保留多久、如何脱敏、删除请求怎样传导到备份和索引，这些问题在现有公告里仍缺少细节。大家开始讨论如何完整记录，却还很少讨论如何安全删除。
合规视角：可用不可见、用途可控、全程留痕
从技术目标看，这套架构与可信数据空间强调的“可用不可见、用途可控、全程留痕”有明显呼应，但两者并不能简单画等号。
- 可用不可见关注的是，在尽量少暴露原始数据的前提下完成计算。智能体治理层本身不提供隐私计算能力，但可以限制智能体能够访问的数据和能够带走的结果。
- 用途可控要求权限不只是“能不能访问”，还要约束访问目的、范围和期限。治理层的身份传递与调用前鉴权，为这种细粒度约束提供了执行位置。
- 全程留痕要求关键行为能够被还原。轨迹审计把记录对象从一次 API 请求，扩展到由模型调用、工具调用和记忆访问组成的决策链路。
因此，两者真正的交点并不是某个具体产品，而是同一种工程趋势：权限从静态配置走向动态执行，审计从结果记录走向过程记录。
从产品公告到基础设施，还有四个空白
不过，从产品公告走到稳定的企业基础设施，中间仍有不少空白。
生产证据不足。 这几项发布里，有的是公开预览，有的刚正式可用，有的部分能力还要“稍后提供”。目前都还缺独立第三方评测和公开的生产案例数据。
性能代价未知。 一次智能体任务可能触发几十次工具调用，每次都做策略决策，累积延迟会成为真实代价，但目前没有公开基准可以参考。
汇总分析与权限继承存在冲突。 继承调用者的行级安全看起来很清晰，但智能体常常需要跨多人的数据做汇总分析，而单个调用者只能看到其中一部分。是按调用者权限截断结果，还是另设汇总权限？前者可能造成结果不完整，后者又可能绕开原有边界。现有公告还没有正面回应这个问题。
记忆治理缺少行业标准。 MongoDB 的四类记忆分类是自家方案，并非公开规范。企业如果同时使用多个智能体平台，记忆审计记录很可能互不兼容、难以迁移。它有点像早期的 APM 生态：各家都有自己的数据模型，但行业还没有形成类似 OpenTelemetry 的统一语义。
治理层最终争夺的是什么
智能体生产化之后，企业面对的不只是智能问题，也是一套新的记账与责任体系：谁发起调用，依据什么权限，消耗多少资源，产生什么结果，出了问题能否还原。
数据平台、中立网关和应用平台争夺的，表面上是治理功能的部署位置，实质上是企业智能体调用的默认入口。入口决定了身份如何传递、日志存在哪里，也决定未来迁移时最难搬走的是什么。
于是，真正值得观察的问题变成了：企业会为了较低的集成成本，把治理交给现有平台；还是会为了跨平台控制，把它放在相对中立的网关？更长远看，这个领域能否出现类似 OpenTelemetry 的开放标准，可能比任何一家厂商当前多提供几个功能更重要。
本文部分内容由 AI 辅助生成，经人工审校和补充后发布。
参考资料
- Onehouse. “Introducing Onehouse AI Gateway: Routing Without Chains and Tolls, Wherever Your Models Run and Data Lives.” 2026-09-30. https://www.onehouse.ai/blog/introducing-onehouse-ai-gateway
- MongoDB. “MongoDB Launches Atlas Agent Engine to Put AI Agents in Production Without a New Stack.” 2026-09-29. https://www.mongodb.com/company/newsroom/press-releases/mongodb-launches-atlas-agent-engine-to-put-ai-agents-in-production-without-a-new-stack
- MongoDB. “Atlas Agent Engine.” 产品页. https://www.mongodb.com/products/platform/atlas-agent-engine
- Kong. “Kong Announces Volcano: Agentic Infrastructure for the AI Era.” 2026-09-30. https://konghq.com/company/press-room/press-release/kong-announces-volcano-agentic-infrastructure-for-the-ai-era
- Sigma. “Sigma Agents Are Now GA: Scale AI Workflows Without the Sprawl.” 2026-09-29. https://www.sigmacomputing.com/blog/sigma-agents-enterprise-scale