目标：定义通往 1.0 的分阶段功能开发清单、交付顺序与验收，并保留后续方向。
本次规划的核心产出是下文「1.0 分阶段开发功能表」；日常执行状态使用 TODO。
路线图以上位 产品愿景 为依据：NextClaw 以做好用户的长期搭档为根本使命，主动参与、持续自我改进，关注用户的整体上下文。个人操作层、统一入口与平台 SDK 是支撑形态或能力方向。
已确定的是使命及 1.0 的三项核心目标：懂用户、主动帮忙、持续自我改进。本次交付 1.0 产品定义、现状/差距清单 与本路线图。2026-09-10 用户认可四阶段功能规划：D01–D16 为开发范围，D17 为发布验收工作；认可规划不代表已执行开发或已完成验收。现状验证用于缩减每项的实际改动，不将整张开发清单推迟到验证之后。首发支持范围和试用参数见产品定义第 7 节，发布日期未承诺。
产品定义负责用户结果与验收，差距清单负责有版本依据的代码事实，本文件负责排序与阶段退出条件。具体任务执行、自身管理和 SDK 建设不能单独代替长期伙伴关系的验收。
下文 SDK 路线保留为伴随式技术方向；既有季度草案保留为待复盘材料，不代表新的 1.0 承诺。新增事项需说明它如何服务搭档使命，再决定进入哪个阶段。
- 通往 1.0 的 Roadmap 必须包含分阶段功能开发表，写清具体改动、复用基础、开发原因、依赖和完成标准；文件级编码步骤归对应执行计划。
- 每个里程碑必须能映射到 GitHub Milestone 或 Issue 集合。
- 每月至少复盘一次：保留、延后、下线三选一。
- 超过 2 个周期未推进的事项必须写明阻塞原因。
- 非目标（Not Doing）必须显式记录，避免反复讨论。
配套参考：
状态：规划范围已认可，尚未实施和验收。面向用户的中英文版本见 中文文档站路线图 与 英文文档站路线图。
F1–F9 是产品能力，D01–D16 是为交付这些能力而拆出的开发工作包；两者不可互相替代。下面每行都能作为一个独立功能任务的范围输入，包含正常使用、状态更新与完成标准。具体接口和存储方案在该项实施前设计，不预设每行都需要一个新页面、新模块或新数据库。
复用与改动的判断依据见 现状清单 E1–E6。D01 的身份与模板不一致已有源码证据；其余各项是在现有基础上明确要交付的产品行为，尚未完成运行差异确认，不能宣称整个功能缺失。若某项用已有配置、技能和入口即可达到下表标准，该项以集成和验收交付，取消重复编码，但不取消用户结果。
| 阶段 | 开发包 | 用户拿到的阶段成果 | 为什么按这个顺序 |
|---|---|---|---|
| M1 理解用户与目标 | D01–D05 | 自动整理用户背景，管理目标计划；换会话仍能按最新理解提供帮助 | 主动参与必须先知道为谁、围绕什么目标、依据什么状态 |
| M2 主动分析与交流 | D06–D10 | 自动识别值得关注的事，后台分析与规划，主动找用户聊、告知或执行 | 在可信背景上建立持续参与，优先完成 1.0 最关键的体验变化 |
| M3 持续自我改进 | D11–D14 | 从实际结果和反馈中改进，后续可见效果，用户可查看与撤销 | 先有真实协作与结果，才有需要改进的行为和评价依据 |
| M4 可长期使用与发布 | D15–D17 | 新用户能启用，运行中断与升级后仍可靠，并有连续试用证据 | 发布前验证前三阶段在同一产品中持续成立 |
| ID / 功能点 | 具体开发内容与交付 | 复用基础 / 改动性质 | 为什么做 | 依赖与完成标准 |
|---|---|---|---|---|
| D01 搭档运行身份与持续参与设置 | 对齐运行身份、初始化模板与内置行为指引；提供持续参与的启用/关闭、范围和权限设置，区分分析沟通与执行授权；让运行读取设置。已有用户迁移保留自定义资料 | E1 身份、bootstrap、初始化链路；改造默认行为并接入参与设置 | 让产品在运行中履行搭档职责，且用户清楚交给了它什么 | 无前置；新老用户的前台/后台读取同一有效设置，关闭后不再自主参与，不覆盖用户定制；对应 G1/G6、A6/A8 |
| D02 对话中的用户信息自动整理 | 从正常交流中提取背景、偏好、当前状态和变化，保留来源与更新时间，区分用户确认和模型推断；冲突信息进入待确认，不静默覆盖 | E1/E2 USER、记忆、文件工具；增强整理与更新行为 | 用户不用在每次会话重新介绍自己，也不用手工维护全部档案 | D01；正常交流后持久保存有效信息，新会话可用，推断不当成确认事实；F1、A1 |
| D03 用户理解的查看、纠正与时效管理 | 提供理解条目查看/编辑/停止使用入口，支持对话纠正；记录临时状态的有效期；让修正、过期、停止使用同步影响后续召回 | E2 记忆读写；补管理体验与状态语义，复用现有设置/对话表面 | 用户能纠正误解，短期状态不会长期支配判断 | D02；纠正后新会话使用新值；到期重确认或标为过期；停止使用后不再引用；F1/F3、A1/A3 |
| D04 个人目标与分阶段计划管理 | 支持跨项目及非项目目标，维护长期目标、阶段计划、近期行动的关系；查看、调优先级、更新进展、暂停/结束；关联已有项目工作，调整目标时给出受影响安排 | E3/E6 项目工作、活动、产物和文件；补用户层目标关系与管理入口 | 搭档知道什么值得持续推进，能把眼前事情放回整体安排 | D02；一个非项目目标与两个持续事项可共同规划；模糊想法不自动成为承诺，计划调整影响后续关注；F2、A2/A3 |
| D05 前台与后台的相关上下文接入 | 将有效用户理解、目标、当前状态和历史决定接入新会话与后台运行；按相关性和授权范围选择资料，保留依据入口；处理旧值和不应混用的项目资料 | E2/E6 现有检索、会话历史和 context provider；补装配与选择行为，不重建检索引擎 | 存下的信息必须真正影响判断，后台不能只拿到一条定时任务文本 | D03/D04；K1 完整通过，后台运行也能使用最新背景；F3、A2/A3 |
阶段退出： 用户可以通过正常交流建立理解和目标，跨会话调用、纠正与时效都成立；K1 通过。D01 不能仅以改好提示词结束，必须证明运行与设置一致。
| ID / 功能点 | 具体开发内容与交付 | 复用基础 / 改动性质 | 为什么做 | 依赖与完成标准 |
|---|---|---|---|---|
| D06 自主关注识别与关注清单 | 从目标、近况和未决问题识别值得持续关注的事；在授权内建立关注或提出确认，展示原因、关联目标、最近结果和后续安排；可暂停/恢复/结束，目标变化同步调整 | E3/E4/E6 项目工作、cron、observation；补用户层关注关系与统一查看，不复制调度状态 | 用户不必逐条告诉搭档“请记得关注”，讨论中的问题也能持续保留 | D04/D05；不手写 cron 即可建立关注；非任务话题可留存；暂停目标后不继续催促；F4、A3/A4 |
| D07 后台主动分析与规划 | 在已有调度入口加入对用户整体上下文的定期审视；联系分散信息、识别冲突/机会、比较方案、形成计划建议与具体讨论问题；记录结论、依据、未决事项和已处理内容 | E4 定时/事件唤醒及 Agent 运行；新增或补强分析工作流，复用现有调度器 | 没有用户新指令或外部变化，也能自主想出值得帮助用户的事 | D05/D06，向用户投递前接入 D08；K2-A 中自主发现时间与计划冲突，提出有依据的选择；不以是否调用工具验收；F5、A4/A5 |
| D08 主动参与的价值判断与节奏控制 | 在发送或执行前综合相关性、紧迫度、是否已讨论、当前状态和预算，选择静默/延后/告知/讨论/行动；提供安静时段、参与频率、预算及总暂停控制，预算到限有状态反馈 | E4 已有筛选、去重、预算、启停；补用户层决策并统一消费现有控制 | 主动性要产生价值，并适应用户节奏，避免重复观点和无效打扰 | D01/D05，随 D07 首次可用一起交付；新认识可发起交流，无新价值保持安静，已讨论内容不重复，总暂停和预算立即约束后续启动；F5/F6、A5/A6 |
| D09 主动话题与回复接续 | 在会话/收件箱呈现有来由的分析、建议、告知或讨论邀请；关联来源、关注事项和会话上下文；支持接着聊、稍后再聊、本次忽略、以后不主动提，持久记录不同选择；允许保留未决问题 | E6 收件箱交付、引用继续会话和消息路径；补话题关系、回应语义与交互 | 搭档能主动找用户聊，用户能直接接上，而非收到一份孤立报告 | D06–D08；K2-A 接续讨论通过，K2-B 告知可独立完成；本次拒绝不变成永久偏好，也不强制创建任务；F6、A4–A6 |
| D10 建议转执行与结果回写 | 用户采纳或既有授权允许时，将建议关联到已有工作项/工具执行；交付实际产物，回写进展或失败，并更新相关计划/关注；执行前重查有效授权，支持停止 | E3/E4/E6 工具、工作项、会话跟进、产物交付；补关联与完成语义 | 真正承诺做事时有结果；结果反过来影响下一次判断 | D04/D09；K2-B 执行分支有可检查产物，失败不报成功，撤权后不启动新动作；纯告知/讨论不进入本分支；F6、A6/A8 |
阶段退出： K2-A 与 K2-B 都通过。能在无外部变化时主动分析规划并找用户交流，也能按变化告知、按需执行；已说清、被拒绝或不值得打扰时能够停止。
| ID / 功能点 | 具体开发内容与交付 | 复用基础 / 改动性质 | 为什么做 | 依赖与完成标准 |
|---|---|---|---|---|
| D11 结果与反馈驱动的自动复盘 | 将执行失败、结果偏差和用户纠偏接入现有学习入口，补充触发条件、适用范围和预算；明确启用状态，防止复盘递归；无可复用经验时允许不改 | E5 learning loop、运行后事件与复盘子会话；改造触发和产出约定 | 无需用户反复要求“记住教训”，也不局限于工具调用次数达到阈值 | D01，采集 D09/D10 结果；一次真实错误可自主触发有效复盘，单次拒绝不误记为永久规则；F7、A7 |
| D12 经验分类与后续应用 | 将事实修正、参与偏好、工作方法分别回写用户理解、参与策略或已有技能；保留来源和适用条件，后续相关运行选用；避免每次复盘都新建技能 | E2/E5 记忆、技能写入与 SkillsLoader；补分类、应用及失效语义 | 学到的经验必须改变后续服务行为，不能只多出几个文件 | D03/D08/D11，持久改动同时接入 D13/D14；下一次相似情境实际使用合适经验；不相关情境不套用；F8、A7 |
| D13 改进记录与效果查看 | 记录改了什么、为什么、适用范围、关联反馈、后续应用和可观察结果；提供查看入口，区分待应用、已应用待验证、有效、需修正 | E5 复盘会话/请求记录和工具记录；补持久改动关联及效果展示 | 用户和产品团队能判断是否变好，避免把复盘已启动当成改进成功 | D11/D12 同批接入；一条记录能追到改动、后续应用和结果，没有后续证据明确显示未验证；F9、A7 |
| D14 经验纠正、禁用与安全撤销 | 支持纠正经验、禁用策略、撤销对应持久变更；保存必要变更前后信息并检查后续修改，存在冲突时不覆盖用户新内容；撤销同步影响后续应用 | E5 现有文件/技能与工具记录；补变更和撤销合同，复用存储而非整目录回滚 | 错误经验不能永久影响搭档，用户始终能调整学习结果 | 与 D12/D13 一起交付；撤销后相关策略不再生效，用户之后的修改保留；F9、A7 |
阶段退出： K3 通过：从一次真实问题，到持久改进，再到另一次相关情境的实际效果，有完整证据且可撤销。D12–D14 作为同批闭环验收，不先交付不可查看、不可撤销的自动改动。
| ID / 功能点 | 具体开发内容与交付 | 复用基础 / 改动性质 | 为什么做 | 依赖与完成标准 |
|---|---|---|---|---|
| D15 搭档启用引导与能力状态 | 在首次使用引导中帮助用户提供必要背景、确认首个目标与参与范围，沿用 D01 设置，明确学习启用状态；展示当前入口支持什么、后台是否运行、为何暂停及可采取的操作；同步用户文档 | 现有设置、入口、运行状态，E5/E6；补完整上手流程与说明，不增加重复设置 | 用户不需要读内部配置文件或知道 cron/learning loop 才能开始使用 | D01–D14 可用后完成整体验收；建议 Native 首发路径能从空资料到第一次有效帮助，受限入口不暗示完整支持；G6 |
| D16 中断恢复、升级与持续状态一致性 | 补强用户资料、目标、关注、待讨论事项、执行状态和改进记录的恢复链路；失败/离线可见，恢复不重复发送或执行；升级保留用户定制与有效设置 | E1–E6 已有持久化、调度恢复与迁移基础；按故障用例修复实际缺口 | “长期搭档”必须能跨越程序重启、连接失败和版本升级 | 数据持久化与停止能力随 M1–M3 各项交付，本项做跨链路补强；K4 通过，不能只凭存储代码存在宣称可靠；A6/A8 |
| D17 整体验收与连续试用（验证工作） | 固定候选版本执行 K1–K4 与 A1–A8，记录两组用例证据；进行建议的 3 人、14 天真实试用，问题回到对应 D 项修复，形成发布判断 | 复用现有测试/操作入口与 PRD 案例，不开发独立评测平台 | 证明三项核心目标在持续使用中共同成立 | D01–D16；按 PRD 第 5 节判定，失败或未验证不能标通过；试用参数仍为建议，不是已确认承诺 |
第一批从 D01 → D02/D03 → D04 → D05 开始，交付 K1 对应的完整使用路径；随后做 D06 → D07/D08 → D09 → D10，交付主动分析与交流。D11 可以随着真实反馈提前接入，但 D12–D14 必须一起完成持久改进闭环。D15 的设置与状态基础随各阶段建设，最终上手体验在 M4 验收；D16 的局部可靠性工作也不推迟到最后。
每个 D 项进入实施时，先用其完成标准核验对应现有路径，确定实际差异，然后完成该项设计、改动与验收；不先开展覆盖全部功能的大盘点来阻塞第一批建设。任务卡直接使用本表的功能名和交付范围，并补当前 actual/expected、实施 owner、改动位置与验证结果。现有能力已满足时，记录证据并关闭该项的编码工作。
建议首发完整验收以 Native runtime 为基准；人力、估时、命令名与接口设计尚未冻结，不能将上述依赖顺序解释成日期承诺。未创建远端 Issue/Milestone，未授权或执行产品开发。本表是可拆任务的功能范围，不冒充文件级编码方案。
运行与发布判定统一使用 产品定义第 5 节 K1–K4。当前四项均未执行，新增开发表不改变验收状态。M1 对应 F1–F3/G1–G3，M2 对应 F4–F6/G3/G4/G6，M3 对应 F7–F9/G5，M4 覆盖 G6 和所有剩余发布阻断项。
F1/F2/F4/F9 的管理行为应由 UI、Agent 工具与适用的对象级 CLI 复用同一产品 owner；命令与接口随各项方案确定，不另起一套状态。用户可见改动同步维护中英文用户说明；本次仅交付内部规划，不代表这些功能已经上线。
本轮不另建记忆引擎、调度器、任务系统或学习框架，不以完整日历应用、全渠道同时覆盖或新增工具数量作为 1.0 前置。通过组合即可完成的部分保留；必须新增的只是现有链路承接不了的产品行为和控制。
以持续试用暴露的需求为顺序依据，候选包括：扩大可理解的数据来源与可执行服务、提升主动判断和改进质量、扩大 runtime/渠道/设备覆盖、产品化外部开发者能力。具体日期与先后不在本次规划中承诺。
“平台 SDK 化”是服务产品主线的长期技术副线，不是另起一套与 NextClaw 平行的平台工程。
目标是让 NextClaw / NCP 的核心能力逐步形成稳定、可组合、可版本化的开发者能力面，使外部开发者最终能够基于同一套基础设施构建自己的 Agent 产品或平台；与此同时，NextClaw 自身持续使用这些公共边界，从真实产品迭代中校验 SDK，而不是维护一套只供演示的平行实现。
这里的“Platform SDK”是一个统一开发者能力面，不预设必须收敛为单个大包：
NCP contracts / runtimes
-> 可嵌入的 kernel 能力
-> client / transport SDK
-> extension / app SDK
-> 文档、示例、测试工具与版本合同
现有基础：
@nextclaw/ncp、NCP runtime 与 toolkit 已承担协议和运行时积木。@nextclaw/kernel已是公开包，但当前大量导出仍需逐步区分“稳定嵌入接口”和“可变内部实现”。@nextclaw/client-sdk已承担上层应用访问 NextClaw 的统一 client contract。@nextclaw/extension-sdk已承担外部 extension server 接入能力。
现阶段真正缺少的不是再新建一个 SDK 名称，而是建立统一的分层、稳定性等级、开发者路径和端到端验收。
一个独立于本仓库的最小示例项目，只依赖公开发布的 NextClaw / NCP packages，不导入源码内部路径，即可完成：
- 装配一个 headless Agent runtime。
- 注册或接入 provider、runtime、tool / skill 等可扩展能力。
- 创建并管理 agent、session 和一次完整 run。
- 消费流式事件，执行取消、恢复和错误处理。
- 持久化必要状态，并通过明确的生命周期释放资源。
- 在升级依赖时依据语义化版本、迁移说明和 contract tests 判断兼容性。
NextClaw 产品自身对同一组稳定能力完成 dogfooding，且不保留功能等价的内部专用主链路，才算真正完成 SDK 化。
| 阶段 | 结果 | 退出条件 | 优先级关系 |
|---|---|---|---|
| A. 能力地图与边界分级 | 盘点 NCP、kernel、client SDK、extension SDK 的公共能力、重复 contract、深层导入和内部泄漏，区分 stable / experimental / internal | 核心领域有唯一 owner；得到首批稳定嵌入能力清单和明确非目标 | 伴随相关主线改动完成，不进行全仓搬家 |
| B. 内部同路消费 | NextClaw 的 server、UI、desktop、companion 和 extensions 优先通过正式公共入口消费稳定能力 | 每个已 SDK 化领域只有一条标准主链路；平行类型、请求层和胶水实现持续减少 | 主线功能触达哪个领域，就先治理哪个领域 |
| C. Headless 嵌入闭环 | 提供面向外部 Agent 平台开发者的最小装配、生命周期、运行、事件和持久化边界，并提供与之同路的 nextclaw exec |
北极星示例可在独立仓库运行；脚本与 CI 可通过稳定的文本、JSON 或事件流合同执行任务；嵌入 API 不依赖 NextClaw UI、CLI 或内部 alias | 这是最关键的新增能力面，按真实外部用例逐步扩展 |
| D. 扩展与组合闭环 | provider、runtime、tool、skill、channel、app 等扩展点拥有一致的注册、能力声明、配置和诊断心智 | 至少一个非内置扩展只使用公开 SDK 完成开发、测试和运行 | 复用 NCP 与现有 extension/app 体系，不重建平行插件系统 |
| E. 开发者产品化 | 文档、starter、API reference、contract tests、版本策略、迁移指南和发布质量形成闭环 | 新开发者能够按文档完成最小平台；破坏性变化有检测、版本和迁移路径 | 在能力真实稳定后产品化，不提前冻结错误抽象 |
触达核心能力时只追加与当前改动同范围、能被真实消费的一小步：
- 先判定 owner：产品语义归 kernel，跨 runtime 协议归 NCP，远程访问归 client SDK，外部进程扩展归 extension SDK；不因调用方便复制 contract。
- 再判定稳定性：只有语义已稳定且存在复用者的能力才进入正式 public API；仍在探索的实现保持 internal 或 experimental。
- 优先内部 dogfooding：新增公共入口后，让当前 NextClaw 消费方走同一路径，再删除等价旧入口、深层导入和重复类型。
- 顺带偿还邻近债务：只清理被本次能力迁移直接淘汰的 wrapper、adapter、兼容层和历史链路，不借 SDK 化扩大无关重构范围。
- 补齐最小合同证据：公共类型、生命周期、错误语义、contract test 和必要文档随能力一起演进；用户可见且已发布的变化遵守 semver 与迁移合同。
并非每次改动都必须新增 SDK API。最好的伴随结果也可能是：确认能力不应公开、收紧内部边界、删除重复出口，或把公共 contract 放回正确 owner。
- 以 agent、session、run、event stream 和 runtime registration 为第一条纵向能力链，完成 public surface inventory。
- 从
@nextclaw/kernel当前根导出中区分稳定嵌入接口与内部实现，先定义稳定性等级，不直接进行破坏性删改。 - 建立一个仓库内但按“外部消费者”约束构建的 headless 示例，禁止源码深层导入和 workspace 私有 alias。
- 以轻量
@nextclaw/harness作为进程内嵌入的独立安装入口，核心实现继续归@nextclaw/kernel；外部示例和文档只依赖 facade，以独立 semver 和导出合同隔离 kernel 演进。 - 在 Harness 最小闭环上增加
nextclaw exec：支持非交互输入、文本 / JSON / NDJSON、取消与超时、headless 审批政策和稳定退出分类，CLI 只做适配，不复制执行语义。 - 后续相关产品功能优先补强这条纵向链，稳定后再扩展到 provider、tool / skill、automation、channel 和 app。
相关既有设计：
- NextClaw 后台职责边界设计
- NextClaw Platform SDK 公共能力面设计
- NextClaw Client SDK 方案设计
- NextClaw Extension SDK 方案设计
- NCP Phase 0 能力冻结
- NCP Session-Centric Agent Backend
| Theme | Outcome | Why Now | Milestone/Issue | Owner | Status |
|---|---|---|---|---|---|
| 产品稳定性 | 降低用户可见错误与中断率 | 提升留存和口碑 | #TBD | @owner | Proposed |
| 多端体验一致性 | CLI / Web / Desktop 关键流程一致 | 降低学习成本 | #TBD | @owner | Proposed |
| 插件生态可用性 | 安装、升级、发布路径更顺滑 | 提升生态增长效率 | #TBD | @owner | Proposed |
| Theme | Outcome | Entry Criteria | Milestone/Issue | Status |
|---|---|---|---|---|
| 企业化能力 | 可观测性与权限能力升级 | Q2 稳定性达标 | #TBD | Candidate |
| 自动化交付 | 发布验证自动化覆盖提升 | 核心链路指标稳定 | #TBD | Candidate |
| Item | Reason | Revisit Date |
|---|---|---|
| 所有 runtime、渠道与平台同时达到完整搭档能力 | 先验证 Native 主链路与首发支持矩阵，扩大覆盖以实际需求为依据 | M4 后复盘 |
| 企业化、完整外部开发者平台作为 1.0 前置 | 当前使命优先落实个人搭档；SDK 按真实复用伴随推进 | 1.0 后复盘 |
| 无边界接入全部个人数据或以自动改写产品代码代表自我改进 | 超出首版可验证范围；先完成有反馈、有结果的改进闭环 | 出现明确用例时 |
- 每周：从 Roadmap 拆解到 TODO
Next。 - 每月：复盘里程碑状态并更新优先级。
- 每季度：重排主题与资源分配，清理失效项。