ZStack Zentrix 首发：企业 AI 从分散接入走向统一管理与治理

过去企业接入 AI，事情相对简单。

业务系统调用一个模型，配置好接口和 API Key，能访问、能统计、出了问题能查日志，基本就能跑起来。

但随着 Agent、MCP 工具和 Skill 开始进入企业，AI 的调用链正在迅速变长。

一次用户请求，可能先进入 Agent，由 Agent 调用模型完成判断，再调用 MCP 工具读取数据、修改工单或执行某项操作；过程中还可能加载多个 Skill，并继续调用其他 Agent。

这时候，企业面对的已经不再是一个“模型接口”。

它正在变成一条真正参与业务运行的 AI 能力链。

而问题也随之发生变化。

模型是谁提供的、Agent 能调用哪些工具、谁有权限执行、敏感数据能不能发出去、一次异常调用为什么被拦截、最终消耗了多少 token、成本应该算到哪个项目——这些事情，如果仍然分散在不同客户端、Agent、工具和模型平台里分别管理，很快就会失去统一视角。

所以，当 AI 从单一模型调用走向 Agent 化执行之后，企业需要解决的已经不只是“怎么把模型接进来”，而是：

如何把进入企业的 AI 能力统一接入、统一控制，
并让每一次调用都能够被看见和追溯。

这也是我们要解决的问题。

它位于 AI 能力提供方与业务使用方之间，将原本分散的能力接入同一个受管入口，并统一承接发布、授权、路由、安全控制、运行审计与成本核算。Zentrix 不负责训练模型，也不替代业务系统的 Agent 编排；它解决的是 AI 能力如何进入企业、谁可以使用、调用时如何受控，以及使用后如何追溯。

这也是 Zentrix 将四类能力纳入同一个分发与治理平面的原因：

不改变它们原有的使用方式，
而是在企业侧建立统一的可见、可分发、可控制和可审计机制。

真正的问题，并不是企业完全没有管理这些 AI 能力的工具，而是不同能力往往各有一套管理方式。

模型有自己的网关、API Key 和配额体系；MCP Server 由不同客户端分别配置；Agent 由各个业务团队维护身份和调用关系；Skill 又跟随具体的 Agent 或运行环境进行安装和升级。

能力越多，权限、凭据、限额、策略和审计也越容易被拆散在不同系统里。

如果每增加一种 AI 能力，企业就重新建设一套管理体系，那么 AI 能力越丰富，治理反而会越碎片化。

Zentrix 的核心判断是：

能力形态可以不同，治理语言应当统一。

在平台中，模型、MCP、Agent 和 Skill 都被抽象为可以分发、授权和审计的企业能力。策略既可以定位某一类能力，也可以进一步定位具体模型、MCP Server、单个工具、Agent、调用方、会话或部署环境。

这种“多轴”表达的价值，不只是让平台支持更多类型的对象，而是让不同 AI 能力复用同一套组织、身份、权限、策略和审计框架。企业新增能力时，可以减少重复建设新的治理系统。

需要说明的是，统一治理有一个前提：相关调用必须经过受管入口。如果客户端绕过网关直接连接上游，这次调用自然不会进入网关的策略、账本和审计。因此，落地时需要由网关集中持有上游凭据，业务侧只使用可撤销、可过期、可审计的网关访问凭据。

将不同 AI 能力放进同一个管理入口，只解决了“统一管理对象”的问题。真正进入运行之后，企业还需要把管理要求落实到一次能力使用的完整过程里。

一项 AI 能力从进入企业，到被某个用户或系统获得，再到实际调用，最后形成运行记录，大体经历三个阶段：

Zentrix 围绕这三个阶段，将权限、凭据、运行策略、安全、审计和成本管理串联在同一条治理链路中。

三个阶段不是彼此割裂的功能集合，而是一条连续链路：能力先被登记和授权，每次调用再经过策略判断，最终沉淀为可查询、可核对的记录。

多轴权限：让四类能力进入同一套组织关系

在 Zentrix 中，组织架构、工作空间和职能组可以作为权限主体，模型、MCP、Skill 和 Agent 统一作为企业能力进行分发。同一个职能组可以同时获得某个模型、某个 MCP 服务、某个 Skill 和某个 Agent，不再需要分别维护多份名单。

平台同时提供 SSO、账号和会话安全配置。企业可以将 IdP 中的组映射为职能组，让人员变动跟随已有组织体系同步，减少在 AI 平台中重复维护成员关系。

由此，“某个人可以使用哪些 AI 能力”可以在统一关系中查询；权限变化也能沿着同一套组织结构生效。

发布、开放与审批：进入目录不等于可以使用

能力被登记到平台，只代表它已经进入管理范围，并不意味着所有用户都可以直接调用。发布与开放用于区分能力的管理状态和可用范围：平台先确认能力是否可以进入企业目录，再决定向哪些组织、工作空间或职能组开放。

对于高风险能力，还可以加入人工审批。例如，用户上传的 Skill 可能包含不安全逻辑或不当依赖。平台对 Skill 进行统一安全扫描，并在管理员审核通过后上架，降低未经验证的能力直接进入生产环境的风险。

凭据集中托管：业务侧不再保存上游密钥

每个接入方在平台中作为独立消费者，拥有自己的凭据、配额和统计口径。凭据可以设置有效期，也可以重置或停用。当人员离职、项目结束或密钥疑似泄露时，管理员可以在平台侧统一处置，不必逐个检查业务系统配置。

模型供应商和外部系统的真实鉴权信息保留在网关侧，对用户侧 Agent 不可见；客户端拿到的是受控的访问凭据。这样既能减少上游密钥扩散，也为按用户、项目和系统计量提供基础。

路由分发：业务条件和合规条件共同参与决策

路由规则可以组合请求路径、模型、请求头、URL 参数、数据分级、个人信息类型、数据来源、调用方、流量标签、时段、灰度 Cookie、客户端 CIDR 等条件。

这意味着，路由不只根据“调用哪个模型”进行判断，也可以把业务和合规要求放进同一条决策链。例如：普通问答可以调用外部模型；如果请求被标记为机密、命中特定个人信息，或数据来自财务系统，则改走内部推理服务或直接拒绝。

将合规条件与路由动作统一配置，可以减少安全策略和流量策略分别维护造成的不一致。

规则命中后，平台可以改走指定模型，也可以拒绝请求。分流支持加权请求哈希和加权轮询：前者让同一逻辑请求稳定命中同一目标，后者让连续请求在多个目标间平滑分布，可用于模型灰度、流量调权和不同业务线的服务分配。

例如，在新模型上线初期，企业可以先将少量流量导向新模型，其余请求继续留在原有服务；也可以按业务线、数据等级或调用方，将不同请求绑定到不同模型档位。路由在这里不只是负载均衡，也承担成本、质量和合规要求之间的协调。

规则还可以返回原因码，便于调用方理解结果并在日志中定位。对于改写失败等异常情况，可以采用拒绝请求的安全默认值。

限流、并发和熔断：避免一个异常调用影响整条链路

Agent 的调用方式与传统人工请求不同。一次任务可能连续调用多个模型和工具，也可能因为异常逻辑产生循环调用或突发并发。

因此，Zentrix 分别从调用方和上游服务两个方向进行隔离。

针对调用方，可以按消费者设置请求频率、并发数量和累计调用量，避免单个 Agent、项目或业务系统占用过多资源；针对上游模型和服务，则通过熔断机制识别持续异常，在依赖故障时让相关请求快速失败，避免问题继续向整条调用链扩散。

平台同时提供并发限制、限速、调用总量、非法尝试保护和豁免等控制方式，并支持根据运行资源设置软、硬上限。

这些机制解决的并不只是“限制调用次数”，而是让企业能够在多个 Agent、业务系统和模型共享同一套 AI 基础设施时，对资源和故障影响范围进行隔离。

安全护栏：覆盖输入、输出和多种规避方式

当 AI 只负责生成文字时，错误往往停留在输出层；当 Agent 可以访问知识库、读取业务数据甚至调用工具执行操作之后，输入和输出中的敏感信息与风险内容就会进一步影响真实业务系统。

Zentrix 因此在网关调用链中提供统一的安全护栏，对用户输入和模型输出分别进行检测和处置。

平台覆盖 PII、密钥凭据、内容风险、企业词库等常见风险类型。对于姓名、证件、银行卡、Access token、API Key 等敏感信息，可以根据不同规则进行审计、脱敏、阻断，或者结合数据敏感等级调整后续路由。

针对不同企业和行业，安全规则也不需要完全从零建设。平台提供通用、证券、医疗和研发安全等策略模板，并允许企业继续维护自己的敏感词、项目名称、内部术语和特殊规则。

风险内容也不一定以标准文本形式出现。针对字符替换、隐藏内容、编码文本、图片和二维码等不同载体，平台会尽可能先还原为可识别内容，再进入后续检测，降低仅依赖关键词规则带来的绕过风险。

安全判断并不会停留在一个简单的“允许/拒绝”结果。命中了什么规则、采取了什么动作、最终为什么放行或阻断，都会进入运行记录，为后续排查和策略优化留下依据。

对于必须按照统一口径回答的问题，平台还可以通过必答题库维护标准答案；对于不同类型的请求，则可以结合本地意图识别，将其分配到更合适的模型或服务。

通过这些能力，安全护栏不再是独立于 AI 调用之外的一套检查系统，而是直接进入一次调用的运行链路。

WASM 插件：为企业定制规则保留扩展空间

内置策略无法覆盖每家企业的全部要求。Zentrix 支持将企业自定义逻辑以 WASM 插件形式挂载到网关请求处理链中，用于扩展特定的鉴权、处理和策略逻辑。

为避免第三方插件影响网关稳定性，平台同时对插件的计算资源、执行时间和运行对象进行约束，使定制逻辑能够运行在受控环境中。

可观测：从汇总指标下钻到单次调用

每笔受管调用都可以记录调用方、时间、目标模型或工具、命中规则以及 token 消耗等信息，并从汇总视图下钻到调用明细。

对于流式对话，平台单独关注首次返回时间。它更接近用户感知到的等待时间，而总耗时更适合衡量完整请求的处理过程。网关自身耗时与上游服务耗时也分别呈现，便于在故障现场判断延迟发生在哪一层。

这两组指标解决的是不同问题：首次返回慢，用户会直接感到“没有响应”；总耗时长，则可能说明生成内容较多或下游工具链较长。与此同时，如果只看端到端耗时，也无法判断延迟来自上游模型还是网关本身。将这些指标拆开，排障时才不会把上游服务问题误判为网关性能问题，或者反过来。

两类审计：谁改了配置，以及调用为何得到这个结果

配置审计记录谁创建、修改或删除了模型、MCP、Agent、凭据和策略；运行记录则解释一次调用经过了哪些判断、最终为何成功、失败、改写或阻断。

将配置变更和运行时调用分别记录并相互关联，可以帮助企业区分“策略被谁改过”和“请求为什么得到这个结果”，缩短排障和取证路径。

例如，一次请求突然被拒绝，运行记录可以指出它命中了哪条规则；配置审计则继续回答这条规则由谁在什么时间修改。两条线分开保存，又能通过策略和调用信息相互关联，才能从故障现象追溯到配置变化，而不是把所有事件堆进同一条日志流中再人工筛选。

成本账本：从总额拆到部门、项目和系统

平台可以按模型、模型分类、项目、消费者和接入系统统计用量，查看趋势、Top 排名，并下钻到单笔调用。财务或平台团队不再只看到一张供应商总账单，而可以继续追踪成本来自哪个部门、项目或业务系统。

告警根据预设阈值自动触发，并关联后续处置入口，帮助运营人员从发现异常继续进入处理流程。

Zentrix 管理后台按照搭建、组织与权限、护栏、质量、运行与排障、用量与成本、告警与处置、审计与取证、系统设置等模块组织，分别承接事前、事中和事后的管理任务。

概览页展示调用量、成功率、延迟分布和待处理告警，帮助管理员掌握当前运行状态。鉴权与流量规则页还会分别呈现控制面的配置版本和数据面的节点加载状态。管理员提交规则后，不仅能确认配置已保存，还能进一步判断规则是否已下发到数据面并被节点加载。

当权限、运行控制、安全、审计和成本被放进同一条调用链之后，Zentrix 的价值并不只是减少几套后台配置。

更重要的是，企业开始可以围绕同一次 AI 能力调用，将“谁获得了能力、调用了什么、经过哪些判断、产生多少成本、最终发生了什么”关联起来。

在此基础上，一套统一治理平面会进一步带来几个实际变化。

第一，帮助 AI 项目具备进入生产的治理条件。

从试点走向生产，安全、合规、财务和运维都需要可以验证的依据：敏感数据如何处理、谁调用过什么、策略是否生效、成本如何归属。Zentrix 将这些信息沉淀为可查询、可导出的记录，为项目评审和持续运营提供证据。

第二，降低 AI 能力变化对业务接入的影响。

Zentrix 将业务侧与具体模型和服务之间的连接收敛到统一入口。在协议兼容范围内，可以通过配置完成供应商切换、流量调权和故障转移，减少业务系统直接适配多个上游的工作量。

第三，新增能力时复用既有治理框架。

今天企业主要接入模型和工具，未来 Agent 之间的协作会越来越多。如果每增加一种能力，就重新建设一套权限、限额、护栏和审计，治理系统将持续碎片化。四类能力共用一套治理表达，可以让企业在扩展能力边界时复用已有的组织、凭据、策略和账本。

第四，支持私有化和离线交付。

Zentrix 支持私有化离线部署，使数据、模型凭据、审计日志和 token 账本保留在客户环境内。对于金融、能源、政务等对数据边界和网络环境有明确要求的行业，这是一项基础交付条件。

随着模型、MCP、Agent 和 Skill 持续进入业务，企业需要的不只是更多 AI 能力，更需要一套能够持续承接这些能力的管理方式。

Zentrix 通过统一入口，将分散的能力、权限、策略、调用、审计和成本关联起来，让 AI 能力可以持续扩展，而治理不必随之碎片化。

让每一次 AI 能力调用，都变得可以交代。