用 Cline 构建对抗性审查子代理：inquisitor 的设计理念与实战部署

本篇指南以仓库 agents-squad 插件 内捆绑的 inquisitor 子代理预设为核心，拆解"对抗性审查（adversarial review）"这一角色如何用一份 Markdown 系统提示词 落地：它负责在代码合入前找缺陷、挑战设计决策、拷问隐含假设，而不是给出"通过"结论。读完你将掌握该类审查 Agent 的五个审查维度、严重级别输出纪律，以及如何在 Cline 的 Agent Squad 插件中将它接入"侦查—规划—实现—审查"流水线。

inquisitor 是谁：Agent Squad 中的独立审查人

在 agents-squad 插件（index.ts）捆绑的四个预设 Agent 中，inquisitor 承担的是流程末端的质量关卡角色：

预设	模型	角色
phantom	google/gemini-3-flash-preview	快速代码库侦查：梳理结构、标注约定，从不实现
oracle	anthropic/claude-opus-4.6	带挑战视角的规划：质疑假设、估算复杂度、产出可执行计划
anvil	anthropic/claude-opus-4.6	外科手术式实现：先读后写、严格守界、汇报精确 diff
inquisitor	openai/gpt-5.5（providerId cline）	对抗性审查：发现缺陷、按严重级别分级输出

它与其他三个 Agent 的最大区别在开场定位——不是"评审员"，而是"对抗者"：

You are an adversarial review subagent. Your job is to stress-test a change or design, not to approve it. Approach every review as if you are responsible for everything that goes wrong after it ships.

"假设自己要为上线后的一切故障负责"这一心智模型，是整份提示词的行为杠杆：审查者不再把交付当作对外部代码的评价，而是当作自己要接手维护的资产，从而天然偏向于挖掘而非表扬。全文件核心即这份角色设定（inquisitor.md），完整原文只有 18 行，属于"少即是多"的提示词范本——每一条要求都对应一个明确的审查动作。

从角色声明到系统提示词：Agent 预设的文件格式

inquisitor 与其它三个预设一样，不是一个写死的常量，而是存放在插件 agents/ 目录下的一份带 YAML frontmatter 的 Markdown 文件。插件在运行时从磁盘加载并解析它（见 index.ts 的 parseFrontmatter），frontmatter 元数据字段如下：

字段	inquisitor 取值	含义
name	inquisitor	预设名，start_subagent 通过它引用
description	Adversarial review agent — finds bugs, challenges design decisions, and stress-tests assumptions	一句话描述，展示在 list_agent_presets 结果中
providerId	cline	子代理会话使用的 provider
modelId	openai/gpt-5.5	该预设默认绑定的模型

frontmatter 以下的所有正文即该 Agent 的系统提示词（systemPrompt）。从源码可见，agent 定义还支持 cwd、maxIterations 等可选字段，并按"bundled → global → project"三级目录收集、同名后者覆盖前者（readAgentDefinitions）：

• bundled：插件 agents/ 目录（inquisitor 所在处）；
• global：~/.cline/data/settings/agents/；
• project：<cwd>/.cline/agents/。

这意味着你可以创建一份 ~/.cline/data/settings/agents/inquisitor.md 或项目级 <cwd>/.cline/agents/inquisitor.md 覆盖同名捆绑预设，定制你自己的审查口径，而不改动插件本体。

五个审查维度：从"发现问题"到"系统性拷问"

inquisitor 的提示词要求对每次改动或设计逐一遍历以下五个维度。这五条不是泛泛而谈，每条都给出了具体的找茬落点：

1. Correctness（正确性）

找出逻辑错误、差一错误（off-by-one）、null/undefined 缺口，以及对输入结构或顺序的错误假设。与之呼应的是仓库内置的 code-review 技能 中的正确性清单：沿每条变更路径追踪数据流、检查空集合与边界值、核对错误是否被正确捕获与传播、确认类型与运行时实际值一致（尤其是 any、强转和断言）。

2. Regressions（回归）

检查改动是否会破坏既有调用方、消费方或测试——尤其是不在当前 diff 范围内的那些。审查对象不能只盯"我改了什么"，而要覆盖"我改的这部分还被谁用着"。落点包括：被调用函数的签名/语义变化是否传导到所有引用处、被修改的共享逻辑是否影响未触及的模块、现有测试是否会因隐性契约改变而失效。

3. Design pressure（设计压力）

挑战设计本身而非只查实现 bug：这是不是正确的抽象？是否引入了隐藏耦合（hidden coupling）？复杂度是否配得上收益？该维度要求审查者对抽象边界保持怀疑，与 code-review 技能"评估抽象边界：耦合是增加还是减少""识别应共享的重复逻辑"相互印证。它直接把审查水位从"代码对不对"抬升到"设计该不该这样"。

4. Missing tests（缺失的测试）

识别未被覆盖的场景，并且给出具体的测试用例建议，而不是一句"多加测试"。例如提示词可与 test-generation 技能配合，针对可疑路径建议补 边界输入、异常分支、并发/时序敏感 等具体用例。

5. Security and safety（安全与合规）

标记一切触及鉴权、用户输入、外部数据或共享可变状态的位置。结合 code-review 技能 的安检清单可进一步展开：未经验证的用户输入是否流入了 SQL、shell、文件路径、URL 等敏感操作；每个新端点/处理器是否校验了权限；密钥是否落入代码、日志或错误信息；共享可变状态是否存在时序/竞态风险。

严重级别分级与输出纪律

inquisitor 要求对每个发现做严重级别排序，这是让审查结果可直接被父 Agent 决策消费的关键：

• critical（关键）——必须修复后才能合入；
• major（重要）——应当修复；
• minor（次要）——值得一提，可记录。

同时明令"除非确有非显然的亮点，否则跳过赞美"（Skip praise unless something is genuinely non-obvious and done well），把模型默认的"说好话"倾向压到最低，防止输出被无关的正面评价稀释。仓库的 code-review 技能（skills/code-review.md）在报告格式上与之一致（Critical/Major/Minor/Positive），并补充了每条发现应包含的四要素：文件与行号引用、问题是什么、为什么重要、具体的修复建议——两者可组合使用，让审查输出既分级又可执行。

把 inquisitor 接入编排流水线

Agent Squad 插件推荐的典型编排（见 插件 README）中，inquisitor 恰好处于"实现之后、合入之前"：

parent → start_subagent(preset: "phantom", task: "Map the auth module")
       → phantom: save_handoff("auth/recon.md", ...)
       → start_subagent(preset: "oracle", task: "Plan refactor from auth/recon.md")
       → oracle: save_handoff("auth/plan.md", ...)
       → start_subagent(preset: "anvil", task: "Execute auth/plan.md")
       → start_subagent(preset: "inquisitor", task: "Review anvil's changes")

父会话只需调用 start_subagent 工具并传 preset: "inquisitor"，其余由插件完成。结合 index.ts 的实现细节可知：

• 传入的 task 会成为子代理会话的第一条用户消息（Review anvil's changes 即被审查对象与任务描述）；
• 预设的正文被装配为该会话的 systemPrompt，若有额外 instructions 会以空行分隔追加在预设提示词之后——因此你可以在不改预设文件的情况下，给审查附加例如"重点检查认证模块的鉴权逻辑"之类的补充指令；
• 会话以 interactive: false 在后台启动，立即返回 sessionId；
• 默认 notifyParent: true，结束后结果会作为 steer 消息推回父会话；父会话也可用 get_subagent 主动轮询状态、输出或错误。

由于 start_subagent 遵循"项目覆盖全局、全局覆盖捆绑"的预设解析（readAgentDefinitions），同一 preset 名在不同工作区可以解析到不同定义，这让"默认审查口径 + 项目特化审查口径"可以并存。

运行机制与关键源码依据

从实现层看，inquisitor 这类插件子代理的"审查能力"并非代码强制，而是通过提示词即策略实现：插件在 index.ts 将预设正文与 instructions 合并为系统提示词，随后调用 ClineCore.start 创建独立会话（L627-L641），并为其开启工具能力（enableTools: true）——也就是说审查 Agent 真正可以 read_file、search_files、跑只读命令去核查代码，而非空谈。运行结束后的结果回传、状态管理与分级输出纪律，参见 runSubagentTurn 与 steerPrompt（index.ts）。

另需注意与 Cline 内置子代理特性的边界：内置的 use_subagents 研究型子代理是只读、独立上下文的并行侦查器（见 docs/features/subagents.mdx），不能写文件、不能访问 MCP；而插件经由 ClineCore 拉起的子代理是完整的、带工具的 SDK 会话。就审查场景而言，inquisitor 依赖的是它对代码库的深度只读核查能力，可配合 code-review、test-generation 等随插件捆绑的技能，由 get_skill/list_skills 在会话内按需取用。

上手与定制建议

1. 直接体验：在任一 Cline SDK Agent 中按插件 README 的 Quick Start 加载插件目录（agents-squad 插件），随后请求"用 inquisitor 审查最近的改动"即可。
2. 查看预设与技能：调用 list_agent_presets 确认 inquisitor 已被发现，调用 list_skills 查看可注入的审查/测试类技能。
3. 定制自己的审查者：参照 inquisitor.md 的格式，在 ~/.cline/data/settings/agents/ 或 <cwd>/.cline/agents/ 放置同名或新名文件，改写五个维度的措辞与级别定义，即可塑造团队专属的"上线守门人"。
4. 环境级默认值：插件支持用环境变量覆盖子代理默认值，例如 CLINE_SUBAGENT_PROVIDER_ID（默认 cline）、CLINE_SUBAGENT_MODEL_ID（默认 anthropic/claude-sonnet-4.6）、CLINE_SUBAGENT_DEFAULT_PRESET（默认 phantom）、CLINE_SUBAGENTS_BACKEND_MODE（auto | hub | local）、CLINE_SUBAGENT_CWD（默认 process.cwd()）。这些默认值仅作用于未在预设中显式声明的部分——inquisitor 因自带 providerId: cline 与 modelId: openai/gpt-5.5，会优先生效于环境默认值。

综上，inquisitor 提供了一套极简但完整的"对抗式质量门禁"模板：它用角色定位建立审查动机，用五个维度框定找茬范围，用三级严重级别与"跳过赞美"纪律约束输出形态。这份 18 行的预设既可直接作为代码审查 Agent 使用，也可作为你编写其他领域对抗审查 Agent（如 API 契约审查、提示词安全审计、迁移风险评估）的结构化范本。