大模型应用开发常被简化成三种技术名词：RAG、Agent、微调。真正做项目时，团队要回答的不是“哪条路线更高级”，而是业务问题属于知识检索、任务执行、领域适配，还是三者叠加。路线选错，会让本来能轻量起步的应用变得复杂，也会让真正需要治理的场景缺少边界。
读完你会得到：一套判断RAG、Agent、微调优先级的方法，以及企业应用从试点走向生产时需要补齐的权限、评估和运营责任。
先问三个问题：缺知识、缺动作，还是缺领域行为
大模型应用开发的路线选择可以从三个问题开始。第一，模型回答不准，是因为缺少最新或内部知识吗？第二，应用目标是否需要调用系统、执行流程或改写业务状态？第三，通用模型即使拿到知识，仍无法稳定输出行业格式、专业表达或特定任务行为吗？
如果主要缺知识，RAG通常优先；如果主要缺动作，Agent更接近目标；如果主要缺长期稳定的领域行为，微调才值得评估。很多项目会组合使用，但组合也应有顺序。先把问题拆清楚，再决定是否叠加技术。
技术路线的先后顺序，应由业务问题的性质决定，而不是由概念热度决定。 这句话能帮助团队避免一开始就把所有能力堆进同一个应用。
RAG适合知识更新快、答案需要可追溯的应用
RAG的核心是把企业文档、制度、产品资料、工单、手册或数据库中的相关内容检索出来，再交给模型生成答案。它适合知识来源明确、更新频繁、答案需要引用依据的场景，例如内部知识问答、售前资料助手、客服辅助、制度查询和运维手册问答。
RAG的难点不在“接一个向量库”这么简单，而在知识治理。文档是否过期，切分是否合理，元数据是否完整，权限是否能过滤，检索结果是否可解释，答案是否能引用来源，这些都会影响最终效果。如果知识库本身混乱，RAG可能只是把混乱以更自然的语言呈现出来。
RAG上线前可以重点验证三类证据：典型问题是否能检索到正确片段，答案是否能区分已知资料和模型推断，越权文档是否不会被召回。只有这三类证据通过，应用才适合进入更大范围试用。
Agent适合有明确流程、工具和权限边界的任务
Agent关注的是让模型围绕目标拆解步骤、调用工具、读取或写入系统，并根据结果继续推进。它适合工单处理、数据查询、报表生成、审批辅助、运维排查、代码操作、知识库维护等任务型场景。与RAG相比，Agent的风险更高，因为它不只是“回答”，还可能“行动”。
Agent的关键不是让模型“更聪明”，而是给每个工具设置边界。哪些工具只能读，哪些工具能写，哪些操作需要人工确认，失败后是否重试，工具返回异常如何解释，日志如何保留，责任归属如何划分，这些问题决定Agent能否进入生产。
如果一个场景还没有稳定流程、没有清晰权限、没有可审计日志，不建议一开始就做强Agent。可以先做只读助手或半自动建议，让人工确认关键动作，再逐步扩大工具权限。
微调适合任务稳定、样本可靠、长期复用的能力沉淀
微调适合解决通用模型在特定领域、格式、风格或任务行为上的稳定性问题。例如特定行业问答格式、固定报告结构、专业术语表达、分类任务、抽取任务或企业标准话术。它的前提是任务相对稳定，并且有足够质量的样本和评估集。
微调不适合用来弥补频繁变化的知识。知识更新快时，RAG通常更灵活；工具执行需求强时，Agent更直接；样本质量不足时，微调可能把错误模式固化到模型里。企业在考虑微调前，应先确认样本来源、标注规则、训练目标、评估指标、基座版本、部署方式和回滚策略。
微调的价值在长期复用。如果只是一次活动、一次试点或少量临时需求，通过提示词、RAG或工作流编排可能更合适。微调应被视为能力沉淀，而不是所有效果问题的默认答案。
三种路线的决策表：先轻后重，先可控后自动
下面的表格可以作为初步判断。它不是绝对规则，但能帮助团队避免把所有问题都推给同一种技术。
| 判断问题 | 更可能优先的路线 | 主要证据 | 风险边界 |
| 资料更新快、答案要引用 | RAG | 文档、检索命中、来源引用 | 知识过期、权限泄露、召回错误 |
| 需要调用系统完成任务 | Agent | 工具清单、权限、执行日志 | 越权操作、失败重试、责任不清 |
| 输出格式和领域表达长期稳定 | 微调 | 高质量样本、评估集、版本记录 | 样本偏差、训练成本、回滚困难 |
| 既要知识又要动作 | RAG+Agent | 检索结果、工具返回、审计链路 | 错误知识驱动错误动作 |
| 既要领域风格又要知识更新 | RAG+微调 | 样本评估、知识库更新机制 | 风格稳定但事实过期 |
表格背后的原则是先轻后重。能用Prompt和RAG解决的，不要过早微调；能用人工确认降低风险的，不要直接给Agent写权限；能在小范围验证的，不要一开始就做全流程自动化。
组合使用时要明确每一层负责什么
真实企业应用往往不是三选一。一个售前助手可能用RAG检索产品资料，用微调稳定方案结构，用Agent生成任务清单或调用CRM只读查询。一个运维助手可能用RAG检索手册，用Agent执行诊断命令，用微调适配故障分类输出格式。组合的关键是职责清楚。
可以把应用拆成三层：知识层负责提供依据，行动层负责调用工具，行为层负责稳定输出。每一层都要有自己的评估指标和失败处理方式。知识层看召回和引用，行动层看工具成功率和权限，行为层看格式稳定性和任务准确率。
组合路线最怕“边界不清”：模型既负责找知识，又负责决定动作，还负责解释结果，但日志里看不出每一步依据。 一旦出现错误，团队无法判断是检索错、工具错、模型推理错，还是样本训练错。
从试点到生产，要补齐评估和运营机制
大模型应用开发进入生产前，需要从演示效果转向运营证据。RAG要有知识库更新流程、文档责任人和召回评估；Agent要有工具权限、操作日志、人工确认和回滚边界；微调要有样本版本、评估集、模型版本和部署记录。
这类运营机制不一定复杂，但必须存在。否则应用上线后，业务方会不断提出“为什么这次答错、为什么没查到、为什么调用失败、为什么和上周输出不同”。没有日志和版本，技术团队只能重新猜测。
如果团队正在建设AI应用能力，可以从 AI基础设施分类 中继续查看模型部署、资源调度和平台治理内容，把应用路线选择与底层服务能力一起规划。
下一步建议：用最小闭环验证一条主线
选择路线时，不建议同时启动RAG、Agent和微调的完整建设。更好的方式是选择最能体现业务价值的一条主线，做一个最小闭环。例如知识问答先做RAG，流程助手先做只读Agent，专业格式输出先做样本评估和少量微调可行性验证。
最小闭环应包含真实输入、可复核输出、失败样例、人工反馈和下一步改进计划。只要这个闭环跑通，再考虑组合其他技术会更稳。大模型应用开发不是一次性架构选择，而是围绕业务价值、风险控制和平台能力持续迭代。
常见问题
大模型应用开发应该先做RAG还是微调？
如果问题主要来自知识缺失、资料更新或答案需要引用依据，通常先做RAG更合适。RAG可以把知识更新和模型能力解耦，便于快速验证业务价值。微调更适合任务稳定、样本质量高、需要长期固化输出格式或领域表达的场景。若知识仍在频繁变化，却先做微调，后续维护成本会很高。比较稳妥的做法是先用RAG建立问答基线，再根据错误样例判断是否需要微调补充。
Agent是不是比RAG更高级，所以更值得投入？
不是。Agent和RAG解决的问题不同。RAG解决“答案依据从哪里来”，Agent解决“需要调用什么工具完成动作”。如果场景只是资料问答，用Agent会增加权限、日志、失败处理和成本；如果场景需要查询系统、生成工单或执行流程，只做RAG又无法闭环。判断Agent价值时，应先确认流程是否稳定、工具权限是否清楚、关键动作是否需要人工确认，以及失败后能否追溯。
RAG、Agent和微调可以在一个应用里同时使用吗？
可以，而且很多复杂应用最终都会组合使用。但组合前要明确每一层职责：RAG负责提供知识依据，Agent负责工具调用和流程推进，微调负责稳定领域表达或任务格式。每一层都要有独立日志和评估指标，避免错误发生时无法定位。建议先用最小闭环验证主线能力，再逐步增加其他路线，而不是第一版就把三种技术全部堆上去。
原创声明：本文为 Alauda 原创技术内容，非商业转载须注明出处：https://www.alauda.cn/blog/1149/。
文中图示和文章内容未经许可不得用于商业转载、培训课件、营销材料或二次分发。
