用配置文件创建Claude Code审查助手

Claude Code 的子代理（subagent），可以把代码审查这类任务交给一个专门的助手：它有独立的上下文、自己的提示词，以及受限的工具和权限，最后把摘要交回主对话。

原文给出了一份可直接保存的审查代理配置。它的价值在于把任务职责、可用工具和调用方式写清楚，减少主对话承接的大段中间信息。不过，作者没有提供效果测试，配置能跑通和审查质量可靠，仍然是两件事。

子代理解决的是主对话里什么问题

一次代码审查可能需要搜索文件、阅读实现，再给出建议。如果这些过程都放在主对话里，就会产生大量文本。

子代理的做法是把这部分工作放进自己的上下文窗口，再返回摘要。主对话接收的是整理后的结果，不必承接全部过程。

子代理的关键是独立处理任务，再把结果收拢回来。

原文还强调了专用提示词、受限工具和独立权限。这几项分别回答：它负责什么、能用什么完成任务、可以执行哪些操作。作者给出的例子是代码审查，职责比较明确，适合用来理解这种分工。

但原文没有展示实际执行记录，也没有测量上下文节省量、耗时或审查准确率。这里讲的是工作机制和配置方法，不能据此断言一定更快或更省。

一个只读代码审查代理怎么写

项目内的配置保存到 .claude/agents/code-reviewer.md；希望所有项目都能使用，则放到 ~/.claude/agents/。

下面是原文的完整配置，它用提示词限定审查职责，并通过工具列表限制可用能力：

---
name: code-reviewer
description: "Revisa código en busca de calidad y buenas prácticas"
tools: Read, Glob, Grep
model: sonnet
---

Eres un revisor de código. Al ser invocado, analiza el código y da
retroalimentación específica y accionable sobre calidad, seguridad
y buenas prácticas.

重点看 tools: Read, Glob, Grep：示例只列出读取和查找工具，没有列出写入工具。提示词则要求代理围绕质量、安全和良好实践，给出具体、可执行的反馈。

model: sonnet 指定了模型，但原文没有给出具体版本，也没有解释为什么选择它。

字段规则比配置长度更值得留意：只有 name 和 description 必填，字段名区分大小写，写错的字段会被静默忽略。配置文件能被读取，不代表每个字段都生效。尤其是工具限制，不能只看文件里「写了什么」，还要核对字段拼写。

创建后有三种调用方式：用自然语言提出请求，输入 @ 后选择代理，或者启动会话时执行 claude --agent code-reviewer。原文没有进一步说明自然语言调用的选择规则，也没有展开多代理协作。

我的判断

这个例子最有用的地方，是把「请帮我审查代码」变成了一份可以重复使用的明确配置。职责写在提示词里，工具单独列出，项目级和跨项目的存放位置也有区分。

对于偶尔一次的审查，在主对话里直接说明要求同样可行。如果审查会反复进行，或者阅读、搜索过程会产生很多文本，独立子代理才更有使用理由。这是基于其工作机制的判断，作者没有给出两种方式的对照数据。

我会保留两个问号。第一，独立上下文返回摘要后，哪些证据会被省略，原文没说清。第二，「质量、安全、良好实践」仍是比较宽泛的要求，不能保证代理理解项目自己的规范。

受限工具能约束操作范围，审查结论仍然需要核验。

能拿来做什么

• 在前端或 Node 项目里，将示例保存到 .claude/agents/code-reviewer.md，把重复使用的审查职责固定下来，再按项目约定补充检查要求。
• 初次使用时保留 Read, Glob, Grep 这组工具，让代理先负责发现和解释问题，再由开发者决定如何修改。
• 核对 name、description、tools、model 的大小写和拼写，尤其不要把字段被静默忽略误判成配置已经生效。
• 调用审查代理时，要求反馈附带文件位置、相关代码和判断理由，便于回到实现中验证，也能减少摘要遗漏证据带来的困扰。