《Agent 学习路线：从工具调用到任务执行系统》

30. Agent 需要解决什么问题

Agent 主要用来解决普通聊天模型不擅长的问题。

普通模型更适合：

• 回答问题
• 总结文本
• 改写内容
• 生成代码片段
• 解释概念

而 Agent 更适合：

• 多步骤任务
• 需要调用外部工具的任务
• 需要读取文件、分析数据、生成结果的任务
• 需要搜索、判断、再执行的任务
• 需要长期上下文和任务状态的任务

例如：

帮我分析这个项目的代码结构，找出主要模块，并生成一份 README。

这个任务不是一次回答就能完成的。Agent 可能需要：

1. 读取项目目录
2. 分析文件结构
3. 打开关键代码文件
4. 总结模块功能
5. 判断启动方式
6. 生成 README 文档

这类任务就非常适合 Agent。

---

31. Agent 的核心组成

一个 Agent 系统一般由以下几个部分组成：

大模型
  ↓
任务规划
  ↓
工具调用
  ↓
记忆系统
  ↓
执行环境
  ↓
结果反馈

31.1 大模型

大模型是 Agent 的“大脑”。

它负责理解用户目标、拆解任务、判断下一步应该做什么，以及根据工具返回的结果继续推理。

31.2 任务规划

任务规划是 Agent 的关键能力。

例如用户说：

帮我做一个个人知识库问答系统。

Agent 不能只回答一句“可以使用 RAG”。它应该拆解为：

1. 明确需求
2. 选择技术栈
3. 设计文档处理流程
4. 设计向量检索流程
5. 设计 Prompt 模板
6. 编写后端接口
7. 编写前端页面
8. 测试问答效果
9. 优化检索质量

任务规划决定了 Agent 是否能处理复杂问题。

31.3 工具调用

工具调用让 Agent 具备执行能力。

常见工具包括：

• 搜索工具
• 浏览器工具
• 文件读写工具
• 数据库工具
• Python 执行器
• Shell 命令
• API 接口
• 邮件工具
• 日历工具

没有工具调用，Agent 仍然只是一个会说话的模型。

有了工具调用，Agent 才能真正完成任务。

31.4 记忆系统

记忆系统用于保存上下文、历史信息或用户偏好。

可以分为：

• 短期记忆：当前对话上下文
• 长期记忆：跨会话保存的信息
• 任务记忆：任务执行过程中的中间状态
• 知识记忆：文档、数据库、知识库内容

例如，一个写作 Agent 可以记住用户喜欢的文章风格；一个项目管理 Agent 可以记住项目目标、成员分工和当前进度。

31.5 执行环境

执行环境是 Agent 真正运行任务的地方。

例如：

• 在 Python 环境中分析 CSV
• 在 Shell 中运行测试命令
• 在浏览器中打开网页
• 在数据库中执行查询
• 在文件系统中创建和修改文件

执行环境越强，Agent 能完成的任务越复杂。

31.6 结果反馈

Agent 每执行一步，都需要观察工具返回的结果。

例如：

执行代码 -> 报错 -> 分析报错 -> 修改代码 -> 再执行

这个过程就是：

Action -> Observation -> Reasoning -> Next Action

Agent 的强大之处就在于它可以根据反馈不断调整行为，而不是一次性生成答案。

---

32. Agent 的基本工作流程

一个典型 Agent 的工作流程可以表示为：

用户提出目标
  ↓
Agent 理解任务
  ↓
拆解执行步骤
  ↓
判断是否需要工具
  ↓
调用工具
  ↓
读取工具结果
  ↓
判断任务是否完成
  ↓
继续执行或输出最终结果

例如用户输入：

帮我查找最近的 AI 新闻，并总结成一篇公众号文章。

Agent 可能会执行：

1. 搜索最近 AI 新闻
2. 筛选重要事件
3. 读取新闻内容
4. 提取关键信息
5. 判断哪些内容适合公众号
6. 组织文章结构
7. 写出标题、摘要和正文
8. 输出最终文章

这个过程比普通问答更复杂，因为它包含搜索、筛选、判断、写作等多个步骤。

---

33. ReAct：Agent 的经典思路

ReAct 是 Reasoning and Acting 的缩写，可以理解为“推理 + 行动”。

它的基本模式是：

Thought -> Action -> Observation -> Thought -> Action -> Observation

也就是：

思考下一步
  ↓
执行动作
  ↓
观察结果
  ↓
继续思考

例如：

用户：帮我找出这个代码为什么运行失败。

Thought：我需要先查看报错信息。
Action：读取日志文件。
Observation：发现缺少某个依赖包。

Thought：需要检查 requirements.txt。
Action：读取 requirements.txt。
Observation：依赖包没有写入。

Thought：需要补充依赖并重新运行。
Action：修改依赖文件并执行安装。
Observation：程序可以正常运行。

Final：问题原因是缺少依赖，已经修复。

ReAct 思路非常适合理解 Agent 的基本运行方式。

---

34. Agent 和 Workflow 的区别

学习 Agent 时，很容易把 Agent 和 Workflow 混在一起。

Workflow 是固定流程。

例如：

上传文件 -> 解析文件 -> 提取文本 -> 调用模型总结 -> 输出结果

每一步都是提前设计好的。

Agent 则更灵活。

它可以根据当前情况决定下一步做什么。

例如：

如果文件是 PDF，就解析 PDF；
如果文件是 CSV，就分析表格；
如果文件是代码项目，就读取目录结构；
如果出现错误，就先修复错误。

可以简单理解：

类型	特点	适合场景
Workflow	流程固定、稳定可控	标准业务流程
Agent	流程动态、灵活决策	开放式复杂任务

实际项目中，不一定非要做纯 Agent。

很多成熟系统会采用：

Workflow + Agent

也就是大流程固定，局部环节让 Agent 自主决策。

这种方式通常更可靠，也更适合真实业务落地。

---

35. Agent 常见应用场景

35.1 数据分析 Agent

数据分析 Agent 可以读取 Excel、CSV 或数据库，然后自动分析数据。

典型任务：

• 读取数据字段
• 清洗缺失值
• 生成统计结果
• 绘制图表
• 总结业务发现
• 输出分析报告

例如：

帮我分析这个销售数据，找出销售额下降的原因，并生成图表。

35.2 编程 Agent

编程 Agent 可以辅助开发、调试和重构代码。

典型任务：

• 阅读项目结构
• 修改代码
• 运行测试
• 分析报错
• 修复 bug
• 生成文档
• 重构模块

例如：

帮我给这个 FastAPI 项目增加用户登录功能。

35.3 搜索研究 Agent

搜索研究 Agent 可以完成资料收集和研究总结。

典型任务：

• 搜索资料
• 阅读网页
• 对比信息
• 提取观点
• 生成报告
• 附带引用来源

例如：

帮我调研一下目前主流 RAG 框架的优缺点。

35.4 办公自动化 Agent

办公自动化 Agent 可以处理邮件、日历、文档和表格。

典型任务：

• 总结邮件
• 安排会议
• 生成会议纪要
• 整理待办事项
• 修改文档
• 生成汇报材料

例如：

帮我总结今天的邮件，并列出需要我回复的事项。

35.5 个人助理 Agent

个人助理 Agent 可以帮助用户管理日常任务。

典型任务：

• 日程规划
• 学习计划
• 旅行规划
• 信息整理
• 提醒事项
• 长期目标跟踪

例如：

帮我制定一个三个月学习大模型应用开发的计划。

---

36. 学习 Agent 需要掌握哪些基础

学习 Agent 需要的知识可以分为五层。

模型基础
  ↓
Prompt 基础
  ↓
工具调用
  ↓
任务编排
  ↓
工程落地

36.1 模型基础

需要理解：

• LLM 的输入输出
• Token 和上下文窗口
• temperature 等参数
• 模型幻觉
• Prompt 约束
• 多轮对话上下文

不需要一开始就训练模型，但要知道模型擅长什么、不擅长什么。

36.2 Prompt 基础

Agent 中的 Prompt 不只是普通提问，而是用于控制模型行为。

例如：

你是一个任务执行 Agent。
你需要先分析用户目标，再决定是否调用工具。
不要编造工具结果。
如果工具返回失败，需要说明原因并尝试修复。

Agent Prompt 通常要定义：

• 角色
• 任务目标
• 可用工具
• 工具使用规则
• 输出格式
• 错误处理方式

36.3 工具调用基础

需要理解：

• Function Calling
• JSON 参数
• API 请求
• 工具返回值
• 错误处理
• 权限控制

一个简单工具可以设计成：

{
  "name": "search_docs",
  "description": "从知识库中搜索相关文档",
  "parameters": {
    "query": "用户搜索问题"
  }
}

模型负责决定什么时候调用工具，以及传入什么参数。

36.4 编排框架

常见 Agent 编排框架包括：

• LangChain
• LangGraph
• LlamaIndex
• AutoGen
• CrewAI
• Semantic Kernel

这些框架可以帮助我们管理：

• 多步骤流程
• 工具调用
• 状态保存
• 多 Agent 协作
• 错误重试
• 任务图编排

初学时不建议一上来就追求复杂框架。

可以先手写一个简单 Agent，再学习框架。

36.5 工程能力

Agent 真正落地时，工程能力非常重要。

需要掌握：

• Python
• HTTP API
• 数据库
• 文件系统
• 日志
• 异常处理
• Docker
• 权限控制
• 成本控制
• 监控告警

Agent 系统不是只有 Prompt，它本质上是一个完整的软件系统。

---

37. Agent 学习路线

如果以应用开发为目标，可以按照下面路线学习：

Prompt 工程
  ↓
大模型 API 调用
  ↓
Function Calling
  ↓
工具封装
  ↓
简单 Agent 循环
  ↓
RAG + Agent
  ↓
LangGraph / LangChain
  ↓
多 Agent 协作
  ↓
Agent 工程化部署

37.1 第一阶段：Prompt 和 API

目标是会调用大模型，并能写出稳定的 Prompt。

需要完成：

• 调用大模型 API
• 理解 messages 格式
• 设置 system prompt
• 控制输出格式
• 使用 JSON 输出
• 处理流式输出

练习项目：

做一个命令行 AI 助手，可以回答问题、总结文本、生成代码。

37.2 第二阶段：Function Calling

目标是让模型学会调用工具。

需要完成：

• 定义工具名称
• 编写工具描述
• 设计参数 schema
• 解析模型生成的工具调用
• 执行工具函数
• 把工具结果返回给模型

练习项目：

做一个天气查询助手：
用户输入城市，模型自动调用天气工具，并生成自然语言回答。

37.3 第三阶段：简单 Agent 循环

目标是理解 Agent 的核心执行过程。

可以实现一个最小 Agent：

while 任务未完成:
    模型思考下一步
    如果需要工具:
        调用工具
        返回观察结果
    否则:
        输出最终答案

练习项目：

做一个文件分析 Agent：
用户给一个文件路径，Agent 可以读取文件、总结内容，并根据需要继续分析。

37.4 第四阶段：RAG + Agent

目标是让 Agent 可以使用知识库。

需要完成：

• 文档切分
• embedding 向量化
• 向量数据库存储
• 相似度检索
• 检索结果重排
• 基于资料回答
• 引用来源

练习项目：

做一个个人知识库 Agent：
可以上传 Markdown、PDF、TXT 文件，然后基于资料回答问题。

37.5 第五阶段：使用 Agent 框架

目标是学习成熟框架的设计方式。

可以选择：

LangGraph

重点学习：

• State
• Node
• Edge
• Conditional Edge
• Tool Node
• Checkpoint
• Human-in-the-loop

练习项目：

做一个研究报告 Agent：
输入主题后，自动搜索资料、整理大纲、生成报告，并允许人工修改。

37.6 第六阶段：多 Agent 协作

多 Agent 是指让不同角色的 Agent 协同完成任务。

例如：

产品经理 Agent -> 需求分析
架构师 Agent -> 技术方案
开发 Agent -> 编写代码
测试 Agent -> 运行测试
文档 Agent -> 生成说明

多 Agent 不一定总是更好，因为它会增加成本和复杂度。

适合在任务明显可以分工时使用。

37.7 第七阶段：工程化部署

目标是让 Agent 可以稳定运行在真实环境中。

需要关注：

• 权限控制
• 工具调用安全
• 日志记录
• 失败重试
• 成本统计
• 用户反馈
• 任务状态保存
• 并发处理
• 服务部署

练习项目：

做一个 Web 版 Agent 助手：
支持用户登录、文件上传、知识库问答、工具调用和历史记录。

---

38. 一个最小 Agent 示例

下面用伪代码表示一个最简单的 Agent 思路：

tools = {
    "calculator": calculator,
    "search_docs": search_docs,
    "read_file": read_file,
}

messages = [
    {
        "role": "system",
        "content": "你是一个可以调用工具完成任务的 Agent。"
    }
]

while True:
    user_input = input("User: ")
    messages.append({"role": "user", "content": user_input})

    response = call_llm(messages, tools=tools)

    if response.tool_call:
        tool_name = response.tool_call.name
        tool_args = response.tool_call.arguments

        result = tools[tool_name](**tool_args)

        messages.append({
            "role": "tool",
            "name": tool_name,
            "content": result
        })

        final_response = call_llm(messages)
        print(final_response.content)

    else:
        print(response.content)

这个示例虽然简单，但已经包含 Agent 的关键思想：

模型判断是否需要工具
  ↓
系统执行工具
  ↓
工具结果返回模型
  ↓
模型生成最终回答

---

39. Agent 开发中的常见问题

39.1 工具描述不清楚

如果工具描述不清楚，模型可能不知道什么时候调用工具。

错误示例：

{
  "name": "query",
  "description": "查询信息"
}

更好的写法：

{
  "name": "search_knowledge_base",
  "description": "当用户问题需要从内部知识库查找资料时，调用该工具。输入应是简洁明确的搜索关键词。"
}

39.2 工具权限过大

Agent 可以调用工具，也意味着它可能误操作。

例如：

• 删除文件
• 修改数据库
• 发送邮件
• 提交订单
• 执行危险命令

因此需要设计权限边界。

常见做法：

• 高风险操作需要用户确认
• 工具参数要校验
• 限制可访问目录
• 限制可执行命令
• 记录操作日志

39.3 缺少状态管理

复杂任务往往需要保存状态。

例如：

当前执行到第几步？
已经读取了哪些文件？
哪些子任务完成了？
哪些工具调用失败了？

如果没有状态管理，Agent 很容易重复执行、遗漏步骤或陷入循环。

39.4 缺少错误处理

工具调用可能失败。

例如：

• 网络超时
• 文件不存在
• API 限流
• 参数错误
• 权限不足
• 数据库连接失败

Agent 系统需要告诉模型错误原因，并允许它选择下一步。

例如：

工具返回：文件不存在。
Agent 下一步：检查路径是否写错，或询问用户重新提供文件。

39.5 过度依赖 Agent

不是所有任务都需要 Agent。

如果任务流程固定，普通 Workflow 更稳定、更便宜。

例如：

上传发票 -> OCR -> 提取字段 -> 存数据库

这种任务更适合固定流程，而不是完全交给 Agent 自主决定。

---

40. Agent 项目实践路线

学习 Agent 最好的方式是做项目。

可以按下面顺序练习。

40.1 项目一：命令行工具调用 Agent

功能：

• 用户在命令行输入问题
• 模型判断是否需要调用工具
• 支持计算器工具
• 支持时间查询工具
• 支持简单文本处理工具

目标：

理解工具调用的完整过程。

40.2 项目二：文件阅读 Agent

功能：

• 读取本地 txt、md、csv 文件
• 总结文件内容
• 根据用户问题查找相关片段
• 输出结构化回答

目标：

理解文件工具和上下文管理。

40.3 项目三：个人知识库 Agent

功能：

• 上传文档
• 自动切分
• 生成 embedding
• 存入向量数据库
• 根据问题检索相关内容
• 基于资料回答
• 给出引用来源

目标：

掌握 RAG 和 Agent 的结合。

40.4 项目四：代码助手 Agent

功能：

• 读取项目目录
• 分析代码结构
• 定位 bug
• 修改代码
• 运行测试
• 生成说明文档

目标：

理解 Agent 在软件开发中的应用。

40.5 项目五：研究报告 Agent

功能：

• 根据主题搜索资料
• 提取关键信息
• 自动生成大纲
• 写出报告正文
• 整理参考来源

目标：

理解搜索、阅读、总结、写作的多步骤任务。

---

41. Agent 工程化需要注意什么

Agent 从 Demo 到真实项目，中间还有很大距离。

真实项目中要重点关注：

41.1 稳定性

Agent 不应该无限循环，也不应该重复调用同一个工具。

可以设置：

• 最大执行步数
• 最大工具调用次数
• 超时时间
• 失败重试次数
• 终止条件

41.2 可控性

用户应该知道 Agent 做了什么。

例如：

我读取了 3 个文件，调用了 2 次检索工具，最终根据以下资料生成回答。

可控性越强，用户越容易信任 Agent。

41.3 安全性

高风险工具必须加限制。

例如：

• 发邮件前确认
• 删除文件前确认
• 修改数据库前确认
• 支付下单前确认
• 执行 Shell 命令前检查

41.4 可观测性

需要记录：

• 用户请求
• 模型输入
• 模型输出
• 工具调用参数
• 工具返回结果
• 执行耗时
• 错误日志
• 用户反馈

否则系统出错时很难排查。

41.5 成本控制

Agent 往往会多次调用模型和工具，因此成本可能比普通问答更高。

可以通过以下方式控制成本：

• 限制最大执行步数
• 使用小模型处理简单任务
• 对检索结果进行压缩
• 缓存重复结果
• 控制上下文长度
• 对长任务拆分阶段执行

---

42. Agent 和 RAG 的关系

RAG 解决的是“从哪里找知识”的问题。

Agent 解决的是“如何完成任务”的问题。

二者可以结合：

Agent 负责规划任务
RAG 负责提供知识
工具负责执行动作
模型负责推理和生成

例如：

用户：帮我根据公司文档写一份产品介绍。

系统可以这样工作：

1. Agent 分析任务
2. RAG 检索公司产品文档
3. Agent 判断是否还需要更多资料
4. 再次检索相关案例
5. 模型生成产品介绍
6. Agent 检查是否符合格式要求
7. 输出最终内容

所以，RAG 可以看作 Agent 的一种重要工具。

---

43. Agent 和微调的关系

Agent 不一定需要微调。

大多数 Agent 项目可以先通过：

• Prompt
• Tool Calling
• RAG
• Workflow
• 规则约束

来实现。

微调更适合解决以下问题：

• 模型总是不按固定格式输出
• 某类任务模式非常稳定
• 需要特定行业表达风格
• 需要减少复杂 Prompt 的长度
• 需要提高某类任务的一致性

但如果问题是知识更新，优先考虑 RAG，而不是微调。

可以简单总结：

Agent 解决任务执行问题。
RAG 解决知识获取问题。
微调解决行为模式问题。

---

44. Agent 学习建议

学习 Agent 时，不建议一开始就追求复杂概念。

更好的路线是：

1. 先写一个普通大模型 API 调用
2. 再加入一个简单工具
3. 再让模型自动选择工具
4. 再加入多轮执行循环
5. 再加入文件读取能力
6. 再加入 RAG
7. 再学习 LangGraph 等框架
8. 最后考虑多 Agent 和工程化部署

学习过程中要多做小项目。

不要只看概念，因为 Agent 的难点往往出现在工程细节中：

• 工具参数设计
• 错误处理
• 状态保存
• 上下文控制
• 成本控制
• 权限安全
• 输出稳定性

真正理解 Agent，必须亲手实现至少一个可以运行的小系统。

---

45. Agent 总结

Agent 是大模型应用从“问答工具”走向“任务执行系统”的重要方向。

它的核心不是让模型变得神秘，而是把模型放进一个可以执行任务的系统中：

模型负责理解和推理
工具负责连接外部世界
记忆负责保存上下文
流程负责控制执行过程
工程系统负责稳定运行

一句话总结：

Agent = 大模型 + 工具 + 规划 + 记忆 + 执行反馈。

学习 Agent 的关键不是一开始就做复杂系统，而是从最小闭环开始：

模型判断工具 -> 调用工具 -> 观察结果 -> 继续回答

只要理解了这个闭环，就掌握了 Agent 的核心思想。