我们给DeepSeek Harness接入了MemSearch ，自动把Memory提炼成Skill

DeepSeek Harness与MemSearch的集成背景

DeepSeek Harness（DSH）的口号是：模型、工具、Skills、会话、沙箱、存储、Agent Loop、调度，甚至 UI，一切皆插件。虽然发布不到两周，但已获得近20万 Star，可能成为相当长一段时间里的 Agent 设计标准之一。

应社区要求，正式将开源的 Agent 记忆框架 MemSearch 接入 DSH 插件。

使用时，只需运行以下命令，即可让 DSH 具备 MemSearch 的能力：

uv tool install "memsearch[onnx]"
dsh plugin --profile web add @zilliz/memsearch-dsh

以下为 MemSearch 的开发与使用详情。

DSH接入MemSearch后的三大能力提升

借助 MemSearch 插件，DSH 可以获得三个能力：

• 第一，永久记忆。今后，使用 DSH 时，跨天、跨会话，做过的操作、下过的决策，都会沉淀成持久化记忆，不再跟着聊天窗口清零。
• 第二，跨 Agent 共享记忆。同一份记忆，可以在 Claude Code、Codex、DSH 之间自然流动。可直接用 DSH 续上之前用 CC 或 Codex 时留下的记忆，无需手动迁移。
• 第三，自进化。记忆不只是回放过去，还能长成下一次可调用的能力，让 DSH 越来越顺手。

永久记忆：支撑企业级项目决策追溯

在设计一些企业级大项目时，当前代码和任务状态可以很好工作。但它无法完整解释一个项目是怎样走到这里的：架构选型的依据、被排除的方案、临时 workaround 的适用条件，以及上次调试已经验证过的方向，都散落在过去的会话里。

缺少它们，Agent 即使知道代码现在是什么样，也未必知道为什么不能随意改动。

为此，给 DSH 提供了高效的长期记忆机制。

装好 MemSearch 插件之后，无论跨多久、跨多少会话、怎么换模型，操作记录都会持久化存下来，随时能被语义检索捞回来。

只要照常使用 DSH，聊天、写代码、调试，插件在后台完成记录。

之后可以直接追问：「这个功能之前规划过吗？当时为什么没有继续？」「我们最终选择 Postgres 的依据是什么？」「这个部署问题上次是怎么解决的？哪些尝试已经失败过？」

这些记录可以让 DSH 找回决策依据，避免重复已经失败的尝试，也方便开发者检查某个方案在当时是否受一次性条件影响。

跨Agent共享记忆：统一记忆格式与项目目录

DSH 的新用户一定有这么一个问题：我原来在 CC、在 Codex 上面的会话记录，我想在 DSH 上继续使用。

MemSearch 插件实现了这一愿望。

之前使用 MemSearch 的用户，这一次装上 DSH 的 MemSearch 插件，直接就能够继续之前在其他主流 Agent 上面的记忆，进行继续开发。

而且，开发工作，本来就是经常需要跨 Agent 进行。你可能在 DSH 里实现功能，随后换到 Codex 做 Code Review，再让 Claude Code 补端到端测试。

三个 Agent 处理的是同一个项目，需要读取同一批历史决策。

MemSearch 会把 Markdown 文件作为记忆的事实来源，并在不同平台插件之间沿用同一套记忆格式。

只要相应 Agent 都安装了 MemSearch，并使用同一个项目中的 .memsearch 记忆目录，后来的 Agent 就可以检索前一个 Agent 留下的进度、决策和经验，不需要先导出再导入。

自进化：从Memory到Skill的正向循环

对比 Claude Code，多数编程 Agent 的扩展机制，都是在一个已经确定的 Agent Loop 之上增加 Skills、工具、子代理或 Hooks。

DSH 的插件边界则更加灵活：除了模型、工具和 Skills，会话、存储、Agent Loop、调度和 UI 本身也属于可组合能力。

如此一来，借助 DSH + MemSearch 就可以形成一个可以从记忆中自动创建 Skill 的正向循环：随着事件记忆持续积累，同一类工作会反复出现。发布版本、准备测试环境、排查线上故障等流程一旦多次复现，Memory 中提出的解决方案，本质上就是一个可以被多次复用的 Skill。

如此一来，Agent 的能力边界就不会再出厂就定死，而是成为一个真正灵活，可以自进化的 Harness 系统。

Memory to Skill：把重复经验变成可复用流程

Agent 在进化的前提是积累大量真实用户交互数据。比如你用了它多久、习惯是什么、环境给了什么反馈。以及哪些任务经常出现，哪些步骤保持稳定，用户有哪些偏好，哪些做法经过了多次验证。

在 MemSearch 中，这对应的是记忆的后台整理能力。打开可选功能、配上整理任务，它会定期从你的项目里提取出 PROJECT.md 和 USER.md：前者记项目长期的状态、决策和风险，后者记你的偏好和开发习惯。

为此，MemSearch 把记忆组织成三层：

这里关于记忆的分类详情，可以参考之前的文章：https://mp.weixin.qq.com/s/PqJAJopvVBHjsjY0SpLOmA

前两层，很多记忆系统都有，第三层的 Memory to Skill 是我们一个独有的能力。

它可以把记忆里反复出现的范式，提炼成符合 Agent Skills 开放标准的 Skill 文件。

举个小例子。你每次发版本，都手动改版本号、更新变更记录、跑构建、再到干净环境验证安装。这套动作散落在记忆里，重复做了五六次。Memory to Skill 会把它蒸馏成一个叫 release 的 Skill。装好之后，下次你只说一句「发个版本」，Agent 就按这套流程走。

这里我们刻意不做成全自动。候选会先躺在 .memsearch/skill-candidates/ ，等人来 review。

这个设计的初衷是因为蒸馏出来的东西不一定对。某个步骤可能带着一次性 workaround，某条命令可能写死了 remote，甚至混进了不该固化的秘密。让这些自动进入能力层，比记错一条笔记危险得多。

为什么Memory to Skill与DSH更搭

有了 Memory to Skill，一个典型的 Agent 闭环就已经搭建完成。

但是在多数的 Agent 中，要想知道 Memory to Skill 主动生成了哪些可以被升级为 Skill 的 Memory，还需要用户主动去打开文件、或者主动提问 Agent：

"现在有什么新的被蒸馏出来的 Skill 了吗？"

DSH 改变了这一步。

因为 DSH 的 UI 也是插件，这样一来，就可以让 MemSearch 直接在 Web 界面中挂载一个 MemSearch Dock（悬浮面板）。

面板会展示待处理的 Skill 候选及其来源与出现频率，并提供 Review 和 Install 入口。

点击 Review，也不会中断正在执行的任务。审查请求会排入 Agent 的下一轮，由它读取候选、核对来源并给出建议；点击 Install 后，候选才会被安装到 DSH 可以加载的 Skill 目录中。

这就形成了一个闭环：

随着系统越用越久，MemSearch 从历史对话中学到的知识与 Skill 也会越来越多，整体 Agent 的效率也会不断提升并接近真实项目和个人习惯。

也就是说，这本质上，就是一种让 Agent 自进化的过程，通过人类的反馈、记忆，来实现 Skill 发现、蒸馏、更新、调用。

它离 Agent 自主重写整个 harness 的这种彻底的进化还很远，但 DSH 把一切都做成了插件，也意味着我们离目标又近了一步。

今天落盘的，是一份经过审查的 Skill。明天，同一批长期反馈，也许能帮你决定换哪种 preset、怎么调调度、在哪一环加审查。

这也是 DSH 创作者模式背后的架构 Cordis 的愿景。

到那时候，你的记忆不再只是回放过去，它会参与到 Agent 的每一次自我改造里。MemSearch DSH 插件，让它迈出了第一步。