本 issue 是项目技术纲要，随开发进展持续更新。所有实现细节见各阶段对应的 issue/PR。
总目标："灵魂插件"
只要把这个系统装到任意目标 repo 并给出初始配置，它就能对目标代码持续不断地进化、观察，直到达到进化目标。如果目标设置得足够长远、约束条件足够宽松，系统就能持续改良这个代码仓库。
一句话定性：一个可以被信任地放着自己跑的、有记忆的、会自动停的、每一步都可回滚的、面向单一目标仓库的 AI 代码进化 runtime。
内核设计原则
这些原则在所有 PR 中保持不变：
- 内核只路由智能，不嵌入智能（Unix 哲学）——kernel 本身不含 LLM，只负责调度角色
- 角色是外部命令——planner / executor / evaluator 通过 JSON 文件 I/O 与 kernel 通信，可插拔替换，LLM 的选择由角色决定而非 kernel
- 代码规模信念——~1000 行是心理锚点，好的机制内核应当简洁
- 执行层要规划 + 检测每轮效果 + 辅助收敛——每轮不是盲目尝试，而是有记忆、有方向的改进
- 复用现成 coding agent——executor 调用 Aider / Claude Code headless，不重造
闭环流程
config → observe → plan → execute → evaluate → accept/reject → ledger
↑_________________history___________________|
每一轮结果写入 ledger，下一轮 planner 读取 history，形成有记忆的持续进化。
阶段路线图
✅ 阶段 0 — 地基（PR #2 · PR #3）
- PR #2（hitome0123）：MVP 闭环 + 严格 scope check + 完整 ledger（含 scope violation 路径）→ 推荐合并，作为主线地基
- PR #3（AndrosEt）：MVP 闭环 + Observer + YAML config → 功能跑通，但 scope violation 路径审计不完整
里程碑：可以跑一次完整闭环，ledger 可审计，scope 严格控制。角色为 stub，无 LLM。
核心交付：接入真 LLM + 多轮进化循环 + History 注入 + Cost Guard
| 功能块 | 描述 | 规模 |
|---|
| 三角色接真 LLM | planner/executor/evaluator 调用真实 LLM 或 coding agent | ~170 行 |
run_until_done() | 多轮循环原语，触发 hard stops 才停 | ~30 行 |
| History 注入 | planner 每轮读前 N 轮记录，不再是布朗运动 | ~50 行 |
| Cost guard | max_total_usd / max_total_tokens 安全闸 | ~30 行 |
里程碑：第一个可演示版本。给一个 repo + 一个目标，放着不管，多轮后 repo 真实发生变化，全程可审计，预算可控。
PR4 完成后的能力边界：
- ✅ 多轮 LLM 反复尝试改进
- ✅ 每轮基于前几轮历史调整方向
- ✅ 失败不污染主分支（worktree 隔离）
- ✅ 每次成功 git commit 可单独回滚
- ✅ 自动撞预算/迭代上限停止
- ❌ 不知道何时算"成功"（跑到上限才停）
- ❌ 无整体方向感（单维渐进，不会多阶段战略）
- ❌ 无进程级 sandbox（LLM 可执行任意 shell）
🔧 阶段 2 — 知道何时算赢（PR5，待 issue）
核心交付：Goal Evaluator + Strategist
| 功能块 | 描述 |
|---|
| Goal Evaluator | 独立角色，判断 mission 整体是否达成，可自动停止进化 |
| Strategist | 每 N 轮触发一次，输出当前阶段/下一里程碑/禁忌方向，注入 planner |
run_until_done 升级 | 增加 goal_reached 作为终止条件 |
里程碑：进化过程有目标感，知道何时算赢，不再依赖人工设置 max_iterations。
🔧 阶段 3 — 逃出局部最优（PR6，待 issue）
核心交付：k-branch 并行探索（FunSearch / AlphaEvolve 模式）
| 功能块 | 描述 |
|---|
| k 个并行 worktree | 同一轮起 k 个分支，各自 plan → execute |
| Fitness 评分 | evaluator 返回浮点分数而非 accept/reject |
| 选择合并 | 选最优 branch 推进 accepted，其余淘汰 |
里程碑：不会因为一个错误方向走死，具备种群级别的探索能力。
🔧 阶段 4 — 生产级安全（PR7，待 issue）
核心交付：Process Sandbox + Remote Observer
| 功能块 | 描述 |
|---|
| Process sandbox | firejail / bwrap / 容器，限制 executor 的 shell 权限 |
| Remote observer | 读取 GitHub Actions 状态、外部 metric API 等 |
里程碑：可以放进真实生产 repo 无人值守跑，executor 无法破坏宿主环境。
发版节点建议
| 版本 | 对应阶段 | 特征 |
|---|
| v0.1 | PR2 合并后 | 机制可用，stub 角色，适合工程演示 |
| v0.2 | PR4 完成后 | 第一个真正可用版本，LLM 接入，多轮有记忆 |
| v0.3 | PR5 完成后 | 知道何时停，完整"灵魂插件"体验 |
| v1.0 | PR7 完成后 | 生产级安全，可信放入真实 repo |
讨论
欢迎在评论区提出对路线图的意见、对某阶段功能的设计建议、或对原则的质疑。
总目标："灵魂插件"
只要把这个系统装到任意目标 repo 并给出初始配置，它就能对目标代码持续不断地进化、观察，直到达到进化目标。如果目标设置得足够长远、约束条件足够宽松，系统就能持续改良这个代码仓库。
一句话定性：一个可以被信任地放着自己跑的、有记忆的、会自动停的、每一步都可回滚的、面向单一目标仓库的 AI 代码进化 runtime。
内核设计原则
这些原则在所有 PR 中保持不变：
闭环流程
每一轮结果写入 ledger，下一轮 planner 读取 history，形成有记忆的持续进化。
阶段路线图
✅ 阶段 0 — 地基（PR #2 · PR #3）
里程碑：可以跑一次完整闭环，ledger 可审计，scope 严格控制。角色为 stub，无 LLM。
🔧 阶段 1 — 第一个真正可用版本（Issue #4 · PR4）
核心交付：接入真 LLM + 多轮进化循环 + History 注入 + Cost Guard
run_until_done()max_total_usd/max_total_tokens安全闸里程碑：第一个可演示版本。给一个 repo + 一个目标，放着不管，多轮后 repo 真实发生变化，全程可审计，预算可控。
PR4 完成后的能力边界：
🔧 阶段 2 — 知道何时算赢（PR5，待 issue）
核心交付：Goal Evaluator + Strategist
run_until_done升级里程碑：进化过程有目标感，知道何时算赢，不再依赖人工设置 max_iterations。
🔧 阶段 3 — 逃出局部最优（PR6，待 issue）
核心交付：k-branch 并行探索（FunSearch / AlphaEvolve 模式）
里程碑：不会因为一个错误方向走死，具备种群级别的探索能力。
🔧 阶段 4 — 生产级安全（PR7，待 issue）
核心交付：Process Sandbox + Remote Observer
里程碑：可以放进真实生产 repo 无人值守跑，executor 无法破坏宿主环境。
发版节点建议
讨论
欢迎在评论区提出对路线图的意见、对某阶段功能的设计建议、或对原则的质疑。