多智能体系统一旦开始加角色，团队最容易默认的想法是“再多一个专家就会更聪明一点”。但真正的生产问题往往恰好相反。角色一多，如果每个角色的边界又不够窄，系统很快就会出现多个半控制器：谁都在规划，谁都在解释，谁都想决定下一步。
专家角色真正的价值，不在于它听起来多专业，而在于它只负责一小段清晰职责。越窄的角色，越容易验证、越容易替换、越不容易偷偷接管控制流。多智能体能否稳定，不只看控制器写得好不好，也看专家角色有没有被收在足够清楚的边界内。
为什么这个问题重要
真实运行代价
当专家角色开始变宽，系统代价会以很隐蔽的方式上升。它们会重复做计划、重复检索上下文、重复调用工具，甚至在没有授权的情况下自行改写目标。表面上角色还叫“专家”，实际上已经在承担部分控制器职责，结果就是系统越来越难解释、越来越难恢复。
- 角色边界模糊后，控制流分散到多个对话里。
- 不同专家重复处理相同问题，成本持续上升。
- 人工接管时很难分辨哪一步是谁真正负责的。
如果不处理会怎样
如果团队不主动收窄专家角色，最先出现的通常不是明显故障，而是低效和漂移。某个角色本来只该做分类，后来开始补充策略；另一个角色本来只该做验证，后来开始决定是否继续执行。久而久之，控制器不再是真正的控制面，而只是众多“会思考角色”之一。
适用场景
谁最需要这套方法
只要系统里已经出现多个专家角色，而且这些角色分别连接不同工具、拥有不同上下文包或不同权限边界，就应该优先把角色收窄。尤其是做取证、分类、校验、摘要、风险判断这类工作时，角色章程越明确，系统越容易保持稳定扩展。
- 每个角色都应能用一句话描述其职责。
- 每个角色都应有明确输入、输出和禁区。
- 每个角色都应能在不理解全局策略的情况下完成工作。
什么时候先不要这么做
如果系统现在只有一个控制器加一个执行者，而且任务边界还在变化，那么过早拆出很多窄角色反而会增加沟通成本。这个阶段更适合先把控制器与执行者跑稳，等重复出现的子职责足够明显时，再把它们提炼成真正独立的专家角色。
推荐系统结构
核心角色与状态
设计窄角色最有效的方法，是给每个专家角色写一份角色章程：它能接收什么输入、允许调用什么工具、必须回传什么字段、绝对不能做什么决定。控制器负责拆解和会合，专家只负责在自己的责任面里产出结果。角色一旦需要改目标、扩范围或决定是否继续，就说明它已经越界了。
- 角色输入应是精简后的上下文包，而不是整段历史。
- 角色输出应是结构化结果，而不是开放式长总结。
- 角色禁区要写清，例如不得改目标、不得直接触发高风险副作用。
与 TaskPilots 的映射
在 TaskPilots 的多 Agent 协作编排集群里，专家角色的窄边界直接决定控制面是否还能保持清晰。控制面适合持有全局状态、会合契约和升级路径；专家节点适合承接分类、提取、验证、生成这类局部工作。只要角色章程足够窄，后续替换模型、追加治理规则或接入人工审批都不会破坏主链路。
风险与失效点
常见失控方式
角色失控常见于三种情况。第一是角色名称看起来很窄，但输入给得太宽，导致它被迫自己补策略；第二是角色虽然职责明确，却拿到了过多工具权限；第三是角色回传没有结构化约束，控制器只能把自然语言回答当成事实使用。三者叠加时，专家角色很快就会演变成第二控制器。
- 角色拿到完整历史后，开始重新定义目标。
- 角色工具权限过宽，执行了本不该执行的副作用。
- 角色回传不稳定，控制器难以可靠比较结果。
需要人工兜底的地方
当某个专家角色连续出现越界行为，或者角色之间开始重复做相同工作时，人工应该介入的不是单次输出，而是角色设计本身。此时最有价值的是回看角色章程、输入包和工具权限，而不是只继续微调提示词。
验证指标
上线前怎么验证
上线前建议专门验证角色边界，而不是只验证任务结果。给角色喂一些超出其职责的样本，看它是否会主动拒绝、上交控制器或按结构化契约回传“不适用”。如果角色总是想把事情做完，通常说明边界还不够窄。
- 检查角色是否会对越界请求做出拒绝或升级。
- 检查角色回传字段是否始终稳定一致。
- 检查角色是否只调用被授权的工具集合。
上线后怎么持续判断
生产阶段建议长期跟踪越界动作率、角色回传合规率、人工覆盖率和重复委派率。越界动作率高，说明角色章程太宽；重复委派率高，说明多个角色职责重叠；人工覆盖率持续上升，则说明控制器正在失去对角色边界的约束力。
下一步 / FAQ
下一步建议
如果你的系统已经有多个专家角色，下一步先不要继续加新角色，而是回头审一遍现有角色：各自职责能否用一句话说清、是否有明确禁区、是否拥有最小工具权限、回传是否足够结构化。把这四件事补齐，系统稳定性通常会立刻提升。
FAQ
专家角色越窄，会不会降低灵活性？ 不会。真正需要灵活性的，是控制器在路由和会合上的判断，而不是每个专家都同时拥有规划能力。
怎么判断角色是不是已经太宽了？ 如果一个角色既要决定目标、又要执行任务、还要解释结果是否可接受，它通常已经太宽了。
一个角色能不能同时接多个工具？ 可以，但前提是这些工具都服务于同一职责边界，而不是让角色因为工具变多就开始接管更多决策。