生命周期执行、模型路由与并发

本页是线上发布摘要；完整目标和裁决以仓库 docs/architecture/MEMEX_PLATFORM_ARCHITECTURE.md 为准。

Service 把一个 Wiki 构建视为一个逻辑 life Job。Engine 的 /life 是 lifecycle 语义的可执行参考入口，但 slash command、Skill 路径和 Claude 会话循环不是生产机器协议。

当前兼容路径调用 /life <STEP_ID> --auto，Service 把它当作单 step attempt；但 Engine 的 auto 语义可以在同一 Agent session 完成当前 step 后继续 next，甚至跨 EGG、BRH、GRW family。因此现状仍可能出现起始 step 归因、实际执行范围、模型路由和预算边界不一致。目标架构不再让 Service 直接使用 /life --auto 作为生产入口。

逻辑拆分为：

/life = LifeProtocol + Interactive/Claude Loop Driver

Service lifecycle = LifeProtocol + Service Durable Loop Driver

Service 可以替换 /life 的会话循环，但必须继续遵守 Engine 的 next graph、enter_when、 exit_when、trigger、artifact、默认选择、用户 Gate、loop checkpoint 和正式 transition 语义。 Service 不得直接修改 lifecycle state、grow_state.json 或伪造 done/skipped。

目标执行协议

Service 通过版本化 Engine Adapter 使用与入口无关的协议：

attach 固定 Engine/Adapter 版本
  -> Engine Adapter 返回当前 ExecutionUnit
  -> EGG* / BRH* / GRW* 选择能力路由
  -> 获取 profile、quota 和 attempt budget
  -> LifecycleStepCapability 执行一个 durable unit
  -> Engine 返回结构化 transition
  -> Harness 验证 artifact 与 QC
  -> 持久化模型、用量、耗时和 checkpoint
  -> Service Durable Loop Driver 发起 next

普通 step 的一个 execution unit 最多完成该 step；loop step 最多完成一个可验证 iteration/checkpoint。Agent session、模型路由、预算和 durable execution unit 必须使用同一边界。

Engine release 通过 capability manifest 声明 protocol、revision 和 Adapter。Build 创建时固定 engine_revision + protocol_version + adapter_version；checkpoint 额外固定 unit_id 和 definition_revision。未知或不兼容协议在启动 Agent 前进入 Paused(engine_incompatible)，不能静默切换入口或把旧 checkpoint 当成新 run。

Run、上下文与预算边界

每次 Agent 调用绑定不可变 Execution Envelope，至少包含 run_id、attempt_id、unit_id、 expected checkpoint、模型路由、最大成本、token、deadline 和 checkpoint grace。Job 总预算跨 Worker、requeue 和 deployment handoff 持久累计，不再在单个 runner 内从零开始。

新 session 的边界是 durable checkpoint：step 完成后，后续执行只依赖磁盘上的 Wiki 产物和 lifecycle 状态，不依赖上一会话的隐式上下文。每个 run 结束后 Service 还会记录：

step 的 done、skipped 或 loop_active 状态
实际 profile、model、能力路由和 quota scope
token、turn、耗时、错误摘要与事件日志
当前产物位置和下一 step

Agent Runtime 持续上报 input、output、cache read、cache creation 和成本。到达软预算时， Capability 在最近 durable checkpoint 退出并由 Service 决定 requeue 或 Paused(budget_exhausted)；只有超过 grace 或发生不可恢复错误时才回收完整进程树。没有 Engine checkpoint 的退出不会被标记为完成，宿主也不能为了满足预算直接推进 cursor。

这种切分同时满足长任务连续性与上下文质量：整本 Wiki 可以运行数小时，但单个 session 不会跨过 execution unit 和模型能力边界。fresh session 必须使用 scoped context，只加载当前 step、必要状态和相关产物，避免切分后重复加载无关上下文抵消 cache 成本收益。

OpenCode 的 overflow 判定和 compaction 实现，以及 Codex 的 compact 实现都以 active context tokens 和模型窗口作为压缩信号，而不是用固定 turn 数结束长任务。

模型路由

Step 家族	路由配置	典型能力
`EGG*`	Egg	分析与蓝图
`BRH*`	Boot	结构与基础产物
`GRW*`	Grow	批量内容建设与质量推进
未知家族	Life	保守兜底

每个 execution unit 开始时重新选择 profile/model，不允许一个会话跨路由边界。池策略有两种：

balance：仅用于能力等价、模型覆盖一致的成员，按 least-inflight 分摊
failover：按配置顺序选择第一个健康且有容量的成员，适合不同成本或能力的主备模型

Service 负责 Job 级准入、step 级路由和跨 profile 故障切换；LiteLLM 等网关负责请求级账号均衡、限流和重试。共享上游额度通过 quota_scope 聚合，避免不同 profile 绕过配额。

并发计算

调度容量只有一条主链：

非峰时硬上限 -> 峰时比例 -> 当前有效全局上限 -> 工作守恒派发

Life 不再叠加隐藏的阶段并发上限。普通构建可以使用全部空闲槽位；交互任务通过更高优先级取得下一个释放的槽位，但不会让系统为了未来可能出现的请求永久空置容量。Egg/Boot/Grow lane cap 只兼容旧流程队列，模型侧容量由当前 step 路由的 max_inflight 和 quota_scope 控制。

快速 scheduler_loop 只负责准入和派发；孤儿恢复、超时、完成性与配置漂移由低频 reconciler_loop 处理，避免全 Wiki 扫描拖慢新任务启动。

大队列下，scheduler 先按优先级、公平性、语言和体量选候选，再只为填充当前空闲槽位惰性解析 Life Job 的下一 step 路由。单个 tick 的路由检查有明确上限；已解析的 queue entry 在当前进程缓存 route，但 profile 池和 quota 可用性仍在每个 tick 重新检查。路由停用或满额时 Job 保持 waiting，同一轮继续尝试其他 route，避免逐 Job 查询整个队列造成 N+1、阻塞 /start，也避免某个不可用模型池让其他可运行任务空耗全局容量。

目标执行协议​

Run、上下文与预算边界​

模型路由​

并发计算​

目标执行协议

Run、上下文与预算边界

模型路由

并发计算