请求成功却没有答案：我用 WorkBuddy 复盘了一次企业 Agent 空响应故障

作者代号： 亦十

案例性质： 真实生产事故的完全脱敏回放；姓名、企业、主机、IP、会话、群聊和请求标识均已替换，故障现象、关键指标、证据关系与结论保持不变。

企业 Agent 出现异常时，最容易犯的错误不是“查得不够多”，而是把某一层的线索直接当成根因：容器显示 healthy，就认为整条业务链路正常；模型接口返回 HTTP 200，就认为一定生成了答案；看到相同卡片出现在几个群里，就认定机器人发生了串群。

这次我使用 WorkBuddy 5.2.6，对一宗真实企业 Agent 事故进行了脱敏回放。整个任务严格限制为只读诊断：不连接生产环境，不执行网络请求，不修改文件、数据库、缓存或配置，也不重启、部署、提交代码和发送消息。目标不是让 AI 猜一个听起来合理的根因，而是形成一份任何接手人都能复核的证据链报告。

一、事故现象

事故发生在 2026 年 9 月 2 日 15:05–15:12（UTC+8）。企业 Agent 在处理一份候选人材料时，界面显示：

Agent couldn't generate a response

当时有两个怀疑：第一，负责执行任务的容器是否异常；第二，分析卡片是否被机器人发送到了错误群聊。

本次复盘需要分别回答三个问题：

1. 容器有没有发生故障？
2. 有没有证据证明机器人跨会话误投？
3. 为什么模型请求已经返回 HTTP 200，用户仍然看不到回答？

二、输入材料

为了避免泄露生产信息，我把真实事故整理为五份脱敏材料：

• 事故简报：时间窗口、现象、诊断目标和禁止动作。
• 调用链：员工、会话、Worker、容器、Router、模型和目标群聊之间的映射。
• 分层证据表：每条观测能够证明什么、不能证明什么。
• 模型请求摘要：HTTP 状态、SSE chunk 数、token 数、可见正文与 reasoning 字符数。
• 运行时与后续结果：关键错误、无关警告以及数分钟后的恢复情况。

这些材料没有上传真实日志，也没有包含姓名、内部域名、IP、Token、密钥或生产文件路径。为了让 WorkBuddy 能直接处理，我将五份材料的完整内容以内联方式放入任务指令，而不是授权它访问生产系统。

WorkBuddy 中的事故现象与执行结果

三、WorkBuddy 配置和任务指令

本次使用日常办公场景、Auto 模型路由和默认权限。指令中首先声明了硬边界：

禁止修改任何输入文件，禁止访问真实生产系统，禁止执行网络请求、重启、部署、提交代码、发送消息或调用产生外部副作用的接口。

随后要求 WorkBuddy 按以下链路逐层判断：

员工 -> 会话 -> Worker -> 容器 -> Router -> 模型提供商 -> transcript -> 消息投递

输出必须包含结论摘要、已确认事实、推断与替代解释、未知项、三个问题的分别结论、继续只读检查建议，以及只有获得修改授权后才能执行的修复建议。

一个意外但很重要的细节是：WorkBuddy 发现自己的任务目录中没有那五个物理文件，因此在报告里主动注明“以内联内容为唯一证据来源”。这句话没有被删除，因为它准确说明了本次运行真正读取了什么。

四、WorkBuddy 的诊断过程

WorkBuddy 没有被 HTTP 200 或 healthy 状态带偏，而是把不同信号放回各自的系统层级。

首先，它确认员工、会话、Worker 和容器的映射一致，因此当前材料描述的是同一个目标对象。但这只能证明对象没有查错，不能证明模型产生了用户可见回答。

其次，容器已经连续运行多日，健康探针通过。该证据排除了明显的崩溃和持续不可用，但 healthy 只证明进程与探针可用，不能证明某一轮业务任务成功完成。

随后，WorkBuddy 检查模型请求摘要。该请求具有以下特征：

• HTTP 状态为 200；
• SSE 流包含 1911 个 chunk，并存在正常结束标记；
• finish_reason=stop；
• completion tokens 为 1909；
• reasoning 内容约 3111 个字符；
• 用户可见正文为 0 个字符；
• 工具调用数为 0。

这组证据说明请求在传输层正常完成，但全部有效输出落在 reasoning 通道，没有形成最终可见正文。运行时随后记录：

incomplete turn detected: ... stopReason=stop payloads=0

因此，界面上的通用错误不是容器崩溃的直接表现，而是运行时发现当前轮次没有任何可交付 payload 后给出的兜底文案。

五、三个问题的分别结论

1. 容器是否异常

现有证据不支持容器异常。容器持续运行、健康探测通过，而且大约三分钟后，用户发送“继续任务”，同一运行时和同一模型成功生成了完整分析。

这里仍然要保留边界：后续成功只能证明服务此后可用，不能证明事故瞬间不存在短暂资源压力。但当前没有容器层异常日志或指标，而模型输出层的证据已经足以解释空响应，因此不需要额外假设容器故障。

2. 是否发生机器人跨会话误投

没有发现误投证据。机器人署名的分析卡片只出现在正确的目标群聊；另外两个会话中的相似卡片已确认由用户账号转发，并非机器人外发。

另一群聊有一条已经撤回的原始消息，撤回后无法确认发送者。因此正确结论是“未发现机器人误投证据”，而不是“已经证明绝对没有误投”。

3. 空响应发生在哪一层

最一致的解释是模型提供商输出层出现了 reasoning-only 完成：HTTP 与流式传输正常结束，模型也消耗了 completion tokens，但最终正文通道为空。运行时正确检测到 payloads=0，前端因此无法渲染答案。

WorkBuddy 对三个问题的结论概览

六、WorkBuddy 交付了什么

WorkBuddy 最终生成了一份约 13.7KB 的 workbuddy-diagnosis.md，任务共消耗 14.17 Credits。报告包含：

• 按调用链排列的事实与证据表；
• 四项有证据支持的推断及替代解释；
• 七项仍未闭合的未知项；
• 三个业务问题的分别结论；
• 七条可继续执行的只读检查建议；
• 六条需要明确授权后才能实施的修复或治理建议。

修复建议包括增加空正文守卫与有限重试、改善用户侧错误文案、监控 reasoning 非空但 payload 为空的事件，以及保留撤回消息的审计归因信息。WorkBuddy 只提出建议，没有执行任何修改。

WorkBuddy 生成的完整诊断报告

七、这次实践真正有价值的地方

这次结果并不是“AI 神奇地找到了根因”。真正有价值的是，WorkBuddy 把原本分散在容器状态、请求记录、模型返回、transcript 和消息投递中的证据，组织成了能够交接和复核的结构。

它还避免了三个常见误判：

• HTTP 200 不等于内容成功；
• 容器 healthy 不等于业务任务成功；
• 相同卡片出现在多个会话，不等于机器人发生串群。

对于企业 Agent 来说，可审计的证据边界往往比一个过度确定的“根因结论”更重要。只有把事实、推断和未知项分开，后续修复、复盘和上线治理才不会建立在错误前提上。

八、适用范围

这套方法适合已有日志、请求记录和消息记录，但材料分散、容易跨层误判的 Agent 故障。它不适合在缺少原始证据时凭截图猜测，也不能替代企业的生产权限、数据合规和变更流程。

本次是一次真实事故的脱敏回放，不是对生产环境的实时操作。后续可以将这套流程封装成 WorkBuddy 专家或只读 Connector，用于企业 Agent 上线体检、事故复盘和日常可靠性治理。