Agent 有了 Skill 和 Memory，还需要 Knowledge 吗？
Skill 存流程，Memory 存经历，事实没人存——这就是 Knowledge 必须单独留一层的原因。
- 三 层分工：Skill 管怎么做，Memory 管发生过什么，Knowledge 管事实是什么。
- 事实写进 Skill 会腐坏：流程半年一改，价目表一周一改，两者不能同一个生命周期。
- 事实写进 Memory 会被污染：一次错误结论会被当成「我记得」反复引用。
- Graph 不是 没前途，是被误当成通用记忆层：独占场景只剩多跳关系和时序失效。
- 大多数公司不需要再抽一张图——业务库外键、CMDB、数据血缘早就是图。
- grep 替代 RAG 有三个前提：在文件系统上、目录有语义、术语是稳定字面量。
- 结论：知识组织的成本从检索侧前移到了写作侧。
三种知识，Skill 和 Memory 顶不了事实
认知心理学早就把知识分好类了，Agent 这三层是一一对应的。
| 知识类型 | Agent 里的载体 | 内容 | 变化频率 |
|---|---|---|---|
| 程序性（procedural） | Skill / SKILL.md | 怎么做一件事、按什么顺序、检查点在哪 | 低，月级 |
| 情景性（episodic） | Memory | 这个用户是谁、上次结论是什么、踩过什么坑 | 中，会话级 |
| 语义性（semantic） | Knowledge | 客观事实：价格、组织架构、接口契约、政策条款 | 高，天级 |
Skill 和 Memory 不是「更高级的知识库」，它们连存储事实这件事都不擅长。
「怎么申请预算」是流程，写进 Skill 没问题。「今年 Q3 单笔审批上限是多少」是事实，写进 Skill 就是把一个天级变更的数据钉在了月级更新的文件里。等财务改了政策，Skill 还在自信地引用旧数字——而且它是 流程的一部分，模型不会怀疑它。
事实写进 Skill 会腐坏，写进 Memory 会被污染
Skill 的失效方式是 静默过期。它没有 TTL、没有 owner 提醒、没人做一致性校验。一份 SKILL.md 里混着 20 行流程和 3 个硬编码数字，半年后那 3 个数字全错，但流程还对，所以没人会去删这个 Skill。
Memory 的失效方式更糟，是 自我强化。Agent 某次推理出「这个客户走的是渠道价」，写进了 Memory；下一轮它读到这条，当成既有事实继续推理，又派生出新的错误记忆。这就是 memory poisoning——Agent 把错误信息写进记忆后怎么办？里说的那套问题，根子上是把「推断」和「事实」存在了同一个地方。
Memory 里应该只有「谁说过什么、什么时候发生」，事实要指向 Knowledge 的具体位置。正确写法是 报销上限见 knowledge/ops/reimbursement.md，而不是 报销上限 800 元——前者永远不会过期，后者一定会。
所以 Knowledge 这一层不是「 还需不需要」的问题，而是它 必须有独立的 owner、独立的更新路径、独立的可追溯性。Skill 和 Memory 都给不了这三样。
Graph knowledge 有没有前途？看关系本身是不是答案
判定标准只有一条：你的问题里，关系是答案，还是只是路径。
- 关系是答案：「这个服务挂了会影响哪些下游」「这笔钱最终流向谁」「A 离职后他审批权限继承给了谁」——图的独占场景，向量检索根本表达不了多跳。
- 关系只是路径：「报销标准是多少」「这个接口怎么调」——文档里一段话就说完了，抽成实体关系纯属自找麻烦。
至于「GraphRAG 是不是在炒冷饭」，我的判断是：技术不是冷饭，把它当通用记忆层卖才是。用 LLM 从非结构化文档里抽实体和关系，成本高、精度飘、schema 一改就得全量重建，而且抽出来的图质量取决于抽取 prompt——你花大钱换来一张不可信的图。
更关键的一点，多数人没意识到：
业务库的外键关系、CMDB 的服务依赖、数据平台的血缘、IAM 的权限继承、组织架构表——这些都是 已经存在、由系统维护、天然准确 的图。需要图能力时，正确做法是把这些图暴露成一个查询工具给 Agent 调，而不是拿 LLM 从 PDF 里再抽一张平行的、更差的图。
Graph knowledge 有前途的是「图查询工具化」这个方向，没前途的是「把所有文档灌进 GraphRAG 建索引」这个姿势。
grep 能不能替代 RAG？看三个前提
Claude Code 用 grep 不用向量检索（ClaudeCode 为什么放弃了 RAG？），但这个结论不能直接搬到公司知识库上。grep 成立要同时满足三条：
| 前提 | 代码仓库 | 公司业务文档 |
|---|---|---|
| 内容在文件系统上，可被逐层导航 | 天然满足 | 散在 Confluence / 飞书 / 邮件附件，不满足 |
| 目录和文件名有语义，能当索引用 | 天然满足 | 「新建文档-副本(1)」，不满足 |
| 查询词和内容里的词是同一个字面量 | 函数名、类名是精确标识符 | 用户问「报销」，文档写「差旅费用限额」， 不满足 |
第三条是企业场景最大的坑。grep 找字面量，向量找相似度，用户提问用的是口语词，文档写的是正式术语，中间这层落差在代码里不存在（没人把 getUserById 叫成「取人的那个方法」），在业务文档里却是常态。
我的处理办法不是上 RAG，是 把召回问题前移到写作时——在文档 front-matter 里写别名：
---
title: 差旅费用限额与报销流程
owner: finance-ops
updated: 2026-07-20
aliases: [报销, 报销标准, 差旅, 打车费, 发票, 住宿上限]
---
grep 一次 aliases 就命中了。这比维护一条 embedding 管线便宜两个数量级，而且 改一个词立刻生效，不用等重建索引。
业务文档放哪里、怎么组织？
结论：放在 Git 仓库里，用目录做分类，用索引文件做导航，用 front-matter 做召回。
knowledge/
README.md # 顶层索引：每个域是什么、owner 是谁
product/
INDEX.md # 本域文件清单 + 一句话摘要
pricing.md
ops/
INDEX.md
reimbursement.md
decisions/ # 决策记录，只增不改
2026-03-give-up-self-hosted-gateway.md
四条约定就够了：
- 每层一个
INDEX.md——人类可读的索引，就是 Agent 的检索器。它读 INDEX 就知道该 Read 哪个文件，不需要猜。 - 每个文件有 owner 和 updated——事实必须能问责，这是 Knowledge 区别于 Skill 的核心。
- 决策记录只增不改——变更写新文件，旧文件标 superseded，Agent 才能回答「为什么当初这么定」。
- 一个事实只有一处权威副本——其他地方一律写链接。重复的事实一定会分叉。
那什么时候还是得上向量检索？语料规模超过 Agent 能扫的量级（十万级文档以上）、 跨语言、或者内容在扫描件和录音转写里。但即便这时，检索的产物也该变一变：
关键在 E 那一步：让检索返回位置，而不是返回答案素材。传统 RAG 把 top-k chunk 塞进 prompt，切片边界一错答案就错；返回路径则让 Agent 自己去读完整上下文，切片精度不再是准确率的乘数。
为什么 Claude Code 都是 Skill？
因为它的 Knowledge 层已经在工作目录里了，不需要单独建。
代码仓库本身就是那份权威事实：接口签名、配置项、依赖版本，全是可 grep 的字面量，而且永远是最新的——它就是运行的那份代码。加上 CLAUDE.md / AGENTS.md 承载项目级约定，Knowledge 的活已经干完了，剩下要补的只有「这类任务按什么流程做」，那正是 Skill 的定义域。
所以「Claude Code 都是 Skill」不能读成「Knowledge 不需要了」，要读成：当知识天然长在工作目录里、且随代码一起演进时，检索层可以省掉。公司业务知识不满足这个条件——它散在十几个 SaaS 里、没有 owner、和执行动作不在同一个空间。把它先搬成一个 Agent 能导航的仓库，这一步没人能替你跳过。
Agent 时代知识管理最大的变化，是成本位置变了：以前砸在检索侧（切片、embedding、rerank、图抽取），现在砸在写作侧（目录约定、索引文件、别名、owner）。后者更笨，但它不会腐坏。
References
- RAG 和 Skill 区别？什么场景必须用 RAG？Skill 能替代吗？ —— 2026-07-24
- ClaudeCode 为什么放弃了 RAG？ —— 2026-06-24
- Agent 把错误信息写进记忆后怎么办？ —— 2026-07-22
- Agent 长对话 Memory 怎么设计？ —— 2026-07-26
- Agent 如何加载海量 Skill？ —— 2026-07-22
- Anthropic Agent Skills 官方文档 —— Skill 结构与渐进式加载
- Microsoft GraphRAG —— LLM 抽取实体关系建图的参考实现
- Zep: A Temporal Knowledge Graph Architecture for Agent Memory —— 时序知识图谱做 Agent 记忆