2026 年，AI 领域最热的词之一，无疑是 Agent。
但真正让 Agent 从"Demo 很酷"走向"生产可用"的，是它背后那套被称为 Agentic Workflow（智能体工作流） 的设计思想。
今天这篇博客，我想系统地聊一聊：Agent 流到底是什么、有哪些核心模式、工程上怎么落地，以及踩过哪些坑。
一、先搞清楚：工作流 vs 智能体
很多人把 Agent 和工作流混为一谈，但 Anthropic 在其官方工程博客中做了一个很清晰的区分：
| 类型 | 定义 | 适用场景 |
|---|---|---|
| 工作流（Workflow） | 通过预定义的代码路径编排 LLM 和工具 | 任务明确、需要一致性和可预测性 |
| 智能体（Agent） | LLM 动态指导自身的流程和工具使用 | 需要灵活性和模型驱动决策 |
简单说：
- 工作流是"人设计好路线，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）：对输入进行分类并引导至专门的后续任务。比如客服查询中，一般问题走轻量模型，复杂问题走重量级模型。
- 并行化（Parallelization）：LLM 同时处理任务并聚合结果，包括"分段"和"投票"两种模式。
- 编排器-工作者（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）是解决这个问题的关键。
基于 SSE（Server-Sent Events）协议，可以定义多种事件类型来覆盖 Agent 执行的完整生命周期：
- thinking：Agent 在思考阶段，告诉用户它在规划还是推理；
- plan：Agent 生成了执行计划，展示给用户确认；
- action：Agent 要调用某个工具，展示工具名和参数摘要；
- observation：工具返回结果，展示结果摘要；
- stream：最终答案的流式输出，逐个 token 推送到前端。
用户看到的是：Agent 在规划 → 展示计划 → 正在搜索 → 搜到了 N 条结果 → 正在分析 → 开始输出答案。每个阶段都有明确的状态提示，用户知道 Agent 在做什么、做完了没有。
七、一些冷思考
Agent 流很强大，但也不是银弹。
工作流解决的是可控性问题，不是智能问题。 大模型根源上"不太聪明"这件事，加上 workflow 也解决不了。工作流解决的是流程上的可干预性和可控性，提升大模型本身的质量依旧十分重要。
少即是多。 Anthropic 的经验总结得很到位：最成功的实现往往不是使用复杂的框架，而是使用简单、可组合的模式。与其急着引入复杂的多 Agent 编排框架，不如先把单个工具调用做到极致。
"闸门"优于"喊话"。 任何关键契约，如果只停留在文档的大写字母 MUST 里，就是靠模型自觉的概率性兜底。真正成熟的做法，是把关键规则变成代码层面的"闸门"------让错的事做不出来，而不是被禁止。
写在最后
Agent 流的核心价值，在于它把一个复杂的任务分解成较小的步骤，在整个过程中融入了更多人类可参与的规划与定义，减少了对 Prompt Engineering 和模型推理能力的过度依赖。
从脚本工具到 RPA 再到 LLM Agent，工作流一直在演进。而 Agent 流带来的最大变化是：系统从"执行者"进化为"协作者"。
这条路才刚刚开始，但方向已经很清晰了。