Deep Agents vs DeepSeek Harness（DSH）

发布时间：2026-08-22来源：智见AGI

研究对象	版本
LangChain Deep Agents	0.7.7
DeepSeek AI DeepSeek Harness	0.1.0-rc.8

根据McKinsey 2025年《The state of AI》数据，23%的组织正在至少一个业务职能中扩展Agent应用，另有39%已开始实验。但Gartner预测，到2027年底，超过40%的Agentic AI项目可能因成本、价值或风险控制不足而被取消（前提是未建立持续治理与价值衡量机制）。与此同时，Stanford HAI的《2026 AI Index》显示，当前最佳Agent在OSWorld上的准确率约为66.3%，距离人类基线（72.4%）仍差不足6个百分点。实验遍地开花，规模化的坎却横在那里。主要矛盾已经从“能不能做”转向了“能不能可靠地进生产”。这一背景下，技术选型不能只看GitHub Star这类热度指标，更要看生产可靠性、治理成本和长期维护能力。

图1: 《2026 AI Index》中OSWorld结果图

Deep Agents 与 DSH 面向的是截然不同的场景，谈不上谁更先进，关键看需要解决什么问题。

评测 / 对比目标与维度

为什么对比？

Deep Agents 与 DSH 都致力于让大模型完成长周期、多步骤的 Agent 任务，但技术哲学和主要目标不同。

Deep Agents 提供 batteries-included 的 Agent 应用层 Harness，重点解决如何让业务团队更快构建可进入生产流程的 Agent的问题。DSH 官方定位仍是 Agent Harness，但从架构上更接近可组合 Agent Runtime，将 Agent Loop、Session、Tools、Filesystem、Sandbox 等能力放入 Cordis plugin / service composition 中，重点解决如何让 Agent Runtime 本身可替换、可组合。

对比的核心是：在什么约束条件下，哪种架构带来的工程投入、长期维护成本和生产风险更合理。

评估维度与验证方式

评估维度	关键问题	验证方式
开发效率（易用性）	从零到可工作 Agent 需要多少代码与理解成本	Quickstart、SDK、API 抽象层次
运行时自由度（可扩展性）	能否替换 Loop / Session / Tool / Backend / 调度逻辑	官方架构文档、源码扩展点
上下文工程能力	长任务如何控制上下文膨胀	Summarization / Offload / Subagent Isolation
状态持久化与恢复	任务中断后能否恢复、Fork、Replay	LangGraph Checkpoint / DSH SessionEvent
可观测与评测基建	是否具备系统化回归测试与轨迹评估	Eval Suite、Benchmark、Tracing
成本基线	Harness 固定输入、工具并发等是否有公开量化数据	官方 Release、源码参数、Benchmark 文档

验证过程与数据表现

开发效率与 API 抽象层次

Deep Agents 的 Quickstart 只需几行核心代码即可启用默认 Harness：

from deepagents import create_deep_agent
agent = create_deep_agent(model="openai:gpt-5.5", tools=[my_tool])
result = agent.invoke({"messages": "Research LangGraph"})

默认能力覆盖 filesystem、subagents、context management 等长任务常用机制，Subagent 可通过声明式字典定义，普通业务开发者通常无需先理解 LangGraph 内部执行图。

DSH 的 Python SDK Facade 同样提供了相对简洁的入口：

from deepseek_harness import DeepSeekHarness
with DeepSeekHarness() as harness:
    result = harness.run("Say hi.")

Python SDK 通过 JSON-RPC stdio 驱动 bundled runtime，最简单调用并不要求业务开发者直接理解 Cordis。但当需要深度扩展 Tool、Loop、Session、Filesystem、Sandbox 等能力时，通常需要理解 Cordis plugin/service/effect 模型。

在替换Agent行为的场景下，两者路径不同。以“自定义Agent提前终止条件”为例：Deep Agents目前通过中间件机制即可实现常见提前终止逻辑（如jump_to="end"），无需重写底层LangGraph图结构；若涉及超出中间件能力范围的图结构深度改造，则需下沉至LangGraph层。DSH则通过替换Loop插件实现，改造路径直接作用于运行时。两者的改造成本取决于团队对LangGraph图模型与Cordis插件模型的熟悉程度，并非简单的行数对比。

上下文工程与 Token 成本基线

Deep Agents v0.7 官方发布说明给出一项明确数据：base input tokens（system prompts + tool descriptions）减少 65%。官方同时说明：新 prompt 结构降低了固定基础输入，Todo List 默认被移除，原因是内部 Eval 显示 Todo List 增加成本和延迟，但没有带来相应性能收益。

DSH 目前未在官方公开资料中找到与 Deep Agents 类似的固定输入优化数据。社区实践表明，通过特定插件（如dsh-mcp-lens）在特定场景下可实现显著成本节省。该数据来源于第三方作者自己的3-task pilot，测试环境为DSH rc.6，在该试点中，DeepSeek V4 Flash的预估成本从$0.0307204降至$0.0034707，请求头中的工具JSON数据量从674,249字节减少到27,401字节。

状态持久化、Fork 与 Replay

这部分是两者最重要的架构差异之一。

机制	Deep Agents / LangGraph	DSH
核心状态模型	Checkpoint-based graph state	Event-sourced SessionEvent log
持久化	Checkpointer / Store	Append-only event log + persistence
Replay	原生支持：从历史 checkpoint 重新执行后续节点	原生支持：从 session event stream 重新派生状态和模型历史
Fork	原生支持：从历史 checkpoint 修改状态后创建新分支	原生支持：Session fork / derived replay
审计语义	Checkpoint + LangSmith trajectory	SessionEvent 本身构成 runtime trajectory

两者的适用边界需进一步明确：

Deep Agents的Checkpoint机制在图状态规模极大（例如长时间运行积累的大量消息上下文）时，序列化与恢复延迟会随之增加；其恢复性能高度依赖配置的Checkpointer实现。
DSH的SessionEvent在超长会话时，事件流的存储与快照构建开销会累积。

运行时自由度

运行时组件	Deep Agents 自由度	DSH 自由度
Agent 主循环 (Loop)	受限。需“下沉”到 LangGraph 重写。	完全。Loop 本身是可替换的插件。
会话 (Session)	受限。与 LangGraph State 绑定。	完全。Session 是可替换的插件。
工具 (Tool)	高。通过中间件或直接添加。	完全。工具注册表本身是插件。
后端 (Backend)	高。支持可插拔后端。	完全。后端/沙箱是插件。
调度逻辑 (Scheduler)	受限。内置于 LangGraph。	完全。Agent Loop可替换，调度策略可通过Loop插件间接定制。
核心理念	分层架构，通过中间件扩展，必要时下沉。	微内核架构，一切皆插件，无特权核心。

可观测与评测基建

Deep Agents 有专用 libs/evals，每个用例调用真实 LLM 并记录 trajectory；集成 FRAMES、Nexus、BFCL v3、MemoryAgentBench、Terminal Bench 2.0 等外部 Benchmark，评分指标覆盖 correctness、step_ratio、tool_call_ratio、solve_rate、median_duration_s；生产可观测性通过 LangSmith Tracing/Eval/Deployment 实现。

DSH 则需拆开评价：

Agent行为级评测/公开Benchmark：Deep Agents的资料库和公开标准化结果比DSH更完整。
Runtime内部质量：DSH在Runtime层面的单元测试、端到端回归测试、快照兼容性测试方面并不薄弱，其SessionEvent为未来建立Runtime-level trajectory evaluation提供了很好的数据基础
就当前公开的Agent任务求解率Benchmark结果而言，Deep Agents可核验的公开数据更丰富；DSH的公开结果目前仍较有限。

适用边界与局限性

在技术选型层面，Deep Agents 与 DSH 有着截然不同的适用场景和设计取舍。两者并非同层竞争，Deep Agents 是 Application-oriented Harness，DSH 是 Runtime-oriented Composable Harness。

Deep Agents的优势在于对小型团队和快速验证极为友好。默认Harness封装了上下文管理、子代理调度和文件系统交互，开箱即用；深度研究、RAG和长文本总结等任务能力成熟，与LangSmith生产链路集成完备。对于未来三到六个月有核心生产上线需求的团队，其兼容性风险明显低于仍处于发布候选阶段的框架。

局限同样不容回避。一旦需要深度定制Agent执行图结构（非中间件可覆盖的改造），就必须下沉到LangGraph层，上层Harness的封装价值随之大幅折损。更深层的架构分歧在于运行时事实模型：如果系统从一开始就要求事件日志作为不可变的事实源，所有模型历史派生自事件流，那么Deep Agents基于检查点的持久化模型将无法匹配。

DSH的优势面向平台级场景。目标是构建企业级Agent Runtime或平台底座，DSH在主循环、会话、工具、文件系统和沙箱等核心能力上均提供架构层面的替换点。事件溯源基因使其天然适配强审计、时间旅行和状态重建。

DSH的适用前提同样清晰：它的深度运行时灵活性，对只需知识检索、网页搜索和报告生成等常规能力的团队是负担而非优势。深度扩展需要掌握Cordis插件机制、生命周期管理、服务依赖注入、事件模型和组合模式等概念——这本身就是平台工程能力的一部分。更关键的是，DSH仍处预览（pre-release）阶段。官方明确声明不提供任何兼容性承诺。监管所需的审计、合规删除等企业级能力也需在框架外补齐。追求长期稳定的生产系统，当前不建议将DSH作为核心依赖绑定。

选型与落地建议

核心问题	建议
快速把 Agent 做成产品	Deep Agents
做企业 Deep Research / RAG	Deep Agents
未来 3–6 个月进入核心生产	Deep Agents（锁版本 + 回归测试）
做 Coding Agent	两者真实 workload A/B
把Agent Runtime做成平台底座	DSH重点PoC（但做好RC版本频繁变动的心理准备）
替换 Agent Loop	DSH（需投入Cordis学习成本）
研究Agent OS / Event-Sourced Runtime	DSH
有专职平台团队	两者并行：业务生产走 Deep Agents，Runtime 研究走 DSH

结论

Deep Agents和DSH两套框架并非同层竞争。Deep Agents是Application-oriented Harness，DSH是Runtime-oriented Composable Harness。Deep Agents的成熟度来自LangGraph生态、上下文工程、子代理、文件系统、记忆、人机回环和LangSmith，更适合业务Agent、RAG、知识助手、PoC和短期生产。DSH的价值在可组合性——“一切皆插件”的Cordis架构、可替换的Loop、事件溯源会话和显式工具契约，更适合平台底座、自定义Runtime和调度研究。

回到开头的数据：62%的参与度与23%的规模化率之间的差距，以及Gartner预测的40%取消率，意味着现阶段大多数团队的核心矛盾是“尽快可靠地交付业务价值”而非“定义下一代Runtime范式”。因此，应用团队从Deep Agents起步更稳妥；平台团队值得拿DSH做PoC，但必须清醒认识到RC阶段的兼容性断层风险。

近期生产选Deep Agents风险更低，但需锁版本并做回归测试；长期可关注DSH的架构方向。核心问题不是谁更强，而是——你主要是在开发一个 Agent 应用，还是把 Agent Runtime 本身当作你的产品与差异化能力？

参考文献

Deep Agents 代码 2026
DeepSeek Harness 代码 2026
Stanford HAI 2026
McKinsey 2025
Gartner, Agentic AI Project Cancellation Forecast 2025

转载说明：本文系转载内容，版权归原作者及原出处所有。转载目的在于传递更多行业信息，文章观点仅代表原作者本人，与本平台立场无关。若涉及作品版权问题，请原作者或相关权利人及时与本平台联系，我们将在第一时间核实后移除相关内容。