你的 AI 智能体需要的是岗位说明，而不是更好的提示词

询问一家公司，新来的应付账款分析师可以做什么，你会得到一个明确的答案。她会使用这些系统，与这些供应商打交道；凡是超过某个审批额度的款项，比如 10,000 美元，都要交由她的经理签字批准。她入职后的头几个月处于试用期。所有这些通常都会记录在一份授权表中，由内部审计部门每年检查。

询问同一家公司，它的新发票处理智能体可以做什么，你通常得到的却只是一张提示词截图。

相比任何模型基准测试，这种落差更让我担忧。我们正在招聘一支数字化员工队伍，却没有配备我们花了一个世纪为人类建立起来的管理体系：没有人写明它的权限，没有人在它上岗前测试它的判断力，也没有人演练过如何将它关闭。

为什么提示词无法胜任这项工作

提示词描述的是意图，说明智能体要做什么，却很少说明它绝不能做什么、权限边界在哪里，或者何时必须停下来并把决定交给人来做。

即使提示词确实写明了这些要求，也没有任何机制强制执行。告诉智能体不要发放超过 500 美元的退款，只不过是在向一个概率系统提出请求。没有审计人员会认可“我们好声好气地请求分析师”可以作为针对人类员工的控制措施，所以我不明白为什么我们会接受这种做法用于软件。

安全领域的人早就给这种情况起了名字。《OWASP 大型语言模型应用十大风险》将过度自主列为核心风险之一，其根源在于功能过多、权限过大或自主性过强。说白了，这就像在员工入职第一天便把所有钥匙都交给他。OWASP 指南读起来就像一份优秀经理的检查清单：只给智能体提供它需要的工具，限定其权限，对影响重大的操作要求人工批准，并在下游系统中强制执行授权，而不是相信模型会自我约束。

最后这一点，我要特别强调。授权必须落实在实际发生操作的地方，包括智能体自身的服务身份、它的工具权限，以及 API 网关上的支出上限。让多个智能体共用一个服务账户，就像五个人共用一张门禁卡。出了问题，审计日志只会显示是该服务账户执行了操作，你只能猜究竟是哪个智能体所为。

项目取消看起来是管理问题

Gartner 预测，到 2027 年底，超过 40% 的智能体 AI 项目将被取消，原因包括成本不断攀升、业务价值不明确以及风险控制不足。

炒作和不成熟的产品也是其中的原因。不过，不妨试着站在首席运营官的角度来看这三项原因。没有人设定预算，成本就会不断攀升。没有人写下工作应当产出什么，价值就会始终不明。没有限制、没有审查，也没有明确的责任人，风险控制就会不到位。Gartner 并没有这样表述；这是我的解读。这和放任员工自由行动却不建立管理体系所导致的问题如出一辙，而这种问题远早于 AI 的出现。

各类框架也看到了同一个缺口。NIST AI 风险管理框架将“治理”视为贯穿“映射”“度量”和“管理”各项职能的环节，其生成式 AI 概况文件也将这一思路延伸到了生成式系统。框架无法提供的是实际运转所需的机制，也就是团队每周二真正会执行的授权、测试和审查。缺少这些机制，治理就只会是一份放在共享云盘里的 PDF 文件。

将传统管理工具应用于智能体

先从岗位说明开始；对于智能体来说，这就相当于一份权限授权。在智能体接触实际运行的系统之前，应该有人能够用一页纸写清楚它可以做什么、绝不能做什么、审批门槛是什么、由哪位人类负责人负责，以及谁有权扩大它的权限。在 RACI 矩阵中，最终负责者必须是一个人。如果写不出这页说明，这个岗位就还没有准备好招人；对人类员工的招聘，你也会这么说。

授权管理中的两条传统规则同样适用于此。你不能委托自己并不拥有的权限，因此子智能体获得的授权范围绝不能超过创建它的智能体。职责分离原则也依然适用。一个既能创建供应商、又能向该供应商付款的智能体，和一个人类员工这样做一样，都会构成审计发现。

接下来是招聘测试。我们测试智能体的方式大多和测试计算器一样，只检查答案对不对。针对员工的测试则应检查：它是否始终在授权范围内行事；是否在应该征求批准时提出了申请；是否在情况超出职责范围时上报；以及是否在应该停止时停了下来。

在我自己的研究中，我一直在构建一个包含 50 个场景的基准测试，专门针对这些问题：超越审批限额、依据过时数据采取行动、遵循扩大权限范围的注入指令，以及在角色变更后仍保留访问权限。到目前为止，我只用脚本控制的智能体运行过这项测试，以确认这些场景的表现符合设计，因此目前没有模型测试结果可供报告。编写这些场景时，最让我惊讶的是它们有多么寻常。它们不过是员工偏离职责范围的常见情形，只是改写成了软件场景。大多数公开排行榜仍然只评估任务是否完成，评估智能体是否遵守权限的排行榜却寥寥无几。

试用和晋升的道理相当直接。对员工，我们一开始会把他们的职责范围限定得较窄，等他们证明自己的判断力后，再逐步扩大范围。智能体也可以通过同样的方式逐步获得权限：凭借始终不越界、妥善上报问题并干净利落地停止行动的记录来赢得权限；同样，这份记录也完全可以成为收紧授权的理由。

智能体还有一点不同于人的特殊之处。供应商升级底层模型时，你实际上就有了一名换了旧工牌的新员工。我会把这视为一次变更事件，并在原有授权继续生效前重新测试。

终止运行必须在真正需要之前演练。如果你必须在接下来一小时内让这个智能体停止运行并撤销其访问权限，你做得到吗？凌晨2点，谁有权作出这个决定？下游哪些环节会出问题？哪些正在进行中的承诺需要有人手动撤回？如果没人演练过这套流程，你就只能指望紧急停止开关能起作用。

你可以追究员工的责任。但你无法追究智能体的任何责任，这就是两者不能再相提并论的地方。这也正是授权必须通过系统强制执行、每个智能体都必须有明确负责人认领的原因。无论如何，最终总得有人承担责任。通常，这个人就是签字批准的人，不管他是否知道自己签了字。

事件复盘时会问什么

这些智能体中有些最终会做出不该做的事。发生这种情况时，事后复盘会提出那些原本就会用于调查员工的问题。它获准做什么？相关规定写在哪里？谁批准扩大它的访问权限？停止它花了多久？谁是负责人？

如果诚实的回答是“ 一条提示词”“没人记得”“几个小时”和“说不清”，那更好的模型也救不了你。

优势最终落在何处

模型正逐渐成为按供应商安排的时间表租用、替换和升级的投入品。两家公司可以运行同一个模型，最终却走向截然不同的境地。一家公司拥有配备预算、权限限制和负责人的智能体，而且每项重要操作都有审计记录；另一家公司则只有一个成本高昂的试点项目，最终可能沦为某人的取消率统计数据。

差异在于模型周围的管理体系。这套体系需要慢慢建立，主要由曾经管理过组织的人来打造。

如果你最新部署的智能体明天越权行事，公司里会有任何机制察觉吗？你能否用书面材料向审计人员说明权限边界在哪里？