慕雪的小助
慕雪小助手的总结
DeepSeek & LongCat

欢迎阅读慕雪撰写的AI Agent专栏，本专栏目录如下

  1. 【MCP】详细了解MCP协议：和function call的区别何在？如何使用MCP？
  2. 【AI】AI对26届及今后计算机校招的影响
  3. 【Agent.01】AI Agent智能体开发专题引言
  4. 【Agent.02】市面上常见的大模型有哪些？
  5. 【Agent.03】带你学会写一个基础的Prompt
  6. 【Agent.04】AI时代的hello world：调用OpenAI接口，与大模型交互
  7. 【Agent.05】OpenAI接口Function Calling工具调用详解
  8. 【Agent.06】使用openai sdk实现多轮对话
  9. 【Agent.07】什么是Agent？从Chat到ReAct的AI进化之路

本专栏的所有代码都可以在https://gitee.com/musnows/agent-blog找到。

在前面几篇文章中，我们已经学习了如何与大模型交互、如何写好Prompt、如何进行Function Calling等基础知识。现在，我们终于来到了这个专栏的核心主题——Agent。

本文有部分内容由AI辅助编写，仅供参考

1. 写在前面

说到Agent，很多人可能会觉得这是一个很复杂的概念。但其实，Agent的本质就是一个能够自主思考和行动的AI助手。

如果说Chat LLM是一个只能说话的顾问，那么Agent就是一个既能说话又能干事的智能助手。这个转变，就是通过我们前面学习的Function Calling和Agent框架来实现的。

本文将从概念层面带大家理解Agent到底是什么，它和传统的Chat LLM有什么区别，以及它是如何工作的。

2. Agent和Chat LLM的区别

要理解Agent，首先要知道它和我们平时使用的Chat LLM（比如DeepSeek的网页聊天框）有什么本质区别。

2.1. Agent和Chat的区别？

传统的Chat LLM就像是只能说话的顾问，你问它答，一问一答的。它没有记忆，每次对话都是独立的，只能生成文本回答，没办法真正帮你做事。而Agent则完全不同，它能主动思考问题，规划执行步骤，还能调用各种工具和API来完成任务。Agent是有状态的，能记住之前的对话内容，可以处理复杂的多步骤任务。

当然啦，现在很多AI的网页端也在进化，开始加入网络搜索、代码知识库这些工具功能，算是朝着Agent的方向转变了（比如豆包）。但我们这里说的，还是最核心的概念区别。

2.2. 为什么需要Agent？

想象一下这个场景：你需要AI帮你预订一张机票。

Chat LLM的处理方式：

plaintext
1
2
3
4
5
6
用户：帮我预订一张明天从北京到上海的机票
Chat LLM：对不起，我无法直接预订机票。但我可以告诉你如何操作：
1. 打开携程/去哪儿/飞猪等订票网站
2. 输入出发地：北京，目的地：上海
3. 选择出发日期：明天
4. 选择航班并完成支付...

Agent的处理方式：

plaintext
1
2
3
4
5
6
7
用户：帮我预订一张明天从北京到上海的机票
Agent：[思考]用户需要预订机票，我需要：
1. 搜索可用航班
2. 选择合适的航班
3. 执行预订操作
[行动]调用search_flights工具 → [分析结果] → 调用book_flight工具 → [完成任务]
Agent：已为您成功预订明天从北京到上海的CA1234航班，08:30起飞，票价1280元。预订号：BK123456789。

这就是本质区别：Chat LLM只能"说"，而Agent能"做"。这一点，在先前的Function Calling章节已经展示给大家了。

在AI时代，我们需要的不仅仅是一个能聊天的助手，更需要一个能帮我们解决实际问题的智能助手。

Agent的出现解决了很多现实问题：

  1. 首先是任务自动化，一些涉及到决策的复杂的多步骤任务，现在可以让Agent自动完成，大大减少了人工干预。
  2. 然后是工具集成，Agent能够调用各种API和工具，这样AI的能力边界就被大大扩展了，能够和几乎任何已有的系统进行集成和协作，完全打破了原始的只能通过OpenAPI人工编写脚本进行定死的任务处理的范式。
  3. 更重要的是智能决策，Agent可以根据实际情况自主判断和选择最佳解决方案。而且通过与环境交互，Agent还能不断优化自己解决问题的策略。

特别是在软件开发、数据分析、客户服务这些场景中，Agent的价值就更加明显了。比如本专栏最终要实现的测试用例生成Agent，就能自动完成代码分析、测试用例编写、覆盖率检查这一整套复杂的任务流程。

不过需要注意的是：Agent并不是万能的，只有涉及到需要利用大模型的思考能力进行决策的场景，才有必要使用Agent来实现。如果是一些诸如静态扫描代码流水线、自动化脚本测试这种已经“固定死”的场景，没有必要盲目蛮干的上Agent，没有任何意义，甚至会降低效果！

简单来说，一个任务中，需要根据数据进行下一步操作决策的节点越多，就越适合引入Agent。反之，如果没有什么需要动态决策的场景，一个传统的写死的脚本依旧是更好的选择。

3. Agent的ReAct工作原理

3.1. 什么是ReAct？

ReAct（Reasoning and Acting，推理-行动）是Agent最核心的工作机制。这个概念是Google在2022年提出的，现在已经成为了Agent框架的标准设计模式。

ReAct的核心思想其实很简单，就是让Agent像人类一样思考问题，然后采取行动。具体来说包含三个步骤：首先是推理，Agent会分析当前的情况，制定一个行动计划；然后是行动，根据计划执行具体的工具调用或操作；最后是观察，看看行动的结果如何，然后根据结果调整策略。

这个过程会不断循环进行，直到任务完成为止。

3.2. ReAct工作流程图

下面是一个典型的Agent ReAct工作流程：

否

是

否

是

否

是

接收用户任务

理解任务需求

分析任务复杂性

需要工具调用?

直接生成回答

完成任务

规划执行步骤

选择合适工具

调用工具/函数

获取执行结果

分析结果质量

任务完成?

更新策略/信息

需要更多工具?

继续推理分析

生成最终回答

3.3. ReAct的具体步骤

让我们用一个具体的例子来说明ReAct是如何工作的。假设用户要求：“帮我分析这个Python文件的性能瓶颈并生成优化建议”。

Step 1: Reasoning（推理）

plaintext
1
2
3
4
5
6
7
8
9
10
Agent思考：用户需要我分析Python文件的性能瓶颈。我需要：
1. 读取Python文件内容
2. 分析代码结构和复杂度
3. 识别潜在的性能问题
4. 生成优化建议

需要的工具：
- file_reader：读取文件
- code_analyzer：分析代码
- performance_profiler：性能分析

Step 2: Acting（行动）

python
1
2
3
4
5
6
# 调用file_reader工具
file_content = file_reader("performance_test.py")
# 调用code_analyzer工具
analysis_result = code_analyzer(file_content)
# 调用performance_profiler工具
performance_report = performance_profiler(file_content)

Step 3: Observation（观察）

plaintext
1
2
3
4
5
Agent观察结果：
- 文件读取成功，共156行代码
- 代码分析发现3个嵌套循环
- 性能分析显示时间复杂度为O(n³)
- 内存使用量较大

Step 4: 再次Reasoning（二次推理）

plaintext
1
2
3
4
5
6
Agent思考：根据分析结果，我发现了以下性能问题：
1. 三重嵌套循环导致时间复杂度过高
2. 大量重复计算
3. 内存使用未优化

现在需要生成具体的优化建议和代码示例。

Step 5: 最终Action（最终行动）

plaintext
1
Agent生成最终的优化报告和改进代码。

ReAct这种机制有很多优势。首先是透明性，Agent每一步的推理过程都是可见的，这样我们就能很方便地调试和优化它的行为。然后是灵活性，Agent可以根据中间得到的结果随时调整策略，而不是死板地按照预设流程执行。还有可控性，我们可以在关键节点设置检查点，确保Agent不会"跑偏"。最后是扩展性，可以很轻松地集成新的工具和能力。

正是这种"思考-行动-观察"的循环机制，让Agent具备了真正的智能行为，能够处理那些复杂的、需要多步骤才能完成的任务。

4. Agent SDK与OpenAI接口的关系

4.1. 从底层到高层的关系

在我们前面学习的内容中，我们接触了三个层次的东西：直接用requests调用OpenAI API，使用OpenAI Python SDK，以及现在要学习的Agent框架。

这三者之间是什么关系呢？我们可以用一个生活中的例子来理解。

  • 直接调用OpenAI API就像手动炒菜，你需要自己控制火候、掌握时间、放调料等等所有细节，虽然很灵活但操作起来特别复杂。
  • 使用OpenAI SDK就像用电饭煲，它把底层的网络请求和响应处理都封装好了，你只需要把米放进去按下按钮就行，可以更专注于业务逻辑。
  • 而使用Agent SDK就更像去餐厅点餐了，你只需要告诉服务员你想要吃什么菜，后厨也就是Agent框架会自动处理所有的烹饪流程，你等着上菜就行。

简单来说，这三个东西的封装层次越来越高，也就是一个依赖链条：

HTTP

OpenAI接口

OpenAI SDK

Agent SDK

Agent工具,如cursor

现在已经有非常多的开源Agent SDK以及封装好的Agent工具，为我们节省了很多工作。本专栏不会告诉大家如何搓一个Agent SDK出来，而是直接转向Agent SDK的应用。

4.2. Agent SDK的架构层次

下面是Agent SDK的架构层次图：

用户输入

Agent SDK

ReAct控制器

Prompt管理器

工具管理器

状态管理器

系统Prompt构建

Function Calling处理

对话历史维护

OpenAI SDK

OpenAI API

大模型

模型响应

SDK解析

工具执行

结果处理

最终输出

4.3. Agent SDK帮我们做了什么？

Agent SDK本质上是在OpenAI SDK的基础上，封装了以下功能：

首先，是自动化的ReAct循环管理，下面是一个伪代码，展示了二者的区别：

python
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 原始方式：我们需要手动管理
def manual_agent(user_input):
    messages = [{"role": "system", "content": system_prompt}]
    messages.append({"role": "user", "content": user_input})

    # 手动调用API
    response = openai.chat.completions.create(...)

    # 手动检查是否需要工具调用
    if response.choices[0].message.tool_calls:
        # 手动执行工具
        # 手动构建第二次请求...
        pass

###################################################

# Agent SDK方式：自动管理
from some_agent_sdk import Agent

agent = Agent(
    tools=[tool1, tool2, tool3],
    model="gpt-4"
)

result = agent.run("帮我预订机票")  # SDK自动处理所有ReAct循环

总而言之言而总之，Agent SDK帮我们把上下文管理、工具管理、工具调用、工具返回结果处理等等逻辑都封装好了，不再需要我们自己去解析OpenAI接口的Function Calling返回格式进行处理，也不需要关注Agent在多轮对话中对工具调用状态的思考等等事项。

我们只需要把prompt、模型、工具传入给Agent SDK，剩下的全由Agent SDK代劳！

4.4. 常见的Agent SDK

名称 开发语言 核心特点 仓库/官方链接
OpenAI Agents SDK Python 官方轻量型Agent SDK，支持多Agent协作、工具调用、会话记忆，原生集成OpenAI模型 官方文档/仓库
LangChain Python/JS 生态最成熟，支持OpenAI等多LLM集成，提供完整Agent工作流（工具、记忆、编排） GitHub
Microsoft AutoGen Python 专注多Agent对话协作，深度兼容OpenAI模型，适合复杂任务分工与自动化执行 GitHub
CrewAI Python 轻量级团队式Agent框架，默认支持OpenAI模型，角色定义清晰、任务分配灵活 GitHub
LangGraph Python 状态机式Agent框架，无缝集成OpenAI模型，擅长复杂流程控制与步骤化任务执行 GitHub

5. The end

好啦，通过这篇文章的学习，咱们算是把Agent的核心概念和工作原理搞清楚了。

Agent的核心工作机制就是ReAct，也就是推理-行动-观察的循环。Agent会先分析情况制定计划，然后执行工具调用，观察结果并调整策略，这个循环让Agent具备了真正的智能行为。

后续，将以OpenAI Agent SDK为例，为大家展示一个最最简单的Agent的代码编写。