必须用可验证指标判断是否拆agent：任务链超4步且专业视角不同、存在可并行交汇子路径、模块横跨多目录或强耦合、显式角色切换≥2次。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在WorkBuddy里面对一个“写完这份行业分析报告再生成PPT提纲”的任务时，不能靠直觉决定要不要拆Agent——拆早了增加调度开销，拆晚了已陷入上下文混乱。必须用可验证的指标来判断任务是否真正需要多Agent介入。
先看任务链长度和环节依赖
第一步：把任务按动作颗粒度拆成最小执行单元，例如“查政策文件→筛近三年数据→比对竞品功能→画SWOT图→写摘要→排PPT页逻辑”。
第二步：标出每个单元的输入来源和输出去向。如果出现“单元C的输入同时依赖单元A和单元B的输出”，且A、B之间无先后关系（比如查政策和筛数据可并行），就满足多Agent的第一个硬条件：【存在至少两个可并行、但最终需交汇的子路径】。
第三步：数环节总数。超过4个明确步骤、且其中任意两个步骤的专业视角明显不同（如“读PDF法规”和“写Markdown摘要”），单Agent极大概率会在第3步开始遗忘第1步的格式要求——这时拆是止损，不是升级。
再验模块耦合度与变更风险
方法一：打开你准备修改的代码库或文档目录，快速扫一眼涉及路径。如果改动横跨/src/api、/docs/spec、/tests/unit三个不相交目录，且每个目录有独立维护人，这个任务就必须拆——因为每个目录背后对应不同校验规则和知识边界。
方法二：问自己一个问题：“如果其中一步出错，我能否只重跑这一段而不影响其他产出？”如果答案是否定的（比如改接口定义后，前端调用、测试用例、文档示例全要同步更新），说明模块间存在隐性强耦合，单Agent无法隔离错误传播，必须拆。
最后测角色切换频次
回看你的原始指令，统计里面出现的角色指令词次数：出现“作为架构师…”，“现在切换为测试工程师视角…”，“请以产品经理口吻总结…”这类显式角色切换提示≥2次，就直接拆。【单次对话中角色切换超过两次，模型会主动丢弃早期约束】——这不是WorkBuddy的缺陷，而是所有大模型的注意力衰减规律。
这一步操作起来很简单，直接复制你的原始提示词到文本编辑器，用Ctrl+F搜“作为”“切换为”“以…身份”，数出来就行。
