当 AI 成本开始细到评论类型，治理就不能再只管 seat 了

Governance Cost Control Compliance Policy Plugin Governance
数字治理
发布日期:   2026-05-10

导语：
5 月上旬最值得数字治理团队关注的，不是某一个 AI 功能多了几个按钮，而是平台开始把 AI 活动拆得越来越细。5 月 8 日，GitHub 把 Copilot code review comment types 纳入 usage metrics API；5 月 6 日，Enterprise-managed plugins in GitHub Copilot CLI 进入 Public Preview；往前看，4 月 23 日平台已经在使用度量里加入 Copilot cloud agent 字段，也开始允许从 Issues 和 Projects 中查看与管理 agent session。再叠加 5 月 1 日对 usage-based billing 的明确推进，可以说，AI 治理的坐标系已经变了。

以前很多组织做 AI 管理，核心抓手只有两个：买了多少 seat，是否允许使用某个产品。这个阶段治理相对粗糙，但还能勉强工作，因为工具链还没有真正深入研发现场。现在情况不同了。AI 已经渗入命令行、代码评审、自动会话、插件调用、云端代理等多个环节，成本、风险和数据外发都不再服从“一个席位一个边界”的逻辑。继续只看 seat 数量，治理会越来越失真。

1. 这次变化真正意味着什么

comment type 进入指标 API，代表平台开始承认“不同 AI 行为要分开计量”。这件事意义很大。过去大家只能粗略知道某个团队用了多少 Copilot，现在则能进一步知道这些使用量更多发生在代码评审、命令行、会话代理还是其他动作上。只要指标粒度足够细，治理才能从“人均购买”走向“行为级管理”。

Enterprise-managed plugins 的预览则把治理难题进一步推向插件层。模型本身不一定直接触网，但插件可以替它读仓库、查依赖、访问内部服务、连接外部系统。也就是说，AI 风险正在从“用了哪个模型”迁移到“让模型能调用什么”。这和过去浏览器扩展、CI 凭证、SaaS 集成的治理逻辑非常像，但复杂度更高，因为调用是半自动甚至自动发生的。

cloud agent 字段和 session 可视化又补齐了问责链条。谁发起了 agent 会话、它做了什么、耗了多少资源、是否改动了 PR、是否进入了项目看板，这些信息一旦能被追踪，组织就有机会建立更细致的成本归因与责任归因机制。

2. 为什么团队现在应该关心

因为很多组织的 AI 账单、权限边界和审计模型都还停留在 2024 年思路里。那时工具主要是个人问答式辅助，审计关注点集中在“是否允许上传代码”“是否开通外部模型”。但到了 2026 年，真正消耗预算和制造风险的，已经不是静态文本问答，而是多轮 agent 会话、PR 级自动操作、插件驱动的数据访问和持续性的代码评审。

如果指标体系不更新，组织会遇到三个问题。第一，看不到真实成本去向，只能在月底收到一张总账单。第二，看不到高风险活动发生在哪些团队和流程里，只能在问题发生后追责。第三，无法区分“高价值 AI 使用”和“低价值 AI 消耗”，最后只能用一刀切的限制政策打击所有人。

治理团队最怕的，不是工具能力增强，而是能力增强之后缺少解释框架。现在平台已经提供了更细的度量入口和更明确的插件边界，正是重做治理模型的时候。

3. 一套可执行的落地流程

第一步，把 seat 视角改成活动视角。
治理台账里不要只写“某部门开通了多少 Copilot”，还要记录这些账号主要在哪些场景中使用：CLI、代码评审、云端 agent、插件调用、知识检索还是文档生成。你治理的是行为，不是按钮。

第二步，建立分层成本规则。
例如，普通补全与短问答属于低成本默认允许；PR 评审与多轮会话属于中成本，需要团队负责人看报表；云端 agent 和外部插件调用属于高成本高风险，需要平台预授权。这个分层不一定追求完美，但必须先有。

第三步，给插件建立准入和分级。
按照数据访问范围、是否触达外部网络、是否能写回仓库、是否读取内部系统，把插件分成白名单、灰名单、禁止名单。Enterprise-managed plugins 的价值就在这里，它让组织终于可以把“能不能装”从个人偏好收回到平台治理。

第四步，把 usage metrics 接到 showback 或 chargeback。
不一定马上做真实计费，但至少要让团队负责人能看见：本组 AI 用量主要花在什么类型的动作上，哪类行为增长最快，哪种插件调用最多。没有这种可见性，任何节流政策都会流于空泛。

第五步，把 session 与变更记录连起来。
如果某个 agent 会话最终推动了 PR、Issue 或项目卡片变化，那就应该在审计链上留下关联。这样做既是为了追责，也是为了复盘哪些 AI 行为真正带来了业务价值。

4. 最容易踩的坑

第一大坑，是看见更细的指标后，立即陷入“指标崇拜”。指标只是解释工具，不是治理本身。你不能因为某团队 code review 消耗高，就断言它在浪费；也可能是这个团队刚好承担了高复杂度系统的审阅工作。指标必须和项目性质、交付节奏一起看。

第二大坑，是只管模型，不管插件。未来大量数据外发和越权访问不会直接发生在模型层，而会发生在插件层和 agent 层。如果组织的准入规则还停留在“允许某个模型、禁止某个模型”，治理实际上已经落后了。

第三大坑，是只有总量限制，没有例外机制。研发组织天然存在差异化。有些团队确实需要更多 agent 会话和更重的 PR 审阅，如果没有合理审批与配额上浮机制，治理会被视为纯粹的阻力。

5. 本周建议执行的动作

本周建议先做下面五件小事：

  1. 拉一份当前 Copilot 使用数据，先确认组织到底能看到哪些维度。
  2. 把 AI 使用场景按低、中、高成本和风险做第一版分类。
  3. 盘点当前正在使用或计划使用的插件，补齐准入判断。
  4. 选一个研发团队做 showback 试点，先展示不收费。
  5. 明确 agent session 与 PR、Issue、Projects 的记录归档规范。

这些动作不需要等制度写完再开始。很多时候，治理真正的起点是先把看不见的行为变得可见。

6. 结语

5 月上旬这些更新说明，AI 治理已经从“买没买、开没开”迈向“怎么用、用在哪、花在哪、连了谁”。数字治理团队如果继续只盯 seat，会越来越难解释成本，也越来越难管理风险。真正成熟的下一步，是把行为、插件、会话、审计和预算拉到同一张治理图里。

参考资料

文章作者: 张显达
文章链接: https://zhangxianda.com/2026/05/10/2026-05-10-digital-governance/
版权声明: 本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 张显达 !
Governance Cost Control Compliance Policy Plugin Governance
赏
  目录