企业官网建设流程全解析

《大模型实战》第 2/10 篇
上篇：选型一张图
下篇预告：RAG 还值不值得做？

很多人把「会写 Prompt」当成会做大模型应用。2026 年真正能交付的系统，通常要分清四层：

Prompt → RAG → Tool Calling → Agent

本篇给你一张分层图，以及每层该上、不该上的判断标准。

你将学到

• 四层分别解决什么问题
• 「会聊天」和「能交付」怎么区分
• 每层常见技术栈与踩坑
• 什么时候停在某一层就够了

一张分层总表

一句话：

• L1 解决「说清楚」
• L2 解决「知道得更多」
• L3 解决「能动手」
• L4 解决「能连续把事做完」

L1：Prompt Engineering——何时够用，何时不够

够用的场景

• 改写、摘要、翻译、分类
• 结构化抽取（JSON 字段少且稳定）
• 单轮问答，不依赖最新私有数据

不够用的信号

1. 答案依赖你们内部文档 / 数据库
2. 需要查天气、下单、改代码、发通知
3. 任务要多步，中途可能失败重试

此时继续堆 Prompt，通常是在用自然语言硬扛系统能力缺口。

最小实践

角色 + 任务 + 约束 + 输出格式 + 示例

先把输出格式钉死（JSON Schema / 字段表），再谈「更聪明的措辞」。

L2：RAG——给模型外挂知识，而不是硬背进 Prompt

解决什么

模型训练截止后不知道的内容：产品文档、制度、工单、代码注释、FAQ。

不该用 RAG 硬上的情况

• 知识其实很小，直接放进上下文更稳
• 需要精确计算 / 强事务（该查库或跑代码）
• 权限复杂到「检索到了也不能给这人看」却没做过滤

关键认知

RAG 质量差时，换更大模型往往救不了。
分块、召回、重排没做好，旗舰模型也会一本正经胡说。

下篇会专门展开：向量库、分块、重排与评测。

L3：Tool Calling——从「生成文本」到「触发动作」

解决什么

让模型决定调用哪个工具，并带上参数：

{"tool": "search_docs", "args": {"q": "退款规则"}}

系统执行工具后，把结果喂回模型，再生成最终回答。

工程要点（比 Prompt 更重要）

1. Schema 少而精：工具太多，模型更容易选错
2. 权限白名单：默认只读，写操作要确认
3. 超时 / 重试 / 幂等：网络抖动是常态
4. 可观测：每次工具调用都要有日志与 trace

和前端的关系：Tool 进度、错误、确认框，是产品体验的一部分，不是后端私货。可对照前端系列第 4 篇（Tool Calling UI）。

L4：Agent——多步规划、记忆与失败恢复

Agent 不是「更长的 Prompt」

Agent 至少要有：

• 目标分解（plan）
• 工具循环（act）
• 状态与记忆（state / memory）
• 停止条件与人工介入（stop / HITL）

什么时候上 Agent

• 任务天然多步：调研→对比→起草→校验
• 需要根据中间结果改路线
• 允许一定自主性，且有沙箱与审计

什么时候不要上

• 单次工具调用就能结束
• 流程固定，用普通工作流 / 状态机更清晰
• 团队还没有权限、日志、回滚能力

没有治理的 Agent，是高速制造事故的机器。

「会聊天」vs「能交付」判断清单

如果你的系统只能回答、不能安全行动、不能复盘，它还停在 L1～L2 的 Demo 阶段。

推荐演进路径（别一步登天）

1. 先做 L1：稳定输出格式
2. 需要私有知识再上 L2
3. 需要查/写系统再上 L3
4. 多步且多分支再上 L4

每一层都先有评测和失败路径，再加深自主性。

和本系列后续篇的对应

小结

2026 年做 LLM 应用，建议把能力拆开看：

1. Prompt 解决表达
2. RAG 解决知识
3. Tool 解决行动
4. Agent 解决连续交付

选层比选模型更先。模型可以换，分层错了会一直痛。

下篇预告：《大模型实战》第 3/10 篇
RAG 还值不值得做？向量库、分块、重排与评测一次讲透。