从 Skill 私有记忆到共享 Agent 知识

llm-wiki-runtime 如何让 HR 知识被其他授权 Agent 复用，同时避免“共享知识”等同于“共享上下文”。

至于使用者痛点，知识孤岛与重复劳动

在实际工作中。HR 程序往往出现以下问题：

• 同一份简历被不同 Skill 反复解析，导致处理时间浪费。
• 候选人档案仅存放在单个工作流目录里其他 Agent 无法直接访问。
• 当某个 Skill 被替换或升级时之前积累的业务洞察也随之消失。怎么说呢，
• 跨团队共享时需要复制大量上下文信息。增加安全风险，不过，

Skill 可以被替换。知识不应该随之消失

一个 HR Skill 完成简历筛选。它提取事实、解析候选人身份、把档案与岗位比较一下、记录风险，并生成筛选报告。这项工作创造的东西，比当前对话中展示的一次性回答更加持久：它创造了 Domain Knowledge。

问题在于，这些知识经常被困在最初生产它的工作流里。后续的候选人详情 Agent 可能 解析同一份简历；怎么说呢，面试题 Agent 可能依赖文件名、当前对话或生成的人才 Graph。才能判断使用者所说的是哪名候选人；未来接入的新 Agent 甚至可能不知道，一份有来源支撑的候选人档案早已存在。

这会产生两个方向相反的故障：

• 候选人档案明明存在下一个 Agent 却找不到；老实说，
• Agent 只有扫描或加载远超任务需要的私有数据。才能找到它，

仅仅给一个 Skill 增加持久目录，并不能解决更大的问题。知识也许保存下来了却仍然与生产者的方法、假设和检索逻辑紧密耦合。

Knowledge Runtime 更关键的作用并不是“给一个 Skill 增加记忆”。而是让 Domain Knowledge 可以独立寻址：

内容才是资产，Runtime 是围绕这项资产建立的访问与治理层。

知识可以被复用，但不需要对所有 Agent 全局可见。不需要复制到每个 prompt，也不应该脱离原有 Domain 的所有权。

再看第一层价值，为单个 Skill 提供更好的记忆层

在讨论多个 Agent 之前。Runtime 必须调整原始 Skill 自己的知识生命周期。在 HR 案例中，Skill 过去依赖当前对话、原始简历、文件名、目录和派生 Graph 的某种组合。这些输入都有用，但没有一个是稳定的候选人身份。也没有一个提供完整的访问契约。

HR Domain Profile 建立了一条更明确的链路：

diplay_name / aliases → candidate_id → candidate profile → source and resume version

This chain defines which aliases are confirmed,what candidate profile represents,and how to disambiguate when names collide.

The Runtime enforces a narrower set of generic mechanisms around se meanings:

• No new hiring logic is added.
• The focus is on locating。 loading,and persisting domain knowledge.

This is first enhancement: cross‑task continuity and clearer control boundaries for a single Skill.

从更大的价值来看，知识应当比生产它的 Skill 活得更久

A true architectural benefit emerges when anor Agent needs same content.

• Simplified resume filtering;
• Candidate detail reporting;
• Tough interview question generation.

Simplified filtering can create candidate profiles,job postings,JD records,reports。and workflow logs. Or workflows consume existing Domain Knowledge and generate ir own Artifacts.

K1: 所有代理都遵循同一套声明式契约，而不是各自实现自己的检索器或缓存机制。从K2来看，消费方无需理解生产方内部文件布局就可以使用数据。怎么说呢，至于K3，可读取方法与强制排除方法分离，以满足隐私与合规需求。K4这方面，写入权限必须通过声明授权，以防止意外覆盖或泄露敏感信息。至于K5，所有查询都支持精确 //N 检索还有 fallback 行为声明。

如何让其他代理接入？

• Domain Owner 定义知识模型： HR Profile 声明稳定身份、记录类型、检索字段等基本元数据；
• Consumer Agent 声明意图： 其 SCP 明确调用域、目标知识、信任级别和可生成 Artifact 等信息；其实，
• Runtime 解析配置与策略： 缺失/关闭/无效时返回显式状态。而非触发全范围搜索，其实，
• 身份先行，再加载内容： 姓名匹配前端字段。仅返回确定性的 //N 并加入 tag=read_denied;
• 最小化上下文加载： 唯一命中后返回方法和 checksum，而非完整简历；
• 执行自己的业务判断：
• 写入仍需声明：
• 派生视图始终保持衍生状态：Graph 用于发现但不决定身份是否最新。

  使用者痛点

  痛点	如何通过 Runtime 减轻
  多版本冲突	明确版本引用并强制校验
  权限泄漏	精细化 allowlist 与排除列表
  重复解析成本	使用统一 ID 与缓存
  跨域协作难度	声明式契约，无需重写检索器

  什么场景值得引入 Knowledge Runtime？

  1. Skill 产生可持续价值——如候选人档案不会因为一次任务而消失；
  2. 未来工作流会使用这些数据——多次迭代或新代理；
  3. 需要比文件读取更严格的数据治理——隐私、安全。
  若只是一次性转换或无状态工具，则 Runtime 的开销可能不值得。

  ---

  当前证据支持什么

  • llm-wiki-runtime @ 1ebcb04测试全部通过；
  • HR Agent Copilot @ 15f634f 与固定 Runtime checkout 一样通过。

  证据表明的观点是，

  text 声明式契约 + 精准 //N 检索 + 控制字符处理 + fallback 支持

  能够在不同代理之间安全地传递 Domain‑owned Knowledge。

  ---

  小结

  真正长期资产不是具体 prompt 或模型，而是带来源支撑且可寻址且受治理限制的数据资产。Knowledge Runtime 在两个层面产生价值：

  1. 为单一 Skill 提供持久、更受控记忆；
  2. 将有价值内容从实现细节解耦，让授权代理复用。

  ⚡️ Skill 可替换，它们积累的数据不应随之消失。

  ---

  推荐阅读

  • 《Domain Semantics in Skills》
  • llm-wiki-runtime @ 1ebcb04
  • HR Agent Copilot @ 15f634f
  • 合成 HR 候选人检索流程测试

  ---