Distilly：把个人经验沉淀为可版本化的 Agent 人物档案
一个把个人材料变成可审核、可回滚 Agent 人物档案的本地工具，不依赖额外模型 Key。
GitHub titanwings/distilly 更新 2026-09-10 分支 distilly-plugin 星标 24.5K 分叉 2.1K
TypeScript Agent Skill MCP Codex OpenClaw Hermes 本地优先

🧭 决策指南

为什么现在热： 无法从材料判断

适合，如果你

  • 你使用 Codex，并能接受 0.1.0-preview.1 Developer Preview。
    README“Install the Developer Preview”与“The first usable flow”说明 Codex Native Plugin 流程已验证。
  • 你运行 OpenClaw 2026.3.24 或 Hermes v0.9.0，并需要 briefing transport 路径。
    README“Host compatibility”记录 OpenClaw 65,536 字节和 Hermes 49,752 字节的 transport-capacity fixture。
  • 你要处理 TXT、Markdown、JSON、SRT/VTT、粘贴文本或公开 URL。
    README“Local material formats”列出首个 Preview 接受的文件格式与来源。
  • 你需要五个 MCP 工具和本地 Panel 中的 promote、reject、rollback。
    README“The first usable flow”明确列出五个工具及候选档案审核流程。

不适合，如果你

  • 你需要正式 tagged release 或 npm package，而不是 0.1.0-preview.1 分支预览。
    README 明确写明当前是 unreleased 0.1.0-preview.1，且不是 tagged release 或 npm package。
  • 你使用 Claude Code、DeepSeek Harness、Pi agent、Grok Build 或 OpenCode，并要求已验证的 Plugin。
    README“Host status”将这些主机列为 exact fixture needed 或 community binding planned。
  • 你需要 PDF、邮件、provider exports 或 hosted connectors 导入。
    README“Local material formats”明确将这些格式列为 follow-up work。
  • 你要求 OpenClaw 或 Hermes 已完成 packaged restart、长期 Skill 与 uninstall 生命周期验证。
    README“The first usable flow”明确说明这些检查仍是 separate，Host status 标为 lifecycle pending。

前置条件

  • 从 distilly-plugin 分支安装 Developer Preview。
  • 使用 Node 22.19+ 或 Node 24 构建。
  • Codex、OpenClaw 2026.3.24、Hermes v0.9.0 仅在记录的主机版本与 release tuple 匹配时启用 setup。
  • 输入材料必须是用户明确提供的 TXT、Markdown、JSON、SRT/VTT 文件、粘贴文本或公开 URL。
  • Legacy Skill 模式需要从 dot-skill 分支安装，并保持最终目录名为 distilly。
  • 不要让 Legacy collectors 与 Plugin 共用同一 ~/.distilly/ 命名空间。

第一步命令（README 原文）

openclaw plugins inspect distilly --json

要注意

  • 同一主机发现范围内只能保留一个 distilly，否则可能加载错误副本。
    README Legacy fallback 要求 keep exactly one distilly active，并核验主机加载的副本。
  • Symlinked selected files 和重复文件名会被拒绝。
    README“Local material formats”明确列出这两类拒绝规则。
  • 超过已验证容量时不会静默截断，而会报告 capacity error 并保持数据不变。
    README“The first usable flow”对 complete briefing 和 profile prompt 的行为有明确说明。
  • OpenClaw 与 Hermes 的容量是 transport/value lower bounds，不代表所有模型会有同样上下文余量。
    README“Host compatibility”明确限定 65,536 与 49,752 字节测量的适用范围。

替代方案

  • dot-skill Legacy Skill compatibility mode：主机尚无已验证 Plugin binding，且只需要本地文件与粘贴文本兼容能力时更合适。
    Host compatibility and explicit Legacy fallback
  • 手动 saved/private Skill：使用 Grok Bot 时更合适，因为 README 未声明其 local repository import 支持。
    Host status

材料未说明

  • README 未提供 For a human 章节内容，因此无法判断面向非开发者的人类使用流程。
  • 材料未说明实际运行所需的操作系统、CPU、内存或磁盘要求。
  • 材料未说明完整构建命令、依赖安装命令或 distilly setup --host codex 的具体 shell 语法。
  • 材料未说明 Person Profile 的具体数据结构、SQLite 是否已在 Developer Preview 中可用。
  • 材料未说明公共 URL 支持哪些网站、认证方式或抓取限制。
  • 材料未说明 4 位贡献者对应的维护分工与响应时间。
  • 材料未说明 1 个版本和 10 个最近提交分别对应的发布时间与发布节奏。
  • 材料未说明为什么项目在 2026-09-10 的 GitHub Trending monthly 榜单上受到关注。

💡 深度解析

6
不适合 我的人物画像流水线主要输入 PDF、邮件和供应商平台导出，还希望接入 hosted connectors 批量收集材料；Distilly 当前 Preview 能否直接作为这条导入链路？
适合读者： 需要处理 PDF、邮件和供应商导出，并希望通过托管连接器批量建立人物画像的数字人或知识蒸馏开发者

不适合直接作为这条导入链路，因为当前 Preview 的输入边界明确排除了这些来源。

  • README 的 “Local material formats” 只列出用户明确提供的 TXT、Markdown、JSON、SRT/VTT、本地粘贴文本和公开 URL。
  • 同一章节明确写明 PDF、email、provider exports 和 hosted connectors 属于 follow-up work，不是当前可用能力。
  • 项目的导入安全边界要求文件来自用户明确提供的路径或来源，并拒绝符号链接选中文件和重复文件名；这并不等于支持第三方平台的批量同步。
  • 现有流程更适合将已经筛选好的材料导入，再生成 evidence-bound briefing 和版本化 Person Profile，而不是承担外部系统采集、凭证管理或连接器编排。

因此，若输入能先转换为 README 支持的格式，可以继续使用其人物解析和审核流程；若必须原生读取 PDF、邮件或托管导出，当前项目不满足约束。

  • README「Local material formats」：The first Preview accepts explicit local TXT, Markdown, JSON, and SRT/VTT files
  • README「Local material formats」：It also accepts pasted text and public URLs
  • README「Local material formats」：PDF, email, provider exports, and hosted connectors are follow-up work
  • README「Local material formats」：symlinked selected files and duplicate file names are rejected
材料未说明：README 未说明外部转换为 TXT、Markdown、JSON 或 SRT/VTT 后的字段保真度要求；README 未说明未来 PDF、邮件和 hosted connector 功能的接口形式或时间表
不适合 我必须在 Claude Code、DeepSeek Harness、Pi agent 或 OpenCode 上使用人物 Skill，但这些宿主还没有完整的 Native Plugin fixture；我能否用 Legacy Skill 作为等价替代，并继续声称拥有 SQLite、五工具 MCP 和 Plugin 生命周期支持？
适合读者： 需要在 Claude Code、DeepSeek Harness、Pi agent 或 OpenCode 上部署人物 Skill、但不能接受未经验证的 Plugin 集成的高级用户

不适合把 Legacy Skill 当作等价替代；它只能提供明确范围内的文件式兼容，不能代表 SQLite、五工具 MCP 或 Plugin 生命周期支持。

  • README 的 Host status 将 Claude Code、DeepSeek Harness、Pi agent 和 OpenCode 的当前路径列为显式 dot-skill Legacy Skill，而不是 Native Plugin。
  • Legacy 模式是独立的 file-based implementation，不共享 Plugin 的受支持数据模型；README 明确要求不要声称 SQLite、five-tool MCP、Panel 或 Plugin lifecycle support。
  • 手动安装只覆盖 local files 和 pasted text；PDF、邮件、provider exports 和 hosted connectors 不在当前兼容承诺中。
  • 如果同一 ~/.distilly/ 命名空间仍启用旧版 collectors，可能写入 credential configuration 并越过 Preview 的安全边界；项目还要求每个宿主发现范围只保留一个 distilly。

因此，Legacy 适合临时保持 Skill 可发现性，不适合替代已验证 Plugin，也不适合据此扩大功能声明。

  • README「Host status」：Claude Code、DeepSeek Harness、Pi agent、OpenCode 使用 Explicit dot-skill Legacy Skill
  • README「Host compatibility and explicit Legacy fallback」：Do not run Plugin setup or claim SQLite, five-tool MCP, Panel, or Plugin lifecycle support
  • README「Host compatibility and explicit Legacy fallback」：This is an explicit, separate file-based implementation
  • README「Local material formats」：PDF, email, provider exports, and hosted connectors are follow-up work
git clone --single-branch --branch dot-skill --depth 1 \
  https://github.com/titanwings/distilly.git \
  <target-directory>
git -C <target-directory> rev-parse HEAD
材料未说明：README 未说明这些 Legacy 宿主的具体 Skill 行为差异和各自的发现刷新机制；README 未提供 Claude Code、DSH、Pi agent 或 OpenCode 的 Native Plugin 完成时间表
适合 我正在使用 Codex，手头有 TXT、Markdown、JSON 和 SRT/VTT 资料，希望让 Agent 学习一位专家的工作习惯和表达方式，并在长期安装前审核版本；Distilly 是否适合？
适合读者： 使用 Codex、希望把专家资料沉淀为可审核和可回滚 Person Profile 的个人用户或小型团队

适合，因为 Codex 是当前完成度最高、完整流程已验证的宿主。

  • README 的 “The first usable flow” 明确说明 Codex 支持从材料导入、人物解析、证据绑定 briefing，到版本化 Person Profile、纠错、审核、回滚和 Skill 安装的完整流程。
  • 系统支持明确提供的 TXT、Markdown、JSON、SRT/VTT、本地粘贴文本和公开 URL；不会读取用户未指定的路径，也会拒绝符号链接和重复文件名。
  • 模型侧固定暴露五个 MCP 工具：distilly_get、distilly_ingest、distilly_pending、distilly_commit、distilly_correct。画像过长时会返回容量错误，而不是静默截断。

需要注意的是，README 没有给出 Codex 端到端安装命令，且当前最新正式 release 只有 v0.01；因此这里的“适合”主要针对 Developer Preview 和受控使用，不等于稳定生产承诺。

  • README「The first usable flow」：On Codex, the complete flow below is verified
  • README「Local material formats」：accepts explicit local TXT, Markdown, JSON, and SRT/VTT files
  • README「The first usable flow」：The model-facing surface remains exactly five MCP tools
  • 项目数据：最新 release 为 v0.01，release_count 为 1
材料未说明：README 未提供 Codex Developer Preview 的完整安装命令和具体依赖配置；README 未说明单个人物画像的推荐资料规模、审核界面细节和升级兼容策略
视情况 我固定使用 OpenClaw 2026.3.24，希望通过 Claude-compatible bundle 接入 Distilly，并需要知道 65,536 字节预算是否足以支持长期 Skill、重启和卸载流程；现在是否适合接入？
适合读者： 维护 OpenClaw 2026.3.24 集成、需要传输较长 briefing 并验证 MCP 发现的集成开发者

视情况：适合验证 briefing 传输和五工具发现，但不适合把 OpenClaw 视为已经完成长期生命周期验证的生产集成。

  • README 的 Host status 记录了 OpenClaw 2026.3.24 的 65,536 字节净传输预算，并说明该版本已有 transport-capacity fixture。
  • OpenClaw 通过 ~/.openclaw/extensions/distilly 加载 Claude-compatible bundle，可用 openclaw plugins inspect distilly --json 检查发现结果。
  • 但 “The first usable flow” 明确指出，OpenClaw 的 packaged restart、long-lived Skill 和 uninstall lifecycle checks 仍未完成。
  • 未记录的宿主版本、release digest、工具描述或 serializer tuple 会在写入前返回 host_unsupported，项目不会自动切换到 Legacy 实现。

因此，如果目标是确认资料导入和 briefing 传输，可以接入；如果目标是依赖长期 Skill、升级和卸载行为，则当前证据不足。

  • README「Host compatibility and explicit Legacy fallback」：65,536 serialized bytes for OpenClaw
  • README「Host compatibility and explicit Legacy fallback」：openclaw plugins inspect distilly --json
  • README「The first usable flow」：OpenClaw 的 packaged restart、long-lived Skill、uninstall lifecycle checks remain separate
  • README「Host compatibility and explicit Legacy fallback」：Any unrecorded version ... returns host_unsupported
材料未说明：README 未说明 OpenClaw 长期 Skill、重启和卸载检查何时完成；README 未给出实际人物画像在 65,536 字节预算中的可容纳规模
视情况 我锁定 Hermes v0.9.0，希望把 Distilly 安装到 `~/.hermes/skills/distilly`，只暴露五个 MCP 工具，并传递完整 briefing；但我还需要重启、长期 Skill 和卸载都经过验证，是否应该采用这条路径？
适合读者： 使用 Hermes v0.9.0、要求 MCP 只暴露五个工具并依赖本地配置的 Agent 集成开发者

视情况：Hermes 的安装路径和 briefing 传输已有明确 fixture，但完整生命周期尚未验证，不能按已完成的生产适配来决策。

  • README 规定 Hermes 使用 ~/.hermes/skills/distilly、~/.distilly/bin/distilly-hermes 和 ~/.hermes/config.yaml，并关闭 resources 与 prompts，使暴露面保持五个工具。
  • Hermes v0.9.0 的记录净预算是 49,752 字节，且 README 说明其 briefing transport path 已针对该 fixture 验证。
  • 可使用 hermes mcp test distilly 检查 MCP，但 “Host status” 仍将 restart、long-lived Skill 和 uninstall lifecycle 标为 pending。
  • 未记录的版本或序列化组合会在写入前被拒绝；项目也不会因为 Plugin 预检失败而自动改用 Legacy 模式。

所以它适合做受控的 MCP 和 briefing 集成，不适合把持久化、升级和卸载视为已经交付的能力。

  • README「Host compatibility and explicit Legacy fallback」：Hermes installs the canonical Skill at ~/.hermes/skills/distilly
  • README「Host compatibility and explicit Legacy fallback」：49,752 serialized bytes for Hermes
  • README「Host compatibility and explicit Legacy fallback」：hermes mcp test distilly
  • README「Host status」：Hermes 的 lifecycle pending
材料未说明：README 未说明 Hermes 的重启、长期 Skill 和卸载验证具体覆盖哪些场景；README 未说明 49,752 字节预算下不同模型会剩余多少可用上下文
视情况 我需要在 Codex、OpenClaw 和 Hermes 之间复用同一人物画像，资料包含工作习惯和表达特征，并要求数据留在本地、每次纠错可追溯；Distilly 是否能满足跨宿主部署？
适合读者： 需要把人物画像部署到多个 Agent 宿主、同时要求本地存储、证据可追溯和不泄露敏感资料的高级集成用户

视情况：Distilly 的本地优先、版本化和纠错模型符合要求，但跨宿主能力受版本 fixture、传输容量和生命周期验证状态限制。

  • 项目洞察将本地数据作为权威来源，并支持 evidence-bound briefing、版本化 Person Profile、显式 correction，以及在本地 Panel 中批准、拒绝或回滚候选版本。
  • Codex 的完整流程已验证；OpenClaw 2026.3.24 和 Hermes v0.9.0 只记录了 briefing transport fixture，长期 Skill、完整重启和卸载仍未全部验证。
  • 三个宿主的传输预算不同：OpenClaw 为 65,536 字节，Hermes 为 49,752 字节；超过已验证预算时会拒绝传输并保持存储数据不变。
  • README 强调只保留一个可发现的 distilly 实例，并要求核对实际加载副本；本地优先也不替用户处理本地文件、宿主进程和公开 URL 的权限管理。

所以它适合受控的跨宿主画像复用，不适合承诺所有宿主拥有一致的持久化、升级和卸载行为。

  • 项目洞察「solution_analysis」：local-first、evidence binding、版本化 Person Profile、correction、审核和回滚
  • README「The first usable flow」：lets you promote, reject, or roll back the candidate in the local Panel
  • README「Host compatibility and explicit Legacy fallback」：OpenClaw 65,536 字节、Hermes 49,752 字节
  • README「The first usable flow」：never silently truncates ... keeps the stored data unchanged
  • README「Host compatibility and explicit Legacy fallback」：Keep exactly one distilly active in any host discovery scope
材料未说明：README 未说明多个宿主之间 Person Profile 版本同步和冲突处理机制；README 未说明本地 Panel 是否提供完整审计日志、访问控制或团队协作权限；README 未证明敏感资料在宿主进程和公开 URL 研究阶段的具体加密与隔离方式

✨ 核心亮点

  • 本地保存可版本化的 Person Profile，无需额外模型 API Key
  • Codex、OpenClaw 2026.3.24、Hermes v0.9.0 有主机实测夹具
  • 模型侧固定为五个 MCP 工具，支持修正、审核与回滚
  • Developer Preview 仍在 0.1.0-preview.1，尚未打标签或发布 npm

🔧 工程化

  • 导入 TXT、Markdown、JSON、SRT/VTT，生成证据绑定的 Person Profile
  • 用 distilly_ingest、distilly_commit、distilly_correct 管理档案版本
  • Codex 使用 Native Plugin，OpenClaw 与 Hermes 使用兼容绑定

⚠️ 风险

  • 0.1.0-preview.1 不是 tagged release，也不是 npm package
  • 未记录的主机版本会在 setup 前返回 host_unsupported
  • OpenClaw 与 Hermes 的重启、卸载生命周期仍待验证
  • Legacy collectors 可能向同一 ~/.distilly/ 写入凭据配置

👥 适合谁？

  • 使用 Codex、OpenClaw 2026.3.24 或 Hermes v0.9.0 的 Agent 开发者
  • 需要把本地 TXT、Markdown 或公开 URL 变成可审核人物档案的团队
  • 希望通过五个 MCP 工具复用个人判断与表达风格的开发者