DeepSeek Harness 解读(四):minimal 真的是最小 Agent 吗?
这是 DSH 系列的最后一篇。我们之前问过:minimal preset 只有两个工具,它是否已经是最小化 Agent?答案是:对模型可见能力来说接近最小,对真实运行时来说并不是。
DSH 的四种 preset 不是四个产品
DSH 当前把 Agent 能力组合成几类 preset:
standard 完整 Coding Agent
ptc TypeScript Code Mode / PTC
minimal persistent bash + str_replace_editor
creator 运行时检查和插件实验
它们不是四个独立程序,而是同一个 Cordis Runtime 上的不同能力组合。
这一区分很重要:preset 决定的是某个 Agent Scope 可以看到和使用哪些能力,而不是重新启动一套完全不同的 Agent 实现。
minimal 为什么看起来很小
DSH 的 minimal 配置对模型暴露的主要能力只有:
1. persistent bash
2. str_replace_editor
同时它关闭或抑制了很多额外上下文:
- 不加载完整 Coding Agent 的复杂工具集;
- 不注入运行时上下文;
- 不使用默认的复杂压缩能力;
- 使用固定、短的系统提示;
- 让 Bash 在多个 step 之间保持状态。
相关实现可以直接看 minimal agent preset 和 minimal runtime 设计记录。
DeepSeek Harness 解读(三):会话、记忆与上下文压缩
这是 DSH 系列的第三篇。很多 Agent 都声称支持“记忆”,但这个词往往同时指会话保存、上下文压缩、跨会话召回和目标续跑。DSH 的有趣之处,是把这些问题明确拆开了。
先把“记忆”拆成五件事
Session Persistence 保存发生过什么
Context History 决定模型当前看到什么
Compaction 压缩当前可见历史
Long-term Memory 跨会话主动召回知识
Goal State Agent 还要继续完成什么
DSH 内置支持前四项中的一部分:它强内置会话事件日志和上下文压缩,Goal 是持久任务状态;真正的语义长期记忆则通过外部 Provider 或 MCP 接入。
1. Session Persistence:日志才是事实来源
DSH 不把 messages[] 当作唯一状态,而是将一次交互保存为 append-only 的类型化事件:
turn/start
user/message
assistant/chunk
assistant/message
tool/call
tool/result
step/end
turn/end
模型的历史消息由这些事件重新派生。这样可以让 UI、Replay、Fork、Telemetry 和恢复逻辑共享同一份事实来源。Session 文档
持久化层通过 ctx.sessionPersistence 抽象出来,目前支持 JSONL 和 SQLite 后端。写入采用批处理和 flush checkpoint;崩溃恢复时,DSH 会识别没有关闭的 turn,并以 interrupted 结束它,而不是粗暴截断日志。Persistence 文档
这是一种“事实优先”的设计:
原始日志尽量完整
模型上下文可以变化
历史投影可以重新计算
2. Compaction:压缩可见表面,不删除原始历史
上下文接近模型窗口时,DSH 不直接删除旧事件,而是选择一段旧的 surface,调用 summarizer 生成摘要,然后追加一个 checkpoint:
DeepSeek Harness 解读(二):内核不是 Agent,而是 Cordis 运行时
上一篇讨论了 DSH 为什么不应该被简单看成“另一个 Codex”。这一篇进入源码架构:DSH 的真正内核不是一个大而全的 Agent 类,而是一套用来组装 Agent 的插件运行时。
先给一个简化模型
Runtime = Profile + Bundle + Patch + Plugin
Agent = Scoped Context + Session + Agent Driver
Turn = LLM Request + Tool Pipeline + Durable Events
DSH 官方文档对自己的描述很直接:模型适配器、工具注册表、会话日志和 Agent Loop 都是插件;没有一个需要被所有扩展修改的 privileged core。DSH Architecture
这里的“没有核心”不是说系统没有基础代码,而是说:基础服务存在,但业务能力没有被绑死在一个不可替换的中心对象里。
Cordis:Context 是服务仓库
Cordis 是 DSH 底层的插件框架。每个插件可以向共享 Context 注册服务:
ctx.llm 模型适配器
ctx.sessions 会话存储
ctx.tools 工具注册表
ctx.systemPrompt Prompt 组装
ctx.fs 文件系统能力
ctx.sandbox 沙箱能力
ctx.agents Agent 注册表
插件不直接依赖具体实现,而是通过 ctx.<key> 找到能力;依赖通过 inject 声明,加载顺序由服务依赖关系决定。插件注册的工具、Prompt、Provider 和事件监听器都会通过 effect 安装,并在插件卸载时撤销。Cordis Primer
DeepSeek Harness 解读(一):它不是另一个 Codex
这是一组关于 DeepSeek Harness(简称 DSH)的源码级解读。第一篇先回答一个很现实的问题:市场上已经有 Codex、Claude Code,为什么还需要 DSH?
先说结论
如果需求是“给我一个现在就能写代码的 Agent”,普通用户没有太多理由选择 DSH。Codex 和 Claude Code 的优势在于完整的产品体验:安装、权限、上下文、编辑、测试、恢复和日常交互都已经被包装好了。
DSH 的合理定位不是“另一个更好用的 Codex”,而是:
一个可编程、可替换、可嵌入、可自托管的 Agent Runtime,同时提供一个 DeepSeek 原生的 Coding Agent。
这两个定位看起来相近,实际上面对的是不同买家。
三种产品不是同一层
可以把 Agent 市场拆成三层:
模型层:DeepSeek / OpenAI / Anthropic / 自建模型
运行时层:DSH / OpenAI Agents SDK / Google ADK / LangGraph / Pi
产品层:Codex / Claude Code / 企业内部 Agent 产品
Codex 和 Claude Code 的核心目标是让用户完成任务。它们当然也在开放 Skills、MCP、SDK 和企业部署能力,但用户不需要先理解运行时内部结构,就可以开始工作。Codex 开发者主页、Claude Code CLI 文档
DSH 的重点则是把运行时本身暴露出来:模型适配器、工具注册表、Session Log、Agent Loop、沙箱和审批都可以通过插件和配置组合。官方架构文档甚至明确写道,产品中的这些部分都属于插件,而不是一个必须修改的特权核心。DSH 架构文档