05｜明察秋毫 ：构建只读型安全审计子代理
黄佳
你好，我是黄佳。
上一讲我们理解了子代理的核心概念，今天我们要动手实战——创建一个只能看、不能改的代码审查员子代理。
为什么要从“只读型”子代理开始？
因为权限边界是子代理最重要的工程价值之一。代码审查是一个完美的场景：审查者需要完整的读取能力来分析代码，但绝对不应该在审查过程中修改代码。如果你的审查工具可能在“帮你”"的过程中偷偷改了什么，那还叫审查吗？
今天的目标就下面三个。
创建一个只有读取权限的代码审查子代理。
用它来发现示例代码中的安全问题。
体验“最小权限原则”的工程价值。
同时，我们也将从真实工程痛点出发，理解"为什么需要这个子代理"的设计思维，并学会将工程经验翻译为子代理的职责边界与调用结构。
好，现在一起开始动手。
项目场景：代码审查
一个后端开发项目中，我们刚刚好写完了一段认证逻辑，想让 Claude Code 帮你审查一下有没有安全问题。你在主对话中说：“帮我检查一下 auth.js 的安全性”。
Claude 完成这个任务当然不在话下，它读了你的代码，发现了硬编码的密钥，然后顺手帮你改成了环境变量读取。等等，发现哪里不对了么？你只是想让它看看有没有问题，并没有让它改啊！而且，它的“好心修复”可能引入了新的问题——比如你根本不想配置任何环境变量。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Claude Code 工程化实战》，新⼈⾸单¥59
《Claude Code 工程化实战》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(5)
- 最新
- 精选
拾掇拾掇最近一个线上场景，因为要在原有功能上迭代，但是涉及了多个系统，然后上周爆了一个bug，有一个系统的接口漏改，功能按钮实属隐蔽。感觉subagent也发现不了吧。一个倒置的多叉树，或者有可能是多个倒置的多叉树，感觉搞个项目的知识库会比较好，然后让subagent去读取一类功能说明2026-02-06归属地：浙江1
jssfy子代理上下文隔离的话，如果一次任务未完成彻底，后续再二度用子代理分析的话，是否只能基于上次子代理任务的summary继续分析了，比如详细的日志分析子代理第一次执行时用到的日志在第二次执行时是不看不到了？2026-02-06归属地：北京
TheOne很多案例都是因为需求对应的上下文不全导致的 解放办法1 尽量去补全一个需求的背景，让ai知道全貌，然后开始工作 其实还有个思路 就是从结果出发，用测试用例复现这些问题，但前提也是个人能想到这个用例，这个场景2026-02-06归属地：北京- jssfy哦，看到skills字段了；那如果配置的skill数量过多，会否超出上下文窗口长度而导致失效？2026-02-06归属地：北京
- jssfyimpact-analyzer子代理启动时，上述知识已经通过 skills 字段注入到上下文中：skill在这里是怎么被触发注入到子代理上下文的？2026-02-06归属地：北京
收起评论