设计 Agentic AI 系统：真实应用如何将模式组合，而非夸大宣传
Source: Dev.to
抱歉，我无法直接访问外部链接获取文章内容。请您提供需要翻译的文本，我将为您翻译成简体中文。
概述
大多数关于 AI‑agent 模式的解释要么 过于抽象 以致难以使用，要么 过于简化 以致不够准确。
本指南旨在通过将每个模式与工程师、架构师和产品负责人已经熟悉的人类行为相结合，既 技术上精确 又 易于理解。
两种基本操作模型
在讨论代理模式之前，我们必须先明确一个几乎决定所有架构决策的区分：并非所有 AI 系统的运作方式相同。
现代基于 LLM 的系统可分为两种由 控制所在位置 定义的操作模型。理解这一边界至关重要，因为它决定了：
- 可靠性
- 安全性
- 可观测性
- 测试策略
- 治理
1. 代理工作流（代码驱动）
| 方面 | 描述 |
|---|---|
| 控制 | 工程师定义步骤顺序、分支逻辑、护栏、失败处理以及终止条件。 |
| LLM 角色 | 在特定时点被调用，以在确定性软件结构内部执行受限任务（解释、生成、分类、推理）。 |
| 执行路径 | 事先已知——一个受控的流水线，辅以概率智能。 |
| 类比 | 一个将 LLM 作为能力调用的确定性系统。 |
| 典型实现 | RAG 流水线、提示链、工具增强服务、编排工作流。 |
2. 自主代理（模型驱动）
| 方面 | 描述 |
|---|---|
| 控制 | 系统提供一个 目标、一组 工具、约束/策略，以及一个可观察的 环境。 |
| LLM 角色 | 决定 采取何种行动、使用哪个工具、如何解释结果，以及 何时继续或停止。 |
| 执行路径 | 通过迭代循环动态产生，常被描述为 Reason → Act → Observe（ReAct）。 |
| 类比 | 一个目标驱动的系统，模型在运行时决定工作流。 |
| 典型实现 | 研究代理、探索系统、编码助手、调查助手、自适应规划环境。 |
在这两种模型之间的选择会改变您设计可靠性、测试、监控和治理的方式。
- 如果代码控制流程，您通过软件工程来管理风险。
- 如果模型控制流程，您通过评估和护栏来管理风险。
Source: …
故障模式
代理工作流
| 来源 | 典型故障 |
|---|---|
| 传统工程问题 | 缺少逻辑分支、编排错误、检索结果不佳、API 失效、集成缺陷、在流程中写入了错误假设。 |
| 示例 | RAG 流程返回了错误的文档 → 导致答案错误。 |
自主代理
| 来源 | 典型故障 |
|---|---|
| 认知行为 | 模型误解目标、采取不必要的操作、陷入循环、幻觉式使用工具、做出不安全的决策、偏离原始目标。 |
| 示例 | 代理不断重复调用工具以“改进”答案。根本原因是 emergent（涌现）行为。 |
测试策略
对于代理工作流（传统软件）
- 单元测试
- 集成测试
- 回归测试
- 确定性场景（相同输入 → 相同路径）
对于自主代理（行为系统）
- 仿真环境
- 评估数据集
- 对抗性测试
- 蒙特卡罗运行（多次执行，略有变化/随机性）
- 人工审查
可观测性与监控
| 在流水线中可以记录的内容 | 在自主代理中需要监控的内容 |
|---|---|
| 步骤执行、API 响应、延迟、错误 | 推理轨迹、决策树、工具调用、记忆状态、目标进度、行动结果 |
| 你跟随流水线。 | 你监控 行为，而不仅仅是执行。 |
防护措施与政策
| 代码强制（代理） | 政策强制（自主） |
|---|---|
| 严格防护措施、审批步骤、验证检查、合规规则 | 工具权限、预算限制、行动约束、终止开关、人类监督、策略引擎 |
| 系统不能偏离。 | 系统可以在边界内进行探索。 |
可预测性 vs. 探索
| 维度 | Agentic Workflow | Autonomous Agent |
|---|---|---|
| 可预测性 | 高（可重复、可审计） | 较低（动态） |
| 典型领域 | 金融、医疗保健、人力资源、理赔、合规 | 研究、编码助手、调查、规划、发现 |
| 关键收益 | 可靠性、可审计性、合规性 | 处理模糊性、类学习行为、问题解决 |
可以这样理解：
Agentic workflow = 一列 火车 —— 安全、可预测。
Autonomous agent = 一辆 汽车 —— 灵活，能够探索新路线。
Impact on Architecture
- 复杂性 – 自主代理通常需要更复杂的编排和安全层。
- 成本控制 – 可预测的流水线更易于预算。
- 生产稳定性 – 确定性流程降低事件频率。
- 事件响应 – 调试确定性流水线相对直接；而出现的行为则需要更丰富的遥测。
- 合规姿态 – 硬编码的防护栏简化审计。
- 运营成熟度 – 团队必须相应提升测试、监控和治理实践。
许多团队低估了这种区别，事后会感到惊讶。
一句话概述
- Workflows 减少不确定性 通过设计。
- Agents 接受不确定性 以获得能力。
现代代理系统的共享原语
| 原语 | 目的 |
|---|---|
| Tools（工具） | 将推理转化为行动（API、数据库查询、计算器、代码执行）。 |
| Retrieval (RAG)（检索） | 拉取相关文档/记录并在回答前注入到 LLM 上下文中。 |
| Memory（记忆） | 在回合/会话之间持久化有用的上下文。 • 短期记忆 (STM) – 保存在提示窗口中。 • 长期记忆 (LTM) – 外部存储（向量数据库、知识图谱、个人档案库）。 |
| Collaboration mechanisms（协作机制） | 使代理能够委派任务、交换结果并编排多代理工作流。 |
传统 LLM 是什么（技术层面）
- 冻结的知识（仅在训练期间）
- 没有持久记忆（除非你提供）
- 没有动作（它只生成文本）
增强型 LLM 模式
在运行时为模型配备：
- Retrieval (RAG) – 注入相关上下文。
- Tools – 让模型调用函数、API、数据库查询、计算器、代码执行等。
- Memory – 在交互之间持久化上下文（STM + LTM）。
一个专家（医生、律师、分析师）之所以强大，并不是因为“只有大脑”。他们之所以强大，是因为他们拥有：
- 客户档案（检索），
- 实时系统（工具），以及
- 以往笔记（记忆）。
增强型 LLM 正是同样的升级：一个有办公桌的模型，而不是孤立的模型。
关键设计要点
- 检索质量是上限 – 垃圾上下文 → 自信的错误答案。
- 工具模式设计 很重要 – 明确的输入/输出契约、幂等性和错误处理是必不可少的。
- 内存管理 – 决定存储什么、存储多长时间以及如何修剪。
- 安全层 – 将硬性防护（代码）与策略引擎（行为）结合。
Durable Agent
大多数 LLM 交互都是短暂的（几秒或几分钟）。
当交互需要 跨越数天或数周 时，必须：
- 需要批准
- 能够在故障后继续运行
- 提供审计追踪
Durable Agent 将 AI 系统包装在持久化执行层中，具备以下功能：
- 在每一步后检查点状态
- 支持暂停 / 恢复
- 安全重试
- 记录完整历史
相关技术
| 类别 | 示例 |
|---|---|
| Temporal | Durable Functions、Step Functions、工作流引擎 |
| 用例 | 一个贷款审批流程，在暂停后（例如度假后）能够精确恢复 |
关键设计要点
- 幂等性 – 避免重复操作
- 模式演进 – 提前规划
- 执行血统 – 追踪以实现可审计性
模式 1 – 提示链
一个复杂任务被拆分为顺序步骤。
每个步骤：
- 执行专注的任务
- 生成结构化输出
- 在继续之前进行验证
好处
- 可靠性 – 错误被提前捕获
- 可观测性 – 每一步都可见
- 可控性 – 易于干预或修改
类比： 工厂装配线——每个站点只做一件事，而不是全部。
设计提示
- 使用验证防止错误传播
- 保持步骤输出的结构化
- 避免传递不必要的上下文
模式 2 – 迭代细化
- 生成输出
- 根据标准进行评估
- 根据反馈进行改进
- 重复，直至满意
类比： 作者 ↔ 编辑 反复起草。
指南
- 制定明确的评估标准
- 限制迭代次数
- 注意评估者偏见
模式 3 – 自主代理
| 周期 | 描述 |
|---|---|
| 决定下一步行动 | 选择接下来要做的事 |
| 执行 | 执行该行动 |
| 观察 | 收集结果 |
| 更新计划 | 根据观察细化计划 |
| 重复 | 持续进行直至目标达成 |
没有固定路径 —— 想象一名侦探在追踪线索。
治理
- 强制 行动预算
- 对风险行动 要求批准
- 记录所有内容 以便追溯
模式 4 – 并行化
独立子任务 并发 运行。两种常见模式：
- Sectioning – 将工作划分为独立的块
- Voting – 运行多个方案并挑选最佳
类比： 一个团队分工合作。
考虑因素
- 确保子任务真正独立
- 仔细设计聚合逻辑
- 监控成本激增
模式 5 – 路由（分类器 → 专家）
分类器将请求指向专门的处理程序。
类比： 医院分诊护士。
关键设计要点
- 衡量路由准确性
- 为误路由的项目定义回退路径
- 调整置信阈值
模式 6 – Orchestrator + Workers
A coordinator decomposes tasks and assigns them to specialists.
Analogy: General contractor managing trades.
设计要点
- Define worker contracts (inputs, outputs, SLAs)
- Detect and resolve conflicts between workers
- Avoid over‑fragmentation (too many tiny workers)
综合运用
这些模式是构建块，而非相互竞争的方法。在生产环境中，它们被有意层叠，每个解决不同类别的问题。
示例：法律团队的合同审查系统
- Routing layer – 对传入的文档（NDA、雇佣协议、供应商合同、监管备案）进行分类，并将其发送到相应的处理路径。
- Prompt chain per path –
- Step 1: 提取条款和元数据
- Step 2: 与标准模板进行比对
- Step 3: 生成风险摘要
- Validation 在各步骤之间进行，以防止错误传播。
- Orchestrator + Workers – 对于复杂的多方合同，专用 worker 分析赔偿、司法管辖、终止权利等，然后综合出统一的评估。
- Augmented LLM – 每次模型调用都通过检索合同库进行 grounding，并通过工具连接内部系统。
- Evaluator‑Optimizer Loop – 将输出与质量标准（完整性、准确性、风险分类）进行对比检查。
- Durable execution layer – 如果需要合作方审阅，系统会暂停，等待后再恢复，且不会丢失状态。
Result: 一个系统，多个模式，每个都提供其他模式无法提供的能力。
设计指南 – 小步起步，按需添加
| 步骤 | 何时使用 |
|---|---|
| Augmented LLM | 基础上下文、工具、基准，需要用于任何系统 |
| Prompt chaining | 任务自然可拆分为顺序步骤 |
| Routing | 不同请求类型需要不同的处理方式 |
| Parallelization | 独立工作可以提升吞吐量 |
| Evaluator loops | 必须始终如一地强制输出质量 |
| Orchestrator + workers | 问题需要多种专门视角 |
| Durable execution | 流程跨越时间或涉及人工检查点 |
| Autonomous agents | 开放式子任务，需设定明确的限制与保障 |
常见错误： 从最复杂的模式（例如自主代理）开始，而不是选择最合适的模式。自主代理在演示中很有吸引力，但会带来治理、可观测性和可靠性挑战，许多团队低估了这些问题。
经验法则： 使用最小集合的模式，以在你的问题上提供可靠性、清晰度和运营信心。