AI 伙伴稳不稳定，别只看某一次回答

AI 伙伴偶尔给出一份漂亮答案，最多说明这次结果可用。一个人把客户跟进、内容整理或发版检查长期交出去以后，可靠性来自另一组问题。它一周接了多少任务，多少结果通过验收，等待和运行花了多久，失败以后有没有留下能继续处理的原因。

我觉得个人经营最容易忽略的是观察周期。每次只盯着最新回复，很难发现任务正在越排越久、失败集中在同一类输入，或者使用量增长却没有带来更多可验收结果。把视角拉到一周，才有机会判断这个伙伴能不能继续承担重复工作。

先把可靠写成你能承受的结果

Google 的 SRE 资料把 SLI 定义为服务某个方面的定量度量，把 SLO 定义为这个指标的目标值或范围，并提醒团队从用户真正关心的行为出发。个人工作流不需要照搬整套工程制度，但这个顺序很有用。先写清哪种结果对你的业务算可用，再决定记录什么。

比如客户回访助手的结果可以写成，每周约定的回访任务都进入清单，有依据不足的项目明确停在待确认，未经人工确认的回复不发送。这里没有通用的百分比。客户消息错过一次可能就要当天处理，内部资料整理偶尔延迟半天也许可以接受。目标应该跟后果一起定。

每周巡查保留四组信号

• 任务完成率。分母只放这周约定要完成的同类任务，分子只算已经通过你验收的结果。生成了内容却仍缺关键事实，不能记成完成。
• 等待与运行耗时。等待时间持续变长，通常说明任务排队或伙伴没有及时开始。运行时间突然变长，则值得检查输入是否膨胀、工具是否卡住，或流程是否在重复尝试。
• 失败类型。保留原始失败类别和最后可用状态，把短暂错误、缺少输入、需要人工决定和不可恢复问题分开。总失败数相同，处理顺序也可能完全不同。
• 使用量与可验收产出。使用量只在和完成任务数、返工次数放在一起时有意义。消耗上升而可用结果没有增加，才需要继续追原因。

GitHub Actions 的官方指标同样把平均运行时间、排队时间和失败率放在工作流观测里，并用使用量帮助定位高消耗任务。这个做法来自软件交付，不能直接替你决定内容或客户工作的标准。它提供的是一组可复用的观察对象。

先看异常，再决定是否需要更多数据

这张 MotiClaw 示例工作台把 15 位伙伴的工作、空闲、离线和异常状态放在一起，每张卡片还能看到任务数与使用量。一个人做每周巡查时，可以先打开离线和异常伙伴，检查最近活动与任务，再决定暂停、补输入或交回人工。

MotiClaw 在这里提供的是状态、任务、最近活动、健康和使用量等原始信号。本文整理的完成率与目标范围需要你根据自己的任务定义，产品当前没有被描述为自动计算 SLO。这个边界很重要，因为一张漂亮的总览仍然不能替你定义什么结果值得继续。

记录到足够排查就停

OpenTelemetry 为生成式 AI Agent、工作流和工具执行定义了可观测语义，并要求操作报错时记录错误类型。它也明确提醒，工具参数和结果等属性可能带有敏感信息。放到个人工作流里，最小记录可以只有任务标识、开始与结束时间、最终状态、失败类型、使用量，以及有没有经过人工处理。

客户原文、完整提示词、工具参数和模型输出没有排查需要时，不要为了以后也许有用就全部保存。工作数据默认留在本机；仅你主动接入的渠道与模型调用按任务所需出网。每周固定十分钟看一次这四组信号，连续两三周后再调整目标。你会先得到一条适合自己业务的可靠性基线，然后才知道哪一项值得自动化得更深。