评测背景：为什么关注 V4-Pro 的 Agent 加成

DeepSeek Harness 发布时，官方同步推出了配套增强模型 DeepSeek-V4-Pro。按照官方定位，这套组合的核心公式是 Model + Harness = Agent——模型负责理解与推理，Harness 负责将能力落地到真实环境。但一个关键问题始终存在：当 Harness 的插件架构、运行模式、工具调用链路完全固定时，换用不同底层模型，Agent 的实际表现究竟会差多少？

这次评测围绕三个核心维度展开：代码理解与多文件修改能力、长任务上下文保持、插件化架构适配与性价比。为了控制变量，所有测试均在同一套 Harness 配置下进行，对比对象包括 V4-Pro 和第三方模型 GLM5.2（后者在 Harness 的 Python SDK 文档中被官方示例采用，社区也有较多使用反馈）。

代码理解与多文件修改：项目级任务实测

SpringBoot 项目结构理解

Harness 的"极简模式"仅保留 Shell 与文件编辑工具，恰好能剥离 UI 插件的干扰，观察模型本身对代码结构的解析深度。测试任务为：向 Agent 提供一个标准 SpringBoot 项目目录，要求它理解分层结构并执行一项跨层修改——增加用户积分系统。

V4-Pro 的表现呈现出比较明显的"项目级"思维。它在 Trajectory 日志中展示的思维链显示，模型首先识别了 controller → service → mapper → entity 的分层惯例，随后主动检查了现有数据库表结构，再规划修改顺序。实际执行时，它能连续完成四项操作：修改 entity 新增积分字段、调整 mapper 的 SQL 映射、在 service 层补充业务逻辑、最后更新 controller 接口。整个过程中，Harness 的插件化工具调用链路没有被中断，模型对"下一步该调用哪个工具"的判断较为准确。

GLM5.2 在相同任务下则出现了两次"迷路"。第一次是在修改完 entity 后，模型尝试直接编译验证，但 Harness 的极简模式下未加载编译插件，导致报错后模型陷入循环重试；第二次是在 service 层修改时，模型遗漏了事务注解的添加，后续通过 Trajectory 回放才定位到问题。这并非 GLM5.2 的代码能力缺陷，而是它对 Harness 当前"可用工具集"的感知不够敏锐——换句话说，对插件化架构的适配深度有差距。

88 页论文翻译任务

社区曾有用户用 Harness 完成 88 页学术论文的翻译，耗时约 22 分钟。我们复现了类似场景：将 PDF 按章节拆分为文本片段，要求 Agent 逐段翻译并保持术语一致性。

V4-Pro 在长文本中的术语对齐表现更稳定。前 20 页建立的核心术语表（如 "attention mechanism" 统一译为"注意力机制"而非"关注机制"），在后 60 页中基本保持了一致，Trajectory 日志中仅出现 3 次人工干预修正。GLM5.2 则在第 40 页后出现了明显的术语漂移，同一技术词汇出现了两种以上译法，需要人工在对话中追加约束指令才能纠正。

这一差异可能源于 V4-Pro 在长上下文窗口中的记忆机制优化，也可能是 DeepSeek 针对 Harness 的 Trajectory 日志格式做了专门的上下文注入训练——毕竟 Trajectory 中"仅追加"的日志设计，对模型的长序列依赖能力提出了更高要求。

插件化架构适配：模型是否"懂"Harness

Harness 的 Cordis 插件架构有一个特点：模型本身不直接调用工具，而是通过生成结构化指令，由 Harness 的插件系统解析执行。这意味着模型需要理解 Harness 的"工具描述协议"——包括每个插件的能力边界、参数格式、以及工具间的组合逻辑。

在 PTC（程序化工具调用）模式下，这一要求被进一步放大。PTC 模式允许模型生成一段代码来编排多轮工具调用，而非逐轮等待用户确认。测试中发现，V4-Pro 生成的 PTC 代码对 Harness 的插件 API 兼容性更好：它能正确引用 ctx.tools 和 ctx.llm 的服务接口，生成的代码片段在 Cordis 的依赖注入机制下可直接运行。

GLM5.2 在 PTC 模式下则偶尔会出现"幻觉式"API 调用——即生成 Harness 插件体系中并不存在的工具名称，导致执行报错。这并非不可修复，但需要开发者在 Prompt 层做更多约束，或等待模型对 Harness 生态的适配更新。

更直观的差异体现在"创造模式"中。该模式允许模型检查当前运行时、在内存中试验 Cordis 插件并组合新运行模式。V4-Pro 能够基于现有插件的元信息，提出合理的组合方案（如"将 Shell 工具与联网检索插件串联，用于实时依赖检查"）；GLM5.2 则更倾向于描述概念性思路，而非输出可执行的插件配置代码。

Token 消耗与响应延迟：性价比的隐性成本

由于 Harness 的 Trajectory 日志完整记录了每次运行的原始事件，我们可以对比相同任务下的 Token 消耗模式。

在 SpringBoot 项目修改任务中，V4-Pro 的总 Token 消耗略高于 GLM5.2（约 15%-20%），但任务完成时间反而更短。原因在于 V4-Pro 的"一步到位"率更高：它在单轮对话中生成的工具调用序列更长、更完整，减少了多轮澄清和修正的次数。GLM5.2 虽然单轮 Token 更省，但多轮累积后总消耗差距缩小，且用户等待时间显著增加。

论文翻译任务则呈现不同格局。V4-Pro 在长文本中的术语一致性优势，大幅降低了后期人工干预和重复翻译的频率，整体任务流更顺畅。GLM5.2 虽然初始响应更快，但后期修正成本（包括人工时间和额外 Token）不可忽视。

需要强调的是，Harness 本身按 Token 计费，但 Agent 任务的总成本不能只看模型侧。一个频繁需要人工介入的模型，其隐性成本（注意力成本、时间成本）往往超过 Token 费用的差异。V4-Pro 与 Harness 的配套优化，核心价值或许正在于此。

评测局限与使用建议

当前测试基于 Harness v0.1 开发者预览版，插件生态和模型适配仍在快速迭代。几个实际使用中的注意事项：

• 工作区配置必须先行：Harness 的 Web UI 中，若未选择工作区（Workspace），输入框会呈灰色不可输入状态，这一设计对新手不够直观
• 端口占用问题：默认 3080 端口被占用时，可通过 dsh --profile web --port 8080 指定其他端口
• API Key 的存储安全：配置界面中 Key 以脱敏形式显示，实际明文存储于 ~/.dsh/.credentials.yaml，团队共享环境需注意权限管理

对于希望深度定制 Agent 运行时的开发者，V4-Pro 与 Harness 的配套优势在复杂任务中会逐渐显现；若只是快速尝鲜或执行简单单文件操作，第三方模型的体验差距并不悬殊。选择时更多应考虑任务复杂度与干预容忍度的平衡。