审批队列并不是给你的智能体增加的负担。它是唯一能让它们变得更聪明的环节。

这里每周都会出现同一个问题的不同版本：“如果智能体采取的每一个行动都需要人来检查，那我们到底省了什么？”这个问题很合理。但我认为这个切入角度不对，而且我亲眼见过它让许多原本不错的智能体落地项目夭折。先交代一点背景。今年大部分时间，我都在和销售、营销及营收运营（RevOps）负责人聊他们投入生产使用的智能体。结果发现，他们分成了两类：第一类把审批环节视为需要尽快消除的额外负担。智能体表现不错，运行一周后，人就不再查看待审批队列，随后审批队列也被关掉。后来告诉我各种事故的，正是这些团队：智能体向已经流失的客户发送续约推销邮件，覆盖了六个月的交易记录，或者批准了某件事，事后却没人能解释为什么。大多数团队最终停用了智能体，并把问题归咎于模型。第二类把每一次批准、修改和拒绝，都视为系统产出的最有价值的数据。他们的做法大致如下：读取无需审批，写入则设审批关卡。按操作分别管理，而不是按整个智能体统一管理。“更新下一步行动”和“给客户发邮件”需要分别赢得信任。每次拒绝都必须附上理由。一句话就够。“联系人不对”“数据过时了”“企业客户不适用这种做法”。这句话就是训练信号。没有它，审批队列就只是走过场，你应该把它关掉，因为没人看的审批队列比没有队列还糟。操作会逐步获得自动执行资格。当某项操作的人工干预率连续几周保持在低位时，就可以转为自动执行。如果出现偏移，就重新纳入审批。没有人争论“我们是否信任这个智能体”，大家看的是那项操作的人工干预率。这些理由会反过来用于完善智能体所依据的信息。不是提示词，而是关于客户、规则和例外情况的底层上下文。拒绝理由会准确告诉你，这些上下文在哪些地方还不够充分。第二类团队的审批队列自然而然地缩小了。第一类团队的队列之所以消失，是因为他们把队列关掉了，随后智能体也消失了。令人不安的是：Gravitee 的 2026 年智能体安全报告发现，只有 14% 的团队在获得安全和 IT 部门完整批准后才上线智能体，而 81% 的团队已经让智能体项目进入了规划之后的阶段。因此，大多数团队默认就落入了第一类，而不是主动选择如此。只有当审批队列随着时间推移不断缩小时，“我们到底省了什么”这笔账才算得过来。如果你的队列没有缩小，问题不在队列本身，而在于没有任何东西从中学习。很想听听大家的经验！坦白说，我经营着一家这个领域的公司，所以请结合这一背景看待我的观点。不过，上述做法都不需要任何产品。用一张电子表格记录拒绝事项及其理由，就能实现大部分效果。