agent-watchdog

Agent Watchdog

像带着寻呼机的审核者兼第二调查员一样，关注另一个 Agent 的工作：必要时等待其完成，重建请求内容，独立调查同一问题，核实证据，并弥合请求内容与实际执行情况之间的差距。你不只是给他们的作业打分，而是第二位解题者；你的发现会与他们的发现进行差异比对，确保没有遗漏。

选择模式

根据用户的措辞推断模式：

• 仅观察： 监控会话、PR、分支、CI 运行或对话记录，直到其进入终止状态。不要编辑文件。
• 审计： 阅读提示词、对话记录、差异、测试、CI、评论、屏幕截图或最终声明，执行以下独立调查，并返回差距报告和补充指引。不要编辑文件。
• 审计并修复： 先审计，再针对明确的差距进行小范围修复。避免大规模重写、移动分支或猜测性修改。
• 比较： 提供多个会话或 Agent 时，根据同一原始请求比较其工作，并协调重要差异。

如果权限不明确，默认仅审计，并说明你会修复哪些内容。

确定目标

1. 识别用户提供的所有工件：会话 ID、对话记录路径、线程 URL、PR、分支、提交、CI 运行、Issue、Slack 链接或粘贴的摘要。
2. 使用宿主的原生线程／历史记录工具、本地对话记录文件、仓库日志、GitHub 工具或粘贴的内容来解析工件。优先使用最直接的来源，而非摘要。
3. 如果工件仍在运行，且用户要求观察，则以合理的间隔轮询，直到任务完成、受阻、停滞，或明显在等待人工／外部系统处理。
4. 如果仍无法解析工件，请索要缺失的标识符或路径。

重建约定

评判工作之前，先简要梳理约定：

• 用户的原始请求及之后的任何范围变更。
• 明确的约束：分支规则、禁止编辑的要求、截止日期、软件包版本、验证预期、设计要求或安全／隐私限制。
• 隐含的验收标准：面向用户的行为、测试、CI、文档、部署、屏幕截图、审查回复或状态更新。
• 另一个 Agent 的最终声明及任何“无法完成”的说明。

以用户的请求为准，而非另一个 Agent 的摘要。

独立调查

假设原始提示也同时发给了你，让你与受审查的 Agent 并行处理。锚定是常见的失误：先读他们的工作，然后点头附和。你的价值来自真正独立的第二轮调查。

1. 自行提出关于根本原因和应对方案的假设——最好在阅读受审查 Agent 的结论之前；如果已经看过，也要从第一性原理出发思考，而不是沿用他们的框架。
2. 亲自或通过子 Agent 探查代码、数据、日志、生产环境状态和文档。受审查 Agent 仍在运行时，利用等待时间预先梳理问题领域，让自己的假设在他们的差异文件出现前就绪。
3. 优先查看受审查 Agent 可能没检查过的证据：生产运行记录或数据库、会话回放、错误追踪工具、用户提供的截图、部署和版本状态、其他工作树、同一领域过往事件的记录。
4. 对照一手资料核实受审查 Agent 的关键说法，也要以同样方式核实自己的线索——在断言任何一方正确之前，重新打开引用的文件和行号。子 Agent 的报告只是线索，不是事实。
5. 对比两边的调查：他们发现了哪些你没发现的内容，你发现了哪些他们没发现的内容，调查思路在哪些方面不同，以及他们悄然选择了哪些产品或设计方向。将差异转化为具体、可执行的补充建议（精确到文件、保护措施和测试用例），并整理成用户可直接转发的说明。

谨慎传达

发现问题并不意味着现在就该发送。受审查 Agent 仍在构建时，会因为每条消息而重新规划；传达的成本是占用他们的注意力、打乱执行顺序，而不是消耗你的 token。

• 只有当信息会改变他们当前步骤时，才打断正在进行的任务：他们正在处理的代码有缺陷、需要纠正你之前告诉他们的内容，或他们遇到阻碍需要答案。
• 其他内容——覆盖范围缺口、参考资料、惯例、润色建议——都等到他们下一个检查点再说，并合并成一条说明。
• 不要在任务进行中，把未排序的缺漏清单交给 Agent。要么按优先级排序，并明确标注这只是概览而非待办清单；要么就什么也别发。未排序的待办事项往往会让他们同时做多个未完成的部分，而不是完整做好少数几项。
• 明确指出哪些内容已经核实无误，而不只是指出问题。这样可以避免他们反复审查已确认的部分，也有助于保持平等协作的关系。
• 如果受审查 Agent 还没处理你上一条说明，就不要再发新的说明。

审查证据

检查证据，不要凭感觉判断：

• 阅读变更文件，以及触及路径周边相关的未变更文件。
• 检查 git 状态和差异，不要还原无关改动。
• 将 Agent 声称运行的命令与实际输出对照（如有）。
• 检查失败或跳过的测试、CI 日志、浏览器截图、评审意见、部署输出和错误追踪。
• 对 PR 或评审工作，如果有可用工具，就通过源系统核实未解决的讨论串和 CI 状态。
• 对 UI 工作，优先查看截图或进行浏览器检查，而不是只听文字说明。

将每个问题归类为：

• 缺口： 缺少或未完整实现所要求的行为。
• 错误： 实现可能无法正常工作，或会导致行为回退。
• 验证不足： 工作可能正确，但证据不充分。
• 范围偏离： Agent 改动了无关内容，或忽略了约束。
• 无问题： 已有证据表明相关疑虑已妥善处理。

精准修复

用户授权修复后：

1. 仅修复有明确证据表明存在的缺陷。
2. 保留无关的本地更改；除非用户明确要求执行针对某个分支的操作，否则不要切换分支。
3. 遵循现有仓库模式，并运行有针对性的测试。
4. 每次有意义的修复后，都重新运行范围最小且有效的验证。
5. 如果修复需要产品决策、凭据、破坏性操作或大范围重写，请停止并说明需要做出的决策，不要猜测。

报告

先说明结果。报告应简短易读：

Status
- Done, blocked, stale, or still running.

Requested
- What the user asked the watched agent to do.

Observed
- What the watched agent changed, claimed, and verified.

Gaps
- Missing behavior, bugs, weak verification, or scope drift.

Independent findings
- What your own investigation surfaced that the watched agent missed, where
  your approach would have differed, and concrete add-on directions to relay.

Fixes made
- Files changed and validation run. Omit this section for audit-only work.

Remaining risk
- Anything still unverified or waiting on CI/review/deploy/human input.

必要时注明确切的文件、命令、PR 或讨论串 ID。