一个约十几个产品的小团队（helpdesk、MES、邮件托管、高校 AI 助手）在 monorepo 里日常使用 Claude Code 子代理，把任务拆成研究、计划、实现三个阶段，并保持每个阶段的上下文干净。作者强调这不是基准测试，踩过的坑才是重点。
研究阶段放在子代理里跑，绝不进主对话。读日志、grep 代码库、拉 Search Console 导出、翻邮箱，这些输出大多只看一次，留在主对话里会持续占用上下文，把模型推入「变笨区」。子代理有独立上下文窗口，只回传摘要。实践中研究子代理会把发现写成文件并返回约 200 字摘要，后续写作者读文件而不是摘要；指令里明确写「只研究，不发布，不开浏览器」。一个例子：Search Console 标记站内 79 个页面为「alternate page with proper canonical tag」，先查示例 URL 发现这些页面根本不在自己站点上，而属于一个指向已停用服务器的被遗忘子域名，最终只需删掉一条 DNS 记录。
计划阶段留在主对话里，因为判断力要放在看得见的地方。计划写得短而具体：改哪些文件、什么算完成、什么明确不在范围内、结果怎么验证。最有用的习惯是把每个子代理的指令写得像给刚进门的能干同事：做什么、别碰什么、报告什么、多少字以内。并行实现阶段最省时间，也最容易出事，由此总结出三条规则：每个共享资源只由一个代理独占，浏览器、邮箱、数据库迁移、部署都适用；小步提交并立即推送，用显式路径 git add；把每个代理的范围缩到最小可验证单元，比如「只改这三个文档的 meta_title 和 meta_description，保留其他所有字段，然后 curl 线上页面确认新标题」。
验证要对着不会说谎的东西：磁盘上的文件、全新页面加载、长度校验，而不是代理自己复述做了什么。长会话中曾出现工具输出被静默丢词，两次差点得出错误结论。最严重的一次事故发生在 Telegram 网页版与真实业务联系人对话中：代理用 DOM 编辑命令把文字插入输入框，屏幕显示了但应用内部草稿状态没更新，重试后向对方发出七条乱码片段。事后改为通过应用真正监听的输入事件写入，并在发送后从应用自己的数据存储读回消息比对。部署后要从外部检查线上 URL，而不是刚重启的容器。
给刚起步团队的建议：先把研究放进子代理，成本最低风险最小；计划留在主对话并写下来；只有在共享资源有归属规则后才上并行实现；让每个代理对着真实系统证明结果，信文件、全新页面加载和校验和，而不是摘要。