8.3 倍使用率差距：企业级 Agent 采用是工作流适配问题，而非许可问题
企业 AI 采用率通常以许可证席位来衡量。然而，有报告显示席位与活跃 Agent 使用之间存在 8.3 倍的差距，这表明更深层的问题。这不是采购失败或培训失败；它证明 Agent 工作流的设计是围绕组织架构图，而非任务实际所需的决策序列。
差距实际衡量的是什么
许可证数量衡量的是采用意图。使用量衡量的是 Agent 是否融入现有决策路径，而不迫使人类重构其工作。如此规模的差距表明，大多数已部署的 Agent 位于工作流旁边，而非内部。它们需要人类在 Agent 输出与记录系统之间进行转换。这一模式在各行业反复出现：酒店、抵押贷款处理和金融行业都报告了采用但未就绪的情况。
机制很简单：当 Agent 被附加到流程边缘时，它产生的产物需要人类复制、粘贴或重新录入。这个转换步骤就是摩擦。摩擦降低使用率。Agent 变成了向访客展示但从未被依赖的演示。
工作流适配作为设计约束
工作流适配是指 Agent 在决策序列中占据特定步骤，而不干扰周围人类工作流的程度。要实现适配，首先映射决策序列：谁决策、依据什么证据、截止时间是什么。然后将 Agent 放置在特定步骤，而非系统边界。
取代整个角色的 Agent 会失败。在角色内部承担一项决策的 Agent 会成功，因为周围的人类工作流保持完整。例如，一个根据收入文件和信用记录起草抵押贷款预批准建议的 Agent，如果它将建议写入人类核保人已经审查此类项目的贷款发放系统，就能成功。核保人的工作流保持不变；Agent 只是添加了一个结构化输入。
集成界面比模型质量更重要。无法写回记录系统的 Agent 将被使用一次后废弃。模型质量影响决策的准确性，但集成决定决策是否进入真实流程。没有写回，Agent 的输出就是孤儿。
为什么许可指标具有误导性
基于席位的指标奖励部署而非集成。它们计算有多少人拥有访问权限，而非有多少决策得到改进。因此，它们总是显示使用量无法证实的采用率。有用的指标是 Agent 每周处理且无需人类返工的决策数，而非激活的席位。
要测量该指标，需要将 Agent 运行追踪到下游结果。大多数企业技术栈不这样做。它们记录 Agent 调用，但不记录输出是被接受、修改还是丢弃。没有这种追踪，组织无法区分被使用的 Agent 和仅仅可用的 Agent。
一种具体的追踪机制：为每个 Agent 输出附加唯一标识符，并将其传播到记录系统。当人类对该输出采取行动时，该行动被链接回 Agent 运行。这允许测量返工率：人类在使用前修改的 Agent 输出比例。高返工率表明工作流适配不佳。
一条实用规则
在部署 Agent 之前，写下三件事：它承担的决策、它需要的证据、它写回的系统。如果三者中任何一个缺失，该 Agent 就是演示。这条规则强制明确 Agent 的角色，并防止常见错误：部署一个在决策序列中没有位置的 Agent。
将首次集成视为产品。存活的 Agent 是其输出落入某人已经阅读的队列中的那个。这意味着与现有记录系统集成，而非创建新仪表板。测量返工率，而非使用率。低返工率配合中等使用率，优于高使用率配合高返工率。
权衡是速度与持久性。深度集成需要更长时间构建，因为它需要理解记录系统、其 API 和数据模型。
做错的代价
部署在工作流旁边的 Agent 会产生影子流程。人类将输出复制到真实系统，而 Agent 的遥测从未反映真实决策。这使得 8.3 倍差距看起来像培训问题，而实际上是架构问题。修复方法并不光鲜：更少的 Agent、更窄的范围、更深的集成。
影子流程还隐藏了真实成本。人类翻译 Agent 输出所花费的时间未被 Agent 指标捕获，因此组织可能认为 Agent 节省了时间，而实际上增加了一个步骤。随着时间的推移，这会侵蚀对 AI 计划的信任，并使未来的采用更加困难。
架构修复需要重新思考 Agent 的设计方式。不要从模型开始并询问它能做什么，而要从决策序列开始，询问 Agent 在哪里可以增加价值而不干扰流程。这通常意味着 Agent 做的比最初想象的少，但它所做的完全集成。
结论
8.3 倍使用率差距不是许可问题。它是工作流适配问题。缩小差距的企业将通过围绕决策序列而非组织架构图设计 Agent 来实现。他们将测量每周无需返工的决策数，而非激活的席位。他们将把集成视为产品，而非事后想法。
前进的道路很明确：更少的 Agent、更窄的范围、更深的集成。这就是差距缩小的方式。
封面照片：panumas nikhomkhai / Pexels。