这个差距首先是一种度量假象，其次才是失败
许可证在采购事件中签发。使用量在集成事件中累积。这两个时钟以不同的速度运行，由不同的团队读取，这就是为什么它们之间的比率在季度评审中看起来触目惊心，而在平台复盘中却平淡无奇。当一家企业报告已配置席位与真正完成任何事情的会话之间存在巨大倍数时，这个数字通常是在两个互不兼容的分母上计算出来的：席位在购买时只计一次，而有意义的会话则按工作单元、按 tool call、按成功写入来计数。
第一个纠正措施是停止把这个比率当作情绪指标。它并不能证明员工不愿意使用 agent。它证明的是，从会话开始到任务完成的路径，跨越了一道采购流程从未触及的边界。
采用仪表盘度量的是错误的事件
大多数用于 agent 使用的内部仪表盘报告的是登录数、周活跃用户数和消息数。这三项都能被一个会话满足：它打开、接受一个 prompt、尝试一次 tool call、收到一个 schema 错误或授权拒绝，然后终止。用户登录了。用户是活跃的。用户发送了消息。任务没有完成。
由于失败被静默吸收，仪表盘显示出健康的采用情况，而支持队列则显示出一条缓慢的涓流式投诉，永远无法聚合成信号。那个本可以暴露问题的聚合指标——每个会话的首次 tool call 失败率——几乎从未被埋点，因为它位于采用团队所拥有的层级之下。
一个有用的诊断方法是按终止状态而非按活动来统计会话。在成功写入后结束的会话、在只读回答后结束的会话，以及在首次失败的 tool call 处结束的会话，是三个不同的群体，对应三种不同的补救措施。把它们合并成一个活跃用户数字，会摧毁唯一重要的信息。
这个差距在各垂直行业间保持稳定，这指向结构性问题
如果这种短缺是培训不足造成的，它会随用户群体的成熟度和赋能计划的质量而变化。但在实践中，这条曲线的形状在金融服务、物流、医疗行政和内部 IT 运营中都很相似。绝对数字不同；下滑模式却相同。
这种稳定性是现有最强有力的证据，表明原因是结构性的。垂直行业之间变化的变量是记录系统，而不是人。当下滑模式完全相同时，原因很可能也相同：agent 与这些系统之间的接口。
这与一个更广泛的观察一致：一旦涉及真实系统，agent 的能力与 agent 的实用性就会急剧分化。这一点在从业者关于 agent 部署经济学的讨论中被反复提及，例如 https://quasa.io 上收集的那些讨论。
照搬内部 API 的 tool schema
当工具界面通过暴露现有服务端点来生成时，模型继承的是组织的形状，而不是任务的形状。一个单一的业务动作——重新预订一批货物——会变成对客户服务、订单服务、库存服务和定价服务的一系列调用，每个服务都有自己的标识符约定，以及自己对何时状态转换合法的判断。
然后模型被要求从端点名称中逆向工程出业务逻辑。它有时会成功。当它失败时，失败被归因于推理能力，但真正的原因是第二次调用的前置条件从未在任何机器可读的地方表达出来。
缺少幂等性
只有当接收系统能识别出这是一次重试时，重试调用才是安全的。在写端点缺少幂等键的情况下，一次超时会让调用方无法区分调用是失败了，还是成功了但响应丢失了。运维人员很快会学到这一点并禁用自动重试。于是 agent 会在第一个瞬时错误上停滞，因为它唯一可用的安全动作就是停下来询问人类。
这是一个管道缺陷，不是模型缺陷。它在针对从不超时的沙箱端点运行的 evaluation 中也是不可见的。
写路径被无法表达的审批所把守
读路径通常是开放的，因为读取风险低，访问模型也简单。写路径则被把守，而这道关卡通常表现为工单系统、聊天线程或策略文档中的人工审批。这些都没有机器可读的表示，来说明正在审批什么、在什么条件下审批、以及何时过期。
因此 agent 可以提议，但无法行动，而提议也没有结构化的去处。它落入一个队列，由人类阅读并手动重新录入，这就把一项自动化变成了一个多了几步的通知系统。
为第二周而设计
任何 agent 部署的第一周都由新鲜感和最简单的任务主导。第二周才是集成界面决定结果的地方。三种做法能改变这条轨迹。
对首次 tool call 进行埋点
把一次会话中首次 tool call 的失败率作为首要采用指标。这是集成界面能够拒绝 agent 的最早时点，也是与会话是否继续最相
发布带有显式契约的类型化工具界面
一个工具定义应当以模型可消费、审查者可审计的形式，说明其前置条件、副作用和失败模式。具体来说，一个写工具应当声明：
- 它需要哪些标识符，以及它们来自哪里；
- 它执行哪些状态转换；
- 它是否幂等，如果是，基于哪个键；
- 它可以返回哪些错误类别，其中哪些可重试；
- 附加到该操作上的审批语义（如果有）。
像对待任何其他依赖一样对这个界面进行版本管理。tool schema 是一个接口，其消费者不是人类，如果它在没有版本边界的情况下发生变化，就会静默地破坏这些消费者。
给写操作一个提议状态
与其授予 agent 审批权限或完全拒绝它，不如把写操作建模为两阶段操作。agent 产出一个提议：一个类型化、已签名的对象，包含预期的状态转换、它所依赖的证据以及过期时间。策略引擎或人类批准该提议，然后由一个独立的执行器应用它。
这给了 agent 的意图一个机器可读的去处，也给了组织一个附加策略的地方。权衡是真实存在的：提议状态会给每次写入增加延迟，并要求执行器真正幂等，因为提议与执行之间的间隙正是重复提交出现的地方。为了保住延迟而跳过这一步的团队，通常会重新引入他们试图移除的人工队列。
应该停止做什么
停止购买席位来解决管道问题。额外的许可证会增加在首次失败的 tool call 处终止的会话数量；它们不会增加完成的会话数量。一旦集成界面成为约束瓶颈，一个席位的边际回报就接近于零。
停止衡量那些从未完成的任务所节省的时间。针对 agent 无法完成的任务计算出的时间节省估算不是预测，而是估算方法的产物。先衡量完成情况；时间数字只有在完成的前提下才有意义。
停止把 agent 框架当作集成层。框架是调用方。它决定何时调用工具以及如何解释结果。它不是适配器，也无法弥补一个没有表达出被要求执行业务逻辑的工具界面。适配器、契约和幂等性属于记录系统，以及拥有它们的平台团队。
当工具界面不再是事后才考虑的东西时，许可证与使用量之间的差距就会缩小。这项工作是乏味的，是有版本管理的，而它就是真正的产品。
封面照片：panumas nikhomkhai / Pexels。