一问题：复杂度不是越高越好
当一个产品经理跑来跟你说"我们要做个 AI Agent"——先停一下。Dave Ebbelaar 在这条视频里把这件事拆得很透：市面上叫"AI Agent"的东西，复杂度可以从 1 到 5 跨越四个数量级，而 80% 的项目其实只需要 Level 1 或 Level 2。
Dave 是 DataLumina 的 AI 工程师、AI 方向双学位（学士+硕士），长期给客户做生产级 AI 系统。这次他不是讲理论框架，而是把自己在客户项目里真正用得上的五个层级摊开来讲，每层都配代码和真实案例。
这个视频解决的核心问题只有一个：当你坐在白板前要做一个 AI 功能时，怎么判断自己到底需要哪一层？
把任何想用 AI 自动化的流程都先拎出来问一句：能不能用一个简单的 LLM 调用解决？能不能用一个 workflow（DAG）解决？只有在简单方案撑不住的时候，才升级到 agent。
二核心概念：什么是"五个层级"
Dave 把所有叫"AI Agent"的东西按自治程度和编排复杂度分成五层。越往上越强大，但同时越难调试、越难维护、越难控制成本。
- Level 1：基础 LLM 调用（augmented LLM）——一次 API call + 结构化输出。最简单，几乎所有项目都从这里起步。
- Level 2：Workflow / DAG（提示链与路由）——多个 LLM 节点按有向无环图编排，前面分类，后面分流。是过去两年 Dave 一直在"布道"的方案。
- Level 3：工具调用 Agent（tool calling）——LLM 可以在循环中自主决定调用哪些工具。灵活，但有不可预测性。
- Level 4：多智能体系统（multi-agent / sub-agent）——多个 Claude/GPT 互相协作、互相调用。能力上限最高，但复杂度爆炸。
- Level 5：自治 Agent / 智能体 OS（agentic coding harness）——能读、写、跑 bash、上网、长时间自主运行（Claude Code、OpenClaw 这种）。
五层之间不是替代关系，而是组合关系——一个 Level 5 的系统里其实同时跑着 Level 1 到 Level 4 的子模块。理解这一点是判断"什么时候用哪一层"的前提。
三五层逐一拆解
Level 1：Augmented LLM——一切的地基
一次结构化输出 API 调用，配上 prompt 工程，就足够解决 30%–40% 的实际业务问题。比如把用户反馈分类、生成产品描述、把工单摘要成 50 字。
关键不是"用 LLM"，而是用结构化输出——给模型一个 JSON schema，让它必须按你定义的字段输出。这是把 LLM 从"聊天机器人"变成"系统组件"的第一步。
Level 2：Workflow / DAG——两年主推的生产范式
这一层 Dave 强调得最多。过去两年他给客户做的所有生产系统，主干都是一个 DAG（directed acyclic graph，有向无环图）。
工作方式：
- 先用一个分类节点判断"进来的请求属于哪一类"（账单问题 / 技术问题 / 投诉 / 其他）；
- 每个分类走自己的子流程；
- 每个子流程里再串若干 LLM 节点 + 工具调用节点 + 数据处理节点。
关键观察：DAG 让你的系统是"可解释的"——任何一个输出都能追溯到具体的执行路径。这在生产环境是不可妥协的，因为出了错你必须能 debug 出到底是哪一步出问题。
我布道了两年的事：先把任何你能想清楚的流程做成 DAG，只有当 DAG 真的表达不出来时再上 agent。这是给客户做生产系统最稳的路径。
Level 3：工具调用 Agent——把判断权交给 LLM
当你的流程里有一步根本无法在写代码时决定怎么做，就升级到 Level 3。比如"用户问了一个问题，模型自己判断要不要去查内部知识库、要不要去搜网络、要不要发邮件"。
Level 3 的本质是：把"控制流"从开发者手里交到模型手里。模型在一个 while 循环里反复判断、调用工具、读结果、决定下一步。
Dave 提到他们最近在 Level 2 系统的"边缘节点"（edge nodes）上引入 Level 3——也就是说，不是把整个系统换成 agent，而是在 DAG 的某个分支上 agent 化。 这是一种更保守也更可控的做法。
Level 4：多智能体协作
Level 4 是"多个 agent 互相调用"。这层在生产环境里非常稀少——因为一旦你有两个 agent 互相协作，调试和 eval 复杂度会指数级上升。
Dave 给的两个合理用例：
- 并行性：把大任务拆给多个 agent 同时跑（比如多源 deep research、多代码库并行探索）；
- 隔离上下文：需要一份"干净的"上下文来做事，不希望被主对话污染（比如代码生成后单独拉一个 agent 做 code review）。
除此之外，大多数声称"需要多 agent"的场景，其实一个主 agent + DAG 就够。多 agent 应该是最后才考虑的事。
Level 5：自治 Agent / Coding Harness
Level 5 是当下最热的方向——Claude Code、Cursor Agent、OpenClaw 这类"coding agent"。它们能：
- 跑任意 bash 命令；
- 读写本地文件；
- 执行 Python / Node 脚本；
- 上网搜索；
- 连续运行几十分钟甚至几小时。
Dave 用 Anthropic 自家的 Claude Agent SDK 演示了 Level 5 的能力。pip install claude-agent-sdk 就能拿到和 Claude Code 一样的内核能力，然后嵌到自己的应用里。
Level 5 非常强大，但也非常experimental——它能改你的文件系统、能执行任意代码、能联网。让这种能力在生产里裸跑，需要非常成熟的安全沙箱和可观测性。目前最适合的形态还是本地 CLI 工具，而不是面向终端用户的产品。
四五层对比表与决策矩阵
| 层级 | 名称 | 核心特征 | 自治程度 | 可解释性 |
|---|---|---|---|---|
| Level 1 | Augmented LLM | 单次 API call + 结构化输出 | 无（纯函数） | ⭐⭐⭐⭐⭐ |
| Level 2 | Workflow / DAG | 多节点编排、有向无环图 | 低（控制流确定） | ⭐⭐⭐⭐⭐ |
| Level 3 | Tool Calling Agent | LLM 在循环中自主选工具 | 中（部分） | ⭐⭐⭐ |
| Level 4 | Multi-Agent | 多 agent 互相调用 | 高 | ⭐⭐ |
| Level 5 | Autonomous / Coding Harness | 跑 bash / 写文件 / 联网 / 长时间运行 | 极高 | ⭐ |
决策矩阵：什么时候用哪一层？
| 业务场景 | 推荐层级 | 理由 |
|---|---|---|
| 工单分类、内容摘要、文档改写 | Level 1 | 单次调用足够，强上 agent 反而引入不确定性 |
| 客服工单处理（分类→查知识库→草拟回复→人工审核） | Level 2 为主，关键分支引入 Level 3 | 主干确定，少数步骤需要 LLM 自主判断 |
| 数据分析助手（用户问"上周销量最好的 SKU 是什么"） | Level 3 | 查询路径无法预判，必须 LLM 决定查什么 |
| 多源调研（同时查 5 个数据源做综合报告） | Level 4（多 sub-agent 并行） | 主 agent 串行太慢，并行子 agent 提速 |
| 开发任务自动化（写代码、跑测试、提 PR） | Level 5 | 需要完整 shell + 文件系统 + 长时间运行 |
五生产经验：Dave 给客户的"反常识"建议
视频后半段 Dave 分享了几个反直觉的生产经验——和当下"agent 万岁"的舆论明显不同：
1. 永远从 Level 1 开始
不要"先做个 agent，以后再优化"——一开始就上 Level 3+，debug 成本会让你后悔。Dave 说他们最近客户项目里 90% 都是 Level 1 + Level 2。
2. Level 2 是生产主力，Level 3 是补丁
主干永远用 DAG，只在某些边角节点上插入 agent。这样主干是确定的、可解释的，agent 失败不会拖垮整条流程。
3. Level 4 多 agent 慎用
除非真的需要并行性或上下文隔离，否则不要上多 agent。理由是 debug 难度和 eval 难度都会爆炸式增长。
4. Level 5 目前是工具，不是产品
Claude Code / OpenClaw 这类工具非常强，但目前最适合的形态还是开发者自己用的 CLI 工具，而不是直接打包成面向终端用户的产品。把它嵌到面向用户的产品里需要：
- 严格的沙箱（不允许它乱删文件）；
- 完整的 audit log（每一步操作可回放）；
- 成本控制（长时间运行可能烧掉几百美元 token）。
5. "复杂度溢出"是真实风险
Dave 反复警告一个他自己踩过的坑：项目一开始 Level 1 就够用，随着业务方需求增加，你开始加 edge case、加分支、加工具——半年后你打开系统图，发现已经是一个DAG 怪物：
从一个小而美的图开始，不断往里加东西，最后你会得到一个有 20 倍到 30 倍节点数的 Frankenstein（科学怪人）式 DAG——能跑，但没人敢动。
他的解法是：每加一个节点前先问一句"能不能用 Level 1 解决？"。如果可以，就别加。
六关键引用
当业务方跑来说"我们想要个 AI Agent"——先按住他们，问一句："你的流程能用 Level 1 描述吗？能用 Level 2 描述吗？" 如果可以，agent 不是答案。
我布道 Level 2 两年了。每次看到新客户想"搞个 agent"，我第一件事都是拉他们回到 DAG。DAG 是你最好的朋友——确定、可解释、能 debug。
Level 5 工具（Claude Code 之类）非常强大，但你要清醒：它能改你文件系统、能跑任意 bash、能联网。让这种东西在生产里裸跑，需要非常成熟的安全设计。
最近的趋势是：客户在主动减少 sub-agent 数量。因为模型越来越聪明，主 agent 能管的复杂度越来越大，sub-agent 的边际收益在变小。
Level 1 + Level 2 解决了客户 90% 的问题。多 agent 听起来性感，但 debug 起来要命。
七时间戳目录
📑 章节速览
- 引入：为什么做 AI 功能前要先选对复杂度层级
- 五层概览：从单次 LLM 调用到自治 agent
- Level 1：Augmented LLM + 结构化输出
- Level 2：DAG 编排，过去两年的生产主力
- Level 2 案例：客户支持工单处理的 DAG 实际拓扑
- Level 3：Tool calling agent 的"边缘节点"模式
- Level 4：多智能体协作的两个合理用例
- Level 5：自治 coding agent（Claude Agent SDK 演示）
- 真实生产系统：18 步客户支持 DAG 案例
- 反常识结论：先 Level 1，再 Level 2，最后才 Level 3+
- 社区与下一步
八术语速查表
| 术语 | 说明 |
|---|---|
| Augmented LLM | 最基础的 LLM 应用形态：一次 API call + 结构化输出，零自主决策 |
| DAG (Directed Acyclic Graph) | 有向无环图，多个 LLM 节点按确定路径编排，主流生产范式 |
| Tool Calling | LLM 在循环中自主决定调用哪些工具（API、数据库、文件等） |
| Edge Node | DAG 中被 agent 化的分支节点；主干仍是确定性流程 |
| Sub-agent | 多 agent 架构中的子智能体，由主 agent 调用 |
| Coding Harness | 能跑 bash / 写文件 / 联网 / 长跑的自治 agent 内核（Claude Code、OpenClaw 都基于此） |
| Claude Agent SDK | Anthropic 提供的 Python SDK，封装 Claude Code 同样的自治能力，可嵌到自定义应用 |
| Structured Output | 给 LLM 一个 JSON schema 强制按字段输出，把 LLM 从"聊天"变成"系统组件" |
九相关推荐
本视频与本站其他几篇 agent 主题文章互为补充，建议按以下顺序阅读：