工程生产与受控自我进化

这一页说什么

这是 MYRILUM 的目标架构设计，不代表图中各项都已上线；某项能力现在能不能用，以《当前可用情况》为准。

升级不能绕过和日常运行同样的治理。本页只讲原则，实现细节不公开。

四种权限分开

运行客户任务、实现变更、审核变更、批准发布是四种不同的权限。实现变更的智能体不能批准自己的高影响成果，也不能自行修改资金、权限或治理政策。

每次升级走同一条路

从真实发生的故障、用户的实际需要以及成本和质量上的证据出发，写清问题、方案、目标与非目标、影响范围、测试和回滚办法；拿到范围授权后，在受限环境里实现；用可重复的测试覆盖正常、异常与安全场景；发布前由人批准一个确定的制品和环境，发布后观察效果，不行就回滚，不可逆的动作单独处置。

复核看独立性，不看人数

不同的角色、模型或脚本仍可能犯同样的错。复核要看来源是否真正独立，而不是靠增加参与者的数量。

工程流水线与客户数据隔离

工程流水线不继承客户数据的权限；客户的工具运行也接触不到生产发布的主凭证。

「已测试」要找得到测试

发布依据不靠口头：证据绑定实际的版本和环境，说「已测试」就必须找得到对应的测试和结果。升级不能自行改动人设定的目标、权限或核心政策，要改就重新走规格与批准。

出处

本页依据《MYRILUM 全架构图谱》v2.2 的 A29。按公开边界，这一页只公开原则，不放图。相关：《治理、运营与运行边界》、《可观测性、质量、成本与运营》、《版本、成熟度与路线图》。