从 Skill 私有记忆到共享 Agent Knowledge
llm-wiki-runtime 如何让 HR 知识被其他授权 Agent 复用，同时避免"共享知识"等同于"共享上下文"。
Skill 可以被替换，知识不应该随之消失
一个 HR Skill 完成简历筛选。它提取事实、解析候选人身份、把档案与岗位进行比较、记录风险，并生成筛选报告。
这项工作创造的东西，比当前对话中展示的一次性回答更加持久：它创造了 Domain Knowledge。
问题在于，这些知识经常被困在最初生产它的工作流里。后续的候选人详情 Agent 可能再次解析同一份简历；面试题 Agent 可能依赖文件名、当前对话或生成的人才 Graph，才能判断用户所说的是哪名候选人；未来接入的新 Agent 甚至可能不知道，一份有来源支撑的候选人档案早已存在。
这会产生两个方向相反的故障：
- 候选人档案明明存在，下一个 Agent 却找不到；
- Agent 只有扫描或加载远超任务需要的私有数据，才能找到它。
仅仅给一个 Skill 增加持久目录，并不能解决更大的问题。知识也许保存下来了，却仍然与生产者的路径、假设和检索逻辑紧密耦合。
因此，Knowledge Runtime 更重要的作用并不是"给一个 Skill 增加记忆"，而是让 Domain Knowledge 可以独立寻址：
Runtime 不负责创造知识的价值。它让有价值的知识脱离最初生产它的 Skill，成为其他授权 Agent 可以复用的资产。
内容才是资产，Runtime 是围绕这项资产建立的访问与治理层。
这也带来一条必须坚持的边界：
共享知识不等于共享上下文。
知识可以被复用，但不需要对所有 Agent 全局可见，不需要复制到每个 prompt，也不应该脱离原有 Domain 的所有权。
第一层价值：为单个 Skill 提供更好的记忆层
在讨论多个 Agent 之前，Runtime 首先必须改善原始 Skill 自己的知识生命周期。
在 HR 案例中，Skill 过去依赖当前对话、原始简历、文件名、目录和派生 Graph 的某种组合。这些输入都有用，但没有一个是稳定的候选人身份，也没有一个提供完整的访问契约。
HR Domain Profile 建立了一条更明确的链路：
display_name / aliases → candidate_id → candidate profile → source and resume version
这条链路的含义属于 HR Skill。它决定哪些别名已经确认、候选人档案代表什么、哪些信息值得保留，以及遇到同名候选人时应如何消歧。
Runtime 负责围绕这些含义执行更窄的通用机制：
| 没有 Runtime 契约 | 接入 Runtime 契约之后 |
|---|---|
| 从对话、文件名、目录或 Graph 输出中猜测身份 | 把声明的姓名和别名解析为稳定的 candidate_id |
| 广泛搜索或再次解析简历 | 返回显式的 found、multiple_matches 或 not_found |
| 加载范围不确定的一组 HR 文件 | 通过受限上下文包，只加载选中的候选人路径 |
| 使用各工作流自己的 Markdown 写入约定 | 校验已声明的路径和引用，执行原子写入，返回 checksum，并记录受控变更 |
| 把知识层故障隐含地变成整个工作流故障 | 返回明确状态，并保留原有 Markdown 工作流作为 fallback |
这不会让 Skill 更懂招聘。它不会判断候选人是否优秀，也不会决定哪一道面试题更有价值。它增强的是 Skill 对 Domain 已有知识的定位、加载和保存能力。
这是第一层增强：为单个 Skill 提供跨任务连续性和更明确的控制边界。
更大的价值：知识应当比生产它的 Skill 活得更久
当另一个 Agent 需要使用相同内容时，更大的架构价值才真正出现。
当前公开 HR 包中有三个接入 Runtime 的工作流：
- 简历筛选；
- 候选人详情报告；
- 面试题生成。
简历筛选可以产生候选人、岗位和 JD 记录，以及报告和工作流日志。其他工作流可以消费已有的 Domain Knowledge，并生成自己声明的 Artifact。
它们不应该各自实现不同的候选人检索器、简历缓存、来源注册表、隐私过滤器和写入约定。消费方 Agent 也不应该必须理解生产方 Skill 的内部文件布局。
相反，Domain 应当发布一份稳定的知识契约：
- 记录类型和稳定身份；
- 声明式检索字段；
- 受限返回字段；
- 可读取路径与强制排除路径；
- 来源引用与版本引用；
- 允许写入的目标；
- fallback 行为。
只要获得授权，消费方 Agent 即使不是最初创建内容的 Agent，也可以接入这份契约。生产者可以演进，模型可以更换，某个子 Skill 也可以被替代；有价值的候选人知识仍然属于 HR Domain，而不是属于某个具体实现。
从这个意义上说，llm-wiki-runtime 把 Skill 私有的工作结果，转化成了可以复用的 Agent Knowledge。
但这句话仍然需要成熟度边界。三个 HR 工作流都已经完成契约接入，但目前大部分实际使用证据来自简历筛选。候选人详情报告和面试题生成仍是早期集成。它们说明生产者与消费者契约可以对接，但还不能提供三个成熟的实际案例；而且它们仍然属于同一个 HR Domain，并不是三个 Domain 验证样本。
图 1：Runtime 是共享访问边界，HR Domain 仍然是知识所有者。
其他 Agent 如何接入
"容易接入"不应该等于"直接读取目录"。
新的消费方 Agent 应当通过与原始 Skill 相同的声明式边界接入：
-
Domain owner 定义知识模型。 HR Profile 声明稳定身份、记录类型、检索字段、返回字段、读取排除项、写入路径和必需来源引用。
-
Agent 声明自己的意图。 它的 SCP 标明调用方 Domain、需要访问的目标知识、信任级别、所需记录、允许生成的 Artifact，以及 fallback 行为。
-
Runtime 解析配置与策略。 知识层缺失、关闭、无效或拒绝访问时，系统会得到显式状态，而不是静默触发更大范围的搜索。
-
Agent 先解析身份，再加载内容。 候选人姓名或已确认别名只与声明的 frontmatter 字段匹配。结果采用确定性的 0/1/N，并在返回元数据之前增加授权失败状态
read_denied。 -
Agent 只加载最小的选中上下文。 唯一命中后，返回路径和 checksum 成为精确的上下文引用。原始简历与内部元数据仍然位于普通上下文包之外。
-
Agent 执行自己的 Domain 工作。 候选人详情 Skill 负责解释档案，面试 Skill 负责设计问题。Runtime 不承担这两种业务判断。
-
写入仍然必须经过声明。 如果消费方有权持久化结果，它就使用声明的记录、Artifact 或日志契约；没有写入权限时，访问保持只读。
-
派生视图始终只是派生视图。 Graph 可以用于发现和浏览，但候选人身份不能依赖 Graph 是否存在或是否最新。
关键在于：消费方 Agent 得到的是一套知识访问协议，而不是生产方 Skill 的副本。
如果辅助内容跨越 Domain 边界，它还可以被标记为数据，而不是指令。这个区别对于 Agent 系统非常重要：可复用知识应当为消费方提供信息，却不能静默变成可执行策略。
图 2：其他 Agent 接入的是知识契约，而不是生产方 Skill 的目录布局。
共享知识不等于共享上下文
让内容更容易复用，会提升它的价值，但也会放大权限配置错误的代价。
在 HR Profile 中，候选人检索只返回一个很小的 allowlist，而不是任意元数据。原始简历和内部 .meta 状态被排除在普通上下文包之外。没有显式策略允许时，跨 Domain 读取默认拒绝。同名结果会进入消歧状态，而不是被系统自动选择。
这些约束让知识可以在存储层和协议层共享，而不需要在 prompt 层广播。
它们也带来真实代价：
- 稳定身份、别名、记录 Schema 和来源引用需要持续维护；
- 精确匹配可能遗漏尚未登记的拼写或姓名变体；
- 消费方越多，对来源、时效性、冲突处理和生命周期所有权的要求越高；
- 设计不当的策略可能扩大私有数据的影响范围；
- Runtime 配置、Profile 版本和健康检查会增加运维工作；
- Runtime 可以执行字段 allowlist，却不能判断这个列表在伦理或法律上是否合适。
因此，内容复用依赖内容质量。一条来源薄弱、事实过期或身份含糊的持久记录，只会变成可以被反复复用的混乱。
这正是 Domain 必须继续拥有内容的原因。Runtime 让访问变得可重复，但不会把 Domain 语义压平为全局 Schema，也不会宣布每条已存事实都值得信任。
图 3：共享存储与协议访问，并不要求全局共享 prompt 上下文。
何时值得引入 Knowledge Runtime
当下面三个条件同时存在时，Knowledge Runtime 最有价值：
- Skill 产生的知识在当前任务之外仍然有价值；
- 未来运行、其他工作流或其他授权 Agent 还会需要这些知识；
- 身份、隐私、来源和写入需要比直接读取文件更强的控制。
对于一次性转换、无状态工具，或者输出没有长期复用价值的工作流，接入 Runtime 的成本可能并不值得。
在 HR 案例中，候选人档案、来源关系、简历版本、筛选报告和面试 Artifact 都具有跨任务生命周期。如果每个 Agent 都重新解析来源、重新建立身份，不仅会重复工作，也会重复引入风险。
Runtime 集中了应该共享的通用机制，同时把招聘判断留给真正理解招聘语义的 Skill。
一个很小的故障可以说明这种区别。部分简历提取文本包含非法控制字符。HR 提取层负责确定性清理来源，Runtime 则拒绝不安全写入，并确保现有目标不被修改。公开测试覆盖了边界两侧。这不是一个吸引眼球的功能，却是让内容足够持久、能够被后续 Agent 信任和复用的一部分。
当前证据支持什么
为支持这篇文章背后的完整证据母稿，我在不可变修订上重新运行了公开测试：
- llm-wiki-runtime @
1ebcb04：325 项测试通过。 - HR Agent Copilot @
15f634f，并配合固定的 Runtime checkout：10 项测试通过。
公开测试覆盖契约声明、基于合成数据的精确 0/1/N 检索、联系方式字段排除、无 Graph 依赖的受限上下文加载、控制字符处理和 fallback 声明。
在一个私有本地 HR scope 中，共检查 72 份候选人档案。其中 3 份包含非法控制字符，共清理 73 个字符，清理后剩余 0 个。移走 Graph 后，精确检索仍然唯一命中一份候选人档案。这些是匿名化的实际运行观察，不是公开基准。
这些证据不能证明生产可靠性、延迟降低、token 使用减少、招聘质量改善、合规增强或业务收益。它也不能证明多 Agent 已被广泛采用：一个 HR 工作流具有较充分的实际使用，另外两个消费工作流仍处于早期阶段。
当前证据能支持的结论更加克制：
一个 Skill 可以通过声明式 Runtime 边界生产 Domain-owned Knowledge；其他获得授权的 Agent 也可以接入同一套身份、策略、上下文和持久化契约，而不需要继承生产方 Skill 的存储逻辑。
这就是从 Skill 私有记忆走向共享 Agent Knowledge 的关键一步。
结论
在 Agent 系统中，真正的长期资产不是某个具体 prompt、模型或 Skill 实现，而是未来工作仍然能够找到并信任的、带来源支撑的 Domain Knowledge。
llm-wiki-runtime 在两个层面创造价值。它为单个 Skill 提供更持久、更受控的记忆；更重要的是，它把有价值的内容与生产它的工作流分离，让其他授权 Agent 可以复用这些内容。
Runtime 本身不是知识。它不创造招聘洞察，不定义候选人身份语义，也不会让已经保存的事实自动变得正确。
它的职责，是在周围的 Agent 不断变化时，让有价值的知识仍然可寻址、受限、受策略治理，并且可以持续维护。
Skill 可以被替换，它们积累的知识不应该随之消失。