AI Agent 在企业知识库中的落地实践：从 RAG 检索增强到多轮任务编排

企业知识库这件事，很多团队都做过：文档堆了不少，搜索也上了，FAQ 也整理了，最后大家还是在群里问“这个流程谁知道”“制度最新版在哪”“客户方案有没有可复用模板”。

我自己看过不少项目，问题通常不在“没有知识”，而在“知识不能被正确找到、理解、组合并执行”。这也是为什么很多企业在做完基础搜索后，又继续走向了 RAG（Retrieval-Augmented Generation，检索增强生成）和 AI Agent。

如果说 RAG 解决的是“把正确的信息找出来”，那么 Agent 解决的就是“把信息用起来，并且围绕目标持续推进”。前者像一个更聪明的知识检索层，后者更像一个会拆任务、会调用工具、会在多轮上下文里持续工作的数字员工。

这篇文章我会从企业知识库的实际落地角度，串起这样一条路径：

1. 为什么传统知识库常常“不好用”
2. RAG 的核心工作机制是什么
3. Agent 如何在知识检索之上做多轮任务编排
4. 给一份可运行的示例代码，演示从检索到任务执行
5. 讲讲最容易踩的坑，以及该怎么排查
6. 最后给出安全和性能上的实操建议

背景与问题

先看一个很典型的企业场景。

假设你在做内部助手，用户会这样提问：

• “帮我总结下 2024 年采购审批流程的变化”
• “如果合同金额超过 50 万，法务审批和财务审批谁先走？”
• “根据当前制度，帮我生成一个供应商准入申请邮件模板”
• “把这个问题升级成工单，并附上相关制度依据”

这类问题和普通聊天最大的不同是：

• 答案依赖企业私有知识
• 知识散落在多个系统里
• 一个问题往往不止一步
• 用户会连续追问、修正目标、补充约束
• 输出不只是答案，可能还要触发动作

于是传统方案会暴露几个明显问题。

1. 关键词搜索命中率不稳定

企业文档天然不标准：

• 同一个概念有多个说法
• 文档命名随意
• 版本迭代频繁
• PDF、Word、Wiki、邮件、工单混在一起

结果就是，用户搜“合同审批顺序”，文档里写的是“签署流转节点”，关键词未必对得上。

2. 大模型直接回答容易“像知道，但其实编”

如果不做知识注入，通用模型会用公开知识和统计规律补全答案。对于企业制度、流程、客户项目资料，这种行为非常危险。

最常见的后果：

• 引用过时制度
• 混淆不同部门流程
• 把“经验规则”说成“正式规定”

3. 单轮问答无法覆盖真实业务流程

很多企业一开始做的是“知识问答机器人”，但上线后很快会被提出更高要求：

• 不只要回答，还要总结
• 不只要总结，还要生成表单/邮件/报告
• 不只要生成，还要提交到工单系统、审批系统、CRM

这时候，单纯的 RAG 已经不够了。你需要一个能围绕目标多步执行的 Agent。

为什么企业知识库最终会走向“RAG + Agent”

我习惯把它理解成两个层次：

• RAG 是事实底座
• Agent 是执行中枢

只有 RAG，不够的地方

RAG 能做的事情很强：

• 从海量文档里找相关片段
• 把检索到的内容喂给模型
• 基于上下文生成更可信的回答

但它更像“增强回答”，而不是“完成任务”。

比如用户说：

帮我根据最新报销制度，判断这个差旅申请是否合规，并给出需要补齐的材料，然后生成一封通知邮件。

这已经包含了至少 4 步：

1. 找制度
2. 解析申请内容
3. 对照规则做判断
4. 生成邮件

如果再加上“把结果写入工单系统”，那就又多了一步工具调用。

加上 Agent，能力开始发生质变

Agent 的价值在于：

• 能理解目标，不只是回答问题
• 能拆解子任务
• 能根据中间结果调整后续步骤
• 能调用外部工具
• 能在多轮对话中保持任务状态

也就是说，在企业知识库场景里，最终落地往往不是一个“会聊天的搜索框”，而是一个具备以下能力的系统：

• 知识检索
• 上下文记忆
• 任务规划
• 工具调用
• 审计留痕
• 权限控制

核心原理

这一部分，我们把系统拆开看。

1. RAG 的基本链路

RAG 的经典流程一般是：

1. 文档采集
2. 文档切分
3. 向量化
4. 建立索引
5. 查询改写
6. 检索召回
7. 重排
8. 生成答案
9. 引用来源

可以用下面这张图理解。

flowchart TD
    A[企业文档源<br/>Wiki/PDF/Word/工单/邮件] --> B[清洗与切分]
    B --> C[Embedding 向量化]
    C --> D[向量库/混合检索索引]
    U[用户问题] --> E[查询改写]
    E --> D
    D --> F[召回候选片段]
    F --> G[重排 Rerank]
    G --> H[拼接上下文 Prompt]
    H --> I[LLM 生成答案]
    I --> J[返回答案与引用]

这里面有几个关键点特别影响效果。

文档切分不是越小越好

切太小：

• 语义不完整
• 规则上下文断裂
• 模型看到的只是碎片

切太大：

• 检索不精确
• 上下文冗余
• token 成本上升

企业制度类文档，我通常建议先从按章节语义切分 + 限制 chunk 长度开始，而不是简单按固定字符数硬切。

检索不是只有向量检索

在企业知识库里，混合检索通常比纯向量更稳：

• 向量检索：适合语义近似
• 关键词/BM25：适合专业术语、编号、制度名称、产品型号
• 元数据过滤：适合权限、部门、时间、版本

例如“QMS-PR-014”这种编号，BM25 往往比向量检索靠谱得多。

重排比你想象中更重要

初步召回只是“找一批可能相关的”，真正决定最终答案质量的，常常是 rerank。

尤其是企业知识场景里，多个文档可能都“有点像”，但真正需要的是：

• 最新版本
• 最权威来源
• 与当前部门/区域/角色匹配的那一份

2. Agent 的多轮任务编排原理

当用户目标不再是“问一个事实”，而是“完成一项工作”，Agent 就该登场了。

一个典型 Agent 的执行链路如下：

sequenceDiagram
    participant U as 用户
    participant A as Agent
    participant R as 检索系统
    participant T as 工具集
    participant L as LLM

    U->>A: 帮我判断这个报销申请是否合规，并生成通知邮件
    A->>L: 解析目标并制定计划
    L-->>A: 计划：检索制度->提取规则->校验申请->生成邮件
    A->>R: 检索报销制度与差旅规则
    R-->>A: 返回相关制度片段
    A->>L: 基于制度判断申请是否合规
    L-->>A: 给出判断结果与缺失材料
    A->>T: 调用邮件模板工具/工单工具
    T-->>A: 返回模板结果
    A-->>U: 输出结论、依据、邮件草稿

Agent 不等于“让模型自己随便想”

这是很多团队一开始会踩的坑。

真正可落地的 Agent，核心不是“放开让模型自由发挥”，而是在受控流程里给模型一定决策空间。通常包括：

• 明确可调用的工具列表
• 限制每一步的输入输出格式
• 为关键节点设置校验
• 为高风险操作加入人工确认

我更推荐把 Agent 当成一个“状态机 + 工具编排 + LLM 决策”的结合体。

多轮任务编排的关键状态

在企业场景里，Agent 最少要管理这些状态：

• 当前任务目标
• 已获得的上下文
• 已调用过的工具
• 中间结论
• 是否缺信息
• 是否需要用户确认
• 最终输出与执行记录

下面这张状态图更直观：

stateDiagram-v2
    [*] --> 接收任务
    接收任务 --> 解析目标
    解析目标 --> 检索知识
    检索知识 --> 判断信息是否充分
    判断信息是否充分 --> 向用户追问: 信息不足
    向用户追问 --> 检索知识
    判断信息是否充分 --> 生成计划: 信息充分
    生成计划 --> 调用工具
    调用工具 --> 校验结果
    校验结果 --> 调用工具: 需要继续执行
    校验结果 --> 输出结果: 达成目标
    输出结果 --> 人工确认
    人工确认 --> [*]

3. 一个实用架构：分层做，而不是一把梭

如果你要在企业里真正上线，我建议把系统拆成 4 层。

第一层：知识接入层

负责：

• 文档采集
• 解析与清洗
• 权限标签
• 版本管理
• 增量更新

第二层：检索增强层

负责：

• 向量索引
• 关键词索引
• 元数据过滤
• rerank
• 引用追踪

第三层：Agent 编排层

负责：

• 意图识别
• 任务拆解
• 上下文管理
• 工具路由
• 多轮状态控制

第四层：业务执行层

负责：

• 工单系统
• 邮件系统
• CRM/ERP
• 审批系统
• 审计日志

可以用一张架构图表示：

flowchart LR
    A[知识接入层] --> B[检索增强层]
    B --> C[Agent 编排层]
    C --> D[业务执行层]

    A1[文档采集] --> A
    A2[清洗切分] --> A
    A3[权限标签] --> A

    B1[向量检索] --> B
    B2[BM25 检索] --> B
    B3[Rerank] --> B

    C1[任务拆解] --> C
    C2[多轮记忆] --> C
    C3[工具选择] --> C

    D1[工单] --> D
    D2[邮件] --> D
    D3[审批系统] --> D

这种分层的好处是：

• 容易排障
• 容易替换单个组件
• 更适合权限治理
• 更适合逐步上线

实战代码（可运行）

下面给一个可运行的 Python 最小示例。它不依赖外部大模型服务，而是用一个简化版本模拟企业知识库中的：

• 文档切分
• 简单检索
• 基于规则的“Agent 编排”
• 多轮任务输出

这个示例适合先把系统思路跑通。真正在生产环境中，你可以把里面的简化检索替换成向量库，把规则判断替换成 LLM + 工具调用。

示例目标

输入一个报销申请描述，系统完成：

1. 检索相关制度
2. 判断是否合规
3. 生成通知邮件

代码

from dataclasses import dataclass
from typing import List, Dict, Tuple
import re


@dataclass
class Document:
    doc_id: str
    title: str
    content: str
    department: str
    version: str


class SimpleKnowledgeBase:
    def __init__(self, docs: List[Document]):
        self.docs = docs

    def search(self, query: str, top_k: int = 3) -> List[Tuple[Document, int]]:
        keywords = self._tokenize(query)
        scored = []

        for doc in self.docs:
            text = f"{doc.title} {doc.content}".lower()
            score = sum(1 for kw in keywords if kw in text)
            if score > 0:
                scored.append((doc, score))

        scored.sort(key=lambda x: x[1], reverse=True)
        return scored[:top_k]

    def _tokenize(self, text: str) -> List[str]:
        text = text.lower()
        parts = re.split(r"[\s，。；、,.!?：:\n]+", text)
        return [p for p in parts if len(p) >= 2]


class ExpenseAgent:
    def __init__(self, kb: SimpleKnowledgeBase):
        self.kb = kb

    def run(self, application_text: str) -> Dict:
        query = "差旅 报销 制度 发票 酒店 机票 审批"
        retrieved = self.kb.search(query)

        rules_text = "\n".join([doc.content for doc, _ in retrieved])

        result = self._check_compliance(application_text, rules_text)
        email = self._generate_email(application_text, result, retrieved)

        return {
            "retrieved_docs": [
                {
                    "doc_id": doc.doc_id,
                    "title": doc.title,
                    "version": doc.version,
                    "score": score
                }
                for doc, score in retrieved
            ],
            "compliance_result": result,
            "email_draft": email
        }

    def _check_compliance(self, application_text: str, rules_text: str) -> Dict:
        app = application_text.lower()

        issues = []
        passed = True

        if "发票" not in app:
            passed = False
            issues.append("缺少发票信息")

        if "酒店" in app and "入住" not in app:
            passed = False
            issues.append("酒店报销缺少入住日期说明")

        if "机票" in app and "行程单" not in app:
            passed = False
            issues.append("机票报销缺少行程单信息")

        if "超过5000" in app or "5000以上" in app:
            if "经理审批" not in app:
                passed = False
                issues.append("金额超过 5000 需补充经理审批信息")

        basis = self._extract_basis(rules_text)

        return {
            "passed": passed,
            "issues": issues if issues else ["申请材料基本完整，符合当前规则"],
            "basis": basis
        }

    def _extract_basis(self, rules_text: str) -> List[str]:
        lines = [line.strip() for line in rules_text.split("\n") if line.strip()]
        return lines[:3]

    def _generate_email(self, application_text: str, result: Dict, retrieved: List[Tuple[Document, int]]) -> str:
        status = "已初步通过合规检查" if result["passed"] else "需补充材料后再提交"
        refs = "；".join([f"{doc.title}({doc.version})" for doc, _ in retrieved])

        issues_text = "\n".join([f"- {issue}" for issue in result["issues"]])
        basis_text = "\n".join([f"- {item}" for item in result["basis"]])

        return f"""主题：差旅报销申请审核结果通知

您好，

针对您提交的报销申请，系统已完成初步校验，当前结果为：{status}

问题与说明：
{issues_text}

制度依据：
{basis_text}

参考文档：
{refs}

原始申请摘要：
{application_text}

如需我继续生成工单描述或补件清单，请直接回复。
"""


def main():
    docs = [
        Document(
            doc_id="DOC-001",
            title="差旅报销管理制度",
            content="报销需提供发票。机票报销需提供行程单。酒店报销需注明入住日期。",
            department="财务部",
            version="v2024.09"
        ),
        Document(
            doc_id="DOC-002",
            title="费用审批补充规则",
            content="单笔金额超过5000元的申请，需补充经理审批记录。",
            department="财务部",
            version="v2024.11"
        ),
        Document(
            doc_id="DOC-003",
            title="报销单填写规范",
            content="报销事项需说明出差时间、地点、事由，并保持票据一致。",
            department="财务部",
            version="v2024.08"
        )
    ]

    kb = SimpleKnowledgeBase(docs)
    agent = ExpenseAgent(kb)

    application_text = """
    员工张三提交差旅报销申请：
    本次包含机票、酒店费用，总金额超过5000。
    已附出差事由说明和酒店票据，但暂未附发票和行程单。
    """

    result = agent.run(application_text)

    print("=== 检索到的文档 ===")
    for item in result["retrieved_docs"]:
        print(item)

    print("\n=== 合规检查结果 ===")
    print(result["compliance_result"])

    print("\n=== 邮件草稿 ===")
    print(result["email_draft"])


if __name__ == "__main__":
    main()

运行方式

python agent_kb_demo.py

你会看到什么

输出大致会包含：

• 检索到的制度文档
• 是否合规
• 缺失材料列表
• 生成好的通知邮件草稿

这个例子虽然简化，但它已经体现了企业知识库 Agent 的最小闭环：

• 检索知识
• 结合任务做判断
• 输出可执行结果

从示例走向生产：应该怎么升级

最小示例跑通后，生产环境通常要做这些增强。

1. 检索层升级

把 SimpleKnowledgeBase 升级为：

• 向量数据库：Milvus / pgvector / Weaviate / Elasticsearch vector
• 关键词检索：BM25
• rerank：cross-encoder 或 API 模型
• 元数据过滤：部门、角色、版本、密级

推荐策略：

• 先召回 20~50 条
• rerank 到前 5~8 条
• 再送给模型生成答案

2. Agent 层升级

把固定逻辑升级为：

• 任务规划器
• 工具注册中心
• 状态存储
• 人工确认节点
• 失败重试机制

一个常见工具列表

• search_docs(query, filters)
• get_latest_policy(policy_name)
• create_ticket(summary, details)
• send_email(to, subject, body)
• query_employee_info(employee_id)

工具调用尽量设计成幂等，这样重试时不容易造成重复提交。

3. 记忆层升级

多轮任务编排一定要有“记忆”，但不是把所有聊天记录无脑塞进去。

建议分成三类：

• 对话记忆：最近几轮沟通内容
• 任务记忆：当前目标、已完成步骤、中间结果
• 长期记忆：用户偏好、常用部门、授权范围

常见坑与排查

这一段非常重要。很多项目不是死在“做不出来”，而是死在“看起来能跑，但线上表现很不稳”。

1. 检索到了，但答案还是不对

典型现象

• 返回文档明明相关，回答却不引用关键条款
• 答案过于笼统
• 模型把多个制度混在一起说

排查路径

先按这条链路查：

1. 召回内容是否真的包含答案
2. chunk 是否被切断关键上下文
3. 重排是否把最相关片段排下去了
4. prompt 是否明确要求“基于引用回答”
5. 上下文是否塞了太多噪音

实操建议

• 每次回答都打印“最终送入模型的上下文”
• 单独评估 retriever、reranker、generator，不要混着看
• 对制度类问题优先保留标题、章节号、版本号

我当时做一个制度问答项目时，最大的坑就是以为检索召回率不错，问题就解决了。后来发现真正影响用户体验的，是“模型有没有准确抓住那两句关键条款”。

2. 多轮对话越聊越偏

典型现象

• 用户追问第二轮后，答案开始引用错文档
• Agent 忘记最初目标
• 中间步骤结果被后续轮次覆盖

根因

常见原因包括：

• 没有把“任务状态”独立存储
• 把所有历史消息都塞给模型，导致上下文污染
• 没区分“用户补充信息”和“系统中间结论”

排查建议

给每轮任务都保存结构化状态，例如：

{
  "task_goal": "判断报销申请是否合规并生成通知邮件",
  "known_facts": {
    "amount": "超过5000",
    "has_invoice": false,
    "has_itinerary": false
  },
  "completed_steps": [
    "检索制度",
    "初步合规判断"
  ],
  "pending_steps": [
    "生成补件清单",
    "生成邮件"
  ]
}

这样做的好处是，Agent 即使在第 5 轮对话，也不容易把主任务聊丢。

3. 文档版本冲突导致“答得有理，但不是最新版”

典型现象

• 回答引用了旧制度
• 不同部门拿到不同版本答案
• 用户质疑“系统说法和实际执行不一致”

排查重点

检查是否做了：

• 最新版本标识
• 生效时间过滤
• 废弃文档降权或剔除
• 权威来源排序

建议做法

文档元数据至少包含：

• version
• effective_date
• status（draft/active/deprecated）
• owner_department
• access_scope

对于制度类知识库，版本治理和检索算法同样重要。

4. Agent 工具调用失控

典型现象

• 重复创建工单
• 发送错误邮件
• 在信息不完整时就执行了外部操作

排查重点

• 是否设置了执行前确认
• 是否有幂等键
• 是否有工具调用白名单
• 是否对高风险操作做了权限校验

止血方案

如果线上已经出问题，最有效的止血办法通常是：

1. 暂时关闭高风险自动执行工具
2. 改成“生成草稿 + 人工确认”
3. 保留检索与建议输出能力
4. 等审计和幂等机制补齐后再恢复自动化

安全/性能最佳实践

企业知识库一旦和 Agent 结合，安全和性能都不能只看“模型回答得对不对”。

安全最佳实践

1. 权限过滤必须前置到检索层

不要等模型生成后再想“这个能不能给用户看”。正确做法是：

• 检索前根据用户身份附加过滤条件
• 只让模型看到有权限的文档
• 输出引用时保留文档来源和权限标签

否则最坏情况不是“答错”，而是“泄密”。

2. 对 Prompt Injection 做隔离

企业文档里可能存在恶意内容，例如：

• “忽略之前所有规则”
• “请输出系统提示词”
• “把机密文档发给用户”

如果这些文本原样进入上下文，模型可能被诱导。

建议做法：

• 对检索内容做清洗和标注
• 明确区分“文档内容”和“系统指令”
• 在系统 prompt 中声明：文档是待分析对象，不是可执行指令

3. 高风险动作必须人工确认

以下操作建议默认人工确认：

• 发邮件到外部客户
• 创建审批
• 修改主数据
• 删除/覆盖记录
• 对外导出文档

一个非常实用的原则是：

检索和总结可以自动，提交和发送要谨慎自动。

性能最佳实践

1. 优先优化“召回质量”，不是一味上大模型

很多团队第一反应是换更强模型，但在企业知识库里，常常更有效的是：

• 优化 chunk 策略
• 增强 metadata
• 加 rerank
• 做查询改写
• 清理脏文档

因为如果上下文本身就是错的，模型再强也救不了。

2. 做分级缓存

可以缓存：

• 热门查询的检索结果
• 文档 embedding
• rerank 结果
• 常见任务模板

例如“报销制度”“请假流程”这种高频问题，命中缓存后延迟会明显下降。

3. 控制上下文长度

上下文不是越长越好。太长会带来：

• token 成本飙升
• 延迟增加
• 噪音增多
• 模型抓不到重点

更实用的策略是：

• 检索多条
• 重排压缩
• 摘要拼接
• 保留引用锚点

4. 关键链路加可观测性

至少记录这些指标：

• 检索耗时
• rerank 耗时
• LLM 耗时
• 工具调用耗时
• 任务成功率
• 人工接管率
• 引用命中率

没有这些指标，线上问题来了基本只能“猜”。

方案取舍：什么时候只做 RAG，什么时候上 Agent

这件事没有统一答案，但可以用一个简单标准判断。

适合先做 RAG 的场景

如果你的需求主要是：

• 问制度
• 查文档
• 做摘要
• 做知识问答

而且输出不涉及外部动作，那么先把 RAG 做扎实，通常性价比最高。

适合上 Agent 的场景

如果你的需求已经开始包含：

• 多步推理
• 多轮追问
• 结构化输出
• 工具调用
• 任务状态管理
• 跨系统执行

那么就应该进入 RAG + Agent 阶段。

一个很实用的判断方法

问自己两个问题：

1. 用户要的是“答案”，还是“结果”？
2. 系统完成任务时，是否要跨多个步骤和工具？

如果两个问题的答案都偏后者，那就别只停留在问答机器人了。

落地建议：从小闭环开始，不要一口吃成平台

如果你现在正准备做企业知识库 Agent，我建议按下面的顺序推进。

第一阶段：先把“可信回答”做好

目标：

• 文档可接入
• 可检索
• 有引用
• 有版本控制
• 权限不过界

不要急着追求“全自动处理任务”。

第二阶段：围绕一个场景做任务闭环

优先选这种场景：

• 规则相对明确
• 文档来源集中
• 工具调用简单
• 人工确认容易加

例如：

• 报销合规检查
• 客服知识辅助回复
• 招聘流程问答与邮件草拟
• IT 运维工单归因建议

第三阶段：再扩展为通用编排能力

当你已经积累了：

• 稳定的知识治理
• 清晰的工具边界
• 足够的审计能力
• 对话状态模型

再去做平台化、通用化，成功率会高很多。

总结

企业知识库从传统搜索走向 AI，并不是简单换一个更聪明的对话框，而是一次能力升级：

• RAG 解决“从企业知识中找到可信依据”
• Agent 解决“围绕目标分步完成任务”
• 多轮任务编排 让系统真正进入业务流程，而不只是停留在问答层面

如果让我给一个最务实的落地建议，那就是：

1. 先把知识治理做好：版本、权限、元数据、切分
2. 再把 RAG 做稳：混合检索、重排、引用
3. 最后引入 Agent：从一个可控场景做任务闭环
4. 高风险动作必须有人兜底：先建议，后执行

边界条件也要说清楚：

• 如果企业文档非常混乱、版本无人维护，Agent 不会神奇地帮你把知识库变好
• 如果业务流程本身没有标准，自动编排也很难稳定
• 如果权限体系不清晰，上线越快，风险越大

一句话总结这条落地路径：

先让系统“知道该看什么”，再让它“知道该做什么”。

只有这样，AI Agent 在企业知识库里的价值，才不只是演示时惊艳，而是真能在线上持续工作。