传统知识库为什么撑不起 Agent 的 "上下文" ?

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

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

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

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

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

01 Agent 卡住的地方, 不在 "找不到文档"

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

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

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

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

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

企业需要的不是 "大上下文" , 而是一围绕任务组织的任务上下文包. 它至少包含六类内容:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

系统最终交给工程师的, 应当是一可以继续处理的工作底稿, 而不是一句 "根因就是某参数" 的结论.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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