Name Last Update
..
README.md Loading commit data...
content.json Loading commit data...
dev.json Loading commit data...
ops.json Loading commit data...

README.md

system/org-graph-templates/

Org Graph(公司级 workflow)的骨架模板库。

每个 *.json 是一种公司类型的执行流图起点。建公司时 orggraph-planning agent 会 ls 本目录、逐个读取、 对照各自的 whenToUse 选型,再结合公司目标(company-goal)与 node bin/lemon.js company templates 给出的可招角色清单,裁剪 / 替换 / 组合出这家公司真正的 org graph。

设计依据:docs/todo/system-design/27-p2-org-graph.md §4.6 命名规范:docs/todo/system-design/27-naming-conventions.md §三

这是起点集合,不是穷举枚举。 模板不是代码里的 switch(type)——加一种公司类型只需往本目录扔一个 JSON 文件,不改任何代码。同样,模板里的角色名只是建议,orggraph-planning 必须核实是否真有可招模板, 没有则走「从 system/templates/base/ 元 agent 继承 + agent-creator 填充」的分支。

当前模板

文件 id 适用 节点链
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

三张图同构:规划 → 执行 → 验收,验收失败回退到执行节点重做。

文件格式

{
  "id": "dev",                    // 必填,与文件名同名(不含 .json)
  "label": "开发型公司",           // 必填,给人看的中文名
  "whenToUse": "……",              // 必填,LLM 选型的唯一依据,写清楚适用场景 + 典型信号词 + 与其他模板的区别
  "nodes": ["org-planner", "org-coder", "org-validator"],
  "edges": [
    { "from": "org-planner",   "to": "org-coder",     "condition": "success" },
    { "from": "org-validator", "to": "org-coder",     "condition": "fail", "edgeKind": "backward" }
  ]
}
  • condition:"success" | "fail",边的语义是执行流(上游出这个结果时流向下游),不是汇报关系。
  • edgeKind:"forward"(默认,可省略)| "backward"。指向拓扑序更早节点的边必须显式标 backward。

加一个新模板

  1. 新建 system/org-graph-templates/{id}.json,按上面的格式填。
  2. 角色名遵循 {domain}-{职能}(27-NAMING §三)。禁止裸用 planner / coder / writer / validator ——跨领域公司会立刻撞名。新领域自己起前缀(如 design- / sales- / data-)。
  3. 避开这 6 个命名冲突 id:agent-creator / digester / evolver / evolver-youtube-crawler / hunter / innovator。它们在 system/agents/ 与 system/templates/ 下同名但内容可能不同步, 引用了会产生「该读哪份 agent.md」的歧义。
  4. orggraph-planning 这类基础设施 agent 不要出现在图里——它规划图,但自己不是图上的节点。
  5. 人工验算 27-P2 §3.3 的四项校验(写入 API 也会校验,但模板先自查能省一轮 LLM 重试):

| # | 规则 | 怎么自查 | |---|---|---| | 1 | 无环(只看 forward 边) | 把所有 backward 边划掉,剩下的边必须能排出拓扑序 | | 2 | 恰好一个入口 | 只数 forward 边的入度,入度为 0 的节点必须恰好一个 | | 3 | 全可达 | 从入口沿 forward 边 BFS,必须覆盖 nodes 里每一个节点,不许有孤立节点 | | 4 | 回退边显式标注 | 任何 to 在拓扑序上早于 from 的边,必须带 "edgeKind": "backward" |

  1. 自验 JSON 能解析: bash node -e "['dev','content','ops'].forEach(f=>JSON.parse(require('fs').readFileSync('system/org-graph-templates/'+f+'.json','utf-8')))"