三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

AI Agent架构设计：6种核心模式构建可扩展智能体系统

发布时间：2026/8/9 5:47:29 三亩地 编程学习日记
AI Agent架构设计：6种核心模式构建可扩展智能体系统

1. AI Agent设计模式：从概念到实战的架构心法

最近和几个做AI应用的朋友聊天，发现大家一提到AI Agent，兴奋点都在大模型选型、提示词工程或者RAG检索上，但聊到怎么把一个个智能“想法”组织成一个稳定、可扩展、好维护的“系统”时，往往就有点抓瞎了。代码写着写着就成了“面条式”的if-else，功能加着加着就发现牵一发而动全身，调试起来更是噩梦。这让我想起了早期面向对象编程没有设计模式时的混乱。AI Agent的开发，本质上也是软件工程，尤其是在它需要处理复杂任务、与环境交互、并具备一定自主性时，一套经过验证的架构模式就显得至关重要。今天，我就结合自己踩过的坑和项目实践，聊聊在AI Agent中最常用、最实用的6种设计模式。这些模式不是凭空的理论，而是能直接帮你解决“智能体怎么思考”、“动作怎么执行”、“记忆怎么管理”、“任务怎么分解”这些核心问题的工具箱。无论你是用Python、Java还是C#，无论你是做自动化流程、数据分析Agent还是对话机器人，理解这些模式都能让你的Agent代码从“能跑”升级到“跑得好、跑得稳”。

2. 模式一：链式思考（Chain of Thought）—— 让Agent的推理“可视化”与“结构化”

链式思考与其说是一种严格的GoF设计模式，不如说是一种核心的推理范式，但在Agent架构中，它常常被实现为一种“模板方法”或“责任链”的变体。它的核心价值在于，强制或引导LLM将复杂的推理过程分解为一系列中间步骤，而不是直接跳跃到最终答案。

2.1 为什么需要链式思考？打破LLM的“思维跳跃”

大模型很强大，但它有时会像一個急于表现的学生，直接给出它认为最可能的答案，而跳过中间的推导。对于简单问题这没问题，但对于需要多步计算、逻辑判断或依赖上下文的问题，直接输出答案的错误率会急剧上升，且过程不可追溯、不可调试。

比如，你问一个数学Agent：“如果小明每天存10元，存了5天后花掉一半，然后又存了3天，他现在有多少钱？” LLM可能会直接输出一个数字。但用链式思考，我们会要求它：

  1. 第一步：计算前5天的总存款。10元/天 * 5天 = 50元。
  2. 第二步：计算花掉一半后的金额。50元 / 2 = 25元。
  3. 第三步：计算后续3天的存款。10元/天 * 3天 = 30元。
  4. 第四步：计算最终总额。25元 + 30元 = 55元。

在代码层面，这通常通过设计特定的提示词模板来实现，这个模板定义了推理的“步骤框架”。在更复杂的Agent系统中，每一步都可能对应一个独立的“推理子模块”或“工具调用”。

实操心得：不要指望只靠一句“请逐步思考”就能获得稳定的链式思考。你需要设计结构化的输出格式，比如要求LLM以“Thought: ... Action: ... Observation: ...”或者明确的步骤标签（Step 1, Step 2）来回应。这本质上是在为LLM的推理过程提供一个“脚手架”。

2.2 工程实现：从提示词到可执行链

在工程上，实现CoT可以有不同的粒度：

  1. 提示词工程层：这是最基础也最常用的。你精心设计一个包含分步指示和输出格式要求的系统提示（System Prompt）。许多框架（如LangChain）也提供了Chain抽象，其中LLMChain就可以通过组合提示模板和LLM来简易地实现一个单步的“思考-行动”单元。

  2. 智能体执行层：在ReAct（Reasoning + Acting）这类Agent范式中，链式思考被固化到Agent的执行循环里。Agent的每一步输出都必须遵循严格的格式，例如：

    # 一个简化的ReAct步骤格式 输出格式必须是： Thought: 我目前需要解决什么问题？我已经有什么信息？ Action: 需要调用哪个工具（或搜索）？工具的名称是什么？ Action Input: 调用工具的输入参数是什么？

    然后系统解析这个输出，执行Action，并将执行结果作为Observation反馈给LLM，开启下一个“Thought”步骤。这就构成了一条清晰的责任链。

  3. 复杂任务规划层：对于需要多智能体协作或复杂任务分解的场景，链式思考可以升级为“工作流”或“有向无环图”。例如，一个内容创作Agent，其思考链可能是：规划大纲 -> 搜集资料 -> 撰写初稿 -> 润色修改 -> 格式化输出。每一步都可以是一个独立的子Agent或模块。

注意事项：

  • 成本与延迟：链式思考意味着更多的LLM调用次数（每一步都可能是一次API调用），这会增加成本和响应时间。需要权衡任务复杂度与效率。
  • 错误累积：如果中间某一步推理出错，错误会传递到后续步骤。因此，在关键步骤加入验证机制（比如用另一个简单的LLM调用或规则检查中间结果）很有必要。
  • 灵活性 vs 可控性：严格的步骤模板提高了可控性和可解释性，但可能限制Agent处理异常或创造性任务的灵活性。有时需要为Agent设计“回退”或“重新规划”的步骤。

3. 模式二：工具使用（Tool Use）—— 扩展Agent能力的“瑞士军刀”

工具使用模式是AI Agent突破纯文本生成局限、与现实世界交互的基石。它借鉴了“适配器模式”和“策略模式”的思想，为LLM这个“大脑”装上了可操作的手和脚。

3.1 工具的本质：将自然语言意图转化为具体操作

LLM本身只能处理和生成文本。但世界不仅仅是文本。工具使用模式通过定义一套规范的接口，让LLM能够“理解”它可以执行哪些操作（如搜索网络、查询数据库、执行代码、操作文件），并通过自然语言描述来“调用”这些工具。

一个工具通常包含几个关键部分：

  • 名称：LLM用来指代它的标识符，如search_web,execute_python。
  • 描述：用自然语言清晰说明这个工具的功能、适用场景和输入输出格式。描述的质量直接决定了LLM能否正确使用它。
  • 参数模式：定义输入参数的结构（JSON Schema），帮助LLM生成格式正确的调用参数。
  • 执行函数：实际的代码实现，接收解析后的参数，执行操作并返回结果。

3.2 实现架构：注册、匹配与调用

一个健壮的工具使用子系统通常包含以下组件：

  1. 工具注册表：一个中心化的地方管理所有可用工具。这可以是一个简单的字典，也可以是一个更复杂的、支持动态加载的插件系统。

    class ToolRegistry: def __init__(self): self._tools = {} def register(self, tool: BaseTool): self._tools[tool.name] = tool def get_tools_descriptions(self): # 生成供LLM参考的工具描述列表 return [f"{name}: {tool.description}" for name, tool in self._tools.items()]

  2. 工具调用解析器：负责解析LLM的输出，识别出调用工具的意图，并提取工具名和参数。这通常需要结合正则表达式或JSON解析，并与LLM的输出格式（如ReAct格式）强关联。

  3. 工具执行器：安全地执行工具对应的函数。这里的安全性至关重要，尤其是当工具可以执行代码或访问系统资源时。必须考虑沙箱环境、权限控制和输入验证。

    class SafeToolExecutor: def execute(self, tool_name: str, arguments: dict): tool = self.registry.get(tool_name) if not tool: return "Error: Tool not found." # 参数验证和清洗 cleaned_args = self._validate_and_sanitize(tool.schema, arguments) try: # 可能在沙箱中执行 result = tool.func(**cleaned_args) return str(result) # 结果通常需要转换为文本 except Exception as e: return f"Error executing tool {tool_name}: {e}"

  4. 工具学习与选择：高级的Agent还需要让LLM学会在何时选择何种工具。这除了依赖清晰的工具描述，还可以通过少量示例（few-shot learning）或在上下文中提供类似的成功调用历史来提升效果。

踩坑记录：早期我们让Agent可以调用shell_execute工具，结果它一度想运行rm -rf /（当然被权限阻止了）。这给我们敲响了警钟：永远不要给Agent提供它不需要的、高权限的工具。工具的设计应遵循最小权限原则，并且尽可能提供功能特定、输入受限的“钝器”，而不是“瑞士军刀”。例如，与其提供一个通用的run_sql工具，不如提供get_customer_by_id、get_recent_orders这样具体的、参数化的查询工具。

4. 模式三：记忆（Memory）—— 赋予Agent“上下文”与“经验”

记忆是Agent实现多轮对话、持续学习和个性化交互的核心。它主要解决“短期上下文窗口有限”和“长期经验积累”两个问题。在架构上，它常常是“备忘录模式”和“存储库模式”的结合。

4.1 记忆的类型与存储策略

我们可以将Agent的记忆分为几个层次：

  1. 短期/对话记忆：保存当前会话中的交互历史。通常直接利用LLM的上下文窗口。当对话轮数增多，超出上下文长度时，就需要进行摘要压缩。一种常见策略是，在每次交互后，让LLM对当前对话的核心要点生成一个简短的摘要，然后将这个摘要和最新的几条原始对话作为新的“压缩后”的历史，送入下一轮上下文。这样既保留了关键信息，又节省了Token。

  2. 长期记忆：存储超越单次会话的信息，如用户偏好、重要事实、学到的知识等。这需要外部存储（数据库、向量数据库、文件系统）。长期记忆的读写不是简单的追加，而是涉及：

    • 索引：通常使用向量嵌入（Embeddings）为记忆片段创建索引，以便进行基于语义的相似性检索。
    • 检索：当需要回忆时，根据当前对话或问题，从长期记忆中检索出最相关的若干条信息，注入到当前上下文中。
    • 更新与合并：新的重要信息需要写入长期记忆。这里要处理信息去重、冲突解决（同一事实的新旧版本）和信息衰减（过时信息降权）等问题。

  3. 工作记忆：Agent在执行一个复杂任务过程中的临时状态。例如，在完成一个多步骤规划时，它需要记住当前进行到哪一步、已经生成了哪些中间结果、下一步的目标是什么。这类似于程序中的堆栈或状态机，通常通过Agent内部的状态变量或一个专门的“任务状态”对象来维护。

4.2 记忆系统的关键设计考量

实现一个有效的记忆系统，需要考虑以下几个关键点：

  • 检索质量 vs 上下文负载：从长期记忆中检索出的信息越多，LLM的上下文就越丰富，但同时也增加了Token消耗和可能的信息干扰。需要设计精妙的检索策略，例如使用“最大边际相关性”算法来平衡相关性与多样性，避免返回大量重复内容。
  • 记忆的粒度：是以整个对话回合为单位存储，还是以单个句子或事实为单位？更细的粒度便于精准检索，但管理开销更大；更粗的粒度便于整体理解，但检索可能不够精确。实践中常采用混合策略。
  • 记忆的主动性与被动性：记忆系统是只在被查询时（被动）返回信息，还是能主动在关键时刻向LLM“提醒”相关记忆？后者更智能，但实现也更复杂，可能需要一个独立的“记忆管理”模块来监控对话流并触发检索。
  • 隐私与安全：长期记忆可能包含敏感信息。必须设计明确的数据归属、访问控制和遗忘机制（例如，实现符合GDPR的“被遗忘权”）。

一个简单的向量记忆检索实现思路：

import chromadb from sentence_transformers import SentenceTransformer class VectorMemory: def __init__(self): self.client = chromadb.PersistentClient(path="./memory_db") self.collection = self.client.get_or_create_collection("agent_memories") self.encoder = SentenceTransformer('all-MiniLM-L6-v2') # 嵌入模型 def store(self, text: str, metadata: dict): # 生成向量嵌入 embedding = self.encoder.encode(text).tolist() # 存储到向量数据库，ID可以基于时间或内容生成 self.collection.add( embeddings=[embedding], documents=[text], metadatas=[metadata], ids=[f"memory_{int(time.time())}"] ) def retrieve(self, query: str, n_results=3): query_embedding = self.encoder.encode(query).tolist() results = self.collection.query( query_embeddings=[query_embedding], n_results=n_results ) # 返回相关的记忆片段 return results['documents'][0]

在实际应用中，metadata可以包含时间戳、记忆类型（事实、偏好、计划）、关联实体等信息，便于更复杂的检索和过滤。

5. 模式四：规划（Planning）与分层任务分解（HTD）—— 让Agent“谋定而后动”

面对一个复杂目标，人类不会直接行动，而是先制定计划，将其分解为更小的、可执行的子任务。对于AI Agent，规划模式就是实现这一能力的关键，它融合了“策略模式”和“组合模式”的思想。

5.1 规划的核心：从目标到动作序列

规划模式让Agent具备“前瞻性”。它不仅仅是反应式的（根据当前状态选择下一个动作），而是能构想出一系列未来的动作及其预期结果，从而选择一条最优或可行的路径。常见的规划方法有：

  1. 基于LLM的规划：直接让LLM根据目标生成一个步骤列表。例如：“目标是写一份季度报告。步骤：1. 收集销售数据。2. 分析数据趋势。3. 撰写报告摘要。4. 制作图表。5. 完成全文并校对。” 这种方法简单直接，但规划质量严重依赖LLM的能力和提示词，且缺乏对执行过程中状态变化的适应性。

  2. 经典规划算法与LLM结合：将LLM作为“世界模型”或“动作生成器”，与传统的规划搜索算法（如BFS、DFS，甚至蒙特卡洛树搜索）结合。LLM负责评估某个状态、生成可能的动作，而搜索算法负责探索动作序列空间，寻找达成目标的路径。这在游戏或模拟环境中特别有效。

  3. 分层任务网络：这是一种更结构化的方法。任务被组织成层次结构，高层任务由低层任务或原子动作组合而成。规划过程就是递归地将高层任务分解，直到所有叶子节点都是可执行的动作。LLM可以负责这个分解过程，或者判断在某个层次上该应用哪个分解方法。

5.2 工程实现：规划器与执行器的协同

在一个典型的具备规划能力的Agent架构中，通常会有一个独立的“规划器”模块：

class Planner: def __init__(self, llm, available_actions): self.llm = llm self.actions = available_actions def create_plan(self, goal: str, current_state: dict) -> List[Task]: """根据目标和当前状态，生成一个任务计划（Task列表）""" prompt = f""" 目标：{goal} 当前状态：{current_state} 可用动作：{self.actions} 请制定一个分步计划来达成目标。输出格式为JSON列表，每个元素包含‘step’和‘action’字段。 """ response = self.llm.generate(prompt) plan = self._parse_response_to_tasks(response) return plan def replan(self, original_plan: List[Task], unexpected_result: str) -> List[Task]: """当执行出现意外时，重新规划""" # 分析意外结果，调整或重新生成计划 ...

执行引擎则负责按顺序执行计划中的任务，并监控执行结果。如果某个任务失败或产生了与预期不符的结果，执行引擎会触发“重新规划”。

常见问题：规划最常遇到的两个问题是“规划幻觉”和“环境变化”。

  • 规划幻觉：LLM生成的计划看起来合理，但其中某些步骤在现实世界中无法执行（例如，计划中包含一个不存在的工具）。缓解方法是在规划阶段就进行“可行性检查”，将计划与可用的工具、资源进行匹配验证。
  • 环境变化：计划是基于对环境状态的假设制定的，但执行过程中环境可能改变，导致原计划失效。因此，Agent需要具备监控和重规划的能力。执行器需要不断将实际结果与预期对比，一旦偏差超过阈值，就暂停执行，请求规划器基于新的状态重新规划。

6. 模式五：反思（Reflection）与自我修正（Self-Correction）—— 让Agent“吃一堑长一智”

一个只会按计划执行、不会从错误中学习的Agent是脆弱的。反思模式使Agent能够评估自身的行为和产出，发现问题并进行改进。这类似于为系统增加了一个“质量评估”和“反馈循环”机制。

6.1 反思的触发时机与内容

反思不是每时每刻都在进行，那样效率太低。它通常在以下关键节点被触发：

  1. 任务完成时：检查最终输出是否满足要求。例如，代码生成Agent在写完一段代码后，可以运行单元测试或静态分析来检查正确性；写作Agent可以检查文章是否涵盖了所有要点、有无语法错误。
  2. 遇到失败或异常时：当工具调用返回错误、规划无法继续、或LLM自身产出了明显不合理的内容时，触发反思来分析原因。
  3. 周期性检查：在长周期任务中，定期暂停并评估当前进展和方向是否正确。

反思的内容可以包括：

  • 成果评估：输出是否符合既定标准（完整性、正确性、风格等）？
  • 过程评估：所采用的步骤、工具或推理路径是否高效、最优？
  • 错误诊断：如果失败了，根本原因是什么？是信息不足、工具错误、还是逻辑有误？

6.2 实现机制：批判者与修正循环

实现反思通常需要引入一个“批判者”角色。这个角色可以由另一个LLM实例扮演（有时甚至可以是同一个LLM，但使用不同的提示词），也可以是一套规则系统。

一个典型的自我修正循环如下：

  1. 生成：Agent产生一个初始输出或完成一个动作。
  2. 评估：“批判者”LLM或规则系统对输出进行评估。提示词可能是：“请从准确性、完整性和逻辑性三个方面，批判性地评估以下文本：[Agent的输出]”。
  3. 诊断与反馈：批判者生成具体的反馈意见，指出优点和缺点。
  4. 修正：原始Agent（或一个专门的“修正器”）根据反馈意见，对输出进行修改和完善。
  5. 迭代：这个过程可以重复多次，直到输出通过评估或达到迭代次数上限。
class SelfReflectiveAgent: def __init__(self, generator_llm, critic_llm): self.generator = generator_llm self.critic = critic_llm def execute_with_reflection(self, task: str, max_iterations=3): current_output = self.generator.generate(task) for i in range(max_iterations): # 评估 critique_prompt = f""" 请评估以下内容。指出其事实错误、逻辑问题、不完整之处或改进建议。 内容：{current_output} """ feedback = self.critic.generate(critique_prompt) # 判断是否通过 if self._is_satisfactory(feedback): break # 修正 revision_prompt = f""" 原始任务：{task} 之前生成的内容：{current_output} 收到的批评反馈：{feedback} 请根据反馈，重新生成一个改进后的版本。 """ current_output = self.generator.generate(revision_prompt) return current_output

注意事项：

  • 无限循环风险：如果批判者过于严苛或生成器无法达到其标准，可能会陷入无限修正循环。必须设置最大迭代次数或让批判者同时给出“通过/不通过”的二元判断。
  • 成本倍增：反思意味着额外的LLM调用，成本可能是普通生成的两倍或更多。需权衡任务重要性与此开销。
  • 批判者的质量：“批判者”本身的能力至关重要。一个弱的批判者可能发现不了问题，或者提出错误的修改建议。有时需要使用更强大的模型作为批判者。

7. 模式六：多智能体协作（Multi-Agent Collaboration）—— 构建“专家团队”

对于极其复杂的任务，单个“全能型”Agent可能力不从心。这时，可以创建多个各有所长的专用Agent，让它们通过协作共同解决问题。这借鉴了“代理模式”和“发布-订阅模式”的分布式思想。

7.2 协作模式与通信机制

多智能体系统的架构设计是关键。常见的协作模式有：

  1. 主从模式：一个“管理者”Agent负责接收用户任务，将其分解，然后分配给不同的“工作者”Agent（专家）去执行，最后汇总结果。管理者负责协调和决策。
  2. 平等协作模式：多个Agent地位平等，通过共享的工作区或消息总线进行通信。每个Agent都可以发布自己的成果或需求，其他感兴趣的Agent可以订阅并响应。这更灵活，但协调复杂度高。
  3. 辩论模式：针对一个议题，多个Agent从不同角度提出方案或论点，通过模拟辩论来逐步逼近最佳方案。这常用于决策或创意生成场景。

通信是多智能体系统的核心。Agent之间需要一种共同的“语言”或协议来交换信息。这可以是：

  • 结构化消息：定义标准的消息格式，包含发送者、接收者、消息类型（如请求、通知、查询）、内容和上下文。
  • 共享状态：使用一个黑板模型或共享数据库，Agent通过读写共享状态来间接通信。
  • 编排引擎：使用一个中心化的编排器（或工作流引擎）来严格定义Agent之间的执行顺序和数据流，例如基于LangGraph或类似框架构建。

7.3 实现示例与挑战

假设我们要构建一个产品设计评审团队，包含：产品经理Agent、UI设计师Agent、开发工程师Agent。

class DesignReviewOrchestrator: def review_design(self, requirement: str): # 1. 产品经理Agent评估需求完整性 pm_feedback = self.pm_agent.evaluate(requirement) # 2. UI设计师Agent根据需求出草案，并接收PM反馈 ui_draft = self.ui_agent.generate_draft(requirement, pm_feedback) # 3. 开发工程师Agent评估UI草案的技术可行性 dev_feedback = self.dev_agent.review_feasibility(ui_draft) # 4. 可能的多轮讨论（将dev反馈给UI，更新草案，再评审...） final_draft = self.ui_agent.revise(ui_draft, dev_feedback) final_feasibility = self.dev_agent.final_review(final_draft) # 5. 汇总结果 return { "final_design": final_draft, "feasibility_report": final_feasibility, "pm_notes": pm_feedback }

构建多智能体系统的主要挑战：

  • 协调开销：管理多个Agent之间的通信、同步和冲突解决会引入显著的复杂性。
  • 一致性与共识：如何让多个Agent对世界的认知和任务目标保持一致？当出现分歧时如何解决？
  • 系统稳定性：一个Agent的失败或异常行为可能会波及其他Agent，导致整个系统崩溃。需要设计容错和降级机制。
  • 成本与性能：N个Agent意味着N倍的LLM调用和计算资源消耗，对响应时间有直接影响。

尽管挑战重重，但对于需要多领域专业知识、创造性发散或复杂决策的任务，多智能体协作往往是唯一可行的架构选择。它的核心思想是“让专业的Agent做专业的事”，通过分工与协作突破单个模型的局限性。

8. 模式融合与实战架构设计

在实际项目中，上述模式几乎从来不是孤立使用的，而是根据需求灵活组合，形成完整的Agent架构。以一个“自动化数据分析报告生成Agent”为例，看看模式如何融合：

  1. 规划与分解：用户请求“分析上周销售数据并生成报告”。Agent首先启动规划模式，将任务分解为：获取数据 -> 数据清洗 -> 探索性分析 -> 生成洞察 -> 撰写报告。
  2. 链式思考与工具使用：在执行“获取数据”子任务时，Agent进入链式思考循环：思考需要哪些数据 -> 调用query_database工具获取原始数据 -> 观察数据格式 -> 思考是否需要进一步处理。
  3. 记忆：在整个过程中，短期记忆保存着任务分解步骤和中间结果；长期记忆（向量数据库）存储着历史报告模板、常用的分析维度，在“撰写报告”阶段被检索出来作为参考。
  4. 反思：在“生成洞察”步骤后，触发反思，用一个简单的规则检查生成的洞察是否包含关键指标（如环比、同比），如果没有，则重新分析。
  5. 多智能体协作（可选）：如果任务极其复杂，可以拆分为“数据工程师Agent”、“数据分析师Agent”和“报告撰写Agent”进行协作。

架构设计心得：

  • 从简单开始：不要一开始就追求大而全的多智能体、复杂规划系统。从一个具备基础工具使用和记忆能力的单一Agent开始，验证核心流程。
  • 明确边界与接口：将不同的功能模式模块化。规划器、工具执行器、记忆管理器、反思评估器之间应通过清晰的API接口通信。这便于单独测试、替换和升级每个模块。
  • 状态管理是核心：设计一个全局的、结构化的“Agent状态”对象。它应该包含当前目标、计划步骤、已执行动作的历史、短期记忆缓存、从长期记忆检索到的上下文等。所有模块都读写这个状态对象，这是Agent的“工作记忆中心”。
  • 可观测性至关重要：为Agent的每一步思考、每一个工具调用、每一次记忆检索都添加详细的日志。这是调试复杂Agent行为的唯一有效方法。可视化Agent的“思维链”对于理解其决策过程不可或缺。

设计模式不是银弹，而是经过验证的最佳实践蓝图。在AI Agent这个快速发展的领域，理解并灵活运用这些模式，能帮助我们从杂乱无章的提示词堆砌和临时脚本，走向可维护、可扩展、真正智能的Agent系统。最重要的不是记住这六个名字，而是理解它们背后要解决的核心问题：如何让一段文本生成模型，变得有规划、能行动、记性好、会反思、可协作。这才是架构工作的真正起点。

编程学习 学习日记 实战经验
← 返回列表