从 Chain、DAG 到 Agent：为什么还需要 Agent？-大赛人网

这一节我们不急着写复杂 Agent，也不急着接真实大模型 API。我们先把一个最容易被说模糊、但后面每一节都会依赖的问题讲透，既然以前已经有 Chain、DAG、Workflow，为什么今天还需要 Agent？

学完以后，你应该能做到：

很多人第一次接触 Agent，会天然产生一种“技术升级”的感觉。

以前是 Chain，后来是 DAG，再后来是 Workflow，现在是 Agent，于是很容易把它们理解成：

Chain
  ↓
DAG
  ↓
Workflow
  ↓
Agent

好像后面的东西天然比前面的高级，甚至像软件版本一样，Agent 一出来，前面的方案就应该被替代。

但真实工程里完全不是这样。

比如一个每天凌晨执行的数据任务：

拉取数据
  ↓
清洗
  ↓
聚合
  ↓
写入报表表
  ↓
发送通知

你完全没有必要让一个大模型每次凌晨两点“思考一下”，“我现在应该先清洗，还是先发通知？”

这种流程越确定，越应该写死。

再比如退款审批：

用户申请
  ↓
校验订单
  ↓
金额判断
  ↓
是否需要主管审批
  ↓
是否需要财务审批
  ↓
退款

它可能有十几个节点，也可能有很多条件分支，但这并不意味着应该交给 Agent。因为金额阈值、权限规则、审批路径都应该明确、可审计、可复现。

反过来，一个看起来非常简单的请求，“帮我看看这个 Python 项目为什么运行不起来。”

只有一句话，却很难写成固定流程。

因为你根本不知道问题在哪里。

可能是：

你可以继续写 if/else：

如果是 ImportError → 查依赖
如果是 SyntaxError → 查代码
如果是 ConnectionError → 查数据库
如果是 FileNotFoundError → 查路径
……

但你很快会发现，真实世界里的错误类型、项目结构、依赖关系和组合情况几乎是开放的。你越想提前枚举所有路径，Workflow 就越容易变成一张越来越难维护的“巨大规则网”。

这就是 Agent 真正出现的地方。

Agent 不是因为“以前的 DAG 不够高级”，而是因为我们开始遇到一类任务，下一步该做什么，必须看刚刚发生了什么，而且很难在任务开始前把所有路径写死。

这句话值得反复读一遍。

传统流程更多解决，“我已经知道该怎么做，帮我稳定执行。”

Agent 更擅长解决，“我知道目标，但不知道完整路径；请你根据当前状态不断决定下一步。”

所以这一节我们会从最熟悉的固定流程开始，一步步看清：

Chain
A → B → C

为什么自然会发展到：

DAG
      → B →
A             → E
      → C → D

再发展到带条件、状态和业务规则的 Workflow。

然后我们再看 Agent：

当前状态
   ↓
LLM 判断下一步做什么
   ↓
Action
   ↓
结果反馈
   ↓
再次判断

最后你会发现，Agent 真正“新”的地方，其实可以浓缩成一句话，Agent 的核心不是调用大模型，而是把部分决策权交给模型。

这里的“部分”也特别重要。

因为我们并不希望模型决定一切。权限、安全、超时、审批、最大步数、SQL 白名单，这些事情依然应该由确定性的程序控制。

这也是后面整门课会一直坚持的工程思想。

把四种结构放在同一张图里，我们会更容易抓住它们真正不同的地方：

Chain 固定顺序，DAG 处理依赖与并行，Workflow 在预定义规则里选择分支；只有到了 Agent，下一步才会根据运行中的 Observation 重新决定。它们不是一条“谁淘汰谁”的升级路线，而是分别适合不同形状的问题。

这一节是第1部分“真正理解 Agent”的第一块地基。开篇我们已经看过最终要造的 Agent Harness，这一节要解决的是：为什么这个 Harness 里必须存在一个“动态决策循环”？

文章版权归作者所有，未经允许请勿转载。

THE END