模型决定智能上限，Harness 决定这种智能能否稳定、安全、可解释地转化为生产结果。
引言：为什么"套个壳"远远不够
2026 年，AI Coding Agent 已经从"能帮你补全代码"进化到"能独立完成工程任务"。但当你仔细拆解这些系统时会发现一个反直觉的事实：真正决定 Agent 能否在生产环境可靠工作的，不是模型本身，而是模型之外的 Harness 系统。
以 Claude Code 为例，逆向分析显示只有约 1.6% 的代码是 AI 决策逻辑（API 调用 + 响应解析），98.4% 是确定性基础设施------权限门禁、上下文管理、工具路由、错误恢复、会话持久化。DeepSeek Harness 更是把这个理念推到极致：连 Agent Loop 本身都是一个可替换的插件。
本文基于对 Claude Code 和 DeepSeek Harness 两套生产级系统的深入分析，提炼出 AI Agent Harness 的核心工程问题和设计范式。这不是两个产品的功能对比，而是关于如何让概率模型在真实世界中持续、安全、可恢复地工作的系统工程讨论。
一、Harness 到底在解决什么问题
一个最小的 Agent 实现只需要：
vbscript
while not done:
response = call_model(context)
if response.has_tool_calls:
results = execute_tools(response.tool_calls)
context.append(results)
else:
return response.text但进入真实产品后，你会发现这个循环远远不够。它没有回答：
| 问题域 | 具体挑战 |
|---|---|
| 启动与边界 | 这次运行用什么模型、什么工具、什么权限？谁决定的？能被覆盖吗？ |
| 上下文治理 | 200K token 窗口怎么分配？长任务产出百万 token 怎么办？ |
| 行动安全 | 模型要执行 rm -rf / 怎么拦？谁有权批准？ |
| 状态连续 | 进程崩了怎么恢复？中断后文件还在原来状态吗？ |
| 完成判定 | 模型说"完成了"，真的完成了吗？测试跑了吗？ |
| 多端协作 | CLI、IDE、Web、SDK 怎么共享同一套执行语义？ |
Harness 就是回答这些问题的完整系统。它位于用户/应用、模型与真实执行环境之间，负责：
- 组合配置------决定每次运行的能力和边界
- 构造上下文------在有限窗口内提供有效工作集
- 调度执行------把模型意图变成安全的真实动作
- 管理状态------让长任务能中断、恢复、分叉
- 判断完成------用证据而非自然语言确认任务结束
二、两种设计哲学：极致可组合 vs 极致确定性
DeepSeek Harness："Everything is a Plugin"
DeepSeek Harness 以 Cordis 为运行时骨架，把一切都做成可替换插件------包括 Agent Loop 本身。
scss
Cordis Kernel (极小核心)
├── Model Adapters (deepseek-v4 / claude / openai-compatible)
├── Tools (file / shell / web-search)
├── Sessions (会话状态 --- 也是插件)
├── Sandboxes (隔离执行 --- 也是插件)
├── Loops (Agent 循环策略 --- 也是插件!)
└── Storage (持久化 --- 也是插件)Cordis 核心只做三件事：生命周期管理、插件依赖解析、上下文传播。关键创新是"可逆性"------每个插件产生的副作用都被跟踪，卸载时自动清理。这意味着你可以在运行时安全地热替换一个有问题的工具插件，而不影响其他能力。
Claude Code："Thin Brain, Thick OS"
Claude Code 走了另一条路：极简主循环 + 极厚基础设施。
核心 while-loop 信任模型做所有规划决策，不做显式 DAG 或状态机。但围绕这个循环，构建了层层确定性保障：
- 7 种权限模式 + ML 风险分类器
- 5 层渐进式上下文压缩
- 动态工具池（内置 + MCP + 条件加载）
- JSONL 追加式会话轨迹
- Sub-agent 上下文隔离
- Hooks 生命周期拦截
- Managed Settings 企业策略
为什么不做显式规划？ Anthropic 的判断是：模型自带规划能力（Extended Thinking），确定性规划器反而会限制模型。而且模型升级后自动获得更好的规划，不需要改 Harness 代码。
本质区别
arduino
DeepSeek Harness 回答: "如何让【任何模型】变成可靠的 agent？"
→ 它是一个操作系统内核
Claude Code 回答: "如何让【Claude 模型】安全地在用户电脑上做事？"
→ 它是一个产品应用三、上下文工程：Agent 的认知供应链
模型看到的不是全部事实，而是一个精心构造的投影
这是 Harness 区别于普通 Chat 封装的核心。它不是把"所有已知信息"塞进请求，而是把不同生命周期的信息编译成当前工作集。
| 信息类型 | 加载时机 | 生命周期 | 目的 |
|---|---|---|---|
| System Prompt | 每次请求 | 产品级 | 角色、协议、行为约束 |
| 项目指令 (CLAUDE.md) | 会话启动 | 仓库级 | 架构规范、构建命令、团队规则 |
| 工具 Schema | 每次请求前缀 | 运行时 | 告诉模型能做什么 |
| 会话历史 | 累积 + 压缩 | 当前 Session | 因果链和工作进展 |
| 长期记忆 | 按相关性召回 | 跨会话 | 项目经验和稳定偏好 |
| Skills | 被调用时 | 按需 | 完整领域知识和工作流 |
关键设计约束：知识、能力、历史必须分层。
把三类信息都塞入 System Prompt 会导致：固定前缀过大、无关知识长期占 Token、工具 Schema 爆炸、权限边界不清。
五层压缩：在信息保真与预算之间的受控折中
Claude Code 的 5 层 Compaction Pipeline 是上下文工程的教科书：
yaml
Layer 1: 源头截断
单次工具返回 > 50K chars → 模型摘要替换原始结果
Layer 2: 工具结果压缩
旧的 file reads / shell output / grep 结果优先回收
Layer 3: 对话压缩
早期 user/assistant 来回被 AI 摘要替代
Layer 4: Sub-agent 隔离
重型探索消耗 100K+ tokens，只返回结论（几百 tokens）
Layer 5: 自动压缩触发
接近窗口限制时全局压缩，用户无感继续核心思想：Context 不是 Transcript 的同义词，而是从完整事实和持久状态中构造出的当前认知工作集。
DeepSeek 的方案：事实追加，视图派生
DeepSeek Harness 把"耐久事实"与"模型当前可见视图"分离。Session Event Log 保留全量证据，Surface 用摘要节点替换一段可见历史：
bash
持久事件 (append-only) → 支持审计、恢复、回放
↓ derive
当前 Surface → 经过 replace/shadow 后的模型可见视图
↓ project
模型请求 → 实际提交给 LLM 的消息日志保留全量证据，压缩只改变视图投影。这意味着你可以从任意历史点 fork、resume 或 replay，而不会丢失原始信息。
Prompt Cache 反向塑造架构
一个不直观但极其重要的约束：
逻辑上等价的动态重排，可能因为破坏缓存前缀而显著增加成本。
因此，工具池变化必须兼顾稳定排序；新增信息应放在后缀或按需加载，而不是频繁改变公共前缀。性能约束在反向塑造架构设计。
四、工具执行：从模型意图到受控现实
模型只是提出请求，Harness 才拥有执行权
这是整个系统的因果边界：
模型输出 tool_use → 行动尚未发生
Harness 执行工具 → 行动才真正发生
Harness 返回 tool_result → 模型获得观察一次工具调用的完整管线：
markdown
模型提出调用
→ Schema 校验（参数结构是否正确）
→ 语义校验（路径是否在工作区内）
→ PreHook（可修改输入或阻止）
→ 权限判定（当前主体是否获准）
→ 执行 handler
→ PostHook（可审计或追加处理）
→ 结果标准化 + 大小限制
→ 配对 tool_result 写回消息三个检查不能混为一谈： Schema 判断格式、语义校验判断环境适用性、权限判断授权。它们必须依次发生。
并发：不是简单的 Promise.all
typescript
function executeToolBatch(toolCalls):
batches = partitionByConurrency(toolCalls)
for batch in batches:
if batch.isConcurrencySafe: // 纯读取
results = runWithLimit(batch.calls, maxConcurrency)
else: // 写操作
results = runSerially(batch.calls)
// 关键：结果按模型原始调用顺序提交
yieldEach(results)无论并发还是串行，结果都按原始调用顺序产出。这同时获得吞吐与可回放确定性。
Capability Seam：同一工具，不同后端
DeepSeek Harness 的 Capability Seam 把一个能力拆成三个角色：
| 角色 | 包含什么 | 不应该包含什么 |
|---|---|---|
| Service Definition | 接口、参数、返回值、错误契约 | 具体实现 |
| Provider | 本地/沙箱/远程的具体实现 | 业务编排 |
| Consumer | 工具对能力的使用 | 对某个 Provider 的硬编码 |
这意味着同一个 Read/Write/Bash 工具逻辑，可以在本地、Docker 沙箱或远程 E2B 环境中运行，只需要替换 Provider。
五、安全控制：不能只靠 Prompt 说"请不要"
Claude Code：多层正交防御
| 控制机制 | 回答的问题 | 强制点 |
|---|---|---|
| 工具可见性 | 模型是否知道这项能力 | 工具组装阶段 |
| Deny/Allow Rules | 某工具/资源是否明确禁止或允许 | 规则引擎 |
| Permission Mode | 默认自主性和交互策略 | 会话级 |
| Auto Classifier | 此动作是否需要人工确认 | 独立 ML 回路 |
| Hooks | 组织是否要阻止/记录/追加审批 | 生命周期事件 |
| Sandbox | 即使执行，最多影响哪些资源 | OS 级隔离 |
| Managed Settings | 企业要求是否不可覆盖 | 最高优先级配置 |
关键认知：权限回答"是否同意执行"，Sandbox 回答"实际最多能影响什么"。二者正交。
DeepSeek Harness：Capability-Based Security
bash
Plugin A 声明需要:
cap:fs:read(/workspace/*)
cap:shell:exec(git, npm)
Runtime 授权:
✓ fs:read /workspace/src/main.ts
✗ fs:read /etc/passwd (未授权路径)插件只拥有被显式授予的 capabilities。这是最小权限原则的编程语言级实现------工具插件不能访问超出其声明范围的资源，即使它运行在高权限进程中。
Auto Mode：第二个模型回路
Claude Code 内部可能同时存在两个模型：
- 主模型：决定要做什么
- 权限分类模型：判断动作能否自动执行
分类器降低确认疲劳（不用每次都点批准），但不应成为唯一安全边界。两个模型的目标、延迟和错误代价完全不同。
六、状态连续性：四种状态不能混淆
长任务能够持续运行，靠的不是模型一直"记得"，而是 Harness 把不同生命周期的状态分别保存。
| 状态类型 | 保存什么 | 恢复特点 |
|---|---|---|
| 消息事实 | tool_use / tool_result / 用户输入 / 模型输出 | 强调因果完整 |
| 模型工作视图 | 系统提示 + 摘要 + 最近历史 | 每轮根据预算重新投影 |
| 持久工作状态 | 任务、依赖、计划、验收标准 | 不随上下文压缩消失 |
| 执行实体状态 | Shell / 后台任务 / 子 Agent | 有独立状态机 |
| 外部环境状态 | 文件 / Git / 数据库 / 云资源 | 不因恢复 JSONL 自动回到原状态 |
一个关键边界： 恢复会话轨迹（JSONL），不代表恢复真实世界。Resume 后，Harness 必须重新核对重要的外部事实。
完成判定：模型停止不等于任务完成
当模型不再发出工具调用时，可能是：
- 任务确实完成了
- 忘记验证了
- 缺少权限
- 没看见后台结果
- 把局部成功误认为整体完成
因此，"模型准备结束"只能触发一次候选停止，真正的出口需要 Completion Gate：
- 是否仍有未完成的 Task？
- 是否仍有测试/后台任务在运行？
- 是否有待处理的权限请求？
- Stop Hook 是否提出新的阻断条件？
- 关键结论是否有与任务类型匹配的完成证据？
| 任务类型 | 典型完成证据 | 仅有文本为什么不够 |
|---|---|---|
| 代码修改 | 文件差异 + 测试通过 | 代码可能未写入或不可运行 |
| 外部写入 | 返回对象 ID + 回读确认 | 请求发出不代表落库成功 |
| 审批流程 | 审批实例终态 | 创建流程不等于流程通过 |
七、扩展生态：不是一个插件接口能解决的
Claude Code 的扩展体系不是一个万能插件接口，而是一组处于不同生命周期、上下文成本和强制等级的接入面：
| 需求 | 更合适的接入面 | 原因 |
|---|---|---|
| 每轮必须知道的规范 | CLAUDE.md | 启动加载，持续可见 |
| 仅某类文件适用的规范 | Rules | 条件加载，降低无关上下文 |
| 偶尔使用的领域知识 | Skill | 按需进入上下文 |
| 调用外部系统 | MCP | 提供真实外部动作 |
| 每次改文件后强制扫描 | Hook | 确定性执行 |
| 大量搜索但只需结论 | Sub-agent | 独立上下文，摘要返回 |
| 跨团队发布整套能力 | Plugin | 组合、版本和分发 |
扩展分层是系统完整性的重要体现，不能简化成"它支持插件"。
八、多 Agent 协作：不是开更多线程那么简单
五种并行模式各有边界
| 模式 | 上下文 | 文件隔离 | 典型用途 |
|---|---|---|---|
| Sub-agent | 独立，摘要返回 | 可选 worktree | 研究、验证 |
| Background Task | 任务内异步 | 不隔离 | 长命令 |
| Agent View | 多个独立会话 | 可结合 worktree | 同时委派多个独立任务 |
| Agent Team | 独立，可互发消息 | 不自动隔离 | 需要协调的依赖任务 |
| Worktree/Batch | 独立会话 | 是 | 并行代码修改 |
三种隔离维度必须分别设计
- 上下文隔离：不同 Agent 不共享完整会话历史
- 能力隔离：不同 Agent 获得不同工具和权限
- 环境隔离：不同 Agent 使用独立 worktree 或容器
Sub-agent 主要解决前两项，Worktree 解决第三项。Team 增加通信协调，但不自动完成环境隔离。
多 Agent 不是 Harness 成熟度的简单倍增器。 任务可分解性和结果合并成本决定其实际价值。
九、从对比中提炼的设计原则
| 原则 | 体现 | 通用意义 |
|---|---|---|
| 模型与执行器分离 | Tool Use 与真实执行分离 | 不让概率模型直接拥有副作用 |
| 知识、能力、历史分层 | CLAUDE.md / Skill / MCP / Session | 避免所有内容长期塞入 Prompt |
| 概率指导、确定性强制 | Prompt 对比 Rules/Hook/Sandbox | 关键边界不能只靠自然语言 |
| 状态追加、视图压缩 | JSONL / Compact / Sidechain | 保留轨迹，动态构造工作集 |
| 恢复属于正常流程 | Transition / Fallback / 有限重试 | 故障处理可测试、可预算 |
| 稳定前缀优先 | Tool 排序 / Cache / 延迟加载 | 性能约束反向塑造架构 |
| 扩展按生命周期分层 | Skill / MCP / Hook / Agent / Plugin | 不用万能接口承载全部责任 |
| 并行与隔离分开 | Agent 协作 + Worktree 文件隔离 | 明确上下文、能力和环境三维度 |
| Harness 必须单独评测 | Feature Gate / OTel / Ablation | 不把系统效果全部归因于模型 |
十、战略判断与适用边界
DeepSeek 赌 "Harness is the Moat"
- 模型能力会趋同
- 但 production-grade 的 agent runtime 有巨大工程壁垒
- 开源生态网络效应一旦形成，很难被取代
- 类比：Linux kernel 本身不赚钱，但围绕它的生态价值万亿
Claude Code 赌 "Model is the Moat"
- 只要模型持续领先，harness 只需"把模型伺候好"
- System prompt 与模型的深度耦合是竞争壁垒
- 终端用户不关心架构是否优雅，只关心"能不能帮我写好代码"
- 类比：iPhone 不需要开放硬件接口，靠体验赢
适用场景判断
| 如果你要... | 更适合的方向 |
|---|---|
| 在生产中部署 agent 服务 | 可组合运行时（DSH 风格） |
| 个人日常编码提效 | 深度调优产品（Claude Code 风格） |
| 需要完整审计链 | Event Sourcing + append-only log |
| 需要多模型降本 | 模型无关适配层 |
| 追求单一场景极致体验 | 模型锁定 + prompt 深度耦合 |
| 构建企业级 Agent 平台 | 多层配置作用域 + Managed Settings |
结语：下一个十年的基础设施
将 Coding Agent 描述成"会改代码的 AI"没有错，但远远不完整。更准确的判断是：
当前的 AI Agent 系统正在把 Coding 场景中验证过的模型运行、能力执行、状态连续性和策略治理机制，产品化为跨本地、云端和嵌入式应用的智能运行时。
它最值得投入的不是某个隐藏 Prompt，也不是某个工具或循环，而是如何让一个概率模型在真实世界中持续工作，同时保持可控、可恢复、可扩展和可治理。
模型能力在快速趋同。Harness 工程------这些看不见的 98.4%------才是下一个阶段真正的竞争壁垒和基础设施。
本文基于 2026 年 8 月对 Claude Code (生产版) 和 DeepSeek Harness (v0.1 Developer Preview) 的架构分析。分析综合官方文档、开源代码、第三方研究论文和历史版本材料。
参考资料：
- Jiacheng Liu et al., "Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems" (arXiv 2604.14228), 2026
- DeepSeek Harness Official Architecture Documentation
- Cordis: A Programming Paradigm for Spatiotemporal Composability (Paper Draft, 2026-08-13)
- Claude Code Official Documentation (code.claude.com)
- VILA-Lab 46-page Reverse Engineering Analysis