Agent 与工作流

Agent 与工作流

Agent（智能体）是当前 AI 产品的核心范式：从「回答你的问题」到「帮你把事情做完」。大模型解决了「会说话」，Agent 要解决「会做事」——围绕一个目标，自主地感知环境、调用工具、执行动作、观察反馈，直到任务完成。本文介绍 Agent 的基本机制、工作流与 Agent 的边界、常见架构与产品设计要点；工具调用与 MCP 协议的机制细节见 工具调用与 MCP，架构模式与多智能体编排见 Agent 架构与多智能体。

什么是 Agent

Agent = LLM + 工具 + 循环决策。与普通对话相比，Agent 能：

• 调用工具：搜索、读文件、操作软件、调 API
• 自主规划：把大任务拆成子任务，决定执行顺序
• 感知结果：执行一步后看结果，再决定下一步
• 循环执行：直到任务完成或达到终止条件

大模型是 Agent 的大脑，工具是手脚，记忆是上下文连续性，规划是任务分解，权限与评估是工程落地的刹车系统。理解 Agent 的前提是分清「模型」与「Agent」：模型是单次推理能力，Agent 是围绕目标持续行动的系统。

感知-规划-行动-反思循环

把 Agent 的运行展开看，是一个持续的循环：

工程上的典型流程是：用户提出目标 → 系统构造上下文（指令、历史、记忆、工具列表、环境状态）→ 模型生成下一步（回答、工具调用或计划更新）→ 工具执行器执行动作 → 系统收集工具结果 → 模型根据结果继续推理 → 达到停止条件后输出最终结果。

停止条件是循环设计里常被忽略的一环，没有停止条件的 Agent 会无限烧 token。常见停止条件有：

• 任务完成，输出最终结果
• 达到最大轮数/最大步数
• 达到预算上限（token 数或金额）
• 工具失败且不可恢复
• 需要用户授权或补充信息（挂起等待，而非失败）
• 触发安全策略

一个具体的例子：用户让 Agent「调研三款竞品的定价策略」。Agent 先规划为「搜定价页 → 提取数字 → 对比汇总」，然后循环执行：调用搜索工具（行动）→ 拿到网页摘要（感知）→ 判断信息是否足够（反思）→ 不够就换关键词再搜（规划）→ 信息齐了输出对比表（终止）。整个过程模型自主决定每一步，但每一步的权限与预算由产品预先设定。

与普通对话的本质差异

普通对话是「一问一答」：模型接收输入，输出文本，应用层只负责展示。Agent 的关键差异在于模型主动决定下一步——它不只是回答，而是可以选择调用某个工具、改变计划、请求澄清，甚至主动停止。差异可以归纳为四点：

• 控制权转移：执行路径不再由代码预先写死，而由模型按上下文动态决定。工作流是「代码调度模型」，Agent 是「模型调度工具」。
• 有真实副作用：工具调用可能发消息、改数据、花钱，错误代价从「说错」升级为「做错」，安全边界比普通聊天产品重要一个量级。
• 有状态：多步任务需要记住中间进度、已尝试的路径与失败原因，不能每次从零开始；长任务还要跨会话恢复。
• 需要边界：没有权限、预算与停止条件约束的 Agent 会失控。自主度是产品光谱而非开关，要从辅助、半自主逐步放到全自主。

Agent 循环的工程实现

把上面的循环落到工程上，需要四个组件配合：

• 模型调用层：把当前上下文（系统指令、历史、工具结果、记忆）打包发给模型，并解析模型输出——是普通文本、工具调用，还是终止信号。
• 工具执行器（Tool Executor）：模型只生成「工具名 + 参数」，真正执行的是宿主程序。执行器负责权限校验、超时控制、结果回填与错误归一化。
• 上下文管理器（Context Manager）：决定每一轮模型看到什么——历史怎么截断、工具结果要不要摘要、记忆怎么注入。上下文工程是 Agent 质量的重要变量，详见 Agent 架构与多智能体 的记忆系统一节。
• 循环控制器（Loop Controller）：检查停止条件（最大步数、预算、超时）、处理重试与降级、在确认节点挂起等待人工。

工程实现里有两个容易踩的坑。一是把模型的内部推理全部暴露给用户——规划过程可以作为进度展示，但完整思维链既干扰阅读又增加安全风险，一般保存为 trace 或压缩成可解释摘要。二是工具结果原样塞回上下文——长输出会挤爆上下文，工具结果要先结构化、裁剪、摘要再回填。

Agent 与 Chatbot、Copilot、Workflow 的区别

产品语境里四个概念经常混用，先分清定义再谈设计：

判断标准：流程固定优先 Workflow；需要用户持续监督适合 Copilot；需要系统自主拆解、执行、迭代才需要 Agent；只是问答就不要过度设计成 Agent。很多产品失败不是因为 Agent 不够智能，而是把确定性工作流错误地做成了不可控 Agent。

核心技术栈

一个完整 Agent 系统可以拆成九层，产品经理不必懂每层的实现，但要在设计评审时能逐层检查是否有缺失：

这九层里，最容易被产品团队砍掉的是「评估与观测层」——没有 trace 和评测，Agent 的失败无法复现，信任也无从建立。九层各有专页展开：规划与编排见 Agent 架构与多智能体，工具与协议见 工具调用与 MCP，评测见 评估与评测。

状态与记忆是 Agent 的隐含要求

Agent 的「有状态」来自记忆系统，产品经理至少要知道四类记忆的分工：

• 会话记忆（短期）：当前对话与最近的工具结果，维持单次任务的连续性。
• 任务记忆（工作记忆）：当前任务的目标、计划、进度、已完成步骤与失败尝试，任务结束可压缩成摘要。
• 长期记忆：跨会话的用户偏好、稳定事实与经验，支持个性化与连续任务（「用户偏好正式语气」这类信息）。
• 工具记忆：哪些工具过去有效、哪些经常失败，用于提高工具选择的成功率。

记忆不是「记住越多越好」：错误记忆比没有记忆更危险，隐私与遗忘机制是硬要求。记忆系统的设计展开见 Agent 架构与多智能体 的「记忆系统」一节。

为什么 2025-2026 年 Agent 从 Demo 走向工程系统

几个因素的合流让 Agent 从「演示好看」变成「生产可用」：

• 模型工具调用能力增强：主流模型能更稳定地输出结构化工具调用、理解工具错误并修复计划。
• 协议标准化：MCP 标准化了「应用如何接入工具与上下文」，A2A 标准化了「Agent 服务之间如何通信」，工具生态不再为每个应用写私有连接器。
• 框架成熟：OpenAI Agents SDK、LangGraph、CrewAI 等框架提供了 handoff、guardrails、tracing、记忆与持久化执行等工程能力。
• 编码 Agent 证明价值：Claude Code、Codex 等工具在真实代码仓库中读写文件、跑测试、提 PR，验证了「Agent 能独立完成有验收标准的任务」。
• 评测体系成形：SWE-bench、WebArena、τ-bench 等基准让 Agent 不再只靠 demo 评估。

对产品经理的意义：Agent 的工程底座已经成熟到可以按产品逻辑设计，而不是赌模型能力。

工作流 vs Agent

「工作流（Workflow）」与「Agent」是两种不同的系统形态，Anthropic 官方（Building Effective Agents）给出了业界最常用的定义：

• 工作流：LLM 与工具被预先编排的代码路径调度。每一步做什么、按什么顺序，由开发者在代码里写死，模型只在节点内部发挥作用。特点是步骤固定、输出可预期、可审计。
• Agent：LLM 动态决定自己的执行过程与工具使用。系统只给目标与工具集，模型自己决定先做什么、用什么工具、何时结束。特点是灵活、能处理开放任务，但结果不可完全预期。

对比

官方原则：先用工作流

Anthropic 的原则是「先找最简单的方案，只在评测证明必要的时候增加复杂度」。很多应用优化单次 LLM 调用（加检索、加上下文示例）就够了，不必上 Agent。判断一个任务是否值得 Agent 化，依次问三个问题：

1. 步骤能否预先枚举？——能，用工作流
2. 结果能否自动验证？——不能，先补验证闭环再谈自主
3. 出错能否恢复？——不能，先设计兜底与人工接管

三者都答「否」，才值得上 Agent。官方点名的两个已验证领域是客服（对话 + 工具，可测解决率）与编码 Agent（可用自动化测试验证结果）。反过来，报销审批、身份认证、支付转账这类强合规流程，天然属于工作流。

工作流 vs Agent 的决策表

把三个判断问题做成决策表，评审时可以直接对照：

经验原则一句话：可枚举、可审计、强合规的任务优先工作流；需要探索、推理、动态选择工具的任务适合 Agent；生产系统里用工作流管大边界，让 Agent 处理局部不确定性。

工作流的五类官方模式

Anthropic 总结了五类覆盖大多数确定性流程的工作流模式，复杂度与回报从低到高：

• 提示词链（Prompt Chaining）：固定顺序的步骤链，上一步的输出是下一步的输入，适合把复杂任务拆成可校验的小段（如先写大纲再成文）。
• 路由（Routing）：先分类再分流，把简单问题给快模型、复杂问题给强模型，或按任务类型分给不同的专门流程。
• 并行化（Parallelization）：扇出-扇入（任务切成多块同时做再合并）与投票（多个独立尝试取多数结果），适合可拆分、相互独立的工作。
• 编排者-工作者（Orchestrator-Workers）：主管模型拆任务、派发给子代理、汇总结果，适合无法预知子任务粒度的复杂任务。
• 评估者-优化者（Evaluator-Optimizer）：生成器产出 + 评估器反馈 + 迭代优化，适合「能明确写出评估标准」的生成任务（如翻译、润色、代码修改）。

这些模式的机制展开见 Agent 架构与多智能体 的「核心设计模式」一节。选型的顺序建议：先确认是否真的需要 Agent，如果不需要，从五类模式里选最贴近需求的一类，跑通后再加自主度。

生产里的混合形态

真实产品很少「纯工作流」或「纯 Agent」，更多是混合：工作流管大边界，Agent 处理局部不确定性。例如企业客服：用工作流控制「转人工、升级、结案」的关键节点，用 Agent 负责理解意图与生成回复；数据报表：工作流固定取数步骤，Agent 只负责解释异常。先按工作流跑通，评测发现某段流程需要动态决策，再把那一段换成 Agent——这是官方推荐的演进路径，也是成本最低的路径。

常见架构

各类架构的适用场景与代价

• 单 Agent：一个模型实例 + 一组工具 + 一个循环。多数 Agent 产品的起点，也常常是终点——「先单 Agent，评测证明收益后再复杂化」。代价是单一上下文窗口有限，超长任务会「忘掉」早期信息。典型例子：单任务写作助手、单工具知识库问答。
• 工作流：把确定性流程固化成代码路径，确定性决策用规则，非确定性决策在节点内调模型。适合「要稳定、要审计」的场景；代价是流程设计成本高，需求一变就要改代码。典型例子：审批流、报表生成流水线、内容审核链路。
• 多 Agent 协作：多个角色分工，适合重度并行、信息量超出单一上下文窗口、需要隔离不同权限的场景；代价是成本成倍上升、上下文重复、错误跨 Agent 传播、调试难度大幅上升。典型例子：多角色研究团队（研究员 + 审稿人）、编码流水线（规划 + 实现 + 审查）。
• 人机协同：不是独立架构，而是横切在所有架构上的控制方式——关键节点让人确认、可回退。风险越高、结果越不可逆，人工介入点越多；代价是任务吞吐依赖人的响应时效。典型例子：代码提交前 review、营销文案发布前审批。

什么时候选多 Agent

多 Agent 不是能力放大器的免费午餐。适合的场景有三个特征：任务天然可拆（每个子任务边界清晰）、子任务可以并行、不同子任务需要不同工具或权限。官方实测表明多 Agent 的 token 消耗约为普通对话的 15 倍，且 token 用量单独解释了约 80% 的评测差异——收益本质是「花钱买并行度与上下文隔离」。反过来说，需要共享同一上下文、Agent 间强依赖的任务（多数编码任务属于此类）不适合多 Agent。

各架构模式的机制展开（提示词链、路由、并行化、编排者-工作者、ReAct、Plan-and-Execute、反思等）与多智能体编排的代价分析见 Agent 架构与多智能体。

产品设计要点

Agent 产品的设计重心是代理权、信任与失败恢复：决定权、执行权与风险从人转移到系统，产品经理要设计的是「系统能在多大范围内自主、在什么节点请人确认、出错后如何恢复」。

• 任务边界：明确 Agent 能自主到什么程度——权限最小化。能读不能写、能草稿不能发送、能查自己的数据不能查别人的。边界是第一设计决定，不是工程细节：它决定了出事故时的责任范围与补救成本。
• 进度可见：展示「正在做什么、用了什么工具」，建立信任。执行中的当前步骤、调用的工具、依据都要可见，用户能中途插入、暂停、接管。Anthropic 把「显式展示 Agent 的规划步骤」列为透明度优先项。
• 确认节点：花钱、发消息、删数据等不可逆操作必须人工确认；可逆操作不打扰用户。确认点设在风险点而不是每个步骤——全量确认会毁掉 Agent 的体验，全不确认会毁掉信任。拒绝时把反馈回传给模型，让它在下一轮改进。
• 失败兜底：Agent 会卡住、会走弯路。设置最大步数、超时、人工接管；Agent 的错误会有状态地累积，不能靠无限重试——要区分「可重试的瞬时错误」与「反复失败的系统性问题」，后者立即降级或转人工，而不是继续烧 token。
• 成本控制：多轮循环 token 消耗大，需要预算上限与档位。成本公式 = 输入 token × 输入价 +（输出 + 思考）token × 输出价，再乘上循环轮数——一个 5 轮循环的任务，成本是单次调用的 5 倍以上。预算用尽要有显式降级路径：从全自主降为「每一步确认」或转人工。
• 可观测性：每次模型调用与工具调用都要有 trace——输入输出、工具参数与结果、耗时、token 消耗、错误与重试。没有 trace 就无法复现失败、审计权限、构造评测集，也就无法回答「为什么这次它选错了工具」。这是 Agent 与普通聊天产品最不同的工程要求。

成本预算算例

预算不是拍脑袋，而是可以提前算的。以「自动生成行业调研报告」为例：目标 1 万字报告，估算单任务平均 8 轮循环、每轮 3000 输入 token + 1500 输出 token，模型输出价 $10/百万 token：

• 单任务 token 成本 ≈ 8 ×（3000 × 输入价 + 1500 × 10）美元/百万的折算 ≈ 8 轮 ×（0.3 万 × 2 + 0.15 万 × 10）= 8 × 2.1 万美元/千万 ≈ 16.8 美元/千任务
• 月活 1000 个付费任务，月成本约 1.7 万美元——这时要么限制每任务轮数、要么降档模型、要么把循环改成工作流
• 缓存命中、批处理、错峰时段可再降 50%-90%，但要先测真实命中率

预算设计三件套：每任务预算上限（超限降级）、每用户档位（免费档限制轮数与工具）、全局告警（成本异常时暂停并转人工）。成本控制的目标不是省钱，而是让成本与用户价值成正比——这需要每任务成本的可观测性，回到 trace。

自主度分级：辅助 → 半自主 → 全自主

分级不是一次性决定，而是随信任增长的动态过程：模型反复触发拦截或失败时，系统应自动回退到更保守的交互方式，避免无人值守运行静默失控。放行全自主之前，先回答一个问题：错误是否被约束在可回滚范围内？

设计评审清单

评审 Agent 产品时逐项过一遍，比凭感觉判断「够不够智能」可靠得多：

• 权限：工具清单是否最小？有没有工作目录/网络/数据边界？非白名单动作是否默认拒绝？
• 护栏：输入/输出/工具三层检查是否齐备？触发后是否快速失败且不产生副作用？
• 恢复：是否有持久化检查点？失败后能否从断点续跑？人工能否在任何节点接管？
• 成本：步骤预算（最大步数）、并发上限、超时、成本上限是否配置？预算用尽时的降级路径是什么？
• 可观测性：步骤日志、工具调用、token 消耗是否可见？规划步骤是否对用户透明？
• 评测：是否有评测集与通过率基线？模型/提示词/工具变更是否跑回归？
• 信任基线：回答带来源、失败透明、可回退——没有这三样，不要放大代理权。

代理权要赚取，不要授予

每多给系统一分代理权，就少一分控制：建议式回复可以覆写，自动发送就必须确保正确。常见错误是系统还没证明「犯错时可控」就直接上全代理——失去可见性、失去信任、动作无法追溯。正确姿势是控制交接：出错时人类能无缝接管，Agent 做错一步，用户能一键纠正并记录，信任和可恢复性从这一步开始。产品上的落地手法包括：回答带来源（可点击回到依据）、失败透明（如实展示失败路径）、可回退（checkpoint 让状态可回滚到任意历史点）。

与 RAG 的关系

Agent 经常包含检索能力（Agentic RAG），但两者不是一回事：

• RAG 解决「知识从哪来」：把外部文档切块、索引、检索，让模型基于证据回答。检索流程通常是固定的「先检索再生成」。
• Agent 解决「事情怎么做」：Agent 决定要不要检索、检索什么、怎么利用结果，检索只是它可选的工具之一。

Agentic RAG 是把 RAG 融入 Agent 循环——模型根据问题动态决定是否检索、检索几次、检索结果不够时是否换关键词或换数据源、是否需要把多份证据交叉验证。它比固定 RAG 灵活，但也引入了检索失败的传播：检索质量差会直接污染后续所有步骤。

RAG 基础见 RAG 基础，高级检索与 Agentic RAG 的展开见 高级 RAG。

常见误区

• 把 RAG 当 Agent：只做了「检索 + 生成」，没有决策循环，遇到检索不到就直接答——这是工作流，不是 Agent。
• 把 Agent 当 RAG：给 Agent 挂了知识库工具就以为解决了事实性问题——检索质量、切块策略、引用溯源仍然决定答案质量，Agent 不改变检索本身的好坏。
• 检索失败沿循环传播：Agentic RAG 里第一步检索差，后续所有推理都建立在坏证据上。要给检索环节加验证：结果为空、置信度低时换查询、换数据源或如实承认不知道。
• 来源不可信的内容当指令：检索回来的网页与文档可能包含恶意提示词，要按不可信数据处理（见 工具调用与 MCP 的工具安全一节）。

当前边界（务实的预期管理）

• 复杂长程任务成功率仍有限。商用场景普遍是「工作流 + 人工复核」，不是全自动无人值守；演示场景可控，真实场景千变万化，上线前要用真实数据压测。
• 多 Agent 协作的成本与不稳定可能超过收益。Anthropic 官方实测：多 Agent 系统的 token 消耗约为普通对话的 15 倍，且 token 用量单独解释了约 80% 的评测差异——多 Agent 的收益本质是「花钱买并行度与上下文隔离」，先量化收益再决定值不值。
• 评测先行。放权前先有可量化的通过率/解决率基线，信任额度 = 评测证据；约 20 个代表性 query 就能发现早期大问题，人工测试会抓到自动评测抓不到的问题。对会改变状态的 Agent，要评测「终态」而非逐轮打分。
• 模型与框架迭代快。工具调用正确率、长程任务成功率都在快速提升，但「当前边界」是动态的——选型与架构决策要跟着评测结果刷新，而不是一次定终身。
• 工程差距大于模型差距。Anthropic 团队明确指出「原型到生产的差距往往比预想的大，最后一公里常常占了大部分旅程」：权限、护栏、持久化、可观测性这些工程补齐，才是 Agent 上线的真正门槛。

上线路径：从只读到自动执行

Agent 上线不是开关，而是权限与自动化程度的渐进式释放，每一步都有对应的验证目标：

常见错误是跳过前两阶段直接上自动执行。放行条件不满足时，宁可维持「半自主 + 人工复核」——多数商用 Agent 长期停留在这个阶段，这本身就是务实的产品决策。

来源说明

本文为原创整理，结论均引用以下权威来源，访问验证日期 2026-08-23：

1. Anthropic — Building Effective Agents：工作流与 Agent 的定义与取舍、「先简单后复杂」原则、五类工作流模式、透明度建议。
2. Anthropic — How We Built Our Multi-Agent Research System：多 Agent 实测数据、token 成本量级（15 倍）、错误累积与「最后一公里」。
3. OpenAI — Agents 指南：Agent 官方定义（规划、调用工具、保持状态完成多步工作）。
4. 评估与评测：评测体系与评测先行原则的站内展开。
5. AIGC-Interview-Book《AI Agent 基础》系列（预取内部参考）：Agent 九层技术栈、运行循环与停止条件、Chatbot/Copilot/Agent 对比。

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用