最近 DeepSeek Harness 开源时我真正感到好奇的不是它又多了一个 CLI 或 Web 界面而是另一个问题一套近期公开的前沿 Agent 框架在真实工程里到底怎样运行模型会思考、会生成、会调用工具这些已经不稀奇。困难在于当它真的要处理一个长期任务时谁来决定它看见什么、能做什么、留下什么证据、失败后怎样继续以及新能力怎样安全地加入系统这些“模型之外的世界”才是我想通过 DeepSeek Harness 研究的对象。这不是一篇产品评测本文不试图判断 DeepSeek Harness 是否“国内第一”也不准备把它当成某个产品的替代品。它只是一个非常适合解剖的工程样本代码、架构文档、测试、CLI、Web、ACP、沙箱、工具、会话和子 Agent 都集中在同一个公开仓库里。我们要做的是借这个样本回答一个更通用的问题一个 LLM 怎样被组织成可运行、可扩展、可恢复、可治理的 Agent Runtime如果这个问题能够被吃透未来无论做代码助手、发布验证、运维排障、知识服务还是工作流自动化底层判断框架都可以复用。先把几个容易混淆的词放在正确的位置概念它解决什么问题例子LLM提供理解、推理和生成能力DeepSeek、GPT、ClaudeAgent围绕任务使用模型、状态和外部能力的执行者规划、检索、调用工具、处理结果Coding Agent专门处理软件工程任务的一种 Agent 形态Claude Code、CodexHarness / Agent Runtime让 Agent 稳定运行的工程底座工具调度、会话、权限、沙箱、恢复、观测、扩展DeepSeek Harness一套具体的开源 Harness 实现也提供若干可运行装配dsh web、dsh --profile headless最关键的区分是Coding Agent 是一种面向软件开发的 Agent 产品形态Harness 是用来构建和运行多种 Agent 的工程底座。DeepSeek Harness 同时提供底座和若干现成装配因此很容易让人把两者混为一谈。本系列会先把 Coding Agent 当作经典样本因为它把文件、终端、测试、权限和子任务等复杂问题集中暴露出来。但研究终点不是 Coding Agent而是通用 Agent Runtime。三个任务同一组难题想象三个任务代码任务定位失败测试修复并验证。 发布任务新版本上线后服务异常收集证据并判断问题环节。 知识任务根据手册与历史问答回答问题证据不足时升级给人工。它们使用的业务工具不同却都需要回答相同的问题此刻模型到底看到了哪些上下文哪些工具可以调用哪些操作需要拒绝或询问工具结果、错误和人工决定如何回到下一次推理运行被取消或进程重启后状态如何恢复新能力接入时如何不破坏既有运行单靠 Prompt 无法持续解决这些问题。模型负责推理Runtime 则负责把推理转化为受控行动并保存它发生过的事实。我希望从研究中得到的四种能力这套研究不以“读了多少文件”为完成标准而以四种可证明能力为标准能力证明方式讲清楚脱离资料解释架构、关键状态和设计取舍追得动从一次输入追到模型、工具、事件、持久化和结果改得对知道新能力应挂在哪个扩展点而不是硬改 Agent Loop造得出独立实现一个缩小版机制并说明与 DSH 原设计的差距前三项保证不是“看懂了”第四项才证明理解已经能够迁移。研究方法不从目录开始而从问题开始每个专题都会走同一个闭环真实现象或工程问题最小实验或可观察行为源码与测试追踪技术博客解释闭卷复述与反向设计D1 / D7 复习文章中的结论会标明来源SOURCE表示源码直接事实DOC表示维护者文档TESTED表示本机验证INFERENCE表示在证据之上的工程理解。这样以后回看时不会把猜测、博客说法和已验证行为混在一起。这趟研究会怎样展开第一阶段先看系统怎样被装配出来Profile、Bundle、Patch、Cordis Loader 和插件生命周期。随后才进入一条任务的黄金链路理解 Agent Loop、Session Event Log、Tool Runtime、权限与沙箱。在主链路打通之后再研究 Context/Skill/Compaction、Code Mode、Workflow、Subagent、ACP 以及产品化的测试和发布体系。最后回到自己的项目从 DSH 中选择真正适合业务问题的机制而不是复制它的产品外观。完整路线如下研究动机与概念边界 → Runtime 装配 → 插件生命周期 → Agent Loop → Session 与上下文 → Tool / Policy / Sandbox → Compaction / Code Mode / Subagent → 产品化工程 → 个人项目迁移这一篇应该留下什么如果读完本文只记住一句话就够了DeepSeek Harness 值得研究不是因为它让模型“更聪明”而是因为它展示了如何把模型放进一个可以控制、恢复、审计和扩展的工程系统。下一篇才正式进入源码一次dsh启动时Profile、Bundle、Patch 与 Loader 如何把一套通用 Runtime 装配出来。闭卷自测LLM、Agent、Coding Agent、Harness 和 DeepSeek Harness 的区别是什么为什么发布验证 Agent 和 Coding Agent 会需要同一类 Runtime 能力“讲清楚、追得动、改得对、造得出”分别如何证明 DeepSeek Harness _ 研究理念
最近 DeepSeek Harness 开源时我真正感到好奇的不是它又多了一个 CLI 或 Web 界面而是另一个问题一套近期公开的前沿 Agent 框架在真实工程里到底怎样运行模型会思考、会生成、会调用工具这些已经不稀奇。困难在于当它真的要处理一个长期任务时谁来决定它看见什么、能做什么、留下什么证据、失败后怎样继续以及新能力怎样安全地加入系统这些“模型之外的世界”才是我想通过 DeepSeek Harness 研究的对象。这不是一篇产品评测本文不试图判断 DeepSeek Harness 是否“国内第一”也不准备把它当成某个产品的替代品。它只是一个非常适合解剖的工程样本代码、架构文档、测试、CLI、Web、ACP、沙箱、工具、会话和子 Agent 都集中在同一个公开仓库里。我们要做的是借这个样本回答一个更通用的问题一个 LLM 怎样被组织成可运行、可扩展、可恢复、可治理的 Agent Runtime如果这个问题能够被吃透未来无论做代码助手、发布验证、运维排障、知识服务还是工作流自动化底层判断框架都可以复用。先把几个容易混淆的词放在正确的位置概念它解决什么问题例子LLM提供理解、推理和生成能力DeepSeek、GPT、ClaudeAgent围绕任务使用模型、状态和外部能力的执行者规划、检索、调用工具、处理结果Coding Agent专门处理软件工程任务的一种 Agent 形态Claude Code、CodexHarness / Agent Runtime让 Agent 稳定运行的工程底座工具调度、会话、权限、沙箱、恢复、观测、扩展DeepSeek Harness一套具体的开源 Harness 实现也提供若干可运行装配dsh web、dsh --profile headless最关键的区分是Coding Agent 是一种面向软件开发的 Agent 产品形态Harness 是用来构建和运行多种 Agent 的工程底座。DeepSeek Harness 同时提供底座和若干现成装配因此很容易让人把两者混为一谈。本系列会先把 Coding Agent 当作经典样本因为它把文件、终端、测试、权限和子任务等复杂问题集中暴露出来。但研究终点不是 Coding Agent而是通用 Agent Runtime。三个任务同一组难题想象三个任务代码任务定位失败测试修复并验证。 发布任务新版本上线后服务异常收集证据并判断问题环节。 知识任务根据手册与历史问答回答问题证据不足时升级给人工。它们使用的业务工具不同却都需要回答相同的问题此刻模型到底看到了哪些上下文哪些工具可以调用哪些操作需要拒绝或询问工具结果、错误和人工决定如何回到下一次推理运行被取消或进程重启后状态如何恢复新能力接入时如何不破坏既有运行单靠 Prompt 无法持续解决这些问题。模型负责推理Runtime 则负责把推理转化为受控行动并保存它发生过的事实。我希望从研究中得到的四种能力这套研究不以“读了多少文件”为完成标准而以四种可证明能力为标准能力证明方式讲清楚脱离资料解释架构、关键状态和设计取舍追得动从一次输入追到模型、工具、事件、持久化和结果改得对知道新能力应挂在哪个扩展点而不是硬改 Agent Loop造得出独立实现一个缩小版机制并说明与 DSH 原设计的差距前三项保证不是“看懂了”第四项才证明理解已经能够迁移。研究方法不从目录开始而从问题开始每个专题都会走同一个闭环真实现象或工程问题最小实验或可观察行为源码与测试追踪技术博客解释闭卷复述与反向设计D1 / D7 复习文章中的结论会标明来源SOURCE表示源码直接事实DOC表示维护者文档TESTED表示本机验证INFERENCE表示在证据之上的工程理解。这样以后回看时不会把猜测、博客说法和已验证行为混在一起。这趟研究会怎样展开第一阶段先看系统怎样被装配出来Profile、Bundle、Patch、Cordis Loader 和插件生命周期。随后才进入一条任务的黄金链路理解 Agent Loop、Session Event Log、Tool Runtime、权限与沙箱。在主链路打通之后再研究 Context/Skill/Compaction、Code Mode、Workflow、Subagent、ACP 以及产品化的测试和发布体系。最后回到自己的项目从 DSH 中选择真正适合业务问题的机制而不是复制它的产品外观。完整路线如下研究动机与概念边界 → Runtime 装配 → 插件生命周期 → Agent Loop → Session 与上下文 → Tool / Policy / Sandbox → Compaction / Code Mode / Subagent → 产品化工程 → 个人项目迁移这一篇应该留下什么如果读完本文只记住一句话就够了DeepSeek Harness 值得研究不是因为它让模型“更聪明”而是因为它展示了如何把模型放进一个可以控制、恢复、审计和扩展的工程系统。下一篇才正式进入源码一次dsh启动时Profile、Bundle、Patch 与 Loader 如何把一套通用 Runtime 装配出来。闭卷自测LLM、Agent、Coding Agent、Harness 和 DeepSeek Harness 的区别是什么为什么发布验证 Agent 和 Coding Agent 会需要同一类 Runtime 能力“讲清楚、追得动、改得对、造得出”分别如何证明