企业官网建设流程全解析

说实话，我见过太多人学 AI Agent 是这么开始的：今天刷到一个视频说某框架很火，赶紧照着拉了个工程跑通 Demo；明天又看到一篇文章讲智能体规划，收藏起来吃灰；半个月过去，Chat 类应用能跑通，但让他解释"为什么这个 Agent 会自己调工具"就哑口无言。

我自己也是从这条路走过来的，所以这份学习清单想做一个反过来的事：不追热点、不堆名词，而是把 AI Agent 从概念到能跑通一个最小可交互的智能体，拆成一条清晰的路径。它不涉及模型训练、不涉及微调，也不涉及复杂的数学推导，只关注工程实现中最常用的那些知识点。如果你有一点 Python 基础，想系统搞明白 Agent 到底怎么工作、怎么自己动手实现一个，那这份清单就是给你准备的。

1. 动手前先想清楚：学习 Agent 到底学的是什么

1.1 "用 Agent"和"造 Agent"是两回事

先做一个判断：你学 Agent 是为了什么？如果是想在业务里快速搭一个问答机器人，那大概率只需要熟悉某个成熟平台的配置页面，把文档拖拽几下就能实现，谈不上学 Agent。但如果你像我一样，希望理解 Agent 是怎么感知环境、怎么决策、怎么调用工具的，甚至能自己写出一套循环逻辑，那你的学习重心就不是"某个框架的用法"，而是"Agent 的基本运行机制"。

这份清单按后者设计。也就是说，学习过程中你会写代码，会亲手实现一个最简单的"思考-行动-观察"循环。我建议你也把目标定为"能独立写出最小 Agent"而不是"会调用某个现成 Agent 产品"，因为后者换一个平台就得重新学，前者才是可迁移的底层能力。

1.2 这份清单覆盖的范围，以及故意不碰的部分

先划清边界，避免学偏。这份清单主要覆盖五块内容：

• 大模型 API 的基础调用逻辑和流式输出
• Prompt 设计的几个核心手法（角色、上下文、格式约束）
• 函数调用（又叫工具调用）的原理与实现
• 记忆的简单实现：会话记忆、长期记忆、向量检索
• 规划与多智能体协作的基本思路，以及可观测性

我故意不碰的方向包括：模型训练、微调、RLHF、Agent 底层强化学习算法、向量数据库的高级调优。不是说这些不重要，而是对一个刚开始学 Agent 的人来说，这些知识离"跑通一个可用系统"太远，过早投入容易消耗信心。等你把最小闭环跑通、对 Agent 的整体运转有了体感，再回来看这些底层知识会顺利得多。

2. 第一阶段：把绕不开的地基概念逐个击穿

2.1 从大模型 API 调用开始，理解"对话"不过是文本输入输出

Agent 绝大多数能力都建立在大模型 API 之上。所以第一件事不是去看 Agent 框架源码，而是亲手用代码调用一个大模型接口，实现一次完整的对话。这一步看起来简单，但有几个关键点值得慢下来体会。

• 输入本质是文本：你发给模型的内容是一段字符串，模型返回的也是一段字符串。所谓"对话"，不过是你把历史消息拼接成数组，每次都发给模型。
• 上下文长度有上限：模型能处理的历史消息是有限的，超出了就得截断或压缩。这个限制直接决定了 Agent 的"记忆力"边界。
• 参数会影响行为：温度（temperature）调高，输出更随机；调低则更确定。对于 Agent 的工具调用场景，通常需要较低的温度，避免模型产生随机的参数。

我建议你写一个最简单的脚本：把用户问题发给大模型，拿到回复，打印出来。然后在此基础上改成流式输出，一字节一字节地接收模型回答。流式输出对 Agent 的意义很大，因为长时间的模型推理如果不做流式，用户界面会卡死，体验非常差。学会流式后，你就能在回调函数里实时处理文本，这也是后面做流式日志、实时拦截的基础。

2.2 Prompt 设计最小技能：角色、上下文、输出格式

Agent 的行为边界很大程度上由 Prompt 定义。学习这一阶段时，不要追求背诵各种花哨的 Prompt 模板，而是掌握三个最核心的变量。

• 角色设定：给模型一个身份描述，比如"你是智能助手""你是后端工程师"。角色不一定改变模型能力，但会明显影响回答的口吻和侧重点。
• 上下文信息：把当前场景、用户画像、已有数据放进去。Agent 之所以看起来"懂你"，很多时候不是模型聪明，而是你把上下文填得够细。
• 输出格式约束：要求模型返回 JSON 或者只输出纯文本，这是让模型结果能被程序解析的关键。

这里有个我经常看到新手踩的坑：人跟模型对话时习惯讲礼貌，写得很口语化，但工程里的 Prompt 需要的是命令式的、结构化表达。比如你要模型输出一段 JSON，必须用非常明确的格式指令，最好再给一个 JSON 示例。模型不是读心术，它只是根据概率预测文本，示例越具体，越不容易跑偏。

2.3 函数调用：Agent 能"动手"的关键机制

很多初学者会困惑：模型不是只能返回文字吗，它怎么能去查天气、订机票、操作数据库？答案就藏在函数调用能力里。这里我把话说明白：模型本身不会执行任何工具，它的真正能力是"输出一个结构化指令"，由你的程序来执行。

整个流程是这样的：你提前把一批工具函数以及它们的参数 schema 发给模型，比如一个查询天气的函数，参数是城市名。当用户问"北京天气如何"，模型判断后返回一条特殊的消息："我想调用查询天气函数，参数是北京"。你的代码接收到这个消息，就去调用真正的天气 API，拿到结果后再把结果作为"工具执行结果"回传给模型。模型看到结果，再生成最终的、面向用户的回答。

这个"模型生成意图-程序执行-结果回传"的循环，就是 Agent 工具的底层本质。学习时你需要亲手实现一次这个循环，不需要用任何框架，用纯代码就能写出来。当你看到模型还知道在参数不够时反问用户时，你会对 Agent 的能力边界有更直观的感受。

2.4 向量检索：给 Agent 外挂一个超大号记忆

模型训练数据有截止日期，也不可能记住你私人文档里的内容，所以 Agent 经常需要一个外挂知识库。最朴素的方案就是把文档切成长度合适的片段，用嵌入模型把每个片段转成向量，存进向量数据库。当用户提问时，把问题也转成向量，用相似度检索找出最相关的几个片段，拼进 Prompt 里，让模型基于这些片段回答。

这就是 RAG 的基本链路。在 Agent 学习清单里，我建议第一阶段只需要理解这个链路，用一个小样例试通就够，先不用纠结切片策略、检索重排、混合检索这些优化项。原因是，Agent 的很多问题不是知识不够，而是流程没跑通。等你把 Agent 主流程做扎实了，再回头优化 RAG 的检索质量会更有把握。

3. 第二阶段：组装一个最小可运行的 Agent 工作流

3.1 手写一个"思考-行动-观察"循环

地基概念过完后，就可以开始组装真正的 Agent 了。我强烈建议你手写一个极简循环，不要急着用任何编排框架。原因很简单：框架帮你把代码结构定义好了，但也会把关键逻辑封装在黑盒里，一旦出错你根本不知道问题出在模型层还是框架层。

下面这个伪代码，是我实际写过的最小结构，你可以照着实现：

messages = [系统提示词, 用户问题] while True: response = call_llm(messages) if response.有工具调用意向: 解析出函数名和参数 执行函数，得到结果 把结果追加到 messages continue else: 输出 response 给用户 break

这个循环里最重要的概念是"把工具调用的结果重新放回消息列表"。很多新手会忽略这一步，导致模型看不到工具执行结果，无法进行下一步推理。你一定要在 messages 里维护完整的历史记录，包括用户消息、模型消息、工具调用消息、工具结果消息，它们共同构成模型下一次推理的上下文。

我把这个最小循环跑通后，最大的收获是理解了"Agent 为什么看起来有逻辑"：不是模型真的会规划，而是程序给了它"想一步、做一步、看结果、再想下一步"的空间。所谓智能，很多时候是循环结构带来的。

3.2 给 Agent 加上记忆：会话记忆与长期记忆

没有记忆的 Agent 是"一问一答"式，每次对话都是重新开始。要给 Agent 加记忆，最笨但有效的方法就是把之前的消息全部拼到上下文里。这就是简单的会话记忆。它的限制也很明显：上下文长度有限，聊久了就会装不下。

更进一步的方案是长期记忆。你可以把用户的重要信息提炼成摘要，存到本地文件或数据库；下次对话时，再从数据库里检索出相关的摘要，放到 Prompt 里。这其实就是一种"外挂记忆"。我在学习时建议你做这么一个小实验：写一个函数，把每轮对话的重要信息（用户偏好、任务状态）写入一个 JSON 文件，下次启动时读取并插入系统提示词。做完这个，你就理解了 Agent 记忆的本质——不是模型在记忆，而是你在程序里替它保存信息。

3.3 用编排框架重新组织代码，理解抽象边界

手写循环通了几轮之后，你肯定已经体会到：如果工具越来越多、判断逻辑越来越复杂，纯手写代码会非常臃肿。这时候再引入编排框架，就是水到渠成的事。框架帮你处理工具注册、消息管理、重试机制、多轮调用调度，你只需要描述有哪些工具、Agent 的逻辑规则是什么。

我的建议是，同一套"最小 Agent"用两种方式各写一遍：第一遍纯手写，第二遍用你选定的框架。然后对比一下，哪些代码是框架省掉的，哪些逻辑仍然是你在控制。这个过程会把"框架替你做了什么"和"框架没替你做但你需要自己加什么"分得一清二楚。

一个常见的误区是：用了框架以后，就不再关注底层消息流转，结果工具返回值格式稍微一变就懵。记住，框架只是简化了流程，没有消除流程。你依然需要清楚每一步消息是怎么被构造、传递、回传的。

4. 第三阶段：规划、多智能体协作与可观测性

4.1 让 Agent 学会规划：从"单步工具调用"到"任务拆解"

最小 Agent 只能做单步决策：模型决定调用一个工具，然后收尾。而真正实用级的 Agent，需要把用户问题拆成多步操作。比如"帮我查这周的天气，如果下雨就提醒我带伞，并把提醒发到手机"，这就涉及多个工具的连续调用。

规划能力的实现思路有很多，最简单的叫"计划-执行"模式：先让模型针对用户问题生成一个任务列表，然后逐步执行。还有一种叫"反思"模式：每执行完一步，让模型检查结果是否符合预期，如果不对就修正。学习时不必一开始就用复杂算法，你可以手写几个固定流程的 Agent：比如先判断意图，是查询类就走 RAG，是操作类就走工具调用，是闲聊类就走普通问答。这种"路由式规划"很容易实现，而且能让你看到规划的本质——其实就是把大问题切分成小问题的逻辑。

4.2 多智能体协作：两个 Agent 怎么分工、怎么避免"互踢皮球"

当任务复杂到一定程度，你会希望有多个各司其职的 Agent 协作。先看最简单的拆分方式：一个主 Agent 负责理解意图，两个子 Agent 分别处理不同领域的任务。主 Agent 根据用户问题把请求转发给对应子 Agent，然后汇总结果。

听起来简单，实操中最大的坑子是什么？"上下文孤岛"。子 Agent 之间不共享历史消息，A 子 Agent 产生的结论，如果要给 B 用，必须由主 Agent 显式传递。很多初学者在做多智能体时，喜欢让所有 Agent 共享同一个超长上下文，结果每一个 Agent 都被无关信息干扰，回答质量全面下降。我建议你从小入手：先做"双 Agent 接力"，一个负责信息抽取，一个负责生成回复，并明确约定两个 Agent 之间的接口格式（比如用 JSON 传递结构化数据）。这样跑通了，再谈更复杂的协同策略。

4.3 日志、追踪与评估：没有观测手段，你调不动 Agent

随着 Agent 的循环越来越长，你会遇到一件很头疼的事：它明明出了错，但你不知道是模型判断错了，还是工具返回错了，还是 Prompt 写得有歧义。所以我建议从第一阶段开始，就养成记录每一项日志的习惯。

至少要有四类日志：每次请求的 Prompt 内容、模型返回的原始消息、工具执行过程的入参和出参、最终回复结果。记录要完整，尤其是模型返回的原始消息。我见过很多人在开发时只打印"最终回答"，一旦回答不对，完全无从排查。用表格来说，一个最小可观测的 Agent 至少要记录：

评估也有讲究。不要只看"用户满不满意"，要给 Agent 准备一组测试用例，每个用例要有预期行为。比如"用户问天气时，必须调用天气工具，且参数必须正确"。这样的断言式测试，能帮你防止改了一个 Prompt 之后，原本正常的场景突然崩掉。

5. 学习过程中的常见卡点和我的解决方法

5.1 Prompt 写得不够清楚，就别急着怀疑模型能力

我最早调试 Agent 时，遇到模型不按预期回答，第一反应就是"这个模型不行"。后来冷静下来，把 Prompt 逐字检查一遍，发现是我没给模型足够明确的边界。比如，我希望模型在无法回答时直接说"不知道"，但 Prompt 里没写这句，模型就开始自由发挥。解决办法也不是把 Prompt 写得越来越长，而是用结构化模板：先给角色定义，再给任务说明，再给输入输出格式，最后给几个示例。给模型做选择而不是让模型开放回答，准确率会高很多。

5.2 函数调用参数不匹配，需要类型校验和重试机制

函数调用说起来简单，实际写起来第一个坑就是模型生成的参数经常不遵守 schema。明明你定义了参数类型是整数，它给你传一个带单位的小数；明明说好枚举值只有三种，它传了一个新造的。这不是模型笨，而是大模型在生成 JSON 时本身就存在一定的随机性。我的应对方式是两件事：第一，解析模型返回的内容时，用严格 JSON 解析，失败时向模型返回一条错误信息，让它修正；第二，为每个工具函数加参数校验，校验不通过就触发重试，重试超过两次则切换为向用户提问澄清。把这一步做好，整个 Agent 的鲁棒性会显著提升。

5.3 记忆过多反而让 Agent 跑偏：信息筛选比存储更重要

给 Agent 加了长期记忆以后，又会出现一个新问题：塞进上下文的记忆太多，模型反而被无关信息干扰，答非所问。我大概在第三个实验项目里遇到这个情况。当时把用户过去的所有对话历史都拼进去，上下文爆满，模型在无关信息里找重点，结果一塌糊涂。后面改成"记忆摘要 + 相关性筛选"：只把最近一轮对话的摘要和与当前问题关键词最相关的几条记忆放进去。效果立竿见影。这也让我意识到，Agent 的记忆系统重点不是在"存得多"，而是在"取得好"。

5.4 接受 Agent 是概率系统，设计容错与人工兜底

学 Agent 到了后期，最需要调整的是心态。Agent 和大模型一样，本质是概率模型，同样的输入两次运行结果可能不同，无法保证 100% 按你的预期执行。这不代表你无能为力，而是要在系统设计上留余地：重要的操作让 Agent 先产出一个"待确认方案"，用户确认后再执行；关键的输出加一层规则校验；整个链路设置最长循环次数，防止出现无限调用。我见过太多人因为 Agent 偶尔一次失败就断定它不可用，实际是自己没有做好容错设计。

6. 这份清单的实际执行顺序与时间参考

我把各阶段内容和建议用时整理在下面，方便你对照自己的进度：

这个时间参考不是死的。如果你已经有 Python 和 API 调用经验，地基阶段可以压缩到三天。但每一步的"完成标志"不建议跳过。原因很简单，Agent 的知识是高度链式依赖的，前一环没亲手做过，后一环看别人代码也会云里雾里。我自己在写第一个手写循环时，花了整个下午调试一个"模型没看到工具结果"的 bug，也正是那次调试让我彻底明白了消息回传的价值。

最后说一句个人体会：学 Agent 最好的方式不是看很多资料，而是尽早陷入一个"怎么还不通"的状态。当你为了一个问题反复翻文档、打印日志、调整 Prompt，最终看到 Agent 按照你的预期连续完成三步工具调用时，你对这份学习清单里所有概念的理解都会突然连成一条线。那条线，才是你自己的 Agent 认知框架。