学习笔记：如何理解 Chatbot、Workflow、Agent 和 Multi-Agent

原文信息

• 标题：如何理解Chatbot、Workflow、Agent 和 Multi-Agent（AI Agent 学习笔记 Stage 0）
• 作者：墨衍（n0vvay，CSDN：m0_46225620）
• 发布时间：2026-05-29
• 原文链接：https://blog.csdn.net/m0_46225620/article/details/161484193
• 定位：AI Agent 学习的 Stage 0 预备笔记，梳理四个基础概念

〇、一句话总结（TL;DR）

区分 Chatbot / Workflow / Agent / Multi-Agent 的核心标准，不是"有没有用大模型"，也不是"有没有调工具"，而是——谁在决定下一步做什么。

一、核心判断标准：控制权归属

判断一个系统属于哪一类，关键问一个问题：

谁在决定下一步做什么？

Chatbot：    用户推进对话，模型负责回答
Workflow：   代码控制流程，模型只是某个处理节点
Agent：      模型控制流程，动态决定下一步行动
Multi-Agent：多个 Agent 分工协作，共同推进任务

要点：流程仍由代码固定控制 → 即使调用了 LLM，也仍然更接近 Workflow。只有当模型能根据状态、工具结果和目标约束动态决定后续步骤时，系统才真正具有 Agent 特征。

二、Chatbot：会对话，但不真正接管任务

核心能力：根据用户输入生成自然语言回复。可以有上下文、可以接知识库，但通常不主动推进外部任务。

User Input → LLM → Answer

关键辨析：RAG ≠ Agent

User Input → Retrieve Documents → LLM → Answer

这个系统虽然用了检索工具，但检索流程是系统预先固定的——模型并没有自主决定"是否需要检索、检索什么、失败后如何调整"。因此它只是带检索能力的 Chatbot，不是完整 Agent。

适用与限制

三、Workflow：流程由代码控制，LLM 只是其中一个节点

定义：通过预定义流程完成任务，每一步由开发者提前设计好。

Input → Step1 解析输入 → Step2 检索/调用工具 → Step3 调用 LLM 生成内容 → Step4 格式化输出 → Output

关键点：下一步做什么由代码决定，而不是由模型决定。

优势 vs 限制

重要观点

Workflow 并不低级。 任务路径清晰、规则稳定、输入输出明确时，Workflow 往往是比 Agent 更可靠的选择。

四、Agent：由 LLM 动态控制任务流程

核心特征：大语言模型不只是生成回复，而是根据当前状态决定下一步行动。

最小 Agent 的三要素

Agent 会围绕目标持续执行：根据当前上下文、工具返回结果和任务状态，决定下一步是继续检索、调用工具、修改计划、请求用户确认，还是输出最终结果。

五、Agent 的基本循环：Observe → Think → Act → Observe

Observe → Think → Act → Observe → ...

Agent 不是一次性生成最终答案，而是执行过程中不断观察、判断、行动，再根据行动结果更新状态。

循环四阶段的工程含义

Agent Loop 工程化伪代码

while not done:
    context = build_context(task_state, memory, observations)
    decision = llm(context, tools)

    if decision.type == "final_answer":
        return decision.answer

    if decision.type == "tool_call":
        if not permission_check(decision.tool_name, decision.args):
            return request_human_confirmation()
        result = execute_tool(decision.tool_name, decision.args)
        observations.append(result)

    if step_count > max_steps:
        return stop_with_reason("exceed max steps")

伪代码体现的基本要素：上下文构建、模型决策、工具调用、权限检查、结果观察、循环停止。一个真正可用的 Agent 系统，不能只关注模型输出，还必须设计这些工程边界。

六、Agent 和 Workflow 的根本区别（分水岭）

Workflow 是代码决定下一步，Agent 是模型决定下一步。

Agent 示例（生成技术调研报告时可能动态决定）：解析目标 → 判断是否需检索 → 调搜索工具 → 发现资料不足则调整关键词重新检索 → 对比不同来源 → 整理中间结论 → 判断是否补代码示例/图表 → 生成结构化报告。这些步骤并非开发者提前写死，而是根据中间观察结果动态调整。

Agent 适合什么任务

• 多步骤任务
• 路径不确定的任务
• 需要调用多个工具的任务
• 需要根据中间结果调整计划的任务
• 需要长期状态管理的任务
• 用户只给目标、没给完整执行步骤的任务

Agent 的代价（不是银弹）

成本更高、延迟更长、行为更难预测、调试更复杂；需要权限控制、trace 记录、失败恢复机制、系统化评测。

七、什么时候不该用 Agent？

常见误区：只要任务复杂就马上用 Agent。Agent 的价值在于处理动态、不确定、多步骤、需要工具交互的任务；任务本身稳定时，用 Agent 反而增加不确定性。

| # | 情况 | 更合适的方案 |
| - | -------------------------------- | ------------------------------------- |
| 1 | 任务流程高度可预测（输入/步骤/输出都稳定） | 普通函数、脚本或 Workflow |
| 2 | 流程稳定且规则明确（每步可提前确定） | Workflow（即使用 LLM 也不必上 Agent） |
| 3 | 几十行脚本就能稳定解决 | 普通脚本（上 Agent 是过度设计） |
| 4 | 准确性/权限/安全要求极高（删数据、发消息、财务操作、生产变更） | Agent 辅助分析提建议，关键动作加人工确认 + 权限控制 + 审计日志 |
| 5 | 缺少评测标准（无法定义成败、没有测试样例和执行日志） | 先补评测体系，不急于部署 |

如果无法评估 Agent 是否完成任务，就不要急于把它放进真实业务流程。

八、Multi-Agent：多个 Agent 的分工协作

注意：Multi-Agent 不是"让多个角色互相聊天"这么简单。真正有工程价值的 Multi-Agent 需要明确的职责划分、通信协议、调度方式和停止条件。

两种常见模式

Manager Pattern（中心管理式）：一个中心管理 Agent 负责拆解任务、分配任务、汇总结果。

User → Manager Agent ├─ Search Agent ├─ Coding Agent ├─ Writing Agent └─ Review Agent → Final Answer

适合任务边界清晰的复杂任务（如内容生成拆成：检索 / 生成 / 事实检查 / 格式整理）。

Handoff Pattern（转交式）：任务在不同 Agent 之间转交，每个 Agent 负责自己擅长的部分，完成后把上下文交给下一个。

User → Planning Agent → Search Agent → Analysis Agent → Writing Agent

优势 vs 问题

Multi-Agent 是复杂系统的组织方式，不是提高智能的魔法。 一个 Single Agent 加几个工具就能完成任务时，没必要一开始就引入 Multi-Agent。

九、四者对比总结表

表中最重要的一列是"谁控制流程"——这是区分四者的核心标准。

十、用同一个任务理解四者区别

任务：生成一份技术主题调研报告（背景、核心概念、相关工作、优缺点分析、总结）。

十一、判断一个系统是不是 Agent 的五个问题

1. LLM 是否能决定下一步做什么？
2. 系统是否能调用外部工具，并根据工具结果继续行动？
3. 系统是否维护任务状态（已做了什么、失败了什么、下一步候选是什么）？
4. 系统是否有明确退出条件（完成任务 / 最大步数 / 工具失败 / 需要人工确认）？
5. 系统是否有权限边界（发消息、删文件、运行命令、改代码前是否需确认）？

无法回答这些问题的系统，可能只是一个"看起来像 Agent"的 prompt 套壳。

十二、工程实践中的升级顺序

普通函数 / 脚本 → Workflow → Single Agent → Multi-Agent

• 普通脚本能解决 → 不需要 Workflow
• 稳定 Workflow 能解决 → 不需要 Agent
• Single Agent 能解决 → 不需要 Multi-Agent

这不是保守，而是工程理性。Agent 系统的目标不是让架构看起来复杂，而是让任务更可靠地完成。

十三、Agent 系统的完整组成

Agent System = LLM + Tools + Instructions + Agent Loop + State + Memory
             + Permissions + Trace + Evaluation + Interfaces + Skills

学习 Agent 不应只停留在 prompt 编写层面，更要理解 agent runtime、工具调用、上下文管理、权限边界、执行轨迹和评测体系。

十四、记忆锚点与常见误区（个人整理）

四个记忆锚点：

1. "谁决定下一步"是唯一分水岭——不看用没用 LLM、调不调工具，只看控制权在用户、代码还是模型。
2. Agent Loop = Observe → Think → Act → Observe——Agent 的本质是循环，不是单次生成。
3. 升级路径要逐级验证：脚本 → Workflow → Single Agent → Multi-Agent，每多上一级就多一份复杂度、成本和不可预测性。
4. 没有评测就没有 Agent——无法评估成败的系统，不要放进真实业务流程。

常见误区：

• ❌ 接了 RAG 就是 Agent → ✅ 检索流程写死的话只是带检索的 Chatbot
• ❌ 任务复杂就该上 Agent → ✅ 路径稳定的任务 Workflow 更可靠
• ❌ 多 Agent 更高级 → ✅ Multi-Agent 默认更复杂，不是默认更强
• ❌ Agent 能自主执行一切 → ✅ 高风险动作必须有人工确认、权限控制和审计

十五、Stage 0 思考题（学完后自测）

1. 目标任务是什么？
2. 这个任务中哪些步骤是固定的？
3. 哪些地方存在不确定性？
4. 哪些地方需要调用外部工具？
5. 哪些地方需要根据中间结果改变计划？
6. 普通 Workflow 能解决到什么程度？
7. 为什么需要 Agent？
8. 是否真的需要 Multi-Agent？如果需要，应该如何拆分？

对初学者来说，这个思考题比直接套用某个 Agent 框架更重要——只有先理解任务边界，后面学 tool calling、memory、MCP、agent runtime、evaluation 和 safety 时，才不会陷入"框架 API 背得很多，但系统设计仍然混乱"的状态。

参考资料

1. Agent-Learning-Hub: AI Agent 学习路线与资料整理 — https://github.com/datawhalechina/Agent-Learning-Hub
2. OpenAI: A Practical Guide to Building Agents — https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
3. Anthropic: Building Effective Agents — https://www.anthropic.com/research/building-effective-agents