- 结论一句话：下一步做什么，由谁决定——代码决定 = workflow，模型决定 = agent，没有”下一步” = chatbot，多个模型各管一段 = multi-agent。
一、小白版：请人办事的四种方式
| 类比 | 他做的事 | |
|---|---|---|
| Chatbot | 问路人 | 你说一句他答一句，答完结束，他不动手 |
| Workflow | 去银行办业务 | 柜员按固定流程走：取号→验证→填表→签字。顺序事先定死，AI 只是”填表”那一环 |
| Agent | 请了个助理 | 你说”帮我订下周去上海最便宜的机票”，下一步干什么他自己判断；没票了自己改方案 |
| Multi-agent | 请了个团队 | 一个查资料、一个写稿、一个审稿，各干各的、各有各的记忆，最后汇总 |
类比的失效边界（重要）
- 助理类比会让人以为 agent 有常识和长期记忆。实际它只有「当前上下文 + 一份工具清单」，上下文一长就忘或跑偏，也不会主动找你确认——除非你专门设计了这个动作。
- 团队类比会让人以为多 agent 一定更强。实际”各干各的”既是优点（互不污染）也是代价：信息必须显式传递，token 成本翻倍，一个环节错会被后面放大。
二、专业版：三条判定线
判定线 1：有没有「行动能力」→ 区分 chatbot
只会生成文本、不能调外部函数 = chatbot。能让模型去执行一个函数（tool call，工具调用）= 迈进了自动化门槛。
判定线 2：控制流归谁 → 区分 workflow / agent
这是唯一真正的分界线，不是”用没用 LLM”，也不是”复杂不复杂”。
| 下一步由谁定 | 有循环吗 | |
|---|---|---|
| Workflow | 开发者写在代码里的 if/else、图、DAG | 有边，但边是代码画的 |
| Agent | 模型在运行时输出「我要调哪个工具」 | 有，观察→决策→行动→再观察 |
一个 agent 至少需要三件套：工具 + 循环 + 基于观察修正。缺任何一个，它就是个 workflow 节点。
工程上的经典建议：能 workflow 就别 agent。workflow 可预测、可测试、便宜、能定位 bug；agent 的路径是运行时才生成的，测不了全路径，成本不可控。
边界提醒：单次 tool call 是临界情况。如果模型调完工具、看到结果后又自己决定”再查一次”，那就跨进 agent 了。所以分界线不是”有没有调工具”，而是调完之后谁决定下一步。
判定线 3：上下文是否隔离 → 区分 agent / multi-agent
关键在”独立上下文”，不在”多个 prompt”。 同一个对话历史里让模型扮演三个角色轮流发言，那是单 agent 的角色扮演（role prompting），不是 multi-agent。
真正的 multi-agent：每个 agent 有自己的消息历史，靠显式的消息传递或共享状态通信。
判据只有两条：独立上下文 + 独立决策。
「角色不同」是最常见的应用形态，不是定义——三个完全相同的 agent 各自独立上下文并行审查同一份代码，也是 multi-agent。
两种常见形态（都不是必需的）：
- 有中心：一个 orchestrator（编排者）分活、汇总
- 无中心：agent 之间直接互相发消息
隔离带来两个真实收益：① 长任务里各自的上下文不被无关信息污染；② 可以并行。代价是通信开销和错误传播。
一张总表
| 下一步谁定 | 工具 | 循环 | 独立上下文数 | |
|---|---|---|---|---|
| Chatbot | 没有”下一步” | 无 | 无 | 1 |
| Workflow | 代码 | 可有（在固定节点内） | 图的边，非模型定 | 1 或 N（靠代码传值） |
| Agent | 模型 | 有 | 有 | 1 |
| Multi-agent | 多个模型各自定 | 有 | 各自可有 | ≥2 |
三、术语对照表
| 小白说法 | 专业术语 |
|---|---|
| 会聊天的 AI | chatbot |
| 把流程写死、AI 只填空 | workflow / pipeline / DAG 编排 |
| AI 自己决定下一步 | agent / 自主循环（agentic loop） |
| AI 去执行一个函数 | tool call / function calling |
| 干完一步看看结果再决定 | ReAct 循环（推理-行动-观察） |
| 让 AI 扮演几个角色说话 | role prompting（不是 multi-agent） |
| 几个 AI 各自有记忆、互相传话 | multi-agent / 多智能体 |
| 几个 AI 共用一个状态 | 共享状态编排（shared state orchestration） |
四、最容易理解错的三个地方
- “多写几个 prompt 就是 multi-agent”——类比成”多写几个函数就是微服务”。判据是上下文是否隔离，不是 prompt 数量。
- “Agent 就是 workflow 加几个 LLM 节点”——反了。加了 LLM 节点但流程仍由代码画，那是 workflow 的增强版。分界线是边的归属：if/else 是代码写的还是模型输出的。
- 拿前端状态管理类比 agent 状态：相似处是”单一事实源、集中管理”；失效处是前端 store 的结构你完全掌控，而 agent state 里会混进模型自由生成的字段——所以 schema 校验必须放在边界上做，不能假设模型老实（对应前端”错误边界”，但这里要校验的是数据形状，不只是异常）。
五、自测题与作答（2026-09-21）
题 1：固定流程 + LLM 选了一次工具，是 workflow 还是 agent？
我的作答：这是一个 workflow，这里的 agent 或者 prompt 的调用，本质上是 workflow 中的一个节点，因为这里面没有循环加基于观测观察的修正。
判定：✅ 正确。 判据抓准了——循环 + 基于观察的修正。
补一层边界：单次 tool call 是临界情况。如果模型调完工具、看到结果后又自己决定”再查一次”，那就跨进 agent 了。分界线不是”有没有调工具”，是调完之后谁决定下一步。
题 2：同一模型扮演三角色、共用一份对话历史，是 multi-agent 吗？
我的作答：这是单个 agent，不是 multiple agent。真正的 multiple agent 是要基于不同的角色，然后指定一个 agent，agent 之间用显示的消息进行共享。
判定：⚠️ 方向对，但有一处概念漏洞。
- 「这是单个 agent，不是 multi-agent」——对。
- 「真正的 multi-agent 是要基于不同的角色」——错。角色不同不是必要条件，是常见形态。判据只有两条：独立上下文 + 独立决策。
- 「指定一个 agent」——如果指”有个总协调者”，那也不是必需的；有中心（orchestrator）和无中心（agent 互发消息）两种形态都存在。
- 「显示的消息」→ 应为「显式的消息」：explicit（明明白白写在代码里的传递）≠ display（画出来给人看）。
最小改动（改成真 multi-agent）：把三个角色从”共用一份 messages”改成”各自一份 messages“，PM 的输出显式作为 input 传给工程师（传字符串，不共享历史）。就这一步。
题 3：举两个你会故意选 workflow 而不选 agent 的理由
我的作答：一个理由是，固定流程的场景下，我们会选用 workflow。其他的想不到了。
判定：✅ 一个对，但只是同一理由的正面说法。 换个角度就能多出好几条：
- 可测试：路径固定 → 能写单测、能重放、能定位 bug。agent 的路径运行时才生成，测不全。
- 成本可预估：token 数和调用次数算得出来。agent 可能绕远路，甚至死循环烧钱。
- 可审计：每一步”为什么这么走”是代码写的，能对客户/监管解释。金融、医疗这类场景绕不开。
- 破坏面可控：agent 自主决策可能做出不可逆操作（删数据、发邮件）。workflow 能做的坏事是有限的。
再加一条最实用的：这俩不是二选一。工业界常见形态是「workflow 骨架 + 关键节点里塞一个 agent」——流程你来定，只在”真的需要判断”的那一步把决定权交给模型。（Anthropic, Building Effective Agents 的核心建议）
六、本次结论
容易把常见形态当成定义。 以后遇到任何概念题，先问一句：”这是定义，还是典型案例？”
- 本次踩坑点：把 multi-agent 的”角色不同”当成了必要条件（实际是充分条件/常见形态）。
- 待复习：下次重考「multi-agent 的判据是什么」+「workflow vs agent 的分界线在哪」。