Claude Code闭源、MCP成熟、经过审核，DSH开源、插件更简单但“活在进程里”、默认你要自己当质量把关人——当“开放”和“精致”被放在同一个选型天平上时，一个团队到底该按“谁更可 hack”来选，还是按“谁在出问题时有人兜底”来选？

——以“可hack性 × 兜底性”二维张力为主线的编码智能体选型工程学

摘要

目录

一、导语与问题定义：选型天平上的两个砝码

一个团队在评估编码智能体时，通常先看基准分数，再看价格，最后看“能不能改”。但当工具真正进入日常研发流程，决定成败的往往不是分数，而是出问题那一刻的责任归属：是提交一个issue等供应商修，还是自己打开源码改一行插件？这两种反应背后，是两种完全不同的工程契约。

本文把这种契约差异抽象为两个可操作的概念。可hack性指团队在多大程度上能够观测、替换、扩展工具的内部行为，包括源码可见性、插件加载方式、协议可替换性与调试接口深度；兜底性指当工具行为偏离预期时，团队能在多大程度上把故障责任转移给外部主体（供应商SLA、审核链路、托管运行时），或以多低成本自行恢复。二者并非同一维度的两端，而是两条相互牵制的曲线。

笔者认为，把“开放”与“精致”当作价值判断是叙事陷阱。工程上真正可度量的是两个量：故障责任的可转移比例（transferable liability ratio，TLR）与行为可观测的粒度（observability granularity，OG）。前者决定“出事谁掏钱、谁背锅”，后者决定“出事多久能定位”。选型天平的两端，本质上是这两个量的组合，而非“开源/闭源”的标签。

定义（本文工作定义）：可hack性 = f(源码可见性, 插件加载位置, 协议可替换性, 调试接口深度)；兜底性 = g(供应商SLA覆盖率, 审核链路强度, 托管运行时隔离度, 社区响应时延)。两者均可在0–1区间内做团队内评分，后文给出评分表。

二、背景：编码智能体的三种工程形态与协议标准化浪潮

2.1 三种工程形态

从工程集成角度看，当前编码智能体大致分三类形态。第一类是IDE内嵌型，以补全与行内编辑为主，行为边界清晰但扩展性弱；第二类是CLI/终端智能体型，具备文件系统读写、命令执行、多步规划能力，Claude Code与多数开源harness属于此类；第三类是平台编排型，把智能体作为流水线节点，强调可观测与权限治理。

形态差异直接决定可hack性的上限。IDE内嵌型的插件接口通常由IDE厂商定义，团队只能在既定槽位内扩展；CLI型把进程边界暴露给用户，理论上可替换任意环节，但也意味着团队要自己承担进程内的一切副作用；平台编排型则把可hack性让渡给平台，换取集中式兜底。本文评述：三种形态并非演进关系，而是责任分配的不同切法，选型时应先确定团队愿意承担哪一段责任，再选形态。

2.2 协议标准化：MCP与A2A把“接口”变成“契约”

Model Context Protocol（MCP）由Anthropic于2024年11月开源，定位是让模型与外部工具、数据源之间用统一协议通信，官方规范与SDK见 modelcontextprotocol.io。其核心价值不在“又一个插件格式”，而在于把工具调用从“每家自定义”变成“可审计的契约”：工具声明schema、能力边界与调用语义，宿主可据此做权限与审核。

2025年后，Agent2Agent（A2A）协议由Google发起并捐赠给Linux基金会，试图解决智能体之间的互操作，规范见 a2a-protocol.org。MCP解决“模型—工具”，A2A解决“智能体—智能体”，两者叠加使“协议层”成为可独立于实现演进的稳定面。笔者认为，协议标准化的真正后果是把可hack性从“改源码”迁移到“换协议实现”：团队不必fork整个工具，只需替换某个MCP server，就能改变行为。这在一定程度上缓解了开源/闭源的二元对立，但没有消除兜底性问题——协议只规定“怎么调”，不规定“调坏了谁负责”。

三、原理：可hack性与兜底性的三维拆解

3.1 协议层：开放接口 vs 审核链路

协议层的可hack性体现在“能否替换实现而不改宿主”。MCP的client/server分离设计使这一点成为可能：团队可以自建MCP server，把内部代码检索、构建系统、发布流水线暴露给智能体，而无需修改宿主程序。代价是，自建server的质量、权限与审计责任全部落在团队身上。

协议层的兜底性则体现在“审核链路”。闭源商业产品通常对工具调用做服务端审核、速率限制与滥用检测，这部分能力对用户不可见但真实存在。本文评述：审核链路是一种隐式兜底，它降低了个体团队的合规成本，但也降低了行为可观测粒度——你很难知道一次调用被拦是因为策略、配额还是模型判断。对强监管行业，这种不透明本身可能构成风险。

3.2 插件层：进程外插件 vs 进程内插件

插件加载位置是本文最看重的工程变量。进程外插件（out-of-process）通过IPC/HTTP与宿主通信，崩溃隔离好、权限可收窄，但延迟高、状态同步复杂；进程内插件（in-process）直接在主进程内运行，调用开销低、能访问全部上下文，但一个异常就可能拖垮整个会话，且难以做细粒度权限控制。

DSH一类开源harness选择进程内插件，换来的是“插件更简单”：不需要定义RPC、不需要序列化上下文、可以直接读写会话状态。这大幅降低了扩展门槛，也把稳定性责任从框架转移给了插件作者。笔者认为，这不是设计缺陷，而是明确的权衡：进程内插件把可hack性推到很高，同时把兜底性压到很低，适合验证预算充足、能把插件纳入CI的团队。

3.3 责任层：供应商兜底 vs 自担

责任层是张力曲线的落点。闭源+托管模式下，供应商承担可用性、安全补丁与合规审核的部分责任，团队通过SLA与支持通道获得兜底；开源+自托管模式下，团队获得完全控制权，也承担全部故障责任。两者之间还有中间态：开源但使用商业托管、闭源但允许本地部署。

本文评述：责任层的选择不能脱离故障的可逆性来谈。若一次错误调用的后果是“改坏一个文件”，自担成本低；若后果是“误发布到生产”，则供应商兜底的价值陡增。因此责任层评估应先做故障影响分级（FMEA式），再匹配兜底策略，而非笼统地问“要不要开源”。

四、对照分析：Claude Code路径与DSH路径的结构性差异

4.1 Claude Code：闭源外壳 + 成熟协议 + 审核链路

Claude Code以CLI形态提供终端内智能体能力，支持通过MCP接入外部工具，官方文档见 docs.anthropic.com。其工程特征可概括为：外壳闭源，协议开放，行为受服务端策略约束。团队能扩展的边界主要在MCP server与权限配置，无法修改核心调度逻辑。

这种结构带来的兜底性体现在：模型与运行时由供应商维护，安全补丁与行为变更通过版本发布统一推送；审核链路降低滥用风险；支持通道提供故障升级路径。代价是可hack性受限：当团队需要非标准调度（例如自定义多智能体协商、特殊上下文压缩策略）时，只能绕行或等待官方支持。笔者认为，Claude Code的定位是“把不确定性外包给供应商”，适合把智能体当基础设施而非研究对象的团队。

4.2 DSH：开源内核 + 进程内插件 + 自担质量

DSH（DeepSeek Harness）是围绕DeepSeek系列模型构建的开源编码智能体框架，仓库与文档见 github.com/deepseek-ai。其设计取向与Claude Code相反：内核开源、插件在进程内加载、默认不提供商业兜底。团队可以直接阅读调度循环、修改上下文管理、替换工具实现。

“插件更简单”是真实收益：无需定义跨进程协议，插件可直接访问会话对象与工具注册表，开发一个内部工具适配器可能只需几十行代码。但“活在进程里”意味着插件异常会污染主循环，且难以做沙箱隔离。本文评述：DSH把质量把关人的角色显式交给团队，这不是缺陷而是契约声明。选择DSH的团队必须同步建设插件测试、异常隔离与回滚机制，否则可hack性会反噬为稳定性负债。

4.3 结构性差异对照表

本文评述：这张表容易被误读为“DSH更自由、Claude Code更省心”的简单二分。真正值得注意的是可hack性上限与兜底性下限的非对称性：可hack性提升带来的收益是渐进的，而兜底性下降带来的风险是阶跃的——一次未隔离的插件崩溃可能让整个会话不可用。这种非对称性是后文评估矩阵设计的核心依据。

五、关键数据与案例：从公开基准到工程事故复盘

5.1 公开基准能说明什么、不能说明什么

SWE-bench系列是当前编码智能体最常引用的基准，其Verified子集由人工校验可复现的issue构成，论文见Jimenez等（2023，arXiv:2310.06770），数据与榜单见 swebench.com。该基准衡量“给定issue能否生成通过测试的补丁”，对单步修复能力有较好区分度。

但基准分数与工程兜底性几乎无关。基准环境是隔离的、测试是预置的、失败无副作用；生产环境则涉及权限、并发、回滚与审计。笔者认为，把SWE-bench分数当作选型主依据是指标错配：它测的是模型能力，不是工程契约。团队应把基准分数当作“能力下限”参考，把兜底性评估当作“风险上限”约束，两者不可互相替代。

5.2 工程事故的类型学复盘

公开的编码智能体事故报告多集中在三类：一是越权操作，智能体执行了超出预期的命令或写入了敏感路径；二是上下文污染，错误信息在长会话中累积导致后续决策偏离；三是依赖漂移，智能体引入未审计的第三方包。三类事故在两种路径下的处置成本差异显著。

以越权操作为例，闭源托管路径通常有服务端策略拦截与审计日志，团队可通过支持通道追溯；开源进程内路径则依赖团队自建的权限钩子，若插件直接调用系统API，框架层难以拦截。本文评述：事故类型学比事故数量更有指导意义，因为它直接对应兜底策略的落点——越权对应权限层，污染对应上下文层，漂移对应依赖层，三层需要不同的门禁设计。

5.3 一个可复用的观测指标集

为把上述讨论落到可度量层面，本文提出一组团队内可采集的观测指标（均为工程实践建议，非某产品官方指标）：插件崩溃率（每千次会话）、平均故障定位时长（MTTD）、回滚成功率、越权拦截率、上下文污染触发率。这些指标可在灰度期采集，用于校准后文的评估矩阵。

# 灰度期观测指标采集伪代码（示意）
metrics = {
  "plugin_crash_per_1k": crashes / sessions * 1000,
  "mttd_minutes": sum(detect_time) / incidents,
  "rollback_success_rate": success_rollbacks / rollbacks,
  "privilege_block_rate": blocked_calls / total_calls,
  "context_pollution_rate": polluted_sessions / sessions,
}
# 建议按周聚合，与基线对比后再决定是否扩大灰度

笔者认为，指标集的价值不在数字本身，而在于它迫使团队把“兜底”从感觉变成可比较的量。当两个候选工具在同一指标集下对比，选型讨论才能从立场之争转为成本之争。

六、操作路径：评估矩阵、灰度迁移与质量门禁设计

6.1 第一步：用二维矩阵给候选工具定位

评估矩阵的两个轴即可hack性与兜底性，各分四档（0–3分）。可hack性评分项：源码可见性、插件加载位置、协议可替换性、调试接口深度；兜底性评分项：SLA覆盖率、审核链路强度、运行时隔离度、社区响应时延。每项由两名以上工程师独立打分后取中位数，减少个人偏好。

本文评述：矩阵的用途不是排名，而是暴露取舍。若两个候选在矩阵上处于不同象限，团队应明确“我们愿意用多少可hack性换多少兜底性”，并把这一判断写入选型纪要，作为后续争议的裁决依据。

6.2 第二步：灰度迁移的三阶段路径

阶段一（影子模式）：新工具只读不写，对同一任务生成建议但不执行，与现有工具输出做diff。此阶段目标是校准行为可观测粒度，采集MTTD基线。阶段二（受限执行）：开放低风险仓库的写权限，启用权限钩子与自动回滚，插件必须通过CI测试。阶段三（全量）：在指标稳定后扩大范围，同时保留旧工具的降级开关。

笔者认为，灰度路径的关键不是阶段数量，而是每个阶段的退出条件必须可量化。例如阶段二退出条件可设为“连续两周插件崩溃率低于阈值且回滚成功率高于95%”。没有量化退出条件的灰度，实质上是无限期试运行。

6.3 第三步：质量门禁的四个落点

权限门禁：所有工具调用经统一代理，按仓库与命令白名单放行，进程内插件不得绕过。上下文门禁：长会话定期压缩并做一致性检查，防止污染累积。依赖门禁：智能体引入的第三方包须经SBOM扫描与许可证检查。回滚门禁：每次写操作前生成快照，失败自动回滚并记录。

本文评述：四个门禁对应前文三类事故加一类恢复能力，构成兜底性的工程实现。对选择DSH路径的团队，门禁是必选项而非可选项；对选择Claude Code路径的团队，门禁可适当简化，但仍需保留权限与回滚两层，因为供应商兜底不覆盖团队自身的误用。

七、对比与局限：张力曲线的边界条件

本文主线成立的前提是：团队具备基本的工程验证能力，且故障后果可分级。若团队规模极小、无专职平台工程师，可hack性带来的收益难以兑现，兜底性权重应上调；若团队处于研究探索期，需要频繁修改调度逻辑，则可hack性权重上调，但必须接受稳定性波动。

局限之一是指标主观性。可hack性与兜底性的评分依赖团队判断，不同团队对同一工具的评分可能差异较大。缓解办法是引入外部校准：参考社区issue响应数据、公开SLA文本与第三方安全评估，减少纯主观打分。局限之二是协议演进的不确定性。MCP与A2A仍在快速迭代，今天“协议内可替换”的假设可能因规范变更而失效。

本文评述：张力曲线不是静态的，它会随协议标准化程度与托管服务供给移动。当开源工具也能买到商业托管兜底时，曲线会向右上方平移，二元对立进一步弱化。因此选型结论应设定复核周期，而非一劳永逸。

八、结论与展望：从“选工具”到“设计责任拓扑”

回到标题的问题：按“谁更可hack”选，还是按“谁在出问题时有人兜底”选？本文的答案是：先设计责任拓扑，再选工具。责任拓扑指团队明确哪些故障自担、哪些外包、哪些通过门禁消解，并据此在张力曲线上取点。工具只是拓扑的载体，不是拓扑本身。

展望未来，三个趋势值得关注：协议层继续标准化，使可hack性从“改源码”转向“换实现”；托管服务供给增加，使开源工具也能获得兜底；评估工具链成熟，使兜底性从定性判断走向可观测指标。笔者认为，最终胜出的不是“最开放”或“最精致”的工具，而是最能被团队责任拓扑容纳的工具。

可操作的收尾建议：本周内完成候选工具的二维矩阵打分；两周内跑通影子模式并采集基线指标；一个月内确定门禁落点与灰度退出条件。把这三件事做完，选型讨论就有了可比较的锚点。

主要参考文献与拓展资源

文章声明

本文内容仅为作者学习、思考、经验、笔记的总结，仅供技术交流与参考。文中观点仅代表笔者个人思辨，不构成任何学术建议、商业建议或专业建议。所有数据来源已标注，引用时请以原始文献为准。