角色设计与任务分配

• 三角色职责划分（计划、执行、反思）
• 闭环机制（计划→执行→反思→修正计划）
• 目标漂移的抑制原理

三角色闭环把"制定计划、执行步骤、反思修正"拆给三个角色：Planner 把用户目标拆成可执行计划并明确验收标准；Executor 执行计划中的步骤；Reflector 检查执行结果是否偏离原目标、是否满足验收标准，决定是继续、修正计划还是终止。闭环让"目标"与"执行"分离：Planner 持有目标定义，Reflector 对比执行结果与目标，发现偏差就回馈给 Planner 修正计划。单 Agent 容易目标漂移是因为"执行"与"校验"混在同一个推理里，容易陷入局部而忘记原始目标；三角色通过"独立校验"持续把执行拉回目标轨道。

目标漂移源于"执行过程吞噬目标"。三角色把"校验目标"独立成 Reflector，形成"执行→比对→修正"的循环，本质是控制回路。关键是 Reflector 要独立、有明确的验收标准，否则反思会空转。

• 合谋/同源偏置的风险
• 评审独立性（不同模型、不同视角、盲审）
• 交叉验证与证据要求

评审者与执行者合谋通常源于"同源偏置"——两者用同一模型、共享同一上下文或顺序依赖，评审者倾向同意执行者。避免方法：独立性——评审者用不同模型/不同初始化/不同视角，或隐藏执行者身份（盲审），避免暗示；交叉验证——评审者需独立重算或检索证据，而非只读执行者结论；机制——不让评审者直接看到执行者答案，让执行者先给出证据再给结论；多评审者——多评审者投票/仲裁，降低单点同源；校准——定期用已知正确/错误用例评测评审者，控制其校准偏差。同时禁止评审者顺序依赖执行者输出。

避免合谋的本质是"保证评审独立于执行"。独立性来自模型/视角/信息隔离，验证来自外部证据而非"同意"。评审者若只是"执行者的复读机"，评审就失去意义，因此要用证据要求与盲审破坏合谋。

• 冲突来源（多角色目标不一致）
• 仲裁机制（优先级、元规则、抽查）
• 一致性维护

角色提示词冲突（如一个角色要求"极致质量"，另一个要求"极速响应"）时，需要显式仲裁。方法：定义优先级/元规则——在系统层设定"目标优先级"，如"正确性 > 速度 > 成本"，冲突时按优先级裁决；预算约束——把"速度"转为可量化的预算（超时、token 上限），质量角色在预算内最优；分层裁决——由 Supervisor 或仲裁者针对冲突决定；按场景切换——不同任务类型走不同策略（如对外响应重速度、内部计算重质量）。同时要把冲突写进提示词约定，避免角色各自为政。仲裁结果要可观测、可回滚。

冲突仲裁的关键是"把模糊的权衡显式化"。先定义优先级与预算，再在执行时裁决，而非让各角色自行揣测。可量化（预算、超时）让"速度"可度量，质量在预算内最优，避免无法裁决的拉扯。

• 两种模式的机制差异
• 集中调度的适用场景
• 对等协作的适用场景

集中调度（Supervisor）由一个总控负责分解、路由、裁决与审计，适合：任务依赖复杂、需要按中间结果动态决策；需要统一治理与权限控制；需要集中审计与可解释；对结果一致性要求高。对等协作（Peer-to-Peer）由各 Agent 自主协商匹配，适合：Agent 数量多、异构、动态；任务相对独立、可并行；需要去中心化、无单点；需要高吞吐与扩展。工程设计上常混合：全局用 Supervisor 治理，局部用对等协作加速。选择依据是"控制力需求 × 扩展性需求"。

集中调度换"可控、可审计"付"单点、瓶颈"；对等协作换"扩展、去中心"付"难治理、难审计"。关键看业务对"控制与审计"的刚需程度，以及 Agent 规模与动态性。复杂异构多 Agent 用对等，简单强治理用集中。

• 数据亲和原理（数据与处理就近）
• 数据分片与就近分配
• 减少重复传输与 token 的方法

数据亲和分配指"让处理该数据的 Agent 与数据所在位置/索引就近"，减少大数据的跨节点传输与重复加载。做法：数据分片——大数据按主题/租户/区块分片，索引与 Agent 绑定，Agent 只处理自己分片；就近调度——路由时优先选择数据已在本地缓存的 Agent；引用传递——不在消息里传原始大数据，而是传数据引用/指针，Agent 按需拉取；去重——同一数据只加载一次，多个任务共享缓存；压缩——传摘要或结构化提炼，而非全文。token 成本上，把"原始数据"与"处理逻辑"分离，只在需要时取必要片段。

数据亲和的核心是"移动计算优于移动数据"。大上下文反复传输既慢又贵，通过分片、就近调度、引用传递与缓存去重，把重复传输降到最低。token 成本也随之下降。

• 冲突裁决机制（仲裁者、置信度、投票）
• 沉默接受的风险
• 冲突处理流程

子 Agent 结论冲突时，裁决方式：仲裁者——由独立的高层 Agent/规则对冲突做最终判定；置信度——比较各结论的置信度/自评，高者胜；投票——多数一致胜（需保证各 Agent 独立，避免同源）；也可组合。关键要避免"沉默接受"：即未显式检测冲突就把第一个或少数结果当作最终结果。设计上：聚合步骤显式检查各子 Agent 输出是否一致；不一致时进入仲裁流程，记录冲突原因；对少数派或低置信度结果做标记，不轻易丢弃。仲裁结果要可审计、可回放。

冲突裁决的前提是"先检测到冲突"。多数系统因"未检测就拼接"而静默接受错误。检测后按置信度/投票/仲裁者裁决，且要保证各 Agent 独立性，避免同源合谋。宁可标记不确定，也不静默接受。

• 能力重叠问题
• 路由策略（能力匹配、负载、去重）
• 避免重复执行的机制

能力重叠时，路由需避免把同一任务重复派给多个 Agent。做法：能力匹配优先——按能力描述与任务匹配度选最合适者，而非全部；路由表/标签——维护 Agent 能力与任务类型的映射，重叠时按优先级、负载、区域分工；去重——任务带唯一 id，路由层按 id 去重，防止同一任务被多次派发；分工切片——把重叠能力按领域/数据切片，让各 Agent 管不同切片，减少重叠。执行后可用结果去重（同一任务结果缓存）。同时记录"谁在负责某任务"，避免无主与重派。

能力重叠本身不是问题，问题是无序重复。解决是靠"路由层的确定性分工 + 去重"：明确责任边界、按 id 去重、按能力/负载选路。让任务有"唯一负责者"，避免重复劳动与结果冲突。

• capability manifest 的内容
• 能力匹配与调度
• 能力声明与校验

capability manifest 是 Agent 的机器可读能力声明，包含：能力名称与描述、支持的任务类型、输入输出 schema、可用工具、约束（模型、上下文、区域）、SLA（延迟、并发）、能力版本。调度器读取 manifest，与任务需求做匹配：按能力语义匹配（标签/向量）、按 schema 校验兼容性、按约束与 SLA 过滤、按负载选路。要防止"能力虚报"：manifest 需与真实能力校验（能力测试、运行验证），并随 Agent 状态更新（可用/饱和）。匹配结果可解释、可回退。

capability manifest 是"调度器与 Agent 之间的契约"。精准匹配依赖结构化、可校验的能力声明 + 运行时校验。只声明不校验会导致调度失误，因此 manifest 要与真实能力绑定并持续更新。

• 角色分工（生成/测试/审查）
• 上下文与工具隔离
• 反馈闭环

为代码生成、测试、审查分配 Specialist Agent：各角色有独立系统提示词、工具集与上下文。生成 Agent：负责编写代码，输出带结构化（文件、函数、依赖），可运行测试；测试 Agent：负责编写/运行测试，验证需求，输出通过/失败与失败原因；审查 Agent：负责代码审查（安全性、可读性、规范、bug），输出审查意见与修改建议。三者形成闭环：生成→测试→（失败反馈生成回修）→审查→（意见反馈生成修改）。关键：角色上下文隔离（不互相污染）、工具权限区分（生成可写代码、测试可运行、审查只读）、反馈结构化（可回修的失败信息），避免角色权限越界。

Specialist 分工的价值是"各司其职 + 独立校验"。生成与审查分离，避免"自写自审"的盲区；测试作为确定性验证器，比 LLM 自评更可靠。关键是权限隔离与反馈闭环，让审查/测试结果可驱动生成修改。

• 依赖关系的表达（DAG、条件）
• 执行调度（拓扑序、并行）
• 结果合并

依赖关系用 DAG 表达：节点为子任务，边表示依赖。串行依赖=有向边（前完成后才执行）；并行=无依赖的节点可并发；条件=分支节点按结果选择后续路径。执行调度用拓扑排序：入度为 0 的节点可并行执行，完成一个就释放其依赖，逐级推进；条件分支按运行时结果决定。结果合并：join 节点在所有依赖完成后聚合结果，条件分支只合并实际执行路径。工程上可用工作流引擎（LangGraph/Temporal）的 DAG + 并行调度实现，配超时与重试。

依赖表达让"串行/并行/条件"可被确定性调度，而非靠 LLM 自觉。DAG + 拓扑调度保证时序正确，并行最大化吞吐。条件分支让流程动态化，join 只等实际路径。

• 失败检测与重试
• 换角色/换策略
• 回退总控与人工兜底

角色退化的兜底分梯度：先重试——对可重试错误（超时、限流）按退避重试；仍失败则换策略——换模型、换提示词、换工具；换角色——把该 Agent 的任务细分或改派给其他 Agent；回退总控——由 Supervisor 收回任务，简化处理或直接执行；最后升级人工——在预算/次数超限时上报人工。要检测"重复失败"（失败计数、失败率）并触发降级，避免无限重试。降级要记录原因与路径，可回放。对"输出不可用"（格式错、质量低）用校验拦截，触发重做或降级。

降级是"多级兜底"：重试→换策略→换角色→回退总控→人工。核心是"失败检测 + 分级降级 + 上限控制"。避免无限重试与反复失败消耗资源，用失败计数与预算触发上升级。

• 上下文预算（系统提示、示例、工具、历史）
• 按任务裁剪 token
• 角色一致性维护

上下文预算是有限的，要按角色分配：系统提示（角色定义）保持精简但完整，固定角色行为的核心；示例（few-shot）按需裁剪，只保留与任务最相关的几条；工具列表裁剪为当前角色真正需要的子集，避免塞入无关工具占用 token；历史与输入按需摘要。角色一致性维护：系统提示中固化的角色定义与规则不裁剪，动态部分（示例、上下文）可裁剪；用"核心指令固定 + 动态上下文可裁剪"的结构，保证角色行为稳定。裁剪要可测（token 记账），避免裁剪过度破坏角色一致性。

上下文预算分配是"固定核心 + 裁剪外围"。角色定义、规则这类"一致性关键"必须保留，示例、工具、历史这类"提升性"内容按任务裁剪。裁剪目标是"在 token 预算内保住角色一致性"，用 token 记账与质量评测验证。

• 粒度过细的代价（协调、重复上下文）
• 粒度过粗的代价（单点过载、并行不足）
• 平衡方法与评估

分工粒度是"协调成本 × 并行收益"的权衡。粒度过细：任务间协调、消息传递、上下文重复传输开销大，还可能引入大量合并与仲裁成本；粒度过粗：单个 Agent 任务过重、上下文过大、单点过载、并行不足。找平衡方法：按依赖强度切分——强依赖的任务聚合为一个 Agent，弱/无依赖的拆开并行；按上下文大小切分——控制每个 Agent 的上下文在一个合理范围；按成本/收益评估——对候选粒度做实测（完成率、延迟、token、协调开销），选最优；动态调整——任务量变化时调整粒度。可设"粒度上限"防止过细。

平衡的本质是"在并行收益与协调成本间找最优"。依赖紧、上下文内聚的任务宜聚合；独立、可并行且上下文小的任务宜拆分。用实测数据（质量、延迟、token）决策，而非拍脑袋。

• 成本构成（角色数、上下文、token）
• 成本评估（token 记账、归因）
• 成本优化手段

多 Agent 成本主要来自：角色数量（每个 Agent 的提示词与调用）、上下文重复传输（同一数据传给多个 Agent）、token 消耗（生成与历史）。评估：按任务/角色/tool 做 token 记账与成本归因，识别成本大头。优化：精简角色——只保留必要角色，合并重叠；减少重复传输——数据亲和、引用传递、共享缓存；控制上下文——裁剪、摘要、限制历史；模型分级——简单任务用小模型，复杂任务用大模型；预算与限额——为每个 Agent/任务设 token 上限与超时。持续用成本监控与质量对比验证优化效果。

成本控制是"可度量 + 可优化"。先归因（谁在花、花在哪），再针对大头优化（角色、传输、上下文、模型）。优化要以"不牺牲关键质量"为前提，用监控与评测闭环验证。

• 三种策略的机制
• 组合策略
• 过载保护（背压、限流、熔断）

任务分配组合：先按能力匹配过滤（选出能做该任务的 Agent），再按负载均衡（选当前最空闲者，避免单点过载），再按优先级调度（高优任务优先，低优让路）。过载保护：单 Agent 设并发上限与队列深度，超限时背压（拒绝新任务或排队）、限流（丢弃/降级）、熔断（连续失败时暂停派发）。用负载均衡均匀分布，用优先级保高优，用容量保护防过载。调度器要监控每个 Agent 的负载与健康状态，动态路由。

三种策略是"能否做→谁空闲→谁优先"的决策链。过载保护是底线：容量上限 + 背压 + 熔断，防止单个 Agent 被压垮而拖垮整体。优先级调度要防低优饿死。

• 独立上下文与共享事实库的划分
• 信息越权风险
• 隔离与授权机制

角色记忆隔离：每个 Agent 维护自身私有上下文（思考、临时状态），共享事实库存放跨 Agent 可访问的公共事实。划分原则：私有信息（本 Agent 的推理、局部状态）不写入共享库；共享库只放授权可共享的事实，并标记权限与来源。防止越权：共享库按角色/租户做 ACL 与访问控制，Agent 只能读写其授权范围；写入前校验权限，读取按权限过滤；敏感信息（凭证、隐私）不进共享库，或用脱敏与加密。隔离要可审计，记录谁读写了什么。

隔离的关键是"权限边界 + 访问控制"。私有上下文与共享库分离，共享库按角色授权。防止"信息越权"（Agent 读到不该读的、或把私有信息泄露给共享）要靠 ACL、脱敏与审计。

• 能力封装（接口、输入输出契约）
• 接口化（与具体实现解耦）
• 可替换性验证

角色可替换性的核心是"面向接口而非面向实现"：把 Agent 封装为统一接口（输入、输出、工具、能力声明），编排层只依赖接口，不依赖具体 Agent。这样替换某个 Agent 时，只要新 Agent 满足同一接口契约，编排无需改动。设计：定义能力契约（输入输出 schema、行为约定、错误语义）；Agent 通过适配器/插件实现接口；注册表管理能力与实现映射；可替换性验证——用回归测试集验证新 Agent 满足契约后上线。支持 A/B 与灰度替换。

可替换性 = 接口契约 + 实现解耦。编排只认接口，不认具体实现。这降低了对单一 Agent 的耦合，也便于升级、降级与多模型切换。契约要与回归验证绑定，保证替换后行为一致。

• 贡献评估指标（合格率、产出、延迟、成本）
• 归因与追踪
• 评测与优化闭环

评估每个 Agent 的贡献需可观测：记录每个 Agent 的输入、输出、工具调用、token、延迟、结果是否被采纳（采纳率）、是否触发返工（返工率）、质量评分（LLM-as-Judge 或人工）。归因：用 traceId 关联一次任务的各 Agent 环节，计算各自的贡献（如"最终结果中该 Agent 产出的占比""该 Agent 的结论被采纳的概率"）。通过贡献评估发现低效/失效角色，做优化或替换。要区分"该 Agent 的原始产出"与"被采纳后的净贡献"，避免错误归因。

贡献评估是"可观测 + 归因 + 优化"的闭环。指标要覆盖质量、效率、成本三方面。关键是排除其余 Agent 干扰的独立归因，用 trace 与采纳率衡量真实贡献。

• 验收标准 AC 的定义（可验证、可度量）
• 返工条件（不合格判定）
• 结果评分

委派时要定义可验证的验收标准（AC）：明确完成条件（输出符合什么 schema、满足什么规则、达到什么质量阈值）、边界（什么不算完成）、以及验证方法（确定性校验、规则、测试、LLM 判断）。返工条件：明确"什么情况下不合格需返工"（未达 AC、格式错、质量评分低于阈值、需求未满足），返工上限与返工原因。结果评分：用评分维度（准确、完整、合规、可执行）与评分标准（0-5 或通过/不通过），可结合规则分 + LLM 分 + 人工分。评分与 AC 联动，返工由评分驱动，避免主观。

验收标准是"可验证、可度量"的，才能在委派-执行-校验闭环中做客观判定。AC 前置、返工条件明确、评分可度量，让"合格/不合格"可判定而非主观。这样闭环才可靠。

• 动态创建/回收角色
• 角色池 vs 按需实例化
• 资源管理与回收

动态角色实例化指按任务类型运行时创建所需角色，结束后回收，避免固定角色池的常驻浪费。设计：任务到达时按类型匹配需要的角色模板，实例化（加载提示词、工具、上下文）；任务结束或超时回收实例（释放上下文、会话、资源）。用角色模板/工厂管理，避免每次重建成本；用池化复用高频角色（缓存已加载的模型上下文），按需实例化低频角色。监控资源使用，设并发上限与回收策略（TTL、空闲回收）。权衡：创建成本高时用池化，创建成本低或任务稀疏时用按需。

动态实例化是"按需分配 + 及时回收"。关键不是"全动态"或"全固定"，而是按频率与成本混合：高频角色池化复用，低频角色按需创建。回收要防泄漏，配合 TTL 与空闲回收。