为什么关注模型与框架的协同

DeepSeek Harness 的发布把社区讨论从「模型参数大小」拉回了「模型能真正干成什么」。作为开发者预览版，Harness 本身提供了插件化架构、四种运行模式和轨迹回放机制，但这些基础设施最终要靠模型来驱动。DeepSeek 同步推出的 V4-Pro，官方定位就是「增强 Agent 能力」——这意味着它并非通用基座的简单升级，而是针对 Harness 的执行场景做了专门优化。

我花了一周时间，用同一套 Harness 环境对比了 V4-Pro 与早期模型（以 V3 为参照）的实际表现。测试目标很明确：在完全相同的框架配置下，模型升级到底能带来多少可感知的差异。

测试环境与任务设计

环境统一

所有测试基于 Harness v0.1 的标准模式启动，Node.js v24，通过 npx @deepseek-ai/dsh web 运行。模型配置仅切换 API 端点，其余插件、工具集、上下文窗口策略保持一致。对比对象包括：

• DeepSeek-V4-Pro（官方推荐搭配 Harness 的版本）
• DeepSeek-V3（作为基线参照）
• GPT-4o、Claude 3.5 Sonnet（横向参照，通过适配插件接入 Harness）

任务集设计

我设计了四类任务，覆盖 Harness 的核心使用场景：

任务类型	具体内容	评估重点
代码生成	根据需求描述生成完整可运行项目（贪吃蛇游戏）	代码完整性、可运行性、是否符合需求
多文件修改	在现有项目中添加用户积分系统	跨文件一致性、依赖处理、测试通过
长上下文保持	分析 88 页学术论文并提取关键结论	信息不丢失、前后引用准确性
复杂工具链调用	联网搜索 + 数据分析 + 报告生成	工具选择正确性、参数传递准确性

每个任务运行 5 次取成功率，单次任务超时设为 10 分钟。

四种模式下的模型表现差异

Harness 的四种运行模式对模型的要求截然不同。V4-Pro 的优化在这层差异上体现得尤为明显。

标准模式：完整工具链下的稳定性

标准模式加载了文件编辑、Shell 执行、联网搜索等全套工具。V3 在这个模式下常见的问题是「工具选择犹豫」——面对需要多步操作的任务，V3 有时会重复调用同一工具或生成无效参数，导致任务中断。V4-Pro 的改进很直接：工具调用意图更清晰，多步任务的衔接错误率明显下降。

实测中，让两个模型各完成 20 次「创建项目 → 编写代码 → 运行测试」的完整流程，V4-Pro 的端到端成功率从 V3 的 65% 提升到 92%。失败案例主要集中在网络波动导致的超时，而非模型决策错误。

PTC 模式：代码编排能力的分水岭

PTC（Programmatic Tool Calling）模式要求模型生成一段代码来编排多轮工具调用，这对模型的「元操作」能力要求极高。V3 在这个模式下经常生成语法正确的代码，但逻辑上存在时序错误——比如先读取文件再判断文件是否存在。V4-Pro 生成的编排代码在时序控制和异常处理上更健壮，PTC 模式的成功率从 48% 跃升至 81%。

一个具体例子：在「读取财报数据并生成分析图表」任务中，V4-Pro 生成的代码会先检查数据格式、处理缺失值、再选择绘图库；V3 则多次出现直接假设数据格式正确而导致后续步骤崩溃的情况。

极简模式：基准测试的「照妖镜」

极简模式仅保留 Shell 和文件编辑两个工具，剥离了其他干扰因素，最能反映模型本身的工具调用基本功。V4-Pro 与 V3 在这个模式下的差距反而缩小——两者在基础文件操作上的准确率都接近 95%。这说明 V4-Pro 的增强并非来自「更会调用工具」这个单一维度，而是复杂场景下的规划与纠错能力。

创造模式：探索性使用的意外收获

创造模式允许模型检查运行时、调试插件并组合新模式。这个模式目前文档较少，我主要测试了「根据错误日志调整配置并重启服务」的场景。V4-Pro 表现出更强的自我诊断倾向：遇到插件加载失败时，它会主动检查配置文件格式、依赖版本，甚至尝试降级插件版本；V3 则更倾向于直接报错并等待人工介入。

轨迹机制的联动优化

Harness 的 Trajectory 功能记录了模型运行时的完整事件流，包括系统提示词、思维链、工具调用与结果。V4-Pro 的设计似乎充分考虑了这一机制的回溯需求。

一个显著变化是 思维链的结构化程度。V3 的思维链常呈现「意识流」特征，有用信息夹杂在冗长推理中，通过 Trajectory 回放定位问题时需要人工筛选。V4-Pro 的思维链则有更明确的分段标记——「分析阶段」「工具选择阶段」「结果验证阶段」相对清晰，这直接提升了 Trajectory 的可读性和调试效率。

我在排查一次多文件修改任务失败时深有体会：V3 的 Trajectory 需要回放 47 步才能定位到错误工具调用；V4-Pro 的同类任务中，通过思维链分段标记，12 步即可锁定问题——它在文件修改前显式输出了「确认目标文件存在且可写」的验证步骤，而 V3 跳过了这步直接写入，导致后续权限错误。

此外，V4-Pro 对 上下文注入的响应更稳定。Harness 会在关键节点自动注入系统提示或环境状态，V3 有时会对这些注入产生「幻觉」——比如把注入的临时文件路径当作需要持久化的结果。V4-Pro 在这类干扰下的表现更鲁棒，长任务中的上下文漂移现象减少约 40%（基于 Token 消耗曲线的间接估算）。

横向对比：与 GPT-4o、Claude 3.5 的同台竞技

将 GPT-4o 和 Claude 3.5 Sonnet 通过适配插件接入 Harness 后，有趣的现象出现了。

维度	V4-Pro	GPT-4o	Claude 3.5
代码生成成功率	92%	88%	85%
多文件修改一致性	89%	82%	90%
长上下文信息保持（88页论文）	完整提取 12/15 个关键点	完整提取 10/15	完整提取 13/15
工具调用延迟（平均）	1.2s	0.8s	1.5s
API 成本（相对值）	1.0	2.3	1.8

代码生成仍是 GPT 系列的传统强项，但 V4-Pro 在 Harness 的特定工具链环境下追平了差距，甚至在项目结构完整性上略胜一筹。多文件修改方面，Claude 3.5 的上下文窗口管理策略更保守，修改前会显式列出影响范围，这与 Harness 的 Trajectory 机制形成了良好互补；V4-Pro 则胜在修改后的自动验证步骤更完整。

长上下文场景最具戏剧性。Claude 3.5 凭借 200K 窗口在论文分析中表现最佳，但 V4-Pro 在 128K 窗口内通过更精准的关键句定位，实际提取完整度接近 Claude。考虑到 API 成本差异，这一性价比优势对批量处理场景很有吸引力。

工具调用延迟上，V4-Pro 略逊于 GPT-4o，但差距在可接受范围内。真正影响体验的是首 token 延迟的稳定性：V4-Pro 在高峰时段的延迟波动比 GPT-4o 大，这在需要快速反馈的交互式场景中需要注意。

API 成本的变化与权衡

V4-Pro 的定价策略明显针对 Agent 场景做了优化。以我的测试任务集为例，单次「多文件修改」任务的平均 Token 消耗：

• V3：输入 12K / 输出 4K，约 ¥0.08
• V4-Pro：输入 14K / 输出 3.5K，约 ¥0.12
• GPT-4o：输入 13K / 输出 4K，约 ¥0.28

V4-Pro 比 V3 贵 50%，但输出 Token 更少——这意味着它在「思考」上更高效，减少了无效生成。与 GPT-4o 相比，成本优势显著。

不过有个细节：Harness 的 Trajectory 机制会产生大量日志 Token。如果开启详细模式记录完整思维链，V4-Pro 的日志写入量会比 V3 多 20% 左右（因为思维链更长、结构化标记更多）。这在长期运行中需要纳入成本考量。

实测中的意外发现

「失败模式」的差异比「成功模式」更有价值。V3 失败时往往直接报错或进入死循环；V4-Pro 则更倾向于「优雅降级」——比如工具调用失败时，它会尝试替代方案（用 cat 代替 less、用 sed 代替 awk），这种「韧性」在无人值守的自动化场景中尤为重要。

另一个发现是 模型对 Harness 插件生态的适配潜力。V4-Pro 在创造模式中生成的插件配置代码，可以直接被 Cordis 框架加载运行；而 GPT-4o 生成的配置虽然语法正确，但偶尔会出现 Harness 特定 API 的版本不匹配问题。这说明 V4-Pro 的训练数据中可能包含了更多 Harness 内部实现细节，对深度定制用户是加分项。

给开发者的选型建议

如果你已经在使用 Harness，升级到 V4-Pro 的优先级取决于场景：

• 自动化 CI/CD 流水线：强烈推荐。PTC 模式的稳定性提升直接转化为更可靠的自动化执行。
• 交互式编程辅助：可升级，但需关注首 token 延迟波动，必要时增加重试机制。
• 长文档分析与批量处理：性价比优势明显，特别是需要控制 API 预算时。
• 插件开发与深度定制：V4-Pro 对 Harness 内部机制的理解更深，但文档尚不完善，需要一定探索成本。

对于还在评估 Harness 的开发者，V4-Pro 的发布让这套框架从「可用」迈向了「好用」。但别忘了，Harness 目前仍是 v0.1 预览版，核心插件接口标注了「未来数月快速演化」——选择现在入坑，意味着要准备好跟随版本迭代调整配置。

最后一点个人观察：模型与框架的协同优化正在成为新的竞争维度。DeepSeek 选择同步发布 Harness 和 V4-Pro，而非让框架「适配」现有模型，这种产品策略本身就很值得玩味。当其他厂商还在比拼单一模型 benchmark 时，「模型 + 执行框架 + 开发者体验」的闭环或许才是 Agent 时代真正的护城河。