给你的DeepSeek Harness Agent 装上自进化能力！

用 DeepSeek Harness（DSH）一阵子了，每次开新会话我都要重复那句「别给我加 emoji，别写『值得一提』，别把『我们应当……』塞到结论」。说三遍我都嫌烦，模型还一脸无辜看着我，好像这事它从来不知道。

DSH是模型，是 Agent loop，是把上下文、工具、子 Agent、计划模式全部插件化的运行框架

DSH是模型，是 Agent loop，是把上下文、工具、子 Agent、计划模式全部插件化的运行框架。v0.1 开发者预览版刚开源两周，社区里所有能跑的「高级 Agent」玩法都还是手写 system prompt 或者改 AGENTS.md。改 AGENTS.md 我有心理负担——它是项目根目录里的一份长期指令，改坏了影响别的项目，改对了又只能服务一个仓库。

直到我把 @graysilver/dsh-evolve-modes@0.3.1 这个独立插件装上。它不动 DSH 核心一行代码，不写 AGENTS.md 一行字符，只是在 Web 输入区旁边多塞了一个紧凑控件。点开，是四个独立的小开关，每个任务都可以重新组合。

它把「Agent 的工作方式」从切人格变成了调参数。

怎么做到不动DSH核心Loop？

DSH 的设计原则是「一切皆插件」，模型、工具、沙箱、UI、Agent loop 全部可替换。dsh-evolve-modes 走的是这条官方通道：注入 agentPresets、commands、llm、systemPrompt、subagents、storageDomain、tools 七个 service 注册点，在不 fork 的前提下挂上自己的 effect。

落地的样子是这样的：Web 输入区右侧会出现一行小字，类似 正常 · 标准 · 关 · 进化 开。点开是个弹层，里面是四个轴，每个轴两个选项互斥。组合跟着 session 走，跨会话只持久化「自进化」这一项（因为它是长期规则）。

这张图把四维度的选项摆在一起。从左到右依次是工作状态、推理策略、质量门禁、自进化。每个轴两个选项——这不是互斥的「人格切换」，是每次任务重新组合的一组工作决策。

四个功能各自管什么

工作状态：立即干，还是先出方案

正常 走 DSH 原生的 execute 模式，你说什么它做什么。计划 直接挂上官方 @deepseek-ai/dsh-plan-mode service，复用 DSH 的计划持久化和 exit_plan_mode 审批流程，不自己造第二套计划系统。两个选项背后走的是同一套 DSH 官方组件，只是开不开。

你点「计划」之后，DSH 会进入受限工作流：默认只允许 read、glob、grep、read_image、平台 shell 和 exit_plan_mode。这一层是 DSH 的 tools/pre-execute pipeline 在把关，不是操作系统 sandbox，但够挡掉大多数误操作。

推理策略：标准回答，还是第一性原理

标准 不做任何额外干预。第一性原理 会把目标、事实、假设、约束、推导、验证这六件事显式写进 request/header.system，Trajectory 里也会保留同一段指令作为可审计证据。关掉之后只影响后续请求，历史证据不会被自动删除——这是它的一个小心思：你想回头看哪一次用第一性原理答错了，Trajectory 里翻得到。

质量门禁：不做审查、对抗审查、还是验收审查

关 不加成本。对抗性审查 在父 Agent 回复完成后，启动一个独立的审查 Agent（用 DSH 的 fork subagent capability），按 Met / Gap / Unverified / Evidence / Concrete follow-up 五段式找风险、遗漏、反例、回归，只报告证据和缺口，不会静默改写、重试或修复父回复。验收审查 换一种打法：对照原始任务和已批准计划逐条验收，同样只输出清单，不动父 Agent 的产物。

审查报告会显示在对应的助手回复下方。每个完成的父回复增加一次模型调用和相应延迟，但插件不会替你跑项目的 test / lint / build——这是有意为之，避免和项目自身的 CI 打架。

自进化：关，还是开

这一项是整个插件最值得讲的差异化，也是后面要单独拆的部分。先记住一句话：默认是 Propose（提议），只生成待人工审阅的候选规则，不会自动改任何后续行为。

自进化到底怎么「进化」

市面上的自进化 Agent 项目我翻过一圈：Karpathy 的 autoresearch 主打让 Agent 在 Markdown 文档里写好指令然后自动跑科研循环；Hermes Agent 用进化算法生成 prompt 变体，再选最佳版本提 PR；EvoMap 给 Agent 配「开放基础设施」沉淀运行时策略。它们共同的特点是：会主动改东西——改 system prompt、改 skill 文件、改代码。

dsh-evolve-modes 走的是反方向：只提议，不动作。改不改、怎么改，最终解释权交回人手里。这是我愿意把它装进生产环境的唯一原因。

具体怎么落地：插件装好之后，每完成一次父 Agent 回复，会把这一轮挂到一个待学习队列里。当累计达到你设定的批次大小（默认 3，可在 1..100 之间调），插件会启动一次隔离的学习请求：

这张流程图把学习闭环画出来了。「隔离」两个字的工程含量比听起来大：学习请求不继承父会话历史、不继承父 Agent 的工作型上下文、不创建学习子 Agent、不携带工具、不加载源会话目录里的 AGENTS.md 或 CLAUDE.md。它就是一条结构化 JSON 用户消息，喂给插件专用、单一 persona 的学习模型。

证据规约也很严：

• 每个源会话最多取最近 100 条学习消息，超出会被截；
• 保留每轮完整的用户消息，以及该轮最后一个可见的助手消息；
• 助手消息只作为上下文，超过 2000 字符时只留开头 1000 + 结尾 1000，中间用 ... 代替；
• 提议的证据必须逐字来自用户消息。助手自己的推断、一次性任务细节、实现结果、沉默或「没有再次提到」，都不能单独成为规则证据。

提议长什么样

学习跑完之后，会在「自进化模式」设置页里出现一张仪表盘：

每条提议带：类别、推断类型、原始用户证据原文。你扫一眼证据就知道这条规则是不是真的从你说过的某句话里捞出来的，还是学习模型自己脑补。点「应用」才会写入全局 learned instructions system prompt section，点「忽略」就当没发生过。每次应用或忽略之前还会自动备份一份，错了能从备份恢复。

写入位置严格限定在带 <dsh-evolve-modes-learned-instructions></dsh-evolve-modes-learned-instructions> 标记的 system prompt section，Trajectory 里会投影同一段内容方便审计。插件只用自己的 storage domain，不会写 AGENTS.md、CLAUDE.md 或任何项目文件——这是写在前面的契约。

学习失败会记录在设置页里，未完成的批次会保留方便之后重试，不会阻塞父 Agent 的正常回复。这条对生产环境很关键：你不会因为学习跑挂了就看着主 Agent 卡死。

一行命令装起来

DSH 装插件走的是官方 CLI。Web profile 一行：

npx -y @deepseek-ai/dsh plugin --profile web add @graysilver/dsh-evolve-modes@0.3.1

如果全局装了 DSH 也可以简写：

dsh plugin --profile web add @graysilver/dsh-evolve-modes@0.3.1

或者直接从 GitHub Release 拉包：

dsh plugin --profile web add https://github.com/GraySilver/dsh-evolve-modes/releases/download/v0.3.1/graysilver-dsh-evolve-modes-0.3.1.tgz

想审计源码装固定 Git revision：

dsh plugin --profile web add github:GraySilver/dsh-evolve-modes#<trusted-commit>

Git 安装包会执行安装期代码，请只安装你信任的 revision。这句话写在 README 里，是个很实在的风险提示。

重启 Web profile，输入区就会出现那个四维控件。打开顶层「自进化模式」设置可以调学习批次、待审阅提议上限、学到的规则库。

命令 API 也很轻量：

/evolve-mode
/evolve-mode working execute
/evolve-mode working plan
/evolve-mode reasoning standard
/evolve-mode reasoning first-principles
/evolve-mode quality off
/evolve-mode quality general-review
/evolve-mode quality acceptance-review
/evolve-mode evolution off
/evolve-mode evolution propose
/evolve-mode evolution batch-size <1..100>
/evolve-mode evolution max-pending-proposals <1..1000>
/evolve-mode review <turn>
/evolve-mode reviews

旧的单模式别名（normal、first-principles、adversarial-review）会自动迁移到四维组合，当前自进化设置会保留——这是 0.3.0 引入的迁移逻辑，不会因为升级就把你积累的规则洗掉。

我现在常用的几组组合

装了一周多，沉淀下来几条比较顺手的工作流：

快速执行日常任务：正常 · 标准 · 关。保持节奏，不加额外流程。这是我写常规文章、改普通 PR 的默认组合。

做高影响决策：计划 · 第一性原理 · 关。先把假设摊开，再用 DSH 原生计划模式走审批。比单开计划模式多一层「先想清楚再做」的保险。

有把握交付实现：正常 · 标准 · 验收审查。实现完成后由独立审查 Agent 对照任务目标逐条验收，验收不通过的项会列在 Gap 里，再决定要不要回炉。审查 Agent 只报告不动手，所以不会和项目自身的 test 串台。

挑战高风险回答：正常 · 第一性原理 · 对抗性审查。先显式展开推理，再让独立 Agent 找遗漏、反例、回归和没依据的结论。这种组合慢一点，但写对外发声的长文、对外发的技术方案时我几乎只用这个。

沉淀长期偏好：正常 · 标准 · 关 · 进化 开。按默认每 3 次回复一批识别长期规则，只生成提议，不会自动启用。隔几天去仪表盘扫一遍，把真的反复出现的「我确实是这样说过」的提议点应用，剩下的忽略掉。几次下来，那种「别加 emoji」「别堆 bullet」「别写『值得一提』」的偏好就稳了。

DSH v0.1 还在早期，插件生态刚刚开始铺，能跑通的自进化玩法暂时就这一个。如果你已经在 DSH 上跑自己的 Agent、又不想为「Agent 不长记性」天天重复指令，强烈建议先装一周试试。提的提议不点应用就是零成本，点错了能从备份恢复。

你最常用哪一组组合？或者你已经有别的自进化方案在跑，欢迎在评论区对比下思路。

JOTO 企业落地观察

• 企业部署此类自进化插件时，需重点评估其「提议-审核-启用」三阶段治理链路是否嵌入现有变更管理流程。由于规则仅写入插件专属 storage domain 且不触碰 AGENTS.md，企业无需改造原有 Agent 工程体系，但需明确人工审核环节的责任归属与审计留存要求。
• 这类系统的取舍在于「隔离学习请求」的设计：它规避了会话污染与上下文泄露风险，但也将学习能力限定于结构化用户指令片段。对企业智能体工程而言，这意味着无法自动捕获隐含意图或跨会话行为模式，需依赖用户显式表达偏好。
• RAG 知识工程团队可复用该插件的证据规约机制——如「逐字来自用户消息」「截断超长响应」等规则，用于构建高质量微调语料集。其对原始对话的保真提取方式，比通用日志清洗更适配 RAG 中 query-relevance 对齐需求。
• AI 安全治理视角下，该插件将「模型自主修改行为」彻底解耦为人工可控的原子操作。企业无需禁用自进化能力，即可通过仪表盘审计每条规则的原始证据、应用时间与操作人，满足 ISO/IEC 42001 中关于 AI 系统可追溯性的条款要求。