v1.6 · Engineering Harness Workflow Skill

AgentWorkflow，
把 AI 研发固化为可管控的工程系统

AgentWorkflow 将复杂的产品、前端、后端协作，压缩成清晰发光的研发结构：Reference → DSL → Plan → AT-T → Verify → Handoff。启动只需要说 启动 aw 或 @aw。

全自动代码地图context plan、task start/complete、watch、pre-commit 自动刷新 CODE_MAP。

先确认再编码DSL、Plan、任务需求、上下文白名单逐层闸门，不靠 Agent 自觉。

跨端同步中心产品、前端、后端共享 DSL / Plan / Contract / Handoff，减少对接成本。

开始使用代码地图复制提示词查看仓库

✦ AgentWorkflow

Overview

DSL Suite

Plans

Sync Center

Delivery Gate

Task Board

TaskOwnerGateStatus

DSL-001PM AgentReviewedReady

AT-FE-012FrontendContextIn progress

AT-BE-008BackendContractBlocked

REL-001FullstackTraceQueued

Notifications

✓ DSL 已审核，可以生成共享 Plan。

● 后端 contract schema 有变更，前端需 pull inbox。

✓ AT-FE-012 测试通过，等待 Git 决策。

AgentWorkflow 解决什么问题

它不是普通提示词集合，而是一套约束 Agent 的研发操作系统：让 AI 不再上来就扫全仓、猜需求、乱改代码、忘记同步、忘记测试。

需求清晰

先 DSL 后代码

需求、页面、交互、事件、联动边界、验收都进入 DSL，审核前不写业务代码。

任务可控

Plan 拆 AT-T

每个研发任务都有范围、依赖、验收、测试计划和完成条件。

跨端同步

同步中心协作

产品、前端、后台前端、后端通过 shared DSL、Plan、任务看板和契约文件沟通。

Agent 注册

长期身份可治理

aw agents register 把长期 Agent 身份、职责、边界和状态登记到 registry，再把任务分配交给 assign / claim。

快速启动

在 Codex、Cursor、Claude Code、Copilot、Windsurf、Cline、Continue、QoderWork、TraeIDE、Lingma、OpenClaw、qclaw 或任意聊天工具中，都可以通过同一套规则启动。

对话启动

启动 aw

请先问我角色：
1 产品
2 前端
3 后端
4 全栈
然后扫描项目，判断新项目 / 已有项目，
再引导我确认同步中心、代码仓库平台和构建目标。

终端启动

./scripts/aw start
./scripts/aw project scan
./scripts/aw status --json
./scripts/aw dashboard

硬规则：角色、项目阶段、同步中心决策、代码仓库平台、构建目标没有确认前，不生成 Plan，不执行研发任务，不写业务代码。

真实产品研发主流程

v1.6 的页面按真实项目路径重新规划：从参考资料进入 DSL，再到计划拆分、任务派发、研发验证、交接发布。

1启动与扫描选择角色，扫描项目，确认新项目 / 已有项目和仓库平台。

2参考资料PRD、UI、Pencil、技术文件、接口资料进入 reference 或同步中心。

3DSL 审核生成多文件 DSL，覆盖需求、页面、交互、事件、边界、验收。

4Plan 拆分审核 DSL 后生成全局 Plan、前端 Plan、后端 Plan 和共同任务。

5研发执行每个 AT-T 先沟通确认，再上下文白名单，再编码、测试、记录 Bug。

6交付闭环trace、policy、contract、score、handoff、Git / VCS 和 release 记录。

产品全生命周期流程图

产品输入PRD / UI / Pencil / 竞品 / 技术资料进入 reference 或同步中心。

需求结构化PM Agent 生成 DSL Suite，覆盖需求、页面、交互、事件、边界、验收。

工程计划DSL 审核后拆 Global Plan、前端 Plan、后台 Plan、后端 Plan、共同任务。

任务派发任务进入 assignment / TASK_BOARD，研发 Agent 认领并检查依赖。

开发联调按 AT-T 执行，接口通过 contract / mock / schema diff 对齐。

验收发布trace、policy、security、release、score、handoff、Git 形成闭环。

四种角色路线

启动后第一件事是问工程师角色。角色决定 Agent 能做什么、真源在哪里、是否需要同步中心。

角色	主要职责	启动后的默认路线	不能做什么
产品	管理参考资料、需求、Pencil、共享 DSL、共享 Plan、任务派发和看板。	`aw pm start` → `aw pm init` → 维护同步中心。	不直接改业务代码，不绕过研发确认。
前端	认领前台 / 后台前端任务，读取共享 DSL / Plan / contract。	`aw sync pull` → `aw task brief` → `aw context gate`。	不私自修改全局 DSL / Plan。
后端	认领接口、数据、权限、服务、契约测试和后端任务。	先检查合同与前端依赖，再确认任务边界。	不口头变更字段、权限、错误码。
全栈	默认前后端同仓开发，可不强制同步中心。	构建目标默认 fullstack；分仓或多人协作时再启用同步中心。	不因为同仓就跳过 DSL / Plan / AT-T。

项目拓扑选择

AgentWorkflow 不默认你只有一个仓库。它会引导选择本地 Git、GitHub、GitLab、Bitbucket、Gitee、GitCode、Gitea、Forgejo、GitLab CE、Gerrit、Codeup 等平台。

仅前端 / 仅后端

单项目

DSL 和 Plan 在本项目内维护；同步中心可选。适合独立工具、单端改造、维护任务。

同一台电脑

前后端多项目

建议在多个项目平级目录建立 project-harness，本地路径同步，必要时再接远程 Git。

不同电脑

远程同步中心

把 project-harness 做成独立远程仓库，各端通过 pull/push 同步 DSL、Plan、看板、契约和 handoff。

三端同步中心机制

当前台前端、后台管理前端、后端分开开发时，不能各自生成各自的 DSL 和 Plan。共享 DSL 与全局 Plan 应放在同步中心，再派生到各端。

同步中心目录	用途	谁维护
`global/references/`	PRD、UI 规范、技术资料、Pencil 源文件和导出图。	产品 Agent 主维护。
`global/dsl/`	共享 DSL：需求、页面、交互、事件、联动边界、验收。	产品 Agent 生成，工程师审核。
`global/plans/`	全局 Plan、前台 Plan、后台管理 Plan、后端 Plan、共同任务。	产品 Agent 拆分，研发 Agent 认领。
`global/contracts/`	OpenAPI、mock、contract test、schema diff、集成矩阵。	前后端共同维护。
`global/dispatch/`	任务派发表、状态看板、阻塞、问题、交接事件。	产品 Agent 监控，各端回写。

产品 / 前端 / 后端同步泳道

产品 Agent

收集 PRD / UI / Pencil

生成共享 DSL

拆全局 Plan 与派发表

监控看板、变更、阻塞

前端 Agent

pull 同步中心

认领页面 / 交互任务

按 contract 联调

回写完成 / 问题 / handoff

后端 Agent

pull 同步中心

认领接口 / 数据 / 权限任务

更新 OpenAPI / mock / test

回写完成 / schema diff / 风险

同步原则：aw sync pull 只把对方快照导入本项目 docs/sync/inbox/，它是只读收件箱；本项目是否采纳，必须通过 REQ / Bug / Plan / Handoff 落账。

多 Agent 角色协同

v1.6 把 Agent 从一次性 owner 升级成长期 worker identity。每个 Agent 先注册身份、职责、边界和运行工具，再进入 assignment、claim、heartbeat、handoff、review 的协作链路。

治理角色

PM / Communicator

PM 维护 DSL、Plan、ATOMIC、dispatch 和 Business Gate；Communicator 作为低污染旁路整理用户意图、进度和交接，不直接改业务代码。

执行角色

Fullstack / Frontend / Admin / Backend

执行 Agent 按已确认任务认领文件边界，使用 claim 和 heartbeat 留下任务锁、状态和下一步，避免多人改同一片区域。

评审角色

Businessman / Plan Review / Tester

评审 Agent 不抢实现职责：商业评审守 ICP 与购买理由，产品计划评审守 runtime 立意，测试 Agent 设计正常、边界、异常、多轮用例并反馈缺陷。

Agent	长期职责	协作边界
`communicator-agent`	低污染沟通旁路、状态整理、指令压缩、handoff 整理。	不直接执行研发任务，不把闲聊写入执行上下文。
`codex-pm-agent`	产品 DSL、Plan、ATOMIC、Business Gate、Demo Scenario。	不越过 Plan / ATOMIC 直接推进实现。
`frontend-agent` / `admin-agent` / `backend-agent`	分别负责前台、后台管理端、后端 runtime/kernel/API/service。	跨端接口变化必须通过 contract、integration matrix 和 sync event。
`businessman` / `product-plan-review-agent`	商业化与产品计划评审，防止偏离 Stateful AI Engineering Runtime 主线。	只评审和输出建议，不私自改实现代码。
`tester-agent`	全维度功能测试、用例执行、缺陷反馈和《测试小结》。	严格按测试逻辑推进，不闲聊、不偏离测试目标。

Agent 身份到任务协作流程图

Registeraw agents register --defaults 写入长期身份、职责、边界、预设来源。

Bindaw agents bind 记录运行工具、provider、workspace、interface 和 sync mode。

AssignPM 或工程师把某个 REQ / AT-T / 阶段职责分配给已注册 Agent。

Claim执行 Agent 对具体 AT-T 和 allowed paths 加任务锁，防止并行冲突。

Heartbeat研发中持续记录 working / blocked / done、当前动作、阻塞和下一步。

Handoff / Review交接证据、评审结果、blocker 和建议进入 ledger，gate 统一检查。

关键命令：aw agents list --bindings 看当前 Agent 运行在哪个工具里；aw agents gate --strict 会阻断未注册 Agent、缺少 runtime binding、路径重叠和 blocking review。

跨 IDE 协同机制

AgentWorkflow 不把流程锁死在某个编辑器里。Claude Code、Codex、Cursor、Copilot、Windsurf、Cline、Continue、QoderWork、TraeIDE、Lingma、OpenClaw、qclaw 都只是薄入口，真源始终在仓库里的 agent-workflow/、scripts/aw 和 docs/。

入口统一

适配文件只是指针

CLAUDE.md、AGENTS.md、.cursor/rules、.qoderwork/rules 等只负责把 Agent 指向同一份 Invocation。

状态统一

Ledger 在仓库内

REQ、DSL、Plan、ATOMIC、Agent Registry、Handoff、Memory、Bug、Report 都进 Git，不依赖某个 IDE 的私有上下文。

身份统一

Runtime Binding

同一个 backend-agent 可以今天跑在 Codex，明天绑定到 Lingma 或 qclaw，但身份、边界和任务历史不变。

升级统一

更新 aw

已安装用户在项目里运行 aw update --from-github --adapters，重新拉取 GitHub、替换 package/scripts，并重装本机 skill。

工具 / IDE	入口文件	绑定示例
Codex	`AGENTS.md`	`aw agents bind codex-fullstack --runtime codex --provider openai`
Claude Code	`CLAUDE.md`	`aw agents bind communicator-agent --runtime claude-code --provider anthropic`
QoderWork / TraeIDE / Lingma	`.qoderwork/`、`.trae/`、`.lingma/`	`aw agents bind tester-agent --runtime qoderwork --interface ide`
OpenClaw / qclaw	`.openclaw/`、`.qclaw/`	`aw agents bind tester-agent --runtime qclaw --provider longjia --sync-mode handoff-only`

跨 IDE 协同流程图

安装适配器aw adapters --all 或 aw adapters --china 创建各工具入口文件。

读取同一真源所有 IDE 都指向 agent-workflow/INVOCATION.md 和 AGENT_RULES.md。

绑定 Runtime用 aw agents bind 标记 Agent 正在哪个工具、workspace 和同步模式里运行。

共享 Ledger任务、心跳、交接、评审、Bug 和报告都写回 docs/，跨工具可接续。

统一 Gateaw agents gate、aw sync gate、aw release gate 在提交和发布前统一检查。

迁移原则：换 IDE 不换流程，换 runtime 不换 Agent 身份。只要仓库 ledger 完整，新工具接手时先 aw status、aw agents bindings、aw handoff --check，再继续任务。

DSL 与 Plan 如何拆

DSL 是产品与工程共同确认的“需求结构”，Plan 是可执行的“研发任务结构”。复杂项目先共享，再派发；简单项目可以在本地直接生成。

DSL Suite

`00-requirements.md`	需求、角色、场景、非目标。
`10-pages.md`	页面结构、信息架构、组件区域。
`20-interactions.md`	交互行为、状态、异常、空态。
`30-events.md`	事件、埋点、触发条件。
`40-boundaries.md`	前后端边界、权限、数据口径、接口。
`90-acceptance.md`	验收标准、测试口径、风险。

Plan 类型

Global Plan	跨端里程碑、依赖、共同任务。
Frontend Plan	前台前端页面、状态、接口联调。
Admin Plan	后台管理页面、权限、表格表单。
Backend Plan	接口、数据模型、权限、服务、测试。
Common Tasks	契约、mock、联调、验收、发布。

DSL 审核到 Plan 派发流程图

参考输入manifest + PRD + UI + 技术约束，分批读取，避免上下文爆炸。

DSL Suite需求 / 页面 / 交互 / 事件 / 边界 / 验收六类文档。

工程师审核确认缺口、歧义、非目标、验收口径，执行 aw approve dsl。

Plan 拆分生成全局计划、端侧计划、共同任务、依赖和测试计划。

任务派发Plan 审核后才写 assignment / TASK_BOARD，研发 Agent 再认领。

关键确认点：DSL 审核后才引导生成 Plan；Plan 审核后才引导前端 / 后端 / 后台前端认领任务。没有审核，不进入编码。

研发执行流程

每个子任务开始前都要像真实研发一样问清楚需求，而不是看到 Plan 状态变化就直接改代码。

Aaw next找出下一项任务与依赖。

Btask brief输出任务范围、验收、风险。

C需求追问确认边界、异常态、非目标。

Dcontext gate只读取白名单文件。

E编码验证改代码、跑测试、记 Bug。

F完成同步任务状态、handoff、看板、Git 决策。

单个 AT-T 研发任务流程图

找任务aw next 找出当前可执行任务和阻塞依赖。

读 Briefaw task brief 输出范围、验收、风险、跨端依赖。

问清楚工程师确认范围、异常态、非目标、接口和权限影响。

控上下文aw context plan / gate 只授权读取白名单文件。

写代码小步修改，跑 lint / typecheck / test / build，Bug 全记录。

完成闭环task complete、FILE_INDEX、handoff、sync board、Git 决策。

硬闸门

这些是 v1.6 需要 Agent 严格执行的流程约束。它们存在的意义是让 AI 不靠自觉，而靠流程卡住风险。

闸门	触发时机	阻止什么
启动闸门	第一次说 `启动 aw` / `@aw`	未确认角色、项目阶段、同步中心就进入开发。
DSL 闸门	生成需求结构后	DSL 未审核就写业务代码。
Plan 闸门	拆分研发计划后	Plan 未确认就拆任务或派发。
任务确认闸门	每个 AT-T 开始前	没有问清楚需求就改代码。
上下文闸门	编码前	全仓扫描、读取无关文件、浪费 token。
验证闸门	任务完成时	测试失败却标记完成。
同步闸门	跨端任务开始 / 完成	前后端各做各的，接口和计划漂移。
VCS 闸门	提交 / PR / MR / CR 前	没有版本记录、测试证据、回滚说明。

研发中需求变更闭环图

变更提出口述新增 / 研发中变更 / Bug 派生需求都先记录类型。

REQ 落账aw req new 或 aw req change，关联原 DSL / Plan / AT-T。

回更真源更新 DSL、Plan、ATOMIC、TASK_BOARD，不直接跳到代码。

同步影响涉及跨端则更新 contract、mock、schema diff、sync event。

重新确认工程师确认新范围后，再进入 context gate 和编码。

Token 预算与上下文压缩

v1.6 的默认策略是“先摘要、后展开”。Agent 不应该把 HTML 手册、工程索引、同步中心、历史记录或整仓代码一次性读进上下文。

默认预算

6 / 12 / 3

每个 AT-T 最多 6 个业务文件、12 个 symbol、3 次精准搜索。超预算必须说明原因并等待确认。

读取顺序

摘要优先

aw status --json、aw next、aw task brief、aw code-map query、aw context plan、aw sync inbox。

新会话恢复

handoff + memory

aw compact 生成新会话粘贴摘要，aw memory 保存长期可复用决策。

上下文读取流程图

先读状态aw status --json / aw next / aw task brief。

生成白名单aw context plan 生成 CTX-AT-T，列出允许文件。

工程师确认超出 6 文件 / 12 symbol / 3 搜索前必须说明原因。

按需展开只读白名单文件和相关 symbol，不读整仓和 HTML 手册。

代码地图：先定位，再读取

代码地图是专门解决“AI 一改代码就扫全仓”的能力。它把项目压缩成模块、入口、Symbol、路由/API、import 线索和测试映射，让 Agent 先查地图，再生成任务级 Context Plan。

自动生成

`CODE_MAP.md`

aw context plan、aw task start、aw task complete、aw watch index 和 pre-commit 会自动刷新代码地图。

精准查询

`query / impact`

通过 aw code-map query "keyword" 和 aw code-map impact "symbol" 找相关文件、调用线索、路由和测试。

进入闸门

Context Plan

代码地图只是定位索引，不授权全文读取。真正编码前仍要生成 CTX-AT-T 并让工程师确认白名单。

文件 / 命令	作用	边界
`docs/context/CODE_MAP.md`	AI 面向的代码地图：模块、入口、Symbol、路由/API、测试映射、依赖线索。	定位用，不等于可以读取全文。
`docs/context/CODE_CONTEXT_INDEX.md`	人工可补充的上下文索引，记录更准的模块、页面、后端入口和测试关系。	作为 CODE_MAP 的补充。
`docs/FILE_INDEX.md`	人类工程师文件索引，方便查找 AI 写过或需要手改的代码文件。	给人看，不让 Agent 默认全文读取。
`aw context plan --task`	把地图查询结果转成当前任务允许读取的文件白名单。	工程师确认后才读文件。

代码地图读取流程图

构建地图aw code-map build 生成模块、入口、Symbol、路由、测试和 import 线索。

查询定位aw code-map query / impact，只看索引和少量命中。

生成白名单aw context plan 把候选文件写入 CTX-AT-T。

工程师确认确认范围、文件、扩大理由和读取预算。

按需读代码只打开白名单文件，改完跑 affected / verify。

默认全自动：研发任务进入 context plan / task start / task complete 时会刷新并校验 CODE_MAP.md；aw watch index 会同步刷新代码地图、文件索引和工程索引；Git pre-commit 会自动刷新并暂存更新后的地图。只有设置 AW_CODE_MAP_AUTO=0 才会关闭自动刷新，这应作为明确例外记录。

工程师索引与文件索引

AI 写代码以后，人类工程师必须能快速找到该手改、该审查、该联调的文件。

文件	读者	用途	维护时机
`docs/FILE_INDEX.md`	人类工程师	项目代码文件索引，说明每个业务文件、测试文件、配置文件的职责。	新增 / 删除 / 重命名业务文件时刷新。
`ENGINEERING_INDEX.md`	人类工程师 + 审计	工程索引、扫描快照、交付状态，不作为 Agent 默认上下文全文读取。	重大阶段、检查、同步、交付前刷新。
`docs/context/tasks/CTX-*.md`	Agent + 工程师	当前任务允许读取的上下文白名单。	每个 AT-T 编码前生成并确认。

提示词大全

下面按项目场景组织。每段都可以一键复制，替换路径、项目名、任务 ID 即可。

1. 通用启动

启动 aw。
请先问我是什么角色：1 产品；2 前端；3 后端；4 全栈。
确认角色后，扫描当前项目，判断是全新项目还是已有项目。
然后引导我选择是否建立同步中心、代码仓库平台、构建目标。
未完成这些确认前，不要生成 Plan，不要写业务代码。

2. 产品 Agent 建同步中心

启动 aw，我的角色是产品。
我要建立项目同步中心，路径是：/path/to/project-harness。
请引导我放入 PRD、UI 规范、Pencil 设计稿、技术资料和接口资料。
然后基于参考资料生成共享 DSL，等待我审核。
DSL 审核后，再生成 Global Plan、Frontend Plan、Admin Frontend Plan、Backend Plan 和共同任务看板。

3. 同电脑前后端多项目

启动 aw。
当前是同一台电脑上的前后端多项目协作。
前台前端路径：/path/to/web
后台管理前端路径：/path/to/admin
后端路径：/path/to/backend
同步中心路径：/path/to/project-harness
请先检查同步中心是否存在，再引导各项目接入。
DSL 和共享 Plan 放同步中心，本地 Plan 只作为执行派生。

4. 不同电脑前后端协作

启动 aw。
当前前端和后端不在同一台电脑。
请引导我配置独立远程同步中心仓库。
代码平台需要让我选择：GitHub、GitLab、Bitbucket、Gitee、GitCode、Gitea、Forgejo、GitLab CE、Gerrit、Codeup。
同步中心用于共享 DSL、Plan、TASK_BOARD、contracts、handoff、bug 和需求变更。
不要用本地路径假设对方能访问。

5. 仅前端项目

启动 aw，我的角色是前端。
这是仅前端项目。
请扫描项目，判断新项目还是已有项目。
如果是已有项目，先建立当前状态基线、文件索引、服务/API 依赖索引。
然后只为下一期或当前需求生成增量 DSL 和增量 Plan。

6. 仅后端项目

启动 aw，我的角色是后端。
这是仅后端项目。
请扫描项目结构、接口入口、数据库迁移、权限模型、测试命令。
确认技术栈和安全底线后，再生成后端 DSL / Plan。
涉及接口、字段、权限、错误码、数据口径时必须明确确认。

7. 已有项目接入

启动 aw。
这是已有项目，不是全新项目。
请不要重建项目，也不要按空白项目生成计划。
先扫描当前代码与文档，建立一期已完成范围、稳定边界、已知 Bug、技术债、接口清单和文件索引。
基线确认后，只针对新增需求生成增量 DSL 和增量 Plan。

8. DSL 审核后生成 Plan

DSL 已确认。
请基于已审 DSL 生成研发 Plan。
如果是三端项目，请先生成共享 Global Plan，再拆出前台前端、后台管理前端、后端和共同任务。
每个任务都要包含范围、依赖、验收、测试计划、是否跨端、阻塞条件。

9. Plan 审核后派发任务

Plan 已确认。
请根据同步中心的 Plan 派发任务。
前端、后台管理前端、后端分别生成 assignment。
共同任务放入 integration / contract / QA 队列。
派发后更新 TASK_BOARD，并说明每个 Agent 下一步应该认领什么。

10. 执行研发任务

执行下一个研发任务。
请先运行或输出 aw next 和 aw task brief。
然后向我确认：范围、验收、非目标、异常态、跨端依赖、接口/字段/权限影响。
我明确确认前，不要写代码。
确认后先用 aw code-map query / impact 定位相关模块，
再生成 context plan、执行 context gate，并只读取白名单文件。

11. 构建代码地图

启动 aw 的代码地图能力。
请确认代码地图自动刷新已开启，不要关闭 AW_CODE_MAP_AUTO。
执行 aw context plan / aw task start / aw task complete 时会自动生成或更新 docs/context/CODE_MAP.md。
然后针对当前需求执行 aw code-map query "<需求关键词/路由/symbol>"。
只根据代码地图输出候选模块、入口文件、相关 symbol、路由/API 和测试映射。
不要因为查询不足就全仓扫描；需要扩大上下文时先说明原因并等待我确认。

12. 需求变更同步

当前有需求变更：
变更内容：<描述>
影响范围：<页面/接口/权限/数据/任务>
请先记录为 REQ change，不要直接改代码。
然后回更 DSL、Plan、ATOMIC_TASKS、TASK_BOARD。
如果影响前后端契约，请同步更新 OpenAPI / mock / contract test / schema diff。

13. 完成任务

完成当前 AT-T。
请执行 aw task complete。
如果测试失败，记录 AI_BUG_LOG，并保持任务未完成。
如果通过，更新 handoff、FILE_INDEX、TASK_BOARD、CHANGELOG。
然后问我是否提交当前项目 Git，以及是否提交同步中心 Git。

14. 新会话恢复

使用 aw 恢复上下文。
请先执行 aw handoff --check、aw memory inject、aw status --json、aw next。
只总结当前阶段、阻塞、下一步。
不要读取 HTML 手册，不要全文读取 ENGINEERING_INDEX.md，不要全仓扫描。

15. 发布前检查

准备发布前检查。
请执行 trace、policy、security、contract、release、score、handoff 检查。
汇总未关闭 Bug、未确认需求变更、未同步任务、未提交版本记录、回滚方案。
如有阻塞项，不要建议发布。

常用命令

命令不是要求工程师死记，而是给 Agent 和工程师共同校验流程状态。

启动 / 状态

./scripts/aw start
./scripts/aw status --json
./scripts/aw dashboard
./scripts/aw doctor

DSL / Plan

./scripts/aw dsl suite feature-x "标题"
./scripts/aw dsl review docs/dsl/DSL_X
./scripts/aw approve dsl docs/dsl/DSL_X
./scripts/aw confirm <dsl> <plan>

研发任务

./scripts/aw next
./scripts/aw task brief AT-T1-001
./scripts/aw context plan --task AT-T1-001
./scripts/aw context gate --task AT-T1-001
./scripts/aw task complete AT-T1-001

代码地图

./scripts/aw code-map init
./scripts/aw code-map build
./scripts/aw code-map query "user list"
./scripts/aw code-map impact "UserService"
./scripts/aw code-map gate --task AT-T1-001

同步中心

./scripts/aw sync init /path/to/project-harness
./scripts/aw sync pull --from all
./scripts/aw sync inbox --from backend
./scripts/aw sync board
./scripts/aw sync push

PM

./scripts/aw pm start
./scripts/aw pm init /path/to/project-harness
./scripts/aw pm plan --write
./scripts/aw pm dispatch
./scripts/aw pm dashboard

质量闭环

./scripts/aw trace check
./scripts/aw policy gate --strict
./scripts/aw security scan
./scripts/aw release gate
./scripts/aw report handoff

Agent 注册

./scripts/aw agents register --defaults
./scripts/aw agents register --preset backend
./scripts/aw agents bind tester-agent --runtime qoderwork
./scripts/aw agents list --bindings
./scripts/aw agents list
./scripts/aw agents show backend-agent
./scripts/aw agents gate --strict

更新 aw

./scripts/aw upgrade --from-github --adapters
./scripts/aw update --from-github --adapters

版本更新

像 App Store 更新记录一样，快速知道每个版本把 AgentWorkflow 往哪一层推进了。

v1.6

2026-05-31

Agent Registry

正式 Agent 注册能力

新增 aw agents register/list/show/unregister，把长期 worker identity 从任务 assignment 中拆出来。
新增 aw agents bind/unbind/bindings，记录 Agent 运行工具、provider、workspace、接口和同步模式。
Agent registry 新增 runtime/tool binding 字段，支持 qoderwork、qoder、trae、traeide、lingma、openclaw、qclaw 等运行时枚举。
新增 communicator、businessman、PM、产品计划评审、fullstack、frontend、admin、backend、tester 默认预设。
新增 QoderWork、TraeIDE、Lingma、OpenClaw、qclaw 适配器，并提供 aw adapters --china 一键安装国产 / 龙嘉组合。
aw agents gate --strict 可阻断未注册 Agent、缺少 runtime binding 的 Agent 以及 assignment / claim 冲突，保留非 strict warning 模式。
新增 aw update --from-github 更新入口，可重新拉取 GitHub、删除旧本机 skill、安装最新版 skill，并替换当前项目 package/scripts。

v1.5

2026-05-29

Manual

产品化 HTML 手册

重做本地 HTML 使用手册，覆盖启动、角色路由、同步中心、DSL/Plan、研发闸门、命令和 FAQ。
把包、Skill、Codex plugin metadata 推进到统一发布版本。
强化多 IDE / 多 Agent 的安装、演示、诊断和文档一致性检查。

v1.4

2026-05

Runtime Gates

上下文、契约和代码地图自动化

引入任务级 Context Plan、读取预算、affected analysis 和 aw context gate。
新增自动 Code Map 刷新，在 context plan、task start/complete、watch、pre-commit 中自动维护索引。
补齐 contract diff、mock、schema 破坏性检查、PR/MR/CR 草稿和 VCS gate。

v1.3

2026-05

PM Flow

PM 同步中心和三端派发

新增 aw pm 产品生命周期：资料 intake、Pencil 设计、共享 Plan、dispatch、dashboard 和 lifecycle gate。
强化前台前端、后台管理前端、后端三端任务看板和集成矩阵。
新增跨项目 sync pull/push/inbox/board/gate，支持分仓和不同电脑协作。

v1.2

2026-05

Harness

工程化闭环扩展

新增 audit、policy、security、service catalog、release、metrics、ops、score 和 recovery 记录。
新增 task checkpoint、file-index gate、release gate、report handoff/release，把完成态证据串起来。
新增 compact、memory chat、handoff snapshot，改善新会话和上下文压缩后的续接。

v1.1

2026-05-19

Workflow

任务执行和验证链路增强

补齐 DSL/Plan apply、多 DSL/Plan 选择、AT-T 当前状态、blocked task、TP 计划和 e2e 验证。
新增 config init、doctor、demo、setup、upgrade/remove、英文 invocation 和可复用 CI workflow。
强化 task brief/confirm/start/complete，防止用户说“开始开发”后 Agent 直接写代码。

v1.0

Initial

Foundation

工具无关 AI 交付工作流

建立 scripts/aw 统一 CLI，覆盖 init、install、dsl、plan、confirm、check、req、next。
建立 Reference → DSL → Plan → Confirm → ENGINEERING_INDEX 的阶段 0 真源链路。
提供 Cursor Skill、Git hooks、pre-commit verify、基础模板和跨工具调用入口。

FAQ

几个最容易混淆的问题，先摊开说清楚。

这些动作是后台自动执行吗？

不是后台服务。Agent 可以在当前会话中自动调用命令，但关键决策仍要向工程师确认，尤其是需求、同步中心、Git、发布和高风险变更。

同步中心必须建吗？

单项目或全栈同仓可以不建。前后端分仓、不同电脑、PM 三端协作、需要共享 DSL / Plan 时建议建立。

前后端怎么知道对方做了什么？

通过 TASK_BOARD、sync inbox、handoff、REQ、Bug、contracts、OpenAPI、mock 和 contract test，不靠聊天口头同步。

Git 会自动提交吗？

不会。每个大需求或任务完成后，Agent 应询问是否提交当前项目 Git 和同步中心 Git。提交前需要版本记录与验证证据。

已有项目怎么接入？

先扫描当前真实状态，建立基线和索引，确认一期完成范围，再对新增需求生成增量 DSL / Plan。不要按新项目重构。

为什么不让 Agent 读 ENGINEERING_INDEX 全文？

它是给人类工程师快速定位项目文件和审查 AI 代码用的。Agent 默认应读任务级 Context Plan，避免 token 爆炸。

AgentWorkflow v1.6 · 本页面是本地静态 HTML，可直接浏览，也同步到 GitHub Pages。运行真源仍以 agent-workflow/INVOCATION.md、skill/SKILL.md 和 scripts/aw 为准。

AgentWorkflow，把 AI 研发固化为可管控的工程系统

AgentWorkflow 解决什么问题

先 DSL 后代码

Plan 拆 AT-T

同步中心协作

长期身份可治理

快速启动

对话启动

终端启动

真实产品研发主流程

四种角色路线

项目拓扑选择

单项目

前后端多项目

远程同步中心

三端同步中心机制

多 Agent 角色协同

PM / Communicator

Fullstack / Frontend / Admin / Backend

Businessman / Plan Review / Tester

跨 IDE 协同机制

适配文件只是指针

Ledger 在仓库内

Runtime Binding

更新 aw

DSL 与 Plan 如何拆

DSL Suite

Plan 类型

研发执行流程

硬闸门

Token 预算与上下文压缩

6 / 12 / 3

摘要优先

handoff + memory

代码地图：先定位，再读取

CODE_MAP.md

query / impact

Context Plan

工程师索引与文件索引

提示词大全

1. 通用启动

2. 产品 Agent 建同步中心

3. 同电脑前后端多项目

4. 不同电脑前后端协作

5. 仅前端项目

6. 仅后端项目

7. 已有项目接入

8. DSL 审核后生成 Plan

9. Plan 审核后派发任务

10. 执行研发任务

11. 构建代码地图

12. 需求变更同步

13. 完成任务

14. 新会话恢复

15. 发布前检查

常用命令

启动 / 状态

DSL / Plan

研发任务

代码地图

同步中心

PM

质量闭环

Agent 注册

更新 aw

版本更新

正式 Agent 注册能力

产品化 HTML 手册

上下文、契约和代码地图自动化

PM 同步中心和三端派发

工程化闭环扩展

任务执行和验证链路增强

工具无关 AI 交付工作流

FAQ

这些动作是后台自动执行吗？

同步中心必须建吗？

前后端怎么知道对方做了什么？

Git 会自动提交吗？

已有项目怎么接入？

为什么不让 Agent 读 ENGINEERING_INDEX 全文？

AgentWorkflow，
把 AI 研发固化为可管控的工程系统

`CODE_MAP.md`

`query / impact`