企业官网建设流程全解析

每次有人跑来问我“从零学 Agent 该先看什么”，我都特别想先反问一句：你打算让这个 Agent 帮你干活，还是打算给 Agent 本身写一套能跑通的东西？这两个目标的学习路径完全不同。但多数人上来就一头扎进框架文档，看了一堆术语，感觉自己懂了，一动手写不出一个能稳定跑完三次工具调用的东西。

我自己的体会是，构建 Agent 真正难的不是某个模型参数，而是“顺序感”——哪些东西必须先变成肌肉记忆，哪些东西可以后面再补。顺序不对，后面每一步都在还债。这篇就按我实际带人入门时反复验证过的一套顺序来讲，不走学院派路线，只讲真正能落地的东西。

1. 为什么学习顺序本身比教程数量更重要

1.1 大多数人的第一个弯路：过早接触编排框架

市面上关于 Agent 的框架很多，有偏可视化的，有偏代码编排的，有主打低代码的。新手最常见的行为是：搜到一篇热门教程，标题写着“三十分钟搭建一个智能助手”，于是跟着拖了几个节点、填了几个 Prompt，跑起来觉得挺神奇，然后就卡住了——想加一个自定义功能，不知道改哪里；想排查一个报错，不知道从哪看日志。

这不是你的问题，是跳级的问题。框架帮你把底层逻辑封装好了，但你的认知还没跟上，一旦黑盒内部的行为和你预期不一致，你就完全失去掌控力。好比一个从没学过内燃机原理的人，直接坐进驾驶室能把车开走，但发动机故障灯一亮，他连该不该继续开都不知道。

我的建议是：在你还没亲手写过一轮“没有框架的裸 Agent”之前，不要依赖任何重量级编排框架。裸写的过程会逼你理解每一次模型调用、每一次工具返回、每一次循环跳转是怎么发生的。有了这层底子，再去看框架，你会一眼看穿它帮你做了什么、没做什么、哪些地方设计得并不合理。

1.2 构建 Agent 的能力可以拆成三层

为了不让自己被海量知识点淹没，我习惯把 Agent 构建能力拆成三层：

• 第一层是模型应用基础：提示词制作、上下文窗口管理、结构化输出。没有这一层，Agent 连“稳定说话”都做不到。
• 第二层是工具交互能力：让模型学会调用外部函数、解析返回值、处理异常。没有这一层，Agent 只是一个会聊天的文本生成器，不算 Agent。
• 第三层是运行时编排能力：多轮循环、记忆管理、任务规划、状态控制。没有这一层，Agent 只能完成一次性任务，无法处理多步骤需求。

这个分层不是学术分类，它对应的是真实工程的递进关系。每一层都建立在前一层完全跑通的基础上。很多人学得痛苦，是因为第三层还没到，就开始研究多智能体协作和复杂规划算法，结果基础抖动，上层全部坍塌。

1.3 一套已验证的入门总览

按这三层，我给出一条已验证可行的路线，下面几个章节就是按这个顺序展开的：

这套时间线偏保守，但它保证了每一步的成果都能当场验证。下面我拆开细讲每一阶段真正该练什么，以及哪些地方容易翻车。

2. 第一阶段的重点不是“写 Prompt”，而是“驯服输出”

2.1 把单次交互练到极致，再谈多步循环

很多人一上来就写多轮对话逻辑，但其实 Agent 最基础的单位是单轮调用：你给模型一个指令、一些上下文，它给你一个响应。这一步如果不稳定，后面循环多少次都是错的累加。

我练这一阶段的方法很简单：反复给同一个任务换不同写法，然后观察输出的变化规律。比如让模型从一段商品描述里抽取价格和库存状态，用自然语言回答和用 JSON 回答，差异有多大；在指令里加不加“如果信息缺失，输出 null”这种边界说明，差异又有多大；温度调高和调低，稳定性差多少。练的是你判断模型行为模式的直觉，不是背 Prompt 模板。

一个很反直觉的经验是：模型的指令遵循能力，在文档里看起来很强，但在边界条件下非常不可靠。你告诉它“只输出 JSON”，它偶尔会在 JSON 外面包一层 Markdown 代码块；你告诉它“不要编造数据”，信息不足时它依然会脑补。这些不是你写 Prompt 不够好，而是你需要引入后处理机制和约束机制。

2.2 上下文窗口管理的三个基础操作

上下文窗口是 Agent 最容易踩坑的地方。第一阶段你必须亲手做三件事：

第一，学会算 Token。不用做得很精细，但要有一个估算能力。中文大概一个字对应 1 到 2 个 Token，英文一个词对应 1 到 1.5 个 Token。拿到一个任务，先估算一轮请求要吃多少 Token，再估算你打算塞进去的历史记录会占多少。

第二，学会塞入和裁剪。你要写一个简单的上下文管理函数，决定哪些历史消息要带、哪些要丢、系统提示词要不要重复注入、长文档能不能分段处理。这一步先不追求策略复杂，只要保证“上下文不超限”就行。

第三，学会压缩。当历史消息太多时，最简单的办法是把前面的消息交给模型做一轮摘要，只保留摘要和最近的消息。这个方法不如向量检索优雅，但在很多业务场景下完全够用，而且便宜、快、易排查。

2.3 结构化输出是 Agent 的“语法基础”

一个经常被忽视的点是：Agent 的所有内部状态，几乎都依赖结构化输出。工具调用参数需要 JSON，规划结果需要 JSON，记忆写入需要 JSON。如果你的模型输出不稳定，后续所有解析逻辑都会变成“碰运气”。

所以第一阶段必须练出一种能力：让模型对任意指令都能稳定返回合法 JSON，并且字段符合预期。我的做法分三步：

1. 在系统提示词里给一个明确的 JSON 格式示例，不只是字段名，还要给一个完整示例值。
2. 在用户消息里把约束写清楚：哪些字段允许为空、哪些值是枚举、枚举值具体是什么。
3. 在代码里做双重校验：先用解析器解析 JSON，再对每个字段做合法性检查。不合规则要求模型根据错误信息重新生成一次。

这里有个小技巧：让模型根据报错重生成，比直接要求“请修正你的输出”更有效。因为报错信息是精确的，而泛泛的修正指令依赖模型自己对“错误”的猜测。我在实验里用这套“解析-校验-重试”链路，能把结构化输出的成功率从 80% 提到接近 100%，代价只是偶尔多一次模型调用。

3. 第二阶段的核心：让模型学会“用工具”，而不是“聊工具”

3.1 工具是什么？Agent 为什么必须依赖工具

工具的本质很简单：把模型不擅长的事情外包出去。比如数学计算、数据库查询、发 HTTP 请求、操作本地文件，这些任务用代码做是确定性的，而语言模型做是概率性的。Agent 的价值不在于它自己能做这些事，而在于它能决定“什么时候该用哪个工具”。

我在教学时喜欢让学员做一个思维转换：模型不是一个知识库，是一个“会读说明书并执行操作”的调度员。它有推理能力，但没有可靠的记忆和精确的执行力。工具就是给它配备的“手脚”，Function Calling 就是“手脚”的控制协议。

3.2 理解工具调用协议的工作方式

从零构建时，你至少要了解工具调用协议最核心的机制：模型在生成回复时，先输出一个“我想调用某个函数”的意图，包含函数名和参数 JSON，然后由你的代码去真正执行这个函数。执行完，再把结果回填给模型，让模型继续生成下一轮回复。

这不难理解，但有一个细节容易忽略：模型生成的参数不一定合法。比如你的工具需要一个整数 ID，模型可能给你一个带引号的字符串，或者把两个参数合并成一个。所以在真正调用工具之前，必须有一个参数校验层，把模型的输出映射成函数真正需要的结构。我见过很多新手在这里偷懒，直接拿模型输出的 JSON 去调函数，结果线上环境遇到一次轻微格式漂移就崩了。

3.3 错误处理：工具返回异常后，Agent 如何恢复

第二阶段真正拉开差距的地方，是处理工具返回的异常情况。我总结出三类最常见的异常，以及对应的处理策略：

第一类是工具本身报错。比如网络请求超时、数据库权限不足。这种情况要做的不是让模型硬猜，而是把错误信息原样或者脱敏后传给模型，让它判断是重试还是换一个方案。我见过一个印象深刻的案例：某个开发者没有把错误信息传给模型，而是自己悄悄重试了三次，结果模型一直以为工具正常返回了空值，就基于错误的假设继续规划。这类问题的根因是信息断裂。

第二类是工具返回了意外格式。比如接口改了字段名、返回了嵌套结构。应对的办法是在工具解析层做容错，尽量规范化输出给模型。比如不管上游返回什么结构，你统一整理成“结果状态 + 数据摘要 + 原始提示”的固定格式，这样模型处理起来稳定得多。

第三类是工具结果互相矛盾。比如两个工具返回的库存数量不一致。这种情况模型做不了判断，你要在编排层设计规则来解决，比如定义优先级、写死冲突时的默认策略。这是第二阶段就该有的意识：不是所有问题都该交给模型解决。

3.4 第二阶段的自测方法

我判断一个人有没有真正掌握工具调用，会让他做一个很具体的任务：做一个 Agent，通过两个工具联动完成一次操作。比如第一个工具查用户订单号，第二个工具查订单物流，Agent 必须先用第一个工具拿结果，再从结果里提取参数，调用第二个工具，最终汇总成一句话回答用户。

这个任务看起来简单，但它覆盖了工具调用全链路。如果学员能做到“没有一次人工干预，连续跑通二十轮不同订单查询”，就算过关。注意是不同订单，不是同一句重复，这样才能暴露模型在不同输入下的不稳定行为。

4. 第三阶段：动手实现一个极简 Agent 运行时

4.1 Agentic Loop：理解 Agent 的“心跳”

Agent 和多轮对话之间最本质的差异，在一个循环：模型输出意图 → 代码执行工具 → 结果回填 → 再交给模型 → 直到模型认为任务完成。这个循环有个名字叫 Agentic Loop，是整个运行时的“心跳”。

自己实现一遍这个循环，比读十篇文章都有效。核心代码其实很短：一个 while 循环、一个状态容器、一组工具注册表、一个退出条件。但真正写一遍你才会意识到，最难的永远不是循环本身，而是循环的终止策略。

模型判断“任务完成”的依据是你给它的提示词和它自己的信心，这俩都不完全可靠。它可能认为完成，但实际上只跑了一半；它也可能在同一个错误结果上反复调用工具，形成死循环。所以实战中我坚持三重停止机制：第一，模型自己输出结束标记；第二，达到最大循环次数强制停止；第三，检测到重复动作连续 N 次时强制停止。第三重最容易被忽略，但它专门防模型陷入原地打转。

4.2 记忆管理：从“全量塞入”到“分层存储”

Agent 的记忆问题在第三阶段开始变得扎手。最简单粗暴的做法是每次请求全部带上历史记录，但 Token 成本很快会压垮你，而且模型注意力被无关历史稀释，反而影响新任务的执行效果。

我实践的方案是三层记忆模型：短期记忆只保留当前任务内的最近几轮交互；工作记忆用摘要保存上一个子任务的目标和结果；长期记忆用向量库按需检索，只有当模型认为需要时才去查询。这个设计不是我自己发明的，而是从多个人工程序里抽象出的共同模式。

刚开始从零构建时，你不需要做完整的向量检索，但要至少做到：把历史消息按轮次存档，并在下一次请求前做一个截断逻辑。比如保留最近 6 轮原始消息，加上前面所有轮次的一句话摘要。这个方案简单、可控、效果好，等以后数据量上来了再引入向量检索也不迟。

4.3 状态与控制：手动设计一个“任务状态机”

一个真正的 Agent 编排系统，内部其实是一个简单的状态机。任务有几种状态：待执行、执行中、等待工具结果、已完成、失败终止。工具调用不会直接推进任务，它只是把新的信息喂给模型；真正的状态转移还是由你的代码控制。

我建议在这个阶段画一个超级简单的状态转移表放代码旁边：

你不需要引入状态机库，用几个 if 就能写完，但这个练习的目的在于：让你形成“Agent 不是全能的，它由外部代码控制边界”的工程意识。很多框架帮你把这些藏起来了，你自己实现一遍才明白状态控制到底在控制什么。

4.4 关于“规划能力”的祛魅

第三阶段最容易被人为复杂化的是规划算法。市面上聊 Agent 必提“让模型自己规划子任务”，好像规划是 Agent 最核心的魔法。但实际经验是，让模型做规划依赖于三个前提：任务目标足够清晰、子任务之间依赖简单、模型对领域知识足够熟悉。三个前提缺一个，规划质量就直线下降。

所以从零构建时，我不建议一开始就设计复杂的规划器。先写死几个固定工作流，比如“先查询A再查询B然后汇总”，把流程跑稳。等你有能力评估规划质量了，再让模型参与规划。大部分业务场景里，固定流程 + 模型微调，已经能解决 80% 的问题，剩下 20% 才值得上真正的动态规划。

5. 第四阶段：让 Agent 从“能跑”变成“可控”

5.1 可观测性：每个决策都要能回放

Agent 系统和传统接口最大的区别在于：它的行为路径是动态的、非线性的。同一个用户问题，可能走三条完全不同的工具调用链。这样一来，一个模糊的“没答对”根本没法定位问题。

我给所有 Agent 加上三类日志：决策日志记录模型每次输出的原始内容、为什么选择这个工具；动作日志记录工具入参、出参、耗时、错误码；轨迹日志把整轮循环串起来，记录从用户提问到最终回答的完整路径。有了这三类日志，下次 Agent 答错时，你可以像回放录像一样找出是在哪一步跑偏的，而不是对着最终结果瞎猜。

5.2 评估：没有评测集的 Agent 就是定时炸弹

做 Agent 的人常常陷入一种“感觉变好了”的幻觉：今天调了一个 Prompt，测了几个例子觉得效果不错，就上线了；过两天改了一下工具描述，又测了几个例子，觉得也不错。但这种零散的验证完全不可靠，因为我踩过太多次“修好一个例子、搞坏一片例子”的坑。

规范的做法是维护一个评估集，至少包含三类样本：常见任务的正例、边界条件的难例、容易误操作的陷阱题。每次改动之后，把整个评估集跑一遍，对比通过率变化。不需要很复杂，哪怕只有三十条样本，也比人工随机点十个例子强一百倍。评估集不是一次性的，它要跟着业务持续补充，每次线上发现新问题，就把复现样本加进去。

5.3 多智能体：先问自己真的需要吗

第四阶段很多人会关注多智能体架构，我的态度非常保守：单个 Agent 跑不通的任务，两个 Agent 大概率也跑不通，只是更难排查而已。多智能体带来的不只是能力拆分，还有通信开销、协调成本、错误传播路径指数增长。

什么时候真的需要多智能体？我归纳了几个信号：单 Agent 的上下文装不下所有工具和知识；不同子任务需要的提示词差异巨大，混在一个系统提示词里互相干扰；或者你要做的不是一个流程，而是一个持续多日的长周期任务。出现这些信号时，再考虑拆。而且拆的第一原则不是“让多个 Agent 自由协作”，而是先分阶段串行——A 做完把结果交给 B，是最容易控制的多智能体模式。

6. 学习中常见的三个认知陷阱

6.1 把“跑通 Demo”当成“掌握”

我见过不少人的学习节奏是：照教程跑通一个 Demo，很开心，觉得自己会了。但 Demo 的代码是别人设计好的，路径是顺滑的，数据是干净的。真实世界的 Agent 开发，绝大多数时间花在调试那些教程里根本没提的意外上。

所以要学会自己给自己“制造困难”。跑通基础 Demo 后，立刻做三件事：把模型换成另一个能力弱一点的版本，看系统还能不能用；给工具加一个延时，看循环会不会异常；改掉上游返回字段名，看 Agent 能不能通过报错自愈。这三件事做过一轮，你对系统的理解深度会远超多看十篇教程。

6.2 用“加模型”代替“修逻辑”

一个新任务跑不通时，很多人的第一反应是：给模型更大的模型、更强的推理、更长的上下文。这种思路偶尔有效，但非常烧钱，而且会掩盖逻辑缺陷。

正确姿势是：先确认工具调用链路本身有没有问题，再确认信息传递有没有缺失，最后才是调模型。如果模型拿到的信息不正确、不完整，你给它再强的推理能力也白搭。实践里我宁可多花时间在数据传递和状态管理上，也不轻易升级模型规格，因为逻辑错误是确定性的，模型升级是概率性的。

6.3 忽视成本与延迟的约束

Agent 和普通 API 调用的最大区别是：一次完整任务可能消耗多次模型调用。当你把一个任务拆成“规划-执行-总结”三步时，成本可能翻了三倍，延迟也从几百毫秒变成十几秒。很多人在 Demo 阶段完全不考虑成本，等接到真实业务需求才发现系统根本跑不起。

从零构建一开始就要建立成本敏感意识。每个循环打印一次 Token 消耗，每个任务的失败重试要有限额，长上下文要控制历史条数。这些约束一开始就放进代码结构里，后面才不会返工。

7. 按自己节奏推进的几条实操建议

最后分享几条我带人入门时的实操建议，都是踩过坑之后沉淀下来的。

第一条：每个阶段都要有一个“验收作品”，不是学完就算。学完模型应用基础，就做一个固定格式的解析服务；学完工具调用，就做一个能完成多步操作的助手。作品不用大，但必须是独立完成的、能演示给别人看的。一个阶段没有验收作品，就不要进入下一阶段。

第二条：坚持写“踩坑日记”。每遇到一个意外问题，记下当时的现象、你排查的思路、最终根因。这个习惯一开始看起来很蠢，但三个月后回看，你会发现自己反复踩过的坑其实就那么几类，而你的排查效率会越来越快。我自己的踩坑日记现在已经变成团队的排错手册雏形了。

第三条：刻意限制自己的学习资源。不要同时关注二十个教程源，选定一套真正实操性强的材料，跟着做完，再考虑扩展。信息过载的学习状态，本质上和完全不学一样低效。我的原则是：一个主题只保留一个主教程和一份官方文档，其余全部当参考，不进入学习主线。

回头再看构建 Agent 这件事，它没有那么神秘，但也没有那么轻松。真正决定你走多远的，不是你掌握了多么复杂的规划算法，而是你有没有把模型应用、工具调用、运行时编排这三层底盘打扎实。按这个顺序走下来，你后面碰到的绝大多数问题都会在可控范围内。如果一个位置卡住了，不要怀疑自己天赋不行，很可能是前面某一步欠的债，回头补上就好。