企业官网建设流程全解析

做Agent应用的时间越长，我越觉得“知识库”这个词被用烂了。市面上大多数知识库产品，本质上是给人用的：漂亮的目录树、富文本编辑器、标签系统、多人协作……但当你把同一个库丢给Agent之后，会发现它根本“读不进去”。我说的不是权限问题，而是格式和结构问题。这半年我反复折腾，最终把整套知识体系改成了一种更朴素、更抗造的方案——Agent原生、本地优先、纯Markdown存储。今天这篇文章就完整讲一下这套方案从设计、存储、检索到与主流Agent框架集成的全过程，顺便把踩过的坑一并交代清楚。

这套方案不是什么灵丹妙药，它只服务于一个核心诉求：让Agent能稳定、高效、可追溯地使用你的私有知识。如果你正在做AI辅助写作、私有化问答、团队协作文档，或者单纯想把个人笔记变成Agent能调用的记忆体，这篇文章的思路应该值得你参考。

1. 先从根上想清楚：Agent到底需要什么样的知识库

1.1 大部分知识库是为“人眼”设计的，不是为“LLM”设计的

建知识库之前，我想先替大家问一个很扎心的问题：你现在的知识库，换谁来读？

如果是人来读，那目录不用太规整，排版漂亮就行，甚至截图、扫描件都能凑合。但Agent读知识的路径完全不同，它只能通过文本解析、工具调用、上下文拼接来“理解”内容。你给它一个排版精致的Notion页面，导出后是一大坨嵌套JSON；给它一个PDF，它要过一层解析模型，图表和表格经常全废；给它一个在线文档链接，它连登录态都没有。

所以“Agent原生”这个词，本质上是在说：知识库的数据格式、组织结构、检索路径，从一开始就是按照“大模型怎么读文本”来设计的，而不是按照“人眼怎么看得舒服”来设计的。

为什么最终选了Markdown？我觉得有三个原因，几乎不可替代：

第一，Markdown是纯文本，token占用极低。同样一段技术文档，Markdown源文件的token数量可能只有HTML导出版本的1/3，PDF解析结果的1/5。Agent上下文窗口是有限的资源，知识库格式越省token，意味着同样的窗口能塞进更多有效信息。

第二，Markdown有可预测的结构。标题层级、列表、表格、代码块、引用，这些结构是明确的、稳定的。LLM在训练语料里见过海量Markdown，它对#、##、-、|这种语法的理解远比对<div class="content">的理解更可靠。你甚至可以直接在工具的返回结果里保留标题结构，让Agent根据标题跳转定位，这比纯文本的一锅粥强太多。

第三，Markdown的生态极度成熟。任何一个编辑器都能打开，Git能做细粒度diff，VS Code、Obsidian、Typora随便选，Python有各种解析库。这种“文件即数据”的属性，让知识库的备份、迁移、版本控制都变得极其简单。

1.2 “本地优先”不是拒绝云端，而是保证数据主权与可审计

“本地优先”这个词容易被误解成“离线主义”，好像用了云服务就低人一等。我的理解不是这样的。本地优先的意思是：知识的权威副本永远保存在你自己的文件系统里，而不是锁在某个平台的数据库里。

这带来三个实打实的好处。

一是数据安全可控。知识库里往往有非公开的技术方案、商业笔记、个人记录，如果把知识库直接放进某个在线知识平台的数据库，你连它服务器在哪儿都不知道。放本地，权限完全由你控制。

二是可审计、可回溯。本地目录天然是一个可Git管理的仓库，每次修改都有记录、有diff、有作者。出了问题时，你能精确地知道是哪一条知识、哪一次改动引入了错误。这一点对企业合规和团队协作尤其重要。

三是不会被平台绑定。今天用这个Agent框架，明天换那个Agent框架，知识文件不用迁移，因为知识库不依赖任何特定软件的存储格式。它只是磁盘上的一个文件夹。

当然，本地优先不意味着不能调云端大模型。常见的做法是：知识文件的读取、检索、过滤都在本地完成，只有被检索到的chunk才作为上下文发送给大模型接口。这样既享受了云端模型的能力，又不用把整个知识库裸露在外部。

1.3 这套方案适合谁，不适合谁

我强烈推荐这套方案给这几类人：

• 在折腾个人AI助手、本地问答机器人，需要一个可持续维护的“外挂记忆”的开发者；
• 小团队的内部知识库，希望知识文件能被Agent直接检索、引用、甚至自动整理；
• 做Agent应用开发，想给Agent挂一套可控的私有数据源，但又不想上重型的向量数据库平台。

同样，它也有明显的边界。如果你需要管理海量PDF合同、扫描件、图片扫描文档，纯Markdown方案会很吃力，你需要的是文档解析管线，不是一个笔记目录；如果你的知识库有几万条强关联业务数据、复杂权限体系，那么你需要的是正经的数据库产品，而不是Markdown文件夹。这个方案的精髓在于轻和透，别让它去扛它不该扛的活。

2. 存储层设计：目录、命名与Markdown规范

设计一个Agent能“读得懂”的知识库，存储层是地基。地基歪了，后面检索做得再好都没用。这里我说的规范不是给别人看的排版规范，而是给Agent的解析器设计的“协议”。

2.1 顶层目录：把“路径”变成“命名空间”

我先给出一个我实际在用的目录模板，然后拆开讲背后的设计逻辑。

knowledge/ 00-inbox/ 01-agent/ 01-concept/ 02-pattern/ 03-prompt/ 02-infra/ 01-linux/ 02-network/ 03-docker/ 03-domain/ 01-product/ 02-market/ _index.md _glossary.md

这套目录结构有三个设计点值得注意。

第一，顶层目录按“域”划分，而不是按时间或文件类型划分。因为Agent遇到一个问题时，第一件事是缩小搜索范围。“这个问题属于哪个域”的判断，通常比“这个问题涉及哪个标签”更直观。当我们让Agent先list_dir('knowledge/')，它看到的就是几个清晰的域，接下来它会顺着路径往下钻，而不是在一堆扁平文件里乱翻。

第二，目录名用数字排序前缀。01-agent、01-concept这种写法，保证了文件系统层面的排序稳定，Agent用list_dir拿到目录列表后，顺序是可预测的。另外一个隐性好处是：目录名本身就是一个“命名空间”，后续做权限管理、范围过滤，直接按前缀处理就行。

第三，设置00-inbox/这个暂存目录。Agent或人收集到的零散素材，先丢进inbox，不强制归类。等攒到一定量，再通过一次“整理会话”让Agent按规则归档。没有inbox，Agent的写操作就会变得特别难控制，这是实操出来的教训。

2.2 单个文件的统一规范

目录结构定好之后，单文件的内容组织才是真正的重头戏。我强烈推荐每篇知识文档使用YAML front matter作为元数据头，也就是文件开头用两行---包起来的键值对。下面是我常用的模板。

--- id: AGT-CON-00102 title: 什么是Agent原生知识库 type: concept tags: [agent, knowledge-base, markdown] created: 2025-01-12 updated: 2025-06-18 related: [AGT-CON-00101, INF-STR-00023] status: active --- # 什么是Agent原生知识库 ## 核心定义 ... ## 实例说明 ... ## 适用边界 ...

为什么必须加id？因为LLM在生成式回复里引用知识点时，如果只写“参考标题为《什么是Agent原生知识库》的文档”，遇到同名文件或者标题被改写的情况就会迷失。稳定的id是给Agent的锚点，标题可以改，id不变，所有引用关系都不会断。

related字段是轻量级的“图结构”。它不等于知识图谱，但它成本极低，维护方便，足以支持“相关推荐”“多跳追溯”这类的需求。如果你的知识库将来一定要升级成KG知识库，related字段就是图谱关系的种子数据。

updated字段同样重要，否则Agent无法判断知识是否过时。在后续检索阶段，我要求Agent先看updated，如果一条知识已经超过半年没更新，而用户问的是时效性要求很高的问题，Agent必须降级处理，不能直接拿旧知识硬答。

2.3 原子化：一个主题，一个文件

最容易被忽视、却最影响检索质量的一句规范是：只允许一个小主题占一个文件。

我见过太多Markdown知识库，本质上是一个“大杂烩文档”，一个文件里写了三十个小节，每个小节之间毫无关联。这种文件一旦被检索出来，Agent要么只读一小段导致上下文不足，要么整个文件塞进上下文导致token爆炸。

我自己的经验阈值是：单个Markdown文件阅读体量超过5000字或者10个独立话题，就要考虑拆分。拆分的规则更简单：先拆出概念页，再拆出操作页。比如原先的《Docker部署指南》拆成《Docker核心概念》《Docker Compose配置模板》《Docker生产事故排查手册》三个文件，每个文件聚焦一个层面的问题。

这样做的好处立竿见影。Agent在检索“Compose网络配置”时，命中的是专门讲Compose的那个文件，而不是在一篇长文档里反复扫描。而且拆文件之后，related关系自然清晰，知识库的网状结构也就浮现出来了。

2.4 正文块级结构：稳定比文采重要

知识库正文不是给人读的散文，是给Agent解析的结构化文本。我要求我自己的知识文件统一使用稳定的块级结构。以概念类文档为例：

## 核心定义 一两句话给出严格定义。 ## 实际案例 给出可复现的例子，代码优先。 ## 适用边界 什么时候可以用，什么时候不要用，以及相互替代的方案。 ## 扩展阅读 相关文档id列表。

强制稳定结构有几个好处：Agent在读取时知道去哪一节找定义、去哪一节找案例，不会把“边界说明”误当成“定义”引用；同时，后续如果做向量化切片，按二级标题切出来的chunk天然语义完整，不会把上下文切得支离破碎。

另外一个细节是表格使用。Markdown表格在LLM解析中表现不错，但要注意：表格的列名必须“自解释”，比如| 工具名 | 用途 | 适用场景 | 注意事项 |，不要用| a | b | c |这种缩写。因为检索阶段的向量模型和Agent本身，都需要从表头理解每一列含义。

3. 检索与工具层：让Agent能“翻书”，而不是背字典

存储规范只是第一步。Agent不会像人一样打开文件管理器去浏览，它需要一套工具系统去访问知识库。我见过不少人把整个知识库塞进system prompt，结果上下文爆掉、回答质量急剧下降。正确的做法是给Agent配一套有节制、有优先级的“检索工具”。

3.1 四个工具就够了：列出、搜索、读取、结构查询

工具数量不是越多越好，每加一个工具，Agent决策的成本就高一分。我实际在跑的知识库工具集，只保留了四个。

这四件套的分工很明确：list_dir负责“浏览目录”，search_all负责“大海捞针”，read_file负责“精读”，grep_struct负责“过滤”。Agent接到用户问题后，会先判断应该用什么工具。比如用户问“Agent安全有哪些注意点”，顺着顶层目录01-agent往下找，很快就能定位；如果用户问的是一个很生僻的概念，Agent就会直接调search_all做全文匹配。

关键细节出现在工具描述里。工具本身的description要写得像“给Agent的操作说明”，而不是给人看的菜单。我写得比较啰嗦，但实际效果很好。比如read_file的description：

read_file用于读取知识库中的单个Markdown文件。 只允许读取knowledge目录下的文件。 返回内容包含front matter元数据与正文Markdown。 如果文件超过200行，先返回目录结构和前100行，等待进一步指令，不要一口吞下。

最后那句“如果文件太长，先返回结构再等待指令”非常关键。它强制Agent不要一次性读完整篇长文，把token消耗控制下来，也给Agent一个继续钻取的选择机会。

3.2 检索策略：先便宜后贵，索引优先于向量

我强烈反对一上来就给知识库套“向量数据库+RAG”的做法。成本高是一回事，更重要的是：很多场景下，不用向量的检索效果反而更好。

我用的检索策略是分层的，按执行成本从低到高排序。

第一层：目录遍历。Agent先看list_dir返回的目录树，按路径猜出大概位置。这个操作开销几乎为零，而且路径本身包含了领域信息，准确率很高。

第二层：关键词全文搜索。直接对Markdown文件跑正则匹配或ripgrep，命中即返回。注意关键词搜索不依赖任何模型，结果确定性强，不会出现“语义相近但字面不同”的幻觉问题。如果用户问题里有明确的术语，这一层基本就搞定了。

第三层：向量语义检索。只有前两层找不到、但用户问题又明显涉及概念关联时，才走这一层。做法是把Markdown按标题切成chunk，每个chunk转成向量存进本地向量库，检索结果返回top k个chunk。

为什么要分层？因为越靠后的检索，计算成本越高、延迟越长、解释性越差。关键词搜索出的结果是可追溯的：“我就是根据docker compose这两个词命中了这个文件”，用户能复核；而向量检索返回的相似度结果，往往让人说不清来由。所以我把向量检索定位成“兜底”，而不是“默认”。

这里顺带聊一下那三个热词纠结点：RAG知识库、KG知识库、结构化知识库到底怎么选。

• 结构化知识库，本质上就是我上面整套方案里的Markdown目录库。它的特征是“人可读、Agent可遍历、路径即语义”，适合知识文件数量在几千篇以内的团队和个人。
• RAG知识库，核心是“向量化+相似度检索”，适合跨文档的模糊问答、总结、比较分析，尤其当你的语料是大段非结构化内容时。缺点是需要维护embedding、异构数据源转换定期同步，且答案可能因为切块不合理而失真。
• KG知识库，核心是实体和关系三元组，适合回答“谁和谁有关”“这类事件的前置条件是什么”这种关系推理题。缺点是构建成本极高，标签、抽取、实体对齐都是大工程。

我的建议很简单：知识库的首选形态永远是结构化文件，纯文本解决不了的跨文档综合再考虑RAG，需要强逻辑链路推理才考虑KG。这三个不是互相取代的关系，而是从轻到重的三个梯度。

3.3 写入与更新：只读优先，写入要过“暂存区”

“只读优先”是我给Agent设的一条铁律。知识库是事实来源，一旦让Agent随便写，它就可能基于幻觉改坏内容。我的设计里，Agent对知识库的默认权限是只读。只有用户明确发起“整理”“记录”“更新知识库”这类指令时，写工具才会被激活。

写操作也不允许直接改正式目录，而是统一写入00-inbox/或一个pending/暂存区。之后由人工确认，或者由另一个专门的“整理Agent”把这些内容合并到正式目录。这个流程相当于加了一个保险丝，避免Agent的每次输出都直接污染知识库。

每次正式目录发生变更，都要同步更新该文件front matter里的updated字段，并触发git commit。提交信息格式我固定成update(KB-xxx): 简述变更内容。这样做之后，任何一次改动都可以用git diff追溯，如果发现Agent写入了一个错误概念，回滚非常方便。这也正是“本地优先”压过在线协作文档的地方。

4. 技术选型与实现：从零搭一套最小可用方案

这一章给一套可以直接落地的技术方案。我不会让你去部署庞大的平台，全部东西加起来，本质就是一个本地目录、一个轻量检索服务、一个对接框架的适配层。

4.1 整体架构

我跑了两个多月的最小架构长这样：

本地方案： 磁盘目录（Markdown文件） ↓ 本地检索服务（Python） ↓ MCP工具 或 http工具 ↓ Agent框架（dify / langchain / crewai / 自定义） ↓ 大模型接口（云端或本地模型）

数据流向是：Agent收到用户问题 → 调用检索工具 → 检索服务返回命中的Markdown片段 → Agent把片段作为上下文交给大模型 → 生成答案。知识文件的读取和检索全部在本地，只有被选中的上下文片段离开你的机器。隐私边界非常清楚。

如果你用的是本地开源大模型，这个链路可以不离开单机。这地方我不展开推理模型部署，只说一点：知识库引擎本身完全没有必要跑在GPU服务器上，一个单核小实例就能扛几千篇Markdown文件的检索，真正的算力消耗在模型推理上。

4.2 检索服务最小实现

本地检索这一层，我用了最朴素的方案：Python+ripgrep+PyYAML，不用任何重型框架。

先看读取文件并解析front matter的核心理念。Python侧用frontmatter库或者PyYAML都行，我习惯用frontmatter，它能把Markdown正文和元数据一次性拆开。

import frontmatter from pathlib import Path BASE = Path("~/knowledge").expanduser() def read_doc(rel_path: str): # 安全校验：防止路径穿越 target = (BASE / rel_path).resolve() if not target.is_relative_to(BASE.resolve()): raise PermissionError("路径越界") post = frontmatter.load(target) return { "id": post.get("id"), "title": post.get("title"), "updated": post.get("updated"), "content": post.content, "path": target.relative_to(BASE).as_posix(), }

路径穿越这个点必须写进代码里。Agent工具层的输入通常来自大模型的输出，而大模型可能因为提示注入或者自身幻觉，输出类似../../../etc/passwd这样的路径。如果没有resolve()和is_relative_to校验，检索服务就变成了一个任意文件读取漏洞。

全文搜索的实现，我直接调系统里的rg，不做数据库索引，胜在零依赖、速度快。

import subprocess def search_md(query: str, max_results: int = 10): result = subprocess.run( ["rg", "-l", "-i", query, BASE], capture_output=True, text=True ) paths = result.stdout.strip().splitlines()[:max_results] return [read_doc(p.replace(str(BASE) + "/", "")) for p in paths]

注意这里加了一个至关重要的参数：-l，只输出匹配的文件路径，不要输出具体匹配行。原因很简单，检索服务返回给Agent的信息越少，Agent越不会被无关内容干扰，上下文也越干净。先返回路径列表，让Agent决定精读哪个文件。

4.3 与主流Agent框架怎么接

接法取决于你先有的Agent框架。

如果你在用dify，有两个选择：一是把知识文件直接上传到dify的知识库模块，让它内部走RAG；二是在Agent节点里挂一个自定义工具，由工具调本地检索服务。我明确推荐后者，因为前者会把Markdown结构打碎成向量chunk，丢失了路径和标题层级信息，也就是失去了“Agent原生”的灵魂。

如果你在用langchain，最自然的做法是用DirectoryLoader加载本地目录，配合MarkdownHeaderTextSplitter按标题切块。这里有个细节，千万不要用默认的RecursiveCharacterTextSplitter按字符硬切，否则会把代码块和表格拦腰斩断。

from langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import MarkdownHeaderTextSplitter loader = DirectoryLoader("~/knowledge", glob="**/*.md") docs = loader.load() splitter = MarkdownHeaderTextSplitter( headers_to_split_on=[ ("#", "H1"), ("##", "H2"), ("###", "H3") ] ) chunks = [] for doc in docs: chunks.extend(splitter.split_text(doc.page_content))

如果你用的是crewai，它也有KnowledgeSource机制，但本质上还是走RAG管线。说实话，这些框架的“知识库”模块都是针对RAG场景设计的，打散重载是其固有逻辑。所以我更推荐走“工具调用”路线，而不是“知识加载”路线——在本地方案里，Agent工具层才保留着完整结构信息。

如果你在自建Agent，直接用MCP协议包一层。MCP已经成为Agent工具的通用接口，一个最小实现大概长这样：

from mcp.server.fastmcp import FastMCP mcp = FastMCP("local-kb") @mcp.tool() def search_knowledge(query: str) -> list: return search_md(query) @mcp.tool() def read_knowledge(path: str) -> dict: return read_doc(path) mcp.run()

这样包好之后，你的知识库对任何支持MCP的Agent客户端来说，都是一个标准工具，而不是某个平台上的私有插件。

4.4 索引与增量同步

纯Markdown方案的一大神韵就是：目录本身就是索引。不需要维护一套独立的数据库，索引就是文件系统。但有三个日常工作要自动跑。

一是初始化扫描：首次把海量旧笔记导入时，要跑一次脚本，统一补全front matter缺失字段，没id的补id，没tags的按目录自动推断。二是增量监听：用watchdog监听目录变化，文件一旦变更就检查front matter的updated是否同步更新。三是定期孤儿检测：找出没有被任何related字段或_index.md引用的文件，这些文件很容易变成知识库里的信息孤岛。

# 一键找出孤儿文件（没有被索引引用的md） rg -l "" --glob '*.md' | \ xargs -I{} sh -c 'rg -q "{}" _index.md || echo {}'

这条命令不是每天跑，我建议一周跑一次，然后人工决定这些孤儿文件是归档还是合并。

5. 实际运营中的常见问题与排查实录

方案跑起来不算难，难的是让它持续稳定运转。我把这几个月实际遇到的坑按频率排序，做成一张问题速查表，后面再挑几个影响最大的展开细讲。

5.1 检索效果不好，先查术语表，而不是换embedding模型

这是我最想说的一条。很多人一遇到“Agent搜不到”，第一反应是换个更好的embedding模型，或者调低相似度阈值。但在我这里，将近三分之二的“搜不到”，问题根本不在语义层面，而在字面层面。

举个例子：你写的知识文档标题是《容器化应用部署故障排查》，用户问的是“Pod起不来怎么查”，这两者在语义上相关，但在关键词上毫无交集。没有向量检索时，Agent确实很难定位。解决这个问题的正解不是立刻上向量库，而是维护一张_glossary.md术语表，把同义词、上下位词、别名都列出来。

--- id: GLOSSARY-00001 --- # 术语表 - 容器化 / Kubernetes / k8s / Pod：部署相关，统一映射到 `02-infra/01-container` - 知识库 / Agent记忆 / 检索增强：上下文里涉及外挂数据时统一指向 `01-agent/01-concept`

每次Agent要检索时，我要求它先读一遍术语表，把用户问题里的词替换成知识库里的“标准词”，再去执行search_all。就这么一个笨办法，把检索命中率拉高了非常多，而且它不依赖于任何模型的隐性理解，稳定、可控、可解释。

5.2 上下文被撑爆，根子在工具设计，不在模型窗口

上下文窗口再大也架不住Agent一次读五个大文件。我后来给read_file工具加强制约束：返回正文前200行，超出部分返回目录结构和文件统计信息，等Agent决定是否继续深入。

这样做效果立竿见影。Agent不再“一口闷”，而是像人看书一样，先看目录，再挑重点章节精读。你可能觉得这会让多一步交互，多一次工具调用，但换来的是每一次真正的读取内容都切合用户问题，而不是莽撞地把无关段落也塞给大模型。

另外一个细节是，不要把所有检索结果都拼进上下文。检索返回的top 10个文件，真正有用的可能只有两三个。正确姿势是让Agent先看结果列表里的title、path、updated，自行筛选，只精读它判断为高价值的两三个文件。

5.3 多人多Agent并发写同一文件，怎么防丢失

如果知识库只有一个人在用，并发问题不明显。一旦变成团队共享，或者同时有两个Agent在整理内容，情况就完全不同了——两个进程同时读改写一个Markdown文件，后写覆盖先写，丢内容分分钟。

我现在的做法很“土”但很管用：

• 写操作统一进pending/目录，用“新文件”而不是“改旧文件”的方式提交内容；
• 合并动作由人工或专门的整理任务执行，整体串行；
• 正式目录里的文件修改，必须通过Git合并，不直接对工作区文件做覆盖写。

这个流程本质上是用“异步暂存”取代“实时写盘”。虽然多了一步，但对正确性的收益远大于那点操作成本。知识库的核心价值是可靠性，宁可慢一点，不能错一点。

5.4 从普通笔记迁移过来时，最容易被忽视的格式陷阱

迁移老笔记到这套体系，最大的坑不是内容，而是格式。常见的情况有几个。

一是Windows下写出来的Markdown文件，换行符是CRLF，而Linux下的解析器只认LF。检索服务倒无所谓，但Git diff会频繁误报整个文件都被修改。解决办法是git config autocrlf input，让仓库里的文件一律标准化成LF。

二是标题里用了中文全角冒号和半角冒号混合，导致front matter解析出错。比如title: 什么是「Agent原生」：一个实践总结，这个全角冒号没问题，但如果你在某处用了半角冒号再跟空格，YAML会认为开启了嵌套结构。统一约定：front matter里的值，如果包含标点符号，一律加引号包裹。

三是图片路径问题。Markdown里如果写![](C:\Users\xxx\Pictures\1.png)，Agent拿到路径后完全无法处理。规范方案是引入/assets/目录，所有图片按assets/YYYYMMDD-slug.png存放，Markdown里只写相对路径![](/assets/20250618-agent-kb.png)。这样不论是本地编辑器、静态网站、还是Agent工具，都能稳定解析。

6. 我跑了一个多月之后的真实体会

这套“Agent原生知识库”我实际跑了超过两个月，最大的感受是：它把“知识管理”从一个“平台问题”重新变成了“文件管理问题”。出了问题，我第一反应是去看目录、看文件、看Git记录，而不是去翻某个平台的日志。这种“一切都摊在明处”的感觉，对维护者来说太重要了。

如果你正在被各种花哨的Agent知识库方案劝退，不妨回到这套最笨的方案试试。别急着上向量库，别急着搞多模态，先花一周时间把你的笔记整理成规范Markdown文件，给Agent配两个最基础的检索工具。你会发现，结构化的纯文本，在Agent手里远比你想象的更聪明、更好用。

最后再分享一个维护小技巧。每周五我会跑一次“孤儿文件扫描”，把一周内没有被任何索引和related字段引用的Markdown文件挑出来。绝大多数时候，这些孤儿文件是Agent整理过程中产生的重复草稿，直接归档即可。但也有几次，孤儿文件里藏着被遗漏的重要知识点。这个每周十五分钟的整理动作，比任何华丽的知识库管理系统都更能保证库的质量。