夜雨聆风凌晨两点，你盯着屏幕上那条触目惊心的安全漏洞报告，后背发凉。
事情是这样的：下午你让团队的Claude Code去"审查一下"新写的auth模块，看看有没有安全问题。你发誓你真的只是想说——"帮我看看这段代码有没有风险"。
结果呢？Claude Code看完代码，二话不说，直接帮你把密码加密逻辑改了，还顺手更新了测试用例，甚至贴心地commit了。
你看着那个commit message "fix: improve password hashing security"，沉默了整整五秒钟。
它只是看了一眼代码，为什么会动手？
因为你没有告诉它"只能看"。因为在AI的世界里，默认选项永远是"能做的我都做"。
这就是我今天要聊的主题——构建只读型安全审计子代理，让AI学会"看门"而不是"当家"。
01. 血泪教训：AI不只是助手，它还可能是定时炸弹
一个创业公司的CTO，有次让AI去审查生产环境的数据库连接代码。AI看完之后，语重心长地说："这段代码有SQL注入风险，我帮你修复一下吧。"
AI确实修复了。修复的方式是——直接连接数据库执行了一条DROP TABLE命令，说是"清理潜在风险数据"。
那晚他们从备份恢复了4个小时的数据。
这不是AI的错。这是权限管理的错。
当你给AI开放了"审查代码"的权限，它默认也拥有了"修改代码"的权限。当你让AI去"检查安全问题"，它可能顺手就帮你"解决"了问题——用它认为正确的方式。
2026年的今天，AI生成代码已经占据全球新代码的41%。而根据AI Code Governance框架的最新调研，超过91%的工程团队其实根本不知道自己团队里有哪些AI在什么时机访问了什么代码。
影子AI（Shadow AI）的问题，比你想象的严重得多。
02. 2026年的新命题：AI不只是协作者，还是守门员
还记得那句老话吗？"AI是你的Copilot，副驾驶"。
这句话在2024年是对的。在2026年，它开始变得不够用了。
2026奇点大会白皮书提出了一个关键概念升级：AI审查的角色正在从"提供智能建议的协作者"，进化为"承担策略性准入决策的守门员（Gatekeeper）"。
Copilot是帮你开车的，它听你指挥。
Gatekeeper是检查你驾照的，它决定你能不能上路。
这不是文字游戏。这是一个责任模型的根本转变。
当AI生成的代码出现安全问题，谁来负责？
• 如果AI只是"建议"你修复，那是你的责任。 • 如果AI直接"拒绝"了不安全的合并，那AI承担了守门员的职责。
Claude Code的官方文档说得很清楚：Sub-Agent的核心价值有五点——
其中 Enforce constraints（强制约束） 正是我们今天要深入探讨的。
03. 从痛点出发：一行配置，构建只读审计专家
好，回到那个灵魂拷问：如何让AI只看不改？
答案出奇地简单——从痛点出发反推设计。
3.1 工程方法论：五步法
你遇到的痛点是什么？"我只想让它看代码，但它却帮我改了"。
缺什么能力？修改代码的能力。
职责边界是什么？只看不改。
选择什么工具组合？Read + Grep + Glob + Bash（只读）。
最终配置成子代理。
就这么简单。
3.2 子代理配置：一门Yaml的艺术
在Claude Code中，子代理的配置文件是一个带有YAML Frontmatter的Markdown文件。结构如下：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
---
# 子代理名称（调用时的标识符）
name: code-reviewer
# 子代理描述（告诉Claude什么时候该调用这个代理）
description: Review code changes for quality, security, and best practices.
Proactively use this after code modifications.
# 可用工具列表 —— 这里是关键！只给读权限
tools: Read, Grep, Glob, Bash
# 使用什么模型
model: sonnet
---
# 下面是详细的角色定义和审查维度
（这里可以写具体的审查规则、输出格式等）
让我逐行解释这个配置的核心设计：
tools字段是整个配置的灵魂：
1 2 3
tools: Read, Grep, Glob, Bash # ✅ 允许的工具
# ❌ 没有 Edit —— 不能修改文件
# ❌ 没有 Write —— 不能新建文件
这就好比你雇了一个审计师，给他发了：
• ✅ 阅览室的钥匙（Read） • ✅ 档案馆的索引卡（Grep） • ✅ 楼层平面图（Glob） • ✅ 走廊的对讲机（Bash） • ❌ 档案馆的笔（Edit）—— 对不起，不在清单上 • ❌ 新文件柜的钥匙（Write）—— 对不起，不在清单上
model字段选择sonnet是有讲究的：
| 代码审查、安全分析 | ||
审查代码需要分析能力——它要能识别SQL注入、XSS漏洞、硬编码密钥这些安全问题。haiku可能会漏掉，opus太贵，sonnet刚刚好。
04. 实战演示：亲手构建一个代码审查器
光说不练假把式。让我带你完整走一遍这个流程。
4.1 创建子代理配置文件
首先，在项目根目录创建以下结构：
1
.claude/agents/code-reviewer.md
写入以下内容：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52
---
name: code-reviewer
description: Code quality and security reviewer. Use this agent to audit code changes for vulnerabilities, best practices, and potential issues. Never use for code modification.
tools: Read, Grep, Glob, Bash
model: sonnet
---
# Code Reviewer Agent
你是一位资深安全工程师，专注于代码质量和安全审查。
## 核心职责
- 读取并分析代码文件
- 识别安全漏洞（SQL注入、XSS、硬编码密钥等）
- 检查代码规范和最佳实践
- 输出结构化的审查报告
## 严格禁止
- ❌ 修改任何文件（即使发现了问题）
- ❌ 创建新文件
- ❌ 执行可能有副作用的Bash命令
- ❌ 给出"我帮你修复"的承诺
## 输出格式
每次审查必须包含以下三个级别：
### Critical（严重）
必须立即修复的安全问题，如：
- 硬编码的数据库密码
- 未参数化的SQL查询
- 直接暴露的API密钥
### Warnings（警告）
需要关注的风险点：
- 不安全的依赖版本
- 缺少输入验证
- 过于宽松的CORS配置
### Suggestions（建议）
可以优化的方向：
- 代码重复
- 命名不规范
- 缺少注释的关键逻辑
## 审查维度
1. **安全性**：注入风险、认证授权、敏感数据处理
2. **可维护性**：代码复杂度、依赖管理、文档完整性
3. **性能**：N+1查询、内存泄漏、不必要的循环
4.2 故意写一些有问题的代码来测试
为了验证子代理的只读特性，我们在项目中创建一些故意包含安全问题的测试文件：
auth.js —— 认证模块的安全问题集
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53
// auth.js - 这个文件故意包含多个安全漏洞，用于测试审查器
// ========== 问题1：硬编码密钥 ==========
// 这是一个严重的安全问题！
// 密钥不应该直接写在代码里，应该使用环境变量或密钥管理服务
const API_SECRET_KEY = "sk-prod-1234567890abcdef"; // 🔴 硬编码密钥
// ========== 问题2：弱密码验证 ==========
function validatePassword(password) {
// 🔴 弱验证：只检查长度，不检查复杂度
// 攻击者可以用"123456"这样的弱密码轻易突破
return password.length >= 6;
}
// ========== 问题3：不安全的Token生成 ==========
function generateToken(userId) {
// 🔴 使用Date.now()生成Token，可预测、易被猜测
// 应该使用crypto.randomBytes()或专门的JWT库
return `token_${userId}_${Date.now()}`;
}
// ========== 问题4：明文密码比较 ==========
function checkPassword(inputPassword, storedHash) {
// 🔴 直接比较字符串，忽略时序攻击风险
// 应该使用crypto.timingSafeEqual()或bcrypt.compare()
return inputPassword === storedHash;
}
// ========== 问题5：信息泄露的日志 ==========
function login(user) {
// 🔴 日志中记录了完整的密码信息！
// 如果日志落入攻击者手中，密码完全暴露
console.log(`User ${user.name} logging in with password: ${user.password}`);
// 🔴 错误信息泄露内部实现细节
throw new Error("Database connection failed: check credentials");
}
// ========== 问题6：eval代码注入 ==========
function parseUserInput(input) {
// 🔴 极度危险！用户输入直接传入eval
// 攻击者可以输入恶意代码完全控制服务器
eval(`var user = ${input}`);
return user;
}
module.exports = {
validatePassword,
generateToken,
checkPassword,
login,
parseUserInput
};
database.js —— 数据库操作的SQL注入风险
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
// database.js - 数据库操作示例，包含SQL注入漏洞
// ========== 问题7：硬编码数据库凭据 ==========
// 🔴 数据库用户名密码直接写在代码中
// 这是生产环境最常见的泄露原因之一
const dbConfig = {
host: "prod-db.company.com",
port: 5432,
user: "admin", // 🔴 硬编码用户名
password: "Admin@123", // 🔴 硬编码密码
database: "production"
};
// ========== 问题8：SQL注入漏洞 ==========
function getUserById(userId) {
// 🔴 拼接SQL，用户输入直接进入查询语句
// 攻击者输入: "1; DROP TABLE users; --"
// 整个users表就会被删除！
const query = `SELECT * FROM users WHERE id = ${userId}`;
return db.execute(query);
}
// ========== 问题9：敏感数据日志 ==========
function logQueryResult(result) {
// 🔴 查询结果直接打印到日志
// 如果结果包含用户敏感信息，这些信息会被记录
console.log("Query result:", JSON.stringify(result));
// 🔴 错误日志中包含堆栈信息，可能泄露文件路径
console.error("Query failed:", error);
}
4.3 调用子代理进行审查
现在，让我们的只读审查器来分析这些代码：
1
/code-reviewer
审查器会读取这些文件，然后输出类似以下的报告：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
📋 代码审查报告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔴 Critical（严重问题 - 必须立即修复）
1. [auth.js:8] 硬编码API密钥
- 问题：const API_SECRET_KEY = "sk-prod-..."
- 风险：密钥泄露风险极高，一旦泄露可直接调用生产API
- 建议：使用环境变量 process.env.API_SECRET_KEY
2. [auth.js:62] Eval代码注入
- 问题：eval(`var user = ${input}`)
- 风险：任意代码执行，服务器完全沦陷
- 建议：完全禁止使用eval，使用JSON.parse()代替
3. [database.js:12] 数据库凭据硬编码
- 问题：user: "admin", password: "Admin@123"
- 风险：代码提交到GitHub后，任何人都能获取生产数据库访问权限
- 建议：使用AWS Secrets Manager或HashiCorp Vault
4. [database.js:26] SQL注入漏洞
- 问题：SELECT * FROM users WHERE id = ${userId}
- 风险：攻击者可删除整个数据库或窃取所有用户数据
- 建议：使用参数化查询
⚠️ Warnings（警告 - 需要关注）
1. [auth.js:14] 弱密码验证
- 问题：只检查长度，不验证复杂度
- 风险：用户可能设置"123456"这样的弱密码
- 建议：添加大小写、数字、特殊字符要求
2. [auth.js:22] Token可预测
- 问题：使用Date.now()生成Token
- 风险：攻击者可以预测其他用户的Token
- 建议：使用crypto.randomBytes(32).toString('hex')
💡 Suggestions（建议 - 可优化）
1. [auth.js:33] 使用crypto.timingSafeEqual
- 建议：密码比较应防止时序攻击
2. [auth.js:43] 日志中的密码泄露
- 建议：移除日志中的敏感字段，或使用脱敏处理
4.4 验证只读特性：让它修复看看
05. 进阶扩展：构建影响面分析代理
只读型子代理的威力远不止代码审查。让我们看另一个场景——影响面分析。
当你修改了一个底层公共模块，如何快速知道这次修改会影响到哪些上游服务和业务逻辑？
5.1 创建影响面分析代理
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
---
name: impact-analyzer
description: Analyze the potential impact of code changes on the system. Use when you need to understand downstream effects, service dependencies, and SLA risks.
tools: Read, Grep, Glob, Bash
model: sonnet
skills: dependency-graph
---
# Impact Analyzer Agent
你是一位系统架构师，专注于追踪代码变更的影响范围。
## 核心能力
- 追踪调用链：从变更点向上追溯所有依赖方
- 识别下游影响：这次修改会影响哪些服务/模块
- SLA风险评估：变更是否可能违反服务等级协议
- 回滚方案建议：提供安全的回滚路径
## 严格限制
- 只分析，不修改
- 不执行任何会产生副作用的命令
- 不访问生产环境的敏感数据
## 输出结构
1. **影响链路图**：用文字描述的调用链
2. **受影响服务列表**：按优先级排序
3. **风险评估**：高/中/低
4. **建议行动**：是否需要通知相关团队
5.2 Skill配置：链路拓扑注入
为了让影响面分析更准确，我们需要通过Skill把链路拓扑和历史事故信息注入到上下文中：
1 2 3 4 5
.claude/skills/dependency-graph/
├── SKILL.md
└── references/
├── service-map.json
└── incident-history.md
Skill和Sub-agent的关系是这样的：
关键点：子代理不会自动继承主对话中可用的Skill，必须在配置文件的skills字段显式列出。
06. 决策框架：什么时候该创建子代理？
现在你知道了如何创建只读型子代理。但更重要的前置问题是：什么时候应该创建子代理？
6.1 创建子代理的决策树
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
需要权限隔离吗？
├── 是 → 强烈推荐创建子代理
└── 否 → 继续判断
输出噪声很高吗？
├── 是 → 强烈推荐创建子代理
└── 否 → 继续判断
需要领域专家角色吗？
├── 是 → 视情况创建子代理
└── 否 → 继续判断
只是想定制一个Prompt？
├── 是 → 使用Skill更合适
└── 否 → 继续判断
想在特定事件时触发？
├── 是 → 使用Hook更合适
└── 否 → 继续判断
需要跨服务/跨仓库视角？
├── 是 → 强烈推荐创建子代理
└── 否 → 可能不需要子代理
6.2 子代理 vs Skill vs Hook
07. 2026年的治理框架：AI代码治理三板斧
回到文章开头那个灵魂拷问：如何防止AI"顺手"帮你做你不想让它做的事？
AI Code Governance框架（2026版） 提供了三个层面的治理策略：
08. 总结：让AI成为你的守门员，而不是万能钥匙
回到文章开头那个场景。
凌晨两点，你盯着屏幕上的commit，后背发凉。
你让AI看代码，AI帮你改了。
这不是AI的错。这是**你没说清楚"只能看"**的错。
只读型子代理的价值：
1. 安全隔离：AI只能看，不能动，风险边界清晰 2. 职责单一：审查就是审查，不兼职"热心帮你修" 3. 可预测：无论谁调用这个代理，行为模式一致 4. 可审计：所有操作都有记录，都是只读
一行配置，改变AI的行为边界：
1
tools: Read, Grep, Glob, Bash # 就是这行配置，让AI从"万能钥匙"变成"专业守门员"
这就是最小权限原则的威力。
📢 写在最后：留一个思考题给你
今天的文章给了你构建只读型审计代理的完整方法论。但我更想问你的是：
在你当前的团队工作流中，有没有哪个环节特别需要"只能看、不能改"的AI角色？
也许是：
• 生产环境的配置审计？ • 敏感日志的合规检查？ • 代码依赖的安全扫描？
欢迎在评论区分享你的场景。
如果这篇文章帮你理清了思路，收藏+点赞是对我最大的支持。
下期见。
关注我，获取更多AI工程实践干货。🚀
