diff --git a/docs/todo/system-design/27-e2e-task-execution-flow.md b/docs/todo/system-design/27-e2e-task-execution-flow.md index bd9d021..56ee776 100644 --- a/docs/todo/system-design/27-e2e-task-execution-flow.md +++ b/docs/todo/system-design/27-e2e-task-execution-flow.md @@ -92,14 +92,14 @@ P2 已经设计了：`system/org-graph-templates/{dev,content,ops}.json` 模板 **状态**：📐 概念已在 27 号文档 §3.4 定义，执行引擎见 [27-P3/P4](./27-p3-p4-work-graph-console.md)，**但 planning agent 本身未设计** -你举的例子 `brd-planning → prd-planning → sdd-planning → benchmark → testdata → code-planner-validator → loop-validator`，与 DevLoop 的实际链路高度重合： +你举的例子 `brd-planning → prd-planning → sdd-planning → benchmark → testdata → planner-validator → loop-validator`，与 DevLoop 的实际链路高度重合： | 你的节点 | DevLoop 对应物 | 状态 | |---|---|---| | brd / prd | PM Agent 产出多页 PRD 站点（`sdd-model.md` M-3） | ✅ 已实现 | | sdd | Architect 产出 SDD（MVCP 四页）+ `units.json` | ✅ 已实现 | | benchmark / testdata | Architect 同步产出 `integration/spec.json`（M-6） | ✅ 已实现 | -| code-planner-validator | Architect 的 self-check + L2 gate 判定 | ✅ 已实现 | +| planner-validator | Architect 的 self-check + L2 gate 判定 | ✅ 已实现 | | loop-validator | Loop-Validator（27 号 §3.5）/ BugTriager | 📐 27 号未实现；DevLoop 版 ✅ 已实现 | 💡 **值得注意**：DevLoop 的 `loops-l2.md` 已经就「谁来写验收标准」做过一次显式的方案选型（A/B/C 三选一），并选了 **A：由 Architect（设计者）在生成 SDD 时同步产出 `integration/spec.json`**，明确否决了 **C：由 Integrator（执行者）自己写测试**，理由是「容易写一个永远会通过的 trivial test」。你的流程让 planner 阶段产出 benchmark/testdata、让后面的 validator 阶段消费它，正好符合方案 A 的思路——**设计者定标准、执行者不定标准**。这条已经被论证过的原则应该在通用层继承下来。 @@ -290,7 +290,7 @@ DevLoop 就这个问题做过显式决策（`loops-l2.md` 方案 A/B/C），选 ✅ **§十一 的三节点设计天然符合这条原则**：`goal-benchmark` / `-test-data` / `-test-script` 三个 agent 与真正写代码的 coder 是**完全不同的 system agent**，产出者和被验收者分离，不存在"自己给自己出考题"的激励问题。 ⚠️ **但仍未解决"标准写错了"这一层**。缓解手段有两个，建议都要： -1. work graph 里的 `code-planner-validator` 节点承担一项明确职责——审"这套验收标准是否可度量、是否覆盖原始需求、是否存在平凡通过的漏洞"，而不只是审 PRD/SDD 本身。 +1. work graph 里的 `planner-validator` 节点承担一项明确职责——审"这套验收标准是否可度量、是否覆盖原始需求、是否存在平凡通过的漏洞"，而不只是审 PRD/SDD 本身。 2. 保留人工 sign-off（DevLoop L3 的做法）作为最终关卡，至少在 v1 阶段不要全自动闭环。 ### 7.4 并行与现有不变量冲突 @@ -431,15 +431,15 @@ benchmark / test data / test script **不是系统基础设施，是 work graph **由 planning agent 在规划 work graph 时动态决定加哪几个**——可以三个都加、只加一个、或某种组合。这使得"要不要加验收节点、加哪个"成为 work graph 规划的一等决策，而不是固定模板。 -例：`code-planner` 这个 org node 的 work graph 可能长成 +例：`org-planner` 这个 org node 的 work graph 可能长成 ``` brd-planning → prd-planning → sdd-planning ─┬→ goal-benchmark ──┐ - ├→ goal-test-data ──┼→ code-planner-validator → loop-validator + ├→ goal-test-data ──┼→ planner-validator → loop-validator └→ goal-test-script ┘ ``` -三个验收节点之间**无依赖，可并行**（fan-out），汇合到 `code-planner-validator`（fan-in）。这正好是 §7.4 fan-out 能力的第一个真实用例。 +三个验收节点之间**无依赖，可并行**（fan-out），汇合到 `planner-validator`（fan-in）。这正好是 §7.4 fan-out 能力的第一个真实用例。 ### 11.2 三者必须产出统一的「验收契约」 diff --git a/docs/todo/system-design/27-example-dev-company-walkthrough.md b/docs/todo/system-design/27-example-dev-company-walkthrough.md index 34988fa..a765a1d 100644 --- a/docs/todo/system-design/27-example-dev-company-walkthrough.md +++ b/docs/todo/system-design/27-example-dev-company-walkthrough.md @@ -58,11 +58,11 @@ ```jsonc // org_graph_nodes + org_graph_edges 的等价视图 { - "nodes": ["code-planner", "code-coder", "code-validator"], + "nodes": ["org-planner", "org-coder", "org-validator"], "edges": [ - { "from": "code-planner", "to": "code-coder", "condition": "success", "edge_kind": "forward" }, - { "from": "code-coder", "to": "code-validator", "condition": "success", "edge_kind": "forward" }, - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edge_kind": "backward" } + { "from": "org-planner", "to": "org-coder", "condition": "success", "edge_kind": "forward" }, + { "from": "org-coder", "to": "org-validator", "condition": "success", "edge_kind": "forward" }, + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edge_kind": "backward" } ] } ``` @@ -79,9 +79,9 @@ curl -X POST http://localhost:3010/api/company/auto-illust/org-graph -d @/tmp/or # 2. 按拓扑序逐个招聘（注意：P2 v0.4 起 hire 不再需要 --reportsTo， # 图的结构已在第 1 步整体写入，招聘只负责建 agent 目录） -node bin/lemon.js company hire --id auto-illust --role code-planner -node bin/lemon.js company hire --id auto-illust --role code-coder -node bin/lemon.js company hire --id auto-illust --role code-validator +node bin/lemon.js company hire --id auto-illust --role org-planner +node bin/lemon.js company hire --id auto-illust --role org-coder +node bin/lemon.js company hire --id auto-illust --role org-validator ``` 三个角色在 `system/templates/` 里都没有同名模板 → `hire()` 返回 `needs_training` → 触发既有的 agent-creator + innovator 培养流水线（`company.js:917-940`，已实现）。 @@ -108,24 +108,24 @@ node bin/lemon.js company hire --id auto-illust --role code-validator 任务不需要另建一张顶层图——**阶段 2 生成的 org graph 本身就是这家公司的 workflow**，任务直接在它上面跑： ``` -[code-planner] --success--> [code-coder] --success--> [code-validator] +[org-planner] --success--> [org-coder] --success--> [org-validator] ↑ │ └────fail(backward)──┘ ``` -从入度为 0 的节点（`code-planner`）开始执行。`execution_mode` 由用户选：`manual`（每步点"下一步"）或 `auto`（一路跑到底）。假设选 `auto`。 +从入度为 0 的节点（`org-planner`）开始执行。`execution_mode` 由用户选：`manual`（每步点"下一步"）或 `auto`（一路跑到底）。假设选 `auto`。 --- -## 阶段 5 · code-planner 的 Work Graph（Level 1） +## 阶段 5 · org-planner 的 Work Graph（Level 1） -`code-planner` 这个 org node 被激活，它先调 **workgraph-planning agent** 规划自己这一层的图。 +`org-planner` 这个 org node 被激活，它先调 **workgraph-planning agent** 规划自己这一层的图。 **规划结果**——注意三个验收节点是**动态选进来的**（[27-E2E](./27-e2e-task-execution-flow.md) §十一）： ``` brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ───┐ - └→ goal-test-script ─┴→ code-planner-validator → loop-validator + └→ goal-test-script ─┴→ planner-validator → loop-validator ``` **planning agent 的选择理由**（这是它要在规划时说清楚的）： @@ -156,15 +156,15 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ── } ``` -**两个并行验收节点是 fan-out 的第一个真实用例**——它们之间无依赖，可以同时跑，汇合到 `code-planner-validator`。🔴 这会撞上 `CONVENTIONS.md` §12「任意 (pid, agent) 同时只允许 1 个 running」和 SessionPool 的 key 复用（见 [27-E2E](./27-e2e-task-execution-flow.md) §7.4）。 +**两个并行验收节点是 fan-out 的第一个真实用例**——它们之间无依赖，可以同时跑，汇合到 `planner-validator`。🔴 这会撞上 `CONVENTIONS.md` §12「任意 (pid, agent) 同时只允许 1 个 running」和 SessionPool 的 key 复用（见 [27-E2E](./27-e2e-task-execution-flow.md) §7.4）。 -`code-planner-validator` 的职责不只是审 SDD，还要审**验收标准本身**（§7.3）：这套 test_data 覆盖了原始需求吗？有没有平凡通过的漏洞？ +`planner-validator` 的职责不只是审 SDD，还要审**验收标准本身**（§7.3）：这套 test_data 覆盖了原始需求吗？有没有平凡通过的漏洞？ --- -## 阶段 6 · code-coder 的 Work Graph（Level 1）+ 并行子图（Level 2） +## 阶段 6 · org-coder 的 Work Graph（Level 1）+ 并行子图（Level 2） -`code-coder` org node 激活，同样先调 planning agent。它读到上一阶段的 SDD，把工作拆成三个可并行的 unit： +`org-coder` org node 激活，同样先调 planning agent。它读到上一阶段的 SDD，把工作拆成三个可并行的 unit： ``` ┌→ [md-parser] → [unittest] ─┐ @@ -193,9 +193,9 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ── --- -## 阶段 7 · code-validator org node + 三级恢复 +## 阶段 7 · org-validator org node + 三级恢复 -`code-validator` 激活，消费阶段 5 产出的 `acceptance.json`： +`org-validator` 激活，消费阶段 5 产出的 `acceptance.json`： | 验收项 | 执行方式 | 状态 | |---|---|---| @@ -203,15 +203,15 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ── | `test_data` | 喂样本比对实际输出 | 🔴 同上 | | `benchmark` | 本次为 null，跳过 | — | -**假设 `no-h2` 这个 case 一直过不了**，而且已经在 L1 打回 code-coder 重写 3 次、L2 重新 planning 1 次，仍然失败。 +**假设 `no-h2` 这个 case 一直过不了**，而且已经在 L1 打回 org-coder 重写 3 次、L2 重新 planning 1 次，仍然失败。 此时进入你描述的第三级 —— **L4 · 迭代 system agent**（[27-E2E](./27-e2e-task-execution-flow.md) §八）： 1. 判定这是**能力缺陷**而非粗心错误（`qa-judge` 的三分类：粗心错误 / 设计缺陷 / **能力缺陷** → `RETRAIN_REQUIRED` + `capability_gaps[]`。🔴 协议已定义在 `qa-judge/agent.md:223-333`，但没有程序化调用入口） -2. 触发 **L4-company**（[27-E2E](./27-e2e-task-execution-flow.md) §八）：**只迭代 `code-coder` 在 auto-illust 这家公司的记忆分区**（`companies/auto-illust/`），自动进行、无需人工确认——因为爆炸半径就限制在这一家公司内，改坏了也波及不到别人。 -3. 回到 L1 重跑 → 再到 code-validator 验证 +2. 触发 **L4-company**（[27-E2E](./27-e2e-task-execution-flow.md) §八）：**只迭代 `org-coder` 在 auto-illust 这家公司的记忆分区**（`companies/auto-illust/`），自动进行、无需人工确认——因为爆炸半径就限制在这一家公司内，改坏了也波及不到别人。 +3. 回到 L1 重跑 → 再到 org-validator 验证 -**注意这里不会碰 `coder` 的 general 本体**。如果这次失败暴露的是 `code-coder` 通用能力上的短板（不只是本公司场景特有的），那属于 **L4-general**：它不在任务循环里发生，而是等当日的 **agent dream 流程**——由 master agent 或人工触发，汇总当天所有公司的成功/失败经验，统一蒸馏一次 general 本体，走 git 版本化以便回滚。这个拆分保证了"为修一个任务而改坏十家公司共用 agent"这件事在架构上不可能发生。 +**注意这里不会碰 `coder` 的 general 本体**。如果这次失败暴露的是 `org-coder` 通用能力上的短板（不只是本公司场景特有的），那属于 **L4-general**：它不在任务循环里发生，而是等当日的 **agent dream 流程**——由 master agent 或人工触发，汇总当天所有公司的成功/失败经验，统一蒸馏一次 general 本体，走 git 版本化以便回滚。这个拆分保证了"为修一个任务而改坏十家公司共用 agent"这件事在架构上不可能发生。 **⚠️ 这里就是 §7.1 说的熔断失效风险**：L4 迭代完之后如果 L1/L2 的计数器重置，"迭代 agent → 重跑 → 再迭代"可以永远循环。所以必须有一个**跨层级共享、只增不减的任务级总预算**： @@ -231,10 +231,10 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ── |---|---| | orggraph-planning + 招 5 个角色（其中 2 个走培养流水线） | ~8 | | Level 0 任务图规划 | 1 | -| code-planner：workgraph-planning 1 + brd/prd/sdd-planning 3 + 验收 2 + code-planner-validator 1 + loop-validator 1 | 8 | -| code-coder：workgraph-planning 1 + 3 unit ×(code+test) 6 + 1.5 次重试 ~4 + integrate 1 + int-test 1 + judge 1 | ~14 | +| org-planner：workgraph-planning 1 + brd/prd/sdd-planning 3 + 验收 2 + planner-validator 1 + loop-validator 1 | 8 | +| org-coder：workgraph-planning 1 + 3 unit ×(code+test) 6 + 1.5 次重试 ~4 + integrate 1 + int-test 1 + judge 1 | ~14 | | L2 一轮修复（triage + 改 SDD + reset 后重跑 2 unit） | ~7 | -| code-validator + L4 一次迭代 | ~6 | +| org-validator + L4 一次迭代 | ~6 | | **合计** | **~44 次** | 粗估 **$8-15、墙钟 40-90 分钟**（并行后）。这个量级下，"自动模式一键跑到底"必须在启动前把预估成本告诉用户。 @@ -248,7 +248,7 @@ brd-planning → prd-planning → sdd-planning ─┬→ goal-test-data ── | # | 断点 | 出现阶段 | 对应设计 | |---|---|---|---| | 1 | `qa-judge` 没有程序化调用入口（判决无法驱动任何自动动作） | 5, 6, 7 | [27-E2E](./27-e2e-task-execution-flow.md) §11.3 | -| 2 | code-validator 节点的验收执行能力（跑 test_script / 喂 test_data）未实现 | 5, 7 | §11.3 | +| 2 | org-validator 节点的验收执行能力（跑 test_script / 喂 test_data）未实现 | 5, 7 | §11.3 | | 3 | 「用户 → 公司」任务入口不存在 | 3 | §三 阶段 3 | | 4 | **P2 的 org graph 边模型需从 `reports_to` 改为 `success`/`fail` 执行流边** | 2, 4 | §五定案 + [27-P2](./27-p2-org-graph.md) v0.4 修正 | | 5 | fan-out 并行撞 CONVENTIONS §12 不变量 + SessionPool key 复用 | 5, 6 | §7.4 | diff --git a/docs/todo/system-design/27-graph-agent-architecture.md b/docs/todo/system-design/27-graph-agent-architecture.md index a089efa..5a5067a 100644 --- a/docs/todo/system-design/27-graph-agent-architecture.md +++ b/docs/todo/system-design/27-graph-agent-architecture.md @@ -60,7 +60,7 @@ │ Company: {companyId} │ │ │ │ Org Graph（company 级 workflow，建公司时生成）│ - │ [code-planner] --success--> [code-coder] │ + │ [org-planner] --success--> [org-coder] │ │ ↑ │ │ │ └──── fail(backward) ───┘ │ │ │ diff --git a/docs/todo/system-design/27-naming-conventions.md b/docs/todo/system-design/27-naming-conventions.md index b07de68..5d8d24c 100644 --- a/docs/todo/system-design/27-naming-conventions.md +++ b/docs/todo/system-design/27-naming-conventions.md @@ -46,20 +46,71 @@ --- -## 三、Org node agent —— `{domain}-{职能}` +## 三、图节点 agent —— 按**所在图的层级**命名（R-15.3 定案） -org graph 上的节点 agent，一律带领域前缀： +命名轴是**节点在哪一层图里**，不是它属于哪个业务领域。 -| id | 职责 | -|---|---| -| `code-planner` | 开发领域：规划阶段的 org node | -| `code-coder` | 开发领域：实现阶段的 org node | -| `code-validator` | 开发领域：验收阶段的 org node | -| `content-planner` / `content-writer` / `content-validator` | 内容领域的同构三段 | +### 3.1 两层节点名 + +| 层级 | 节点名规则 | 例 | +|---|---|---| +| **Org Graph 节点** | `org-{职能}` | `org-planner` / `org-coder` / `org-validator` / `org-innovator` | +| **Work Graph 节点** | `{父 org 节点全名}-{职能}` | `org-coder-validator` / `org-planner-validator` | -**不允许**裸用 `planner` / `coder` / `validator` —— 它们必须能被一眼看出属于哪个领域，否则跨领域公司（既做开发又做内容）会立刻撞名。 +三个 org-graph 模板因此首尾同名，只有中段职能不同——差异在于**中间做什么**，规划和验收本身不分领域： ---- +``` +dev.json org-planner → org-coder → org-validator +content.json org-planner → org-writer → org-validator +ops.json org-planner → org-monitor → org-validator +``` + +**为什么不按业务领域**（v0.2 曾定为 `code-planner` / `content-planner`，已作废）：一家公司的 org graph 只有一套节点，领域信息由 company 本身承载。同一个 `org-planner` 服务开发型还是内容型公司，靠 [27-E2E](./27-e2e-task-execution-flow.md) §八bis 的**元 agent 继承 + 公司/角色记忆分区**区分行为。按领域命名会让 agent 池随「领域数 × 职能数」膨胀，同一种能力无法跨领域复用经验。 + +### 3.2 节点名 ≠ 本体名（R-15.3 新增的命名轴） + +**这是本规范此前完全缺失的一条轴**，不区分会直接导致 agent 本体被无谓复制： + +| | 例 | 带前缀？ | +|---|---|---| +| **system agent 本体** | `planner-validator` / `coder-validator` / `org-validator` | ❌ 不带 | +| **org graph 节点** | `org-planner` / `org-coder` / `org-validator` | ✅ 带 `org-` | +| **work graph 节点** | `org-coder-validator` / `org-planner-validator` | ✅ 带父节点全名 | + +落到 schema 上就是两个字段（[27-P3/P4](./27-p3-p4-work-graph-console.md) §四.A）：`node_name` 存节点名（图内唯一），`system_agent_id` 存本体名（跨图复用）。 + +**为什么本体不带前缀**：禁止裸用 `validator` 的理由是「一家公司内两个节点不能重名」——该理由针对**节点**，不针对**本体**。本体若被迫带领域前缀，`coder-validator` 会复制成 `org-coder-validator` / `content-coder-validator` 多份，与 [27-P1](./27-p1-virtual-reference.md)「同一份本体、多处引用、各自私有语境」直接冲突。 + +### 3.3 三个 validator 是三个独立本体 + +`planner-validator` / `coder-validator` / `org-validator` 验的东西本质不同——规划产物 / 代码 / 整个任务达成，是**不同能力**，不是同一能力的不同语境。§八bis 的「不特化」原则针对的是同一能力在不同 org node 下，与本条不冲突。 + +两级验收的分工： + +| | 节点名 | 验什么 | 失败退到哪 | +|---|---|---|---| +| **org 层** | `org-validator` | 整个任务达成了吗 | 退回某个 org node，**整张 work graph 重跑** | +| **work 层** | `org-{X}-validator` | 这个 org node 自己的产出合格吗 | 退回本张 work graph 内的某个节点 | + +`org-validator` 本身是一个 org node，按定义有自己的 work graph，`benchmark-validator` / `testdata-validator` 就是这张 work graph 的节点——落在已有的递归模型里，引擎不加分支。 + +### 3.4 存量 system agent 的归位 + +按同一规则把散落的老 agent 归到它实际所处的层级： + +| 旧名 | 新名 | 依据 | +|---|---|---| +| `innovator` | **`org-innovator`** | `type='cxo'`，是 org graph 层的节点 | +| `hunter` | **`innovator-hunt`** | `retrain-pipeline.js:161`，innovator work graph 第 1 阶段 | +| `digester` | **`innovator-digest`** | 同上第 2 阶段（行 179，输入是 hunter 产出） | +| `evolver` | **`innovator-evolver`** | 同上第 3 阶段（行 196）；行 231 明写 `steps: ['re_hunt','re_digest','evolve']` | + +**这顺带解决了 6 个命名冲突 id**（27 号文档 §七）——重命名后 `system/agents/` 与 `system/templates/` 下不再有同名目录。剩两个单独判断： + +- `agent-creator`：与 `orggraph-planning` 同属**基础设施角色**，不是任何图上的节点，不加前缀，保持原名。 +- `evolver-youtube-crawler`：针对单个 skill 特化的 evolver 实例，按规则应为 `innovator-evolver-youtube-crawler`，名字过长且疑似一次性产物，**待定**，暂不改名。 + +> ⚠️ §3.4 的四个重命名**尚未落到代码**，需要一次迁移（目录改名 + `system_agents` 表 + `retrain-pipeline.js` 等引用点）。§3.1-3.3 的新命名已应用于文档与 `system/org-graph-templates/`。 ## 四、验收产物 —— `goal-{类型}` @@ -208,10 +259,14 @@ task_id TEXT, -- 形如 'T-xxx'，system/tasklog/{taskId}.json | 不要用 | 要用 | |---|---| -| `planner` | `code-planner` / `content-planner` / … | -| `validator` | `code-validator` / `content-validator` / … | +| `planner` | `org-planner`（节点）| +| `validator` | 节点：`org-validator` / `org-{X}-validator`；本体：`org-validator` / `{X}-validator` | | `planning` | `orggraph-planning` / `workgraph-planning` / `brd-planning` / `prd-planning` / `sdd-planning` | | `org-graph-creator` | `orggraph-planning` | +| `innovator` | `org-innovator` | +| `hunter` | `innovator-hunt` | +| `digester` | `innovator-digest` | +| `evolver` | `innovator-evolver` | | `benchmark`（裸用） | `skill-benchmark` / `agent-benchmark` / `goal-benchmark` | | `test-data` / `test-script`（裸用） | `goal-test-data` / `goal-test-script` | | `goal` / `goals`（指 OKR 体系时） | `okr` | diff --git a/docs/todo/system-design/27-p2-org-graph.md b/docs/todo/system-design/27-p2-org-graph.md index 5b08b9d..4d556d5 100644 --- a/docs/todo/system-design/27-p2-org-graph.md +++ b/docs/todo/system-design/27-p2-org-graph.md @@ -23,7 +23,7 @@ v0.1-v0.3 把 Org Graph 建模为**静态汇报结构**：节点是角色引用 |---|---|---| | 生成者 | `orggraph-planning` agent | `workgraph-planning` agent | | 生成时机 | 建公司时，一次 | 每个 org node 接到任务时 | -| 节点指向 | org node agent（`code-planner` 等） | system agent 引用 | +| 节点指向 | org node agent（`org-planner` 等） | system agent 引用 | | 边的语义 | **执行流**：`condition ∈ {success, fail}` | **执行流**：同左 | | 执行引擎 | [27-P3/P4](./27-p3-p4-work-graph-console.md) 的同一套 | 同左 | @@ -146,9 +146,9 @@ v0.2/v0.3 设计的 `hire(companyId, roleName, {reportsTo})` **不再需要**。 ```jsonc { "nodes": [ - { "id": 12, "roleName": "code-planner", "systemAgentId": "code-planner", "status": "active" }, - { "id": 13, "roleName": "code-coder", "systemAgentId": "code-coder", "status": "active" }, - { "id": 14, "roleName": "code-validator", "systemAgentId": "code-validator", "status": "active" } + { "id": 12, "roleName": "org-planner", "systemAgentId": "org-planner", "status": "active" }, + { "id": 13, "roleName": "org-coder", "systemAgentId": "org-coder", "status": "active" }, + { "id": 14, "roleName": "org-validator", "systemAgentId": "org-validator", "status": "active" } ], "edges": [ { "from": 12, "to": 13, "condition": "success", "edgeKind": "forward" }, @@ -185,7 +185,7 @@ if (bootstrap.status === 'hired_from_template') { **不自己写渲染逻辑** —— org graph 与 work graph 同构，直接复用 [27-P3/P4](./27-p3-p4-work-graph-console.md) T3 的画布组件（其本身又是扩展自既有的 `web/src/components/devloop/UnitsDAG.vue`，已实现 SVG + Kahn 分波布局 + 状态着色 + 点击下钻）。 -这也意味着 **P2 的前端工作依赖 P3 的画布组件先做出来**。若想让 P2 独立上线，可以先在 Company Dashboard 用一个纯文本的拓扑序列表占位（`code-planner → code-coder → code-validator`），等 P3 画布就绪再替换。 +这也意味着 **P2 的前端工作依赖 P3 的画布组件先做出来**。若想让 P2 独立上线，可以先在 Company Dashboard 用一个纯文本的拓扑序列表占位（`org-planner → org-coder → org-validator`），等 P3 画布就绪再替换。 ### 4.6 `system/org-graph-templates/` @@ -197,16 +197,16 @@ if (bootstrap.status === 'hired_from_template') { "id": "dev", "label": "开发型公司", "whenToUse": "目标包含实现某个产品/功能、需要跑代码开发-测试循环时优先参考", - "nodes": ["code-planner", "code-coder", "code-validator"], + "nodes": ["org-planner", "org-coder", "org-validator"], "edges": [ - { "from": "code-planner", "to": "code-coder", "condition": "success" }, - { "from": "code-coder", "to": "code-validator", "condition": "success" }, - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edgeKind": "backward" } + { "from": "org-planner", "to": "org-coder", "condition": "success" }, + { "from": "org-coder", "to": "org-validator", "condition": "success" }, + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edgeKind": "backward" } ] } ``` -同理提供 `content.json`（`content-planner → content-writer → content-validator`）、`ops.json`。 +同理提供 `content.json`（`org-planner → org-writer → org-validator`）、`ops.json`。 设计要点： diff --git a/system/org-graph-templates/README.md b/system/org-graph-templates/README.md index df101a4..568f309 100644 --- a/system/org-graph-templates/README.md +++ b/system/org-graph-templates/README.md @@ -17,9 +17,9 @@ JSON 文件，**不改任何代码**。同样，模板里的角色名只是*建 | 文件 | id | 适用 | 节点链 | |---|---|---|---| -| `dev.json` | `dev` | 交付可运行代码 | `code-planner → code-coder → code-validator` | -| `content.json` | `content` | 交付给人读/看的内容 | `content-planner → content-writer → content-validator` | -| `ops.json` | `ops` | 让已有系统持续正常运转 | `ops-planner → ops-monitor → ops-validator` | +| `dev.json` | `dev` | 交付可运行代码 | `org-planner → org-coder → org-validator` | +| `content.json` | `content` | 交付给人读/看的内容 | `org-planner → org-writer → org-validator` | +| `ops.json` | `ops` | 让已有系统持续正常运转 | `org-planner → org-monitor → org-validator` | 三张图同构：**规划 → 执行 → 验收**，验收失败回退到执行节点重做。 @@ -30,10 +30,10 @@ JSON 文件，**不改任何代码**。同样，模板里的角色名只是*建 "id": "dev", // 必填，与文件名同名（不含 .json） "label": "开发型公司", // 必填，给人看的中文名 "whenToUse": "……", // 必填，LLM 选型的唯一依据，写清楚适用场景 + 典型信号词 + 与其他模板的区别 - "nodes": ["code-planner", "code-coder", "code-validator"], + "nodes": ["org-planner", "org-coder", "org-validator"], "edges": [ - { "from": "code-planner", "to": "code-coder", "condition": "success" }, - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edgeKind": "backward" } + { "from": "org-planner", "to": "org-coder", "condition": "success" }, + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edgeKind": "backward" } ] } ``` diff --git a/system/org-graph-templates/content.json b/system/org-graph-templates/content.json index 34b45ae..42e1ecc 100644 --- a/system/org-graph-templates/content.json +++ b/system/org-graph-templates/content.json @@ -1,11 +1,11 @@ { "id": "content", "label": "内容型公司", - "whenToUse": "公司目标（company-goal）指向「持续产出面向人阅读/观看的内容」，交付物是文章、脚本、文案、视频稿、报告，验收方式是人（或 validator agent）按选题契合度、事实准确性、风格一致性打分时，优先参考本模板。典型信号词：写作、选题、公众号/小红书/YouTube、文案、剧本、翻译、周报。注意与 dev 的区别：这里没有「跑一遍就知道对不对」的自动化验收，因此 content-validator 的 fail 回退边尤其重要，改稿循环是常态。", - "nodes": ["content-planner", "content-writer", "content-validator"], + "whenToUse": "公司目标（company-goal）指向「持续产出面向人阅读/观看的内容」，交付物是文章、脚本、文案、视频稿、报告，验收方式是人（或 validator agent）按选题契合度、事实准确性、风格一致性打分时，优先参考本模板。典型信号词：写作、选题、公众号/小红书/YouTube、文案、剧本、翻译、周报。注意与 dev 的区别：这里没有「跑一遍就知道对不对」的自动化验收，因此 org-validator 的 fail 回退边尤其重要，改稿循环是常态。", + "nodes": ["org-planner", "org-writer", "org-validator"], "edges": [ - { "from": "content-planner", "to": "content-writer", "condition": "success" }, - { "from": "content-writer", "to": "content-validator", "condition": "success" }, - { "from": "content-validator", "to": "content-writer", "condition": "fail", "edgeKind": "backward" } + { "from": "org-planner", "to": "org-writer", "condition": "success" }, + { "from": "org-writer", "to": "org-validator", "condition": "success" }, + { "from": "org-validator", "to": "org-writer", "condition": "fail", "edgeKind": "backward" } ] } diff --git a/system/org-graph-templates/dev.json b/system/org-graph-templates/dev.json index 4db129c..2e66a83 100644 --- a/system/org-graph-templates/dev.json +++ b/system/org-graph-templates/dev.json @@ -1,11 +1,11 @@ { "id": "dev", "label": "开发型公司", - "whenToUse": "公司目标（company-goal）指向「做出/改进一个软件产品、功能、脚本、API、工具」，交付物是可运行的代码，验收方式是跑测试或跑起来看结果时，优先参考本模板。典型信号词：实现、开发、重构、修 bug、写接口、上线某个功能、做一个 App/网站/CLI。若公司同时还要产出内容或做运维，本模板可与 content.json / ops.json 组合，把本图作为主干、另一张图接在 code-validator 之后。", - "nodes": ["code-planner", "code-coder", "code-validator"], + "whenToUse": "公司目标（company-goal）指向「做出/改进一个软件产品、功能、脚本、API、工具」，交付物是可运行的代码，验收方式是跑测试或跑起来看结果时，优先参考本模板。典型信号词：实现、开发、重构、修 bug、写接口、上线某个功能、做一个 App/网站/CLI。若公司同时还要产出内容或做运维，本模板可与 content.json / ops.json 组合，把本图作为主干、另一张图接在 org-validator 之后。", + "nodes": ["org-planner", "org-coder", "org-validator"], "edges": [ - { "from": "code-planner", "to": "code-coder", "condition": "success" }, - { "from": "code-coder", "to": "code-validator", "condition": "success" }, - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edgeKind": "backward" } + { "from": "org-planner", "to": "org-coder", "condition": "success" }, + { "from": "org-coder", "to": "org-validator", "condition": "success" }, + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edgeKind": "backward" } ] } diff --git a/system/org-graph-templates/ops.json b/system/org-graph-templates/ops.json index f1d1001..3b11e87 100644 --- a/system/org-graph-templates/ops.json +++ b/system/org-graph-templates/ops.json @@ -1,11 +1,11 @@ { "id": "ops", "label": "运维型公司", - "whenToUse": "公司目标（company-goal）指向「让一个已经存在的系统/流程持续正常运转」，交付物不是新造物而是一次处置动作 + 一份现状证据，验收方式是核对指标是否回到阈值内时，优先参考本模板。典型信号词：监控、值班、巡检、告警、故障处理、数据同步、定时任务、成本治理、SLO/可用性。与 dev 的区别：dev 的循环是「写了再测」，ops 的循环是「动了再观察」——ops-monitor 既执行处置也采集处置后的真实指标，ops-validator 判断指标是否达标，不达标则打回 ops-monitor 换一种处置继续观察。", - "nodes": ["ops-planner", "ops-monitor", "ops-validator"], + "whenToUse": "公司目标（company-goal）指向「让一个已经存在的系统/流程持续正常运转」，交付物不是新造物而是一次处置动作 + 一份现状证据，验收方式是核对指标是否回到阈值内时，优先参考本模板。典型信号词：监控、值班、巡检、告警、故障处理、数据同步、定时任务、成本治理、SLO/可用性。与 dev 的区别：dev 的循环是「写了再测」，ops 的循环是「动了再观察」——org-monitor 既执行处置也采集处置后的真实指标，org-validator 判断指标是否达标，不达标则打回 org-monitor 换一种处置继续观察。", + "nodes": ["org-planner", "org-monitor", "org-validator"], "edges": [ - { "from": "ops-planner", "to": "ops-monitor", "condition": "success" }, - { "from": "ops-monitor", "to": "ops-validator", "condition": "success" }, - { "from": "ops-validator", "to": "ops-monitor", "condition": "fail", "edgeKind": "backward" } + { "from": "org-planner", "to": "org-monitor", "condition": "success" }, + { "from": "org-monitor", "to": "org-validator", "condition": "success" }, + { "from": "org-validator", "to": "org-monitor", "condition": "fail", "edgeKind": "backward" } ] } diff --git a/system/templates/orggraph-planning/agent.md b/system/templates/orggraph-planning/agent.md index 39906ad..e39a1e2 100644 --- a/system/templates/orggraph-planning/agent.md +++ b/system/templates/orggraph-planning/agent.md @@ -37,7 +37,7 @@ | 字段 | 含义 | 你怎么用 | |---|---|---| | **`goal`（company-goal）** | 这家公司**要达成什么** | **规划的主依据**。图的形状由它决定 | -| `description` | 这家公司**是干什么的** | 背景信息，用来消歧和定领域前缀 | +| `description` | 这家公司**是干什么的** | 背景信息，用来消歧、决定中段执行节点的职能 | 两者不是一回事，别混。`goal` 是「三个月内做出一个能跑的短视频自动剪辑工具」， `description` 是「一家做 AI 视频工具的公司」——**前者定图，后者定语气**。 @@ -81,8 +81,8 @@ node bin/lemon.js company templates 你**被明确允许**： - **裁剪**：模板三个节点，这家公司只需要两个 → 砍掉一个 -- **替换**：`code-coder` 换成更贴合的既有模板角色 -- **组合**：既做开发又做内容 → 以 dev 为主干，把 content 的链接在 `code-validator` 之后 +- **替换**：`org-coder` 换成更贴合的既有模板角色 +- **组合**：既做开发又做内容 → 以 dev 为主干，把 content 的链接在 `org-validator` 之后 - **新造**：判断需要一个模板库里根本没有的角色 → 直接写进图里（Step 7 会自动建它） 你**不被允许**： @@ -94,7 +94,7 @@ node bin/lemon.js company templates **图的基本形状**（三份模板都是这个同构骨架，你的图通常也应该是它的变形）： ``` -{domain}-planner --success--> {domain}-{执行} --success--> {domain}-validator +org-planner --success--> org-{执行职能} --success--> org-validator ^ | +---------- fail --------------+ (edgeKind: backward) @@ -171,21 +171,21 @@ curl -s -X POST http://localhost:3010/api/company/<公司ID>/org-graph \ ```jsonc { "nodes": [ - { "roleName": "code-planner", "systemAgentId": "code-planner" }, - { "roleName": "code-coder", "systemAgentId": "code-coder" }, - { "roleName": "code-validator", "systemAgentId": "code-validator" } + { "roleName": "org-planner", "systemAgentId": "org-planner" }, + { "roleName": "org-coder", "systemAgentId": "org-coder" }, + { "roleName": "org-validator", "systemAgentId": "org-validator" } ], "edges": [ - { "from": "code-planner", "to": "code-coder", "condition": "success" }, - { "from": "code-coder", "to": "code-validator", "condition": "success" }, - { "from": "code-validator", "to": "code-coder", "condition": "fail", "edgeKind": "backward" } + { "from": "org-planner", "to": "org-coder", "condition": "success" }, + { "from": "org-coder", "to": "org-validator", "condition": "success" }, + { "from": "org-validator", "to": "org-coder", "condition": "fail", "edgeKind": "backward" } ] } ``` - `systemAgentId` 可省略，省略时默认等于 `roleName`。 - `edgeKind` 省略时默认 `forward`。 -- 节点也可以直接写成字符串 `"code-coder"`，等价于 `{roleName:"code-coder"}`。 +- 节点也可以直接写成字符串 `"org-coder"`，等价于 `{roleName:"org-coder"}`。 #### ⚠️ 返回 400 怎么办：读懂 errors，自己修，重试 @@ -222,9 +222,9 @@ curl -s http://localhost:3010/api/company/<公司ID>/org-graph 顺序重要——它让 `data/companies/<公司ID>/agents/` 的创建顺序与执行顺序一致，便于排查。 ```bash -node bin/lemon.js company hire --id <公司ID> --role code-planner --type executor --name "研发规划" -node bin/lemon.js company hire --id <公司ID> --role code-coder --type executor --name "研发实现" -node bin/lemon.js company hire --id <公司ID> --role code-validator --type executor --name "研发验收" +node bin/lemon.js company hire --id <公司ID> --role org-planner --type executor --name "研发规划" +node bin/lemon.js company hire --id <公司ID> --role org-coder --type executor --name "研发实现" +node bin/lemon.js company hire --id <公司ID> --role org-validator --type executor --name "研发验收" ``` 每条命令的返回都要看： @@ -295,9 +295,9 @@ curl -s -X PUT http://localhost:3010/api/company/<公司ID>/agents/orggraph-plan | ❌ 不要用 | ✅ 要用 | |---|---| -| `planner` | `code-planner` / `content-planner` / `ops-planner` | -| `validator` | `code-validator` / `content-validator` | -| `writer` | `content-writer` | +| `planner` | `org-planner` / `org-planner` / `org-planner` | +| `validator` | `org-validator` / `org-validator` | +| `writer` | `org-writer` | 新领域自己起前缀（`design-` / `sales-` / `data-` / `growth-`…），前缀用**小写英文单词**， 整个 id 只允许小写字母、数字和连字符。 diff --git a/system/templates/orggraph-planning/tools.md b/system/templates/orggraph-planning/tools.md index 1f6955b..c08a71f 100644 --- a/system/templates/orggraph-planning/tools.md +++ b/system/templates/orggraph-planning/tools.md @@ -40,10 +40,10 @@ node bin/lemon.js company templates **先写文件**（用文件写入工具写 `/tmp/orggraph-<公司ID>.json`，单行紧凑 JSON）： ```jsonc -{"nodes":[{"roleName":"code-planner"},{"roleName":"code-coder"},{"roleName":"code-validator"}], - "edges":[{"from":"code-planner","to":"code-coder","condition":"success"}, - {"from":"code-coder","to":"code-validator","condition":"success"}, - {"from":"code-validator","to":"code-coder","condition":"fail","edgeKind":"backward"}]} +{"nodes":[{"roleName":"org-planner"},{"roleName":"org-coder"},{"roleName":"org-validator"}], + "edges":[{"from":"org-planner","to":"org-coder","condition":"success"}, + {"from":"org-coder","to":"org-validator","condition":"success"}, + {"from":"org-validator","to":"org-coder","condition":"fail","edgeKind":"backward"}]} ``` **再发送**： @@ -58,7 +58,7 @@ curl -s -X POST http://localhost:3010/api/company/<公司ID>/org-graph \ | 字段 | 说明 | |---|---| -| `nodes[].roleName` | 必填，角色名，同一公司内唯一。也可直接写成字符串 `"code-coder"` | +| `nodes[].roleName` | 必填，角色名，同一公司内唯一。也可直接写成字符串 `"org-coder"` | | `nodes[].systemAgentId` | 可省略，省略时默认等于 `roleName` | | `edges[].from` / `to` | **用角色名**，不是数字 id（图还没落库，你手里没有 id） | | `edges[].condition` | `"success"` \| `"fail"`，必填 |