在很多 AI 应用中人们习惯把“大模型能力”理解成单个模型的能力。一个模型负责理解需求。一个模型负责生成代码。一个模型负责检查错误。一个模型负责输出结果。这种单模型结构简单也容易实现。但随着任务复杂度上升单个模型会遇到明显瓶颈。它既要理解业务又要设计架构。既要生成代码又要审查代码。既要推进任务又要判断风险。既要保持创造性又要遵守严格约束。这些目标之间经常互相冲突。生成者希望快速给出方案。审查者希望尽量发现风险。规划者希望任务结构完整。执行者希望步骤足够具体。业务角色关注结果。工程角色关注稳定性。如果把所有职责都压在一个模型上最终得到的往往不是“全能智能”而是一种不断切换角色的混合状态。这也是多智能体系统出现的原因。与其要求一个模型同时扮演所有角色不如把复杂任务拆给多个具有不同职责、不同上下文和不同约束的 Agent。例如Planner Agent 负责任务规划 Architect Agent 负责架构设计 Coder Agent 负责代码实现 Reviewer Agent 负责代码审查 Tester Agent 负责测试设计 Risk Agent 负责风险识别看起来问题似乎被解决了。每个 Agent 只做自己擅长的事整个系统就能像一个虚拟团队一样协作。但真正进入工程实践后会发现多智能体系统最困难的问题并不是“如何分工”。真正困难的是当多个 Agent 得出不同结论时系统应该相信谁这涉及一致性、冲突消解、权力分配、证据管理和最终责任归属。多智能体系统的核心不是 Agent 数量。而是决策机制。一、为什么单 Agent 架构会逐渐失效单 Agent 的基础结构通常很简单classSingleAgent:def__init__(self,model,tools):self.modelmodel self.toolstoolsdefrun(self,task:str)-str:contextself.collect_context(task)planself.model.plan(task,context)resultself.execute(plan)returnself.model.summarize(result)它接收任务、收集上下文、生成计划、执行并输出结果。对于简单任务这种结构足够有效。例如解释一段代码编写一个独立函数整理一份文档生成一个简单脚本分析一个明确报错。但当任务变成“设计并实现一个完整系统”时问题就出现了。假设任务是为电商系统增加一套高并发库存扣减机制同时保证订单一致性和失败补偿。这个任务至少包含业务语义分析 并发模型设计 缓存策略 数据库事务 消息队列 幂等控制 异常补偿 监控报警 性能测试 降级策略单 Agent 要同时处理这些层面很容易出现局部优化。例如它可能给出一个性能很高的 Redis 扣减方案却忽略数据库最终一致性。也可能设计完整事务流程却导致吞吐量无法接受。还可能代码结构很漂亮但没有考虑重复消息与补偿失败。问题并不一定来自模型不够聪明。而是因为复杂系统本身包含多个互相竞争的目标。性能 vs 一致性 开发效率 vs 长期维护 自动化程度 vs 可控性 系统复杂度 vs 容错能力 局部最优 vs 全局稳定单个 Agent 很难同时保持所有视角。多 Agent 架构的价值就是把这些冲突显式化。二、多智能体系统不是“多个聊天窗口”很多所谓的多智能体系统本质上只是把同一个问题重复问几次。answers[]for_inrange(5):answers.append(model.generate(task))final_answervote(answers)这种结构可以增加答案多样性但不能真正称为多智能体协作。因为不同实例之间没有稳定角色。它们拥有相似目标。使用相似上下文。遵循相似提示。最后只是产生多个随机采样结果。真正的多智能体系统需要明确三个条件角色异构 信息异构 目标异构1. 角色异构每个 Agent 承担不同职责。Planner 负责规划 Coder 负责实现 Reviewer 负责质疑 Tester 负责验证2. 信息异构不同 Agent 看到的上下文不完全相同。例如 Reviewer 不一定需要看到生成者的全部推理只需要看到需求、约束和代码差异。Security Agent 可以重点读取权限模型、依赖清单和外部接口。3. 目标异构不同 Agent 的评价标准不同。Coder 的目标是完成任务。Reviewer 的目标是发现问题。Tester 的目标是构造失败条件。Architect 的目标是控制长期复杂度。只有当角色、信息和目标真正不同多个 Agent 才会产生有价值的认知差异。三、多 Agent 架构的三种基础拓扑多智能体协作并不是只有一种结构。常见架构可以分成三类。1. Supervisor-Worker 架构由一个 Supervisor 负责任务拆解和结果汇总多个 Worker 负责执行。┌──────────────┐ │ Supervisor │ └──────┬───────┘ │ ┌──────────────┼──────────────┐ ↓ ↓ ↓ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ Architect │ │ Coder │ │ Tester │ └────────────┘ └────────────┘ └────────────┘伪代码如下classSupervisor:def__init__(self,workers):self.workersworkersdefexecute(self,task):subtasksself.decompose(task)results{}forrole,subtaskinsubtasks.items():workerself.workers[role]results[role]worker.run(subtask)returnself.synthesize(results)这种结构简单、清晰适合任务分解明确的场景。但它有一个明显问题Supervisor 会成为单点认知瓶颈。如果 Supervisor 任务拆错了所有 Worker 都会沿着错误方向执行。如果 Supervisor 汇总能力不足多个高质量结果也可能被错误整合。2. Peer-to-Peer 架构所有 Agent 地位相对平等通过消息交换形成结论。┌────────────┐ ┌────────────┐ │ Architect │ ←────→ │ Coder │ └──────┬─────┘ └──────┬─────┘ ↑ ↓ ┌──────┴─────┐ ┌──────┴─────┐ │ Reviewer │ ←────→ │ Tester │ └────────────┘ └────────────┘这种结构更开放也更接近团队讨论。classPeerAgent:def__init__(self,name,role):self.namename self.rolerole self.messages[]defreceive(self,message):self.messages.append(message)defrespond(self,shared_state):returnself.reason(shared_state,self.messages)优点是不存在单一控制者。缺点是协调成本高。多个 Agent 可能不断重复讨论。可能产生循环争论。可能出现消息爆炸。也可能没有任何 Agent 愿意承担最终决策。这种结构适合探索性问题不一定适合严格工程执行。3. Blackboard 架构所有 Agent 围绕一个共享状态空间工作。┌─────────────────┐ │ Blackboard │ │ 共享事实与状态 │ └────────┬────────┘ │ ┌───────────────────┼───────────────────┐ ↓ ↓ ↓ ┌────────────┐ ┌────────────┐ ┌────────────┐ │ Planner │ │ Reviewer │ │ Tester │ └────────────┘ └────────────┘ └────────────┘Agent 不需要互相直接沟通。它们读取 Blackboard 中的任务状态、事实、假设、候选方案和验证结果再写入自己的贡献。classBlackboard:def__init__(self):self.facts{}self.hypotheses[]self.proposals[]self.verification_results[]self.decisions[]defadd_fact(self,key,value,source):self.facts[key]{value:value,source:source}defadd_proposal(self,proposal):self.proposals.append(proposal)Blackboard 架构的优点是信息集中状态可追踪Agent 之间耦合较低容易记录决策过程适合多轮协作。它的问题是共享状态可能被污染。一个错误事实进入 Blackboard 后所有 Agent 都可能在错误基础上继续推理。所以 Blackboard 必须有事实验证和写入权限控制。四、共享事实与观点必须分离多智能体系统最常见的设计错误是把所有输出都当成同等级信息。例如某个 Agent 说订单服务目前没有幂等保护。这句话可能是从代码中读取到的事实根据部分代码做出的推测基于常见架构模式的假设Agent 自己生成的错误判断。如果系统不区分这些来源后续协作就会失去可靠性。因此共享状态中至少应该区分Fact 已验证事实 Hypothesis 待验证假设 Proposal 候选方案 Decision 已确认决策 Constraint 硬性约束可以设计统一的数据结构fromdataclassesimportdataclassfromtypingimportLiteral,Any KnowledgeTypeLiteral[fact,hypothesis,proposal,decision,constraint]dataclassclassKnowledgeItem:item_type:KnowledgeType content:Any source:strconfidence:floatevidence:list[str]verified:boolFalse例如itemKnowledgeItem(item_typehypothesis,content库存服务缺少请求幂等机制,sourcereviewer_agent,confidence0.72,evidence[未发现 request_id 去重逻辑,扣减接口允许重复调用],verifiedFalse)这样其他 Agent 就知道这不是事实而是一个等待验证的假设。多智能体系统要避免的不只是错误。更要避免错误信息伪装成共识。五、Agent 之间发生冲突是正常现象假设 Architect Agent 给出方案使用 Redis Lua 脚本完成原子库存扣减 再通过消息队列异步写入数据库。Consistency Agent 可能反对异步写入会导致 Redis 与数据库短暂不一致 需要明确补偿机制和消息重放策略。Simplicity Agent 可能提出当前业务规模并不需要引入消息队列 可以先采用数据库条件更新。Performance Agent 又可能认为数据库条件更新在大促场景下无法满足峰值吞吐。这些意见并不代表某个 Agent 错了。它们只是优化目标不同。Architect 优化系统结构 Consistency 优化一致性 Simplicity 优化复杂度 Performance 优化吞吐量现实中的架构决策本来就不是寻找唯一正确答案。而是在多个目标之间做权衡。多 Agent 系统的价值不是消除冲突。而是让冲突充分暴露。六、为什么简单投票通常不可靠最直观的冲突解决方法是投票。defmajority_vote(proposals):votes{}forproposalinproposals:votes[proposal.choice]votes.get(proposal.choice,0)1returnmax(votes,keyvotes.get)但多数票并不一定代表正确。假设有三个通用 Agent 和一个安全 Agent。三个通用 Agent 都认为代码可以合并。安全 Agent 发现了严重权限绕过。按照多数票代码会被批准。但显然这是错误决策。因为不同角色的意见权重不应相同。安全问题不是“少数意见”就可以忽略。因此多智能体决策不能只有数量逻辑还需要领域权重和否决机制。七、加权共识模型可以为不同角色设置不同权重。ROLE_WEIGHTS{architect:1.0,coder:0.8,reviewer:1.1,tester:1.0,security:1.5,business:1.2}然后计算方案得分defweighted_consensus(evaluations):scores{}forevaluationinevaluations:roleevaluation.role optionevaluation.option scoreevaluation.score weightROLE_WEIGHTS.get(role,1.0)scores[option]scores.get(option,0)score*weightreturnmax(scores,keyscores.get)但静态权重仍然不够。因为角色重要性与任务类型相关。安全任务中 Security Agent 权重更高。性能任务中 Performance Agent 权重更高。内容写作中 Reviewer 和 Audience Agent 更重要。代码修复中 Tester 和 Maintainer 更重要。所以权重应该是动态的。defget_role_weight(role:str,task_type:str)-float:matrix{security_patch:{security:2.0,reviewer:1.5,coder:0.8},performance_optimization:{performance:2.0,architect:1.3,tester:1.2},feature_development:{business:1.5,architect:1.2,coder:1.0}}returnmatrix.get(task_type,{}).get(role,1.0)这比简单投票更合理。但它仍然没有解决一个关键问题Agent 的意见是否有证据。八、证据优先而不是角色优先真正可靠的共识机制不能只看谁说的。还要看它基于什么证据。例如 Reviewer Agent 说这个补丁会破坏接口兼容性。如果它提供了旧接口 schema 新接口 diff 调用方代码 失败测试那么这个结论具有较强证据。如果另一个 Agent 只是说我认为应该没有影响。即使它的角色权重高也不应该覆盖前者。因此可以为每个判断计算证据分。dataclassclassEvaluation:role:stroption:strscore:floatconfidence:floatevidence_count:intverified_evidence_count:intdefevidence_score(evaluation:Evaluation)-float:ifevaluation.evidence_count0:return0.2verification_ratio(evaluation.verified_evidence_count/evaluation.evidence_count)return(evaluation.confidence*0.4verification_ratio*0.6)最终权重可以由三部分组成角色权重 × 任务相关性 × 证据强度deffinal_weight(evaluation,task_type):role_weightget_role_weight(evaluation.role,task_type)task_relevancecalculate_task_relevance(evaluation.role,task_type)evidenceevidence_score(evaluation)returnrole_weight*task_relevance*evidence这才更接近工程决策。不是谁声音大。不是谁数量多。也不是谁身份高。而是谁提供了更可靠的证据。九、否决权比投票权更重要对于部分风险不能用综合评分抵消。例如明确的数据泄露已确认的权限绕过无法回滚的数据删除破坏公开接口未经确认的生产部署核心测试失败。这些问题应当触发硬性否决。classVetoPolicy:BLOCKING_CONDITIONS[confirmed_security_vulnerability,public_api_breaking_change,critical_test_failure,irreversible_action_without_approval,data_loss_risk]defshould_veto(self,findings):returnany(finding.typeinself.BLOCKING_CONDITIONSandfinding.verifiedforfindinginfindings)这意味着多智能体系统不能只有民主机制。还需要宪法机制。普通分歧可以投票。重大风险必须否决。硬性约束不能被多数意见覆盖。十、从讨论到决策需要一个 Decision Agent 吗很多系统会增加一个 Decision Agent专门负责综合所有意见。Planner Architect Coder Reviewer Tester ↓ Decision Agent ↓ Final Decision这种设计很自然但也有风险。Decision Agent 可能成为新的单点故障。它可能错误概括他人意见。可能忽略少数关键证据。可能偏向表达更完整的方案。可能在复杂冲突中做出武断折中。因此 Decision Agent 不应直接凭自然语言总结做决定。它应该基于结构化决策记录。dataclassclassDecisionRecord:option:strsupporters:list[str]objections:list[str]verified_evidence:list[str]unresolved_risks:list[str]constraint_violations:list[str]weighted_score:floatvetoed:bool决策流程应当是收集候选方案 ↓ 结构化各方意见 ↓ 验证关键证据 ↓ 检查硬性约束 ↓ 执行否决规则 ↓ 计算加权评分 ↓ 输出决策与未决风险Decision Agent 的职责不是替所有 Agent 思考。而是执行决策协议。十一、辩论机制并不天然提高正确率多 Agent 系统中经常使用 Debate 模式。一个 Agent 提方案。另一个 Agent 反驳。第三个 Agent 评判。Proposer → Critic → Judge这种结构能够暴露问题但也存在局限。1. 语言优势偏差表达更流畅的 Agent 可能更容易被 Judge 接受即使证据并不充分。2. 共同知识偏差多个 Agent 来自相似模型可能共享同一种错误认知。它们看似在辩论实际上只是围绕同一错误前提进行不同表达。3. 过度收敛Agent 为了达成一致可能过早放弃少数观点。4. 无限争论如果缺少停止条件辩论会不断循环。因此 Debate 需要严格协议。classDebateProtocol:max_rounds3required_fields[claim,evidence,counterexample,uncertainty]stop_conditions[critical_fact_verified,hard_constraint_triggered,no_new_evidence,max_rounds_reached]辩论的目标不是让 Agent 多说几轮。而是让新的证据进入系统。如果一轮辩论没有带来新证据就不应该继续。十二、多智能体系统中的上下文隔离如果所有 Agent 都看到完全相同的信息它们容易产生相同结论。如果所有 Agent 都互相看到完整输出又容易相互影响失去独立判断。因此需要上下文隔离。例如Coder Agent 看到需求、相关代码、工程规范 Reviewer Agent 看到需求、约束、代码 diff、测试结果 Security Agent 看到权限模型、外部接口、依赖和敏感数据路径 Business Agent 看到业务目标、用户流程和验收标准可以通过 Context Policy 实现classContextPolicy:defbuild_context(self,role,shared_state):ifrolecoder:return{requirements:shared_state.requirements,source_files:shared_state.source_files,coding_rules:shared_state.coding_rules}ifrolereviewer:return{requirements:shared_state.requirements,constraints:shared_state.constraints,diff:shared_state.diff,test_results:shared_state.test_results}ifrolesecurity:return{auth_model:shared_state.auth_model,external_inputs:shared_state.external_inputs,dependencies:shared_state.dependencies,diff:shared_state.diff}return{}上下文隔离有两个作用第一减少信息过载。第二保持判断独立性。十三、任务应该由角色竞争还是由系统指派多 Agent 系统还会遇到一个调度问题。谁来执行某个任务最简单的方法是固定指派。写代码 → Coder 写测试 → Tester 做审查 → Reviewer但真实任务常常跨多个领域。例如“优化缓存层”既涉及代码也涉及架构和性能。可以引入任务竞标机制。dataclassclassTaskBid:agent_id:strcapability_score:floatestimated_risk:floatestimated_cost:floatconfidence:floatdefselect_agent(bids:list[TaskBid])-str:rankedsorted(bids,keylambdabid:(bid.capability_score*bid.confidence-bid.estimated_risk-bid.estimated_cost*0.2),reverseTrue)returnranked[0].agent_id每个 Agent 根据自身能力评估是否适合任务。这类似分布式系统中的工作节点调度。但 Agent 的自我评估未必可靠。因此系统还要结合历史表现。dataclassclassAgentProfile:role:strsuccess_rate:floatreview_rejection_rate:floataverage_cost:floatdomain_scores:dict[str,float]长期运行后系统可以根据历史任务结果动态调整 Agent 权重。十四、多智能体系统也需要可观测性多 Agent 结构比单 Agent 更难调试。当最终结果出错时需要知道哪个 Agent 最先引入错误错误事实何时进入共享状态哪个 Agent接受了错误前提决策器为什么忽略反对意见测试 Agent 是否真正验证了关键路径最终共识是如何形成的所以系统必须有可观测性。dataclassclassAgentEvent:agent_id:strevent_type:strinput_refs:list[str]output_ref:strconfidence:floattimestamp:str事件链可能是TaskCreated PlanProposed ArchitectureSelected PatchGenerated ReviewRejected PatchRevised TestsExecuted RiskDetected DecisionBlocked可以进一步构建因果图错误需求解释 ↓ 错误架构假设 ↓ 不完整实现 ↓ 测试覆盖不足 ↓ 错误方案被接受没有可观测性多 Agent 系统只是把一个黑盒变成多个黑盒。十五、多 Agent 不一定比单 Agent 更好这是一个必须正视的问题。多 Agent 会增加调用成本 通信成本 状态同步成本 冲突消解成本 延迟 错误传播路径 系统复杂度对于简单任务单 Agent 往往更有效。例如写一个数据格式化函数解释一个 API修改一段文档生成一个简单 SQL修复一个明确的小错误。如果为这些任务启动六个 Agent反而会过度设计。可以设置复杂度路由defchoose_architecture(task):scorecalculate_complexity(task)ifscore0.3:returnsingle_agentifscore0.7:returnsupervisor_workerreturnmulti_agent_consensus任务复杂度可以由以下因素决定涉及领域数量 风险等级 影响文件数量 是否存在目标冲突 是否需要多种专业视角 是否包含不可逆操作多智能体不是默认答案。它只适合单一认知路径不足以处理的任务。十六、一套可落地的多 Agent 流程一个相对完整的工程流程可以设计成用户任务 ↓ Task Classifier ↓ 复杂度评估 ↓ 选择 Agent 拓扑 ↓ 角色分配 ↓ 独立生成候选方案 ↓ 证据验证 ↓ 冲突检测 ↓ 否决规则 ↓ 加权共识 ↓ 执行 ↓ 独立验收伪代码如下classMultiAgentRuntime:def__init__(self,agents,context_policy,verifier,consensus_engine,veto_policy):self.agentsagents self.context_policycontext_policy self.verifierverifier self.consensus_engineconsensus_engine self.veto_policyveto_policydefrun(self,task):topologychoose_architecture(task)selected_agentsself.select_agents(task,topology)proposals[]foragentinselected_agents:contextself.context_policy.build_context(agent.role,task.shared_state)proposalagent.propose(task,context)proposals.append(proposal)verified_proposals[self.verifier.verify(proposal)forproposalinproposals]findingsself.extract_findings(verified_proposals)ifself.veto_policy.should_veto(findings):return{status:blocked,reason:critical risk detected,findings:findings}decisionself.consensus_engine.decide(verified_proposals,task.task_type)execution_resultself.execute(decision)final_reviewself.independent_review(execution_result,task)return{decision:decision,execution:execution_result,review:final_review}这个结构的重点不在 Agent 数量。而在几个关键环节独立生成 证据验证 风险否决 共识计算 独立验收十七、未来的 Codex 可能更像软件团队而不是单个程序员如果把 Codex 只看成代码生成器它的价值仍然是局部的。更高级的形态可能是需求分析 Agent 架构 Agent 实现 Agent 测试 Agent 审查 Agent 维护 Agent一个需求进入系统后不是直接生成代码而是经过多个角色。Requirement Agent ↓ Architecture Agent ↓ Implementation Agent ↓ Testing Agent ↓ Review Agent ↓ Maintainer AgentMaintainer Agent 会问这个实现半年后是否还能维护 是否引入了不必要的抽象 是否符合原项目风格 是否增加隐藏依赖Security Agent 会问输入是否经过校验 权限边界是否变化 敏感数据是否可能泄露 依赖是否有风险Tester Agent 会尝试主动破坏方案而不是只证明它能运行。这使 Codex 从“会写代码”逐渐接近“能够组织软件生产流程”。但前提仍然是系统必须有可靠的一致性机制。否则多个 Agent 只会制造更多互相矛盾的代码和意见。十八、写在最后多智能体的核心不是模拟团队而是治理分歧很多人想象多智能体系统时会把它看成一支虚拟团队。一个负责产品。一个负责架构。一个负责开发。一个负责测试。一个负责审核。这个想象没有错。但人类团队最困难的问题从来也不是把岗位名称列出来。真正困难的是信息不完整时如何决策。专业意见冲突时相信谁。少数意见什么时候必须保留。重大风险能不能被多数票覆盖。事实、假设和观点如何区分。失败之后谁来承担责任。历史表现如何影响未来权重。决策过程能不能被复盘。多智能体系统也会面对同样的问题。甚至更加严重。因为多个 Agent 可能来自相似模型拥有相似偏差生成同样流畅但错误的结论。它们表面上是多个角色。底层却可能是同一种认知模式的不同包装。因此多 Agent 并不会自动带来更高智能。真正决定系统质量的是角色是否真正异构 上下文是否合理隔离 结论是否基于证据 关键风险是否有否决权 冲突是否有明确协议 结果是否经过独立验证 整个过程是否可追踪ChatGPT 可以承担语言理解和协作表达。Codex 可以承担代码分析、实现和工程操作。但当系统从单模型走向多个 Agent真正的技术难点就不再是生成。而是治理。治理角色。治理信息。治理权限。治理分歧。治理共识。治理错误传播。多智能体架构最终要解决的不是“如何让更多 Agent 一起说话”。而是如何让多个具有不同目标、不同上下文和不同判断的智能体在不抹平分歧的前提下形成一个可验证、可解释、可执行的决策。这才是多智能体系统真正困难的地方。也是 ChatGPT 与 Codex 从个人助手走向复杂软件生产系统时必须面对的下一层工程问题。