1. 从单兵作战到团队协作：为什么我们需要多Agent系统？

最近在捣鼓AI应用开发的朋友，可能都有过类似的体验：你有一个挺复杂的任务，比如想让它帮你分析一份财报，然后写个总结，再根据总结做个PPT大纲。你对着一个AI大模型，吭哧吭哧地输入一连串的指令，扮演着“项目经理”、“数据分析师”、“文案编辑”和“设计师”多个角色，来回切换，不断调整提示词。整个过程就像在指挥一个能力超强但“一根筋”的超级员工，你得把每一步都掰开揉碎了喂给它，稍有不慎，它可能就理解偏了，或者忘了上一步的上下文。

这就是典型的“单Agent”模式。一个AI模型，一个大脑，处理所有事情。它很强，但不够“聪明”，这里的聪明指的是系统性的任务分解与协作能力。人类处理复杂问题，靠的是分工协作，各司其职。把这个逻辑搬到AI世界，就是“多Agent系统”的核心思想。

我最近花了不少时间，动手做了一个多Agent智能协作软件的原型。我的目标很简单：让AI告别单打独斗，像一支训练有素的团队一样工作。一个Agent负责理解用户模糊的指令并拆解任务（项目经理），一个Agent专精于数据检索与分析（分析师），另一个Agent擅长结构化写作（编辑），还可以有一个Agent负责检查逻辑和格式（质检员）。它们之间能传递信息、讨论分歧、接力完成工作。

这不仅仅是“多个AI聊天窗口”那么简单。真正的多Agent协作，涉及到角色定义、任务编排、通信协议、记忆管理和冲突解决等一系列工程问题。市面上已经出现了一些优秀的框架和概念，比如基于LangGraph构建的工作流、强调任务拆分的CrewAI、或是某些新兴的智能体平台。我的实践正是基于对这些理念的探索，试图打造一个更轻量、更聚焦于特定场景（比如内容创作、数据分析报告生成）的协作环境。

接下来，我会详细拆解这个过程中的核心思考、技术选型、实现细节以及那些只有亲手搭建才会遇到的“坑”。无论你是对Agent概念感兴趣的开发者，还是想寻找下一代AI应用形态的产品经理，希望这些来自一线的实战经验能给你带来启发。

2. 多Agent系统的核心架构：不只是“多个聊天机器人”

在开始写代码之前，我们必须先想清楚：一个能真正协作的多Agent系统，它的骨架应该长什么样？这决定了软件的扩展性、稳定性和智能上限。经过多次迭代，我最终确定的架构主要包含以下几个层次，它们共同构成了智能体团队的“操作系统”。

2.1 智能体（Agent）本体：定义角色与能力

这是系统中最基本的执行单元。每个Agent不再是一个通用模型，而是一个被赋予了特定角色、目标和能力的“专家”。

• 角色（Role）：这是Agent的“岗位说明书”。例如，“财务分析师”、“创意文案”、“代码审查员”。角色决定了它的行为模式和对话风格。
• 目标（Goal）：Agent存在的意义。例如，财务分析师的目标是“从提供的数据中提取关键财务指标并评估风险”；创意文案的目标是“将分析结果转化为吸引人的、符合品牌调性的文案”。
• 能力（Capabilities）：Agent能做什么。这通常通过以下几部分实现：
  • 核心大模型（LLM Core）：Agent的“大脑”。可以是同一个大模型（如GPT-4）的不同实例，也可以是针对不同任务微调的专用模型，甚至是本地部署的小模型。关键在于，为不同角色配置最合适的系统提示词（System Prompt），将角色、目标和约束“固化”到它的思维中。
  • 工具集（Tools）：Agent的“双手”。大模型不擅长计算、搜索、读写文件。因此，我们需要为Agent配备工具。一个数据分析Agent可能需要调用Python计算库；一个研究Agent需要联网搜索工具；一个写作Agent需要调用文档生成API。在我的实现中，使用了类似LangChain Tools的抽象，让Agent可以声明并调用这些功能。
  • 记忆（Memory）：Agent的“笔记本”。分为两种：
    1. 短期记忆/会话记忆：保存当前任务执行过程中的上下文，确保它在多轮对话中不迷失。
    2. 长期记忆：可选。可以是一个向量数据库，存储Agent的历史经验或领域知识，供其在类似任务中快速调用。

一个定义良好的Agent，应该像这样工作：当接收到任务时，它会根据角色和目标，自主决定是否需要使用工具、如何组织思考过程（Chain of Thought），并生成输出。

2.2 编排器（Orchestrator）：团队的指挥中枢

这是多Agent系统的“大脑”或“项目经理”。它的职责是协调整个团队的工作流。编排器接收用户的初始任务，然后决定：

1. 任务分解：将复杂的用户请求拆解成一系列有序的子任务。例如，“为我分析特斯拉Q3财报并写一份摘要”会被分解为“获取特斯拉Q3财报数据”、“提取关键财务指标（营收、利润、现金流等）”、“进行同比/环比分析”、“撰写分析摘要”等。
2. Agent调度：为每个子任务分配合适的Agent。它维护着一个Agent注册表，知道每个Agent擅长什么。分解出的“提取关键财务指标”任务会分配给“财务分析Agent”。
3. 流程控制：决定任务执行的顺序。是串行、并行，还是有条件分支？比如，必须等“数据获取Agent”成功返回数据后，“分析Agent”才能开始工作。
4. 结果整合：收集各个Agent的输出，按照既定逻辑进行汇总、去重、格式化，最终生成给用户的统一结果。

我尝试过几种实现编排器的方式：简单的基于规则的状态机、使用LangGraph这样的图工作流框架、以及用一个大模型（我称之为“主管Agent”）来动态决策。目前我的软件采用了混合模式：对于确定性高的流程用图定义，对于需要灵活判断的环节则调用“主管Agent”。

2.3 通信层（Communication Layer）：Agent之间的“会议室”

Agent不能活在真空里，它们需要交流。通信层定义了信息交换的协议和媒介。

• 消息协议：最简单的就是自然语言。Agent A完成任务后，将结果以文本形式发送给编排器或下一个Agent。但为了更结构化的协作，我定义了标准的消息格式，包含发送者、接收者、消息类型（如任务结果、请求帮助、提出质疑）、内容和元数据（如关联的任务ID）。
• 通信模式：
  • 广播（Broadcast）：主管Agent向所有相关Agent同步信息。
  • 发布/订阅（Pub/Sub）：Agent可以订阅特定类型的任务或消息。
  • 直接对话（Direct Chat）：两个Agent被允许直接对话，以讨论某个子任务的细节。这能模拟团队中的“小会”。
• 共享工作区（Shared Workspace）：这是一个非常重要的概念。想象成一个团队的共享白板或云端文档。所有Agent都可以在这里读取和写入中间成果。例如，分析Agent把整理好的数据表格贴到工作区，写作Agent直接从工作区获取这些数据来撰写报告。这避免了信息在传递过程中丢失或变形，也方便任何一个Agent回溯检查。

2.4 监督与评估模块：确保输出质量

多Agent系统也可能“集体犯错”或陷入低效循环。因此，需要引入监督机制。

• 人类监督（Human-in-the-loop）：在关键节点设置检查点，将中间结果呈现给用户确认，再继续执行。这增加了可控性。
• AI监督（AI-in-the-loop）：引入一个专门的“评审Agent”。它的角色是“质检员”或“专家委员会”，负责评估其他Agent产出的质量，比如检查事实准确性、逻辑连贯性、格式规范性等。如果评审不通过，任务可能被发回重做或触发新的讨论。
• 超时与故障处理：给每个任务设置超时时间，防止某个Agent“卡死”导致整个流程停滞。当Agent执行出错时，编排器需要能捕获异常，并决定是重试、换一个Agent执行，还是上报错误。

这个架构看起来复杂，但它的优势是清晰的：高内聚、低耦合。每个Agent只需专注自己的专业领域，编排器负责宏观协调，通信层确保信息流畅。当需要增加新功能时，你只需要训练或配置一个新的“专家”Agent，并将其注册到系统中即可，无需推翻重来。

3. 关键技术选型与实现：从理论到代码

确定了架构，下一步就是选择合适的技术栈将其实现。这里没有银弹，我的选型是基于“快速验证核心想法”、“保持足够灵活性”和“控制复杂度”这三个原则进行的。

3.1 大模型层：核心大脑的选择

这是整个系统的基石。我主要评估了以下几个方向：

• 云端大模型API（如OpenAI GPT-4, Anthropic Claude）：

  • 优点：能力强大，特别是GPT-4在复杂推理、指令遵循和角色扮演方面表现出色。无需担心部署和算力，开发速度快。
  • 缺点：成本高（尤其是多Agent频繁调用时），数据隐私性需要考虑，存在API速率限制和潜在的不稳定性。
  • 我的选择：在原型开发阶段，我主要使用GPT-3.5-Turbo和GPT-4 API。它们为不同角色的Agent提供了稳定可靠的基础能力。为了控制成本，我会对非核心推理环节（如格式整理）使用更便宜的模型，并为所有调用添加了完善的日志和成本统计。

• 本地开源大模型（如Llama 3, Qwen, DeepSeek）：

  • 优点：数据完全私有，无使用成本（只有硬件成本），可定制化微调。
  • 缺点：对硬件要求高，同等参数下能力通常弱于顶级闭源模型，需要自己处理部署、优化和上下文长度等问题。
  • 我的实践：我尝试用Ollama在本地部署了Qwen2.5-7B模型，用于一些对推理能力要求不高的Agent（如简单的文本格式化Agent）。这证明了混合云-本地模型的可行性。对于核心的分析和创作Agent，目前仍依赖云端大模型。

提示：一个常见的误区是追求所有Agent都用最强模型。实际上，根据任务复杂度分层使用模型是更经济高效的做法。主管Agent（负责复杂任务拆解和调度）可以用最强模型，而执行具体、格式化任务的Worker Agent可以用轻量级模型。

3.2 框架与工具链：站在巨人的肩膀上

完全从零开始实现通信、记忆、工具调用等底层功能是巨大的工程。我选择了组合使用现有成熟框架。

• LangChain / LangGraph：

  • LangChain：我主要利用其提供的Agent、Tool抽象以及大量的集成（如搜索引擎、计算器、各种API）。它让为Agent装备“工具”变得非常方便。
  • LangGraph：这是我实现编排器和工作流的核心。它允许你用“图”来定义Agent之间的协作流程。节点（Node）可以是执行一个Agent，边（Edge）定义了执行路径。LangGraph内置了状态管理，能很好地维护整个对话的上下文，非常适合实现带有分支、循环和并行步骤的复杂工作流。我的软件中，每个复杂的任务类型（如“生成市场分析报告”）都对应一个预先定义好的LangGraph图。

• CrewAI：

  • 这是一个更高层次的多Agent框架。它直接内置了Agent、Task、Process（相当于编排逻辑）和Crew（团队）的概念，开箱即用的味道更浓。它的设计哲学是让创建Agent团队像搭积木一样简单。
  • 我在早期快速验证想法时使用了CrewAI。它的优点是上手极快，但深度定制工作流和通信模式时，感觉不如LangGraph灵活。最终，我的软件在核心编排层借鉴了CrewAI的Agent-Task设计思想，但用LangGraph实现了更底层的流程控制。

• 向量数据库与记忆：

  • 对于需要长期记忆或知识库的Agent，我选择了ChromaDB。它轻量、易用，适合原型开发。每个Agent可以有自己的向量存储，用于记忆任务上下文或存储领域知识。例如，一个“技术文档专家”Agent的向量库中存储了项目相关的API文档，当它需要回答问题时，可以先进行相关文档检索（RAG），再生成答案。

3.3 通信与状态管理的实现细节

这是将各个部分粘合起来的关键。

• 基于事件的通信：我实现了一个简单的事件总线（Event Bus）。当Agent完成任务、编排器发出指令、或评审Agent提出意见时，都会发布一个事件。关心该事件的组件（其他Agent、编排器、日志模块）会订阅并处理。这实现了松耦合的通信。

• 共享状态管理：LangGraph的State对象是整个工作流的“共享工作区”的完美载体。这个State是一个字典，可以在各个执行节点（Agent）间传递和修改。例如：

  # 伪代码示例 from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator class AgentState(TypedDict): # 定义共享状态的结构 original_query: str # 用户原始问题 subtasks: list # 分解后的子任务列表 research_data: Annotated[list, operator.add] # 研究Agent收集的数据，会被累加 analysis_report: str # 分析Agent生成的报告 final_output: str # 最终输出 # 构建图，每个节点（函数）都能读取和修改AgentState workflow = StateGraph(AgentState) workflow.add_node("planner_agent", planner_node_function) workflow.add_node("research_agent", research_node_function) workflow.add_node("analysis_agent", analysis_node_function) workflow.add_node("writer_agent", writer_node_function) # ... 添加边，定义流程

  这样，research_agent节点可以把找到的数据存入state['research_data']，analysis_agent节点可以直接读取这些数据进行分析，实现了信息的无缝共享。

• 错误处理与回退：在每个Agent的执行函数外，我都包裹了try...except块。如果某个Agent调用失败（如API超时、工具异常），会触发一个“故障处理”流程。编排器会尝试重试、更换备用模型，或者将任务标记为失败，并尝试让其他Agent接手或通知用户。

4. 实战演练：构建一个“行业分析报告”生成团队

理论说再多，不如看一个实际例子。假设用户输入：“请分析一下新能源汽车行业2024年上半年的市场竞争格局，并预测下半年的趋势。”

我的多Agent软件会如何协作完成这个任务？下面我拆解整个工作流的执行步骤。

4.1 阶段一：任务规划与分解（主管Agent）

首先，用户请求被发送给“主管Agent”（即编排器的智能部分）。这个Agent由GPT-4驱动，拥有强大的任务分解能力。

1. 理解与拆解：主管Agent分析指令，识别出核心需求：行业分析、时间范围（2024上半年）、主题（市场竞争格局）、交付物（趋势预测）。它会将这个大任务分解为一系列原子性子任务：

   • T1（研究）：搜集2024年上半年全球及中国新能源汽车的销量数据、主要品牌（如特斯拉、比亚迪、蔚小理等）的市场份额变化、新产品发布动态、重大行业事件（如价格战、政策调整）。
   • T2（分析）：基于T1收集的数据，分析当前的竞争格局（谁是领导者？挑战者是谁？格局是集中还是分散？），识别出关键竞争维度（价格、技术、渠道、供应链）。
   • T3（预测）：结合历史趋势、当前格局和已知的未来变量（如新车上市计划、宏观经济预期），预测2024年下半年市场竞争的可能演变，包括潜在的黑马、合作与并购可能性等。
   • T4（撰写）：将T2的分析结果和T3的预测整合成一份结构清晰、语言专业的行业分析报告。

2. 资源调度：主管Agent根据任务类型，从Agent池中分配合适的成员：

   • T1 ->网络研究Agent（配备联网搜索和权威数据源查询工具）
   • T2 ->商业分析Agent（擅长数据解读、SWOT分析、波特五力模型等）
   • T3 ->战略预测Agent（具有逻辑推理和趋势外推能力）
   • T4 ->专业报告撰写Agent（熟悉商业报告文体，文笔流畅）

3. 设定依赖关系：主管Agent定义执行顺序：T1必须最先完成，T2依赖T1的输出，T3依赖T2的输出，T4最后执行，依赖T2和T3的输出。T2和T3理论上可以并行，但T3需要T2的部分结论，所以设计为串行更稳妥。

4.2 阶段二：分布式执行与协作

工作流被激活，各Agent开始按序工作。

• 网络研究Agent出动：它接收到T1的详细描述。它首先规划搜索策略：“我需要销量数据（来源：乘联会、CleanTechnica等）、品牌动态（新闻）、政策文件。”然后，它调用内置的搜索工具，执行多次查询，过滤和总结信息。它会将收集到的结构化数据（如表格）和关键信息摘要写入共享工作区（即LangGraph的State）。它可能会标记某些信息存在矛盾或缺失，供后续Agent参考。

• 商业分析Agent工作：T1完成后，T2自动开始。商业分析Agent从工作区读取所有研究数据。它的系统提示词要求它使用专业的商业分析框架。它可能会执行以下操作：

  • 计算各品牌的市场份额变化曲线。
  • 指出“比亚迪在A级车市场通过冠军版车型发起价格战，显著挤压了合资品牌份额”等关键发现。
  • 分析竞争格局从“特斯拉一枝独秀”演变为“多强并立”的驱动因素。
  • 它将分析结论（文字+图表描述）写入工作区，并可能@战略预测Agent，提出“需重点关注电池成本下降对低端市场格局的影响”这样的观点。

• 战略预测Agent推理：基于T2的扎实分析，预测Agent开始工作。它不会凭空想象，而是基于已有事实进行逻辑推演。例如：“鉴于上半年价格战已导致部分品牌毛利率承压，预计下半年头部企业将通过技术升级（如800V快充、城市NOA）而非进一步降价来竞争。二线品牌可能面临更大整合压力。”它将预测要点和关键论据写入工作区。

• 专业报告撰写Agent整合：最后，撰写Agent登场。它的任务是“缝合”。它读取工作区里所有的中间成果：数据、分析、预测。它按照“摘要-现状分析-竞争格局深度解读-未来趋势预测-结论与建议”的标准报告结构，生成一份完整的文档。它还会检查全文的逻辑连贯性和数据引用准确性。

4.3 阶段三：评审与交付

在最终输出前，我可以选择引入一个“评审Agent”（由另一个高质量的模型实例担任）对报告草稿进行审查。评审Agent会检查：

• 事实一致性：报告中的数据是否与研究阶段收集的数据一致？
• 逻辑漏洞：预测是否基于前面的分析？有无跳跃性结论？
• 格式与语言：是否符合商业报告规范？有无语病？

如果评审提出修改意见，报告可能会被发回给撰写Agent进行修订。最终，一份结构完整、数据翔实、分析深入的行业分析报告就生成并交付给用户了。

整个过程中，用户只需输入一个指令，就像向一个咨询团队下达了任务简报。背后的多Agent系统自动完成了从调研、分析、预测到成稿的全部工作，展现了“团队协作”的强大威力。

5. 开发中的挑战与解决方案：那些绕不开的“坑”

搭建这样一个系统绝非一帆风顺。以下是几个让我耗费了大量时间的关键挑战，以及我的应对思路。

5.1 幻觉与信息一致性难题

这是多Agent系统中最棘手的问题之一。A Agent生成的内容，在传递给B Agent时，可能被误解或扭曲。更严重的是，某个Agent可能在执行中“捏造”了事实（幻觉）。

• 问题表现：研究Agent找到的数据是“品牌A市场份额25%”，分析Agent在报告中写成了“品牌A市场份额30%”，撰写Agent最终可能引用了一个从未出现过的数据源。
• 解决方案：
  1. 强化源头追溯：要求每个Agent在生成内容时，尽可能引用其信息源。例如，研究Agent提供数据时，附上来源链接或摘要。在共享工作区中，信息与其元数据（来源、生成者、时间戳）绑定在一起。
  2. 设立交叉验证环节：在关键数据节点，设置一个“事实核查Agent”。它的任务很简单：对比不同Agent产出的同一事实表述，如果发现冲突，则触发一个“讨论”子流程，让相关Agent重新确认或提供证据。
  3. 限制生成自由度：对于处理确定性信息的Agent（如数据整理Agent），使用更严格的提示词，要求它“严格基于提供的资料，不得添加任何未提及的信息”，并可以要求它以JSON等结构化格式输出，便于程序化校验。
  4. 最终评审机制：如前所述，一个独立的评审Agent专注于一致性检查，这是最后一道防线。

5.2 通信开销与效率瓶颈

Agent之间频繁的通信和模型调用，会导致任务执行速度变慢，成本飙升。

• 问题表现：一个简单任务，因为多个Agent来回对话讨论细节，调用了十几次API，耗时几十秒，费用却不低。
• 解决方案：
  1. 优化工作流设计：避免不必要的串行。仔细分析任务依赖，能让并行执行的环节坚决并行。例如，研究Agent可以同时搜索“销量数据”和“政策新闻”。
  2. 消息压缩与摘要：Agent在传递大量文本信息（如一篇长文章）时，不传递全文，而是先生成一个关键信息摘要，并将原文索引存入工作区。后续Agent如需细节，可按需查询。
  3. 分层模型策略：如前所述，并非所有Agent都需要GPT-4。任务分解、复杂分析、最终评审用强模型；数据提取、格式转换、简单摘要用便宜或本地模型。
  4. 异步执行与超时控制：对于可并行的任务，采用异步调用。为每个子任务设置合理的超时时间，防止某个慢速Agent阻塞整个管道。

5.3 任务分解的粒度与模糊性

“主管Agent”如何进行任务分解，直接决定了后续执行的成败。分解得太粗，单个Agent负担过重，可能失败；分解得太细，通信和管理开销巨大。

• 问题表现：用户请求“帮我策划一个社交媒体营销方案”，主管Agent可能错误地分解出一个“设计全球供应链优化策略”这样完全不相关的子任务。
• 解决方案：
  1. 提供分解范例：在主管Agent的系统提示词中，提供几个不同领域（如市场分析、内容创作、代码开发）的任务分解成功案例，让它学习这种“思维模式”。
  2. 动态任务验证：引入一个简单的验证步骤。主管Agent生成分解计划后，不是立即执行，而是先将其呈现为一个可读的列表，由一个“验证Agent”（或用户）快速确认。或者，让主管Agent自己问自己一句：“这个子任务是否直接服务于最终目标？有没有更简单的分解方式？”
  3. 迭代式分解：不要试图一步到位。采用“规划-执行-反思”循环。主管Agent先做一个初步的高层分解。当第一个Agent（如研究Agent）执行并返回一些结果后，这些新信息可能促使主管Agent对后续任务进行动态调整和细化。

5.4 系统的可解释性与调试

当最终结果不理想时，如何定位问题出在哪个环节？是分解错了，还是某个Agent能力不足，或是通信出了问题？

• 问题表现：生成的报告质量很差，但不知道是研究没做好，还是分析没到位，或是写作水平低。
• 解决方案：
  1. 全链路日志：为每一个Agent的每一次调用、每一次工具使用、每一次消息传递都打上详细的日志。日志包括输入、输出、耗时、token使用量、模型名称等。这就像飞机的黑匣子。
  2. 可视化工作流：利用LangGraph的特性，可以将每次任务执行的工作流图状态保存下来。通过一个简单的可视化界面，可以清晰地看到任务是如何流转的，每个节点的输入输出是什么。这对于调试复杂流程至关重要。
  3. 中间结果检查点：在软件中设计“检查点”功能，允许用户在流程的关键节点（如研究完成、分析完成）暂停，查看当时的共享工作区内容。这能快速定位问题发生的阶段。

6. 未来展望与个人思考：Agent协作的星辰大海

完成这个原型，只是迈出了第一步。多Agent系统展现出的潜力让我非常兴奋，同时也看到了未来需要深耕的方向。

首先，是Agent的“专业化”与“工具化”深度结合。目前的Agent，其专业能力很大程度上依赖于提示词工程和背后大模型的通用能力。未来的方向，是为Agent集成更强大、更垂直的专业工具。比如，数据分析Agent直接连接公司内部的BI系统；代码开发Agent能直接操作IDE、运行测试、发起Merge Request。Agent将从一个“聪明的聊天对象”进化成能够直接操作专业软件的“数字员工”。

其次，是协作模式的进化。目前的协作大多是基于预设流程的“流水线”模式。更高级的协作应该像人类的头脑风暴，具备动态组织和涌现能力。例如，当遇到一个前所未见的问题时，多个Agent可以自发地组织一场辩论，各自提出方案并相互挑战，最终合成一个创新性的解决方案。这需要更复杂的通信协议和共识机制。

再者，是长期记忆与持续学习。现在的Agent每次任务基本都是“从零开始”。如何让Agent团队拥有“组织记忆”？将成功的工作流、积累的知识、犯过的错误都沉淀下来，形成可复用的“团队知识库”。当下次遇到类似任务时，它们能快速调用历史经验，甚至自主优化工作流程。这涉及到更复杂的记忆存储、检索和知识蒸馏技术。

最后，也是最重要的，是人机交互界面的革命。用户不应该去学习如何“指挥”Agent。交互应该更自然。可能是通过自然语言直接描述目标，也可能是通过与一个“首席助理”Agent对话，由它去管理背后的整个团队。界面需要直观地展示团队的工作状态、思考过程和决策依据，让人感到可信、可控。

对我个人而言，构建这个系统的过程，是一个不断将抽象认知具象化的过程。它让我更深刻地理解到，AI的未来不在于创造一个无所不能的“超级AI”，而在于设计一套精妙的机制，让多个各有所长的“专业AI”能够高效、可靠地协同工作，从而解决那些单个AI或单个人类都无法独立应对的复杂挑战。这条路很长，但每一步都充满乐趣和惊喜。