软件自进化可能是个伪命题：插件会自己变强，也可能自己失控

很多人对“软件自进化”有个浪漫想象：

软件自己发现问题，自己写代码，自己安装插件，自己修复 bug。用户什么都不用管，系统越用越聪明。

听起来很美。

可一旦真把这件事交给模型，场面可能立刻变成另一种画风：配置文件越来越多，插件互相覆盖，行为开始漂移，昨天还能用的功能，今天突然换了一套逻辑。

你以为它在进化。

它可能只是在积累混乱。

“能生成代码”，不等于“能维护软件”

模型现在很擅长写一次性代码。

比如：

• 写一个临时脚本，把几十个文件改名
• 做一个网页抓取器，跑一次数据采集
• 生成一段 SQL，导出本月销售数据
• 做一个小工具，把 Markdown 转成 PDF

这种任务有个共同点：目标明确，使用周期短，出错成本可控。

写错了？重跑一遍。

结果不对？人工检查一下。

真正麻烦的是长期运行的插件和服务。它们需要面对一堆模型不擅长独立处理的问题：

• 需求会变化
• 依赖会升级
• 数据格式会改变
• 用户习惯会漂移
• 不同插件之间会互相影响
• 一次修复可能破坏另一个功能
• 出现事故后，需要定位、回滚和追责

这已经不是“写一段代码”的问题了。

这是完整的软件工程。

插件只有两种命运

一个插件要么是一次性工具，要么是需要长期维护的产品。

一次性插件：可以快，但别装成永恒方案

比如你让 Agent 写一个脚本，把某个目录里的图片压缩后上传。

这种插件可以临时生成，用完即删。只要权限收紧，输入输出可控，风险并不高。

它的价值在于省下半小时手工操作。

别指望它自动成长成一套稳定图片处理平台。那是另一项工程。

长期插件：必须有设计、测试和维护

如果插件每天都要运行，处理真实用户数据，还连接了支付、数据库、邮箱或内部系统，要求就完全不同了。

你至少需要准备：

• 清晰的功能边界
• 固定的输入输出协议
• 权限控制
• 日志和监控
• 自动化测试
• 版本号
• 灰度发布
• 一键回滚
• 人工审批节点

少一个环节，系统就多一块盲区。

模型可以帮你写实现，也可以帮你补测试、生成文档、分析日志。可它不该直接拥有“改完就上线”的权力。

OpenClaw 的 Skills，已经暴露了问题

以 OpenClaw 这类 Agent 系统里的 Skills 为例。

Skills 看起来像能力插件：需要什么，就让模型生成一个；发现问题，就让模型修改；用得多了，系统似乎会越来越强。

可实际使用一段时间后，常见问题很快会冒出来：

• 同一个任务出现多个功能相近的 Skill
• Skill 描述互相冲突，模型不知道该调用哪个
• 临时修复被当成正式能力长期保留
• 旧版本没有清理，新版本又叠加上去
• 权限范围越来越大
• 失败原因被新逻辑覆盖，无法复盘
• Skill 数量增加后，模型选择错误的概率上升

这就像你在办公桌上不断堆工具。

剪刀、胶水、螺丝刀越堆越多，不代表工作更快。到了某个临界点，你连一把合适的剪刀都找不到。

问题不是模型不会生成 Skill。

问题是系统缺少“能力治理”。

软件自进化，最容易混淆三件事

1. 自动生成

模型根据需求写出代码或配置。

这件事已经相当成熟，适合低风险、短周期任务。

2. 自动适配

系统根据输入变化，调整参数、路由或提示词。

这类能力也有实用价值。比如根据用户查询类型，自动选择不同的检索策略。

3. 自动改变自身结构

系统自己新增插件、修改核心逻辑、替换依赖，再把结果投入生产环境。

风险主要集中在这里。

因为它改变的不是一次任务的答案，而是系统未来的行为。

一旦改错，错误可能被重复执行几千次。更麻烦的是，系统可能把错误修复当成正确经验继续累积。

更靠谱的方案：让模型参与进化，不让模型独自决定进化

真正可用的架构，可以把“自进化”拆成一条受控流水线：

发现问题
  ↓
生成候选修改
  ↓
自动测试
  ↓
安全检查
  ↓
沙箱运行
  ↓
小流量灰度
  ↓
人工确认
  ↓
正式发布
  ↓
持续监控与回滚

模型负责提出方案。

测试系统负责拦截错误。

人工负责关键决策。

这才是工程上能落地的“半自动进化”。

给插件系统加上四道闸门

闸门一：能力注册

每个插件都要有明确登记信息：

name: image-compressor
version: 1.3.0
purpose: 压缩图片并输出 WebP
inputs:
  - file_path
outputs:
  - compressed_file
permissions:
  - read_selected_directory
network_access: false
owner: content-team
status: active

别让模型随手生成一个没有名字、没有版本、没有权限说明的黑盒子。

闸门二：变更审查

任何涉及以下内容的修改，都要进入人工审批：

• 新增网络访问
• 扩大文件读写范围
• 修改数据库结构
• 更换外部 API
• 删除旧逻辑
• 修改支付、权限、身份认证相关代码

模型说“这是为了修复 bug”，不代表它真的修好了 bug。

闸门三：隔离运行

新生成的插件先放进沙箱。

限制它能看到的数据、能访问的网络、能调用的系统命令。跑几组真实但脱敏的样本，观察结果是否稳定。

别直接让一个刚生成的 Skill 接触生产数据库。那不是自动化，是拿公司数据做压力测试。

闸门四：可回滚

每次发布都要保留：

• 修改前版本
• 修改后版本
• 触发修改的原因
• 测试结果
• 发布人或审批人
• 运行指标

如果新版本让错误率上升，必须能在几分钟内恢复旧版本。

没有回滚能力的自动进化，等于把方向盘拆了，再宣布汽车会自己开。

哪些场景适合交给模型自动处理？

可以放手的任务，通常具备这些特点：

• 影响范围小
• 输入输出清晰
• 失败成本低
• 结果容易验证
• 不涉及敏感权限
• 可以随时删除或回滚

例如：

• 自动整理文件名
• 生成报表草稿
• 清洗格式混乱的文本
• 为代码补充单元测试
• 根据日志生成排查建议
• 创建临时数据转换脚本

需要谨慎的任务包括：

• 自动修改生产代码
• 自动升级核心依赖
• 自动改变权限策略
• 自动操作财务系统
• 自动删除数据
• 自动训练并替换线上模型
• 自动创建拥有高权限的新插件

判断标准很简单：

这个修改出了问题，能不能快速发现，能不能快速恢复？

两个答案里有一个是否定的，就别让模型直接上线。

别急着等“模型自学习”解决一切

有人会说，等模型未来拥有更强的自学习和自进化能力，软件维护自然就简单了。

这可能会改善一部分问题，却不会消灭软件工程。

模型能力越强，能修改的范围越大，错误造成的影响也可能越大。一个只会改错一行代码的模型，危险有限。一个能重构整个系统、调整权限和部署链路的模型，出错时会更难控制。

真正重要的不是模型会不会自己学习。

而是系统有没有边界、证据和刹车。

一份可直接使用的检查清单

准备让 Agent 自动创建或修改插件前，检查这几项：

• [ ] 插件解决的问题是否足够具体？
• [ ] 能否用一次性脚本完成，而不是长期驻留？
• [ ] 输入和输出是否有固定格式？
• [ ] 是否限制了文件、网络和系统权限？
• [ ] 是否有自动化测试？
• [ ] 是否经过沙箱验证？
• [ ] 是否记录了版本和变更原因？
• [ ] 是否支持灰度发布？
• [ ] 是否可以一键回滚？
• [ ] 是否有人负责后续维护？
• [ ] 插件失效后，业务能否继续运行？

如果最后一项答案是否定的，说明它已经不是“小工具”，而是核心系统的一部分。

那就别再用“模型随便生成一下”的标准对待它。

写在结尾

“软件自进化”不是完全做不到。

真正的问题是，很多方案把“自动生成”直接跳到了“自动接管”。中间缺了测试、审查、权限、监控和回滚。

插件可以由模型生成。

能力可以自动发现。

配置可以持续优化。

可一旦涉及长期运行和真实数据，软件就必须回到工程逻辑：可验证、可追踪、可恢复。

咱们真正需要的，不是一个会无限长大的软件怪物。

而是一套能帮你省时间、出问题能刹车、出了事故还能找回来的系统。