专家团怎么进化
OpenCorvus 里专家团修订的两条路径——从你的反馈来，或从一次度量活动来——以及它们共同的终点：一次由你给出的确认。
专家团是一个包，不是你改过一次的提示词。它可以被修订，而修订本身也是一个带版本、带 digest、带历史、 带回退路径的包。
进入修订只有两条路径，而且它们的终点都是一次必须由你给出的确认。
路径一 · 从你说过的话来
快路径。它之所以存在，是因为你给一支专家团的最有价值的纠正，往往是任务进行到一半时顺口说的那句—— 而它通常也就随那段对话一起死了。
当你说出一条长期有效的偏好（一条下次同类任务还会适用的偏好）时，专家团可以据此起草修订。 接下来发生的事情完全在宿主侧：
- 逐字节复制当前已安装的精确版本。
- 套用提出的文件改动：Agent 提示词、调度器提示词、选择说明、Skills，或者 manifest 本身。
- 把结果校验成一个可运行的包。
- 发布候选 Artifact，其中记录这条偏好；起草的 Agent 被要求逐字带过去，而不是转述。
- 返回一条需要你接受的确认。
在你接受之前，什么都不会安装；而返回给你的回执，就是撤销它的凭据。
有两条约束值得知道，因为它们能解释被拒绝的原因：
- 能力面不得变宽。 候选如果授予了这支专家团原本没有的 Tool、Skill、基础角色或引用，会被拒绝。 修订可以在 Agent 之间搬运能力，但不能新增能力。
- 声称改写过什么，会被核对。 候选可以声明自己改写了一条冲突指令，也可以声明本来就没有冲突。 一旦声明了改写，宿主就拿字节来核：如果每个改动过的文件都仍以原文开头、只在末尾追加，候选会被拒绝。 追加会让更老、更具体的那条指令继续生效——这也正是「修订之后好像什么都没变」的常见原因。
这条路径没有试验，也没有度量。你的接受就是判决，不应该被描述成「已测试」。
路径二 · 从度量结果来
进化实验室（Evolution Lab）以三条工作流跑一次明确的活动：机会分析、候选准备、活动评估。
顺序是关键。实验规划者在任何候选被撰写之前，就冻结目标版本、用例、评分器、环境、臂序、预算和 变异面。一场评分标准在结果出来之后才定的活动，不是对比。
产出是一组带类型的 Artifact：活动规格、候选修订、运行证据包、评估结果、完整性审查、对比建议。 它们都已持久化，所以这场活动事后是可读的，而不是只剩一份总结。
只有当你明确要求调查、构造、评估、比较、提升或恢复某个版本时，才选择进化实验室。
真正会安装的是什么
有三种操作会改变已安装的包，每一种都是一次独立授权：
| 操作 | 做什么 |
|---|---|
feedback_revision | 安装一个由你陈述的偏好起草出来的候选 |
promotion | 安装一个由活动推荐的候选 |
restoration | 把目标退回它此前持有过的某个版本 |
每一种都需要一条真实的操作者消息，绑定到那个精确的项目、任务与根 Session，并携带该次变更的确切确认 文本。投影出来的 Agent 给不了它，调度器、恢复流程、迟到的结果也给不了。重复同一次授权是幂等的。
历史与回退
每一次活动、每一个修订都会被记录。进化历史会列出一个目标持有过哪些版本，分为当前版本与历史版本。
恢复是一个撤销动作，不是对这份列表的随机访问：它要引用一份此前的变更回执，而且只能把目标退回那份 回执亲眼见过的版本——它装上去的那个 digest，或者它替换掉的那个。引用哪一份回执是自由的，只要它在当前 任务里读得到；所以要退回更早的版本，直接引用当初装上它的那份回执即可。
这仍然是「接受一次修订」之所以是低风险决定的原因：退路是一份已记录的回执，不是一次凭记忆的重建。
边界，说清楚
OpenCorvus 不会在后台改自己的专家团。这里没有自主重写循环，没有静默的版本跳变，也没有任何修订会 因为某个指标动了就安装。上面每一条路径都停在一次确认上，而每一次确认都是你自己发出的消息。