从零理解 AI Agent：概念、ReAct、Prompt 五要素与面试要点
🥰个人主页：会编程的土豆（欢迎来访）
💎作者简介：后端学习者
❄️个人专栏：数据结构与算法，数据库，leetcode
✨那些你一个人走过的夜路，终将化作照亮未来的光
适合对象：几乎零基础、想搞懂 Agent 是什么、顺便准备面试的同学
本文不堆框架源码，先把「能讲清楚」这件事做扎实
写在前面
很多人一上来就打开 LangChain、Eino 之类的仓库，结果越看越懵。其实 Agent 本身并不神秘，复杂的是工程实现。
先记住一句就够入门：
Agent = 会围绕目标，自己决定要不要用工具，并动手完成工作的 AI 助手。
- 普通聊天机器人：主要「动嘴」——你问一句，它回一句。
- Agent：不但会说话，还会「动手」——需要时去查天气、算数、搜文档、调 API，再根据真实结果回答你。
本文会按这个顺序讲：
- Agent 到底是什么（生活类比）
- LLM、工作流、Agent 的区别
- Agent 由哪些部分构成
- ReAct 推理模式是什么、怎么实现
- Message / Tool 这些基础零件
- Prompt 五要素框架（怎么把话跟模型说清楚）
- 面试高频题与口述模板
- 零基础学习路线建议
一、用生活例子理解 Agent
1.1 查天气
你问：「外面冷不冷？」
| 类型 | 做法 |
|---|---|
| 普通机器人 | 凭印象猜：「大概挺冷吧。」 |
| Agent | 打开天气 App（工具）一看：现在 8℃，再说「挺冷，建议穿外套。」 |
手机上的天气 App，在 Agent 里就叫 Tool（工具）。
1.2 算数题
你问：「3×7 等于多少？」
Agent 的典型过程：
- 想：这是计算题，用计算器更靠谱。
- 做：调用计算器工具，参数
3*7。 - 看：工具返回
21。 - 答：告诉你「等于 21」。
这就是 Agent 最核心的行为模式：想 → 做 → 看 → 再想/再答。
1.3 一句话定义（建议背下来）
Agent 能够 围绕目标，自主完成工作。
「自主」不是完全没人管，而是：步骤不必你每一步手把手指定，它可以自己选择行动。
二、LLM、工作流、Agent：三者别混
这是面试和入门最容易混淆的地方。
2.1 只用大模型（LLM）
输入 → LLM → 输出
例子：你说「给我一个会议纪要模板」，模型直接写出模板。
特点：
- 擅长生成文字、总结、改写
- 不会真正去操作你的邮箱、日历、数据库（除非另外接工具）
- 本质是「会写字的大脑」
2.2 工作流（Workflow）
输入 → 步骤1 → 步骤2 → 步骤3 → 输出
例子：发会议纪要的流水线（步骤由人写死）：
- 获取会议记录
- 调用 LLM 做总结
- 打开邮箱
- 发送邮件
特点：
- 路径固定，可控、可预期
- 适合流程明确、合规要求高的业务
- 模型通常只负责其中某几步，不会自己改路线
2.3 Agent（智能体）
输入 →（Agent 自己决定执行步骤）→ 输出
例子：你说「帮我把上次会议纪要发给参会人」。
Agent 可能自己决定：
- 上次会议是什么时候？
- 先连日历试试
- 或去腾讯会议找记录
- 再让大模型总结
- 邮箱不清楚就先问你
特点：
- 目标导向，步骤动态选择
- 更灵活，也更难控、成本可能更高
2.4 对比小结
| 维度 | LLM | 工作流 | Agent |
|---|---|---|---|
| 核心能力 | 生成文本 | 按固定流程执行 | 围绕目标自主决策并行动 |
| 步骤谁定 | 基本无多步业务流 | 人预先写死 | 模型动态决定 |
| 会不会用工具 | 默认不会 | 可以，但按编排调用 | 会，且常自己判断何时调用 |
| 典型比喻 | 会写字 | 按菜谱做菜 | 你说「弄顿饭」，它自己买菜炒菜尝咸淡 |
三、Agent 的构成：像招了一个「数字员工」
可以把 Agent 理解成公司里的实习生 / 数字员工：你给目标，他尽量自己干完。
中间是 LLM 大脑，周围通常还有：
3.1 Prompt（岗位说明书）
规定：
- 你是谁（角色）
- 负责什么（任务）
- 什么能做/不能做（约束）
- 怎么说话、输出什么格式
没有说明书，员工就容易自由发挥；Agent 也一样。
3.2 Memory（记忆）
记得你们之前聊过什么、任务做到哪一步。
短期可以是当前对话的消息列表；长期可以是存进数据库的历史。
3.3 Tools（工具）
真正「干活的手」：
- 查天气 API
- 计算器
- 搜索
- 读写文件 / 查数据库
- 发邮件
关键认知：
模型通常只「提议」要调哪个工具、带什么参数；
真正执行工具的是你的程序，不是模型自己神秘连上了数据库。
3.4 外部知识（可选）
公司文档、知识库、RAG 检索结果等，让回答有据可依，而不是只靠模型「背」。
3.5 构成公式
Agent ≈ LLM（大脑）
+ Prompt（说明书）
+ Tools（手）
+ Memory / 知识（记得住、查得到）
+ 循环控制（想→做→看，直到完成）
四、Agent 推理模式与 ReAct
4.1 常见推理模式有哪些？
「推理模式」指 Agent 如何组织思考与行动。常见包括：
| 模式 | 一句话理解 | 适用直觉 |
|---|---|---|
| ReAct | 边想边做：推理 ↔ 行动交替 | 最基础、最常考 |
| Plan-and-Execute | 先做计划，再逐步执行（可再规划） | 步骤多、需要先拆解 |
| Reflexion / 带反思 | 做完再反省，错了改进 | 强调自我纠错 |
| Function Calling | 用结构化方式提出工具调用 | 现代 Agent 的常见底盘 |
| Multi-Agent | 多角色分工协作 | 复杂任务加分项 |
入门优先掌握：ReAct。
4.2 ReAct 是什么？
ReAct = Reasoning（推理）+ Acting（行动）
不是「一次想完再一口气做完」，而是循环：
思考（Reason）
→ 行动（Act，例如调用工具）
→ 观察（Observe，看工具返回）
→ 再思考
→ ……
→ 给出最终答案
也可以记成笔记里的三字循环：
思考 → 行动 → 检查（不够就再思考）
黄字级别的记忆点：
会推理，会行动。
4.3 用「竞品分析」理解循环
任务：帮我做竞品分析。
可能循环：
- 理解要分析什么
- 整理/搜集数据（可能调搜索工具）
- 做图表或结构化总结
- 检查够不够；不够再回去补充
直到目标基本完成，才对用户给最终结果。
4.4 ReAct 具体怎么实现？（面试高频）
不必背某个框架源码，讲清通用实现即可。
（1）需要的零件
- 消息历史
history（对话上下文） - 工具列表（名字、描述、参数说明、执行函数）
- 最大步数
maxSteps（防止死循环） - 一个能对话、最好支持工具调用的 LLM
（2）伪代码
history = [系统提示词, 用户问题]
循环 最多 N 次:
回复 = 调用 LLM(history, 可用工具)
如果 回复是最终答案（没有工具调用）:
返回给用户
结束
如果 回复里包含 tool_call:
结果 = 执行对应工具(参数)
把工具结果追加进 history
继续下一轮循环
（3）三个关键点
-
模型如何表达「要调工具」
- 现代常见：Function Calling / Tool Calling（结构化 JSON）
- 早期论文风格：文本里写
Thought/Action/Action Input
-
谁执行工具
- 你的后端 / Agent 运行时执行
- 模型负责决策，程序负责落地
-
观察如何回到模型
- 把工具返回写成一条「工具消息」写回历史
- 下一轮 LLM 就能看到结果并继续推理
（4）工程上还要有什么
- 最大迭代次数
- 超时、重试
- 工具白名单与参数校验
- 日志 / Trace（每一步想了什么、调了什么）
- 高风险操作的人工确认（可选）
4.5 和小例子对齐（建议写进笔记）
用户：3×7 等于多少？
- Reason：需要计算，调用 calculator
- Act：
calculator("3*7") - Observe：
21 - Reason：可以回答了
- Output：等于 21
这就是最小可用的 ReAct。
五、基础零件：Message 与 Tool
即使暂时不写代码，也建议建立这两个概念——它们是几乎所有 Agent 框架的通用语言。
5.1 Message（聊天气泡）
Agent 处理的不是「单独一句话」，而是 一串消息历史。
常见角色：
| 角色 | 含义 |
|---|---|
| system | 系统设定：人设、规则、说明书 |
| user | 用户说的话 |
| assistant | 模型说的话；也可能在这里提出工具调用 |
| tool | 工具执行后的返回结果 |
普通聊天
system → user → assistant
Agent 调工具时（典型顺序）
system
→ user（提问）
→ assistant（决定调用某某工具）
→ tool（工具结果）
→ assistant（基于结果给出最终回答）
记住：
对话上下文 =
[]Message
工具结果也要进历史，模型下一轮才能「看见」真实数据。
5.2 Tool（工具）
工具至少包含：
- 名字：如
calculator、get_weather - 描述：什么时候该用它（给模型看的说明书）
- 参数 schema：需要哪些字段
- 执行逻辑：真正跑起来的函数 / API
模型侧看到的是「有哪些工具可用」；
运行时侧负责「真的执行并返回字符串或结构化结果」。
5.3 和框架的对应关系（仅作地图，不必深挖）
以 Go 生态的 Eino 为例（知道分层即可）：
| 概念 | 常见对应 |
|---|---|
| Message | schema.Message |
| 模型接口 | ChatModel / Generate、Stream |
| 工具 | Tool / InvokableTool |
| Agent 循环 | ADK 中的 ChatModelAgent 等 |
| 启动入口 | Runner.Query |
学习建议： 会用示例、能讲清概念即可；不要一上来通读 internal/ 或超长实现文件。
六、Prompt 五要素框架（输入-处理-输出闭环）
Prompt（提示词）解决的是：怎么把话跟大模型说清楚。
对 Agent 来说，System Prompt 往往就是「岗位说明书」。
6.1 为什么 Prompt 重要
模型不会读心。你写得越清楚，它越按意图做事；写得模糊，就容易：
- 跑偏
- 幻觉编造
- 格式混乱
- 乱调工具或不调工具
6.2 五要素总览
完整 Prompt 常包含：
- 角色（Role）
- 任务（Task）
- 约束（Constraint）
- 输入（Input）
- 输出（Output）
口诀：
你是谁 → 干什么 → 有啥规矩 → 材料是啥 → 答成啥样
它们共同形成 输入 → 处理 → 输出 的闭环。
6.3 ① 角色（Role）
定义： 模型扮演谁。
粒度：
- 粗：
你是一个助手 - 细：
你是电商售后客服，只处理退换货，语气礼貌，不承诺无法兑现的时效
角色越具体，视角和语气越稳定。
6.4 ② 任务（Task）
定义： 这次要完成什么。
写法建议：
- 用清晰动词：判断、总结、提取、生成、调用工具后回答
- 复杂任务要 拆解：先…再…最后…
示例：
任务：根据用户问题处理退货咨询。
拆解：
1）识别用户意图
2）必要时查询订单状态
3）用三条要点给出处理建议
6.5 ③ 约束（Constraint）
定义： 边界与禁止项。
常见类型：
- 内容约束：不编造；不确定就说不确定
- 长度/风格：不超过 100 字；必须中文
- 行为约束：最多调用工具 3 次；高风险先确认
- 安全约束：不泄露隐私；拒绝危险指令
示例：
不要编造订单号与物流信息；
金额必须以工具返回为准；
信息不足时只追问一个关键问题。
面试可说：约束用于降低幻觉、控制风险、稳定行为。
6.6 ④ 输入（Input）
定义： 给模型的原材料（用户问题、文档、工具结果等）。
组织输入时的关键技巧：
| 技巧 | 说明 |
|---|---|
| 分块组织 | 用户问题一块、参考资料一块，避免糊成一团 |
| 使用分隔符 | 用 ###、---、""" 等隔开「指令」与「数据」 |
| 输入顺序 | 通常先规则/任务，再贴材料 |
| 边界控制 | 标明输入从哪开始到哪结束 |
| 可信度说明 | 说明哪份输入更优先（如：以工具结果为准） |
示例：
### 用户问题
我想退货，订单号 123
### 工具结果（可信，优先采信）
订单状态：已发货；签收前可退
为什么分隔符重要？
因为如果不隔开，模型可能把「用户粘贴的内容」误当成「系统指令」，造成注入或混乱。
6.7 ⑤ 输出（Output）
定义： 结果应该长什么样。
常规定：
- 输出结构：先结论后理由；分点列出
- 格式要求：Markdown / JSON / 表格
- 引用规则：是否标注来源
- 异常处理：做不到时追问、拒绝或说明原因，而不是瞎编
示例：
请用 JSON 输出：
{
"can_refund": true,
"reason": "...",
"next_step": "..."
}
若信息不足：can_refund 为 null，并给出需要用户补充的字段。
对 Agent 而言：结构化输出也是 Tool Calling 能稳定工作的基础。
6.8 五要素关系
角色 + 任务 → 定方向（以什么身份处理什么事）
约束 → 控过程（别越界、别胡来）
输入 → 供材料（闭环的输入）
输出 → 收结果（闭环的输出）
缺一块，模型更容易自由发挥；五块齐全，行为更稳。
6.9 五要素完整示例（可直接改着用）
【角色】你是电商售后助手。
【任务】回答用户关于退货的问题；需要订单状态时使用查询工具。
【约束】
- 不编造物流与金额
- 不确定就明确说明
- 回复简洁，避免官话套话
【输入】
### 用户问题
（用户原文）
### 工具结果（优先采信）
（工具返回）
【输出】
- 先给出「可否退货」的结论
- 再列 2～3 条依据
- 若信息不足，只问一个澄清问题
6.10 Prompt 与 Agent 的关系（别混）
| 概念 | 是什么 |
|---|---|
| Prompt | 你怎么「吩咐」模型（说明书） |
| Tool | 模型可调用的外部能力（手） |
| Agent | 按说明书 + 自己判断，循环用工具完成目标 |
一句话：
Prompt 是说明书，Tool 是手，ReAct 循环是干活方式。
七、面试要点整理（可直接口述）
7.1 什么是 AI Agent？
Agent 是在大模型之上，结合工具、记忆与决策循环，能够围绕目标自主选择行动并完成任务的系统。它不只生成文本，还能在需要时调用外部能力，并根据观察结果继续推理。
7.2 Agent 和普通 Chatbot、工作流有什么区别？
Chatbot 侧重多轮问答与文本生成；工作流是人类预定义的固定步骤；Agent 则在目标约束下动态决定下一步，既可以调用工具，也可能询问用户，路径不事先完全写死。
7.3 ReAct 是什么？怎么实现？
ReAct 是 Reasoning + Acting 的交替循环：模型先推理，必要时发起行动（工具调用），系统执行后把观察写回上下文，再继续推理，直到给出最终答案。实现上通常维护消息历史、注册工具、循环调用 LLM，解析 tool_call 并执行，设置最大步数防止死循环。
7.4 好的 Prompt 应包含什么？
常见五要素：角色、任务、约束、输入、输出，形成输入-处理-输出闭环。角色任务定方向，约束控风险，输入要分块与分隔并标明可信度，输出要规定结构、格式与异常处理。
7.5 如何避免 Agent 乱调工具或死循环？
设置最大迭代次数；工具白名单与参数校验；在 Prompt 中明确何时用工具、禁止编造；对关键路径用工作流写死；高风险操作增加人工确认；做好日志与评测。
7.6 什么时候用 Agent，什么时候用 Workflow？
流程清晰、强可控、强合规 → 优先 Workflow/Graph；任务开放、需要动态决策与多工具协作 → 更适合 Agent。也可以混合：Agent 负责决策，关键子流程用工作流封装成工具。
DAMO开发者矩阵，由阿里巴巴达摩院和中国互联网协会联合发起，致力于探讨最前沿的技术趋势与应用成果，搭建高质量的交流与分享平台，推动技术创新与产业应用链接，围绕“人工智能与新型计算”构建开放共享的开发者生态。
更多推荐
0
0- 0
已为社区贡献1条内容
所有评论(0)