deepseek-harness：一切皆插件的 TypeScript Agent 框架
DeepSeek Harness 把工具调用与 prompt 编排拆成可插拔模块，用 TypeScript 组装 CLI 助手，MIT 许可，已获 25 万星标。
一个 agent 框架最容易死的地方，不是模型不够强，而是每接一个新系统就要动一次内核。DeepSeek Harness 的赌注是：把内核做没，只留插件。
它由 DeepSeek AI 开源，TypeScript 编写，MIT 许可，仓库 deepseek-ai/deepseek-harness 目前 252213 星标、30337 fork、0 个 open issue。README 第一句就把架构讲完了——everything-is-a-plugin，底层跑在 Cordis 上，那套设计范式写在论文《A Programming Paradigm for Spatiotemporal Composability》里。
这句话值得拆开看，因为它是整个项目所有取舍的来源。
内核被压缩到只剩「插件容器」
大多数 agent 框架的组织方式是分层的：模型层、工具层、记忆层、编排层，每层有固定的接口和固定的位置。加一个能力，等于在某一层里插一个实现。这种结构上手快，但边界一旦定死，跨层的需求就得改框架本身。
dsh 反过来。工具调用、prompt 编排这些通常被当作「框架内置能力」的东西，在它这里都是插件。框架本身不预设 agent 应该长什么样，它只负责三件事：
- 加载插件：发现、装配、启动；
- 管理生命周期：插件的注册与卸载，这是 Cordis 那套「时空可组合性」要解决的问题——插件可以被动态加入，也可以被移除，而不是启动时一次性写死；
- 提供宿主：把装配好的 agent 跑起来，对外暴露成 Web UI 或 CLI。
按 README 能确认的组件，可以归纳成这样的分层：
| 层 | 组成 | 职责 |
|---|---|---|
| 宿主层 | dsh web 命令、Web UI（默认 http://127.0.0.1:3080） | 启动服务、打开浏览器、承载交互界面 |
| 装配层 | Cordis 运行时 | 插件的注册、组合、生命周期管理 |
| 能力层 | 工具调用插件、prompt 编排插件、以及社区 dsh-plugin 主题下的第三方插件 | 每一项 agent 能力，独立成插件 |
| 接入层 | 用插件封装的现有内部 API | 把已有系统接进 agent，不改内核 |
请求的流转路径因此很直：用户在 Web UI 里发起一次任务 → 宿主层把请求交给装配好的 agent → agent 的 prompt 编排由插件决定 → 需要调工具时，调的是某个工具插件 → 工具插件再去打内部 API。任何一环想换实现，换的是插件，不是框架。
这套设计的直接后果是：接入内部系统不需要 fork 框架。README 里点明的最典型用法就是这个——用插件封装现有 API，快速搭出可用的 CLI 助手。你写的是插件，框架不动。
跑起来只要一行
安装 Node.js 之后：
shnpx @deepseek-ai/dsh web
这条命令默认在 http://127.0.0.1:3080 起 Web UI 并在默认浏览器打开。两个细节 README 写得很明确：通过 SSH 启动时只打印 host URL，因为本地转发地址归 SSH 客户端或编辑器管；加 --no-open 则只起服务、不开浏览器。
想从源码跑：
shgit clone https://github.com/deepseek-ai/deepseek-harness.git cd deepseek-harness pnpm install pnpm run build pnpm dsh web
pnpm run build 准备构建产物，pnpm dsh web 直接用这些产物，不会重新构建。开发时另有 pnpm run dev:web，在同一个终端里完成构建、服务和客户端 bundle 的热重建；make help 会列出 Web 与 Desktop 对应的 Make 目标。
值得注意的是 npx 那条路径——不需要 clone、不需要 pnpm、不需要 build，一个命令起一个本地 agent 宿主。这是「按需组装」这个理念在分发层面的体现：先用起来，再决定要不要写插件。
插件生态的入口是一个 GitHub topic
dsh 没有另建插件市场。README 给的约定是：给你的插件仓库打上 `dsh-plugin` 主题，方便被发现。仓库自身的 topics 也是 ai-agents, cordis, dsh, dsh-plugin——dsh-plugin 和 cordis 并列，说明插件与运行时在这个项目里是同等重要的一等概念。
反馈走 GitHub Discussions，社区在 Discord。这些都是常规配置，但配合 0 个 open issue 这个数字看，维护节奏是「讨论区消化问题，issue 区保持干净」，而不是靠 issue 数量堆活跃度。
它和同主题项目差在哪
把几个同主题项目摆在一起，定位差异比功能列表更清楚：
| 项目 | 语言 | 约星标 | 核心定位 | 扩展方式 |
|---|---|---|---|---|
| deepseek-harness | TypeScript | 252213 | 一切皆插件的 agent 宿主 | 插件（dsh-plugin） |
| browser-use | Python | 117662 | 让模型直接操控浏览器 | 面向网页任务的专用框架 |
| TradingAgents | Python | 110665 | 多 Agent 协作做金融交易决策 | 角色拆分 + prompt 驱动 |
| rea | TypeScript | 108195 | 多 agent 逆向分析闭源程序 | 面向安全分析的 agent 编排 |
| graphify | Python | 125581 | 把代码库转成可查询知识图谱 | /graphify skill 接入现有 CLI |
| JavaGuide | JavaScript | 158947 | 后端知识体系与面试指南 | 文档，非框架 |
差别不在能力多少，在边界画在哪。
browser-use、TradingAgents、rea 都是「为某类任务预设好 agent 结构」——浏览器操控、交易决策、二进制逆向，各自有一套固定的角色与流程。这类框架的价值在于开箱即用，代价是换一个任务域就要换一个框架。
graphify 走的是另一条路：它不提供 agent 宿主，而是作为一个 skill 挂进 Claude Code、Cursor 这类已有 CLI，给 agent 补上「读懂项目全貌」这一块。它是能力补充，不是宿主。
dsh 选的是最靠底的那一层：它不预设你的 agent 干什么，只提供装配机制和宿主。文档整理、表格分析、写代码、定时任务——官网首页列出的这四类用法，在 dsh 里是四个插件组合出来的结果，不是四个内置功能。这让它更像一个运行时，而不是一个成品 agent。
JavaGuide 严格说不构成对照，它是知识文档而非框架，放在这里只是说明这个赛道里「高星」的含义并不统一：有的是框架被大量使用，有的是资料被大量收藏。
一个必须说清楚的边界
dsh 目前是 developer preview，README 用全大写强调：THERE WILL BE COMPATIBILITY-BREAKING CHANGES. 这不是免责声明式的客套，它直接决定了使用策略——现在写的插件，未来可能要跟着改。
README 还要求运行前先读 safety notice（SAFETY.md）。一个能调用工具、能接内部 API、能执行定时任务的 agent 宿主，权限边界就是它的风险边界，这一点在本地跑 Web UI 时尤其要注意。
仓库创建于 2026-08-13，最近推送 2026-10-17，两个多月里长到 25 万星。这个速度本身就说明「TypeScript + 插件化 agent 宿主」这个组合踩中了需求：前端和 Node 生态的开发者需要一个能用自己熟悉的语言写 agent 的容器，而不是去 Python 生态里找。
上手路径
如果你要评估它，顺序大概是：
npx @deepseek-ai/dsh web起一个本地实例，看 Web UI 里 agent 的实际交互形态；- 读 architecture 文档 和 development guide，理解 Cordis 的插件模型；
- 挑一个内部 API，写第一个插件，验证「不改内核接系统」这件事在你这里成不成立；
- 如果要做二次开发，
pnpm run dev:web起开发模式，按 AGENTS.md 的约定来。
- 源码：github.com/deepseek-ai/deepseek-harness
- 官网：deepseek.com/harness
- 文档：deepseek-harness.github.io/deepseek-harness
- 许可：MIT，第三方依赖与许可列在
THIRD_PARTY_NOTICES.md
「一切皆插件」不是一句口号，它是一个明确的责任划分：框架只保证装配和运行，能力边界交给插件作者。这个选择让 dsh 在 developer preview 阶段就敢让外部写插件，也让它的稳定性承诺只落在很小的一块内核上。要不要押注它，取决于你信不信「内核越小，活得越久」这条规律。