1. 开门见山awesome-llm-apps 到底是个什么东西第一次看到 awesome-llm-apps 这个项目名很多人会以为它又是一个堆链接的收藏夹。实际上它更像是一张 LLM 应用开发的藏宝图把散落在各个框架、教程和论文里的落地案例按场景整理成可以直接跑通的代码示例。我前后刷了三遍每次都有新收获今天想把它拆开聊一聊。从名字就能看出来这是一个典型 awesome 系列项目。GitHub 上一堆 awesome-xxx 的资源汇总质量参差不齐。但 awesome-llm-apps 不太一样它不满足于只列链接而是把每个应用的代码、流程、依赖和 README 都整理得相对完整。换句话说它不是告诉你“世界上有这个项目”而是告诉你“这个项目是怎么做出来的”甚至给你可以直接复制下来跑的代码。这一点在 LLM 应用扎堆冒出头的阶段价值非常高。它解决的问题也很直接大模型 API 谁都会调但真正把 LLM 变成产品中间隔着一大堆工程细节。文档怎么切、记忆怎么存、工具怎么调、报错怎么排、成本怎么控这些靠官方文档往往学不到而 awesome-llm-apps 用大量实例把这些问题摆到了你面前。适合三类人看刚入门、想快速做出第一个 LLM demo 的开发者已经调过 API、但不知道怎么把聊天机器人做成完整产品的工程师以及做技术选型、想了解市面上常见大模型应用形态的产品和技术管理者。2. 这类项目为什么值得反复刷一个 repo 背后的 LLM 应用全景图2.1 它不只是收藏夹更是“需求-方案”对照表很多初学者收藏了一堆 awesome 列表结果真正用上的没几个。原因很简单收藏夹里的东西是死的没有明确的使用场景。awesome-llm-apps 给了我另一种视角它本质上是一张“需求-方案”对照表。每个 demo 背后都对应一个具体的业务问题客服问答、文档总结、Excel 数据处理、语音助手、代码审查……当你脑子里有“我想用大模型做 XX”这个念头时去里面一搜大概率能找到别人已经做过的尝试。这种对照关系很重要因为 LLM 应用开发最大的难点不是模型能力不够而是“不知道怎么把模糊的想法拆成可执行的步骤”。看到一个和你业务相似的案例你至少能回答三个问题这个应用需要哪些输入中间经过了哪些处理最终输出是什么想清楚这三个问题项目就成功了一半。2.2 七种最常见的 LLM 应用形态刷一遍 awesome-llm-apps你会发现大部分应用跑不出下面这张表。应用形态解决的核心问题典型技术组件对话助手多轮聊天、客服问答LLM API、对话记忆、意图识别RAG 知识库问答基于私有文档问答文档加载、切分、向量化、检索、重排Agent 自主任务让模型调用工具完成多步操作函数调用、ReAct、工具调度、任务规划多模态应用看图说话、图片理解、语音交互视觉模型、语音识别、多模态输入处理代码生成与审查补全代码、解释代码、自动修 bug代码模型、静态分析工具、沙箱执行自动化工作流把重复性劳动做成流水线定时任务、事件触发、API 编排垂直场景工具润色、翻译、摘要、分类Prompt 模板、结构化输出、批处理框架我建议你把这张表当成一个检查清单。如果你做过 LLM 应用可以对照看看自己接触过其中几种如果只做过单一的对话机器人那下一步自然就知道该往哪个方向扩展了。2.3 每个 demo 背后都是三层功夫模型、编排、工程很多人看 demo 只看表面的 AI 效果这其实远远不够。一个完整的 LLM 应用从上到下至少有三层模型层、编排层和工程层。模型层负责“智力”比如你到底用 GPT、Claude还是开源的 Qwen、Llama决定能力天花板编排层负责“手脚”比如用 LangChain、LlamaIndex 还是自己手写流程把模型、检索、记忆、工具串起来工程层负责“运维”比如 API 网关、缓存、日志、限流、成本监控、灰度发布决定这个应用能不能稳定跑在线上。awesome-llm-apps 里很多案例的代码并不复杂但你把这三层拆开看就会发现每一个示例都在告诉你模型可以换编排方式可以选工程手段不能少。真正到生产环境第三层的分量比前两层加起来还要重。3. 拆解 LLM 应用的核心技术点从 demo 到能用的关键细节3.1 Prompt 工程不是写话术是定义接口我见过不少初学者把 Prompt 当成“哄模型说话的话术”这其实是个误区。在真实项目里Prompt 更像是一份接口文档它需要约定输入格式、输出格式、约束条件和边界情况。写得好模型稳定输出写得随便线上事故不断。一个结构完整的 Prompt 通常包含四部分角色设定、任务描述、输入数据、输出格式。角色设定告诉模型“你是谁”任务描述告诉模型“你要干什么”输入数据是动态传入的内容输出格式决定了你能不能稳定解析结果。尤其是需要程序自动处理结果时一定要让模型输出 JSON并在 Prompt 里给一个具体的 schema 示例。system_prompt 你是一个代码优化助手。请根据下面给定的代码片段输出优化建议。 要求 1. 只输出 JSON不要输出任何解释性文字。 2. JSON 结构如下 { issues: [问题描述1, 问题描述2], suggestion: 整体优化建议 } user_prompt f这是用户提交的代码\n{code_content}这里有个关键参数temperature。如果你做的是客服问答这类追求稳定输出的场景temperature 建议调到 0 到 0.3如果是写文案、头脑风暴再考虑调高到 0.7 以上。我见过好几个人温度不调结果同一套 Prompt 每次返回的 JSON 结构都不一致解析代码直接崩溃。3.2 RAG把知识库接进来难点在召回RAG检索增强生成是当前企业级 LLM 应用里最常用的方案原因是它能在不大规模微调模型的情况下让模型“知道”私有知识。原理讲起来很简单把文档切块向量化存到向量数据库里用户提问时先检索最相关的片段再把片段塞进 Prompt 让模型回答。但真正动手做难点全在召回质量。文档怎么切直接影响检索效果。切太碎语义不完整切太长混入无关信息还浪费 token。我常用的策略是普通说明文按 500 到 800 个 token 切代码或表格类内容按结构块切切的时候用 50 到 100 个 token 的重叠减少断句切断语义。还有一点很容易被忽略中文场景下向量模型的选择很关键。通用英文 embedding 模型对中文支持参差不齐建议先用中文评测集跑一下召回率再决定用哪个。如果预算允许可以在检索后面加一个 rerank 重排模型它能大幅提升排在前面的结果相关性。实操下来加了 rerank 之后的效果提升往往比换更大的模型更明显。3.3 Agent模型做决策但边界要人定Agent 是 LLM 应用里最吸引人的方向也是翻车重灾区。它的核心思路是模型不直接返回最终答案而是先判断需要调用哪个工具再根据工具返回结果继续推理直到完成任务。这种“思考-行动-观察”循环通常被称为 ReAct 模式也被很多框架包装成“Agent”。我的看法是Agent 可以类比成一位实习生能力很强但需要你给清晰的边界。你用 Prompt 告诉它有哪些工具、每个工具怎么用、什么时候该用但别指望它每次都做出正确判断。所以工程上必须加限制工具数量不要太多单个工具的描述要足够清晰关键操作加人工确认设置最大循环次数防止死循环。举个实际例子我做过一个信息整合 Agent最初给了它 8 个工具结果它经常在“查询 A-查询 B-再查 A”之间打转浪费大量 token。后来我把工具精简到 4 个并且在系统 Prompt 里加了一句“如果已获得必要信息请立即给出最终答案”情况立刻好转。Agent 不是工具越多越聪明而是边界越清晰越可控。3.4 工具调用与结构化输出工具调用Function Calling是现代 LLM API 最实用的能力之一。它让模型能够按照预先定义的函数签名输出结构化的调用参数从而真正操作外部系统。这个能力比单纯让模型“吐出 JSON”可靠得多因为 API 层面的参数约束已经被模型专门训练过。tools [ { type: function, function: { name: search_hotel, description: 根据城市和日期搜索可用酒店, parameters: { type: object, properties: { city: {type: string, description: 城市名}, check_in: {type: string, description: 入住日期格式 YYYY-MM-DD}, check_out: {type: string, description: 离店日期格式 YYYY-MM-DD} }, required: [city, check_in, check_out] } } } ]使用工具调用时有几个细节需要特别留意。第一函数描述要写清楚因为模型靠描述来匹配用户意图第二返回结果里最好同时包含原始数据和可读性摘要方便模型生成最终回复第三一定要做好异常兜底模型可能传空参数、非法日期甚至捏造函数名参数校验必须放在应用层不能只靠模型“自觉”。3.5 记忆与上下文管理多轮对话一旦超过上下文窗口就会出现两种情况要么 API 直接报错要么模型“忘记”了前面的内容。解决这个问题核心是建立一套记忆管理机制。最朴素的方案是滑动窗口只保留最近 N 轮对话最老的对话被丢弃。简单有效但会丢失早期关键信息。稍微复杂一点的是摘要记忆每当对话超过一定长度就调用一次模型把前面的内容总结成几句摘要始终把摘要放在最前面。再进阶一点的是向量记忆把每轮对话向量化存入向量库每次提问时按相似度召回相关历史。在 awesome-llm-apps 这类项目里你能看到不同记忆方案的实现。我个人的经验是不要一开始就上复杂的记忆架构先用滑动窗口跑通流程等发现“模型需要记住更多内容”时再针对具体场景加摘要或向量记忆。提前把架构设计得很复杂只会让你调试成本翻倍。3.6 评估没有 eval一切都是玄学这是我踩了很久才真正明白的道理一个 LLM 应用好不好用不能靠感觉必须建立评估集和评估指标。每次改 Prompt、换模型、调参数都需要同一套测试问题来验证否则你根本不知道改动是变好了还是变坏了。最小可行的评估方案分三步。第一步整理 30 到 100 条真实用户问题覆盖正常提问、边界提问和恶意提问第二步对每条问题记录预期答案或关键点第三步跑一轮把模型的输出和预期答案对比人工看一遍准确率。这听起来很原始但足够撑起项目初期的质量保障。等规模大了可以引入 LLM as judge也就是让另一个大模型给回答打分。不过要记住自动评估只能辅助不能替代人工判断。尤其涉及安全、伦理、准确性的场景最后一道闸门必须是人。4. 实操把一个 awesome 示例改造成自己的应用4.1 选型先抄作业再改作业看再多 demo不如动手改一个。我建议你的第一步是从 awesome-llm-apps 里挑一个跟当前业务最接近的应用先把原版跑通再逐步改成自己的。选型标准有三条。第一看技术栈是否熟悉如果你从来没写过 Python就别选依赖大量异步代码的案例第二看依赖是否复杂尽量选只依赖两三个核心库的项目避免还没跑起来就先被环境问题劝退第三看许可证和代码质量awesome 列表里的项目质量参差不齐优先选 Star 多、README 清晰、有测试用例的。跑通原版之后不要急着大改。先做两件小事把硬编码的 API Key 挪到环境变量把模型版本参数提出来作为配置。这一步虽然简单但能让后面替换模型、调参数时轻松很多也更接近生产应用的工程习惯。4.2 从零搭一个最小可用的知识库问答助手为了讲得更具体我直接演示一个最小知识库问答助手的搭建过程。技术栈选 Python LangChain Chroma 向量库数据用几篇 FAQ 文档。这套方案跑起来快也方便后面扩展。# requirements.txt # langchain # langchain-openai # chromadb # openai from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_chroma import Chroma from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI # 1. 加载文档 loader TextLoader(faq.txt, encodingutf-8) documents loader.load() # 2. 切分文档 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) docs splitter.split_documents(documents) # 3. 向量化并存储 embeddings OpenAIEmbeddings() vectorstore Chroma.from_documents(docs, embeddings) # 4. 构建问答链 llm ChatOpenAI(modelgpt-4o-mini, temperature0) qa_chain RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}) ) # 5. 提问 result qa_chain.invoke({query: 退货流程是什么}) print(result[result])这段代码每一步都有讲究。文档切分时我特意加了中文标点作为分隔符是为了避免一句话被拦腰截断retriever 里的“k4”表示召回 top 4 个片段太少可能漏信息太多则浪费 token实际场景需要根据文档内容调整最后一步用temperature0是为了让回答尽可能稳定。跑通之后你可以在外面套一层 Gradio 或 Streamlit几分钟就能得到一个带界面的问答助手。这个“最小闭环”虽然简陋但已经包含了一个完整 RAG 应用的所有核心环节后续所有优化都是在这个基础上叠加。4.3 从“能跑”到“好用”的三步演进第一个版本跑通后千万不要停在那里接下来按三步优化每一步都对应一个真实痛点。第一步加入来源引用。把召回出的文档片段和对应文件名一起传给模型并要求它在回答末尾附上来源编号。用户看到答案有出处信任度会提高很多你自己排查问题时也能很快定位是检索错了还是生成错了。第二步增加重排。召回 20 个候选片段用 rerank 模型重排后只保留 top 4 个送入 Prompt。这一步能明显提升答案的精准度代价是增加一点延迟和成本但在大多数业务场景下完全值得。第三步收集用户反馈。在界面加“赞同”“反对”按钮把负面反馈连同当时的 Prompt 和上下文落库。之后每周看一次失败样本你会惊讶地发现大部分问题不是模型不够聪明而是文档本身写得不清楚或者切分策略有缺陷。这时再针对性地改文档、调 Prompt效率远高于盲目升级模型。5. 从 repo 到生产避坑清单与调试经验5.1 常见问题速查表我把实际开发中遇到的典型问题整理成一张速查表基本涵盖 LLM 应用从开发到上线的主要坑点。问题可能原因排查方法建议解法输出格式不稳定未约定 schema、temperature 过高连续调用多次观察输出在 Prompt 中给示例、开 JSON mode、降低 temperature回答与资料不符召回不准确、chunk 切分不合理打印召回的上下文片段调整切分策略、加 rerank、检查文档质量对话到一半忘事无记忆或上下文超限被截断查看每次请求的 token 数和消息列表引入滑动窗口或摘要记忆中文检索效果差embedding 模型对中文支持弱用中文测试集跑召回率换中英双语 embedding 模型按中文标点切分API 调用变慢Prompt 过长、并发不足看耗时分布和日志精简 Prompt、异步调用、加连接池成本快速上升每轮都传入大量历史、无缓存统计 token 消耗记忆裁剪、语义缓存、用小模型处理简单任务5.2 成本、延迟与稳定性LLM 应用上线后最容易被低估的是成本尤其是 RAG 和 Agent 场景。RAG 每问一个问题除了最终生成回答消耗的 token还有检索、重排、多次模型调用的开销Agent 更厉害一次任务可能触发十几轮工具调用费用成倍增长。我的做法是分三层控成本。第一层在模型侧简单分类、信息抽取优先用便宜小模型复杂推理才用大模型甚至可以做一个“路由层”按问题难度分发模型。第二层在缓存侧相同或相似问题直接命中缓存不重复调用模型语义缓存可以用向量相似度判断相似度超过阈值的直接复用旧答案。第三层在工程侧给每个用户、每个 API Key 设置配额超限自动降级到小模型或静态答案防止恶意刷量打爆预算。与此同时稳定性不能放松。LLM API 偶尔会超时或返回 5xx代码里必须做超时控制和指数退避重试。重试次数建议 3 次以内单次超时控制在业务可接受范围内。如果让用户长时间转圈等待即使最终成功体验也已经失败了。5.3 我踩过的三个坑第一个坑以为向量化是万能的。早期做知识库问答时我把一份几十页的产品手册直接扔进切分器向量化之后就让模型回答。结果一问细节就胡说八道。后来把那部分召回上下文打印出来才发现切出来的 chunk 把表格拆得七零八落关键数据全丢失了。从那以后我养成了先看“模型到底拿到了什么”再调功能的习惯。第二个坑把所有逻辑都塞进 system prompt。有一段时间我图省事想让一个模型同时做意图分类、信息抽取和文案生成于是把三种任务的说明全写在 system prompt 里。测试时发现模型要么漏做任务要么输出格式错乱。后来我把这三个任务拆成三次模型调用或者用工具调用分别路由问题立刻解决。模型擅长专注做一件事别让它一心多用。第三个坑没做并发控制。上线一个内部工具时我没给用户操作加锁结果有人连续点了几次按钮瞬间发了几十个并发请求直接触发 API 限流还连累其他服务一起超时。现在我在所有外部 API 调用前面都加了一层队列或信号量宁可排队也不能打爆上游。5.4 安全与合规的底线做 LLM 应用安全不是加分项是底线。第一不要把未脱敏的隐私数据直接发给外部 API能本地处理就本地处理必须用云端模型时先做字段脱敏敏感行业建议部署私有化模型。第二用户输入本身可能是攻击载荷。系统 Prompt 再怎么强调“你是助手”也拦不住恶意用户尝试套取内部指令。所以涉及敏感操作时不要把用户输入直接拼进可执行命令也不要把工具权限暴露给不可信角色。第三内容侧要有熔断机制。在线应用必须接内容审核检测到违规内容直接拒绝返回离线批处理场景也要保留人工抽检环节。所有这些不仅是为了合规更是为了不让一个不可控的 Bug 把整个产品拖下水。最后再分享一点个人经验我在刷 awesome-llm-apps 的时候会拿一张自己的 LLM 应用检查清单去对照模型边界、数据召回、输出解析、兜底逻辑、用户反馈、成本监控。看到某个 demo 实现了清单里我没做的一块就会花一个周末把它移植进自己的项目。后来发现真正让我成长的不是收藏了多少项目而是拆了多少项目。建议你也挑一个最贴近业务的示例先改一版数据结构再换一个使用场景别怕把它改得不好看。改过一遍这个项目才是你的。 awesome-llm-apps实战指南：从LLM应用到RAG与Agent开发
1. 开门见山awesome-llm-apps 到底是个什么东西第一次看到 awesome-llm-apps 这个项目名很多人会以为它又是一个堆链接的收藏夹。实际上它更像是一张 LLM 应用开发的藏宝图把散落在各个框架、教程和论文里的落地案例按场景整理成可以直接跑通的代码示例。我前后刷了三遍每次都有新收获今天想把它拆开聊一聊。从名字就能看出来这是一个典型 awesome 系列项目。GitHub 上一堆 awesome-xxx 的资源汇总质量参差不齐。但 awesome-llm-apps 不太一样它不满足于只列链接而是把每个应用的代码、流程、依赖和 README 都整理得相对完整。换句话说它不是告诉你“世界上有这个项目”而是告诉你“这个项目是怎么做出来的”甚至给你可以直接复制下来跑的代码。这一点在 LLM 应用扎堆冒出头的阶段价值非常高。它解决的问题也很直接大模型 API 谁都会调但真正把 LLM 变成产品中间隔着一大堆工程细节。文档怎么切、记忆怎么存、工具怎么调、报错怎么排、成本怎么控这些靠官方文档往往学不到而 awesome-llm-apps 用大量实例把这些问题摆到了你面前。适合三类人看刚入门、想快速做出第一个 LLM demo 的开发者已经调过 API、但不知道怎么把聊天机器人做成完整产品的工程师以及做技术选型、想了解市面上常见大模型应用形态的产品和技术管理者。2. 这类项目为什么值得反复刷一个 repo 背后的 LLM 应用全景图2.1 它不只是收藏夹更是“需求-方案”对照表很多初学者收藏了一堆 awesome 列表结果真正用上的没几个。原因很简单收藏夹里的东西是死的没有明确的使用场景。awesome-llm-apps 给了我另一种视角它本质上是一张“需求-方案”对照表。每个 demo 背后都对应一个具体的业务问题客服问答、文档总结、Excel 数据处理、语音助手、代码审查……当你脑子里有“我想用大模型做 XX”这个念头时去里面一搜大概率能找到别人已经做过的尝试。这种对照关系很重要因为 LLM 应用开发最大的难点不是模型能力不够而是“不知道怎么把模糊的想法拆成可执行的步骤”。看到一个和你业务相似的案例你至少能回答三个问题这个应用需要哪些输入中间经过了哪些处理最终输出是什么想清楚这三个问题项目就成功了一半。2.2 七种最常见的 LLM 应用形态刷一遍 awesome-llm-apps你会发现大部分应用跑不出下面这张表。应用形态解决的核心问题典型技术组件对话助手多轮聊天、客服问答LLM API、对话记忆、意图识别RAG 知识库问答基于私有文档问答文档加载、切分、向量化、检索、重排Agent 自主任务让模型调用工具完成多步操作函数调用、ReAct、工具调度、任务规划多模态应用看图说话、图片理解、语音交互视觉模型、语音识别、多模态输入处理代码生成与审查补全代码、解释代码、自动修 bug代码模型、静态分析工具、沙箱执行自动化工作流把重复性劳动做成流水线定时任务、事件触发、API 编排垂直场景工具润色、翻译、摘要、分类Prompt 模板、结构化输出、批处理框架我建议你把这张表当成一个检查清单。如果你做过 LLM 应用可以对照看看自己接触过其中几种如果只做过单一的对话机器人那下一步自然就知道该往哪个方向扩展了。2.3 每个 demo 背后都是三层功夫模型、编排、工程很多人看 demo 只看表面的 AI 效果这其实远远不够。一个完整的 LLM 应用从上到下至少有三层模型层、编排层和工程层。模型层负责“智力”比如你到底用 GPT、Claude还是开源的 Qwen、Llama决定能力天花板编排层负责“手脚”比如用 LangChain、LlamaIndex 还是自己手写流程把模型、检索、记忆、工具串起来工程层负责“运维”比如 API 网关、缓存、日志、限流、成本监控、灰度发布决定这个应用能不能稳定跑在线上。awesome-llm-apps 里很多案例的代码并不复杂但你把这三层拆开看就会发现每一个示例都在告诉你模型可以换编排方式可以选工程手段不能少。真正到生产环境第三层的分量比前两层加起来还要重。3. 拆解 LLM 应用的核心技术点从 demo 到能用的关键细节3.1 Prompt 工程不是写话术是定义接口我见过不少初学者把 Prompt 当成“哄模型说话的话术”这其实是个误区。在真实项目里Prompt 更像是一份接口文档它需要约定输入格式、输出格式、约束条件和边界情况。写得好模型稳定输出写得随便线上事故不断。一个结构完整的 Prompt 通常包含四部分角色设定、任务描述、输入数据、输出格式。角色设定告诉模型“你是谁”任务描述告诉模型“你要干什么”输入数据是动态传入的内容输出格式决定了你能不能稳定解析结果。尤其是需要程序自动处理结果时一定要让模型输出 JSON并在 Prompt 里给一个具体的 schema 示例。system_prompt 你是一个代码优化助手。请根据下面给定的代码片段输出优化建议。 要求 1. 只输出 JSON不要输出任何解释性文字。 2. JSON 结构如下 { issues: [问题描述1, 问题描述2], suggestion: 整体优化建议 } user_prompt f这是用户提交的代码\n{code_content}这里有个关键参数temperature。如果你做的是客服问答这类追求稳定输出的场景temperature 建议调到 0 到 0.3如果是写文案、头脑风暴再考虑调高到 0.7 以上。我见过好几个人温度不调结果同一套 Prompt 每次返回的 JSON 结构都不一致解析代码直接崩溃。3.2 RAG把知识库接进来难点在召回RAG检索增强生成是当前企业级 LLM 应用里最常用的方案原因是它能在不大规模微调模型的情况下让模型“知道”私有知识。原理讲起来很简单把文档切块向量化存到向量数据库里用户提问时先检索最相关的片段再把片段塞进 Prompt 让模型回答。但真正动手做难点全在召回质量。文档怎么切直接影响检索效果。切太碎语义不完整切太长混入无关信息还浪费 token。我常用的策略是普通说明文按 500 到 800 个 token 切代码或表格类内容按结构块切切的时候用 50 到 100 个 token 的重叠减少断句切断语义。还有一点很容易被忽略中文场景下向量模型的选择很关键。通用英文 embedding 模型对中文支持参差不齐建议先用中文评测集跑一下召回率再决定用哪个。如果预算允许可以在检索后面加一个 rerank 重排模型它能大幅提升排在前面的结果相关性。实操下来加了 rerank 之后的效果提升往往比换更大的模型更明显。3.3 Agent模型做决策但边界要人定Agent 是 LLM 应用里最吸引人的方向也是翻车重灾区。它的核心思路是模型不直接返回最终答案而是先判断需要调用哪个工具再根据工具返回结果继续推理直到完成任务。这种“思考-行动-观察”循环通常被称为 ReAct 模式也被很多框架包装成“Agent”。我的看法是Agent 可以类比成一位实习生能力很强但需要你给清晰的边界。你用 Prompt 告诉它有哪些工具、每个工具怎么用、什么时候该用但别指望它每次都做出正确判断。所以工程上必须加限制工具数量不要太多单个工具的描述要足够清晰关键操作加人工确认设置最大循环次数防止死循环。举个实际例子我做过一个信息整合 Agent最初给了它 8 个工具结果它经常在“查询 A-查询 B-再查 A”之间打转浪费大量 token。后来我把工具精简到 4 个并且在系统 Prompt 里加了一句“如果已获得必要信息请立即给出最终答案”情况立刻好转。Agent 不是工具越多越聪明而是边界越清晰越可控。3.4 工具调用与结构化输出工具调用Function Calling是现代 LLM API 最实用的能力之一。它让模型能够按照预先定义的函数签名输出结构化的调用参数从而真正操作外部系统。这个能力比单纯让模型“吐出 JSON”可靠得多因为 API 层面的参数约束已经被模型专门训练过。tools [ { type: function, function: { name: search_hotel, description: 根据城市和日期搜索可用酒店, parameters: { type: object, properties: { city: {type: string, description: 城市名}, check_in: {type: string, description: 入住日期格式 YYYY-MM-DD}, check_out: {type: string, description: 离店日期格式 YYYY-MM-DD} }, required: [city, check_in, check_out] } } } ]使用工具调用时有几个细节需要特别留意。第一函数描述要写清楚因为模型靠描述来匹配用户意图第二返回结果里最好同时包含原始数据和可读性摘要方便模型生成最终回复第三一定要做好异常兜底模型可能传空参数、非法日期甚至捏造函数名参数校验必须放在应用层不能只靠模型“自觉”。3.5 记忆与上下文管理多轮对话一旦超过上下文窗口就会出现两种情况要么 API 直接报错要么模型“忘记”了前面的内容。解决这个问题核心是建立一套记忆管理机制。最朴素的方案是滑动窗口只保留最近 N 轮对话最老的对话被丢弃。简单有效但会丢失早期关键信息。稍微复杂一点的是摘要记忆每当对话超过一定长度就调用一次模型把前面的内容总结成几句摘要始终把摘要放在最前面。再进阶一点的是向量记忆把每轮对话向量化存入向量库每次提问时按相似度召回相关历史。在 awesome-llm-apps 这类项目里你能看到不同记忆方案的实现。我个人的经验是不要一开始就上复杂的记忆架构先用滑动窗口跑通流程等发现“模型需要记住更多内容”时再针对具体场景加摘要或向量记忆。提前把架构设计得很复杂只会让你调试成本翻倍。3.6 评估没有 eval一切都是玄学这是我踩了很久才真正明白的道理一个 LLM 应用好不好用不能靠感觉必须建立评估集和评估指标。每次改 Prompt、换模型、调参数都需要同一套测试问题来验证否则你根本不知道改动是变好了还是变坏了。最小可行的评估方案分三步。第一步整理 30 到 100 条真实用户问题覆盖正常提问、边界提问和恶意提问第二步对每条问题记录预期答案或关键点第三步跑一轮把模型的输出和预期答案对比人工看一遍准确率。这听起来很原始但足够撑起项目初期的质量保障。等规模大了可以引入 LLM as judge也就是让另一个大模型给回答打分。不过要记住自动评估只能辅助不能替代人工判断。尤其涉及安全、伦理、准确性的场景最后一道闸门必须是人。4. 实操把一个 awesome 示例改造成自己的应用4.1 选型先抄作业再改作业看再多 demo不如动手改一个。我建议你的第一步是从 awesome-llm-apps 里挑一个跟当前业务最接近的应用先把原版跑通再逐步改成自己的。选型标准有三条。第一看技术栈是否熟悉如果你从来没写过 Python就别选依赖大量异步代码的案例第二看依赖是否复杂尽量选只依赖两三个核心库的项目避免还没跑起来就先被环境问题劝退第三看许可证和代码质量awesome 列表里的项目质量参差不齐优先选 Star 多、README 清晰、有测试用例的。跑通原版之后不要急着大改。先做两件小事把硬编码的 API Key 挪到环境变量把模型版本参数提出来作为配置。这一步虽然简单但能让后面替换模型、调参数时轻松很多也更接近生产应用的工程习惯。4.2 从零搭一个最小可用的知识库问答助手为了讲得更具体我直接演示一个最小知识库问答助手的搭建过程。技术栈选 Python LangChain Chroma 向量库数据用几篇 FAQ 文档。这套方案跑起来快也方便后面扩展。# requirements.txt # langchain # langchain-openai # chromadb # openai from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_chroma import Chroma from langchain.chains import RetrievalQA from langchain_openai import ChatOpenAI # 1. 加载文档 loader TextLoader(faq.txt, encodingutf-8) documents loader.load() # 2. 切分文档 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , , ] ) docs splitter.split_documents(documents) # 3. 向量化并存储 embeddings OpenAIEmbeddings() vectorstore Chroma.from_documents(docs, embeddings) # 4. 构建问答链 llm ChatOpenAI(modelgpt-4o-mini, temperature0) qa_chain RetrievalQA.from_chain_type( llmllm, retrievervectorstore.as_retriever(search_kwargs{k: 4}) ) # 5. 提问 result qa_chain.invoke({query: 退货流程是什么}) print(result[result])这段代码每一步都有讲究。文档切分时我特意加了中文标点作为分隔符是为了避免一句话被拦腰截断retriever 里的“k4”表示召回 top 4 个片段太少可能漏信息太多则浪费 token实际场景需要根据文档内容调整最后一步用temperature0是为了让回答尽可能稳定。跑通之后你可以在外面套一层 Gradio 或 Streamlit几分钟就能得到一个带界面的问答助手。这个“最小闭环”虽然简陋但已经包含了一个完整 RAG 应用的所有核心环节后续所有优化都是在这个基础上叠加。4.3 从“能跑”到“好用”的三步演进第一个版本跑通后千万不要停在那里接下来按三步优化每一步都对应一个真实痛点。第一步加入来源引用。把召回出的文档片段和对应文件名一起传给模型并要求它在回答末尾附上来源编号。用户看到答案有出处信任度会提高很多你自己排查问题时也能很快定位是检索错了还是生成错了。第二步增加重排。召回 20 个候选片段用 rerank 模型重排后只保留 top 4 个送入 Prompt。这一步能明显提升答案的精准度代价是增加一点延迟和成本但在大多数业务场景下完全值得。第三步收集用户反馈。在界面加“赞同”“反对”按钮把负面反馈连同当时的 Prompt 和上下文落库。之后每周看一次失败样本你会惊讶地发现大部分问题不是模型不够聪明而是文档本身写得不清楚或者切分策略有缺陷。这时再针对性地改文档、调 Prompt效率远高于盲目升级模型。5. 从 repo 到生产避坑清单与调试经验5.1 常见问题速查表我把实际开发中遇到的典型问题整理成一张速查表基本涵盖 LLM 应用从开发到上线的主要坑点。问题可能原因排查方法建议解法输出格式不稳定未约定 schema、temperature 过高连续调用多次观察输出在 Prompt 中给示例、开 JSON mode、降低 temperature回答与资料不符召回不准确、chunk 切分不合理打印召回的上下文片段调整切分策略、加 rerank、检查文档质量对话到一半忘事无记忆或上下文超限被截断查看每次请求的 token 数和消息列表引入滑动窗口或摘要记忆中文检索效果差embedding 模型对中文支持弱用中文测试集跑召回率换中英双语 embedding 模型按中文标点切分API 调用变慢Prompt 过长、并发不足看耗时分布和日志精简 Prompt、异步调用、加连接池成本快速上升每轮都传入大量历史、无缓存统计 token 消耗记忆裁剪、语义缓存、用小模型处理简单任务5.2 成本、延迟与稳定性LLM 应用上线后最容易被低估的是成本尤其是 RAG 和 Agent 场景。RAG 每问一个问题除了最终生成回答消耗的 token还有检索、重排、多次模型调用的开销Agent 更厉害一次任务可能触发十几轮工具调用费用成倍增长。我的做法是分三层控成本。第一层在模型侧简单分类、信息抽取优先用便宜小模型复杂推理才用大模型甚至可以做一个“路由层”按问题难度分发模型。第二层在缓存侧相同或相似问题直接命中缓存不重复调用模型语义缓存可以用向量相似度判断相似度超过阈值的直接复用旧答案。第三层在工程侧给每个用户、每个 API Key 设置配额超限自动降级到小模型或静态答案防止恶意刷量打爆预算。与此同时稳定性不能放松。LLM API 偶尔会超时或返回 5xx代码里必须做超时控制和指数退避重试。重试次数建议 3 次以内单次超时控制在业务可接受范围内。如果让用户长时间转圈等待即使最终成功体验也已经失败了。5.3 我踩过的三个坑第一个坑以为向量化是万能的。早期做知识库问答时我把一份几十页的产品手册直接扔进切分器向量化之后就让模型回答。结果一问细节就胡说八道。后来把那部分召回上下文打印出来才发现切出来的 chunk 把表格拆得七零八落关键数据全丢失了。从那以后我养成了先看“模型到底拿到了什么”再调功能的习惯。第二个坑把所有逻辑都塞进 system prompt。有一段时间我图省事想让一个模型同时做意图分类、信息抽取和文案生成于是把三种任务的说明全写在 system prompt 里。测试时发现模型要么漏做任务要么输出格式错乱。后来我把这三个任务拆成三次模型调用或者用工具调用分别路由问题立刻解决。模型擅长专注做一件事别让它一心多用。第三个坑没做并发控制。上线一个内部工具时我没给用户操作加锁结果有人连续点了几次按钮瞬间发了几十个并发请求直接触发 API 限流还连累其他服务一起超时。现在我在所有外部 API 调用前面都加了一层队列或信号量宁可排队也不能打爆上游。5.4 安全与合规的底线做 LLM 应用安全不是加分项是底线。第一不要把未脱敏的隐私数据直接发给外部 API能本地处理就本地处理必须用云端模型时先做字段脱敏敏感行业建议部署私有化模型。第二用户输入本身可能是攻击载荷。系统 Prompt 再怎么强调“你是助手”也拦不住恶意用户尝试套取内部指令。所以涉及敏感操作时不要把用户输入直接拼进可执行命令也不要把工具权限暴露给不可信角色。第三内容侧要有熔断机制。在线应用必须接内容审核检测到违规内容直接拒绝返回离线批处理场景也要保留人工抽检环节。所有这些不仅是为了合规更是为了不让一个不可控的 Bug 把整个产品拖下水。最后再分享一点个人经验我在刷 awesome-llm-apps 的时候会拿一张自己的 LLM 应用检查清单去对照模型边界、数据召回、输出解析、兜底逻辑、用户反馈、成本监控。看到某个 demo 实现了清单里我没做的一块就会花一个周末把它移植进自己的项目。后来发现真正让我成长的不是收藏了多少项目而是拆了多少项目。建议你也挑一个最贴近业务的示例先改一版数据结构再换一个使用场景别怕把它改得不好看。改过一遍这个项目才是你的。