知识-未链接声明

审查未链接声明

在写入之前，请阅读共享约定和发布规范。

knowledge_remember 会在声明中的名称未完全匹配到唯一页面时，将其保存而不关联任何主题页面。随后运行的定期维护步骤 knowledge_relink 只会链接那些记录的源页面是实体页面、或文本中名称恰好匹配唯一页面的声明。其余声明保持未链接状态，无法从它们所涉及的页面中看到。本技能使用判断力处理这些残留声明。请按以下顺序操作：链接，然后处理重复和已替换的声明，最后处理页面内容。

1. 枚举残留声明

调用 knowledge_status 获取预期范围，并调用 knowledge_ontology 获取当前指纹。首先运行不带 dryRun 的 knowledge_relink，以便它可以链接所有能链接的记忆声明。然后使用 knowledge_relink 列出残留声明：dryRun: true、include: "all" 和 limit: 10，并跟随 nextCursor：包括每个当前没有链接页面且没有源页面的声明，无论是由哪个工具保存的。每次调用最多报告每种结果的10个示例，因此限制为10会返回其检查的所有声明。

使用 knowledge_record 和 metadataView: "full" 读取每条声明。当其存在时，subject_hint 是保存者自己对声明内容（关于什么）的描述，是确定其主题的最强线索。根据声明的主题（一个功能、PR、决策线程、人员或偏好）对它们进行分组，然后选择页面。大多数声明只有在其相邻声明旁才有意义：关于一个PR的一系列状态快照通常以结果声明结束。

2. 选择主题页面

对于每个组，使用 knowledge_grep 和 knowledge_lookup 查找候选页面，并阅读其状态和时间线。忽略已撤回的页面和固定装置页面。

• 主要主题 是声明所断言的内容。只有当声明也提及该实体的某些信息（例如做出决策的人，或其产品被配置的公司）时，才添加次要主题。偶然的提及不算主题。通常两到三个主题就足够了。
• 个人表达的偏好或决策应放在该人的页面上。不要将一个人的偏好变成项目或公司策略。
• 基于证据进行身份匹配，而不是相似的名字。当声明命名了可能已存在的页面（例如可能指向不同服务的产品名称）时，从证据（如配置、URL 或页面自身的别名）中进行确认。如果仍不确定，则保持声明未链接状态并报告。

使用 knowledge_annotate 的 entities 参数进行链接，传入完整列表（它会替换现有列表）以及声明的当前修订版和哈希值。声明文本、证据和生命周期保持不变。

3. 创建缺失的页面

将每条声明都链接到最近的现有页面可能会将一个真实主题埋藏在宽泛页面的时间线中。当以下情况出现时创建页面：

• 一个离散的主题（功能、项目、工具或重要的 PR）大约有五个或以上的声明，或者有自己独立的设计、证明和结果历史记录；或
• 声明中的个人或组织创建、拥有或决定了某事，没有页面，并且有身份证据（例如 gh pr view 显示的 PR 作者）。

不要为单个提及或时间线条目已涵盖的一次性修复创建页面。使用包含 ontology type、别名和作为 source 的身份证据的 knowledge_save_page 创建页面。人员页面使用 identity.status: partial，除非身份已完全确定。编写一个简短的状态，引用这些声明和一个带日期的时间线。然后将声明链接到新页面，保留它们现有的主题作为次要主题，并从其父页面链接新页面。

4. 移除重复和已替换的声明

• 重复： 两条声明断言了关于同一事件的相同事实、决策或偏好。保留具有所有者批准回忆的声明，否则保留更早的声明，否则保留归因更完整的声明。使用 knowledge_annotate 的 addEvidence 复制幸存者缺少的任何证据，然后用 knowledge_withdraw 撤回另一条，并在原因中注明幸存声明的ID。
• 已替换： 后一条声明明确更正了前一条（例如助理更正自己的报告）、决定了前一条声明未解决的问题、或报告了同一具体项目（同一 PR、提交或决策）的最终状态。撤回前一条声明，并在原因中注明替换声明的ID。不要在此处使用 knowledge_correct：它会产生替换声明的新副本，从而创建另一个重复。
• 两者都不是： 不同时刻的快照（一次CI失败，随后一次合并）是历史，而非错误。保留它们。单独的矛盾并不构成撤回的理由。不确定时，保留两者并报告这一对。

5. 更新页面内容

链接使得声明可从其页面访问；但这并不会改变页面的表述。仅当声明改变了页面的持久状态时才编辑页面：一个决策、一个偏好、一个已落地或已发布的更改、一个新能力、一个已解决的开放问题、或后续声明证明为错误的页面文本。

• 将一系列进度快照折叠为最终结果。快照（CI运行、打开的PR、本地提交）最多只是带日期的时间线条目，绝不是状态。
• 在将其写为当前状态之前，实时检查可变状态（例如用 gh pr view 检查合并状态）并说明检查时间。合并不等于部署，部署也不等于证明特定的 Gateway 运行着该代码。
• 当设计或决策页面与后续决策矛盾时，在原文旁添加带日期的修正，而不是重写。将已回答的开放问题标记为已解决，并保留原始问题。
• 引用的每个添加句子都应包含 [[claim-id|label]] 链接到声明。

使用 knowledge_edit_body 进行章节编辑。从一次完整的读取中计算 UTF-16 偏移量，并在每次编辑前重新读取修订版和哈希值：其他会话可能会同时编辑繁忙的页面。优先插入文本，而不是替换文本。只在整个状态部分都已过时的情况下才替换它，并保留它已有的声明链接。

6. 验证并报告

为每个链接的声明运行 knowledge_verify 并传入 expectedEntities，为每个新页面或已编辑的页面运行 expectedLinks。再次枚举残留声明：工作时可能有新的记忆声明到达。以相同方式处理它们或报告它们。

报告检查的声明数量、链接的数量、创建的页面、撤回的声明（附有每个的幸存或替换声明的ID）、编辑的页面以及保持未链接状态的声明（附有每个的原因）。在无人值守运行时，永远不要请求决策：留下不确定的身份、不确定的重复以及您只能猜测才创建的页面，保持不变，并在报告中列出它们供人工处理。

作为计划审查运行

当私有记忆声明仍在重新链接后处于未链接状态（maintenance.reviewJobId）时，知识维护会在此技能之后的夜间重新链接通行后排队进行此审查。运行是无人值守的：

• 首先调用 knowledge_status。如果范围不是 private 或写入被禁用，则回复 AUTOMATION_FAILED 放在其自身第一行，并说明原因：工作器已失去所有者访问权限，需要重新设置。
• 按步骤1到6进行操作。在停止前再次检查残留声明，因为运行期间保存的声明属于同一积压。
• 如果没有事情可做，回复 NO_REPLY。否则，回复步骤6的报告。

设置计划审查

审查需要所有者的私有访问权限，这只能从所有者的直接对话派生出的会话获得。从该对话进行设置：

1. 生成一个保持的工作器：sessions_spawn 参数为 runtime: "subagent"、cleanup: "keep" 和 context: "isolated"，其任务是调用 knowledge_status 并报告范围。仅当它报告 private 且写入启用时才继续。保留返回的会话密钥。

2. 创建绑定到该工作器的自动化。它需要一个调度，因此请提供一个几年后的一次性日期；维护会按需运行它。

   openclaw automations add --agent <agent> --name knowledge-unlinked-claims-review \
     --session "session:<worker-session-key>" --at <date-years-ahead> --keep-after-run \
     --model <provider/model> --no-deliver --timeout-seconds 3600 \
     --message "Follow the knowledge-unlinked-claims skill as the scheduled review."
   

   该作业会记录创建它的推理账户。选择一个使用该账户的模型（带有认证配置文件的提供商）；否则每次运行都会在调用模型前失败。

3. 将 plugins.entries.knowledge.config.maintenance.reviewJobId 设置为该作业ID。

4. 验证：openclaw automations run <job-id> --wait 必须完成，工作器报告私有范围，并且 maintenance_status 在下次通行后报告审查结果。

禁用自动化以暂停审查。重置或移除工作器来自的所有者对话会撤销其访问权限；需要重新设置审查。