做产品时最容易踩的坑，是把「给大模型加个对话框」当成智能体，结果需求评审时说不清为什么这个功能智能体做不了、为什么要加钱加延迟。这篇不聊模型参数，只从产品角度把两者的能力边界摆开：传统大模型做什么、智能体多出来哪几块、什么任务值得上智能体、什么任务上它就是给自己找麻烦。
做产品最容易踩的坑，是把「给大模型加个对话框」当成智能体。需求评审时说不清为什么这个功能智能体做不了、为什么要加延迟加成本，根子往往在于没把两者的能力边界摆开。这篇不聊模型参数，只从产品角度讲清：传统大模型能干什么、智能体多出哪几块、什么任务值得上、什么任务上了就是给自己找麻烦。
先给个粗糙但好用的直觉：传统大模型是「问一句答一句」，智能体是「接个目标，自己想几步、动手做几步、看结果再调整」。中间差的不是模型更聪明，而是外面多了一圈规划、工具和循环的壳。产品同学要判断的，就是这圈壳值不值得加。
先划清：传统大模型的能力天花板在哪
传统大模型本质是一次输入到一次输出的映射：你给提示词和上下文，它给一段文本或结构化结果，中间不自己决定下一步。它的强项是理解、总结、改写、分类、生成；弱项是「需要先查一下才知道」的事实，以及需要真正动手操作外部系统的事。
- 一次映射
- 输入进去、结果出来，模型不掌管道中间要不要再查、再做
- 知识截止
- 训练时没见过的东西，它只能猜，猜得像真的但不可靠
- 无手无脚
- 查库存、改订单、发邮件这些动作，必须外面有系统去执行
产品上最常见的误区，是以为接了大模型就能查库存、改订单、发邮件。实际上这些能力一行都不在模型里，全靠外部系统提供。评审时如果需求写着「让 AI 帮用户下单」，先问一句：下单这个动作由谁执行、参数从哪来、失败了谁兜底。答不上来，说明这个需求缺的不是模型，是接口。
多出来的第一块：规划与多轮循环
规划指的是模型先把任务拆成若干子步骤，再逐步执行，中途根据结果调整下一步，而不是一口气生成最终答案。产品上看得到的差别是交互形态：传统大模型一次回复，智能体是一轮轮「想一步、做一步、看结果、再想」。用户看到的往往是一个过程面板，而不是一段成品文字。
代价要提前说清：每一轮都是一次调用，token 消耗和响应时间通常成倍增加，链路变长，出错点也变多，用户在界面上会直接感知到「慢」。规划环节还有个隐性风险，模型拆出来的步骤未必是你想要的顺序，中途跑偏了得靠产品设计去纠。
| 维度 | 传统大模型 | 带规划的智能体 |
|---|---|---|
| 交互形态 | 一次问答出结果 | 多轮想—做—看循环 |
| 任务拆解 | 人来拆，写进提示词 | 模型自己拆，可能跑偏 |
| 延迟与成本 | 一次调用，可预期 | 随轮数上涨，波动大 |
| 适用任务 | 步骤固定、能提前写死 | 步骤无法穷举、需随机应变 |
不适用的情况要说在前面：任务步骤固定、两三步就能穷举的，用写死的流程编排比让模型自己规划更稳、更便宜。客服常见问题、格式化抽取、文案改写这类，单轮调用就够，硬上规划只会让链路变脆。
多出来的第二块：工具调用与记忆
工具调用是智能体能接外部系统的关键：把查数据库、调接口、读文件、下单这类动作包装成可被调用的能力，由模型决定调哪个、传什么参数。没有工具调用，智能体再会规划也只是在说，不是在做事。
工具描述写得好不好直接决定成败。名字含糊、参数说明不清，模型就会乱调或漏调。这是落地时最常见的故障点，先别急着怪模型不行，回头看看工具文档是不是写给人看的糊弄话。给每个工具写清「什么时候用、参数什么含义、失败返回什么」，比换模型有效得多。
- 读操作先行：先接查询类工具，跑稳了再接写操作，别一上来就让模型能改数据
- 写操作加闸：权限边界、二次确认、操作日志三件套，缺一件都别上线
- 单次任务内记忆：把做过什么、拿到什么结果记在上下文里，不然模型会重复调同一个工具
- 跨会话记忆：用户偏好和历史要产品自己设计存储与读取策略，别指望模型自己记住
- 失败可回退：每个工具调用都要有超时和降级，规划链一断，用户得看到明确的下一步
产品落地前的对照清单
把下面几个问题过一遍，基本就能判断这个需求该不该上智能体。答「否」越多的，越应该退回单轮调用或固定流程。清单不是绝对标准，团队工程能力和风险承受度不同，结论也会不同，但这些问题是绕不开的。
- 问任务是否天然多步步骤能不能提前穷举？能穷举就用固定流程编排，不要交给模型自由规划；只有步骤随输入变化、必须边做边定的，才考虑规划能力
- 问是否缺数据或缺动作只是缺知识，优先考虑检索增强，不必上智能体；需要执行真实动作的，才需要工具调用，同时把权限和日志一起设计
- 问延迟和成本能忍吗多轮循环会让响应变慢、单次消耗上升。先定一个用户能接受的上限，再决定链路最多允许几轮调用，超了就降级成单轮
- 问谁来兜底团队里有没有人负责工具接口维护和日志排查？没人兜底，工具一报错产品就变黑盒，用户看到的是转圈，你看到的是无解
- 量一遍基线再拍板上线前先用站内测速工具量接口延迟，把每轮调用的耗时加总，再对照上面的上限做决定，别拍脑袋估
最后补一句核对方法：模型侧的能力和价格随时在变，具体数字不要凭记忆，到 模型资料库（/models） 和 价格追踪（/price-watch） 看当时的记录；接口延迟到 测速工具（/tools/speed-test） 实测。判断标准比具体数字更耐用。
智能体不是更聪明的模型，是给模型加了一圈会犯错、也需要你兜底的壳。下一步拿你手上正在评审的那个需求，逐条过上面的清单，把「缺数据」和「缺动作」分开写；再去模型资料库确认选型，去测速工具量一遍链路延迟，带着数字回评审会。→
常见问题
智能体是不是就是大模型加个插件？
不完全是。插件或工具只是其中一块，智能体还需要规划能力（把任务拆步骤、按结果决定下一步）、上下文管理（记住中间状态），以及一个能反复执行的循环机制。少了规划和循环，本质上仍是单次调用，只是顺带能查点东西。
什么任务看起来适合智能体，其实不该上？
步骤固定、可以提前写成流程图的任务，比如固定的审批流转、固定字段的表单抽取、固定的数据格式转换。这类任务用规则或固定编排更便宜也更可控；让模型自由规划只会引入不确定性和额外成本。判断标准是：任务的下一步是否高度依赖上一步的返回内容。
上了智能体之后效果不稳定，先从哪查？
按链路从后往前查：先看工具描述和参数定义是否清楚，这是最常见的乱调原因；再看中间结果有没有被正确带进下一轮上下文；然后看是否给了模型明确的终止条件，很多「跑不完」是缺少停止信号；最后才考虑换模型或调提示词。
