基于LLM的多智能体系统构建：从原理到实践

1. 项目概述与核心价值

最近在探索AI智能体应用时，发现了一个名为“Agent of Empires”的开源项目，它的名字就透着一股宏大的叙事感。简单来说，这是一个基于大型语言模型（LLM）构建的、用于模拟和运行多智能体协作系统的框架。你可以把它想象成一个数字沙盘，在这个沙盘里，你可以创建多个拥有不同角色、目标和能力的AI智能体，让它们在一个共享的环境（比如一个虚拟的城镇、一个公司、一个游戏世界）中自主交互、协作甚至竞争，共同完成复杂的任务。

这个项目的核心价值在于，它为我们提供了一个低门槛、高灵活性的“智能体社会”实验平台。过去，想要研究多智能体系统（Multi-Agent System, MAS），往往需要深厚的分布式计算、强化学习或博弈论背景，从零搭建通信、协调、环境模拟等底层架构，门槛极高。而“Agent of Empires”将LLM作为每个智能体的“大脑”，利用其强大的自然语言理解、推理和生成能力，极大地简化了智能体行为逻辑的构建。开发者或研究者只需关注智能体的角色设定、任务规划和环境规则，就能快速构建出能进行复杂对话、制定策略、使用工具、并产生涌现行为的智能体社群。

它适合谁呢？首先，是对AI前沿应用感兴趣的开发者，你可以用它来构建智能客服团队、自动化工作流协调员，或者更酷的——游戏NPC生态。其次，是研究人员，可以在一个可控的环境里研究社会动力学、组织行为学或经济学模型。最后，对于产品经理和创业者，这也是一个绝佳的原型验证工具，可以快速模拟一个由AI驱动的产品或服务是如何被多个“虚拟用户”使用和评价的。

2. 架构设计与核心组件拆解

要理解“Agent of Empires”如何工作，我们需要深入其架构。整个系统可以看作一个由“环境”、“智能体”、“记忆”和“协调器”四大核心组件构成的循环。

2.1 环境：智能体活动的舞台

环境是智能体感知和行动的对象。在项目中，环境通常被定义为一个共享的、结构化的状态空间。它可以是一个简单的文本描述（如“一个会议室，里面有白板、投影仪和五把椅子”），也可以是一个复杂的、包含实体和关系的图谱数据库。

环境的核心职责是：

1. 状态维护：记录当前世界的所有事实，例如物品的位置、智能体的属性、已完成的任务等。
2. 动作执行与反馈：接收智能体发出的动作指令（如“移动到A地点”、“拿起杯子”），根据预设的物理或逻辑规则判断动作是否有效，并更新环境状态，将结果反馈给智能体。
3. 事件触发：可以主动或按计划向环境内注入事件（如“突然下雨了”、“客户发来了新需求”），驱动智能体做出反应。

在“Agent of Empires”的典型实现中，环境往往通过一个WorldState类来管理，它可能包含一个JSON对象或一个图数据库连接，用于存储所有动态信息。

2.2 智能体：拥有“大脑”的独立个体

智能体是系统的核心。每个智能体都包含以下几个关键部分：

• 角色设定：这是智能体的“人设”，包括姓名、职业、性格、长期目标、口头禅等。例如，“张三，一个谨慎细致的财务分析师，目标是控制项目预算在100万以内”。
• LLM核心：通常集成如GPT-4、Claude 3或开源的Llama 3、Qwen等模型。LLM负责处理所有“思考”工作：理解环境观察、检索相关记忆、规划下一步行动、生成自然语言回应或结构化动作指令。
• 记忆系统：这是智能体实现持续性和个性化的关键。记忆通常分为：
  • 短期记忆/工作记忆：保存当前对话或任务的上下文。
  • 长期记忆：一个向量数据库（如Chroma、Weaviate），存储智能体过去的经历、学到的知识、与其他智能体的关系亲密度等。当需要决策时，系统会从长期记忆中检索最相关的片段，注入到给LLM的提示词中。
• 工具集：赋予智能体“动手能力”。工具可以是调用外部API（查询天气、发送邮件）、操作环境状态（修改白板内容）、进行计算，甚至是调用其他智能体。LLM通过函数调用（Function Calling）或ReAct等模式来决定何时使用何种工具。

注意：智能体的“幻觉”问题在这里会被放大。一个智能体可能基于错误记忆或错误推理，做出不符合环境规则的动作。因此，环境的“动作验证”和“记忆的可靠性设计”至关重要。

2.3 协调与通信：智能体社会的运行规则

多个智能体共存，就需要规则。协调机制决定了智能体如何交互。

1. 通信协议：智能体之间如何“说话”？常见方式有：
   • 广播：某个智能体的发言可以被环境中所有智能体听到（或看到）。
   • 私聊：点对点通信，只有指定的接收者能获取信息。
   • 基于事件的触发：当环境发生某件事时，只有相关智能体会收到通知。
2. 调度策略：在模拟的每一步，决定哪个智能体先行动。可以是简单的轮询（Round Robin），也可以是基于优先级、或由某个“管理者”智能体动态指派。
3. 冲突解决：当两个智能体的目标或行动发生冲突时（比如都想用同一台打印机），系统需要有仲裁机制。这可以是一个固定的规则（“先到先得”），也可以交由一个特定的“仲裁者”智能体来裁决。

“Agent of Empires”的优雅之处在于，这些协调规则本身也可以用配置或自然语言来描述，甚至由另一个更高级的“元智能体”来动态调整。

2.4 项目文件结构解析

查看njbrake/agent-of-empires的仓库，我们通常能看到类似如下的结构：

agent-of-empires/ ├── agents/ # 智能体核心类定义 │ ├── base_agent.py # 智能体基类，定义思考、行动循环 │ ├── role_playing_agent.py # 具备角色扮演能力的智能体 │ └── memory/ # 记忆系统实现 │ ├── short_term.py │ └── long_term_vector.py ├── environment/ # 环境定义 │ ├── world_state.py │ └── simulator.py # 环境模拟器，推进时间、处理动作 ├── coordination/ # 协调机制 │ ├── scheduler.py # 智能体调度器 │ └── communication_bus.py # 通信总线 ├── tools/ # 工具库 │ ├── calculator.py │ ├── web_search.py │ └── custom_tool.py ├── configs/ # 配置文件（YAML/JSON） │ └── startup_town.yaml # 定义一个“创业小镇”场景 ├── utils/ # 工具函数 ├── main.py # 主运行入口 └── requirements.txt # 项目依赖

这种结构清晰地将各核心组件模块化，便于扩展和维护。例如，你想新增一个“画家”智能体，只需在agents/下继承基类，并为其添加paint()工具即可。

3. 从零搭建一个多智能体模拟场景

理论说了这么多，我们来动手搭建一个简单的场景：“一个小型软件开发团队”。这个团队由一名项目经理、一名前端工程师和一名后端工程师组成，他们的共同目标是完成一个用户登录功能。

3.1 环境与角色定义

首先，我们定义环境状态。创建一个configs/dev_team.yaml文件：

environment: name: "虚拟软件项目室" state: current_sprint: "Sprint 1" project: "用户登录系统" backlog: # 产品待办列表 - id: "US-001" title: "设计登录页面UI" status: "todo" assignee: null - id: "US-002" title: "实现后端登录API" status: "todo" assignee: null - id: "US-003" title: "前后端联调" status: "todo" assignee: null resources: - "前端开发服务器" - "后端开发服务器" - "团队沟通频道"

接下来，定义三个智能体。在代码中，我们初始化它们：

# 示例代码，基于假设的框架API from agents.role_playing_agent import RolePlayingAgent project_manager = RolePlayingAgent( name="王经理", role="项目经理", personality="有条理，善于协调，关注截止日期", goal="确保登录功能在Sprint 1结束时高质量完成", long_term_memory_db=chroma_client.create_collection(name="wang_manager_memories") ) frontend_dev = RolePlayingAgent( name="小李", role="前端工程师", personality="注重细节，热爱新技术，有点完美主义", goal="实现美观、响应式的登录页面，并与后端流畅对接", tools=[UISketchTool, CodeEditorTool, APITestTool], long_term_memory_db=chroma_client.create_collection(name="li_frontend_memories") ) backend_dev = RolePlayingAgent( name="老张", role="后端工程师", personality="稳重，注重安全和性能", goal="构建安全、高效的登录API，处理好用户认证与数据存储", tools=[APIDesignTool, DatabaseTool, SecurityCheckTool], long_term_memory_db=chroma_client.create_collection(name="zhang_backend_memories") )

每个智能体在初始化时，我们会向它的长期记忆里“植入”一些基础知识和关系，例如：“王经理是小李和老张的上司”、“小李和老张在之前的项目中合作愉快”。

3.2 配置运行循环与通信

主运行逻辑main.py可能如下所示：

import asyncio from coordination.scheduler import RoundRobinScheduler from coordination.communication_bus import BroadcastBus from environment.simulator import WorldSimulator async def main(): # 1. 初始化环境 world = WorldSimulator.load_from_config("configs/dev_team.yaml") # 2. 初始化智能体列表 agents = [project_manager, frontend_dev, backend_dev] # 3. 初始化协调器（轮询调度 + 广播通信） scheduler = RoundRobinScheduler(agents) comm_bus = BroadcastBus() # 4. 模拟运行10个回合 for round in range(10): print(f"\n=== 回合 {round+1} ===") current_agent = scheduler.get_next_agent() # 4.1 智能体感知环境 observation = world.get_observation_for(current_agent) # 观察中包括：环境状态 + 其他智能体上一回合的公开发言 # 4.2 智能体“思考”并决定行动 # 这里会调用LLM，结合记忆和工具，生成行动指令 action = await current_agent.think_and_act(observation, comm_bus) # 4.3 环境执行动作并更新状态 result = world.execute_action(current_agent.name, action) # 4.4 智能体接收结果，并更新记忆 current_agent.update_memory(observation, action, result) # 4.5 如果动作是广播消息，则通过通信总线发送 if action.type == "broadcast_message": comm_bus.broadcast(current_agent.name, action.content) # 可选：每回合后保存环境快照，用于复盘 world.save_snapshot(round) if __name__ == "__main__": asyncio.run(main())

在这个循环中，智能体们会依次行动。王经理可能会先分配任务（修改backlog中任务的assignee），小李领取前端任务后开始“编码”（调用CodeEditorTool，其执行结果可能改变环境状态，如将US-001状态改为in progress），老张亦然。他们可以通过广播总线讨论接口规范或联调问题。

3.3 提示词工程：塑造智能体行为

智能体的“灵魂”在于给LLM的提示词。一个典型的think_and_act方法内部的提示词模板可能包含：

你是一个{role}，名叫{name}。你的性格是：{personality}。你的长期目标是：{goal}。 当前环境状态： {formatted_world_state} 相关历史记忆（你过去的相关经历）： {retrieved_memories} 最近团队沟通记录： {recent_messages} 你可以使用的工具： {tools_description} 请基于以上信息，决定你接下来要做什么。你的输出必须是以下JSON格式之一： 1. 如果你想说话：{{"action": "speak", "content": "你想说的话", "to": "all" 或 "特定智能体名"}} 2. 如果你想使用工具：{{"action": "use_tool", "tool_name": "工具名", "parameters": {{...}}}} 3. 如果你想在环境中做某事：{{"action": "act_on_world", "command": "具体的操作指令", "target": "操作对象"}} 你的思考过程（仅内部推理，不要输出）： ... 你的最终行动决定：

通过精心设计提示词，我们可以引导智能体表现出更符合预期的协作行为，比如在动手前先同步信息，在遇到困难时主动求助。

4. 高级特性与实战技巧

当基础的多智能体模拟跑通后，我们可以探索一些更高级的特性，让整个系统更加逼真和强大。

4.1 动态环境与事件驱动

静态的环境很快会变得乏味。我们可以引入事件系统。在环境配置中增加一个events列表：

events: - trigger: "round == 5" # 第5回合触发 type: "requirement_change" content: "客户提出新需求：登录需要增加短信验证码功能。" - trigger: "state.backlog.US-002.status == 'done'" # 后端API完成时触发 type: "integration_ready" content: "后端登录API已部署到测试环境，可供前端联调。"

世界模拟器在每个回合检查触发条件，一旦满足，就将事件内容作为环境观察的一部分，广播给所有或相关智能体。这能模拟项目开发中常见的需求变更和里程碑事件，测试智能体的应变能力。

4.2 智能体关系与情感模拟

为了让交互更生动，可以为智能体引入简单的“关系值”和“情绪状态”。这些可以作为内部状态存储在记忆里，并影响其行为。

• 关系值：智能体A对智能体B有一个从-10（敌对）到+10（信任）的数值。当B帮助A完成任务时，关系值增加；当B批评或阻碍A时，关系值减少。
• 情绪状态：如“高兴”、“沮丧”、“有压力”。情绪可以受任务进度、与其他智能体的互动、甚至随机事件影响。

在提示词中，可以加入：“你当前对小李的信任度是+7（关系良好），情绪状态是‘专注但略有压力’。请据此决定你的沟通语气和合作意愿。”这样，LLM生成的回应会更加拟人化，例如关系好时更愿意提供帮助，有压力时可能说话更简短。

4.3 工具使用的进阶设计

工具是智能体能力的延伸。设计得好，能极大提升效率。

1. 工具的组合与链式调用：一个“编写用户故事”工具，内部可以链式调用“查询类似案例”工具和“生成验收标准”工具。
2. 工具的权限与成本：为工具设置使用权限（如只有项目经理能使用“分配任务”工具）和“成本”（如调用一次“代码生成”工具需要消耗一定的“精力”点数），迫使智能体更谨慎地规划行动。
3. 工具学习：智能体可以通过观察其他智能体使用工具的成功案例，或在长期记忆中记录某个工具在什么情境下最有效，来“学习”优化自己的工具使用策略。

4.4 评估与调试：如何知道你的智能体在“好好工作”？

运行一个复杂的多智能体系统，调试是一大挑战。以下是一些实用的评估方法：

• 设定关键绩效指标：根据场景目标定义KPI。对于开发团队，可以是“任务完成数量”、“bug引入数量”、“沟通回合数”等。在环境状态中记录这些指标。
• 轨迹记录与可视化：详细记录每个智能体每个回合的观察、思考、行动和结果。将这些数据可视化，例如绘制任务完成进度甘特图、智能体交互社交网络图。
• “上帝视角”干预与A/B测试：作为管理员，你可以在运行中暂停，手动修改某个智能体的记忆或环境状态，然后继续运行，观察不同“干预”下的系统演变路径，进行对比。
• 定性分析对话日志：仔细阅读智能体间的对话日志，检查其是否合乎逻辑、是否围绕目标、是否出现了无意义的循环或离题万里的“幻觉”。这是调整提示词和规则的重要依据。

实操心得：在初期，不要追求一次模拟太多回合。先运行3-5个回合，仔细检查日志，确保每个智能体的基本行为符合预期，通信和工具调用没有错误。然后再逐步增加回合数和智能体复杂度。另外，给LLC的提示词中加入明确的输出格式限制（如必须输出JSON），能极大简化后续的解析逻辑，避免“解析错误”这个最常见的运行时问题。

5. 典型问题排查与性能优化

在实际运行“Agent of Empires”这类项目时，你肯定会遇到各种问题。下面是一些常见坑点及其解决方案。

5.1 智能体行为异常问题排查

5.2 系统性能与成本优化

多智能体系统频繁调用LLC，成本和延迟是现实问题。

• 缓存策略：对于常见的、结果不变的查询（如“今天的日期”、“项目章程内容”），可以将LLM的回复缓存起来，下次直接使用。可以使用@lru_cache装饰器或Redis。
• 分层调用：并非每一步思考都需要调用最强大（也最贵）的模型。可以设计一个“双系统”：一个快速、廉价的小模型（如小型化的开源模型）负责常规决策和对话；只有当遇到复杂规划、推理或创意任务时，才召唤强大且昂贵的大模型。
• 异步并行：如果智能体之间的行动在逻辑上独立，可以尝试让它们在同一回合内异步执行think_and_act，然后用asyncio.gather等待所有结果，再统一更新环境。这能显著减少模拟现实时间。
• 减少上下文长度：这是控制成本最有效的方法。定期总结和清理对话历史，将冗长的历史压缩成几个关键要点后再存入长期记忆。在给LLM的提示词中，只放入最相关的几条记忆和最近几次对话。

5.3 扩展性与可维护性建议

当场景越来越复杂时，良好的工程实践能让你事半功倍。

1. 配置驱动：将所有智能体角色、环境初始状态、事件规则都写在YAML或JSON配置文件中。主代码从配置文件加载一切。这样，要创建新场景，几乎不需要修改代码。
2. 插件化架构：将工具、记忆后端、通信协议、调度策略设计成可插拔的接口。例如，通过实现一个Memory接口，你可以轻松地将记忆存储从Chroma切换到Pinecone。
3. 状态序列化：实现环境状态和智能体记忆的完整序列化与反序列化功能。这允许你随时保存模拟的“存档”，并在之后加载回来继续运行，对于调试和演示至关重要。
4. 日志与监控：建立完善的日志系统，记录不同级别（DEBUG, INFO, ERROR）的信息。可以考虑集成像Prometheus这样的监控工具，来跟踪每个智能体的API调用次数、耗时、工具使用频率等指标。

我个人在搭建这类系统时，最大的体会是：始于简单，迭代增长。不要一开始就设计一个拥有20个智能体、100条规则的复杂世界。从一个智能体、一个简单任务开始，确保它能正确感知、思考、行动。然后加入第二个智能体和最基本的通信。接着引入工具和记忆。每增加一个特性，都充分测试。这个过程中，你会对LLM的“习性”、多智能体交互的涌现现象有更直觉的理解，这些经验远比一开始就追求宏大叙事更有价值。最后，别忘了享受这个过程，看着你创造的这些数字生命在规则内自主演化、协作甚至产生意想不到的创意，本身就是一种独特的乐趣。