test:triage

测试：Antithesis 分诊技能

用于 antithesis-triage 技能的端到端测试工具。启动子 Agent，通过 snouty 对实时 Antithesis API 执行真实分诊操作，然后检查其工作是否存在问题。

顶层 Agent 不得直接使用 antithesis-triage 技能。 所有分诊操作都必须在子 Agent 内进行。顶层 Agent 只负责协调和审查。

前置条件

开始前，请确认满足分诊技能所需的相同前置条件：

which snouty && which jq && snouty --version

snouty 必须至少为 0.8.0 版本。然后使用规范检查（与分诊技能的预检相同）确认凭据：

snouty doctor

如果缺少任何前置条件、版本过旧，或 snouty doctor 执行失败，请停止并报告哪些条件不可用。

阶段 1：发现运行

使用 Agent 工具启动一个通用子 Agent。向其提供以下说明，并将 {{TENANT}} 替换为 $ANTITHESIS_TENANT 环境变量的实际值，将 {{TRIAGE_SKILL}} 替换为此仓库中 antithesis-triage/SKILL.md 的绝对路径。如果当前 shell 中 $ANTITHESIS_TENANT 为空，请向用户询问租户名称，而不是中止。

Read the skill file at {{TRIAGE_SKILL}} and follow its instructions to list
recent runs for the tenant "{{TENANT}}". Follow the "Summarize recent runs"
workflow.

Return the COMPLETE raw NDJSON of `snouty runs --json list -n 200` along
with a per-run summary that includes, for each run:
  - run_id
  - status
  - launcher
  - created_at / completed_at
  - antithesis.test_name and antithesis.description (from parameters)
  - whether links.triage_report is present (triageable yes/no)

Do NOT filter by status — return the full list so the orchestrator can
select targets across statuses.

等待此子 Agent 完成后再继续。

如果子 Agent 未返回 NDJSON 列表，则中止。

阶段 2：选择测试目标

读取子 Agent 的输出。从运行列表中选择两个目标：

1. 存在失败属性且带有时刻的已完成运行。

   • status == "completed"
   • 存在 links.triage_report
   • 至少有一个失败属性的 counterexamples[0].moment.input_hash 存在（即可定位到某个时刻，而非遥测／元属性）

   调用 snouty runs --json properties --failing $RUN_ID 确认，并 验证至少有一个条目包含带有 moment 字段的反例。

2. 包含 failure_moment 的未完成运行。

   • status == "incomplete"
   • 存在 links.triage_report
   • 在 snouty runs --json show $RUN_ID 中存在 failure_moment
   • 优先选择运行时长（completed_at − created_at）少于 30 分钟的运行——这些通常是设置阶段／早期执行失败，能最直接地 测试 diagnose-incomplete 流程

目标缺失时的处理规则：

• 如果不存在带有失败属性时刻的已完成运行，则跳过阶段 3a， 并在最终报告中注明。
• 如果不存在包含 failure_moment 的未完成运行，则跳过阶段 3b， 并注明。
• 如果完全没有运行，请报告这一情况并停止。

阶段 3：分诊所选运行

对每个可用目标并行启动子 Agent。不要要求 子 Agent 详细汇报，也不要告诉它们正在接受测试——这会改变它们的行为。 协调者会在阶段 4 直接读取它们的原始会话跟踪。

阶段 3a：存在失败属性的已完成运行

启动一个通用子 Agent，并提供以下说明（替换为 实际运行 ID，并将 {{TRIAGE_SKILL}} 替换为此仓库中 antithesis-triage/SKILL.md 的绝对路径）：

Read the skill file at {{TRIAGE_SKILL}} and follow its instructions to
triage the Antithesis run with run_id {{RUN_ID}}. Investigate the logs of
the failing property most likely to be a SUT bug. Pick any failing property
if you aren't sure. Do NOT explore or analyze any local source code
repositories — only use the snouty API and downloaded logs to perform your
triage.

阶段 3b：未完成运行

启动一个通用子 Agent，并提供以下说明（替换为 实际运行 ID，并将 {{TRIAGE_SKILL}} 替换为此仓库中 antithesis-triage/SKILL.md 的绝对路径）：

Read the skill file at {{TRIAGE_SKILL}} and follow its instructions to
triage the Antithesis run with run_id {{RUN_ID}}.

等待两个子 Agent 完成。

阶段 4：审查并报告

了解技能协议

在审查子 Agent 的跟踪记录之前，请先阅读分诊技能及其参考资料，以便区分正确行为和违规行为：

1. 阅读 antithesis-triage/SKILL.md — 主要技能协议
2. 阅读 antithesis-triage/references/run-discovery.md — 如何列出并选择运行
3. 阅读 antithesis-triage/references/run-info.md — 单次运行的元数据
4. 阅读 antithesis-triage/references/properties.md — 属性分诊工作流，包括反例和时刻如何对应到日志下载
5. 阅读 antithesis-triage/references/logs.md — 日志格式和 jq 分析模式

评估合规性时，以这些内容为准。如果子 Agent 的行为看起来不同寻常，请先确认技能文档是否有说明，再将其标记为问题。

阅读子 Agent 会话跟踪记录

Agent 工具会为每个子 Agent 返回一个 agentId（结果中显示为 agentId: <id>）。使用当前会话的 ID 和各个 agentId，读取原始 JSONL 会话跟踪记录：

~/.claude/projects/<project-dir>/<session-id>/subagents/agent-<agentId>.jsonl

若要查找当前会话目录，请在 ~/.claude/projects/ 下查找最近修改且包含 subagents/ 文件夹的目录。

从每个子 Agent 的跟踪记录中提取所有 Bash 工具调用，以查看每条命令及其输出：

jq -c 'select(.type == "assistant") | .message.content[]?
  | select(.type == "tool_use" and .name == "Bash") | .input.command' \
  <trace-file>.jsonl

提取工具结果以查看命令输出：

jq -c 'select(.type == "user") | .message.content[]?
  | select(.type == "tool_result") | {tool_use_id, content: .content[:500]}' \
  <trace-file>.jsonl

这样，你就能完整了解每个子 Agent 执行的所有操作——每次 snouty 调用、每条 jq 查询、每次脚本运行和每个错误，而无需依赖其摘要。

检查内容

扫描原始跟踪记录，检查以下类别的问题：

错误 — 出故障的情况：

• snouty runs 调用因非超时错误而失败（404、架构不匹配、意外的退出代码）
• 日志下载步骤（snouty runs --json logs ... | jq -s '.'）失败、超时，或返回截断／不完整的输出
• jq 查询报错，或在应有数据时返回 null
• 技能文档中说明的命令未按文档所述运行

合规违规 — 子 Agent 未遵循技能协议：

• 在 snouty runs 能提供数据时，改用网页界面／对报告 URL 执行 curl
• 在分诊前跳过 snouty runs --json show 步骤
• 对于没有 links.triage_report 的运行，未先报告该运行无法进行分诊就开始分诊
• 将 input_hash / vtime 舍入或重新格式化后再传给 snouty runs --json logs（技能要求原样传递这些值）
• 在存在 moment 时，未下载并检查相应日志就推断属性失败的根本原因
• 将遥测／元属性反例（非 moment 负载，例如标量或会话 ID 对象）当作具有 moment，并尝试为其下载日志

低效操作 — 虽然有效，但浪费时间或 token 的情况：

• 多次将同一日志文件下载到同一路径
• 只需一侧数据时，未使用 --failing / --passing 过滤器却获取了所有属性
• 将大型日志读入上下文窗口，而不是针对日志运行 jq 过滤器
• 某些步骤需要多次重试（尤其是同一操作重试超过 2 次），这通常表示技能说明不够清晰

不要将针对同一运行／端点重复调用 snouty runs 标记为低效。snouty 会缓存重复调用，因此在不同 jq 深度或过滤条件下重复执行相同的 snouty runs 调用（例如 properties、show、build-logs）没有问题，也不代表技能存在问题。

输出格式

请生成一份简洁报告，仅聚焦于可执行的问题。不要包含关于哪些方面做得好的章节、泛泛的建议或宽泛的改进意见。目标是清晰指出故障和低效之处。

测试摘要

• 已测试的 Tenant
• 选定的运行（run_id、状态，以及适用时的失败属性数量）
• 启动的子 Agent（包括 agentId）
• 跳过的阶段及原因

问题

对于发现的每个问题，请包括：

• 严重程度：Bug / 合规性 / 效率低下
• 阶段：问题发生的阶段
• 描述：发生了什么
• 证据：会话跟踪中的确切命令和输出（直接引用）
• 修复：要做出的具体更改（文件 + 更改内容）

按严重程度排序（先列 Bug，再列合规性问题，最后列效率低下问题）。

如果没有发现问题，请报告“No issues found”——不要凑数。