构建企业级Agent知识库是实现AI落地的关键一步，本文将深入解析如何打造真正贴合业务场景的知识底座，助力企业高效部署智能应用。

Agent的构建看似简单，实则蕴含深意。只需几分钟就能搭建一个可运行的Agent，但要使其真正服务于业务，却需要满足诸多条件。其中，知识库的构建是最核心的环节之一。接下来，基于AICX服务客户的实际业务经验，我们将分享如何构建企业级Agent所需的知识底座。

“知识就是财富”这句话，过去或许只是哲学层面的指引，但在AI时代已成为触手可及的现实。想要打造能够提升业务效率的Agent，知识管理不应只是某个项目中的临时任务，而应成为每个组织、每家企业的日常习惯。只有深入理解AI对知识底座的需求，才能在平时有意识地进行搜集与整理，从而在场景落地时从容应对。

第一步：构建候选知识库

这一步涉及多种知识来源。最常用的包括历史数据（如对话记录、工单、已有知识库）、已出版的书籍与文章，以及对业务专家的访谈。除了内部信息，往往还需要补充外部公有知识，例如行业标准，或对竞品知识库进行逆向分析。

此外，对话日志中用户频繁提问但尚无标准答案的内容，也值得重点关注。对这些知识进行补充和整理时，AI工具能提供巨大助力，但需注意对AI生成结果进行质量检验——从实践经验来看，AI生成的问法往往不够“人性化”，需要人工优化。

以上搜集过程，本质上是对企业知识体系进行精加工。在此过程中，需要合并重复问题（甚至合并相似场景）、去除无效前缀、规范表达方式（例如运用7W2H框架将知识归类到标准问题类型），并对看似相近但实际不同的场景进行明确区分。

举个例子，当用户提问“如何与某专家老师达成培训业务合作，费用是多少？”——仔细分析会发现，这其实包含两条完全独立的知识：一条是合作的步骤与方式，另一条是收费标准。因此，需要将一条知识拆分为两条独立知识，这样用户只问其中一个问题时，大模型就能精准匹配答案，避免冗余信息造成干扰。

第二步：提炼高频知识

这一环节的核心在于明确知识库的构建重点，确定知识整理的优先级。通过对历史数据的统计分析，结合业务专家的经验判断，最终从搜集到的知识中提炼出高频知识。

话说回来，知识维护的资源终究有限，因此需要根据咨询频率和业务价值两个维度来划分优先级。实操中，通常会将80%以上的资源投入高频知识，因为这些问题的答案基本能覆盖90%以上的用户场景。

高频知识的识别有两种方法。一种是数据驱动——根据历史数据的频率，通过算法合并语义相同的提问，然后按排序提取高频知识。另一种是业务专家驱动——让一线业务人员根据经验圈定范围，这非常适合没有历史数据的冷启动场景。通常，我们会组织业务专家通过工作坊进行头脑风暴来整理知识清单。

此外，还需建立动态维护机制。通过日志查看每条知识的答复率和准确率，一旦超过阈值，就要纳入重点关注范围。

对于低频知识，通常只投入20%以内的精力，这类知识主要覆盖长尾需求。知识库上线后，如果季度或半年内没有这些知识的访问记录，一般会纳入“待删除”清单。

还有一类是无效知识。通过标记每条知识的最后命中时间，超过期限的就要及时清理，避免造成知识污染。无效知识包括新旧知识冲突——例如政策变动、公司制度调整，或平台活动规则变化。可通过系统自动告警，及时冻结并删除旧知识。

第三步：知识分类

这一步本质上是对知识进行结构化，厘清知识之间的关联。通常可分为：可结构化的知识、模糊的知识、无规律的具体知识、表格知识以及多维度推理知识。

结构化的知识指具有清晰层级关系的知识。例如医保报销，包括报销流程、报销比例、注册所需证件等，层级非常清晰。通过多轮对话，让用户最终明确自己实际要咨询的问题。

模糊的知识是指用户提问时未包含足够信息，无法直接让大模型在知识库中匹配。此时需要进行多轮意图澄清。比如用户说“帮我查一下某某某号码”，潜在意图可能是查询上个月的消费记录，也可能是话费余额或流量余额。需要构建一个可能的意图树，预设所有可能的子意图分支，将这些模糊问题拆解为可选路径，让Agent根据意图树进行追问。实践中，这类选项的数量通常为3-5个，以防用户信息过载，同时也要提供兜底选项（如“转人工”），防止用户想问的内容不在列举范围内。此外，要做好上下文管理，让Agent记住用户的历史选择或历史问题中明确的指代，从上下文中找到本轮咨询的主语。

无规律的具体知识通常是一些长尾问题，彼此独立且用户提问率较低。对于这类知识，需要设计精细化的标签体系，包括业务类目、地域甚至人群标签。例如，用户是“初级顾问”，同时属于“人力资源领域”，还服务于“新能源”行业——结合这些多标签的组合检索，可以提高这类人群常问问题的命中率。在设置答案时，也要设计得更模板化，方便快速梳理并填充到知识库。比如某政府单位的知识库，可以这样设计答案模板：“根据某某政策，可按ABC步骤办理。如仍不了解，可咨询XX电话或XX部门。”通过这个模板，可以快速维护无规律的知识。

表格类知识非常适合参数化查询，能快速响应用户的精准提问。这类知识有明确的行列字段，处理时需要让字段更标准化，并关联用户最关心的核心属性（非核心属性可简化）。还要保证数据支持语义分析——比如当用户提问“最贵的咨询服务方式是哪种”（确实有人这样问），要能快速映射到咨询产品的价格及交付方式，然后将答案从知识库返回给大模型，由大模型自行判断。

最后是多维度的推理类知识，非常适合复杂逻辑判断，依赖知识图谱和规则引擎。主要用于处理涉及多个条件的复杂问题。例如用户提问：“某个项目收入50万，项目周期6个月，涉及XX模块，客户有哪些特殊需求，是否可以立项？”处理步骤是：首先抽取用户问题中的关键参数（项目收入50万、涉及模块、项目周期等），然后根据参数配置规则引擎（比如根据用户企业体量估算某模块执行成本的计算公式），最后进行动态推理和输出，判定项目是否适合立项。这里也可能需要设计意图树，让Agent根据意图树追问以补充信息。

整理知识就好比收拾房间——该归类归类，该扔的扔。

第四步：选择问答引擎

基于知识类型选择合适的引擎。问答引擎是基于NLP和信息检索技术的系统，能够理解用户用自然语言提出的问题，并从结构化或非结构化的数据源中提取或生成答案。不同类型的知识需要不同的处理方式，而问答引擎正是实现这一目标的技术工具。选择与知识类型匹配的引擎，可以显著提升准确性、效率和用户体验。

传统的检索引擎，类似图书馆查图书，基于目录进行快速匹配。例如FAQ问答引擎，特别适合处理简单的一问一答。多轮对话引擎适合需要追问补充信息或厘清用户需求的场景。表格查询引擎适合查询结构化数据，知识图谱适合处理多维度的推理问题——需要根据知识属性进行针对性选择。

老式引擎的使用和维护成本都较高。以FAQ为代表，这类引擎需要手工录入、手动分类甚至手动关联，灵活性非常差，用户提问新增一种问法，都需要手动修改知识库。大模型出现后，可以通过RAG+LLM大幅降低维护成本、增加知识灵活性。但大模型的使用成本相对较高——可以这样理解：老式引擎类似新华字典的目录，查询方式固定，印刷后无法修改，但查询精准且单次查询成本有限。大模型则类似每次查询都需要把新华字典全部过一遍，虽然灵活，但精准度和单次查询成本不一定优于老式方法。因此，没有最好的方案，只有根据项目需求选择最合适的。

第五步：知识整理

基于前四步的任务产出，整理知识库所需的知识，包括QA清单、知识表格甚至知识图谱。

以上知识搜集整理的SOP，并非运行一次就足够。而是需要经过多轮多次，在实践验证中不断补充完善，最终形成知识搜集整理的“飞轮”。

“知识就是财富”这句话，过去或许只是哲学层面的指引，但在AI时代已成为触手可及的现实。想要打造能够提升业务效率的Agent，知识管理不应只是某个项目中的临时任务，而应成为每个组织、每家企业的日常习惯。只有深入理解AI对知识底座的需求，才能在平时有意识地进行搜集与整理，从而在场景落地时从容应对。