拓冰网站定制 
这两年最常被问到的一个问题就是企业内部的知识助手到底该怎么落地。很多团队的路径出奇地一致先上一套 RAG 把文档问答跑通然后跑着跑着发现“只能答不能做”再往上加 Agent 能力让系统能调用工具、能主动检索多轮信息、能完成跨系统操作。这条路几乎成了企业知识助手开发的默认路线也确实是踩坑最少的一条路。这篇文章就围绕“从 RAG 到 Agent”这条演进线索讲清楚一个完整的企业知识助手是怎么一步步搭起来的。我会拆解 RAG 的原理与瓶颈、Agent 化改造的关键设计并给出完整的工程实现和踩坑记录。适合正在做知识问答类应用的研发同学也适合准备把 LLM 接入企业业务但还在观望的团队参考。1. 为什么企业知识助手的选择是“先 RAG后 Agent”1.1 RAG 到底解决的是什么问题先说清楚 RAG 是什么。RAG 的全称是 Retrieval-Augmented Generation检索增强生成。它的核心思路很直白大模型不是万能的尤其在企业内部知识面前它既不知道你们的产品文档写了什么也不知道你们内部流程走的是哪套审批逻辑。所以与其指望模型记住这些不如先把知识存在外部每次问答前先检索出相关内容再把“问题 检索到的资料”一起丢给模型生成答案。这句话听起来简单但它是整个企业知识助手的逻辑起点。做 RAG 的本质不是写个检索接口而是重新定义“知识怎么存放、怎么被找到、怎么被使用”这三件事。企业内部的知识形态高度混合有 Word 文档、PDF、PPT、网页、表格、甚至聊天记录里的经验碎片。RAG 的价值在于把这些异构内容统一成同一种形态——文本向量——然后用语义相似度来召回。用户问“报销流程怎么走”不需要文档里出现“报销”两个字只要语义相关向量检索也能找得到。这也是 RAG 比微调更适合企业知识场景的根本原因。微调意味着把知识压进模型参数里每次知识更新都要重新训练成本高、周期长、还容易让模型“记串了”。RAG 则把知识留在外部更新知识就是更新索引模型本身不动幻觉风险也相对可控。对于知识频繁变动的企业场景RAG 几乎是唯一在成本和效果之间取得平衡的方案。1.2 为什么最终要走向 AgentRAG 能解决“从文档中找答案”但解决不了“复杂任务需要多步处理”的问题。举几个真实场景你就能感受到差距。第一个场景用户问“帮我对比一下 A 产品和 B 产品在安全认证方面的差异”这不是一次检索能搞定的需要先定位 A 产品的认证文档再找 B 产品的资质材料可能还要查一个第三方的认证标准最后汇总对比。第二个场景用户问“下周要提交给客户的方案帮我拉一下最近三个项目的技术细节”这已经不只是问答了这是要跨文档、跨系统、带条件的任务。第三个场景更典型用户说“查一下这个故障码在运维手册里的处理方法然后按格式生成一张工单”这里面有检索动作、有格式变换、还可能涉及调用工单系统接口。这些需求暴露了 RAG 的硬瓶颈RAG 是无状态的“检索-生成”单轮通道没有规划能力没有工具调用能力也没有多步推理能力。而 Agent 恰恰补上的是这三样。Agent 的本质是让大模型不再只是“回答者”而是“决策者”和“执行者”。它自己做任务拆解决定先检索什么、再干什么甚至在需要时调用外部工具完成动作。所以企业知识助手的完整形态往往不是纯 RAG 也不是纯 Agent而是从 RAG 这个“阅读理解能力”出发叠加 Agent 的“任务执行能力”。2. RAG 的五大瓶颈这是升级 Agent 的直接理由2.1 检索层的先天缺陷固定 Top-K 与语义盲区所有 RAG 系统第一个碰到的痛点就是“检索结果不稳定”。你设了 Top-K5可能用户问的问题只需要 3 段资料就够了多出来的 2 段反而干扰了模型回答换个问题5 段又不够真正关键的文档排在第 6 位模型根本没看到。这就是固定 Top-K 的结构性缺陷。另一个更隐蔽的问题是纯向量检索的语义盲区。向量检索擅长找“意思相近”的内容但在处理精确匹配时非常弱。比如用户输入一个产品型号“SG-2000”向量检索很可能把“SG-2000 Pro”“SG-2000 Mini”都当成相似内容拉出来而文档里所有提到“SG-2000”的段落全部命中后真正包含技术参数的章节反而因为文本太短、向量距离不够近而被漏掉。还有代码片段、IP 地址、工单号、合同编号这类高精度信息用向量检索完全是不擅长的。这也是后来要引入混合检索、关键词倒排索引甚至 Agent 检索规划的原因所在。2.2 编排层的僵硬单轮问答撑不起复杂任务RAG 的标准链路是“一问一检一答”这个链路在简单问答上没问题但撑不起复杂任务。典型现象是用户的问题涉及多个知识域比如“这个设备的保养周期是多少如果超期未保养会影响质保吗”前半个问题属于运维手册后半个问题可能藏在商务合同条款里。普通 RAG 会把两个子问题混在一次检索里结果召回的文档两边都没完全覆盖。这种问题的本质是 RAG 缺少“查询规划”的能力它不知道把问题拆成子问题、分路检索再汇总。有些团队试图靠一个复杂 Prompt 让模型先生成检索词、再检索、再回答这个方向的尽头就是 Agent因为一旦进入“根据查询结果决定下一步查什么”的循环你实际上已经是在写 Agent 的 ReAct 逻辑了。2.3 知识表示层面的冲突RAG 与 KG 的分工很多团队会问一个问题RAG 知识库和知识图谱KG到底有什么区别什么时候该用哪个我的判断是这样的RAG 适合非结构化文本的语义召回KG 适合实体关系和结构化事实的精确查询。前者擅长“找内容”后者擅长“找关系”。举个例子员工问“A 项目的负责人是谁他之前负责过哪些项目”如果只靠 RAG系统检索到的是提到这个人的若干段落需要模型自己从中把实体关系抽出来准确率看运气。如果知识库里同时有一张图谱节点是人、项目、角色边是“负责”“参与”“汇报给”这类关系这个问题就可以直接走图谱查询拿到确定答案。所以成熟的企业知识助手往往底层是 RAG KG 两条检索通道由 Agent 判断问题更适合走哪条路或者两条都走、再做结果融合。这也是从 RAG 向 Agent 升级时一个非常重要的结构性变化。2.4 缺失记忆与个性化企业知识助手的隐性问题RAG 的另一个硬伤是没有记忆。用户问“刚才那份合同里约定的付款条件是什么”系统无法正确理解“刚才”指的是哪一份合同。用户连续问了三个关于安全审计的问题系统也不会把上下文串联起来形成一份连续的分析。这在个人使用场景里只是体验问题但在企业场景里是效率问题。员工希望知识助手记住自己在看哪个项目、关注哪个客户、上次查过什么这样后续问题不用重复交代背景。Agent 框架天然具备解决这个问题的结构——记忆机制。对话记忆保存短期上下文向量记忆保存长期偏好实体记忆保存用户关注的对象。一个带记忆的 Agent才能做到真正贴合使用者。第 3 章我会详细展开这块设计。2.5 企业级安全与权限这是最容易被低估的坑RAG 早期落地时大家只顾着“答得准不准”忽略了一个致命问题企业内部知识是有权限边界的。销售不该看到研发内部的缺陷报告外包人员不该接触核心财务数据但纯 RAG 把所有人的提问都映射到了同一个知识库上本质上是一次信息越权通道。要堵住这个洞至少要做三层隔离检索前校验提问者身份与权限范围检索时按权限过滤知识库或文档集生成后对答案做脱敏检查。这三层逻辑在 RAG 架构里做起来非常别扭因为知识库和检索链路是静态的。但在 Agent 架构下就顺理成章了因为 Agent 本身就带工具调用链路把“检索”封装成一个受控工具在工具内部做权限判断在规划层控制工具使用范围安全策略从“全局一把锁”变成了“每个动作一把锁”。3. Agent 化改造的核心机制与架构设计3.1 ReAct 循环Agent 的“想一步做一步”Agent 最核心的机制是 ReAct也就是 Reason Act 的循环。大模型在每一轮先分析当前状态、决定下一步动作执行动作后观察结果再根据结果继续推理。这个循环可以类比成一个人查资料的过程先想“这个问题需要查什么”然后去翻文件看到文件里提到了另一个部门又去问那个部门的负责人最后把信息整合成答案。在工程实现上ReAct 循环通常由三部分组成大模型充当推理中枢工具集提供执行能力循环控制器负责调度。大模型输出的是“行动指令”比如调用 search_knowledge_base(查询词) 或者 calculator(表达式)控制器接收指令后调用对应的工具函数拿到真实结果后把它作为观察信息回传给大模型模型再决定是继续行动还是输出最终答案。这个过程循环往复直到模型认为信息足够、输出答案或者到达预设的最大迭代次数。理解 ReAct 是理解 Agent 的分水岭。很多人以为 Agent 就是一个会调 API 的聊天机器人其实 Agent 的真正能力来自“规划—执行—观察—再规划”的循环每多走一轮系统对任务的理解就深一层。3.2 一个企业知识助手的整体架构设计我在这里给出一个已经在实际项目中稳定跑通的架构你可以直接作为参考。整体上分为四层接入层、Agent 编排层、工具层、知识层。接入层负责统一接收来自 Web 端、企业微信、钉钉或聊天界面的用户请求做身份认证与权限上下文组装。Agent 编排层是核心大脑包含任务规划、ReAct 循环、记忆管理三个模块。工具层是一组可被模型调用的函数集合典型工具有知识库检索工具、KG 查询工具、SQL 查询工具、工单创建工具、日程工具。知识层则是底层的数据资产包括文档向量库、结构化数据库、知识图谱和外部 API。这套架构的关键在于知识库不再是唯一的知识来源而是作为 Agent 的一个工具存在。模型决定“是否需要检索、检索什么”而不是每次问答都强制检索。这样一来简单问题直接用模型常识回答需要查证的问题才走检索工具复杂任务则自动规划多条行动路径。整个系统的灵活性和准确性都上了一个台阶。3.3 技术选型对比LangChain、Dify 与 CrewAI 怎么选做 Agent 化改造时团队绕不开框架选型的问题。这三者的定位其实完全不同LangChain 是开发库Dify 是应用平台CrewAI 是多 Agent 编排框架。选型的关键是看你的团队在哪个层级做事情。如果你们是研发团队需要对流程深度定制比如自定义工具调用逻辑、精细控制 Prompt 和记忆策略选 LangChain 或者直接裸写 LLM API 会更灵活。LangChain 的 Agent 模块提供了 ReAct Agent、工具加载、记忆抽象但不同版本 API 变动频繁必须做好版本锁定。如果团队更偏向业务侧想快速搭一个带 UI 的知识助手、不需要深入代码定制Dify 这类低代码平台见效最快内置了知识库管理、Agent 编排和应用发布功能。CrewAI 则适合需要多个角色协作的场景比如一个导师 Agent 加一个研究员 Agent 再加一个质检 Agent 协同完成复杂任务它把角色定义、任务分配、协作流程都抽象成了配置项。我的建议是第一个项目不要贪多先选一个框架跑通全链路。选 LangChain 要有长期维护代码的准备选 Dify 要接受它的定制边界。等到业务复杂度真正上来了再评估是否需要引入多 Agent 框架。3.4 工具定义与记忆机制Agent 的关键设计Agent 系统中的工具定义直接影响模型调用工具的准确率。好的工具定义要做到三点名称简短明确、描述交代清楚使用场景和参数含义、参数设计粒度适中。我在实践里会把描述写成“什么时候用”的句式比如“当需要查询内部知识库中的非结构化文档时使用如产品手册、运维指南、制度文件。输入为自然语言查询词或关键词。”模型在规划时看到这样的描述能准确判断是否该调这个工具错误调用的概率长时间运行下来明显更低。记忆机制上我强烈建议做三级分层。第一级是短期记忆把最近 5 到 10 轮的对话内容放进上下文保证多轮问题中“刚才”这类词能被正确解析。第二级是任务记忆把当前任务中间结果暂存下来比如刚检索到的文档片段防止后续步骤重复检索。第三级是长期记忆从历史交互中提取用户关心的主题、常用查询模式、偏好表达以向量形式存入知识库在后续对话开始时把相关旧记忆加载进来。有这三层记忆托底助手的体验才能从“每次都像第一次见面”变成“和你合作过的老同事”。4. 开发实战从零实现企业知识助手4.1 环境准备与项目结构开始写代码前先把环境准备好。我这里用的是 Python 3.10 LangChain 0.1.x OpenAI 兼容 API Chroma 向量库这套组合足够轻量适合第一版跑通。项目结构我建议按下面这样组织knowledge-assistant/ ├── agent/ │ ├── __init__.py │ ├── orchestrator.py # Agent 编排主逻辑 │ ├── tools/ │ │ ├── kb_search.py # 知识库检索工具 │ │ ├── kg_query.py # 图谱查询工具 │ │ └── sql_executor.py # 数据库查询工具 │ └── memory/ │ ├── short_term.py # 短期对话记忆 │ └── long_term.py # 长期向量记忆 ├── rag/ │ ├── loader.py # 文档加载器 │ ├── splitter.py # 文本切分器 │ ├── embedder.py # 向量化封装 │ └── retriever.py # 混合检索器 ├── data/knowledge/ # 原始知识文档 ├── config.yaml # 模型与索引配置 └── main.py # 入口程序这样的分层明确了 RAG 和 Agent 的边界rag 目录是检索基础设施agent 目录是决策编排逻辑。后续你从单 Agent 扩展为多 Agent只需要在 agent 目录下加新角色模块不用动底层检索代码。4.2 知识库建设文档解析与文本切分知识库建设的质量决定了 RAG 的上限。首先要做的是文档解析不同类型文档使用不同解析器。PDF 用 PyMuPDF 提取文本层扫描件先过 OCR 再提取Word 和 Markdown 直接解析文本。这里要特别注意表格的解析表格在纯文本提取后结构会丢失我的做法是把表格转成 Markdown 表格格式保留结构化信息这样模型能理解行列关系。然后是文本切分。切分的核心原则是“保持语义完整性”常用的策略是按标题层级切分先识别文档的结构把每个二级标题下的内容作为一个大块再按文本长度二次切分。切分参数要根据你的 Embedding 模型来定。以 text-embedding-3-small 为例它的最大输入 token 数为 8191我一般把 chunk 设为 800 到 1200 个 token重叠 100 到 150 个 token。重叠的作用是防止一句话恰好被切在分界线上导致语义断裂。切分完之后生成向量索引并存入向量库。这里有一个容易被忽略的点知识文档更新后要增量写入不要每次全量重建。我建议在库里记录每个 chunk 的来源文档和版本号重跑某篇文档时先删除该文档旧版本的全部向量再写入新版本避免新老内容混在一起导致检索结果混乱。4.3 混合检索解决纯向量召回不准的问题我在 2.1 节提到过纯向量检索的盲区解决这个问题的标准方案是混合检索也就是“向量召回 关键词召回 重排序”。关键词部分用 BM25 这种经典算法它擅长精确匹配产品型号、编号这类高频密信息向量部分负责语义召回最后用重排序模型把两路结果融合排序去掉重复和低相关条目。下面这个代码片段是一个可用的混合检索实现用的是 LangChain 的 EnsembleRetrieverfrom langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings # 向量检索器 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma( collection_nameenterprise_kb, embedding_functionembeddings, persist_directory./chroma_db ) vector_retriever vectorstore.as_retriever(search_kwargs{k: 10}) # BM25 关键词检索器 bm25_retriever BM25Retriever.from_documents(docs) bm25_retriever.k 10 # 融合检索向量和关键词各取 10 条按权重合并 ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.3, 0.7] ) docs ensemble_retriever.invoke(SG-2000 的认证信息有哪些)融合之后我还会用重排序模型对结果做一次精排。推荐使用 bge-reranker 这类开源模型它对“查询-文档”对打分能把最相关的内容顶到最前面。RAG 链路中检索结果前三位决定了答案质量的 80%重排序绝对值得投入。4.4 实现 RAG 基线问答链路在升级 Agent 之前先把 RAG 基线做出来方便后续做效果对比。RAG 的核心链路是“检索增强的问答链”。用 LangChain 的 create_retrieval_chain 可以快速搭起来但我更推荐自定义链路因为企业场景往往需要在检索之后、生成之前做一些后处理。下面是一个简洁可用的自定义 RAG 链路from langchain_openai import ChatOpenAI from langchain.prompts import ChatPromptTemplate from langchain_core.runnables import RunnablePassthrough, RunnableLambda prompt ChatPromptTemplate.from_messages([ (system, 你是一名企业知识助手。请仅根据以下参考资料回答问题。 如果资料中没有相关内容请直接回答“根据现有知识库无法回答该问题”。 参考资料 {context}), (human, 问题{question}) ]) def format_docs(docs): return \n\n.join([d.page_content for d in docs]) rag_chain ( { context: ensemble_retriever | RunnableLambda(format_docs), question: RunnablePassthrough(), } | prompt | ChatOpenAI(modelgpt-4o-mini, temperature0.3) ) result rag_chain.invoke(SG-2000 的认证信息有哪些) print(result.content)这里 temperature 我设置得比较低知识问答场景里不希望模型自由发挥0.3 是一个平衡点。System Prompt 里的“回答不出就直说”这句约束也很有必要能有效减少幻觉。4.5 升级 Agent工具调用与任务编排RAG 链路跑通后开始做 Agent 化。第一步是把知识检索封装成工具。在 LangChain 里工具的本质是一个带文档字符串的函数模型通过读函数名和文档字符串来决定是否调用、怎么调用。这是知识库检索工具的定义from langchain_core.tools import tool tool def search_knowledge_base(query: str, top_k: int 5) - str: 当需要查询企业内部知识库时使用。 知识库涵盖产品手册、运维指南、制度文件、项目文档等非结构化资料。 输入应为自然语言描述的信息需求。 docs ensemble_retriever.invoke(query)[:top_k] return \n\n.join( f[来源: {d.metadata.get(source, 未知)}]\n{d.page_content} for d in docs )注意返回内容里我加了来源信息这个做法非常有用。模型在生成答案时能够引用来源文档用户在查看答案时也能溯源企业场景里“可追溯”是刚需。工具准备好后用 create_tool_calling_agent 把这个工具注入 Agentfrom langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate agent_prompt ChatPromptTemplate.from_messages([ (system, 你是一个企业知识助手。你可以调用知识库工具获取信息 也可以根据需要使用计算和其他已注册工具。请一步步完成任务并在最终回答中注明信息来源。), (placeholder, {chat_history}), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent( llmChatOpenAI(modelgpt-4o, temperature0.2), tools[search_knowledge_base], promptagent_prompt ) agent_executor AgentExecutor( agentagent, tools[search_knowledge_base], verboseTrue, max_iterations5, return_intermediate_stepsTrue )max_iterations 设置成 5 是为了防止 Agent 在某个查询里无限循环。return_intermediate_steps 打开后可以拿到 Agent 的完整思考链这个信息在调试阶段非常宝贵。真正让 Agent 比 RAG 强的场景是复杂任务。比如“请帮我查一下 SG-2000 的维护手册中关于润滑保养的部分并总结成一段可以直接发给客户的说明”。Agent 会先调用知识库工具检索“SG-2000 维护手册 润滑保养”拿到内容后根据“直接发给客户”这个要求重写语气与措辞。这种“检索改写面向场景调整”的组合是 RAG 链路很难做到的任务级能力。4.6 权限与安全的工程落地Agent 化之后安全策略要同步升级。我在实际项目中使用了三层防护每一层都简单但有效。第一层是工具级别的权限控制。所有检索类工具的输入参数带上 user_context在工具内部判断该用户是否有权访问目标知识集。实现方式是给知识文档打上权限标签检索时过滤掉无权访问的标签。第二层是数据脱敏。检索结果送入模型之前用正则和敏感词库过滤手机号、身份证号等个人信息防止模型在回答中意外输出敏感字段。第三层是输出审计。Agent 的每轮思考与最终回答写入日志API 层面设置内容安全审核策略也就是“可以不给答案但绝不能给错答案、给越权答案”。注意企业知识助手上线前一定要做一次覆盖“人员离职权限回收”“跨部门文档访问”“工具调用频率控制”的完整安全评审。技术上的安全问题都好解决组织层面的权限定义才是复杂来源建议在早期就与业务方对齐权限模型。5. 常见问题与排查技巧实录5.1 检索质量差召回内容不相关或关键信息缺失排查检索问题我有一套固定的诊断顺序。第一步看召回结果本身把检索器返回的前几条内容和问题摆在一起看如果问题相关但内容不相关问题出在向量化或切分上如果内容相关但答案不准问题出在生成环节如果连内容都不相关问题基本出在查询理解上。查询理解是 RAG 项目里最容易被低估的环节。用户口语化的提问方式和文档中的术语表达差异很大直接拿用户原话去检索经常找不到东西。解决办法有几个用同义词扩展改写查询词把口语转换成文档术语根据历史检索日志做查询分析找出高频检索失败的模式或者更简单直接在 Agent 规划环节增加一个“查询优化”动作让模型先改写检索词再执行检索。5.2 切分参数怎么调chunk 大小和重叠的正确思路很多团队问 chunk_size 到底设多少合适。这个参数没有标准答案取决于知识文档的类型和 Embedding 模型能力。我的经验判断文档逻辑块比较独立、每块信息密度高用小块400 到 600 token文档叙述性强、需要上下文连续用大块1000 到 1500 token。重叠长度一般设置为 chunk 的 10% 到 15%。判断切分效果好坏有一个快速办法随机抽一批用户问题一个个去检索器里查看召回的前几条内容是否覆盖了答案的所有必要信息。覆盖率达不到 80% 以上就先别急着调 Prompt问题大概率在检索端也就是切分和索引上。RAG 领域有句老话垃圾进去垃圾出来召回的内容不完整模型再聪明也编不出正确答案。5.3 知识库能存图片吗多模态问题的边界这个问题被问到的频率非常高。答案是可以但不能像存文本一样简单。向量数据库本质上存的是向量和文本元数据图片本身不直接进库。可行的做法有三条路。第一把图片转成文本描述再入库适合流程图、架构图这类需要语义理解的图用视觉语言模型生成描述文本。第二走多模态 Embedding把图片和文本映射到同一个向量空间检索时图文可以互相召回不过这类模型在企业内网部署还有不少限制。第三图片作为附件引用向量库里存图片路径和上下文描述回答时输出图片链接。需要说明的是如果图片里包含表格或文字信息先做 OCR 提取文本比直接图片入库更实用。比如扫描版 PDF 中的报表OCR 结果进入文本索引原始图片作为阅读附件检索命中率会高得多。5.4 Agent 工具调用失灵的排查思路Agent 类问题最常见的表现是模型该调工具时不调或者调用了错误的工具参数。遇到这类问题不要急着改 Prompt先检查工具定义本身。工具名称是否清晰表达了功能描述里是否说明了“什么时候用”而不只是“是什么”参数名和描述是否让模型容易理解工具多了之后模型的选择难度也升高建议每个 Agent 挂载的工具数量控制在 5 个以内业务扩大后拆分成多个专业 Agent 比不断增加单个 Agent 的工具数更可靠。另外日志是你最好的调试工具。我强烈建议把 AgentExecutor 的 verbose 打开把每轮思考、动作、观察完整记录下来。问题发生后顺着 ReAct 轨迹一步步看就能定位是模型规划错了还是工具返回了空结果还是返回结果太长超出了上下文窗口。大多数 Agent 问题三分钟看日志就能定位个八九成。6. 踩坑心得团队落地知识助手的几点忠告6.1 先定评估标准再开始做优化这是我特别想强调的一点。很多团队一上来就调 Prompt、换模型、调切分参数搞了半个月效果也不知道变好还是变差。正确做法是先建立一套评估集选取 100 到 300 条覆盖核心场景的真实问题每条标注期望答案和检索参考文档。每次改动后在评估集上跑一遍计算召回率、答案准确率和无答案率。没有评估集的优化都是自我感觉良好有了评估集每一次改动是变好还是变差立刻见分晓。评估集的来源最好是真实用户问题。第一版可以先从业务部门收集问题后续上线后持续从日志里抽一批新的、经过用户反馈确认的问题加入评估集。三个月后你的评估集会成为判断系统健康度的最重要资产。6.2 从单 Agent 到多 Agent 要克制很多人做完第一个单 Agent 知识助手之后马上就想上多 Agent让一个“管理员 Agent”去调度多个专业 Agent。我的经验是先用最少一个 Agent 的架构跑通业务闭环只有当出现以下三种情况再考虑拆分——工具数量太多导致模型选择困难不同任务类型需要差异很大的 Prompt 和记忆策略多个任务环节需要并行处理或者轮流质检。拆分时也要注意多 Agent 之间的通信、上下文共享、冲突仲裁都是新问题复杂度是线性往上涨的。先小步快跑别为了架构的“高级感”而提前引入复杂度。我个人的体会是企业知识助手这个项目最大的难点从来不是模型多聪明而是知识工程做得多细致、工程链路做得多扎实。RAG 解决的是知识怎么到达模型的问题Agent 解决的是任务怎么完成的问题两者是递进关系。把检索质量做扎实了Agent 才有可靠的工具可用把 Agent 规划做好了RAG 才有智能的调度者。建议你按照本文的顺序先搭 RAG 基线建立评估集再逐步加 Agent 能力每一步都用真实问题验证效果稳扎稳打地往前推进。 从RAG到Agent：企业级知识助手的落地路线与工程实践
这两年最常被问到的一个问题就是企业内部的知识助手到底该怎么落地。很多团队的路径出奇地一致先上一套 RAG 把文档问答跑通然后跑着跑着发现“只能答不能做”再往上加 Agent 能力让系统能调用工具、能主动检索多轮信息、能完成跨系统操作。这条路几乎成了企业知识助手开发的默认路线也确实是踩坑最少的一条路。这篇文章就围绕“从 RAG 到 Agent”这条演进线索讲清楚一个完整的企业知识助手是怎么一步步搭起来的。我会拆解 RAG 的原理与瓶颈、Agent 化改造的关键设计并给出完整的工程实现和踩坑记录。适合正在做知识问答类应用的研发同学也适合准备把 LLM 接入企业业务但还在观望的团队参考。1. 为什么企业知识助手的选择是“先 RAG后 Agent”1.1 RAG 到底解决的是什么问题先说清楚 RAG 是什么。RAG 的全称是 Retrieval-Augmented Generation检索增强生成。它的核心思路很直白大模型不是万能的尤其在企业内部知识面前它既不知道你们的产品文档写了什么也不知道你们内部流程走的是哪套审批逻辑。所以与其指望模型记住这些不如先把知识存在外部每次问答前先检索出相关内容再把“问题 检索到的资料”一起丢给模型生成答案。这句话听起来简单但它是整个企业知识助手的逻辑起点。做 RAG 的本质不是写个检索接口而是重新定义“知识怎么存放、怎么被找到、怎么被使用”这三件事。企业内部的知识形态高度混合有 Word 文档、PDF、PPT、网页、表格、甚至聊天记录里的经验碎片。RAG 的价值在于把这些异构内容统一成同一种形态——文本向量——然后用语义相似度来召回。用户问“报销流程怎么走”不需要文档里出现“报销”两个字只要语义相关向量检索也能找得到。这也是 RAG 比微调更适合企业知识场景的根本原因。微调意味着把知识压进模型参数里每次知识更新都要重新训练成本高、周期长、还容易让模型“记串了”。RAG 则把知识留在外部更新知识就是更新索引模型本身不动幻觉风险也相对可控。对于知识频繁变动的企业场景RAG 几乎是唯一在成本和效果之间取得平衡的方案。1.2 为什么最终要走向 AgentRAG 能解决“从文档中找答案”但解决不了“复杂任务需要多步处理”的问题。举几个真实场景你就能感受到差距。第一个场景用户问“帮我对比一下 A 产品和 B 产品在安全认证方面的差异”这不是一次检索能搞定的需要先定位 A 产品的认证文档再找 B 产品的资质材料可能还要查一个第三方的认证标准最后汇总对比。第二个场景用户问“下周要提交给客户的方案帮我拉一下最近三个项目的技术细节”这已经不只是问答了这是要跨文档、跨系统、带条件的任务。第三个场景更典型用户说“查一下这个故障码在运维手册里的处理方法然后按格式生成一张工单”这里面有检索动作、有格式变换、还可能涉及调用工单系统接口。这些需求暴露了 RAG 的硬瓶颈RAG 是无状态的“检索-生成”单轮通道没有规划能力没有工具调用能力也没有多步推理能力。而 Agent 恰恰补上的是这三样。Agent 的本质是让大模型不再只是“回答者”而是“决策者”和“执行者”。它自己做任务拆解决定先检索什么、再干什么甚至在需要时调用外部工具完成动作。所以企业知识助手的完整形态往往不是纯 RAG 也不是纯 Agent而是从 RAG 这个“阅读理解能力”出发叠加 Agent 的“任务执行能力”。2. RAG 的五大瓶颈这是升级 Agent 的直接理由2.1 检索层的先天缺陷固定 Top-K 与语义盲区所有 RAG 系统第一个碰到的痛点就是“检索结果不稳定”。你设了 Top-K5可能用户问的问题只需要 3 段资料就够了多出来的 2 段反而干扰了模型回答换个问题5 段又不够真正关键的文档排在第 6 位模型根本没看到。这就是固定 Top-K 的结构性缺陷。另一个更隐蔽的问题是纯向量检索的语义盲区。向量检索擅长找“意思相近”的内容但在处理精确匹配时非常弱。比如用户输入一个产品型号“SG-2000”向量检索很可能把“SG-2000 Pro”“SG-2000 Mini”都当成相似内容拉出来而文档里所有提到“SG-2000”的段落全部命中后真正包含技术参数的章节反而因为文本太短、向量距离不够近而被漏掉。还有代码片段、IP 地址、工单号、合同编号这类高精度信息用向量检索完全是不擅长的。这也是后来要引入混合检索、关键词倒排索引甚至 Agent 检索规划的原因所在。2.2 编排层的僵硬单轮问答撑不起复杂任务RAG 的标准链路是“一问一检一答”这个链路在简单问答上没问题但撑不起复杂任务。典型现象是用户的问题涉及多个知识域比如“这个设备的保养周期是多少如果超期未保养会影响质保吗”前半个问题属于运维手册后半个问题可能藏在商务合同条款里。普通 RAG 会把两个子问题混在一次检索里结果召回的文档两边都没完全覆盖。这种问题的本质是 RAG 缺少“查询规划”的能力它不知道把问题拆成子问题、分路检索再汇总。有些团队试图靠一个复杂 Prompt 让模型先生成检索词、再检索、再回答这个方向的尽头就是 Agent因为一旦进入“根据查询结果决定下一步查什么”的循环你实际上已经是在写 Agent 的 ReAct 逻辑了。2.3 知识表示层面的冲突RAG 与 KG 的分工很多团队会问一个问题RAG 知识库和知识图谱KG到底有什么区别什么时候该用哪个我的判断是这样的RAG 适合非结构化文本的语义召回KG 适合实体关系和结构化事实的精确查询。前者擅长“找内容”后者擅长“找关系”。举个例子员工问“A 项目的负责人是谁他之前负责过哪些项目”如果只靠 RAG系统检索到的是提到这个人的若干段落需要模型自己从中把实体关系抽出来准确率看运气。如果知识库里同时有一张图谱节点是人、项目、角色边是“负责”“参与”“汇报给”这类关系这个问题就可以直接走图谱查询拿到确定答案。所以成熟的企业知识助手往往底层是 RAG KG 两条检索通道由 Agent 判断问题更适合走哪条路或者两条都走、再做结果融合。这也是从 RAG 向 Agent 升级时一个非常重要的结构性变化。2.4 缺失记忆与个性化企业知识助手的隐性问题RAG 的另一个硬伤是没有记忆。用户问“刚才那份合同里约定的付款条件是什么”系统无法正确理解“刚才”指的是哪一份合同。用户连续问了三个关于安全审计的问题系统也不会把上下文串联起来形成一份连续的分析。这在个人使用场景里只是体验问题但在企业场景里是效率问题。员工希望知识助手记住自己在看哪个项目、关注哪个客户、上次查过什么这样后续问题不用重复交代背景。Agent 框架天然具备解决这个问题的结构——记忆机制。对话记忆保存短期上下文向量记忆保存长期偏好实体记忆保存用户关注的对象。一个带记忆的 Agent才能做到真正贴合使用者。第 3 章我会详细展开这块设计。2.5 企业级安全与权限这是最容易被低估的坑RAG 早期落地时大家只顾着“答得准不准”忽略了一个致命问题企业内部知识是有权限边界的。销售不该看到研发内部的缺陷报告外包人员不该接触核心财务数据但纯 RAG 把所有人的提问都映射到了同一个知识库上本质上是一次信息越权通道。要堵住这个洞至少要做三层隔离检索前校验提问者身份与权限范围检索时按权限过滤知识库或文档集生成后对答案做脱敏检查。这三层逻辑在 RAG 架构里做起来非常别扭因为知识库和检索链路是静态的。但在 Agent 架构下就顺理成章了因为 Agent 本身就带工具调用链路把“检索”封装成一个受控工具在工具内部做权限判断在规划层控制工具使用范围安全策略从“全局一把锁”变成了“每个动作一把锁”。3. Agent 化改造的核心机制与架构设计3.1 ReAct 循环Agent 的“想一步做一步”Agent 最核心的机制是 ReAct也就是 Reason Act 的循环。大模型在每一轮先分析当前状态、决定下一步动作执行动作后观察结果再根据结果继续推理。这个循环可以类比成一个人查资料的过程先想“这个问题需要查什么”然后去翻文件看到文件里提到了另一个部门又去问那个部门的负责人最后把信息整合成答案。在工程实现上ReAct 循环通常由三部分组成大模型充当推理中枢工具集提供执行能力循环控制器负责调度。大模型输出的是“行动指令”比如调用 search_knowledge_base(查询词) 或者 calculator(表达式)控制器接收指令后调用对应的工具函数拿到真实结果后把它作为观察信息回传给大模型模型再决定是继续行动还是输出最终答案。这个过程循环往复直到模型认为信息足够、输出答案或者到达预设的最大迭代次数。理解 ReAct 是理解 Agent 的分水岭。很多人以为 Agent 就是一个会调 API 的聊天机器人其实 Agent 的真正能力来自“规划—执行—观察—再规划”的循环每多走一轮系统对任务的理解就深一层。3.2 一个企业知识助手的整体架构设计我在这里给出一个已经在实际项目中稳定跑通的架构你可以直接作为参考。整体上分为四层接入层、Agent 编排层、工具层、知识层。接入层负责统一接收来自 Web 端、企业微信、钉钉或聊天界面的用户请求做身份认证与权限上下文组装。Agent 编排层是核心大脑包含任务规划、ReAct 循环、记忆管理三个模块。工具层是一组可被模型调用的函数集合典型工具有知识库检索工具、KG 查询工具、SQL 查询工具、工单创建工具、日程工具。知识层则是底层的数据资产包括文档向量库、结构化数据库、知识图谱和外部 API。这套架构的关键在于知识库不再是唯一的知识来源而是作为 Agent 的一个工具存在。模型决定“是否需要检索、检索什么”而不是每次问答都强制检索。这样一来简单问题直接用模型常识回答需要查证的问题才走检索工具复杂任务则自动规划多条行动路径。整个系统的灵活性和准确性都上了一个台阶。3.3 技术选型对比LangChain、Dify 与 CrewAI 怎么选做 Agent 化改造时团队绕不开框架选型的问题。这三者的定位其实完全不同LangChain 是开发库Dify 是应用平台CrewAI 是多 Agent 编排框架。选型的关键是看你的团队在哪个层级做事情。如果你们是研发团队需要对流程深度定制比如自定义工具调用逻辑、精细控制 Prompt 和记忆策略选 LangChain 或者直接裸写 LLM API 会更灵活。LangChain 的 Agent 模块提供了 ReAct Agent、工具加载、记忆抽象但不同版本 API 变动频繁必须做好版本锁定。如果团队更偏向业务侧想快速搭一个带 UI 的知识助手、不需要深入代码定制Dify 这类低代码平台见效最快内置了知识库管理、Agent 编排和应用发布功能。CrewAI 则适合需要多个角色协作的场景比如一个导师 Agent 加一个研究员 Agent 再加一个质检 Agent 协同完成复杂任务它把角色定义、任务分配、协作流程都抽象成了配置项。我的建议是第一个项目不要贪多先选一个框架跑通全链路。选 LangChain 要有长期维护代码的准备选 Dify 要接受它的定制边界。等到业务复杂度真正上来了再评估是否需要引入多 Agent 框架。3.4 工具定义与记忆机制Agent 的关键设计Agent 系统中的工具定义直接影响模型调用工具的准确率。好的工具定义要做到三点名称简短明确、描述交代清楚使用场景和参数含义、参数设计粒度适中。我在实践里会把描述写成“什么时候用”的句式比如“当需要查询内部知识库中的非结构化文档时使用如产品手册、运维指南、制度文件。输入为自然语言查询词或关键词。”模型在规划时看到这样的描述能准确判断是否该调这个工具错误调用的概率长时间运行下来明显更低。记忆机制上我强烈建议做三级分层。第一级是短期记忆把最近 5 到 10 轮的对话内容放进上下文保证多轮问题中“刚才”这类词能被正确解析。第二级是任务记忆把当前任务中间结果暂存下来比如刚检索到的文档片段防止后续步骤重复检索。第三级是长期记忆从历史交互中提取用户关心的主题、常用查询模式、偏好表达以向量形式存入知识库在后续对话开始时把相关旧记忆加载进来。有这三层记忆托底助手的体验才能从“每次都像第一次见面”变成“和你合作过的老同事”。4. 开发实战从零实现企业知识助手4.1 环境准备与项目结构开始写代码前先把环境准备好。我这里用的是 Python 3.10 LangChain 0.1.x OpenAI 兼容 API Chroma 向量库这套组合足够轻量适合第一版跑通。项目结构我建议按下面这样组织knowledge-assistant/ ├── agent/ │ ├── __init__.py │ ├── orchestrator.py # Agent 编排主逻辑 │ ├── tools/ │ │ ├── kb_search.py # 知识库检索工具 │ │ ├── kg_query.py # 图谱查询工具 │ │ └── sql_executor.py # 数据库查询工具 │ └── memory/ │ ├── short_term.py # 短期对话记忆 │ └── long_term.py # 长期向量记忆 ├── rag/ │ ├── loader.py # 文档加载器 │ ├── splitter.py # 文本切分器 │ ├── embedder.py # 向量化封装 │ └── retriever.py # 混合检索器 ├── data/knowledge/ # 原始知识文档 ├── config.yaml # 模型与索引配置 └── main.py # 入口程序这样的分层明确了 RAG 和 Agent 的边界rag 目录是检索基础设施agent 目录是决策编排逻辑。后续你从单 Agent 扩展为多 Agent只需要在 agent 目录下加新角色模块不用动底层检索代码。4.2 知识库建设文档解析与文本切分知识库建设的质量决定了 RAG 的上限。首先要做的是文档解析不同类型文档使用不同解析器。PDF 用 PyMuPDF 提取文本层扫描件先过 OCR 再提取Word 和 Markdown 直接解析文本。这里要特别注意表格的解析表格在纯文本提取后结构会丢失我的做法是把表格转成 Markdown 表格格式保留结构化信息这样模型能理解行列关系。然后是文本切分。切分的核心原则是“保持语义完整性”常用的策略是按标题层级切分先识别文档的结构把每个二级标题下的内容作为一个大块再按文本长度二次切分。切分参数要根据你的 Embedding 模型来定。以 text-embedding-3-small 为例它的最大输入 token 数为 8191我一般把 chunk 设为 800 到 1200 个 token重叠 100 到 150 个 token。重叠的作用是防止一句话恰好被切在分界线上导致语义断裂。切分完之后生成向量索引并存入向量库。这里有一个容易被忽略的点知识文档更新后要增量写入不要每次全量重建。我建议在库里记录每个 chunk 的来源文档和版本号重跑某篇文档时先删除该文档旧版本的全部向量再写入新版本避免新老内容混在一起导致检索结果混乱。4.3 混合检索解决纯向量召回不准的问题我在 2.1 节提到过纯向量检索的盲区解决这个问题的标准方案是混合检索也就是“向量召回 关键词召回 重排序”。关键词部分用 BM25 这种经典算法它擅长精确匹配产品型号、编号这类高频密信息向量部分负责语义召回最后用重排序模型把两路结果融合排序去掉重复和低相关条目。下面这个代码片段是一个可用的混合检索实现用的是 LangChain 的 EnsembleRetrieverfrom langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever from langchain_community.vectorstores import Chroma from langchain_openai import OpenAIEmbeddings # 向量检索器 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma( collection_nameenterprise_kb, embedding_functionembeddings, persist_directory./chroma_db ) vector_retriever vectorstore.as_retriever(search_kwargs{k: 10}) # BM25 关键词检索器 bm25_retriever BM25Retriever.from_documents(docs) bm25_retriever.k 10 # 融合检索向量和关键词各取 10 条按权重合并 ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.3, 0.7] ) docs ensemble_retriever.invoke(SG-2000 的认证信息有哪些)融合之后我还会用重排序模型对结果做一次精排。推荐使用 bge-reranker 这类开源模型它对“查询-文档”对打分能把最相关的内容顶到最前面。RAG 链路中检索结果前三位决定了答案质量的 80%重排序绝对值得投入。4.4 实现 RAG 基线问答链路在升级 Agent 之前先把 RAG 基线做出来方便后续做效果对比。RAG 的核心链路是“检索增强的问答链”。用 LangChain 的 create_retrieval_chain 可以快速搭起来但我更推荐自定义链路因为企业场景往往需要在检索之后、生成之前做一些后处理。下面是一个简洁可用的自定义 RAG 链路from langchain_openai import ChatOpenAI from langchain.prompts import ChatPromptTemplate from langchain_core.runnables import RunnablePassthrough, RunnableLambda prompt ChatPromptTemplate.from_messages([ (system, 你是一名企业知识助手。请仅根据以下参考资料回答问题。 如果资料中没有相关内容请直接回答“根据现有知识库无法回答该问题”。 参考资料 {context}), (human, 问题{question}) ]) def format_docs(docs): return \n\n.join([d.page_content for d in docs]) rag_chain ( { context: ensemble_retriever | RunnableLambda(format_docs), question: RunnablePassthrough(), } | prompt | ChatOpenAI(modelgpt-4o-mini, temperature0.3) ) result rag_chain.invoke(SG-2000 的认证信息有哪些) print(result.content)这里 temperature 我设置得比较低知识问答场景里不希望模型自由发挥0.3 是一个平衡点。System Prompt 里的“回答不出就直说”这句约束也很有必要能有效减少幻觉。4.5 升级 Agent工具调用与任务编排RAG 链路跑通后开始做 Agent 化。第一步是把知识检索封装成工具。在 LangChain 里工具的本质是一个带文档字符串的函数模型通过读函数名和文档字符串来决定是否调用、怎么调用。这是知识库检索工具的定义from langchain_core.tools import tool tool def search_knowledge_base(query: str, top_k: int 5) - str: 当需要查询企业内部知识库时使用。 知识库涵盖产品手册、运维指南、制度文件、项目文档等非结构化资料。 输入应为自然语言描述的信息需求。 docs ensemble_retriever.invoke(query)[:top_k] return \n\n.join( f[来源: {d.metadata.get(source, 未知)}]\n{d.page_content} for d in docs )注意返回内容里我加了来源信息这个做法非常有用。模型在生成答案时能够引用来源文档用户在查看答案时也能溯源企业场景里“可追溯”是刚需。工具准备好后用 create_tool_calling_agent 把这个工具注入 Agentfrom langchain.agents import create_tool_calling_agent, AgentExecutor from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate agent_prompt ChatPromptTemplate.from_messages([ (system, 你是一个企业知识助手。你可以调用知识库工具获取信息 也可以根据需要使用计算和其他已注册工具。请一步步完成任务并在最终回答中注明信息来源。), (placeholder, {chat_history}), (human, {input}), (placeholder, {agent_scratchpad}), ]) agent create_tool_calling_agent( llmChatOpenAI(modelgpt-4o, temperature0.2), tools[search_knowledge_base], promptagent_prompt ) agent_executor AgentExecutor( agentagent, tools[search_knowledge_base], verboseTrue, max_iterations5, return_intermediate_stepsTrue )max_iterations 设置成 5 是为了防止 Agent 在某个查询里无限循环。return_intermediate_steps 打开后可以拿到 Agent 的完整思考链这个信息在调试阶段非常宝贵。真正让 Agent 比 RAG 强的场景是复杂任务。比如“请帮我查一下 SG-2000 的维护手册中关于润滑保养的部分并总结成一段可以直接发给客户的说明”。Agent 会先调用知识库工具检索“SG-2000 维护手册 润滑保养”拿到内容后根据“直接发给客户”这个要求重写语气与措辞。这种“检索改写面向场景调整”的组合是 RAG 链路很难做到的任务级能力。4.6 权限与安全的工程落地Agent 化之后安全策略要同步升级。我在实际项目中使用了三层防护每一层都简单但有效。第一层是工具级别的权限控制。所有检索类工具的输入参数带上 user_context在工具内部判断该用户是否有权访问目标知识集。实现方式是给知识文档打上权限标签检索时过滤掉无权访问的标签。第二层是数据脱敏。检索结果送入模型之前用正则和敏感词库过滤手机号、身份证号等个人信息防止模型在回答中意外输出敏感字段。第三层是输出审计。Agent 的每轮思考与最终回答写入日志API 层面设置内容安全审核策略也就是“可以不给答案但绝不能给错答案、给越权答案”。注意企业知识助手上线前一定要做一次覆盖“人员离职权限回收”“跨部门文档访问”“工具调用频率控制”的完整安全评审。技术上的安全问题都好解决组织层面的权限定义才是复杂来源建议在早期就与业务方对齐权限模型。5. 常见问题与排查技巧实录5.1 检索质量差召回内容不相关或关键信息缺失排查检索问题我有一套固定的诊断顺序。第一步看召回结果本身把检索器返回的前几条内容和问题摆在一起看如果问题相关但内容不相关问题出在向量化或切分上如果内容相关但答案不准问题出在生成环节如果连内容都不相关问题基本出在查询理解上。查询理解是 RAG 项目里最容易被低估的环节。用户口语化的提问方式和文档中的术语表达差异很大直接拿用户原话去检索经常找不到东西。解决办法有几个用同义词扩展改写查询词把口语转换成文档术语根据历史检索日志做查询分析找出高频检索失败的模式或者更简单直接在 Agent 规划环节增加一个“查询优化”动作让模型先改写检索词再执行检索。5.2 切分参数怎么调chunk 大小和重叠的正确思路很多团队问 chunk_size 到底设多少合适。这个参数没有标准答案取决于知识文档的类型和 Embedding 模型能力。我的经验判断文档逻辑块比较独立、每块信息密度高用小块400 到 600 token文档叙述性强、需要上下文连续用大块1000 到 1500 token。重叠长度一般设置为 chunk 的 10% 到 15%。判断切分效果好坏有一个快速办法随机抽一批用户问题一个个去检索器里查看召回的前几条内容是否覆盖了答案的所有必要信息。覆盖率达不到 80% 以上就先别急着调 Prompt问题大概率在检索端也就是切分和索引上。RAG 领域有句老话垃圾进去垃圾出来召回的内容不完整模型再聪明也编不出正确答案。5.3 知识库能存图片吗多模态问题的边界这个问题被问到的频率非常高。答案是可以但不能像存文本一样简单。向量数据库本质上存的是向量和文本元数据图片本身不直接进库。可行的做法有三条路。第一把图片转成文本描述再入库适合流程图、架构图这类需要语义理解的图用视觉语言模型生成描述文本。第二走多模态 Embedding把图片和文本映射到同一个向量空间检索时图文可以互相召回不过这类模型在企业内网部署还有不少限制。第三图片作为附件引用向量库里存图片路径和上下文描述回答时输出图片链接。需要说明的是如果图片里包含表格或文字信息先做 OCR 提取文本比直接图片入库更实用。比如扫描版 PDF 中的报表OCR 结果进入文本索引原始图片作为阅读附件检索命中率会高得多。5.4 Agent 工具调用失灵的排查思路Agent 类问题最常见的表现是模型该调工具时不调或者调用了错误的工具参数。遇到这类问题不要急着改 Prompt先检查工具定义本身。工具名称是否清晰表达了功能描述里是否说明了“什么时候用”而不只是“是什么”参数名和描述是否让模型容易理解工具多了之后模型的选择难度也升高建议每个 Agent 挂载的工具数量控制在 5 个以内业务扩大后拆分成多个专业 Agent 比不断增加单个 Agent 的工具数更可靠。另外日志是你最好的调试工具。我强烈建议把 AgentExecutor 的 verbose 打开把每轮思考、动作、观察完整记录下来。问题发生后顺着 ReAct 轨迹一步步看就能定位是模型规划错了还是工具返回了空结果还是返回结果太长超出了上下文窗口。大多数 Agent 问题三分钟看日志就能定位个八九成。6. 踩坑心得团队落地知识助手的几点忠告6.1 先定评估标准再开始做优化这是我特别想强调的一点。很多团队一上来就调 Prompt、换模型、调切分参数搞了半个月效果也不知道变好还是变差。正确做法是先建立一套评估集选取 100 到 300 条覆盖核心场景的真实问题每条标注期望答案和检索参考文档。每次改动后在评估集上跑一遍计算召回率、答案准确率和无答案率。没有评估集的优化都是自我感觉良好有了评估集每一次改动是变好还是变差立刻见分晓。评估集的来源最好是真实用户问题。第一版可以先从业务部门收集问题后续上线后持续从日志里抽一批新的、经过用户反馈确认的问题加入评估集。三个月后你的评估集会成为判断系统健康度的最重要资产。6.2 从单 Agent 到多 Agent 要克制很多人做完第一个单 Agent 知识助手之后马上就想上多 Agent让一个“管理员 Agent”去调度多个专业 Agent。我的经验是先用最少一个 Agent 的架构跑通业务闭环只有当出现以下三种情况再考虑拆分——工具数量太多导致模型选择困难不同任务类型需要差异很大的 Prompt 和记忆策略多个任务环节需要并行处理或者轮流质检。拆分时也要注意多 Agent 之间的通信、上下文共享、冲突仲裁都是新问题复杂度是线性往上涨的。先小步快跑别为了架构的“高级感”而提前引入复杂度。我个人的体会是企业知识助手这个项目最大的难点从来不是模型多聪明而是知识工程做得多细致、工程链路做得多扎实。RAG 解决的是知识怎么到达模型的问题Agent 解决的是任务怎么完成的问题两者是递进关系。把检索质量做扎实了Agent 才有可靠的工具可用把 Agent 规划做好了RAG 才有智能的调度者。建议你按照本文的顺序先搭 RAG 基线建立评估集再逐步加 Agent 能力每一步都用真实问题验证效果稳扎稳打地往前推进。