演化闭环

系统部署之后不是终点：任务会失败、上下文会出现缺口、流程会暴露重复劳动。演化闭环（Evolution Loop）把这些信号转化为受治理的改进——观察、诊断、提案、审批、灰度发布、度量、更新语义层，七步循环，让组织能力随使用持续累积而不失控。

// 核心命题

自演化不能理解为 Agent 自己无限改自己，而应该是受治理的闭环：每一次改进都有提案、有审批、有灰度、有度量、有回滚。演化的速度来自闭环的吞吐量，演化的安全来自闭环的闸门。

为什么演化必须受治理

"让 Agent 自我改进"听起来诱人，但不受约束的自演化是平台的首要风险之一：Agent 可能为了完成任务而放宽自己的权限、修改自己的策略、绕过审计通道——每一步局部看都"合理"，叠加起来就是失控。对应的缓解措施只有一条：所有策略变更必须有 proposal、approval、rollback。

演化闭环把这条原则工程化。它在 六层架构 中位于 L6（Observability & Evolution Layer），职责可以概括为 Evolution Governance & Cross-Department Orchestration：收集全平台的运行信号，治理改进提案的生命周期，并编排跨部门的灰度推广。Agent 可以发起演化，但不能批准演化；闭环保证每次变更在生效前经过人类负责人或强策略规则的闸门，在生效后有数据证明它确实有效。

闭环七步

一次完整的演化从信号到语义层更新，经过七个步骤：

01 Observation观察

收集任务成功率、失败原因、上下文缺口、人工接管点。信号来源是机制化的：Action Log 提供每次动作的发起者、版本与结果；Context Gateway 的上下文包记录可被评估器回放，用于定位检索质量问题；人工接管点标记了 Agent 能力的真实边界。观察是持续后台过程，不依赖有人"想起来去看"。

02 Diagnosis诊断

判断问题属于哪一类：工具缺失、权限过窄、Ontology 关系缺失、提示策略不佳，还是流程设计问题。归因决定后续动作的目标层——同样是"任务失败率高"，工具缺失要改 Cell 的工具注册，权限过窄要走策略调整，关系缺失要改语义层，混淆归因会让改进打在错误的层上。

03 Proposal提案

Agent 或评估器生成改进提案。提案是结构化对象而不是一段聊天：它声明改什么（目标对象与差异）、为什么改（关联的观察证据）、预期效果（验证指标）、影响范围（哪些 Cell、哪些对象类型）以及回滚方式。提案本身写入文件系统并进入审计链，被拒绝的提案也保留——它们是下一轮诊断的输入。

04 Approval审批

人类负责人或策略规则批准。低风险、影响范围小的提案可以由预先定义的策略规则自动批准（例如调整某个 Cell 内部的检索参数）；触及权限、跨部门共享、语义 schema 的提案必须由对应目录的人类负责人审批。审批记录绑定审批人与提案版本，写入 Action Log。

05 Deployment灰度发布

灰度发布到单个部门 Cell。批准的变更不会全平台同时生效，而是先在一个 Cell 上运行——Cell 的隔离边界（独立文件系统、独立运行时、独立审计）天然就是灰度边界，变更出问题时影响被锁定在一个部门内。发布前对目标 Cell 做 snapshot，保证可以整环境回退。

06 Measurement度量

对比指标，确认有效后推广。度量使用与 Observation 相同的指标体系（成功率、失败原因分布、人工接管率），对比灰度 Cell 在变更前后、以及与未变更 Cell 之间的差异。数据支持结论才推广到更多 Cell；不达预期则触发回滚，并把负结果写回观察记录。

07 Ontology Update语义层更新

必要时更新 Object / Link / Action / Interface。如果改进被证明有效且涉及语义层——新增对象类型、补充关系、定义新的受控动作——最后一步把它写入 Ontology 并升级语义版本。从这一刻起，全平台的 Context Gateway 路由、权限判定和审计合约都基于新语义工作；更新失败则回滚到上一稳定版本。

什么可以演化

闭环对演化对象是白名单制的。允许进入闭环的五类对象，覆盖了从单个 Agent 的行为到组织流程的不同层面：

演化对象典型触发信号审批通道
Agent prompt 和工具选择策略任务失败归因为提示策略不佳或工具误选Cell 负责人，低风险可策略自动批准
Context Gateway 的检索和压缩规则上下文缺口、上下文包回放显示检索质量差平台负责人
Ontology schema 的新增对象、关系和 action诊断为语义缺失，Agent 无法表达或定位某类实体语义层人类负责人，强制走完整闭环
部门文件结构和 SOP重复流程、交付物落点混乱、人工接管点集中对应目录的 C-suite 负责人
自动化任务编排稳定重复的多步任务出现、跨 Cell 流程固化涉及的各部门负责人会签

共同点是：这五类对象的错误变更都可以被度量发现、被回滚撤销，且影响范围可以用灰度控制。这正是它们被允许自动演化的前提。

什么禁止自动演化

// 禁止自动演化

以下对象不允许进入自动演化通道，必须保留人工批准或强策略审批：高权限 IAM 策略；KMS 和 secrets 管理；跨部门敏感数据共享规则；生产环境破坏性动作。

共同特征是失败不可逆或不可度量：权限放宽后泄露的数据收不回来，密钥边界被破坏后审计链无法自证，破坏性动作没有"灰度一下看看"的余地。任何触及这四类对象的变更，无论由谁发起，都必须由人类负责人显式批准。

这条边界在运行时也被强制执行，而不只是流程约定：禁止 Agent 自行修改 IAM 策略、KMS、security group；禁止 Agent 自动扩大自己的文件系统与网络策略；沙箱的文件与进程策略在创建时锁定，Agent 进程没有改写它们的通道（见 AWS 部署映射）。换言之，"不允许"不是依赖 Agent 自觉，而是它在基础设施层就做不到。

灰度发布与回滚

闭环的第 5、6 步合起来构成变更的安全释放机制。一次变更的标准路径是：

  1. 快照

    对目标 Cell 做 snapshot（运行环境、配置、策略），建立可整体回退的基线；策略与配置类变更同时在 Git 中留下变更前版本。

  2. 单 Cell 灰度

    变更只发布到一个部门 Cell。Cell 边界即灰度边界：独立文件系统、独立运行时、独立审计缓冲，故障影响被物理锁定在一个部门。

  3. 对比度量

    用统一指标对比变更前后与未变更 Cell：任务成功率、失败原因分布、人工接管率、上下文缺口频次。度量窗口由提案声明，不允许"看起来没问题"式的主观放行。

  4. 推广或回滚

    指标改善则逐 Cell 推广，每步推广沿用同样的快照与度量纪律；指标恶化或出现未预期行为则立即回滚，负结果写回观察记录，成为下一轮诊断的证据。

回滚路径按对象类型预先定义，与 可靠性与降级 中的版本化机制共用同一套基础设施：

变更对象回滚机制
Agent 运行环境（策略、模型、工具）变更前 snapshot，失败时 restore 整环境
策略与配置（policy YAML、IaC）Git revert + 重新下发，历史版本即回滚点
Ontology schema语义版本化，更新失败回滚到上一稳定版本；在途任务继续使用上下文包绑定的旧版本
部门文件结构与 SOP文件系统版本化与备份，目录级回退
// 治理规则

没有回滚方案的提案不进入审批。提案必须声明回滚方式与度量指标，缺一不可；灰度发布前必须完成 snapshot。这三项由闭环流程强制检查，而不是依赖提案人自觉。

与自演化 Ontology 的关系

概念页 自演化 Ontology 回答"为什么"：企业语义层不应依赖一次性建模，而应在真实使用中持续修正自己——任务失败、上下文缺口、重复流程都是语义层需要演化的信号。本页回答"怎么做"：这种演化由七步闭环工程化执行，信号从 Observation 进入，语义变更从 Ontology Update 落地，中间隔着诊断、提案、审批、灰度和度量五道闸门。

两页合起来构成一个完整论断：语义层的生命力来自演化，演化的可信度来自治理。没有闭环的"自演化"是失控，没有演化的语义层会退化为一次性建模——上线即过时。

相关阅读