为什么 DeepSeek Harness 敢让 AI 自己改自己？
- URL: https://mp.weixin.qq.com/s/VgUUmeb27DW-wcP04t9pqA
- Date Saved: 2026-08-14
- Source: WeChat (黑客下午茶)
- Tags: ai-engineering, dev-tools
- Repo: https://github.com/deepseek-ai/deepseek-harness
Summary
基于论文《A Programming Paradigm for Spatiotemporal Composability》拆解 DeepSeek Harness 的核心架构 — 如何让 agent 在运行时安全地自我修改。
核心问题
一个能持续生成、替换自己模块的 agent，最怕改到负责恢复自己的组件。“动态组合”一直没有数学地基。
架构设计：一切皆插件
- 模型适配器、工具注册表、会话日志、agent 循环本身都是插件
- 底层框架叫 Cordis（论文就是它的设计文档）
- Harness 把 Cordis vendored（源码级内嵌），可审计、可打补丁
两个正交维度的解法
时间维度 — 可逆效应（Revertible Effects）
- 每个副作用操作自带逆操作（撤销键）
- 运行时记录所有撤销键，卸载模块时 LIFO 回滚
- 源码：
ctx.effect(function*() { yield 撤销键 }) - 即使中途崩溃，generator 自动回滚已 yield 的撤销键
空间维度 — 响应式协效应（Reactive Coeffects）
- 模块声明”我提供什么”+ “我需要什么”
- 系统维护依赖表：依赖齐 → 激活，依赖缺 → 停用
- 源码：
extends Service提供服务 +ctx.inject([...])声明依赖
最漂亮的定理
无论经历多少次装载/卸载/替换/回滚，最终状态 = 从零按最终配置静态装配一次的状态。→ agent 可以放心试错，历史自动收敛。
工程落地证据：18 条本地补丁
- 修复重入卸载（卸载期间再次触发卸载导致资源泄漏）
- 事务性配置对账（热替换失败回滚到旧插件）
- 修复并发死锁（两个配置变更交错导致 fiber 卡死）
- 理论保证存在性，工程保证不破
组件生命周期
PENDING → LOADING → ACTIVE → UNLOADING → DISPOSED（含 inertia 惯性：异步过渡未完成前不响应新变化）
真正野心：自演化 Agent 系统
为”会自己改自己的软件”提供两样稀缺能力：
- 时间安全网 — 频繁替换时每步可完整恢复
- 空间自动协调 — 依赖拓扑变化时自动理清激活/停用顺序
73 个 Service 类散布各包，连 agent 循环本身都只是可替换插件。