背景与现状

ScienceDiscovery 已完成多数领域代码的物理分包，runtime-core 也基本保持领域中立；但能力进入一次 Agent Run 时，仍依赖中心代码手工接线。因此当前更接近“代码分包”，尚未达到“能力可插拔”。

已有基础包括：

• runtime-core 只依赖 Context、Model、Tool、Event 等通用端口；
• Tool Registry 已支持工具注册、可见性、并发执行和统一结果；
• Context Contributor Registry 已支持注册、Scope、冻结、故障隔离和 Trace；
• Plan、MCP、Artifact、Review 等业务实现大多已有所属 package。

当前问题

主要问题不在 Agent Loop，而在 Run 的能力装配层：新增或移除一种能力，通常仍要修改多个中心模块。

1. WorkspaceAgentOptions 承载 MCP、Artifact、Review、Memory、Subagent 等大量领域回调，已经成为事实上的能力总线。
2. NativeAgent 显式识别 Plan 等具体能力，负责拼接其工具和上下文；新能力仍可能侵入 Agent 主流程。
3. services/api/src/runs/index.ts 集中构造各种领域回调，能力的实现、接入和运行期状态处理尚未形成统一边界。
4. Tool 与 Context 各自可注册，但缺少统一的 capability owner、注册生命周期、注销和事件接口。
5. 当前每轮会组装 Prompt 和工具 Schema，但尚未形成正式、可观测的不可变 Step Contract。
6. Pending Mode 尚未实现，也缺少第二个真实的互斥 Run Driver 来校准通用冲突协议。

解决方案

方案核心是让 package 自主声明能力、组合层统一注册、Run 开始前冻结契约；runtime-core 继续只执行已经组装好的通用端口，不感知 Plan、Goal、PUCT 等领域名称。

1. 建立最小能力注册内核

在 orchestration/composition 层提供统一入口，而不是把插件装配控制流放入 runtime-core：

interface CapabilityPlugin {
  readonly id: string;
  register(context: CapabilityContext): Disposable;
}

V1 先提供当前已有真实需求的扩展点：

• tools：注册 Tool 及其 Schema；
• context：注册 Context Contributor；
• events：发布和监听类型化运行事件；
• state：读取只读、带版本的运行状态。

Guard、Projection、Run Driver 后续按真实能力接入需要扩展，不在第一阶段一次性预建完整体系。

2. 由所属 package 完成能力注册

每个 package 同时拥有其工具、上下文和事件定义；Service 只提供依赖并注册能力，不再逐字段转发到 WorkspaceAgentOptions。

优先迁移三类代表性能力：

1. Plan：验证 Tool、Context、Event 的组合注册；
2. MCP/Web：验证普通工具集合注册；
3. Artifact/Review：验证状态、Governance 和审计交互。

迁移完成后，NativeAgent 和 Runtime Core 不应出现具体 package 名称分支，createWorkspaceTools() 只保留真正属于 Workspace 的通用能力。

3. 固化 Step Contract

每次模型调用前生成不可变快照，覆盖本轮模型响应及同批 Tool Call：

interface StepContractSnapshot {
  readonly stepId: string;
  readonly modelInput: unknown;
  readonly tools: readonly ToolSpec[];
  readonly modelConfig: ModelConfig;
  readonly stateVersion: number;
}

会改变 Prompt、工具 Schema 或模型配置的状态，最早在下一 Step 生效；同批异步工具的完成顺序不得改变当前 Step 契约。

4. 最后实现 Pending Mode

Pending Mode 只服务于确实存在运行模式冲突的 package，不替代 Permission、Sandbox、资源锁等其他判断平面。

• package 提交带 owner 和影响面的 Transition Intent；
• Runtime 只保证 immediate / next_step / next_run 的最低安全边界；
• pending 可按 owner 查询、提交、取消和审计；
• 暂不可用的工具返回结构化、可恢复结果，不自动跨 Step 重放；
• 使用真实的第二个互斥能力或 Run Driver 完成接口校准后，再扩展通用冲突策略。

实施顺序

实施过程先解决能力注册和中心接线问题，再补 Step 安全边界，最后处理真实模式冲突。

1. 增加 CapabilityPlugin、owner、Disposable 和最小 CapabilityContext；
2. 迁移 Plan，并移除 NativeAgent 中的 Plan 特殊接线；
3. 迁移 MCP/Web、Artifact/Review，逐步拆除 Workspace 能力总线；
4. 收敛 runs/index.ts，使其只负责 Run 组合和生命周期；
5. 导出并记录 StepContractSnapshot，补充同批异步一致性测试；
6. 基于真实互斥案例实现 owner-scoped Pending Mode。

验收标准

完成后，能力应能通过“package 实现 + composition 注册”接入，Agent 主流程无需理解能力的领域含义。

• 新能力只修改自身 package 和应用组合清单；
• Runtime Core、NativeAgent 不出现具体能力名称分支；
• Tool、Context 和事件具有统一 owner 与生命周期；
• 同一 Step 的 Prompt、工具 Schema、模型配置和状态版本保持不可变；
• 移除某个 capability 注册后，主流程仍可正常编译和运行；
• Pending Transition 可按 owner 查询、提交、取消和审计；
• 覆盖 capability 重复注册、注销、故障隔离、Step 一致性和 pending 冲突测试。

非目标

本 Issue 聚焦 Agent 执行路径的能力解耦，不要求同时插件化所有 UI 和 HTTP 路由，也不在 V1 支持运行时热装卸、自动跨 Step 工具重放或完整模式配置 DSL。