Agent Harness · Plugins · Multi-Agent Orchestration

DeepSeek Agent Harness：把 Coding Agent 变成可插拔工作台

英文原题：I Tested DeepSeek Agent Harness Against Codex and Claude Code。Owain Lewis 用一次真实的代码审查和并行修 bug 演示，比较 DeepSeek Agent Harness、Codex 与 Claude Code 的工作形态差异。

频道：Owain Lewis 时长：13 分 27 秒播放量：18,964 上传日期：2026-08-22

一、问题引入：为什么还需要另一个 Agent Harness

这支视频表面是在试用 DeepSeek 的 Agent Harness，真正讨论的是一个更实际的问题：当一个开发者每天同时推进多个项目、几十个任务，并且想把 Claude Code、Codex、本地模型或云端 runner 混在一起用时，单一终端或单一聊天窗口很快会变成管理瓶颈。Owain 的判断很直接：模型能力之外，谁能把任务、权限、工具、轨迹和插件做成可编排系统，谁就更接近下一代开发工作台。

他先展示自己写的自定义看板扩展。这个看板不是独立项目管理工具，而是运行在 Harness 里的插件 UI：能看到正在执行的任务、归档工作、子代理调用、token 用量、等待人工处理的项目，以及是否按项目分组。这里的重点不是“看板好看”，而是 Harness 允许开发者把代理运行状态投射成自己的工作界面。

核心判断：Agent 的竞争不只在模型回答质量，也在于你能否把它接进自己的任务系统、审查流程和多代理调度方式。

这与 Codex、Claude Code 的默认体验形成对比。Codex 更像成熟的工程代理和任务执行环境，Claude Code 更贴近终端开发者习惯；DeepSeek Agent Harness 则把“代理本身可以被插件化改造”放到台前。视频后半段也承认它并不是全面胜出，特别是在成本模式和现阶段可靠性上，Owain 仍然更偏向订阅制的 Codex。

二、核心概念解释：Harness、插件、模式和轨迹

1. Harness 不是模型，而是模型周围的操作系统

视频里的 Harness 可以理解成一层代理运行时：它把模型 provider、工具权限、任务会话、UI 扩展、agent loop 和执行轨迹组织起来。用户一开始需要 DeepSeek API key，但后续可以切换不同模型 provider，例如 DeepSeek、OpenRouter、本地模型或其他接口。模型是“推理引擎”，Harness 决定这个引擎能看到什么、能调用什么、如何并发工作、如何被人观察。

2. 插件化 UI 是它最突出的差异

Owain 反复强调“everything is a plug-in”。这句话在视频中不是抽象口号：他展示的看板插件能把 agent session、任务状态、归档项、token 统计和等待人工确认的事项合到一个界面里。相比之下，如果在 Claude Code 或 Codex 中实现同样界面，通常需要另写一个外部应用，再通过 API 或本地状态去接入。

3. 模式决定工具边界

Harness 提供不同运行模式：标准模式适合大多数日常任务；minimal 模式只保留很少工具；PTC 代表 programmatic tool calling，让代理写代码来定制自己的工具调用路径；creator 模式用于交互式构建插件和扩展。这里的工程意义是：权限和工具不是固定开关，而可以被组织成不同的工作画像。

4. 轨迹视图是 Agent Debugger

视频展示了 trajectory view，用来查看每一步工具调用、搜索历史和执行过程。对做过 Langfuse、OpenTelemetry 或 agent tracing 的工程师来说，这就是代理工作流的可观测性入口。它可以回答“为什么这个任务跑了很久”“哪个子代理在等待”“工具调用是否重复”等问题。

看板把多项目、多任务、多会话的运行状态聚合成可扫描视图。

模式把工具权限、agent loop 和插件能力组合成不同执行环境。

Provider让同一个 Harness 可以连接 API 模型、订阅入口或本地模型。

Trajectory把代理过程从黑盒聊天变成可复盘、可优化的执行记录。

三、关键论点与实操步骤

安装与启动：先跑起来，再在浏览器里工作

Owain 的安装演示很简短：复制官方命令到终端，启动后 Harness 会在本地端口提供 Web 界面。进入界面后，它看起来有点像 Codex 风格的浏览器工作台，可以打开多个项目、多个 session，并在侧边栏中切换。这个设计对“同一天处理 5 到 6 个项目、50 到 60 个任务”的开发者尤其重要，因为终端 multiplexer 虽然强大，但在 agentic coding 场景里很难给出全局任务状态。

配置权限：workspace 与 full access 要分清

视频里能看到权限切换：workspace 权限只允许写当前目录，full access 则扩大到当前目录之外。这个选择不是 UI 细节，而是安全边界。一个会调用 shell、读写文件、调用第三方插件的代理，一旦进入 full access，风险就接近“能代表用户操作整台机器”。因此，默认用 workspace，只有明确需要跨目录操作时才提升，是更稳妥的工程习惯。

连接 Claude Code 与 Codex：让 Harness 当协调器

最值得看的部分，是 Owain 把 Claude Code 和 Codex 当作工具调用目标。他让 Harness ping 本机上的 Claude Code 和 Codex，并把它们作为可调度的 worker。换句话说，DeepSeek Harness 不一定要替代 Codex，它也可以作为上层协调器，把不同代理分配到不同任务里。

这也是视频标题里“against Codex and Claude Code”的真正含义：它不是简单比谁回答更好，而是在比较三类角色。Codex 是强执行者，Claude Code 是熟悉的终端工作流，DeepSeek Harness 的价值则在于能把多个执行者接到同一个可视化、可插件化的流程。

用 Agent OS 管理任务：先生成 ticket，再并行派工

Owain 还展示了自己正在开发的 Agent OS：里面有类似看板的任务管理，可以存知识库、配置 runner、运行云端或虚拟机上的代理，并用 inbox 接收代理回报。演示中，他给 Harness 一个很粗糙的提示：“review the code and find any bugs we need to fix”，让代理在代码库里找 bug，并通过 MCP server 创建任务。

生成的任务并不是一句话 TODO，而是包含 bug 描述、为什么重要、涉及代码位置和修复建议。随后他采用 coordinator-worker pattern，把 4 个 bug fix 分派给 4 个隔离 worktree 里的 agent session，并由一个主 session 监控它们的完成状态。这是视频最有工程价值的实操：把“一个大任务”拆成“可审查的 ticket + 多个隔离执行者 + 总控复核”。

遇到代理不知道自己有工具：上下文和自描述仍然重要

演示中还有一个非常现实的片段：代理一开始没有意识到自己有 RPC 能力来创建新 session，Owain 需要提醒它可以调用 `session.create`、`session.prompt` 一类能力。这个细节说明，哪怕 Harness 暴露了强工具，代理也未必自动知道何时使用。工具自描述、系统提示、示例任务和失败恢复仍然是多代理系统的关键工程面。

价格判断：API key 模式适合实验，不一定适合高频开发

Owain 试用了两天，估算只把 20% 编码工作放进这个 Harness 就花了约 2 美元；如果全天使用，可能两天达到 6 到 7 美元。他因此认为，对高频开发者来说，订阅制通常更可控。这个判断不代表 API 模式没有价值，反而给出了边界：探索新 Harness、跑特定模型、搭私有流程时 API 很灵活；日常重度 coding agent 使用时，成本可预测性更重要。

四、对比表格：什么时候选 DeepSeek Harness、Codex 或 Claude Code

工具/模式	适用场景	优点	主要风险	决策建议
DeepSeek Agent Harness	想搭自定义 Agent 工作台、插件 UI、多模型 provider、多代理协调器。	插件化程度高，可定制 UI、工具、agent loop、权限模式和轨迹视图。	社区插件安全风险较高；API key 计费对重度开发不够可预测；代理仍需清晰工具提示。	适合做 agent platform 原型、团队内部工具和多代理实验，不必马上替换主力 coding agent。
Codex	需要稳定完成工程任务、代码修改、测试验证、长期上下文任务。	执行质量和工程闭环强，订阅制成本更易预估，适合日常主力开发。	自定义 UI 和外部协调层能力不如插件式 Harness 直接。	继续作为主执行者；需要多代理编排时，可以让 Harness 或任务系统调度 Codex。
Claude Code	偏好终端、需要和本地开发习惯强绑定、希望快速在 shell 中协作。	贴近命令行工作流，容易和已有开发环境结合。	多项目、多 session、多任务状态在终端里不够可视化，长时间并行工作容易丢上下文。	适合作为熟悉的 worker；在复杂编排中可以由上层系统派工。
本地模型 + Harness	隐私、离线、成本实验，或需要控制模型运行环境。	理论上更可控，也能接入同一插件体系。	硬件成本高，速度和能力未必达到云端 frontier 模型体验。	优先用于低风险、低成本、可容错任务；关键代码修改仍要用强模型复核。

五、引用块：这支视频最该带走的判断

如果把 Agent 看成只会回答问题的模型，你会比较模型分数；如果把 Agent 看成工作系统，你会比较任务编排、权限边界、插件生态和可观测性。

这句话不是视频原文逐字引用，而是对整段演示的浓缩。Owain 的真正兴趣点，是 Harness 让开发者把“代理过程”产品化：有看板、有 runner、有 inbox、有轨迹、有 provider、有插件。对于团队来说，这比单次回答质量更接近生产力系统。

第三方插件越强，越要把安全模型想清楚；因为它们面对的不是普通网页，而是能接触凭据和文件系统的代理。

视频也提醒了安全问题：从互联网安装的插件可能获得代理上下文、工具调用能力、凭据和本机文件访问路径。插件化是优势，同时也是攻击面。真正落地时，应该把插件来源、权限声明、审计日志、隔离执行和撤销机制纳入最低设计要求。