最近，AI投资圈又出现一条吸引眼球的消息：腾讯又投了一家AI独角兽，估值897亿。这类投融资新闻放在新闻客户端里是资本话题，放在开发者社区里，真正值得追问的是另一个问题：一家公司被冠上“AI独角兽”标签之后，它的工程团队靠什么把大模型能力变成一天24小时稳定运行的业务系统。
答案不是发布会上的演示视频，而是一条完整的技术链路。一个能用的AI应用，通常要从模型选型和部署开始，经过API调用、Agent编排、幻觉治理、性能优化、成本控制，最后接入日志监控和合规约束。任何一个环节没打通，产品就会停在demo阶段。下面会从零演示如何把一个大模型跑起来，完成第一次调用，实现一个会用工具的Agent，加入RAG检索降低幻觉，然后讨论生产环境必须关注的指标和排查方法。
适合阅读这篇博客的开发者，包括正在做AI应用开发、准备把大模型接入公司业务，以及刚接触AI工程化但不想只停在“跑通一个demo”阶段的同学。读完后，你会对AI应用从模型到产品的完整路径有一个可操作的认知。
1. AI独角兽的估值故事，技术侧应该关注什么
1.1 模型能力不等于产品能力
普通用户看到的“AI独角兽”，是模型能写文案、能画图、能回答复杂问题。但工程团队看到的是完全不同的对象：每天几万次请求里，有多少次返回超时，有多少次模型编造了不存在的合同条款，工具调用失败后用户看到的提示是什么，突发流量下GPU资源够不够，账单里的Token消耗是否正常。
模型能力解决的是“能不能生成合理内容”的问题。产品能力解决的是“在一套业务规则下，能不能稳定、安全、可预期地提供内容”的问题。后者需要工程化手段。一个很好的方法，是把AI产品拆成几条线：模型能力线、应用代码线、数据线、运维线。模型再强，应用代码线没有处理异常分支，数据线没有做好检索和更新，运维线没有监控，产品依然不可用。
实际项目中的表现往往是这样：demo在本地显卡上跑得很流畅，部署到服务器后首Token延迟超过3秒；测试时模型回答正确，上线后同一个问题换了表述，答案完全不同。这些都不是模型“变笨了”，而是工程链路没有跟上。
1.2 一条可复用的大模型应用技术栈
结合大多数AI应用项目的落地形态，可以梳理出这样一条技术栈分层：
应用层：业务系统、小程序、Web、客服、内容生成工具 编排层：Agent框架、RAG检索、提示词管理、多轮会话状态 推理层：OpenAI兼容API、本地推理服务、量化部署、流式输出 模型层：开源模型权重、托管大模型服务 平台层：日志追踪、监控告警、评测回归、限流、安全过滤每一层都有独立的关注点。模型层决定能力上限，推理层决定速度和成本，编排层决定模型能不能结合业务数据执行真实任务，应用层决定用户体验，平台层决定系统能不能长期稳定运行。
这套技术栈和普通Web后端有明显的差异。普通后端的大部分逻辑是确定性代码，而AI应用的输出不确定，所以平台层的评测和监控更加关键。没有评测，你就无法判断一次系统变更到底是变好了还是变坏了；没有追踪，用户报告一个错误回答时，你不知道是提示词问题、检索问题还是模型本身问题。
1.3 一条能落地的工程主线
接下来的章节会沿一条最小可复现的路径推进：
- 先搭建一个可用的模型服务，可以是本地推理服务，也可以是兼容接口的云端API。
- 完成第一次对话调用，理解请求参数和返回结构。
- 加入工具调用，让模型具备使用外部函数的能力。
- 引入RAG检索，让回答基于真实资料而不是模型记忆。
- 最后讨论把Demo推向生产时的指标、成本和排查手段。
这条主线不需要你提前具备很深的机器学习理论基础，但需要你熟悉Python、命令行，并且知道怎么安装依赖。每完成一步，都可以用一段代码和一次运行结果验证。
2. 先把大模型跑起来：选型、部署与最小调用
2.1 三种部署形态：云端API、私有化部署和混合架构
不管项目来自融资新闻里的高估值公司，还是一个刚启动的小团队，所有AI应用都逃不开一个问题：模型跑在哪里。三种常见形态如下表：
| 形态 | 适用场景 | 优点 | 代价 |
|---|---|---|---|
| 云端托管API | 快速验证、原型开发、非敏感业务 | 接入简单，不需要GPU，按量付费 | 数据会交给服务方，长期使用成本随调用量增长 |
| 私有化部署 | 数据敏感、需要离线可用、深度定制 | 数据不出内网，可以针对业务做微调和量化 | 需要GPU资源、推理框架和运维能力 |
| 混合架构 | 敏感业务和通用业务共存 | 敏感数据走本地，通用任务走API，灵活平衡成本 | 链路更复杂，需要统一网关和路由策略 |
选型时不要只看模型榜单，还要考虑三个问题：数据能不能出域，调用量是否有峰值，团队有没有能力维护推理服务。如果只是一天几百次调用，云端API通常更划算；如果是内部知识库，数据安全要求高，私有化部署更合适。混合架构看起来先进，但管理复杂度会成倍增加。
2.2 本地部署开源模型的最小步骤
为了后面演示RAG和工具调用，这里先介绍本地部署方式。它最大的价值是可以反复调试，不需要为每次实验付费。常见做法是使用Ollama这类推理工具，它把模型下载、量化、启动和对外提供服务封装成了几条命令。
前提条件：
- 一台装有Linux或macOS的机器，Windows建议使用WSL2。
- 至少有8GB可用内存，运行7B参数模型时更稳妥。
- 确认Ollama已经安装，具体安装方式以官方文档为准。
安装并启动后，拉取一个中文场景常用的模型：
ollama pull qwen2.5:7b ollama run qwen2.5:7b拉取模型的时间取决于网络环境。如果拉取速度很慢，不要反复中断，先检查磁盘剩余空间和网络连接质量。模型文件通常有几个GB，磁盘不足会直接导致失败。
模型启动后，Ollama会监听本机的11434端口，并提供一个类似大模型服务的HTTP接口。可以用命令行先验证一次：
curl http://localhost:11434/api/generate \ -d '{"model":"qwen2.5:7b","prompt":"用一句话介绍你自己","stream":false}'返回的JSON里会包含模型生成的文本。这一步通过，说明本地推理链路已经打通。这里要注意，Ollama更适合学习和开发调试，生产环境通常在vLLM这类推理框架上部署，目的是获得更稳定的吞吐量和更丰富的监控指标。
2.3 通过兼容接口完成第一次模型调用
很多大模型服务商都提供了OpenAI兼容接口，这意味着你可以用同一套客户端代码，去调用不同厂商的模型。本地部署的Ollama也支持这种方式。
先安装依赖：
pip install openai然后创建一个Python脚本，示例调用如下：
from openai import OpenAI client = OpenAI( api_key="sk-local-noop", # 本地部署时仅用于占位 base_url="http://localhost:11434/v1" ) resp = client.chat.completions.create( model="qwen2.5:7b", messages=[ {"role": "system", "content": "你是一名技术助手，回答要简洁。"}, {"role": "user", "content": "用一句话解释什么是大模型。"} ], temperature=0.3, max_tokens=300, stream=False ) print(resp.choices[0].message.content)运行后，终端会打印模型的回答。这个代码块里有几个点要理解：
base_url指向本地服务。如果你在使用某个云端大模型平台，把它换成平台提供的接口地址。api_key在本地部署时不一定需要真实密钥，但云端调用时必须通过环境变量或密钥管理服务提供，不要硬编码在代码里。messages是对话结构，system用于设定行为边界，user是用户输入。temperature控制随机性，max_tokens限制输出长度。
2.4 模型调用的关键参数与成本观察
同样是“写一段产品文案”，把temperature从0.2调到1.0，结果可能完全不同。下面这张表总结了常见参数：
| 参数 | 含义 | 常见取值范围 | 调大影响 | 调小影响 |
|---|---|---|---|---|
| temperature | 采样随机性 | 0到2 | 输出更发散、更有创造性 | 输出更稳定、更保守 |
| top_p | 核采样概率阈值 | 0到1 | 允许更多候选词参与生成 | 候选词更少，结果更集中 |
| max_tokens | 最大输出Token数 | 视模型而定 | 回答可能更长 | 回答易被截断 |
| stream | 是否流式输出 | true或false | 用户能更快看到首字 | 等待完整结果，感知延迟更高 |
参数没有绝对的对错，关键是和任务匹配。抽取合同编号、提炼结构化信息、生成代码这类任务，推荐低温参数；头脑风暴、广告创意、开放式写作，可以适当调高温度和top_p。
Token用量直接影响成本和响应速度。一个中文汉字通常会被拆成多个Token，输入和输出都会计费。实际项目里第一件事不是看模型回答得好不好，而是先记录一次请求消耗了多少Token，再估算一个月会产生多少费用。
3. 从单次调用到AI Agent：让模型会使用工具
3.1 为什么单次问答不够用
如果你只是用大模型做“一问一答”，很多业务场景是跑不通的。用户问“帮我查一下订单状态”，模型并不知道订单数据存在哪个数据库里；用户问“明天上海适合穿什么”，模型没有实时天气数据。单次问答只能使用模型内部的记忆，而Agent可以通过工具调用读取真实数据、操作系统接口，再把结果回传给模型生成回答。
打个比方：把单次问答理解成一个只会背书的顾问，Agent理解成一个能查资料、能算数、能提交工单的助理。后者的价值在于，大模型不需要“记住”每一个细节，它只需要学会在什么场景下调用哪个工具。
3.2 Agent的五个核心模块
一个最小可用的Agent系统，通常包含五个模块：
- 规划：把复杂任务拆解成步骤。
- 记忆：保存多轮对话上下文和业务知识。
- 工具：对外提供函数、API或数据库查询能力。
- 执行：实际运行工具代码，把结果返回给模型。
- 反思：根据执行结果判断是否还需要下一步操作。
这五个模块并不需要一次性全部实现。从能跑通开始，先实现“工具调用”这一个能力，再逐步加入规划、记忆和反思，是更稳妥的路线。
3.3 最小工具调用示例
工具调用的核心机制是：应用先把工具清单发给模型，模型根据用户问题决定是否调用工具，应用执行工具后把结果追加到对话里，再让模型生成最终回答。
以天气查询场景为例：
from openai import OpenAI client = OpenAI( api_key="sk-local-noop", base_url="http://localhost:11434/v1" ) tools = [ { "type": "function", "function": { "name": "get_weather", "description": "查询指定城市当前的天气情况", "parameters": { "type": "object", "properties": { "city": { "type": "string", "description": "城市名，例如北京、上海" } }, "required": ["city"] } } } ] messages = [ {"role": "user", "content": "北京今天适合穿什么衣服？"} ] resp = client.chat.completions.create( model="qwen2.5:7b", messages=messages, tools=tools, tool_choice="auto" ) assistant_msg = resp.choices[0].message print(assistant_msg.tool_calls)如果模型判断需要查询天气，返回的tool_calls里会包含函数名get_weather和参数{"city": "北京"}。应用拿到这个结构后，执行真实的天气查询代码，再把结果追加到messages中，发起第二轮调用：
messages.append(assistant_msg) messages.append({ "role": "tool", "tool_call_id": assistant_msg.tool_calls[0].id, "content": "北京今天多云，气温12到20摄氏度" }) final = client.chat.completions.create( model="qwen2.5:7b", messages=messages, tools=tools, tool_choice="auto" ) print(final.choices[0].message.content)这一轮模型会基于工具返回结果，生成“建议穿薄外套”之类的回答。工具调用已经成为应用层能力和模型之间的桥梁。
3.4 工具调用失败时的回退策略
工具调用看起来简单，实际项目中会暴露很多边界问题。下表列出了常见异常：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
模型返回的tool_calls为空 | 工具描述不清或模型判定无需工具 | 检查工具名称和描述，必要时强制tool_choice指定工具 |
| 工具参数解析失败 | JSON格式不符合预期 | 增加参数校验，把解析错误返回给模型重新生成 |
| 工具执行异常 | 数据库无响应、第三方接口超时 | 捕获异常，把错误信息作为工具结果回传 |
| 模型循环调用同一工具 | 没有设置最大步数 | 限制Agent最多执行N轮，超出后返回兜底回答 |
这里的关键是：工具调用不是“模型输出正确代码”就结束了，而是要把错误信息也当作一种数据，回传给模型，让它有机会修正。不要把异常直接丢给用户。
4. 缓解AI幻觉：提示词、上下文和RAG要一起上
4.1 AI幻觉的表现与产生原因
AI幻觉是指模型生成了看起来合理、但实际没有事实依据的内容。它可能表现为：编造不存在的公司名称、引用错误的法条、给出未经验证的医学建议。
产生幻觉的原因大致有三类：
- 模型训练数据存在截止时间，无法覆盖最新信息。
- 模型本身是概率生成器，它不知道什么是“事实”，只知道什么词更容易出现在一起。
- 用户问题超出了模型知识边界，模型为了给出完整回答而强行补全。
理解这一点很重要。缓解幻觉不是靠一个参数，而是要在提示词、上下文、检索和评测四个方面同时加约束。
4.2 提示词模板设计与参数约束
提示词模板是成本最低、见效最快的手段。把“回答限制在给定资料内”写清楚，能明显减少编造。下面是一个客服场景的模板：
你是一名电商客服助手。 回答问题前，请优先参考如下资料： {context} 用户问题： {question} 要求： 1. 只依据资料作答，资料中没有的信息，直接回答“资料中未提及”。 2. 不要补充资料之外的猜测性内容。 3. 回答控制在200字以内。 4. 如果资料中有多个观点，请分别说明。模板里使用{context}和{question}占位符，在代码里用真实数据替换。注意，模板本身不能保证不产生幻觉，但它能给模型一个明确的行为边界。配合低温参数，输出会更稳定。
4.3 用RAG让模型基于真实资料回答
RAG（检索增强生成）是目前生产环境中使用最广泛的幻觉治理方案。它的思想很简单：模型需要回答问题时，先从知识库里检索相关内容，把检索结果拼进提示词，再让模型基于这些内容生成回答。
一个最小实现包含四步：切分文档、向量化、检索、生成。向量化部分常用Embedding模型把文本转成向量，然后通过相似度计算找最相关的片段：
from sentence_transformers import SentenceTransformer import numpy as np embedder = SentenceTransformer("BAAI/bge-small-zh-v1.5") documents = [ "公司报销流程：员工提交报销单，直属领导审批，财务复核后打款。", "公司年假标准：入职满一年可享受5天年假。", "办公用品申请：需要在OA系统提交申请单，部门主管审批。" ] doc_vecs
