Agent Watchdog 用于监督另一个智能体的工作，像带寻呼机的审查者一样：必要时等待完成、重建请求、核验证据，并指出所要求与实际结果之间的差距。
主要模式
- 仅监视：监控会话、PR、分支、CI 运行或转录，直到进入终态；不编辑文件。
- 审计：阅读提示、转录、diff、测试、CI、评论、截图或最终声明，返回缺口报告；不编辑文件。
- 审计并修复：先审计，再针对明确缺口做窄范围修复，避免大范围重写、移动分支或推测性改动。
- 比较：给定多个会话或智能体时，基于同一原始请求比较其工作并调和重要差异。 权限不明确时默认仅审计，并说明会修复什么。
使用方式 先确定用户提供的所有工件：会话 ID、转录路径、线程 URL、PR、分支、提交、CI 运行、issue、Slack 链接或粘贴的摘要。优先使用最直接来源而非摘要。若工件仍在运行且用户要求监视，则以合理间隔轮询直至完成、阻塞、停滞或明显等待人工/外部系统。无法解析时，询问缺失的标识符或路径。
审计逻辑 在判断前构建紧凑契约：原始用户请求及后续范围变更、显式约束、隐含验收标准、被监督智能体的最终声明与“无法完成”说明。以用户请求为事实来源，而非被监督智能体的摘要。检查证据而非感觉：读取变更文件及相关未变更文件，检查 git status/diff 且不回退无关工作，比较声称运行的命令与实际输出，检查失败或跳过测试、CI 日志、浏览器截图、审查评论、部署输出与错误追踪。对 PR/审查工作，在工具可用时从源系统验证未解决线程与 CI 状态；对 UI 工作，优先截图或浏览器检查而非文字声明。问题分类：缺口（缺少或未完成所要求行为）、缺陷（实现可能失败或导致回归）、验证缺失（可能正确但证据薄弱）、范围漂移（改动无关内容或跳过约束）、无问题（已有证据表明已处理）。
修复与报告 仅在用户授权修复时行动：只修复有明确证据的缺口，保留无关本地更改，除非明确要求否则不移动分支，沿用现有仓库模式与针对性测试，每次有意义修复后重跑最小有效验证。若修复需要产品决策、凭据、破坏性操作或大范围重写，应停止并报告决策而非猜测。报告先给结果，包含状态、请求、观察、缺口、已做修复、剩余风险，并在重要时给出确切文件、命令、PR 或线程 ID。
限制 资料未提供具体安装方式、收费、平台支持或效果数据。