很多人做 AI 应用会卡在一个说不清的阶段：提示词改了几十版效果还是飘，加了知识库又不知道算不算智能体，看到别人上 Agent 又怕自己用不上。这篇不讲概念史，而是给一条可以自查的演进路径：你现在在哪一级、卡点是什么、下一级需要具备什么条件、什么时候不该往上走。每一级都配可执行动作和停止信号。
做 AI 应用最容易卡在一种说不清的状态：提示词改了十几版，效果还是看运气；后来加了知识库，又不确定自己算不算在做智能体；看别人晒 Agent 演示，心里发虚，怕自己落后，又怕硬上白烧钱。这篇不聊概念发展史，只给一条能自查的路径：你现在大概在哪一级、这一级的典型卡点是什么、往下一级要补什么条件、以及什么情况下根本不该往上走。
先把预期放正：这四级的划分不是学历，不是越高越体面。级别升高，通常意味着任务本身的「不稳定程度」在升高——输出更依赖外部事实、要做多步决策、错了还不好人工兜底。如果你的任务三项都不沾，老老实实停在提示层是最省钱也最稳的选择。下面逐级拆，每级都配可执行动作和停止信号。
把大模型应用分成四级：先看清自己在哪一级
四级是：单轮提示 → 结构化提示与模板 → 检索增强（RAG）→ 工具调用与智能体。注意它是按「任务不稳定程度」递增的，不是按技术水平排的高低。看清自己在哪级，主要靠三个自查问题：输出需不需要外部事实、需不需要多步决策、失败能不能人工兜底。三项都答「否」的，就别急着往上跳。
| 级别 | 典型形态 | 判断通过的信号 | 常见卡点 |
|---|---|---|---|
| 单轮提示 | 一次性问答、改写、润色 | 同一批样本返工率稳定可接受 | 措辞调到头还是飘 |
| 结构化提示 | 模板、固定字段、格式约束 | 字段缺失和格式错能自动检出 | 模板一多就没人维护 |
| 检索增强 | 先查资料再生成，带引用 | 答案能溯源到原文片段 | 召回为空时回答乱来 |
| 工具调用与智能体 | 模型自己决定调哪个接口 | 失败有重试和人工确认点 | 权限没边界，出错难回滚 |
- 先用自己的历史任务做一份样本集，别用公开榜单的题目，榜单只作参考，去 /benchmarks 看当时题目的构成和口径
- 给每一级定可量化验收口径：准确率、返工率、人工介入次数，口径必须来自你自己的数据
- 记录「当前级答不好的那批任务」，这批任务就是升级的动机，没有这批任务就别升级
- 每升一级前，问一遍：这级的失败代价我兜得住吗，兜不住就退回上一级
从提示工程升到 RAG 的信号与做法
什么时候该从提示层升到 RAG？出现这三类症状就说明提示层基本到顶了：一是问题涉及的知识超出模型原有范围；二是答案要求能指到出处；三是同一个问题每次回答风格和口径不一致。这几种情况下，继续抠措辞的收益，远不如补一层检索来得直接。
- 先定切分与召回口径确定文档怎么切、按什么召回、召回几条。先用几十条真实问题跑一遍，看召回的片段里到底有没有答案，没有就先别调生成。
- 再挑嵌入与重排嵌入模型怎么选、当期各家的表现怎么对比，去 /embeddings 页面看当时的对照数据，别凭印象挑。
- 最后回头调提示检索稳了再改提示词，让它基于片段作答、给出引用；这一步之前调提示基本是白调。
- 补兜底策略召回为空时怎么回答、引用和原文对不上时怎么拦截，这两条必须在上线前写好。
不适用的场景也得说清：纯创意写作、风格模仿、头脑风暴这类任务，本来就不要求事实准确，加检索反而把模型框死，输出变得干巴。这类任务留在提示层更合适。
工具调用：从「会说」到「会做」的分界线
工具调用解决的是一个很具体的矛盾：模型不能直接改外部状态。查库存、下单、发消息、跑代码，都属于「要动外部世界」这一类。只要任务开始要求模型真的去操作东西，光靠提示就没用了，必须给它接口。可调用的接口类型和当期目录，可以去 /stacks/agent-apis 页面核对。
- 上工具前先写权限表：每个工具能读什么、能写什么、失败重试几次、人工确认放在哪一步
- 写操作和读操作分开授权，能只读就别给写权限，能二次确认就别自动执行
- 给每次工具调用留日志，能看出是模型判断错还是接口返回错
- 准备回滚或补偿方案，写错了怎么撤回，写之前就要想好
不适用的情况同样明确：任务本身只是单轮问答、外部系统没有稳定接口、或者错误写入的代价没法回滚。这几种情况下，让人复制粘贴的半自动流程反而更划算，别为了「像智能体」硬上。没有权限边界的工具调用，风险远大于收益。
什么样的任务才配得上智能体
智能体适合「步骤数不固定、每步要看上一步结果」的任务。反过来，步骤固定且能枚举的流程，用工作流编排更省事也更便宜——固定流程交给固定代码，别交给模型的临场判断。判断方法很朴素：把任务画成流程图，如果每个分支你都能提前写出来，那就不是智能体的活。
| 维度 | 适合智能体 | 更适合工作流 |
|---|---|---|
| 步骤数 | 不固定，看中间结果决定 | 固定可枚举 |
| 依赖关系 | 每步依赖上一步输出 | 步骤之间弱依赖 |
| 失败处理 | 能重试、有人工确认点 | 错误可直接丢弃重来 |
| 成本可控性 | 需要设上限和降级路径 | 预算容易预估 |
上之前先跑离线回放：把历史任务重放一遍，统计步数、工具调用次数和失败点都卡在哪。跑不通通常说明缺的是数据或接口，不是模型能力，这时候换更强的模型也救不了。上线后延迟基线可以用 /tools/speed-test 自己量，质量波动按 /tools/quality-monitor 这类口径持续观察，别只看一次演示的效果。
跨级迁移的检查清单与什么时候别升级
升级前做四项确认：任务边界是否清楚、验收样本是否足够、失败兜底是否存在、成本和延迟上限是否被接受。缺任何一项，先别动。迁移顺序建议：先在旁路跑新链路，和旧链路对照着看差异，确认稳定再切流量，并且始终保留回退开关。模型换代时可以对照 /models 的当期规格页，先对齐能力边界再动手。
- 旁路对照：新旧链路同时跑同一批任务，差异能解释清楚再切
- 灰度切流：先放一小部分真实流量，观察失败率再逐步放大
- 回退开关：随时能切回上一级，回退过程要演练过一次
- 数据量小到检索没意义时，别上 RAG，直接维护一份人工答案表更快
- 流程已经稳定到用固定脚本更快时，别上智能体，脚本更便宜也更好查
- 团队没人能维护工具权限和日志时，先补人再升级，否则上线就是埋雷
还有一种情形要忍住：只是看到别人在做 Agent 就跟着上。没有那批「当前级答不好」的真实任务，没有能维护权限的人，升级只会拖长交付周期。停下来不是保守，是把钱和人花在能验证收益的地方。
判断该不该升级，看的不是模型多强，而是你的任务有多不稳定、失败代价你兜不兜得住。下一步想先摸清自己现在卡在哪一级，可以从模型与工具目录对起，再对照当期价格和速度基线做一次自查。→
常见问题
提示工程是不是已经过时了，现在都该做智能体？
没过时，只是它的适用边界变清楚了。任务只要不依赖外部实时事实、也不需要多步操作外部系统，把提示写清楚就是成本最低的方案。上智能体意味着多出工具权限、回放测试、监控和失败兜底这几笔开销，任务复杂度不够时纯属负担。先用小样本验证提示层能不能到你要的成功率，到不了再谈升级。
RAG 和智能体是替代关系吗，能不能只选一个？
不是替代关系，是叠加关系。RAG 解决「模型不知道的事实从哪来」，智能体解决「知道之后怎么一步步去做」。只做 RAG 也能支撑问答类应用；只有需要多步决策并改动外部状态时，才在 RAG 之上加工具调用与循环控制。反过来，没有可靠检索的智能体容易在第一步就编事实，后面全错。
怎么判断我的任务该停在提示层还是继续往上走？
用三个问题筛：答案是否必须引用模型训练数据之外的东西、完成一次任务是否需要中途看结果再决定下一步、出错后能否靠人工低成本纠正。三个都是否，停在提示层；只有第一条是是，加 RAG；第二条也是是，才考虑工具调用与智能体。判断时配合自己的历史任务样本统计，不要拿通用榜单结论直接套。
