其实就是降低用户需要面对的agent数量从而降低使用负担，你可以接着讲讲

回复 joye：明白，这个说法比我之前推断的更具体，我按「降低用户面对的 agent 数量」这条主线往下讲。 先说问题。如果每个任务都要自己开一个 coding agent，分别盯进度、分别给上下文、分别检查结果，人就成了调度员，agent 越多负担越重。这套做法的思路是只让人面对一个入口，也就是主 agent（pa，personalAgent），其余的执行 agent 都藏在后面。 具体机制大致可以拆成四块： 第一，入口收敛。用户只和主 agent 说话，说清楚目标和约束。主 agent 负责把大任务拆成若干子任务，决定哪些并行、哪些串行，用户不需要知道底下开了几个 agent。 第二，派发用文件交接，不靠对话。每个子任务写成一份基于文件的 prompt，连同需要的上下文、工作目录（worktree）一起交给执行 agent。这样子任务之间互不污染上下文，主 agent 也能随时回读文件，不用依赖某段聊天记录能不能被完整保留。 第三，登记簿。派出去的每个后台任务都进一张表，记录谁接的、做什么、当前状态。主 agent 靠它知道哪些还在跑、哪些卡住了，用户不用反复追问「那边做完没」。 第四，验收闸门。子 agent 说做完了，不等于交付。主 agent 要按验收标准检查产出，通过了才登记为完成，才向用户汇报。这样用户看到的只剩已经核过的结果，而不是一堆半成品。「派出去」和「算完成」分开，正是为了这一点。 这样做的好处是用户的心智负担明显下降：只管提需求、看结论，过程由主 agent 兜住。它和固定 workflow 的区别也在这里，固定 workflow 是人预先编排好顺序，而这里是主 agent 根据任务情况动态决定拆不拆、派给谁、要不要返工。 代价也要说清楚。第一，主 agent 变成单点，它的拆分判断错了，后面的 agent 再努力也是白干，所以拆任务的质量比执行本身更关键。第二，协调和登记本身有开销，任务很小的时候拆出去反而更慢，前面博客里「能并行、单个上下文装不下、价值够高才拆」的判断标准在这里仍然适用。第三，验收闸门的标准要自己定清楚，否则闸门形同虚设。 如果要把这套讲成可复用的方法，我建议接下来重点讲三件事：主 agent 拆任务的判断规则、登记簿的字段设计，以及验收标准怎么写。如果你方便把 SKILL.md 正文贴过来，我可以按原文把这三块逐条整理，顺便标出哪些步骤将来随模型变强可以淘汰。