正确解读这一差距
企业 AI 报告中反复出现的一个模式是：已配置的席位与实际完成的会话之间存在很大的比例差距。具体数字因调查而异，但形态是稳定的：许可很多，完成的任务很少。直觉上会把这解读为热情问题——用户获得了访问权限却没有使用。这种解读通常是错的。
席位与已完成会话之间的巨大比例，是关于任务设计的信号。当一个 agent 被挂接到一个没有明确完成条件的工作流上时，会话不会大声失败。它会停滞。用户打开工具，得到一个看起来合理的中间结果，无法判断工作是否完成，于是回到原来的方法。许可被消耗了。什么也没有完成。统计许可的指标记录的是采购，而不是 agent 是否完成了任何事情。
这一差距在不同厂商和不同模型代际之间持续存在。如果它是产品质量问题，随着模型改进它应该会缩小。它并没有按比例缩小。这种稳定性指向一个结构性原因：交给 agent 的工作单元大小不对。
先分解，再委派
在选择模型之前，先分解工作流。有用的划分方式不是按部门或按工具，而是按某个步骤是否具有可验证的完成条件。
当一个第三方——脚本、审查者、schema 检查——能够查看输出并就其是否完成达成一致时，该步骤就具有可验证的完成条件。例如：从这份文档中提取这十二个字段到该 schema；按这套分类法对这些工单进行分类；起草一封只引用该语料库中来源的回复；核对这两份列表并标记不匹配之处。这些步骤可以交给 agent，因为 agent 可以针对该步骤而非整个任务被评估。
当"完成"的定义存在于某个人的头脑中或某种未成文的规范中时，该步骤就不具有可验证的完成条件。例如：判断这份合同是否可以接受；在三种策略中选择哪一种；判断这位客户是否处于风险之中。这些步骤需要一个人类决策点，或者需要被收窄，直到它们确实具有可检查的输出。"判断这份合同是否可以接受"变成"提取与标准模板不同的条款并标记出来"——这是可检查的——随后再由人类做决定。
大多数失败的部署是把 agent 挂接到整个工作流，而不是其中的一个有界步骤。agent 被要求端到端地负责一个流程。由于该流程没有单一的完成条件，agent 无法知道何时停止，用户也无法知道。会话在模糊中结束，而这被记录为未使用。
一个具体机制：有界步骤契约
使其可操作的一种方法是有界步骤契约。对于每个候选步骤，在选择任何模型之前先写下四件事：
- 该步骤消费的输入，具有固定的形态；
- 该步骤产生的输出，具有固定的形态；
- 判断输出是否可接受的检查；
- 检查失败时的升级路径。
如果这四项中有任何一项无法写下，该步骤就还没有准备好交给 agent。这是刻意为之的无聊。它迫使分解在设计阶段发生，而不是在试点期间才被发现。
该契约还给了你可供埋点观测的东西。由于输出形态和检查都是明确的，你可以记录该步骤在哪里失败，而不仅仅是它失败了。这就是一个可以调试的部署与一个只能被放弃的部署之间的区别。
对流失进行埋点观测
采用率仪表盘通常记录会话是否以成功结束。这是可用的信号中最没用的一个。真正重要的是会话在工作流中的哪个位置结束。
在第二步被放弃的会话与在第九步被放弃的会话是不同的信号。在第二步被放弃通常意味着该步骤的范围划定有误——输入形态与现实不符
轨迹级遥测把一项采用率统计转化为一项设计输入。你不再问"用户是否采用了这个工具"，而是问"这个工作流中哪个步骤在流失会话，该步骤与其他流失会话的步骤有什么共同点"。第二个问题有一个能改变设计的答案。第一个没有。
一个实用的模式是在会话结束时记录步骤索引，同时记录该步骤的检查结果。经过几周，这会为该工作流生成一条按步骤划分的流失曲线。流失率高且检查失败的步骤是分解错误。流失率高且检查通过的步骤是集成错误。两者需要不同的修复方式，而一个成功/失败标志无法区分它们。
令人不安的结论
有些工作流根本就不应该在其中放置 agent。把这一点说出来，比再做一次试点更便宜。一次运行一个季度并得出"用户没有采用它"的试点，与一次得出"这个工作流没有值得自动化的有界步骤"的设计评审，成本相同——只不过设计评审结束得更早，并且让工作流保持完好。
这一权衡是真实存在的，值得直白地说明。分解在任何价值交付之前就要花时间，而且它可能得出结论：答案是"不"。厂商主导的部署立即交付访问权限，并把问题推迟。对于一支承受着展示进展压力的团队来说，第二个选项更有吸引力。它也是产生使用差距的那个选项。
厂商有动机报告席位，因为席位是他们所售卖的东西。买方需要报告已完成的工作单元，因为已完成的工作是他们所消费的东西。这两个指标会分化，而这种分化并不是丑闻。它是一种度量错配，只有当买方把厂商的指标当作自己的指标时，它才会成为问题。
值得关注的指标是同一个有界步骤上的重复使用。第一周的登录衡量的是好奇心。在一个具有可检查输出的步骤上的重复使用，衡量的是该步骤在放入 agent 后是否确实变得更好。如果一个步骤被使用一次后就被放弃，那么分解是错的。如果它被同一批人反复使用，那么该步骤的范围划定正确，契约也站得住。
这是一种更慢的采用 agent 的方式。它也是唯一能区分一个需要更好模型的工作流与一个需要不同形态的工作流的方法。
封面照片：Jakub Pabis / Pexels。