传统知识库为什么撑不起Agent的“上下文”？

AI进入企业业务流程后，很多团队都会遇到同一个问题：模型能从资料库中找到相关内容，却很难据此完成一项真实任务。

以设备异常处理、制度审核或客户方案准备为例，Agent召回了文档，并不代表它知道当前该用哪一版规则、这条经验是否适用、谁应当确认，以及下一步能否执行。很多团队因此不断增加文档、优化RAG，或在应用层拼接数据、提示词和接口；系统看起来越来越复杂，但Agent依然缺少可用的业务上下文。

问题不只在检索，而在于企业能否把原始证据、高频经验、项目状态、责任关系和受控行动组织成一条连续的知识供给链。

本文解释传统知识库为什么难以支撑Agent的上下文，并拆解RAG、知识编译、组织记忆、Skill与结果回流在一次真实任务中分别承担什么角色。对希望让人、流程与Agent更顺畅协同、逐步形成“超级组织”能力的企业而言，这是一项需要先补齐的基础工作。

本文作者严超，360AI知识库产品负责人。全文约5,500字，阅读约需10分钟。

01 Agent卡住的地方，不在“找不到文档”

如果系统只给它几段语义相近的文本，模型会自行补齐空白。它可能写出一段很像专家意见的总结，却未必知道这段经验来自哪次项目，是否已被新制度替代；也未必知道当前任务是否允许它继续调用业务系统，或修改结果。

因此，许多企业AI项目在演示阶段很顺利，进入生产后却会被业务人员追问：“依据是什么？”“为什么是这一版？”“出了问题找谁？”

问题不在于召回文档不够多，而在于企业没有把文档背后的判断条件与责任边界一并交给Agent。

有人把上下文理解为“给模型更多材料”。这是一种常见误解。

模型上下文窗口再大，也不应该把历史邮件、会议记录、制度文件和数据库结果无差别装进去。这样做会增加推理成本和响应时间，也会带来更多噪声和更模糊的权限边界。材料越多，模型越难判断哪一条才是当前任务真正可以采用的依据。

企业需要的不是“大上下文”，而是一个围绕任务组织的任务上下文包。它至少包含六类内容：

以现场异常诊断为例，系统不应把“所有设备文档”交给模型，而应先收拢与本次告警相关的设备、工艺、批次、现行SOP和历史案例；再过滤掉失效标准、无权资料和不适用案例；最后把处置依据、风险提示和需要人工确认的节点，组成一个可读、可查的上下文包。

此时，Agent的回答有了明确的事实范围、规则约束和责任边界。

把它放到运行时，会得到一条更具体的装配链路：

要理解Agent为什么需要知识中枢，先要看任务所需的知识从哪里来。检索增强生成（Retrieval-Augmented Generation，RAG）擅长从海量原始资料中找回相关片段。它适合处理长尾问题，也适合在用户需要核对原文、追溯细节时提供证据。

问题在于，原始材料通常没有为某个具体任务预先组织好判断条件。一段会议纪要可能记下了“客户要求延期”，却没有把客户背景、项目阶段、承诺、风险和后续结果关联起来；一份SOP可能有完整条款，却没有在检索时自动表达哪一版有效、哪些设备适用、由谁负责发布。

因此，面向Agent的知识体系通常需要两条并行链路：

在360AI知识中枢的产品设计中，这一过程被称为“知识编译”：在解析、智能分块、摘要提取、标签和向量化之外，再通过LLM Wiki（由模型辅助生成、保留来源与关联的结构化知识页）、场景模板、开放的结构化知识格式和本体等方式，将原始材料组织为更适合Agent调用的知识。

关键变化在于：知识不再只是原始文本，而是带来源、对象、关系、版本和适用条件的可调用单元。

一份原始会议纪要可以只是一段文本；经过编译的知识单元则会保留来源文件锚点，抽取主题、对象和关系，关联版本与适用范围，并为高频问题沉淀可复用的知识页或模板。资料更新后，相关知识单元也需要更新、废弃或重新审核。Agent查询时，不必从几十篇会议纪要里重新推理全部关系，而可以先定位到相应的组织记忆，再按需返回原始证据。

RAG与LLM Wiki不是替代关系。前者保证原始证据和长尾信息可被找回，后者提高高频任务的上下文密度和可复用性。两者共同组成“先有可靠知识，再有可靠回答”的供给链。

但这还不是几项彼此独立的能力。对于一次真实任务而言，RAG先找回原始依据，知识编译再整理高频规则和经验；组织记忆补足项目状态、责任和历史决策；在人工确认后，Skill负责执行被授权的动作；最终结果经过审核后回流，成为下一次任务可用的知识。

它们前后接续，才构成Agent所需的完整上下文。

这正是“组织记忆”与“文件集合”的区别。文件集合回答“公司有哪些资料”；组织记忆尝试回答“在当前对象、条件和风险下，公司过去是如何判断和行动的”。

但这不意味着企业要把所有人的经验都自动写进知识库。经验必须经过来源约束、场景归类、责任确认和持续评测。特别是在合规、质量、金融、政务等高风险场景，Agent可以协助归纳、发现冲突和生成草案，却不应替代责任人确认标准或批准行动。

所以，组织记忆的形成，依赖企业把原本散落在个人、流程和系统中的Know-how，用可追溯的方式变成可复用的公共资产。

回到开头的新能源制造场景。企业希望降低对少数专家的依赖：当设备报警、参数异常或批次问题发生时，一线人员能够更快找到原因、处置依据和历史经验，并把处理结果沉淀为下一次可复用的知识。

这类任务的技术重点，是把分散的资料、规则和历史案例组织为有顺序的排查过程。

第一步是接入并识别对象。系统需要从MES告警、设备参数、工艺/机台/批次信息、SOP和历史案例中识别这次异常涉及的设备、工序、物料和风险点。此时，文档解析、表格解析、结构化数据映射和实体识别都不是后台细节，而是后续判断能否成立的基础。

第二步是建立关联与范围。同一个参数异常在不同工艺、不同批次、不同版本规范下，处置方式可能不同。系统需要把报警与当前适用的标准、相似案例、已知风险和责任角色关联起来，并过滤掉已失效或不适用的内容。

第三步是给出受控建议。Agent的输出应包括已发现的关联事实、优先排查步骤、有效SOP、相似案例结果、待确认条件和建议决策人。

系统最终交给工程师的，应当是一份可以继续处理的工作底稿，而不是一句“根因就是某个参数”的结论。

第四步是让结果回流。现场专家或维修班组完成处理后，工单、最终原因、处置结果和验证结论不应只留在某次沟通中。经过审核后，它们可以回写为案例知识，使下一次检索不必从零开始。

如果工程师确认需要推进后续动作，Agent才在授权范围内调用Skill（可被Agent调用的受控业务能力），例如创建工单、提醒负责人或提交审批。它不能因为“知道了问题”就自行修改工艺参数或关闭异常。

系统可以推荐排查顺序、引用现行标准、生成处置草案；但它不应越过现场复核直接判定根因、修改工艺参数或关闭异常。这个边界决定了Agent是可靠的协作工具，还是不可控的自动化风险。

这是一条典型的知识闭环：每次输入都服务于当前任务；经过确认的输出，则成为下一次任务可复用的起点。

前面讨论的是一次异常任务如何获得上下文。最后再看，这些步骤在知识中枢中分别由什么能力承接。

产品架构不应是一张能力菜单。对于开头的现场异常任务，读者更关心的是：告警进入后，哪些系统负责识别对象，哪些知识可以被引用，谁能批准下一步动作，结果怎样留下。

在这条链路中，360AI知识中枢首先接入告警、工单、文件和业务数据，并识别其中的设备、批次、项目、负责人等业务对象。知识解析、加工与编译能力把文档、表格、音视频和结构化数据整理为可理解、可关联的知识单元，为后续任务提供有效证据。

当Agent开始处理任务时，系统再结合版本、权限、密级和任务范围过滤候选信息，避免失效资料、无权内容或不适用的经验进入上下文。知识治理则持续处理重复、过期、冲突和需要回流的内容。

在人工确认后，Agent可以通过Skill调用已授权的API和专业方法，创建待办、提交审批或生成业务草案；处理结果再按规则保存为临时产物、候选知识或正式知识。

其中，“读取知识”“调用工具”“回写结果”是三类不同操作。读取时要校验知识范围与版本；调用工具时要校验执行权限和审批条件；回写时要确定结果属于临时工作产物、候选知识还是正式知识。将它们分开设计，才能避免Agent拿到信息后默认拥有全部行动权限。

在这个意义上，知识中枢的价值不在于层数更多，而在于每一步都能回答：输入从哪里来、系统做了什么、谁对结果负责、出现问题如何回到源头。

建设知识中枢时，最容易犯的错误是把目标定成“一次性接入全域数据”。企业内部的数据量巨大，部门和业务线复杂，且不同知识的质量、责任、权限和更新频率完全不同。大而全的起步通常会让项目陷入材料清洗和口径争论，迟迟无法验证业务价值。

更合适的起点，是选择一个同时满足四个条件的场景：高频、价值明确、决策链较清楚、结果可回流。会议记忆、项目复盘、合规审核、现场故障诊断、销售报价都可能成为切口。

以会议记忆为例，企业不必先整理所有会议。可以先从一个明确的经营主题或项目群开始，围绕“事实、决策、承诺、变化、经验”建立最小知识模型：哪些会议能进入范围、哪些结论需要确认、谁负责更新、哪些待办需要追踪、上层Agent如何调用。这样既能验证知识提炼是否有效，也能把治理责任和权限边界提前暴露出来。

知识中枢不是一个一次性交付的项目，而是一项持续的知识工程。先让一个场景跑出“接入—提炼—调用—反馈”的闭环，再扩展到更多对象和业务域，通常比先追求知识数量更稳妥。

传统知识库帮助员工找到公司资料；面向Agent的知识中枢，要进一步把资料背后的事实、关系、版本、权限、任务状态和行动边界组织起来。

这并不要求企业先建一个无所不包的“企业大脑”。它要求企业在具体场景里回答几个更朴素的问题：哪些知识是真正的依据？谁对它负责？它适用于什么条件？Agent可以据此做什么？结果又如何回到组织中？

当这些问题有了工程化答案，Agent才不必在每次任务里重新翻资料、猜口径、问同事。它能在企业给定的上下文中工作，给出有来源的建议，完成受控的动作，并把新的结果沉淀为下一次可复用的经验。

这或许才是知识中枢的意义：把企业过去难以传承的判断能力，变成可以持续积累、共享和调用的基础设施。

如果企业准备从一个具体场景开始，建议先选定一种任务，明确它依赖的权威来源、责任人和权限边界，再定义哪些结果允许回流为组织知识。本文讨论的是如何把这些内容装配成上下文；当上下文进入审核、决策和执行流程后，版本、权限、证据与反馈如何被工程化，将是下一篇讨论的主题。

当人的经验、业务流程和Agent产出能够持续汇入同一套可治理的知识体系时，企业沉淀的就不只是答案，而是一种能被更多人和更多Agent共同调用的判断能力。