1. 项目概述当LLM开发从“炼丹”走向“工程”最近和几个团队交流发现一个挺有意思的现象大家聊起大语言模型LLM应用开发已经从半年前的“哪个模型效果最好”、“怎么调提示词更灵”逐渐转向了“我们这套RAG流程怎么优化”、“Agent的稳定性怎么保证”、“线上服务怎么压测”。这个转变很有意思它标志着一个领域从早期的技术探索和“玄学”调优开始进入规模化、工程化的深水区。我自己从去年初开始密集投入LLM应用开发从最初的单点提示词优化到构建复杂的多智能体工作流再到如今负责整个应用的生命周期管理踩过的坑、交过的学费不少。今天想和你聊聊的就是这个过程中的核心体会LLM开发远不止是写提示词它至少包含了三个相互交织又各有侧重的工程维度——提示工程、应用工程和平台工程。理解这三个维度对于任何一个想在这个领域深耕的团队或个人都至关重要。它帮你跳出“唯提示词论”的局限看清一个LLM应用从想法到稳定服务的全貌。你会明白为什么一个在本地跑得飞快的Demo一上线就各种幺蛾子为什么别人的Agent能稳定处理复杂任务你的却动不动就“宕机”。这背后是不同工程维度上的认知差距和工具缺失。接下来我们就逐一拆解这三个维度看看它们各自关注什么、用什么工具、解决什么问题以及在实际项目中如何协同工作。2. 第一维度提示工程——从“魔法咒语”到可复用的构建块提示工程是大多数人接触LLM的第一站。它直观、反馈快有点像在和模型“对话”或“下指令”。但早期的提示工程往往停留在“试错”和“玄学”层面缺乏系统性和可复用性。真正的提示工程应该将其视为一种软件工程实践。2.1 核心范式演进从零样本到思维链与程序模拟最初的提示很简单就是零样本Zero-Shot或少量样本Few-Shot的直接问答。但很快大家发现对于复杂任务直接问效果很差。于是思维链Chain-of-Thought, CoT出现了。它的核心是引导模型“一步步思考”把推理过程展示出来。这不仅仅是让答案更准确更重要的是让整个过程变得可调试。你可以看到模型在哪一步“想歪了”从而有针对性地调整提示。但CoT还是线性的、描述性的。更进一步的是程序模拟式提示比如ReActReasoning Acting范式。它要求模型不仅推理还要规划行动如调用工具、搜索信息。这时的提示词更像是在给模型编写一个“剧本”或“工作流描述”。例如一个客服Agent的提示词里会明确包含“首先你需要理解用户的问题属于哪个类别技术故障、账单查询、产品咨询。如果是技术故障请依次询问设备型号、故障现象、出现时间。然后根据知识库检索相关解决方案若没有则告知用户已升级至人工客服。” 这种提示结构化了模型的输出使其行为更可控。注意思维链提示的成功高度依赖于模型本身的推理能力。对于较小的模型如7B参数级别复杂的CoT提示可能反而会导致它“胡思乱想”输出混乱。通常70B参数以上的模型对复杂提示的遵循能力会强得多。在选择范式时首先要评估你的模型能力。2.2 系统化实践模板、变量与版本管理当提示词变得复杂且数量增多时靠记事本和复制粘贴就完全不够用了。这时需要引入工程化方法模板化将提示词抽象成模板把可变部分抽离为变量。例如一个总结报告的提示模板可能是“请基于以下{文档类型}生成一份摘要重点突出{重点领域}字数控制在{字数限制}以内。” 在实际调用时动态注入变量值。这大大提升了复用性。版本控制提示词的每次修改都应该被记录。你可以用Git来管理提示词文件.txt或.json就像管理代码一样。每次优化后提交写明修改原因和测试结果如准确率提升了多少。这避免了“改了半天还不如上一版”的尴尬。评估与测试为重要的提示词建立测试集。这个测试集包含一系列输入和期望的输出或输出标准。每次修改提示词后跑一遍测试集量化评估效果变化如使用BLEU、ROUGE分数或更简单的分类准确率、关键信息抽取成功率。这使优化过程从“感觉”变成了“数据驱动”。我自己的习惯是为每个核心功能建立一个提示词目录里面包含prompt_template.j2Jinja2模板文件、config.yaml变量配置、test_cases.json测试用例以及一个简单的evaluate.py脚本。这样无论是自己迭代还是交给同事维护都清晰很多。2.3 高级技巧与常见陷阱除了范式一些实操技巧能显著提升效果角色扮演Role Playing给模型一个明确的角色如“你是一位经验丰富的Linux系统管理员”、“你是一位严谨的法律文书审核专家”。这能有效约束模型的回答风格和知识范围使其输出更专业、更聚焦。输出格式化指令明确要求模型以特定格式输出如JSON、Markdown表格、带编号的列表。例如“请以JSON格式输出包含problem、root_cause、solution三个键。” 这极大方便了后续的程序化处理。但要注意对于JSON输出最好在提示词中给出一个明确的示例Schema否则模型可能生成不合法的JSON。负面提示Negative Prompting告诉模型“不要做什么”。这在生成内容时尤其有用比如“避免使用过于口语化的表达”、“不要包含任何主观臆测”。这能减少不希望的输出。最常见的陷阱有两个一是提示词过长过细导致模型注意力分散甚至忘记前面的指令。对于长上下文模型这不是大问题但对于短上下文模型需要精炼提示。二是忽略模型的“幻觉”倾向。对于事实性问题永远不要完全相信模型的单次输出必须通过检索增强RAG或要求它提供引用来源来交叉验证。3. 第二维度应用工程——构建可靠、可扩展的LLM工作流如果说提示工程是“砖块”那么应用工程就是如何用这些砖块搭建起稳固的“房子”。它关注的是如何将LLM能力嵌入到一个完整的软件系统中处理真实的、复杂的业务逻辑。这里LangChain、LlamaIndex这类框架成为了标配但它们也只是工具核心在于架构设计。3.1 核心模式链Chain、代理Agent与检索增强RAG这是应用工程的三种核心构建模式复杂度依次递增。链Chain最简单的模式将LLM调用与其他操作如API调用、数据计算按固定顺序连接起来。比如“用户输入 - 意图分类 - 查询改写 - 向量检索 - LLM生成答案”就是一个链。它的优点是逻辑清晰、可控性强适合流程固定的任务。缺点是灵活性差无法处理需要动态规划路径的复杂问题。代理Agent更高级的模式。Agent被赋予一个目标并可以自主选择调用哪些工具如计算器、搜索引擎、数据库来逐步达成目标。它核心包含三个部分规划Planning、工具使用Tool Use和记忆Memory。Agent的强大在于其自主性能处理开放域任务。但挑战也在于此如何保证其决策的可靠性、如何防止其陷入死循环或执行危险操作。在实际项目中我建议先从ReAct模式的Agent入手它要求模型将“思考”和“行动”以文本形式交替输出便于人类理解和调试。检索增强生成RAG这几乎是当前企业级LLM应用的基石。它解决的是模型知识陈旧、专业领域知识不足以及“幻觉”问题。RAG系统将用户查询与私有知识库通常是向量数据库进行匹配检索出相关文档片段并将其作为上下文喂给LLM让LLM基于此生成答案。一个完整的RAG流水线包括文档加载、文本分割、向量化嵌入、存储、检索、重排序、上下文构造、最终生成等多个环节每个环节都有大量优化点。3.2 架构设计考量状态、流式与容错当应用从Demo走向生产以下几个工程问题必须考虑状态管理State Management对话应用是有状态的。你需要管理整个会话的历史对话记忆可能还包括用户个人信息、会话目标等。简单的做法是把整个对话历史都塞进上下文但这会消耗大量Token且可能让模型迷失在冗长历史中。更优的做法是采用摘要式记忆或向量记忆。摘要式记忆定期让模型总结之前的对话要点向量记忆则将历史对话片段向量化存储在需要时动态检索最相关的部分注入上下文。LangChain等框架提供了多种记忆后端但如何设计记忆的更新和触发策略需要根据业务逻辑仔细设计。流式输出Streaming为了用户体验不能让用户对着一个空白页面干等好几秒。流式输出是必须的。这要求后端能够处理SSEServer-Sent Events或WebSocket并将LLM生成的Token逐个推送到前端。技术上不复杂但要注意与整个应用的非阻塞架构结合。容错与降级Fallback DegradationLLM服务可能不稳定API超时、限流模型也可能输出无法解析的内容。你的应用必须有降级策略。例如当主要LLM API调用失败时自动切换到备用API或更小、更快的本地模型当Agent多次尝试失败后自动转入人工客服通道或返回一个预设的保守答案。重试机制带指数退避和断路器模式Circuit Breaker在这里非常有用。可观测性Observability线上应用出了错你得知道为什么。你需要记录和监控关键指标每个LLM调用的耗时、Token消耗、输入输出脱敏后、工具调用记录、最终输出质量可通过简单规则或轻量模型打分。这能帮你快速定位问题是出在提示词、检索环节还是模型本身。3.3 工具生态与集成应用工程离不开工具。除了LangChain这类高层框架你还需要和一系列基础设施打交道向量数据库Chroma轻量、易用、Pinecone全托管、性能好、Weaviate功能丰富、自带向量化模块、Qdrant性能强劲、Rust编写等都是热门选择。选型时考虑部署复杂度、性能、过滤查询能力以及是否支持多模态。LLM网关与编排如果你使用多个模型如GPT-4处理复杂任务Claude处理长文本本地模型处理简单查询需要一个统一的网关来管理路由、密钥、限流和计费。像OpenAI的库虽然方便但在生产环境建议使用Litellm这样的代理它提供了统一的接口调用数十种模型并内置了故障转移、重试、缓存等功能。评估框架如何自动化评估你的RAG系统或Agent的好坏Ragas、TruEra、Phoenix等框架提供了评估检索相关性、答案忠实度、信息完整性等指标的工具。将它们集成到你的CI/CD流水线中可以在每次更新提示词或检索策略后自动运行评估防止效果回退。4. 第三维度平台工程——为规模化应用提供底座当你的团队有多个LLM应用在开发或者单个应用需要服务海量用户时提示工程和应用工程层面的技巧就不够了。你需要一个统一的平台来管理模型、资源、部署和监控。这就是平台工程的范畴它的目标是让应用开发者能更专注于业务逻辑而不是底层基础设施。4.1 模型服务化与推理优化直接调用云API简单但成本高、数据出境可能有合规风险、定制化能力弱。因此许多团队选择私有化部署开源模型。这就带来了模型服务化的问题推理服务器你需要一个高性能的服务器来加载和运行模型。vLLM是目前公认的高性能推理服务器它通过PagedAttention等技术极大地优化了内存使用和吞吐量特别适合高并发场景。TGIText Generation Inference是Hugging Face推出的推理服务器与Transformers生态结合紧密功能丰富。Llama.cpp则通过量化技术让你能在消费级GPU甚至CPU上运行大模型适合边缘部署或成本敏感场景。选型时需要权衡性能、功能支持如是否支持流式、工具调用和部署复杂度。模型量化与优化原始模型动辄几十GB对显存要求极高。量化是将模型权重从高精度如FP16转换为低精度如INT4、INT8的过程能大幅减少内存占用和提升推理速度但会带来轻微的质量损失。GGUF是Llama.cpp社区推动的量化格式标准有从Q2到Q8多种精度可选。通常Q4或Q5的量化能在质量和效率间取得很好平衡。在部署前必须用你的业务数据对量化模型进行充分测试。批处理与持续批处理为了提升GPU利用率需要将多个用户的请求批量处理。持续批处理Continuous Batching是一种先进技术它允许不同请求的生成过程在批次中交错进行而不是等一个请求完全结束再处理下一个这能显著提升吞吐量。vLLM就内置了持续批处理能力。4.2 部署、运维与成本管控平台工程要确保服务稳定、可控、成本透明。部署与扩缩容使用Kubernetes来部署你的推理服务器和应用程序是行业标准做法。通过HPA水平Pod自动扩缩容根据请求量自动调整实例数量。你需要仔细配置资源请求和限制CPU、内存、GPU特别是GPU的共享策略如MIG, Multi-Instance GPU。监控与告警除了应用层的可观测性平台层更需要监控硬件和基础服务。监控GPU利用率、显存使用、请求延迟P50, P99、吞吐量Tokens per second。设置告警规则当服务错误率升高或延迟异常时及时通知。Prometheus Grafana是经典的监控组合。成本分析与优化LLM推理成本是大头。你需要能清晰地追踪每个应用、每个用户甚至每个会话的Token消耗和GPU耗时。这有助于进行成本分摊和优化决策。例如发现某些查询模式总是触发长上下文消耗就可以优化提示词或检索策略来缩短上下文。对于内部应用可以设置Token预算或速率限制。4.3 内部平台与开发者体验最终一个成熟的LLM平台会向内部开发者提供一套自助服务模型仓库像Docker Hub一样管理不同版本、不同量度的模型文件方便部署时拉取。实验管理开发者可以方便地提交不同的提示词、检索配置、模型参数进行A/B测试并查看对比指标。流水线服务提供标准的RAG流水线、Agent框架作为可配置的服务开发者只需关注业务逻辑和提示词。安全与合规集成内容过滤防止生成有害内容、数据脱敏、审计日志等功能满足企业合规要求。平台工程的构建是一个长期过程通常从最痛的“模型部署难”和“成本不可控”开始逐步迭代。它的价值在于当业务团队想尝试一个新想法时不再需要花两周时间折腾环境而是能在平台上几分钟内拉起一个测试服务。5. 三维度对比与协同实战理解了三个维度各自的内涵我们再来横向对比并看它们如何在一个具体项目中协同工作。5.1 维度对比一览维度核心关注点典型工具/技术产出物主要挑战提示工程与模型的高效、可靠交互思维链CoT、ReAct、角色扮演、结构化输出可复用、可测试的提示词模板与策略提示词的效果不稳定、难以量化评估、长上下文管理应用工程构建完整、可靠的应用逻辑与用户体验LangChain/LlamaIndex、向量数据库、Agent框架、流式传输可部署的应用程序或服务如FastAPI后端状态管理、复杂工作流编排、Agent的可靠性、系统集成平台工程提供稳定、高效、可扩展的模型服务与基础设施vLLM/TGI推理服务器、Kubernetes、模型量化、监控告警模型服务平台、资源调度系统、成本监控仪表盘高并发下的性能与稳定性、GPU资源管理、多模型生命周期管理、成本控制简单来说提示工程是“说什么”应用工程是“怎么用”平台工程是“在哪跑、怎么管”。一个新手开发者可能只关注提示工程一个全栈开发者需要精通应用工程而一个基础设施团队或大型项目负责人必须面对平台工程的挑战。5.2 实战案例构建一个智能客服知识库问答系统假设我们要为一个软件产品构建一个智能客服助手它需要回答用户关于产品功能、故障排查等问题。提示工程层的工作设计核心提示模板首先设计回答问题的核心提示词。这很可能是一个RAG风格的提示“你是一位专业的{产品名}客服专家。请严格根据以下提供的参考信息来回答问题。如果信息不足以回答问题请明确告知用户‘根据现有资料无法确认建议您……’切勿编造信息。参考信息{context}。用户问题{question}”。优化检索结果处理检索到的文档片段context可能杂乱、重复。需要设计一个“上下文压缩”或“重排序”的提示词让模型先对检索结果进行筛选和去重提炼出最相关的部分再用于最终答案生成。这能节省Token并提升答案质量。设计分类与路由提示在RAG之前可能还需要一个分类Agent判断用户问题是“知识库问答”、“工单创建”还是“转人工”。这需要另一个精心设计的提示词。应用工程层的工作构建RAG流水线使用LangChain定义整个流程用户输入 - 查询改写提升检索效果- 向量检索 - 重排序/压缩 - 调用LLM生成答案。集成记忆与多轮对话需要维护会话历史。可以采用“缓冲窗口记忆”只保留最近N轮对话并结合向量存储长期记忆当用户追问历史细节时进行检索。实现流式输出与前端交互后端使用FastAPI实现流式响应前端用JavaScript逐步渲染生成的答案提升体验。添加降级策略当主要LLM服务如GPT-4超时或返回错误时自动降级到备用模型如本地部署的Qwen2.5-7B并记录日志。平台工程层的工作部署推理服务由于涉及大量内部知识决定私有化部署一个开源模型如Qwen2.5-72B。使用vLLM部署该模型的GPTQ量化版本INT4以节省显存。构建知识库更新流水线当产品文档更新时自动触发一个CI/CD流水线爬取最新文档 - 分割文本 - 生成向量 - 更新到Pinecone向量数据库。这个过程完全自动化。配置监控与告警在Kubernetes中部署应用和vLLM服务配置Prometheus监控各项指标。当API的P99延迟超过3秒或GPU利用率持续低于20%可能预示有资源浪费触发告警。成本仪表盘开发一个内部仪表盘展示每个客服坐席、每类问题的平均Token消耗和成本为运营优化提供数据支持。在这个案例中三个维度紧密协作平台工程提供了稳定高效的72B模型服务应用工程利用该服务构建了可靠、体验良好的RAG对话流程而提示工程则确保了在这个流程中模型能基于知识库做出准确、可控的回答。任何一层的短板都会直接影响最终的用户体验和业务效果。6. 演进路径与团队协作建议对于个人开发者或团队如何在这三个维度上发展个人开发者建议从提示工程和应用工程入手。先熟练掌握一种框架如LangChain能独立构建一个功能完整的RAG应用或简单Agent。同时深入理解提示词设计的各种技巧和评估方法。平台工程可以先使用云服务如OpenAI API、Pinecone来绕过但需要了解其基本概念和成本结构。创业或中小型团队在个人能力的基础上需要开始关注平台工程的萌芽。当应用数量增多或用户量上来后模型API成本、响应速度、私有化部署需求会浮现。这时可以逐步引入vLLM来部署关键模型使用简单的脚本进行监控和成本统计。重点是为未来的规模化预留架构空间。大型企业或技术平台团队必须系统性地建设平台工程能力。成立专门的MLOps或LLM基础设施团队负责模型的生命周期管理、推理平台建设、资源调度和成本优化。同时为业务开发团队提供易用的SDK、平台门户和最佳实践让他们能专注于提示工程和应用工程快速迭代业务逻辑。在团队协作中清晰的边界和接口定义很重要。平台团队提供稳定、标准的模型服务和数据服务API应用开发团队消费这些API构建最终产品并负责其业务逻辑和提示词优化而算法或NLP团队可能更专注于前沿的提示策略研究和模型微调。三者通过清晰的契约如API文档、SLA、评估标准协同工作。最后我想说LLM开发这片海域已经从最初发现新大陆的兴奋进入了需要扎实造船、精确导航的远航阶段。提示词是你的帆和舵应用架构是你的船体而平台则是你赖以生存的港口和补给线。忽略任何一个维度都可能让你在风浪中搁浅。希望这份从“提示词”到“脚手架”的维度对比能帮你画出一张更清晰的海图在构建真正有价值、可持续的LLM应用的道路上走得更稳、更远。在实际操作中我最深的体会是尽早建立数据反馈闭环。无论是提示词的效果、RAG的检索质量还是Agent的任务成功率都要想办法收集真实用户交互数据并设计自动化评估流程。这个闭环是驱动整个系统持续优化的唯一引擎。 LLM应用开发三维度：从提示工程到平台工程的工程化实践
1. 项目概述当LLM开发从“炼丹”走向“工程”最近和几个团队交流发现一个挺有意思的现象大家聊起大语言模型LLM应用开发已经从半年前的“哪个模型效果最好”、“怎么调提示词更灵”逐渐转向了“我们这套RAG流程怎么优化”、“Agent的稳定性怎么保证”、“线上服务怎么压测”。这个转变很有意思它标志着一个领域从早期的技术探索和“玄学”调优开始进入规模化、工程化的深水区。我自己从去年初开始密集投入LLM应用开发从最初的单点提示词优化到构建复杂的多智能体工作流再到如今负责整个应用的生命周期管理踩过的坑、交过的学费不少。今天想和你聊聊的就是这个过程中的核心体会LLM开发远不止是写提示词它至少包含了三个相互交织又各有侧重的工程维度——提示工程、应用工程和平台工程。理解这三个维度对于任何一个想在这个领域深耕的团队或个人都至关重要。它帮你跳出“唯提示词论”的局限看清一个LLM应用从想法到稳定服务的全貌。你会明白为什么一个在本地跑得飞快的Demo一上线就各种幺蛾子为什么别人的Agent能稳定处理复杂任务你的却动不动就“宕机”。这背后是不同工程维度上的认知差距和工具缺失。接下来我们就逐一拆解这三个维度看看它们各自关注什么、用什么工具、解决什么问题以及在实际项目中如何协同工作。2. 第一维度提示工程——从“魔法咒语”到可复用的构建块提示工程是大多数人接触LLM的第一站。它直观、反馈快有点像在和模型“对话”或“下指令”。但早期的提示工程往往停留在“试错”和“玄学”层面缺乏系统性和可复用性。真正的提示工程应该将其视为一种软件工程实践。2.1 核心范式演进从零样本到思维链与程序模拟最初的提示很简单就是零样本Zero-Shot或少量样本Few-Shot的直接问答。但很快大家发现对于复杂任务直接问效果很差。于是思维链Chain-of-Thought, CoT出现了。它的核心是引导模型“一步步思考”把推理过程展示出来。这不仅仅是让答案更准确更重要的是让整个过程变得可调试。你可以看到模型在哪一步“想歪了”从而有针对性地调整提示。但CoT还是线性的、描述性的。更进一步的是程序模拟式提示比如ReActReasoning Acting范式。它要求模型不仅推理还要规划行动如调用工具、搜索信息。这时的提示词更像是在给模型编写一个“剧本”或“工作流描述”。例如一个客服Agent的提示词里会明确包含“首先你需要理解用户的问题属于哪个类别技术故障、账单查询、产品咨询。如果是技术故障请依次询问设备型号、故障现象、出现时间。然后根据知识库检索相关解决方案若没有则告知用户已升级至人工客服。” 这种提示结构化了模型的输出使其行为更可控。注意思维链提示的成功高度依赖于模型本身的推理能力。对于较小的模型如7B参数级别复杂的CoT提示可能反而会导致它“胡思乱想”输出混乱。通常70B参数以上的模型对复杂提示的遵循能力会强得多。在选择范式时首先要评估你的模型能力。2.2 系统化实践模板、变量与版本管理当提示词变得复杂且数量增多时靠记事本和复制粘贴就完全不够用了。这时需要引入工程化方法模板化将提示词抽象成模板把可变部分抽离为变量。例如一个总结报告的提示模板可能是“请基于以下{文档类型}生成一份摘要重点突出{重点领域}字数控制在{字数限制}以内。” 在实际调用时动态注入变量值。这大大提升了复用性。版本控制提示词的每次修改都应该被记录。你可以用Git来管理提示词文件.txt或.json就像管理代码一样。每次优化后提交写明修改原因和测试结果如准确率提升了多少。这避免了“改了半天还不如上一版”的尴尬。评估与测试为重要的提示词建立测试集。这个测试集包含一系列输入和期望的输出或输出标准。每次修改提示词后跑一遍测试集量化评估效果变化如使用BLEU、ROUGE分数或更简单的分类准确率、关键信息抽取成功率。这使优化过程从“感觉”变成了“数据驱动”。我自己的习惯是为每个核心功能建立一个提示词目录里面包含prompt_template.j2Jinja2模板文件、config.yaml变量配置、test_cases.json测试用例以及一个简单的evaluate.py脚本。这样无论是自己迭代还是交给同事维护都清晰很多。2.3 高级技巧与常见陷阱除了范式一些实操技巧能显著提升效果角色扮演Role Playing给模型一个明确的角色如“你是一位经验丰富的Linux系统管理员”、“你是一位严谨的法律文书审核专家”。这能有效约束模型的回答风格和知识范围使其输出更专业、更聚焦。输出格式化指令明确要求模型以特定格式输出如JSON、Markdown表格、带编号的列表。例如“请以JSON格式输出包含problem、root_cause、solution三个键。” 这极大方便了后续的程序化处理。但要注意对于JSON输出最好在提示词中给出一个明确的示例Schema否则模型可能生成不合法的JSON。负面提示Negative Prompting告诉模型“不要做什么”。这在生成内容时尤其有用比如“避免使用过于口语化的表达”、“不要包含任何主观臆测”。这能减少不希望的输出。最常见的陷阱有两个一是提示词过长过细导致模型注意力分散甚至忘记前面的指令。对于长上下文模型这不是大问题但对于短上下文模型需要精炼提示。二是忽略模型的“幻觉”倾向。对于事实性问题永远不要完全相信模型的单次输出必须通过检索增强RAG或要求它提供引用来源来交叉验证。3. 第二维度应用工程——构建可靠、可扩展的LLM工作流如果说提示工程是“砖块”那么应用工程就是如何用这些砖块搭建起稳固的“房子”。它关注的是如何将LLM能力嵌入到一个完整的软件系统中处理真实的、复杂的业务逻辑。这里LangChain、LlamaIndex这类框架成为了标配但它们也只是工具核心在于架构设计。3.1 核心模式链Chain、代理Agent与检索增强RAG这是应用工程的三种核心构建模式复杂度依次递增。链Chain最简单的模式将LLM调用与其他操作如API调用、数据计算按固定顺序连接起来。比如“用户输入 - 意图分类 - 查询改写 - 向量检索 - LLM生成答案”就是一个链。它的优点是逻辑清晰、可控性强适合流程固定的任务。缺点是灵活性差无法处理需要动态规划路径的复杂问题。代理Agent更高级的模式。Agent被赋予一个目标并可以自主选择调用哪些工具如计算器、搜索引擎、数据库来逐步达成目标。它核心包含三个部分规划Planning、工具使用Tool Use和记忆Memory。Agent的强大在于其自主性能处理开放域任务。但挑战也在于此如何保证其决策的可靠性、如何防止其陷入死循环或执行危险操作。在实际项目中我建议先从ReAct模式的Agent入手它要求模型将“思考”和“行动”以文本形式交替输出便于人类理解和调试。检索增强生成RAG这几乎是当前企业级LLM应用的基石。它解决的是模型知识陈旧、专业领域知识不足以及“幻觉”问题。RAG系统将用户查询与私有知识库通常是向量数据库进行匹配检索出相关文档片段并将其作为上下文喂给LLM让LLM基于此生成答案。一个完整的RAG流水线包括文档加载、文本分割、向量化嵌入、存储、检索、重排序、上下文构造、最终生成等多个环节每个环节都有大量优化点。3.2 架构设计考量状态、流式与容错当应用从Demo走向生产以下几个工程问题必须考虑状态管理State Management对话应用是有状态的。你需要管理整个会话的历史对话记忆可能还包括用户个人信息、会话目标等。简单的做法是把整个对话历史都塞进上下文但这会消耗大量Token且可能让模型迷失在冗长历史中。更优的做法是采用摘要式记忆或向量记忆。摘要式记忆定期让模型总结之前的对话要点向量记忆则将历史对话片段向量化存储在需要时动态检索最相关的部分注入上下文。LangChain等框架提供了多种记忆后端但如何设计记忆的更新和触发策略需要根据业务逻辑仔细设计。流式输出Streaming为了用户体验不能让用户对着一个空白页面干等好几秒。流式输出是必须的。这要求后端能够处理SSEServer-Sent Events或WebSocket并将LLM生成的Token逐个推送到前端。技术上不复杂但要注意与整个应用的非阻塞架构结合。容错与降级Fallback DegradationLLM服务可能不稳定API超时、限流模型也可能输出无法解析的内容。你的应用必须有降级策略。例如当主要LLM API调用失败时自动切换到备用API或更小、更快的本地模型当Agent多次尝试失败后自动转入人工客服通道或返回一个预设的保守答案。重试机制带指数退避和断路器模式Circuit Breaker在这里非常有用。可观测性Observability线上应用出了错你得知道为什么。你需要记录和监控关键指标每个LLM调用的耗时、Token消耗、输入输出脱敏后、工具调用记录、最终输出质量可通过简单规则或轻量模型打分。这能帮你快速定位问题是出在提示词、检索环节还是模型本身。3.3 工具生态与集成应用工程离不开工具。除了LangChain这类高层框架你还需要和一系列基础设施打交道向量数据库Chroma轻量、易用、Pinecone全托管、性能好、Weaviate功能丰富、自带向量化模块、Qdrant性能强劲、Rust编写等都是热门选择。选型时考虑部署复杂度、性能、过滤查询能力以及是否支持多模态。LLM网关与编排如果你使用多个模型如GPT-4处理复杂任务Claude处理长文本本地模型处理简单查询需要一个统一的网关来管理路由、密钥、限流和计费。像OpenAI的库虽然方便但在生产环境建议使用Litellm这样的代理它提供了统一的接口调用数十种模型并内置了故障转移、重试、缓存等功能。评估框架如何自动化评估你的RAG系统或Agent的好坏Ragas、TruEra、Phoenix等框架提供了评估检索相关性、答案忠实度、信息完整性等指标的工具。将它们集成到你的CI/CD流水线中可以在每次更新提示词或检索策略后自动运行评估防止效果回退。4. 第三维度平台工程——为规模化应用提供底座当你的团队有多个LLM应用在开发或者单个应用需要服务海量用户时提示工程和应用工程层面的技巧就不够了。你需要一个统一的平台来管理模型、资源、部署和监控。这就是平台工程的范畴它的目标是让应用开发者能更专注于业务逻辑而不是底层基础设施。4.1 模型服务化与推理优化直接调用云API简单但成本高、数据出境可能有合规风险、定制化能力弱。因此许多团队选择私有化部署开源模型。这就带来了模型服务化的问题推理服务器你需要一个高性能的服务器来加载和运行模型。vLLM是目前公认的高性能推理服务器它通过PagedAttention等技术极大地优化了内存使用和吞吐量特别适合高并发场景。TGIText Generation Inference是Hugging Face推出的推理服务器与Transformers生态结合紧密功能丰富。Llama.cpp则通过量化技术让你能在消费级GPU甚至CPU上运行大模型适合边缘部署或成本敏感场景。选型时需要权衡性能、功能支持如是否支持流式、工具调用和部署复杂度。模型量化与优化原始模型动辄几十GB对显存要求极高。量化是将模型权重从高精度如FP16转换为低精度如INT4、INT8的过程能大幅减少内存占用和提升推理速度但会带来轻微的质量损失。GGUF是Llama.cpp社区推动的量化格式标准有从Q2到Q8多种精度可选。通常Q4或Q5的量化能在质量和效率间取得很好平衡。在部署前必须用你的业务数据对量化模型进行充分测试。批处理与持续批处理为了提升GPU利用率需要将多个用户的请求批量处理。持续批处理Continuous Batching是一种先进技术它允许不同请求的生成过程在批次中交错进行而不是等一个请求完全结束再处理下一个这能显著提升吞吐量。vLLM就内置了持续批处理能力。4.2 部署、运维与成本管控平台工程要确保服务稳定、可控、成本透明。部署与扩缩容使用Kubernetes来部署你的推理服务器和应用程序是行业标准做法。通过HPA水平Pod自动扩缩容根据请求量自动调整实例数量。你需要仔细配置资源请求和限制CPU、内存、GPU特别是GPU的共享策略如MIG, Multi-Instance GPU。监控与告警除了应用层的可观测性平台层更需要监控硬件和基础服务。监控GPU利用率、显存使用、请求延迟P50, P99、吞吐量Tokens per second。设置告警规则当服务错误率升高或延迟异常时及时通知。Prometheus Grafana是经典的监控组合。成本分析与优化LLM推理成本是大头。你需要能清晰地追踪每个应用、每个用户甚至每个会话的Token消耗和GPU耗时。这有助于进行成本分摊和优化决策。例如发现某些查询模式总是触发长上下文消耗就可以优化提示词或检索策略来缩短上下文。对于内部应用可以设置Token预算或速率限制。4.3 内部平台与开发者体验最终一个成熟的LLM平台会向内部开发者提供一套自助服务模型仓库像Docker Hub一样管理不同版本、不同量度的模型文件方便部署时拉取。实验管理开发者可以方便地提交不同的提示词、检索配置、模型参数进行A/B测试并查看对比指标。流水线服务提供标准的RAG流水线、Agent框架作为可配置的服务开发者只需关注业务逻辑和提示词。安全与合规集成内容过滤防止生成有害内容、数据脱敏、审计日志等功能满足企业合规要求。平台工程的构建是一个长期过程通常从最痛的“模型部署难”和“成本不可控”开始逐步迭代。它的价值在于当业务团队想尝试一个新想法时不再需要花两周时间折腾环境而是能在平台上几分钟内拉起一个测试服务。5. 三维度对比与协同实战理解了三个维度各自的内涵我们再来横向对比并看它们如何在一个具体项目中协同工作。5.1 维度对比一览维度核心关注点典型工具/技术产出物主要挑战提示工程与模型的高效、可靠交互思维链CoT、ReAct、角色扮演、结构化输出可复用、可测试的提示词模板与策略提示词的效果不稳定、难以量化评估、长上下文管理应用工程构建完整、可靠的应用逻辑与用户体验LangChain/LlamaIndex、向量数据库、Agent框架、流式传输可部署的应用程序或服务如FastAPI后端状态管理、复杂工作流编排、Agent的可靠性、系统集成平台工程提供稳定、高效、可扩展的模型服务与基础设施vLLM/TGI推理服务器、Kubernetes、模型量化、监控告警模型服务平台、资源调度系统、成本监控仪表盘高并发下的性能与稳定性、GPU资源管理、多模型生命周期管理、成本控制简单来说提示工程是“说什么”应用工程是“怎么用”平台工程是“在哪跑、怎么管”。一个新手开发者可能只关注提示工程一个全栈开发者需要精通应用工程而一个基础设施团队或大型项目负责人必须面对平台工程的挑战。5.2 实战案例构建一个智能客服知识库问答系统假设我们要为一个软件产品构建一个智能客服助手它需要回答用户关于产品功能、故障排查等问题。提示工程层的工作设计核心提示模板首先设计回答问题的核心提示词。这很可能是一个RAG风格的提示“你是一位专业的{产品名}客服专家。请严格根据以下提供的参考信息来回答问题。如果信息不足以回答问题请明确告知用户‘根据现有资料无法确认建议您……’切勿编造信息。参考信息{context}。用户问题{question}”。优化检索结果处理检索到的文档片段context可能杂乱、重复。需要设计一个“上下文压缩”或“重排序”的提示词让模型先对检索结果进行筛选和去重提炼出最相关的部分再用于最终答案生成。这能节省Token并提升答案质量。设计分类与路由提示在RAG之前可能还需要一个分类Agent判断用户问题是“知识库问答”、“工单创建”还是“转人工”。这需要另一个精心设计的提示词。应用工程层的工作构建RAG流水线使用LangChain定义整个流程用户输入 - 查询改写提升检索效果- 向量检索 - 重排序/压缩 - 调用LLM生成答案。集成记忆与多轮对话需要维护会话历史。可以采用“缓冲窗口记忆”只保留最近N轮对话并结合向量存储长期记忆当用户追问历史细节时进行检索。实现流式输出与前端交互后端使用FastAPI实现流式响应前端用JavaScript逐步渲染生成的答案提升体验。添加降级策略当主要LLM服务如GPT-4超时或返回错误时自动降级到备用模型如本地部署的Qwen2.5-7B并记录日志。平台工程层的工作部署推理服务由于涉及大量内部知识决定私有化部署一个开源模型如Qwen2.5-72B。使用vLLM部署该模型的GPTQ量化版本INT4以节省显存。构建知识库更新流水线当产品文档更新时自动触发一个CI/CD流水线爬取最新文档 - 分割文本 - 生成向量 - 更新到Pinecone向量数据库。这个过程完全自动化。配置监控与告警在Kubernetes中部署应用和vLLM服务配置Prometheus监控各项指标。当API的P99延迟超过3秒或GPU利用率持续低于20%可能预示有资源浪费触发告警。成本仪表盘开发一个内部仪表盘展示每个客服坐席、每类问题的平均Token消耗和成本为运营优化提供数据支持。在这个案例中三个维度紧密协作平台工程提供了稳定高效的72B模型服务应用工程利用该服务构建了可靠、体验良好的RAG对话流程而提示工程则确保了在这个流程中模型能基于知识库做出准确、可控的回答。任何一层的短板都会直接影响最终的用户体验和业务效果。6. 演进路径与团队协作建议对于个人开发者或团队如何在这三个维度上发展个人开发者建议从提示工程和应用工程入手。先熟练掌握一种框架如LangChain能独立构建一个功能完整的RAG应用或简单Agent。同时深入理解提示词设计的各种技巧和评估方法。平台工程可以先使用云服务如OpenAI API、Pinecone来绕过但需要了解其基本概念和成本结构。创业或中小型团队在个人能力的基础上需要开始关注平台工程的萌芽。当应用数量增多或用户量上来后模型API成本、响应速度、私有化部署需求会浮现。这时可以逐步引入vLLM来部署关键模型使用简单的脚本进行监控和成本统计。重点是为未来的规模化预留架构空间。大型企业或技术平台团队必须系统性地建设平台工程能力。成立专门的MLOps或LLM基础设施团队负责模型的生命周期管理、推理平台建设、资源调度和成本优化。同时为业务开发团队提供易用的SDK、平台门户和最佳实践让他们能专注于提示工程和应用工程快速迭代业务逻辑。在团队协作中清晰的边界和接口定义很重要。平台团队提供稳定、标准的模型服务和数据服务API应用开发团队消费这些API构建最终产品并负责其业务逻辑和提示词优化而算法或NLP团队可能更专注于前沿的提示策略研究和模型微调。三者通过清晰的契约如API文档、SLA、评估标准协同工作。最后我想说LLM开发这片海域已经从最初发现新大陆的兴奋进入了需要扎实造船、精确导航的远航阶段。提示词是你的帆和舵应用架构是你的船体而平台则是你赖以生存的港口和补给线。忽略任何一个维度都可能让你在风浪中搁浅。希望这份从“提示词”到“脚手架”的维度对比能帮你画出一张更清晰的海图在构建真正有价值、可持续的LLM应用的道路上走得更稳、更远。在实际操作中我最深的体会是尽早建立数据反馈闭环。无论是提示词的效果、RAG的检索质量还是Agent的任务成功率都要想办法收集真实用户交互数据并设计自动化评估流程。这个闭环是驱动整个系统持续优化的唯一引擎。