资深软件工程师构建生产级 LLM 应用的能力体系与方法论
面向已有扎实工程能力、计划在 12 个月内成为能独立交付 AI 应用的资深工程师，系统阐述 LLM 应用的能力地图、架构范式（RAG / Agent）、Prompt 工程、评估体系、定制路径（Prompt/RAG/微调）与成本延迟优化，形成一套可落地、可迭代、可度量的工程方法论。
对资深软件工程师而言，AI 工程 ≈ 系统工程 + 概率直觉 + LLM 应用范式，无需先啃完深度学习理论。本白皮书的核心论点是：AI 应用的竞争力不在"更聪明的模型"，而在围绕模型的工程纪律——结构化的 Prompt、可靠的检索、严格的评估、受约束的 Agent、以及对成本与延迟的持续治理。
我们主张三条基本原则：(1) 评估先行——没有黄金集与可信指标就没有可迭代的产品；(2) 知识用 RAG、行为用微调、其余用 Prompt——按成本从低到高选择定制路径；(3) 约束 Agent 而非放任其"更自主"——清晰的工具、硬性的停止条件、代码层护栏与可回放的可观测性。沿着本白皮书的章节推进，读者可在 6–12 个月内建立从能力地图到生产落地的完整闭环。
目标读者：已有扎实工程能力、想在 12 个月内成为能独立交付 AI 应用的资深工程师。 结论先行：对资深 SWE 而言，AI 工程 ≈ 系统工程 + 概率直觉 + LLM 应用范式，不必先啃完深度学习理论。
| 层级 | 能力 | 为什么重要 | 最小掌握标准 |
|---|---|---|---|
| 1. 基础直觉 | 概率、向量、梯度下降的直觉 | 看懂论文与调参 | 能解释 embedding / softmax / 过拟合 |
| 2. LLM 应用 | Prompt 工程、结构化输出、function calling | 90% 落地工作在这层 | 能写出稳定 JSON 输出的 prompt |
| 3. 检索 | Embedding、向量库、RAG、重排序 | 让模型用私有/最新知识 | 能搭一个可用的 RAG |
| 4. Agent | 工具调用、规划、多步循环、MCP | 复杂任务自动化 | 能写一个带工具的 agent 循环 |
| 5. 评估 | 离线评测、A/B、幻觉检测、回归 | 上线质量的护城河 | 有一套可复现的 eval 集 |
| 6. 部署/运维 | 推理服务、成本、缓存、限流、可观测 | 生产可靠性与成本 | 能算清单请求成本并优化 |
大多数 LLM 应用可归为四种范式，复杂度递增。先用能满足需求的最简范式。
最简单：给 prompt，拿输出。适合翻译、摘要、分类、改写。
const res = await llm.complete({
system: "你是严格的分类器，只输出 JSON。",
user: `把邮件分类为 {work, personal, spam}：\n${email}`,
temperature: 0,
});工程要点：低温、明确输出 schema、给 few-shot 例子、对输出做校验与重试。
当答案依赖私有/最新/大量知识时，先检索再生成。
query → embed → 向量检索 top-k → 拼进 prompt → 生成（带引用）
工程要点：切分粒度、混合检索（关键词 + 向量）、重排序、把「来源」带回答案里以便核查。详见 RAG 架构入门。
让模型决定调用哪个函数、传什么参数，由你的代码执行。
const tools = [{
name: "get_weather",
parameters: { type: "object", properties: { city: { type: "string" } } },
}];
const call = await llm.complete({ user: "北京天气？", tools });
if (call.toolCall) {
const result = await getWeather(call.toolCall.args.city);
// 把 result 回传给模型生成最终回答
}工程要点：工具描述要精确；参数用 schema 约束；对副作用工具（写操作）加确认与幂等。
多步任务：模型在「思考 → 调用工具 → 观察结果」间循环，直到完成。
let context = [userGoal];
for (let step = 0; step < MAX_STEPS; step++) {
const decision = await llm.decide(context, tools);
if (decision.done) return decision.answer;
const observation = await execute(decision.toolCall);
context.push(decision, observation);
}工程要点：
Model Context Protocol 把「工具、资源、提示」抽象成标准接口，让不同客户端/模型复用同一批能力。价值在于解耦：工具提供方与模型使用方各自演进。
需要外部/私有知识？ ──否──> 直接调用
│是
v
需要执行动作/多步？ ──否──> RAG
│是
v
任务步骤固定？ ──是──> 工具调用 + 你写编排
│否
v
Agent 循环
相关：AI 工程师能力地图与学习路线。
检索增强生成（Retrieval-Augmented Generation, RAG）把「外部知识检索」与「大模型生成」结合， 让模型在回答时引用最新、私有或领域特定的资料，而不是仅依赖训练时的参数记忆。
async function rag(query: string) {
const qVec = await embed(query);
const chunks = await vectorStore.search(qVec, { topK: 5 });
const context = chunks.map((c) => c.text).join("\n---\n");
return llm.complete(`基于以下资料回答：\n${context}\n\n问题：${query}`);
}| 维度 | 选择 | 说明 |
|---|---|---|
| 切分粒度 | 200–500 token | 太大稀释相关性，太小丢上下文 |
| 向量库 | pgvector / Qdrant | v1 预留，v2 接入 |
| 重排序 | Cross-encoder | 提升 top-k 精度 |
在 AI LifeOS 中，RAG 属于 v2：v1 先把知识库内容与元数据做扎实，为向量化预留
Embedding模型。
目标读者：正在把 LLM 塞进真实产品的工程师。结论先行：Prompt 不是"话术"，是一段需要版本化、测试、监控的代码。把它当接口契约来对待。
相关阅读：LLM 应用架构、RAG 架构、AI 工程师路线。
一个生产级 prompt 由四段组成，建议固定顺序：
[System] 你是一个严格的合同审阅助手。只依据<资料>作答，
资料中没有的内容必须回答 "INSUFFICIENT_CONTEXT"。始终输出 JSON。
[资料]
<<<
{{retrieved_chunks}}
>>>
[任务] 抽取所有付款条款，输出 schema:
{ "terms": [{ "clause": string, "due_days": number }] }
[输出] 只输出 JSON，不要解释。| 手段 | 何时用 | 代价 |
|---|---|---|
Provider 的 JSON mode / response_format | 首选，能强约束 | 需模型支持 |
| Function / Tool calling | 需要触发副作用或严格 schema | 略增延迟 |
| 语法约束解码（grammar/GBNF） | 自托管、要 100% 合法 | 部署复杂 |
| 纯 prompt 锚点 + 后处理解析 | 兜底 | 需重试与容错 |
关键实践：无论哪种，都要在代码侧用 schema（zod / pydantic）再校验一次，失败即触发一次"修复重试"（把校验错误回灌给模型）。
给 2–5 个覆盖边界情况的示例，比堆形容词有效得多。示例要包含"困难样本"（否定、空结果、歧义）。
让模型先推理再给答案能提升复杂任务准确率；但生产中不要把推理暴露给用户，用工具调用或"先想后答，只输出答案字段"控制。对已具备内建推理的模型，避免强行叠加冗长 CoT。
对高价值、可离线的任务：采样多条（temperature>0）→ 多数投票 / 打分聚合。用延迟和成本换准确率。
一个巨型 prompt 不如 3 个单一职责的小 prompt：抽取 → 规范化 → 生成。每步可单测、可缓存、可换模型。
让模型对照评分表给自己的输出打分并修订。注意 judge 也会有偏差，需与人工抽检校准。参见 LLM 应用评估。
INSUFFICIENT_CONTEXT / null 出口，宁可拒答不可幻觉。prompts/xxx@v3.md），不硬编码在业务逻辑深处。JSON.parse——生产必炸。你是{{角色}}。目标：{{单一任务}}。
规则：
- 只依据<资料>作答；缺失信息输出 {{兜底值}}。
- 输出严格符合以下 JSON schema，且只输出 JSON：
{{schema}}
示例：
输入：{{ex_in}} 输出：{{ex_out}}
<资料>{{context}}</资料>
输入：{{user_input}}Prompt 工程的上限不在"魔法咒语"，而在结构化、可测试、可监控的工程纪律。把它当成会被 code review 的接口，你的 LLM 应用才会稳定。
结论先行：Evals 是 LLM 产品的护城河。模型会换、prompt 会改、数据会漂，只有一套可信的评估体系能让你放心迭代。它对 LLM 应用的意义，等价于单元测试之于传统软件。
相关阅读：Prompt 工程模式、RAG 架构、LLM 应用架构。
| 层 | 对象 | 频率 | 例子 |
|---|---|---|---|
| 单元级 | 单个 prompt / 组件 | 每次改动 | JSON 合法率、字段抽取准确率 |
| 场景级 | 端到端任务 | 每次发布 | 一组真实用户任务的通过率 |
| 线上级 | 生产流量 | 持续 | 用户反馈、拒答率、延迟、成本 |
{ input, ideal_output?, must_include[], must_not_include[], tags }。不是每条都需要唯一标准答案——很多任务用性质断言比精确匹配更实用。对"有帮助/忠实/连贯"这类难量化维度，用强模型按 rubric 打分：
你是严格评审。依据下面评分表给"回答"打分(1-5)并给出理由。
维度：忠实性(仅依据资料)、相关性、完整性。
资料：{{context}} 问题：{{q}} 回答：{{a}}
输出 JSON: {"faithfulness":n,"relevance":n,"completeness":n,"reason":"..."}必须校准：先让人工标 30–50 条，测 judge 与人工的一致性（如 Cohen's κ / 相关系数）。judge 与人不一致时，先修 rubric，别急着信分数。注意位置偏差（成对比较要交换顺序取平均）。
把失败归因到层，否则你会瞎调：
改动 prompt/模型/检索参数
│
▼
跑黄金集 ──► 指标对比基线
│
├─ JSON 合法率 < 99% → 阻断
├─ 关键任务通过率下降 >2% → 阻断
└─ 成本/延迟回归超阈值 → 告警原则：任何影响输出的改动都要过评估，像跑测试一样。为可复现，固定随机种子/温度，或对采样类指标多次取均值。
先花两天搭一个 50 条黄金集 + 少量确定性指标 + 一个校准过的 judge，你的迭代速度和信心会立刻不同。评估体系的成熟度，基本等于 LLM 团队的成熟度。
结论先行：Agent = LLM + 工具 + 循环 + 记忆 + 停止条件。90% 的"Agent 需求"其实用一个带工具调用的确定性工作流就够了；只有当步骤数不可预知、需要动态决策时，才真正需要自主循环。
相关阅读：Prompt 工程模式、LLM 应用评估、LLM 应用架构、RAG 架构。
最常见也最稳。LLM 输出一个函数调用，代码执行后可选把结果回灌一次。适合"查天气/查订单/结构化抽取"。能用它就别上循环。
交替"推理—行动—观察"，模型自己决定下一步用哪个工具：
Thought: 需要先查用户余额
Action: get_balance(user_id="u1")
Observation: 1200
Thought: 余额够，执行转账
Action: transfer(...)
Observation: ok
Thought: 完成
Answer: 已转账优点：灵活、可解释。风险：可能绕圈、步数发散——必须设 max_steps 与循环检测。
先让模型产出完整计划，再逐步执行（执行时可用更便宜的模型）。比 ReAct 更可控、更省钱，适合步骤较确定的多步任务；计划错了需要"重规划"分支。
执行后让模型对照目标/测试结果自评并重试。对"写代码→跑测试→修错"类任务提升明显；代价是更多轮次。
把复杂任务拆给多个专职 agent（如 规划者 / 编码者 / 评审者），由一个 orchestrator 协调。
| 拓扑 | 说明 | 适用 |
|---|---|---|
| Supervisor（主管路由） | 一个主管把子任务分派给专家 | 任务可清晰分工 |
| Pipeline（流水线） | A 的输出是 B 的输入 | 阶段固定 |
| Debate / Review | 生成者 + 批评者互相制衡 | 高质量要求 |
忠告：多智能体会放大延迟、成本与故障面。先用单 agent + 好工具打透，确有必要再拆。
除最终答案外，评估轨迹质量：是否选对工具、步数是否合理、是否绕圈、成本是否可控。把典型任务做成黄金集，回归门禁化——见 LLM 应用评估。
Agent 的工程难点不在"让它更聪明"，而在约束它：清晰的工具、硬性的停止条件、代码层护栏、可回放的可观测性。先做最简形态，用评估驱动复杂度的增加。
结论先行：先 Prompt，再 RAG，最后才微调。90% 的"要不要微调"其实是"知识没喂对"或"prompt 没写好"。微调解决的是行为/风格/格式问题，不是知识新鲜度问题——后者是 RAG 的活。
相关阅读：RAG 架构、Prompt 工程模式、LLM 应用评估、LLM 应用架构。
| 路径 | 擅长 | 不擅长 | 成本/门槛 |
|---|---|---|---|
| Prompt | 快速试错、通用任务、注入少量上下文 | 大量私有知识、稳定风格 | 最低 |
| RAG | 私有/时效知识、可溯源、易更新 | 改变模型"说话方式"、复杂推理风格 | 中（需检索基建） |
| 微调 | 固定风格/格式/领域语气、压缩长 prompt、提升特定任务一致性 | 注入会变的知识、可解释性 | 高（数据+训练+评估+运维） |
一句话：知识用 RAG，行为用微调，其它用 Prompt。
需求来了
│
├─ 只是通用任务/少量上下文？ → Prompt（先做到位）
│
├─ 需要私有/最新/可溯源的知识？ → RAG
│
├─ 需要稳定的风格/格式/领域语气，
│ 或想压缩超长 prompt 降本？ → 考虑微调（PEFT/LoRA）
│
└─ 既要新知识又要稳风格？ → RAG + 微调 组合
在投入微调前，先确认：
缺任意一条，先别微调。
把三者当互补层而非竞争项：Prompt 打底、RAG 供知识、微调定行为。按"低成本→高成本"顺序推进，每一步都用评估验证收益，别一上来就烧微调。
结论先行：LLM 的两大生产成本是token 费用和用户等待。优化顺序应是先"别调用"（缓存/路由），再"调小/调短"（分级/压缩），最后才"调快基建"（流式/并行/批处理）。
相关阅读：LLM 应用架构、微调 vs RAG vs Prompt、Agent 架构模式、LLM 应用评估。
max_tokens、要 JSON 别要长篇解释。每次优化（换小模型、压上下文、开缓存）都可能掉质量。用黄金集回归（见 LLM 应用评估）确认"省了成本但通过率没跌超阈值"，否则就是劣化。
成本与延迟优化是工程活，不是玄学：先测量，再按"别调用 → 用对模型 → 调短 → 调快 → 改基座"的顺序动手，每步用评估兜住质量。多数应用做完缓存+分级+上下文瘦身，就能砍掉一大半开销。