Agent 架构与多智能体
Agent 架构与多智能体
单次调用模型不难，难的是把「模型 + 工具 + 状态 + 循环」组织成稳定、可观测、可恢复的系统。本文讲 Agent 的核心设计模式（提示词链、路由、并行化、编排者-工作者、评估者-优化者、ReAct、Plan-and-Execute、反思）、记忆系统、多智能体编排、主流编排框架与 AgentOps。产品落地视角见 Agent 产品设计深度篇，框架选型清单见 框架与平台选型速查。
核心设计模式
设计模式的价值是把高频问题沉淀成可复用的结构：任务怎么拆、工具怎么选、失败怎么恢复、上下文怎么不爆炸。Anthropic 官方（Building Effective Agents）与 ReAct 论文给出了业界共识的分类。总览：
设计模式不是炫技：它们用来控制复杂度、降低失败率、提高可解释性与工程可维护性。一个成熟系统往往同时用多种模式——比如编码 Agent 用 Plan-and-Execute 生成计划，用 ReAct 循环读文件跑测试，再用工作流强制「生成 diff → 跑测试 → 人工 review → 创建 PR」的流程。
| 模式 | 一句话机制 | 适用场景 | 代价 |
|---|---|---|---|
| 提示词链（Prompt Chaining） | 固定顺序步骤链，上一步输出是下一步输入 | 可拆成可校验小段的复杂任务 | 步骤多则延迟累积 |
| 路由（Routing） | 先分类再分流到不同流程/模型 | 任务类型可区分、成本差异大 | 路由错误直接带偏 |
| 并行化（Parallelization） | 扇出-扇入或投票 | 子任务相互独立、可并行 | 并发成本与结果合并复杂度 |
| 编排者-工作者 | 主管拆任务派发给子代理并汇总 | 子任务粒度不可预知 | 主管成为瓶颈，委派要写清楚 |
| 评估者-优化者 | 生成 + 评估 + 迭代 | 有明确评估标准的生成任务 | 多轮生成，成本上升 |
| ReAct | 思考 → 行动 → 观察交替 | 需要动态获取信息的任务 | 可能陷入无效循环 |
| Plan-and-Execute | 先计划后执行，计划可修订 | 长任务、步骤可提前规划 | 初始计划可能过时 |
| 反思/自我修正 | 执行后自评并修正 | 有明确成功/失败信号 | 无外部验证时会放大幻觉 |
提示词链（Prompt Chaining）
固定顺序的步骤链，每一步的模型调用接收上一步的结构化输出，再产出下一步。典型例子：先写大纲 → 按大纲成文 → 按格式校验。适合「一个任务可以拆成多个可独立校验的步骤」的场景——每步的输出都可检查，错误在节点处就被拦截，不会一路错到底。代价是步骤多则端到端延迟与成本累积；步骤无法预先确定时不适合。
路由（Routing）
先做分类再分流：简单/常见问题路由给快而便宜的模型，复杂/罕见问题路由给强模型；或按任务类型路由给不同的专门流程。适用场景是「任务类型可区分且成本差异大」——客服首轮走快模型、深度分析走推理模型。代价是路由错误会直接带偏后续所有步骤，路由本身的准确率要纳入评测。模型间路由与模型内档位调节的细节见 模型能力与边界 的「多模型路由」一节。
并行化（Parallelization）
两种形态：扇出-扇入（把任务切成多块同时处理再合并，如同时调研三个竞品）与投票（多个独立尝试取多数结果，如代码评审多方意见）。适用场景是子任务相互独立、合并结果成本低。代价是并发调用成本与结果合并的复杂度——官方实测显示多路并行是 token 消耗上升的主因之一，合并逻辑本身也要评测。
编排者-工作者（Orchestrator-Workers）
一个主管 Agent 负责理解任务、拆解子任务、派发给工作者 Agent（每个工作者有自己的工具与提示词）、汇总结果。适合「子任务粒度无法预先确定」的复杂任务（如代码库改造：先探索再拆模块）。两个工程要点：委派要写清楚——子任务描述含糊会导致重复劳动；子代理直接写产物文件、只传引用给主管——避免「传话游戏」式的信息失真。
评估者-优化者（Evaluator-Optimizer）
一个生成器产出内容，一个评估器按标准打分反馈，循环迭代直到达标。适合「评估标准能写清楚」的生成任务：翻译、润色、代码修改、文案打磨。代价是多轮生成的成本与延迟；评估标准写不清时，循环会变成无方向的重复劳动——这时应该先人工定标准，而不是指望循环自动收敛。
ReAct（推理 + 行动交替）
ReAct（Reasoning and Acting，论文）让模型交替输出思考（Thought）与行动（Action），行动结果作为观察（Observation）再进入下一轮思考：
1 | |
它同时解决纯 CoT（只靠内部知识，容易幻觉）与纯工具调用（缺少高层推理，容易盲目搜索）的缺陷：用推理决定下一步行动，用外部观察修正推理。适合知识密集型问答、多跳检索、交互式任务。已知局限：贪心决策可能反复调用无效工具、每轮调用都增加延迟成本、长任务中 observation 挤爆上下文——需要最大步数、重复调用去重与结果摘要来兜底。
Plan-and-Execute（先计划后执行）
规划器先生成可执行的步骤计划，执行器逐步执行，失败或环境变化时由重规划器修订计划。与 ReAct 的区别：ReAct 走一步看一步，Plan-and-Execute 先整体规划再执行——更结构化，适合长任务（研究、数据分析、编码）；代价是初始计划可能过时，高度交互、每步依赖环境反馈的任务不如 ReAct 灵活。工程上通常包含 Planner / Executor / State Store / Evaluator / Replanner 五个组件，且计划、进度要持久化（见 AgentOps 一节）。
反思/自我修正（Reflection）
执行后让模型检查自己的产出并修正；进阶形态（Reflexion，论文）把失败经验写入记忆供下次尝试。适合有明确成功/失败信号的任务：代码测试失败后的修复、浏览器任务失败后的重试。反思要结构化（哪一步错了、证据是什么、下次不做什么、试什么新策略），且只在失败、低置信或高风险时触发——没有外部验证的反思容易从「纠错机制」退化成「更长的幻觉」。反思写入长期记忆前要经过质量过滤，对同一问题设置最大反思轮数，避免过度修正偏离原始需求。
搜索式推理：Tree-of-Thought 与 LATS
以上模式之外还有一类「搜索式」模式，值得了解但生产慎用：Tree-of-Thought 对每个状态生成多个候选分支并评估、回溯（适合谜题、复杂规划）；LATS 把语言模型、行动与树搜索结合，在多条行动轨迹中搜索更优路径（适合交互式环境）。共同点是「不接受第一条推理路径，生成多条并搜索」。代价是成本不可控、延迟高、需要可靠的评估函数——适合高价值低频的难题求优，不适合高并发常规请求，生产上通常限制搜索宽度与深度、用小模型初筛大模型评估。
如何选择模式
选择顺序建议：
- 先判断是不是必须 Agent（见 Agent 与工作流 的三问），能工作流就工作流
- 步骤固定且可校验 → 提示词链；任务类型可分 → 路由；子任务独立 → 并行化
- 需要动态获取信息 → ReAct；长任务且步骤可预规划 → Plan-and-Execute
- 生成质量是瓶颈且有明确评估标准 → 评估者-优化者；有明确失败信号 → 反思
- 子任务粒度不可预知、需要分工 → 编排者-工作者
- 多模式可以组合（如 Plan-and-Execute 外壳 + ReAct 内部循环），但每加一层复杂度都要评测证明收益
记忆系统
模型本身是无状态的，Agent 的连续性靠记忆系统。记忆系统解决「哪些信息应该长期保留、如何检索、如何更新、如何遗忘」，上下文工程解决「当前这一轮模型到底应该看到什么」——两者合起来决定 Agent 能否从一次性问答走向长期可靠工作。记忆分两个层次：
- 短期记忆：上下文窗口内的当前对话、最近工具结果——维持单次任务的连续性
- 长期记忆：上下文窗口之外的外部存储（向量库、键值存储、文件），保存用户偏好、稳定事实、任务经验——支持跨会话的个性化与连续任务
两者是互补关系：短期记忆解决「这一轮」，长期记忆解决「记住之后」。长上下文模型不能替代长期记忆——成本（每次全量塞入）、注意力稀释（长上下文里关键信息反而容易被忽略）、缺少结构化、缺少更新与遗忘、缺少权限隔离，都决定了「长上下文用于当前任务的高价值材料，记忆系统负责长期存储与治理」。
记忆与 RAG 的分工
容易混淆的两个概念：RAG 解决「这个问题需要查什么知识」（外部文档、知识库，低更新频率，Query-driven），记忆解决「这个 Agent 记得什么」（对话、行为、偏好、任务状态，高更新频率，Context-driven）。两者互补组合：从记忆取用户偏好与任务进度，用 RAG 查外部知识，合并进上下文，任务结束后把新的经验写回记忆。关键是把来源标注清楚——模型要知道哪些信息来自长期记忆、哪些来自文档检索、哪些来自当前用户指令，避免把不可信内容当成高优先级规则。
记忆的读写
- 写入策略：不是所有内容都值得记住。写入前过滤闲聊与临时信息，用「稳定性、复用价值、用户意图、隐私等级、来源可信度、冲突情况、作用域」判断；用户明确要求记住的、高置信的稳定事实才进长期记忆。错误记忆比没有记忆更危险。
- 检索注入：按需检索注入上下文，而不是全量倒灌。常用策略：最近 N 条、语义检索、元数据过滤（按 topic/scope/时间）、混合检索加排序；检索结果要标注来源与置信度，不能让模型把记忆当成最高优先级指令。常见错误是只用向量相似度——实际系统需要 metadata 过滤 + 混合评分 + 重排，否则容易检出语义相近但作用域错误的记忆。
- 过期与遗忘：记忆要能更新、衰减与删除——用户偏好会变、事实会过期、隐私要能擦除。常见机制：TTL、时间衰减、冲突检测（新记忆与旧记忆冲突时触发合并或确认）、版本化、用户可查看与删除。删除不只是删向量库文本，还要处理缓存、索引与备份。
长期记忆的存储架构
长期记忆通常不是单一数据库，而是多存储协同：
| 存储 | 适合内容 | 优点 | 局限 |
|---|---|---|---|
| 关系数据库 | 用户画像、记忆元数据、权限、版本 | 事务、查询、权限、审计友好 | 语义检索弱 |
| 向量数据库 | 非结构化文本记忆、摘要、经验片段 | 语义相似检索强 | 删除与权限治理需额外设计 |
| 图数据库 | 人物、项目、实体关系、依赖网络 | 关系推理与路径查询强 | 成本与建模复杂 |
| 事件日志 | 原始对话、工具调用、任务轨迹 | 可审计、可回放 | 不能直接作为高效检索层 |
原则：不要把所有记忆只存在向量库里——向量库适合语义搜索，但不擅长权限、版本、删除、审计与复杂事务。跨 Agent 复用记忆时要分域（按用户/租户/项目/角色隔离）、权限过滤、来源标注、质量审核；让所有 Agent 直接读写同一个全局向量库，是隐私泄露与记忆污染的源头。
上下文工程
上下文工程（Context Engineering）决定「这一轮模型到底看到什么」：哪些历史进上下文、哪些工具结果保留还是压缩、哪些记忆相关、接近 token 上限时如何 compact。核心动作三个：retrieve（从记忆/RAG/文件找相关信息）、assemble（按优先级拼装：系统指令与安全策略最高，当前任务目标次之，记忆与检索证据中，过期输出与闲聊最低）、compact（超预算时把低层级内容压成结构化摘要，保留恢复任务所需的关键信息）。技巧展开见 高级提示词技巧。
上下文溢出的组合治理
上下文窗口溢出是 Agent 的高频工程问题（长对话、多步循环、工具返回、日志与测试输出都是来源），解法不是单一「换长上下文模型」，而是组合治理：
- 滑动窗口：只保留最近 N 轮——简单稳定，但可能丢早期关键决策
- 摘要压缩：把旧历史压成摘要（目标、约束、已完成步骤、重要决策、失败尝试、下一步）——压缩比高，但可能丢细节
- 语义压缩/选择性保留：按语义重要性保留（多工具调用只留成功结果与关键错误、研究任务只留高置信证据）——信息密度高，但实现复杂
- 工具结果折叠：长 stdout、网页、文件内容先裁剪再摘要，保留引用位置
- 子 Agent 隔离：探索性任务交给子 Agent，主 Agent 只接收结论
目标是保证模型看到的不是「最多信息」，而是「对当前决策最有用的信息」；裁剪规则要可观测，避免重要信息被静默丢弃。
记忆对产品体验的意义
记忆是产品差异化的关键维度：同样一个模型，「记得你」的 Agent 与「每次都从零开始」的 Agent 体验完全不同——个性化（记住偏好）、连续任务（记住上次进度）、经验复用（记住什么方法有效）。但记忆也是数据安全的重灾区：跨用户串线、敏感信息长期化、恶意内容写入记忆，都需要写入前的检测与用户的查看/删除控制。记忆系统没有治理，越强越危险。
跨会话恢复：自我总结与状态恢复
长任务中断后要能续跑，靠的是结构化恢复信息，而不是重新来一遍：
- 每次长任务结束（或定期）生成 session summary：用户目标、当前进度、已完成步骤、修改过的文件、已运行命令与结果、未解决问题、下一步建议、重要约束与风险
- 计划、已完成/未完成事项、失败尝试保存为结构化状态（而不是散落在对话历史里）
- 下次恢复时先注入摘要，再按需加载历史细节
- 对项目约定与用户偏好写入长期记忆；对工具失败与环境信息保存为诊断记录
好的恢复摘要能让 Agent 在 1 次调用后接上任务；坏的摘要只写「用户让我们继续任务」，等于没有恢复。
多智能体编排
多智能体编排的目标是让多个具有不同角色、工具、记忆或权限的 Agent 协同完成任务。先回答一个根本问题：什么时候值得多 Agent？
| 情况 | 单 Agent 更合适 | 多 Agent 更合适 |
|---|---|---|
| 任务长度 | 短、单轮 | 长、可拆、可并行 |
| 工具数量 | 少 | 多且分散（不同子任务不同工具） |
| 上下文需求 | 需要共享同一上下文 | 子任务可上下文隔离 |
| 质量要求 | 常规 | 需要互相审查、多方验证 |
| 权限隔离 | 无特殊要求 | 不同子任务需要不同权限 |
一句话：多 Agent 是组织结构设计，不是 Agent 数量越多越先进。组织结构设计不好，人多反而更乱。
分工模式
多智能体（Multi-Agent）的编排本质是组织结构设计，常见模式：
- 主管-员工（Supervisor）：一个上级 Agent 拆任务、协调下级、汇总结果——控制强，适合复杂项目；风险是主管成为瓶颈。
- 辩论（Debate）：多个 Agent 提出不同观点，由评审（judge）决策——可提升复杂判断质量；成本高，可能互相强化错误。
- 投票（Voting）：多个独立 Agent 各自完成再取多数/最优——适合有明确优劣判断的任务。
- 市场竞价（Market/Bidding）：Agent 根据能力声明竞争任务——灵活，但可控性与调试难度最高。
实际工程里最常见的是主管-员工、路由与团队模式，因为它们可控、可观测、容易落地。模式速选表：
| 模式 | 核心思想 | 优点 | 风险 | 适合场景 |
|---|---|---|---|---|
| 主管-员工 | 上级拆任务、协调下级 | 控制强 | 主管成为瓶颈 | 复杂项目、研究报告 |
| 路由 | 按任务类型分发 | 简单高效 | 路由错误带偏 | 客服、意图分发 |
| 辩论 | 多方观点 + 评审决策 | 提升复杂判断质量 | 成本高、互相强化错误 | 高价值决策、方案评审 |
| 投票 | 独立完成取多数 | 结果稳健 | 成本 ×N | 有明确优劣判断的任务 |
| 市场竞价 | 按能力声明竞争任务 | 灵活 | 可控性、调试难 | 开放探索型任务 |
协作通信：直接传消息 vs 共享黑板
- 直接传消息：Agent 之间显式发消息/传引用——链路清晰、可审计，适合角色边界明确的协作
- 共享黑板（Blackboard）：多个 Agent 读写共享工作区——适合探索性协作，但容易互相污染上下文
工程建议：给每个 Agent 独立上下文；子 Agent 把产物写入文件系统、只传引用给主管；对写文件、发消息、执行命令等副作用操作设置单一责任人。通信越结构化，错误越容易定位。
可持久化、可恢复的编排
多 Agent 长任务必须把运行过程从「临时对话」变成「状态机」，四个关键设计：
- 显式状态：记录任务目标、当前步骤、已完成步骤、失败原因、待审批项、工具结果摘要
- 节点化执行：流程拆成 plan / execute / evaluate / human_review / replan / finalize 等节点，每个节点完成后持久化状态
- 可重试与幂等：区分只读与副作用工具；副作用操作需要幂等键（idempotency key），重试不产生重复副作用
- 人工介入：高风险节点进入审批（approve / reject / edit / abort），Agent 挂起等待而不是超时失败
LangGraph 这类图编排框架的价值正在于此：把复杂编排变成可持久化、可中断、可恢复、可观测的图状态机，长任务不因一次故障从头再来。
多 Agent 的代价
多 Agent 不是免费的：成本 ×N（官方实测多 Agent 系统 token 消耗约为普通对话的 15 倍）、不一致（角色之间互相矛盾、错误跨 Agent 传播）、调试难（上下文重复、信息丢失、问题难以复现）。社区实测也印证了这一点：有团队复盘自研的 7-Agent 研发流水线，结论是链路冗余、职责边界模糊——多 Agent 的「传话游戏」会让信息失真，子 Agent 产出经转述后丢失细节，因此官方建议「让子 Agent 直接写产物文件、只传引用」。结论：先单 Agent，多 Agent 只在评测证明收益时上。适合多 Agent 的场景：任务天然可拆、需要并行探索、需要互相审查、不同子任务需要不同权限；不适合：需要共享同一上下文、Agent 间强依赖的任务。
编排框架概览
主流框架一句话定位（详细清单与选型建议在 框架与平台选型速查，本页不重复）：
- LangChain / LangGraph：LangGraph 把工作流建模为有状态图（节点 = 步骤，边 = 控制流），支持持久化 checkpoint、断点续跑、人工中断，适合复杂、长时、需恢复的工作流；LangChain 是上层 Agent harness（Agent = Model + Harness）。
- CrewAI：以「团队 + 角色 + 任务 + 流程」为核心的多 Agent 协作框架，适合角色分工明确的业务流程。
- AutoGen / AG2：多 Agent 对话与协作框架，适合研究型多 Agent、代码协作与模拟讨论。
- OpenAI Agents SDK：轻量框架，原语少（Agent、Handoff、Guardrails、Tracing），与 OpenAI 生态绑定深。
- LlamaIndex：数据连接与 RAG 导向，适合知识库问答与文档 Agent。
- Google ADK：Google 生态的 Agent 开发工具包，原生支持 A2A。
选型建议：框架解决的是工程问题（状态、恢复、观测），不解决「模型聪不聪明」；「demo 用平台、产品化用代码」是常见路径，核心编排逻辑保持薄层隔离以保留迁移余地。五类框架按工程定位区分：通用 Agent SDK（OpenAI Agents SDK）、图式状态机（LangGraph）、多 Agent 协作（CrewAI、AutoGen/AG2、Google ADK）、知识型/RAG 框架（LlamaIndex）、编码 Agent 产品（Claude Code、Codex 等——注意它们是「Agent 产品」而非通用编排框架）。选型时还要注意框架的更新速度：教程与第三方文章容易过期，一切以官方文档为准。
框架与产品的关系
框架 ≠ 产品：demo 跑通后，产品化还需要权限、监控、灰度、计费、多租户等框架之外的工程；「demo 能跑」与「产品可上线」之间隔着完整的工程化补齐。选择框架时还要问三个问题：团队能否维护（框架更新快、教程易过期）、换模型是否灵活（跨厂商接口可降低绑定）、编排逻辑是否与框架 API 解耦（保留迁移余地）。另外要分清「通用编排框架」与「编码 Agent 产品」：前者是开发工具，后者是面向用户的成品。
AgentOps
Agent 上线后的运营体系，比 MLOps/LLMOps 多了「行动」维度：LLMOps 管「模型怎么被调用」，AgentOps 管「智能体如何在真实环境中行动并被治理」。对比：
| 概念 | 关注点 |
|---|---|
| MLOps | 模型训练、部署、数据版本、特征、监控 |
| LLMOps | 大模型调用、Prompt、RAG、评测、成本、延迟 |
| AgentOps | Agent 任务、工具调用、权限、轨迹、状态、人工接管、事故响应 |
AgentOps 需要额外管理：Agent/Prompt/Skill/工具版本、工具权限策略、会话与任务状态、工具调用 tracing、人工审批、后台任务、多 Agent 调用链、记忆写入与使用、失败样本回流、灰度发布与回滚。四个支柱：
可观测性：trace 每一次推理与工具调用
记录：用户输入、系统指令版本、模型调用参数与输出、工具调用名称/参数/结果/耗时、handoff 事件、guardrail 结果、权限审批记录、token 与成本、错误与重试。目标是能回答三件事：失败为什么发生（复现）、成本花在哪（归因）、有没有越权（审计）。没有 trace 的 Agent 无法上线。
trace 的三个典型用途：调试（复现「为什么选错工具」、回放失败案例）、成本分析（每任务成本归因、缓存命中率）、评测数据构造（失败样本回流成评测集、注入攻击回放测试）。主流 SDK 与框架普遍内置 tracing（如 OpenAI Agents SDK、LangSmith），上线前接入是硬性要求而不是可选项。
评估：任务成功率、步数、成本、工具错误率
Agent 评测不能只看最终答案，生产环境至少跟踪六类指标：
| 类别 | 指标 |
|---|---|
| 任务成功 | 任务成功率、pass@1、pass@k、完成率 |
| 过程质量 | 工具选择准确率、参数准确率、重复调用率、轨迹合理性 |
| 安全合规 | 越权率、注入成功率、敏感泄露率、误拒率、误放率 |
| 可靠性 | 多次运行稳定性、失败恢复率、断线恢复率 |
| 成本性能 | token 用量、工具调用次数、延迟、费用、缓存命中率 |
| 人机协作 | 人工审批次数、人工接管率、review 通过率 |
一个生产级 Agent 不能只报「任务成功率 80%」，还要回答：剩下 20% 怎么失败的？成功的任务过程是否合规？平均成本多少？能否稳定复现成功？是否依赖大量人工介入？方法论见 评估与评测；公开基准（SWE-bench、WebArena、τ-bench 等）只能做初筛，生产必须自建业务评测集——「以正确方式完成任务」比「完成任务」更重要，对会改变状态的 Agent 要评测「终态」而非逐轮打分。
安全护栏
输入、输出、工具、状态四类边界：输入检测恶意请求与注入；输出检查敏感泄露与违规内容；工具检查权限与参数范围（工具边界是最关键的一层——工具一旦执行，副作用已经发生）；状态防止错误记忆写入与跨用户串线。实现手段：规则、分类器、小模型、LLM-as-Judge、策略引擎与人工审批的组合。
版本与灰度
提示词、工具定义、模型版本都是会改变行为的产品资产：进版本管理，变更走灰度（按用户/租户/任务类型），灰度期间对比任务成功率、成本与人工接管率，异常即回滚。对会改变状态的 Agent，上线前跑「终态」评测（结果状态是否符合预期），而非只评逐轮文本。灰度放量顺序建议：影子模式（shadow，只记录不执行）→ 小流量只读 → 受控写入 → 全量。
事故响应与审计
Agent 事故（误操作、越权、成本失控）要有预案：能暂停 Agent、回滚策略版本、还原 trace、撤销副作用（补偿操作或人工恢复流程）、补充回归评测。审计体系记录「谁在什么时候让 Agent 做了什么」的完整调用链——这是责任划分与安全事件响应的基础。
产品落地与边界
设计要点
Agent 产品的设计要点（权限最小化、确认节点、进度可见、失败兜底、成本预算、可观测性）展开见 Agent 与工作流 与 Agent 产品设计深度篇；权限、护栏、恢复、可观测性的设计评审清单也在那里。技术边界之内，产品决策的核心是：先工作流，再单 Agent，评测证明收益后再多 Agent——这是官方原则，也是成本最低的路径。架构评审时可以对照「设计评审清单」（权限、护栏、恢复、成本、可观测性、评测、信任基线）逐项过，缺一项就说明架构还没有闭环。
长程任务成功率的现状与预期管理
- 复杂长程任务的成功率仍有限，且错误会有状态地累积——第 10 步的错误会污染第 20 步的决策
- 真实产品普遍是「工作流 + 人工复核」，全自动无人值守仍是少数
- 对用户承诺要保守：Agent 是「加速器」不是「许愿机」，验收标准与人工兜底路径要写进产品说明
- 上线前用真实数据压测：演示场景可控，真实场景千变万化；Agent 反复尝试同一失败路径时如实展示，不要伪装成正常执行
常见坑
- 过度自主：目标太大、工具太多、约束太少，计划无法收敛——把大任务切成可验证的小任务，让 Agent 在明确边界内自主解决局部不确定性
- Demo 陷阱：演示环境跑通就上线——真实数据、真实权限、真实副作用都不同
- 没有验证闭环：Agent 产出的报告没人核对，比没有更糟——「无法验证的改动不要上线」
- 框架掩盖底层：出问题时无从下手——先用 LLM API 起步，用框架前先读懂它
- 跳过评估：没有评测基线就放大代理权——信任额度 = 评测证据
- 多 Agent 炫技：单 Agent 能解决的硬拆成多 Agent——成本 ×N 只换来协调复杂度
- 忽略上下文预算：上下文塞满才想起压缩——上下文工程要在架构里提前设计，而不是出问题再补
- 不设停止条件：循环没有最大步数与预算上限——成本失控与死循环只差一个参数
未来方向
以官方信息为准的一句话展望：自进化 Agent（从任务轨迹沉淀经验为记忆、Skill 与策略，由 Curator 评分、合并、归档、回滚）与多平台运行时（Agent 跨 Web/IDE/桌面/移动端持续运行）是两个明确方向；前者要解决「可审计、可回滚的知识资产维护」，后者要解决「跨平台的权限与状态同步」。自进化的边界设计尤其重要：经验只能写入可审计、可回滚的知识资产（记忆、Skill、策略、评测样本），不能允许 Agent 随意改自己的行为策略——否则一次错误经验会污染所有后续任务。趋势会变，但「评测先行、边界内自主」的原则不会变。
给产品经理的架构速记
评估一个 Agent 架构是否健康，看三件事：循环有没有停止条件（最大步数、预算、超时）、状态有没有持久化（断点能续跑）、行为有没有 trace（失败能复现）。这三样齐了，再谈模型选型与模式选择。
练习
给「自动生成行业调研报告」选一个主模式：先判断用 ReAct 还是 Plan-and-Execute，说明理由；再设计它的记忆（哪些进短期、哪些进长期）、是否值得多 Agent、上线需要哪些 AgentOps 指标。
来源说明
本文为原创整理，结论均引用以下权威来源，访问验证日期 2026-08-23：
- Anthropic — Building Effective Agents：五类工作流模式、编排者-工作者与评估者-优化者的工程要点。
- ReAct 论文：推理与行动交替的机制与局限。
- Reflexion 论文与 Plan-and-Solve 论文：反思与计划模式（视需要引用）。
- Anthropic — How We Built Our Multi-Agent Research System：多 Agent 成本量级（15 倍 token）与编排实测。
- LangGraph 官方文档与 OpenAI Agents SDK：框架定位（以官方为准）。
- AIGC-Interview-Book《AI Agent 基础》系列（预取内部参考）：记忆生命周期、上下文工程、AgentOps 与多智能体编排模式。
发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用