Copilot一次分析了12个潜在问题，3个版本号查错，一半建议被毙掉，最后4个值得动手。这不算糟——但怎么让AI把活干完，而不是只给建议？
子代理（sub-agent）是答案，但新手用它会踩同一个坑：喂太多信息，管太细，反而把自主性废了。
我上周刚走完这套流程。从代码分析到PR提交，全程没碰键盘。关键不是让Copilot"更聪明"，是把前置脏活做透，让子代理拿到合格的输入。
第一步：别让AI在垃圾堆里翻金子
我的初始提示很懒："分析代码库，报告改进和潜在bug。"Copilot CLI吐回来12条。我让它每条建GitHub issue，打好标签和优先级。
然后发现3条关于"版本不存在"的警告。实际上我用的版本比它的训练数据新。关闭，不予修复。
剩下9条里，有些闻起来不对——Copilot会自信地编规则，尤其是面对不熟悉的代码模式。我手动+AI交叉验证，又关掉5条。
4条存活。这时候才轮到子代理上场。
很多人反着来：先扔给子代理，边跑边纠。问题是子代理一旦启动，你插嘴的成本极高。上下文断了，它得重新加载，等于白跑。
所以triage阶段要榨干信息。如果你已经能判断"这条issue该关"，说明你挖到了足够细节——这些细节就是子代理的启动燃料。
参考Claude Code的Annotation Cycle：先让AI标注代码，你审，再让它基于反馈重新标注。循环几次，输入质量指数级上升。
第二步：一条提示，六个动作
我的子代理提示长这样（格式化给人看的版本）：
针对issue X、Y、Z，各启动一个子代理，执行：
1. 用gh工具抓取issue详情
2. 用git worktree创建独立工作目录
3. 实现功能或修复问题
4. 必要时写测试，全部通过再继续
5. 推送到独立分支
6. 按命名规范创建PR
六个动作，零次人工介入。但每个都有坑。
坑一：GitHub权限默认只读
Copilot CLI默认连GitHub MCP Server，但只读。想创建或更新issue？用gh命令行。
终端里先gh auth login，再启动Copilot CLI。同一shell会话，权限继承。这是官方文档没写透的细节。
坑二：分支冲突
git branch在同目录切分支，多个子代理会互相踩。git worktree解决：每个分支映射到独立文件夹，物理隔离。
原理简单——一个仓库支持多个工作树，同时检出多个分支。但很多人没用过这条命令，包括不少 senior。
坑三：测试是门槛，不是装饰
提示里写"全部通过再继续"，子代理真的会跑。但没写的话，它可能跳过，或写个空测试糊弄。
AI对"完成"的定义和你不同。你的完成是"功能对+测试绿"，它的完成是"代码看起来跑过"。
为什么前置triage不能省
子代理的自主性建立在输入质量上。12条issue里8条是噪音，扔给8个子代理，得到8个垃圾PR。审PR的时间比自己做还长。
我的4条存活issue，子代理全部一次过。因为triage阶段已经验证：问题真实存在，边界清晰，实现路径大致可行。
这像产品经理写PRD。需求模糊，开发来回扯皮；需求清楚，工程师自闭环。子代理就是那个"工程师"。
一个反直觉的发现
子代理跑完后，我检查了4个PR的提交历史。3个的commit message比我写得好——有具体issue引用，有改动摘要，有测试覆盖说明。
第4个的message是"fix bug"。我让它重写，它补上了细节。
AI在结构化输出上偶尔超越人类，因为人类会偷懒，它会严格执行提示里的格式要求。
但这也意味着提示必须精确。"写个好点的commit message"没用，"包含issue编号、改动摘要、测试覆盖"才有用。
这套流程的边界
不是万能。我试过让子代理处理需要跨模块重构的问题，它改了A模块的接口，没更新B模块的调用，测试全绿——因为测试也没覆盖集成点。
子代理的视野限于单个worktree。架构级改动，需要人在更高层 orchestrate。
另外，训练数据截止日期是硬约束。我的版本号问题，Copilot 4o到2024年初，新版库它不认识。子代理也一样，不会凭空知道新API。
给想试的人
别从复杂场景开始。选几个边界清晰的bug fix，走完全流程：triage → 子代理 → PR。感受哪里卡壳。
我的第一个子代理跑了47分钟，因为没限制测试超时，它在一个 flaky test 上重试了9次。现在我的提示里有"单测试超时120秒，失败即停"。
这些细节不会出现在教程里，因为每个人的代码库不同。你只能跑，卡了，修提示，再跑。
Copilot CLI的sub-agent功能还在快速迭代。上周的语法这周可能变。但核心逻辑不变：好输入 → 自治执行 → 最小人工介入。
我最后合并了3个PR，第4个需要产品决策，扔回backlog。从"分析代码库"到"3个PR就绪"，总耗时2.5小时，其中人工时间35分钟。
剩下的时间，我在看子代理写的测试——有一个 corner case 我没想过。它从issue描述里挖出来的。
如果让你设计一个子代理的"安全刹车"机制，你会选什么指标？测试覆盖率、代码变更行数、还是别的什么？
热门跟贴