harness-ai-kit：Agent 资产包管理器
harness-ai-kit：Agent 资产包管理器
深度判断
值得深挖，因为它把 skills、CLIs、MCPs、loops 从“复制文件/收藏链接”推进到“带 manifest、lockfile、校验和、runtime target 的 agent asset supply chain”。这正击中 External-Agent-Skills-Design-Patterns 里长期存在的问题：skill 生态越丰富，安装、版本、冲突、离线复现和团队一致性越重要。
机制 / 一阶原理
harness-ai-kit 的核心不是某个单一 skill，而是一个组合层：通过 harness-ai-kit.yml 声明项目使用哪些 agent 资产，通过 lockfile 记录 SHA-256 和版本，通过 sync/add/validate 把资产安装到 Codex、Claude Code、Cursor、Kiro 等运行时。README 明确把它定位为“compose more, build less”：复用外部能力，但用 manifest 管住来源和版本。
这相当于把 npm/pip 的包管理思想迁移到 agent context/tool/skill 层。对长期 agent workflow 来说，缺少这层会导致“同一个 repo 在不同机器/不同 agent 上读到不同技能”，进而让调试和复盘失真。
和既有 wiki 的关系
- 与 External-Agent-Skills-Design-Patterns 形成 supply-chain 维度互补：不仅要会写 skill，也要会治理 skill。
- 与 Harness-Engineering 的 code-owned contracts 呼应：规则和能力清单应由版本化 manifest 拥有，而不是散落在口头约定中。
- 与 Context-Engineering 的 capability retrieval 呼应：未来不仅检索文档，也检索可用能力。
对 Hermes / llm-wiki 的可执行启发
- llm-wiki 可增加“外部 skill 候选表”：来源、用途、风险、版本、验证状态、是否建议安装。
- 对高风险 skill 不应直接安装；先 raw 归档、source 页面分析、再用小样例验证触发/不过触发。
- 如果未来 Hermes 支持跨运行时 skill 同步，应优先采用 manifest + lock + checksum，而不是隐式复制目录。
失败模式 / 边界
包管理器会降低安装门槛，也会放大供应链风险。低 star/新仓库/带脚本安装/请求高权限的资产必须进入 HOLD；lockfile 只能证明“安装的是同一份代码”，不能证明代码安全或方法有效。
写入记录
- 2026-08-17 09:00 CST：从 GitHub README 深度入库，记录机制、与既有 wiki 概念的关系、Hermes/llm-wiki 可执行启发和失败模式。