论一个 LLM 应用的四个积木

① Prompt（提示词）：你告诉模型"你是谁、要做什么、输出什么格式"。分系统提示（system）和用户提示（user）。

② 上下文（Context）：模型本身没有你的私有数据。RAG 就是把相关文档检索出来拼进 prompt；多轮对话就是把历史消息拼进 prompt。

③ 工具（Tools / Function Calling）：模型只会"说话"，不会查数据库、不会算数。你暴露函数给它，它决定何时调用，你执行后把结果回灌给它。

④ 编排（Orchestration）：单个问答不够用时，用 Agent 把"思考→调工具→看结果→再思考"串成循环，或让多个角色协作。

一句话：LLM App = Prompt（说什么）+ Context（给什么背景）+ Tools（能干什么）+ Orchestration（怎么串）。框架（LangChain / Spring AI / LlamaIndex）只是帮你少写胶水代码。

论常用技巧

少样本（Few-shot）：给 1~3 个「输入→期望输出」的例子，模型照着学格式，比空说"按 JSON 返回"可靠得多。

思维链（Chain-of-Thought, CoT）：加一句"一步步思考"，模型先推理再给答案，复杂题准确率明显提升；推理模型（如 o 系列）已内置。

结构化输出：明确"只返回 JSON，字段为 x/y"，必要时用 JSON Schema 约束（很多框架支持 response_format / structured output）。

temperature / top_p：temperature 低（0~0.3）=严谨可复现（分类、抽取）；高（0.8+）=有创意（写文案）。top_p 控制候选词范围，二者别同时大幅调。

论函数设计的三条铁律

幂等：同一个参数调两次结果一致（查询类天然幂等；写操作要小心重复扣款）。

可超时/可限流：工具里调外部 API 必须设超时，否则一个慢接口拖垮整轮对话。

参数校验：模型可能传奇怪的参数，执行前先校验类型/范围/权限，别直接拼 SQL。

论为什么 RAG 比"微调"更适合私有知识

微调是把知识"烧进权重"，更新慢、贵、易遗忘；RAG 是"即查即用"，知识改了只更新文档库，回答还可附引用、可追溯。私有/易变知识优先 RAG，微调留给"风格/格式/特定能力"更划算。

论两个必须记住的点

① 同一模型才可比：不同 Embedding 模型的向量空间不同，不能混用。入库和查询必须同一个模型、同一套参数。

② 向量库选型看规模：小数据用内存向量（NumPy / FAISS）；百万级用专用向量库（Milvus / pgvector / Redis / Chroma）。近似检索（ANN）比暴力全量快几个数量级，召回率略降但够用。

论Agent 的失败模式（必须防）

死循环：模型反复调同一个工具停不下来。→ 设最大步数（max_steps）强停。

幻觉工具调用：编造不存在的函数或参数。→ 工具白名单 + 参数校验，非法调用直接拒绝。

上下文溢出：多轮工具结果越攒越长，超 token 上限。→ 摘要压缩历史，只留关键。

人的兜底：高风险动作（发邮件、扣款）用 human-in-the-loop，模型提建议、人确认。

论记忆工程的三件事

① 按会话隔离：用 conversationId 区分用户/会话，互不串台（隐私与正确性的底线）。

② 窗口管理：只保留最近 N 条（如 20 条），更早的做摘要压缩，避免超上下文、控成本。

③ 持久化：生产用 Redis / 数据库存历史，重启不丢；本地 demo 用内存即可。

论成本治理四象限

缓存：相同/相似问题缓存答案，命中即省 token。

模型分级：简单分类用便宜小模型，复杂推理才上大模型。

上下文瘦身：只塞必要的历史和片段，长上下文是按 token 计费的真金白银。

监控：每次调用记 token 数、耗时、费用，异常飙升立刻告警。

论何时自研、何时用框架

原型/小工具直接调原生 API 最快；等出现"多工具编排、记忆管理、RAG 链路、评估"等重复胶水代码，再引入框架。框架替你管样板，但核心方法论（本文前三章）不变——先把方法论搞懂，换框架只是换语法。