我们在落地 Agent 时面临的核心矛盾，是大模型的概率生成机制与工程系统所需的绝对确定性存在天然冲突。要获取大规模、可维护且值得信赖的代码，必须在系统外围构建 Harness。Harness 的本质是将不确定性转化为确定性。

提高信任度和可靠性需要极度压缩 Agent 的解决方案空间。我们必须放弃让模型「生成任何内容」的灵活性，转而采用包含大量技术细节的提示、规则和框架。特定的架构模式、强制执行的边界以及标准化的结构，构成了这套护栏的物理基础。

当前越来越多的团队在持续快速的产生代码，而这些演示很好看，当真的进入整个软件生命周期中，就会产生混乱，当越来越多的人随着时间的推移在仓库中堆砌代码，组织就开始堆人进行 review、反复返工，最后 AI 的吞吐量被人类注意力卡死，表面上用了 Agent，实际产能没上去，维护成本还更高。

当然，这是一种结果，也有人在过程中不停的构建基建，做 Harness 工程，整个代码不再是无序的扩张。从这个逻辑来讲，harness 的作用是把大模型输出从概率事件压回工程确定性的系统设计。

Agent 的 Harness

harness 是什么

很多人把 harness 比作一个操作系统，模型是 CPU，但我觉得并不是。

如果模型真的是 CPU，那它接收指令后的执行结果应该是绝对严格且可预测的；但大模型本质上是一个概率引擎，它在潜空间里做的是模式匹配与概率生成。因此，harness 并不是像操作系统那样去调度底层硬件资源或分配内存，它更像是一套概率过滤器和对齐机制。它依靠纯粹的工程手段，把模型那种发散的、充满不确定性的「创造力」或「幻觉」，强行压缩进一条狭窄、严谨且符合人类预期的流水线里。

这种工程逻辑在实践中，体现为无处不在的防御性设计和反馈闭环。当模型吐出一串代码或一个决策时，harness 并不负责直接「运行」它，而是负责「质检」和「纠偏」。它通过静态检查、架构规则扫描、自动化测试和沙箱验证，把模型给出的「大概率正确」转化为工程上非黑即白的「通过或驳回」。正是这种让概率不断撞击确定性规则的过程，才使得最终沉淀到代码库里的产物是安全、可控且符合系统长期利益的。

harness 解决确定性问题的终极目的，是为了在系统中建立无需人工干预的信任，从而真正释放 AI 的吞吐量。如果没有这套逻辑，模型生成的代码越多，人类审查的负担就越重，整个组织的运转速度依然会被人类的注意力瓶颈卡死。

Martin Fowler 的博客中发表了 Thoughtworks 的技术专家的一篇文章，将 OpenAI 文章中所描述的 harness 分为三个方面：

上下文工程

上下文工程需要做到动态与静态的交织

单纯依赖超长 Prompt 无法解决复杂工程问题。上下文工程的核心在于构建代码库中持续增强的知识库，并打通 Agent 对动态上下文的访问路径。

静态知识库定义了系统的基础法则。我们将领域模型、API 契约和历史架构决策文档化，作为 Agent 初始化的基线上下文。动态上下文决定了 Agent 在运行时的决策质量。系统需要将实时的可观测性数据、测试覆盖率报告甚至浏览器导航状态，实时注入到 Agent 的工作流中。缺乏动态上下文的 Agent 就像蒙眼狂奔的打字机，产出的代码在语法上完美，在逻辑上完全脱离系统现状。

架构约束

架构约束是确定性的防线。

完全依赖 LLM 进行自我反思和代码审查，在生产环境中极度危险。架构约束必须由确定性的自定义代码检查器和结构测试来强制执行。

我们通过静态分析工具拦截不合规的依赖调用，利用 AST（抽象语法树）解析确保代码分层符合规范。当 Agent 试图在 UI 层直接发起数据库连接时，确定性的检查器会立即阻断该行为，并将具体的错误堆栈和修复路径作为反馈输入给 Agent。这种混合架构确保了系统的底线由死板的规则守卫，Agent 的创造力被严格限制在安全的沙盒内。

垃圾回收

垃圾回收主要是用于对抗代码熵增。

完全自主的智能体引入了代码库衰败的新问题。Agent 会精准且不知疲倦地复现代码仓库中已存在的模式，包含那些不均衡或不够理想的遗留设计。随着时间的推移，这种行为不可避免地导致系统架构漂移。

最初，人类开发者试图手动处理这个问题。团队过去每周五要花费 20% 的时间清理「AI 残渣」。这种依赖人力的做法毫无可扩展性。

我们将资深工程师的主观品味转化为机械规则，提炼为「黄金原则」并直接编码到代码仓库中，建立了一个循环清理流程。我们强制要求使用共享的实用程序包，禁止手工编写零散的辅助工具，确保不变式集中管理。我们严禁使用猜测性的数据探测，强制验证边界或依赖类型化的 SDK，防止 Agent 基于虚幻的结构进行构建。

系统定期运行一组后台 Agent 任务，扫描代码库中的偏差、更新质量等级，并发起有针对性的重构 Pull Request。这些 PR 大多可以在一分钟内完成审查并自动合并。这套机制的功能等同于内存管理中的垃圾回收。技术债务如同高息贷款，通过高频的微小重构不断偿还，远胜过让债务累积到系统崩溃。人类的架构品味一旦被捕获并规则化，就会无情地应用于每一行代码，每天自动发现并消灭不良模式。

AI Agent Harness 的工程化落地

从几个流行的框架来看，主要是从流程强化、规格沉淀、任务编排等逻辑上来做事情。

将这些逻辑拆开可以分为四个维度：

上下文工程

上下文工程主要是在规范层解决问题，其主要解决的「规则文件失控」的问题，实现规格沉淀与对齐，以及上下文工程的可控。

之前，我们习惯把所有规范塞进类似于单个 .cursorrules 文件，导致 AI 上下文过载且容易忽略细节。这一层落地的第一步是建立结构化、按需加载的规范体系。主要做到如下的点：

• 规范模块化：将系统架构、数据库规范、错误处理等拆分为独立的结构化文档。
• 按需检索：AI 不需要每次都通读所有规范，而是根据当前所处的任务阶段，动态检索并加载所需的上下文。
• 任务记忆隔离：为每个独立任务建立物理隔离的工作区和日志。AI 每次开启新会话时，只读取当前任务的精确记忆，既解决了“跨会话失忆”，又屏蔽了无关信息的干扰。

以 Trellis 框架为例，Trellis 摒弃了单一庞大的全局提示词文件，而是采用 spec/ 目录将规范模块化（如拆分为 database-guidelines.md）。在执行任务时，它利用 tasks/ 目录下的 JSONL 配置文件，让 Agent 动态检索并按需加载上下文。

架构约束

架构约束的核心逻辑：用代码约束代码，实现闭环自愈。 口头约定或纯文本规范在 AI 面前是脆弱的，它极易为了「跑通逻辑」而破坏架构分层。

• 规则代码化：将核心的架构依赖规则（例如“前端组件严禁直接调用数据库”）编写为静态分析脚本或自定义 Linter。
• 带解释的强阻断：在代码提交或验证阶段强制执行这些拦截器。关键在于，报错信息不能仅仅是「检查失败」，必须输出高度结构化的指导：明确告诉 AI“为什么违反了规则”以及“正确的做法是什么”。
• 自动修复：AI 读取到结构化的报错指导后，能够自动理解并修正代码，形成无需人类介入的自愈闭环。

反馈循环

核心逻辑：降噪处理，防范死循环。 LLM 的注意力会被长篇大论的日志（如几千行的覆盖率输出）稀释注意力，从而忽略真正致命的错误。 因此我们需要做到：

• 零输出原则：改造验证脚本。如果测试通过，脚本应保持完全沉默；如果失败，只输出精简的错误堆栈和失败原因。
• 强制验收清单：在 AI 试图标记任务「已完成」之前，系统应强制拦截，要求其对照需求文档逐项确认边界条件。
• 防死循环干预：设定重试阈值。如果 AI 对同一文件连续修改多次且测试依然失败，系统应主动中断并强制其回滚代码、重新审视需求，防止 AI 陷入无效的「幻觉修 Bug」循环。

熵管理

熵管理主要是阻断「坏模式」的指数级扩散

核心逻辑：快速偿还技术债。 AI 复制坏代码的速度是指数级的。一旦允许一个临时的妥协方案合入主分支，AI 会在极短时间内将其复制到整个代码库。

• 高频垃圾收集：彻底放弃“集中清技术债”的传统做法。每天必须安排固定时间，专门 Review AI 生成的代码（人工或 AI 自动），及时识别新引入的坏模式。
• 规范资产的动态演进：一旦发现坏模式，立即让 AI 深度分析根因，并自动将正确的防范规则更新到规范库中。
• 团队级免疫：由于规范库与代码同源管理（存在于 Git 仓库中），当这段新规则被提交后，团队其他成员拉取代码时，他们的 AI 助手就能立刻“学会”这个新技能。这把偿还技术债的动作，变成了每天自动化、可积累的系统进化。

以 Cursor 为例，可以更新 Team Rules

组织级 Harness

聊完 Agent 的 Harness，再聊一下组织的。

人的角色已经变了

大家都知道康威定律，简单来说就是：设计系统的组织，其产生的设计受限于这些组织的沟通结构。

而系统设计到最后，也一定会遇到一个问题：谁来定义规则，谁来解释例外，谁来承担后果。

以前的软件开发分工相对稳定。PM 写需求，设计出稿，前后端分别实现，测试验证，运维发布。大家各自占一段链路，边界虽然有摩擦，但总体清楚。

AI 进来以后，边界开始模糊。

PM 已经可以直接产出前端原型，很多时候产出的还不是静态图，而是真能跑的页面代码。设计师也不再只是给稿子，很多交互和组件约束可以直接沉淀成生成资产。前端工程师花在纯页面搭建上的时间下降，开始更多介入状态管理、交互抽象、可维护性收拢。后端和算法也更早被拉进来，因为很多 AI 生成的原型一开始就会碰到真实数据和能力边界。

这是现在很多团队正在进行的转型。

如果组织还按旧的分工运转，Agent 会把协作缝隙快速放大。

组织级 Harness 要管什么

我理解的组织级 harness，重点在三件事：

1. 定义新的协作接口
2. 重新分配注意力
3. 把责任从「谁写了代码」改成「谁定义了系统」

协作接口要前移

以前很多问题可以留到开发阶段再对齐。现在不行。

因为 PM 通过 AI 已经能直接产出前端代码，需求不再是文字说明，而可能是一个可交互原型；设计规范也不再只是 Figma 标注，而是可以半自动映射到组件约束；后端接口能力如果不提前讲清楚，前面的生成很容易一路偏到错误方向。

所以组织里的评审必须前移，重点也得改。

过去的需求评审，很多时候在讨论功能要不要做。现在要多讨论三件事：

• 验收标准到底是什么
• 哪些边界不能突破
• 哪些部分允许先用原型推进，哪些必须工程化收拢后才能上线

这几个东西不提前定，后面会出现一个很常见的问题：原型阶段看起来进展飞快，进入工程化后才发现返工巨大。

注意力要重新分配

我现在越来越少鼓励资深工程师花时间逐行抠低风险代码。

这不是说 review 不重要，而是注意力要贵着用。

在 Agent 环境里，重要的工作变成了：

• 定义验收标准
• 设计架构边界
• 提炼黄金原则
• 识别系统性失败信号
• 决定哪些异常值得阻塞主流程
• 审核高风险改动和高影响面重构

反过来，低风险、重复性、局部性的东西，应该尽量交给自动化校验和后台清理任务。

如果一个组织还在让最贵的人力去看大批格式化差异、小工具改名、重复样板代码，那 harness 基本等于没有。

责任归属要重写

在 AI-Native 组织里，谁对结果负责？

PM 产出了页面代码，前端做了工程化收拢，Agent 自动补了测试，清理 Agent 又改了一轮共享工具。最后线上出问题，算谁的？

如果这个问题没有明确答案，团队会很快进入防御状态。每个人都怕接 AI 产出的锅，于是流程开始重新变重，所有人都试图把责任往后传。

所以组织级 harness 一定要明确责任模型。

可以按三层分：

• 需求责任：谁定义了目标与验收标准，谁负责需求正确性
• 架构责任：谁定义了边界、模式和约束，谁负责系统一致性
• 发布责任：谁决定进入生产环境，谁负责风险接受

不要再执着于「谁手写了这行代码」。就像团队管理一样，最后拍板的人担责。

可落地的 AI-Native 研发流程

以下为我们当前在跑的流程：

需求生成

第一步由 PM 主导，但交付物不再只是 PRD，而是带验收标准的可运行原型。

但是，原型代码不等于可直接上线代码。它的价值是澄清需求、暴露分歧、提前感知交互复杂度。

所以 PM 可以生成，但不能默认拥有工程决策权。最终所有的代码都需要前端工程师构建的工具链条，以及 AI 和人工的审核及合入。

联合评审

第二步是全员参与的需求评审与架构设计。设计、前端、后端、算法都要尽早介入。

这个阶段重点不是抠实现细节，而是确定：

• 用户路径是否成立
• 数据流怎么走
• 状态边界怎么划
• 哪些能力用现有服务承接
• 哪些模块需要新增抽象
• 风险点在哪
• 验收怎么自动化

这这一步的产出结构化进仓库，因为后面它会直接成为 Agent 的约束输入。

工程收拢

第三步是工程化整合。这个阶段前端、后端、算法开始把前面的原型和需求收敛进正式系统。

这里 Agent 会大量参与，但人类不能退出。重点工作包括：

• 把原型重构进现有组件和模块体系
• 校正状态管理、错误处理、埋点、权限、监控
• 对接真实接口和算法能力
• 补齐类型、边界验证和回归测试
• 处理跨模块影响面

这一段最考验 harness，因为原型代码最容易带着局部最优、全局失真、风格漂移的问题冲进主仓。

自动验证与灰度

最后一步是自动化测试、灰度发布和反馈回收。

这一步先由专门的工程团队来负责，加入部分的 AI 成分，固化系统。

从 Agent 到组织，真正难的是控制系统

很多人以为 AI 落地的核心挑战在模型能力、成本或者工具接入。我现在看，最大挑战更集中在三个词：环境、反馈回路、控制系统。

环境决定 Agent 看到了什么、能做什么、不能做什么。

反馈回路决定错误会被放大，还是会被系统吸收成改进信号。

控制系统决定生成能力增长之后，组织是变得更稳，还是更乱。

这三个东西做不好，模型再强也只是更快地产生问题。

做得好，哪怕模型能力没到最顶尖，系统一样能稳定进化。因为工程上真正稀缺的，从来不是一次惊艳输出，而是长期重复地产出靠谱结果。

组织的 AI-Native 化

组织的 AI-Native 化也是慢慢进货，逐步推进的，先从小范围试起，再根据结果不断调整规则和流程。并且各家有各家的风格和气质。

第一，选一条链路打透。不要一开始就全组织铺开。先找一个协作关系清楚、反馈周期短、风险相对可控的场景，比如中后台、运营工具、内部系统，或者低风险服务改造。重点不是让 AI 多写代码，而是先验证：信息怎么给、边界怎么定、错误怎么发现、问题怎么清理。

第二，先改规则，再谈效率。很多团队一上来就问产能能提升多少，但更重要的是：规则有没有沉淀下来，错误能不能回流，坏模式能不能及时发现并清掉。如果这些没做好，所谓提效往往只是把问题推后，甚至把混乱放大。

第三，把人的位置往上移。资深工程师要逐渐从大量写代码，转向定规则、画边界、看反馈；技术管理者要从盯人和排期，转向设计流程、分层风险、明确责任；产品可以更早参与原型，但不能越过工程判断。

组织真正变成 AI-Native，不是因为每个人都在用 Agent，而是协作方式已经围绕 Agent 被重新设计过。

模型当然重要，但不是决定性因素。真正拉开差距的，是谁先意识到：Agent 不是一个更快的开发者，而是一个高吞吐的生产单元。它会放大环境本身。规则清楚，它就放大规则；流程混乱，它就放大混乱。

所以到最后，harness 这件事谈的根本不只是 AI。

谈的是工程纪律怎么重新编码。

谈的是组织协作怎么重新布线。

谈的是我们怎么把概率生成系统，放进一个仍然要求长期维护、长期演进、长期负责的软件世界。

这是我理解的「从 Agent 到组织」。

以上。

如果 AI 能像人一样，随着时间，经验，反馈不断学习，会发生什么？

我们现在常用的 Agent，不管是豆包，还是编程用的 Cursor，本质是还是一次性对话工程，你问一句，它答一句，或者执行完一堆任务，任务结束后不会成长。

如果能成长呢？这将会是不一样的世界。

这也是今年硅谷比较热门的方向。

为什么是这个方向：

1. 人性，人天生懒惰，公司逐利
2. 成本，自动化的 Agent 比 Chat AI 消耗的成本高出数个数量级，而自己进化的 Agent 所消耗的 token 又比一般的自动化的 agent 要高出多个数量级
3. 上下文更长、模型更大、工具更多，这些路线都还有效，但边际收益已经没有前几年那么夸张。当其它维度进入瓶颈的时候，时间永远是可以考虑的重要维度，

自我进化不是「长期记忆」，而是 Agent 依据自身交互情况、任务反馈或环境信号，对上下文、记忆、技能、工作流甚至模型参数进行持续更新。这些更新会直接干预未来的任务执行。

通过不断调整大模型和 harness 的边界，在静态世界里不断进化，模型能够能够越来越熟悉环境工具记忆等

任何演进路径都必须压在评估、版本、回滚、权限与供应链治理的基础之上。

自我进化用一句来讲，大概是这样：

真实任务里的经验，怎么变成下一次任务可复用、可验证、可治理的能力。

拆解一下，可以分为四层或者说四种可实现路径：

1. 上下文进化：将执行经验、用户偏好或环境约束写回本地记忆文件、会话索引或技能目录，在下一次任务触发时通过检索提取并拼接入上下文。
2. 技能进化：把经验外化成结构化的 SKILL.md、技能包或工作流脚本。系统依据执行报错或反馈信号，自动修改技能代码，在测试集中跑通后覆盖老版本，失败则触发版本回滚。
3. 群体智能进化：多个 Agent、多台机器、多个用户的本地经验接入云端共享层。系统在服务端完成轨迹去重、冲突合并、安全脱敏与质量验证，最后将提纯后的技能或记忆分发回所有终端。
4. 策略进化：将真实的交互轨迹与成败反馈收集起来，直接修改 Agent 的核心调度代码、工作流拓扑，甚至转化为强化学习（RL）的标量奖励来更新大模型的底层参数。

从工程落地的角度来说，上下文闭环和技能闭环是不错的起始点，也是能快速落地，快速带来结果的点。

这两层改动的基本都是文本资产，容易审计，且故障可控，回滚成本低。如果实现群体闭环或策略闭环，就会多出很多数据脱敏，权限控制等等问题。

上下文进化

上下文进化是指让 Agent 在自己的主循环里，将执行经验、用户偏好或环境约束写进以后还能用到的上下文资产。

典型的上下文资产包括：

• 跨会话记忆
• 会话检索
• 用户画像
• 项目级上下文
• 技能目录的动态装载
• 失败后的反思记录

优点：轻、快、容易落地。

缺点：如果底层模型本身不够强，光靠上下文很难突破上限；如果没有治理，错误经验会稳定污染后续行为。

以 Hermes Agent 为例，它将持久记忆（MEMORY.md / USER.md）、跨会话检索（SQLite + FTS5）和技能创建塞进同一个对话主循环。

工程实现上，Hermes 走的是一条贴紧主循环的轻量闭环。用户下发任务，Agent 经由消息网关调用终端工具。执行反馈与用户纠正产生分叉，一部分写入策展记忆，一部分沉淀为 Skills。当新任务到来，系统通过 session_search 将历史记忆与技能一并汇入下一轮上下文。

上下文进化解决的问题是Agent 的「金鱼记忆」与重复试错成本。在早期开发中，大模型每次新建会话都会丢失之前的上下文。昨天刚通过多轮对话教会它如何绕过内网的 SSL 证书校验，今天遇到同样的报错，它依然会从零开始盲目重试。上下文进化通过持久化存储（如 SQLite 配合 FTS5 全文检索），让 Agent 在行动前先查阅历史成功路径，直接跳过无效的探索阶段。

适用于单兵作战的个人助手、轻量级代码副驾、日常办公辅助。只要底层大模型的推理能力在线，且任务经验不需要跨团队、跨设备共享，这是投入产出比最高的一层。它不需要复杂的评测沙箱，几百行代码就能让单体 Agent 的可用性产生质变。

技能进化

上下文闭环再往前一步，就是把经验沉淀成可复用技能。

当经验开始重复出现，必须将其从松散的记忆层提升到结构化的技能层。把经验外化成结构化的 SKILL.md、技能包或工作流脚本。系统依据执行报错或反馈信号，自动修改技能代码，在测试集中跑通后覆盖老版本，失败则触发版本回滚。

在 Agent Skills 生态里，SKILL.md 充当了 Agent 的程序性记忆，定义了触发时机、执行脚本、环境约束和异常处理逻辑。

SKILL.md 这一类开放技能格式，是这波 Agent 工程里比较实用的中间层，它有如下的特点：

• 比记忆更结构化
• 比代码改动更轻
• 比参数训练更便宜
• 可迁移、可 diff、可版本化、可回滚

所以当我们发现某类经验开始重复出现，就不应该继续把它留在记忆层，而应该上升成技能资产。

Darwin Skill 把 SKILL.md 当作可评测、可回滚的资产。

Hermes Agent 的技能系统不是静态文档库，它允许 agent 自己创建、编辑、补丁、删文件、写附属文件。核心工具是 skill_manage。[skill_manager_tool.py]

Hermes Agent 的技能进化，并不完全依赖用户主动说「把这个存成技能」。

它有两层自动复盘机制。

第一层是 nudge。memory 按用户回合数触发，skills 按工具迭代次数触发。达到阈值以后，系统会在主任务完成后，后台 fork 一个 review agent，让它复查当前会话，看有没有东西值得落 memory 或 patch/create skill。[run_agent.py] run_agent.py#L2448-L2547 [run_agent.py] run_agent.py#L11586-L11612

第二层是 guidance。系统提示里直接写明：

• 复杂任务、踩坑任务、发现可复用流程，要考虑存技能
• 技能用着发现过时或不完整，要立刻 patch

它已经把「技能进化」从人工运营动作，拉进了 agent 自己的工作流。系统不再等人整理文档，而是把复盘变成运行时行为。

但这种触发还是偏软。nudge 只是提醒，review agent 还是模型自己判断。只靠提示词和后台复盘，技能库后面大概率会出现三类问题：

• 有价值流程没被沉淀
• 沉淀下来的技能版本缺少来源和上下文
• 技能被 patch 多次以后，质量开始飘

技能进化解决的问题是纯文本记忆的非结构化缺陷。当任务复杂度上升，大模型在处理几万字的自然语言排错记录时极易丢失细节，甚至产生幻觉。复杂的业务需要确定的执行路径。人工维护这些包含几十个步骤的 SOP（标准作业程序）脚本成本极高，且极易因外部 API 的微小变动而全盘失效。技能进化将脆弱的静态脚本转化为能够依据报错信息自我修复的动态资产。

其适用于垂直领域的自动化流水线、运维巡检、复杂数据清洗。当业务要求 Agent 严格遵循既定流程操作，且操作环境（如第三方接口、依赖库版本）会频繁发生变化时，技能进化是维持系统长期稳定运行的唯一解。

群体智能进化

当你有多个 Agent、多台机器、多个用户时，单机技能闭环就不够了。

因为最大浪费会变成另一件事：
同一个坑被不同实例反复踩。

这时候我们就需要一个共享层，把个人经验抽出来，变成全体可复用资产。

这就是群体闭环要解决的问题。

它的收益大，但治理也复杂。因为共享意味着：

• 权限问题
• 隐私问题
• 脱敏问题
• 质量门控问题

等等

Ultron 将散落在各次会话里的经验蒸馏成群体知识，提供 Memory Hub、Skill Hub 和 Harness Hub。

Memory Hub 实现了 HOT / WARM / COLD 分层存储。系统根据命中次数进行再平衡，引入时间指数热度衰减公式 hotness = exp(-α × days)。未经衰减处理的记忆库是一场灾难，Agent 会频繁召回半年前已经废弃的内部 API 规范。

数据入库前，系统通过 Presidio 进行中英 PII（个人身份信息）检测与脱敏。这是企业级落地的底线。一旦某个 Agent 将包含真实客户手机号的排错日志写入群体记忆，整个系统的合规风险将彻底失控。

Skill Hub 负责将进入 HOT 层的记忆结晶为多步工作流技能。Harness Hub 则将人设、记忆、技能打包为蓝图，支持一键导入。这种设计抹平了多实例部署的知识水位差。

其主要解决的问题是规模化部署下的经验孤岛。如果团队里有 50 个开发人员，每个人的 Agent 都在本地独立摸索公司内部 CI/CD 系统的某一个奇葩报错，相当于团队为同一个坑支付了 50 遍大模型的 API 账单。群体智能进化打破了实例之间的物理隔离，让一个 Agent 踩过的坑成为全团队的免疫抗体，抹平多实例部署的知识水位差。

其适用场景于企业级 Agent 矩阵、跨部门研发协同、大型内部工具链。团队规模越大，这层进化的网络效应越明显。前提是必须在共享层前置严苛的 PII（个人身份信息）脱敏与恶意 Prompt 注入拦截机制，防止单一终端的脏数据污染全局技能库。

策略进化

再往下走，就是最重的一层：让系统直接改策略本身。

这里的策略可能是：

• 代码
• 工作流拓扑
• 模型参数
• 策略网络
• 推理路径分配

这层能力上限很高，也很危险。因为一旦我们把真实用户反馈接进训练或策略更新链路，很多以前可以拖着不管的问题会立刻变成硬约束：

• 数据许可
• 脱敏
• 训练延迟
• 奖励劫持
• 评测作弊
• 安全回滚
• 服务与训练解耦

将真实的交互轨迹与成败反馈收集起来，直接修改 Agent 的核心调度代码、工作流拓扑，甚至转化为强化学习（RL）的标量奖励来更新大模型的底层参数。

其主要解决的问题是基座模型能力天花板的绝对限制。无论是追加记忆还是改写技能，本质上都在做外挂。当遇到模型根本无法理解的深层逻辑或极度复杂的推理链条时，外挂方案会全线崩溃。策略进化直接向底层动刀，利用在线交互产生的真实反馈信号（如代码是否编译通过、测试用例是否全绿）来微调模型权重或重构 Agent 的执行逻辑。

主要适用场景是拥有充足算力预算的 AI 基础设施团队、需要将开源模型逼出闭源模型效果的核心业务。这一层工程风险极大。任务必须具备极度清晰、可自动化判别的反馈信号（如数学定理证明、代码生成）。如果反馈信号存在噪声，模型会迅速在错误的梯度中崩溃，产生严重的奖励作弊（Reward Hacking）现象。

核心工程挑战

上面讲了四层进化，但是要落地自进化系统，必须跨越四道工程天堑。

评估器比生成器更重要。没有评估器的自动修改，只是在自动制造生产事故。Darwin Skill 的棘轮、Ultron 的升级门控、OpenClaw-RL 的 PRM，都在解决同一个问题：证明改动没有让系统变坏。评估器的算力消耗通常是生成器的三倍以上。

可回滚是自进化的基础设施。技能层的优势在于天然支持版本化。参数层的更新回滚成本极高。工程实践的逻辑是：能在记忆层解决的异常，绝不改写技能；能在技能层修补的逻辑，绝不修改代码；能在代码层绕过的缺陷，绝不在线更新权重。

共享经验需要严苛治理。群体智能闭环的引入，意味着污染风险的全局放大。一个包含 rm -rf / 的错误技能一旦进入共享库，会摧毁整个团队的开发环境。权限分层、PII 脱敏、候选验证和版本审计，是系统上线的强制前置条件。

技能供应链安全无法事后补救。Agent Skills 已经演变为跨生态的能力封装格式。它包含脚本、远程依赖和执行指令。技能市场必须审查其是否读取敏感路径、是否执行危险命令、是否下载未知来源的 Shell 脚本。沙箱隔离和系统调用拦截必须做在宿主的最底层。

当前可落地执行的路线，不要一步到位堆砌在线 RL。可分阶段实施：

第一阶段，夯实上下文治理。让 Agent 具备最基本的成长能力：记录偏好、总结失败、检索历史。重点是让项目上下文和工具状态形成稳定机制，控制上下文窗口的 Token 消耗。

第二阶段，跑通技能资产沉淀。当排错经验重复出现，将其提取为 SKILL.md。引入类似 Darwin Skill 的测试集与评估机制。这是当前投入产出比最高的一步，能够立竿见影地降低 API 调用成本。

第三阶段，建设跨端群体智能。部署共享存储与演化服务，实现多终端经验的去重、验证与分发。在这个阶段，投入 50% 的研发精力解决隐私脱敏与权限审计问题。

第四阶段，谨慎切入参数与工作流修改。只有当你的 PRM 准确率达到生产可用级别，沙箱隔离足够坚固，版本回滚延迟降到秒级时，才去触碰在线强化学习。

自进化 Agent 的核心壁垒，从来不是模型本身有多聪明，而是底层的评估、沙箱、治理和安全机制有多扎实。

以上。