RAG管知识，Agent管执行：FDE手里的两块技术基石

去年有个制造业客户，把二十年的技术图纸、BOM表、工艺文档一股脑塞给我，说："让AI帮工程师查料号、看图纸，别再让人翻三天档案了。"

我信了。

结果第一版上线，工程师问"MAT-001的公差是多少"，AI回答"根据公开资料，常见金属公差约±0.5mm"。

料号是客户私有的，图纸是客户私有的，公差也是客户私有的。模型答得越像那么回事，坑越大——因为它根本没看过那些文件，全靠"猜"。

这不是模型不行，是缺了两块基石：一块管"知识从哪来"，一块管"事怎么干"。这就是今天第八讲的主题——RAG 与 Agent 架构。

一、先认清 LLM 的三道致命伤

很多人以为，给模型接个数据库就完事了。没那么简单。大模型天生有三个缺陷，做企业交付时每一个都能让你翻车：

知识截止于训练日。 模型不知道你上周更新的价格表，也不知道你刚签的合同条款。

看不到企业私域数据。 客户的图纸、工单、历史邮件，模型一概没见过。

会一本正经地胡说（幻觉）。 你越让它"显得专业"，它编得越顺。

检索增强生成（RAG）就是为修这三道伤而生的：在模型开口之前，先去外部知识库把相关材料捞出来，塞进上下文，让它"基于真实信息说真话"。

它的好处不用重训模型就能让模型"懂"企业内部知识，每次回答还能追溯到出处，知识库一更新模型立刻跟上。

二、RAG 八环：从一堆 PDF 到可信回答

一个能上生产的 RAG 系统，不是"切文件+向量库"两步就完事。工业级链路有八个环节，FDE 得对每个的工程要点心里有数。

环一·资料盘点——不是所有 PDF 都该进库。 第一步是"选文件"不是"切文件"。一份过时的产品手册，进库只会让模型给出错误答案。这步要和业务方一起输出《知识库内容清单》，标清楚每份文档的版本、生效日、适用范围。

环二·文档解析——从非结构化到结构化。 制造业的 CAD 图纸、扫描件最难搞。要把图纸里的文字说明、BOM 表抽成可检索文本，还得保留表格结构和层级。常用 Unstructured、PyMuPDF 批量解析。

环三·分块——语义切分留重叠。 块太大塞进一堆无关信息，块太小丢了上下文。工业实践用语义切分，保住标题层级和段落完整，再加 50 token 左右的重叠窗口，防止边界语义被切断。

环四·嵌入——bge-m3 的多语言能力。 文本变向量才能被机器搜。bge-m3 是智源推出的多语言嵌入模型，中英文都稳，制造业场景表现好。维度通常 1024~4096，越高表达越强但检索越慢。

环五·检索——ANN 与阈值控制。 用户问题也转成向量，在库里找最相似的 Top-K。ANN（近似最近邻）在保精度的同时把速度拉满。工业实践常设 0.7 相似度阈值做过滤，低于它的不返回，避免模型基于不相关内容硬答。Milvus、Qdrant、Chroma、PgVector 按并发和部署要求选。

环六·重排序——交叉编码器提精度。 向量召回的"语义像但其实不相关"得二次排序。bge-reranker 把候选块和问题逐对打分，取 Top-N 进上下文，精度明显高于纯向量，代价是算力。

环七·生成——强制仅依上下文。 这是控幻觉的关键。System Prompt 里写死："上下文找不到就直说'我不知道'，不要编。" 检索相关性低于阈值直接拒答，绝不硬生成。

环八·引用——返回 Chunk ID 供审计。 每次回答必须带文档片段 ID 和来源链接。这不是锦上添花，是 FDE 在客户现场建立信任的硬机制。

▎ 八环里最容易被省掉的是环一和环八。但恰恰是这两个，决定了系统是"能用的"还是"能赖的"。

三、RAG 进阶：三个让准确率跳一截的工程

基础八环跑通后，三个进阶手段能把效果再拉一截：

混合检索（BM25 + 向量）。 纯向量对关键词不敏感，技术文档里满屏专业术语和编码。BM25 做关键词召回，向量做语义召回，两路合并再重排，制造业文档尤其吃这套。

查询改写。 用户常说"那个单子现在咋样了"——省略上下文让检索系统一脸懵。用 LLM 把原问题补成完整查询，比如把"那个单子"扩成"2024-03-15 客户张三的订单 ORD-20240315-001 的交付状态"。

多模态 RAG。 制造业大量知识在图纸、表格、图片里。把图像也转成向量统一入知识的库，检索时文本图像一起匹配，模型才"看得懂"图纸。难点在把图像和文本对齐到同一语义空间。

还有一个制造业特有的坑：表头重复策略。图纸表格常跨页，自动分页会把表头切没。分块时得检测表格结构，重复表头或保完整上下文，否则检索回来一段没表头的数据，模型根本读不懂。

四、从"知道"到"做到"：为什么还需要 Agent

RAG 解决了"知识从哪来"，但客户真正要的是"把事办了"。查到库存不足，谁来生成补货单？发现工单超时，谁去催？

这就是从"问答系统"到"自治系统"的跨越。Agent 架构把模型的文本生成能力，转化成可执行的智能行动。它要解决三个矛盾：静态知识库 vs 动态环境、单次推理 vs 复杂任务、通用能力 vs 垂直场景。

一个生产级 Agent 有七个面，构成完整执行闭环：

• 任务入口：收目标、解意图、初始化上下文。要防注入、做格式标准化。把"帮我查下那个订单"变成结构化的"查询订单状态（订单号：待补）"。
• 意图识别：拆子任务。说"安排下周会议"得拆成查日程→找空闲→建邀请→发通知。意图模糊时主动追问，而不是硬猜。
• 状态管理：短期记忆存当前对话和中间结果（Redis），长期记忆存跨任务知识和用户偏好（向量库）。要管上下文窗口、做注意力压缩。
• 工具选择：从工具库挑最优工具、生成参数。工具描述写多清楚，直接决定调用准不准——写"查询数据"模型能把天气新闻订单都当成范围；写"只查公司内部销售库，支持日期/品类/区域筛选"，它才不会乱调。
• 人审节点：高风险操作必须拦截等人工确认。自动退款超阈值就暂停，批了再走。这是"概率性工程"的实体化。
• 异常处理：超时、重试、降级、熔断、回滚。核心是幂等——同一参数调多次结果一致。每个工具定义明确错误码，比如 ERR_NO_AUTH、ERR_TIMEOUT、ERR_NOT_FOUND。
• 结构化输出：把结果格式化成 JSON Schema / 状态码，对接下游 ERP、CRM、工单系统。

▎ 七面里最值钱的是"人审节点"和"工具选择"。一个敢让模型自由发挥的 Agent，迟早在生产环境闯大祸。

五、Skill 与 MCP：把能力变成可复用资产

如果每接一个客户都重写一遍脚本，FDE 就退化成外包。要资产化，靠两样东西：Skill 封装和 MCP 协议。

Skill 封装把业务 SOP、执行脚本、领域知识打成结构化能力包。一个典型目录：

manufacturing-催单-skill/
├── SKILL.md          # 元数据(name/description/allowed-tools) + 指令步骤
├── scripts/          # send-reminder.py 发催单邮件, check-status.sh 查状态
└── references/       # customer-preference-table.md 客户偏好表

关键是渐进式加载：运行时不是一股脑全塞给模型，而是三级——元数据常驻（用于选技能）、核心指令选中才加载、资源层按步骤拉。这样 Agent 能掌握上百个技能，但某次任务只专心处理真正相关的那几个。

MCP（模型上下文协议）解决的是"工具太多、适配爆炸"的问题。它把外部能力抽象成三种标准原语：Tools（可执行）、Resources（只读数据）、Prompts（预定义模板）。架构是 Host/Client/Server 三元——Host 是面向用户的 AI 应用，Server 是每个外部系统的适配层。对 Host 开发者，不关心具体 API 差异，接一次 MCP 就行；对系统方，实现一个 MCP Server 就能被所有支持 MCP 的 Host 调用。

工具调用的 JSON Schema 必须写严谨，否则模型瞎填参：

{
  "type": "function",
  "function": {
    "name": "query_inventory",
    "description": "查询指定仓库库存，支持物料编码或仓库ID过滤",
    "parameters": {
      "type": "object",
      "properties": {
        "material_code": { "type": "string", "description": "物料编码，如 'MAT-001'" },
        "warehouse_id": { "type": "string", "description": "仓库ID，如 'WH-01'" }
      },
      "required": []
    },
    "error_codes": {
      "ERR_NO_AUTH": "调用者无权限查询该仓库",
      "ERR_TIMEOUT": "数据库查询超时，建议缩小范围"
    }
  }
}

参数、权限、错误码一个都不能省。省一个，模型就多一个翻车点。

六、连起来：Agent 的执行循环

RAG 和 Agent 接上之后，系统的节奏是一个持续循环：

用户给目标 → 规划拆步骤 → 模型读记忆判下一步 → RAG 检索知识库 → 工具系统执行动作 → 结果写回记忆 → 不一致就重新规划 → 直到完成或触发人工接管

这段逻辑里最关键的是控制权。模型可以建议下一步，但真正的执行、权限、限流、审计、失败恢复，必须由业务系统掌控。生产级 Agent 不是让模型自由发挥，是把模型放进一个可控的执行框架里。

结语

第八讲结束，你拿到了 FDE 的两块技术基石：RAG 管线解决知识的来源与可信，Agent 架构解决能力的执行与可控。下一篇，我们进入交付实战，看看怎么在客户现场从一片混沌里，把这两块基石搭成能跑的生产系统。

《智能体工程化交付（FDE）实战十五讲》第八讲。本讲实训：用 Dify 或 LangChain 搭一条含矛盾文档的 RAG 管线测抗幻觉率，为"库存查询"写完整 JSON Schema 工具定义，并把"库存查询+低库存预警"封装成一个 Skill。