先交代一下背景：我前阵子在做一个内部实验，目标很单纯——让多个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 量子概念对应表

这套映射用下来，最大的收益不是“算得准”，而是让代码结构变得非常清晰：谁负责定义状态、谁负责计算相关性、谁负责组合输出，一目了然。

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个角色以内都不是问题。

第二步，按投影值生成初始权重。这一步会先做一次温度缩放，避免某个角色投影值略高就直接垄断话语权。权重公式用到的正是一个标准的softmax：

w_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_factory=list) 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_tokens=5) return float(response.strip())

这个写法的优点是代码简单，缺点是每次都要多调一次LLM，成本会高。如果做成生产级系统，我更推荐替换成离线计算的语义向量点积，十几个角色一轮的耗时能从几秒降到几十毫秒。

5.3 跑通一次多角色协作

我设计了一个高频测试任务：“为一款面向业余摄影师的入门课程写三节简介和一份风险点提示”。四个角色各自跑完初稿后，曾老师算法把它们组合成最终文案。

实测记录：策划者输出的内容占最终稿的60%，执行者补充占了30%，质疑者提出的“课程定价不宜过高”被转成风险提示语，记忆管家只是简单校对了前后措辞一致。整个流程用了三轮迭代，第一轮权重比较平均，第二轮冲突抑制后执行者权重上升，第三轮收敛完成。

如果你在自己机器上跑，建议第一轮把temperature调到1.2，让各角色充分表达；第二轮再调到0.6，让决策更果断。这样既不会第一轮就灭掉边缘想法，又不会最后阶段迟迟收敛不了。

6. 常见问题与排查技巧实录

这套系统我前后迭代了三版，踩坑无数。挑几个最典型的记录一下，希望能帮你绕过。

6.1 问题速查表

6.2 我踩过的三个深坑

第一个坑是角色污染问题。最早版本我用一个公共内存库记录所有角色的历史，理论上只允许角色A读自己的历史，但某个状态下角色B的检索逻辑写错，读到了角色A的上下文，结果执行者突然用策划者的口吻输出。后来我把读写权限做成显式接口，所有检索都带角色ID过滤，才算根治。

第二个坑是权重振荡。头两版算法没有做平滑，导致相邻两轮之间的权重变化很大，结果整个协作过程像精神分裂，一个方案刚成形就被另一角色推翻。解决办法是给权重加一阶惯性，也就是上一轮权重的60%保留到下一轮，这样系统更稳定，也更像真实团队的决策节奏。

第三个坑是过度收敛。temperature调太低之后，整个系统变成了“一个角色说话其他人点头”，多样性归零，方案没了灵气。现在我的建议是至少保留一个“质疑者”角色不被压权，即使它的投影值很低，也给它一个固定的最低表达比例，比如5%。这相当于团队里永远留一个唱反调的人。

6.3 调试时的观察技巧

我调试时最常用的是“权重时间线”。把每一轮每个角色的权重打印成一条折线图，配合输出片段，一眼就能看出谁在哪个阶段主导了方向。如果某一段输出效果特别好，回看时间线，就知道应该把那个阶段的决策模式固化成规则。

权重时间线的关键词就是两个：谁是主导者、谁被压制。大多数协作问题都能从这两点里找到答案。

7. 后续还能怎么玩与我的个人体会

这套系统的价值不在于“量子”这个名头，而在于它逼我重新梳理了多角色协作的四个核心问题：角色如何定义、状态如何隔离、权重如何计算、冲突如何处理。Bra-Ket符号只是帮助我把这些问题用更清晰的数学语言表达出来，真正让系统跑起来的，还是工程上的取舍。

后续我在考虑两个扩展方向。一个是让“曾老师”变成真正的自适应学习模块，根据过往任务的反馈，自动调整温度、冲突阈值和角色基底，而不是每次人工调参。另一个是把这套协作模式嵌入到更复杂的持续任务中，比如让一个策划者链条持续跟进一个月的项目，每天自动刷新全局目标，调整各角色的任务拆解。这个方向如果能做成，就不再是一个Demo，而是一个真正能长期陪伴工作的AI协作团队。

最后分享一个在实际操作中很管用的小技巧：不要一上来就设计八个角色。我最初版本设计了八个，结果一大半时间都在维护角色之间的边界。后来砍到四个，系统反而更流畅。角色数量不是越多越好，关键是每个角色都要有不可替代的职责。如果你想试试这套协作系统，从两个角色起步：一个负责产出，一个负责质疑。跑顺了，再慢慢加人。