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

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

广义上的智能体系统（Agentic Systems）泛指由 LLM 驱动、具备自主推理与行动能力的 AI 系统。行业中也常将其进一步细分为两类：把遵循预定义代码路径、由 LLM 参与处理节点的系统称为智能体工作流（Agentic Workflows），而把由 LLM 动态决定执行步骤与工具调用、自主控制处理流程的系统称为智能体（Agents）。二者均可接入外部工具与数据，区别在于赋予模型的自主决策范围不同。

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

在动手构建智能体前，首先应评估任务是否真的需要智能体。正如此前 Anthropic 的工程指南所建议：优先采用能满足业务需求的最简方案，仅在确有必要时才增加系统复杂性。引入智能体虽有助于提升复杂任务的成功率，但也会显著增加响应延迟与调用成本——很多业务场景只需“单次 LLM 调用 + 检索上下文 + 少量 Few-shot 示例”即可解决。

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

同时，架构设计应遵循简单、透明、可控的原则，避免过早引入多层黑箱抽象。例如，LangGraph 等框架虽便于快速搭建图流程，但若过度封装也可能掩盖底层提示词与响应细节；因此在工程实践中，常仅用 LangGraph 编排顶层控制流，而配合 Instructor 及显式消息组装来精细控制结构化输出与错误重试，确保开发者能够清晰解释提示词与程序逻辑是如何共同决定智能体行为的。具体设计准则包括：

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

保持架构精简：采用直接清晰的工作流，每新增一个组件或循环分支都应有明确的收益支撑。
保障过程可追踪：完整记录执行计划、可观察的中间状态与详细日志，方便开发者排障并建立用户信任。
精心打磨智能体—计算机接口（Agent-Computer Interface，ACI）：像打磨提示词一样打磨工具定义与 API 接口（后续 MCP 课程将深入展开）。清晰的参数说明与防呆接口设计能让模型调用更准确、更安全，且每个工具都应经过充分测试。

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

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

以下五种可复用的单智能体工作流模式源自 Anthropic 的工程总结与行业实践，既可单独使用，也可作为构建复杂系统的基础模块：

提示词链

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

提示词链将复杂任务拆解为固定顺序的线性子任务序列，由 LLM 或工具依次处理，每一步的提示词均可接收上一步的输出作为上下文。例如撰写研究报告时，依次执行“生成提纲 → 校验提纲是否满足要求 → 逐节撰写正文 → 汇总润色”。通过让每次调用专注于更简单的单一子问题，以多次串行调用的延迟换取更高的输出质量与可控性。链条中间可插入由传统代码实现的检查关卡（Gate）——例如在生成提纲后用程序校验是否覆盖了所有必选主题，未通过时立即打回重改或直接退出流程。

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

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

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

路由

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

例如，电商助手可先区分用户是“咨询商品库存”还是“发起下单购买”：咨询类请求直接转入库存知识库 RAG 工作流，购买类请求则转入具备购物车操作工具的智能体分支。按职责分流后，各分支可使用专属提示词与工具独立调优，互不干扰。

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

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

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

并行处理

当任务的各个子部分彼此独立，或者需要对同一问题多次采样以提升置信度时，可采用并行处理模式——并发发起多个 LLM 调用，最后由聚合器（Aggregator）汇总结果。主要分为两种形式：

分区并行（Sectioning）：将互不依赖的子任务拆分并行执行。例如按章节并行生成长文档摘要、同时填写复杂表单的不同模块，或并行检索撰写报告的不同章节，最后拼接合并。
多路投票或择优（Voting / N-best）：对同一任务并行执行多次调用（或使用略有差异的提示词变体）生成多个候选结果，再通过多数投票或评判模型选出最优解。

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

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

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

在 LangGraph 中，同一阶段的多个并行节点执行完毕后会扇入（Fan-in）汇聚节点更新状态。工程上需确保每个并行分支都拿到了所需的原始提示词与上下文，并评估最终聚合步骤的开销不会抵消并行带来的延迟收益。

4. 编排器—工作者（Orchestrator–Workers）

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

它与“并行处理”的核心区别在于：子任务的数量与具体内容无法预先写死，而是由编排器根据具体输入和中间结果动态决定的。例如，代码修改智能体在分析需求后判断需要改动 5 个文件，便动态拉起 5 个 Worker 分别修改对应文件，汇总验证时若发现新问题还可继续派发新任务；深度研究（Deep Research）智能体则可根据问题复杂度动态衍生出多个不同方向的搜索子任务，收集完各路证据后再综合成文。

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

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

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

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

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

5. 评估器—优化器循环（Evaluator–Optimizer）

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

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

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

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

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

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

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

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

组合与定制模式

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

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

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

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

记忆与 Scratchpad（草稿本）

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

短期记忆（工作记忆）：保存在当前提示词上下文中的实时对话历史、过程记录与最近的工具输出，在单次任务的各轮循环间传递，会话结束后若未持久化则会释放。受模型上下文窗口上限（如 128K token）与注意力分散效应制约，短期记忆不能无休止增长：留存信息过少会丢失关键前提，留存过多则可能超限或干扰当前推理。

长期记忆：跨会话持久化保存在外部数据库、向量存储或文件中的信息（如历史已解决工单的经验摘要、用于个性化服务的用户画像偏好）。智能体通常在会话启动或推理中途通过相似度搜索等检索工具按需读取长期记忆，也可主动将新提炼的事实写入其中。

Scratchpad（中间过程草稿本）：属于短期记忆的一部分，专门用于记录当前任务的执行计划、已尝试过的动作及中间计算结果，既能防止智能体在同一问题上原地打转重复试错，也为开发者排查执行轨迹提供了可观察记录。在 LangGraph 中可通过状态字段与追踪日志记录节点输入输出，手动实现时则可将中间记录按需拼接到后续提示词中。

检索增强（RAG）与记忆的异同：部分文献也将外部向量库称为智能体的长期记忆。一般而言，RAG 侧重于检索静态或业务外部知识库，而智能体记忆侧重于保存智能体自身在过往交互中生成或收集的信息（如提炼出的语义记忆事实），但二者在底层常共用相似的向量检索接口。

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

摘要：对过长的旧对话或过程记录进行概括，压缩信息，同时注意细节丢失风险。
滑动窗口截断：仅在上下文中保留最近 NNN 轮交互原文，更早的历史记录转存至长期记忆并按需检索。
相关性过滤：当对话主题发生切换时，主动剔除与当前新目标无关的历史片段。

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

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

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

终止条件与安全措施

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

目标完成判定：单轮问答在生成最终答案后自然结束；多步任务则需在提示词或 function calling 中明确完成信号（如返回不含工具调用的普通 assistant 消息，或置位完成标志字段）。
最大迭代次数上限：根据任务复杂度设定硬性步数上限（如最多允许 5 次工具调用或 10 轮推理循环）。一旦触达上限，立即停止循环并返回当前已收集的阶段性结果、提示用户补充信息或转交兜底流程。
时间与成本熔断：设定单次任务的最大总耗时（如不超过 XXX 秒）或最大累计 token 消耗（不超过 YYY 个 token），防止长链路调用失控烧穿预算。
质量收敛条件：在 Evaluator–Optimizer 模式中，当评分达到阈值（如 9/10）、满足全部检查项或达到最大修改轮数时停止；在 Orchestrator–Workers 模式中，当所有子任务均返回结果且无需追加新任务时停止。
用户控制：用户提出新要求或要求停止时，系统应响应。每轮开始应检查新输入或中止信号。

2. 安全限制（后续课程还将深入讨论 Guardrails）

输入输出内容安全：拦截违规输入与不当输出（可在生成后串联内容审查，或利用前文介绍的并行模式同步运行合规检查）。
工具权限与沙箱隔离：不仅要在提示词中声明操作边界，更要在代码执行层强制实施权限校验与沙箱限制（例如将文件读写工具严格限制在指定沙箱目录内，严禁访问未授权的 /etc/passwd 等系统路径）。
高风险操作人工确认（Human-in-the-Loop）：涉及重要变更的复杂任务中，可要求智能体先输出执行计划并暂停等待人工确认后再实际执行（以增加一次交互耗时换取操作安全）。
全链路日志与死循环监控：实时记录每次动作决策与工具返回；当监测到异常模式（如连续发起 20 次搜索仍无实质进展）时，立即触发熔断并告警。

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

在正式上线前，智能体应先在挂载了测试账号与安全限制的受控沙箱环境（如工单系统的测试沙箱）中充分验证，并设计好优雅的失败降级方案——一旦触达限制或遇到无法自愈的错误，面向用户的系统应诚实说明限制、返回已完成的部分结果并平滑转交人工或确定性流程，切忌静默返回错误结论或无限挂起。

选择可验证的工作流

在课程企业知识问答场景中，针对常规单次提问优先采用边界清晰的“授权检索 + 结构化生成”固定工作流；仅当确需多步核对资料时，才通过 LangGraph 显式定义状态与节点。凡涉及多路并行检索知识源时，所有分支均必须传入同一个经过服务端认证的用户身份并独立执行权限校验；任一分支发生异常时，均需在状态中保留明确的错误记录。

练习：记录本课所用配置、输入、预期结果与失败分支，并用脱敏数据复现。