面试题 · Agent
请描述多Agent系统框架的基本结构组成，并探讨是否存在构建多Agent系统的通用方法论或设计原则？
核心组件四层结构：
典型协作拓扑：
按学习路线查看教程、项目和面试题。
| 原则 | 核心要义 |
|---|---|
| 单一职责 | 每个Agent聚焦一个明确能力域，避免"万能Agent" |
| 显式契约 | 输入输出Schema标准化，降低耦合（如OpenAI的Function Calling格式） |
| 状态外置 | 关键状态持久化到共享存储，Agent无状态化便于弹性扩缩 |
| 容错设计 | 超时重试、降级策略、人工介入钩子 |
| 可观测性 | 全链路追踪Agent间的调用链与决策路径 |
关键权衡：灵活性与可控性——对话式协作易发散，状态机式协作需预设完备。
场景切入
假设我们做一个智能客服系统，需要多个Agent协作：一个负责意图识别，一个查订单，一个生成回复。你会怎么设计这个多Agent框架？核心组件有哪些？
层层追问
你觉得多Agent系统和单个Agent比起来，难点在哪？……那怎么让它们高效协作呢？……有没有通用的设计原则可以遵循？比如架构上的考量？
直球架构
请描述一个多Agent系统框架的基本结构组成，并讨论是否存在构建多Agent系统的通用方法论或设计原则。从组件、通信、协调到环境接口，以及你的实践经验。
这道题其实是在问：当任务复杂到单个大模型搞不定时，我们怎么拆成多个[[Agent]]，让它们像团队一样协作，同时又不失控。多Agent系统的基本结构，你可以理解成四个层次。最下面是Agent本体层，每个Agent有自己的LLM、工具集、记忆模块，还有角色定义，比如客服Agent和质检Agent的人格设定就完全不一样。往上是通信层，Agent之间怎么说话，常见的有直接对话、广播消息，还有黑板机制，就是大家往一个共享区域写信息，谁需要谁去拿。再往上协调层，负责拆任务、排优先级、解决冲突，决定谁做什么、什么时候做。最上面是环境接口层，连外部API、共享存储、人机交互界面。
讲几个通用设计原则。先看单一职责，每个Agent只干一件事，别搞万能Agent。比如客服退款场景，拆成意图识别Agent、订单查询Agent、退款处理Agent，每个专注自己的领域，好维护也好调试。再看状态外置，关键状态别存在Agent的上下文里，要放到共享存储，比如Redis或数据库。这样Agent挂了可以无状态重启，也方便横向扩展。还要看显式契约，Agent之间输入输出格式要标准化，比如都用[[Function Calling]]的Schema，这样换掉一个Agent不影响其他。
具体到框架，差异挺大。AutoGen是对话驱动，两个Agent聊着聊着就把任务完成了，适合探索性任务，比如头脑风暴，但容易跑偏。LangGraph是显式状态机，节点和边都定义好，可控性强，适合生产环境，比如订单处理流程，但灵活性差一些。CrewAI上手快，角色扮演风格，但定制性弱。实际落地时，我倾向混合架构，核心流程用状态机保证可靠性，边缘探索任务用对话式Agent。
这里有个坑，就是状态一致性问题。多个Agent并发操作共享数据，很容易出现脏读或死锁。我会引入版本号或乐观锁，每次更新前检查版本。另外，调试多Agent系统非常痛苦，每个Agent的决策链都要能追踪，所以可观测性是必须的，每个Agent的输入输出和中间推理都要打日志。
还有一个点，就是中心化协调和去中心化协商的权衡。中心化调度简单，但协调者是单点瓶颈；去中心化灵活，但一致性难保证。我倾向于在任务复杂度高、实时性要求不高的场景用去中心化，反之用中心化。
所以，多Agent系统不是银弹，前提是你得把业务逻辑理清楚，能拆成独立职责的模块。如果任务之间耦合太紧，硬拆反而增加复杂度。