当企业拥有十万AI员工，谁来当它的“人事部”？

一家公司需要多少名AI员工？Gartner给出了一个惊人的预测：到2028年，一家《财富》500强企业平均可能运行超过15万个AI Agent，而2025年这一数字还不到15个。微软对31个国家的调查也显示，81%的企业领导者预计，未来12至18个月内Agent将中度或深度进入公司的AI战略。

“15万个”的数字未必会精确兑现。它更像一个提醒，让我们看到Agent的增长方式与人类雇员完全不同。企业很难在3年内招聘15万名员工，却可以很快复制出成千上万个Agent。它们有的长期运行，有的只为一项任务临时生成；同一个Agent还可能因不同客户和权限产生大量实例。因此，企业很快会遇到一个棘手的问题：这么多AI员工，究竟如何管理？

从“会回答”到“能行动”

大模型作为聊天助手时，主要风险是说错话。而Agent接入企业系统后，风险的形态发生了变化。它可以读取客户资料、查询库存、发送邮件、修改代码、创建订单，甚至触发付款。错误从屏幕上的一句话进入到现实业务流程中。

设想一家制造企业部署了采购Agent。它发现库存低于阈值，随即比较报价、生成订单并提交付款申请。可一旦库存数据有误、供应商账户被替换，或带有提示注入的邮件诱导Agent改变目标，高效率便会放大损失。传统网络安全主要防范无权者闯入系统；Agent时代的一类重要风险，来自拥有合法权限的软件实体作出了错误行动。

Agent也不能只被当作普通软件账号。传统程序通常执行预先写好的规则，Agent会根据环境生成计划、选择工具，并在多步行动中改变路径。它还可能把任务委托给另一个Agent。身份、权限和责任由此变得流动：谁创建了它？它代表谁行动？可以把权限转交到哪一层？造成损失后，谁来负责？

企业现有的IT管理体系只能回答其中一部分。身份管理系统管账号，财务系统管预算，运维平台管程序状态，审计制度管人员责任。Agent同时跨越这些边界。它既像员工，又像软件；既消耗算力，又能调动资金和数据。企业需要一套将这些分散能力重新拼接起来的管理基础设施。

AI员工也需要“花名册、工牌和绩效表”

这套基础设施可以被称为“Agent管理平台”。如果借用企业管理的语言，它至少要承担四项职能。

首先是建立花名册。企业必须知道内部运行着多少Agent，由哪些部门创建、连接哪些工具、服务哪项业务。低代码平台使普通员工也能创建Agent之后，“影子Agent”会像当年的“影子IT”一样出现。没有统一登记，企业甚至无法判断某个Agent是否仍在工作，离职员工留下的Agent是否还持有敏感权限。

其次是发放可随时收回的“工牌”。Agent应当拥有独立身份，并与明确的人类责任人绑定。权限遵循最小必要原则，且根据场景、金额和风险动态变化。一个采购Agent可以查库存、询价，却不能在没有人工批准的情况下向新供应商支付大额款项；一个编程Agent可以在测试环境修改代码，进入生产环境则需要更高等级的授权。

第三是留下可审计的行动轨迹。企业需要看见Agent接到什么目标，调用了哪些模型、工具和数据，以及人类在何处批准或干预。传统日志常常只能告诉人们“系统发生了什么”，Agent审计还要尽量回答“它为什么这样做”。特别是当多个Agent互相委派任务时，监测和回放更为重要。

第四是考核绩效并办理“离职”。Agent的完成率、耗时、Token成本和业务收益需要持续评估。表现失常时，平台应当限权、暂停或回滚；业务变化后，旧Agent要及时下线。数量快速增长后，无人维护的“僵尸员工”很可能成为成本与安全黑洞。

一个新软件品类正在出现

Agent治理正在从概念变成产品竞争。美国国家标准与技术研究院在2026年启动AI Agent标准计划，把身份认证、安全交互和跨Agent协作列为重点。身份管理公司Okta开始把Agent视为需要独立登记、授权和注销的“第一类身份”。这意味着传统身份安全市场正在向“人类身份＋机器身份＋Agent身份”扩张。

中国厂商也开始抢占这一层。阿里云推出面向多Agent的统一注册、权限、审计、Token监控和成本控制能力；腾讯云的Agent网关则试图统一管理模型调用、MCP工具和多Agent协作。它们传递出一个清晰信号：企业级Agent的竞争正在从“谁能做出更多Agent”，延伸到“谁能让不同来源的Agent安全地一起工作”。

由此可能形成一条新的产业链。底层是模型和算力，中间层是Agent身份、网关、评测、可观测性、成本管理与安全审计，上层是客服、销售、研发等业务应用。过去云计算普及催生了云管理、FinOps和零信任安全；Agent规模化也会产生类似的“管理红利”。模型厂商、云服务商、网络安全公司和企业软件公司都在争夺这个入口。

这门生意的收费方式也可能随之改变。企业采购模型时，常按Token或调用量付费；Agent管理平台更可能按照Agent数量、受管身份、业务任务或风险等级收费。客户购买的已经不仅是算力，也包括对数字劳动的控制能力。谁能回答“一个Agent完成一张订单花了多少钱”“一次错误行动经过了哪些授权”“哪些Agent正在重复工作”，谁就掌握了企业评估AI投资回报的重要入口。

管理能力将决定Agent的上限

Agent带来的组织变化，也不会止于IT部门。业务部门要界定哪些决定可以交给机器，法务部门要设计责任边界，人力资源部门要重新划分员工与Agent的岗位，财务部门要核算每项任务的数字劳动成本，管理者则要学会给Agent设定目标、检查过程和处理例外。未来的“Agent人事部”很可能是一套由技术平台支撑、多个部门共同参与的治理机制。

真正困难的地方在于，这几个部门拥有不同的目标。业务部门希望Agent尽快上线，IT部门更看重系统稳定，安全部门倾向于收紧权限，财务部门关心成本，法务部门则担心责任无法追溯。过去，一个软件项目上线后通常按照既定规则运行；Agent会持续调用新数据、连接新工具，并在反馈中调整行动路径。对它的治理也需要从一次性的上线审批，转向持续性的监督。

企业可能因此建立跨部门的Agent治理委员会，也可能出现“Agent平台主管”“数字劳动力经理”等新角色。这些角色的重要工作并非亲自创建Agent，而是确定哪些流程可以自动执行，哪些节点必须保留人工批准，以及异常发生后谁有权按下停止键。将责任简单推给“使用Agent的员工”并不公平，因为普通使用者往往无法看见模型、数据和工具链的全部缺陷；把责任全部交给IT部门同样行不通，因为许多决策只有业务部门才能判断。更可行的办法，是为每个Agent指定业务责任人、技术责任人和风险等级，并把权限与责任同时写进工作流。

另一个隐患来自项目制数字化建设。客服部门采购一个Agent，财务部门开发一个Agent，区域公司再委托供应商建设自己的版本。每个项目在验收时都能完成演示，企业层面却缺少统一目录、技术标准和退出机制。几年后，公司可能拥有一批互不相识、功能重叠、无人统筹的数字员工。有些Agent已经停止创造价值，却仍在消耗Token；有些继续使用离职员工或外部供应商配置的权限。届时新增Agent的边际收益会下降，治理成本则持续上升。

在不久的将来，判断一家公司的AI能力，Agent数量可能只是很粗糙的指标。更重要的是，它能否知道每个Agent是谁、允许它做什么、花了多少钱、创造了多少价值，以及出现偏差时谁能立即让它停下来。拥有一支可识别、可授权、可观察、可问责的数字劳动力的企业，将更有可能在激烈的市场竞争中脱颖而出。

（作者王翔为复旦大学数字与移动治理实验室研究员）

来源：王翔