DeepSeek Harness深度解析：自进化Agent架构的核心设计

从模型到运行时：Agent进化的第五步

当大多数人还在讨论「大模型+几个工具」如何完成任务时，DeepSeek Harness（简称DSH）却把注意力从模型本身转向了模型之外的运行环境。据B站UP主的深入研究分析，DSH很可能不是一个随处可见的普通Agent产品，而是指向下一代Agent架构的一种全新方式。

Agent（智能体）是AI领域中指代具有自主决策和行动能力的系统。与传统的「输入-输出」式大语言模型不同，Agent能够感知环境、制定计划、调用工具并根据反馈调整行为。2023年以来，随着GPT-4、Claude等大模型能力的飞跃，Agent成为AI应用层最热门的方向之一。AutoGPT、BabyAGI等早期项目展示了Agent的基本形态，但它们普遍面临可靠性差、上下文管理混乱、工具调用不稳定等问题。这些问题的根源往往不在模型本身，而在于模型之外的运行时架构——这正是DSH试图解决的核心问题。

它关注的核心问题很底层：如果AI在执行任务的过程中需要新工具、新规则，甚至需要更换一整套工作方式，那么到底是「谁」来改变它的运行环境？DSH的答案不是让模型突然拥有自我意识，而是把模型「装进」一个可以持续运行、可以变化、可以重新组合的系统里。

AI能否改造自己的运行环境

这里的「自己改造自己」需要谨慎理解——它既不是模型像人一样觉醒意识，也不是模型立刻能重写全部代码。更准确的理解是：一个AI系统能否在运行过程中改变自己所处的工作环境。

比如它原本只有一个工具，后来增加了第二个；原本只能看到当前对话，后来能看到一整段任务记录；原本的规则发生了变化，下一步就按新规则执行。如果这些变化都能被系统统一管理，那么AI就不再是「问一次答一次」，而是拥有了一个会持续变化的运行时。

这里的「运行时」（Runtime）是计算机科学中的基础概念，指程序在执行期间所依赖的环境和基础设施。例如Java程序需要JVM（Java虚拟机）作为运行时，JavaScript需要浏览器引擎或Node.js。运行时负责内存管理、资源调度、异常处理等底层工作。DSH将这一概念引入Agent领域，意味着AI Agent不再是一段「跑完就结束」的脚本，而是拥有了一个持续存在、可以动态调整的执行环境。正如不同的运行时决定了同一段代码的执行行为和能力边界，不同的Harness也决定了同一个模型能表现出的智能水平。

核心公式：智能 = Model + Harness

DSH提出了一个关键判断：智能 = Model + Harness。

模型（Model）只做三件事：理解我们说了什么、进行判断、提出下一步想做什么。但模型本身并不天然拥有工具、文件权限、任务记录，也不知道上一步造成了什么影响。这就像一个很聪明的人被关在空房间里，没有资料、没有电话、没有工具，他的才智很难影响真实世界。

而Harness就是这个人的工作环境和工作系统——它负责把工具放进来、把任务存下来、把规则告诉模型、把模型的动作放到真实环境里执行，再把结果带回来。

加号背后的动态循环

这里的「加号」不是简单的数学相加，而是一个动态循环：首先模型决定下一步做什么，然后Harness负责让这一步真实发生，并让结果进入下一步的输入。

这也解释了为什么DSH不是一条固定的循环——它更关心这条循环本身能不能被拆开、替换、在运行过程中被重新组合。有AI专家在被问及「Harness是否是AGI的充要条件」时回答：大概率不是，但很可能是重要的组成部分。

Agent进化的五个阶段

DSH背后有一条清晰的概念演进时间线，它描述的不是产品发布顺序，而是「Harness」这个概念如何被逐层构建出来：

• 第一步：模型。最初我们只有模型，它给你一段文本、一个答案（如日常与豆包对话）。
• 第二步：工具调用。给模型装上工具后，它可以行动——读文件、调接口、影响外部事件。
• 第三步：状态管理。任务不止一步，系统必须记住刚才做了什么、结果如何、哪里出错。
• 第四步：Harness整合。把模型、工具、记录长期组织在一起，处理权限、规则、循环、错误和不同工作方式。
• 第五步：自主进化。系统不仅完成任务，还能改变承载任务的工具、规则和运行方式。

说个细节：DSH并未完成自进化，而是在搭建自进化的基础设施。目前绝大多数工具（包括Claude Code）仍停留在第四步，而DSH明显在探索第五步的可能性。

Harness的三层结构

要理解Harness的工作原理，需要拆解三个核心概念层次：

模型层、Harness层与环境层

• 模型层：负责判断「下一步应该干什么」。
• Harness层：负责把想法变成动作，检查工具或权限是否有资格调用，以及调用结果写到哪里。
• 环境层：真实的用户工作环境，可能包含文件、网络、数据库或其他系统。

举个例子：模型需要读取一个文件。Harness先确认当前任务有没有读文件的能力、这个文件可读吗；然后环境真正给出结果——文件存在或不存在；最后结果回到Harness，进入模型的下一步输入。

所以Agent不是一条孤零零的循环，而是模型、运行环境和外部世界共同组成的完整系统。

组件化的工程设计

DSH做了一个关键的工程选择：不把所有能力焊死在一个超级核心里，而是将能力做成独立组件（可理解为运行时中的功能插件）：

• Model Adapter：将不同模型统一接入
• 工具注册：声明当前可用的工具集合
• System Prompt：把角色、规则、背景组织成模型能理解的说明
• Session Log：保存任务过程中发生的所有事件
• Agent：单步单轮对话处理
• Agent Loop：常见的ReAct循环，不断观测环境、推进任务

ReAct（Reasoning + Acting）是2022年由普林斯顿大学和Google研究团队提出的Agent推理框架。其核心思想是让大语言模型在执行任务时交替进行推理（Reasoning）和行动（Acting）：模型先思考当前状态和下一步计划，然后执行一个具体动作（如调用API、搜索信息），观察执行结果后再进入下一轮推理。这种循环使模型能够根据真实反馈不断修正策略，而非一次性给出所有答案。ReAct已成为当前主流Agent框架（如LangChain、AutoGen）的基础模式，但其局限在于循环结构通常是固定的——DSH在此基础上进一步探索循环本身是否也可以被动态重组。

这种组件化设计继承了软件工程中成熟的架构传统。插件化架构（Plugin Architecture）最早在Eclipse IDE、WordPress等系统中被广泛应用，核心思想是将系统功能分解为可独立加载和卸载的模块。依赖注入（Dependency Injection）则是Spring框架等企业级系统的核心设计模式，通过将组件的依赖关系外部化管理，实现松耦合和高可测试性。DSH的Codis机制结合了这两种传统——既支持插件的动态装卸，又通过Service和Context机制管理组件间的依赖关系。

这种组件化设计带来的好处是：模型可替换而不必重写整套逻辑；工具只在特定任务或范围内出现；提示词可按需组合；某个能力退出时系统能知道它留下了什么影响并清理干净。

Codis：让能力可装配可撤销的底层机制

插件如何装进系统？这依赖DSH的底层核心——Codis。用最直白的话说，Codis是一套在运行环境中可以装配、变化、收拾干净的底层机制。它不是业务逻辑，也不是大脑，而更像一个工作场所的管理系统，负责把各个部件协调在一起。

Codis的几个关键概念：

• 插件（Plugin）：一个功能组件，如读文件的能力、模型适配器
• Service（服务）：可理解为API接口，开放给其他部件调用
• 上下文（Context）：当前工作现场有哪些能力、规则、对象正在生效
• 事件（Event）：像工作场地里的一声铃，某事件发生后其他部件能听见并决定是否响应
• 效果（Effect）：部件进入系统后留下的变化——注册服务、增加监听、改配置

Codis最关键的一点是：这些变化不是加进去就完事，而是有机会撤销。当插件离开时，系统能把它产生的影响一并清除。

这种「变化可撤销」机制，对应的是软件工程中的事务性（Transactionality）概念。数据库系统通过ACID事务保证操作的原子性——要么全部成功，要么全部回滚。在分布式系统中，Saga模式通过定义每个操作的补偿操作来实现类似的可撤销性。Codis将这种思想应用到Agent的运行时管理中：每个插件进入系统时产生的所有Effect都被记录，插件退出时这些Effect可以被逆向清除。这在实际场景中至关重要——例如一个Agent在执行复杂任务时临时加载了一个具有文件写入权限的插件，任务完成后该权限必须被彻底回收，否则可能造成安全隐患。

用演唱会现场理解Codis

可以把Codis想象成临时搭建的演唱会现场管理系统：不仅要把设备搬进来，还要知道电线搭在哪里、监听音响在放什么歌，结束之后所有东西都要拆走、恢复原状。这就是Codis的核心价值——它处理的不再是空间上「怎么装」，而是时间维度上「什么时候加入、什么时候变化、什么时候退出」。

每一步都在重新生成当前世界

DSH最能体现其架构特点的地方，发生在每一次调用模型之前。

常见的Agent处理方式是：提示词是任务开始前写好的静态文件，工具列表也是固定的，后面只是不断往对话里追加内容。在当前主流Agent实现中，System Prompt（系统提示词）通常在对话开始时一次性设定，后续仅通过不断追加用户消息和助手回复来推进对话。这种方式的问题在于，随着对话轮次增加，早期的上下文信息可能因为Token窗口限制被截断，导致模型「遗忘」关键信息。此外，工具列表、权限规则等元信息在任务执行过程中可能已经发生变化，但静态提示词无法反映这些变化。模型看到的世界很容易变成「过去的快照」，无法反映最新状态。

而DSH的做法是：每一次请求模型之前，重新整理组织当前工作现场。它会检查当前任务记录是什么、现在有哪些规则和工具可用、前一步发生了什么、哪些能力和权限仍然有效，整理完后把一份全新的上下文说明交给模型。这种「每步重新生成上下文」策略，本质上是在每次模型调用前进行一次完整的状态快照——这虽然增加了计算开销，但确保了模型在每一步都基于最新、最准确的信息做决策。这种设计理念与React前端框架中的「每次渲染都是一个新快照」有异曲同工之妙。

动态上下文的三个变化维度

这里的上下文更像是「打印出来的当前工作说明」——环境变了、工具变了，说明也会跟着变。具体来说，变化连成一条链：

• 状态变化：工具返回结果、执行错误、中间事实都被记录，下一步不会遗忘
• 提示词变化：因为记录和环境已变化，下次给模型的说明也会重新组织
• 工具变化：可见工具随插件加载、任务范围、权限设置而动态改变

这就是所谓「自进化基础」的含义——它不是模型参数被重新训练，也不是凭空获取新知识，而是Harness改变了模型下一步能看到什么、能做什么、需要遵守什么规则。

结语：智能藏在模型之外

两句话概括DeepSeek Harness的核心价值：第一，DSH不是一个固定的Agent，而是一套可以重新组装能力的运行时系统；第二，Codis不是运行逻辑，而是让插件、服务、当前工作现场以及变化能够共存的底层基础设施。

如果压缩成一句话：模型决定想做什么，Harness决定如何让它存在。模型可以提出一个动作，但Harness决定这个工具执行会不会被记住、下一步能看到什么、任务结束能否干净收缩。

DeepSeek Harness真正有价值的地方，不是让Agent多做几个动作，而是把Agent背后的运行环境替换成了一个可以观察、可以改变、可以替换、也可以恢复的系统。至于AI会不会真正改造自己，仍是更远的问题——但从DSH和Codis的架构方向看，答案已经不藏在模型参数里，而藏在模型外面的那层Harness里。