学习https://github.com/datawhalechina/Agent-Learning-Hub笔记：区分 Chatbot、Workflow、Agent、Multi-Agent

今天主要学习了 agent 系统里的几个基础概念：chatbot、workflow、agent、multi-agent。最大的收获是：它们的区别不在于“是不是用了大模型”，也不只是“有没有工具”，而在于谁决定下一步怎么做。

一、Chatbot：对话式交互

Chatbot 的核心是对话。用户提出问题，模型给出回答，整体节奏由用户主导。

它可以有工具，也可以没有工具。现在的 ChatGPT、Claude 等产品已经能上传文件、看图片、联网、运行代码，所以不能简单说“能调用工具就是 agent”。更准确的区分是：

chatbot 主要是在回应用户；agent 则是在主动推进任务。

比如“解释这段代码”“帮我总结这篇文章”更像 chatbot；而“读取整个项目、定位问题、修改代码、运行测试、根据结果继续修复”就更接近 agent。

二、Workflow：固定或半固定流程

Workflow 是由人或程序预先设计好的流程。模型可能参与每一步，但整体路径通常是确定的。

例如：

输入问题 → 分类 → 检索资料 → 生成答案 → 检查 → 输出

哪怕里面设计了多个角色，比如 adviser、executor、critic、summarizer，只要流程、循环、停止条件是提前写好的，它本质上还是 workflow。

今天一个重要修正是：多角色不等于 multi-agent。很多“角色扮演式 agent”其实只是 workflow 中的多个 LLM 调用。

三、Agent：目标驱动的动态循环

Agent 的关键是：模型不只是回答问题，而是围绕目标，观察环境、思考下一步、采取行动，再根据反馈继续调整。

基本循环可以概括为：

observe → think → act → observe

也就是：

观察当前状态 → 判断下一步 → 调用工具或执行动作 → 读取结果 → 继续决策

所以 agent 的重点不是“权限更大”，而是有一定自主决策能力。它可以根据任务状态选择工具、修改计划、处理失败、决定是否继续或停止。

我现在对 agent 的理解是：

agent 是一个由 LLM 驱动的任务执行系统，它能根据目标和环境反馈，动态决定下一步行动。

四、什么时候不该用 Agent

这是今天很重要的一点。Agent 很灵活，但也带来不确定性、成本和调试难度。

不适合 agent 的情况包括：任务路径非常明确；流程稳定、可预测；普通脚本或固定 workflow 就能解决；对结果稳定性要求很高，但不需要复杂判断；每一步都必须严格可控。

这时强行使用 agent，可能不是“更智能”，而是把一个简单问题复杂化。

更好的原则是：

能用脚本就别用 workflow，能用 workflow 就别急着用 agent，能用单 agent 就别急着拆 multi-agent。

五、Multi-Agent：多个 Agent 的协作系统

Multi-agent 不是简单地“多个角色聊天”，而是多个 agent 围绕同一目标协作，每个 agent 有自己的职责、上下文、工具权限或工作边界。

典型例子：

planner 负责拆解任务

researcher 负责搜索资料

executor 负责执行

reviewer 负责检查质量

supervisor 负责调度和终止

它的优点是职责更清晰、上下文不容易混乱、复杂任务可以拆开处理。但它也有明显代价：通信成本更高、协调更难、调试更复杂。

所以 multi-agent 适合在这些情况下使用：单个 agent 的提示词太复杂；工具太多，容易选错；任务确实需要不同专业能力；不同部分需要不同权限；上下文需要隔离，但结果又需要汇总。

六、对两篇文章的 2026 视角

今天读了两篇文章：

Anthropic: Building effective agents，发布于 2024-12-19。
网址：​编辑https://www.anthropic.com/engineering/building-effective-agents

OpenAI: A practical guide to building agents，面向工程和产品团队的 agent 实践指南。
网址：https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/

截至 2026 年，它们的核心思想仍然有借鉴意义：先判断是否真的需要 agent；优先从简单方案开始；区分 workflow 和 agent；把工具设计清楚；给 agent 设置边界、停止条件和人工介入点；不要过早拆成 multi-agent；要做评估、监控和错误处理。

但也有一些内容需要带着保留看：具体框架、SDK、模型名称、API 写法可能已经变化；2024 到 2025 年的 agent 产品形态，到 2026 年已经更成熟，比如浏览器 agent、代码 agent、电脑操作 agent、MCP 工具生态等；文章中的具体工具推荐不一定是最新最佳实践；对 multi-agent 的工程实现方式，2026 年已经更强调 orchestration、权限隔离、可观测性和安全边界；不能只按文章里的示例照搬，应该结合当前官方文档和实际项目需求。

所以我的判断是：

这些文章的概念框架没有过时，但具体实现细节需要用 2026 年的新工具、新 SDK、新模型重新校准。

七、今天的总结

今天我对四个概念的区分更清楚了。

Chatbot：下一步主要由用户决定，特点是对话问答为主。

Workflow：下一步主要由预设流程决定，特点是稳定、可控，适合确定性任务。

Agent：下一步主要由模型根据目标和环境反馈决定，特点是动态、开放，能自主推进任务。

Multi-Agent：下一步由多个 agent 或 supervisor 协调决定，特点是适合复杂任务和职责拆分。

最重要的一句话：

判断一个系统是不是 agent，不是看它有没有大模型，也不是看它有没有工具，而是看它能不能基于目标和环境反馈，自主决定下一步行动。