27-REQ · 原始需求
所属: 27 Graph Agent 架构 的需求源头文档。 版本: v0.1 日期: 2026-08-15 定位: 用户提出的需求原话照搬，再做结构化解析。本页是 27 系列所有设计决策的「源头」。 格式与定位对齐仓库既有惯例
docs/prd/newfunction/_spec/requirement.md（DevLoop 的原始需求页）。
为什么需要这一页
27 系列其余文档（E2E / P2 / P3-P4 / EXAMPLE / NAMING）全部是对下面这些原话的转述与结构化解读，包括 27-example-dev-company-walkthrough.md 里那个「配图工厂」场景——那是为了走查而虚构的例子，不是用户给的。
转述会漂移。当出现「当初到底是怎么说的」这类争议、或者需要判断某个设计决策是不是过度解读时，以本页为准。
照搬原则：原文一字不改，含笔误（validtor / syste agent / intergration / fin in / object-key result 等）与不完整的句子，一律保留。笔误本身有时是理解意图的线索。
R-1 · 起点：P2 对 P1 的依赖排查
你看一下todo 的 需求文档，p2 的部分有多少依赖于 p1 的实现
落点：无独立文档，结论并入 27-P2 §九。
R-2 · 要一份 P2 详细设计
那你现在写一个新的 p2 的需求设计文档，来对 p2 的需求进行详细设计，任务划分
落点：27-P2（初版 v0.1，后经 R-3 / R-10 两次重写）
R-3 · Org Graph 由第一个 agent 动态生成
org graph 生成，应该由 company 的第一个 agent： org graph creator agent 来实现，根据这个公司的目标，描述，类型，来生成，比如要生成开发，还是运营，还是内容生成，会有多个不同的 org graph的模板，然后根据需求+agent list 动态来生成 org graph
落点：27-P2 §4.1（orggraph-planning agent）、§4.6（system/org-graph-templates/）
后续变更：其中 org graph creator 这个名字在 R-10 的命名统一中改为 orggraph-planning。
R-4 · 要一个执行控制台页面
我们需要一个新的页面，展示公司的 org graph 和每一个 org node 运行的 work graph，这个需求也需要设计一下，这个界面还需要设计一下 MVCP，数据库设计，界面设计，有启动，下一步，暂停，停止，重试这样的操作按钮，还需要展示每一个节点的运行日志，边的输入输出，loop 的划线，这些展示，还有主流程如何处理，异常流程如何处理，下钻的 sub agent 的流程如何处理和展示。
落点：27-P3/P4 全文（§四 按 MVCP 四象限组织）
关键澄清：此处的 "MVCP" 经确认是 Model-View-Control-Process，即仓库既有 SDD 的四象限文档格式（docs/prd/newfunction/_spec/sdd-{model,view,control,process}.md），不是 MVP（最小可行范围）。
R-5 · 手动 / 自动两种执行模式
对，而且运行有自动化和手动化两个选择，如果是手动，则 org graph，work graph 的执行是需要在界面上点击下一步下一步来完成，如果是自动则是授权自动从头到尾自动执行，一个节点完成则自动跳转到下一个节点执行
落点：27-P3/P4 §四.C（execution_mode ∈ {manual, auto}，两者共用同一个 advanceOne() 原语，区别只在谁触发下一次调用）
R-6 · 完整的七阶段流程（核心需求）
我说一下我理解的 process， 1， 用户新建一个 company 写入 company 的目标和描述2. company 默认有一个 org graph creator，根据用户描述，生成基础的 org graph，每一个 org graph node 可以从 system agent 中引用实现，也可以新建一个 system agent 来实现，比如开发 company，需要有 planner，code，validator 三个基础的 org graph 3. 用户输入一个具体的开发task， 4. org planner agent 作为执行 orggraph 的第一个节点，首先调用 planning work graph subagent，来规划执行 planning work graph 的这个任务，生成针对 planner agent 这个节点的 work graph，比如 brd->prd->sdd->benchmark->testdata->planner validtor->judge-loop-jump 来完成开发的第一个阶段需求planner的工作，这里面的每一个 work graph 节点都是一个 system agent 的引用，并且完成第一个 loop 闭环的跳转，如果成功则完成，如果有 bug 则跳转到对应的节点，让其只针对某一个部分开始修改。5 完成当前 org graph 节点工作，进入下一个 code graph node agent 的工作 6 code agent 也需要先调用 planning-work graph subagent 来设计 code work graph，可能是可以 fan out 并行多个 phase 的 code subagent->unit test 的开发，如果 unittest 有问题则loop 到 code subagent 来持续修改，全部并行完成后 fin in 节点到一个整合，->intergration test 来完成测试，如果有 bug 则判断是重新 planning 一个新的 work graph ，还是跳转到原有某个 work graph 节点来完成 7 codeagent 完成则进入全局的 validetor agent 来进行整体的判断，测试，审计，benchmark 的测试，test data 的测试等等，成功后完成，不成功则需要判断为什么会报错，是不是需要迭代某一个 syste agent 的 skill memory data llm 才能完成，先迭代 system agent ，再 loop 某个 work graph workflow ，再跑到 validator 验证，直至最后满足这个任务的 benchmark 或者 test data。 这个流程你整理成为一个文档，并且跟我们的 p2 设计比较，更新文档。 还有哪些没有考虑到的地方，这个流程是否是这样实现的？
落点：27-E2E 全文（§三 七阶段逐段还原、§四 与既有设计的差异、§七 未考虑到的地方）
由此产生的三条核心结论（27-E2E §二）：
- 这套流程 70-80% 已在
docs/prd/newfunction/_spec/被完整设计过（DevLoop 的 L1/L2/L3） - DevLoop 是这套架构的一个硬编码实例
- 第七步「迭代 system agent」是真正全新的一层（后定名 L4）
R-7 · 更正：benchmark / test data 是 work graph 的节点，不是基础设施
我描述的 benchmark 和 test data 是 workgraph 的两个 subagent 节点，例如在code planner agent，他的 work graph里包含了要规划当前 goal task 的 benchmark 或者 test data 或者 test script 来完成最终对这个 goal 的验收，所以 work graph 里 就需要调用 code-planner-benchmark code-planner-test-data code-planner-test-script 这三个 system agent ，动态选择是否需要在 work graph 中加入这三个节点，还是只需要其中某一个，来完成 code planner。
落点：27-E2E §十一（验收产出节点设计）
这条更正推翻了什么：此前我把 benchmark / test data 理解成系统级基础设施，因而去核实 benchmark-runner.js 并判定「是假的、test data 不存在」。该判断与本需求无关——本流程根本不使用 benchmark-runner.js。
后续变更：文中的 code-planner-benchmark / code-planner-test-data / code-planner-test-script 三个名字，经 R-10 与 R-12 两轮，最终定为 goal-benchmark / goal-test-data / goal-test-script（作用域从"父 org node"改为"goal"）。
R-8 · 是否需要独立的 example 文档
是否将我的描述的这个用户流程，更新迭代在文档里，并且作为一个 example 文档？
落点：27-EXAMPLE ⚠️ 注意：该文档用的是虚构的「配图工厂」场景，不是本页 R-6 的原文。R-6 的原文只在本页。
R-9 · 四个关键决策（回答确认问题）
以下四条是针对具体设计分叉的定案回答，逐条照搬。
R-9.1 · Org Graph 的定位（最大的架构分叉）
org graph 是由 company 级别生成的 workflow ，work graph 是由 org graph node 级别生成的 workflow 我不知道这个解释清楚了么？
落点：27-E2E §五定案、27-P2 v0.4 §一、27 号总纲 v0.3 §二术语表 + §3.3
推翻了什么：P2 v0.1-v0.3 把 Org Graph 建模为静态汇报结构（边是 reports_to / collaborates_with），以及我提出的 A/B/C 三个折中方案，全部作废。新模型下两层图同构，共用一套 schema、引擎与 UI。
R-9.2 · 元 Agent 继承
我们所有的org graph work graph 的 subagent 的 node agent，都是由一个元 agent 架构来继承生成的，统一有全局通用+公司/角色记忆分区
落点：27-E2E §八bis
关联发现：元 agent 在仓库里已有实物 —— system/templates/base/（"标准基座员工 Base Agent"），已强制 RESEARCH → PLAN → EXECUTE → VERIFY 四段式 + 阶段间 context flush + 换装元技能 + 失败写 _lessons.md 打回上一阶段。它本身就是一个最小 work graph。
R-9.3 · 验收产物由谁生成、由谁执行
验收产物在 org graph 中是由 planner 生成，由 validator 执行，每一个 node agent 的 benchmark 是由自身的 work graph 的 validator/test script/test benchmark/test script /节点来运行,
落点：27-E2E §11.3
要点：验收是逐层递归的——不是最外层一次总检，每一层图收尾都跑自己那层的验收；且执行由 agent 节点承担，不由引擎硬编码。
R-9.4 · L4 拆成 company / general 两条通道
迭代 system agent 本体，也是分为 company 还是 general 的部分，company 的部分在运行过程中就需要自动迭代，general 的部分需要 system agent 的管理者 master agent 或者人工来驱动执行，比如每日定时或者手工执行agent dream流程来自我更新，根据今天所有的 company 执行的成功 失败 经验，来更新 general 的本体部分
落点：27-E2E §八（L4-company / L4-general 对照表）、§8.1（agent dream 流程）
解决了什么：此前我提出的「为修一个任务而改坏十家公司共用 agent」这一跨公司污染风险（原 §7.2），以及我给的三个缓解方案（fork 副本 / 只改私有 / 人工确认），因这条分层而全部不再需要——在线自动迭代永远只碰 company 分区，general 本体的更新被移出任务循环。
R-10 · P2 重写 + 统一命名前缀
把 p2 文档按新的执行流边模型重写，仓库里的 benchmark 是 单 agent-benchmark 或者是 skill-benchmark ，给他们改个名字 ，我们这次聊的是goal-benchmark 或者 task-benchmark，我们在前面都统一加上前缀，包括 planner validator 也要加上 code-planner code-validator ，planning 是 workgraph-planning brd-planning，prd-planning orggraph-planning 这样起名，你可以统一排查一下
落点：27-P2 v0.4 全文重写、27-NAMING 全文
取舍过程：原话给了 goal- 与 task- 两个选项。我初次选了 task-，理由是"goal 已被 OKR 体系占用"；R-11 把 OKR 正名后该理由失效，我改用"验收标准跟着一次 task 执行走"作为理由继续保留 task-。这个理由在 R-12 被推翻，最终定为 goal-。
R-11 · OKR 正名
okr 树应该叫做 object-key result ，可以修改一下，不要叫做 goal 了
落点：27-NAMING §六
要点：体系整体从 goal 改为 okr；且当前第 1 层节点也叫 "Goal" 是一处自我遮蔽，建议正名为 Objective（O-001），成为标准的 Objective → Key Result → Sub-Task 三层。代码层已于 commit 74ea1ff 实施完毕（okr-service.js/routes/okr.js、/api/okr + 旧路径别名、scripts/migrate-goals-to-okr.js 迁移脚本、7 例单测）。
R-12 · 验收产物定名 goal-，并给出 goal 与 task 的层级区分
改回 goal-benchmark，因为 task 可能有很多个，task 是 sub agent 或者并行的层次，但是 goal 对于一个人类的需求描述只有一个，task 在 graph 中可能会有多个
落点：27-NAMING §四（含 goal / task / okr 三者的层级定义）
这条推翻了什么：推翻了 R-10 阶段"验收标准跟着一次 task 执行走"这个理由。关键区分是基数：
| 概念 | 基数 | 说明 |
|---|---|---|
| goal | 一个人类需求描述 = 1 个 | 验收的边界。"这次交付到底算不算满足了人的要求" |
| task | 一个 goal 分解出 N 个 | 图中的执行单元，可并行、可下钻 sub agent |
| okr | 跨多个 goal 的长周期度量树 | Objective / Key Result（见 R-11） |
验收标准回答的是"人类想要的东西做到了没有"，这是 goal 级的判定；task 只是达成它的执行分支，一个 goal 下有很多个，把验收挂在 task 上会导致"到底以哪个 task 的验收为准"无法回答。
R-13 · P2 需求审计中的四个定案
针对「P2 是否兑现原话」的逐条比对，四个分叉的定案回答，逐条照搬。
R-13.1 · goal 分三层
公司的目标是公司的 goal 叫做 company-goal ，任务的目标叫做 task-goal ，还有每一个子任务的目标叫做 subagent-goal，应该这么叫吧？
落点：27-NAMING §四「goal 是三层递归的」、27-P2 §4.1 第 1 步
澄清了什么：R-12 说的「一个人类需求描述只有一个 goal」，指的其实是三层里的 task-goal。三个验收 agent（goal-benchmark / goal-test-data / goal-test-script）保持通用，不按层级拆分——在哪一层调用就为那一层的 goal 产出标准，与 R-9.2 元 agent 继承一致。
后续变更（R-14）：subagent-goal 按执行者命名，与另两个的作用域命名轴不一致，已定名为 subtask-goal。上方原话保留提出时的用词，不随之改写。
R-13.2 · 公司类型由 agent 推断
完全由 orggraph-planning 推断
落点：27-P2 §4.6（模板是起点集合，不是代码里的 switch(type)）
推翻了什么：审计时我把「不给 company.json 加枚举 type 字段」记为「我擅自偏离了 R-3 原话（原话把类型列为输入）」。本条确认 LLM 推断正是所需，当前设计无需修改，那条自我记过的缺陷不成立。
R-13.3 · 新 agent 从元 agent 继承
从 base 元 agent 继承 + agent-creator 填内容，建成后可以手动或者根据 company 的需求设置自动innovator 培养训练
落点：27-P2 §4.1 第 7 步、§五 T5b
这是 R-9.2 在 P2 的落地点：模板不存在的角色，先从 system/templates/base/ 继承骨架（自动带上 RESEARCH → PLAN → EXECUTE → VERIFY 四段式），再由 agent-creator 填充角色定义——不是直接走现有的 needs_training 全量培养分支。训练是可选后置步骤，可手动触发或按公司需求配置自动。新建 agent 一律 scope='company'。
R-13.4 · org graph 强制单入口
强制单入口（推荐）
落点：27-P2 §3.3 第 2 条（原为 open question，现已定案）
R-14 · 命名轴统一为作用域
改成 subtask-goal
落点：27-NAMING §四
定案：三层 goal 一律按作用域命名 —— company-goal / task-goal / subtask-goal。R-13.1 提出时第三个叫 subagent-goal（按执行者命名，与另两个的轴不一致），本条统一。R-13.1 的原话引用保留提出时的用词，不随之改写。
附 · 需求 → 设计落点 速查
| 需求 | 一句话 | 主要落点 |
|---|---|---|
| R-3 | org graph 由第一个 agent 按公司描述动态生成 | P2 §4.1 / §4.6 |
| R-4 | 执行控制台页面（MVCP + 五个控制按钮 + 日志 + loop 划线 + 下钻） | P3/P4 全文 |
| R-5 | 手动 / 自动两种执行模式 | P3/P4 §四.C |
| R-6 | 七阶段端到端流程 | E2E §三 |
| R-7 | 验收产物是 work graph 的动态可选节点 | E2E §十一 |
| R-9.1 | org graph = company 级 workflow；work graph = org node 级 workflow | E2E §五 / P2 §一 / 总纲 §3.3 |
| R-9.2 | 所有 node agent 由元 agent 继承生成 | E2E §八bis |
| R-9.3 | 验收逐层递归，planner 生成、validator 执行 | E2E §11.3 |
| R-9.4 | L4 拆 company（自动）/ general（dream，人工或 master 驱动） | E2E §八 / §8.1 |
| R-10 | 统一命名前缀 | NAMING 全文 |
| R-11 | OKR 正名，不叫 goal | NAMING §六 |
| R-12 | 验收产物定名 goal-；goal 唯一、task 多个 |
NAMING §四 |
| R-13 | goal 三层；类型由 agent 推断；新 agent 从 base 继承；强制单入口 | NAMING §四 / P2 §3.3 §4.1 §五 |
| R-14 | 命名轴统一为作用域：subagent-goal → subtask-goal |
NAMING §四 |