最近在建设自动化、无人值守运维（unattended）和复杂业务数据分析 agent 的过程中，我们反复遇到一个问题：系统已经接入了知识检索，模型也具备很强的语言理解与推理能力，但在真正需要处理流程性任务时，agent 仍然会生成看起来完整、实际上并不存在的处理流程。

问题表面上像是幻觉；但进一步拆解后会发现，症结并不只在模型，也不只在提示词，而在于系统提供给模型的知识对象本身就被切错了。

在这些场景里，agent 面对的往往不是一段单点事实，也不是一条孤立规则，而是一个具有前置条件、步骤顺序、分支判断、例外条件、回滚策略和责任边界的整体流程。一旦知识系统以 chunk 作为主要检索单位，返回给模型的就不再是完整流程对象，而是若干局部相关、来源各异、版本不一的片段。模型再凭借其推理能力去补全缺口，最终得到的，往往不是更可靠的执行路径，而是一条被东拼西凑出来、逻辑上自洽但事实上并不存在的流程。

也正是在这个问题上，才逐步引出了一个更基础的思考：知识库系统的核心，到底应该建模什么。

如果借用《庄子·养生主》里常被引用的一句话——“臣之所好者，道也；进乎技矣。”——那么放到知识系统建设的语境中，它给出的提醒很直接：应先界定系统中何者构成“知识”，再讨论 TextRAG、GraphRAG、rerank、agentic retrieval 这些具体技术路径。

一、问题从哪里冒出来：agent 面对的是流程知识，而不是文本片段

在无人值守运维与复杂业务数据分析场景中，agent 所处理的问题有一个共同特点：任务不是靠单条事实就能完成的，而是依赖一组有结构的知识。

以无人值守运维为例，一个真正可执行的处理流程通常至少包含：

• 故障识别条件
• 适用范围与前置假设
• 止血步骤的执行顺序
• 指标观察点与阈值判断
• 例外场景下的分支动作
• 升级条件
• 回滚条件
• 责任边界与审计要求

复杂业务数据分析也是类似的。一个看起来像“帮我分析为什么这个指标异常”的请求，背后往往并不是一句话能解决的。它通常依赖：

• 指标口径定义
• 数据表与字段关系
• 分析顺序
• 拆解维度
• 过滤条件
• 异常排查路径
• 经验性判断规则
• 特定业务场景下的例外说明

无论是运维还是分析，这些内容都更接近一个流程型知识对象，而不是一组可以任意拼接的文本片段。

在有人工兜底的场景下，系统即便只返回局部材料，使用者也可能通过经验把它们重新校正。但在 unattended 场景里，错误不会停留在理解层，而会直接进入行动层。此时，知识对象是否完整、是否处于正确版本、是否满足适用范围，就不再是“体验问题”，而是执行质量问题。

二、问题如何暴露：chunk 检索会把流程打碎，而模型会把碎片重新“补全”

如果知识系统主要围绕 chunk 建索引，那么在流程型任务里，系统很容易召回到这样一组内容：

• 某篇 runbook 里的一个止血步骤
• 另一篇文档里的阈值说明
• 某个旧版本流程里的回滚条件
• 一条只适用于特殊租户的例外规则
• 一段看起来相似、实际上来自其他业务场景的分析 SQL

这些片段单独看都相关，甚至都“像答案的一部分”。但它们并不必然属于同一个流程对象，也不必然来自同一个版本、同一个作用域、同一个责任边界。

问题在于，大模型面对这类输入时，通常不会停在“信息不完整”。相反，它会利用自身较强的语言组织与推理补全能力，把这些片段整合成一条完整的叙述链路。

于是系统得到的不是“若干有待确认的碎片”，而是一条：

• 顺序完整
• 表达流畅
• 看起来很合理
• 但事实上并不存在于任何真实知识对象中的流程

这类错误比普通问答场景中的幻觉更难察觉。因为它通常不是明显编造一个无中生有的事实，而是把多个真实片段错误地组织成一个虚假的整体。

因此，问题并不只是“模型会幻觉”，而是：当系统把流程知识切碎后，模型会非常自然地把碎片重新补成一个貌似合理的流程。

这也是为什么在这些场景中，单纯强调模型推理能力，往往不能真正解决问题。模型越擅长补全，反而越容易把对象层的错误掩盖成一条看似高质量的答案。

三、由此才引出一个更基础的问题：知识库的核心到底是什么

一旦问题被还原到这里，讨论的重点就会发生变化。

起初看上去，问题像是在问：

• RAG 的召回为什么不够准
• rerank 为什么没把最好的片段排前面
• GraphRAG 能不能改善多跳检索
• prompt 如何约束模型不要乱拼

但这些问题都还停留在“如何更好地取用知识”的层面。

更基础的问题其实是：系统到底把什么当成了知识。

如果知识系统的核心对象是：

• 文档
• chunk
• 或围绕 chunk 抽出来的松散实体与关系

那么后续所有能力增强，本质上都仍然是在围绕这些对象做优化。问题是，这些对象未必就是知识系统中真正应被治理、被复用、被追责的对象。

于是，原本是一个工程实现问题，最后会自然走向一个更抽象但也更根本的判断：知识库系统的核心，不应首先是 document，也不应首先是 chunk，而应是知识对象本身。

四、在实践里，我们最终抽象出了 brief 与 playbook

如果把前面的讨论继续落回工程实现，会发现问题并不会自然收敛到“要不要更强的检索”上，而是会逼着系统回答：究竟应该把什么样的对象交给 agent。

在我们的语境里，最终逐步抽象出了两类对象：brief 与 playbook。

1. brief：轻量知识对象，本质上仍接近 chunk

brief 对应的是那些局部事实、简短说明、局部规则、字段定义、阈值解释、上下文补充之类的轻量知识。它的价值主要在于：

• 能快速提供局部证据
• 能补足上下文细节
• 能作为回答或推理过程中的引用材料

从对象强度上看，brief 和普通的 chunk 召回并没有本质差别。它解决的仍然是“把局部信息更快、更准地拿出来”的问题。因此，brief 并不是在否定 chunk，而是在承认：对于这类知识，轻量检索单元本来就是合理的。

这也意味着，文章这里要反对的并不是 chunk 本身，而是把所有知识都压成 chunk，再让模型负责恢复对象边界。

2. playbook：流程知识对象，是 RAG 与 skill 之间的新形态

playbook 则完全不同。它不是局部证据，而是面向任务执行的流程型知识对象。

从能力上看，playbook 保留了传统 skill 中非常有价值的部分，例如：

• 步骤描述
• 工具使用约束
• 前置条件
• 分支判断
• 执行顺序
• 回滚与结束条件

但它又不等同于传统 skill。

在很多 agent 系统里，skill 往往意味着一种预先安装、显式激活、相对封装的能力单元。这种方式在边界明确、任务单一时很有效；但当任务无法被单个 skill 独立覆盖，或者需要跨多个能力域协作时，就容易遇到两个问题：

• 必须先知道该激活哪个 skill
• 多个 skill 之间不容易在同一任务上下文里自然协同

playbook 的价值恰恰在于，它试图把 skill 的结构化执行知识，与 RAG 的按需检索能力结合起来：

• 保留步骤、工具和条件这些执行语义
• 不要求先安装或显式激活单个 skill 才能使用
• 可以按任务上下文被动态召回
• 当任务跨多个能力域时，也更容易与其他 playbook 或 brief 共同参与同一轮规划与执行

如果从这个角度看，playbook 可以理解为一种介于传统 RAG 与传统 skill 之间的新对象：它不是纯文本片段，也不是必须先进入运行时才能生效的封闭技能包，而是可检索、可组合、可约束执行语义的流程知识对象。

3. 这两个对象真正说明了什么

brief 与 playbook 放在一起，恰好说明了同一件事：知识系统需要的不是单一抽象，而是与知识形态相匹配的对象抽象。

• 对局部事实和局部证据，轻量对象已经足够
• 对流程、方法、运维处置、分析路径这类知识，必须有比 chunk 更强的对象边界

这也正是为什么“知识库的核心到底是什么”会成为一个必须先回答的问题。因为如果对象没有先定义清楚，就无法判断一条知识到底应该以 brief 的形式存在，还是应该以 playbook 的形式被治理、检索和复用。

五、文档不是知识，RAG 也不是知识

这句话表面上像是在做概念辨析，但它对应的是一个非常具体的系统设计问题。

1. 文档不是知识

文档当然重要。对人来说，文档是最自然的创作、传播和阅读载体。

方案、规范、FAQ、案例复盘、经验总结，通常都以文档形式存在。但文档是按照人类阅读需求组织起来的，并不是按照系统治理需求组织起来的。

一篇文档里经常同时包含多类内容：

• 概念定义
• 业务规则
• 操作流程
• 例外条件
• 经验结论
• 风险提示
• 背景说明

对人来说，这些内容被放在同一篇文档里是自然的，因为阅读依赖上下文；但对系统来说，它们并不是同一种对象。

例如：

• 定义和规则不是一类知识
• 流程和经验不是一类知识
• 例外条件和主规则也不是一类知识

如果系统把它们统一建模成 document，那么后续很多能力都会落在错误的对象层级上：

• 冲突治理会停留在文档层，而不是知识层
• 版本演进会停留在“改过哪篇文章”，而不是“哪条知识已失效”
• 复用会停留在“引用整篇文档”，而不是“引用某个生效规则”
• agent 消费时拿到的仍是一个大包裹，而不是明确的知识对象

因此，文档当然是知识的载体，但它不是知识系统里最适合被治理的最小单元。

2. RAG 也不是知识

如果说“把文档当知识”是传统系统常见的问题，那么“把 RAG 当知识”就是很多 AI 系统正在重复的新问题。

RAG 的核心价值，是让系统能从已有知识源中取材，再配合模型完成生成、问答和推理。它解决的是知识的访问与消费问题。

但 RAG 中最常见的核心对象——chunk——并不是知识单元，而是检索单元。

chunk 的边界通常由这些因素决定：

• tokenizer 如何切分
• 上下文窗口有多大
• 检索精度与召回率如何平衡
• 工程上如何切片最方便

这些边界本质上是检索边界，不是知识边界。

也就是说，chunk 之所以存在，首先是为了“更容易找到”，不是为了“更准确地定义知识是什么”。

这会带来一个常见但常被忽略的问题：

chunk 很适合做证据材料，但并不适合天然充当知识系统的核心对象。

因为一旦把 chunk 当成知识本体，系统就很容易出现这些现象：

• 同一条知识在多个 chunk 中被重复表达
• 一条规则被拆散到多个片段里，边界变得模糊
• 不同版本、不同适用范围的内容在召回时混在一起
• LLM 能把多个相关片段拼成一段流畅回答，但系统本身并不知道这段回答到底绑定的是哪条知识

因此，文档不是知识，RAG 也不是知识。

文档适合呈现，RAG 适合消费，而知识本身，应该被单独建模。

五、从 TextRAG 到 GraphRAG，为什么仍然可能停留在“术”

一种常见观点是：既然 TextRAG 主要依赖文本相似性，那么就应引入 GraphRAG，以获得关系理解与多跳检索能力。

这一方向当然有现实价值，而且在不少场景下确实有效。GraphRAG 的典型收益包括：

• 把跨片段关系接起来
• 从“词相似”走向“结构相关”
• 更适合做多跳检索
• 更容易给出一条更具路径解释性的推理链路

但需要区分的是，GraphRAG 提升的是知识取用能力，不是知识定义能力。

如果底层图里的节点仍然是：

• 文档
• chunk
• 从 chunk 中抽出来的松散实体

那么系统依然没有回答这些关键问题：

• 哪个对象才是知识系统的一等对象
• 哪条规则当前处于生效状态
• 哪个流程适用于什么前提条件
• 哪两条知识是冲突关系，哪两条只是补充关系
• 哪个对象可以被审核、追踪、追责和复用

换句话说，GraphRAG 解决的是检索路径问题，不是知识本体问题。

如果对象建错了，图并不会自动把对象建对；很多时候，它只是把既有对象进一步关系化、复杂化和技术化。

因此，从 TextRAG 到 GraphRAG 的许多升级，并不能替代对象层的重新定义。它们主要是在既定对象之上增强能力边界，仍然属于“术”的范畴。

六、为什么知识建模比检索增强更重要

知识系统真正要解决的，绝不只是“能不能找到相关内容”。

一个真正可用的知识系统，最终总会面对这些问题：

• 这条知识是否成立
• 它适用于什么范围
• 它是否已经过期
• 它和其他知识是否冲突
• 它的证据与来源是什么
• 当前由谁维护
• 当前版本是否已审核生效
• 它能否被不同场景、不同 agent 安全复用

这些问题中，只有很少一部分是纯检索问题。更多的是：

• 对象定义问题
• 状态管理问题
• 作用域约束问题
• 关系建模问题
• 治理问题

而这些问题如果没有一个明确的知识对象，就几乎无从谈起。

这一点可以进一步概括为：

传统 RAG 检索的是像答案的片段，而知识系统应该检索能负责的知识对象。

所谓“能负责”，至少意味着它应当具备这些属性：

• 有明确边界
• 有适用范围
• 有来源与证据
• 有生效状态
• 有责任归属
• 有版本与演进历史
• 能被引用、复用和废弃

只有当系统真正围绕这样的对象建模时，后面的检索、问答、推荐、agent 调用才有稳固的基础。

否则，系统拿到的就只是一组看起来相关的材料，而不是一组可治理、可解释、可复用的知识。

七、playbook 是一个典型例子

在各类知识对象中，playbook 是最容易暴露传统 RAG 边界的例子之一。

因为 playbook 从来都不只是“一段说明文字”，它本质上是一个结构化的流程知识对象。一个典型的 playbook 往往会包含：

• 要解决什么问题
• 适用于什么场景
• 执行前需要满足哪些前置条件
• 应按什么顺序执行哪些步骤
• 遇到什么条件需要分支处理
• 哪一步触发升级或转人工
• 哪些风险点必须提醒
• 出现错误时如何回滚
• 当前 owner 是谁
• 当前版本是否生效

也就是说，playbook 的本体不是文本，而是流程、约束、分支、状态和责任的组合。

1. 如果把 playbook 当普通文档做传统 RAG，会发生什么

一种常见做法是：

• 先把 playbook 写成文档
• 再按长度切成若干 chunk
• 用 chunk 建索引
• 查询时召回 top-k chunk
• 把这些片段交给模型生成答案

这一流程在工程上很常见，但它有一个根本问题：

它把一个本来具有全局结构约束的知识对象，拆成了多个局部相似片段。

于是系统经常会召回到：

• 一段处理步骤
• 一段监控阈值说明
• 一段升级条件
• 一段旧版本遗留策略

这些片段单独看都“像答案”，但拼起来未必构成一个正确、可执行、可负责的 playbook。

于是就会出现几类典型问题：

• 召回了步骤，却没召回前置条件
• 召回了局部最佳片段，却丢掉了完整流程
• 把不同 scope 下的处理经验拼在一起
• 把不同版本的规则拼成了同一个答案
• 模型生成出一段流畅的话，但执行上并不可用

这里真正丢掉的，不是“文本细节”，而是结构。

当知识对象本来是流程时，把它切成 chunk 再召回，本质上是在用局部相似性去重建一个全局有约束的对象。这个过程天然会丢失结构。

2. 如果把 playbook 作为知识对象来建模，会发生什么

正确的方向不是不要文本检索，而是先承认：playbook 是一等知识对象，文本只是它的某种表现形式。

一旦这么看，系统的检索方式就会发生根本变化。

用户问的就不再是：

• 给我找几个最像的 chunk

而更像是：

• 给我找最相关的 playbook
• 告诉我它当前的生效版本
• 告诉我它适用什么范围
• 展示它的关键步骤、前提条件、分支条件、回滚策略
• 附上相关证据片段和来源说明

这时 chunk 当然仍然有价值，但它的角色变了。它不再是知识本体，而是：

• 证据单元
• 解释材料
• 辅助召回特征

这个差别看起来只是“召回单位”变了，实际上改变的是整个系统对知识的认识方式。

八、商业搜索引擎其实早就给出了更成熟的蓝本

如果把视野从 RAG 系统稍微拉远一点，会发现商业搜索引擎很早就对这个问题给出了更成熟的处理方式。

这里有一个常见误解：把商业搜索理解成“就是搜文档”，再把 RAG 理解成“终于可以直接搜片段了”。

更准确的说法是：商业搜索内部当然会使用 passage、片段和局部证据，但它通常不会轻易把孤立片段当成主结果本体。

无论是综搜还是大量垂搜，用户最终看到和消费的主单位，通常仍然是这些对象：

• 一个网页
• 一篇文章
• 一个商品
• 一个视频
• 一个问答页
• 一个医生主页
• 一个职位
• 一个门店或服务对象

也就是说，搜索系统的主结果单位，通常是 doc、page、item 或 object，而不是一个脱离上下文的孤立 chunk。

原因也并不复杂。搜索系统要解决的从来不只是相关性，还包括：

• 权威性
• 可理解性
• 去重
• 时效性
• 归属关系
• 质量评估
• 展示闭环
• 排序治理

这些属性都需要一个稳定对象来承载。

chunk 可以帮助理解、帮助打分、帮助摘要生成、帮助证据展示，但它很难单独承担这些治理属性。

所以一个值得记住的判断是：

搜索引擎会把片段当证据，而不会轻易把片段当结果本体。

这一点对知识系统非常有启发。

九、真正值得借鉴的，是商业搜索的对象建模与处理 pipeline

很多团队在做知识系统时，最容易抄的是各种 RAG demo：

• 文档切片
• embedding 入库
• top-k 检索
• 拼接上下文
• 调模型生成答案

这条链路很直观，也容易快速跑起来。但如果系统要做深，它并不是最好的蓝本。

更值得借鉴的，是商业搜索那套成熟得多的对象建模与处理 pipeline。

一套典型的搜索 pipeline，往往会包括：

• 对象获取
• 对象解析
• 对象规范化
• 对象理解
• 对象治理
• 索引构建
• 召回排序
• 结果呈现

这套 pipeline 最重要的启发不在于某个排序 trick，而在于它的顺序：

先定义对象，再理解对象，再治理对象，最后才是围绕对象做索引、召回和呈现。

如果把它映射回知识系统，会变成这样：

• 从文档、FAQ、规则库、操作记录、playbook 中采集知识源
• 从知识源中解析出事实、规则、流程、定义、实体和关系
• 对这些知识做去重、规范化、版本识别和来源绑定
• 对知识对象做审核、冲突检测、失效判断和 owner 管理
• 为不同层次的对象构建索引：文档索引、对象索引、关系索引、向量索引
• 在检索阶段做对象召回、关系召回和证据召回
• 在呈现阶段返回完整知识对象，并附上证据、解释和上下文

这时，RAG 不再是“整个知识系统”，而只是消费层中的一个重要接口。

这也解释了为什么在生产力场景中，需要谨慎评估那些以开箱即用、端到端智能问答为主要卖点的统一知识平台。此类产品通常能快速完成采集、切片、索引、检索和生成闭环，因而在 PoC 阶段具备明显效率优势；但它们也往往预设了对象模型、治理边界与使用路径。如果组织尚未先定义知识对象、状态、责任、版本与关系，就容易把产品抽象误认为知识系统抽象本身。短期内，这种路径能够降低接入成本；长期看，一旦进入规则知识、流程知识、冲突治理和 agent 复用场景，预设模型的约束就会逐步显现。

十一、可以把知识系统分成三层：文档层、知识层、消费层

如果把前面的讨论再压缩成一个更清晰的结构，可以把知识系统看成三层。

1. 文档层

文档层面向的是人类：

• 创作
• 编辑
• 阅读
• 讨论
• 归档

这一层强调上下文组织、可读性和创作效率。它非常重要，但不适合作为知识系统唯一的核心模型。

2. 知识层

知识层才是系统真正的中枢。

这一层需要建模的不是“文章”，而是：

• 知识对象
• 知识关系
• 作用域
• 生效状态
• 证据
• 冲突
• 版本
• owner

当系统能围绕这些对象工作时，很多此前只能依赖人工判断的能力，才会变成系统能力：

• 哪条规则和哪条规则冲突
• 哪个流程属于哪个版本
• 哪条结论适用于哪个租户、业务、时段或环境
• 哪条知识已经失效但仍被引用
• 哪个 agent 可以安全使用哪些知识对象

3. 消费层

消费层面对的是各种使用知识的方式：

• 搜索
• RAG
• Agent
• 推荐
• 问答
• 工作流执行

这一层当然可以很强，但它不应该反过来定义知识层的对象。

这可以概括为：

文档是载体，RAG 是接口，知识对象才是领域模型。

十二、结语：不要把更强的检索，误认为更好的知识系统

在 unattended 运维和复杂业务数据分析场景中，问题并不只是模型会不会幻觉，而是系统是否把真正需要执行、需要追责、需要复用的知识对象正确地交给了模型。

如果系统交给模型的只是若干局部相关的 chunk，那么模型越擅长推理，就越可能把这些碎片组织成一条事实上不存在的流程。

因此，TextRAG、GraphRAG、rerank、agentic retrieval 当然都重要；但它们首先解决的是“如何更好地取用知识”，而不是“知识本体应该是什么”。

由此可见，知识库的下一阶段，未必首先是更强的召回、更长的上下文或更复杂的图，而更可能是更好的知识建模。

问题不应首先是如何把 chunk 找得更准，而应首先是：系统里真正应该被建模、被治理、被复用的，到底是什么。

如果这个问题没有回答清楚，那么文档会越来越多，chunk 会越来越碎，图会越来越复杂，模型会越来越能说，但知识系统本身未必会因此更清晰。

反过来，如果这个问题回答清楚了，那么文档、RAG、GraphRAG、agent 都会回到各自更合适的位置上：

• 文档负责表达与传播
• RAG 负责检索与生成
• 图负责组织与关联
• agent 负责执行与编排
• 知识对象负责成为这一切的稳定核心

这可以作为本文的结论：

建模的应当是知识，而不是文档或 RAG。