DeepSeek Harness实测：开源Agent运行时的真实体验

当DeepSeek-V4-Pro正式版发布的同时，另一项开源项目也悄然登场——DeepSeek Harness。这个被社区期待已久的项目，究竟是DeepSeek版本的Codex，还是另有定位？经过对源码和产品的深度实测，我发现了一些与预期不太一样的答案。

架构解析：模块化的Agent运行时

从源码结构来看，DeepSeek Harness更像是一个可定制的Agent运行时平台，而非开箱即用的终端编码工具。它提供了Web coding agent、Headless模式、Python SDK、ACP和JSON-RPC等多种接入方式，模型、工具、会话、权限、沙箱、Agent Loop和UI都可以拆解重组。这种"一切皆插件"的设计理念，为开发者预留了充足的定制空间。

社区反馈的两极分化

仓库采用TypeScript monorepo架构，核心层包括：Agent Loop负责驱动Turn/Step执行，Session管理追加式事件日志，Tools处理工具注册与执行，System Prompt组装各Prompt片段。底层依赖Cordis插件生命周期框架，使得Loop、Provider、Session和UI都采用同一种插件组合模型。这意味着即使替换底层的模型提供方或执行环境，上层的工具层也能保持相对稳定。

从社区反馈来看，用户关注点呈现明显分化：一部分开发者期待成熟的桌面App和终端体验，关注日常编码效果；另一部分内测者则更看重插件、Preset、Trajectory和运行时自修改能力。两边都没看错——DSH确实同时具备这两个身份，只是完成度不对称。默认产品的交互体验尚未追赶上Claude Code或Kimi Code，但其运行时开放程度确实值得称道。

Trajectory功能获得了社区一致好评。它将Agent执行过程的时间轴、每轮请求和日志完整呈现，开发者可以清晰看到模型在每一步调用了哪些工具、token和缓存如何变化、任务为何结束。这种透明度的关键在于：DSH要求模型看见的内容必须已经记入日志，Trajectory直接从session event log投影，而非另埋一套监控数据——这使得轨迹更接近模型当时收到的真实请求。

同模型不同Harness：执行路径的显著差异

为验证Harness对最终产物的影响，我使用同一模型（Kimi K3）、相同提示词和验收标准，对比DSH minimal与Kimi Code的执行轨迹。结果显示：两道测试题两边都通过了，但执行路径差异显著。Kimi Code倾向于首轮并行读取后整文件写入，工具调用更精简；DSH minimal则在persistent bash与编辑器之间来回切换，步骤更碎但上下文更可控。 进一步测试中，我让两个Harness各用V4 Pro开发一款"跳一跳"游戏。最终产物呈现出不同风格：Kimi Code版本偏向全屏游戏体验，DSH版本更像带完整信息区的Web页面。这印证了一个有趣的现象：同一模型、同一Prompt，Harness会参与塑造最终产物。

如有侵权，请联系删除。