智能体先别全盘治理：企业得有一张风险优先队列

一家企业问“我们有多少智能体”，得到的答案往往不是数字，而是几份不同平台的导出表。业务在 Copilot Studio 做了助手，数据团队在云平台跑了 Agent，客服又接入了 SaaS 里的自动流程；它们各自看得见自己，却没有人看得见全貌。真正棘手的从来不是少一张清单，而是当治理资源有限时，究竟先盯住哪一个。

9月24日，Dataiku 发布 Agent Management，明确把跨平台智能体的发现、价值衡量和风险提示放到同一层。其公告援引 IBM 调研称，不到五分之一的组织维护了完整、最新的 AI 系统清单；新产品则连接 AWS Bedrock、Google Vertex、Microsoft Copilot Studio、Salesforce Agentforce 等环境，识别每个智能体所用模型与工具。厂商公告当然不是行业普查，但它把一个被忽略的运营事实说透了：看不全，就无法决定先管谁。

总清单不是终点，优先队列才是

把所有智能体拉进一个台账，是必要的第一步，却很容易制造另一种假安全感：项目看起来都“已登记”，实际风险却没有排序。一个只读、每天服务十位内部员工的问答助手，和一个能调客户资料、能发起退款、还在夜间持续运行的智能体，不应该得到同样的审查频率。

我的判断是：智能体治理的最小单位不是“平台”，也不是“模型”，而是一条按风险排好序的工作队列。先把有限的人审、测试和预算用在一旦出错就最难收回的动作上。

这张队列至少可以用四个问题排序：它碰到什么——是否接触客户、资金、核心系统或敏感数据；它能做什么——只是回答、生成草稿，还是能提交、修改和调用外部工具；它跑得多快——一次失误的影响是单笔，还是会被批量、持续地放大；它能不能收回——出错后是否能暂停、回滚、定位责任人与完整复盘。前两项描述暴露面，后两项决定事故半径。

同一周的三条信号，指向同一件事

9月15日，Cisco 为 Splunk Agent Observability 增加 Tokenomics：实时追踪智能体表现与 Token 支出、将消耗归因到具体智能体和员工使用的编码工具，并预估账期结束前的趋势；同时它宣称在运行时施加护栏，拦截不准确或不安全的动作。这次更新的启示不是“每个 Agent 都要盯得一样细”，而是价值、成本和动作风险必须被放在同一张排序表里。

9月22日，Okta 联合多家厂商发布安全智能体架构，把部署后的治理浓缩为四个问题：智能体在哪里、它能做什么、它正在做什么、出事时如何响应。该联盟援引 Gartner 的预测：到2028年，全球财富500强企业平均会使用超过15万个智能体，但认为自身治理到位的组织只有13%。这组预测不是既成事实，仍应按预测口径理解；它真正值得借鉴的是顺序——先发现、再限定、再观察、最后准备处置，而不是先买一个统一大屏。

把队列变成每周可执行的动作

我建议先把智能体分成红、黄、绿三档，而非给所有团队下同一套重流程。红档是能碰核心数据或代表企业对外、且影响难以逆转的智能体：要有明确负责人、上线前场景测试、运行中抽查和一键暂停。黄档是有受限工具调用或明显成本波动的智能体：重点核对权限、支出和异常升级。绿档则是只读或低影响的内部助手：保留基本归属和版本记录即可。每周复核的，不是“新增了多少个”，而是红档是否仍有无主、无证据、无停机路径的项目。

对 STARBOX 来说，组织层应先设定风险分级、责任人和升级规则；BOX 层沉淀智能体任务、连接的知识与工具、测试结果和运行证据；智能体层只在相应档位的边界内行动。DDABC 闭环再把拦截、人工改写、成本异常和投诉回流，让某个智能体的风险等级可以升降，而不是一上线就永久贴标签。

企业不必等到“智能体爆发”才开始治理。先做一张能每天更新的风险优先队列，你就能把最稀缺的审核能力，优先给最可能改变业务结果、也最可能带来代价的那一小部分智能体。规模化不等于一视同仁；成熟的治理，恰恰始于知道哪里不该平均用力。