现在图形界面和命令行的 Agent 已经不少了。Codex、Claude Code、CodeBuddy、Kimi、Qwen，各有各的长处；手头有一两个用顺手的，其实就够干活了。

所以一开始看到 DeepSeek Harness（DSH）时，我也没觉得非试不可。后来因为要测试 WikiSkill，开始用 CodeBuddy 的 CLI，才慢慢意识到：问题不只是选哪个 Agent，而是这些 Agent 能不能放在同一套工作流里用，过程和数据能不能留下来。

DSH 值得关注的地方，就在这里。它想做的不是再造一个 Agent，而是当一个能调度多个 Agent 的入口。

1 先把 Agent 当成工具来用

这个月 CodeBuddy 包月额度没花完，为了不浪费，开始用 CodeBuddy 的命令行 CLI 干点杂活儿。

CodeBuddy 的 CLI 用法和 Codex 很接近，Qwen、Kimi 也有类似工具。

npm install -g @tencent-ai/codebuddy-code
codebuddy login # 此时在浏览器中扫码登录

codebuddy -p "你的问题或指令"
codebuddy -p --dangerously-skip-permissions "你的问题或指令"
codebuddy -p --output-format json "你的问题或指令"

-p 是非交互模式，适合把 Agent 当成一条命令执行。--dangerously-skip-permissions 会自动授权，--output-format json 返回 JSON，方便后面接脚本处理。

复杂的编程任务，还是适合在 GUI 里持续交互。固定场景里，如果一次调用就能拿到结果，直接把 CLI 当成子进程会更方便。尤其是已经有成熟的 Skill、SOP 时，没必要把整个流程绑在某个工具或模型上。

但 Agent 一多，新的问题就出来了：每家都是一个入口、一份会话、一套记忆。想把它们串起来，或者想留下完整过程，往往得自己做适配。

2 会话日志可以慢慢积累成 RAW

CLI 和 GUI Agent 的会话通常会保存在本地用户目录的 sessions 一类位置，大多是明文 JSONL，只是各家的事件格式不同。

这些日志不只是临时聊天记录。只要不手动删掉，理论上可以把自己和不同模型的对话收集起来，慢慢整理成原始材料（RAW）、知识库，或者给后续 Agent 用的定制资料。

这里有两点需要注意一下：

• 日志不等于每次模型调用的完整上下文。比如 Codex 用了 100K token，记录的通常是增量事件和 token 元数据，不会把 100K token 原文全塞进日志。

• 日志很多，噪音也不少。更现实的做法是定时采集 RAW，再清洗、加工和反思。ChatCrystal、ai-memory、llm-iwiki 都在尝试这件事，但还比较早期。如果接上 WikiSkill 来总结，再配一个性价比高的模型，可能会有不错的产出。

CodeBuddy 的 CLI 和图形界面可以共用同一份 memory。DSH 则是把这件事往前推了一步，想把多个 Agent 的执行过程也收进一个入口。

3 DSH 想做什么

如果只运行一个 CLI，直接用 CodeBuddy、Codex 或其他命令行工具就够了。DSH 的价值，在于想把多个 CLI 和 Agent 放到一起调度。

我觉得目前有三个亮点：

• 底层模型可替换。模型适配器是插件，支持 Anthropic、OpenAI、AWS Bedrock、Azure，也支持 OpenAI 兼容端点。

• 可以编排多个 Agent CLI，包括 Codex、Claude Code、TraeCode、OpenCode、Gemini、Cursor、Kimi、Qwen 等。

• Skill、SOP 等工具配置可以写进 AGENTS.md 或 CLAUDE.md，Harness 会自动读取。

换句话说，DSH 更像主控。具体任务交给不同的 Agent，模型也可以按任务替换。

3.1 会话和日志

DSH 的做法很明确：模型能看到的系统提示词、工具调用和结果、子 Agent 调度，都会写进仅追加的会话日志。持久化、恢复、fork、查询、回放、遥测和 UI，都从同一组事件派生。

这正好对应前面那个痛点。理想情况下，主控放在 DSH，执行交给不同 Agent（如 Codex、OpenCode），过程和记忆统一留在 DSH 的体系里。以后就不用分别去每个 Agent 里抓日志，“多源适配”会变成“单源读取”。

不过现在还不能把这件事想得太满。比如 DSH 调 Codex CLI 工作时，Codex 自己的对话未必会被 DSH 完整保存，如何保存需要看你使用的插件的具体实现。

隐私方面，DSH 是本地优先的，默认在本地设备处理和存储；但内测版本默认会上传全部会话日志用于诊断，可以用 DSH_TELEMETRY_DISABLED=1 关闭。

3.2 插件为什么重要

DSH 底层用的是 Cordis 插件系统，核心思路是“一切皆插件”。可以把插件理解成可替换的零件：模型、工具、会话日志、记忆机制、界面，甚至驱动 Agent 运转的主循环，都能换。安装方式如下：

dsh plugin --profile web add <插件包名>

DeepSeek 自带一套基本可用的模块，不装插件也能跑。觉得界面不好，可以换界面插件；觉得记忆机制不合适，也可以自己写一个。它有点像 Obsidian 插件，但能改得更深：Obsidian 主要改界面和编辑体验，DSH 可以一直改到 Agent 的引擎层。

这对爱折腾的开发者挺有价值。很多工具都处在“改源码麻烦，等官方更新又等不起”的阶段。插件把定制从源码里拆出来，只要接口没变，上游升级时，自己写的部分还能继续用。

3.3 Plugin、Skill 和 ACP

Plugin 改的是 Agent 系统本身，Skill 改的是 Agent 完成具体任务的方法。

• Plugin 挂在 DSH 运行时上，可以替换模型、工具、会话日志、记忆机制、界面和主循环，决定 Agent 怎么运转。

• Skill 通常是一份 SOP 文档，加上一些脚本或工具，告诉 Agent 遇到某类任务时怎么做。它依赖 Plugin 提供的基础能力，属于任务层的封装。

简单说，Plugin 管运行方式，Skill 管做事方法。

外部 Agent 接进 DSH 时，还会涉及 ACP。它是主控和子 Agent 之间传递消息、状态和执行过程的一套通信约定。就像 MCP 更偏向于 Agent 调用外部工具，ACP 更偏向于主控调用 Agent。

ACP 提供了过程回流的基础，但环境能不能传过去、结果和过程能不能完整回来，还是取决于具体插件和适配器。插件也不一定比直接调用命令更好用：有些桥接插件目前只能回传结果，看不到执行过程。

4 为什么觉得它值得试

DSH 现在还比较粗糙，插件接口、依赖、沙箱协调和会话回流都要继续磨合。它不是那种装好就能替代现有 Agent 的工具，更像一个“能跑通，但需要调试”的架构尝试。

但这个方向很有意思。很多 Agent 平台都在建自己的围墙，把模型、工具和服务锁在一个体系里；DSH 开源的更像一个车间，模型、工具、Skill、Session、Sandbox、Agent Loop 和 UI 都可以替换。

这从架构能看到的一种可能：它不强制绑定某个模型，而是先把更多 Agent 吸引到同一个入口。以后 Codex、Claude Code 这样的 Agent，也可能成为 DSH 的启动器；DeepSeek 的模型和 API，则有机会获得更多分发入口。

对我来说，重点不是选出一个永远最强的 Agent。换模型、换工具之后，自己的数据和工作过程还能留下来，这件事更重要。

---

还有更多细节推演和展开，写在文章里太过抽象，我以问答的形式录成了 B 站视频，可扫码观看。