DeepSeek Harness 很强，但我想给它一个真正的项目工作台

最近我一直在折腾一个东西，叫 Harness Workbench。

开源地址在下面，一句话让你的agent帮你安装。

• 开源地址：https://github.com/yeah529/Harness-Workbench

做这个的起因也很简单。DeepSeek 把 Harness 开源之后，我花了一段时间研究它。越看越觉得，这套框架有点意思：模型、工具、会话、权限、子 Agent，甚至界面，都可以通过插件组合。开发者不用为了加一个功能，把整套 Agent 重新造一遍。

可一拿它做项目，我很快遇到了另一个问题。

一个会话能解决眼前的任务，项目却不会在一次对话里结束。今天讨论需求，明天改代码，后天补资料，中间还可能冒出五个待办、三个新会话和一堆“我记得之前聊过，但到底在哪个窗口”的历史记录。

会话越来越多，AI 也越来越能干，我反而开始找不到东西了。

所以，我给 DeepSeek Harness 做了一个个人工作台。视觉上借了一点赛博朋克的味道，里面装的却是很朴素的东西：项目、会话、知识、待办和自动化。

如果你只想先看一句话版本：

DeepSeek Harness 负责让 Agent 实际运行，Harness Workbench 负责让这些运行结果围绕一个项目长期留下来。

下面展开聊聊。

一、先说清楚，DeepSeek Harness 到底是什么

第一次看到 Harness 这个词，很多人会把它理解成“又一个 AI 聊天工具”。其实它更接近 Agent 的运行底盘。

模型本身负责理解和生成。可一个 Agent 想在真实环境里干活，还需要有人处理这些事情：

• 这次该调用哪个模型？
• 模型可以使用哪些工具？
• Bash、文件、搜索和浏览器该怎么接入？
• 工具调用要不要审批？
• 一轮任务失败后如何重试？
• 会话怎样保存、恢复和追踪？
• 子 Agent 怎么创建，谁负责结束它？

这些围在模型外面的运行机制，就是 Harness 的价值。

DeepSeek Harness 的设计思路很直接：Everything is a plugin。 模型、工具、skill、Session、Sandbox、存储、Agent Loop、调度和 UI，都可以作为插件挂到 Cordis 这棵运行树上。

我用一个不太严谨、但容易理解的比喻：

DSH 还有一个我比较喜欢的设计：模型看到的内容会写入追加式 Session 日志。用户消息、模型输出、工具调用、工具结果和上下文注入，都能沿着同一条事件流追踪。界面里的 Trajectory，本质上就是把这段过程摊开给你看。

这意味着恢复会话、回放过程、查看工具做过什么，不需要再猜“模型当时可能看到了什么”。日志就是依据。

DSH 目前还提供 Standard、Code、Minimal 和 Creator 等不同运行方式。你可以把它们理解成不同的 Agent 配置：有的工具齐全，有的只保留最小能力，有的方便开发和试验插件。背后的模型可以换，工具和运行方式也能换。

听起来已经很完整了，对吧？

确实完整。但它解决的是“Agent 如何运行”，我想继续解决“项目如何长期推进”。

二、AI 会话很好用，项目却很容易聊散

我最早也觉得，多开几个会话就行了。

一个会话写需求，一个会话研究技术，一个会话处理 Bug，再开一个会话做发布检查。每个窗口单独看都挺聪明，合在一起就有点像四位能力不错、但从不交接工作的同事。

慢慢让我不舒服的，主要是四件事。

1、会话缺少项目归属

聊天列表通常只按时间排列。项目做久以后，今天的技术讨论、昨天的资料分析和上周的 Bug 修复混在一起。标题稍微取得含糊一点，过两天自己都认不出来。

2、资料需要反复解释

产品文档、技术方案、会议记录和数据表散落在文件夹里。每开一个新会话，都得重新告诉 AI：项目背景是什么、哪些资料可信、上一轮已经做了哪些决定。

复制粘贴久了，人会产生一种奇怪的错觉：好像我才是那个负责上下文管理的 Agent。

3、对话结束后，下一步容易消失

AI 在结尾经常会列出“接下来可以做什么”。看起来很完整，窗口一关，也就完成了它短暂而体面的使命。

项目需要的是：这些下一步能进入待办，有截止时间，明天还能继续推进。

4、自动任务与项目历史断开

普通定时提醒只能告诉你“该做事了”。我希望时间到了以后，Agent 能真的执行任务，并把过程保留成一个可以继续追问、复盘和重试的会话。

这几个问题放在一起，我想做的东西就逐渐清楚了：一个围绕项目组织 Session 的控制面。

三、Workbench 没有重写 DSH，它只加了一层项目组织

做这类工具很容易犯一个错误：觉得原来的聊天界面不够用，于是另写一套消息、附件、模型状态和工具调用。

刚开始看起来很自由，后面就要同时维护两套 Session、两套上传逻辑和两套状态同步。原生能力一升级，外面的壳先裂开。（这类坑，产品经理看多了也会形成肌肉记忆。）

所以 Harness Workbench 的边界一直很明确：

容器组织上下文，DSH Session 负责执行。

消息、流式输出、模型选择、工具、审批、附件、重试和 Trajectory，继续交给 DSH。Workbench 只管理项目、会话范围、知识芯片、待办、定时任务和总结。

进入项目后，界面分成三个区域：

1. 左侧是全局导航、最近会话和设置；
2. 中间保留完整的 DSH 原生会话；
3. 右侧放这个项目自己的待办、自动化和关联知识。

这里没有新造一套“阉割版聊天”。项目会话仍然可以切模型和推理等级，查看工具过程，处理审批，上传文件，停止、重试和 steer，也能看到 Subagent 的活动。

Workbench 只是给同一种 DSH Session 划分了三种工作范围：

三种范围底下跑的仍然是完整 Session。差别只在于这次工作的边界，以及它能继承哪些上下文。

新会话还采用延迟创建。打开空白输入页时不会马上产生一个 Session ID，第一条消息真正发出后才创建。看似是个小细节，却能避免“点开看了一眼，历史列表里就多出一个空会话”这种数字垃圾。

四、知识芯片：让资料可以插到不同项目里

项目除了代码和聊天，还有大量资料。

比如做一个 AI 产品，可能同时需要需求文档、竞品分析、接口说明、会议纪要和历史方案。它们不一定只属于一个项目，也不应该每次提问都重新上传。

所以我把知识库做成了“知识芯片”。

一个知识芯片可以放多份文档，也可以同时关联多个项目。解除关联只代表这个项目暂时不用它，不会顺手把共享资料一起删掉。

文件进入知识芯片后，会经过解析、分块、Embedding 和向量写入。页面会显示每个文件走到哪一步，失败后也能单独重试。目前支持常见文本、Markdown、HTML、Office 文档，以及多种代码文件。

默认 Embedding 走本机 Ollama：

model: qwen3-embedding:0.6b
dimensions: 1024

如果已有 OpenAI-compatible Embedding 服务，也可以在设置里替换模型、Endpoint 和向量维度。凭据仍然交给 DSH 的 credentials 管理，不写进浏览器存储。

我不太喜欢那种“知识库在后台神秘工作”的体验。所以 Workbench 会把注入的 knowledge context 放进 Trajectory，回答后再附上去重的来源，原始文档也能打开或下载。

至少当 AI 一本正经地说错话时，我们知道该先查哪份资料，而不是和它进行一场哲学辩论。

除此之外，在输入框里键入 @，还可以主动组合三类上下文：

• Workspace 文件；
• 当前可用的知识芯片；
• 其他 Workbench 会话。

这一步解决的是“我知道资料在哪里，也知道要把哪段历史带进来”。比让系统无限扩张上下文更可控。

五、让 Agent 回答完以后，还能继续干活

如果 Workbench 只负责整理会话，它顶多算一个比较好看的档案柜。

项目每天还会产生下一步：修一个 Bug、补一份说明、晚上生成总结，或者下周一重新跑一次检查。因此我又加了待办、定时 Agent 和每日自动化。

待办本身不神奇，重点是它和项目会话连在一起。系统可以根据当天的用户消息、最终回答和新增知识，生成次日事项；工具参数、Thinking、协议文本和报错不会被当成待办保存。

定时任务也不是“到点弹个提醒”。规则到期后，Workbench 会启动一个真正的 DSH Agent：

• 第一次运行时创建项目会话；
• 后续运行继续使用同一会话的上下文；
• 继承 DSH 原生模型、Agent Preset 和工具；
• 成功或失败都会留下 Session 与 Trajectory。

目前可以设置一次性、每日、每周和每月任务。比如每天收集项目进展、每周检查依赖更新，或者固定时间整理一份研究简报。

同一个项目还可以在晚上生成每日总结和次日待办。这里我特意限制了输入范围：只读取当天的项目会话和新增项目知识，不把无关的知识问答、工具噪声和错误信息混进去。

我想要的不是一段“今日工作十分充实”的 AI 周报，而是一份第二天真的能接着用的记录。

六、模型、Subagent 和 Codex，继续交给 DSH

Workbench 没有绑定某一个生成模型。模型列表、Provider 和凭据仍由 DSH 管理。你可以继续使用 DeepSeek 的模型，也可以按自己的环境接入其他 Provider。

DSH 的 Agent Preset 和 Subagent 能力同样保留。可续聊的子 Agent 可以继续发送消息，一次性子 Agent 则保持只读，不在界面上假装它支持底层不存在的多轮能力。

我还加了一个可选的 Codex 接入入口。

Codex 桥接默认关闭，只有用户主动扫描时才读取本机登录缓存。普通启动不会读取 ~/.codex/auth.json。只有在设置里点击“扫描并接入 Codex”，或启动时明确开启选项，Workbench 才会把本地 Access Token 导入 DSH credentials。浏览器端只看到脱敏状态，看不到 Token 内容。

这里也得把边界说清楚：这是对本地 Codex 登录缓存的可选兼容，不是 OpenAI 提供的公开认证 API。缓存格式以后发生变化，适配代码也可能要跟着更新。

七、谁适合用，谁暂时不用折腾

如果你只是偶尔问 AI 一个问题，开完即走，原生 DSH 已经足够。额外安装一套项目系统，反而多了维护成本。

Harness Workbench 更适合下面这些情况：

• 同一个项目会持续几天甚至几个月；
• 经常在多个会话之间切换；
• 项目依赖一批需要反复查阅的文档；
• 希望 Agent 定时执行任务，而不只是提醒；
• 在意工具过程、来源和失败记录能不能追溯；
• 想保留 DSH 原生能力，又不想自己再拼一套项目管理界面。

截至写稿时，需要先从 GitHub 源码安装。公共 npm Registry 里还没有这个包，所以别直接照着包名执行全局安装——现在只会收获一个很干脆的 404 Not Found。

git clone https://github.com/yeah529/Harness-Workbench.git
cd Harness-Workbench
npm ci
npm run build
./scripts/install.sh
node ./bin/dsh-workbench.js

我这次发布的 Workbench 0.1.1 对应 DeepSeek Harness 0.1.1-rc.2，需要 Node.js 22.5+。如果使用默认本地 RAG，还需要准备 Ollama 和 qwen3-embedding:0.6b。

截至写稿时，DSH 仍处于开发者预览阶段，公开接口还可能变化。Workbench 也只保证与当前锁定版本的接口兼容。我不打算把这一点藏在安装说明的小字里——新框架好玩，但升级前先验证，比半夜修环境有意思得多。

数据边界也值得注意。Workbench 的 SQLite、上传文件和向量索引默认放在本机；文档解析与默认 Embedding 也在本机进行。但只要你使用远程生成模型，问题、检索出的上下文、总结和待办内容仍可能发送给对应 Provider。涉及不能离开本机的资料，别因为界面上写了“Local-first”就放松判断。

写在最后

做完这一版以后，我对“Agent 工作台”的理解也发生了一点变化。

它不需要替模型变得更聪明。它要解决的是那些看起来不够性感、实际每天都在发生的问题：资料放哪、会话属于谁、下一步是什么、定时任务有没有真的执行、失败以后还能不能找到现场。

DeepSeek Harness 给了我一套可以组合的 Agent 运行框架。Harness Workbench 做的事情，是把这套能力放回项目里，让一次次对话慢慢积累成可以继续工作的系统。

至于赛博朋克风格……主要是我觉得，既然每天都要面对待办和 Bug，至少工作台可以长得像是要去夜之城拯救世界，而不是准备填下一张 Excel。

项目还会继续迭代。现在这版已经能让我少翻几个会话、少复制几遍背景，也让那些原本躺在聊天记录里的下一步，真的开始往前走。

这就够它先“觉醒”一阵子了。