CSDN小白/程序员必看：轻松入门大模型Agent，收藏这份从0到1实战指南！

要给 Agent 下个准确的定义，比想象中难。

这词你可能天天都能碰到，但真要追问一句“Agent 到底是什么”，能讲清楚的人并不多。

要么抛给你一串学术定义：感知、规划、记忆、行动，听起来都对，但落到工程里，还是不知道第一步该怎么做。

要么又把它讲得太玄，好像只要接上大模型、能回上两句话的系统，都能称作 Agent。

我猜不少朋友也有类似感受：概念听了很多，但还没真正从 0 到 1 搭过一个智能体，哪怕只是个 demo。

所以这篇文章不先追求一个完美定义。我们先把 Agent 和工作流的边界讲清楚，再用一个案例实际跑一遍。

一、什么是 Agent

关于“什么是工作流，什么是 Agent”

这里不再重复展开，只保留一个最简单的区分方式：

下一步做什么，如果是代码提前写死的，那更像工作流；如果需要模型根据当前情况自己判断，那才更接近 Agent。

Agent 是能围绕一个目标，自主判断下一步、调用工具，并持续推进任务完成的系统。

工作流 vs Agent

所以，判断一个系统是不是 Agent，关键不在于它有没有接大模型、有没有调用 API，而在于：

任务推进过程中，那些无法提前写死的关键决策，是不是交给了模型。

当然，这不代表什么都让模型决定。

真实的 Agent 往往是：确定的交给代码，不确定的交给模型；模型负责判断，工程负责兜底。

理解了这点，后面再看模型、工具、提示词和 ReAct 循环，就不会把它们当成孤立概念了。

二、Agent 设计基础概念

既然 Agent 的关键，是让模型在一定边界内参与任务推进和关键决策，那真正落地时，最先要看明白的是三个基础部分。

模型，决定它怎么想。

工具，决定它能做什么。

提示词，决定它按什么边界去想、去做。

Agent 的三大基础

这三个东西单独看都不复杂，但一组合起来，问题就开始变多。

原因也很简单：Agent 不是传统代码。

传统代码更多是在处理确定规则，哪里写错了，就回去改那段逻辑；但 Agent 要面对的是不完整的信息、变化的上下文，以及每一步都可能不同的工具结果。

我之前看到过一句话，放在这里特别合适：做 Agent 型产品，底层思维不是完全相信大模型，而是在相信它能判断的同时，用产品和工程尽量降低它的不确定性。

接下来准备介绍的模型、工具、提示词，其实都是围绕这件事展开：哪些地方相信模型，哪些地方用工程把边界兜住。

一）模型

模型就是智能体的大脑，负责推理、判断和决策。

选模型的第一直觉，往往是直接挑最强的。

但真正跑起来你会发现，没有哪个模型能在能力、延迟、成本上同时做到最好，选模型本质上是在做取舍。

1、不是所有任务都需要能力最强的模型

一个完整任务链路拆开看，是一堆难度不一的小任务。

给文本归类、提取订单号、判断用户问的是售后还是物流，这类任务不需要用能力最强的模型。

更轻量的模型就能处理。

但像这份合同有没有风险、这段需求到底该不该承诺、用户这个问题是不是涉及权限边界，就不一样了。

它需要反复权衡，需要理解上下文，也需要判断风险，这才轮得到能力更强的模型上场。

我做 AI 落地时也踩过这个坑。

一条链路要调七八次模型，如果每一步都套最强的，延迟会被一层层叠起来，用户等得难受，token 成本也很快上去。

所以，不是每一步都要用能力最强的模型，关键是把能力更强的模型留给真正需要判断的地方。

把能力更强的模型留给判断

2、先保效果，再压成本

那具体怎么判断，哪些环节需要能力更强的模型，哪些环节可以换成更轻量的模型？

我现在更推荐的做法是，先用能力更强的模型把每个环节的原型跑通，把效果上限测出来。

等链路能稳定完成任务了，再逐个环节换成更轻量的模型，看效果下降多少，业务能不能接受。

这样做的好处是，你不会一开始就把能力上限封死，也能看清楚哪些环节可以降配，哪些环节应该保留。

顺序别搞反。

一个连任务都完成不好的智能体，哪怕它再快、再便宜，也没人买单。

3、别让模型做确定性的事

很多人发现 Agent 处理速度很慢，不是因为模型不够强，而是因为太多本来可以确定处理的事情，也被交给了模型。

比如 参数校验、固定格式转换、字段映射、简单分支判断，这些事情交给代码更稳定，也更便宜。

模型真正该负责的，是那些规则提前写不死的部分。

比如用户意图模糊、信息不完整、下一步取决于工具返回，或者多个方案之间需要权衡优先级。

确定的交给代码，不确定的交给模型。

二）工具

模型是大脑，工具就是手脚。

只会推理、不能行动的智能体，很难真正完成任务。工具就是它连接真实世界的方式。

但工具不是随便接几个 API 就完事。

工具设计得好，模型的判断会更稳定；工具设计得不好，模型再强，也容易被错误的信息结构误导。

按工具大致分成两类：

• • 数据类：让智能体取到干活需要的信息，比如查数据库、读 PDF、搜网页；
• • 行动类：让智能体动手改变点什么，比如发邮件、更新记录、把工单转人工；

先记住这个分类就够了。

真正考验功夫的是：给模型多少个工具，职责怎么划，每个工具返回的信息能不能支撑它继续判断。

工具设计的三道护栏

下面这几个坑，都是我最近在项目里遇到过的，也更接近真实落地时会出问题的地方。

1、工具返回结果，要分清“没权限”和“没数据”

有个反直觉的点：工具明确告诉模型“这里你没权限看”，往往比悄悄返回一个空结果更安全。

因为模型看到空值，很容易理解成“数据不存在”。

我做工业软件的 Agent 时遇到过。

查物料信息时，普通字段谁都能看，但成本价、供应商这类敏感字段，只有特定角色有权限。

早期图省事，没权限的字段后端直接返回空。结果模型一看成本价是空的，就告诉用户“该对象未填写成本价”。

系统数据中明明有，只是这个用户不该看，却被解读成了字段“没填”。

混合场景更麻烦：查出十条记录，其中三条当前用户无权访问。

如果 Agent 直接过滤，用户会以为总共只有七条；如果因为这三条直接报错，模型就拿不到任何结果，连剩下七条本来能看的记录也用不上。

正确的做法，是让权限状态在返回结果里显形：

• • 没权限的字段，标成“受限”，而不是只给个空值；
• • 能看的记录正常返回，看不了的，补一句“另有 N 条因权限未展示”。

工具把权限边界标清楚，AI 才能既不漏报、也不越权：该给的给到，不该给的明确挡住。

没权限不等于没数据

2、工具返回结果，要让模型看得懂

工具返回的不是给人看的接口文档，而是模型下一步判断的依据。

这点很容易被忽略。

我在基于工业软件做 Agent 的过程中，会优先复用现有的开放接口，封装成工具，这样省事点。

但是有些老接口会返回一大段原始 JSON，字段名又长又乱，还混着很多当前任务用不上的字段。

这样模型拿到之后容易抓错重点。又慢，又贵，还容易误解。

所以，我现在更倾向于在工具层先整理一遍，把返回结果变成模型能直接使用的业务状态，保持最干净的状态。

比如查订单，不要只返回一堆数据库字段，而是直接告诉模型重点信息：

• • 订单状态是什么；
• • 是否满足退款条件；
• • 缺少哪些信息；
• • 当前状态下有哪些业务约束；
• • 哪些字段因为权限不能展示。

比如这样的结构：

{ "order_status": "delivered", "refund_eligible": true, "missing_info": [], "business_constraints": [ "退款申请需在签收后 7 天内发起", "已拆封商品需要人工审核" ], "restricted_fields": ["cost_price", "supplier_name"]}

这样做的目的，不是替模型决定下一步，而是减少它理解业务状态时的猜测。

好的工具返回结果，不是把数据原样丢给模型，而是把业务状态翻译成模型看得懂的结构。

3、工具不是越多越好

直觉上，给 Agent 配的工具越多，它能干的事情就越多。但实际跑起来，经常不是这样。

我自己在项目里就遇到过一个很典型的问题。

第一版设计很简单：一个节点、一份大提示词，再把所有工具都平铺给模型

工具少的时候没什么问题，但随着能力越来越多，模型开始不稳定：

• • 有时分不清两个职责相近的工具；
• • 有时对象类型识别错了，后面的工具自然全选偏；
• • 有时上下文太长，直接漏掉某条规则。

后来我发现，问题不只是“工具太多”。

更准确地说，是我让模型在同一轮里同时完成了太多事情：理解用户意图 → 从全部工具里做选择 → 填参数 → 最后组织语言。

每一步都不算特别难，但全部塞在一次判断里，出错概率就会叠起来。

所以工具变多之后，第一反应不应该是继续往提示词里堆规则。

更有效的做法，往往是先拆职责，再缩小模型每次需要面对的选择范围。

4、先缩小范围，再匹配工具

后来我把原来的大节点拆成了三段：

• • 先分流（Router）： 先判断这个请求属于哪个能力域；
• • 再执行（Executor） ：只在当前能力域里选择工具、填写参数；
• • 最后表达（Composer）： 最后把工具结果组织成用户能理解的回答。

关键不在于一定拆成三段，而在于先缩小选择范围。

先给工具划好“能力域”，让智能体先锁定范围，再在小范围里匹配工具。

选择面从“全部工具”缩到“几个相关的工具”，这样，选错的概率自然就降下来了。

当工具和规则越来越多时，没必要让它在一次判断里同时处理所有事情。

5、分几层，跟着复杂度走

这里要补一句，免得你以为每个 Agent 都要拆这么细。

工具不多的时候，光靠这一层“能力域”的路由就够用了。再往下细分，只会增加延迟和成本，没必要。

什么时候该再加一层？

等某个能力域里的工具继续增多、模型在域内也开始频繁选错时，再考虑增加一层意图识别。

先判断用户这次是要“查数据记录”还是“统计数量”，再据此把工具子集缩得更小。

说到底还是同一套漏斗逻辑：从最模糊的用户输入，一层层收窄到最后那几个候选工具。

层数不是越多越好，够用就行。

6、有代价的工具，必须有人确认

还有一类工具要单独讲，就是行动类工具。

查数据库、搜网页、读 PDF，错了可以重来。

但发邮件、删数据、下订单、改合同状态，这类动作一旦执行，就会影响真实世界。

这类工具不能只靠模型自己决定并直接执行。

原则很简单：凡是不可逆、有成本、超出授权边界、或者影响别人权益的操作，都要加一道确认。

这就是后面实战里订酒店前要停下来问你的原因。

Agent 可以自主，但自主一定有边界。这个边界不是写在口号里，而是写在高风险工具调用前的确认机制里。

三）提示词

指令写得好不好，对任何大模型应用都重要，但对智能体尤其关键。

如果只是单轮内容生成，提示词写得不够清楚，通常影响的是回答质量。

Agent 不一样。

提示词一旦含糊，影响的不是一句回答，而是后面一整串动作。

它可能选错工具、填错参数、漏掉权限判断，甚至在该停下来的时候继续往前走。

所以 Agent 的提示词，要帮模型分清两件事：

哪些规则是确定的，必须遵守；哪些步骤是不确定的，需要自己判断。

把文档变成 Agent 能执行的提示词

有一点很容易混淆：

Agent 的整体路径可以动态，但局部业务规则依然可以是确定的。

比如退款处理，用户怎么描述问题、下一步该查什么、要不要追问，可能需要 Agent 判断；但退款政策、权限边界、哪些动作必须确认，不能让模型临场发挥。

所以提示词不是把 Agent 写成固定工作流，而是把确定的规则和边界交代清楚。

1、确定规则怎么写

1）备料：先找现成依据

不要从零开始凭空写指令。

公司里现成的 SOP、政策文档、客服话术、知识库文章，往往就是最好的材料。

只要你不是在重塑业务流程，就没必要重新发明一套规则，直接把这些资料改造成指令，效率最高。

很多时候不是缺提示词技巧，而是缺业务材料。真正懂业务的人，早就把规则写在培训手册、质检标准和老员工经验里了。

2）拆解：把复杂规则拆成步骤

如果某个环节本来就有明确 SOP，不要把一大段资料原样交给模型，而是要拆成它可以逐步执行的步骤。

不好的做法，是直接把一整篇 2000 字的退款政策原文交给它，让模型参照着处理。

更稳定的做法：把那篇政策拆解成清晰的步骤：

– 步骤1：确认下单是否在 7 天内 – 步骤2：确认商品是否已拆封 – 步骤3：核对是否满足退款条件 – 步骤4：发起退款并通知用户

步骤越清楚，模型越不容易理解跑偏。

3）定义：把每一步动作说具体

指令里的每一步，都要写清楚“具体做什么”、“具体输出什么”，不要只写一个模糊方向。

不好的写法是：

向用户了解下订单情况。

这样，智能体很可能不知道下一步怎么执行。

是问用户？还是查数据库？

问什么？查哪个字段？

更明确的写法：

– 第一步：向用户提问“请提供您的订单号”- 第二步：拿到订单号后，调用 `getOrderDetails` API 查询订单详情

必要的时候，甚至连“话术是什么”都要写清楚，给足模型参考。

确定性环节少让模型自由发挥，需要判断的地方再交给它。

4）兜底：提前处理异常情况

真实用户很少完全按照你设想的流程走，兜底方案要提前写好。

理想流程：

问订单号 → 用户给了 → 查询 → 告诉结果

现实可能是这样：

• • 用户给的信息不全：你问订单号，他说“我不记得了”。
• • 用户突然问别的：查订单查到一半，他问“你们退货政策是什么”。

所谓“稳健的流程”，就是在指令里提前为这些场景写好异常分支：

– 如果用户提供了订单号 → 直接查询- 如果没有订单号 → 改用手机号 + 姓名查询- 如果用户中途问了无关问题 → 先简短回应，再拉回原流程

你可以先让模型根据现有文档整理初稿，但要记住：

模型可以帮你梳理规则，不能替你确认规则。

尤其是原文没有覆盖的异常情况，可以让模型先列出来，再由真正懂业务的人来判断。

2、探索型任务，写边界，不写剧本

另一种情况，是 路径不固定的探索型任务。

前面说的是那些本来就确定的业务规则和操作环节。

但很多时候，Agent 的价值就在于：整体路径没法提前写死，需要模型根据当前情况判断下一步。

所以像旅行规划、资料调研、代码修复这种探索型任务，就不要在提示词里把每一步写成固定剧本。

提示词不是都写成固定流程

比如旅行规划，就不适合强行规定它必须先查天气、再搜景点、再搜酒店、再生成行程。

因为查完天气发现下雨，它可能要先找室内景点；搜景点发现博物馆闭馆，它又要回头调整。

这种时候，提示词要写清楚的是：

• • 目标是什么；
• • 能用哪些工具；
• • 每次输出什么格式；
• • 什么信息算收集够了；
• • 哪些操作必须先问人；
• • 什么时候结束。

也就是给边界，而不是写死流程。

确定规则，写清依据、步骤、动作和异常分支。探索型任务，写清目标、工具、约束和停止条件。

前者是减少模型猜测，后者是给模型留下判断空间。

这个区别很重要。

如果混淆了，要么边界太松，Agent 容易乱跑；要么步骤写得太死，最后做出来的其实还是工作流。

三、Agent 常见设计模式

上一章把智能体的重要组件讲清楚了：模型、工具、提示词。

这一章接着看：这些组件，可以组合出哪些常见的智能体形态。

说到类型，很多资料一上来就列十几种模式，看起来很完整，但读完反而更容易混乱。

我更愿意把它拆成两条线来看。

第一条线问的是：一个 Agent 内部怎么推进任务。

是边想边做，还是先把计划列好再动手，还是干完了回头再改一遍。

第二条线问的是：这个任务用几个 Agent、它们怎么分工。

是一个 Agent 扛到底，还是一个中心节点调度多个专家，还是几个平级 Agent 互相交接。

一条讲“内部怎么推进”，一条讲“多个 Agent 怎么分工”。这两条线不是二选一，而是可以组合使用。

智能体有哪些类型

一）第一条线：Agent 内部怎么推进

1、ReAct：边想边做

这是最常见的一类模式，很多需要边查边判断的任务都会用到。

它的节奏是：想一步 → 调个工具 → 看结果 → 再想下一步。推理和行动交替进行，这也是它叫 ReAct（Reason + Act）的由来。

好处是每一步都基于真实结果推进，不容易完全凭空生成。

模型不是一口气把答案写完，而是先看工具返回了什么，再决定下一步怎么做。

什么时候用它？

如果下一步该调什么工具，取决于上一步查出来什么，就适合用 ReAct。

ReAct：边想边做

比如一个售后 Agent 收到用户问题：“我的订单为什么一直没动静？”

Agent 先查订单，发现状态是“待人工审核”，但原因字段为空。

它就不会直接下结论，而是继续查审核记录、仓库记录或物流状态，沿着工具返回的线索一步步排查。

ReAct 的价值就在这里：不是执行预设分支，而是看见一个结果，再决定下一步查哪里。

它的代价也很明显，就是慢。

每转一轮都要调用一次模型，步骤一多，延迟就会明显增加。所以 ReAct 适合动态任务，但不适合所有任务都直接套用。

2、Plan-and-Execute：先谋后动

ReAct 是走一步看一步，Plan-and-Execute 是先把计划列出来，再按计划执行。

比如一个 Agent 要写一份竞品分析报告。

整体步骤一开始就能拆出来：先确定分析维度，再收集资料、整理对比表、提炼结论、写成报告。

Plan-and-Execute 的价值就在这里：先让 Agent 把复杂目标拆成一组可执行任务，再逐个推进。

Plan-and-Execute：先谋后动

它解决的是“任务太大，模型一口气做容易乱”的问题。

这种模式下，模型不是一上来就写答案，而是先搭一个任务骨架，输出结果的稳定性也会更强。

这里要和工作流分清楚。

如果一件事的步骤稳定、条件明确、分支也能提前枚举，那更适合写成工作流。

Plan-and-Execute 适合的是大方向能规划，但执行细节还需要模型判断的任务。

而且这个计划不是固定的。

执行过程中，如果发现信息不够、某一步走不通，也要允许它局部调整，必要时重新规划。

它的代价也很明显：

1、如果任务本来很简单，专门多花一次调用去做规划，通常不划算；

2、如果一开始计划拆错了，后面执行得越认真，可能偏得越远。

3、Reflection：做完再检查

模型的第一版输出，说到底是它基于上下文算出来的一个高概率答案。

但“最可能”不等于“最对”。

Reflection 的做法是：让模型换一个角色，检查前一轮输出的问题，再根据检查结果修正。

Reflection：做完再检查

这和写文章、写代码其实很像。初稿先解决有没有，第二遍再看准不准，第三遍才谈好不好。

它适合那种“第一版通常还能继续优化，而且有相对明确检查标准”的场景，比如长文写作、代码生成、方案设计。

但如果场景对延迟很敏感，而且允许一定误差，就不一定要加 Reflection。

它也不是没有成本：多一道检查，就多一次调用，也需要多一段等待时间。

二）第二条线：多个 Agent 怎么分工

1、单体

一个 Agent，配好工具和指令，一个循环从头跑到尾。

单体 Agent：一个 Agent 扛全程

不要因为它简单，就觉得它不够高级。恰恰相反，大多数任务，一个调好的单体就够了。

每多引入一个 Agent，就多一条通信链路、多一个出错点，也会增加调试成本。任务本身不需要那个复杂度时，最好的选择就是什么都不加。

我现在越来越觉得，做 Agent 很像做系统设计。

不是一上来就拆服务、上架构，而是先看单体能不能把问题解决掉。单体真的扛不住了，再考虑往多体走。

2、多体 – 管理者

单体扛不住，通常是因为一个 Agent 的任务太杂。

工具列表太长，职责太多，注意力被稀释，每件事都做得不够稳定。

管理者模式的解法是分工：一个中央 manager 负责拆任务、分派给专家、最后把结果收回来。

搜索的只管搜索，写代码的只管代码，分析数据的只管分析数据。每个专家都在自己的小上下文里，处理最擅长的部分。

manager 不只是转发任务，它还要负责看各个专家的结果能不能拼到一起。

管理者模式：一个中心调度多个专家

它适合那种能清晰拆成几块、又需要统一收口的任务。

比如一个复杂调研任务，可能同时需要搜索资料、整理事实、写初稿、做审校。

这个时候，让一个 manager 来拆任务、控进度、做汇总，就会比一个 Agent 全部承担更稳。

3、多体 – 交接模式

管理者模式是中心调度，去中心化模式则是接力交接。

这里没有一个固定总指挥，Agent 之间可以直接把控制权“交接”给对方。

当前 Agent 判断这件事该由谁处理，就把任务和上下文一起交过去，接手的 Agent 继续往下推进。

交接模式：合适的人接着做

客服分流是最典型的例子：一个分诊 Agent 判断用户是要退款还是问技术，然后交给对应的专员 Agent 接手，自己不再参与后续处理。

它适合请求类型比较清楚、一次交接到合适专家后就能继续推进、不需要统一汇总收口的场景。

反过来，如果任务需要多个专家并行处理，最后还要合成一个完整结果，那就更适合管理者模式。

三）两条线可以组合，不是二选一

前面把两条线分开讲，是为了方便理解。但真到用的时候，它们往往是叠在一起的。

第二条线决定“谁来做”，第一条线决定“怎么推进”。

比如一个企业级系统，外层可能用管理者架构搭骨架，由 manager 用 Plan-and-Execute 拆任务，再派给几个专家 Agent；

每个专家内部再跑 ReAct，边调工具边推进；最后过一道 Reflection 做检查。

所以别把这些模式当成互斥选项去背，把它们当成可以组合的设计模块就好。

但组合不代表越多越好。

类型不是越往多体走越高级。从单体到多体，增加的是复杂度，不是能力等级。

能一个 Agent 完成的，就不要拆成三个。优先找最简单的方案，只在真正需要时才增加复杂度。

四、跑通一个最小 Agent

前面三章，把 Agent 是什么、由哪些零件组成、有哪些常见形态，都讲完了。

这一章不添新概念，只做一件事：带你亲手跑通一个最小可用的 Agent。

不需要你手写代码。把需求讲清楚，让 Cursor 生成代码，你负责运行、观察结果，再根据结果调整。

暑假到了，有娃的朋友们可能已经开始准备带娃出去玩了。

我们就做一个旅行规划助手：输入“未来三天的苏州旅程”，它自己查天气、搜景点，最后生成一份三天行程。

1、先想清楚：为什么这个场景适合 Agent

关键在于，天气不是终点，而是约束。

查到某天下雨，就要把露天景点挪走，换成室内安排；排完发现博物馆周一闭馆，又要回头调整。

这条链一环扣一环，下一步调什么，取决于上一步查到了什么。这正是 ReAct 适合发挥作用的场景。

对照前两章讲过的组件，这个 Agent 至少需要五个部分：

• • 大脑：LLM，负责每一轮的推理
• • 手脚（工具）：查天气、搜景点、模拟订酒店
• • system prompt：告诉它能用哪些工具、按什么规则推进的提示词
• • 循环：想 → 动 → 看 → 再想，直到行程排好为止
• • 停止条件和确认机制：最多循环几轮就停；遇到有成本的操作，先停下来让人确认

2、准备 API Key 和工具

要准备的东西不多，三个基础配置，再加一个免注册的天气服务：

• • 一个 Coding Agent：Cursor / Claude Code / Codex（用来生成和运行代码）
• • 一个 LLM 的 API key（给 Agent 当大脑）
• • 一个 Tavily API key（给 Agent 当搜索引擎）
• • 查天气用 wttr.in，免注册、不要 key

LLM 我用的是智谱，开放平台获取 API Key 的位置在这里：https://bigmodel.cn/apikey/platform

在模型预览地址，选择合适的模型，并复制对应的 API 文档，作为 Cursor 编写 Agent 的上下文。

https://docs.bigmodel.cn/cn/guide/start/model-overview
```

Tavily API Key 获取地址：https://app.tavily.com/home


#### 3、把需求发给 Coding Agent

我这里打开 Cursor，把下面这段话发给它：

```plaintext
帮我用 Python 写一个"旅行规划助手" agent，要求：## 目标用户给一句话（比如"暑期苏州三天游"），它自己规划出一份三天行程。## 工具1. get_weather(city)：用免费的 wttr.in 查未来天气，不需要 key；2. search_web(query)：用 Tavily API 搜景点、美食、营业时间；3. book_hotel(name)：模拟订酒店，先不用真订。## 运行逻辑用最经典的 ReAct 循环：每一圈让模型输出一段Thought（怎么想）+ Action（调哪个工具、参数是什么）；程序执行工具、把结果作为 Observation 塞回去，进入下一圈；模型觉得行程排好了，就输出 Action: Finish[最终行程] 结束。## 注意事项1. 主循环最多转 12 圈，防止它无限打转；2. 只要模型想调 book_hotel（要花钱的操作），程序必须先停下来、 在终端问我"确认要订吗？"，我回 y 才执行，回别的就跳过。3. 不可以在提示词中约束固定步骤，必须使用 ReAct 的最佳实践。## Tavily1. apikey：xxx2. 请求示例：search_depth 中 basic 代表快速获取答案，advanced 代表进阶获取```curl -X POST https://api.tavily.com/search \\-H 'Content-Type: application/json' \\-H 'Authorization: Bearer tvly-dev-*************************************************' \\-d '{ "query": "", "search_depth": "basic"}'```## LLM1. base_url:xxx2. model:xxx3. api_key:xxx4. 参考文档：xxx

这段话本身就把目标、工具、循环方式、停止条件和确认机制交代清楚了。

剩下的就交给编码完成后，边测试边调试就可以了。

4、看懂核心：system prompt

AI 会生成三个文件：tools.py（工具）、llm.py（调用 LLM）、agent.py（主循环）。

我们再来看看实际跑通后的 agent.py 里的 system prompt。

备注：这是基于前面的需求，多次调试后得到的一版提示词。提示词存在的偏好，个人看法， 仅供参考。

SYSTEM_PROMPT = """你是一个专业的旅行规划助手。用户给你一个旅行需求，你通过调用工具自主收集信息，判断信息足够后输出一份详细的三天行程规划。每次回复必须严格按照下面格式输出，且每次只能包含一个 Thought 和一个 Action：Thought: <你的思考——当前掌握了什么、还缺什么、下一步打算做什么>Action: <工具名>[<参数>]可用工具：- get_weather[城市名]：查询该城市未来三天的天气- search_web[查询词]：搜索景点、美食、住宿等信息- book_hotel[酒店名]：预订酒店（需用户确认）当你判断信息已足够，输出最终行程：Thought: <自检过程及结论>Action: Finish[完整的三天行程规划]—生成行程前需要掌握的信息（你来决定如何收集、收集几次）：- 目的地未来三天天气- 主要景点（室内和户外各有哪些，营业时间 / 休息日）- 当地特色美食- 住宿选择（如用户需要预订，再用 book_hotel 预订一家）注意，涉及景点营业时间、闭馆日等动态信息，优先使用景区官网、官方公众号或权威来源；通常 5-8 次工具调用即可收集齐全，超过 10 次应评估是否已有足够信息。—天气联动原则（生成行程时遵守）：- 晴天 / 多云：优先安排户外景点- 高温（≥32°C）：户外活动移至早晨或傍晚，午间安排室内- 小雨 / 阵雨： 允许：博物馆、美术馆、寺庙室内大殿、古街漫步（带伞）、有顶篷游船 禁止：大型露天古典园林（如拙政园、留园等）、爬山 / 山丘类景点（地滑危险） 行程中注明"建议携带雨具"- 大雨 / 暴雨：整天以室内活动为主，提示注意安全- 每天开头注明天气，并说明与景点安排的对应逻辑地理动线原则（生成行程时遵守）：- 同一天景点尽量集中在相邻区域，减少来回折返- 餐饮就近安排，不为吃饭单独绕远- 每天开头简要说明当日活动重心区域自检（输出 Finish 前，在 Thought 中逐项确认）：- 雨天是否有大型露天古典园林或爬山类景点？有 → 从已收集的备选中替换- 大雨天是否有无遮蔽的露天湖边活动？有 → 替换- 是否有景点安排在闭馆时段（如博物馆周一）？有 → 调整- 餐饮是否就近安排，无绕远情况？全部通过 → 输出 Finish；有问题 → 先在 Thought 中说明替换方案，再输出修正版 Finish。规则：- 每次只输出一个 Thought + 一个 Action，绝对不要一次性输出多个 Action- Action 的方括号内是参数，不要加引号或额外格式- 不要输出 Markdown 代码块"""

我们来简单解读下。

Thought + Action 是这个 demo 的格式约定，方便程序解析，也方便你在终端里看清楚 ReAct 循环。

备注：显式输出 Thought，只是为了解释过程，不代表生产环境的最佳实践。

真做产品时，用 function calling、structured output 这类更稳的方式。

循环次数也一样。

提示词里的“通常 5-8 次工具调用”“超过 10 次应评估”，只是给模型的软提醒。

真正防止无限循环的，是代码里的硬上限，比如主循环最多跑 12 轮。

这段提示词真正值得看的是三块：

• • 信息清单：告诉模型生成行程前至少要掌握哪些信息，并给出软性的调用次数参考，避免查两下就急着收尾；
• • 天气联动和地理动线：把雨天、高温、区域集中、餐饮就近这些约束写清楚，让行程更像真的能用；
• • 输出前自检：在 Finish 前逐项检查天气、闭馆、动线等问题，有问题先替换，再输出最终行程。

注意，真实开发过程中，任务该不该结束，不能只看跑了几轮，还要看信息是不是收集够了、自检有没有通过、有没有需要用户确认的动作。

轮数是防失控，状态才决定能不能收尾。

5、跑起来，看 ReAct 循环怎么推进

接下来，我们看它真正跑起来是什么样。

首先在终端运行：

python agent.py "未来三天苏州游，顺便帮我推荐一家 500 左右一晚、地点合适的酒店"

你能清楚地看到：每一轮 Action，都依赖上一轮 Observation。

查到天气之后，它才知道哪些天适合户外；搜到景点营业时间之后，它才知道哪里需要调整。

它不是一口气生成一份行程，而是基于工具返回一步步推进。

6、确认机制：为什么订酒店前要停

跑到第六轮的时候，终端会出现：

前面几轮它可以自主推进，到 book_hotel 这里停下来问你，这是故意设计出来的。

查天气、搜景点是数据类工具，结果不理想还可以重查，允许它自主调用问题不大。

订酒店是 行动类 工具，可能产生真实成本，一旦执行就不容易撤回。

凡是不可逆、有代价的操作，就该让用户确认后再执行。

Agent 可以自己查资料、自己调整方案，但不能替用户花钱做决定。

7、最终输出行程

确认或跳过订酒店之后，它会把前面收集到的信息整理成一份完整计划。

这份结果不是单纯把景点罗列出来，而是会把天气、动线、餐饮和住宿建议一起考虑进去。

回头看这个 demo，它只有一个大脑、一套循环，从头跑到尾，就是上一章说的单体 Agent；它每一轮都在想一步、调个工具、看结果、再想下一步，就是 ReAct。

例子很简单，但目标、工具、循环、停止条件和确认机制都齐了。

跑通这一遍，Agent 怎么围绕目标一步步推进，基本就有感觉了。

五、总结一下

最后总结一下，从 Agent 是什么，到模型、工具、提示词，再到常见形态和最小实战，基本轮廓就差不多清楚了。

说到最后，还是那句话：优先找最简单的方案，只在真正需要时才增加复杂度。

Agent 很容易让人兴奋，但最后能不能跑稳，往往不取决于架构名字有多好听，而取决于几个很朴素的问题：

目标有没有说清楚？

工具边界有没有设计好？

哪些地方该让模型判断，哪些地方该交给代码？

有代价的动作，有没有让人确认？

这些问题想清楚了，一个简单的单体 Agent，也能把问题解决。想不清楚，再复杂的架构，也只是把问题放大。

真正做工程时，也不需要从零手写循环，现有 Agent 框架已经封装了不少底层能力。

普通人如何抓住AI大模型的风口？

领取方式在文末

2026年入行AI大模型的黄金窗口!!!

AI产业正迎来前所未有的爆发式增长。 从DeepSeek以百万年薪重金招募顶尖研究员，到百度、阿里、腾讯等头部企业加速推进AI Agent商业化布局，再到国家层面持续出台政策，大力扶持数字经济与AI人才培育体系，多重信号清晰指向一个共识：AI的“黄金十年”已全面开启

在产业浪潮的强劲推动下，AI人才争夺战日趋白热化。技术迭代与场景落地双轮驱动，催生海量高价值岗位。放眼未来，AI领域的职业发展前景广阔无垠，正涌现出大量高潜机遇，堪称一片值得深耕的**“人才蓝海”**。

脉脉数据显示📊：
2026年1-2月，AI岗位数量同比增长约12倍，增速远超新经济行业整体增幅；AI岗位在全部新经济岗位中的占比也从2025年同期的2.29%跃升至26.23%，几乎占据新经济招聘市场的四分之一。

与此同时，AI新发岗位平均月薪高达60738元，较新经济行业整体平均月薪48189元高出约26%。

这一切都说明一件事：2026年，正是入行AI大模型的黄金窗口❗️❗️

最佳学习路线

只要你真心想学习AI大模型技术，这份精心整理的学习资料我愿意无偿分享给你，但是想学技术去乱搞的人别来找我！

在当前这个人工智能高速发展的时代，AI大模型正在深刻改变各行各业。我国对高水平AI人才的需求也日益增长，真正懂技术、能落地的人才依旧紧缺。我也希望通过这份资料，能够帮助更多有志于AI领域的朋友入门并深入学习。

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

大模型全套学习资料展示

自我们与MoPaaS魔泊云合作以来，我们不断打磨课程体系与技术内容，在细节上精益求精，同时在技术层面也新增了许多前沿且实用的内容，力求为大家带来更系统、更实战、更落地的大模型学习体验。

希望这份系统、实用的大模型学习路径，能够帮助你从零入门，进阶到实战，真正掌握AI时代的核心技能！

01 教学内容

• 从零到精通完整闭环：【基础理论 →RAG开发 → Agent设计 → 模型微调与私有化部署调→热门技术】5大模块，内容比传统教材更贴近企业实战！

• 大量真实项目案例： 带你亲自上手搞数据清洗、模型调优这些硬核操作，把课本知识变成真本事‌！

02适学人群

应届毕业生‌： 无工作经验但想要系统学习AI大模型技术，期待通过实战项目掌握核心技术。

零基础转型‌： 非技术背景但关注AI应用场景，计划通过低代码工具实现“AI+行业”跨界‌。

业务赋能突破瓶颈： 传统开发者（Java/前端等）学习Transformer架构与LangChain框架，向AI全栈工程师转型‌。

vx扫描下方二维码即可
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】

本教程比较珍贵，仅限大家自行学习，不要传播！更严禁商用！

03 入门到进阶学习路线图

大模型学习路线图，整体分为5个大的阶段：

04 视频和书籍PDF合集

从0到掌握主流大模型技术视频教程（涵盖模型训练、微调、RAG、LangChain、Agent开发等实战方向）

新手必备的大模型学习PDF书单来了！全是硬核知识，帮你少走弯路（不吹牛，真有用）

05 行业报告+白皮书合集

收集70+报告与白皮书，了解行业最新动态！

06 90+份面试题/经验

AI大模型岗位面试经验总结（谁学技术不是为了赚$呢，找个好的岗位很重要）

07 deepseek部署包+技巧大全

由于篇幅有限

只展示部分资料

并且还在持续更新中…

人工智能大潮已来，不加入就可能被淘汰。如果你是技术人，尤其是互联网从业者，现在就开始学习AI大模型技术，真的是给你的人生一个重要建议！

真诚无偿分享！！！
vx扫描下方二维码即可
加上后会一个个给大家发
【附赠一节免费的直播讲座，技术大佬带你学习大模型的相关知识、学习思路、就业前景以及怎么结合当前的工作发展方向等，欢迎大家~】