自进化 Agents Team 系统技术方案

本文遵循 AGENTS.md 的协作协议与循证要求。

设计核心锚定：

• 调研基础：自进化 Agents Team 调研
• 理论先例：Routine 迭代模式调研
• 子系统参考：Routine 系统、Skills 设计、可观测性
• 记忆/知识参考：记忆系统、记忆白皮书、知识库、知识图谱
• 权威源：engine/routine/decision.py（护栏范式）、models/skill.py（版本快照范式）

#0. 范围与定位

#设计对象

总纲：进化 = 数据变更（DB 白名单字段），框架 = 代码（变更唯一通道 Git PR 人工 Merge，复用 Routine pr_url 产 PR 等待人工 Merge 的既有先例）。

记忆/知识系统兼具进化基质（substrate）（反思、playbook、采收用例的沉淀介质）与进化客体（object）（自身配置可被进化回路优化）双重角色——概念定义见调研报告 §6.1，回路边界裁定见 ADR-4。

范围外：模型权重训练/微调、框架代码的自动合并。

#1. 理论锚点与核心论断

#1.1 核心论断

本系统不是「从零造进化框架」，而是把平台已分散存在的四个进化原语收敛为一条统一的 遥测 → 评测 → 提案 → 验证 → 门控发布 流水线：

#1.2 学术锚点

#2. 四层架构总览

#2.1 「框架不自改」四道边界

参考 engine/routine/decision.py 的护栏纯函数范式：

1. 晋升/回滚判据为纯函数硬编码：新增 engine/evolution/decision.py，与 routine/decision.py 同构——无 IO、可单测、阈值不读自可被进化的表；
2. DB 权限隔离：进化 worker 使用独立 DB role，仅授予进化登记簿 + 资产版本表写权限，无法 UPDATE 框架配置表；
3. 进化对象白名单为代码常量：枚举 target_kind（agent_prompt / skill_template / builtin_tool_config / mcp_pipeline / memory_pipeline_prompt / retrieval_config / knowledge_strategy），新增类型必须改代码走 PR；
4. 框架改进降级为 PR 提案：由 Routine（Claude Code）起草 PR，人工 Merge，绝不自动合并。

#3. 遥测子系统（数据地基）

#3.1 现状盘点

关键论断：记忆子系统是唯一已有「检索 → 引用（was_referenced）→ 结果反馈（outcome_feedback）」全链遥测的层——tool_invocations 的归因设计应向其对齐，而非反向重建。

#3.2 新表 tool_invocations

统一工具调用事实表（append-only），关键字段：

tool_invocations
├── id                    UUID PK
├── caller_kind           ENUM(adk_agent, routine, skill_invoke, mcp_trial, scheduled_task)
├── agent_name            TEXT NULLABLE        -- 调用方 Agent
├── thread_id             UUID NULLABLE        -- 会话（松耦合，对齐 ToolExecution.run_id 注释）
├── routine_iteration_id  UUID NULLABLE        -- Routine 关联
├── tool_kind             ENUM(builtin, mcp, adk_function, skill)
├── tool_ref              TEXT                 -- 工具标识
├── tool_version          TEXT NULLABLE        -- 版本（skill 时为 SemVer）
├── skill_ref             TEXT NULLABLE        -- 技能展开时的技能标识
├── status                ENUM(success, error, denied, timeout)
├── latency_ms            INTEGER
├── error_class           TEXT NULLABLE
├── input_digest          TEXT NULLABLE        -- 截断摘要 + hash（16KB 上限）
├── output_digest         TEXT NULLABLE
├── tokens_in/out         INTEGER NULLABLE
├── cost_usd              FLOAT NULLABLE
├── trace_id/span_id      TEXT NULLABLE        -- 反查 Langfuse
├── canary_assignment     TEXT NULLABLE        -- 进化实验标记
├── outcome_score         FLOAT NULLABLE       -- 异步归因回填
├── outcome_source        TEXT NULLABLE        -- (routine_verdict, thread_feedback, attribution_job)
├── created_at            TIMESTAMPTZ

字段对齐 OTel execute_tool span schema（gen_ai.tool.name → tool_ref、gen_ai.tool.type → tool_kind、gen_ai.tool.call.arguments/result → input/output_digest）。

#3.3 采集挂点（三源归一）

1. ADK 侧：新增 before/after_tool_callback（当前仓库未用，是新挂点）统一上报；
2. Routine 侧：由 streaming_persister 写 routine_iteration_events 时旁路双写；
3. MCP trial 侧：由 McpToolExecutionService 旁路双写。

#3.4 聚合与反馈

• tool_stats_daily 聚合表：成功率 / p50·p95 延迟 / 成本 / 调用量，按 tool_ref + version 分桶；
• memory_stats_daily 聚合表：zero_hit_rate / referenced_rate / helpful_ratio / fallback_rate / conflict_rate，按检索 strategy + config version 分桶（数据源 memory_retrieval_logs + memory_conflicts + _log_fallback_event）——config version 分桶即 §7.3 金丝雀对比的现成报表基础；
• interaction_feedback 新表（对齐 knowledge_feedback 范式）：thread_id / event_id / agent_name / feedback_type(thumbs_up/down|rating|correction) / score / comment / source(human|code|llm_judge)；
• Langfuse 深接：proposal_id / eval_run_id / canary_assignment 写入 trace metadata。

#4. 评测子系统

#4.1 新表四件套

eval_suites
├── id                    UUID PK
├── target_kind           ENUM(agent, skill, builtin_tool, mcp_tool, pipeline,
│                              memory_retrieval, knowledge_retrieval, kg_extraction)
├── target_ref            TEXT
├── scoring_config        JSONB (judge 模型 + rubric + 可选 gate 命令)
├── is_frozen             BOOLEAN DEFAULT false  -- 冻结 holdout 集标记
├── holdout_ratio         FLOAT DEFAULT 0.2      -- 冻结集占比
├── owner_id              UUID
├── visibility            ENUM(private, team, public)

eval_cases
├── id                    UUID PK
├── suite_id              UUID FK
├── input                 JSONB
├── expected              JSONB / rubric 文本
├── weight                FLOAT DEFAULT 1.0
├── tags                  TEXT[]
├── source                ENUM(manual, harvested, synthetic)
├── provenance_ref        TEXT NULLABLE           -- 采收来源（tool_invocation / thread）

eval_runs
├── id                    UUID PK
├── suite_id              UUID FK
├── target_kind/ref/version  TEXT
├── baseline_version      TEXT NULLABLE
├── trigger               ENUM(proposal, scheduled, manual)
├── score_mean / pass_rate / cost_total / latency_p95 / regression_count
├── status                ENUM(running, completed, failed)

eval_results
├── id                    UUID PK
├── run_id                UUID FK
├── case_id               UUID FK
├── score                 FLOAT
├── verdict               TEXT
├── output_digest         TEXT
├── judge_raw             JSONB                   -- 审计（对齐 evaluator.py 全过程审计）

#4.2 评测执行器

复用 engine/routine/evaluator.py 范式：LLM-as-Judge（resolve_model_config_async + litellm.acompletion + JSON 结构化输出 + 指数退避）+ 可选客观门控命令锚定评分。

记忆/知识 suite 不重建 runner：

• 记忆检索 suite：026 白皮书已有 LoCoMo-mini / LongMemEval-mini CI 基线（recall 0.933 / 0.867），注册为 eval_suites 行纳管（target_kind=memory_retrieval，gate 命令即现有 CI 脚本）；
• KG 抽取 suite：复用 knowledge/graph/quality.py 的综合质量分（完整性/覆盖/置信度/证据四维加权）+ metrics.py 构建指标（chunks_fallback / over_extraction_chunks / entity_density_p95）作客观门控——对齐"可选 gate 命令锚定评分"既有设计。

#4.3 Golden Set 双轨（Goodhart 防护）

• 公开集（is_frozen = false）：提案优化时可见，允许迭代拟合；
• 冻结 holdout 集（is_frozen = true）：仅晋升裁决时运行，结果不回流 proposer——防止单一指标过拟合。

#4.4 在线信号融合

晋升判据 = 离线分 AND 在线金丝雀指标（成功率 / 成本 / 延迟 / 用户反馈）双确认，任一退化即否决。权重与窗口硬编码在 evolution/decision.py。

记忆/知识配置的晋升判据额外增加：zero_hit_rate 与 referenced_rate 不退化（窗口与阈值同样硬编码于 evolution/decision.py）。

#4.5 用例采收回路

失败的 tool_invocation / 被 thumbs_down 的交互 / Routine 失败迭代 → 半自动转化为 eval_case（source=harvested），人审后入 suite——评测集随真实失败自动长大。

#5. Agent 自迭代回路

#5.1 版本化（先决条件）

新表 agent_versions 严格对齐 models/skill.py 的 skill_versions 范式：

agent_versions
├── id                    UUID PK
├── agent_id              UUID FK → agents
├── version               VARCHAR(32)            -- SemVer（如 1.2.3）
├── snapshot              JSONB                  -- 冻结 system_prompt / model / skills / tools
├── origin                ENUM(code_sync, evolution, manual)
├── is_active             BOOLEAN DEFAULT false
├── is_stale              BOOLEAN DEFAULT false  -- 基线更新后标记
├── created_at            TIMESTAMPTZ
├── UNIQUE(agent_id, version)

agents 表新增：active_version VARCHAR(32) NULLABLE（指针）+ baseline_origin TEXT。

#5.2 解析顺序改造

agents/_dynamic_instruction.py 的加载逻辑改为：

active_version 指向的快照 > agents.system_prompt（代码 Sync 基线） > 代码硬编码 fallback

Sync 改造（解决 interface/api.py sync_negentropy_agents 的覆写冲突）：

• sync_negentropy_agents 改为「只更新基线 + 落一条 origin=code_sync 的版本行，绝不触碰 active_version」；
• 进化版本晋升后若基线更新（代码改了 prompt），自动将该进化版本标记 is_stale 并要求重评——显式拒绝自动三方合并（交还人/重新进化）。

#5.3 GEPA/ACE 式反思驱动 Proposer

输入 = 该 Agent 近期失败样本（tool_invocations + interaction_feedback + routines.reflections）+ 当前 prompt； 输出 = 结构化 evolution_proposals（diff + rationale + evidence 引用）。

实现范式复用 engine/consolidation/reflection_generator.py（retry + JSON + 降级）。每次变异幅度受限（diff 行数上限 + prompt 长度硬上限约 1,500 字符，Decagon 经验：4 倍压缩仅损 0.8%）。

#5.4 回路状态机

reflect → propose(draft)
  → shadow_eval（跑离线 suite，对比 baseline）
  → pending_approval（按风险等级可自动）
  → canary（thread/user 哈希分桶 N%，运行时在 InstructionProvider 处按 assignment 解析候选版本）
  → promote / rollback

• 晋升 = 改 active_version + invalidate_cache(prefix="subagent:")，60s 内全量生效；
• 回滚同理（秒级、无部署）；
• 金丝雀路由天然挂点：config/model_resolver.py 的 TTL 缓存（60s）按 assignment 分键。

#5.5 与 Routine 闭环的关系

进化提案的生成与验证默认走轻量 in-engine worker（consolidation_jobs 队列范式）；仅当提案需要重型工作（如同时改 skill 资源、写评测用例文件）时，将其降级派发为一个 Routine（goal=改进提案、acceptance_criteria=评测达标），完整复用其预算守卫/审批/审计。

#6. 技能/工具自迭代回路

#6.1 Skills 进化（最低悬挂果实）

models/skill.py 的 skill_versions 已就绪，补三件事：

1. per-skill eval_suite（评测驱动准入）；
2. proposer（变异 prompt_template / default_config）；
3. skills 表加 active_version 指针（区分「最新」与「已晋升」）。

Agent 侧 name@semver 锁定（_parse_skill_ref 已实现）使金丝雀可按 Agent 粒度灰度（部分 Agent 引用候选版）。

#6.2 Builtin Tools 进化

进化对象 = builtin_tools.config JSONB（参数级，如检索 top_k / 超时 / Prompt 片段）。新增 builtin_tool_versions 快照表（同范式）。credentials 永不进入快照与进化范围（脱敏边界既有）。

#6.3 MCP / Pipeline 进化

perceives 的 competition_mode 从「运行时每次竞争」升格为「进化证据源」——竞争评审结果回流为 tool_invocations 的相对效果数据，提案器据此调整 StageToolConfig.rank/enabled 与引擎参数。

注意：pipeline YAML 当前在配置文件不在 DB。Phase 3 仅 DB 化 stage 工具排序等安全子集，全量 DB 化留作远期议程。

#6.4 工具效果三级评分

#6.5 Agent 自造技能（Phase 4，Voyager 式）

流程：Agent/Routine 起草 skill（沿用 skill_templates/*.yaml 模板 schema + SemVer 强校验）→ Jinja2 沙箱静态检查 → 沙箱试运行（engine/sandbox/）→ 影子评测 → 强制人审（新技能一律 pending_approval，无自动晋升通道）→ 入库 visibility=private 试用期 → 效果达标后才可申请 is_global（is_global 晋升永远人审）。

#6.6 删除/退役回路

长期低分 / 零调用的技能与工具版本自动生成「退役提案」，同样走门控——防能力库熵增（呼应 negentropy 主题）。

#7. 记忆与知识系统自迭代回路

#7.1 双重角色与回路边界（ADR-4 的展开）

记忆/知识系统兼具基质与客体双角色（定义见调研报告 §6.1）。工程上的关键裁定是分轨：

• 条目级演化（基质侧，高频）：fact 写入/更新、反思生成、ACE 式 delta 沉淀、记忆淘汰——继续走既有 consolidation 回路（consolidation_jobs 队列 + reflection_worker），不进 evolution_proposals 状态机。条目级操作每天成百上千次，状态机门控会成为瓶颈；且其已有 retention / dedup / conflict 三重治理。Letta sleep-time compute^[12] 证明离线巩固窗口是该回路的正确调度时机——consolidation_jobs 即既有实现；
• 配置级进化（客体侧，低频）：检索参数、遗忘 λ、管线 prompt、抽取策略的变更——走 evolution_proposals 统一状态机，享受 shadow eval / canary / 人审门控全套保护。

#7.2 可进化资产白名单

前置依赖：表中多数参数现为 env（HippoRAGSettings）或代码常量（_MEMORY_TYPE_DECAY_RATES）——进化回路无法直接写。需先做"白名单参数 DB 化"迁移（配置版本表见 §7.3），列入 Phase 3 范围；在迁移完成前，这些参数的"进化"以提案生成 + 人工改 env/代码的半自动形态运行。

#7.3 配置版本化与金丝雀

• 新表 memory_config_versions：范式同 builtin_tool_versions（JSONB 快照 + SemVer + is_active 指针 + origin），按 config_scope（retrieval / forgetting / pipeline_prompt / knowledge_strategy）分领域——延续 ADR-2 的"登记簿泛型 + 快照专表"原则；
• 金丝雀挂点：检索入口按 thread 哈希分桶解析候选配置（同 §5.4 的 InstructionProvider 模式）；memory_stats_daily 按 config version 分桶即金丝雀对比报表（§3.4 已铺垫）；
• 回滚语义的本质差异（必须显式声明）：回滚 = 配置指针回退，配置可逆；但配置生效期间写入的记忆条目内容不在回滚范围——坏配置（如过激的 extractor prompt）产生的劣质条目需依赖既有治理（conflict 检测、retention 衰减、audit）逐步消化。这是记忆配置进化与 Agent prompt 进化的本质差异，也是其门控档普遍更严的原因。

#7.4 基质侧：进化经验沉淀于记忆系统

客体回路反向滋养基质——进化流水线自身的经验写回记忆系统，形成数据血缘闭环：

• 提案成败反思：evolution_proposals 的 rejected / rolled_back 记录经 reflection 化沉淀（复用 reflection_generator.py），供 proposer 检索为负样本——ReasoningBank^[13] 证明失败经验与成功经验同等可蒸馏且无需 ground-truth 标签；
• 采收溯源：评测用例采收（§4.5）的 provenance_ref 可经 memory_retrieval_logs 反查到具体检索行为——基质（用例从记忆性失败中采收）与客体（配置因失败被改进）在数据血缘上闭合；
• ACE 计数复用：playbook 条目的 helpful/harmful 计数直接映射 MemoryRetrievalLog.outcome_feedback（helpful/irrelevant），条目去重复用 governance/reflection_dedup.py。

#8. 进化编排：流水线状态机与调度

#8.1 evolution_proposals 统一登记簿

evolution_proposals
├── id                    UUID PK
├── target_kind           ENUM(agent_prompt, skill_template, builtin_tool_config, mcp_pipeline,
│                              memory_pipeline_prompt, retrieval_config, knowledge_strategy)
├── target_ref            TEXT
├── base_version          TEXT
├── proposed_version      TEXT
├── payload               JSONB (diff / 快照)
├── origin                ENUM(reflection, telemetry_anomaly, competition, human, routine)
├── rationale             TEXT
├── evidence              JSONB
├── status                ENUM(draft, shadow_eval, pending_approval, approved, canary, promoted, rejected, rolled_back, stale)
├── shadow_eval_run_id    UUID NULLABLE
├── canary_config         JSONB (比例/范围/窗口)
├── canary_metrics        JSONB
├── risk_level            ENUM(low, medium, high)
├── decided_by            UUID NULLABLE
├── decided_at            TIMESTAMPTZ
├── created_at / updated_at TIMESTAMPTZ

#8.2 调度复用统一心跳

evolution_inspector 作为新 Scheduler job 注册进 engine/schedulers/registry.py（与 routine_inspector 并列）。tick 内推进状态机（与 engine/routine/orchestrator.py 的 REAP/EVAL/DISPATCH 三段式同构：领取 due 提案 → 推进一步 → FOR UPDATE SKIP LOCKED 幂等）。

#8.3 并发约束

每 target 同时至多一个非终态提案（对齐 Routine「单在途」不变量）；canary 期间禁止该 target 的新提案进入 canary。

#9. 护栏与治理

#9.1 人审门控矩阵

复用 Routine approval_mode 三档语义：

#9.2 自动回滚条件

硬编码于 evolution/decision.py（对齐 engine/routine/decision.py 范式）：

• Canary 窗口内：错误率超基线 X% / 成本超基线 Y% / 延迟超基线 Z% → 立即回滚；
• 用户负反馈率超阈 → 立即回滚；
• 评测 regression_count > 0（holdout 集任一 case 回归） → 立即回滚；
• 记忆/知识配置 canary 窗口内：zero_hit_rate 或冲突率超基线 → 立即回滚；
• 回滚后：提案标记 rolled_back + 生成反思（失败经验入库，负样本喂回 proposer）。

#9.3 爆炸半径控制

• 金丝雀从小到大：单 Agent → 按 thread 哈希 N% → 全量；
• is_global 技能与 root Agent prompt 的 canary 比例上限更低；
• 全系统同一时间窗在途 canary 数量上限。

#9.4 防 Goodhart 四件套

1. 冻结 holdout 集（is_frozen = true）：结果不回流 proposer；
2. 多目标判据：质量 AND 成本 AND 延迟 AND 在线确认——单指标最优不可晋升；
3. Judge 与 Proposer 模型异源（task_model_settings 治理）；
4. 评测集换血：随失败采收持续更新，防固定 benchmark 过拟合。

#9.5 预算控制

• 进化子系统全局 max_cost_usd 日/月预算 + per-proposal 预算（shadow eval + canary 额外成本计入）；
• 范式直接对齐 routines.max_cost_usd 硬上限 + pre_dispatch_check 熔断。

#9.6 安全不变量清单

#10. 演进路线

实现进度注记（2026-07）：Phase 3 记忆检索权重面第一切片已落地——engine/evolution/ 子系统骨架（decision 纯函数护栏 / canary 路由 / weights 配置解析 / GEPA proposer / Phase 1 遥测地基也已落地——tool_invocations 事实表 + tool_stats_daily 聚合表 （迁移 0082）+ ADK before/after_tool_callback 采集器（fire-and-forget，灰度 tool_telemetry_enabled）

• tool_stats_aggregate 每日聚合 job。这是后续 agent/skill/knowledge 面 GEPA 的共同证据源。 eval_runner 窗口指标对比 / orchestrator 状态机）+ evolution_proposals + memory_config_versions 两表（迁移 0081）+ memory_retrieval_logs 加 config_version 分桶列 + search_memory canary 路由 + evolution_inspector 心跳。默认全关灰度 （settings.evolution.enabled/auto_mode）。明确留后续：agent/skill/knowledge 面 proposer、Phase 1 tool_invocations 三源遥测、eval 四表子系统、归因 job、记忆管线 prompt 进化。本切片基建（proposer _ProposerBase / decision / orchestrator）对后续面 无重造，仅各面补 proposer 子类 + eval_runner + config_versions 表。

加固注记（2026-07，第二迭代）：对照综述 §9.4（防 Goodhart）/§9.3（运行时控制）/§10.4 （自生成经验稳定性）批判性复核后补强：① canary 分桶键解耦（routine 按 routine.id、ADK 按 thread_id，修复自治 routine 共用 "system" 同桶致灰度沦为 0%/100%）；② stale canary REAP （max_canary_seconds 超时强制 rollback，防样本不足无限挂起）；③ anti-collapse 多样性护栏 （decide_canary 加 distinct memory_id 覆盖率非退化判定）；④ no-op/防振荡硬护栏（proposer prompt 软约束的确定性兜底）；⑤ 成本预算（max_proposals_per_day/max_cost_usd_daily）； ⑥ SSE 审计事件（复用 routine bus，promote/rollback/shadow→canary 翻转可观测）。

延后项（YAGNI/前置条件未满）：

• target_kind 注册表分派（P3）：当前 _advance_shadow/_advance_canary/_promote/_rollback 仍硬编码 retrieval 面，第二面（agent/skill）接入时再抽 TargetHandler 基类一次到位（避免 单实现期过度抽象，且本加固仍在稳定这 5 方法签名）；
• frozen holdout（P4，综述 §9.4 头号 Goodhart 防护）：需检索流量大到可同时支撑「可见训练桶
  • 冻结评估桶」双份样本（当前 min_samples=50/桶，holdout 需 100+/窗口）；evolution 默认关闭、 流量不足，强上会致两桶都凑不够 → canary 永久 hold。anti-collapse diversity 护栏已部分覆盖 （防 collapse）；等灰度跑稳、QPS 上升后单独切片。

第三迭代注记（2026-07，Skill 进化闭环 + TargetHandler 抽象 + eval 基座，PR #1038）： 上方「延后项」中的 target_kind 注册表分派（P3） 与 frozen holdout（P4） 已落地—— ① eval 四表（迁移 0083）+ SuiteRunner + CounterfactualAttributor（反事实 Skill Influence Pattern）+ visible_results_query（结构性排除 partition='holdout'，综述 §9.4 防 Goodhart）； ② TargetHandler ABC + RetrievalConfigHandler（retrieval 路径 golden 测试守护逐字节等价）+ orchestrator 退化为薄分派层（第二面接入时一次到位，见 ADR-5）；③ SkillTemplateHandler + SkillProposer（GEPA 变异 prompt_template）+ skills.active_version 发布指针（迁移 0084）， shadow 用 visible 集 decide_skill_shadow 增益门、canary 用 holdout 集 decide_skill_canary 零回归门。综述 §8 SI 六目标中 held-out gain / backward retention / path attribution 已落地； longitudinal stability / improvement efficiency / safety non-regression 仍列后续。详见 141 号调研。

#Phase 1：遥测 + 评测地基

范围：tool_invocations 三源采集（ADK callback 新挂点 / Routine 旁路 / MCP 旁路）+ interaction_feedback + tool_stats_daily 聚合 + eval 四表 + DB 驱动 eval runner + 首批 golden suite（每个 Faculty Agent ≥20 例）+ memory_stats_daily 聚合 + LoCoMo-mini / LongMemEval-mini / KG quality 注册为 eval_suites 行。

验收：

• 任一 Agent/Skill/Tool 可查 7 日健康度；
• 记忆/知识健康度可查（zero_hit_rate / referenced_rate / 冲突率 7 日趋势）；
• 可对任一 Agent 当前 prompt 手动发起评测并得到与基线可比的分数报告；
• 遥测写入对主链路 p95 延迟影响 <5ms（异步旁路）。

不做：自动化进化、agent_versions、Sync 改造。

#Phase 2：Agent prompt 进化

范围：agent_versions + agents.active_version + 解析顺序改造 + Sync 改造 + GEPA proposer + 提案状态机 + 影子评测 + 金丝雀路由 + 一键回滚。

验收：

• 一个非 root Faculty 走完 propose→shadow→canary→promote 全闭环；
• Sync 后进化版本不丢失；
• holdout 集分数同步不退化。

不做：Root Agent 进化、技能/工具进化、自造技能。

#Phase 3：技能/工具进化

范围：Skills active_version + per-skill suite + builtin_tool_versions + competition 证据回流 + 归因 job + 记忆/知识白名单参数 DB 化迁移（memory_config_versions 表）+ 检索参数 / rerank / chunking 数值级进化。

验收：

• 至少一个技能和一个 builtin tool 经数据驱动完成参数/模板改进并晋升；
• 至少一项记忆/知识检索参数经数据驱动完成改进并晋升（auto 档全闭环）；
• 工具退役提案流程跑通一例。

不做：MCP YAML 全量 DB 化、自造新技能、记忆管线 prompt 进化。

#Phase 4：自造技能 + 团队结构进化

范围：Voyager 式新技能流水线（Routine 起草 → 沙箱 → 人审 → 试用期）+ skills 挂载 / 模型选型纳入进化范围 + 记忆管线 prompt（extractor / reflection / KG 抽取）进化 + 遗忘 λ 进化试点（every 档）。

验收：

• Agent 针对一类重复失败任务自造技能并经人审入库，试用期指标达标转正；
• 至少一个记忆管线 prompt 经 GEPA 式提案完成改进（影子抽取对比 + 人审晋升）；
• 全程审计链完整可回放。

#11. 复用/新增对照总表

新增模块收敛为：models/evolution.py、models/evaluation.py、engine/evolution/（orchestrator / decision / proposer / eval_runner / canary / telemetry / attribution）、interface API + UI、3–4 个 Alembic 迁移。

#12. 关键权衡决策（ADR）

#ADR-1：进化编排——复用 Routine 还是独立子系统？

推荐：独立轻量状态机 + Routine 作可选重型执行器。

Routine 的 decide() 语义是「迭代直至验收」（no_progress/oscillation 守卫），而进化是「发布流水线」（shadow→canary→promote 的门控推进），状态机不同构。Routine 执行器是 Claude Code 子进程（重，文件系统绑定），prompt 变异只需一次轻量 LLM 调用。但 Routine 的预算守卫/审批/审计/心跳调度全部值得复用。结论：进化用独立的 evolution_proposals 状态机，重型工作降级派发为 Routine。

#ADR-2：版本快照——统一泛型表 vs 每资产专表？

推荐：登记簿泛型 + 快照专表混合。

泛型表（target_kind + target_id）便于 meta-layer 统一处理，但丢失 FK 完整性且与已上线的 skill_versions 冲突。结论：evolution_proposals / eval_runs 用泛型 target 引用（流水线统一），版本快照沿用专表范式（skill_versions 已有，新增 agent_versions / builtin_tool_versions 同构复制）。

#ADR-3：system_prompt 的事实源之争

推荐：基线/进化双轨 + active_version 指针。

sync_negentropy_agents 无条件覆写 agents.system_prompt，与进化写入正面冲突。方案：Sync 只写基线列 + 落 origin=code_sync 版本行，运行时解析顺序 promoted 版本 > 基线 > 代码 fallback。代价是基线更新后进化版本需标 stale 强制重评（显式拒绝自动三方合并），用少量人工换确定性。

#ADR-4：记忆条目级演化与系统配置级进化分轨

推荐：条目级走既有 consolidation 高频回路，配置级走 evolution_proposals 低频门控流水线。

条目级操作（fact 写入/更新、反思生成、ACE delta、记忆淘汰）每天成百上千次，与配置级变更（参数/prompt/策略，每周个位数）频率相差约 3 个数量级，强行统一进一个状态机会使门控失去意义或成为吞吐瓶颈。风险面也不同：条目级已有 retention 衰减 / reflection 去重 / conflict 检测三重既有治理，单条劣化影响局部；配置级变更影响全局检索与写入质量，必须享受 shadow eval + canary + 人审全套保护。代价：条目级演化缺少 shadow eval 前置保护，靠 outcome_feedback 事后信号与治理回路兜底——这是用吞吐换保护粒度的明确取舍。

#ADR-5：TargetHandler 抽象——按 target_kind 分派进化面

推荐：orchestrator 退化为薄分派层，每 target_kind 一个 TargetHandler 子类（advance_shadow / advance_canary / rollback / maybe_spawn）。

§10「延后项」曾裁定「第二面接入时再抽 TargetHandler 基类一次到位（避免单实现期过度抽象）」。第二面（skill_template）已随 PR #1038 到达，故本抽象落地：RetrievalConfigHandler 把原 orchestrator 的 retrieval 硬编码逻辑原样迁入（test_evolution_orchestrator_state_machine golden 守护 retrieval 路径逐字节等价），SkillTemplateHandler 接 PR1 的 SuiteRunner + decide_skill_* 双相门 + CounterfactualAttributor。代价：共享辅助（_enter_canary/_emit_evolution_event/_bump_patch 等）抽到 handlers/_shared.py，handler 读各自模块的 settings 绑定（非 orchestrator.settings），单测须相应 patch 三处 binding；retrieval byte-equivalence 靠 golden 集成测试守护。新增第三面（agent_prompt / builtin_tool / knowledge_strategy）只需一个 handler 子类 + 注册，零改动 orchestrator。

[1] J. Fang et al., "A comprehensive survey of self-evolving AI agents," arXiv:2508.07407, 2025. [2] A. Novikov et al., "AlphaEvolve: A coding agent for scientific and algorithmic discovery," arXiv:2506.13131, 2025. [3] L. A. Agrawal et al., "GEPA: Reflective prompt evolution can outperform reinforcement learning," in Proc. ICLR (Oral), 2026. arXiv:2507.19457. [4] Q. Zhang et al., "Agentic context engineering: Evolving contexts for self-improving language models," in Proc. ICLR, 2026. arXiv:2510.04618. [5] J. Zhang et al., "Darwin Gödel machine: Open-ended evolution of self-improving agents," arXiv:2505.22954, 2025. [6] R. Fang et al., "Memp: Exploring agent procedural memory," arXiv:2508.06433, 2025. [7] W. Zhong et al., "MemoryBank: Enhancing large language models with long-term memory," in Proc. AAAI, 2024. arXiv:2305.10250. [8] B. Jiménez Gutiérrez et al., "From RAG to memory: Non-parametric continual learning for large language models," in Proc. ICML, 2025. arXiv:2502.14802. [9] Z. Tan et al., "In prospect and retrospect: Reflective memory management for long-term personalized dialogue agents," in Proc. ACL, 2025. arXiv:2503.08026. [10] C. Lam et al., "Governing evolving memory in LLM agents: Risks, mechanisms, and the SSGM framework," arXiv:2603.11768, 2026. [11] S. Dong et al., "A practical memory injection attack against LLM agents," in Proc. NeurIPS, 2025. arXiv:2503.03704. [12] K. Lin et al., "Sleep-time compute: Beyond inference scaling at test-time," arXiv:2504.13171, 2025. 工业实现见 Letta Docs: https://docs.letta.com/guides/agents/architectures/sleeptime/ [13] S. Ouyang et al., "ReasoningBank: Scaling agent self-evolving with reasoning memory," arXiv:2509.25140, 2025.