OpenCode、Pi、DeepSeek Harness 怎么选：Coding Agent Harness 全景与服务化对比

最近集中看了几套 Coding Agent 工具：OpenCode、Pi、DeepSeek Harness、Codex、Claude Agent SDK、OpenHands。刚开始看时，它们都能聊天、读文件、执行命令、调用工具，功能表放在一起很像，越看反而越难选。

真正拉开差距的不是它们会不会写代码，而是怎么接进现有系统：有没有稳定的服务接口，会话和事件能不能拿出来，工具怎么注册，任务能不能取消，运行环境怎么隔离，以及我们要为它补多少控制面。

这篇主要做工具梳理和选型。至于选完以后怎样放进业务、现有 CLI 怎么接、哪些能力还得自己建设，放到下一篇单独讨论。

以下判断基于 2026 年 9 月 5 日 能查到的官方资料。这个领域变化很快，具体接口仍应以实际采用版本为准。

先说结论

如果只看目前比较常见的几种建设目标，我的选择会是：

建设目标	优先看什么
已有 Go、Java、Python 服务，想尽快接一个独立 Agent Runtime	OpenCode
想把 Agent 内核嵌进自己的 Node.js 产品	Pi
团队以 Python、DeepSeek 为主，并关注轨迹、评测或训练闭环	DeepSeek Harness
已经确定使用 OpenAI 或 Claude	Codex / Claude Agent SDK
需要完整仓库、容器、浏览器和远程开发环境	OpenHands

这不是产品能力排名。OpenCode 的优势是接入快，Pi 的优势是容易改，DeepSeek Harness 的吸引力在模型与训练方向，OpenHands 解决的是更重的执行环境。团队面对的问题不同，答案自然也不同。

还有一个结论比较确定：不要因为某个工具恰好能执行 Shell，就直接把它当成业务后端。 能跑命令只能说明 Demo 能工作，离生产还差会话、取消、隔离、权限、审计和任务恢复。

这些工具属于同一类吗

不完全是。

我这里把 Harness 理解为模型外部的执行环境。它负责组织上下文，让模型选择工具，把工具结果送回模型，并把这个循环持续到任务结束。

Agent = Model + Harness

Harness =
  Agent Loop
+ Context
+ Tool Runtime
+ Session
+ Permission
+ Workspace / Sandbox
+ Event Stream

按这个定义，常见项目大致可以分成三类：

类型	代表工具	更像什么
可以直接运行的 Harness	OpenCode、Pi、DeepSeek Harness、Codex、Claude Agent SDK	已经装好的执行引擎
Agent 开发框架	LangGraph、AutoGen、PydanticAI、Semantic Kernel	用来自己组装执行引擎的零件
协议和基础设施	MCP、ACP、A2A、Sandbox	连接工具、Agent 或运行环境的标准

LangGraph 和 OpenCode 经常会被放在一起比较，但它们不在同一层。用 LangGraph，任务状态、节点、路由和持久化大多由我们自己设计；用 OpenCode，现成的 Agent Loop、Session、工具和交互方式已经在那里了。

OpenCode：最像一个现成的 Agent Backend

OpenCode 最吸引我的地方不是终端界面，而是它已经把 Server、SDK、Session、事件和扩展方式接到了一起。

官方提供 opencode serve，业务侧可以通过 HTTP 创建 Session、发送消息，通过 SSE 接收事件。工具侧既可以直接使用 Bash，也可以写 Custom Tool、Plugin，或者连接 MCP Server。Agent、Subagent 和 Skill 也有明确的配置方式。

典型接法很直观：

Business Service
      │ HTTP / SSE
      ▼
OpenCode Server
      ├── Agent / Skill
      ├── Custom Tool
      ├── Bash
      └── MCP Server

它适合下面这种团队：

• 业务服务已经存在，不想为了 Agent 改成 Node.js；
• 希望 Runtime 独立部署；
• 想先用 HTTP/SSE 把任务、过程和结果跑通；
• 还没有决定长期绑定哪家模型。

需要注意的是，OpenCode 仍然带有本地 Coding Agent 的设计背景。多租户、Worker 调度、共享存储、工作目录隔离、凭证和高可用不是启动一个 Server 就自动具备的。把它接成后端容易，把它做成稳定的多租户执行面仍然需要工程投入。

Pi：更像可以嵌入产品的 Agent 内核

Pi 的感觉和 OpenCode不太一样。OpenCode 更像一个已经可以对外提供服务的进程，Pi 更像一组小而清晰的可编程构件。

它有两种比较实用的接入方式：

• 在 TypeScript/JavaScript 服务里使用 SDK，直接创建和控制 Agent Session；
• 以 RPC 模式运行长驻进程，通过 stdin/stdout 上的 JSONL 发送命令和接收事件。

Pi 的 Extension 可以注册工具、命令和事件钩子，Skill、Prompt Template、Package 也比较适合做产品级组合。如果团队想自己决定外部 API、UI、会话存储和任务状态，只复用 Agent Loop，Pi 会比较顺手。

代价也很直接：它不会替我们提供完整的企业控制面。认证、租户、数据库、Worker 调度、配额和运维接口，基本都要自己做。对于 Go 或 Java 服务，JSONL RPC 虽然能接，但还要处理子进程退出、背压、重启和协议版本。

所以我会把 Pi 放在“自由度更高，但建设量也更大”的位置。

DeepSeek Harness：值得关注，但要给变化留空间

DeepSeek Harness 的特点不只是运行 Agent。它试图把 Harness、插件、部署、轨迹和模型训练放在同一条链路上，这一点和单纯面向个人使用的 Coding Agent 不太一样。

从当前资料看，它提供 CLI、Web、Python SDK、Plugin 和 ACP 等接入方式。对于 Python 团队，或者本来就在围绕 DeepSeek 做行业 Agent、数据回放和持续评测，这个方向很有吸引力。

但它仍是较新的项目，官方也将当前阶段标为 Developer Preview。真正上生产前，需要自己验证：

• 并发任务和长任务是否稳定；
• Session 能否恢复；
• 取消后子进程是否真的结束；
• Plugin 和 SDK 升级是否兼容；
• 多模型 Provider 是否满足实际需求；
• 轨迹数据怎样落库和脱敏。

我的看法是可以尽早试，但不要让业务接口直接依赖它当前的 SDK 类型。外面包一层 Adapter，升级或切回其他 Runtime 都容易一些。

Codex 和 Claude Agent SDK：生态确定时更省事

如果公司已经确定模型平台，就不一定非要追求“模型中立”。

Codex 提供非交互执行、SDK 和 App Server 等方式，可以管理 Thread、Turn、事件、审批、结构化输出、MCP 和 Sandbox。Claude Agent SDK 则把 Claude Code 的 Agent Loop、工具、Session、Hook 和权限机制开放给 Python、TypeScript 应用。

这类厂商 Runtime 的优点是模型和 Harness 的配合通常更完整，官方能力出现后也更容易直接用上。缺点是迁移成本更高，账号、模型、协议和运行时会形成一组绑定。

如果本来就确定使用对应平台，这种绑定未必是问题；如果目标是做一个可在多家模型间切换的通用 Agent 平台，就要谨慎一些。

OpenHands：需要完整执行环境时再考虑

OpenHands 比前几种更重。它不只是一个 Agent Loop，还包含 SDK、Agent Server、远程 Sandbox、Web UI，以及面向软件工程任务的完整执行环境。

如果任务需要拉取仓库、安装依赖、启动服务、运行测试、操作浏览器，并持续执行较长时间，OpenHands 的价值会比较明显。如果只是读取几项业务数据，再生成一个结构化结果，这套平台可能有些重。

这里不是说重不好，而是要看我们的任务到底需要“一个循环”，还是需要“一台可远程使用的开发机”。

放在一起比较

下面这张表只比较作为业务 Runtime 时比较关心的部分，不比较代码补全体验：

工具	接入方式	工具扩展	模型选择	服务化感受	主要代价
OpenCode	HTTP Server、SSE、SDK	Bash、Custom Tool、Plugin、MCP、Skill	相对开放	接入最快	企业控制面和隔离要自己补
Pi	TypeScript SDK、JSONL RPC	Extension、Tool、Skill、Package	相对开放	适合深度嵌入	外部服务层基本要自己建
DeepSeek Harness	CLI、Python SDK、ACP、Web	Plugin、工具和协议扩展	偏 DeepSeek 方向	适合验证新方向	项目较新，要控制版本风险
Codex	exec、SDK、App Server	MCP、Skill、Sandbox、Approval	OpenAI	服务接口完整	平台绑定较强
Claude Agent SDK	Python/TS SDK	MCP、自定义 Tool、Hook、Permission	Claude	SDK 集成方便	平台绑定较强
OpenHands	SDK、Agent Server	Tool、MCP、Remote Sandbox	可配置	软件工程环境完整	部署和资源成本较高

表里的“服务化方便”不等于“已经可以直接承担生产业务”。它只代表二次封装的起点更高。

选型时我会重点看什么

1. 怎么被业务系统调用

TUI 好不好用和服务端好不好接是两回事。我会先确认有没有稳定的 SDK、RPC 或 HTTP 接口，以及能不能持续获取事件。

如果只能启动一次 CLI、等进程退出后读取 stdout，那么任务取消、审批、进度展示和故障恢复都会比较难做。

2. Session 到底归谁管理

要确认 Session 能不能创建、恢复、查询和删除，数据存在哪里，多实例之间是否共享。

业务任务和 Harness Session 也不应该混成一个 ID。一次业务任务可能因为超时、重试或切换 Runtime 产生多个 Session。

3. 工具是不是有明确契约

所有 Coding Agent 几乎都能执行 Shell，但我更关心能否把工具描述成带 Schema 的接口：参数有什么类型，哪些值允许传，返回值是否稳定，哪些调用需要审批。

只靠 Prompt 告诉模型“请按这个格式拼命令”，能跑，但不适合作为长期方案。

4. 任务能不能停下来

用户取消以后，不能只把页面状态改成 cancelled。模型请求、Shell 子进程、浏览器任务和远程工具都要一起结束，否则后台仍会继续花钱，甚至继续执行有副作用的操作。

5. 隔离是不是足够

工作目录不是安全边界。并发任务至少要考虑目录、进程、网络、凭证、缓存和 Session 的隔离。涉及代码执行或不可信输入时，还要看容器或 Sandbox 能力。

6. 最终结果能不能被程序使用

业务系统通常需要 JSON，而不是一段“看起来不错”的 Markdown。最好直接支持 JSON Schema 或结构化结果；其次可以通过一个专门的 Tool 提交最终结果；最差才是从自由文本里解析。

按团队情况怎么选

已有业务服务，先把链路跑起来

我会先试 OpenCode。HTTP/SSE 对现有 Go、Java、Python 服务都比较友好，也不必把 Agent 内核嵌进主进程。

准备把 Agent 做成自己的产品能力

我会重点看 Pi。它给的控制权更多，适合自己定义 API、会话和 UI，但要接受更多平台建设工作。

Python 团队，希望结合 DeepSeek 做持续评测或训练

可以验证 DeepSeek Harness。建议固定版本，先跑离线任务或影子流量，再决定是否进入核心链路。

已经确定单一模型平台

直接评估 Codex 或 Claude Agent SDK 往往更省时间。所谓中立性不是免费获得的，如果团队没有真实的多模型需求，不必为了抽象而抽象。

任务本身就是远程软件开发

优先看 OpenHands，或者其他带完整 Sandbox 的平台。此时运行环境的能力可能比 Agent Loop 本身更重要。

最后不要靠 Demo 拍板

选型时最好准备一组真实任务，固定输入、工具和结果格式，然后分别跑候选 Runtime。至少记录：

• 任务完成率；
• 工具调用是否正确；
• 无依据结论的比例；
• 人工接管次数；
• p50、p95 完成时间；
• Token 和基础设施成本；
• 超时、取消和恢复是否正常。

一次演示效果很好，可能只是模型碰巧选对了路径。能稳定跑完几十个真实任务，才说明 Harness、工具和上下文设计基本合适。

总结

如果现在要做一个业务 Agent 原型，我会先从 OpenCode 开始，因为接入成本低；如果很快发现需要自己掌控会话、事件和工具生命周期，再考虑用 Pi 重做执行内核；如果团队的重点是 DeepSeek 和训练评测闭环，就单独验证 DeepSeek Harness。

不管选哪一个，业务侧最好先保留自己的 task_id、run_id、事件和结果格式。这样 OpenCode、Pi、DeepSeek Harness 才是可替换的执行器，而不是整个系统无法绕开的中心。

下一篇 《把 Coding Agent Harness 用到业务里：我们能复用什么，又该自己建设什么》 继续讨论选完以后怎样接进业务，以及已有 CLI 应该以什么方式交给 Harness。

参考资料

• OpenCode Server
• OpenCode SDK
• OpenCode Tools
• OpenCode Custom Tools
• OpenCode MCP Servers
• Pi RPC Mode
• Pi SDK
• Pi Extensions
• DeepSeek Harness GitHub Repository
• DeepSeek Harness Interaction Modes
• Codex as a Platform
• Codex Non-interactive Mode
• Claude Agent SDK Overview
• OpenHands Software Agent SDK
• OpenHands Agent Server

常见问题

OpenCode、Pi、DeepSeek Harness 都能调用自定义 CLI 吗？

原则上都可以。OpenCode 可以通过 Bash、自定义 Tool 和 MCP，Pi 可以通过 Extension 注册工具或执行命令，DeepSeek Harness 可以通过 Plugin、SDK 或 ACP 扩展。正式使用时最好为 CLI 增加结构化参数、权限和审计，而不是让模型自由拼接 Shell。

哪个更适合接到已有业务服务后面？

如果希望通过 HTTP/SSE 快速接入，OpenCode 的路径较短；如果准备把 Agent 内核嵌入自己的 Node.js 服务并自行设计控制面，Pi 更灵活；如果团队以 Python 和 DeepSeek 为主，可以验证 DeepSeek Harness，但要给早期版本变化留出隔离层。