通过验证改进闭合反馈循环

定义需要闭合的反馈循环

软件在使用中产生证据，包括错误、延迟、支持请求、事件、维护发现和重复人工工作。完整生命周期会将这些证据反馈给工程决策。

软件自我改进可以指自动化帮助发现、提出、实现和验证修改，不一定意味着模型训练自己。说明变化发生在哪一部分：应用代码、配置、测试、指令、工作流，还是模型参数。

自愈恢复已知运行状态。自我改进改变系统，以便未来产生更好结果。后者需要比较，也需要防止回归。

沿生命周期追踪一项观察

下面是一种建议的工程方法，并不声称任何产品都能自主执行每一步。

保留这些产出之间的链接。复盘行动若只写“改进监控”，就很难验证。明确的信号、负责人、阈值和经过测试的响应，才能让完成情况可观察。

让评估独立于提议

智能体可以创建补丁并提出测试。团队仍须检查这些测试能否发现原始问题。保留有版本的评估集，不允许修改悄悄削弱它。

对于虚构内存泄漏，应比较等效工作负载和版本。纳入大型导出、取消、重试和拒绝访问案例。使用能代表相关数据结构的合成数据，不暴露客户记录。

如果更快的导出丢失记录、绕过授权或超过允许成本，就拒绝它。优化前定义这些约束。否则，系统可能改善选定指标，却让服务更差。

修改智能体指令或模型时，用有代表性的任务和已知失败案例评估行为。保留之前版本。更新指令，不能证明底层模型已经从事件中学会了什么。

发布并测量结果

金丝雀发布让有限用户群使用候选版本。比较候选组与对照组信号，并定义何时扩大或停止。流量稀少或工作负载不同，可能让比较无法得出结论。参见金丝雀发布指南。

虚构团队用固定合成工作负载记录基线，测试修复，在获准边界内发布，再检查可比的生产时段。如果证据仍不足，就记录不确定性，而不是宣布收益。

也要衡量重复人工工作。自动化可以减少这类运维负担，但本身也需要维护和故障处理。判断结果时，计入这些成本。参见减少重复运维工作。

让反馈记录可用

练习使用以下字段：观察与版本；基线；拟议原因；验收标准；回归检查；修改与审查；发布边界；实测结果；负责人和下次复核时间。

Taiga Maintaining 将代码仓库发现关联到修复工作。Initiatives 将预期修改关联到规划和交付。它们提供证据链的一部分，但服务负责人仍须验证部署和运行结果。参见 Maintaining和 Initiatives。

成熟的软件工厂将这些工作跨产品贯通。随着自动化增加，继续明确决策权和评估标准。最终证据是经过验证、变得更好的服务，而不是更多生成的修改。