理解 Agent：从概念到实践

如果你正在学习 AI Agent 相关知识，却对"Agent 到底是什么"、"它和 Chatbot 有什么区别"、"什么时候该用什么时候不该用"感到困惑，这篇文章就是为你写的。

引言

2024-2025 年，"Agent" 成为 AI 领域最火热的词汇之一。从 LangChain 到 AutoGPT，从 OpenAI Assistants 到 Anthropic 的 Claude Code，几乎每个 AI 框架都在谈论 Agent。但越是热门的概念，越容易被滥用和误解。

很多初学者会把 Agent 等同于"更聪明的聊天机器人"，或者把一个简单的自动化脚本称为"Agent"。这些混淆不仅影响理解，还会导致在实际项目中做出错误的技术选型。

本文将从三个维度帮你建立清晰的认知框架：

1. 分清四个概念：Chatbot、Workflow、Agent、Multi-Agent 到底有什么区别？
2. 理解核心循环：Agent 是如何通过 "观察 → 思考 → 行动" 的循环来完成任务的？
3. 知道何时不用：什么时候 Agent 反而不如一个简单的脚本？

一、Chatbot、Workflow、Agent、Multi-Agent：四兄弟各司其职

很多人把这四个概念混为一谈，但它们代表了完全不同的系统架构和自主性级别。我们用一个生活化的类比来区分：

1.1 Chatbot — 前台接待员

核心特征：接收输入，生成响应，一问一答。

用户: "今天天气怎么样？"
Chatbot: "今天北京晴，气温 25°C。"

Chatbot 的本质是一个函数映射：输入一个问题，输出一个回答。它可以基于规则（关键词匹配），也可以基于大语言模型（LLM），但核心模式不变 —— 被动响应，无自主行动能力。

一句话总结：Chatbot 回答问题，但不会主动做事。

1.2 Workflow — 流水线工人

核心特征：预定义的步骤序列，按固定流程执行。

步骤1: 接收用户邮件
步骤2: 提取关键信息（姓名、订单号）
步骤3: 查询数据库
步骤4: 生成回复模板
步骤5: 发送邮件

Workflow 的本质是一条确定性的流水线。每个步骤的输入和输出都是预定义的，执行路径是固定的。你可以在 n8n、Zapier、GitHub Actions 等工具中构建它。

一句话总结：Workflow 按剧本演戏，每一步都是写好的。

1.3 Agent — 独立工作者

核心特征：自主决策、使用工具、动态调整策略来完成目标。

目标: "帮我调研 LangChain 和 LlamaIndex 的区别，写一份对比报告"

Agent 的行为:
  → 思考: 我需要搜索两个框架的信息
  → 行动: 调用搜索工具，查询官方文档
  → 观察: 获取到文档内容
  → 思考: 信息不够，我还需要看看社区评价
  → 行动: 搜索 GitHub issues、Reddit 讨论
  → 观察: 收集到足够的信息
  → 思考: 现在可以组织报告了
  → 行动: 生成对比报告

Agent 的本质是一个自主循环系统。它不像 Workflow 那样按固定路径走，而是根据每一步的结果动态决定下一步做什么。这正是 Agent 和 Workflow 最根本的区别 —— 控制流是运行时决定的，而不是预先编写好的。

一句话总结：Agent 是自己决定怎么做、做什么的工作者。

1.4 Multi-Agent — 协作团队

核心特征：多个 Agent 分工协作，共同完成复杂任务。

项目经理 Agent: 分解任务，分配给不同角色
  ├── 研究员 Agent: 负责信息搜集
  ├── 分析师 Agent: 负责数据分析
  └── 写手 Agent:   负责撰写报告

协作流程:
  项目经理 → 下发任务
  研究员 → 完成调研，提交结果
  分析师 → 基于调研结果进行分析
  写手 → 基于分析结果撰写报告
  项目经理 → 审核整合，交付最终成果

Multi-Agent 的本质是一个组织结构。每个 Agent 有自己的角色、职责和能力，通过通信协议协作。这类似于公司里的团队合作 —— 每个人做好自己的部分，项目经理负责协调。

一句话总结：Multi-Agent 是一个分工明确的团队，而非一个人。

1.5 一张图看懂四者关系

┌─────────────────────────────────────────────────┐
│                 自主性递增 →                      │
│                                                  │
│  Chatbot      Workflow       Agent    Multi-Agent │
│  ───────      ────────       ─────    ─────────── │
│  问答机器人    流水线执行      自主决策   团队协作    │
│                                                  │
│  输入→输出     A→B→C→D       目标→规划   角色→分工   │
│  被动响应      确定性流程      动态循环   分布式协作   │
│                                                  │
│  简单问答      自动化流程      复杂任务   大型项目    │
└─────────────────────────────────────────────────┘

关键洞察：这四种系统不是"好坏"的关系，而是适用场景不同。用 Agent 去做 Chatbot 能搞定的问答，是杀鸡用牛刀；用 Chatbot 去完成需要多步推理的任务，又力不从心。

二、Agent 的核心循环：Observe → Think → Act

理解了 Agent 是什么之后，我们来深入看看它是如何工作的。几乎所有 Agent 系统的核心都遵循同一个循环模式：

         ┌──────────┐
         │ Observe  │ ← 观察环境、获取信息
         └────┬─────┘
              │
              ▼
         ┌──────────┐
         │  Think   │ ← 分析信息、推理决策
         └────┬─────┘
              │
              ▼
         ┌──────────┐
         │   Act    │ ← 执行动作、影响环境
         └────┬─────┘
              │
              ▼
         ┌──────────┐
         │ Observe  │ ← 观察行动的结果
         └────┬─────┘
              │
              └──→ 回到 Think ... 循环继续

这个模式在学术界被称为 ReAct（Reasoning + Acting） 模式，源自 2022 年 姚顺雨 等人的论文 "ReAct: Synergizing Reasoning and Acting in Language Models"。

2.1 三个阶段详解

Observe（观察）

Agent 从环境中获取信息。这些信息可以来自：

• 用户输入：用户说的话、提的要求
• 工具返回：搜索引擎的结果、API 的响应、代码执行的输出
• 环境状态：文件系统的变化、数据库的内容、网页的内容
• 上一轮的结果：自己之前做了什么、成功还是失败

# 示例：Agent 观察到的信息
observation = {
    "user_request": "帮我找到项目中所有的 TODO 注释",
    "tool_result": "在 src/main.py 第 42 行找到 TODO: 需要优化这个函数",
    "previous_action": "调用了 grep 工具搜索 TODO 关键词"
}

Think（思考）

Agent 基于观察到的信息进行推理和决策。这是 Agent 最核心的能力 —— 它不只是处理信息，而是理解信息并做出判断。

思考过程可能包括：

• 任务分解：这个大目标可以拆成哪些小步骤？
• 策略选择：下一步我应该做什么？用什么工具？
• 结果评估：上一步的结果符合预期吗？需要调整吗？
• 终止判断：任务完成了吗？可以结束了吗？

# 示例：Agent 的思考过程（由 LLM 驱动）
thought = """
我已经找到了 15 个 TODO 注释。
用户要求的是"所有"TODO，我需要确保搜索覆盖了整个项目。
目前只搜索了 .py 文件，还需要搜索 .js、.ts、.java 等文件。
下一步：扩大搜索范围到所有代码文件。
"""

Act（行动）

Agent 执行具体的操作来影响环境。常见的行动包括：

• 调用工具：搜索、读写文件、执行代码、调用 API
• 生成内容：写报告、写代码、回复用户
• 修改状态：更新数据库、发送消息、创建文件

# 示例：Agent 的行动
action = {
    "tool": "grep",
    "parameters": {
        "pattern": "TODO|FIXME|HACK",
        "glob": "**/*.{py,js,ts,java,go,rs}",
        "path": "/project/src"
    }
}

2.2 一个完整的例子

假设你让 Agent "帮我查一下 Python 3.12 有什么新特性，整理成一个要点列表"：

🔄 循环 1:
  Observe: 用户要求查询 Python 3.12 新特性
  Think:   我需要搜索 Python 3.12 的官方发布说明
  Act:     调用搜索工具，搜索 "Python 3.12 new features"

🔄 循环 2:
  Observe: 搜索结果返回了 Python 官方文档链接和几篇技术博客
  Think:   官方文档最权威，我先读取官方文档
  Act:     调用网页抓取工具，读取 Python 3.12 官方 What's New 页面

🔄 循环 3:
  Observe: 获取到了详细的特性列表，包括模式匹配增强、错误消息改进等
  Think:   信息足够了，我可以整理成要点列表了
  Act:     生成结构化的要点列表，返回给用户

✅ 任务完成

2.3 循环的终止条件

Agent 不能无限循环下去，需要有明确的终止条件：

实践建议：一定要设置终止条件。没有终止条件的 Agent 就像没有刹车的汽车 —— 理论上能跑，实际上很危险。

2.4 为什么这个循环如此重要？

这个 "Observe → Think → Act" 循环赋予了 Agent 三个关键能力：

1. 适应性：根据观察到的结果动态调整策略，而不是机械地执行预定义步骤
2. 自我纠错：如果行动的结果不符合预期，Agent 可以在下一轮观察中发现问题并修正
3. 渐进式完成：复杂任务可以被分解成多轮循环逐步完成，每轮都在前一轮的基础上推进

这正是 Agent 区别于 Workflow 的本质 —— Workflow 的控制流是预先写死的，而 Agent 的控制流是在运行时通过 Think 阶段动态决定的。

三、什么时候不该用 Agent？

这是最容易被忽视的部分。在 Agent 热潮中，人们很容易陷入"万物皆可 Agent"的思维陷阱。但事实是：很多场景下，Agent 不仅不是最佳选择，反而会带来负面影响。

3.1 可预测的任务 — 用脚本就够了

如果一个任务的输入、处理逻辑和输出都是确定的，你不需要 Agent。

❌ 过度设计:
   用 Agent 来"智能地"将 CSV 文件转换为 JSON

✅ 正确做法:
   用一个 Python 脚本:
   import csv, json
   with open('data.csv') as f:
       data = list(csv.DictReader(f))
   with open('data.json', 'w') as f:
       json.dump(data, f, indent=2)

判断标准：如果你能在写代码之前完整描述每一步操作，那它就是一个脚本任务，不是 Agent 任务。

3.2 流程稳定的场景 — 用 Workflow 更可靠

如果业务流程是固定的、经过验证的、不需要动态决策的，用 Workflow 比 Agent 更好。

❌ 不必要的灵活性:
   用 Agent 来"自主决定"如何处理订单退款

✅ 更好的方案:
   用 Workflow 定义清晰的退款流程:
   1. 验证退款请求是否符合条件
   2. 检查订单状态
   3. 计算退款金额
   4. 调用支付网关执行退款
   5. 发送退款通知邮件

为什么 Workflow 更好？ 因为：

• 可预测性：每次执行结果一致，便于测试和调试
• 可审计性：流程清晰，出问题容易定位
• 成本更低：不需要 LLM 推理的开销
• 速度更快：没有 LLM 调用的延迟

3.3 Agent 的隐性成本

使用 Agent 不是免费的，它带来以下成本：

3.4 决策框架：该不该用 Agent？

遇到一个新任务时，用下面的流程图来判断：

开始
  │
  ▼
任务的步骤是否完全确定？
  │
  ├─ 是 → 用脚本或 Workflow
  │
  └─ 否 ↓
       │
       ▼
     是否需要动态决策（根据中间结果选择不同路径）？
       │
       ├─ 否 → 用 Workflow（固定分支）
       │
       └─ 是 ↓
            │
            ▼
          任务是否涉及非结构化输入（自然语言、图像等）？
            │
            ├─ 否 → 考虑用规则引擎或传统算法
            │
            └─ 是 ↓
                 │
                 ▼
               错误的后果是否可控？
                 │
                 ├─ 否 → 加入人工审核环节，或不用 Agent
                 │
                 └─ 是 → ✅ 使用 Agent

3.5 反面案例：Agent 的"翻车"现场

案例 1：用 Agent 做数据清洗

一个团队用 Agent 来"智能清洗"客户数据。Agent 在某一轮循环中"判断"某些邮箱格式不对，于是自动"修正"了它们 —— 把 user@company.co.uk 改成了 user@company.com。结果导致大量英国客户的邮件发送失败。

教训：数据清洗的规则是确定的，用正则表达式和脚本更安全。

案例 2：用 Agent 做自动化部署

一个 Agent 被赋予了部署权限，在一次"优化部署"的过程中，它判断旧版本的容器"已经不需要了"，于是主动删除了正在运行的生产环境容器。

教训：高风险操作需要确定性的审批流程，不应该交给 Agent 自主决策。

3.6 什么时候该用 Agent？

反过来说，Agent 真正有价值的场景是：

• 信息搜集与综合：需要从多个来源收集信息、交叉验证、生成报告
• 开放性问题：没有唯一正确答案，需要探索和推理
• 多工具协调：需要根据情况动态选择使用哪些工具
• 非结构化处理：输入是自然语言、需求模糊、需要理解意图
• 研究与分析：需要多步推理、假设验证、迭代深入

总结

Agent 的核心循环 Observe → Think → Act 赋予了它自主决策和动态调整的能力，但也带来了不确定性、成本和安全风险。

最重要的一条原则：

不要因为 Agent 很酷就用 Agent。选择最简单、最可靠、最可预测的方案来解决问题。

技术选型不是炫技，而是在能力、成本和风险之间找到平衡。理解 Agent 的本质，才能在正确的场景下发挥它的价值。

参考资料

• ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)
• Building effective agents — Anthropic
• A Survey on Large Language Model based Autonomous Agents