# 工程生产与受控自我进化

MYRILUM 可以用 AI 建设 MYRILUM，但运行客户任务、实现、审核与发布四种权限相互分开；每一次升级都走同一条路：观察→规格→实现→验证→人工批准→发布→度量。

> Document ID: MYRILUM-DOC-ARCH-029
> Document type: concept
> Product: NOT_APPLICABLE
> Version: 0.1.0
> Region: GLOBAL
> Visibility: PUBLIC
> Publication: PUBLISHED_GLOBAL
> Content maturity: DRAFTED
> Governance: APPROVED
> Capability state: IN_DEVELOPMENT
> Availability: NOT_AVAILABLE
> Authorization: PUBLIC_INFORMATION
> Freshness: CURRENT
> Safety class: INFORMATIONAL
> Owner: Web3Capital Documentation Steward
> Approvers (assignment only; not approval evidence): Stephen
> Canonical authority: SRC-ARCHITECTURE-ATLAS-V2-2
> Source commit: 6b41cce4496de03c67a501aa94cd41ec6ac0e85a
> Content digest: 6e2fd0c58a0ea5c04b486d655cc87c329c5e7cee6740e957ed8b9a53919106f7
> Effective: NOT_SET
> Expires: NOT_SET
> Last verified: 2026-09-23
> Review due: 2026-10-23
> Command authority: NONE
> Canonical URL: /zh-cn/architecture/engineering-and-evolution

<a id="overview"></a>

## 这一页说什么

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

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

<a id="separated-rights"></a>

## 四种权限分开

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

<a id="one-path"></a>

## 每次升级走同一条路

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

<a id="review-independence"></a>

## 复核看独立性，不看人数

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

<a id="pipeline-isolated"></a>

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

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

<a id="evidence-bound"></a>

## 「已测试」要找得到测试

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

<a id="source"></a>

## 出处

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

---

This document is read-only, grants no command authority, and does not authorize deployment, payment, provider modification, or any other real-world action.