引子：这篇文章和市面上的有什么不同
DeepSeek 开源的 Agent Harness（DSH）已经有不少介绍文章了：它是什么、怎么装、插件架构有多优雅。这些文章大多止步于“又一个 Agent 框架”，因为它们回答的问题是“DSH 长什么样”。
这篇文章想回答另一个问题：为什么一家模型厂商要花这么大精力做一个 Harness，以及它的设计选择对企业意味着什么。
切入点是后训练。后训练（SFT、RLHF、agentic RL）做的事是：在权重里塑形模型行为。而 Harness 做的事是：在环境里塑形模型行为——通过工具集、护栏、审批、反馈，改变模型实际表现出来的策略。这两条路指向同一个目标：让模型按你需要的方式干活。区别只是生效时延、可撤销性和爆炸半径。
一旦用后训练这个视角看 Harness，DSH 的很多设计决策就串成了一条线：那些看起来像工程师洁癖的设计和抽象——日志即状态、一切皆派生、能力即插件——连起来看，遵循的是敏捷试验、谨慎固化，铺出的是一条完整的企业进化路径：环境塑形、轨迹沉淀、权重塑形。本文希望把这条线讲清楚，并用自进化 POC 验证它到底通不通，又在哪里断裂——接口设计、契约形态、反馈质量。
01
先把三层概念说清：
预训练、后训练、工作现场
Cloud Native
一个模型进入企业的完整链条是三层：
第一层，预训练。模型出厂时的通识能力：会写代码、能推理、懂语言。这层能力是通用的，跟你的企业无关。
第二层，后训练。用偏好数据、反馈信号、环境交互把行为“写进权重”。这层开始有针对性：让它更听话、更会使用工具、更少犯特定错误。后训练的生效有三个特征，值得先解释清楚，因为它是理解“Harness 为什么必要”的钥匙：
- 离线：训练和推理是两条分离的流水线。模型上线服务时权重是冻结的——用户每次调用用的都是同一份权重，行为不会在服务过程中改变。想让模型改掉某个行为，只能走一条独立的加工链：先攒数据（哪种回答更好的成对标注、带反馈的任务轨迹，攒到有统计意义的规模）→ 训练集群跑训练任务 → 评测 → 灰度发布新版本。从观察到“模型不听话”到模型真的改过来，中间隔着以周计的加工周期，这条链与线上服务完全断开。
- 周期性：模型推理行为改变是版本式的跳变，不是连续的调节。两个版本之间模型行为零变化，新版本发布那一刻行为一次性跳变。日常使用中感觉不到模型在逐渐变好，只会在发布时感受到“它变了”。
- 不可轻易撤销，但全体生效：所有实例共享同一份权重。坏的一面：权重是海量数据的统计压缩产物，没法像删一行配置那样定点删掉一个行为，想消除它只能再训一轮，而新一轮训练又可能引入新的行为漂移；好的一面：新版本一上线，所有使用该模型的实例同时受益。
训练需要批量数据才有统计意义，训练任务天然不在线上推理请求路径上，新权重上线前必须评测和灰度。这也正是第三层（工作现场）存在的理由——不是每个行为问题都能等下一轮训练。
第三层，工作现场。模型被企业实际使用时的运行环境：它能看到什么工具、什么约束会拦住它、什么动作需要审批、审批者是谁。这一层长期被低估，但它决定了同一份权重装在不同的工作现场里，实际表现可以从完全不可用到满分——因为环境在替模型兜底和引路。下文的两组对照实验，量的就是这个差距。
DSH 的价值就在第三层与第二层的关系上。用这个视角读，它的一系列设计可以归结为一个判断：
Harness 是后训练的安全试验场。新行为先在环境里以可撤销的方式验证，高频且被人类审批放行的模式，再蒸馏进权重。
这个判断解释了 DSH 里一个看起来反直觉的设计：自进化通道“敏捷试验、谨慎固化”。试验这一端几乎没有门槛（模型在会话里挂载一段自己写的代码，零审批）；固化这一端必须过人（想把实验变成持久能力，得走正常开发流程，人类评审）。松的那一端保证进化真的发生，严的那一端保证进化不出事故。
在展开之前，先看 DSH 的三个设计支柱。它们是后面所有机制的地基。
02
三个设计支柱：
日志即状态、一切皆派生、能力即插件
Cloud Native
支柱一：日志即状态
先说清“日志”是什么。这里说的不是我们平时打的那种应用日志。平时 logger.info 打出来的是旁路产物：它记录“发生过什么”，供人排查；把整个日志文件删掉，系统照样跑，只是出事时没法查。
DSH 的这条日志是另一类，更接近 git 的提交历史：它不是对状态的记录，它就是状态本身。你看到的工作区是从提交历史检出出来的；同样，DSH 里的对话历史、审批策略、沙箱模式，全都是从这条日志算出来的。删掉它，会话不是“少了记录”，而是根本不存在。判据很简单：应用日志是可以删的；这条日志删了，系统就没有状态了。
熟悉数据库的读者可以拿 binlog 对比——形态很像（逻辑事件、只追加、可重放），但 DSH 走得更远一步：DB 里真源是表数据、binlog 是它的伴随流，而 DSH 里没有“表数据”那一层，日志就是唯一的数据源。
DSH 的 Session 内部只有一个数据结构：一条只进不出的追加日志，只能在尾部追加，已经写进去的事件永远不改、不删。用户消息、模型回复、工具调用、审批决策、沙箱模式切换、目标状态变化、定时提醒——全部以结构化事件的形式追加进这条日志。对话历史不是“存储下来的第二份记录”，审批策略不是一个变量，沙箱模式不是一个状态字段——它们都是日志的投影。
这条日志有三条硬规则：事件追加时深度冻结（不只是顶层对象，嵌套字段也一并冻住，事后任何一层都改不动）；序号连续（每条事件的位置就是它的身份）；崩溃恢复靠扫描尾部未闭合的事件合成闭合器（一次意外中断不会让日志变成半截账）。
这带来一个看似平淡、实则深刻的性质：状态和日志不一致这件事，在结构上不存在。因为状态没有独立存储，它只是日志折叠出来的结果。大多数系统的故障调查都要面对一个问题——“状态显示 A，日志显示 B，哪个是真的？”在 DSH 里这个问题被消灭了。
支柱二：一切皆派生
因为日志是唯一真源，所以所有能推导出来的东西都不该存第二份。这一节里”派生”和”投影”是同一件事的两个说法：投影强调它们是同一份数据的不同视角，派生强调这些视图都是算出来的——共同点是，没有一份是额外存储的。模型看到的对话历史，是从日志逐条投影出来的；界面上的”消息气泡”是一个索引数组（指向日志里的位置），不是另一个存储；甚至”可变会话摘要”这种看起来必须有的缓存也被整体删掉了（连带磁盘上的伴随文件与相关列）——设计笔记写得很直白：摘要原本要提供的一切都可从仅追加日志中派生，首条提示就是第一条用户消息，活跃度就是最后一个事件的时间，那就不要摘要。
这条原则的工程意义是：不存在第二事实源，所以不存在两份事实打架。你永远不需要写“同步逻辑”——因为根本没有第二个地方需要同步。一致性不是靠纪律维持的，是靠结构保证的。
支柱三：能力即插件
这条支柱回答的是一个很具体的问题：一项能力怎么装上去、又怎么卸下来，以及卸掉之后模型还看不看得见它。
DSH 全仓库 54 个包，唯一包含“调模型、跑工具、重复”这个循环逻辑的只有一个包。其余一切——沙箱、审批、定时唤醒、目标推进、甚至模型自己写的新工具——都是同一套插件契约（cordis，DSH 内联的微核插件框架），可以像零件一样装配进运行时。
组合即产品：开启沙箱等于在配置里装配四个插件，删掉即退回无限制执行；模型工具表里的权限字段会随沙箱能力缺席而自动消失。这个支柱是“自进化”的结构前提：宿主本身就是一棵可组装的插件树，所以模型才能用和人类开发者同款的方式往运行时里加东西。
三个支柱合起来的图景是：DSH 把“环境”从一套死的配置变成了一个活的、可审计、可回滚的有机体——这就是进化路径的第一环，环境塑形。而它同时还在做第二件事：把这个环境里发生的每一次决策，都留成了一笔可查的账。
03
护栏不是安全部门，是“训练环境”
Cloud Native
市面上的 Agent 框架大多有护栏，但多数护栏是“拦截器”：出问题时跳出来拦住你，拦完就消失了。DSH 的护栏有两个不同的设计点。
第一，所有护栏挂在同一条管道上，并且默认拒绝（fail-closed）。一个工具调用从模型发出到真正执行，要依次经过：策略链（一串规则，逐条判定允许/拒绝/需要问人）→ 审批解析 → 单调守卫（只能否决、不能放宽的检查）→ 执行 → 结果定稿（冻结成不可再改的最终结果）。审批的结果集是封闭的：allowed-once（仅此一次）是唯一的放行词，rejected、cancelled、unavailable 全拒；审批者缺失、报错、返回词表外的值，一律按拒绝处理。没有审批者（比如 headless 部署）就等于全部拒绝——系统默认说不，而不是默认说是。
这个“默认说不”不是一个可以被绕过的默认值，两个细节能看出它是结构性的。一是策略先于交互：部署侧把某个动作配成 never 之后，服务在把请求交给任何一个审批者之前就已经确定性地返回拒绝，审批者根本收不到它——所以事后想靠“把自己插到审批链最前面”来放行也没用，“谁先注册”这种顺序脆弱性在结构上被排除了。二是审批请求刻意不携带工具参数：它只带一个调用 ID，挂到那次已经流式展示给人看的调用上，从根上防止“审批时看到的”与“实际执行的”发生漂移——不是靠事后比对校验，是让漂移没有发生的余地。
第二，护栏的每一次触发都被记成了结构化事件，而且刻意与模型可见的对话分开存储。一次审批产生一对事件：approval/asked 和 approval/decided，由同一个审批请求 ID 配对，log-only——不进模型看到的对话流。沙箱侧则把拒绝特征和模型自报的越权理由都放在了结构化位置上：前者是后端汇报的 denialSignatures，后者是工具参数里的权限申请与理由字段。
这两个设计点从后训练的角度看，含义完全不同：
- 审批的 asked/decided 审计对，就是人类偏好数据：什么动作、什么理由、在什么上下文里，被谁放行或拒绝。这正是 RLHF/DPO 需要的偏好信号，而且是生产环境里自然产生的，不需要额外标注成本。
- 沙箱的越权记录，就是边界探测行为的标注：这些字段能还原出模型在什么情况下申请越权、给出的理由成不成立。这是训练“模型知道边界在哪”的现成素材（这里说的是可采集，DSH 本身并没有把每次越权尝试单独记成一条事件）。
- 审计与对话分离存储，意味着训练时可以分别取样：行为克隆用对话流，偏好学习用审计对——人类监督信号不会泄漏进模型输入，避免标签污染。
- 每次模型调用恰好对应一个锚点事件，轨迹的轮次边界天然干净，不需要事后清洗对齐。
换句话说：每一次“要不要放行”的人类决策，都被 DSH 顺手记成了可以直接当训练数据用的结构化事件。你的安全机制越严格，你的数据资产越值钱——这两件事在 DSH 里不但不冲突，还共享同一套事件底座。这就是“安全”与“越跑越好”在架构层面不必然互相挤压的机制证据：护栏既是拦截器，也是采集器，拦截得越频繁，沉淀得越厚。
沙箱侧还有一个值得单说的设计：DSH 刻意区分“软边界”和“硬隔离”。软边界是可撤销的约束（同一内核进程内包装执行参数），硬隔离是可隔离的爆炸半径（整组替换执行世界，比如换到容器/远程执行器）。判据是共享文件系统：Agent 的 bash 和文件工具如果在同一个世界，就用参数包装；如果在两个世界（bash 在容器里、文件工具写宿主机），Agent 就生活在分裂世界里，必须整组替换。这条判据直接回答了企业做 Agent 安全时最纠结的问题：什么情况加一层权限，什么情况必须换执行环境。放在链的语境里，它是“实验”与“事故”之间的可撤销缓冲——环境塑形之所以敢让模型随便试，是因为软边界先兜住，硬隔离再兜底。
04
自进化：能力是怎么“长”出来的
Cloud Native
DSH 最激进的部分，是把“修改自己运行时”的权力交给了模型。它提供三类工具：获取当前进程运行时信息（读 API 目录，目录从源码 AST 生成，模型读到的是带文档的真实签名）、挂载（模型写的 JS 在一个受限求值环境里执行，挂成临时插件，即刻生效）、卸载（等所有挂载物到达静止态才回收）。
这里的“挂载/卸载”是语义说法：工具面上挂载由“定义 + 运行”两步完成，卸载由“停止 + 注销”两步完成；在系统的状态上，挂载等于 LOADING→ACTIVE，卸载等于 ACTIVE→UNLOADING→DISPOSED，并且实机探针抓到的事件序列与工具回执的时间点一一对应。
于是闭环出现了：模型发现自己缺一个工具 → 自己写一段代码 → 挂载 → 下一轮这个工具就能调用。挂载物可以注册新工具、监听 Agent 事件、提供服务供后续挂载使用——模型可以分多次挂载，逐步组装出复杂能力。
但 DSH 在这里做了一个非常克制的设计：运行时实验不落盘，固化必须走审批。
但 DSH 在这里做了一个非常克制的设计：运行时实验不落盘，固化必须走审批。
设计笔记的原话是：没有自动保存、自动提升、自动安装的通道——保留一个实验，意味着请 Agent 通过正常开发流程实现一个真正的项目插件。为什么堵死自动提升？因为挂载是开发工具，求值环境防的是意外污染，不是安全边界——挂载代码拿的是全权限上下文。一旦有“一键转正”通道，模型写的代码就绕过了人类评审进入持久配置面。
这就是前面说的“敏捷试验、谨慎固化”的结构化实现。扩成完整的三段式：
1. 实验：会话内、进程内存、零审批、可即时回收。爆炸半径 = 这个会话。
2. 固化：写成 skill 文档（知识/流程）或真插件（代码能力），跨会话持久，人类评审签字。爆炸半径 = 这个部署。
3. 蒸馏：高频且被审批放行的模式进权重，全实例生效。爆炸半径 = 所有使用该模型的实例。
信任等级单调递减，生效范围单调递增。DSH 只实现了前两段，第三段留给模型厂商。而模型厂商恰恰就是 DeepSeek 自己——这条“留给厂商”的边界在 DSH 里是刻意的留白，在企业平台的视角下，正是数据飞轮的接口位。
时间维上还有两个配套机制：定时唤醒（模型可给自己设提醒，但只在完全空闲时收到，绝不打断当前轮次）和目标推进（长任务的自动续跑，但进程重启、会话恢复后必须人类重新授权才能继续；取消即暂停，防止“取消”被当成自动重启的触发器）。它们共同回答的问题是：一个自主进化的系统，怎么保证人始终握着最终的开关。
05
我们用 POC 验证了什么：实机证据
Cloud Native
我们在本地构建的 DSH（0.1.0-rc.5）上，用 qwen3-max 驱动（另有 qwen3-coder-plus、qwen3.8-max 作对照臂），搭了一个“自进化竞技场”：宿主握着一套不对外公开的验收口径当裁判，模型只能靠每轮的失败样例，用“写代码 + 挂插件”的方式给自己造新能力。这里有个刻意的设计选择：藏的只是验收口径（掩码保留几位、多条规则谁先谁后），任务目标本身是公开的——这跟真实工作一致，“做个脱敏工具”人人都懂，但“两种敏感信息重叠时先算哪个”必然要跟审计方反复对齐。下文输出摘录逐字取自会话事件流。
5.1 凭什么说“进化了”：四道客观闸门
不采信模型自述（实测中模型连自己已经成功都会误判）。判定“确实进化了”必须过四道闸：
1. 能力存在：调用从“未知工具”变为可执行——确实多了一项可调用的能力。
1. 能力存在：调用从“未知工具”变为可执行——确实多了一项可调用的能力。
2. 能力正确：宿主裁判给出通过率——在当前用例集上正确。
2. 能力正确：宿主裁判给出通过率——在当前用例集上正确。
3. 能力真实：模型不可见的隐藏用例（holdout）得分——区分“学会了”和“背下来了”。
4. 增量可归因：能力账本逐用例记录每轮新增/丢失——每一轮具体多了什么、弄丢了什么。
四道全过才能说“进化了”；只过前两道只能说“造出了一个能跑的东西”。这套闸门本身就是 POC 的第一个产出：它回答了企业最不敢问的问题——你怎么知道你的 Agent 真的变强了，而不是自我感觉良好？
5.2 三组最有讲头的对照实验
对照一：接口设计决定泛化（V18 游戏世界）。任务：模型写一个游戏移动规则引擎，宿主拿它去走一张地图，判定正确的格子才点亮。两轮实验唯一变量是探测接口多给一个字段——目标格地形（toTerrain）。结果：训练侧进化曲线几乎逐轮一致（16 格 → 40 格 → 51 格全亮），但隐藏地图上（顺序反转、坐标全错开）：无地形输入的版本 0/146，模型自报背了训练图坐标；有地形输入的版本 146/146 满分，模型自报“完全不含坐标”。这里要补一句：两版在另一张含未见地形的地图上同为 24/29——没见过的东西对谁都还是边界，这里的“满分”只针对同类地形的新布局。同样一套进化过程，泛化能力天壤之别——能不能学会而不是背，接口设计说了算。更值得注意的是：无地形版本里模型其实“知道”正确答案——它在最终汇报中给出了完全正确的架构诊断（“真正通用的解法需要把地牢状态作为输入”），但在那个接口下它无路可走，只能背图。
对照二：契约的信息形态决定成败（V19 Agent 帝国）。任务升级到组织维度：Chief 不亲手干活——每种能力必须是它造出来的动态工具，每个工人必须是真实拉起的子 Agent 会话。四阶段目标：伐木、建房、挖矿、建奇迹。run1 只给文字描述的契约：97 次工具定义全部失败，模型在三种 API 形状错误之间循环，194 次调用零产出。run2 把验证过的代码模板逐字内嵌进提示：32 次调用 0 失败，4 个策略工具一次成型，9 个真实工人会话各司其职，4 回合建成奇迹，全图 192/192 点亮。同模型、同任务、同引擎，唯一变量是契约的信息形态。契约的形态比契约的有无更关键——“文字描述的契约”约等于没有契约，必须给逐字可运行的模板，而模板本身的正确性由冒烟测试保证。
对照三：反馈不等于能力（V14 vs V15）。两边都给了远超实际所需的轮数预算：V14 是无结构任务（规则不可归纳），训练区 24/24 满分，但 holdout 4/16，等于随机——模型的手法就是硬编码查表，典型的刷分，被隐藏探针当场拆穿。V15 是可归纳任务（隐藏规则含四个数论概念），4 轮拿下 60/60，且 holdout 20/20 完全泛化。两次实验都没跑满预算。结论：决定可达空间的不是轮数预算，而是每轮反馈的信息增益；而反馈有没有信息增益，取决于任务本身有没有可归纳的结构。“有反馈就能一直进化”，是一个已经被证伪的直觉。
5.3 这套闭环在 RL 视角下是什么
把竞技场的要素逐一映射到强化学习的术语，会发现它恰好是一个完整的 RL 基础设施：
- 环境：宿主竞技场（持隐藏真值，可编程切换六种难度模式）。
- 动作空间：写代码 + 挂插件——而且动作空间可以被 Agent 自己撑大：它新注册的工具本身就是可调动作。
- 奖励：宿主裁判的客观得分，真值不进上下文——可验证奖励。
- 归因：账本把一次代码修改的效果拆到具体输入粒度——稠密的 credit assignment。
- 策略：不是权重，是当前在跑的 package 代码——可读、可回滚、可审计。
- 轨迹：可回放的事件流，已蒸成 96 步 model-level 记录 + 20 份策略代码产物入库。
在轨迹的背后，有一个贯穿 POC 始终的实证值得单说一下：以上所有产物——模型对话 transcript（transcript.jsonl）、轨迹数据集（steps.jsonl，96 步 model-level 记录）、Web 回放页（evolution.html）、帝国实时面板（game-live.html）——都不是独立存储的“第二份数据”。它们全部来自同一份 session 事件日志的派生：export-trajectory.py 从 session 日志计算每步的 input/output/usage；build-viewer.py 从轨迹数据投影出交互页面；面板的 world snapshots 是 session 事件流的另一个视图。不存在第二份存储，也就不存在“对话历史和审计记录对不上”的风险。一致性不是靠纪律维持的，是靠结构保证的——这就是支柱二“一切皆派生”在整个试验中的实证。
最后有三条边界必须说清。第一，本 POC 没有做任何权重更新、没有多 episode 采样、没有接优化算法。 它验证的是“在 DSH 上可以搭出环境 + 可自扩展动作空间 + 可验证奖励 + 稠密归因 + 可重放轨迹的完整闭环”，属于 RL 基础设施层面的可行性，不是训练结果。第二，护栏（沙箱/审批）与自进化的组合拦截行为本轮未验证。第三，能力默认不跨会话——想保留必须人工固化。
V20/V21 将同一套自进化机制推进到 3D 体素世界——V20 体素拓荒（Three.js 3D 面板、五个 capability gate、灯塔终局），V21 自进化拓荒（craft ops 发明新玩法、跨局遗传）。
V20 试验中同样的能力进化、同样的 gate 逻辑，模型在三维岛屿上指挥工人采集资源、建造灯塔，一路跑到灯塔点亮的终局，所有里程碑验证通过。这是“自进化”从引擎验证走向游戏化应用的预览。
V21 的 craft ops 与跨局遗传机制已经实现，但代际闭环尚未真跑。这里还有一点必须说明：跨会话的能力遗传是我们在宿主侧自建的绕过，不是 DSH 提供的能力——DSH 当前并未提供运行时挂载物的自动跨会话延续，从一定程度上，这也正是企业平台要做的。
V22（蒸馏固化审批，设计阶段，待实跑）是叙事链的下一环：V11 证明了“不固化就没了”，V22 要证明“固化后还在”——模型在竞技场中完成任务后，将运行时 mount 固化为 workspace skill 文件，经过审批完整性检查（版本号/用途/测试用例），不满足则拒绝并给出理由；固化后在新会话中用 holdout 验证能力可迁移。这是“敏捷试验、谨慎固化”在 POC 里的最后一环。
06
对企业意味着什么：三个转变
Cloud Native
转变一：从“发版驱动”到“生长驱动”
今天企业的 Agent 能力集是发版驱动的：工具面写在配置里，上线前固定。遇到没覆盖的需求，Agent 只有三条路：绕道、失败、等下一个版本。POC 证明了一条新路径：Agent 可以在运行时把缺失的工具补上，当轮生效；宿主用能力闸（capability gate：宿主先检查对应工具是否真的在运行，没造出来就拒绝）保证“科技树上的每个节点不是布尔标记，而是你真的写出了这个能力”。但生长必须有闸：运行时实验零审批，蒸馏固化必须审批——DSH 把”敏捷试验、谨慎固化”做成了结构，这是自进化能进企业生产环境的先决条件。
转变二：从“日志即排查工具”到“日志即数据资产”
今天企业的 Agent 会话日志，绝大多数在出事故前没人看过，出完事故看完就删。DSH 的日志模型指向另一种用法：每个事件类型都有对应的后训练用途——审批对是偏好数据、越权记录是边界标注、目标轮次是长任务结构数据、环境切换是消融实验数据。而它的两个设计细节（审计与对话分离存储、每次模型调用一个锚点事件）让这份日志拿来就能用，不需要事后清洗。企业部署 Agent 系统的每一分安全投入，同时就是在积累训练数据资产。
转变三：从“纪律维持”到“结构保证”
多数企业系统的数据一致性靠团队纪律维持：约定“状态必须和日志对齐”，然后靠 code review 和测试兜底。DSH 走的是另一条路：日志即状态、一切皆派生，分歧在结构上不可能发生。当“对话历史”和“审计记录”是同一份事件的两个投影，而不是两张需要同步的表时，这一类 bug 与它对应的合规风险就不再需要防。这对企业平台设计的启发是：治理目标不应该靠流程制度去追，应该靠数据结构去保证。
边界与机会
- 进化不等于泛化。业务版脱敏任务训练区 15/15，holdout 只有 6/8，模型还编了一条“脱敏规则跟出生年有关”的伪规则。能力的真实边界必须用隐藏用例测，否则满分只是另一种形式的自欺。
- 权重塑形是刻意留白。DSH 没有任何轨迹导出/训练对接机制。这不是缺陷——它把“环境塑形”做到了极致，把“权重塑形”留给了模型厂商自己。对企业平台而言，这段留白就是机会位：谁先把轨迹采集管道、事件分通道存储、固化审批工作流做成产品，谁就占据了“企业进化”的基础设施位置。DSH 没做的，正是企业级平台要做的。语义长期记忆、多租户隔离、组织级审批策略、训练管道对接——这些都是单机 Harness 的合理边界，也是企业平台的差异化空间。
结语
Cloud Native
DeepSeek Harness 是一个模型厂商对两个问题的工程回答：Agent 如何在运行时被约束，如何随时间变强。它的回答浓缩成三句话：
1. 一致性靠结构保证，不靠纪律维持——日志即状态，一切皆派生。
2. 护栏与进化共享同一套事件底座——每一次安全决策都是训练数据。
3. 敏捷试验，谨慎固化——爆炸半径越大，门槛越高。
从后训练的角度看，它完成了整条企业进化路径的三分之二：环境塑形和轨迹沉淀，并用“留给厂商”的第三段，把交接点放在了明处。我们的 POC 在它的地基上跑通了最小闭环，也用 holdout 和对照实验量出了这条路径的断裂点在哪里——接口设计、契约形态、反馈质量。
对企业来说，这篇文章的结论可以很朴素：你的 Agent 系统今天产生的每一份日志、每一次审批、每一次越权尝试，都是你未来训练数据的雏形。区别只在于，你是把它们当废料丢掉，还是像 DSH 一样，把它们的采集设计进架构里。后者，才是“企业进化”这四个字的工程含义。
本文作者@阿里云云原生。原文链接：https://mp.weixin.qq.com/s/JzkELoKKL7mA-35mnWZvCw