企业 Agent 治理缺口

企业第一次引入 Agent 时，可以把它理解为能够执行任务的 AI 工作助手或智能代理。真正进入组织之后，问题很快就不再是“回答得好不好”，而是“这次任务经过了哪些模型访问资源，谁能复核，谁要负责”。对很多中国技术团队而言，治理缺口往往出现在平台建设、项目交付和模型服务选择三者的交界处。

先画调用路径，不要先堆制度清单

如果从制度名称开始讨论，会议很容易变成抽象的权限、审计和合规愿望。更有效的起点是画出一条具体路径：Agent 从哪个 Service Endpoint 进入，使用哪个规范化模型身份，经过哪个 Provider 与 Connection，最终由哪个 Adapter 完成当前支持范围内的模型服务通信。

这张图首先解决责任归属，而不是替团队做政策判断。平台团队负责公共模型访问基础，业务研发负责 Agent 工作负载，安全团队关注凭据边界，ToB 交付团队还要考虑同一套基础如何在不同项目中复用。路径不清楚时，每个团队都只能看到自己的一段。

企业 Agent 治理的起点，不是给 Agent 增加更多自主决策，而是让组织能够不依赖 Agent 自述，仍然复原它到达模型的路径。

中国企业常见的是多团队、多项目、多模型服务并存

一个平台团队可能同时服务内部研发与客户项目；不同项目又可能因为部署区域、采购安排或现有技术栈，连接不同的境内或国际模型服务。这里不应推断任何合作关系或广泛兼容能力，但治理问题已经存在：相同的模型名称是否代表相同资源？项目复制时是否连到了原本不该复用的 Connection？谁有权调整路由？

因此，组织需要一套稳定词汇，把“某个模型接口”拆成可管理对象：

需要命名的对象	评审时要回答的问题	当前可核验的产品概念
Agent 入口	哪个系统把请求送入控制面？	Service Endpoint
模型意图	业务希望使用哪个稳定模型身份？	规范化模型
服务归属	目标模型服务由哪个资源表示？	Provider
具体配置	端点与凭据落在哪个实例？	Connection
执行方式	控制面如何与该类模型服务通信？	Adapter

把治理要求落进方案评审单

适合立项或架构评审的记录，不需要假装成产品配置。它只要迫使参与者把边界写清楚：

工作负载：项目交付文档核对 Agent
业务负责人：交付产品组
Agent 入口：指定 Service Endpoint
规范化模型：项目批准的文本模型身份
Provider / Connection：由平台团队命名并维护
路由预期：按显式配置确定执行路径
当前证据：在支持范围内检查文本请求
待确认项：组织权限、限额与更深追踪报告

这类评审单尤其适合 ToB 交付复用。同一个交付模板可以复用“必须回答哪些问题”，但不应复制真实凭据，也不应默认不同客户环境、区域或模型服务使用同一个 Connection。

当前产品证据可以支持哪些判断

Stravia Console 当前 0.1.0-alpha 预发布产品基础已经提供可核验的 Control Plane 概念，包括 Service Endpoint、Provider、Connection、Adapter、规范化模型、确定性路由、定价配置、凭据边界和请求检查。当前执行边界是 OpenAI-compatible、非流式文本。固定 Demo 证据只用于说明产品界面与概念，不代表客户遥测或生产运行结果。

这些证据可以帮助团队确认资源是否被明确命名、路由是否按显式配置表达、凭据角色是否被区分，以及当前文本请求是否有可检查入口。它们不能推出自动故障转移、流式处理、tools、vision、隐私扫描、广泛 Provider 支持、生产就绪或合规认证。

公开 Early Access 尚未开放，当前状态应表述为 Coming Soon。是否公开可获得，与 0.1.0-alpha 产品基础中哪些行为可以被核验，是两件不同的事。

扩大使用前，先设三条判断线

技术负责人不必等到所有路线图能力完成才开始评估，但应当明确三条线：

1. 当前证据线：现有产品能够展示和复核什么。
2. 采用前置线：组织权限、限额、隐私政策执行、追踪审计与报告中，哪些是扩大采用前必须解决的条件。
3. 禁止推断线：哪些能力、认证、SLA 或生产结果目前没有证据，不能写进方案承诺。

最终产出不应是一句笼统的“可以使用 Agent”，而应是一份可追责的路径说明。它可以成为 Enterprise Pilot 的评估输入，但不会因此变成生产部署、响应时间或交付结果的保证。