乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > 我不想再为任何一个 AI 软件打工:把 Skills、MCP、知识库和记忆都收进自己手里

我不想再为任何一个 AI 软件打工:把 Skills、MCP、知识库和记忆都收进自己手里

当前时间： 1970-01-01 08:00:00 分类：办公文件 评论(0)
我不想再为任何一个 AI 软件打工:把 Skills、MCP、知识库和记忆都收进自己手里
Codex 是我最近用得最顺手的 AI 开发 Agent，但它有个"带不动团队"的问题。
我们团队里大多不是技术出身。原生 GPT 账号不好分配，让小伙伴自己在codex配置国内 DeepSeek模型，分配API密钥，费劲、门槛又高——工具是好工具，可推不下去，就成了我一个人的玩具。
直到 DeepSeek Harness 上线，一出来就爆了。我上手体验，从基础调用一路玩到开发插件，越用越觉得：这玩意儿简直是为我们这种"技术水平参差不齐的团队"量身定的。于是问题就来了——要不要迁过去？
真正让我离不开 Codex 的，其实不是模型本身。
项目规则放在 AGENTS.md 里，它照着执行；重复性任务做成 Skills，一句话就能调；店铺数据、外部数据接了 MCP 直连；复杂任务还能拆给多个 Agent 并行跑。用久了你就会发现，它早就不只是一个聊天框，而是我整个 AI 工作流的底盘。
但也就是在这一刻，我想通了一件更重要的事。

01

真正头疼的，不是换一个 AI 软件
我后来发现，这次迁移真正头疼的，不是换一个 AI 工具。
而是我过去积累的东西，全都长在 Codex 里面。
我写了很多 Skills，接好了店铺数据和外部数据的MCP，给不同 Agent 设定了分工和做事规则，整理了一套自己的知识库——还有，那么多轮对话里，我和 Agent 之间磨合出来的默契。
这些才是我真正值钱的东西。
Codex、DeepSeek Harness，或者以后出现的其他 Agent 软件，说到底都只是帮我调用这些资产的"工作台"。
如果每换一个软件，技能重新写一遍、MCP 重新配一遍、规则重新教一遍、知识库重新传一遍、记忆全部清零——那根本不叫迁移。
那叫推倒重来。
所以，我现在想做的事情已经变了。
我不是单纯把 Codex 搬到 DeepSeek Harness，而是要把自己的 AI 工作流从任何一个软件里拆出来，单独管理。
说得再直白一点：
软件可以换，我积累的东西不能跟着报废。
以后不管市面上是 Codex、Claude Code、DeepSeek Harness，还是其他 Agent 更新得更好用，我都希望只做一次简单适配，就能继续使用原来的技能、数据接口、规则、知识库和记忆。
我准备把这套东西建成一个团队 AI 资产库：5 类资产，加 1 个软件适配层。
资产 1：Skills——AI 会做什么
Skills 可以理解成我教给 AI 的一套套做事方法：怎么分析亚马逊广告、怎么核算产品利润、怎么研究一个新品类、怎么生成报告。
以前这些技能主要放在 Codex 里。换到其他 Agent 时，我不想重新写一遍，所以会把每个 Skill 都整理成独立文件夹，一个文件夹放清楚：
  • 什么时候使用；
  • 具体怎么执行；
  • 需要哪些脚本；
  • 依赖哪些参考资料；
  • 最后交付什么结果。
Agent 软件只负责读取和执行。以后换软件，迁移的就不是一堆零散提示词，而是一套整理好的业务能力。
资产 2：MCP——AI 能连接什么数据
MCP 可以简单理解成 AI 连接外部系统的插座：店铺数据、广告数据、关键词数据，都通过这些插座接给 Agent。
麻烦的是，不同 Agent 软件存放 MCP 配置的位置不一样。但每个 MCP 用什么地址、需要什么参数、提供哪些工具，这些核心信息其实没变。
所以我不在每个 Agent 里分别维护配置，而是先建一份统一的 MCP 清单，只记录：这个 MCP 是做什么的、从哪里启动、需要哪些环境变量、提供哪些工具、谁能用。再针对不同软件生成它们认识的配置格式。
以后新增或修改一个 MCP，我只维护源头，不再去每个软件里手动改一遍。
资产 3：Agent 规则——AI 应该怎样分工
我现在的工作流里，不同 Agent 有不同分工：有的查资料、有的执行、有的检查数据、有的做最后审核。
这些分工不该绑定某一个软件。所以我把每个 Agent 的身份、职责、输入、输出和不能做的事，整理成独立规则：
  • 总调度 Agent 负责拆任务，不能自己编数据；
  • 数据 Agent 只负责调用工具和保存证据；
  • 分析 Agent 根据已有数据形成判断；
  • 审核 Agent 检查结果，不参与前面的执行。
Codex 有自己的加载方式，DeepSeek Harness 也有自己的插件和调度方式。加载方式可以变，但底层规则不变。换软件时，只需要把规则翻译成它认识的格式，而不是重新想一遍团队该怎么分工。
资产 4：知识库——AI 可以参考什么
知识库是最容易被软件绑住的部分。很多 AI 产品都支持上传文件，但文件一旦全放进某个平台，换工具时又要重新整理、重新上传，甚至不知道哪些内容已经过期。
所以我的知识库不会只存在某个 Agent 的聊天记录里。产品资料、运营方法、历史报告、店铺规则、团队经验，都保存在自己能控制的目录中：能用 Markdown 就用 Markdown，需要表格就保留 Excel，原始数据用 CSV 或 JSON 等通用格式。
Agent 只负责读取知识库，不负责拥有知识库。 换软件时，我不需要搬走全部资料，只需要告诉新 Agent 去哪里读取。
资产 5：会话记忆——AI 做过什么、学到了什么
这是最容易被忽略、也最要命的一类资产。
我们平时和 Agent 聊天，会不断补充背景、纠正判断、确认规则——店铺现在什么阶段、上次广告调了什么、哪些关键词测过了、为什么暂时不做某产品、老板更看利润还是销售额、这个 Agent 上次错在哪、任务做到哪一步了。
这些内容不会全写进知识库，却直接影响 Agent 下一次能不能接着干活。
如果换一个 Agent 软件，这些记忆全丢，新 Agent 就只能从头再问一遍——前面聊了几十轮，换个平台，一夜回到解放前。
所以，会话记忆也必须从软件里拆出来单独管理。我准备把它分成三层：
第一层：原始会话。 用户说了什么、Agent 做了什么、调过哪些工具、得到什么结果。它相当于完整工作记录，不一定每次都喂给模型（太长、成本高），但必须保留，方便以后查询追溯。
第二层：任务记忆。 每次任务完成后，不只保存聊天记录，还自动整理一份交接说明：这次的目标、完成的步骤、用过的数据、关键判断、用户确认的决定、没解决的问题、下一步做什么。这样哪怕换了会话、换了 Agent、换了软件，也能读取交接说明继续干活。
第三层：Agent 长期记忆。 不同 Agent 该有各自的长期经验——广告 Agent 记住测过哪些调整，内容 Agent 记住我的写作习惯，审核 Agent 记住出过哪些错。
但这些记忆不能由 Agent 随便写，否则它可能把一次临时要求当成永久规则，或把错误判断一直留着。所以长期记忆要设置明确的写入条件：
  • 用户明确确认过；
  • 在多个任务中重复出现；
  • 后续仍然可以复用；
  • 不包含账号密码等敏感信息；
  • 写入后可以查看、修改和删除。
这样保存下来的不是聊天废话，而是真正能帮助下一次工作的经验。
一句话区分这三类资产：知识库保存"我们知道什么"，会话记忆保存"我们做过什么、为什么这样做、下一步做什么"，Agent 记忆保存"这个 Agent 在长期协作中学会了什么"。
最后一块：软件适配层——不同 Agent 的"转换插头"
当 5 类资产都独立出来以后，才轮到 Codex 和 DeepSeek Harness。
我会给每个 Agent 软件准备一个转换层。它不保存真正的业务资产，只负责把同一套资产转换成不同软件能识别的格式：告诉软件去哪读 Skills、生成对应的 MCP 配置、加载规则、注入当前 Agent 的记忆、任务结束后生成交接记录。
以后换工具，不再重新搬家，只需要换一个转换插头。
团队 AI 资产库├── Skills：会做什么├── MCP：能连接什么├── Agent 规则：应该怎么做├── 知识库：知道什么└── 会话记忆：做过什么、学到了什么          ↓软件适配层├── Codex├── DeepSeek Harness└── 以后出现的其他 Agent
其中最关键的一条边界是：软件里的完整聊天记录可以保留，但只有经过提炼和确认的内容，才能进入长期记忆。否则迁移的不是经验，而是一大堆噪音。

02

验证：软件和资产，先各归各位
说了这么多，我实际验证过的第一步，就是搞清一件事：你从这个目录启动 DeepSeek Harness，不代表业务文件也要迁进这个目录。
现在实际已经形成了三层目录：
目录
实际用途
是否迁业务文件
deepseek-harness/
程序源码、启动服务
不迁
~/.dsh
模型设置、会话、Web 配置和插件注册
只放运行配置
Documents/业务工作区/
实际业务
Codex 工作流迁到这里
启动就一行：
cd deepseek-harnesspnpm dsh web
打开网页后选择业务工作区，之后 Agent 的读取、修改、Skill 发现和命令执行，都围绕业务目录进行，不会局限在程序源码里。
一句话：软件装在它自己的地方，你的东西放在你的地方，两边各归各位。
目前已经验证的事实：
  • AGENTS.md 放在业务项目根目录，DeepSeek Harness 原生识别，不用改名、不用搬；
  • Skill 放在业务项目的 .dsh/skills/ 下就会被发现，Codex 的技能结构可以直接保留；
  • 需要稳定调用的能力，封装成原生插件注册到 ~/.dsh/profiles/web，重启后生效——核心计算链路已用固定数据验证通过。
但端到端验收还没做完，所以这篇文章只讲方法和进度，不写"已经迁移完成"。

03

记忆怎么迁：不搬聊天记录，只搬有用的结论
Codex 和 DeepSeek Harness 的会话格式不一样，所以我不会直接复制聊天记录。
真正要迁移的只有三类内容：
  1. 团队已经确认的规则和决定；
  2. 每个 Agent 工作中积累的经验；
  3. 当前项目做到哪里、下一步做什么。
具体实现并不复杂。
我会在业务项目中建立一个统一的记忆目录：
三个地方分别保存不同内容：
  • shared.md：团队长期有效的公共规则和已确认决定；
  • agents/*.md：每个 Agent 自己踩过的坑和可复用经验；
  • handoff.md：当前项目完成了什么、还剩什么、下一步做什么。
然后在项目的 AGENTS.md 里加两条规则：
Codex 和 DeepSeek Harness 都在同一个业务工作区里读取 AGENTS.md，所以它们会使用同一套记忆文件。
这样换 Agent 软件时，不需要迁移记忆目录。
因为记忆从一开始就不属于 Codex，也不属于 DeepSeek Harness，而是保存在自己的业务项目里。
实际运行过程就是：
Codex 现有会话也不用全部整理。
只挑真正重要的历史任务，让 Codex 输出一份包含"确认决定、验证经验、当前进度、下一步"的交接摘要，再写进对应的 shared.md、Agent 记忆或项目 handoff.md。
这才是长期记忆迁移。
不是把过去的聊天全部搬走，而是让新的 Agent 知道：以前做过什么、踩过什么坑、现在应该接着做什么。
一句话版的实现方式就是：
用 AGENTS.md 规定读写规则，用 Markdown 文件保存记忆，让 Codex 和 DeepSeek Harness 共同读取。
第一版不要急着做数据库、向量检索或自动总结。先把这三个文件跑通：
等真实运行一段时间，记忆文件多到不好查了，再增加自动分类和搜索。

04

这才是这篇文章真正想讲的事
回到开头那个问题。
我一开始以为，我要写的是"怎么把 Codex 搬到 DeepSeek Harness"。
写到一半才明白，这次迁移真正的主角不是 Codex，也不是 DeepSeek Harness，而是我这些年攒下来的 AI 资产。
Skills 是我会做的事情，MCP 是我能调用的数据，Agent 规则是我的团队分工，知识库是我踩过的坑和攒下的经验，会话记忆是我们和 AI 之间磨合出来的默契。
这些资产，应该一直掌握在我自己手里。
DeepSeek Harness 只是这次用来验证迁移方案的新工作台——验证的是：原来在 Codex 里使用的 Skill、脚本和业务逻辑，能不能在保留核心资产的情况下，换一个 Agent 软件继续运行。
我的最终目标，是把这些零散资产做成一个统一管理的团队 AI 资产库。以后团队不需要关心底层用的是 Codex 还是 DeepSeek Harness——哪个工具更稳定、更便宜、更适合国内团队，我们就用哪个。
工具一直会变。
但我们积累下来的 Skills、数据接口、知识、规则、记忆和业务经验，应该一直掌握在自己手里。
一句话总结这篇：我要做的不是 Codex 的备份，而是一套不依赖任何 Agent 软件的团队 AI 资产管理系统。
喜欢这篇的话，点个赞和在看，转发给身边做 AI 的朋友。
我是脆皮AI，00后跨境电商创业者，从0到1记录AI学习成长——踩过的坑、试过的工具、赚到的方法，都在这。关注我，下次不迷路。