我最早以为，Agent 既然能让模型自己决定调用哪些工具，那它一定比 Pipeline 高级。直到我在一个生产项目里用 Agent 做客服问答，结果它在一半请求里调用错了数据库，还一脸笃定。后来我把流程改成 Pipeline，问题瞬间消失。这件事让我重新思考：这两种范式到底分别适合什么场景？
先看 Pipeline。用 Haystack 构建一个 RAG 应用，你大概会这样做：把文档切块、向量化，用户提问后先检索最相关的块，再把这些块塞给大模型生成回答。每一步做什么、顺序是什么，都是你在代码里写死的。这就是声明式编排——你声明流程，框架负责执行。
Agent 完全不同。你给它几个工具：搜索引擎、数据库、计算器。它自己决定先调用哪个、怎么调用、调用的结果怎么处理。模型在每一步都生成一个"思考"，然后选一个动作，观察结果，再思考下一步。这就是自主决策，你只给目标，不给路径。
听起来 Agent 明显更聪明。但生产环境不是智力竞赛，而是可靠性竞赛。要理解为什么 Pipeline 在大多数场景下更稳，得先看两者底层的机制差异。
Pipeline：一条写死的流水线，每一步都看得见
Pipeline 的本质是一个有向图。每个节点是一个组件，比如检索器、重排序器、生成器。你用代码把节点连接起来，数据按固定的方向流动。Haystack 的 Pipeline 代码大概长这样：
pipe = Pipeline()
pipe.add_component("retriever", retriever)
pipe.add_component("llm", llm)
pipe.connect("retriever.documents", "llm.documents")连接一旦建好，执行顺序就确定了。这意味着你可以在任何一步插入日志、调试、加缓存，甚至可以单独测试某个节点。Pipeline 的可预测性来自它放弃了灵活性——它不聪明，但它可靠。
这种设计很适合企业级应用。比如医疗问答，你必须保证每个问题都经过特定的审核节点，Pipeline 可以强制做到。如果换成 Agent，模型可能跳过审核直接输出答案，这是合规问题。
Agent：一个会思考的实习生，但你不清楚他下一步干嘛
Haystack 的 Agent 基于 ReAct 范式：模型重复 Thought → Action → Observation 的循环，直到得出最终答案。每一步，模型从你预设的工具列表里选一个，生成调用参数，然后框架执行工具，把结果反馈给模型，模型再决定下一步。
这个过程看起来很酷，但有个致命问题：你无法预知模型会调用哪条路径。你可能设置了 5 个工具，但模型偏要组合出第 6 种用法。有时候这是惊喜，有时候是灾难。
我踩过一个具体的坑：给 Agent 配了一个搜索工具和一个数据库工具，用户问"昨天销售额是多少"，Agent 先去搜索了一遍，没找到，然后才去查数据库——浪费了 3 秒。还有一次，用户问"退货流程"，Agent 居然调用了发邮件工具，试图给用户发一封退货指引邮件。虽然逻辑上没错，但这是生产环境，用户只是想知道流程，不是要收邮件。
一张表说清两者的本质区别
| 维度 | Pipeline | Agent |
|---|---|---|
| 编排方式 | 声明式，流程在代码里写死 | 自主式，模型动态决定流程 |
| 决策者 | 开发者 | 模型 |
| 执行过程 | 固定路径，每个节点按序执行 | 循环探索，路径不固定 |
| 可预测性 | 高，相同输入得到相同路径 | 低，相同输入可能走不同路径 |
| 调试难度 | 低，可以单步追踪 | 高，需要看模型的思考日志 |
| 性能开销 | 低，无多余调用 | 高，多次模型推理 |
| 容错能力 | 弱，节点失败则流程中断 | 强，可以尝试其他工具 |
| 适用场景 | 流程明确的业务 | 任务开放的探索 |
这张表的核心是决策权在哪。Pipeline 把决策权交给开发者，Agent 把决策权交给模型。这决定了你在面对具体问题时该怎么选。
什么时候用 Pipeline？什么时候用 Agent？
我现在的判断标准很简单：如果业务流程在需求阶段就能画出来，用 Pipeline；如果画不出来，或者流程本身会随上下文变化，用 Agent。
具体来说，Pipeline 适合这些场景：
- 固定业务逻辑：比如客服工单的分类、转交、回复模板，每个环节都有明确规则。
- 合规与审计要求：每一步都必须有记录，不能跳过，比如金融风控。
- 低延迟服务：Pipeline 每一步都精简，没有多余的模型调用。
- 可解释性要求高：你能向客户解释"为什么推荐这个产品"，因为你可以展示检索到的文档和排序分数。
Agent 适合这些场景：
- 任务不明确：用户需求五花八门，比如"帮我研究一下这个行业"，你需要模型自己拆解问题。
- 工具组合多变：需要根据问题动态选择工具，比如有时查天气、有时查日历、有时发消息。
- 探索性任务：没有固定答案，模型需要多步推理，比如复杂的逻辑问答。
- 流程会自我修正：当第一步的结果影响后续步骤时，Agent 可以根据中间结果调整计划。
注意，这些场景并不是非黑即白。我在实际项目中见过很多混合用法：用 Pipeline 做主干流程，在某个节点嵌入一个 Agent 做子决策。比如客服系统，先通过 Pipeline 判断用户意图，如果是复杂问题，才调用 Agent 处理。这样既保证了大部分请求的可控性，又给少数复杂请求留了灵活性。
一个容易被忽略的维度：成本
Agent 的每一步思考都是一次大模型调用。一个简单的三步骤任务，Pipeline 可能只调一次模型，Agent 要调三次以上，还要加上工具执行时间。在 API 按 token 计费的今天，这意味着 Agent 的每次请求成本可能是 Pipeline 的 5 到 10 倍。我见过一个团队上线 Agent 后，月度 API 账单涨了 12 倍，后来不得不给 Agent 加超时限制和最大步数。
所以，不要因为 Agent 看起来"智能"就盲目选它。你的业务真的需要模型自己决定路径吗？如果流程是稳定的，Pipeline 是更经济、更可控的选择。
我的认知转变
两年前我刚开始接触 Haystack 时，看到 Agent 的 demo 非常兴奋：模型自己调用搜索引擎、自己算数、自己组织答案，太强了。那时候我写什么应用都想用 Agent。直到一次生产事故让我彻底改变：用户问了一个关于产品价格的问题，Agent 先调用了搜索工具，搜到一篇过时的博客，然后基于那篇博客回答了错误价格。用户投诉后，我们查日志才发现，Agent 根本没有调用价格数据库，因为它的思考过程是"搜索应该能获得最新信息"。这个错误在 Pipeline 里几乎不可能发生——你会在代码里明确把价格数据库作为唯一的数据源。
那之后我总结了一条经验：Agent 适合做"辅助决策"，不适合做"核心流程"。核心流程必须由 Pipeline 保证确定性，Agent 可以用来处理边缘情况。
现在你怎么选？
回到开头的问题。如果你在构建一个生产级应用，我的建议是：先用 Pipeline 把主流程搭起来，把每一步都跑通、测好，然后只在真正需要灵活性的地方引入 Agent。比如，检索不到答案时，让 Agent 尝试其他检索策略；或者，让 Agent 帮你把用户的问题改写得更清晰，但最终的回答生成还是由 Pipeline 控制。
如果你在做一个实验项目，或者任务本身就没有标准答案，Agent 可能是更好的起点。但请记住，Agent 的不可预测性既是它的优势也是它的代价。你需要在产品里为用户留好"兜底"，比如限制最大步数、设置超时、提供人工转接。
最后说一句：技术选型没有高下之分，只有匹配度之分。Pipeline 和 Agent 不是替代关系，而是互补关系。理解了它们的机制和适用边界，你才能在任何场景下做出不后悔的选择。
原创文章，作者：guanweilu，如若转载，请注明出处：https://guanweilu.cn/article/282.html