AI Agent 学习路线
目录
1.第一步：Prompt + Function Calling
1.第一步：Prompt + Function Calling
请看【LLM&&AI应用开发 八股文】--2.Prompt与调用基础-CSDN博客的2、7章节
2.第二步：建立 Agent 认知
Agent到底是什么？和普通大模型问答有什么区别？
2.1.LLM为"告诉你怎么完成"
先别急着定义 Agent，我们从最熟的普通问答说起。
普通大模型问答是什么？
就是用户输入一句话，模型根据上下文生成一段回复。
比如你问：
帮我解释一下 Redis 为什么快？
模型会回答：
Redis 快，主要因为它基于内存、单线程避免锁竞争、使用 IO 多路复用、数据结构高效……
这就是典型的大模型问答。
它可以很聪明，可以讲得很细，也可以帮你写代码、改简历、总结文章。
但它有一个核心特点：它主要是在生成文本。
你让它讲 Redis，它讲给你听。
你让它写 SQL，它把 SQL 写出来。
你让它分析日志，它只能基于你贴给它的日志分析。
这类系统的交互方式很简单：
用户给问题 -> 模型生成答案 -> 用户继续追问。
整个过程中，模型大多数时候没有真正"动手"。
它不知道你的数据库现在有什么数据，不会自己去查监控，不会自己打开系统后台，不会自己执行脚本，也不会在发现第一步失败后自动换方案。
所以普通问答更像一个知识很强的顾问。
它能给建议，但行动还得你来做。
2.2.Agent是"帮你完成"
Agent 的关键不是更会说，而是更会做。
这句话很重要。
普通问答的核心产物是"答案"。
Agent 的核心产物是"完成任务的过程和结果"。
举个例子。
你对普通大模型说：
帮我分析一下这个网站为什么最近转化率下降。
如果是普通问答，它可能会给你一套分析思路：
- 看流量来源有没有变化
- 看页面加载速度有没有变慢
- 看按钮点击率有没有下降
- 看最近有没有改版
- 看用户反馈里有没有负面信号
这些建议可能都对，但你还是要自己去查数据。
如果是一个真正的 Agent，它应该能做更多事：
- 先拆解问题：转化率下降可能来自流量、页面、价格、性能、用户路径。
- 调用数据工具：查最近 30 天 PV、UV、点击率、跳出率、支付转化。
- 调用日志工具：看接口延迟、错误率、页面加载耗时。
- 对比历史数据：找出异常时间点。
- 生成初步结论：比如"移动端支付页加载时间从 1.2 秒涨到 4.8 秒"。
- 继续验证：查看是否和某次发布有关。
- 最后输出结论和建议：哪个环节出问题，证据是什么，下一步怎么修。
你看，这里已经不是"回答问题"了。它是在围绕一个目标，自己决定下一步做什么，并不断根据结果调整。这才是 Agent 的味道。
2.3.Agent 至少要有四个能力
先记住这四个能力：规划、工具、执行、反馈。
没有这四个东西，很多所谓 Agent 其实只是披了个名字。
1. 规划：知道任务要怎么拆
用户给 Agent 的往往不是一个简单问题，而是一个目标。
帮我整理一下这个仓库的技术债，并给出优先级。
这不是一句话能答完的。
Agent 需要先拆任务：
- 先看项目目录
- 再看核心模块
- 再看最近提交
- 再找重复代码、复杂函数、缺测试的地方
- 再判断哪些问题影响最大
- 最后整理成报告
这一步就是规划。
没有规划，Agent 就会变成想到哪做到哪。
很多 Agent 翻车，就是因为计划不稳定：一开始说要检查测试，跑着跑着忘了；一开始说要分析全仓库，最后只看了两个文件就开始总结。
2. 工具：能连接外部世界
没有工具，Agent 很多时候只能"会说不会做"。
工具可以是：
- 搜索工具
- 数据库查询工具
- 文件读写工具
- 代码执行工具
- 浏览器工具
- 业务 API
- 发邮件、发消息、创建工单的接口
工具的意义，是让模型从"文本生成器"变成"能操作环境的执行者"。
比如用户问：
帮我查一下昨天订单失败最多的原因。
普通问答只能说："你可以从支付失败、库存不足、风控拦截几个方向排查。"
Agent 应该能调用订单数据库，查失败码分布，再调用日志系统看异常接口，最后给出真实结论。
这就是 Function Calling / Tool Use 为什么重要。
它不是 Agent 的附属能力，而是 Agent 行动能力的入口。
3. 执行：一步一步把任务跑完
会规划不等于会执行。
很多模型特别擅长列计划：
第一步，收集数据；第二步，分析问题；第三步，输出报告。
听起来很完整，但真正执行时就散了。
因为执行不是写计划，而是把每一步真的做完。
比如查数据库失败怎么办？
工具返回为空怎么办？
某个接口超时怎么办？
发现数据不够，要不要换一个工具继续查？
这些都属于执行过程。
真正的 Agent，需要能在执行中处理分支，而不是只按一张固定清单往下走。
4. 反馈：看结果，再决定下一步
Agent 和普通程序最大的区别之一，是它会根据中间结果调整动作。
比如它先查订单失败原因，发现失败最多的是"支付超时"。
那下一步就不应该继续查库存，而应该去查支付接口延迟、第三方支付回调、网关错误日志。
这就是反馈。
它的基本循环是：
思考 -> 行动 -> 观察结果 -> 再思考 -> 再行动。
很多人听过 ReAct，其实就是这个思路。
Reasoning 是思考，Acting 是行动，中间靠 Observation 把工具结果带回来。
一个简单判断：它有没有"自己决定下一步"
怎么判断一个系统是不是 Agent？
我给一个很实用的判断标准：
看它有没有在任务过程中，自己决定下一步做什么。
如果它只是固定流程：
- 用户输入问题
- 系统检索知识库
- 模型总结答案
- 返回给用户
这更像 RAG 问答，不一定是 Agent。
如果它是：
- 用户给一个目标
- 模型判断需要先查知识库
- 查完发现信息不够，又决定查数据库
- 数据库结果异常，又决定调用日志工具
- 根据日志继续定位问题
- 最后生成结论
这就更像 Agent。
因为它不是在机械执行固定流程，而是在根据任务状态做动态决策。
这里要注意，不是用了大模型就叫 Agent。
也不是用了 Function Calling 就一定叫 Agent。
如果工具调用路径完全固定，没有开放决策，那它可能只是一个带工具的 Workflow。
Agent 的核心是：目标驱动 + 动态决策 + 外部行动 + 反馈迭代。
这四个词，面试时可以直接说。
2.4.Agent 和 Workflow的差异
Agent 和 Workflow 很容易混。
Workflow 是工作流。
它适合流程明确、步骤稳定、规则清楚的任务。
比如发票审核：
- OCR 识别发票
- 提取金额、税号、日期
- 校验字段
- 调用财务系统入账
- 返回审核结果
这个流程很固定，用 Workflow 就很好。
你不需要让模型每次自由发挥："我想想接下来要不要入账。"
那太危险了。
Agent 适合什么？
适合任务开放、路径不固定、需要中途判断的场景。
比如：
帮我定位线上接口变慢的原因。
这个任务没有固定路径。
可能是数据库慢，可能是缓存击穿，可能是某个服务发布导致，可能是第三方 API 超时。
你没法提前写死每一步。
这时候 Agent 的价值就出来了：它可以根据查到的现象，决定下一步查哪里。
所以别神化 Agent。
能用 Workflow 稳定解决的问题，就不要硬上 Agent。
Agent 的自由度更高，但不代表更可靠。
自由度越高，越需要约束、评估、权限控制和失败恢复。
2.5.Agent 是一套系统
这点很容易被忽略。
很多人说"我用了 GPT-5，所以我做了 Agent"。
模型只是 Agent 的一部分。
一个完整 Agent 系统，通常至少包括：
- 模型：负责理解、推理、生成
- Prompt：定义角色、目标、边界
- 工具：连接外部系统
- 执行器：真正调用工具、处理返回结果
- 状态管理：记录当前任务进度
- 记忆系统：保存跨轮信息
- 评估机制：判断做得对不对
- 权限控制：限制能做什么、不能做什么
- 失败恢复：出错后能不能重试、回滚、停止
所以 Agent 不是"一个更强模型"。
它更像一个围绕模型搭起来的工程系统。
模型负责思考，但系统负责让它安全地行动。
这也是为什么同样用一个模型，不同团队做出来的 Agent 效果差很多。
差距往往不在模型本身，而在工具设计、上下文管理、执行编排、评估观测这些工程细节。
2.6.面试官可能会问
如果面试官问：
你怎么理解 Agent？
不要只回答：
Agent 是智能体，可以自主完成任务。
这句话太虚了。
你可以这样回答：
我理解的 Agent，不是单纯的大模型问答，而是一个围绕目标持续行动的系统。它会根据用户目标进行任务规划，选择合适的工具调用外部环境，执行中观察工具返回结果，再决定下一步动作。普通 ChatBot 主要是生成回答，而 Agent 更强调行动、反馈和迭代。它的核心不是模型更聪明，而是系统具备规划、工具调用、执行编排和状态反馈能力。
这个回答就比较稳。
如果面试官继续问：
那 Agent 和 Workflow 有什么区别？
你可以补一句：
Workflow 更适合步骤固定、规则明确的任务；Agent 更适合路径不确定、需要动态决策的任务。工程上不是所有场景都应该上 Agent，如果流程能写死，用 Workflow 往往更稳定、更可控。
这句话很加分。
因为它说明你不是看到 Agent 热就硬套，而是知道取舍
3.第三步：Agent 设计模式
这三个词不是三套神秘框架，而是三种很朴素的 Agent 做事方式：
- ReAct：边想边做，看一步走一步
- Reflection：做完回头看，发现问题再改
- 规划执行：先拆任务，再按计划推进
重点不是背概念，而是知道：什么场景用哪种，为什么面试官喜欢追问 ReAct。
3.1.ReAct
边思考，边行动，边观察
ReAct 是 Agent 里最经典的一种思路。
它的名字来自两个词：
- Reasoning：推理，先想清楚下一步为什么这么做
- Acting：行动，调用工具或执行动作
但只记这两个还不够。
ReAct 真正关键的是中间还有一个 Observation（观察）。
也就是工具执行后的观察结果。
一个典型 ReAct 循环长这样：
- Thought：我现在需要知道什么
- Action：我要调用哪个工具
- Observation：工具返回了什么
- Thought：根据结果，我下一步该做什么
举个例子。
用户问：
“帮我定位接口
/api/pay昨天晚上为什么变慢。”ReAct Agent 可能这样跑：
- Thought：先看接口延迟曲线，确认变慢时间段。
- Action：调用监控查询工具，查询
/api/pay昨晚 P95 延迟。- Observation：22:10 后 P95 从 300ms 涨到 3.8s。
- Thought：需要看这个时间点有没有发布。
- Action：调用发布记录工具。
- Observation：22:05 发布了支付服务 v2.3.1。
- Thought：继续查错误日志和下游接口耗时。
- Action：调用日志工具。
- Observation：第三方支付回调超时明显增加。
你看，ReAct 的特点很明显：
它不要求一开始就把完整计划想完，而是每拿到一个结果，再决定下一步。
这就是为什么 ReAct 特别适合工具调用场景。
因为真实环境里，你一开始根本不知道问题在哪。
你只能查一步，看一步，再决定下一步。
ReAct 适合路径不确定的任务，但必须配合步数限制、工具权限、状态记录和停止条件。
3.2.Reflection
不是让模型自嗨，而是让它检查结果
Reflection 翻译过来叫反思。
很多人一听反思，就以为是让模型输出一句：
“我再仔细检查一下。”
这没用。
模型说自己检查了，不代表真的检查了。
Reflection 的核心不是一句提示词，而是给 Agent 一个明确的检查环节。
比如 Agent 写完一段 SQL，不要直接交付。
让它回头检查：
- 字段有没有写错
- WHERE 条件有没有漏
- 是否会全表扫描
- 返回结果是否符合用户目标
再比如 Agent 生成一份问题分析报告，也不要直接交付。
让它检查：
- 结论有没有证据支撑
- 是否遗漏关键时间点
- 是否把相关性当成因果
- 建议是否能落地
这才是 Reflection。
它不是让模型“感觉自己更认真”，而是让模型按照标准检查输出。
1. 结果容易有格式错误
比如结构化输出、SQL、配置文件、接口参数。
模型第一次生成很可能看起来对，但细节错。
这时候加一个检查环节，能拦住很多低级问题。
2. 任务有明确验收标准
比如：
- 单测是否通过
- JSON 是否符合 Schema
- SQL 是否能执行
- 报告是否包含指定字段
- 简历项目是否包含四要素
有标准，Reflection 才有抓手。
没有标准，只让模型“反思一下”，它很容易给你一段漂亮废话。
3. Agent 容易过早交付
很多 Agent 的问题不是不会做，而是做了一半就开始总结。
Reflection 可以在交付前加一道门：
当前结果是否已经满足用户目标？如果不满足，还缺什么证据？是否需要继续调用工具？
这个检查能把“半成品交付”挡住一部分。
但 Reflection 也有边界。
如果模型本身不知道正确答案长什么样，它反思十遍也没用。
比如让模型判断一个线上故障根因，它没有日志、没有监控、没有发布记录，只靠自我反思，最后还是猜。
所以 Reflection 最好和工具、规则、测试、评估一起用。
不要把它当玄学许愿。
3.3.Plan
规划执行：先拆任务，再推进：Plan-and-Execute。
它的逻辑很简单：
先让模型根据用户目标生成一个计划。
然后再按计划一步一步执行。
比如用户说：
“帮我分析这个仓库的技术债，并给出优先级。”
如果用规划执行，Agent 不能一上来就随便翻几个文件。
它应该先生成计划：
- 了解项目结构和技术栈。
- 找核心模块和高频变更文件。
- 检查复杂函数、重复代码、缺测试模块。
- 结合影响范围评估优先级。
- 输出技术债清单和修复建议。
然后再执行每一步。
规划执行的优点是：任务更有方向，不容易一开始就跑偏。
尤其适合复杂任务。
比如：
- 代码库分析
- 竞品调研
- 数据分析报告
- 多文件重构
- 长文档整理
- 面试题系统总结
这些任务如果完全靠 ReAct，一步一步临时想，容易走散。
先规划，再执行，会稳很多。
计划不是不可修改的剧本，而是可更新的任务清单 + 当前假设集合。 每执行完一个子任务：
- 收集观测结果、更新任务状态；
- 校验支撑当前计划的假设是否仍然成立；
- 如果假设被证伪、目标路径变化，触发重规划，调整后续任务，保留已经验证有效的成果，不是全盘推倒重来。
3.4.如何选择
举个真实一点的例子。
用户说：
“帮我定位线上支付接口变慢，并给出修复建议。”
比较稳的 Agent 设计应该是：
- 先规划：确认要查监控、日志、发布记录、下游依赖。
- 中间 ReAct：根据每次查询结果，决定下一步查哪里。
- 最后 Reflection：检查结论是否有证据，建议是否对应根因。
这就比单独讲某一种模式更成熟。
因为真实任务不是教科书。
它不会乖乖按照某个模式走完。
3.5.面试官可能会问
面试官问：你怎么理解 ReAct？
不要只说：
“ReAct 是 Reasoning and Acting。”
可以这样答：
“ReAct 是一种让 Agent 在推理和行动之间循环的设计方式。模型先判断当前需要什么信息，再选择工具执行，拿到 Observation 后再决定下一步。它适合故障排查、数据查询这类路径不确定的任务。工程上要注意限制步数、记录状态、设置停止条件，否则容易跑偏或陷入无效工具调用。”
面试官问：Reflection 有什么用？
可以这样答：
“Reflection 不是简单让模型‘再想想’，而是在交付前增加一个检查环节。它要基于明确标准检查结果，比如格式是否符合 Schema、结论是否有证据、任务目标是否完成。如果没有外部标准或工具结果，Reflection 容易变成模型自我安慰，所以最好结合测试、规则和评估机制使用。”
面试官问：规划执行Plan和 ReAct 有什么区别？
可以这样答：
“规划执行Plan更强调任务开始前先拆解步骤，适合复杂长任务；
ReAct 更强调执行过程中根据观察结果动态决策，适合路径不确定的任务。
实际项目里一般会组合使用：先做粗粒度规划，中间用 ReAct 调工具推进，最后用 Reflection 做交付前检查。”
这套回答，基本够用了。
4.第四步：Agent vs Workflow
不是所有任务都需要 Agent。很多场景硬上 Agent，反而是在给系统制造不稳定。
这篇就专门讲一个面试和项目里都很常见的问题：
Agent 和 Workflow 到底怎么选？什么时候根本不需要 Agent？
主题：别盲目上 Agent！能写死流程的场景，优先 Workflow
4.1.Workflow
先说结论：流程能写死，就优先 Workflow
不少人有个误区：Workflow 是低级方案，Agent 才更高级。 这个理解不对。Workflow 并不比 Agent “低一等”，在大量生产场景里，Workflow 反而更可靠。
什么是 Workflow？ 简单讲：步骤固定、规则明确，输入输出可预期的流程编排。
举个例子：发票审核。
- OCR 识别发票图片
- 提取金额、税号、开票日期
- 校验字段合法性
- 调用财务系统入账
- 返回审核结果
整个链路清清楚楚，先做什么、后做什么、异常如何兜底，都可以提前定义。 这种场景完全没必要交给大模型自由思考：“我想想下一步要不要入账”。 财务场景追求的不是灵活，而是稳定、可审计、可回放、可控。
原则一句话：如果业务流程可以稳定写死，优先选 Workflow，不要硬上 Agent。
2.Workflow 解决的是「按固定步骤稳定执行」
Workflow 的核心价值，是把业务逻辑编排成一条可控执行链路。 它关心这些事情：
- 每一步执行什么动作
- 每个节点依赖哪些前置输入
- 节点失败如何重试、降级
- 哪些分支需要人工审批介入
- 全链路日志、状态记录，方便追踪
客服退款流程就是典型带分支的 Workflow： 用户提交退款申请
- 校验订单是否存在
- 判断是否在退款时效内
- 判断商品是否发货
- 未发货：自动退款
- 已发货：流转人工审核
- 写入退款记录，通知用户
虽然存在分支判断，但它依旧是 Workflow。 因为分支条件是确定规则，写死在代码里：超过 7 天不可退、已发货转人工…… 如果交给 Agent 去解读业务规则，反而引入风险：模型可能误读规则、边界 case 幻觉。 Workflow 的优势就是：规则一旦固化，每次执行都严格一致，不会随机发挥。
1.Agent 的核心价值：路径未知的动态探索决策
Agent 的真正价值，只存在于目标明确，但执行路径无法提前穷举的场景。线上故障排查、业务数据下跌分析等场景，根因多种多样，事前无法预判排查顺序，只能边执行、边观察、边决策。
这类场景中，Workflow 完全无法适配，而 Agent 可以通过 ReAct、动态规划执行的能力，根据实时观测结果，动态调整后续工具调用和排查步骤，完成开放式探索任务。
这里纠正一个关键误区：有分支≠需要 Agent。规则固定的分支是业务逻辑，归 Workflow；只有执行中才会出现、无法提前定义的未知分支，才需要 Agent 动态决策。
2.过度 Agent 化，是项目翻车的核心原因
盲目追求智能化，把简单确定性流程包装成 Agent，是工程最大的坑，会带来四大硬伤：
1. 成本更高：Workflow 仅需简单接口调用，Agent 需要多轮模型推理+工具调用，消耗大量 Token；
2. 延迟更高：多余的意图解析、规划、总结链路，严重影响用户体验；
3. 稳定性更差：模型动态决策存在不确定性，容易选错工具、执行跑偏，高风险业务无法兜底；
4. 排查更难：Workflow 节点日志清晰可定位，Agent 推理链路黑盒多，调试成本极高。
先问自己：这件事能不能画成固定流程图。
4.2.Workflow + Agent
最稳的方案，往往是 Workflow + Agent
真实项目很少简单二选一。生产上更靠谱的方案是混合架构：外层用 Workflow 守住主流程，仅把少数开放节点交给 Agent。
智能工单就是典型例子。 主流程走 Workflow：接收工单、判断工单类型、分配处理队列、处理完成通知用户、记录结果。主链路必须稳定。 而「分析工单根因」节点交给 Agent。工单问题各不相同：有的查日志、有的查订单、有的看用户行为、有的查上线记录，没法预先写死排查路径，适合动态探索。
核心思路：Workflow 管控边界与主流程，Agent 做开放问题求解。 不要让 Agent 接管整个系统，只在真正需要动态判断的地方使用，同时拿到稳定性和灵活性。
4.3.面试官可能会问
面试官问：Agent 和 Workflow 有什么区别？
“Workflow 适合步骤明确、规则稳定、可提前编排的任务，核心是稳定执行；
Agent 适合目标明确但路径不确定、需要中途观察结果并动态决策的任务，核心是探索和调整。工程上不是所有场景都要用 Agent，如果流程能写死，用 Workflow 更稳定、更便宜、更容易审计。”
面试官问：你们项目里为什么不用纯 Agent？
“因为纯 Agent 的自由度太高，成本、延迟和不确定性都会上升。
我们一般把主流程放在 Workflow 里，保证权限、状态流转和异常处理可控；
只有在路径不确定的节点，比如故障定位、原因分析、复杂数据查询，才让 Agent 调工具动态判断。”
面试官问：怎么判断一个场景该不该上 Agent？
“我会先看流程能不能提前画清楚。
如果步骤固定、分支规则明确，就用 Workflow；
如果路径无法提前穷举，需要根据中间结果不断调整下一步，才考虑 Agent。同时还要看风险、成本、延迟和可解释性要求，不能为了技术热度硬套 Agent。”
这套回答就比较稳。
它说明你不是只会追热点，而是知道工程取舍。
