2026 年AI 领域最热的词之一无疑是Agent。但真正让 Agent 从Demo 很酷走向生产可用的是它背后那套被称为Agentic Workflow智能体工作流的设计思想。今天这篇博客我想系统地聊一聊Agent 流到底是什么、有哪些核心模式、工程上怎么落地以及踩过哪些坑。一、先搞清楚工作流 vs 智能体很多人把 Agent 和工作流混为一谈但 Anthropic 在其官方工程博客中做了一个很清晰的区分类型定义适用场景工作流Workflow通过预定义的代码路径编排 LLM 和工具任务明确、需要一致性和可预测性智能体AgentLLM 动态指导自身的流程和工具使用需要灵活性和模型驱动决策简单说工作流是人设计好路线LLM 按路线走智能体是LLM 自己决定怎么走。Anthropic 还特别强调了一个反直觉的观点不要一上来就构建复杂的智能体。大多数应用只需要通过检索和上下文示例来优化单个 LLM 调用就足够了。智能体系统通常以延迟和成本为代价来换取更好的任务性能。二、四种核心设计模式吴恩达在 2026 年 4 月红杉的演讲中总结了 4 种主要的 Agentic Workflow 设计模式1. Reflection反思让 Agent 审视和修正自己生成的输出。本质上是一个博弈过程你让大模型写一段代码再让它自己检查代码的准确性和规范性给出评论然后基于反馈输出更好的版本。如果有两个 Agent——一个负责 Coding另一个负责 Code Review效果会更佳。2. Tool Use工具使用LLM 生成代码、调用 API 等工具进行操作。比如你用 Kimi Chat 查询某个问题时它会在互联网上检索相关内容基于检索结果进行总结分析最后给出结论。这就是大模型利用网页搜索工具的典型例子。3. Planning规划让 Agent 分解复杂任务并按计划执行。Agent 会先识别任务目标然后自行规划执行路径——比如先调用姿势提取模型再调用图像合成模型最后通过语音合成输出完成整个流程任务。4. Multiagent Collaboration多智能体协同多个 Agent 扮演不同角色合作完成任务。ChatDev 就是一个经典案例它模拟一家虚拟软件公司通过扮演 CEO、产品经理、CTO、程序员、测试员等不同角色的智能代理来协作完成从设计、编码、测试到文档编写的全流程。三、Anthropic 的五种工作流模式在吴恩达的四种模式之外Anthropic 从工程实践角度进一步细化了五种工作流模式提示链Prompt Chaining将任务分解为一系列步骤每个 LLM 调用处理上一步的输出。适合任务可以分解为固定子任务的场景。路由Routing对输入进行分类并引导至专门的后续任务。比如客服查询中一般问题走轻量模型复杂问题走重量级模型。并行化ParallelizationLLM 同时处理任务并聚合结果包括分段和投票两种模式。编排器-工作者Orchestrator-Workers中央 LLM 动态分解任务、委派给工作流 LLM 并综合结果。评估器-优化器Evaluator-Optimizer一个 LLM 生成响应另一个在循环中提供评估和反馈迭代改进。四、Agent 的基础架构Lilian Weng 在她的经典博客中提出了一个被广泛引用的公式Agent LLM 规划 记忆 工具使用其中LLM扮演 Agent 的大脑负责理解上下文和推理规划Planning包括子目标分解、反思与改进将大型任务拆解为可管理的子任务记忆Memory分为短期记忆对话上下文和长期记忆通过向量数据库存储和召回信息工具Tools通过调用外部 API 获取模型中缺少的额外信息和能力。五、工程落地的几个关键原则理论讲完了聊聊实际开发中最容易踩坑的地方。原则一模型管判断代码管能力把系统拆成两类东西确定性能力生成图片、转码、写文件→ 留在代码里做成工具判断与编排选哪个方案、何时该停、质量够不够→ 留在指令里交给模型。好处是改流程不用改代码改能力不用动流程。原则二能力靠发现不靠枚举新手最容易犯的错是在 prompt 或代码里硬编码一份工具清单。成熟做法是运行时发现所有工具注册到一个 registry模型查 registry 拿到当前可用的能力。原则三上下文是预算默认渐进披露模型的上下文窗口是稀缺资源。把所有信息一股脑塞进去既贵又稀释注意力。应该像设计 API 一样分层——便宜的摘要在前昂贵的细节按需加载。原则四长流程要可恢复、可审计一个跑十几步、要花钱、可能中途挂掉的流程必须解决两个问题断了能不能续事后能不能查可以用状态机管理阶段流转每个阶段产出规范化工件用 checkpoint 记录进度支持断点续跑。六、流式输出让 Agent 的思考可见在实际产品中Agent 的执行过程对用户来说往往是黑盒。流式输出Streaming是解决这个问题的关键。基于 SSEServer-Sent Events协议可以定义多种事件类型来覆盖 Agent 执行的完整生命周期thinkingAgent 在思考阶段告诉用户它在规划还是推理planAgent 生成了执行计划展示给用户确认actionAgent 要调用某个工具展示工具名和参数摘要observation工具返回结果展示结果摘要stream最终答案的流式输出逐个 token 推送到前端。用户看到的是Agent 在规划 → 展示计划 → 正在搜索 → 搜到了 N 条结果 → 正在分析 → 开始输出答案。每个阶段都有明确的状态提示用户知道 Agent 在做什么、做完了没有。七、一些冷思考Agent 流很强大但也不是银弹。工作流解决的是可控性问题不是智能问题。大模型根源上不太聪明这件事加上 workflow 也解决不了。工作流解决的是流程上的可干预性和可控性提升大模型本身的质量依旧十分重要。少即是多。Anthropic 的经验总结得很到位最成功的实现往往不是使用复杂的框架而是使用简单、可组合的模式。与其急着引入复杂的多 Agent 编排框架不如先把单个工具调用做到极致。闸门优于喊话。任何关键契约如果只停留在文档的大写字母 MUST 里就是靠模型自觉的概率性兜底。真正成熟的做法是把关键规则变成代码层面的闸门——让错的事做不出来而不是被禁止。写在最后Agent 流的核心价值在于它把一个复杂的任务分解成较小的步骤在整个过程中融入了更多人类可参与的规划与定义减少了对 Prompt Engineering 和模型推理能力的过度依赖。从脚本工具到 RPA 再到 LLM Agent工作流一直在演进。而 Agent 流带来的最大变化是系统从执行者进化为协作者。这条路才刚刚开始但方向已经很清晰了。 Agent 流：从概念到落地的全景解读
2026 年AI 领域最热的词之一无疑是Agent。但真正让 Agent 从Demo 很酷走向生产可用的是它背后那套被称为Agentic Workflow智能体工作流的设计思想。今天这篇博客我想系统地聊一聊Agent 流到底是什么、有哪些核心模式、工程上怎么落地以及踩过哪些坑。一、先搞清楚工作流 vs 智能体很多人把 Agent 和工作流混为一谈但 Anthropic 在其官方工程博客中做了一个很清晰的区分类型定义适用场景工作流Workflow通过预定义的代码路径编排 LLM 和工具任务明确、需要一致性和可预测性智能体AgentLLM 动态指导自身的流程和工具使用需要灵活性和模型驱动决策简单说工作流是人设计好路线LLM 按路线走智能体是LLM 自己决定怎么走。Anthropic 还特别强调了一个反直觉的观点不要一上来就构建复杂的智能体。大多数应用只需要通过检索和上下文示例来优化单个 LLM 调用就足够了。智能体系统通常以延迟和成本为代价来换取更好的任务性能。二、四种核心设计模式吴恩达在 2026 年 4 月红杉的演讲中总结了 4 种主要的 Agentic Workflow 设计模式1. Reflection反思让 Agent 审视和修正自己生成的输出。本质上是一个博弈过程你让大模型写一段代码再让它自己检查代码的准确性和规范性给出评论然后基于反馈输出更好的版本。如果有两个 Agent——一个负责 Coding另一个负责 Code Review效果会更佳。2. Tool Use工具使用LLM 生成代码、调用 API 等工具进行操作。比如你用 Kimi Chat 查询某个问题时它会在互联网上检索相关内容基于检索结果进行总结分析最后给出结论。这就是大模型利用网页搜索工具的典型例子。3. Planning规划让 Agent 分解复杂任务并按计划执行。Agent 会先识别任务目标然后自行规划执行路径——比如先调用姿势提取模型再调用图像合成模型最后通过语音合成输出完成整个流程任务。4. Multiagent Collaboration多智能体协同多个 Agent 扮演不同角色合作完成任务。ChatDev 就是一个经典案例它模拟一家虚拟软件公司通过扮演 CEO、产品经理、CTO、程序员、测试员等不同角色的智能代理来协作完成从设计、编码、测试到文档编写的全流程。三、Anthropic 的五种工作流模式在吴恩达的四种模式之外Anthropic 从工程实践角度进一步细化了五种工作流模式提示链Prompt Chaining将任务分解为一系列步骤每个 LLM 调用处理上一步的输出。适合任务可以分解为固定子任务的场景。路由Routing对输入进行分类并引导至专门的后续任务。比如客服查询中一般问题走轻量模型复杂问题走重量级模型。并行化ParallelizationLLM 同时处理任务并聚合结果包括分段和投票两种模式。编排器-工作者Orchestrator-Workers中央 LLM 动态分解任务、委派给工作流 LLM 并综合结果。评估器-优化器Evaluator-Optimizer一个 LLM 生成响应另一个在循环中提供评估和反馈迭代改进。四、Agent 的基础架构Lilian Weng 在她的经典博客中提出了一个被广泛引用的公式Agent LLM 规划 记忆 工具使用其中LLM扮演 Agent 的大脑负责理解上下文和推理规划Planning包括子目标分解、反思与改进将大型任务拆解为可管理的子任务记忆Memory分为短期记忆对话上下文和长期记忆通过向量数据库存储和召回信息工具Tools通过调用外部 API 获取模型中缺少的额外信息和能力。五、工程落地的几个关键原则理论讲完了聊聊实际开发中最容易踩坑的地方。原则一模型管判断代码管能力把系统拆成两类东西确定性能力生成图片、转码、写文件→ 留在代码里做成工具判断与编排选哪个方案、何时该停、质量够不够→ 留在指令里交给模型。好处是改流程不用改代码改能力不用动流程。原则二能力靠发现不靠枚举新手最容易犯的错是在 prompt 或代码里硬编码一份工具清单。成熟做法是运行时发现所有工具注册到一个 registry模型查 registry 拿到当前可用的能力。原则三上下文是预算默认渐进披露模型的上下文窗口是稀缺资源。把所有信息一股脑塞进去既贵又稀释注意力。应该像设计 API 一样分层——便宜的摘要在前昂贵的细节按需加载。原则四长流程要可恢复、可审计一个跑十几步、要花钱、可能中途挂掉的流程必须解决两个问题断了能不能续事后能不能查可以用状态机管理阶段流转每个阶段产出规范化工件用 checkpoint 记录进度支持断点续跑。六、流式输出让 Agent 的思考可见在实际产品中Agent 的执行过程对用户来说往往是黑盒。流式输出Streaming是解决这个问题的关键。基于 SSEServer-Sent Events协议可以定义多种事件类型来覆盖 Agent 执行的完整生命周期thinkingAgent 在思考阶段告诉用户它在规划还是推理planAgent 生成了执行计划展示给用户确认actionAgent 要调用某个工具展示工具名和参数摘要observation工具返回结果展示结果摘要stream最终答案的流式输出逐个 token 推送到前端。用户看到的是Agent 在规划 → 展示计划 → 正在搜索 → 搜到了 N 条结果 → 正在分析 → 开始输出答案。每个阶段都有明确的状态提示用户知道 Agent 在做什么、做完了没有。七、一些冷思考Agent 流很强大但也不是银弹。工作流解决的是可控性问题不是智能问题。大模型根源上不太聪明这件事加上 workflow 也解决不了。工作流解决的是流程上的可干预性和可控性提升大模型本身的质量依旧十分重要。少即是多。Anthropic 的经验总结得很到位最成功的实现往往不是使用复杂的框架而是使用简单、可组合的模式。与其急着引入复杂的多 Agent 编排框架不如先把单个工具调用做到极致。闸门优于喊话。任何关键契约如果只停留在文档的大写字母 MUST 里就是靠模型自觉的概率性兜底。真正成熟的做法是把关键规则变成代码层面的闸门——让错的事做不出来而不是被禁止。写在最后Agent 流的核心价值在于它把一个复杂的任务分解成较小的步骤在整个过程中融入了更多人类可参与的规划与定义减少了对 Prompt Engineering 和模型推理能力的过度依赖。从脚本工具到 RPA 再到 LLM Agent工作流一直在演进。而 Agent 流带来的最大变化是系统从执行者进化为协作者。这条路才刚刚开始但方向已经很清晰了。