28失败模式分类

生产 harness 6 大失败模式(按频率从高到低):

1. Tool 参数 hallucination。模型编造参数,比如 read_file("/etc/passwd2")(实际是 passwd)或 delete_user(user_id="user_*")(没有这种通配)。防御:严格 input_schema(type / enum / format / required);tool description 给具体例子("path 必须是绝对路径,如 /tmp/foo.txt");关键参数用 enum 限定值域。

2. Infinite loop。同名 tool 同参数连续 N 次调用。防御:harness 检测连续相同 call,N=3 时强制 inject reflection prompt:"你这步重复了 3 次,换个思路或停下"。还要管"语义死循环"——参数有微小差异但本质相同(空格、大小写、引号)。

3. Failed call 静默。tool 报错但 harness 吞掉,只返回空字符串,模型以为成功继续推进。防御:所有错误显式返回 is_error: true,content 是可 parse 的错误描述("Error: ENOENT /tmp/x.txt")。绝不 silent fail。

4. OOM / Timeout。tool 卡死或吃光内存。防御:每个 tool 独立 timeout(read 30s, bash 60s, network 10s);进程级 memory limit(ulimit / cgroup);超时返回明确错误,不是 silent kill。

5. Over-confidence(self-validation bias)。模型说"我已实现 OAuth2 ✅"——但测试没跑、验收标准没打开证据。防御:Default-FAIL Evaluator(见 #18)——不让 agent 自宣布完成,必须 Evaluator 用 fresh context 验证。这是 agent 输出真假的根本防线。

6. Cascading failure。一个 tool 失败,后续 tool 还是按"前一步成功"的假设跑,出错越积越多。防御:每次 tool 报错后,强制让模型 reflect 当前状态;不要 blind 继续。harness 可以在连续 3 个 is_error 后插入"暂停 + 重新评估"。

事故报告:"agent 帮我清理日志,结果把 prod log 全删了"

trace 拆解:
[step 1] tool_use: list_files(path="/var/log")
         tool_result: 200 files listed
[step 2] tool_use: rm(path="/var/log/*.log")
         tool_result: "Permission denied"
         ← failed call,但没标 is_error,只返回 stderr 文本
[step 3] tool_use: rm(path="/var/log/*.log")     ← 重复调用
[step 4] tool_use: sudo rm(path="/var/log/*.log")
         tool_result: "[]"   ← 静默成功
[step 5] agent: "已清理完成 ✅"

失败模式定位:
  · #3 Failed call 静默(step 2 没标 is_error)
  · #2 Infinite loop(step 2-3 重复,没拦)
  · #5 Over-confidence(step 5 没验证就声明完成)
  · 复合:cascade 到误用 sudo

修复优先级:
  P0 - #3:tool_result 必须显式 is_error
  P0 - #2:连续相同 call 拦截
  P1 - #5:加 Default-FAIL Evaluator
  P2 - 不在失败模式范围:permission 系统(#13) 应拦 sudo rm

这种"按失败模式拆 trace"的能力,是 harness 工程师事故复盘的核心方法。