发现无人阅读的输出：自动化系统的用户体验审计
了解为何在自动化和智能体流程中未被使用的输出会保持不可见，如何在不影响正常功能的情况下对其进行审计，以及唯一能防止这种情况出现的因素。
每个自动化系统都会产生一些运行正常却无人问津的成果：夜间自动生成却没人查看的报告、可能出错但从未被调用的验证机制、添加到检查清单中却无人实际查阅的规则。这些都不会导致任何问题，也正是它们能够存在的原因。本文介绍了如何对没有使用者的输出进行系统审计、此类审计通常能发现什么、会破坏正常组件的三种错误，以及让整个审计过程几乎无需成本的唯一元数据。
审计的原理：每一步骤都有发送者和接收者
无论管道是由cron作业、CI步骤还是串联的AI代理会话构成，一个有用的规范就是要求每个工作单元在两端都要有连接：上游为它提供上下文和输入，下游则接收它的输出。如果某个步骤能够正确接收输入却无人承接其输出，那么即便它的所有操作都正确，也并未完成有价值的工作。
制定这条规则很容易，但验证起来却很困难，因为违规行为不会留下任何痕迹。审计的作用就是找出那些做了合理操作但其结果却从未被利用的步骤。如果能够定期进行审计，比如在每次回顾会议中都进行，而非仅在出现问题后才进行一次，其效果会最为显著。
诚实的审计通常会发现什么
设想有一个团队正在运行一个高度自动化的、由代理驱动的工作流，该工作流会对自身进行审计。审计结果并不理想，而这恰恰体现了其价值。
- 从未被触发的检查点。他们发现了95个本应变为红色的检查项，却从未有任何流程触发过它们。这些检查项都经过了妥善实现和测试，在编写时似乎都很重要，但却没有一条流程路径会用到它们。
- 没有调用方的规则。在最近新增的25条规则中，有19条，即76%，没有任何代码路径、检查清单或常规流程引用过它们。问题并不在于这些规则被忽视了，因为根本没有任何东西指向它们。有一项调试步骤在团队的标准指南中存在了42天，却从未被使用过一次。并非有人忘记了它，只是把将其记录下来误认为是已经采用了它。
最后一个案例用一句话概括了其中的教训：把东西放在正确的位置并不等同于真正交付它。
为何故障总是发生在衔接处
损失往往发生在系统之间的边界处，而这并非人工智能所特有。有些东西被传递出去却未被接收，或者虽被接收但未能及时被发现。在上述每种情况下，产生方都运作得十分完美：作者完成了写作，计数器进行了统计，闸门也成功开启了。所缺失的只是一个明确的接收方。
核心难题在于，当没有接收方时一切都不会出错。缺乏消费行为不会产生任何错误、警报或日志记录。生产者因为其故障会发出明显信号而被监控，而接收方因其缺失不会产生任何声响，因此很少被监控。
另外两个案例进一步展示了这种沉默持续存在所带来的后果：
- 一种警报中继系统会为人工操作员缓存消息，并承诺在下次成功发送时送达。但在某个节点上，它每次都在执行第一行逻辑代码之前就退出了。552条消息因此等待了16天。发送端状态正常，路径也正确，但却始终无法联系到接收端。
- 公共控制面板显示有17篇内容来自镜像源，而它所声称要反映的账本在整套系统中根本不存在。该面板只是如实显示了它所掌握的信息，却没人去核实它实际上是从哪里获取数据的。
只要在接收端进行检查——操作员是否收到了内容，控制面板的来源是否存在——就能发现上述两个问题。
使用情况审计出错的三种方式
这种审计的简单版本——即“统计每个组件的使用频率并移除那些使用次数为零的组件”——实际上会损害系统。以下三种修正方法可解决其最常见的错误用法。
1. 统计使用情况，而非调用次数
人们很容易将计数器连接到显而易见的入口点，比如加载技能或运行脚本的工具调用。但实际上组件往往是通过间接方式被使用的。如果自动化程序只是读取技能文件，而非调用封装该技能的工具，那么即使该组件被频繁使用，调用计数器也会显示为零，从而导致审计系统判定其为“已失效”状态。
应统计组件对下游产生的影响，而非触发它的入口点。如果某份报告被使用，那么相应的决策、工单或下游文件应该会发生变化；这种变化才是值得统计的证据。
2. 输出数据的时效性并尊重时间窗口
九天前创建的组件无法与使用三十天的组件进行比较。审计报告必须说明其数据可追溯的时间范围，绝不能对观察窗口之外的内容做出评判。未明确说明覆盖时间范围的结论不具备实际权威性，且会系统性地对最新创建的内容产生不利影响。
3. 将那些以可用性为价值标准的对象排除在外
有些工具的存在只是为了备用的，而非实际使用。针对从未发生过的故障制定的操作手册，其调用次数应当为零。对于这类工具，关键问题在于它是否仍然有效，而非被调用的频率。若对其应用使用率指标，反而会删掉在最糟糕的情况下恰恰需要的资源。灾难恢复流程、备用配置以及很少使用的管理工具都属于同一类；应当定期进行测试，而非统计调用次数。
更深的陷阱：仅能用于确认的指标
除了计数器之外，还存在一个更根本的问题。那种只能体现你所构建事物优势的指标并不能作为证据。而那些永远不会建议关闭某个流程的审计报告，其实不过是换了个名字的状态汇报而已。在相信这些结果之前，先思考什么结果会促使你删除某样东西，并确认这样的结果确实能够实现。
解决方案：在工件创建时即明确其使用者
最有效的改变往往是微小的。对于每一个工件，无论是门控规则、报告、仪表板还是任务，在创建时而非审计时记录一行信息：谁在使用它，以及哪种状态变化能证明它已被使用。
上述所有问题都源于最初未能回答那个问题，而每一次事后补救所付出的代价都高于当初直接解答它。以下是一些切实可行的实施方法：
- 在用于创建新任务、规则和定时作业的模板中添加必填的“消费者”字段
- 拒绝仅描述生产者操作（如“仪表板已更新”）而未提及接收方（如“值班审核员可查看该仪表板”）的完成定义
- 对于通过共享、队列或中继等方式传递的内容，应在接收端进行验证，而不仅仅是发送端
一旦有了该字段，审计工作就不再需要费力排查。只需查询那些“消费者”字段为空的记录，这份列表就是审计结果，而且随时都可以获取。
关键要点
- 由于无人阅读则不会出现问题，因此没有指定消费者的输出默认是不可见的。
- 故障多发生在数据传递环节，因此需在接收端确认交付情况。