一、全景对比
| 项目 | 类型 | 核心适用场景 |
| --- | --- | --- |
| MCP 协议 | Agent | 需要让 AI 连接本地文件、数据库、内部系统、SaaS 工具的场景， |
| RAG 混合检索与重排 | 检索增强 | 企业知识库、文档问答、客服话术检索、代码库检索等场景 |
| Agent 工作流设计 | 工作流 | 资料整理、报告生成、代码修复、数据同步等多步骤任务 |
| LoRA 微调 | 微调 | 固定格式生成、垂直领域术语理解、风格统一的内容生产 |
| 推理模型使用技巧 | Reasoning | 数学与逻辑题、复杂代码调试、方案权衡、长链条数据分析 |
二、MCP 协议
1. MCP 解决的是什么问题
MCP（Model Context Protocol）是让模型安全访问外部工具和数据源的一套开放协议。在它之前，每个 AI 客户端都要为每个数据源写一套私有集成；有了 MCP，工具提供方只需实现一个 MCP Server，就能被所有支持该协议的客户端复用。它把「模型 ↔ 工具」的连接标准化为「Client ↔ Server」，通信基于 JSON-RPC，支持本地进程（stdio）和远程服务（HTTP/SSE）两种传输方式。
2. 配置一个 MCP Server
以文件系统工具为例，在支持 MCP 的客户端配置文件中加入：
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/me/project"
]
}
}
}3. 能力分级与安全边界
MCP Server 通常暴露三类能力：Tools（可执行的动作，如读写文件、发请求）、Resources（只读数据，如文档、表结构）、Prompts（预置模板）。接入时务必遵循最小权限原则：只挂载必要目录、数据库用只读账号、涉及写操作的 Tool 要求二次确认。远程 MCP 服务还要校验来源，避免把内部凭证暴露给不受信任的 Server。
4. 实用建议
工具数量不是越多越好。单个会话挂载 5-8 个高相关 Tool 效果通常好于几十个；Tool 的 description 要写清楚「什么时候用、参数含义、返回什么」，这直接决定模型能否正确调用；调试时先单独验证 Server 能否正常响应，再接入客户端排查模型侧问题。
适用场景与边界：适合需要让 AI 连接本地文件、数据库、内部系统、SaaS 工具的场景，是构建 Agent 基础设施的通用方式。
三、RAG 混合检索与重排
1. 纯向量检索的天花板
很多 RAG 系统上线后效果不稳，根源在于只用向量检索。向量擅长语义相似，但对精确匹配（型号、错误码、人名、API 名称）不敏感，遇到长尾查询容易召回一堆「语义相近但答非所问」的片段。工程上的标准解法是混合检索：向量召回 + 关键词召回（BM25）并行，再融合排序。
2. 四步搭建一条可靠链路
1. 分块：按语义边界切分（标题、段落），块大小 300-800 字，保留 10%-20% 重叠，并给每块写入来源、章节等元数据。
2. 双路召回：向量 top-20 + BM25 top-20，用 RRF（倒数排名融合）合并去重。
3. 重排：用 cross-encoder 类重排模型对候选片段打分，保留 top-3 到 top-5。
4. 生成约束：把片段编号后交给模型，要求「只基于给定片段回答，无法回答时明说」，并在输出里标注引用编号。
3. 评估比调参更重要
准备 30-50 条真实问题构成评测集，分别看召回命中率、答案正确率、无答案拒答率三个指标。没有评测集的 RAG 优化基本靠猜：换 embedding、调 chunk size、加重排，每一步都要用量化指标验证，否则很容易出现「局部变好、整体变差」。
适用场景与边界：适用于企业知识库、文档问答、客服话术检索、代码库检索等场景；数据量小于几百条时，直接全量放进上下文往往比 RAG 更简单可靠。
四、Agent 工作流设计
1. 先分清「工作流」和「自主 Agent」
工作流是把任务拆成固定步骤、由代码控制流转，模型只负责其中的判断和生成；自主 Agent 则把「下一步做什么」也交给模型决定。前者稳定、可测试、成本可控，后者灵活但容易跑偏。生产环境的主流做法是：主干用工作流，只在需要探索的分支上放开有限自主权。
2. 最小可靠闭环
规划：让模型输出结构化任务列表（目标、步骤、所需工具、验收标准）。
执行：按步骤调用工具，每次调用都设超时、重试上限和失败降级。
校验：用代码或第二个模型检查结果是否满足验收标准，而不是让模型自己说「完成了」。
记忆：只持久化结构化状态（已完成步骤、关键结论、待办），不要存原始对话全文。
3. 成本与稳定性控制
给每一步设置 token 预算和最大轮次，超过就直接进入兜底分支；把确定性环节（格式校验、数值计算、权限判断）交给代码而不是模型；对工具返回做清洗和截断，避免一次报错把上下文撑爆；记录每步的输入输出，出问题时能定位到具体环节而不是整体重跑。
适用场景与边界：适合资料整理、报告生成、代码修复、数据同步等多步骤任务；步骤少于三步且高度确定的任务，用普通脚本加一次模型调用就够了。
五、LoRA 微调
1. 什么情况下才需要微调
微调不是万能药。先确认三件事：提示词和 RAG 已经试过且效果不够、你有稳定的任务定义、你能拿到几百到几千条高质量样本。微调擅长的是「稳定输出风格与格式」「学习领域术语与判断标准」，不擅长注入频繁变化的事实知识——后者应该交给检索。
2. 关键参数怎么定
秩（rank）：8-64 之间起步，任务越接近「风格模仿」越小，越接近「新能力」越大。
学习率：通常比全量微调高一个量级，1e-4 到 2e-4 是常见起点。
数据：质量远比数量重要，500 条干净样本往往优于 5 万条噪声数据；样本要覆盖真实分布，包括「应该拒绝」的负例。
轮次：1-3 个 epoch 足够，过多容易过拟合到训练集的措辞上。
3. 数据格式与验证
训练数据统一成指令-输入-输出三段式，输出部分要和你线上期望的格式完全一致（包括标点、换行、JSON 缩进）。训练完成后必须做三组对照：原始模型、微调模型、微调模型 + 提示词，在同一批留出样本上比较，避免把「提示词带来的提升」误记成微调效果。
适用场景与边界：适合固定格式生成、垂直领域术语理解、风格统一的内容生产；知识频繁更新的场景应优先用 RAG，而不是反复微调。
六、推理模型使用技巧
1. 推理模型和普通模型用法不同
推理模型在内部会先展开较长的思考过程再给结论，因此它不是「更聪明的聊天模型」，而是「更适合复杂问题的模型」。用它做简单任务（改写、翻译、分类）会明显更慢更贵，且容易过度分析。判断标准很简单：需要多步推导、需要权衡约束、需要发现矛盾时用它；单步映射类任务用普通模型。
2. 把约束写清楚，而不是催它思考
「请仔细思考」「一步一步来」这类话对推理模型的边际收益很低，因为它本来就会思考。真正有效的是把验收标准写明确：输出必须满足哪些条件、哪些是硬约束、遇到冲突时优先级如何。约束越清晰，推理过程越短且越准。
3. 控制成本的两个开关
推理强度：多数 API 提供 low/medium/high 档位，简单任务降到 low 可以显著降低延迟和费用。
输出长度：给结论设字数上限，避免模型在结论里重复完整推导过程。
另外，推理模型不适合做高频、低价值的分支判断——把这类判断前置给规则引擎，只把真正的难题交给它。
适用场景与边界：适合数学与逻辑题、复杂代码调试、方案权衡、长链条数据分析；不适合高并发分类、简单改写、实时性要求极高的场景。
落地路径
第一步，小样本验证：挑 20-30 条真实输入，记录基线效果，只改一个变量做对照，避免一次性换掉整条链路。
第二步，固化成流程：把验证有效的配置写成模板或配置文件，纳入版本管理，让效果可复现。
第三步，上线并监控：记录准确率、延迟、单次成本三项指标，设置异常阈值，出现效果漂移时能快速回滚。
常见问题
Q：这些技巧需要重新训练模型吗？
不需要。上下文工程、检索重排、Agent 流程都属于推理侧优化，不改模型权重就能生效，成本也最低，优先从这里开始。
Q：效果怎么衡量？
固定一批 20-30 条真实输入作为评测集，每次只改一个变量，记录正确率、延迟和单次成本三项，避免凭感觉判断好坏。
Q：落地顺序怎么排？
一般按「上下文组织 → 检索质量 → 流程编排 → 微调」推进，前一步没有稳定前不要跳到下一步，否则问题会互相掩盖。
小结
以上五个方向覆盖了技术领域当前最值得关注的能力与用法。选择从哪里开始，建议先用自己业务里的 20-30 条真实样本做一轮对照测试，同时记录准确率、延迟和单次成本三个指标，再决定接入顺序。
💬 评论区 (0)
暂无评论，快来抢沙发吧！