agent与微调怎么选：适合场景与实施思路

多数团队纠结 agent 与微调怎么选，本质上是在问：问题是“会不会做流程”，还是“会不会按你的方式回答”。如果任务需要调用工具、查询系统、分步骤决策，优先考虑 agent；如果任务需要稳定掌握特定表达风格、分类边界、行业话术或格式规范，微调更合适。两者不是替代关系，很多成熟方案会先用提示词和检索验证需求，再决定是否引入 agent 或微调。

先把两个概念放到业务语境里

agent 可以理解为让大模型从“回答问题”升级到“完成任务”。它通常包含目标理解、任务拆解、工具调用、状态记忆、结果校验等环节。例如让它根据客户问题查询订单、判断退款规则、调用工单系统并生成回复，这就不是单轮问答，而是一个可执行流程。

微调则是改变模型在某类输入下的输出习惯。它更像给模型补一套稳定的“做题方式”：客服标签怎么分、合同条款怎么抽取、销售话术用什么语气、医疗随访记录按什么格式归纳。微调不天然解决“去哪里查数据、什么时候调用接口、如何重试”这些流程问题。

一个简单判断是：如果你能把任务写成一条固定输入到固定输出的映射，且有足够样本，微调值得评估；如果任务中间要看外部状态、走不同分支、调用多个系统，agent 通常更贴近需求。

哪些场景优先用 agent

第一类是跨系统操作。比如销售助理要查 CRM、读邮件、生成拜访摘要、更新客户阶段；财务助手要读取发票信息、对账、提醒异常。这类任务的关键不在模型背不背知识，而在能否安全、准确地连接工具。

第二类是动态信息强依赖。政策、库存、价格、排班、订单状态经常变化，靠微调把这些信息“记进模型”通常不合适。更稳妥的做法是让 agent 通过检索或接口拿到最新数据，再基于规则生成结果。

第三类是多步骤决策。比如售后处理需要先识别问题类型，再判断是否在质保期，接着选择补寄、维修、退款或升级人工。流程越长、分支越多，越需要把任务编排、权限控制、日志追踪作为工程重点，而不是只盯着模型本身。

哪些场景更适合微调

微调适合输出模式稳定、评价标准明确、样本可积累的任务。典型例子包括意图识别、文本分类、信息抽取、固定格式改写、行业问答口吻统一、内部知识场景下的回答风格对齐。

当提示词已经写得很长、规则反复强调仍然不稳定时，可以考虑微调。例如每次都要求模型按 12 个字段输出售后原因，但它总漏字段、乱改字段名；或者要求客服回复保持品牌语气，但不同对话波动明显。这时微调可能降低提示词复杂度，让输出更一致。

但要注意，微调不是知识库的替代品。如果你的痛点是“模型不知道最新制度”“无法引用企业文档”，优先应考虑检索增强、知识库治理或接口查询，而不是直接微调。把易变知识放进训练数据，后续维护成本会很高。

五步判断框架：从问题形态到实施路线

第一步，拆清任务输入、输出和中间动作。拿一个真实场景写清楚：用户会提供什么信息，系统必须返回什么结果，中间是否需要查数据库、调用工具、审批或人工确认。如果中间动作超过两个，agent 的价值会明显上升。

第二步，判断信息是否经常变化。稳定的规则、风格、标签边界可以进入微调候选；频繁变化的库存、政策、客户状态应放在外部系统中，由 agent 或检索组件实时获取。不要让模型承担数据库职责。

第三步，看是否有高质量样本。微调需要成体系的输入输出样本，还要覆盖常见边界情况。样本不是越多越好，关键是干净、一致、可审核。如果历史人工回复本身风格混乱，直接拿来微调只会把混乱固化。

第四步，先做最低成本验证。很多场景可以按“提示词加少量示例，再加检索或工具调用”的方式先跑通。只有当你明确看到瓶颈：流程无法自动执行、输出稳定性不够、成本或延迟不可接受，再进入 agent 工程化或微调阶段。

第五步，设计可回滚方案。agent 要能限制工具权限、记录每一步调用、失败时转人工；微调模型要能与基座模型对比，保留切换入口。上线不是一次性替换，而应先在低风险流量或内部场景中灰度。

常见组合方案：不是二选一

在企业落地中，常见路线是“检索增强加 agent”。知识放在文档库或业务系统中，agent 负责判断该查什么、调用什么、如何合成答案。这适合企业知识问答、客服辅助、运营分析等场景。

另一种路线是“微调加 agent”。微调负责让模型更懂企业语气、分类标准和输出格式，agent 负责执行流程。例如智能客服中，微调模型先稳定识别用户意图和情绪，agent 再查询订单、判断规则、创建工单。

还有一种更务实的路线是“不急着微调”。先通过提示词模板、结构化输出约束、示例库、人工审核闭环，把任务定义清楚。很多团队在这个阶段就能解决 60% 以上的问题，也能为后续微调沉淀更干净的数据。

风险、限制与验收要点

agent 的主要风险是不可控动作。它可能调用错工具、传错参数、在信息不足时继续执行。因此必须设置权限边界、确认节点和日志追踪。涉及付款、删除、发货、合规判断等高风险动作，应保留人工确认或规则引擎兜底。

微调的主要风险是数据质量和泛化边界。训练样本如果带有错误标签、过时政策、个人隐私或不一致表达，模型会学习这些问题。微调后还可能在原本表现不错的通用能力上退化，所以验收不能只看训练集表现，要看独立测试集和真实流量。

验收指标要和业务目标绑定。agent 不能只看“是否能回答”，还要看任务完成率、工具调用准确率、平均处理时长、转人工率、错误动作数。微调不能只看主观感觉，要看格式合规率、分类准确率、字段抽取准确率、人工修改率。

同时要设置失败样本池。把模型答错、流程失败、用户追问、人工改写的案例持续沉淀，每周或每两周复盘一次。agent 优化往往改的是流程、工具描述和权限策略；微调优化改的是样本、标签规范和训练目标。

可直接使用的决策建议

如果你的需求是“让 AI 帮我查、算、填、提交、追踪”，优先评估 agent。如果你的需求是“让 AI 更稳定地按某种标准说、分、抽、写”，优先评估微调。如果你还说不清稳定标准，先不要微调，先把任务样本、评价口径和失败案例整理出来。

如果业务数据经常变化，优先用检索、接口和 agent；如果规则长期稳定且样本充足，可以把微调纳入方案。如果错误成本高，先做人机协同，不要让 agent 直接闭环执行高风险操作。

行动清单

列出 20 个真实任务样本，标注输入、期望输出和中间动作。

把任务分成三类：纯生成或分类、多步骤流程、依赖实时数据。

检查是否已有高质量标注样本；没有样本时先建立人工审核与样本沉淀机制。

用提示词、示例、检索或简单工具调用做一次小范围验证。

为 agent 方案定义工具权限、失败转人工、日志字段和关键指标。

为微调方案定义训练样本规范、独立测试集、上线前后对比指标。

最后再回答“agent与微调怎么选：适合场景与实施思路”这个问题：先按任务形态选方向，再按数据质量和风险等级定实施深度。不要为了技术名词上项目，能稳定解决业务问题的方案，才是正确选择。