构建智能体系统的架构模式

一般而言，Agentic Systems 指能够由 LLM 自主推理和行动的 AI 系统。近期也有人尝试用这一术语特指较确定的 Agentic Workflows，并将 Agentic AI 用于多智能体自主系统。本课专注单个智能体设计，多智能体交互将在后续讨论，重点是简单、可靠、有效的工作流。成功实现通常采用可组合的简单模式，保持架构易于理解。我也认同这一点：虽然完全自主的多智能体系统可能是未来方向，可靠构建仍有挑战。本课介绍这些简单模式及其架构原则。

Agentic Workflows 由 LLM 驱动，但遵循预先定义的代码路径；智能体则让 LLM 动态决定行动与工具使用，控制自身处理过程。两者都可以结合工具或外部数据，智能体交给模型的决策自主范围更大。

有效智能体系统的设计原则

构建前，应判断任务是否需要智能体。Anthropic 的指南建议采用能够满足需求的简单方法，只有必要时才增加复杂性。智能体可能提高任务成功率，同时增加延迟与成本，其收益应足以支持这些开销。许多应用只需单次 LLM 调用，结合检索和少量上下文示例。需要判断：直接的检索增强提示词是否已经可以解决问题？

需要动态决策、工具使用或无法预先固定的多步骤推理时，可以选择固定工作流，或让智能体拥有更大自主性。工作流通过明确逻辑提供可预测性和一致性；智能体通过模型选择路径提供灵活性与适应能力。任务清楚时可采用结构化工作流，开放式任务的步骤无法预定时，自主智能体更有价值。

另一个原则是简单设计。过早加入多层抽象可能造成问题。LangGraph 等框架便于构建原型，也可能隐藏提示词与响应细节，令开发者看不清模型实际行为。这也是本课仅用 LangGraph 管理流程，同时使用 Instructor 处理结构化输出与重试、手动组织消息的原因之一。框架封装了具体模式，理解其内部机制仍然重要。你应当能够解释提示词与程序如何共同决定智能体行动。

设计需要保持简单、透明、可控，并用结果证明额外复杂性确有价值。Anthropic 的建议包括：

保持简单：选择直接清楚的工作流，每个新增组件或循环都应有明确用途。
保证过程可追踪：记录计划、可观察的中间结果和详细日志，使开发者和模型都能了解任务进展，支持调试与信任。
认真设计 agent-computer interface（ACI）：像设计提示词一样认真设计工具和 API。清楚文档和易用接口让调用更容易、更安全。后续 MCP 课程会继续讨论；目前应让工具用途对模型足够明确，并充分测试每个工具的使用。

这些原则有助于同时提高能力、可靠性、可维护性和可控性。

常见的单智能体工作流模式

以下介绍五种可复用架构，让主要负责推理的 LLM 结合工具与记忆完成任务。这些模式来自 Anthropic 的相关文章与行业实践，也可作为更复杂系统的组成部分。

提示词链

Prompt Chaining 将复杂任务分为线性子任务，由 LLM 或工具依次处理。例如，生成有研究依据的报告时，先生成提纲，再验证要求，然后逐节撰写，最后汇总。每一步的提示词都可包含前一步输出，沿处理链传递上下文。

每次模型调用专注较简单的子问题，可能提高准确性。它以多次调用的延迟换取可靠性或质量，适合具有清楚阶段、或需要中间验证的任务。图中的 gate 表示程序检查或验收条件，例如生成提纲后检查是否覆盖所有主题；不符合时，可以修改提纲或终止流程。

适用情况：所有输入都应经过稳定的子任务顺序，例如带评审的内容生成、多阶段数据处理，或需要系统化完善答案的任务：

分阶段写作：先起草，再概括，再翻译。
复杂问答：先提取问题或文档中的关键实体，再查询知识库，最后组织答案。
验证流程：LLM 生成代码，另一个模型或工具测试，再由模型修复错误。

提示词链具有模块化特点，每一步可以独立开发和测试。LangGraph 中可将各子任务定义为节点，再连接为图；节点也可以仅运行普通代码。这类模式路径预定，主要属于工作流，同时展示了输入与输出如何流动，为更灵活模式提供基础。

路由

不同输入可能需要不同处理。Routing 先分类请求，再将其送到相应专用流程或提示词。最初的路由步骤可以由 LLM 或普通程序逻辑完成，在后续多个处理链或工具中选择。

例如，助手同时处理库存咨询与购买意图。查询型问题可以送到库存知识库工作流；购买型请求可以进入能够管理购物车的智能体系统。按职责划分后，每类请求使用专门提示词与工具，各自优化，减少相互干扰。

适用情况：任务种类不同、单一方案无法同时做好时。如果提示词为了覆盖大量场景而过于复杂，可以分开处理逻辑。路由可以使用 LLM 分类，例如“该输入属于 A、B 还是 C？”，也可以使用正则表达式或模型置信度阈值。

客服系统分别处理库存、评价和投诉。
按难度选择模型：简单问题使用便宜、快速的模型，困难问题使用更强模型，或专门针对困难问题微调的模型。我见过多个系统从中获益。
先判断一般问题能否直接回答，是否需要额外智能体能力，再选择预定工作流。

架构中，路由是让图产生分支的初始节点；LangGraph 可以用条件边表达。各分支可独立开发和调优，也更容易预测某类输入会触发哪些组件。前提是初始分类可靠，否则请求会进入错误流程。因此应认真设计分类标准，必要时加入置信度检查，无法判断时交给人工或默认流程。

并行处理

任务各部分相互独立时，可以同时处理；也可以对同一任务进行多次尝试，提高置信度。Parallelization 并发运行多个 LLM 调用，再聚合结果，常见两种形式：

分区处理：将独立子任务并行执行。例如，长文档按章节分别生成摘要，复杂表单的不同部分同时填写，或报告各节并行研究与写作，最后合并。
投票或 n-best：同一任务多次执行，或略微调整提示词，生成若干候选。再通过多数投票或评判模型选择。例如，对重要问题调用三次，再比较结果。

并行处理以计算资源换取速度或置信度。互不依赖的步骤同时运行，可以减少总延迟，组合多个结果也可能提高质量。但需要可靠聚合：连接章节摘要较简单，合并不同答案可能需要评分函数或最终评判模型。

适用情况：子任务独立或可以变成独立任务，或者需要多个角度：

AI 安全检查：一个模型回答，另一个模型或程序同时检查问题或草稿是否合规。两者完成后，只在检查允许时返回答案，往往比让同一个模型同时承担两项职责更有效。
LLM 评估：多个模型分别按准确性、清晰程度、礼貌等标准评分，再聚合。
多角度构思：并行提出不同解决方案，选择最佳或组合，形成自动的发散思考过程。
冗余验证：重要计算执行两次并比较；结果不一致时，说明存在不确定性。

实现时可以并发调用工具或 LLM。LangGraph 中，同一阶段的多个节点随后汇合，将结果写入状态，再由后续节点汇总。需要确保合并开销没有抵消速度收益，并让每个分支都获得必要的原始提示词或相关数据。

Orchestrator–Workers

这一模式由协调 LLM 动态划分任务，再把子任务分配给 worker 调用，最后汇总。中央智能体实时规划和分配工作，处理过程根据输入与中间结果调整。

与固定提示词链或预定并行分工相比，关键在于子任务数量与内容事先未知。例如，编码智能体分析功能需求后，判断需要修改五个文件，便启动五个 worker 分别处理。完成后，再整合和验证；测试发现新问题时，还可创建新任务。

研究智能体也可以根据问题发起多个搜索任务，每个关注一个方面，收集结果后再形成综合答案。

编排器与工作Agent — 编排器安排多个工作分支，综合器汇总各分支完成的结果。

适用情况：无法提前预测子问题，或每次输入需要不同分工的任务。编码任务涉及的文件与函数数量不断变化；开放式搜索和分析需要的来源数量也不固定，都适合这种模式。

这可以理解为层级智能体：一个协调角色与多个辅助角色，可能使用相同模型。本课仍把协调器视为主要智能体，它通过组织多个 LLM 调用完成工作。LangGraph 中可以让协调节点决定下一步，为子任务运行子图，再收集结果。一个清楚的两层实现可以包括协调调用、一定数量的 worker，以及最终综合调用。

重要挑战是让 worker 获得准确指令。协调器需要为每个 worker 生成清楚的任务说明、角色与输出格式，这本身就是规划与提示词设计。它带来灵活能力，也增加编排复杂性和故障追踪难度，因为多个调用都可能出错。必须记录各 worker 的输出与协调决策。

Evaluator–Optimizer 循环

这一模式至少包含两个 LLM 角色：一个生成初步答案或方案，另一个评估并提出反馈，生成角色再据此改进。上一周内容已涉及其中大部分方法。它类似作者与编辑之间的合作。

例如，模型先回答问题，另一调用按准确性、完整性、风格等标准检查，指出错误或缺失，然后再次修改。可以迭代多轮，直到满足质量条件，类似写作中使用 Grammarly 或同行评审改善文本。

评估器与优化器循环 — 生成器提交候选方案，评估器通过时输出结果，未通过时返回反馈以继续改进。

适用情况：具有明确评估标准，或迭代修改能够带来价值的任务，尤其是初次结果常需完善、且能定义何为更好的场景：

复杂写作与翻译：先翻译，再检查是否保留含义与细微语气，随后修改。
研究与事实查找：搜索并回答后，评估证据是否充分，不足时继续检索。
编码：一个模型写代码，另一个评审或运行测试，再根据问题修复。

这种模式要求模型能够有效评价输出。它可以看作增加了批判性反思步骤的推理过程。

实现时，solver 先产生结果，evaluator 接收原始输入与结果并生成反馈，再将反馈与上一轮输出送回 solver 修改。必须设置终止条件，例如固定轮数，或评估器确认满足标准，防止评估器不断提出问题而无限循环。

反馈必须具体、可理解、可执行。“这个答案不好”一类模糊评价没有帮助；过严或错误的评价甚至会降低质量。评估器提示词应强调建设性和具体要求。

组合与定制模式

这些模式可以组合。例如，路由后的一个分支采用提示词链，另一个采用评估循环；自主智能体也可在动态工作流中插入固定处理链或评估步骤。

LangGraph 和一般工作流引擎便于表达分支、循环与汇合。手动实现时，也可以为不同模式编写独立函数，再按需要调用。模块化使各部分能够先独立开发和测试，再进行集成。

每个新增模式都应有可测量的作用。例如，固定链输出质量波动时，可以加入并行投票；最终答案经常存在可识别错误时，可以增加评估循环。通过测试确认各项组合是否确实改善结果。

可以把这些模式看作组成工作流的基本单元，按照任务需要组合。

记忆与 Scratchpad

记忆影响智能体如何保留信息，以及后续行为的一致性，主要形式包括：

短期记忆：当前提示词上下文中的用户对话、过程记录和最近工具输出，在循环之间传递。会话结束后，未保存到外部的信息便消失；其大小受到模型窗口限制，例如 128K token。设计时要决定保留、概括和删除什么。上下文太少会遗漏细节，太多则可能超限或分散对当前任务的注意。

长期记忆：跨会话保存，或无法放进单次提示词的信息，通常位于数据库、向量存储或文件。例如，保存已解决问题的摘要，以便类似问题出现时使用；保存用户信息以支持个性化。智能体通过检索工具读取，也可能主动保存新内容。常见方式是维护向量化记录，在会话开始或需要时进行相似度搜索，取得相关历史。

Scratchpad：中间过程记录。它属于短期记忆，可保存计划、行动和中间结果。记录已经尝试的方法，可以减少重复；保存计算过程或阶段成果，便于继续任务；保留可观察的执行轨迹，也有助于开发者定位问题。构建时应明确如何保存并传递这些状态。LangGraph 配合追踪工具可以记录节点输入输出；手动实现则可累积过程文本，并将需要的信息加入后续提示词。

检索增强与记忆：术语存在交叉，有人把向量数据库也称为长期记忆。RAG 通常检索外部知识，记忆则常保存智能体此前生成或遇到的信息。两者都通过相关内容扩展上下文，也通常使用相似的搜索或查询接口。检索常用于语义记忆，也就是提取并保存的重要事实和结论，无需保存全部原始对话。

记忆管理：短期容量有限，可以采用：

摘要：对过长的旧对话或过程记录进行概括，压缩信息，同时注意细节丢失风险。
窗口限制：仅保留最近 N 次交互的原文，较早内容需要时从长期记忆获取。
相关性过滤：只保留当前目标需要的信息。主题变化后，可以移除不再相关的内容。

这些策略可以自动或人工执行。例如，加入“概括目前完成的工作”步骤，再用摘要代替较长的过程记录。

工作记忆限制与错误：智能体有时忘记早先细节或出现前后矛盾，原因可能是上下文限制或模型能力。重要信息在推理时没有进入提示词，模型便无法利用它。应确保关键事实与决定持续传递。例如，用户在第 1 条消息提出重要要求，第 20 条消息才再次用到，应确保它仍在短期上下文中，或已保存并正确检索。长会话测试有助于发现问题。

例如，客服智能体处理长时间故障排查时，短期记忆保存当前对话，长期记忆保存客户资料或过去问题，Scratchpad 记录已尝试的步骤，减少重复尝试。同一问题持续较久时，可以概括“已检查 X 和 Y，仍未解决”，同时帮助模型和用户了解进度。记忆使智能体具有状态，能够持续处理问题。

终止条件与安全措施

智能体需要明确停止条件，防止无限循环或过早结束；执行中还应有安全措施，限制不希望出现的行为。

目标完成：回答问题或完成任务后停止。单轮问题通常以最终答案作为结束；多步骤任务应明确完成标准。提示词可以要求模型确认任务完成后给出最终答案。使用 function calling 时，普通 assistant 消息通常表示无需继续调用工具。
最大迭代次数：根据任务复杂程度设置上限，例如 5 次工具调用或 10 轮推理。达到上限时，给出已有结果、请求帮助或交由其他方式处理。它通常意味着系统未能顺利推进，具体数值需要调节。
时间与成本限制：设置总耗时或 token 上限，例如超过 X 秒或 Y 个 token 时停止。长期运行、使用昂贵模型的智能体尤其需要监控成本。
质量与收敛条件：Evaluator–Optimizer 可在达到固定轮数、评分为 9/10 或所有标准满足时停止。Orchestrator–Workers 则可以检查所有子任务结果，判断是否还需继续。
用户控制：用户提出新要求或要求停止时，系统应响应。每轮开始应检查新输入或中止信号。

安全限制：后续第 7 周会进一步讨论 guardrails。主要包括：

内容安全：检查输入和输出，防止产生不允许的内容或行动。例如，生成后检查禁止内容类别，或并行运行合规监控。
工具使用限制：文件工具可以限制在沙箱目录。工具实现应执行权限检查，例如禁止访问未授权的 /etc/passwd。提示词应说明边界，系统也应在程序层强制执行。
人工监督节点：复杂任务中，可以让智能体提交计划并等待确认。这样有助于信任，同时增加交互与耗时，应根据场景选择。
日志与监控：记录行动、决定和可观察结果，方便发现异常与重复循环。例如，连续搜索 20 次仍未进展时，可以终止过程并调查。

广泛部署前，应在受控沙箱中测试，并启用安全限制。例如，在工单系统的测试环境中使用测试账号，使错误操作不会带来严重后果。确认行为符合预期后，再扩大使用范围。

还应设计失败后的处理方式。达到限制或遇到无法解决的错误时，面向用户的系统可以提供部分结果、说明限制并转交人工或更简单的系统；后台任务则可以触发告警。可靠系统需要以安全、清楚的方式结束失败，避免默默产生错误结果或无限等待。明确终止条件与安全措施，能够让单个智能体始终处于可控范围。