先说结论：企业里 Agent 数量变多之后，真正难处理的往往不是模型够不够强，而是没人说得清“现在到底有多少个 Agent、各自归谁、还能动什么”。本文只讲一个场景——员工自己搭的 Agent 进了生产，IT 台账里却没有它——把发现、登记、分级、收编、回收五步拆开，给出能落地的字段、控制点与验收指标。
边界先划清：本文讨论企业内部的 Agent 资产治理，不涉及具体安全产品选型，也不替代甲方的安全审计；文中引用的调研数字都标注来源与口径，落地效果以客户环境实测为准；涉及个人信息与数据合规的部分仅供参考，不构成法律意见。
一、一个很常见的场景：Agent 上了生产，台账里没有
多数企业的 Agent 不是一次性规划出来的，而是一个部门一个部门长出来的。它们通常以三种方式出现：
- 员工自己搭的。市场部为了赶活动，用低代码平台拼了三个 Agent：一个做选题，一个做改写，一个做分发。模型用的是员工个人申请的 API key，工作区挂在个人账号下，IT 资产台账里没有这一项。
- 复用了共享凭据的。客服主管给工单系统接了一个自动回复 Agent，图省事直接用了团队共用的服务账号，密码写在配置文件里，谁都能改，谁也不用负责。
- 人走了、任务还在跑的。财务共享中心让一位实习生整理发票，搭了一个识别与归档的小 Agent。实习期结束，账号停用了，Agent 的定时任务还在跑，输出还在往共享目录里写。
这三件事单看都不算事故，合在一起就变成了治理难题。第一，看不见：这个人到底建了几个 Agent、调了哪些系统，IT 只能靠问。第二，说不清：Agent 用的不是它自己的身份，而是某个员工的账号或一个共享账号，出了问题分不清责任。第三，收不回：员工离职、项目结束、供应商更换，都没有对应的回收动作。第四，算不清：模型调用费、第三方 API 费按部门或按人分摊，落不到具体某个 Agent 上，优化时找不到抓手。
这四件事有一个共同的根：Agent 从来没有被当成“有身份、有负责人、有生命周期”的资产来管。它被当成了一个工具，用完就放在那里。
二、为什么现在必须做：三组公开数据
这不是某一家企业的管理问题。2026 年公布的多份调研，指向同一个结论：Agent 的部署速度，已经快过治理建设。
- 跑起来的很多，管起来的很少。据 OutSystems《2026 State of AI Development》调研（样本约 1,900 名全球 IT 经理人，调研期 2025 年 12 月至 2026 年 1 月）：96% 的企业已在某种程度上使用 AI Agent，但只有 12% 建立了集中化治理平台；94% 的受访者担心 Agent 蔓延（agent sprawl）会增加复杂度、技术债与安全风险（据 OutSystems 2026-04-13 新闻稿）。
- 身份这一层最薄。Gartner 2026 年 9 月 30 日发布的《Agentic Security: Secure AI Agents With Workload IAM Architecture》把问题指向身份与访问管理：不少企业仍把 Agent 当人员账号管理，或允许员工与 Agent 共用凭据。报告的建议方向很明确——把 Agent 归入工作负载身份管理，用短期凭据、最小权限与集中策略，让授权控制在调用时生效，而不是停留在制度文档里（据 Gartner 报告，经行业媒体转引）。
- 数量还会继续上去。Gartner 预测，到 2028 年财富 500 强企业平均将运行超过 15 万个 Agent，而 2025 年这个数字还不到 15 个；同时只有 13% 的组织自认为具备合适的 Agent 治理能力（据 Gartner，经 Kong 2026 年 10 月 1 日引用；13% 为企业自评，不是第三方审计结论）。
产品侧的动向也在印证同一件事。ServiceNow 在 2026 年 10 月 15 日发布 AI Passport，用密码学签名凭证在运行时校验 Agent 可以访问什么、可以执行什么，同时把影子 AI 发现、权限映射与 AI 成本管理放进治理平台，预计 2026 年第四季度可用（据 ServiceNow 新闻稿，2026-10-15）。Deloitte 在 2026 年 10 月初提出的口径更进一步：把每个 Agent 视为高权限数字主体，为它设置可验证身份、明确负责人、批准用途和有限权限，并完整记录指令、工具调用、外部通信与执行结果（据 Deloitte 公开观点，经行业媒体转引）。
把这些信息放在一起看，结论并不复杂：Agent 治理已经不是“要不要做”的判断题，而是“先盘清单还是先买平台”的顺序题。我们的建议是先盘清单，原因在下一节。
三、怎么跑：五步把影子 Agent 收进台账
这套流程在制造、贸易和共享服务中心三类环境里都适用，区别只在权威源不同。整体目标是先做到“看得见、说得清”，再谈“控得住”。
第一步：定范围，先盘“有对外动作”的 Agent
不要一上来盘所有 AI 功能。先把范围收窄到三类：能调用工具或外部接口的、能写业务数据的、能对外发消息的。纯问答、纯改写、不接触业务系统的助手，可以只登记不深管。这样第一轮盘点的对象通常能压缩到几十个，两周内能跑完。
同时确认权威源。经验上的优先级是：身份提供方（IdP）里的应用授权记录 → Agent 或低代码平台的构建清单 → 代码仓库与 CI/CD 变量 → 各 SaaS 的审计日志 → MCP server 注册表。前两个能覆盖大部分“员工自建”，后三个负责兜底，尤其是那些只留了一个 API key、连平台工作区都没有的脚本式 Agent。
第二步：发现，三条线索交叉验证
- 身份线索。按 OAuth 授权、服务账号、API key 前缀反查。重点看“谁授权了什么”，而不是“谁申请了什么”。
- 流量线索。看模型服务与外部工具的出站调用，按调用量、来源域名、时间分布归集。一条稳定的每小时调用曲线，往往就是一个没人知道的定时 Agent。
- 构建线索。看平台工作区、代码仓库里的 manifest、定时任务与环境变量。这一步最容易发现“人走了任务还在跑”的遗留物。
每条线索都要落成结构化记录：来源 URL、记录时间、获取方式、置信度。置信度低的先标“待确认”，不要直接下结论。发现阶段的产出不是一张漂亮报表，而是一份可追溯的线索清单。
第三步：登记，台账字段要能回答四个问题
台账最常见的问题是字段太多、没人维护，或者字段太少、回答不了问题。我们建议按三层设计，每层只回答一个问题：
- 身份层：它是谁？Agent 名称、用途、运行环境、身份类型（独立身份 / 人类账号 / 共享账号 / 长期密钥）、凭据位置与轮换周期。
- 归属层：谁负责？业务归属部门、责任人姓名（必须落到具体的人，不能只写部门）、上线时间、最近一次调用时间、当前状态（在用 / 观察 / 冻结 / 已下线）。
- 动作与成本层：它能做什么、花了多少？可访问的系统与动作清单、数据级别、单次限额、模型与外部 API 费用、成本归属。
其中两个字段最容易被省略，也最不该省略。一是责任人：写成部门的台账，三个月后一定失效。二是凭据位置：只写“有密钥”没有意义，必须写到具体配置项，否则回收时找不到地方下手。
第四步：分级处置，确定性控制优先
盘点不是目的，处置才是。按“业务价值 × 风险”分成四档，每档给一个明确动作：
- 保留。有明确责任人、权限最小、在册可查。给它补一条季度复核记录即可。
- 收编。业务确实有用，但用的是个人账号或共享凭据。动作是换成独立身份、补责任人、纳入审批，再重新上线。
- 观察。连续 30 天无调用的，先冻结凭据、保留配置，通知业务方确认。确认无用再下线，避免误停。
- 下线。无法说明用途、无法找到责任人、或明显超出业务需要的，停任务、撤凭据、留记录。
控制手段上，先做确定性的，再谈模型层的。确定性控制包括：工具白名单、出站域名白名单、单次与单日条数限额、金额类动作强制人工确认、敏感数据外发前二次审批。这些规则不依赖模型判断，失败时默认拒绝（fail closed），比让模型自己判断是否越权更可靠。模型层的防护可以作为补充，但不能当第一道闸。
第五步：生命周期，回收要成套
回收不是“把账号停掉”一个动作。离职、转岗、项目结束、供应商更换，四个时点都要触发同一套流程，我们把它叫回收四件套：
- 停任务：先停定时任务与工作流，避免撤权后任务报错刷屏。
- 撤凭据：撤销 OAuth 授权、停用服务账号、轮换或删除 API key，三样都要查。
- 留记录：记录操作时间、操作人、影响范围，写进台账状态。
- 通知业务方：告诉使用方 Agent 已下线、替代方案是什么，避免私下重建一个更隐蔽的。
离职回收的目标时长建议定在 24 小时内，转岗与项目结束可以放宽到 5 个工作日。这个指标必须可测，否则流程会停在纸面上。
四、技术要点：四个容易做偏的地方
1. 一个 Agent 一个身份，不共用人类账号
Agent 应该有独立的、可命名的身份，并带上归属标签（部门、责任人、用途）。这样在审计日志里，人和 Agent 的动作能分开；在权限回收时，也不会因为停了某个人的账号而误伤其他业务。工作负载身份（workload identity）这类方案已经比较成熟，自建系统也可以用“服务账号 + 标签 + 独立密钥”做到同等效果，关键是别共用。
2. 控制放在调用链上，不放制度里
写在管理办法里的“不得访问超出范围的系统”，执行时没人检查。有效的做法是在 Agent 与业务系统之间放一层网关或代理，工具白名单、限额、审批都在这层执行，并且默认拒绝。网关本身要能被监控，配置变更要留版本记录，否则它会变成新的盲区。
3. 记录归集到同一条时间轴
Agent 的一次任务可能跨三四个系统。每个系统各记一份日志，事后很难拼起来。交付时要把调用记录归集到同一时间轴：来源系统、动作、参数摘要、结果、耗时、记录时间，用同一个任务 ID 串起来。参数摘要只记关键字段，不落敏感明文。这样既能做故障归因，也能回答“这次操作是谁批准的”。
4. 成本按 Agent 计量，再做部门汇总
只按部门看账单，永远不知道是哪个 Agent 在烧钱。计量粒度至少要到 Agent：模型 token、调用次数、外部 API 费用三个口径分开记，再按部门与责任人汇总。预算告警要早于停用，先提醒再限流，最后才停，给业务方留出调整时间。
五、交付物与验收：怎么判断这件事做完了
首轮盘点的交付清单建议固定为七项，少一项就会在三个月后返工：
- Agent 资产台账（含身份层、归属层、动作与成本层）；
- 身份与凭据清单（含凭据位置与轮换周期）；
- 分级处置建议表（保留 / 收编 / 观察 / 下线，逐条给动作）；
- 控制策略配置（白名单、限额、审批点）与变更记录；
- 回收流程与责任矩阵（四个触发时点、四件套动作、责任人）；
- 季度复核模板（复核项、判定标准、签字人）；
- 首轮盘点报告（发现方式、置信度、遗留问题）。
验收指标建议四个，都能从台账和日志里直接算出来，不靠汇报：
- 台账覆盖率：在册 Agent 数 ÷ 实际发现 Agent 数。首轮目标可以先定 95%，剩余部分列入待确认清单，限期闭环。
- 无主 Agent 数量：没有具体责任人的 Agent 个数。目标是清零，确实需要保留的走临时豁免并写到期日。
- 共享凭据占比：仍在使用人类账号或共享账号的 Agent 比例，按季度下降。
- 平均回收时长：从离职或项目结束生效，到凭据撤销完成的平均小时数，目标 24 小时内。
六、边界、成本与最常见的失败
先把边界说清楚。第一，Agent 资产盘点不等于安全审计，它回答“有什么、归谁、能做什么”，不替代渗透测试与漏洞管理。第二，盘点只应在授权范围内读取身份系统与 SaaS 的审计日志，优先取元数据，不读取业务内容本身；涉及个人信息的处理要按甲方制度执行，本文不构成法律意见。第三，台账覆盖率、回收时长这类指标受客户现有日志完整度影响，具体数值以客户环境实测为准。
成本主要在人力，不在工具。首轮盘点通常需要 2 到 4 人投入 2 到 4 周，规模越大、历史遗留越多，时间越长；工具优先复用现有的 IdP、日志平台与工单系统，不建议为了盘点先上一套新平台。台账用表格就能跑通字段与流程，跑顺一个季度再考虑系统化，顺序反了容易买完不用。
我们自己在交付里踩过的坑，集中在三件事上，也建议甲方提前规避：
- 台账建完不维护。首轮盘点很热闹，三个月后字段全是旧值。解决办法是把更新动作嵌进现有流程——新 Agent 上线必须登记，离职流程必须勾选“是否有 Agent”，不靠自觉。
- 只做发现不做处置。报告交上去，没人拍板收编还是下线，影子 Agent 依旧在跑。解决办法是在盘点启动时就确定处置会的召集人和频次，把“处置完成率”写进验收。
- 控制策略没和业务对齐。网关一上线，业务方发现常用工具被拦，转头用个人账号重建一个更隐蔽的。解决办法是先跑两周观察模式、只记录不拦截，把误拦清单给业务方确认，再切到拒绝模式。
七、常见问题
Q1：我们只有五六个 Agent，也需要台账吗？
数量不是判断标准。只要 Agent 有独立凭据、能写业务数据或对外发消息，就需要有人负责、有记录可查。五六个 Agent 用一张表就能管，成本很低。
Q2：员工用个人账号搭的 Agent，IT 能直接停吗？
建议先冻结凭据、保留配置，再和业务方确认用途，避免直接影响在跑的业务。停用动作要留记录，同时把“自建 Agent 必须登记”写进制度，否则停了还会再建。
Q3：台账一定要上系统吗？
不一定。先用表格把字段、流程和责任人跑通，一个季度后再评估是否系统化。字段设计没定就上系统，通常要返工两次。
Q4：这和 IAM、零信任是什么关系？
台账解决“清单与归属”，IAM 解决“执行与控制”。两者要对接：台账里的身份类型和凭据位置，应该能在 IAM 里找到对应对象；回收动作也应该由 IAM 执行、回写台账状态。
Q5：盘点会不会影响业务运行？
只读元数据、限制读取频率、避开业务高峰，通常不会。需要暂停任务的情况只出现在“观察”和“下线”两档，且会提前通知业务方。
附：口径与来源
- OutSystems 2026-04-13 新闻稿《Agentic AI Goes Mainstream in the Enterprise, but 94% Raise Concern about Sprawl》：样本约 1,900 名全球 IT 经理人，调研期 2025 年 12 月至 2026 年 1 月；96% 已在某种程度上使用 AI Agent、12% 建立集中化治理平台、94% 担心 Agent 蔓延增加复杂度、技术债与安全风险。
- Gartner《Agentic Security: Secure AI Agents With Workload IAM Architecture》（2026-09-30）：建议将 Agent 归入工作负载身份管理，使用短期凭据、最小权限与集中策略，让授权控制在调用时生效。据 Gartner 报告，经行业媒体 2026 年 10 月转引。
- Gartner 预测：到 2028 年财富 500 强企业平均运行超过 15 万个 Agent，2025 年不足 15 个；仅 13% 的组织自认具备合适的 Agent 治理能力（企业自评）。据 Gartner，经 Kong 2026-10-01 引用。
- ServiceNow 新闻稿（2026-10-15）：AI Passport、影子 AI 发现与 AI 成本管理，预计 2026 年第四季度可用。
- Deloitte（2026-10-05）公开观点：将每个 Agent 视为高权限数字主体，设置可验证身份、明确负责人、批准用途与有限权限，并完整记录指令、工具调用、外部通信与执行结果。据 Deloitte 公开观点，经行业媒体转引。
- 本文为公开信息整理与工程实践总结，不构成法律意见；调研口径以原报告与厂商公告为准，落地指标以客户环境实测为准。
