用 DeepSeek Harness 二开你自己的 WorkBuddy：Agent 运行时作为平台底座的实践路径

适用场景 / 应用范围：本文面向「想基于开源 Agent 框架构建自有智能应用」的架构师与开发者。核心观点：Agent 框架的价值不止于「写插件给 agent 用」，更在于把整个 agent 运行时当成自己产品的底座------类比当年基于 Spring Boot 搭业务系统、基于低代码引擎搭表单应用。文章以腾讯 WorkBuddy 为参照，逐模块拆解「用 dsh 做出一台差不多的 WorkBuddy」需要什么样的二开，最后给出「智能数据工作台」的个人实践与开源计划。

一、问题：Agent 框架的二开，我们只解锁了 10%

2026 年的 Agent 生态有个显著现象：框架越来越多，教程越来越卷，但九成内容停留在同一个层次------教你怎么给某个框架写一个插件。

以 DeepSeek Harness（dsh，v0.1.0-rc.5，基于 Cordis 的万物皆插件架构）为例：

官方文档铺开就是「怎么写一个 tool 插件」「怎么写一个 provider 插件」「怎么声明一个 ctx.* 能力缝」
社区讨论也集中在「给 agent 加个工具」「接个新数据源」

这当然有价值，但它只是框架使用者的视角 。很少有人从平台所有者的视角问一个问题：

能不能不把 Agent 框架当成「一个 agent」，而是当成「一个可以承载我自己产品的运行时」？

类比一下：

低代码时代：低代码引擎不只是「做表单的工具」，它是「应用运行时底座」------你基于它二开，生成自己的行业应用。
微服务时代：Spring Boot 不只是「写接口的框架」，它是「业务系统底座」------你基于它二开，构建自己的业务平台。
Agent 时代：dsh 这类框架，同样应该成为「智能应用底座」------你基于它二开，构建自己的智能工作台/智能枢纽/智能平台。

从传播度上看 WorkBuddy特别火 ，本质上就是这条路线的商业验证：以 Agent 运行时为底座，挂载办公领域的业务能力。本文将拆开它，看看用开源的 dsh 做出一台「差不多的 WorkBuddy」，到底需要什么样的二开。

二、约束：为什么这个想法现在才成立

在展开方案之前，先明确几个约束，它们决定了「以 agent 为底座」不是一句口号：

dsh 是 developer preview。README 第一行就写着「THERE WILL BE COMPATIBILITY-BREAKING CHANGES」。把它当生产底座，必须接受「版本锁死 + 隔离升级」的策略，不能指望 API 稳定。
Agent 框架的能力边界在「编排」，不在「业务领域」。它给你的是：agent 循环、工具注册表、会话事件日志、审批/沙箱、定时与工作流、SDK 驱动。它不给你：办公语义、企业知识库、连接器生态、业务前端。这些必须自研。
智能平台的核心资产是「可审计、可追溯」。好在这个约束 dsh 天然满足------它的 Session 是 append-only 事件日志，LLM 消息历史都是从日志派生的，这恰好是操作审计与业务溯源想要的底座。
受限环境部署。我们所在的环境强调内网/资源受限/全离线，这意味着运行时必须可静态分发、可离线运行------dsh 的 headless 模式无服务器无端口，SDK 通过 stdio JSON-RPC 驱动，天生适合。

三、架构级描绘：运行时底座到底提供什么

把 Agent 框架当底座，首先要看清它作为「运行时」提供了哪些可依赖的契约。以 dsh 为例，从架构级别拆解：

javascript 复制代码

┌─────────────────────────────────────────────────────┐
│              你的业务应用（领域层）                    │
│   办公能力 / 数据能力 / 生产模型 / 业务前端（自研）     │
├─────────────────────────────────────────────────────┤
│             Agent 运行时底座（dsh）                   │
│  ┌─────────┬──────────┬──────────┬───────────────┐  │
│  │ 规范契约  │ 集成能力  │ 扩展机制  │ 运维与安全      │  │
│  │ Service │ SDK驱动  │ 插件挂载  │ 会话事件日志     │  │
│  │ 声明式   │ JSON-RPC │ 工具注册  │ 审批/权限/沙箱   │  │
│  │ inject  │ headless │ provider │ 定时/工作流      │  │
│  └─────────┴──────────┴──────────┴───────────────┘  │
├─────────────────────────────────────────────────────┤
│        模型适配层（DeepSeek 系 / 可替换）              │
└─────────────────────────────────────────────────────┘

3.1 规范契约：不是 API 是「协议」

运行时底座和普通 SDK 的本质区别，是它给出的不是「函数调用」，而是可组合的规范：

Service 声明式依赖（inject） ：插件声明 inject: ['tools', 'sessions']，运行时按依赖关系装配------你的业务模块可以声明「我需要 agent 循环」，而不是手动拼装。
事件协议（Event）：emit / waterfall / parallel / serial 四种派发模式，业务可以「观察」agent 的行为（审计）、「包装」agent 的结果（增强）、「拦截」agent 的请求（策略）。
可逆效果（Effect）：所有注册都是可回滚的------业务模块卸载时，它注册的工具、监听器、prompt 段自动消失，不会污染运行时。

这套规范意味着：你的业务逻辑可以「长」在运行时上，而不是「绑」在运行时里。

3.2 集成能力：三种嵌入姿势

姿势	方式	适用场景
A. 工具注入	业务能力注册为 `ctx.tools` 的工具	给 agent 加「手」------让 agent 能调你的查询引擎、能操作你的业务系统
B. Provider 扩展	业务实现能力缝的 provider	给 agent 换「传感器」------新的数据源、新的模型、新的搜索后端
C. SDK 驱动	外部进程通过 JSON-RPC/stdio 驱动 headless 运行时	你的产品是主框架，agent 是「大脑」------最推荐的二开姿势

3.3 扩展机制：能力缝（Seam）

dsh 的插件系统把「可扩展点」显式化为一组能力缝：ctx.tools（工具）、ctx.llm（模型）、ctx.web（搜索/抓取）、ctx.shell（命令）、ctx.sessions（会话）、ctx.subagents（子代理）、ctx.schedule（定时）......每个缝都是注册表 + 选择器：注册多个 provider，运行时按配置挑选。

这是「底座」的典型特征：核心稳定、边界清晰、扩展点显式化------和 Spring 的 Bean 容器、低代码引擎的组件库是同一个思想。

四、用 dsh 二开一台「差不多的 WorkBuddy」

4.1 WorkBuddy 是什么

腾讯 WorkBuddy是企业级 AI 智能工作平台，核心能力五大模块：

模块	能力
自然语言交互	对话式指令操作办公软件（创建文档、安排日程、查询数据）
AI Agent 编排	创建自定义 Agent，串联多步任务（收集周报→汇总表格→发送邮件）
企业知识库	对接内部文档/CRM/ERP，私有数据问答与生成
跨应用自动化	连接腾讯文档/企业微信/会议，审批、提醒、流程触发
多终端适配	PC + 移动端，与企业微信深度集成

它的本质：以 Agent 运行时为底座 + 办公领域能力挂载。下面逐模块看 dsh 怎么二开实现。

4.2 逐模块二开对照：dsh 版 WorkBuddy

WorkBuddy 模块	dsh 实现方式	二开工作量
自然语言交互	dsh 的 agent 循环天然支持多轮对话；`ask_user_question` 工具做澄清；前端自建聊天 UI，通过 SDK 连 headless 运行时	⭐ 小（底座已有）
AI Agent 编排	`ctx.subagents` 子代理 + `workflow` 插件编排多步任务；`todo` 工具做任务管理；agent 循环自动处理「收集→汇总→发送」的串联	⭐ 小（底座已有）
企业知识库	自研 `knowledge` 插件：文档解析 → 向量化 → 存向量库；注册 `retrieve` 工具让 agent 能 RAG 检索；知识权限对接你的认证体系	⭐⭐⭐（领域自研）
跨应用自动化	`schedule` 插件做定时触发；`workflow` 做流程编排；业务连接器写成工具插件（如 `send_wecom`、`create_doc`、`query_crm`）------这正是「工具注入」姿势	⭐⭐（写连接器）
审批节点	dsh 自带 `interaction/approval` 能力 + `user-questions` 缝------agent 到审批节点暂停，等人确认再继续	⭐ 小（底座已有）
多终端	headless + SDK 无 UI 依赖：Web/移动端/CLI 都通过 JSON-RPC 驱动同一个运行时	⭐ 小
审计与安全	Session 事件日志天然记录全部操作；权限预设（read-only / workspace-write / danger-full-access）做分级控制	⭐ 免费获得

核心结论：WorkBuddy 的「Agent 部分」几乎全是 dsh 底座现成的，你要二开的是「业务连接器」和「知识库」两个领域模块。

4.3 最小可跑示例：一个「会查数据的 WorkBuddy」

用 SDK 驱动一个 headless agent，注册一个查询工具，就是 WorkBuddy 的最小雏形：

python 复制代码

from deepseek_harness import DeepSeekHarness

with DeepSeekHarness(
    model="deepseek-v4-flash",
    cwd="/workspace",
    cordis="examples/jsonrpc-agent/minimal.cordis.yml",
    runtime_bin="/path/to/packaged-bin.js",
) as harness:
    result = harness.run("查一下上周的销售数据，汇总成表格")
print(result.final_response)

工具插件（把业务能力挂到 agent 上）：

typescript 复制代码

import { defineTool } from '@deepseek-ai/dsh-tools'

export const name = 'tool-sales-query'
export const inject = ['tools']

export function apply(ctx: Context): void {
  ctx.tools.register(defineTool({
    name: 'query_sales',
    description: '查询销售数据（时间范围、区域）',
    parameters: {
      from: { type: 'string', required: true },
      region: { type: 'string' }
    },
    async execute(args) {
      return await querySalesDB(args.from, args.region)  // 你的业务查询
    }
  }))
}

agent 接到「查销售数据」→ 调 query_sales 工具 → 拿到结果 → 组织成表格回答。这就是 WorkBuddy 的对话式数据查询，半小时能跑通。

4.4 同一底座，不同领域

WorkBuddy 是「办公」，同样的 dsh 底座可以挂：

企业生产经营智能枢纽：生产数据（设备 IoT、MES、能耗）→ 智能体实时分析 → 异常自动报警 → 生成处置建议 → 审批后下发执行。领域侧提供设备/产线/工单模型，agent 侧复用同一套循环。
供应链智能枢纽：库存/订单/物流 → 智能体推演 → 补货建议 → 联动 ERP。
智能数据工作台（个人案例，见下节）。

底座不变，变的是「挂载的领域模块」------这正是运行时底座最大的价值。

五、个人案例：智能数据工作台（即将开源）

以我自己的实践为例，说明这条二开路径的具体落地。目标是构建智能数据工作台：数据源管理、实体管理、数据血缘、任务管理、智能查询、ChatBI。

架构：产品为核 + dsh 为 Agent 引擎

javascript 复制代码

┌─────────────────────────────────────┐
│  智能数据工作台（我的产品）            │
│  ├─ 数据源 / 实体 / 血缘 / 任务（自研）│
│  ├─ 前端 UI                          │
│  └─ Agent 网关 ──JSON-RPC/SDK── dsh  │
│      （智能查询 / ChatBI 由 dsh agent 处理）│
└─────────────────────────────────────┘

工作台通过 dsh 的 Python SDK / JSON-RPC（stdio）起一个 headless agent 运行时，把「自然语言 → 规划 → 工具调用 → 回答」的整段智能逻辑托管给 dsh，业务侧只负责数据与界面。

为什么选「产品为核」而非「dsh 为核」

领域边界干净。数据源管理、血缘、调度是数据工程问题，塞进 dsh 插件系统只会让两边都变复杂。业务归业务，agent 归 agent。
隔离升级风险。dsh 是 preview，产品为核下升级 dsh 只影响 Agent 网关；dsh 为核下升级等于重写产品。
复用最值钱的能力。要的不是 dsh 的表单和按钮，而是它的 agent 循环、工具执行管道、事件溯源日志、审批沙箱------这些恰好都是通过 SDK 暴露的。

核心壁垒：业务工具接入

工作台自己实现「多源联邦查询引擎」（DuckDB 插件化联邦：postgres_scanner / mysql_scanner / httpfs + 自研 HTTP API 表函数），然后把它注册成 dsh 的 tool 插件：

typescript 复制代码

import { defineTool } from '@deepseek-ai/dsh-tools'

export const name = 'tool-duckquery'
export const inject = ['tools']

export function apply(ctx: Context): void {
  ctx.tools.register(defineTool({
    name: 'duckquery',
    description: '对多数据源执行 SQL 查询（http/file/s3/jdbc），返回结果集',
    parameters: { sql: { type: 'string', required: true } },
    async execute(args) {
      return await runDuckQuery(args.sql)
    }
  }))
}

这一层就是「智能数据工作台」和普通 agent 的分水岭：agent 的大脑是通用的，工具是数据专属的。

免费获得的审计与血缘

sql 复制代码

用户提问 "上月华东区销售额"
  → dsh agent 规划
  → 调 duckquery 工具执行 SQL
  → 引擎返回结果集
  → agent 组织自然语言回答
  → 整个过程写入 append-only SessionEvent 日志

每次 NL→SQL→结果→决策的链路天然留痕，后续做「查询级血缘」和操作审计时不需要额外埋点------dsh 的事件日志就是现成的数据源。

开源计划

这个项目我会在近期开源：以 dsh 为 Agent 引擎 + 自研多源联邦查询层 + 事件日志血缘底座，三件套拼成一个「会思考、可追溯、能调度」的数据平台雏形。开源后欢迎大家在此基础上挂载自己的领域模块------这本身就是「运行时底座」理念的实践：核心稳定、边界清晰、扩展点开放。

六、踩坑记录

SDK runtime 找不到 ：Unable to locate the bundled DeepSeek Harness SDK runtime------SDK 默认要「捆绑运行时」，源码构建必须显式传 runtime_bin 或 launch_args_override。
后台 shell 没有 pnpm/node ：fnm 管理的 node 在 multishell 路径里，cron/后台进程继承不到，必须显式 export PATH=.../fnm/node-versions/v22.23.1/installation/bin:$PATH。
沙箱默认拦截 bash ：headless 无审批通道，workspace-write 模式下 bash 直接被拒（提示装 bubblewrap/Landlock）；二开跑真实任务要显式 DSH_PERMISSION_MODE=danger-full-access，但这意味着把沙箱责任交还给产品层，必须自行补权限控制。
插件类名大小写是硬约束 ：扩展生成器把扩展名 linuxinfo 转成 LinuxinfoExtension，类名写 LinuxInfoExtension 会静态链接失败------生成器与源码的命名必须逐字符一致。
preview 版本升级成本：0.1.0-rc.x 之间 API 会变（SDK 的 runtime 契约、插件的 inject 签名），二开一定要锁版本、锁源码、留升级窗口。

七、总结

Agent 框架的二开价值，不在「多写几个插件」，而在「能不能把一个 agent 运行时，像数据库、像消息队列、像低代码引擎一样，当成平台的组成部分」。

腾讯 WorkBuddy 已经证明了这个方向------「AI Agent 办公新范式」的本质，就是以 agent 运行时为底座，挂载办公领域的业务能力 。而本文的核心在于：用开源的 dsh，你也能二开出一台差不多的 WorkBuddy------它的自然语言交互、Agent 编排、审批、审计全是底座现成的，你要写的只是「业务连接器」和「知识库」两个领域模块。

同样的底座可以挂办公（WorkBuddy）、挂 CRM（Agentforce）、挂运维（ServiceNow）、挂生产经营（智能枢纽）、挂数据（我的工作台）。底座不变，变的是「挂载的领域模块」。

dsh 在这件事上有几个难复制的底子：

万物皆插件------业务工具、数据源 provider、审批策略都是可替换的挂载点；
事件溯源 Session------agent 的每一次思考与工具调用都是 append-only 日志，天然满足审计与溯源；
headless + SDK------无服务器、stdio 驱动，受限环境下可以像调用本地库一样把 agent 嵌进自己的产品。

技术会迭代，dsh 的 API 会变，但「以 agent 运行时为平台底座」这个思路，会是未来几年智能应用构建的主流姿势之一。早一步踩坑，就早一步拥有把 agent 变成基础设施的能力。