DeepSeek Harness内核解析及Cordis优势 | 前途科技众所周知，DeepSeek Harness的内核是cordis，通过vendor"钉"进主仓库，附带 18 条本地补丁，改名 @deepseek-ai/cordis。
它来自一个最开始和 AI 八竿子打不着的项目——Koishi，一个 QQ 聊天机器人框架。
一个聊天机器人框架的内核，为什么能给当红炸子鸡 DeepSeek 当 Agent 运行时的内核？
带着这个疑问，这两天我仔细琢磨了那篇配套论文、cordiverse/cordis 的源码结构以及翻了各家代码级拆解，大概是摸到了一些门道。
cordis 的作者叫 Shigma，本名史一凡，北大人。
这哥们对 "shi" 这个音有很深的执念：本名 Yifan Shi，做的框架叫 Koishi，GitHub ID 叫 Shigma。（doge）
Koishi 是 2020 年发布的聊天机器人框架，在国内做 QQ 机器人的圈子里几乎人手一份。四年时间，社区给它攒了 4000 来个插件。
而 cordis 这个名字，来自拉丁语的"心"。用 Shigma 自己的话说：Koishi 的一切，都从 cordis 开始。
时间线拉出来，你会发现这是个伏笔回收的剧本：
2022 年 5 月，Shigma 把 Koishi 里的插件管理内核抽了出来，做成一个独立的元框架，就是 cordis，首次提交在 5 月 18 日。
2023 年，他给 Koishi 写了一篇设计文章，标题叫《可逆的插件系统》。记住"可逆"这两个字——它是后面所有故事的主线。
2026 年，Shigma 的名字出现在 DeepSeek V3 技术报告里，人进了 DeepSeek。然后就是 8 月 13 日：cordis 以 vendor 的身份进了 DeepSeek Harness 主仓库；同一天，一篇北大加 DeepSeek 联合署名的论文挂上预印本——《A Programming Paradigm for Spatiotemporal Composability》，时空可组合性编程范式。
再看几个数，感受一下这个项目的"体格"。
cordis 仓库总共 7,634 行 TypeScript，其中核心逻辑约 2000 行；运行时零依赖——是真零，只依赖 Node 和 TS 的内置能力。550 个 commit 里，90% 以上出自 Shigma 一人之手。
顺便一提，围绕 cordis 还有个自建的小生态：官方组织 cordiverse 名下，除了主仓库，还有配套的论文仓库（2,100 多 star），加上 database、webui、registry、server 等八个官方插件包。典型的自上而下产品化打法——不是只交一个 core 等社区自己长，而是先把参考实现铺满。
说白了，这是一个人用四年业余时间养出来的一颗内核。
Shigma 当年在 cordis 文档里留过一句话：
"我希望它能成为未来软件（至少是我开发的软件）的核心。"
四年后，DeepSeek 用一篇论文加一整个 Harness，替这句话盖了章。
那么问题来了——一个聊天机器人框架的插件内核，到底解决了什么了不起的问题，值得 DeepSeek 连人带代码一起收编？
插件系统这东西，相信大家都非常熟悉了。
往一个系统里动态塞一个模块，这个能力几十年前就有了。现在的 IDE 和浏览器里面非常常见。
但是插件难的根本不是"装"，是"卸"。
先看一个最常见的死法。
你给一个框架装了个插件，它注册了全局事件监听、开了定时器、占了文件句柄、改了全局状态。等你想卸载它的时候发现：监听还在响，定时器还在跑，句柄漏了，全局状态被污染了。
这就好比，如果退租的时候墙上还留着钉子，房东找谁说理去？租客早就跑了。系统也一样——写插件的人早就不维护了，留你一个人面对满墙钉子。
想了解 AI 如何助力您的企业？
免费获取企业 AI 成熟度诊断报告，发现转型机会
在 Node.js 的长驻进程里，内存泄漏和僵尸监听器不是意外，是常态。插件装了卸、卸了装，反复几个循环之后，系统就慢慢"变味"了。表现出来就是：跑得越久越慢，重启一下包治百病。
这个问题，在 AI Agent 时代被放大了无数倍。
为什么？因为 agent 运行时把插件系统往一个它从没被设计过的方向上拧。
传统的宿主是静态的：编辑器在那儿，插件往身上挂，相安无事。而 agent loop 是一个带状态的多步流程机——它要跨几十轮对话维护上下文、调用工具、执行多步计划。你中途拔掉一个它依赖的组件，下游所有已经"答应"了这个计划的步骤，要么跟着变，要么当场崩。
文本编辑器可以容忍一个插件留下悬空引用，大不了界面闪一下。一个已经提交了多步计划的 agent 不能。
况且，现在大家想让 agent 自己改自己的运行时——装新工具、换新技能、挂新适配器。改动如果不能干净回滚，改坏一次，整个进程的状态就被污染了。
举个具体的场景。你让一个 agent 做接口压测，它发现自己缺一个压测插件，于是现场写一个、挂上去。听起来很爽对吧？但如果挂载这个动作注册了事件、占了句柄、改了状态，而后续卸载时留了一半垃圾，跑上几个小时之后，这个进程的内部状态就是一锅粥。
到那时，你甚至回答不了一个最基本的问题：现在系统里到底有什么？
这个问题在 agent 框架圈还有另一个变体。LangChain、AutoGen、CrewAI 这一批，核心循环、上下文管理、调度策略全锁死在框架内部——你能在边缘加工具、换模型，但想改 agent loop 的调度逻辑？要么 fork 整个框架，要么提个 PR 排队等人 review。想换掉 session 的存储方式？对不起，核心代码里写死了。
看看市面上的基础设施框架，你会发现每家都只解了半道题：
▍NestJS 有依赖注入，但没有副作用追踪——写 NestJS 插件的人照样得手动清理 timer 和 listener。
▍pytest 那套 Pluggy 有 hook 系统，但插件之间不能声明依赖。
▍Effect-TS 有完整的 effect 模型，但它不是框架，生命周期得自己搭。
▍Vue 和 React 的 plugin 加 context，只覆盖 UI 层，够不到应用级生命周期。
cordis 的赌注就一句话：干净卸载，应该是框架在结构上保证的属性，而不是每个插件作者都要自觉重写一遍的纪律。
那 cordis 是怎么把"可卸"做成数学性质的呢？
《A Programming Paradigm for Spatiotemporal Composability》——时空可组合性编程范式。这篇文章把"动态组合"切成了两个正交维度，一个管时间，一个管空间。
▍时间维度：Temporal Composability，副作用可逆。
一个组件被卸载时，它产生的所有副作用——事件监听、文件句柄、内存分配、注册的命令——必须被完整逆转。系统恢复到"这个插件从来没来过"的状态，不多一分，不少一毫。
落到 API 上，核心就一个函数：ctx.effect()。
它要求所有副作用操作都返回一个"清理函数"（disposer）。运行时把清理函数存进栈里，插件卸载时，按注册的逆序全部执行。写出来大概长这样：
ctx.effect(() => {
const timer = setInterval(poll, 1000)
return () => clearInterval(timer)
})
就这么几行。你注册副作用，顺手把"反悔的方式"交出去。剩下的——什么时候执行、按什么顺序执行、怎么保证执行——全是运行时的事，不劳插件作者操心。
你可以把它理解成租房：每往墙上钉一个钉子，就自动记一笔账；退租那天，按记账逆序把钉子全起出来、把胶印全擦掉，房间恢复到你入住前的样子。
相信懂 C++ 和懂 Rust 的朋友看到这里都不会陌生——这不就是 RAII 和 Drop trait 嘛。区别在于，cordis 把这件事从语言层提升到了运行时层。
语言级的 RAII 只能管住你自己写的代码。运行时级的 RAII，意味着两个从没见过面的团队、隔着时区的两个人写的第三方插件，卸载时照样干干净净。
在 Koishi 里，这件事被验证了四年：管理员从控制台停用一个插件，它对系统的影响原地撤回，其他插件接着干活；开发者改完插件代码一保存，被修改的插件重新挂载，缓存和连接纹丝不动。
▍空间维度：Spatial Composability，依赖反应式管理。
光能卸干净还不够。组件之间是有依赖关系的——功能插件依赖数据库驱动，数据库驱动依赖连接池，牵一发动全身。
传统 DI 容器（比如 Spring 那一派）的解法，是启动时把对象图装配好，一次成型，之后基本不再动。这对静态系统够了，对插件生态完全不够——插件是要随时来、随时走的。
cordis 的解法是"声明式依赖加反应式响应"：插件不"接收注入"，而是"声明需求"。运行时保证三件事——
B 依赖 A，B 一定在 A 就绪之后才启动；A 要停，B 一定先于 A 卸载；A 起不来，B 压根不启动。
变化时刻，当 A 被替换、重连或升级时，只有依赖真正发生变化的插件会被重启，依赖没变的插件纹风不动。
在 Koishi 生态里，这意味着你可以在线切换存储后端、重连消息适配器，而几百个插件里只有真正依赖它的那几个被重新激活。要知道，这些插件是几百个不同的作者独立写的，彼此之间唯一的协调机制，就是 cordis 的这条规则。
一套动态组合规则，真的能在开放生态里跑起来——这是论文最想证明的事。
底层还有个实现，叫 fiber。每个插件跑在一个 fiber 里，运行时给每个 fiber 维护一个"纪元"（epoch）——本质是所有依赖的指纹。依赖变了，指纹就变，插件被调度重载：先同步清空副作用列表，再逆序调用 dispose，中间用一把 inertia 锁保证重载和卸载不会并发打架。
▍两个维度合起来，产出一个工程上美妙的性质：路径无关性。
系统的最终状态，只取决于"开了哪些插件"，跟这些插件以什么顺序、经历几轮装卸到达这个状态，没有任何关系。
为什么说"美妙"？因为绝大多数系统的内部状态，是跟操作顺序耦合的。先装 A 再装 B，和先装 B 再装 A，跑一段时间之后往往就是两个世界——注册表的顺序、缓存的内容、监听器的排列，全都带着历史痕迹。cordis 把这些痕迹全部装进可逆的 effect 里，装卸互为逆操作，历史被逐步抹平，只剩当下。
加载路径不影响终态——这就是热重载在数学上安全的全部前提，也是 agent 想改自己运行时还不留烂摊子的全部前提。
cordis 甚至自己实现了 Node 环境下的热重载：监听文件变化，备份模块缓存，清空，重新导入，重新注册插件，一套"备份-清空-重导入"的组合拳，跨 Node 22、23、24 三个大版本兼容。开发插件的人保存一下代码，插件原地换新，连接和缓存全都不动。
支撑这套范式的，是三个落地的机制，全部暴露在一个共享的 ctx 上下文对象上：
▍ctx.effect()：可逆副作用，前面讲透了。
▍生命周期事件：ready / dispose / fork，挂载、销毁、分叉三个节点。
▍服务系统：插件的"贡献"以服务的形式注册进上下文，靠 Proxy 加 Symbol 命名空间做依赖路由——你写 ctx.foo，拿到的是当前作用域里那个正确的 foo，同名服务在不同隔离域里对应不同的实例。
Context 还支持三种嵌套操作：extend 继承、isolate 隔离、intercept 拦截，分别覆盖"局部定制、全局兜底"的三种玩法。会话隔离、请求隔离、不改实现就改配置，全靠这三板斧。
插件还自带配置解析：每个插件可以声明自己的配置模式，运行时沿原型链解析——子级覆盖父级，深度合并，父级兜底。这东西单看平平无奇，但它是 dsh 后来那套"四层配置管道"的物理基础。
数一数，cordis 一共给了五样东西：插件、生命周期与副作用、服务、事件、可配置。每一样单拎出来好像都听过，很多框架都有其中一两样。但五样拼在一起、互相咬合，才是论文标题里那个"时空可组合性"的完整体。
这里还有一个细节：cordis 的事件系统有五种派发模式——emit、parallel、serial、bail、waterfall——全部统一到一条内部路径上。前四种好理解，广播、并发、串行、短路。第五种 waterfall（瀑布流）是：一串监听器排成链，每个都拿到 next()，不调用就掐断整条链。
接下来看 DeepSeek 怎么在这颗内核上造发动机。
▍四、DeepSeek 在这颗内核上，造了一个什么发动机？
dsh 是个 49 个包的 TypeScript monorepo，约 1980 个 TS 文件，要 Node 22 以上才能跑。一条命令 npx @deepseek-ai/dsh web，浏览器里就起了一个 Agent 运行时，默认端口 3080。
standard 预设里都装了些什么？检视仓库、编辑文件、执行 shell 命令、检索本地文件和网页、维护计划、调用技能、委派子代理、执行审批策略。一个完整的 agentic coding 循环。
"产品的每一个部分都是插件——包括模型适配器、工具注册表、会话日志，以及 agent 循环本身——所以每一部分都能从配置里替换掉。这里没有一个特权内核可供修补。你扩展 dsh 的方式，是在其他插件旁边挂载一个新插件。"
—— DeepSeek Harness 架构文档
这句话的意义，要跟当前主流 Agent 产品结合对比才能掂出来。
Claude Code 和 Codex 允许你加工具、改提示词、挂 hook，但那个"读消息、思考、调工具、再思考"的主循环，是焊死在成品里的地基。你只能在地基留好的口子上挂东西。打个比方：Claude Code 和 Codex 是把模型和外壳焊死的成品手机，拿到就能用，想换颗螺丝得找原厂；dsh 不卖整机，卖的是图纸加全套可拆装模组——电池、摄像头、操作系统、屏幕，连"怎么打电话"的规矩都是一个个能拔能插的插件。
而 dsh 把地基本身也做成了插件：core/agent 定义接口，core/agent-loop 只是"实现该接口的默认驱动"。既然是默认的，就意味着可以换掉。
一个运行中的 dsh，本质就是一个 cordis Context：所有能力作为插件向 Context 注册服务、事件和 effect，最终由一份配置文件组装成可运行的 Agent。配置是一条四层管道——bundle 分发层、profile 补丁、用户主目录补丁、命令行 --patch，逐层叠加，后写覆盖。跑一句 dsh --dump-config，你这台机器实际启动成什么样，打印出来的任何一行都能被你的补丁替换。
换能力的方式，是改配置，不是改源码。这就是"一切皆插件"的操作入口。
仓库里目前带着四个预设：standard（常规任务全集）、code（对外叫 PTC 模式——工具列表塌缩成一个 run_code，模型直接写 TypeScript 程序来编排多步工具调用，五轮往返压成一轮）、minimal（最小环境，官方跑分用的就是它）、creator（创造模式，挂上 tool-cordis 和两个创作技能，让 agent 在运行时内省、试装插件、创作新 preset）。
还有个容易被一带而过的细节：预设是"每会话"级别的。同一个进程里，可以同时跑几个组装方式完全不同的 agent——一个揣着全套工具干重活，一个最小配置跑基准，各带各的工具和提示词分段，互不干扰。
连你浏览器里打开的那个 Web 界面，本身也只是一个默认挂载的插件。卸掉它，换一个自己写的，系统照跑。
工具的每次执行，都走一条 cordis waterfall：tools/pre-execute 到 tools/execute，再到 tools/post-execute，落到 tools/result。链上每个监听器都拿到 next()，不显式调用，链路就断。
这一下就把所有横切关注点统一了：超时策略挂在 execute 上，沙箱提醒挂在 post-execute 上，审批在 pre-execute 返回时触发，外部 hook 桥直接挂 pre 和 post 两个节点。
这意味着"审批、沙箱、超时、hook"这些原本散落各处的安全逻辑，现在共享同一条主干道。想加一道新的关卡，挂一个监听器就行，不用碰任何核心代码。
更关键的一条：模型驱动的调用、workflow 脚本的调用、subagent 的调用、PTC 模式的子调用——全部过同一个 ToolRuntime.execute 闸门。PTC 的子调用想绕过审批和沙箱？门儿都没有。
每一次 agent 运行都记进一份 append-only 日志：系统提示、推理过程、工具调用、返回结果、子代理调度、每一次上下文注入，全量留痕。
Turn 和 Step 都是日志事件，喂给模型的消息序列由 deriveMessages() 这个纯函数从日志投影出来。每次派发请求前，agent-loop 会拿 JSON.stringify 比对"即将发出的请求"和"从日志重建出来的结果"，不一致，直接 fail。
换句话说，这个系统在机械上强制"模型看到的"和"日志记录的"完全一致。排障、调试、评测、合规，全靠这个底座。Agent 干了什么、看到过什么，事后可以完整回放——这是原则。
评测也一样受益。想知道模型从哪一轮开始跑偏？日志里逐轮回放。想知道某个工具调用为什么被拒？瀑布链上每一站都留了痕。想知道换个模型的对照组表现？同一个日志，换一个适配器重放就行。
▍第三根：Capability Seam，能力接缝。
可替换的能力被拆成三个角色：服务定义（接口）、服务提供方（实现）、消费方（模型面向的工具）。
威力最大的是"执行世界"抽象——文件系统和子进程共享同一个 provider。你把 provider 指向远端沙箱（仓库里已经有 E2B 的概念验证），Bash、终端、LSP 整体迁移，消费方零改动。
同一个逻辑推到极致，就是 subagent：一个接口底下并存着六七个 provider。其中两个是别人家的成品——subagent-claude-code 直接在会话工作区里调 Claude Agent SDK，subagent-codex 通过 codex 的 app-server 起临时线程。
模型无关也是写进 DNA 的：provider 目录里躺着 Anthropic、OpenAI、Bedrock、Vertex、Azure 和任意 OpenAI 兼容端点的适配器，近 40 个模型可换。默认是 DeepSeek，但没人拦着你接 Claude 和 GPT。
沙箱是操作系统级的真隔离，不是应用层"自觉"：Windows 用 CreateRestrictedToken，Linux 用 Landlock 加 bwrap，macOS 用 Seatbelt。agent 在什么样的笼子里跑代码——这本身也是个配置项。社区连笼子都造好了三款：sandbox-micro、sandbox-mxc、sandbox-nono，对应三套隔离方案，挑一个换上就行。
其实，我之前挺好奇的，以 DeepSeek 的阵容和实力，为什么不自己造，偏偏是它？
一个会自我演化的 agent，需要三件事：动态加载（装得上新工具）、安全卸载（改坏了能回滚）、状态无关性（先装 A 还是先装 B，终态一致）。
市面上大多数框架做到了第一条。后两条，几乎没有人在框架层做到——直到 cordis 把它们做到了范式层。
dsh 仓库里有个包叫 packages/self-modification/，描述的是："agent 检查并挂载它自己的插件。"当所有能力都是插件，而 agent 又能装插件，它就具备了改造自己的接口。
但是当前版本里，动态包是不可变的、仅内存态的，进程重启即失；所谓"改自身"，是会话内的临时叠加，加上用文件工具把新 preset 写盘、重启挂载——不是运行中热替换当前装配。
然而方向我相信是明白无误的：一个能改自己运行时的 agent，只有在改动可逆时才值得拥有。改坏了回滚不干净，自进化就是自毁。cordis 的路径无关性，恰好是"自进化"这四个字的安全带。
DeepSeek 大可以自己写一个插件系统。但自研的东西，上线第一天没有实战数据；cordis 带着 Koishi 四年、4000 来个插件、几百个互不相识的作者的验证。
"不同作者独立开发的插件，在开放生态里动态组合还能保持正确"——这是拿四年生产环境换来的。
再加上工程适配性：零运行时依赖，核心 2000 行，TypeScript 原生，塞进 monorepo 零摩擦。vendor 进来，打 18 条补丁，改名发包，一个下午的活。
反过来看自研的风险。插件系统的坑，全藏在边角案例里——并发卸载、循环依赖、部分失败、热重载的缓存一致性。这些坑，cordis 用四年时间和几千个社区插件替你趟完了。自研团队要用生产事故去趟，代价只会更高。
还有人才方面，Shigma 本人在 DeepSeek。Harness 团队负责人崔添翼，浙大计算机出身，在校拿了 6 次 ACM 亚洲区金牌，毕业后在香港和纽约的 Jane Street 干了 9 年，是梁文锋的浙大学弟，今年 3 月加入 DeepSeek 组建 Harness 团队。论文三作者横跨北大和 DeepSeek——一作史一凡，二作张伟是北大软件研究所的副教授，研究方向就是软件工程和编程语言。
这个阵容，不是"临时找个开源库用用"的配置。这是冲着"Agent 时代的运行时基建"去组的队。
当前，模型和 agent 的能力，离收敛还远得很。今天看着正确的 agent loop、正确的工具协议、正确的记忆方案，明天可能被一篇论文整个掀翻。
在这个阶段做基建，"押注哪个答案"是个伪问题，"保留更换答案的能力"才是真问题。Claude Code 把一切焊死，换来稳定；dsh 什么都不焊，换来一条永远敞开的退路。
DeepSeek 团队就那么点人，不可能独自把记忆、调度、沙箱、多智能体的所有可能性都探索一遍。把 harness 开源成插件市场，就是把这个探索问题外包给全世界。社区插件话题 dsh-plugin 下面，已经攒了近 300 个。
迁移的路也全铺好了。hook 层面，hooks-claude-code 直接吃你现有的 hooks.json；API 层面，DeepSeek 官方同时提供 OpenAI 格式和 Anthropic 格式两个 BASE URL——一堆原本只认 Anthropic 接口的客户端，改个地址就能指过来。两家主流 coding agent 的用户迁移成本，被压到接近零。
当前官方在 GitHub 上暂不接收外部 PR，文档基本就是仓库本身，UX 还远远谈不上打磨完毕。
开源社区的规律从来是 1% 的贡献者养活 99% 的使用者。harness 这种需要开发者投入真金白银时间的项目，从 star 到插件之间隔着的不是热情，是真实的工程收益。收益什么时候出现？要么等生态里长出"杀手级插件"，要么等 DeepSeek 把模型能力和框架价值的联动真正跑通。
Claude Code 走的是苹果那条路：闭源、垂直整合、体验可控。dsh 摆明了走安卓那条路：图纸全公开，等全世界来盖房子。
房子最后有没有人盖，DeepSeek 说了不算。但如果这条路径跑通了，dsh 就是 Agent 时代的 npm，Agent 时代的 Kubernetes——比跑分领先几分，黏得多。基建的生意，从来不是赢在最快，而是赢在最难离开。
模型决定一辆车能跑多快，
harness 决定这辆车能不能边跑边换轮子。
而敢边跑边换轮子的车，
才开得进没人画过地图的地方。
21小时前
关注公众号
扫码关注，获取最新 AI 资讯
免费获取 AI 落地指南
3 步完成企业诊断，获取专属转型建议
已有 200+ 企业完成诊断
