嗨，我是 Lena。我盯着大家怎么聊 agentic workflow 也有一阵了。每个人用这个词的姿势都不太一样——而且老实说，我自己花了比想承认更长的时间才搞清楚，一个 agentic workflow 跟一个普通的 AI agent，或者一条基础的自动化链，到底差在哪儿。
这篇是我把眼下这片图景摆开来的尝试：有哪几种子类型、之间怎么选、在生产里哪些走得通、又是在哪些地方崩。如果你正在用 agent 搭东西、又在纠结到底选哪种工作流架构才真的对得上你的问题，这篇文章应该能帮你少走几段弯路。
一句话定义
一句话讲清 agentic workflow
Agentic workflow 是这么一个系统：AI 模型自己决定下一步要做什么、去调哪些工具、评估结果、然后继续往下走——跨多个步骤、对流程本身有一定程度的自主权。
就这样。关键词是对流程的自主权。模型不只是回答问题。它在决定怎么去拆这个问题、选哪些工具用、根据回包做调整。
为什么这个词在 2026 还是这么乱
事情是这样——"agentic workflow" 这个词如今涵盖的东西，从一条带条件分支的两步链，到一整套带共享记忆、自我纠错循环的多 agent 系统，全都被框进去了。Anthropic 那篇 building effective agents 的指南做了一个有用的区分：workflow 是 LLM 在预先定义好的代码路径中被编排的系统，agent 则是动态地自己决定流程的系统。但实际上，大多数生产级系统都活在两者之间。
我第一次读到这个区分的时候，停在那儿想了一会儿。它在纸面上看着干净，但我一直见到的那些系统，没一个能干净利落地塞进任意一个盒子里。
Agentic workflow 的形态图谱
不是所有 agentic workflow 都是一个样子搭出来的。这些差异在你决定要造什么的时候很重要——更要紧的是，决定你造出来的东西能不能扛住生产。
线性 workflow
最简单的形式。任务 A 喂给任务 B，再到任务 C。每一步都是一次带工具访问的 LLM 调用，但序列是预先定好的。想一下：抽取 → 分析 → 总结。自主度低、可预测性高。 适合文档处理、数据抽取管线，以及任何步骤不会变的场景。
分支 workflow
系统会在一个或多个点上做路由决策。"如果输入是工单，往左；如果是销售询问，往右。" 路由可以是 LLM 驱动也可以是规则驱动。大多数团队从基础链往上做的时候，是从这里开始的。LangGraph 这类框架用基于图的状态管理和条件边把这个模式做得很显式。
自我纠错 workflow
这里才开始变得真有意思。系统跑完一次任务，对自己的输出做评估，如果结果没过校验就回头重试或修订。 本质上是一个 evaluator-optimizer 循环。我看到这套模式被频繁用在代码生成里——一个模型写、一个模型审，往复迭代直到 reviewer 满意为止。坑是：没有靠谱的退出条件，这种循环会无止境地烧 token。
多 agent workflow
多个专门化的 agent 在问题的不同部分上工作，由一个 orchestrator 协调。Anthropic 描述他们的多 agent 研究系统用的就是这个模式——一个 lead researcher 把子任务分派给专门的 subagent 并行跑。Orchestrator-worker 模式很强，但带来了真实的协调复杂度：agent 可能重复劳动、互相漏掉关键片段、或者在分派不精确的情况下互相打架。
人在回路里的 workflow
上面任何一种模式，加上明确的检查点，由人来审、批、或重定向之后系统才继续。这不是一种单独的架构，更像你叠在其它架构上面的一个约束层。对高风险领域来说没得商量——金融决策、法律审核，以及任何一旦做错就有真实后果的场景。
Agentic workflow 跟 agent 和自动化的区别
Workflow vs agent
Workflow 有结构。哪怕它有适应性，也是一段被设计过的流，带定义好的步骤和过渡。Agent 更开放——它自己决定干啥、什么时候干、怎么干，预定义结构降到最低。绝大多数生产系统是 workflow，不是纯 agent，因为纯 agent 更难调试、更难预测、更难控制。
Agentic workflow vs RPA
传统 RPA 跟的是严格、基于规则的脚本。它在固定顺序里点按钮。Agentic workflow 能解析非结构化输入、做判断、并在数据跟期望不符时调整。 RPA 一旦界面变了就坏。Agentic workflow 也会坏，但坏的方式不一样、有时候更难察觉——可它处理变化的能力强很多。
Agentic workflow vs 无代码自动化
Zapier、Make 这类无代码工具把触发-动作这种模式做得很好。但它们是无状态的，也缺推理。Agentic workflow 能跨步骤持有上下文、根据中间结果做条件性决定、应付那种需要理解力（而不只是路由）的任务。Model Context Protocol (MCP) 在这儿值得提一句：它把 AI 应用如何连接外部工具和数据源标准化了，越来越多 agentic workflow 底下接的就是这层结缔组织。
按用例看的真实例子
编码：Agent 写代码 → 跑测试 → 读错误 → 改 → 再跑。自我纠错循环。这大概是目前生产中最成熟的 agentic workflow 模式。
研究：Orchestrator 把研究问题拆成子任务 → 并行的 subagent 在不同来源搜索 → 结果被综合。关键挑战是去重和"什么时候停止挖"。
文档处理：从 PDF 抽字段 → 对照 schema 校验 → 标记异常 → 路由给人审。线性 + 在校验那步带分支。
支持：把工单分类 → 取相关文档 → 起草回复 → 校对语气和准确性 → 发送或升级。带一层草稿自我纠错的分支 workflow。
运维：监控系统指标 → 发现异常 → 诊断可能原因 → 给出修复建议 → 等审批 → 执行。这里人在回路是关键。
决策图：你该选哪种 workflow
……答案有点出乎意料——不是"选最复杂的那个"。恰恰相反。下面是一个快速框架：
| 因素 | 线性 | 分支 | 自我纠错 | 多 agent |
|---|---|---|---|---|
| 任务稳定性 | 步骤几乎不变 | 输入变、步骤不变 | 输出质量浮动 | 子任务互相独立 |
| 工具风险 | 低——只读工具 | 中——有写操作 | 中——可重试 | 高——需要隔离 |
| 审核需求 | 低 | 中 | 中到高 | 高 |
| 记忆要求 | 极低 | 适中 | 适中（循环状态） | 高（跨 agent 上下文） |
从能安全处理你任务的最简架构开始。 一个跑得起来的线性 workflow，胜过一个偶尔在协调上发癔症的多 agent 系统。Google 的 Agent2Agent (A2A) 协议 正在推动多 agent 协调的标准化，但对大多数团队来说当下的现实是：只有当子任务真的相互独立、可以并行时，多 agent 系统带来的复杂度才划得来。
Agentic workflow 在生产里为什么会崩
这是我反复回到的部分。我见过那些在 demo 阶段美得不行的 workflow，真用了一周就解体。失败模式足够一致，可以列出来：
上下文漂移。 在长时间运行的任务里，模型会逐渐失去对早期上下文的把控，开始做出跟它三步之前的决定相矛盾的判断。Token 上限是真的，而大多数 workflow 在上下文剪枝上做得不够好。CIO 关于 agentic AI 在工程领域的分析把这点列为核心挑战——多步骤上的持续执行需要的是刻意的上下文架构，而不只是更长的 context window。
工具失败。 API 挂了。撞到限流。响应格式变了。一个对工具失败处理不优雅的 workflow，会把一次 API 超时直接放大成一次完整失败。大多数团队在重试逻辑和回退路径上的投入是不够的。
校验薄弱。 Workflow 跑完了、出了输出、没人去查输出到底好不好。自我纠错 workflow 能帮上忙，但前提是 evaluator 真的能抓住 generator 犯的错。我见过那种 setup：evaluator 因为 prompt 写得不够精确，直接对一切都点头放行。
修复没复用。 这一条挺微妙的，但放长来看可能是代价最大的。Agent 撞到一个问题，人去修了，修法蒸发了。下周，同一个问题、同一种手工干预。那次成功的修复从来没被沉淀成可以复用的东西。 没有任何机制把一次一次性的纠正变成持续的改进。Workflow 不会从自己的历史里学——它只会重置。
我到现在也还没完全想清楚，这件事在基础设施层面正确的解法长什么样。但我觉得有个 pattern 是关键：如果你的 workflow 反复撞到同一个失败，而你反复在手工打补丁——你遇到的不是工作流问题，而是一个能力继承问题：成功的修复需要成为系统的一部分，而不是停留在某个人脑袋里。
这也正是我们做 evomap.ai 的起因。我们一直在看 agent 解决真实问题——debug、测试、写文档——然后到下一次运行时，它们刚搞清楚的所有东西又没了。所以我们开始问：要是那些已经走通的修复，能被打包、被分享，然后被其他 agent 自动继承呢？这就是我们 Genome Evolution Protocol 的核心想法——不是去做一个更聪明的模型，而是确保一个 agent 辛苦得来的方案，不会蒸发。如果你也在被那个"修-忘-再修"的循环拖着，把你的问题直接抛过来看回什么，可能值得一试。
FAQ
agentic workflow 到底是啥？跟普通 AI agent 或简单自动化有什么区别？
Agentic workflow 坐在硬性自动化和完全自主 agent 中间。它有预定义结构（步骤、过渡、检查点），但在那个结构里把决策权交给了 AI 模型。普通自动化遵循固定规则。纯 agent 自己决定一切。Agentic workflow 给模型在已定义阶段里怎么做完的自主权，整个流是人设计的。
2026 年最实用的 agentic workflow 真实例子是啥？
带自我纠错的代码生成、多源研究综合、带校验的文档抽取、带质量检查的客户支持回复起草、带人在回路修复的运维监控。共通主线是：那些需要多步、用工具、并对输出做某种形式评估才能交付结果的任务。
Agentic workflow 怎么处理记忆、上下文和多步骤任务？
短期上下文通常通过模型的 context window 管理——会话历史和工具结果作为消息流过去。对更长的 workflow，团队用外部状态存储：数据库、文件、或者专门的记忆系统，把信息跨步骤地持久化下来。多 agent 系统经常用一个所有 agent 都能读写的共享状态对象。上下文管理仍然是这个领域最难的工程问题之一。
Previous Posts:
- 想对现代 agent 系统在本文讨论的 workflow 模式底下的分层，有更清楚的图景？这篇拆 OpenHarness、GEP 和 agent stack layers 的文章直接接到架构那一面：OpenHarness and GEP Agent Stack Layers
- 上面提到的"workflow vs 能力继承"问题，在把可复用 skill 和可复用程序性资产做对比的时候会更明显：Agent Skills vs GEP Assets Real Difference
- 如果本文的自我纠错和编排模式戳到你，这篇关于 agent execution chains 和 hooks 的文章是顺势接上的下一读：Agent Hooks AI Execution Chains
- Agentic workflow 在生产里最大的失败模式之一是修复没法跨运行保留。这篇文章把这道学习鸿沟挖得更深：ARC AGI 3 Agent Learning Gap GEP
- 如果你在评测记忆、编排、workflow 持久化的实用框架，这篇对 Mem0、LangGraph、CrewAI 以及 harness 工程模式的比较是这篇之后自然的延伸：Harness Engineering Mem0 LangGraph CrewAI
