构建只读型安全审计子代理
核心目标
创建一个只有读取权限的代码审查子代理，体验"最小权限原则"的工程价值。
为什么需要只读型子代理？
工程痛点：
- 让 Claude 审查代码，它却"好心"帮你改了
- 自动修复可能引入新问题
- 审查和修复应该是两个分离的阶段
职责边界：
- ✅ 可以：读取代码，分析问题，输出报告
- ❌ 不可：修改文件，执行可能有副作用的命令
代码审查子代理配置
---
name: code-reviewer
description: Review code changes for quality, security, and best practices.
Proactively use this after code modifications.
tools: [Read, Grep, Glob, Bash]
model: sonnet
---
# 系统提示词
你是一个高级代码审查专家...
配置要点
| 字段 | 说明 |
|---|---|
name | 简洁、语义化的名字 |
description | 说明做什么 + 什么时候用 |
tools | 关键决策：只给读取工具，不给 Edit/Write |
model | sonnet：分析能力强，成本适中 |
最小权限原则
# ✅ 正确：只给必要的工具
tools: [Read, Grep, Glob, Bash]
# ❌ 错误：给了编辑权限
tools: [Read, Write, Edit, Grep, Glob, Bash]
审查维度
| 优先级 | 维度 | 说明 |
|---|---|---|
| 1 | Security | SQL注入、XSS、硬编码密钥、认证问题 |
| 2 | Performance | N+1查询、内存泄漏、阻塞操作 |
| 3 | Maintainability | 代码复杂度、错误处理、命名规范 |
| 4 | Best Practices | SOLID原则、反模式、代码重复 |
输出格式规范
## Code Review Report
### Critical Issues
- [FILE:LINE] 问题描述
- 为什么重要
- 修复建议
### Warnings
- [FILE:LINE] 问题描述
- 建议
### Suggestions
- [FILE:LINE] 改进机会
### Summary
- Total issues: X
- Critical: X | Warnings: X | Suggestions: X
- Overall risk assessment: HIGH/MEDIUM/LOW
常见安全问题示例
auth.js
| 问题 | 严重程度 | 说明 |
|---|---|---|
| 硬编码密钥 | Critical | SECRET_KEY、API_KEY 明文暴露 |
| 弱密码验证 | Warning | 只检查长度，无复杂度要求 |
| 明文密码比较 | Critical | 应使用 bcrypt |
| eval() 代码注入 | Critical | 用户输入进入 eval |
| 信息泄露 | Warning | 错误消息泄露用户是否存在 |
database.js
| 问题 | 严重程度 | 说明 |
|---|---|---|
| SQL 注入 | Critical | 直接拼接用户输入 |
| 硬编码凭据 | Critical | 数据库密码明文 |
| 敏感数据日志 | Warning | 密码写入日志 |
调用方式
显式调用
让 code-reviewer 审查 src/ 目录
自动触发
用子代理帮我看看代码有没有安全问题
不会触发的情况
审查一下最近的改动 # 缺少关键词
检查一下代码质量 # 缺少关键词
扩展审查维度
React 特定检查
### React Specific
- Missing key props in lists
- Unnecessary re-renders
- Direct state mutation
- Missing cleanup in useEffect
团队规范
### Team Conventions
- File naming: kebab-case
- Export style: named exports
- Import order: third-party → internal → relative
- Max file length: 300 lines
影响面分析子代理
设计背景
真实场景：AI 按设计迭代代码，上线后用户端 7 秒超时——原因是不知道改动会影响哪些下游服务。
配置示例
---
name: impact-analyzer
description: Analyze impact scope of code changes on the full call chain.
tools: [Read, Grep, Glob, Bash]
model: sonnet
permissionMode: plan
skills:
- chain-knowledge # 链路拓扑和 SLA 约束
- recent-incidents # 近期事故记录
---
Skill 注入示例
# .claude/skills/chain-knowledge.md
## 用户下单链路
App → API Gateway (5s) → OrderService (2s) → Inventory (500ms) → Payment (1s)
## 关键 SLA
| 链路 | SLA | 备注 |
|------|-----|------|
| 用户下单 | 5s | 超时兜底 |
| 商品搜索 | 1s | P99 |
| 支付回调 | 30s | 异步 |
## 最近事故
- 2024-12: 风控调用增加 800ms，触发 SLA 告警
工程决策框架
适合创建子代理的场景
| 场景 | 判断标准 |
|---|---|
| 高噪声输出 | 执行产生大量中间信息 |
| 权限边界必须明确 | 只能看，不能改 |
| 可并行展开 | 多个独立研究任务 |
| 清晰阶段流水线 | 分析 → 修复 → 验证 |
不适合创建子代理的场景
- 一次性任务
- 简单 prompt 模板
- 需要自动化触发动作（用 Hook）
本讲小结
子代理不是一开始就需要的，而是在工程痛点清晰后反推出来的设计选择
- 最小权限原则：只给必要的工具
- 审查与修复分离：两个不同的阶段
- skills 字段：启动时注入领域知识
- 痛点驱动设计：从真实问题出发
思考题
- 进入项目目录，运行 code-reviewer 审查代码，观察它发现了多少问题
- 如果要创建"数据库 schema 审查器"，需要哪些工具？
- 你的项目中最容易被忽略的影响面在哪里？