Pi Coding Agent 07：选型横评——Pi vs Claude Code vs DeepSeek Harness 架构全景对比

在探讨 Coding Agent 的工程化选型时，很多团队经常陷入一种误区：找几个开源框架，跑一次官方自带的“用 Python 写一个贪吃蛇” Demo，看谁写得快就草率得出“框架 A 完胜框架 B”的结论。

然而，在面对长达数周的复杂长程任务、多团队协同规范、金融级安全审计以及多端内嵌诉求时，表面的 Demo 往往会掩盖深层的架构瓶颈。

技术选型的本质，绝不是比较功能清单的长短，而是选择你的系统内部：模型适配、会话持久化、上下文工作集管理、安全防护网与扩展代码，分别由谁来买单、由谁来承担责任。

本篇我们将把业内最受关注的三大开源/工业级 Harness——Pi Coding Agent、Claude Code 与 DeepSeek Harness（DSH） 放在同一严苛基准线上，展开全方位的横向架构拆解。

一、三种截然不同的产品边界与架构世界观

这三个系统代表了三种完全不同的工程解题哲学：

  1. Pi（极简微内核优先）：
    • 官方将自己定位为 Minimal Agent Harness。它提供了极度干净的多模型统一适配（pi-ai）、树形会话追溯、RPC 与 SDK 接口。它刻意不把复杂的权限弹窗、特定工作流和 MCP 写死在核心里，鼓励开发者按需组装。
  2. Claude Code（端到端产品化工作流优先）：
    • 围绕 Anthropic Claude 大模型深度打造的商业级研发利器。它提供了极致开箱即用的开发体验，内置操作系统级沙箱、自动化 Checkpoint、完善的 Hook 与 Subagent 机制。代价是深度绑定 Claude 生态，核心控制流不对外开放修改。
  3. DeepSeek Harness（高度可组合的无特权微内核）：
    • 基于 Cordis 微内核架构构建，在设计上“不存在任何不可替换的特权内核”。模型适配器、工具管线、事实源、甚至整个 Agent Loop 调度算法都是插件。适合构建高复杂度的企业级 Agent 操作系统或进行多 Agent 博弈调度实验。

二、九维度硬核决策矩阵

基于官方稳定版本（Pi commit a470b121、Claude Code 官方规范、DSH v0.1.0-rc.8），三者的关键架构对比如下：

架构对比维度 Pi Coding Agent Claude Code DeepSeek Harness (DSH)
主要交互入口 终端 TUI、Print/JSON、RPC、Node.js SDK 终端 CLI、IDE 插件、桌面端产品 Profile 拼装的 Web、Headless、TUI
底层模型策略 pi-ai 原生管理多模型，支持任意中立切换 深度围绕 Claude 模型特性做极限工程调优 ctx.llm 统一接缝，支持任意模型适配器
会话状态存储 基于父指针的 JSONL 树形分支，原生支持 /tree、/fork 本地 Session、Checkpoint、差异还原 不可变追加写事件事实源（Session Log）
扩展定制机制 Skill（知识）、Extension（代码）、Package（分发） Skill、Hook、MCP、Subagent Cordis 插件、能力接缝（Seams）、Profile
项目资源防护 Project Trust 机制拦截项目级代码执行 Settings 作用域、权限规则拦截 外部策略平面与 Profile 权限组合
工具安全审批 由 Extension 拦截 tool_call（需自研或装包） 原生内置 allow / ask / deny 细粒度规则 单调 Guard 闸门，只能收紧不能放宽
底层系统隔离 无内置沙箱，推荐 Plain Docker / Gondolin 原生内置 OS 级 bash sandbox，防御穿透 外部 Sandbox 插件与可插拔容器后端
控制流侵入能力 在 Extension API 允许范围内定制，可 Fork 源码 严格受官方暴露的产品接口约束，不可改核心 极高！可随意编写新插件替换 ctx.agentLoop
团队维护成本 中等：需对第三方包与外部沙箱安全负责 极低：官方维护产品稳定性，团队仅需配置 较高：需维护复杂的插件依赖图与配置覆盖

三、安全架构的三大灵魂拷问

在评估这三者的安全性时，不能只看宣传文档，必须拆解为三个致命问题：

1. 谁决定某个危险动作是否被允许？

  • Pi：默认内置工具没有统一弹窗，依赖 Extension 在 tool_call 时动态拦截。
  • Claude Code：内置工业级权限引擎，支持根据命令模式与工作区范围做规则前置匹配。
  • DSH：由策略管线统筹，前置 waterfall 评估与单调 Guard 最终收紧权限。

2. 谁限制最坏情况下的系统破坏范围？

  • Pi：依赖外部运维手段（启动 Docker 容器、micro-VM 或低权限 Linux 账号）。
  • Claude Code：内置通过操作系统能力实现的沙箱机制（对 bash 执行进行环境约束）。
  • DSH：依赖装配的 Sandbox Provider。

3. 当安全服务崩溃时，系统是放行还是阻断？

  • 生死线（Fail-Closed）：当审批服务不可用、UI 无法渲染或沙箱解析抛错时，三者均要求严格阻断（Fail-Closed）！绝不允许静默降级为宿主机裸奔！

四、同一基准任务下的实验验证

为了直观展现三者的运行风格，我们设计了相同的测试场景：

1
2
固定任务：给出一个包含 2 个源码文件与 1 个失败单元测试的仓库。
硬性约束：只能修改 src/a.ts 与 src/b.ts，禁止调用外部网络，必须跑通测试后停下。

观察三者在真实环境下的表现差异：

  1. Pi：以极快的速度启动，生成极其清晰的 toolCallId 配对轨迹，在遇到多工具请求时支持整洁的并行执行。若未配置沙箱，执行的正是本机的真实命令；
  2. Claude Code：围绕测试报错给出极具洞察力的思维推理链，在执行命令前弹出细致的权限模式提示，并在沙箱内安全完成测试与回滚；
  3. DSH：将每一步的决策、请求头快照和工具结果以不可篡改的事件写入 Session Log，状态机推进严丝合缝，展现出极强的工业审计确定性。

五、最终选型指南：按你的约束做决定

技术架构没有唯一的胜者。看清每个系统的职责边界，根据团队现有的基建水平与安全底线做出清醒的选择，才是成熟软件工程师的核心素养。