DeepSeek Harness 和 Pi Agent 怎么选？先想想你愿意折腾什么

想要 Web 界面、MCP、子 Agent 这些现成能力，可以先试 DeepSeek Harness；习惯在终端里干活，想保留一个小核心，用到什么再加什么，可以先试 Pi Agent。

它们的出发点不一样。DeepSeek Harness 从一套可以替换的零件出发，Pi 从最小核心出发。选错之后，最先让你头疼的往往是维护工作：想省配置的人忙着拼扩展，想要极简的人忙着管运行时。给 AI 挑个工具，挑着挑着，自己多了一份配置工程师的兼职。

模型、版本、任务都会影响结果。想知道哪套适合自己，可以先看它们默认给了什么、还得自己补什么，再用同一个任务跑一次试点。

模型、Harness、成品 Agent，别混着比

聊 Harness 时问"哪个模型更强"，容易把两件事混在一起。Harness 是模型干活时用的工具和运行环境，换个工作台，不会顺便把模型的脑子也换了。

DeepSeek Harness（dsh）是 DeepSeek 开源的 Agent 运行时，采用 MIT 协议，目前处于开发者预览阶段，官方明确会有破坏性变更。它不等于某个 DeepSeek 模型，你仍然需要配置模型，可以用 DeepSeek，也可以接其他兼容接口或本地模型。
Pi Agent（Pi Coding Agent）是开源的终端编码 Harness，同样采用 MIT 协议，走极简路线。它支持多个模型和供应商，也能在会话中切换模型。

比较时，把模型、任务和提示词固定下来，再看默认能力、扩展方式和运维负担。否则模型一换，最后夸的、骂的，都可能找错对象。

两者具体差在哪

维度	DeepSeek Harness	Pi Agent
设计哲学	插件式运行时：模型、工具、Skill、会话、沙箱、存储、循环、调度、界面都可以换	最小终端核心：先给一个能跑的循环，其他能力按需扩展
界面	浏览器 Web UI，也可以无头运行	终端交互，也支持打印 / JSON 输出、RPC、SDK 嵌入
默认工具	通过 profile / bundle / 插件组合能力，包括子 Agent、计划模式等	内置四个：读文件、写文件、改文件、跑命令，其他能力靠扩展
扩展方式	插件可以接入回合开始、工具执行前等运行时事件点，甚至替换循环本身	TypeScript 扩展、Skill、提示词模板、主题、包，主要围绕小核心添加能力
MCP	内置通用 MCP 客户端	没有内置 MCP，需要通过扩展或按文档接入
审批与隔离	内置偏 fail-closed 的审批服务；沙箱目前主要覆盖文件系统影响，不覆盖完整的网络和进程隔离	没有内置权限系统和沙箱，文档建议用容器等外部手段隔离
会话	可组合的会话插件和服务，日志支持恢复、分叉、搜索和回放	JSONL 树形会话，支持分支、分叉、恢复、压缩，方便在会话里反复尝试
模型选择	默认 DeepSeek，也支持其他兼容接口和本地模型	多供应商、多模型，可以在会话中切换
成熟度	开发者预览，功能和接口变化快，适合试点，不宜直接当作生产标准	核心小、概念少，容易上手；外围能力仍需要自己选择和维护

DSH 内置审批服务，但沙箱目前主要管文件系统，完整的隔离边界还要靠部署方式补齐。Pi 的内置能力少，扩展之后照样能做事；扩展来源审核和容器隔离，则由使用者负责。两边都不能只凭内置功能的多少判断安全性。

怎么试：同一个任务，两边各跑一遍

找一个可以丢弃的前端演示项目就够了，不需要拿真实业务代码冒险。两边从相同的代码起点开始，任务、提示词、验收标准和检查命令保持一致，只换 Harness。别让后跑的那位直接接着前一位的作业往下写。

第一步：准备可丢弃的演示项目

bash 复制代码

# 演示项目先复制一份，或者用 worktree 单独开分支
git worktree add ../demo-pi-dsh-test -b demo-pi-dsh-test HEAD
cd ../demo-pi-dsh-test
git status --short

确认工作区干净、这份代码可以随时丢弃。API Key 也单独开一个小额度的，主力 Key 先别来参加这场试验。

第二步：启动 DSH，核对配置

bash 复制代码

# 需要 Node.js 22.19 以上
node -v
npx @deepseek-ai/dsh web

默认 Web UI 在 http://127.0.0.1:3080。进入设置里的模型配置，填好 Key、选好模型，再开一个会话。开始对比前，确认：

Web UI 能打开，会话能正常对话；
实际使用的模型就是你配置的那个，没有和默认模型混淆；
插件和 MCP 的开关已经逐项确认，知道哪些开着，别默认全开。

记下 DSH 的版本号。它还在开发者预览阶段，设置位置和插件行为都可能随版本变化。不记版本，下个月复现时，很容易怀疑自己上次到底是怎么跑起来的。

第三步：启动 Pi，先跑通基本操作

按 Pi 官方安装指引装好 pi 命令，再做一个小范围检查：

bash 复制代码

pi --version
# 进会话，确认供应商和模型能正常连接
# 先做一个单文件小改动，看 diff 是否干净
git status --short
git diff --stat

确认这几项：

pi --version 能输出已安装的版本；
供应商和模型连接正常，能对话；
单文件小改动只产生预期范围的 diff，没有顺手改无关文件。

基本操作还没跑通时，先别加 MCP、子 Agent 和扩展包。东西堆得越多，越难找到最初是哪一环出了问题。这个小改动检查完，正式对比仍然从干净的代码起点开始。

第四步：用同一个任务，记录结果

可以用一个商品列表筛选任务，看看它们能不能老实守住改动范围。提示词两边一字不改：

给商品列表加一个按价格区间筛选，筛选结果用派生值，不要改原数组，筛选状态只放在当前组件里，不要写进全局 store，不要改公共组件的 props，不要升级依赖。做完输出改动文件清单，并跑一遍相关测试。

记录这些内容：

改动范围：改了几个文件？有没有动公共组件、全局 store 或无关文件？
验收结果：筛选逻辑是否正确？切回"全部"时顺序有没有乱？相关测试是否通过？
范围纪律：有没有"顺手重构""顺手升级"？让它加个筛选，最后收到一份架构改造方案，这项就得扣分。
长任务表现：中途打断后能不能恢复、分支、回退？恢复后丢了多少上下文？
隔离与审批：危险操作有没有被拦住或提示？隔离由内置能力提供，还是由自己搭的容器提供？
成本与耗时：消耗多少 token、花了多久、失败后重试了几次？

如果两边模型不同，就在记录里写清楚。这种情况下，结果反映的是整套组合的表现，不能把差异全算在 Harness 头上。

第五步：把维护时间也算进去

DSH 的默认能力可能帮你省下不少配置时间，但插件升级、版本变更也会花时间；Pi 的核心容易上手，接 MCP、补审批和隔离却可能需要自己组装。

别只记安装花的时间，把后面折腾配置的工夫算成自己的业余爱好。

如果两边写出的代码差不多，就看团队更擅长维护哪一套。功能清单更长，并不能替团队接下维护工作。

哪些情况可以先试哪一个

想要现成能力、Web 界面和一整套默认配置，可以先试 DSH。习惯终端、偏爱小核心，希望自己决定加什么，可以先试 Pi。

再看看谁来维护。能审插件来源，也愿意跟进预览版变更，DSH 的插件路线才比较合适。不想频繁追着版本变动跑，Pi 的小核心可能更省心；加上去的扩展，仍然得有人管。

长任务多，就重点试会话机制：中断后怎么恢复，怎么分支，反复尝试方不方便。隔离要求高，就检查审批和沙箱到底管到哪，哪些边界还得自己用容器等手段补齐。功能清单上的"安全"两个字，信息量不够。

试点阶段也可以两个都用。它们都能读 Skill、都能接模型，可以一个处理日常改动，另一个做长任务或插件实验。等打分表有了结果，再挑主力，不必凭第一印象就搬迁整套工作流。

用不顺时，先查这几处

DSH 装完插件就乱：检查 profile / bundle 有没有叠太多，插件来源有没有审过，版本有没有记录。插件之间打架，也得算进使用成本。
DSH 升级后行为变了：开发者预览阶段会有破坏性变更。试点和生产要区别对待，升级前先在演示项目里重跑一次试点任务，别见到"最新版"就直接往生产里搬。
Pi 接不上 MCP：确认自己走的是扩展路线还是文档里的接入方式，别照着"内置通用 MCP 客户端"的预期去找开关。
Pi 长任务断了接不上：先试清楚会话的分支、恢复和压缩机制，再判断是否需要外部会话管理或检查点。
两边结果差很多：先核对模型、提示词、任务和测试命令。模型没对齐，暂时还轮不到 Harness 领功或背锅。

可以直接复制的试点模板

提示词两边保持一致：

css 复制代码

任务：[一个具体的前端任务，写清改什么、不改什么]
验收标准：[做完怎么算做对，越具体越好]
禁止事项：[不改公共组件、不升级依赖、不顺手重构，写清楚]
检查命令：[跑哪条测试或 lint 命令]
输出要求：[改动文件清单 + 需要人工确认的点]

开跑前核对：

想要现成能力还是自己组装，谁来管插件，长任务和隔离有什么要求，都已经明确
两边从相同的代码起点开始，任务、提示词、验收标准和测试命令一致
演示项目可以丢弃，API Key 是单独的小额度 Key
DSH 的版本号、插件状态、MCP 开关已经确认
Pi 的版本、供应商、模型连接和单文件 diff 已经验证

跑完填写记录，最后按结果选，不按功能清单长度或第一印象选：

改动范围：文件数、无关改动、公共代码是否被修改，有没有顺手重构或升级
验收结果：功能、边界条件和相关测试是否通过
长任务：中断后能否恢复、分支、回退，恢复后丢了哪些上下文
隔离审批：危险操作是否被拦住或提示，隔离由内置能力还是自搭环境提供
成本耗时：token、耗时、失败重试次数
维护成本：插件 / 扩展升级、版本变更花了多少时间
模型记录：两边的模型、模型版本、Harness 版本