从文档库到知识能力:让 Agent 有据可依

设想一次用例评审。Agent 已经能自动登录测试平台，为一个多租户的规则管理功能生成了二十多条权限用例，正常输入、异常输入、边界值、角色检查一应俱全。评审卡在其中一条上：“检查不同用户能否查看和修改规则。”它列出了检查项，预期一栏却是空的。跨租户到底该允许还是拒绝？审计角色能不能修改？没有人能凭通用经验回答，Agent 也不能。

答案其实早就写在 Wiki 里的一份《规则权限设计》中：用户只能访问所属租户的规则，审计角色允许读取、不允许修改。文档一直在，只是没有人把它拿给 Agent。能进入系统，解决的是访问问题；有依据地理解业务，才是知识能力要解决的问题。组织往往不缺文档，缺的是让文档进入一次具体任务的能力。

下面围绕一个 Wiki 知识能力集群，讨论它在能力序列中的位置、内部怎样分工，以及一条用例是怎样从“只能猜”变成“每条预期都有来源”的。案例为教学假设，文档名称、页面标识、版本和章节号都是示例；它们说明方法，不对应某个产品的真实规则。

定位：登录之后，先补依据

身份之后，缺的是依据

自动登录给了 Agent 身份和会话，让它能进入业务系统。但能进去不等于知道该怎么判断。一个已经拥有有效会话的 Agent，不必为每次查资料重新登录；它缺的是一条通道，把组织内部的规则、方案和经验送到当前任务面前。

把企业能力放在一条线上看会更清楚：身份、知识、流程、工程资产。自动登录对应身份，Wiki 侧重知识，研发过程管理系统承载需求、缺陷和用例等过程记录，代码仓库承载代码及其版本。这是教学上的侧重，本篇只深入 Wiki。

Wiki 里装的不只是段落

需求解释、技术方案、测试规范、环境说明、复盘经验，都以文档形式保存；文档里又有表格、流程图、架构图和截图。前面那份《规则权限设计》，关键的租户隔离关系很可能画在一张架构图里，而不是写在正文中。把 Wiki 理解为纯文字资产，就会漏掉图里的箭头、表格里的关系和截图里的限制条件。

所以 Wiki 的独立价值在于，让原本需要人翻找、阅读和解释的材料，有机会通过稳定的能力进入任务。资料仍由组织维护，业务判断仍要确认适用范围；变化的是知识能被怎样发现、引用和复用。

架构：三类能力把知识送到任务面前

知识服务层：Search 拿回候选，Read 拿回原文

对使用方而言，先认识三个动作。Search 回答“可能在哪里”：它返回一张候选表，每行有标题、摘要片段、排序和更新时间。Read 回答“这页现在写了什么”：它返回当前页面快照，带页面标识、版本、正文和图片链接。Publish 负责把需要沉淀的内容写回，包括写前检查、更新冲突保护和写后回读核对。集群入口按意图派发：知道要读哪一页就交给 Read，只有主题就交给 Search，要写回才进入 Publish。

候选和快照是两种不同的东西。回到那份权限设计文档，用“租户隔离、规则权限、审计角色”去搜，可能拿回这样三条候选：

排序是算法排序，摘要可能滞后，所以候选只用来缩小范围。真正要采用第一条的内容，就用它的页面标识去 Read，拿回快照头：页面标识 88213、版本 v7、更新于 08-12、适用版本 3.2、状态已评审。引用时带上标识和版本，后续分析才能说清依据来自哪里，而不只留下一段模型生成的摘要。

Publish 不是每次查询的最后一步。只有结果经过验证、确实需要沉淀、并且有写入授权时才写回；请求返回成功，还要回读一遍确认页面里确实是预期内容。把这些责任收进发布能力，业务应用就不必各自处理一套写入规则。

索引支撑层：让文字和图片里的知识都能被找到

文档一多，只靠标题或逐页阅读很难缩小范围。支撑层为此维护页面目录与元数据缓存、正文语义索引、图片语义索引，并提供共享的认证和接口访问。它们在幕后服务于知识访问，业务调用者只面对 Search 和 Read。

两条索引链路并列：

页面正文 → 分块 → 文本向量 → 文字索引页面图片 → 描述或识别文本 → 文本向量 → 图片索引文字索引 + 图片索引 + 关键词召回 + 按条件的服务端搜索 → 融合排序 → Search 出口

图片链路值得单独说：图先变成描述或识别出来的文字，再进入同一种文本索引。这样架构图里的隔离关系也能被搜到，代价是描述可能漏掉箭头、条件和布局。两条链路各自维护，可以并行推进。向量也不是唯一手段，关键词召回补专有名词的精确匹配，按条件的服务端搜索在约定条件下补充候选，多路结果再按页面去重排序。

索引负责让页面被找到。采用依据时回到当前原文，关键图要看原图；已知页面标识的直接读取，也不需要等索引重建。

业务应用层：把页面内容变成任务需要的输入

通用读取解决“取到了什么”，业务应用回答“这些内容在这个场景里怎么用”。环境页面里的表格投影成带来源的脱敏环境候选，周报页面汇总成周期信息和覆盖记录，已经复核的阶段进展组织成适用模板内的报告。这些应用理解自己的业务语义，而不只是转换格式。

同一页知识在不同任务里被投影成不同形态，解释权留在使用方。环境表里写着某个版本，此刻实际部署的是不是它，仍要看环境本身；报告能生成，不代表测试已经执行。三层由此形成清楚的协作：服务层给稳定入口，支撑层承担检索与公共访问的内部复杂性，应用层把知识用于具体问题。它们是职责视角，一次已知页面读取只经过入口和 Read，一个复杂任务也可以多次使用同一项能力。

方法：让知识校准行动，再把经验沉淀回来

一条用例的依据链

回到开头那条填不出预期的用例。它的问题不是检查项不够，而是有两个决定预期的疑问没有依据：跨租户能否查看？审计角色能否修改？依据链从这里开始：测试设计方先把不确定的预期写成这两个具名问题；Search 拿回三条候选；Read 回读排在前面的设计页，拿到页 88213、v7 的快照；测试设计方核对版本、范围和评审状态，确认它适用于本次要测的 3.2 版；最后校准用例。每一步都交出可以指认的产物：两个问题、三条候选、一份快照、一条核对结论、一组用例。

校准后的用例是这样的：

第五行最重要。文档没写到的跨租户修改，不猜，标成待确认交给业务确认或用执行结果回答。知识缺口有了具体位置，比多写十条用例更有价值。两份文档打架时也一样，核对适用版本、范围和评审状态，不凭相似度或更新时间选一份；仍定不下来的，保留为待确认。

真正完成纠偏的不是 Search 单独给出一个答案，而是这条有产物的依据链。用例数量没有增加，变化的是每条预期都能说出采用了哪份文档、哪一节、哪个页面、哪个版本。

知识建立预期，运行验证预期

候选、快照、运行证据回答的是三个不同的问题。候选说明某页可能相关；快照说明某页在读取时写了什么；运行证据说明系统在指定条件下实际发生了什么。它们都有价值，支撑的结论不同。相似度排名解释不了正确率，页面回读成功也解释不了产品是否通过。

知识可以成为证据。保留页面标识、版本和原文，正是为了让它作为证据发挥作用：对测试设计，它决定预期应该是什么；对系统行为，还要有对应条件下的执行结果。原则是按问题选择证据：文档写的是预期，系统跑出来的才是结果。遇到知识缺口也不必让全部工作停下，依据充分的部分继续推进，缺口标明位置。

把共同机制固化，把业务责任留在原处

从这个集群可以提炼一种能力设计方法：把可复用动作固化在清楚的责任单元里，把具体业务解释留给使用者。Search 不负责测试通过与否，Read 不负责决定部署状态，Publish 不负责生成未经验证的业务结论；业务应用复用这些动作，不复制底层认证和接口实现。

这样做的意义在于每项能力的输入、输出和边界能被理解、验证和维护。索引实现可以演进，使用方仍围绕候选和当前快照工作；不同应用共享读取和发布能力，不需要一起改造。先建立能独立交出可核对结果的能力单元，再讨论编排，组合才有稳定基础。

验证过的经验，才写回 Wiki

知识闭环不能停在生成答案。上面那组用例执行之后，核对过、也跑过的规则可以整理成一段带适用条件和来源的说明，在写入授权下交给 Publish 保存，再回读确认。没验证的猜测一旦写回，下一次搜索会把它当成依据，所以先验证，再沉淀。

写回、索引更新、再次被发现是三个先后发生的事：页面写回后，索引维护更新派生缓存，后续任务才能再次搜到它。衡量价值从任务出发：适用资料是否更容易定位，每条预期能否解释来源，关键缺口是否被记录，验证过的经验能否被下一次任务复用。这些是值得观察的方向，具体改善幅度要用同范围任务实测，不从文档数量或向量条数推导。

从一条用例开始

测试人员可以从三步开始：把不确定的预期写成具名问题；让 Agent 先搜后读，引用带页面标识和版本；文档没写的标待确认。写成一条指令就是：为「规则管理」补充权限用例，预期不确定的先查 Wiki，Search 相关设计页，Read 原文后再写预期，每条预期注明页面标识与版本，文档没写的标「待确认」，不要猜。

由此带走一套方法：以问题发现知识，以证据校准预期，以稳定能力支持复用，以验证过的经验完成沉淀。它不要求一次建成完整平台，也不要求每个任务走完所有环节。让 Agent 有据可依，不是让它记住更多文档，而是让组织知识能够被找到、被核对、被用于业务，并在验证后继续积累。