Back to Details

agent-watchdog

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Agent Watchdog

Agent Watchdog

Watch another agent's work like a reviewer with a pager: wait for completion when needed, reconstruct the request, verify the evidence, and close the gap between what was asked and what actually happened.
像带着传呼机的评审员一样监控其他Agent的工作：必要时等待工作完成，还原请求内容，验证相关证据，弥补需求与实际执行结果之间的差距。

Choose The Mode

选择模式

Infer the mode from the user's wording:
  • Watch only: monitor a session, PR, branch, CI run, or transcript until it reaches a terminal state. Do not edit files.
  • Audit: read the prompt, transcript, diff, tests, CI, comments, screenshots, or final claims and return a gap report. Do not edit files.
  • Audit and fix: audit first, then make narrow fixes for clear gaps. Avoid broad rewrites, branch movement, or speculative changes.
  • Compare: when given multiple sessions or agents, compare their work against the same original request and reconcile the important differences.
If authority is unclear, default to audit-only and say what you would fix.
根据用户的表述推断适用模式：
  • 仅监控： 监控会话、PR、分支、CI运行或转录文本，直到进入终端状态。不编辑文件。
  • 审核： 读取提示词、转录文本、差异文件、测试结果、CI日志、评论、截图或最终声明，返回差距报告。不编辑文件。
  • 审核并修复： 先进行审核，然后针对明确的差距进行小幅修复。避免大范围重写、分支操作或推测性更改。
  • 对比： 当提供多个会话或Agent时，对比它们的工作与同一原始请求的匹配情况，梳理关键差异。
若权限不明确，默认采用仅审核模式，并说明会修复哪些问题。

Resolve The Target

定位目标对象

  1. Identify every artifact the user supplied: session ID, transcript path, thread URL, PR, branch, commit, CI run, issue, Slack link, or pasted summary.
  2. Use the host's native thread/history tools, local transcript files, repo logs, GitHub tools, or pasted content to resolve the artifact. Prefer the most direct source over summaries.
  3. If the artifact is still running and the user asked to watch, poll at a reasonable interval until it is done, blocked, stale, or clearly waiting on a human/external system.
  4. If the artifact cannot be resolved, ask for the missing identifier or path.
  1. 识别用户提供的所有工件：会话ID、转录文本路径、线程URL、PR、分支、提交记录、CI运行、问题工单、Slack链接或粘贴的摘要。
  2. 使用宿主原生的线程/历史工具、本地转录文件、仓库日志、GitHub工具或粘贴的内容来定位工件。优先选择最直接的来源而非摘要。
  3. 若工件仍在运行且用户要求监控，以合理的间隔轮询，直到工作完成、阻塞、停滞或明确等待人工/外部系统响应。
  4. 若无法定位工件，请求用户提供缺失的标识符或路径。

Reconstruct The Contract

还原需求约定

Build a compact contract before judging the work:
  • Original user request and any later changes in scope.
  • Explicit constraints: branch rules, no-edit requests, deadlines, package versions, validation expectations, design requirements, or security/privacy limits.
  • Implied acceptance criteria: user-visible behavior, tests, CI, docs, deploys, screenshots, review replies, or status updates.
  • The other agent's final claims and any "could not do" caveats.
Treat the user's request as the source of truth, not the other agent's summary.
在评判工作前，先构建简洁的需求约定：
  • 用户的原始请求及后续任何范围变更。
  • 明确约束：分支规则、禁止编辑要求、截止日期、包版本、验证预期、设计要求或安全/隐私限制。
  • 隐含验收标准：用户可见行为、测试结果、CI状态、文档、部署情况、截图、评审回复或状态更新。
  • 其他Agent的最终声明及任何“无法完成”的说明。
以用户的请求为唯一依据，而非其他Agent的摘要。

Audit The Evidence

审核证据

Inspect evidence, not vibes:
  • Read changed files and relevant unchanged files around the touched paths.
  • Check git status/diff without reverting unrelated work.
  • Compare commands the agent claimed to run with actual output when available.
  • Inspect failed or skipped tests, CI logs, browser screenshots, review comments, deploy output, and error traces.
  • For PR/review work, verify unresolved threads and CI state from the source system when tools are available.
  • For UI work, prefer screenshots or browser checks over prose claims.
Classify each issue as:
  • Gap: requested behavior is missing or incomplete.
  • Bug: the implementation likely fails or regresses behavior.
  • Verification miss: the work may be right but the evidence is weak.
  • Scope drift: the agent changed something unrelated or skipped a constraint.
  • No issue: the concern is already handled, with evidence.
基于证据而非主观判断进行检查：
  • 读取已更改的文件及变更路径周边的相关未更改文件。
  • 查看git状态/差异，不回滚无关工作。
  • 对比Agent声称执行的命令与实际输出（若可用）。
  • 检查失败或跳过的测试、CI日志、浏览器截图、评审评论、部署输出和错误追踪信息。
  • 对于PR/评审工作，若工具可用，从源系统验证未解决的线程和CI状态。
  • 对于UI工作，优先参考截图或浏览器检查结果而非文字声明。
将每个问题分类为：
  • 差距： 请求的行为缺失或不完整。
  • Bug： 实现可能导致功能失败或退化。
  • 验证缺失： 工作可能正确，但证据不足。
  • 范围偏离： Agent更改了无关内容或违反了约束条件。
  • 无问题： 相关问题已得到处理，且有证据支持。

Fix Narrowly

精准修复

When the user authorized repair:
  1. Fix only gaps with clear evidence.
  2. Preserve unrelated local changes and do not move branches unless explicitly asked for that branch operation.
  3. Use existing repo patterns and targeted tests.
  4. Re-run the smallest useful validation after each meaningful fix.
  5. If a fix would require a product decision, credential, destructive action, or broad rewrite, stop and report the decision instead of guessing.
当用户授权修复时：
  1. 仅修复有明确证据的差距。
  2. 保留无关的本地更改，除非明确要求进行分支操作，否则不移动分支。
  3. 使用仓库现有的模式和针对性测试。
  4. 每次进行有意义的修复后，重新运行最小范围的有效验证。
  5. 若修复需要产品决策、凭证、破坏性操作或大范围重写，停止操作并报告该决策需求，而非自行猜测。

Report

报告

Lead with the outcome. Keep the report short enough to scan:
md
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.

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.
Name exact files, commands, PRs, or thread IDs when they matter.
以结果开头。报告需简洁易读：
md
状态
- 已完成、阻塞、停滞或仍在运行。

需求内容
- 用户要求被监控Agent完成的工作。

执行情况
- 被监控Agent做出的更改、声明及验证内容。

存在差距
- 缺失的功能、Bug、验证不足或范围偏离。

已修复内容
- 更改的文件及运行的验证操作。仅审核模式下省略此部分。

剩余风险
- 任何尚未验证或等待CI/评审/部署/人工输入的事项。
当相关时，明确列出具体文件、命令、PR或线程ID。