From 4eab30b944a131c8f0c93e7722aea501e1cd4dd5 Mon Sep 17 00:00:00 2001 From: Chris <2293611667@qq.com> Date: Tue, 24 Mar 2026 00:08:34 +0800 Subject: [PATCH] docs: refresh readme roadmap - docs(readme): mark phase 1 complete and summarize the delivered repository workflow loop - docs(roadmap): split the next work into local harness and control-plane phases - docs(readme_zh): sync the chinese roadmap and future directions with the english update --- README.md | 36 ++++++++++++++++++++---------------- README_zh.md | 36 ++++++++++++++++++++---------------- 2 files changed, 40 insertions(+), 32 deletions(-) diff --git a/README.md b/README.md index 647df0f..7276fce 100644 --- a/README.md +++ b/README.md @@ -29,7 +29,7 @@ For coding work, a task enters through CLI and config setup, flows through the a ## Current Status -`Phase 0` is complete. The current baseline includes: +`Phase 0` and `Phase 1` are complete. The current baseline includes: - CLI and runtime configuration - Agent loop and tool-calling basics @@ -38,6 +38,8 @@ For coding work, a task enters through CLI and config setup, flows through the a - Test infrastructure and deterministic mdBook validation - Change-aware documentation automation for README and book chapters, including scope decisions, reference context, blocking verify, and review/rework evidence +`Phase 1` completes the in-repository coding workflow loop: structured git and patch tools, repository search, policy-gated mutations and approvals, bounded build/test, and `git_add` / `git_commit` for packaging changes. + ## Documentation Automation Documentation automation follows the same local-first, bounded pattern as the runtime. The writer stage only edits approved homepage and book targets, while generated JSON, diagram specs, and rendered diagram artifacts stay under `docs/generated/` as handoff and review evidence. @@ -96,19 +98,26 @@ Goal: complete a stronger coding workflow loop inside a repository. - [x] add patch validation and rejection flow before writeback - [x] support bounded build/test execution loops for CMake and `ctest` - [x] improve failure recovery and retry guidance from tool results -- [ ] add explicit commit packaging flow with `git_add` and `git_commit` +- [x] add explicit commit packaging flow with `git_add` and `git_commit` ### Phase 2 -Goal: decouple reusable workflows into Skills. +Goal: complete a local Agent Harness on top of the current CLI + tool loop (stateful core, extension, orchestration, robustness, and real-model validation—not a handful of unrelated features). + +- [ ] Stateful Core: memory, planning / task decomposition, session and state persistence +- [ ] Extensibility Layer: rules, skills, MCP +- [ ] Orchestration Layer: subagent and team/multi-agent orchestration +- [ ] Robustness Layer: context compaction, budget control, safety/approval/execution boundary +- [ ] Real-Model Harness: OpenAI-compatible model validation; benchmark, regression, e2e, and load testing + +### Phase 3 -- [ ] define the skill directory convention and metadata/frontmatter shape -- [ ] implement a skill loader for workspace and shared skill locations -- [ ] inject selected skills into prompt/session assembly -- [ ] add built-in skills for C++ conventions, testing workflow, and git workflow -- [ ] expose skill enablement through CLI and config -- [ ] add skill execution traces and debugging output -- [ ] dogfood one real repository maintenance workflow through skills +Goal: Agent Boundary Expansion / Control Plane on the Phase 2 harness—external entry, control surface, trace UI, and daemon-style execution as adapters to one runtime (not a separate agent core per channel). + +- [ ] P3.1 Channel Adapter Layer: unify Telegram, WeChat, and other message entry behind a shared chat transport/adapter instead of per-platform agent logic +- [ ] P3.2 Human-in-the-Loop Control Plane: approvals, resume, pause, cancel, new session, session restore, task status, asynchronous notifications +- [ ] P3.3 UI / Trace Console: local or web UI for current plan, tool-call timeline, memory, subagent/team graph, compaction before/after, approval queue, diff preview, replay +- [ ] P3.4 Remote Execution / Agent Daemon: long-lived or remote process so channels and UI attach to the same runtime, not only a local shell ### Docs Agent Milestone @@ -126,9 +135,4 @@ This track follows a local validation first -> change-aware updates -> stronger ## Future Directions -Longer-term directions stay centered on the runtime itself: - -- MCP integration -- Telegram or other remote interfaces -- finer-grained sandbox and permission models -- stronger autonomous coding workflows +Concrete sequencing is in **Roadmap** above: **Phase 2** builds the full local Agent Harness; **Phase 3** adds the control plane and external boundaries around that harness. Broader explorations (for example finer-grained sandboxing beyond the current policy model) may still land inside those phases rather than as one-off spikes. diff --git a/README_zh.md b/README_zh.md index b18c6ae..c09c0d5 100644 --- a/README_zh.md +++ b/README_zh.md @@ -29,7 +29,7 @@ NanoCodeAgent 是一个教学型 C++ code agent 运行时，重点放在确定 ## Current Status -`Phase 0` 已完成，当前基线包括： +`Phase 0` 与 `Phase 1` 已完成，当前基线包括： - CLI 与运行时配置 - agent loop 与基础 tool-calling @@ -38,6 +38,8 @@ NanoCodeAgent 是一个教学型 C++ code agent 运行时，重点放在确定 - 测试基础设施与确定性的 mdBook 校验 - 面向 README 和书籍章节的 change-aware 文档自动化，包括 scope decision、reference context、blocking verify，以及 review/rework evidence +`Phase 1` 补齐了仓库内 coding workflow 闭环：结构化 git 与 patch 工具、仓库搜索、带策略闸门的变更与审批、受限 build/test，以及用于封装变更的 `git_add` / `git_commit`。 + ## Documentation Automation 文档自动化沿用了与 runtime 相同的 local-first、bounded 思路。writer 阶段只允许修改获批的主页和书籍目标文档；生成出来的 JSON、diagram spec、渲染图与 run evidence 都留在 `docs/generated/` 下，作为阶段交接和 review 证据，而不是最终用户文档。 @@ -96,19 +98,26 @@ git submodule update --init --recursive - [x] 增加 patch 校验与拒绝回退流程 - [x] 支持围绕 CMake 与 `ctest` 的受限 build/test 循环 - [x] 强化失败恢复与基于 tool result 的重试提示 -- [ ] 增加显式的提交封装流程，如 `git_add` 与 `git_commit` +- [x] 增加显式的提交封装流程，如 `git_add` 与 `git_commit` ### Phase 2 -目标：把可复用工作流解耦为 Skills。 +目标：在现有 CLI + tool loop 之上完成本地 Agent Harness（local Agent Harness）：有状态核心、扩展层、编排层、健壮性层与真实模型验证，而不是零散拼几个 feature。 + +- [ ] Stateful Core：memory、planning / task decomposition、session 与 state persistence +- [ ] Extensibility Layer：rules、skills、MCP +- [ ] Orchestration Layer：subagent 与 team/multi-agent orchestration +- [ ] Robustness Layer：context compaction、budget control、safety/approval/execution boundary +- [ ] Real-Model Harness：OpenAI-compatible 模型校验；benchmark、regression、e2e 与 load testing + +### Phase 3 -- [ ] 定义 skill 目录约定与 metadata/frontmatter 结构 -- [ ] 实现 workspace 与共享位置的 skill loader -- [ ] 把选中的 skill 注入 prompt / session 装配流程 -- [ ] 内置 C++ 规范、测试流程与 git 工作流等基础 skills -- [ ] 通过 CLI 与 config 暴露 skill 开关 -- [ ] 增加 skill 执行 trace 与调试输出 -- [ ] 用 skills 真正跑通一个仓库维护型 dogfood workflow +目标：在 Phase 2 harness 之上做 Agent Boundary Expansion / Control Plane：外部接入、控制面、trace 类 UI、daemon 形态，均作为同一 runtime 的适配层（不是每个通道各做一套 agent 核心）。 + +- [ ] P3.1 Channel Adapter Layer：将 Telegram、微信等消息入口统一为 chat transport/adapter，避免按平台各写一套 agent 逻辑 +- [ ] P3.2 Human-in-the-Loop Control Plane：审批、续跑、暂停、取消、新会话、恢复会话、任务状态查询、异步通知 +- [ ] P3.3 UI / Trace Console：本地或 Web UI，覆盖当前 plan、tool 时间线、memory、subagent/team 图、compaction 前后对比、approval 队列、diff preview、replay +- [ ] P3.4 Remote Execution / Agent Daemon：常驻或远程进程，使通道与 UI 连接同一 runtime，而非仅绑定当前 shell ### Docs Agent Milestone @@ -126,9 +135,4 @@ git submodule update --init --recursive ## Future Directions -更远期方向仍然围绕 runtime 本身展开： - -- MCP 集成 -- Telegram 或其他远程入口 -- 更细粒度的 sandbox / permission 模型 -- 更强的自主 coding workflow +具体排期见上文 **Roadmap**：**Phase 2** 完成本地 Agent Harness；**Phase 3** 在该 harness 之上补齐控制面与外部边界。更细粒度的 sandbox 等探索，原则上仍落在上述阶段内推进，而不是零散试水。