PyLLM

主题

Agent 是什么：从 Chain 到自主决策 ​

到目前为止，我们构建的所有应用——无论是情感分析器、RAG 问答系统、还是多模态助手——都有一个共同的特征：它们的行为是预先确定好的。用户输入进来，数据沿着一条固定好的管道（Chain）流过各个组件，最终产生输出。整个过程中，模型不会"做决定"，它只是按照我们写好的流程被动地处理信息。

但现实世界中的很多任务不是这样线性的。比如你让一个助手"帮我调研一下 Python 和 Go 在并发性能上的差异，然后写一份对比报告"。这个任务需要：

  1. 先搜索 Python 并发的资料
  2. 再搜索 Go 并发的资料
  3. 可能还需要找一些基准测试数据
  4. 整理分析后写成报告
  5. 如果发现某个环节的信息不够，还要回去补充搜索

每一步该做什么、下一步往哪走，取决于当前获得了什么信息。 这种需要动态决策的场景，固定的 Chain 无法胜任。这就是 Agent（智能体） 登场的时刻。

Agent vs Chain：关键区别 ​

用一个最直观的类比来理解两者的区别：

Chain 像流水线工厂。原料从一端进去，经过一道道固定工序，产品从另一端出来。每道工序的位置和顺序是预先设计好的，不会因为原料的不同而改变。

用户问题 → [提示词模板] → [LLM] → [输出解析器] → 最终答案
            (固定步骤)     (固定步骤)    (固定步骤)

Agent 像一个有经验的员工。你给它一个目标，它自己决定先做什么、再做什么、用什么工具、做到什么程度算完成。如果中间遇到问题，它会调整策略；如果发现信息不足，它会主动去补充。

用户目标 → [Agent 大脑]
              ↓
         思考：我需要做什么？
              ↓
         决策：调用哪个工具？
              ↓
         行动：执行工具获取结果
              ↓
         观察：结果是什么？够不够？
              ↓
        （不够 → 回到"思考"继续循环）
        （够了 → 组织最终答案）

让我们用代码来感受这个区别：

python
# Chain 方式 — 固定流程，无决策能力
chain = prompt | chat | parser
result = chain.invoke({"question": "北京今天天气怎么样？"})

# 如果用户问的是完全不同的问题，Chain 还是走同样的流程
result = chain.invoke({"question": "帮我算一下 17 * 23 + 45"})
# Chain 不知道这需要计算器，它只会"基于训练知识猜"
python
# Agent 方式 — 有决策能力，能选择合适的工具
agent = create_react_agent(chat, tools=[search_tool, calculator_tool])

result = agent.invoke({"input": "北京今天天气怎么样？"})
# Agent 自己决定：这个问题需要用 search_tool

result = agent.invoke({"input": "帮我算一下 17 * 23 + 45"})
# Agent 自己决定：这个问题需要用 calculator_tool

同一个 Agent 对象面对不同的问题会做出不同的决策——这就是 自主性（Autonomy）。

Agent 的核心思维模式：ReAct ​

目前最主流的 Agent 架构叫做 ReAct（Reasoning + Acting），它定义了一个简洁而强大的思维循环：

Thought（思考）→ Action（行动）→ Observation（观察）→ Thought（思考）→ ...

这个过程不断重复，直到 Agent 认为任务完成了为止。让我们通过一个具体例子来看这个循环是如何运转的：

用户提问："2024 年巴黎奥运会中国代表团拿了多少枚金牌？"

Round 1 — Thought: 用户想知道巴黎奥运会中国的金牌数，我需要搜索最新信息。 Action: search("2024 Paris Olympics China gold medals")Observation: 中国代表团在 2024 年巴黎奥运会上获得 40 枚金牌...

Round 2 — Thought: 我已经找到了金牌数量是 40 枚。信息足够了，可以回答了。 Final Answer: 根据搜索结果，中国代表团在 2024 年巴黎奥运会上共获得 40 枚金牌。

整个过程只用了 2 轮就完成了。再看一个更复杂的例子：

用户提问："比较一下北京和上海今天的气温差多少度"

Round 1 — Thought: 需要知道北京和上海两地的温度，我先查北京的。 Action: search("北京今天气温")Observation: 北京今天晴，最高温 28°C，最低温 18°C

Round 2 — Thought: 北京的温度拿到了（28°C），现在查上海的。 Action: search("上海今天气温")Observation: 上海今天多云，最高温 32°C，最低温 25°C

Round 3 — Thought: 两地温度都拿到了，北京 28°C，上海 32°C，相差 4 度。 Final Answer: 今天北京最高温约 28°C，上海约 32°C，两地温差约为 4°C。

注意看 Round 3 的思考过程——Agent 不仅调用了工具，还在内部做了推理和计算（32 - 28 = 4）。这说明 Agent 不只是机械地调用工具，它真正地在"思考"。

Agent 的三大核心组件 ​

一个完整的 Agent 系统由三个核心部分组成：

1. LLM（大脑） ​

LLM 是 Agent 的"大脑"，负责所有的思考和决策工作。它需要回答的问题是：

  • 用户想让我做什么？
  • 我手头有哪些工具可以用？
  • 当前应该调用哪个工具？
  • 工具返回的结果够不够完成任务？
  • 还需要做什么？

这些决策全部由 LLM 通过生成文本的方式完成。所以 Agent 的智能程度直接取决于底层 LLM 的能力——更强的模型意味着更准确的决策和更少的无效循环。

2. Tools（工具） ​

工具是 Agent 的"手和脚"，是它用来与外部世界交互的手段。每个工具是一个封装好的函数，有明确的输入和输出：

python
@tool
def search(query: str) -> str:
    """搜索互联网获取信息"""
    # ... 调用搜索 API ...
    return "搜索结果..."

@tool
def calculator(expression: str) -> str:
    """计算数学表达式"""
    result = eval(expression)
    return str(result)

Agent 可以使用的工具越多，它能完成的任务就越复杂。常见的工具类型包括：

工具类型示例用途
搜索工具Google Search / Tavily / DuckDuckGo获取实时信息
计算工具Python REPL / Calculator数学运算
数据库查询SQL Database Tool查询结构化数据
API 调用Weather API / Stock API获取特定服务的数据
文件操作Read / Write / List Files读写本地文件
代码执行Python REPL / Shell运行代码
RAG 检索Retriever从知识库中查找信息

3. 执行引擎（Orchestrator） ​

执行引擎负责驱动 ReAct 循环——它把 LLM 的决策翻译成实际的函数调用，把工具的返回结果喂回给 LLM，并判断何时该停止循环。LangChain 提供了几种不同的执行策略：

  • ReAct Agent：最经典的模式，Thought→Action→Observation 循环
  • Plan-and-Execute Agent：先生成完整的执行计划，再逐步执行
  • OpenAI Functions Agent：利用 OpenAI 的 function calling 能力做结构化工具调用

我们在下一节会详细介绍每种模式的用法。

Agent 能做什么：典型应用场景 ​

理解了 Agent 的架构之后，你可能想知道它在实际中能解决哪些问题。以下是几个典型的应用场景：

场景一：研究助手 ​

用户："帮我调研一下 LangChain 和 LlamaIndex 在 RAG 方面的差异，写一份对比报告"

Agent 会自动：

  1. 搜索 LangChain RAG 的相关信息
  2. 搜索 LlamaIndex RAG 的相关信息
  3. 可能还会搜索第三方的对比评测
  4. 整理成结构化的报告

场景二：数据分析助手 ​

用户："读取 sales_2025.csv，告诉我 Q3 哪个产品线增长最快"

Agent 会自动：

  1. 使用文件读取工具加载 CSV
  2. 使用数据分析工具筛选 Q3 数据
  3. 使用计算工具找出增长最快的品类
  4. 给出结论

场景三：编程助手 ​

用户："帮我写一个 Flask API，实现用户注册和登录功能"

Agent 会自动：

  1. 搜索 Flask 最佳实践
  2. 编写代码（可能分多次写入文件）
  3. 检查代码是否有明显错误
  4. 给出使用说明

Agent 不是万能的 ​

在开始深入技术细节之前，有必要对 Agent 的能力边界建立正确的预期：

第一，Agent 会犯错。LLM 的决策并不总是正确的——它可能选错了工具、传错了参数、或者在应该停止的时候继续循环。这是当前 Agent 技术最大的挑战之一，也是活跃的研究方向。

第二，Agent 有成本。每次 ReAct 循环都包含一次 LLM 调用 + 一次工具调用。一个复杂任务可能需要 10-20 轮循环，这意味着 10-20 次 API 调用。相比简单的 Chain（只需 1 次），Agent 的成本可能高出一个数量级。

第三，Agent 有延迟。由于多轮循环的存在，响应时间比 Chain 长得多。简单问题可能需要 5-10 秒，复杂问题可能需要 30 秒甚至更长。对于需要即时反馈的场景，Agent 可能不是最佳选择。

第四，Agent 需要精心设计的工具。工具的质量直接决定了 Agent 的上限。如果你的搜索工具经常返回无关结果，或者你的计算工具不支持需要的运算符，Agent 再聪明也无能为力。

因此，是否使用 Agent 应该根据任务的复杂度和灵活性需求来判断：

  • 任务流程固定且简单 → 用 Chain
  • 任务需要动态决策和多步规划 → 用 Agent
  • 两者结合 → Chain 处理固定部分，Agent 处理灵活部分

接下来的一节，我们将深入学习如何定义和使用工具（Tools）——这是构建 Agent 最基础也最重要的技能。

基于 MIT 许可发布

版权所有 © 2024-至今