DeepSeek Harness与Codis架构解析：Agent开发迈向插件化时代

一个小时Star破2万，Harness凭什么？

DeepSeek 在 8 月 13 号放出的 Harness 项目，热度可以用"吓人"来形容。上线一个多小时 Star 数就突破 2 万，创下了 GitHub 历史上的增速记录；到第五天，Star 数已经冲到 14 万以上。官方给它的定位其实只是"开发者预览"（Developer Preview），但社区显然按捺不住，很多人已经把它当作正式公测来使用。

GitHub Star 数是开源社区衡量项目热度的核心指标之一。此前增速记录的保持者包括 DeepSeek-R1（发布首周即突破 10 万 Star）和 Meta 的 Llama 系列模型。一个项目一小时内获得 2 万 Star，意味着每秒有超过 5 个开发者点击了 Star 按钮，这种传播速度通常只在大型 AI 实验室发布里程碑式项目时才会出现。值得注意的是，Star 数的增速与社交媒体传播的病毒系数高度相关——Twitter/X 上的一条高转发推文可以在几分钟内带来数千 Star，而 Harness 一小时 2 万的增速意味着它在多个社交平台上同时引爆，这种传播模式在技术社区被称为"多平台共振效应"，此前只在 Auto-GPT（2023 年 3 月一周内从零到 10 万 Star）等少数项目上出现过。Developer Preview 阶段意味着 API 和接口规范尚未冻结，随时可能发生破坏性变更（breaking changes），但社区的提前涌入也说明开发者对 Agent 基础设施的需求已经到了迫不及待的程度。

项目已经完全开源，但真正值得深入探讨的，并不是这个惊人的 Star 数字，而是它背后所采用的 Codis 架构——这套架构可能正在改变 Agent 开发的底层逻辑。

Codis架构的起源：从聊天机器人框架长出来的设计基因

Codis 最早是国内聊天机器人框架 CodeC 的底座。要理解它为什么长成今天这个样子，得回到几年前 QQ 群和 Discord 里机器人的使用场景。

那时候群机器人的需求特别碎：群管理、点歌、抽卡、接小游戏 API……今天加个签到功能，明天接个天气查询，后天又嫌某个功能太吵想关掉。在国内，Koishi、NoneBot、HoshinoBot 等框架在 QQ 群机器人领域形成了独特的技术文化；在海外，Discord.js 和 discord.py 则主导了 Discord 生态。这些框架面临的共同挑战是：用户需求极度碎片化、插件之间可能产生冲突、运行时需要热更新而不能重启服务。正是这种高度动态、需求不断变化的环境，逼出了一个核心能力——每个功能都是可以随时拔下来的积木，拔掉之后留下的副作用还能干净地撤销。

Codis 的服务注入与依赖回滚机制，就是在这样的土壤里生长出来的。服务注入（Service Injection）是依赖注入（Dependency Injection）模式在运行时的动态化延伸。依赖注入最早由 Martin Fowler 在 2004 年的文章中系统化定义，其核心思想是将对象的创建和使用分离，Java 的 Spring 框架和 .NET 的 Unity 容器是最经典的实现。但传统的依赖注入有一个隐含假设：依赖关系在应用启动时确定后就不会改变。Codis 的服务注入打破了这个假设，允许在系统运行过程中动态地注册、替换和注销服务——这在技术上更接近于 OSGi（Open Service Gateway Initiative）规范中的动态服务模型，OSGi 最早是为 Java 嵌入式系统设计的模块化框架，后来被 Eclipse IDE 广泛采用。

依赖回滚（Dependency Rollback）则更进一步：当某个插件被卸载时，它所注册的服务、监听的事件、修改的状态都需要被干净地撤销，不留残余副作用。这在技术上类似于数据库事务的回滚机制，但应用在了插件的生命周期管理上。实现这一能力的关键在于对每个插件的副作用进行精确的追踪和记录——包括它注册了哪些服务、订阅了哪些事件、修改了哪些共享状态——从而在卸载时能够逆向执行所有操作。

这套设计初衷是为了应对聊天机器人的碎片化需求，但它解决的本质问题，恰恰和今天的 Agent 开发高度重合。

一切皆插件：Harness的内核哲学

Harness 把这套理念贯彻到底，主张"一切皆插件"：内核只负责三件事——加载、卸载、以及管理依赖关系。而模型、工具、沙箱、存储、调度、界面，全部都是插件。这个设计理念与 Codis 完全一脉相承。

Agent开发者一直在重复交的"学费"

过去两年，做 Agent 的团队几乎都在重复造轮子。会话怎么存、上下文怎么管、工具怎么注册、子任务怎么调度、崩溃怎么恢复、状态怎么回放——每一家都要从头写一遍。结果往往是：写得都差不多，而且还都不好用。

具体来说，Agent 开发框架在过去两年经历了爆发式增长。LangChain、AutoGen、CrewAI、MetaGPT 等框架各自定义了一套 Agent 的抽象方式，但它们在底层工程问题上的解法高度重叠。会话状态管理通常依赖 Redis 或 SQLite，上下文窗口管理需要自行实现截断和摘要策略，工具注册需要手动编写 JSON Schema，子任务调度则往往是硬编码的有向无环图（DAG）。

然而 DAG 调度存在根本性的局限：它要求任务之间的依赖关系在执行前就已完全确定。Apache Airflow、Prefect 等数据工程工具都以 DAG 为核心抽象，但 Agent 场景下，下一步执行什么往往取决于上一步的输出——这是一个动态决策过程，无法预先画好一张完整的 DAG 图。这也是为什么简单地将数据工程的 DAG 调度器移植到 Agent 框架中往往效果不佳。

更棘手的是崩溃恢复问题：一个运行了数小时的 Agent 如果中途失败，大多数框架只能从头重跑，因为中间状态没有被持久化。这些重复劳动消耗了大量工程资源，却没有产生差异化的竞争优势。

大家似乎默认，这些是 Agent 时代必须交的"学费"。但 Codis 的思路提出了一个更本质的判断：这些问题大部分其实是同一道题——即如何构建一个长期运行、需要动态组合能力、并且能优雅处理副作用的软件系统。

从这个视角看，它到底是聊天机器人还是编程 Agent，反而不是重点。底层的工程挑战是相通的，这也是为什么一套源自聊天机器人的架构，能够被用来支撑编程 Agent。

事件溯源设计：只追加不覆盖的会话日志

Harness 还做了一个关键设计：会话日志只追加、不覆盖。模型看到的系统提示、思维链、工具调用、子 Agent 调度，全部写进同一条事件流。恢复、分叉、检索、回放，用的都是这同一份流。

事件溯源（Event Sourcing）是一种源自领域驱动设计（DDD）的架构模式，最早由 Martin Fowler 等人系统阐述。其核心思想是：不存储实体的当前状态，而是存储导致状态变化的所有事件序列。当前状态可以通过重放事件序列来重建。这种模式在金融交易系统、审计系统中已有广泛应用。

事件溯源通常与 CQRS（Command Query Responsibility Segregation，命令查询责任分离）模式配合使用。CQRS 将数据的写入（命令）和读取（查询）分离为不同的模型，使得系统可以针对不同的访问模式进行独立优化。在 Agent 场景下，写入端是事件的追加（工具调用结果、模型推理输出等），读取端则是多种视图——调试界面需要完整的事件时间线，上下文管理器需要最近 N 轮的摘要，计费系统需要 token 消耗的聚合统计。事件溯源 + CQRS 的组合让这些不同的读取需求可以从同一份事件流中派生，而不需要维护多套冗余数据。

在 Agent 场景下，事件溯源的价值尤为突出：Agent 的每一次工具调用、每一轮思维链推理、每一个子任务分派都是一个事件。当 Agent 执行失败或需要调试时，开发者可以精确地回溯到任意时间点，查看当时的完整上下文。更重要的是，事件流天然支持"分叉"操作——从某个历史节点创建一个新的执行分支，尝试不同的策略，而不影响原有的执行路径。这与 Git 的分支模型有异曲同工之妙。

这种"事件溯源"式的设计，让 Agent 的状态管理变得干净而可追溯——任何时刻都能回到某个节点重新分叉，也能完整回放整个执行过程。这正是复杂 Agent 系统最难啃的骨头之一。

配置层替换能力：垂直领域Agent开发的新范式

Harness 最具想象力的地方在于：开发者不用改源码，在配置层就能替换能力。

举个例子，只要更换文件系统的提供方，bash 终端、语言服务就会一起搬到远程沙箱。子 Agent 提供方也是同一个接口——背后既可以是新建的子智能体，也可以把整个任务直接甩给另一个产品来完成。

这种配置层替换能力的本质是控制反转（Inversion of Control, IoC）原则在 Agent 领域的极致应用。在传统软件工程中，Spring 框架通过 IoC 容器让 Java 应用实现了组件的声明式装配，极大降低了企业级应用的开发复杂度。Harness 将类似的理念引入 Agent 开发：文件系统、终端、语言服务等能力都被抽象为"提供方"（Provider）接口，开发者只需在配置文件中声明使用哪个提供方的实现，框架就会自动完成依赖的组装和连接。例如，将文件系统提供方从本地切换为远程沙箱时，所有依赖文件系统的组件——bash 终端需要在远程执行命令，语言服务需要在远程分析代码——都会自动跟随迁移，开发者无需修改任何业务逻辑代码。

这意味着什么？做医疗、法律或特定工业软件 Agent 的团队，不用再从零搭建骨架。他们要做的，是在一棵已经跑通的树上，替换掉几个和自己领域相关的插件。这大幅降低了垂直领域 Agent 的开发门槛。

Harness与Claude Code、Codex的关键区别

当然，项目目前还处于 Developer Preview 阶段，这意味着兼容性还会不断变化，一些第三方工具还很难一次跑通，token 消耗也不算低。

和 Anthropic 的 Claude Code、OpenAI 的 Codex 相比，Harness 最大的不同在于：它是完全开源的，插件可替换。这不是一个封闭的、你只能使用的产品，而是一个可以被拆解、重组、扩展的工程底座。

具体来说，Anthropic 的 Claude Code 采用的是端到端优化策略，模型能力与工具调用深度耦合，用户获得的是一个高度打磨的编程助手体验，但无法替换底层模型或自定义工具链。OpenAI 的 Codex 则更偏向 API 服务化，通过云端沙箱执行代码任务，但其执行环境和调度逻辑对用户来说是黑箱。两者的共同特点是：你可以使用它们，但不能拆解和重组它们。

Harness 的开源插件化路线意味着开发者可以将 DeepSeek 的模型替换为其他开源模型（如 Qwen、Llama），可以将沙箱从 Docker 切换为 WebAssembly——WebAssembly 沙箱是近年来容器化技术的重要补充，与 Docker 容器相比，Wasm 沙箱的启动时间通常在毫秒级（Docker 为秒级），内存占用更小，且安全边界由 Wasm 运行时的线性内存模型保证，Fastly、Cloudflare 等边缘计算平台已经大规模使用 Wasm 作为函数执行环境。对于 Agent 场景，Wasm 沙箱的快速启动特性尤其重要：一个 Agent 可能在一次任务中需要执行数十次代码片段，如果每次都启动一个 Docker 容器，累积的启动延迟将严重影响用户体验。开发者还可以将存储从本地文件系统切换为云端对象存储——这种灵活性对于需要私有化部署或满足数据合规要求的企业场景尤为关键。

真正的革命：从搭地基到拼积木

综合来看，Harness 真正可能引发的革命，并不是它成为"最强 Agent"，而是它把 Agent 的开发方式从"一遍遍搭地基"，转变为"可以拼接和替换的工程生态"。

如果这条路走通，那么未来垂直领域 Agent 之间的竞争，拼的将不再是谁的底层骨架写得更漂亮，而是谁的领域插件做得更好、更专业。骨架成为公共基础设施，价值则向领域知识和插件生态迁移。

从软件产业的历史规律来看，当基础设施层标准化之后，价值往往会向生态层迁移。WordPress 的插件生态、VS Code 的扩展市场、Kubernetes 的 Helm Chart 仓库，都遵循了这一演化路径。如果 Harness 的插件架构成为事实标准，那么未来可能出现一个 Agent 插件市场：医疗领域的团队发布符合 HIPAA 合规要求的病历分析插件——HIPAA（Health Insurance Portability and Accountability Act）是美国医疗数据隐私保护的核心法规，要求所有处理受保护健康信息（PHI）的系统必须满足严格的访问控制、审计追踪和数据加密要求，当 AI Agent 处理医疗数据时，HIPAA 合规不仅要求数据不出境、加密存储，还要求每一次数据访问都有完整的审计日志，这恰好与事件溯源架构天然契合；法律领域的团队发布判例检索和合同审查插件；工业领域的团队发布 PLC 控制和传感器数据解析插件。类似地，欧盟的 GDPR、中国的《个人信息保护法》也对 AI 系统处理个人数据提出了类似的可追溯性要求，开源、可私有化部署的架构是满足这些合规要求的前提条件。

竞争焦点将从"谁能搭出一个能跑的 Agent"转变为"谁的领域插件更精准、更可靠"。这种范式转移的深远影响在于：它可能让数量庞大的垂直领域专家——即使不具备深厚的 AI 工程能力——也能参与到 Agent 生态的建设中来。

这或许才是这个项目值得关注的深层意义——它试图把 Agent 开发从各自为战的重复劳动，推向一个标准化、模块化、可协作的工程新阶段。