
上周我在调一个挺复杂的 CI/CD 流水线任务涉及三个环节编译、静态分析、部署。按以前的做法我得把整个流程写在一个 Prompt 里结果 Claude 经常在中间步骤遗忘上下文改一次 Prompt 要等好几分钟才知道对不对。但我试了一轮 Claude Code 新版本里那个子智能体Sub-agent功能后彻底回不去了。说白了Claude Code 的子智能体不是一个单独的模型而是让当前会话动态派生出多个独立的推理线程每个干自己的活互不干扰。你把一个大任务拆成几个小任务每个子智能体拿到自己的上下文、自己的指令干完活把结果汇报回来主智能体再做整合。这听起来不就是函数调用吗对但区别在于——每个子智能体是带着完整的推理能力去执行不是简单的 API 调用结果拼接。它真的会自己读代码、自己写文件、自己跑命令。我第一个实战场景是这样的给一个老项目加单元测试覆盖率报告。项目是 Java Maven几千个文件手动改不现实。我是这么拆的子智能体 A扫描所有 pom.xml找出 module 结构确定哪些模块需要加 jacoco 插件。子智能体 B在找到的模块里插入 jacoco 配置验证语法是否正确。子智能体 C写一个 shell 脚本跑完整测试并生成覆盖率报告。这三个任务是并行跑的——注意不是串行是并行。Claude Code 会自己管理并发你只需要定义好任务就行。这里有个踩坑的地方——依赖传递。我第一次跑的时候以为子智能体之间会自动共享文件系统状态结果发现每个子智能体的工作目录是隔离的。子智能体 A 改了 pom.xml子智能体 B 看不到改动因为它在自己的沙箱里。解决方案是显式传文件路径用 --input 和 --output 参数打通数据流。第二个实战代码审查自动化。PR 太大 reviewer 不想看的时候我就让子智能体代劳。拆法子智能体 1diff 分析找出改动涉及的所有类和接口标注破坏性变更改接口签名、删方法这种。子智能体 2安全扫描正则匹配常见漏洞模式SQL 注入、XSS、硬编码密钥这些。子智能体 3测试覆盖率变化对比改动前后的覆盖行。三个结果合并成一个 review report自动贴在 PR 下面。效果比我预期好很多——虽然偶尔有误报但至少把人从看完 500 行 diff 发现只是改了个变量名这种破事里解放出来了。我发现子智能体最适用的场景有几个特征一是任务可以清晰拆解。如果你的需求是帮我优化这个项目太模糊了子智能体不知道从哪下手。但帮我找出项目中所有未使用的 import逐个删除——这就是子智能体的菜。二是每个子任务可以独立验证。子智能体的输出最好是能单独验证的文件是否生成了、命令是否跑过了、测试是否通过了。如果一个子任务的结果要到最后合并阶段才能判断好坏那说明任务拆得还不够细。三是并行真的有收益。有些任务串行更快——比如数据清洗必须保证顺序。但在代码生成、批量修改、多文件分析这些 I/O 密集或计算密集的场景下并发就是实打实的时间节省。我目前踩过的坑还有几个值得一提上下文膨胀。每个子智能体启动时都会携带一部分上下文如果父会话上下文已经很大子智能体的启动速度会变慢。解决方案是只传最必要的文件路径或摘要。还有个坑是结果合并冲突。两个子智能体同时改了同一个文件的同一行。目前我没什么优雅的解法就是在任务拆分时尽量按文件维度切避免两个子智能体碰同一个文件。组里有人问我你这么用跟直接调 API 有什么区别说实话如果是简单任务直接调 API 更快。但子智能体的价值在于它在你的工作目录里运行能直接操作你的文件、跑你的命令、读你的配置。它不是一个黑盒 API 调用——它是一个真正参与开发流程的智能体。这种区别在批处理、自动修复、持续集成场景下特别明显。