1. 项目概述当大语言模型成为“多面手”决策者最近在跟几个做游戏AI和自动化流程的朋友聊天大家不约而同地提到了一个共同的痛点单一的大语言模型LLM智能体在处理复杂、动态的交互环境时常常显得“力不从心”。比如你让它控制一个游戏角色它可能能很好地执行“走到A点”的指令但如果任务变成“在资源有限、敌人动态出现的地图中协同队友完成采集、建造、防御等一系列目标”单个智能体就容易陷入混乱要么顾此失彼要么做出前后矛盾的决策。这背后反映的其实是当前LLM智能体在分层决策和多智能体协作能力上的瓶颈。“Multi$^2$: Hierarchical Multi-Agent Decision-Making with LLM-Based Agents in Interactive Environments”这个项目直击的就是这个核心问题。它不是一个简单的“用LLM控制多个角色”的脚本而是一套完整的、层次化的多智能体决策框架。简单来说它试图回答如何让一群基于大语言模型的“AI员工”在像游戏、模拟环境甚至某些自动化业务流程这样的动态世界里像一支训练有素的团队一样既有高层战略规划又能灵活执行战术还能在突发情况下相互沟通协作这个框架的价值远不止于游戏。想象一下自动化客服系统中需要查询、分析、回复、升级等不同职能的AI协同工作或者在复杂的软件研发流程中需求分析、编码、测试、部署等环节的AI智能体如何接力与配合。Multi$^2$提供了一种将复杂问题“分而治之”的架构思路让每个LLM智能体专注于自己擅长的子任务并通过一套清晰的层级和通信机制将它们整合成一个有机的整体。对于AI研究者、游戏开发者、自动化工程师乃至任何需要构建复杂多智能体系统的从业者来说理解并实践这样的框架意味着能够解锁LLM在更广阔场景下的应用潜力。2. 核心架构与设计哲学为何是“分层”与“多智能体”在深入Multi$^2$的具体实现之前我们必须先厘清其设计背后的两个核心概念分层决策Hierarchical Decision-Making和基于LLM的多智能体LLM-Based Multi-Agent。这不仅是两个技术名词更是解决复杂交互环境中AI决策问题的关键思想。2.1 分层决策从战略到战术的思维拆解人类处理复杂任务时本能地会采用分层思维。例如公司CEO制定年度战略高层部门总监规划季度目标中层员工执行每周任务底层。这种结构将宏大的、模糊的目标逐步分解为具体的、可操作的动作。在交互环境中单一、扁平的LLM智能体试图一次性消化所有环境信息屏幕像素、游戏状态、文本指令等并直接输出原子动作如“按下W键”、“点击某个按钮”这对其上下文理解、长期规划和逻辑一致性提出了极高要求极易导致决策质量下降。分层决策的核心思想就是引入一个决策抽象层。在Multi$^2$的语境下这种分层通常体现为战略层/管理者智能体负责顶层目标解析和任务分解。它接收最终目标如“赢得这场游戏”结合对环境的高层次理解如“我方经济落后”、“敌方主力在左路”将目标分解为一系列子任务或子目标如“阶段一发展经济阶段二集结兵力阶段三发起总攻”。这个智能体不需要关心具体怎么“采矿”或“走位”它只做宏观规划。战术层/协调者智能体接收来自战略层的子目标并将其进一步转化为具体的行动计划或指令序列。例如针对“发展经济”这个子目标它可能生成指令“农民A、B去采矿农民C去伐木建造两个兵营”。执行层/工作者智能体这是最底层的智能体直接与环境交互。它们接收具体的指令如“农民A去金矿”并将其转化为环境可执行的原生动作如生成一系列移动和交互的API调用。每个执行层智能体可能只专注于一类简单动作。这种分层结构极大地降低了每个智能体的决策复杂度让高层智能体专注于“要做什么”底层智能体专注于“怎么做”从而提升了整体决策的可靠性和可解释性。2.2 LLM-Based Multi-Agent超越简单脚本的协作智能“多智能体”并非新概念传统方法可能使用规则系统或强化学习来训练多个智能体。但Multi$^2$强调“LLM-Based”这带来了根本性的不同自然语言作为通用接口LLM智能体之间、智能体与系统之间的通信可以使用自然语言或结构化的自然语言如JSON。这使得智能体间的指令传递、状态汇报、协商请求变得极其灵活和易于理解无需设计复杂的专用通信协议。强大的上下文理解与生成能力每个LLM智能体都可以理解冗长的任务描述、历史对话和环境观察并能生成符合语境的决策文本。这使得智能体能够处理非结构化的、富含语义的信息。零样本/少样本学习能力通过精心设计的提示词PromptLLM智能体可以在没有大量特定环境训练数据的情况下根据对任务的自然语言描述表现出合理的决策行为大幅降低了开发成本。Multi$^2$框架的精妙之处在于将分层决策的思想与LLM智能体的上述优势相结合。它不仅仅是部署多个LLM而是定义了一套清晰的交互协议规定了不同层级的智能体如何通过自然语言进行“对话”从而共同完成任务。例如执行层智能体在无法完成指令时如“金矿已枯竭”可以向战术层智能体发送“求助”或“报告异常”信息从而触发上层重新规划。注意这里存在一个关键权衡。分层虽然简化了单个智能体的任务但增加了智能体间通信和协调的开销。设计不佳的层级和通信协议可能导致信息延迟、指令冲突或“扯皮”现象。因此如何设计层数、各层的职责边界以及通信机制是Multi$^2$框架实现中的首要挑战。3. Multi$^2$框架核心组件拆解理解了设计哲学我们来看Multi$^2$框架具体由哪些核心组件构成。一个典型的实现通常包括以下部分我们可以将其类比为一个公司的运作体系。3.1 智能体角色定义与专业化分工这是框架的基石。每个智能体都必须有清晰、互斥的角色定义这是分工协作的前提。角色定义通常通过系统提示词System Prompt来完成。管理者Manager对应战略层。其提示词会强调宏观视野、目标分解和优先级判断能力。例如“你是一个战略指挥官。你的目标是在模拟环境中取得胜利。你需要根据当前的整体局势资源、敌我力量、地图控制等将胜利目标分解为几个关键阶段并为每个阶段设定明确的子目标。你不需要关心具体单位如何移动。”协调者Coordinator对应战术层。其提示词侧重于资源分配、任务调度和冲突解决。例如“你是一名战术协调官。你从指挥官那里接收阶段性子目标如‘建立经济优势’。你需要将此目标转化为具体的任务指令分配给不同的执行单位并监控任务进度。当执行单位报告问题或任务间出现资源冲突时你需要及时调整指令。”执行者Executor对应执行层。其提示词非常具体聚焦于动作转换和环境交互。例如“你是一名农民单位控制器。你接收的指令可能是‘前往金矿并采集黄金’。你需要将此指令解析为一系列游戏API调用move_to(gold_mine_location)然后start_gathering()。”实操心得定义角色时务必确保职责的“正交性”。一个常见的错误是让协调者智能体“越俎代庖”开始思考本应由执行者处理的底层动作细节这会导致系统混乱。提示词中要用明确的禁止性语句划定边界比如“你只负责生成高级任务指令切勿输出具体的移动坐标或API调用”。3.2 层次化通信与状态管理机制智能体之间不能胡乱“喊话”需要一套稳定的通信协议。Multi$^2$通常采用一种基于消息队列或黑板Blackboard模型的通信方式。通信流向通常是自上而下的指令流和自下而上的状态/报告流。管理者向协调者发送子目标协调者向执行者发送具体任务。同时执行者定期或在遇到障碍时向协调者发送状态报告如“任务完成”、“遭遇敌人”、“资源不足”协调者汇总后可能向管理者发送阶段进度报告。消息格式为了便于解析和处理消息通常采用结构化的JSON格式即使内容是用自然语言描述的。例如{ sender: Coordinator_A, receiver: Executor_Farmer_1, type: TASK_ASSIGNMENT, content: 前往地图坐标(120, 85)处的金矿进行采集优先级为高。, timestamp: 1625097600 }状态共享黑板一个所有智能体都能读取的公共存储区域用于存放全局关键信息如“当前总黄金量”、“敌方主力位置”、“下一个战略阶段”。这避免了信息在层级间逐级传递的延迟和失真。管理者负责更新战略状态协调者和执行者按需读取。常见问题消息风暴。如果每个执行者智能体都高频报告状态协调者会被淹没。解决方案是设计报告阈值和聚合报告机制。例如执行者只在任务状态变更完成、失败或资源低于阈值时才报告协调者定时如每10个环境步长主动向下查询状态而非被动接收。3.3 环境感知与信息抽象层LLM智能体不能直接“看到”像素或“听到”二进制数据。它们需要一层环境感知抽象层将原始的环境状态如游戏内存数据、API返回的JSON对象转化为智能体能够理解的自然语言描述或结构化语义信息。对于管理者智能体它需要高度概括的信息“我方经济领先20%但军事力量弱于对手地图中央控制权丢失。” 对于执行者智能体它需要非常具体的信息“你控制的农民单位生命值100%位于坐标(50,60)前方10单位距离有一个金矿周围未发现敌人。”这个抽象层的设计质量直接决定了智能体的决策水平。它需要过滤噪音只提取与智能体角色相关的信息。保持一致性不同层级智能体获取的关于同一实体的信息不应矛盾。实时性信息更新频率要跟上环境变化。实操要点这个抽象层往往是手写规则或轻量级模型如基于规则的状态分类器实现的而不是由LLM本身完成。因为让LLM去实时解析海量原始数据成本极高且延迟不可接受。我们的做法是用传统编程方法预先定义好一套“语义化观察”的模板然后根据实时环境数据去填充这个模板。4. 实现流程与核心环节实操假设我们要在《星际争霸II》这类复杂的即时战略游戏环境中实现一个简化版的Multi$^2$框架以下是关键步骤。4.1 第一步环境集成与观察抽象化首先你需要通过游戏API如PySC2连接到游戏环境。核心工作是构建一个观察处理器Observation Processor。class ObservationProcessor: def __init__(self): # 初始化一些状态缓存 self.previous_state {} def get_abstracted_obs(self, raw_obs, agent_role): 根据智能体角色提供抽象后的观察信息。 raw_obs: 从游戏API获取的原始观察数据。 agent_role: manager, coordinator, executor_unit_type abstracted_info {} # 提取公共基础信息所有角色都需要一部分 game_loop raw_obs.observation.game_loop player_info self._extract_player_info(raw_obs) if agent_role manager: abstracted_info[summary] self._generate_strategic_summary(player_info, raw_obs) abstracted_info[current_stage] self._infer_game_stage(player_info) # 例如{summary: 开局阶段我方有12农民敌方有10农民。地图资源点控制率我方为40%。, current_stage: early_game} elif agent_role coordinator_economy: abstracted_info[resource_status] player_info[minerals], player_info[vespene] abstracted_info[worker_count] player_info[workers] abstracted_info[idle_workers] self._find_idle_workers(raw_obs) # 例如{resource_status: (400, 100), worker_count: 12, idle_workers: [unit_tag_1, unit_tag_2]} elif agent_role.startswith(executor): # 假设角色是 executor_scv unit_type agent_role.split(_)[1] assigned_unit_tag self._get_assigned_unit(unit_type) # 从协调者分配中获取 unit_obs self._get_unit_detail(raw_obs, assigned_unit_tag) abstracted_info[unit_state] unit_obs # 例如{unit_state: {tag: 123, health: 45, position: (x,y), order: Idle, nearby_resources: [...]}} return json.dumps(abstracted_info, ensure_asciiFalse) def _extract_player_info(self, raw_obs): # 实现从raw_obs中提取玩家矿物、气体、人口、单位列表等信息的逻辑 pass # ... 其他辅助方法这个处理器是框架的“眼睛”它输出的JSON字符串就是LLM智能体的“观察输入”。4.2 第二步构建智能体与提示词工程接下来为每个角色初始化LLM客户端如调用OpenAI API或本地部署的模型并编写核心的系统提示词。管理者智能体提示词示例你是一个即时战略游戏的AI总指挥官。你的唯一目标是取得游戏胜利。 【你的职责】 1. 宏观分析根据提供的游戏阶段总结和态势信息判断整体局势优势、劣势、均势。 2. 阶段规划将“取得胜利”这个最终目标分解为连续的、明确的战略阶段。常见的阶段包括早期发展、中期扩张/骚扰、后期决战。 3. 目标输出为当前或下一个战略阶段生成1-3个清晰、可衡量的子目标。 【输入格式】 你将收到一个JSON格式的观察信息包含summary态势总结和current_stage当前推断阶段。 【输出格式】 你必须且只能输出一个JSON对象包含以下字段 - analysis: (字符串) 你对当前局势的简短分析。 - next_stage: (字符串) 你决定进入的下一个战略阶段名称。 - sub_goals: (字符串列表) 为该阶段制定的子目标每个目标应简洁具体。例如[达到50人口的基础部队, 建立第二个基地, 升级攻击等级1] 【行动边界】 你只负责制定战略和目标绝对不要输出任何关于具体单位如何移动、建造什么建筑、何时攻击等战术或执行细节。那是协调者和执行者的工作。 现在开始你的第一次决策。观察信息{observation_json}协调者与执行者的提示词遵循类似结构但职责描述、输入输出格式完全不同。协调者需要接收管理者目标、资源状态输出任务列表分配给哪个执行者、什么任务。执行者则接收具体任务和自身单位状态输出动作序列如[{action: move, target: [x,y]}, {action: gather, target: mineral_field}]。关键技巧提示词中强制规定的JSON输出格式至关重要。这保证了上层智能体能够以编程方式可靠地解析下层智能体的输出形成自动化决策流水线。务必在提示词中加入“必须且只能输出JSON”等强约束语句并使用后处理代码验证格式。4.3 第三步实现决策循环与通信总线这是框架的“中枢神经系统”。我们需要一个主循环在每一个游戏步长或决策周期内从环境获取原始观察。观察处理器为不同角色生成抽象观察。将观察传递给对应的智能体获取其决策输出JSON。解析决策转化为环境动作。执行动作更新环境。管理智能体间的通信消息。class Multi2Framework: def __init__(self, env, manager_agent, coordinators, executors, obs_processor): self.env env self.manager manager_agent self.coordinators coordinators # 字典key为协调领域如‘economy’, ‘military’ self.executors executors # 字典key为单位类型或ID self.obs_processor obs_processor self.message_board MessageBoard() # 消息黑板实例 self.current_goals [] def run_step(self): # 1. 获取环境状态 raw_obs self.env.get_observation() # 2. 更新黑板上的公共环境摘要供管理者使用 strategic_obs self.obs_processor.get_abstracted_obs(raw_obs, manager) self.message_board.set(strategic_overview, strategic_obs) # 3. 管理者决策频率较低比如每100步一次 if self.env.step_count % 100 0: manager_decision self.manager.decide(strategic_obs) # 解析出子目标更新到黑板 self.current_goals manager_decision[sub_goals] self.message_board.set(current_goals, self.current_goals) # 4. 各协调者决策频率中等如每10步一次 if self.env.step_count % 10 0: for domain, coordinator in self.coordinators.items(): # 协调者获取自己领域的观察和全局目标 domain_obs self.obs_processor.get_abstracted_obs(raw_obs, fcoordinator_{domain}) goals_for_domain self._filter_goals_for_domain(self.current_goals, domain) coordinator_decision coordinator.decide(domain_obs, goals_for_domain, self.message_board) # 协调者决策结果是给执行者的任务列表发布到黑板 self.message_board.set(ftasks_{domain}, coordinator_decision[tasks]) # 5. 执行者决策每一步或每几步一次 for unit_type, executor in self.executors.items(): # 执行者从黑板领取分配给自己的任务 assigned_task self.message_board.get(ftask_for_{unit_type}) unit_obs self.obs_processor.get_abstracted_obs(raw_obs, fexecutor_{unit_type}) if assigned_task: actions executor.decide(unit_obs, assigned_task) # 将动作转化为环境指令并执行 self.env.execute_actions(unit_type, actions) # 6. 执行环境步进 self.env.step()这个循环清晰地体现了分层和通信管理者定调子目标协调者分任务执行者做动作。黑板message_board是所有信息的交汇点。5. 调试、优化与常见问题实录在实际搭建和运行Multi$^2$系统时你会遇到一系列教科书上不会写的“坑”。以下是一些典型问题及我们的排查经验。5.1 智能体“幻觉”与决策漂移这是LLM智能体最常见的问题。管理者可能突然制定出一个与游戏版本完全不符的战略例如在《星际争霸II》中要求建造不存在的单位或者执行者将“攻击敌人”误解为“移动到敌人旁边发呆”。排查与解决强化提示词约束在系统提示词中明确列出可行动作集和知识边界。例如在管理者提示词末尾加上“请注意本游戏版本为《星际争霸II虚空之遗》你可用的种族为人类。禁止提及或规划其他种族单位或本版本不存在的科技。”输出格式校验与重试在代码中严格解析智能体返回的JSON。如果解析失败或JSON中包含了非法值如不存在的单位类型则记录错误并向该智能体重新发送一个包含错误信息的修正提示要求其重新决策。例如“你上次的输出无法被解析或包含了非法单位‘航母’。请严格按照输出格式和可行单位列表重新决策。”引入短期记忆与一致性检查为智能体尤其是管理者维护一个简短的决策历史上下文。在每次请求时附带之前的几个决策并要求其新决策与历史保持逻辑一致。这可以通过在提示词中附加“Previous decisions: ...”来实现。5.2 通信延迟与决策不同步在分层系统中上层决策传到下层并执行需要时间。当环境变化很快时可能出现“命令赶到情况已变”的尴尬局面。比如管理者下令“集结部队进攻”但等协调者把指令分发给各个执行者时敌人的主力已经转移了。优化策略设置决策频率与优先级不是所有层级的智能体都需要在每个环境步长进行决策。为管理者设置较低的决策频率如每100步协调者中等每10-20步执行者最高每1-5步。这既减少了计算开销也给了下层智能体一定的实时反应空间。赋予执行者有限自主权在执行者的提示词中加入“紧急情况处理”条款。例如“你的主要任务是执行分配的任务。但是如果你的单位在移动途中突然遭到攻击生命值快速下降你可以立即中断当前任务优先执行‘逃离到最近的安全点’或‘反击’的自我保护动作并在事后向协调者报告。”采用预测性指令协调者在分配任务时可以不只是给一个静态目标而是给一个带条件的指令序列。例如“前往A点采集资源。如果到达后发现资源枯竭则自动前往B点。如果途中遇到敌人且战力不足则撤退至C点并呼叫支援。”5.3 资源竞争与死锁当多个协调者或执行者竞争同一资源时例如经济协调者和军事协调者都急需晶体矿来建造不同的建筑系统可能陷入僵局。解决方案引入资源仲裁机制在黑板系统中设立一个“资源锁”或“资源预算”模块。管理者在制定战略目标时可以附带一个粗略的资源分配方案如“早期阶段70%资源用于经济30%用于防御”。协调者在申请资源执行任务时需要向仲裁模块“申请预算”获批后才能进行。这需要设计一套简单的资源请求/批准协议。设计协商协议让协调者智能体之间具备简单的协商能力。当经济协调者收到“建造基地”任务但矿物不足时它可以向军事协调者发送一个协商请求“我急需200矿物建造二矿以完成‘扩张经济’目标你是否可以暂缓建造下一个兵营”这需要在通信协议中增加NEGOTIATION_REQUEST和NEGOTIATION_RESPONSE消息类型并在提示词中教导智能体如何进行简单的利弊权衡与协商。5.4 成本与性能瓶颈频繁调用大型LLM如GPT-4成本高昂且延迟可能影响实时性。降本增效实践模型分层使用对实时性要求高、任务简单的执行者智能体可以使用更小、更快的模型如较小的开源模型甚至精心设计的规则引擎配合少量LLM调用。只有需要复杂规划和分析的管理者、协调者才使用能力更强的大模型。缓存与复用很多决策在短时间内是稳定的。可以缓存智能体对相似观察的决策结果在一定步长内直接复用而不是每次都调用LLM。例如执行者“农民采矿”的决策在矿点没采完、没有新指令的情况下可以持续多个步长不变。异步决策与并行化不同智能体的决策过程可以异步进行。在一个决策周期内可以同时让所有执行者智能体基于上一周期的任务进行决策和行动而协调者和管理者则在后台并行计算下一周期的计划计算完成后更新黑板供下个周期使用。6. 进阶思考与应用场景延伸Multi$^2$框架的价值不仅在于解决游戏AI问题其“分层协作”的思想可以迁移到众多需要复杂决策与协作的领域。在自动化工作流与RPA场景可以将一个复杂的业务流程如“处理客户发票”分解。管理者智能体解析发票类型和紧急程度协调者智能体调度OCR识别、数据验证、财务系统录入等子任务执行者智能体则是调用具体API的工具。这比设计一个巨型的、处理所有情况的单一自动化脚本要灵活和健壮得多。在智能软件开发与运维想象一个自动化的DevOps流水线。管理者智能体根据代码变更和系统监控判断当前需要进入“开发测试”、“集成部署”还是“故障修复”模式。协调者智能体负责调度测试用例运行、部署管道触发、回滚决策等。执行者智能体则执行具体的docker build、kubectl apply等命令。系统能够更智能地处理流水线中的异常和依赖。在模拟训练与实验平台Multi$^2$框架本身是一个绝佳的研究平台用于探索多智能体协作、人机协作、应急响应等课题。通过调整层级结构、通信协议和智能体的提示词可以模拟出各种组织行为模式观察其效率与鲁棒性。我个人在尝试将类似框架应用于一个内部流程自动化项目时的体会是最大的挑战不在于让单个LLM智能体“变聪明”而在于设计一套清晰、稳定、容错的“组织规则”。这更像是在设计一个公司的管理制度和沟通流程。提示词是岗位说明书通信协议是会议和报告制度黑板是公司的公共数据库。一个设计良好的框架即使其中的每个“员工”智能体能力平平也能通过有效的协作产生“112”的效果。反之如果架构混乱职责不清通信不畅即使每个智能体都用上最顶尖的模型整个系统也会陷入内耗和混乱。因此在动手编码之前花足够的时间在纸上画清楚智能体的层级、职责、输入输出和数据流是项目成功最关键的一步。 
长河君 · 2026/8/18 5:49:17 · 阅读 1.2k 基于大语言模型的分层多智能体决策框架：原理、实现与应用
1. 项目概述当大语言模型成为“多面手”决策者最近在跟几个做游戏AI和自动化流程的朋友聊天大家不约而同地提到了一个共同的痛点单一的大语言模型LLM智能体在处理复杂、动态的交互环境时常常显得“力不从心”。比如你让它控制一个游戏角色它可能能很好地执行“走到A点”的指令但如果任务变成“在资源有限、敌人动态出现的地图中协同队友完成采集、建造、防御等一系列目标”单个智能体就容易陷入混乱要么顾此失彼要么做出前后矛盾的决策。这背后反映的其实是当前LLM智能体在分层决策和多智能体协作能力上的瓶颈。“Multi$^2$: Hierarchical Multi-Agent Decision-Making with LLM-Based Agents in Interactive Environments”这个项目直击的就是这个核心问题。它不是一个简单的“用LLM控制多个角色”的脚本而是一套完整的、层次化的多智能体决策框架。简单来说它试图回答如何让一群基于大语言模型的“AI员工”在像游戏、模拟环境甚至某些自动化业务流程这样的动态世界里像一支训练有素的团队一样既有高层战略规划又能灵活执行战术还能在突发情况下相互沟通协作这个框架的价值远不止于游戏。想象一下自动化客服系统中需要查询、分析、回复、升级等不同职能的AI协同工作或者在复杂的软件研发流程中需求分析、编码、测试、部署等环节的AI智能体如何接力与配合。Multi$^2$提供了一种将复杂问题“分而治之”的架构思路让每个LLM智能体专注于自己擅长的子任务并通过一套清晰的层级和通信机制将它们整合成一个有机的整体。对于AI研究者、游戏开发者、自动化工程师乃至任何需要构建复杂多智能体系统的从业者来说理解并实践这样的框架意味着能够解锁LLM在更广阔场景下的应用潜力。2. 核心架构与设计哲学为何是“分层”与“多智能体”在深入Multi$^2$的具体实现之前我们必须先厘清其设计背后的两个核心概念分层决策Hierarchical Decision-Making和基于LLM的多智能体LLM-Based Multi-Agent。这不仅是两个技术名词更是解决复杂交互环境中AI决策问题的关键思想。2.1 分层决策从战略到战术的思维拆解人类处理复杂任务时本能地会采用分层思维。例如公司CEO制定年度战略高层部门总监规划季度目标中层员工执行每周任务底层。这种结构将宏大的、模糊的目标逐步分解为具体的、可操作的动作。在交互环境中单一、扁平的LLM智能体试图一次性消化所有环境信息屏幕像素、游戏状态、文本指令等并直接输出原子动作如“按下W键”、“点击某个按钮”这对其上下文理解、长期规划和逻辑一致性提出了极高要求极易导致决策质量下降。分层决策的核心思想就是引入一个决策抽象层。在Multi$^2$的语境下这种分层通常体现为战略层/管理者智能体负责顶层目标解析和任务分解。它接收最终目标如“赢得这场游戏”结合对环境的高层次理解如“我方经济落后”、“敌方主力在左路”将目标分解为一系列子任务或子目标如“阶段一发展经济阶段二集结兵力阶段三发起总攻”。这个智能体不需要关心具体怎么“采矿”或“走位”它只做宏观规划。战术层/协调者智能体接收来自战略层的子目标并将其进一步转化为具体的行动计划或指令序列。例如针对“发展经济”这个子目标它可能生成指令“农民A、B去采矿农民C去伐木建造两个兵营”。执行层/工作者智能体这是最底层的智能体直接与环境交互。它们接收具体的指令如“农民A去金矿”并将其转化为环境可执行的原生动作如生成一系列移动和交互的API调用。每个执行层智能体可能只专注于一类简单动作。这种分层结构极大地降低了每个智能体的决策复杂度让高层智能体专注于“要做什么”底层智能体专注于“怎么做”从而提升了整体决策的可靠性和可解释性。2.2 LLM-Based Multi-Agent超越简单脚本的协作智能“多智能体”并非新概念传统方法可能使用规则系统或强化学习来训练多个智能体。但Multi$^2$强调“LLM-Based”这带来了根本性的不同自然语言作为通用接口LLM智能体之间、智能体与系统之间的通信可以使用自然语言或结构化的自然语言如JSON。这使得智能体间的指令传递、状态汇报、协商请求变得极其灵活和易于理解无需设计复杂的专用通信协议。强大的上下文理解与生成能力每个LLM智能体都可以理解冗长的任务描述、历史对话和环境观察并能生成符合语境的决策文本。这使得智能体能够处理非结构化的、富含语义的信息。零样本/少样本学习能力通过精心设计的提示词PromptLLM智能体可以在没有大量特定环境训练数据的情况下根据对任务的自然语言描述表现出合理的决策行为大幅降低了开发成本。Multi$^2$框架的精妙之处在于将分层决策的思想与LLM智能体的上述优势相结合。它不仅仅是部署多个LLM而是定义了一套清晰的交互协议规定了不同层级的智能体如何通过自然语言进行“对话”从而共同完成任务。例如执行层智能体在无法完成指令时如“金矿已枯竭”可以向战术层智能体发送“求助”或“报告异常”信息从而触发上层重新规划。注意这里存在一个关键权衡。分层虽然简化了单个智能体的任务但增加了智能体间通信和协调的开销。设计不佳的层级和通信协议可能导致信息延迟、指令冲突或“扯皮”现象。因此如何设计层数、各层的职责边界以及通信机制是Multi$^2$框架实现中的首要挑战。3. Multi$^2$框架核心组件拆解理解了设计哲学我们来看Multi$^2$框架具体由哪些核心组件构成。一个典型的实现通常包括以下部分我们可以将其类比为一个公司的运作体系。3.1 智能体角色定义与专业化分工这是框架的基石。每个智能体都必须有清晰、互斥的角色定义这是分工协作的前提。角色定义通常通过系统提示词System Prompt来完成。管理者Manager对应战略层。其提示词会强调宏观视野、目标分解和优先级判断能力。例如“你是一个战略指挥官。你的目标是在模拟环境中取得胜利。你需要根据当前的整体局势资源、敌我力量、地图控制等将胜利目标分解为几个关键阶段并为每个阶段设定明确的子目标。你不需要关心具体单位如何移动。”协调者Coordinator对应战术层。其提示词侧重于资源分配、任务调度和冲突解决。例如“你是一名战术协调官。你从指挥官那里接收阶段性子目标如‘建立经济优势’。你需要将此目标转化为具体的任务指令分配给不同的执行单位并监控任务进度。当执行单位报告问题或任务间出现资源冲突时你需要及时调整指令。”执行者Executor对应执行层。其提示词非常具体聚焦于动作转换和环境交互。例如“你是一名农民单位控制器。你接收的指令可能是‘前往金矿并采集黄金’。你需要将此指令解析为一系列游戏API调用move_to(gold_mine_location)然后start_gathering()。”实操心得定义角色时务必确保职责的“正交性”。一个常见的错误是让协调者智能体“越俎代庖”开始思考本应由执行者处理的底层动作细节这会导致系统混乱。提示词中要用明确的禁止性语句划定边界比如“你只负责生成高级任务指令切勿输出具体的移动坐标或API调用”。3.2 层次化通信与状态管理机制智能体之间不能胡乱“喊话”需要一套稳定的通信协议。Multi$^2$通常采用一种基于消息队列或黑板Blackboard模型的通信方式。通信流向通常是自上而下的指令流和自下而上的状态/报告流。管理者向协调者发送子目标协调者向执行者发送具体任务。同时执行者定期或在遇到障碍时向协调者发送状态报告如“任务完成”、“遭遇敌人”、“资源不足”协调者汇总后可能向管理者发送阶段进度报告。消息格式为了便于解析和处理消息通常采用结构化的JSON格式即使内容是用自然语言描述的。例如{ sender: Coordinator_A, receiver: Executor_Farmer_1, type: TASK_ASSIGNMENT, content: 前往地图坐标(120, 85)处的金矿进行采集优先级为高。, timestamp: 1625097600 }状态共享黑板一个所有智能体都能读取的公共存储区域用于存放全局关键信息如“当前总黄金量”、“敌方主力位置”、“下一个战略阶段”。这避免了信息在层级间逐级传递的延迟和失真。管理者负责更新战略状态协调者和执行者按需读取。常见问题消息风暴。如果每个执行者智能体都高频报告状态协调者会被淹没。解决方案是设计报告阈值和聚合报告机制。例如执行者只在任务状态变更完成、失败或资源低于阈值时才报告协调者定时如每10个环境步长主动向下查询状态而非被动接收。3.3 环境感知与信息抽象层LLM智能体不能直接“看到”像素或“听到”二进制数据。它们需要一层环境感知抽象层将原始的环境状态如游戏内存数据、API返回的JSON对象转化为智能体能够理解的自然语言描述或结构化语义信息。对于管理者智能体它需要高度概括的信息“我方经济领先20%但军事力量弱于对手地图中央控制权丢失。” 对于执行者智能体它需要非常具体的信息“你控制的农民单位生命值100%位于坐标(50,60)前方10单位距离有一个金矿周围未发现敌人。”这个抽象层的设计质量直接决定了智能体的决策水平。它需要过滤噪音只提取与智能体角色相关的信息。保持一致性不同层级智能体获取的关于同一实体的信息不应矛盾。实时性信息更新频率要跟上环境变化。实操要点这个抽象层往往是手写规则或轻量级模型如基于规则的状态分类器实现的而不是由LLM本身完成。因为让LLM去实时解析海量原始数据成本极高且延迟不可接受。我们的做法是用传统编程方法预先定义好一套“语义化观察”的模板然后根据实时环境数据去填充这个模板。4. 实现流程与核心环节实操假设我们要在《星际争霸II》这类复杂的即时战略游戏环境中实现一个简化版的Multi$^2$框架以下是关键步骤。4.1 第一步环境集成与观察抽象化首先你需要通过游戏API如PySC2连接到游戏环境。核心工作是构建一个观察处理器Observation Processor。class ObservationProcessor: def __init__(self): # 初始化一些状态缓存 self.previous_state {} def get_abstracted_obs(self, raw_obs, agent_role): 根据智能体角色提供抽象后的观察信息。 raw_obs: 从游戏API获取的原始观察数据。 agent_role: manager, coordinator, executor_unit_type abstracted_info {} # 提取公共基础信息所有角色都需要一部分 game_loop raw_obs.observation.game_loop player_info self._extract_player_info(raw_obs) if agent_role manager: abstracted_info[summary] self._generate_strategic_summary(player_info, raw_obs) abstracted_info[current_stage] self._infer_game_stage(player_info) # 例如{summary: 开局阶段我方有12农民敌方有10农民。地图资源点控制率我方为40%。, current_stage: early_game} elif agent_role coordinator_economy: abstracted_info[resource_status] player_info[minerals], player_info[vespene] abstracted_info[worker_count] player_info[workers] abstracted_info[idle_workers] self._find_idle_workers(raw_obs) # 例如{resource_status: (400, 100), worker_count: 12, idle_workers: [unit_tag_1, unit_tag_2]} elif agent_role.startswith(executor): # 假设角色是 executor_scv unit_type agent_role.split(_)[1] assigned_unit_tag self._get_assigned_unit(unit_type) # 从协调者分配中获取 unit_obs self._get_unit_detail(raw_obs, assigned_unit_tag) abstracted_info[unit_state] unit_obs # 例如{unit_state: {tag: 123, health: 45, position: (x,y), order: Idle, nearby_resources: [...]}} return json.dumps(abstracted_info, ensure_asciiFalse) def _extract_player_info(self, raw_obs): # 实现从raw_obs中提取玩家矿物、气体、人口、单位列表等信息的逻辑 pass # ... 其他辅助方法这个处理器是框架的“眼睛”它输出的JSON字符串就是LLM智能体的“观察输入”。4.2 第二步构建智能体与提示词工程接下来为每个角色初始化LLM客户端如调用OpenAI API或本地部署的模型并编写核心的系统提示词。管理者智能体提示词示例你是一个即时战略游戏的AI总指挥官。你的唯一目标是取得游戏胜利。 【你的职责】 1. 宏观分析根据提供的游戏阶段总结和态势信息判断整体局势优势、劣势、均势。 2. 阶段规划将“取得胜利”这个最终目标分解为连续的、明确的战略阶段。常见的阶段包括早期发展、中期扩张/骚扰、后期决战。 3. 目标输出为当前或下一个战略阶段生成1-3个清晰、可衡量的子目标。 【输入格式】 你将收到一个JSON格式的观察信息包含summary态势总结和current_stage当前推断阶段。 【输出格式】 你必须且只能输出一个JSON对象包含以下字段 - analysis: (字符串) 你对当前局势的简短分析。 - next_stage: (字符串) 你决定进入的下一个战略阶段名称。 - sub_goals: (字符串列表) 为该阶段制定的子目标每个目标应简洁具体。例如[达到50人口的基础部队, 建立第二个基地, 升级攻击等级1] 【行动边界】 你只负责制定战略和目标绝对不要输出任何关于具体单位如何移动、建造什么建筑、何时攻击等战术或执行细节。那是协调者和执行者的工作。 现在开始你的第一次决策。观察信息{observation_json}协调者与执行者的提示词遵循类似结构但职责描述、输入输出格式完全不同。协调者需要接收管理者目标、资源状态输出任务列表分配给哪个执行者、什么任务。执行者则接收具体任务和自身单位状态输出动作序列如[{action: move, target: [x,y]}, {action: gather, target: mineral_field}]。关键技巧提示词中强制规定的JSON输出格式至关重要。这保证了上层智能体能够以编程方式可靠地解析下层智能体的输出形成自动化决策流水线。务必在提示词中加入“必须且只能输出JSON”等强约束语句并使用后处理代码验证格式。4.3 第三步实现决策循环与通信总线这是框架的“中枢神经系统”。我们需要一个主循环在每一个游戏步长或决策周期内从环境获取原始观察。观察处理器为不同角色生成抽象观察。将观察传递给对应的智能体获取其决策输出JSON。解析决策转化为环境动作。执行动作更新环境。管理智能体间的通信消息。class Multi2Framework: def __init__(self, env, manager_agent, coordinators, executors, obs_processor): self.env env self.manager manager_agent self.coordinators coordinators # 字典key为协调领域如‘economy’, ‘military’ self.executors executors # 字典key为单位类型或ID self.obs_processor obs_processor self.message_board MessageBoard() # 消息黑板实例 self.current_goals [] def run_step(self): # 1. 获取环境状态 raw_obs self.env.get_observation() # 2. 更新黑板上的公共环境摘要供管理者使用 strategic_obs self.obs_processor.get_abstracted_obs(raw_obs, manager) self.message_board.set(strategic_overview, strategic_obs) # 3. 管理者决策频率较低比如每100步一次 if self.env.step_count % 100 0: manager_decision self.manager.decide(strategic_obs) # 解析出子目标更新到黑板 self.current_goals manager_decision[sub_goals] self.message_board.set(current_goals, self.current_goals) # 4. 各协调者决策频率中等如每10步一次 if self.env.step_count % 10 0: for domain, coordinator in self.coordinators.items(): # 协调者获取自己领域的观察和全局目标 domain_obs self.obs_processor.get_abstracted_obs(raw_obs, fcoordinator_{domain}) goals_for_domain self._filter_goals_for_domain(self.current_goals, domain) coordinator_decision coordinator.decide(domain_obs, goals_for_domain, self.message_board) # 协调者决策结果是给执行者的任务列表发布到黑板 self.message_board.set(ftasks_{domain}, coordinator_decision[tasks]) # 5. 执行者决策每一步或每几步一次 for unit_type, executor in self.executors.items(): # 执行者从黑板领取分配给自己的任务 assigned_task self.message_board.get(ftask_for_{unit_type}) unit_obs self.obs_processor.get_abstracted_obs(raw_obs, fexecutor_{unit_type}) if assigned_task: actions executor.decide(unit_obs, assigned_task) # 将动作转化为环境指令并执行 self.env.execute_actions(unit_type, actions) # 6. 执行环境步进 self.env.step()这个循环清晰地体现了分层和通信管理者定调子目标协调者分任务执行者做动作。黑板message_board是所有信息的交汇点。5. 调试、优化与常见问题实录在实际搭建和运行Multi$^2$系统时你会遇到一系列教科书上不会写的“坑”。以下是一些典型问题及我们的排查经验。5.1 智能体“幻觉”与决策漂移这是LLM智能体最常见的问题。管理者可能突然制定出一个与游戏版本完全不符的战略例如在《星际争霸II》中要求建造不存在的单位或者执行者将“攻击敌人”误解为“移动到敌人旁边发呆”。排查与解决强化提示词约束在系统提示词中明确列出可行动作集和知识边界。例如在管理者提示词末尾加上“请注意本游戏版本为《星际争霸II虚空之遗》你可用的种族为人类。禁止提及或规划其他种族单位或本版本不存在的科技。”输出格式校验与重试在代码中严格解析智能体返回的JSON。如果解析失败或JSON中包含了非法值如不存在的单位类型则记录错误并向该智能体重新发送一个包含错误信息的修正提示要求其重新决策。例如“你上次的输出无法被解析或包含了非法单位‘航母’。请严格按照输出格式和可行单位列表重新决策。”引入短期记忆与一致性检查为智能体尤其是管理者维护一个简短的决策历史上下文。在每次请求时附带之前的几个决策并要求其新决策与历史保持逻辑一致。这可以通过在提示词中附加“Previous decisions: ...”来实现。5.2 通信延迟与决策不同步在分层系统中上层决策传到下层并执行需要时间。当环境变化很快时可能出现“命令赶到情况已变”的尴尬局面。比如管理者下令“集结部队进攻”但等协调者把指令分发给各个执行者时敌人的主力已经转移了。优化策略设置决策频率与优先级不是所有层级的智能体都需要在每个环境步长进行决策。为管理者设置较低的决策频率如每100步协调者中等每10-20步执行者最高每1-5步。这既减少了计算开销也给了下层智能体一定的实时反应空间。赋予执行者有限自主权在执行者的提示词中加入“紧急情况处理”条款。例如“你的主要任务是执行分配的任务。但是如果你的单位在移动途中突然遭到攻击生命值快速下降你可以立即中断当前任务优先执行‘逃离到最近的安全点’或‘反击’的自我保护动作并在事后向协调者报告。”采用预测性指令协调者在分配任务时可以不只是给一个静态目标而是给一个带条件的指令序列。例如“前往A点采集资源。如果到达后发现资源枯竭则自动前往B点。如果途中遇到敌人且战力不足则撤退至C点并呼叫支援。”5.3 资源竞争与死锁当多个协调者或执行者竞争同一资源时例如经济协调者和军事协调者都急需晶体矿来建造不同的建筑系统可能陷入僵局。解决方案引入资源仲裁机制在黑板系统中设立一个“资源锁”或“资源预算”模块。管理者在制定战略目标时可以附带一个粗略的资源分配方案如“早期阶段70%资源用于经济30%用于防御”。协调者在申请资源执行任务时需要向仲裁模块“申请预算”获批后才能进行。这需要设计一套简单的资源请求/批准协议。设计协商协议让协调者智能体之间具备简单的协商能力。当经济协调者收到“建造基地”任务但矿物不足时它可以向军事协调者发送一个协商请求“我急需200矿物建造二矿以完成‘扩张经济’目标你是否可以暂缓建造下一个兵营”这需要在通信协议中增加NEGOTIATION_REQUEST和NEGOTIATION_RESPONSE消息类型并在提示词中教导智能体如何进行简单的利弊权衡与协商。5.4 成本与性能瓶颈频繁调用大型LLM如GPT-4成本高昂且延迟可能影响实时性。降本增效实践模型分层使用对实时性要求高、任务简单的执行者智能体可以使用更小、更快的模型如较小的开源模型甚至精心设计的规则引擎配合少量LLM调用。只有需要复杂规划和分析的管理者、协调者才使用能力更强的大模型。缓存与复用很多决策在短时间内是稳定的。可以缓存智能体对相似观察的决策结果在一定步长内直接复用而不是每次都调用LLM。例如执行者“农民采矿”的决策在矿点没采完、没有新指令的情况下可以持续多个步长不变。异步决策与并行化不同智能体的决策过程可以异步进行。在一个决策周期内可以同时让所有执行者智能体基于上一周期的任务进行决策和行动而协调者和管理者则在后台并行计算下一周期的计划计算完成后更新黑板供下个周期使用。6. 进阶思考与应用场景延伸Multi$^2$框架的价值不仅在于解决游戏AI问题其“分层协作”的思想可以迁移到众多需要复杂决策与协作的领域。在自动化工作流与RPA场景可以将一个复杂的业务流程如“处理客户发票”分解。管理者智能体解析发票类型和紧急程度协调者智能体调度OCR识别、数据验证、财务系统录入等子任务执行者智能体则是调用具体API的工具。这比设计一个巨型的、处理所有情况的单一自动化脚本要灵活和健壮得多。在智能软件开发与运维想象一个自动化的DevOps流水线。管理者智能体根据代码变更和系统监控判断当前需要进入“开发测试”、“集成部署”还是“故障修复”模式。协调者智能体负责调度测试用例运行、部署管道触发、回滚决策等。执行者智能体则执行具体的docker build、kubectl apply等命令。系统能够更智能地处理流水线中的异常和依赖。在模拟训练与实验平台Multi$^2$框架本身是一个绝佳的研究平台用于探索多智能体协作、人机协作、应急响应等课题。通过调整层级结构、通信协议和智能体的提示词可以模拟出各种组织行为模式观察其效率与鲁棒性。我个人在尝试将类似框架应用于一个内部流程自动化项目时的体会是最大的挑战不在于让单个LLM智能体“变聪明”而在于设计一套清晰、稳定、容错的“组织规则”。这更像是在设计一个公司的管理制度和沟通流程。提示词是岗位说明书通信协议是会议和报告制度黑板是公司的公共数据库。一个设计良好的框架即使其中的每个“员工”智能体能力平平也能通过有效的协作产生“112”的效果。反之如果架构混乱职责不清通信不畅即使每个智能体都用上最顶尖的模型整个系统也会陷入内耗和混乱。因此在动手编码之前花足够的时间在纸上画清楚智能体的层级、职责、输入输出和数据流是项目成功最关键的一步。