不是关于速度。而是关于让多个不同观点的 Agent 就一个决策进行争论,并得出比任何单个 Agent 都更好的结论。附上完整代码:编排器、专家和合并。
当你让一个模型评估一个决策时,它只会给出一个观点,通常平均且谨慎。它倾向于同意、平滑、寻找平衡。这就是问题所在:一个重要的决策不能由一个平均化的观点来评估,它必须从不同侧面被攻击。
一组 Agent 群从结构上解决了这个问题。你创建多个专家,每个都有硬性的角色和偏见:一个只考虑金钱,另一个只考虑技术风险,第三个只考虑用户。他们独立分析同一个决策,得出不同的结论,然后你强制对这些结论进行协调。这里的价值不是速度,而是分歧被内置于结构中。单个 Agent 倾向于与自己达成群体思维,而一组角色则不会。
本文展示了如何构建这样一个 Agent 群,并附有代码。我们涵盖三个部分:分配角色的编排器、独立分析的专家,以及将它们协调为一个结论的合并器。
架构:编排器、专家、合并器
用于分析的 Agent 群由三个组件组成。
编排器接收任务并决定需要哪些专家角色。对于评估产品发布,这些角色可能包括投资者、工程师、产品专家、安全人员。编排器本身不分析,它分配角色。
专家们并行且独立地工作。每个专家都看到相同的决策,但通过自己的视角。关键是,他们看不到彼此的结论,否则就会产生趋同。独立性是产生不同观点的原因。
合并器收集专家的结论并进行协调:他们在哪里达成一致,在哪里矛盾,最终 verdict 是什么。这不是平均化,而是将分歧作为信号保留的综合。

第一步:基本客户端
从一个简单的模型客户端开始。我使用兼容 OpenAI 的消息格式,它适用于大多数提供商和本地 Ollama。
1import requests2import json3from concurrent.futures import ThreadPoolExecutor45API = "http://localhost:11434/api/chat" # Ollama,或提供商端点6MODEL = "qwen2.5:32b"78def ask(system, user, temperature=0.7):9 resp = requests.post(API, json={10 "model": MODEL,11 "messages": [12 {"role": "system", "content": system},13 {"role": "user", "content": user},14 ],15 "temperature": temperature,16 "stream": False,17 }, timeout=120)18 resp.raise_for_status()19 return resp.json()["message"]["content"]
第二步:编排器分配角色
编排器获取任务并决定需要哪些专家。不要预先硬编码角色,让模型针对特定任务选择它们,这样 Agent 群才具有通用性。要求返回严格的 JSON 以便解析。
1ORCHESTRATOR_SYSTEM = """你是分析型 Agent 群的编排器。2对于给定的任务,定义 3-5 个专家角色,这些角色将对决策提供最大程度不同3且相互冲突的观点。这些角色的利益必须冲突,而不是互补。45为每个角色提供:名称、关注点(它执着于什么)、偏见(它倾向于什么,它容易高估什么)。67仅回复一个 JSON 数组,不要解释:8[{"name": "...", "focus": "...", "bias": "..."}, ...]9"""1011def plan_roles(task):12 raw = ask(ORCHESTRATOR_SYSTEM, f"要分析的任务:\n{task}",13 temperature=0.9) # 较高的温度以获得角色多样性14 # 切出 JSON,以防模型在周围添加了文本15 start, end = raw.find("["), raw.rfind("]") + 116 return json.loads(raw[start:end])
我们故意在这里保持高温度:我们希望角色多样化,而不是显而易见的。提示中的“角色必须冲突”是关键,没有它,模型会给出三个几乎相同的角色,整个 Agent 群的意义就丧失了。
第三步:专家并行且独立地分析
每个专家获得其角色和相同的决策。关键是:他们并行运行,并且看不到彼此的结论。这里的并行性不仅是为了速度,它保证了独立性——一个专家物理上无法调整以适应另一个专家的意见。
1EXPERT_SYSTEM = """你是一名专家,角色:{name}。2你的关注点:{focus}。3你的偏见:{bias}。不要对抗它,它正是你对分析的价值所在。45严格从你的立场分析决策。不要平衡,不要试图考虑其他观点,其他专家会做这些。6你的工作是将你的角度推向极限。78给出:9- 从你的立场得出的结论(赞成/反对/有条件)10- 2-3 个从你的角度出发的主要论点11- 1 个从你的立场最明显而其他人会忽略的风险12简短有力,不要废话。"""1314def run_expert(role, task):15 system = EXPERT_SYSTEM.format(**role)16 opinion = ask(system, f"要分析的决策:\n{task}", temperature=0.7)17 return {"role": role["name"], "opinion": opinion}1819def run_swarm(roles, task):20 # 并行启动:独立性和速度兼得21 with ThreadPoolExecutor(max_workers=len(roles)) as pool:22 futures = [pool.submit(run_expert, role, task) for role in roles]23 return [f.result() for f in futures]
注意专家的提示:我们明确禁止它保持平衡。这反直觉,但正是关键所在。如果每个专家都试图考虑所有方面,你会得到五个相同的谨慎意见。通过强制每个专家将其角度推向极限,你得到一个真正的光谱,然后由合并器进行协调。
第四步:合并器协调结论
现在我们有了几个尖锐、片面的意见。合并器将它们收集成一个结论,但不是通过平均化。它寻找专家们达成一致的地方(强信号),他们矛盾的地方(需要决策的风险区域),以及什么比什么更重要。
1MERGE_SYSTEM = """你是分析型 Agent 群的合成器。你得到了几位具有不同偏见的专家对一个决策的意见。23你的工作不是平均化它们。你的工作是:41. 一致:尽管立场不同,专家们达成了什么共识。这是最可靠的信号,请突出显示。52. 冲突:专家们直接矛盾的地方。不要平滑处理,明确说出冲突,并指出每一方的代价。63. 盲点:只有一位专家提到的风险,但它很重要。74. 最终结论:综合考虑后的赞成/反对/有条件,以及在什么条件下会改变。89写得紧凑。将分歧作为信息保留,不要隐藏它。"""1011def merge_opinions(task, opinions):12 block = "\n\n".join(13 f"### 专家:{o['role']}\n{o['opinion']}" for o in opinions14 )15 user = f"决策:\n{task}\n\n专家意见:\n{block}"16 return ask(MERGE_SYSTEM, user, temperature=0.4) # 较低温度以获得冷静的合成
我们在合并时降低温度:如果专家应该多样化(高 T),那么合成器应该冷静且一致(低 T)。这里的关键指令是“不要平均化,将分歧作为信息保留”。普通的合并会把一切变成稀粥,“一方面,另一方面”。一个好的合并会直截了当地说:这里所有人都同意,而这里有一个冲突,代价是这么多。
第 4.5 步:对抗虚假一致的魔鬼代言人
有一个潜在的危险:有时专家们达成一致不是因为决策好,而是因为每个人都出于惯性看向同一个方向。这是虚假的一致,它比公开的冲突更危险,因为它看起来像信心。
针对这一点,我们添加一个特殊的 Agent:魔鬼代言人。它唯一的工作就是攻击共识。它看到所有专家的意见,并有义务找出为什么他们可能同时都错了。如果 Agent 群一致投票“赞成”,代言人就会寻找一个场景,证明这可能是灾难。
1DEVIL_SYSTEM = """你是分析型 Agent 群中的魔鬼代言人。你得到了专家们的意见。你唯一的工作:攻击他们的一致意见。23如果专家们在某件事上趋同,找出为什么他们可能同时都错了。寻找一个共同的盲点:一个所有人都未经检查就接受的假设,一个因为不方便而没人考虑的情景。45不要客气。你的价值在于你说出群体不想听的话。给出:6- 专家们最危险的共同假设是什么7- 一个情景,其中 Agent 群的一致意见被证明是致命错误的8- 一个群体小心回避的问题9如果没有一致意见,专家们真正有分歧,就直说,并指出最尖锐的未解决冲突。"""1011def run_devil(task, opinions):12 block = "\n\n".join(13 f"### {o['role']}\n{o['opinion']}" for o in opinions14 )15 user = f"决策:\n{task}\n\nAgent 群意见:\n{block}"16 return ask(DEVIL_SYSTEM, user, temperature=0.8)
代言人在专家之后、合并之前运行,它的攻击与意见一起进入合成。关键是,即使是一个一致同意的 Agent 群,也至少有一个 Agent 有义务寻找裂缝。这很便宜(一次调用),并在结构上打破群体思维:共识现在必须经受住攻击,而不仅仅是发生。
第 4.6 步:一轮辩论来激化冲突
第一轮专家分析是独立的,这有利于多样性。但在收集意见后,你可以给出一轮辩论:向每个专家展示其他专家意见的摘要,并让其提出异议。这激化了冲突,薄弱的论点被淘汰,强大的论点得到巩固。
1DEBATE_SYSTEM = """你是第二轮分析中的专家 {name}。2你原来的立场:3{own_opinion}45现在你看到了其他专家的意见。不要屈服于压力,但也不要忽视强有力的论点。给出:6- 如果别人的论点真正击中了你的立场,诚实地承认7- 你在哪里坚持你的立场,以及为什么他们的异议是薄弱的8- 辩论后你是否改变了你的结论,如果改变了,如何改变9简短。这不是第一轮意见的重复,而是对对手的反应。"""1011def debate_round(roles, task, opinions):12 others_map = {}13 for o in opinions:14 others = "\n\n".join(15 f"### {x['role']}\n{x['opinion']}" for x in opinions if x is not o16 )17 others_map[o["role"]] = others1819 def rebut(o):20 system = DEBATE_SYSTEM.format(name=o["role"], own_opinion=o["opinion"])21 user = (f"决策:\n{task}\n\n"22 f"对手的意见:\n{others_map[o['role']]}")23 return {"role": o["role"], "opinion": ask(system, user, temperature=0.6)}2425 with ThreadPoolExecutor(max_workers=len(opinions)) as pool:26 return list(pool.map(rebut, opinions))
辩论轮也是并行的:每个专家同时对所有其他专家做出反应,再次避免实时趋同。辩论后,意见通常更尖锐:你可以看到哪些立场在火力下坚持住了,哪些崩溃了。正是这些经过强化的意见进入最终的合并。
第五步:整合在一起
1def analyze(task, debate=True):2 print("编排器正在挑选角色...")3 roles = plan_roles(task)4 for r in roles:5 print(f" - {r['name']}: {r['focus']}")67 print(f"\n并行启动 {len(roles)} 个专家...")8 opinions = run_swarm(roles, task)9 for o in opinions:10 print(f"\n[{o['role']}]\n{o['opinion']}")1112 # 可选的辩论轮:专家们互相反驳13 if debate:14 print("\n辩论轮,专家们互相反驳...")15 opinions = debate_round(roles, task, opinions)1617 # 魔鬼代言人攻击 Agent 群的一致意见18 print("\n魔鬼代言人寻找一致意见中的裂缝...")19 devil = run_devil(task, opinions)20 print(f"\n[魔鬼代言人]\n{devil}")2122 # 合并器协调结论以及代言人的攻击23 print("\n合并器正在协调结论...")24 opinions_plus = opinions + [{"role": "魔鬼代言人", "opinion": devil}]25 verdict = merge_opinions(task, opinions_plus)26 print(f"\n=== 最终结论 ===\n{verdict}")27 return verdict2829if __name__ == "__main__":30 analyze(31 "我们想取消免费套餐,让产品完全付费,并提供 14 天试用。我们应该这样做吗?"32 )
运行这段代码,你会看到完整的流程:编排器挑选角色,专家们从各自角度切割真相,在辩论轮中互相辩论,代言人攻击他们的一致意见,合并器给出包含攻击在内的最终结论。同一个问题,单个 Agent 会给出模糊的“取决于你的受众”,而 Agent 群会给出结构化的分析,其中冲突是明确的,共识也经过了压力测试。
是什么让这个 Agent 群有效
三个因素区分了有用的 Agent 群和由 Agent 组成的表演。
角色必须冲突,而不是互补。如果你的专家是“一个营销人员、一个 SMM 专家、一个内容经理”,他们会给出几乎相同的答案,因为他们的利益一致。真正的价值在于利益冲突:增长 vs 可持续性,速度 vs 质量,眼前的钱 vs 未来的信任。利益冲突才能打开决策。
专家们不能互相看到。一旦一个专家看到另一个专家的意见,趋同就开始了,它会调整。独立性不是一个实现细节,而是一个工作条件。并行启动免费提供了这一点。
合并器不平均化,而是保留冲突。一个糟糕的合并会把五个尖锐的意见变成一个无牙的摘要。一个好的合并让冲突可见,因为冲突是最有价值的信息:它显示了决策真正有风险的地方,而不是每个人都点头的地方。
扩展方向
这个骨架可以朝明显的方向扩展。你可以添加一个辩论轮:在第一次合并后,向专家展示摘要,让他们提出异议,这激化了冲突。你可以用一个更强的模型作为裁判,放在专家之上来权衡论点。你可以将角色固定用于重复发生的决策类型,这样就不必每次都生成。
但基本原则保持不变:不同的视角、独立的分析、尊重分歧的合成。一个 Agent 群对分析有用,不是因为有很多 Agent,而是因为他们以不同的方式看待,并且不让彼此滑向共同点。拿一个你现在独自在脑海里翻来覆去的决策,通过这样一个 Agent 群运行它。你会看到你之前没有抓住的角度。





