专栏：大模型应用开发：从原理到生产
篇号：01
内容标签：人工智能、AIGC、语言模型、RAG、AI Agent、大模型
很多人第一次做大模型应用，都会觉得这件事很简单。
注册一个模型平台，拿到 API Key，安装 SDK，写几行代码，把用户问题塞进 messages，再把模型返回的文本显示到页面上。
一个最小 Demo 就跑起来了。
如果只是演示，这确实够了。你可以做一个聊天框，可以做一个文案助手，可以做一个“看起来很聪明”的企业知识库问答机器人。老板一看，觉得 AI 已经能用了；团队一看，觉得这个项目应该很快能上线。
但真正接入业务之后，问题会马上冒出来。
用户问的是公司最新制度，模型却回答了一个过期版本。
知识库里明明有资料，模型却没有引用到关键段落。
客服机器人回答得很流畅，但说错了赔付规则。
Agent 接上数据库和文件系统后，开始遇到权限、状态、循环调用、超时和审计问题。
微调实验在样例上表现很好，一到真实用户问题就不稳定。
成本看起来每次调用不贵，流量上来以后账单突然变得很刺眼。
这就是大模型应用开发最容易被低估的地方。
核心判断：调 API 只是把模型接进系统，不等于完成大模型应用开发。
真正的大模型应用开发，解决的不是“怎么让模型回复一句话”，而是：
如何把大模型能力，变成稳定、可控、可持续迭代的生产系统。
这篇文章是整个专栏的第一篇。我们先不急着写代码，而是先建立一张完整的技术地图。地图有了，后面的 Prompt、RAG、微调、Agent、MCP、Memory、评估和生产治理，才不会变成一堆孤立名词。
一、为什么“会调 API”还远远不够
调用模型 API，只解决了一个最基础的问题：你的系统可以和大模型说话了。
但业务系统真正需要的，远不止“会说话”。
一个能上线的大模型应用，至少还要回答这些问题：
- 模型应该看到哪些业务资料？
- 用户身份不同，能看到的资料是否不同？
- 模型不知道答案时，能不能承认不知道？
- 输出是否需要引用来源？
- 答案错了以后，怎么追溯是哪一步出了问题？
- 什么动作可以自动执行，什么动作必须人工确认？
- 一次任务失败后，是重试、降级，还是转人工？
- 每天的调用成本、成功率、延迟和用户满意度怎么观测？
这些问题，API 本身不会替你解决。
比如你要做一个企业知识库问答系统。最简单的版本是：用户提问，模型回答。这个版本很快能演示，但它通常经不起真实使用。
真实系统里，文档有权限，资料会更新，文件格式不统一，长文档需要分块，检索结果需要排序，答案要带引用，敏感问题要拒答，错误答案要能回放，用户反馈要进入评估集。
这时你会发现，大模型项目不是一个“聊天功能”，而是一套围绕模型构建的信息系统。
换句话说，大模型只是核心引擎，不是完整应用。
二、大模型应用开发有六层
为了不被工具名带乱，我们可以把大模型应用开发拆成六层。
第一层是底层原理：Transformer、Token、Embedding、推理流程、上下文窗口、幻觉。
这一层解决的问题是：模型到底在做什么，它为什么能生成答案，又为什么会一本正经地说错。
第二层是交互控制：Prompt Engineering、System Prompt、结构化输出、Context Engineering。
这一层解决的问题是：你怎样组织输入，才能让模型更稳定地按你的目标工作。
第三层是知识增强：RAG、文档解析、分块、向量检索、重排、引用、检索评估。
这一层解决的问题是：模型训练时不知道的知识，怎么在回答时补给它。
第四层是模型定制：微调、LoRA、QLoRA、SFT、DPO、对齐。
这一层解决的问题是：通用模型不适合你的领域、格式或行为习惯时，怎么让它变得更像一个专用模型。
第五层是行动系统：Function Calling、Workflow、Agent、MCP、Memory、多智能体。
这一层解决的问题是：模型如何不只是回答问题，而是能调用工具、管理状态、规划步骤、执行任务。
第六层是生产治理：评估、权限、观测、成本、审计、人工确认、ROI。
这一层解决的问题是：系统能不能上线，能不能稳定运行，能不能被团队持续改进，最终能不能产生业务价值。
很多项目卡住，不是因为某个框架没选对，而是因为把不同层的问题混在一起了。
知识缺失的问题，用 Prompt 硬编。
流程控制的问题，让模型自由发挥。
权限治理的问题，交给一句 System Prompt。
评估缺失的问题，靠“我感觉回答不错”判断。
这类项目在 Demo 阶段看起来没问题，一进入真实业务就会变形。
三、第一层：先搞懂模型为什么会说，也为什么会编
大语言模型最底层的工作，可以用一句话理解：
根据已有上下文，预测下一个最可能出现的 Token。
你输入“人工智能的核心是”，模型并不是像人一样先查阅一个事实数据库，再给出严谨结论。它是在当前上下文里计算后续 Token 的概率，然后一个 Token 一个 Token 地生成下去。
这件事非常重要。
因为它解释了大模型的两个特征。
第一个特征是强生成能力。模型在海量文本上训练过，为了预测下一个 Token，它被迫学会了语言结构、知识关联、代码模式、推理形式和常见任务的表达方式。所以它能写文章、写代码、做总结、改简历、解释概念。
第二个特征是幻觉。模型追求的是“在语言上最合理的输出”，不是“在事实上一定正确的输出”。当上下文里没有足够事实，或者检索资料不可靠，模型仍然可能生成一段听起来很顺的回答。
这不是某个模型的偶然缺陷，而是概率生成机制带来的天然风险。
所以做大模型应用时，不能只问“模型强不强”。你还要问：
- 模型当前看到了什么？
- 这些信息是否足够回答问题？
- 输出是否需要事实校验？
- 是否应该要求模型引用来源？
- 哪些问题必须走检索、工具或人工确认？
理解这一层，你就不会把所有问题都归因于“模型不够聪明”。
很多时候，问题不在模型，而在上下文、知识库、检索链路、权限设计和评估体系。
四、第二层：Prompt 不是咒语，Context 才是工作现场
很多人学习大模型开发，是从 Prompt 开始的。
这没有问题。Prompt 是你和模型协作的第一层接口。
但 Prompt Engineering 不应该被理解成“写几句神奇咒语”。它真正做的是输入工程：把任务目标、背景信息、角色边界、输出格式、示例和约束组织清楚。
同样一个问题：
“帮我总结这份合同。”
和下面这个输入，效果完全不同：
“你是公司法务助理。请基于以下合同文本，从付款条款、违约责任、交付时间、自动续约、数据安全五个角度提取风险点。每个风险点给出原文依据、风险等级和修改建议。不要补充合同中没有出现的信息。”
后者不是更“礼貌”，而是信息结构更清楚。
不过，仅仅写好 Prompt 还不够。真正进入工程场景后，更重要的是 Context Engineering，也就是上下文工程。
Context 不只是用户最后输入的那句话。它包括：
- System Prompt
- 用户问题
- 对话历史
- 用户身份和权限
- 检索出来的文档片段
- 工具调用结果
- 已保存的长期记忆
- 当前任务状态
- 输出格式约束
模型只能基于它看到的上下文工作。上下文组织得混乱，模型就会在混乱里生成；上下文缺少关键事实，模型就会在缺口处编造。
所以从工程角度看，Prompt 是入口，Context 才是模型真正工作的现场。
五、第三层：补知识、补能力、控行为
当 Prompt 和 Context 解决不了问题时，你就要进入能力增强层。
这一层最重要的三类手段是：RAG、微调和对齐。
RAG 解决的是“补知识”。
模型训练完成后，不会自动知道你的公司制度、内部文档、产品手册、数据库记录和最新业务变化。RAG 的做法是，在回答前先从外部知识库检索相关资料，再把资料放进上下文，让模型基于资料回答。
如果你的问题是“模型不知道业务知识”，优先考虑 RAG，而不是微调。
微调解决的是“补能力”。
比如你希望模型稳定输出某种行业格式，学会某类客服话术，适应某种标注任务，或者形成特定领域的回答风格。此时你不是只给模型临时资料，而是用训练数据继续调整模型，让它形成更稳定的任务习惯。
对齐解决的是“控行为”。
你希望模型更安全、更有帮助、更符合人类偏好，知道哪些话不能说，哪些请求要拒绝，哪些场景要谨慎。这类问题就进入对齐范畴。
这里有一个很实用的判断顺序：
先改输入，再补知识，再考虑改模型。
也就是说，能用 Prompt 和 Context 解决的，不急着上 RAG；能用 RAG 解决的，不急着微调；只有当你确实需要模型形成稳定的新能力、新风格或新行为模式时，再进入微调和对齐。
这能帮你少走很多弯路。
六、第四层：让模型从“回答问题”走向“完成任务”
前面几层解决的是“模型如何更好地回答”。
但很多真实业务并不只是要一个答案，而是要完成一个任务。
比如：
“帮我整理过去 7 天的销售线索，找出高意向客户，生成跟进计划，并把结果同步到 CRM。”
这个需求不是一次文本生成能完成的。它至少包含几步：
这时就需要 Function Calling、Workflow 和 Agent。
Function Calling 让模型可以以结构化方式调用外部工具。比如查数据库、发邮件、查天气、生成报表、调用业务 API。
Workflow 是预先设计好的流程。步骤相对固定，适合稳定业务。比如合同审核、客服工单分类、发票识别、日报生成。
Agent 则更进一步。它不是只执行固定步骤，而是围绕目标进行规划，根据中间结果选择工具，必要时反思和重试。
一个可用的 Agent，通常不只是“LLM + 工具”。它还需要目标、状态、记忆、工具权限、错误处理和停止条件。
这也是很多 Agent Demo 好看、生产系统难做的原因。
Demo 里，Agent 只要跑通一次就行。生产里，你要关心它每一次为什么这么做、失败后怎么办、调用了什么数据、是否越权、成本是否可控、日志是否可追踪。
七、第五层：生产系统关心的不是“聪明”，而是可控
到了生产环境，大模型系统的评价标准会发生变化。
你不能只问“它回答得像不像人”。你要问：
- 准确率是否能被评估？
- 错误是否能被复现？
- 用户反馈是否能沉淀成评估集？
- 敏感数据是否被正确隔离？
- 工具调用是否有权限边界？
- 关键动作是否有人类确认？
- 延迟和成本是否在业务可接受范围内？
- 系统是否有日志、追踪和告警？
这就是从 Demo 到生产的鸿沟。
在这个专栏里，我会把这类能力统一放在生产治理里讲。你也可以把它理解成给大模型系统装上仪表盘、刹车和护栏。
没有这些东西，大模型应用就像一个很会说话、但没人能管理的实习生。它可能很有潜力，但不能直接放到核心业务流程里裸奔。
一个成熟的大模型应用，应该能被评估、被追踪、被回放、被限制权限、被人工接管、被持续改进。
这才是“可交付”的含义。
八、一张完整技术地图
把前面的内容合在一起，大模型应用开发的技术地图大致是这样：
底层原理
Transformer / Token / Embedding / 推理流程 / 幻觉
↓
交互控制
Prompt Engineering / System Prompt / Context Engineering / 结构化输出
↓
知识增强
RAG / 文档解析 / 分块 / 向量检索 / Rerank / 引用 / 评估
↓
模型定制
SFT / LoRA / QLoRA / 对齐 / 领域数据集
↓
智能体架构
Function Calling / Workflow / Agent / MCP / Memory / 多智能体
↓
生产治理
评估 / 权限 / 观测 / 成本 / 审计 / 人工确认 / ROI
以后你看到任何一个新工具、新框架、新概念，都可以先问一句：
它处在哪一层？它解决的是哪类问题？
LangChain、LangGraph、Dify、n8n、Coze、LlamaIndex、CrewAI、AutoGen、MCP、向量数据库、Rerank 模型、Embedding 模型，它们看起来很多，但都能放回这张地图里。
工具会变，框架会变，模型名也会变。
但这张地图背后的分层逻辑，会长期存在。
九、一个实际选型例子
假设你的公司要做一个内部知识库助手。
用户希望它能回答制度、流程、产品、客户案例和项目文档相关问题。
你应该怎么判断技术路线？
如果问题是“模型回答格式不稳定”，优先从 Prompt 和结构化输出入手。
如果问题是“模型不知道公司内部资料”，优先做 RAG，把文档解析、分块、检索、重排和引用链路打好。
如果问题是“模型总是用不像公司客服的口吻回答”，可以先用 Few-shot 示例和 System Prompt 调整；如果仍然不稳定，再考虑微调。
如果问题是“用户想让助手查订单、改状态、生成工单”，就要引入 Function Calling 或工作流。
如果问题是“用户给一个目标，让系统自己拆任务、查资料、调用多个工具、反复修正”，才进入 Agent 架构。
如果问题是“系统要上线给全公司使用”，就必须补上权限、评估、日志、成本控制、人工确认和异常处理。
你会发现，技术选型不是看哪个词更热门，而是看问题卡在哪一层。
这是这套专栏最想训练你的能力：不是追名词，而是做判断。
十、这个专栏会怎么展开
接下来，这个专栏会按从原理到生产的路线展开。
第一单元先建立全局认知，讲清 AI、机器学习、深度学习、大语言模型和 Agent 的关系，也会把 Token、Embedding、上下文窗口和幻觉这些基础概念讲透。
第二单元进入底层原理，重点讲 Transformer、Attention、推理流程、KV Cache、MoE 等内容。目标不是推公式，而是让你形成工程直觉。
第三单元讲 Prompt 和 Context。你会看到，提示词不是玄学，真正关键的是如何管理模型看到的一切。
第四单元深入 RAG。我们会从最小可用系统开始，拆到文档解析、分块、向量检索、重排、引用、评估和 Agentic RAG。这会是整个专栏非常重要的一部分。
第五单元讲微调与对齐。什么时候该微调，数据集怎么做，LoRA 和 QLoRA 解决什么问题，SFT、RLHF、DPO 到底在对齐什么，都会逐步展开。
第六单元进入 Agent 和生产落地。包括 Function Calling、MCP、Memory、多智能体、框架选型、Harness Engineering，以及企业 AI 项目如何从 Demo 走向可运营系统。
如果你已经做过一些 AI Demo，这套专栏会帮你把零散经验整理成体系。
如果你刚开始进入大模型应用开发，它会帮你少被术语带跑，先建立正确的坐标系。
结尾：先把地图装进脑子
大模型应用开发不是一个 API 技巧，也不是某个框架教程。
它是一套系统能力。
你要理解模型为什么能工作，也要知道它为什么会犯错；你要会写 Prompt，也要会管理上下文；你要会接知识库，也要知道什么时候该微调；你要能做 Agent，也要能把权限、评估、观测和成本控制补齐。
只有这样，一个 AI Demo 才有机会变成真正可用的生产系统。
下一篇，我们继续往前走，讲清楚一条最重要的演进线索：
从 AI 到 Agent，大模型技术栈到底是怎么一步步走到今天的。
