做 LLM 应用开发这两年我最大的感受是真正卡住大家的往往不是模型本身的能力而是“不知道该做什么、怎么做”。GitHub 上的 awesome-llm-apps 这类仓库表面看是一份资源清单实际上是一张 LLM 应用生态地图——它告诉你好用的大模型应用长什么样、哪些方向已经被验证过、哪些还停留在 demo 阶段。我把它翻过好几轮顺着里面的项目读源码、跑 demo、再改造到自己业务里踩了不少坑也攒下来一套自己的判断标准。这篇就把我对这个生态的观察和实操心得一次说清楚。不管你是刚接触大模型的初学者还是已经在做应用落地的工程师应该都能从中找到能直接拿走用的东西。1. awesome-llm-apps 是什么一个仓库背后的 LLM 应用全景图1.1 从仓库定位看收集逻辑awesome-llm-apps 的核心内容是把散落在整个开源社区里的大模型应用项目按类别收集起来。它里面收录的项目大致覆盖这么几个方向基于大模型的 AI 助手和聊天机器人、各类 Agent自主智能体项目、知识库问答和 RAG检索增强生成应用、代码生成与编程辅助工具、写作翻译总结等文本处理工具以及垂直行业应用法律、金融、教育等。这份清单的收集逻辑其实代表了 LLM 应用领域的主流认知大模型不是拿来直接用的而是要包一层产品逻辑、接上数据、配上工具才能真正产生价值。看这份清单重点不是把每个项目都背下来而是理解每个类别背后的技术栈和实现思路。有些项目是纯粹的 prompt 封装把一段精心设计过的提示词包成 API 或者 Web 界面有些项目会在模型外面加检索、加记忆、加工具调用形成完整的 agent 架构还有一类会针对特定领域做微调让模型输出符合行业规范。同样是“LLM 应用”这三种做法的复杂度和适用场景差别巨大。1.2 为什么需要这样一份清单LLM 领域最大的问题不是资料太少而是信息密度太高、更新太快。几乎每天都有新项目冒出来今天看还觉得先进的架构下个月可能就被另一套方案取代。awesome-llm-apps 这类清单的价值在于它帮你过滤掉了大量重复和低质量的项目只留下那些经过社区验证、确实跑得通的代表作品。我自己的使用方式很直接接到一个新业务需求时不急着动手写代码先去这份清单里找有没有同类参考项目。比如去年要做企业内部知识库问答我先翻了一遍清单里和 RAG 相关的项目把几个主流方案的工程实现做了对比——有的是纯向量检索有的是向量加关键词混合检索有的还加了重排序环节。看完之后我对技术选型就有了底至少知道这个方向是社区验证过的而不是自己闷头造轮子。另一层价值在于这份清单反映了大模型应用的能力边界。你会看到哪些场景已经被产品化比如代码辅助和客服机器人哪些还在探索期比如复杂多步 agent 任务。这些信息对判断技术投入方向很有参考意义。我自己判断新项目值不值得看标准很简单有没有真实用户、有没有完整的工程实现、有没有把模型的弱点处理到位。三个都满足才值得花时间深入研究。2. 应用分类背后藏着技术选型的底层逻辑2.1 对话增强型应用Prompt 工程的主场清单里最多的就是对话增强型应用把大模型封装成聊天机器人、写作助手、翻译工具。这类应用的核心工作几乎全部集中在 prompt 工程上技术门槛最低但要做到“真的好用”其实很难。这里我要说一个很多人容易忽略的点prompt 工程不是简单地写几句“你是一个专业的翻译”而是要设计完整的角色设定、任务分解、输出格式约束、边界条件处理。我自己在实践中最常用的套路是给模型明确的角色和任务目标让它在特定上下文里工作用 few-shot 示例把输入输出的格式说清楚比写十句抽象描述都管用把可能出现的边界情况写进 prompt比如“如果用户问题与主题无关请回复 XXX”设置输出解析标记方便程序稳定读取结果一个写作助手最初版本可能只是“帮我写一篇介绍”但实际产品需要考虑用户给的材料、风格偏好、字数要求、语气控制这些维度全部得靠 prompt 设计去约束。所以对话增强型应用虽然简单却是理解 LLM 应用开发基本功的最好切入点。把一个聊天机器人的 prompt 打磨到在各种刁钻输入下都不跑偏这个能力在后面的复杂应用里全是刚需。2.2 Agent 型应用从“会聊天”到“会干活”真正让 LLM 应用产生质变的是 Agent 方向的尝试。LLM powered autonomous agents 这个概念火起来之后核心思路变成了让模型自主规划任务、调用外部工具、根据执行结果调整下一步动作从“会聊天”变成“会干活”。Agent 的核心组件包括模型本身的推理能力、工具调用的协议现在主流是 function calling、记忆模块短期和长期、任务规划模块。清单里比较有代表性的 Agent 项目有的擅长老老实实按步骤执行任务有的会在执行过程中自我纠错有的支持多 Agent 协作——比如一个负责调研、一个负责写代码、一个负责审查角色分开、互相验证。我实际跑通一个多 Agent 项目后的感受是看起来很美但稳定性是最大的问题。模型在单步决策上的准确率可能很高但多步串联之后错误会被逐级放大。每执行一步都可能出错而 Agent 往往缺乏可靠的错误恢复机制。比如让 Agent 去调研一个主题并写成报告它可能在第三步搜索时就理解错了方向后面所有内容都建立在错误的基础上。所以我的判断是Agent 类应用适合用在“错了也来得及被人类发现”的场景比如辅助调研、内容草稿生成不太适合完全托管的自动化决策流程。2.3 RAG 应用让模型读你的私有文档RAG检索增强生成是目前企业落地最广的方向。本质上是给大模型加一个外部知识库先把文档切块、向量化、存进向量数据库用户提问时先检索出相关片段再把片段和问题一起交给模型生成回答。用生活化的方式理解大模型像一个知识面很广但记忆力有限的顾问你问他问题他不会承认自己不知道而是会编一个答案。RAG 相当于给他配了一个资料室他回答之前先去资料室翻资料翻到相关材料再回答答案就有了依据用户也能看到他参考了哪些文档。RAG 应用的开发难点不在模型调用而在检索质量。文档怎么切块、块与块之间怎么保持语义完整、用哪个 embedding 模型、向量库的召回率、检索结果的重排序……这些环节每一步都影响最终效果。清单里 RAG 类的项目有的强化了切块策略有的加入了向量加关键词的混合检索有的加入了回答后的引用溯源——这些都是实践中积累出来的真实需求。我自己的经验是切块这个环节最容易被低估。切得太小语义不完整切得太大检索精度下降。实际调优时我会根据文档类型做差异化处理合同按条款切技术文档按章节切问答对按候选答案粒度存。2.4 工作流型应用稳定压倒一切还有一类应用走的是“工作流加 LLM”的路线把业务流程拆成固定的节点每个节点调用一次大模型节点之间用代码串联。这类应用看起来不如 Agent 炫酷但稳定性比 Agent 高得多——因为流程是预设的模型只负责每个节点内的单步任务。比如一个合同审核应用流程可以是上传合同、提取关键条款、逐条比对公司标准、输出风险报告。每个步骤都是一个小模型调用即使某一步输出不理想也只影响这一步不会像 Agent 那样错误链式放大。在实际业务里我越来越倾向于用工作流替代 Agent。对于大部分场景固定流程加单点模型调用已经足够而且更容易调试、更容易评估、成本也更可控。Agent 的自主规划能力确实强但它的不确定性恰恰是生产环境最忌讳的。我把几种应用类型整理成一个选型对照基于我自己和社区项目的实践应用类型核心组件适用场景稳定性开发成本对话增强Prompt 设计聊天、写作、翻译高低RAG向量检索加生成知识库问答、文档分析中高中工作流流程编排加模型调用合同审核、数据处理高中Agent规划加工具调用加记忆自动调研、复杂任务低高3. 跑通一个 LLM 应用要迈过的三道真实门槛3.1 模型调用层的细节参数、上下文与输出解析清单里的项目看再多最终要落地还是得自己写代码。跑通一个 LLM 应用第一道门槛是模型调用层的工程细节。先看参数设置。temperature 控制输出的随机性做代码生成、数据提取这类任务我通常调到 0 到 0.3做创意写作可以调到 0.7 以上。max_tokens 限制输出长度很多人忽略的是这个参数不只是防止超长输出还会影响模型对任务的规划——如果输出空间不够模型会倾向于截断而不是先回答问题。比如你让它写一份分析报告输出上限设得太小它可能刚写完开头就停了。接着是输出解析。模型返回的不只是纯文本还要考虑流式输出、工具调用参数、格式化输出这些情况。我踩过最多的坑是 JSON 解析模型偶尔会在 JSON 前后加注释、加说明文字甚至生成不完整的 JSON。现在的做法是在 prompt 里严格要求纯 JSON 输出同时用容错解析库兜底解析失败就自动重试一次。这套组合下来解析失败率能降到很低。还有一个很多人不注意的细节上下文的管理。模型调用的输入包含系统提示词、历史对话、检索结果三部分它们一起占用上下文窗口。对话越来越长之后要么做截断要么做摘要压缩要么做滑动窗口。这块做不好应用用着用着就会“失忆”或者费用一路暴涨。3.2 工具调用Agent 落地的关键一跳Agent 类应用的核心是让模型学会调用工具。现在主流模型都支持 function calling 协议开发者先声明一堆工具函数比如查询天气、搜索网页、执行代码模型在回答时会决定要不要调用某个工具、传什么参数然后由应用代码去真正执行再把执行结果返回给模型继续生成。这里的工程细节非常多。工具函数的描述要写清楚因为模型是靠描述来理解工具用途和参数的参数校验要严格模型生成的参数经常有格式问题工具返回的内容可能很长需要截断或摘要后再传回给模型否则上下文会被工具结果塞满。我见过很多人在这一步栽跟头工具定义写得太模糊模型不知道该调用哪个或者工具链太长模型在中间步骤迷路。我的经验是工具数量控制在 5 个以内、每个工具的用途说明不超过两句话时模型调用的准确率最高。工具一多再强的模型也会犯糊涂。另外工具执行结果一定要设计统一的返回格式最好包含状态码和结构化数据这样模型判断下一步时才不会因为看到一段杂乱的输出而蒙圈。3.3 成本与延迟生产环境的第一道坎demo 跑通和上线生产是两回事其中成本与延迟是最现实的门槛。先算一笔粗略的账。一个企业客服机器人假设每天处理 1 万次对话每次对话平均 4 轮每轮消耗 1000 个输入 token 和 500 个输出 token按市面上主流大模型 API 的计费标准估算一个月光模型调用费就是相当可观的数字。很多团队做 LLM 应用第一版功能上线后发现 API 账单比服务器费用还高这才开始想优化。优化手段无非几个方向用缓存完全相同的请求直接命中缓存不重复调用模型用小模型简单的分类和提取任务不需要最强的模型换小模型能省一大笔精简上下文历史对话定期做摘要而不是每次都把全部内容塞进去批量处理异步任务集中调 API有些平台对批量请求有折扣。延迟同样是个问题。大模型生成是逐 token 输出的长回答意味着高延迟。如果产品对响应速度有要求就得用流式输出让用户看到逐字生成的效果或者限制输出长度。做实时交互类应用还要考虑模型选择的平衡更强的模型通常更慢也更贵。我的原则很简单先明确这个任务需要多强的模型能力再选最便宜的那个而不是一上来就上旗舰模型。4. 效果不稳定是常态上下文管理与评估体系4.1 上下文窗口不是越大越好现在模型支持的上下文窗口越来越大但实际使用中我们发现窗口大不代表效果好。模型对中间部分内容的关注度往往不如开头和结尾这就是社区里常说的“lost in the middle”现象。你塞进去 10 万字资料模型可能只盯着前面和最后的部分看中间的关键信息反而被忽略。所以在设计应用时我的原则是“能不放就不放”。需要模型处理长文档优先考虑分段处理、逐段回答而不是把全文都塞进上下文。需要模型做全局判断的先做内容摘要再基于摘要做决策。这个原则能同时提升效果和降低成本是一举两得的事情。另一个跟上下文相关的问题是历史对话的管理。长时间对话中早期信息会逐渐被挤出上下文窗口模型开始“忘记”用户说过的偏好。社区的常见做法是做记忆摘要每隔几轮对话把前面的内容总结成一段摘要保存在系统提示词里。这样既能保留关键信息又不占用太多上下文空间。我实践下来这个方案比单纯加大窗口效果好得多尤其适合客服和助手类产品。4.2 评估集LLM 应用开发的隐形基础设施这是我最想强调的一点。很多团队做 LLM 应用改了一版 prompt 之后凭感觉说“好像变好了”然后上线然后出问题。正确的做法是建评估集。评估集就是一批经过人工标注的测试用例一份输入、一份期望输出或者期望行为描述。每次修改 prompt、调整检索逻辑、更换模型都用同一套评估集跑一遍对比效果变化。这样你才能知道一次改动到底是变好了还是变坏了。我在实际项目里建评估集的做法是这样的收集线上真实用户的问题挑覆盖面广的 50 到 100 条为每条问题标注期望的答案要点核心内容要覆盖但不要求逐字一致跑评估脚本用大模型当裁判给回答打分每次改动后跑一遍记录分数变化这套流程听上去笨重但能帮你避免大量无效的“调 prompt”工作。没有评估集你的每次优化都是一次赌博。我见过最典型的例子一个团队调了一版 prompt肉眼看了五六个例子觉得不错就上线了结果线上差评率反而升高回滚之后才发现新 prompt 在特定类型的问法上全挂了。有了评估集这类问题在部署前就能被拦住。4.3 幻觉处理的现实手段幻觉是大模型应用的永恒话题。模型一本正经地胡编乱造这在客服、医疗、法律等场景里是不可接受的。RAG 架构能把幻觉率降下来但降不到零。实践中我处理的维度有三个。输入侧约束在 prompt 里明确告诉模型“只能基于给出的资料回答资料里没有的信息要明确说不知道”。检索侧优化提高检索质量让模型有足够的相关资料可依。输出侧校验对关键事实做二次校验比如生成的内容里如果包含具体数字、日期、人名用规则或另一个模型调用做核对。需要清醒认识到的是幻觉无法完全消除。所以在产品设计上要给用户留出确认的环节——提供引用来源、显示回答的置信度、在关键决策场景引入人工审核。这些不是妥协而是负责任的做法。用户对 LLM 应用的信任往往建立在这些细节之上。一个能明确说“我不知道”并给出相关资料链接的助手比一个每次都自信满满但偶尔出错的助手更让人放心。5. 垂直领域 LLM 应用数据准备才是重头戏5.1 通用模型做垂直任务的三种路线聊完通用应用再聊垂直领域。很多人做 LLM 应用做到一定阶段会发现通用模型对行业知识的理解不够深比如法律模型分不清法条和司法解释的关系医疗模型容易把症状和诊断混为一谈。这时候有三条路线可选提示词路线把行业规则、术语表、示例写进 prompt让模型按规则输出。成本最低但效果受限于上下文长度RAG 路线把行业文档、规范、历史案例做成知识库通过检索增强模型回答。适合知识密集型场景微调路线用行业数据对模型做继续训练让模型本身的“知识”和“行为习惯”都变得行业化。成本最高但效果最彻底这三条路线可以组合使用。我见过比较成功的垂直领域应用通常是“微调打底加 RAG 补充实时知识加 prompt 约束输出格式”的组合拳。微调让模型具备行业语言能力RAG 让它拿到最新的领域资料prompt 则保证输出形式符合业务要求。5.2 数据准备的具体做法很多团队一上来就想微调但忽略了一个事实微调的效果很大程度上取决于数据的质量而不是数量。垂域 LLM 数据准备是有方法论可循的。第一步是数据清洗。原始行业数据往往包含大量噪音格式混乱的表格、重复文本、错误标注、个人信息等。清洗至少要过几关去重、格式规范化、敏感信息打码、低质量样本过滤。这一步不做好后面所有环节都会受到影响。第二步是构造指令数据。微调需要的是“指令加输入加输出”结构化的数据但原始数据通常是文档、工单、日志不会天然是这个格式。需要花大量人力把原始数据转写成指令形式。这一步非常耗人我见过一个医疗项目光是把病历转写成问答对就花了三个人两周时间。这个环节偷不得懒但可以借助一个初版的大模型先做一轮转换再由人工校对能省下不少时间。第三步是质量控制。指令数据的质量直接决定微调效果的天花板。常见的做法是做交叉审核每一条指令数据至少两个人标注不一致的重新讨论。过程很枯燥但偷懒的话后面模型的效果会成倍地还回来。5.3 微调之外更轻量的方案微调门槛高、周期长。对于大部分团队来说先做 RAG 是更务实的选择。RAG 对数据的处理要求没那么高不需要构造指令对只要把文档切块、向量化、入库就行缺点是检索质量决定应用效果需要花时间调试。我的建议是这样一个推进节奏先用 RAG 把产品跑起来积累真实用户问题用这些真实问题构造评估集当 RAG 效果触顶、评估集也足够大的时候再上微调。这个顺序能避免“一上来就微调结果数据质量不行、效果比基座模型还差”的尴尬。关于预训练和微调的损失函数设计这是模型训练层的专业话题。做应用层开发的人不需要完全理解所有细节但至少要知道微调阶段用的是交叉熵损失目标是让模型学会对齐指令和答案预训练的损失函数决定了模型从零开始学习语言的能力。对应用开发者来说理解到这一层就够了不必陷进去。真正需要投入精力的永远是数据准备和效果评估这两件事。6. 给想入局的人一条可复制的学习路径6.1 先会用再懂原理接触 LLM 应用开发我的建议是不要一上来就啃论文。先把模型 API 用好跑通一个最简单的对话应用理解 prompt、上下文、temperature、max_tokens 这些概念。这个过程快的话几天就能完成但能帮你建立最基本的手感。然后学 RAG搭一个本地知识库问答系统自己准备文档、切块、向量化、检索、生成。在这个过程里你自然会对 embedding 模型、向量数据库、召回率这些概念有直观认识。RAG 是现在落地最多的技术栈学会它基本就能应对大多数业务需求。再往后才是 Agent 和微调。Agent 需要你理解工具调用的协议和设计模式微调需要你理解训练数据的构造和训练流程。这两个方向都不是必须的根据你的业务需要再深入。LLM 的原理可以边做边补比如你用到上下文窗口了再去读关于注意力机制的文章理解会更深刻也不会觉得枯燥。6.2 动手项目怎么选学习 LLM 应用开发动手很关键但不建议从零开始造轮子。我的做法是先找 awesome-llm-apps 清单里的一个项目把它完全跑起来然后改造一个小功能。比如清单里有个知识库问答项目你跑通之后把它的文档换成你的业务文档再调整一下 prompt这就是一个属于你的应用了。更进一步的练手方向有两个。一个是做个人知识库助手把笔记、资料、收藏的文章整理成知识库做一个能问答的助手。这个项目麻雀虽小五脏俱全RAG 的所有关键环节都能练到。另一个是做一个简单的 Agent定义两三个工具比如查天气、做算术、搜索信息让模型学会在对话中调用工具完成任务。跑通这个你对 function calling 的理解会比看十篇文章都深。这两个项目做完你已经具备独立开发一个 LLM 应用的基本能力了。剩下的就是在实际业务场景里积累经验处理那些文档里不会写到的边界情况。6.3 持续跟进生态的节奏LLM 生态变化太快保持跟进本身就是一种能力。我的习惯是每天花固定时间扫一遍技术社区的热点重点关注三类信息新模型发布和能力评测判断哪些新能力可以用来改进现有应用重要框架和工具的版本更新比如 agent 框架、RAG 框架的迭代方向高质量的实践案例和踩坑总结这类内容往往比官方文档更有价值需要提醒的是不要每个新概念都追。LLM 领域热词层出不穷但很多概念换个说法就是旧东西。判断一个方向值不值得投入我的标准是它有没有解决真实问题、有没有案例验证过、有没有稳定可用的实现。三个都满足才值得花时间研究。最后分享一个我自己的体会做 LLM 应用最忌讳的是把模型当成无所不能的魔法。模型确实很强但它强在语言理解和生成弱在准确性和稳定性。一个成熟的应用架构永远是在发挥模型的长处的同时用工程手段补上它的短板——要么用检索约束事实要么用工作流控制流程要么用评估体系守住质量线。模型更新换代很快但你围绕业务构建的数据、评估方法和工程框架才是真正会随时间沉淀下来的资产。 LLM 应用开发实战：从生态地图到工程落地的关键方法
做 LLM 应用开发这两年我最大的感受是真正卡住大家的往往不是模型本身的能力而是“不知道该做什么、怎么做”。GitHub 上的 awesome-llm-apps 这类仓库表面看是一份资源清单实际上是一张 LLM 应用生态地图——它告诉你好用的大模型应用长什么样、哪些方向已经被验证过、哪些还停留在 demo 阶段。我把它翻过好几轮顺着里面的项目读源码、跑 demo、再改造到自己业务里踩了不少坑也攒下来一套自己的判断标准。这篇就把我对这个生态的观察和实操心得一次说清楚。不管你是刚接触大模型的初学者还是已经在做应用落地的工程师应该都能从中找到能直接拿走用的东西。1. awesome-llm-apps 是什么一个仓库背后的 LLM 应用全景图1.1 从仓库定位看收集逻辑awesome-llm-apps 的核心内容是把散落在整个开源社区里的大模型应用项目按类别收集起来。它里面收录的项目大致覆盖这么几个方向基于大模型的 AI 助手和聊天机器人、各类 Agent自主智能体项目、知识库问答和 RAG检索增强生成应用、代码生成与编程辅助工具、写作翻译总结等文本处理工具以及垂直行业应用法律、金融、教育等。这份清单的收集逻辑其实代表了 LLM 应用领域的主流认知大模型不是拿来直接用的而是要包一层产品逻辑、接上数据、配上工具才能真正产生价值。看这份清单重点不是把每个项目都背下来而是理解每个类别背后的技术栈和实现思路。有些项目是纯粹的 prompt 封装把一段精心设计过的提示词包成 API 或者 Web 界面有些项目会在模型外面加检索、加记忆、加工具调用形成完整的 agent 架构还有一类会针对特定领域做微调让模型输出符合行业规范。同样是“LLM 应用”这三种做法的复杂度和适用场景差别巨大。1.2 为什么需要这样一份清单LLM 领域最大的问题不是资料太少而是信息密度太高、更新太快。几乎每天都有新项目冒出来今天看还觉得先进的架构下个月可能就被另一套方案取代。awesome-llm-apps 这类清单的价值在于它帮你过滤掉了大量重复和低质量的项目只留下那些经过社区验证、确实跑得通的代表作品。我自己的使用方式很直接接到一个新业务需求时不急着动手写代码先去这份清单里找有没有同类参考项目。比如去年要做企业内部知识库问答我先翻了一遍清单里和 RAG 相关的项目把几个主流方案的工程实现做了对比——有的是纯向量检索有的是向量加关键词混合检索有的还加了重排序环节。看完之后我对技术选型就有了底至少知道这个方向是社区验证过的而不是自己闷头造轮子。另一层价值在于这份清单反映了大模型应用的能力边界。你会看到哪些场景已经被产品化比如代码辅助和客服机器人哪些还在探索期比如复杂多步 agent 任务。这些信息对判断技术投入方向很有参考意义。我自己判断新项目值不值得看标准很简单有没有真实用户、有没有完整的工程实现、有没有把模型的弱点处理到位。三个都满足才值得花时间深入研究。2. 应用分类背后藏着技术选型的底层逻辑2.1 对话增强型应用Prompt 工程的主场清单里最多的就是对话增强型应用把大模型封装成聊天机器人、写作助手、翻译工具。这类应用的核心工作几乎全部集中在 prompt 工程上技术门槛最低但要做到“真的好用”其实很难。这里我要说一个很多人容易忽略的点prompt 工程不是简单地写几句“你是一个专业的翻译”而是要设计完整的角色设定、任务分解、输出格式约束、边界条件处理。我自己在实践中最常用的套路是给模型明确的角色和任务目标让它在特定上下文里工作用 few-shot 示例把输入输出的格式说清楚比写十句抽象描述都管用把可能出现的边界情况写进 prompt比如“如果用户问题与主题无关请回复 XXX”设置输出解析标记方便程序稳定读取结果一个写作助手最初版本可能只是“帮我写一篇介绍”但实际产品需要考虑用户给的材料、风格偏好、字数要求、语气控制这些维度全部得靠 prompt 设计去约束。所以对话增强型应用虽然简单却是理解 LLM 应用开发基本功的最好切入点。把一个聊天机器人的 prompt 打磨到在各种刁钻输入下都不跑偏这个能力在后面的复杂应用里全是刚需。2.2 Agent 型应用从“会聊天”到“会干活”真正让 LLM 应用产生质变的是 Agent 方向的尝试。LLM powered autonomous agents 这个概念火起来之后核心思路变成了让模型自主规划任务、调用外部工具、根据执行结果调整下一步动作从“会聊天”变成“会干活”。Agent 的核心组件包括模型本身的推理能力、工具调用的协议现在主流是 function calling、记忆模块短期和长期、任务规划模块。清单里比较有代表性的 Agent 项目有的擅长老老实实按步骤执行任务有的会在执行过程中自我纠错有的支持多 Agent 协作——比如一个负责调研、一个负责写代码、一个负责审查角色分开、互相验证。我实际跑通一个多 Agent 项目后的感受是看起来很美但稳定性是最大的问题。模型在单步决策上的准确率可能很高但多步串联之后错误会被逐级放大。每执行一步都可能出错而 Agent 往往缺乏可靠的错误恢复机制。比如让 Agent 去调研一个主题并写成报告它可能在第三步搜索时就理解错了方向后面所有内容都建立在错误的基础上。所以我的判断是Agent 类应用适合用在“错了也来得及被人类发现”的场景比如辅助调研、内容草稿生成不太适合完全托管的自动化决策流程。2.3 RAG 应用让模型读你的私有文档RAG检索增强生成是目前企业落地最广的方向。本质上是给大模型加一个外部知识库先把文档切块、向量化、存进向量数据库用户提问时先检索出相关片段再把片段和问题一起交给模型生成回答。用生活化的方式理解大模型像一个知识面很广但记忆力有限的顾问你问他问题他不会承认自己不知道而是会编一个答案。RAG 相当于给他配了一个资料室他回答之前先去资料室翻资料翻到相关材料再回答答案就有了依据用户也能看到他参考了哪些文档。RAG 应用的开发难点不在模型调用而在检索质量。文档怎么切块、块与块之间怎么保持语义完整、用哪个 embedding 模型、向量库的召回率、检索结果的重排序……这些环节每一步都影响最终效果。清单里 RAG 类的项目有的强化了切块策略有的加入了向量加关键词的混合检索有的加入了回答后的引用溯源——这些都是实践中积累出来的真实需求。我自己的经验是切块这个环节最容易被低估。切得太小语义不完整切得太大检索精度下降。实际调优时我会根据文档类型做差异化处理合同按条款切技术文档按章节切问答对按候选答案粒度存。2.4 工作流型应用稳定压倒一切还有一类应用走的是“工作流加 LLM”的路线把业务流程拆成固定的节点每个节点调用一次大模型节点之间用代码串联。这类应用看起来不如 Agent 炫酷但稳定性比 Agent 高得多——因为流程是预设的模型只负责每个节点内的单步任务。比如一个合同审核应用流程可以是上传合同、提取关键条款、逐条比对公司标准、输出风险报告。每个步骤都是一个小模型调用即使某一步输出不理想也只影响这一步不会像 Agent 那样错误链式放大。在实际业务里我越来越倾向于用工作流替代 Agent。对于大部分场景固定流程加单点模型调用已经足够而且更容易调试、更容易评估、成本也更可控。Agent 的自主规划能力确实强但它的不确定性恰恰是生产环境最忌讳的。我把几种应用类型整理成一个选型对照基于我自己和社区项目的实践应用类型核心组件适用场景稳定性开发成本对话增强Prompt 设计聊天、写作、翻译高低RAG向量检索加生成知识库问答、文档分析中高中工作流流程编排加模型调用合同审核、数据处理高中Agent规划加工具调用加记忆自动调研、复杂任务低高3. 跑通一个 LLM 应用要迈过的三道真实门槛3.1 模型调用层的细节参数、上下文与输出解析清单里的项目看再多最终要落地还是得自己写代码。跑通一个 LLM 应用第一道门槛是模型调用层的工程细节。先看参数设置。temperature 控制输出的随机性做代码生成、数据提取这类任务我通常调到 0 到 0.3做创意写作可以调到 0.7 以上。max_tokens 限制输出长度很多人忽略的是这个参数不只是防止超长输出还会影响模型对任务的规划——如果输出空间不够模型会倾向于截断而不是先回答问题。比如你让它写一份分析报告输出上限设得太小它可能刚写完开头就停了。接着是输出解析。模型返回的不只是纯文本还要考虑流式输出、工具调用参数、格式化输出这些情况。我踩过最多的坑是 JSON 解析模型偶尔会在 JSON 前后加注释、加说明文字甚至生成不完整的 JSON。现在的做法是在 prompt 里严格要求纯 JSON 输出同时用容错解析库兜底解析失败就自动重试一次。这套组合下来解析失败率能降到很低。还有一个很多人不注意的细节上下文的管理。模型调用的输入包含系统提示词、历史对话、检索结果三部分它们一起占用上下文窗口。对话越来越长之后要么做截断要么做摘要压缩要么做滑动窗口。这块做不好应用用着用着就会“失忆”或者费用一路暴涨。3.2 工具调用Agent 落地的关键一跳Agent 类应用的核心是让模型学会调用工具。现在主流模型都支持 function calling 协议开发者先声明一堆工具函数比如查询天气、搜索网页、执行代码模型在回答时会决定要不要调用某个工具、传什么参数然后由应用代码去真正执行再把执行结果返回给模型继续生成。这里的工程细节非常多。工具函数的描述要写清楚因为模型是靠描述来理解工具用途和参数的参数校验要严格模型生成的参数经常有格式问题工具返回的内容可能很长需要截断或摘要后再传回给模型否则上下文会被工具结果塞满。我见过很多人在这一步栽跟头工具定义写得太模糊模型不知道该调用哪个或者工具链太长模型在中间步骤迷路。我的经验是工具数量控制在 5 个以内、每个工具的用途说明不超过两句话时模型调用的准确率最高。工具一多再强的模型也会犯糊涂。另外工具执行结果一定要设计统一的返回格式最好包含状态码和结构化数据这样模型判断下一步时才不会因为看到一段杂乱的输出而蒙圈。3.3 成本与延迟生产环境的第一道坎demo 跑通和上线生产是两回事其中成本与延迟是最现实的门槛。先算一笔粗略的账。一个企业客服机器人假设每天处理 1 万次对话每次对话平均 4 轮每轮消耗 1000 个输入 token 和 500 个输出 token按市面上主流大模型 API 的计费标准估算一个月光模型调用费就是相当可观的数字。很多团队做 LLM 应用第一版功能上线后发现 API 账单比服务器费用还高这才开始想优化。优化手段无非几个方向用缓存完全相同的请求直接命中缓存不重复调用模型用小模型简单的分类和提取任务不需要最强的模型换小模型能省一大笔精简上下文历史对话定期做摘要而不是每次都把全部内容塞进去批量处理异步任务集中调 API有些平台对批量请求有折扣。延迟同样是个问题。大模型生成是逐 token 输出的长回答意味着高延迟。如果产品对响应速度有要求就得用流式输出让用户看到逐字生成的效果或者限制输出长度。做实时交互类应用还要考虑模型选择的平衡更强的模型通常更慢也更贵。我的原则很简单先明确这个任务需要多强的模型能力再选最便宜的那个而不是一上来就上旗舰模型。4. 效果不稳定是常态上下文管理与评估体系4.1 上下文窗口不是越大越好现在模型支持的上下文窗口越来越大但实际使用中我们发现窗口大不代表效果好。模型对中间部分内容的关注度往往不如开头和结尾这就是社区里常说的“lost in the middle”现象。你塞进去 10 万字资料模型可能只盯着前面和最后的部分看中间的关键信息反而被忽略。所以在设计应用时我的原则是“能不放就不放”。需要模型处理长文档优先考虑分段处理、逐段回答而不是把全文都塞进上下文。需要模型做全局判断的先做内容摘要再基于摘要做决策。这个原则能同时提升效果和降低成本是一举两得的事情。另一个跟上下文相关的问题是历史对话的管理。长时间对话中早期信息会逐渐被挤出上下文窗口模型开始“忘记”用户说过的偏好。社区的常见做法是做记忆摘要每隔几轮对话把前面的内容总结成一段摘要保存在系统提示词里。这样既能保留关键信息又不占用太多上下文空间。我实践下来这个方案比单纯加大窗口效果好得多尤其适合客服和助手类产品。4.2 评估集LLM 应用开发的隐形基础设施这是我最想强调的一点。很多团队做 LLM 应用改了一版 prompt 之后凭感觉说“好像变好了”然后上线然后出问题。正确的做法是建评估集。评估集就是一批经过人工标注的测试用例一份输入、一份期望输出或者期望行为描述。每次修改 prompt、调整检索逻辑、更换模型都用同一套评估集跑一遍对比效果变化。这样你才能知道一次改动到底是变好了还是变坏了。我在实际项目里建评估集的做法是这样的收集线上真实用户的问题挑覆盖面广的 50 到 100 条为每条问题标注期望的答案要点核心内容要覆盖但不要求逐字一致跑评估脚本用大模型当裁判给回答打分每次改动后跑一遍记录分数变化这套流程听上去笨重但能帮你避免大量无效的“调 prompt”工作。没有评估集你的每次优化都是一次赌博。我见过最典型的例子一个团队调了一版 prompt肉眼看了五六个例子觉得不错就上线了结果线上差评率反而升高回滚之后才发现新 prompt 在特定类型的问法上全挂了。有了评估集这类问题在部署前就能被拦住。4.3 幻觉处理的现实手段幻觉是大模型应用的永恒话题。模型一本正经地胡编乱造这在客服、医疗、法律等场景里是不可接受的。RAG 架构能把幻觉率降下来但降不到零。实践中我处理的维度有三个。输入侧约束在 prompt 里明确告诉模型“只能基于给出的资料回答资料里没有的信息要明确说不知道”。检索侧优化提高检索质量让模型有足够的相关资料可依。输出侧校验对关键事实做二次校验比如生成的内容里如果包含具体数字、日期、人名用规则或另一个模型调用做核对。需要清醒认识到的是幻觉无法完全消除。所以在产品设计上要给用户留出确认的环节——提供引用来源、显示回答的置信度、在关键决策场景引入人工审核。这些不是妥协而是负责任的做法。用户对 LLM 应用的信任往往建立在这些细节之上。一个能明确说“我不知道”并给出相关资料链接的助手比一个每次都自信满满但偶尔出错的助手更让人放心。5. 垂直领域 LLM 应用数据准备才是重头戏5.1 通用模型做垂直任务的三种路线聊完通用应用再聊垂直领域。很多人做 LLM 应用做到一定阶段会发现通用模型对行业知识的理解不够深比如法律模型分不清法条和司法解释的关系医疗模型容易把症状和诊断混为一谈。这时候有三条路线可选提示词路线把行业规则、术语表、示例写进 prompt让模型按规则输出。成本最低但效果受限于上下文长度RAG 路线把行业文档、规范、历史案例做成知识库通过检索增强模型回答。适合知识密集型场景微调路线用行业数据对模型做继续训练让模型本身的“知识”和“行为习惯”都变得行业化。成本最高但效果最彻底这三条路线可以组合使用。我见过比较成功的垂直领域应用通常是“微调打底加 RAG 补充实时知识加 prompt 约束输出格式”的组合拳。微调让模型具备行业语言能力RAG 让它拿到最新的领域资料prompt 则保证输出形式符合业务要求。5.2 数据准备的具体做法很多团队一上来就想微调但忽略了一个事实微调的效果很大程度上取决于数据的质量而不是数量。垂域 LLM 数据准备是有方法论可循的。第一步是数据清洗。原始行业数据往往包含大量噪音格式混乱的表格、重复文本、错误标注、个人信息等。清洗至少要过几关去重、格式规范化、敏感信息打码、低质量样本过滤。这一步不做好后面所有环节都会受到影响。第二步是构造指令数据。微调需要的是“指令加输入加输出”结构化的数据但原始数据通常是文档、工单、日志不会天然是这个格式。需要花大量人力把原始数据转写成指令形式。这一步非常耗人我见过一个医疗项目光是把病历转写成问答对就花了三个人两周时间。这个环节偷不得懒但可以借助一个初版的大模型先做一轮转换再由人工校对能省下不少时间。第三步是质量控制。指令数据的质量直接决定微调效果的天花板。常见的做法是做交叉审核每一条指令数据至少两个人标注不一致的重新讨论。过程很枯燥但偷懒的话后面模型的效果会成倍地还回来。5.3 微调之外更轻量的方案微调门槛高、周期长。对于大部分团队来说先做 RAG 是更务实的选择。RAG 对数据的处理要求没那么高不需要构造指令对只要把文档切块、向量化、入库就行缺点是检索质量决定应用效果需要花时间调试。我的建议是这样一个推进节奏先用 RAG 把产品跑起来积累真实用户问题用这些真实问题构造评估集当 RAG 效果触顶、评估集也足够大的时候再上微调。这个顺序能避免“一上来就微调结果数据质量不行、效果比基座模型还差”的尴尬。关于预训练和微调的损失函数设计这是模型训练层的专业话题。做应用层开发的人不需要完全理解所有细节但至少要知道微调阶段用的是交叉熵损失目标是让模型学会对齐指令和答案预训练的损失函数决定了模型从零开始学习语言的能力。对应用开发者来说理解到这一层就够了不必陷进去。真正需要投入精力的永远是数据准备和效果评估这两件事。6. 给想入局的人一条可复制的学习路径6.1 先会用再懂原理接触 LLM 应用开发我的建议是不要一上来就啃论文。先把模型 API 用好跑通一个最简单的对话应用理解 prompt、上下文、temperature、max_tokens 这些概念。这个过程快的话几天就能完成但能帮你建立最基本的手感。然后学 RAG搭一个本地知识库问答系统自己准备文档、切块、向量化、检索、生成。在这个过程里你自然会对 embedding 模型、向量数据库、召回率这些概念有直观认识。RAG 是现在落地最多的技术栈学会它基本就能应对大多数业务需求。再往后才是 Agent 和微调。Agent 需要你理解工具调用的协议和设计模式微调需要你理解训练数据的构造和训练流程。这两个方向都不是必须的根据你的业务需要再深入。LLM 的原理可以边做边补比如你用到上下文窗口了再去读关于注意力机制的文章理解会更深刻也不会觉得枯燥。6.2 动手项目怎么选学习 LLM 应用开发动手很关键但不建议从零开始造轮子。我的做法是先找 awesome-llm-apps 清单里的一个项目把它完全跑起来然后改造一个小功能。比如清单里有个知识库问答项目你跑通之后把它的文档换成你的业务文档再调整一下 prompt这就是一个属于你的应用了。更进一步的练手方向有两个。一个是做个人知识库助手把笔记、资料、收藏的文章整理成知识库做一个能问答的助手。这个项目麻雀虽小五脏俱全RAG 的所有关键环节都能练到。另一个是做一个简单的 Agent定义两三个工具比如查天气、做算术、搜索信息让模型学会在对话中调用工具完成任务。跑通这个你对 function calling 的理解会比看十篇文章都深。这两个项目做完你已经具备独立开发一个 LLM 应用的基本能力了。剩下的就是在实际业务场景里积累经验处理那些文档里不会写到的边界情况。6.3 持续跟进生态的节奏LLM 生态变化太快保持跟进本身就是一种能力。我的习惯是每天花固定时间扫一遍技术社区的热点重点关注三类信息新模型发布和能力评测判断哪些新能力可以用来改进现有应用重要框架和工具的版本更新比如 agent 框架、RAG 框架的迭代方向高质量的实践案例和踩坑总结这类内容往往比官方文档更有价值需要提醒的是不要每个新概念都追。LLM 领域热词层出不穷但很多概念换个说法就是旧东西。判断一个方向值不值得投入我的标准是它有没有解决真实问题、有没有案例验证过、有没有稳定可用的实现。三个都满足才值得花时间研究。最后分享一个我自己的体会做 LLM 应用最忌讳的是把模型当成无所不能的魔法。模型确实很强但它强在语言理解和生成弱在准确性和稳定性。一个成熟的应用架构永远是在发挥模型的长处的同时用工程手段补上它的短板——要么用检索约束事实要么用工作流控制流程要么用评估体系守住质量线。模型更新换代很快但你围绕业务构建的数据、评估方法和工程框架才是真正会随时间沉淀下来的资产。