Open Interpreter 的 review-agent 技能剖析:只读、缺陷优先的代码审查 Skill 是怎么定义和运行的
【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter
本文围绕仓库中的 review-agent 技能定义 展开:先完整拆解这份 SKILL.md 的审查规则(审查目标、基线比较方法、缺陷判定五条件、P0–P3 严重级输出格式),再结合codex-rs/skills与codex-rs/app-server的源码,说明该技能如何作为"系统技能"内嵌进客户端、如何被/review与interpreter exec review显式触发,以及allow_implicit_invocation: false策略的含义。读完你可以完整理解一个"缺陷优先的代码审查 Agent"的技能契约设计,并能照此思路为自己的项目定制同类只读审查技能。
一、review-agent 是什么:一个内嵌的系统级代码审查技能
SKILL.md 位于codex-rs/skills/src/assets/samples/review-agent/目录下,属于 Open Interpreter 随二进制分发的"系统技能"(system skills)。它的作用由 frontmatter 一句话概括:
--- name: review-agent description: Perform a read-only, defect-first review of a specified code change and return every actionable finding. Use when another agent delegates review of uncommitted changes, a base-branch diff, a commit, or custom review instructions. ---frontmatter 只有name和description两个字段:description既是技能的自述,也是模型判断"何时该用这个技能"的依据——覆盖未提交改动、基线分支 diff、指定 commit、自定义审查指令四类目标。
与该 SKILL.md 配对的 agents/openai.yaml 声明了技能的界面元数据与调用策略:
interface: display_name: "Review Agent" short_description: "Find actionable bugs in code changes" default_prompt: "Use $review-agent to review the requested code changes and return actionable findings." policy: allow_implicit_invocation: false从 model.rs 的源码结构看,SkillPolicy.allow_implicit_invocation缺省时默认是true(见 SkillMetadata::allows_implicit_invocation),即模型可以在任务中自主联想到并调用该技能;而 review-agent 显式关闭了这一开关。这意味着:review-agent 只能被显式点名使用(例如审查入口生成的提示词、或用户直接提及该技能),模型不会在日常编码中"顺手"把它拉进来——这对一个会输出大量审查结论的技能是合理的收敛设计,避免无关会话被审查输出污染。
从源码结构看,这些samples/下的技能目录整体通过include_dir!宏编译进二进制,并在启动时解压安装到CODEX_HOME/skills/.system/下(见 lib.rs 中的SYSTEM_SKILLS_DIR与install_system_skills,并用带盐的指纹文件.codex-system-skills.marker避免每次启动重复写入)。因此在本地查看"当前版本实际生效的 review-agent 技能",应到 Open Interpreter 主目录(如~/.openinterpreter)下的skills/.system/review-agent/SKILL.md;技能发现路径的其他层级(仓库级.agents/skills/、个人级~/.agents/skills/等)可参考 docs/skills.md。
二、SKILL.md 全文规则拆解:审查契约的每一条
2.1 行为红线:只读,且不产生副作用
技能开头立即划定了四条"不许做":
Inspect the requested target directly and return every finding that the author would likely fix. Do not modify files, create commits, push branches, post review comments, or delegate the review to another agent.
即:直接检查目标本身(而不是转述别人给的信息),并且不得修改文件、创建 commit、推送分支、发布评审评论,也不允许把审查任务再委托给另一个 agent。这使 review-agent 成为一个纯"感知-推理-输出"的只读角色,即使运行在宽松的审批策略下也不会对仓库状态产生副作用。
2.2 审查流程四步
- 先读取适用的
AGENTS.md指令(项目级约定应影响"什么算问题"的判断); - 检查目标对象的完整 diff,并阅读足够的周边代码以理解每个被改动路径的上下文;
- 识别该变更引入的具体回归(concrete regressions)——找到第一个问题后必须继续审查完整个 diff,不允许"见好就收";
- 核对相关测试与调用点,确认每一条发现都是真实且可执行的(actionable)。
这四步的顺序暗含优先级:先建立项目语境(AGENTS.md),再建立变更语境(diff + 周边代码),然后才做缺陷判定,最后用测试和调用方做证据闭环。
2.3 基线分支审查:比较"实际会合并的内容"
这是 SKILL.md 中最具工程细节的一段。对 base-branch 审查(对应interpreter exec review --base main这类目标),文档明确要求:
- 比较对象应是最终会合并进基线的变更,而不是直接拿本地分支 tip 与基线做 diff(避免把本地未推送/超前提交算进审查范围);
- 若分支存在 upstream 且 upstream 领先本地分支,比较基准应解析到该 upstream;否则用本地分支;
- 具体操作:执行
git merge-base HEAD <comparison-ref>得到 merge-base,再检查git diff <merge-base-sha>; - 若本地分支无法解析,应显式尝试其配置的 upstream,之后才允许报告"目标不可用"。
这段规则本质上是把git rebase/merge的三方合并语义内化给了模型:审查的是"合入点"两侧的差异,而非两个 tip 之间的差异。
2.4 缺陷判定五条件(全部满足才可上报)
SKILL.md 规定,只有当以下条件同时成立时才允许标记一个问题:
- 它确实在正确性、安全性、性能或可维护性上有实质影响;
- 它是离散的、可执行的(discrete and actionable);
- 它是由本次被审查的变更引入的(introduced by the reviewed change);
- 受影响的场景或调用路径能从代码中被演示出来;
- 作者如果知道这个情况,大概率会去修它。
并明确排除四类噪声:臆测性担忧、既有问题(pre-existing problems)、有意的行为变更、以及不遮挡阅读的纯风格挑剔。这套"高门槛 + 白名单外全部丢弃"的规则直接对应技能名称中的 "defect-first"——宁可漏报风格问题,也不产出作者看了会反感的噪声。
2.5 输出格式:按严重级排序的发现列表
结果必须"发现优先、按严重度排序",每条问题一个条目,标题行格式固定为:
[P1] Imperative finding title — path/to/file.rs:line标题用祈使句,并以路径:行号收尾;随后跟一个短段落,说明受影响场景与行为错误的原因,引用范围要尽量小且必须与被审查的 diff 有交集(防止"指着 diff 之外大段说事")。
严重级定义如下:
| 级别 | 含义 |
|---|---|
P0 | 通用性发布阻断问题或严重故障(universal release blocker or critical failure) |
P1 | 应当紧接着修复的紧急缺陷 |
P2 | 应当修复的普通缺陷 |
P3 | 影响较低但仍值得修复的问题 |
若无任何符合条件的发现,必须原样输出No findings.,禁止为了填满结果而编造发现。发现列表之后,再给一段简短的总体评估,并提及实质性的测试缺口或残余风险。
三、源码纵深:review-agent 如何被触发与分发
3.1 审查入口:/review与interpreter exec review
用户侧的触发点在文档中有明确记载:
- 交互模式斜杠命令:
/review("Review current changes for bugs and regressions"),见 docs/interactive.md 的用法说明; - 非交互命令:
interpreter exec review --uncommitted、interpreter exec review --base main、interpreter exec review --commit abc123,见 docs/exec.md 与 docs/cli-reference.md。
注意 docs/auto-review.md 特意区分了两个概念:auto-review(approvals_reviewer = "auto_review")是把审批提示交给评审 agent 评估,而代码审查要用/review或interpreter exec review——后者正是本文的 review-agent 技能的服务目标。
3.2 Detached 交付:把技能路径写进提示词
在 turn_processor.rs 的review_start_inner中,审查请求携带thread_id、target与delivery三个参数。当交付方式为Detached时,服务端会构造如下提示词:
let review_skill_path = system_cache_root_dir(&self.config.codex_home) .join("review-agent") .join("SKILL.md"); let prompt = format!( "Use $review-agent for this review.\n\n{target_prompt}", review_skill_path.display() );即提示词显式引用安装在本机skills/.system/review-agent/SKILL.md的技能路径,让新会话加载该技能后执行审查;提交前还会用MAX_USER_INPUT_TEXT_CHARS校验输入长度,超限直接报input_too_large错误。Inline交付则走start_inline_review,在原线程内完成审查。这与 2.1 节"仅显式调用"的策略相互印证:即使是系统自带的审查流程,也是通过点名技能文件来触发的。
3.3 分发机制:编译期内嵌 + 启动时指纹安装
lib.rs 展示了这套分发如何做到"升级即更新、不升级零开销":
include_dir!("$CARGO_MANIFEST_DIR/src/assets/samples")把samples/整个目录(含 review-agent、skill-creator、qa-testing 等全部系统技能)编译进产物;install_system_skills在启动时把内嵌目录写入$CODEX_HOME/skills/.system,写入前用目录内所有文件的路径与内容哈希(外加 salt"v1")计算指纹;- 指纹与标记文件
.codex-system-skills.marker一致则跳过安装,不一致(即技能内容有变更)则先清空旧目录再整体重写。
因此 review-agent 的 SKILL.md 更新会随新版本发布自动替换本地缓存副本,无需用户手动同步。配套的单元测试(同文件末尾的fingerprint_traverses_nested_entries)验证了指纹遍历能覆盖嵌套条目。
四、实战要点与适用前提
- 调用方式:交互式会话中直接输入
/review;脚本化场景用interpreter exec review --uncommitted | --base <branch> | --commit <sha>。基线审查时,SKILL.md 的 merge-base 规则决定了审查范围是"实际会合并的变更",若你的本地分支落后于远端 upstream,比较基准会自动切到 upstream。 - 期望输出:一段按 P0→P3 排序的发现列表(
[Px] 标题 — 文件:行号+ 一段场景说明),或明确的No findings.,末尾附总体评估与测试缺口提示。可以据此在 CI 中做结构化解析:匹配行首的[P\d]即可提取发现条目。 - 适用前提:本技能依赖目标仓库可执行
git merge-base/git diff,且技能文件只从CODEX_HOME/skills/.system读取——修改本地缓存副本会被下次版本指纹校验覆盖,定制应走 docs/skills.md 所述的.agents/skills/(仓库级)或~/.agents/skills/(个人级)技能目录,同名技能以本地优先。 - 设计可复用性:如果想在 Open Interpreter 中自建一个同类"只读审查/检查"技能,review-agent 提供了完整的模板——frontmatter 只保留
name/description、用agents/openai.yaml的policy.allow_implicit_invocation: false锁死显式调用、在正文中用"红线清单 + 触发条件 + 固定输出格式"三段式约束模型行为。
综上,review-agent 技能 展示了 Open Interpreter 系统技能体系的一个完整切片:SKILL.md 负责用自然语言精确约束审查行为与输出契约,openai.yaml 负责界面与调用策略,codex-rs/skills负责编译期打包与启动期安装,codex-rs/app-server负责在审查请求中把技能路径写进提示词完成显式唤起——四层各自独立、又拼成一个可离线复现的"只读缺陷优先代码审查"能力。
【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考