故障分类与检测
生产级 Harness 会遇到哪四层故障？
| 层级 | 典型故障 | 性质 |
|---|---|---|
| API 层 | 限流（HTTP 429）、服务过载、请求超时、连接中断、输出触顶被截断 | 与任务内容无关的基础设施噪声 |
| 工具层 | 幻觉调用（工具不存在）、参数畸形、执行抛异常、反复返回同一错误而模型不加改变地重试 | 最危险的是无效重试 |
| 上下文层 | 上下文窗口溢出、压缩失败、轨迹结构损坏（工具调用缺少配对的结果消息） | 结构类故障 |
| 控制流层 | 死循环（反复执行相同操作毫无进展）、死亡螺旋（恢复逻辑自身再调 LLM 又出错） | 系统性失效 |
- 前提: 分类是系统应对的第一步;
- 严重性参照: 仅缺失一条工具结果反馈就足以让 Agent 陷入无限循环;
捕获故障后的第一个判断是什么？
- 判断: 不是“要不要重试”，而是“值不值得重试”;
- 可重试: 限流、过载、网络抖动——重试才有意义;
- 不可重试: 参数不合法、权限不足、工具不存在——原样重试结果相同，必须改变输入或策略;
- 实现: 生产级 Harness 维护一张错误到恢复策略的映射表，而非笼统地“出错就重试”;
除了单次错误还要检测什么模式？
- 重复调用指纹: 对“工具名 + 参数”计算指纹，相同指纹反复出现就是无进展循环的明确信号;
- 连续失败计数: 每条恢复路径维护独立计数器，作为熔断依据;
哪些故障不表现为错误？
- 现象: 流式连接最危险的失败不是断开（会立即报错），而是静默卡死——连接建立成功但数据流停止;
- 盲区: SDK 超时机制往往只覆盖初始连接而非传输过程;
- 手段: 独立的空闲看门狗，超过设定时间没有新输出就判定卡死，主动杀死挂起的流并触发重试;
- 推广原则: 每个长连接都需要活性信号，而非仅依赖连接超时;
完整性监控管什么？
- 对象: 轨迹结构;
- 规则: 发现工具调用缺少配对的结果消息时，在注入上下文前自动修复配对关系，而不是把结构异常抛给模型或用户;
- 双模式细节: 部分生产级 Agent 同时运行产品模式与训练数据收集模式——产品模式可用占位符修补缺失消息，训练模式拒绝修复，因为合成占位符会污染训练数据;
- 含义: “产品宽容、训练严格”的双重标准体现 Harness 与模型训练的深度耦合;
相关机制在哪里展开？
- 检测之后的分级恢复、熔断与终止: 见 错误恢复与终止熔断;
- 工具层错误如何变成模型输入: 同一篇;
- 通用五要素中的“纠正”定位: 见 Harness 工程;