先交代一下背景我前阵子在做一个内部实验目标很单纯——让多个AI角色在一套系统里既保持各自的“性格”和职责又不要互相抢话、互相污染还能像一支配合了半年的团队那样把一件复杂任务拆解完。折腾过单纯用提示词堆、用角色卡堆也试过让多个LLM API并发跑再简单投票结果都不理想。最后我借了量子力学里的Bra-Ket符号形式搭了一套“多人格AI协作系统”还给核心调度逻辑起了个代号曾老师智慧算法。这篇文章不会讲什么玄学就是把这套系统的设计思路、公式映射、工程实现和踩坑记录完整摊开想给同样在搞多Agent协作或者AI角色管理系统的人一点可抄作业的参考。1. 先聊清楚多人格AI协作到底难在哪很多人一上来就误会以为“多人格AI协作”就是拿一个统一Prompt里面写上“你是客服小A你是审核小B你是文案小C”然后让模型自己切换。实测下来这种方案在单轮对话里勉强能用一旦进入多轮、多任务、多角色交叉的场景问题会像洋葱一样一层一层冒出来。1.1 单模型多角色时最常见的失控现场我最早做的一个模拟项目X需要同时处理客服答疑、内容合规检查、营销文案生成三个角色。我把三套人格说明写进同一个系统提示词结果遇到三个经典故障角色串味客服角色回答到一半突然开始输出营销话术还带着另外一套人格的口吻。目标倾轧合规角色太强势把所有客服回复都改成“建议您自行查阅”导致体验差到没法上线。上下文漂移聊到第7轮后系统提示词里的角色边界基本失效模型开始按最近几轮的用户语气即兴发挥。问题根源不是模型不够聪明而是所有角色共用一个上下文状态角色信息被当成了“背景文本”而不是“有边界的行为约束”。这就好比一群人开会每个人都有自己的立场但会议室里只有一个话筒谁先抢到谁说话最后输出的东西完全取决于临场情绪而不是角色本身的能力。1.2 团队协作视角下的“状态叠加”做了一段时间后我开始换一个角度看问题与其把角色当成一段段提示词不如把它们当成一组“行为状态”。每个角色在任意时刻都有一个状态这个状态里包含它的系统设定、最近输入、当前任务目标、已有输出片段。多个角色同时存在共同影响最终输出这就是一种“叠加”。但这里的叠加不是量子物理意义上的真实叠加而是管理学意义上的状态混合。问题是怎么描述这种混合怎么决定谁的影响占主导怎么在冲突时做取舍我当时给了自己一个很直白的类比团队开会时每个成员都在脑中形成一个“目标投影”这些投影之间有的方向一致有的方向相反。最终决策不是简单的平均也不是少数服从多数而是要看每个投影相对于全局目标的“重叠度”。重叠度越高的意见权重自然越高。基于这个想法我开始把Bra-Ket符号形式当成协作系统的数学骨架。2. Bra-Ket量子形式能不能当协作系统的设计语言先别被“量子”两个字吓退。Bra-Ket符号是狄拉克发明的线性代数记号本来是用在量子力学里的但其核心思想完全可以移植到AI系统的状态管理和调度设计上。我用的并不是真正的量子计算只是借用它的符号体系来表达“多个状态之间的关系”。2.1 五分钟理解狄拉克符号Bra-Ket里面只有两种核心角色Ket向量 |ψ⟩表示一个状态。可以理解成“当前系统处在某个具体情形下的描述”。Bra向量 ⟨φ|表示一种观测或者约束。可以理解成“我们希望系统满足什么条件”。两个符号合在一起写成 ⟨φ|ψ⟩叫内积数值上表示两个状态的“重叠程度”或“投影强度”。如果两个状态方向完全一致内积接近1如果方向完全相反内积接近0甚至为负。我在系统里做了一个简单但关键的映射每个AI角色的人格和当前即时状态合并成一个Ket向量全局任务目标和一个“本轮的硬性约束”合并成Bra向量。然后用内积来决定这个角色本轮应该获得多大的话语权。2.2 量子概念对应表量子力学概念在多人格AI系统里的对应物作用态向量 |ψ_i⟩角色i的完整运行状态系统提示、上下文、当前中间产物描述角色“此刻想做什么”观测算符 ⟨C|全局目标与硬性约束任务要求、合规边界、输出格式定义“这一次协作的验收标准”内积 ⟨C|ψ_i⟩角色i当前输出与全局目标的相关度决定角色i本轮权重基态集合一组正交化的人格模板策划、执行、审核、记忆减少角色之间的语义污染测量坍缩收敛输出选出一个组合后的最终结果让协作有明确终点这套映射用下来最大的收益不是“算得准”而是让代码结构变得非常清晰谁负责定义状态、谁负责计算相关性、谁负责组合输出一目了然。2.3 用内积解决目标碰撞的例子举个例子。一次任务里策划角色想走“大胆前卫”的创意方向合规角色想走“保守稳妥”的方向两个角色在交叉评审时互相攻击。旧方案我是让它们轮流发言最后取个并集结果方案变成缝合怪。换用Bra-Ket思路后我引入两个投影值策划对全局目标的内积 p_plan ⟨C|ψ_plan⟩合规对全局目标的内积 p_compliance ⟨C|ψ_compliance⟩谁的投影值高谁的核心观点保留更多另一方只保留与全局目标不冲突的部分。这样不用真正“说服”其中一个角色而是让它们在目标层面自动完成了一次加权协商。3. 多人格AI协作系统的整体架构这套系统我在工程上拆成了五层角色层、状态层、调度层、组合层、输出层。每一层只做一件事调试时特别省心。3.1 角色层人格基底的设定角色层不直接写死一整段人格描述而是把每个角色拆成三块身份标签角色的职责边界例如“策划者”“执行者”“质疑者”。行为规则集在这个项目中允许做什么、禁止做什么。语气风格参数输出长度、正式程度、是否允许反问等。这三块共同构成角色的“基底”。系统里我预设了四个基底角色策划者负责拆解目标、执行者负责产出具体内容、质疑者负责找漏洞、记忆管家负责维护历史上下文。这样设计的好处是任意复杂任务都可以由这四个基础角色组合完成而不是为每个新需求都新造一个角色。3.2 状态层每个角色一个独立上下文我放弃了“所有人共用一个上下文”的做法。每个角色维护自己的消息队列和状态缓存状态格式是一个统一的字典包含role、current_task、history_summary、last_output。聊天时角色之间不直接读写彼此的原始上下文只能通过一个“协作事件总线”收发结构化的消息。例如策划者发布一条“目标已更新”的消息执行者订阅后把新目标写入自己的当前任务字段。上下文隔离是这套系统没再出现角色串味的关键。3.3 调度层Bra-Ket投影计算与权重分配调度层是整系统的核心负责算每个角色的投影值然后决定本轮各角色输出的组合权重。具体流程会在下一节展开。调度层还兼任“目标守卫”如果某个角色的输出明显偏离全局目标调度层会直接把它的权重压到接近0。3.4 组合层与输出层生成最终结果组合层拿到各角色的输出和权重后不是简单拼接而是按段落做加权取舍。比如策划者给出十个要点执行者产出了五段文字质疑者提出了三个风险点组合层会把风险点转成附注把执行者的文字按策划要点重新排序最终形成一篇有共同主题、有审核痕迹的结构化内容。输出层再做最后一次格式校验保证输出是用户能直接使用的形式。4. 曾老师智慧算法的核心逻辑“曾老师”这个名字并不是指某个具体的人而是我在工程里给“统筹决策模块”起的代号。它在我心里扮演的角色等同于“一个经验丰富的老教师在最后把关”听所有人汇报但不盲目相信任何人结合全局目标做加权裁决。4.1 算法的三段式流程曾老师智慧算法每次运行分三步投影打分、冲突抑制、收敛组合。第一步对整个角色集合计算内积 p_i ⟨C|ψ_i⟩。这一步需要把全局目标和角色状态向量化。我没有用什么花哨的向量数据库就是先用模型生成一个512维的语义摘要向量再通过一个简单映射函数折算成0到1之间的标量。推理量的控制上50个角色以内都不是问题。第二步按投影值生成初始权重。这一步会先做一次温度缩放避免某个角色投影值略高就直接垄断话语权。权重公式用到的正是一个标准的softmaxw_i exp(p_i / temperature) / Σ_j exp(p_j / temperature)temperature值我默认设在0.8。数值越大各角色权重越平均数值越小越倾向于服从投影最高的角色。实际使用中需要高创意的时候调高需要强执行的时候调低。第三步冲突抑制。计算任意两个角色输出之间的相似度矩阵如果相似度过高说明两个角色在同质化输出需要把后发言者权重压低保证多样性。这一步避免团队陷入“所有人都在重复同一个正确废话”的局面。4.2 算法的伪代码实现下面是我在模拟项目X里跑过的简化版伪代码可以直接抄去改def zeng_teacher_algorithm(roles, global_state): # roles: 每个角色包含 state_vector 和 last_output # global_state: 本轮全局目标向量 weights [] for role in roles: p dot(global_state, role.state_vector) # 投影值 weights.append(p / temperature_scale) weights softmax(weights) # 归一化 # 冲突抑制相似度惩罚 for i in range(len(roles)): for j in range(i 1, len(roles)): sim cosine_similarity(roles[i].last_output, roles[j].last_output) if sim 0.7: # 后发言者降权 weights[j] * 0.5 weights weights / sum(weights) final_output merge_outputs( [role.last_output for role in roles], weights ) return final_output, weights需要注意如果角色数量很大相似度矩阵是O(n²)的复杂度。我在实际项目里会先按职责分组只在同一个组内做冲突抑制不同组的输出直接按投影权重组合这样能把计算量降下来。4.3 为什么它比简单投票有效简单投票的毛病在于所有人都以同等身份说话无法体现“谁更接近目标”。而曾老师算法的关键不是选“支持人数最多的方案”而是选“与目标重叠程度最高且在组合后仍然不冲突的一组输出”。这两个标准有本质区别。我之前拿同一批实验数据对比过简单投票方案在两个角色意见相左时结果经常是三个角色各写一段然后拼起来A段和B段观点互相打架曾老师算法跑出来的结果是高投影角色的核心论点被保留低投影角色只保留不矛盾的补充信息整体逻辑一致性提升非常明显。5. 实操记录从零搭一个可运行的Demo考虑到很多人想看的是“我自己能不能跑通”这里放一条我实际验证过的搭建路径。整个Demo不需要真实量子计算环境只需要能调用任意一个LLM API就行。5.1 准备基础框架技术栈我选的是Python。目录结构简化成三层demo/ ├── agents/ # 角色定义与独立上下文 ├── core/ # 调度、权重、合并逻辑 └── main.py # 入口与测试脚本角色定义部分我用一个数据类统一描述dataclass class AgentState: name: str role: str system_prompt: str current_task: str history: list field(default_factorylist) last_output: str 每个AgentState实例对应一个角色调度层不直接操作这个类内部的提示词只读取统一暴露的state_vector和last_output两个字段。5.2 实现调度层核心函数调度层核心就是一个函数输入角色列表和全局目标输出组合结果和权重。我在demo里没有真的做语义向量编码而是简化成用LLM生成一个“相关性打分”效仿内积的效果def projection_score(role, global_goal): prompt f 判断以下角色当前输出与全局目标的相关程度输出0到1之间的数字。 全局目标{global_goal} 角色输出{role.last_output} response call_llm(prompt, max_tokens5) return float(response.strip())这个写法的优点是代码简单缺点是每次都要多调一次LLM成本会高。如果做成生产级系统我更推荐替换成离线计算的语义向量点积十几个角色一轮的耗时能从几秒降到几十毫秒。5.3 跑通一次多角色协作我设计了一个高频测试任务“为一款面向业余摄影师的入门课程写三节简介和一份风险点提示”。四个角色各自跑完初稿后曾老师算法把它们组合成最终文案。实测记录策划者输出的内容占最终稿的60%执行者补充占了30%质疑者提出的“课程定价不宜过高”被转成风险提示语记忆管家只是简单校对了前后措辞一致。整个流程用了三轮迭代第一轮权重比较平均第二轮冲突抑制后执行者权重上升第三轮收敛完成。如果你在自己机器上跑建议第一轮把temperature调到1.2让各角色充分表达第二轮再调到0.6让决策更果断。这样既不会第一轮就灭掉边缘想法又不会最后阶段迟迟收敛不了。6. 常见问题与排查技巧实录这套系统我前后迭代了三版踩坑无数。挑几个最典型的记录一下希望能帮你绕过。6.1 问题速查表现象可能原因解决方法所有角色输出越来越像上下文在多个角色间被间接共享检查协作事件总线上是否传了原始文本改成只传结构化摘要某个角色长期权重为0投影计算时全局目标向量过于偏科给全局目标增加多维度描述别只写单一关键词组合输出逻辑不连贯合并时按角色段落拼接没做语言层润色增加一道整合润色步骤用一个通用模型重写衔接部分运行成本突然翻倍投影评估频繁调用LLM打分把投影计算换成离线向量相关性或用缓存多轮后角色忘记职责每个角色历史摘要太长有效信息被稀释改用“滚动摘要”每轮只保留最近结果和最新目标变更6.2 我踩过的三个深坑第一个坑是角色污染问题。最早版本我用一个公共内存库记录所有角色的历史理论上只允许角色A读自己的历史但某个状态下角色B的检索逻辑写错读到了角色A的上下文结果执行者突然用策划者的口吻输出。后来我把读写权限做成显式接口所有检索都带角色ID过滤才算根治。第二个坑是权重振荡。头两版算法没有做平滑导致相邻两轮之间的权重变化很大结果整个协作过程像精神分裂一个方案刚成形就被另一角色推翻。解决办法是给权重加一阶惯性也就是上一轮权重的60%保留到下一轮这样系统更稳定也更像真实团队的决策节奏。第三个坑是过度收敛。temperature调太低之后整个系统变成了“一个角色说话其他人点头”多样性归零方案没了灵气。现在我的建议是至少保留一个“质疑者”角色不被压权即使它的投影值很低也给它一个固定的最低表达比例比如5%。这相当于团队里永远留一个唱反调的人。6.3 调试时的观察技巧我调试时最常用的是“权重时间线”。把每一轮每个角色的权重打印成一条折线图配合输出片段一眼就能看出谁在哪个阶段主导了方向。如果某一段输出效果特别好回看时间线就知道应该把那个阶段的决策模式固化成规则。权重时间线的关键词就是两个谁是主导者、谁被压制。大多数协作问题都能从这两点里找到答案。7. 后续还能怎么玩与我的个人体会这套系统的价值不在于“量子”这个名头而在于它逼我重新梳理了多角色协作的四个核心问题角色如何定义、状态如何隔离、权重如何计算、冲突如何处理。Bra-Ket符号只是帮助我把这些问题用更清晰的数学语言表达出来真正让系统跑起来的还是工程上的取舍。后续我在考虑两个扩展方向。一个是让“曾老师”变成真正的自适应学习模块根据过往任务的反馈自动调整温度、冲突阈值和角色基底而不是每次人工调参。另一个是把这套协作模式嵌入到更复杂的持续任务中比如让一个策划者链条持续跟进一个月的项目每天自动刷新全局目标调整各角色的任务拆解。这个方向如果能做成就不再是一个Demo而是一个真正能长期陪伴工作的AI协作团队。最后分享一个在实际操作中很管用的小技巧不要一上来就设计八个角色。我最初版本设计了八个结果一大半时间都在维护角色之间的边界。后来砍到四个系统反而更流畅。角色数量不是越多越好关键是每个角色都要有不可替代的职责。如果你想试试这套协作系统从两个角色起步一个负责产出一个负责质疑。跑顺了再慢慢加人。 
长河君 · 2026/10/22 19:38:58 · 阅读 1.2k 基于Bra-Ket符号的多人格AI协作系统设计与实践
先交代一下背景我前阵子在做一个内部实验目标很单纯——让多个AI角色在一套系统里既保持各自的“性格”和职责又不要互相抢话、互相污染还能像一支配合了半年的团队那样把一件复杂任务拆解完。折腾过单纯用提示词堆、用角色卡堆也试过让多个LLM API并发跑再简单投票结果都不理想。最后我借了量子力学里的Bra-Ket符号形式搭了一套“多人格AI协作系统”还给核心调度逻辑起了个代号曾老师智慧算法。这篇文章不会讲什么玄学就是把这套系统的设计思路、公式映射、工程实现和踩坑记录完整摊开想给同样在搞多Agent协作或者AI角色管理系统的人一点可抄作业的参考。1. 先聊清楚多人格AI协作到底难在哪很多人一上来就误会以为“多人格AI协作”就是拿一个统一Prompt里面写上“你是客服小A你是审核小B你是文案小C”然后让模型自己切换。实测下来这种方案在单轮对话里勉强能用一旦进入多轮、多任务、多角色交叉的场景问题会像洋葱一样一层一层冒出来。1.1 单模型多角色时最常见的失控现场我最早做的一个模拟项目X需要同时处理客服答疑、内容合规检查、营销文案生成三个角色。我把三套人格说明写进同一个系统提示词结果遇到三个经典故障角色串味客服角色回答到一半突然开始输出营销话术还带着另外一套人格的口吻。目标倾轧合规角色太强势把所有客服回复都改成“建议您自行查阅”导致体验差到没法上线。上下文漂移聊到第7轮后系统提示词里的角色边界基本失效模型开始按最近几轮的用户语气即兴发挥。问题根源不是模型不够聪明而是所有角色共用一个上下文状态角色信息被当成了“背景文本”而不是“有边界的行为约束”。这就好比一群人开会每个人都有自己的立场但会议室里只有一个话筒谁先抢到谁说话最后输出的东西完全取决于临场情绪而不是角色本身的能力。1.2 团队协作视角下的“状态叠加”做了一段时间后我开始换一个角度看问题与其把角色当成一段段提示词不如把它们当成一组“行为状态”。每个角色在任意时刻都有一个状态这个状态里包含它的系统设定、最近输入、当前任务目标、已有输出片段。多个角色同时存在共同影响最终输出这就是一种“叠加”。但这里的叠加不是量子物理意义上的真实叠加而是管理学意义上的状态混合。问题是怎么描述这种混合怎么决定谁的影响占主导怎么在冲突时做取舍我当时给了自己一个很直白的类比团队开会时每个成员都在脑中形成一个“目标投影”这些投影之间有的方向一致有的方向相反。最终决策不是简单的平均也不是少数服从多数而是要看每个投影相对于全局目标的“重叠度”。重叠度越高的意见权重自然越高。基于这个想法我开始把Bra-Ket符号形式当成协作系统的数学骨架。2. Bra-Ket量子形式能不能当协作系统的设计语言先别被“量子”两个字吓退。Bra-Ket符号是狄拉克发明的线性代数记号本来是用在量子力学里的但其核心思想完全可以移植到AI系统的状态管理和调度设计上。我用的并不是真正的量子计算只是借用它的符号体系来表达“多个状态之间的关系”。2.1 五分钟理解狄拉克符号Bra-Ket里面只有两种核心角色Ket向量 |ψ⟩表示一个状态。可以理解成“当前系统处在某个具体情形下的描述”。Bra向量 ⟨φ|表示一种观测或者约束。可以理解成“我们希望系统满足什么条件”。两个符号合在一起写成 ⟨φ|ψ⟩叫内积数值上表示两个状态的“重叠程度”或“投影强度”。如果两个状态方向完全一致内积接近1如果方向完全相反内积接近0甚至为负。我在系统里做了一个简单但关键的映射每个AI角色的人格和当前即时状态合并成一个Ket向量全局任务目标和一个“本轮的硬性约束”合并成Bra向量。然后用内积来决定这个角色本轮应该获得多大的话语权。2.2 量子概念对应表量子力学概念在多人格AI系统里的对应物作用态向量 |ψ_i⟩角色i的完整运行状态系统提示、上下文、当前中间产物描述角色“此刻想做什么”观测算符 ⟨C|全局目标与硬性约束任务要求、合规边界、输出格式定义“这一次协作的验收标准”内积 ⟨C|ψ_i⟩角色i当前输出与全局目标的相关度决定角色i本轮权重基态集合一组正交化的人格模板策划、执行、审核、记忆减少角色之间的语义污染测量坍缩收敛输出选出一个组合后的最终结果让协作有明确终点这套映射用下来最大的收益不是“算得准”而是让代码结构变得非常清晰谁负责定义状态、谁负责计算相关性、谁负责组合输出一目了然。2.3 用内积解决目标碰撞的例子举个例子。一次任务里策划角色想走“大胆前卫”的创意方向合规角色想走“保守稳妥”的方向两个角色在交叉评审时互相攻击。旧方案我是让它们轮流发言最后取个并集结果方案变成缝合怪。换用Bra-Ket思路后我引入两个投影值策划对全局目标的内积 p_plan ⟨C|ψ_plan⟩合规对全局目标的内积 p_compliance ⟨C|ψ_compliance⟩谁的投影值高谁的核心观点保留更多另一方只保留与全局目标不冲突的部分。这样不用真正“说服”其中一个角色而是让它们在目标层面自动完成了一次加权协商。3. 多人格AI协作系统的整体架构这套系统我在工程上拆成了五层角色层、状态层、调度层、组合层、输出层。每一层只做一件事调试时特别省心。3.1 角色层人格基底的设定角色层不直接写死一整段人格描述而是把每个角色拆成三块身份标签角色的职责边界例如“策划者”“执行者”“质疑者”。行为规则集在这个项目中允许做什么、禁止做什么。语气风格参数输出长度、正式程度、是否允许反问等。这三块共同构成角色的“基底”。系统里我预设了四个基底角色策划者负责拆解目标、执行者负责产出具体内容、质疑者负责找漏洞、记忆管家负责维护历史上下文。这样设计的好处是任意复杂任务都可以由这四个基础角色组合完成而不是为每个新需求都新造一个角色。3.2 状态层每个角色一个独立上下文我放弃了“所有人共用一个上下文”的做法。每个角色维护自己的消息队列和状态缓存状态格式是一个统一的字典包含role、current_task、history_summary、last_output。聊天时角色之间不直接读写彼此的原始上下文只能通过一个“协作事件总线”收发结构化的消息。例如策划者发布一条“目标已更新”的消息执行者订阅后把新目标写入自己的当前任务字段。上下文隔离是这套系统没再出现角色串味的关键。3.3 调度层Bra-Ket投影计算与权重分配调度层是整系统的核心负责算每个角色的投影值然后决定本轮各角色输出的组合权重。具体流程会在下一节展开。调度层还兼任“目标守卫”如果某个角色的输出明显偏离全局目标调度层会直接把它的权重压到接近0。3.4 组合层与输出层生成最终结果组合层拿到各角色的输出和权重后不是简单拼接而是按段落做加权取舍。比如策划者给出十个要点执行者产出了五段文字质疑者提出了三个风险点组合层会把风险点转成附注把执行者的文字按策划要点重新排序最终形成一篇有共同主题、有审核痕迹的结构化内容。输出层再做最后一次格式校验保证输出是用户能直接使用的形式。4. 曾老师智慧算法的核心逻辑“曾老师”这个名字并不是指某个具体的人而是我在工程里给“统筹决策模块”起的代号。它在我心里扮演的角色等同于“一个经验丰富的老教师在最后把关”听所有人汇报但不盲目相信任何人结合全局目标做加权裁决。4.1 算法的三段式流程曾老师智慧算法每次运行分三步投影打分、冲突抑制、收敛组合。第一步对整个角色集合计算内积 p_i ⟨C|ψ_i⟩。这一步需要把全局目标和角色状态向量化。我没有用什么花哨的向量数据库就是先用模型生成一个512维的语义摘要向量再通过一个简单映射函数折算成0到1之间的标量。推理量的控制上50个角色以内都不是问题。第二步按投影值生成初始权重。这一步会先做一次温度缩放避免某个角色投影值略高就直接垄断话语权。权重公式用到的正是一个标准的softmaxw_i exp(p_i / temperature) / Σ_j exp(p_j / temperature)temperature值我默认设在0.8。数值越大各角色权重越平均数值越小越倾向于服从投影最高的角色。实际使用中需要高创意的时候调高需要强执行的时候调低。第三步冲突抑制。计算任意两个角色输出之间的相似度矩阵如果相似度过高说明两个角色在同质化输出需要把后发言者权重压低保证多样性。这一步避免团队陷入“所有人都在重复同一个正确废话”的局面。4.2 算法的伪代码实现下面是我在模拟项目X里跑过的简化版伪代码可以直接抄去改def zeng_teacher_algorithm(roles, global_state): # roles: 每个角色包含 state_vector 和 last_output # global_state: 本轮全局目标向量 weights [] for role in roles: p dot(global_state, role.state_vector) # 投影值 weights.append(p / temperature_scale) weights softmax(weights) # 归一化 # 冲突抑制相似度惩罚 for i in range(len(roles)): for j in range(i 1, len(roles)): sim cosine_similarity(roles[i].last_output, roles[j].last_output) if sim 0.7: # 后发言者降权 weights[j] * 0.5 weights weights / sum(weights) final_output merge_outputs( [role.last_output for role in roles], weights ) return final_output, weights需要注意如果角色数量很大相似度矩阵是O(n²)的复杂度。我在实际项目里会先按职责分组只在同一个组内做冲突抑制不同组的输出直接按投影权重组合这样能把计算量降下来。4.3 为什么它比简单投票有效简单投票的毛病在于所有人都以同等身份说话无法体现“谁更接近目标”。而曾老师算法的关键不是选“支持人数最多的方案”而是选“与目标重叠程度最高且在组合后仍然不冲突的一组输出”。这两个标准有本质区别。我之前拿同一批实验数据对比过简单投票方案在两个角色意见相左时结果经常是三个角色各写一段然后拼起来A段和B段观点互相打架曾老师算法跑出来的结果是高投影角色的核心论点被保留低投影角色只保留不矛盾的补充信息整体逻辑一致性提升非常明显。5. 实操记录从零搭一个可运行的Demo考虑到很多人想看的是“我自己能不能跑通”这里放一条我实际验证过的搭建路径。整个Demo不需要真实量子计算环境只需要能调用任意一个LLM API就行。5.1 准备基础框架技术栈我选的是Python。目录结构简化成三层demo/ ├── agents/ # 角色定义与独立上下文 ├── core/ # 调度、权重、合并逻辑 └── main.py # 入口与测试脚本角色定义部分我用一个数据类统一描述dataclass class AgentState: name: str role: str system_prompt: str current_task: str history: list field(default_factorylist) last_output: str 每个AgentState实例对应一个角色调度层不直接操作这个类内部的提示词只读取统一暴露的state_vector和last_output两个字段。5.2 实现调度层核心函数调度层核心就是一个函数输入角色列表和全局目标输出组合结果和权重。我在demo里没有真的做语义向量编码而是简化成用LLM生成一个“相关性打分”效仿内积的效果def projection_score(role, global_goal): prompt f 判断以下角色当前输出与全局目标的相关程度输出0到1之间的数字。 全局目标{global_goal} 角色输出{role.last_output} response call_llm(prompt, max_tokens5) return float(response.strip())这个写法的优点是代码简单缺点是每次都要多调一次LLM成本会高。如果做成生产级系统我更推荐替换成离线计算的语义向量点积十几个角色一轮的耗时能从几秒降到几十毫秒。5.3 跑通一次多角色协作我设计了一个高频测试任务“为一款面向业余摄影师的入门课程写三节简介和一份风险点提示”。四个角色各自跑完初稿后曾老师算法把它们组合成最终文案。实测记录策划者输出的内容占最终稿的60%执行者补充占了30%质疑者提出的“课程定价不宜过高”被转成风险提示语记忆管家只是简单校对了前后措辞一致。整个流程用了三轮迭代第一轮权重比较平均第二轮冲突抑制后执行者权重上升第三轮收敛完成。如果你在自己机器上跑建议第一轮把temperature调到1.2让各角色充分表达第二轮再调到0.6让决策更果断。这样既不会第一轮就灭掉边缘想法又不会最后阶段迟迟收敛不了。6. 常见问题与排查技巧实录这套系统我前后迭代了三版踩坑无数。挑几个最典型的记录一下希望能帮你绕过。6.1 问题速查表现象可能原因解决方法所有角色输出越来越像上下文在多个角色间被间接共享检查协作事件总线上是否传了原始文本改成只传结构化摘要某个角色长期权重为0投影计算时全局目标向量过于偏科给全局目标增加多维度描述别只写单一关键词组合输出逻辑不连贯合并时按角色段落拼接没做语言层润色增加一道整合润色步骤用一个通用模型重写衔接部分运行成本突然翻倍投影评估频繁调用LLM打分把投影计算换成离线向量相关性或用缓存多轮后角色忘记职责每个角色历史摘要太长有效信息被稀释改用“滚动摘要”每轮只保留最近结果和最新目标变更6.2 我踩过的三个深坑第一个坑是角色污染问题。最早版本我用一个公共内存库记录所有角色的历史理论上只允许角色A读自己的历史但某个状态下角色B的检索逻辑写错读到了角色A的上下文结果执行者突然用策划者的口吻输出。后来我把读写权限做成显式接口所有检索都带角色ID过滤才算根治。第二个坑是权重振荡。头两版算法没有做平滑导致相邻两轮之间的权重变化很大结果整个协作过程像精神分裂一个方案刚成形就被另一角色推翻。解决办法是给权重加一阶惯性也就是上一轮权重的60%保留到下一轮这样系统更稳定也更像真实团队的决策节奏。第三个坑是过度收敛。temperature调太低之后整个系统变成了“一个角色说话其他人点头”多样性归零方案没了灵气。现在我的建议是至少保留一个“质疑者”角色不被压权即使它的投影值很低也给它一个固定的最低表达比例比如5%。这相当于团队里永远留一个唱反调的人。6.3 调试时的观察技巧我调试时最常用的是“权重时间线”。把每一轮每个角色的权重打印成一条折线图配合输出片段一眼就能看出谁在哪个阶段主导了方向。如果某一段输出效果特别好回看时间线就知道应该把那个阶段的决策模式固化成规则。权重时间线的关键词就是两个谁是主导者、谁被压制。大多数协作问题都能从这两点里找到答案。7. 后续还能怎么玩与我的个人体会这套系统的价值不在于“量子”这个名头而在于它逼我重新梳理了多角色协作的四个核心问题角色如何定义、状态如何隔离、权重如何计算、冲突如何处理。Bra-Ket符号只是帮助我把这些问题用更清晰的数学语言表达出来真正让系统跑起来的还是工程上的取舍。后续我在考虑两个扩展方向。一个是让“曾老师”变成真正的自适应学习模块根据过往任务的反馈自动调整温度、冲突阈值和角色基底而不是每次人工调参。另一个是把这套协作模式嵌入到更复杂的持续任务中比如让一个策划者链条持续跟进一个月的项目每天自动刷新全局目标调整各角色的任务拆解。这个方向如果能做成就不再是一个Demo而是一个真正能长期陪伴工作的AI协作团队。最后分享一个在实际操作中很管用的小技巧不要一上来就设计八个角色。我最初版本设计了八个结果一大半时间都在维护角色之间的边界。后来砍到四个系统反而更流畅。角色数量不是越多越好关键是每个角色都要有不可替代的职责。如果你想试试这套协作系统从两个角色起步一个负责产出一个负责质疑。跑顺了再慢慢加人。