apps/ 下实际有 21 个 agent（ls apps/ | wc -l = 21，文档常说 9/12，Day 01 讲过的漂移）。按用途大致分四类：

agent-creator（造 agent）、skiller-creator（造 skill）。L03-L05 精读。

requirement-discoverer → spec-author → spec-executor → release-coordinator，让平台"自己开发自己"。L06-L09 精读。

supervisor-router-agent（跨 agent 路由）、bmc-agent-mcp（MCP 形态载体，D13 讲过）。

所有 agent 共用同一套 toolkit，但按需裁剪出不同"形态"。理解这些变体，能体会框架的弹性：

元 Agent（meta-agent）= 造 Agent/组件的 Agent。它的输出不是"业务分析结果"，而是"另一段代码/一个新组件"。它们本身也是标准的 LangGraph agent（有 State、builder、节点、Critic），只是节点干的活是"分析需求、渲染模板、生成文件"而非"查日志、算指标"。本框架有两个：

• agent-creator：一句自然语言描述 → 生成一个符合规范、可直接跑的新 agent 代码骨架（一次成型）。
• skiller-creator：生成并注册新的 Skill 组件，带自动评测-修订的迭代闭环（RLHF 思想）。

agent-creator 的图是纯串行——需求→架构→脚手架→评测设计→查错→组装，没有分支没有循环（apps/agent-creator/agent_creator/builder.py:40-59）：

def build_agent_creator_graph():               # builder.py:40
    builder = StateGraph(AgentCreatorState)
    builder.add_node("requirements_analyst", requirements_analyst_node)
    builder.add_node("architect", architect_node)
    builder.add_node("scaffolder", scaffolder_node)
    builder.add_node("evals_designer", evals_designer_node)
    builder.add_node("critic_l1", build_critic_l1())       # ← 复用 D07 business_layer1！
    builder.add_node("warn_check", check_eval_count_warning)
    builder.add_node("assemble_outcome", assemble_outcome)
    # 一条直线，无分支
    builder.add_edge(START, "requirements_analyst")
    builder.add_edge("requirements_analyst", "architect")
    builder.add_edge("architect", "scaffolder")
    builder.add_edge("scaffolder", "evals_designer")
    builder.add_edge("evals_designer", "critic_l1")
    builder.add_edge("critic_l1", "warn_check")
    builder.add_edge("warn_check", "assemble_outcome")
    builder.add_edge("assemble_outcome", END)
    return builder.compile()

skiller-creator 比 agent-creator 多了一个自我评测-修订循环。它的图有两条路径，靠两个条件函数控制。先看图组装（apps/skiller-creator/skiller_creator/builder.py:83-117）：

g.add_edge(START, "skill_writer")
g.add_edge("skill_writer", "scaffolder")
g.add_edge("scaffolder", "critic_l1")
g.add_conditional_edges("critic_l1", _after_critic, {   # ← 路由①
    "assemble": "assemble",
    "test_query_generator": "test_query_generator",
    "evaluator": "evaluator"})
g.add_edge("test_query_generator", "evaluator")
g.add_conditional_edges("evaluator", _after_eval, {     # ← 路由②
    "assemble": "assemble",
    "reviser": "reviser"})
g.add_edge("reviser", "scaffolder")                     # ← 修订后回炉！循环边
g.add_edge("assemble", END)

真正的精髓是评测后的路由 _after_eval（builder.py:65-80）——它决定"达标交付 or 回炉重写"：

def _after_eval(state) -> str:                 # builder.py:65
    eval_report = state.get("eval_report") or {}
    passes = bool(eval_report.get("passes_threshold", False))
    current_iter = int(state.get("iteration") or 0)
    max_iter = int(state.get("max_iterations") or 0)
    if passes:
        return "assemble"                      # 达标 → 交付
    if current_iter >= max_iter:
        return "assemble"                      # ← 预算用尽也交付（不死循环）
    return "reviser"                           # 不达标 + 还有预算 → 修订后回炉

最精彩的部分——4 个 agent 串成一条"平台自己给自己提需求、写规格、改代码、评审发布"的流水线（就是 Day 04 route_chain 那条链）：

先看 requirement-discoverer 的 critic 路由——它体现了"cron 场景不该重试"（apps/requirement-discoverer/requirement_discoverer/builder.py:33-37）：

def _route_after_critic(state) -> str:         # builder.py:33
    """critic 三态:pass → writeback / fail → __end__(等下次 cron · 不 retry · 防 noise)。"""
    if state.get("critique_passed", False):
        return "writeback"
    return "end"                               # ← 不过就结束，不回炉重试

spec-author 把一段需求文本变成 OpenSpec change 的 4 个文件（proposal/tasks/design/spec-delta），写完还会自校验、失败自修复（apps/spec-author/spec_author/builder.py）。它的图骨架（文件头 docstring 画得很清楚）：

# builder.py:1 docstring 描述的图：
#  classify → scan_related_specs → generate_proposal → generate_tasks →
#  generate_design → generate_spec_delta → write_files → validate
#                                                          │
#                            ┌───── validate.status ───────┤
#                          valid                          failed
#                            │              self_repair_count < 2 ?
#                            │                ┌────────────┴──────────┐
#                            │              yes(repair→write→loop)   no(fail_2x)
#                            └────────────────┴────────────────────────┘
#                                          ↓  reporter → END
REPAIR_LIMIT = 2                           # builder.py:40 · 最多自修复 2 次
...
def build_spec_author_graph():             # builder.py:55

spec-executor 用一张图跑两种模式（apps/spec-executor/spec_executor/builder.py:1-20 docstring）：m0_plan 只做计划就 reporter 收尾；m1_execute 才真正 prepare_worktree → patch_files → run_quick_test → commit_branch。而 commit 的约束写在节点里：

# commit_branch.py:1
"""commit_branch · M1 only · 测试 pass 才 commit 到 agent/<change-id>。"""
# → 只提到临时分支 agent/*，永不碰 main；测试不过不 commit

release-coordinator 则是"5 道 gate 并行"的裁判（apps/release-coordinator/release_coordinator/builder.py:38-63）。它并行跑 ruff/mypy/pytest/arch/risk/doc 多道闸，用一个 reducer 合并各闸结果：

def _merge_gate_results(left: dict, right: dict) -> dict:   # builder.py:38
    """gate_results 字段的 reducer · 并行 gate 写各自 key · LangGraph 合并 dict。"""
    return {**(left or {}), **(right or {})}       # ← 各 gate 写不同 key，字典合并零冲突

元 Agent 和 spec 流水线都会往磁盘写文件——这是最危险的副作用。spec-author 的写文件全走 safe_change_write 这道闸（apps/spec-author/spec_author/tools/safe_change_write.py）。核心判定函数：

_DENY_PREFIXES = (                             # safe_change_write.py:14 · 黑名单
    "openspec/specs/",    # capability spec 是 ground truth，走 archive 流程，禁直改
    "apps/spec-author/",  # 禁改自己（防自递归污染）
    ".env", ".git/", "secrets/", "deploy/",
)

def is_change_path_allowed(rel_path: str, change_id: str) -> tuple[bool, str]:  # :41
    rp = _normalize(rel_path)                  # 统一斜杠 / 拒绝绝对路径
    if ".." in rp.split("/"):
        return False, "path 含 `..` parent traversal 拒"      # ① 防目录穿越
    for deny in _DENY_PREFIXES:
        if rp.startswith(deny):
            return False, f"黑名单前缀 {deny!r}"               # ② 黑名单
    expected_prefix = f"openspec/changes/{change_id}/"
    if not rp.startswith(expected_prefix):
        return False, f"必须在 {expected_prefix!r} 子树"       # ③ 白名单：只准写本次 change
    if not re.match(r"^\d{4}-\d{2}-\d{2}-[a-z0-9][a-z0-9-]*$", change_id):
        return False, f"change_id 格式不规范:{change_id!r}"    # ④ change_id 格式校验
    return True, ""

✋ 动手

# 1. 扫一遍所有 agent（数一下确实 21 个）
ls apps/ | wc -l && ls apps/
# 2. 元 Agent 的图：串行 vs RLHF 循环
sed -n '40,59p'  apps/agent-creator/agent_creator/builder.py
sed -n '40,117p' apps/skiller-creator/skiller_creator/builder.py
# 3. spec 四段流水线的 4 个 builder（读 docstring 图）
sed -n '1,40p' apps/spec-author/spec_author/builder.py
sed -n '1,40p' apps/spec-executor/spec_executor/builder.py
sed -n '1,40p' apps/release-coordinator/release_coordinator/builder.py
sed -n '1,45p' apps/requirement-discoverer/requirement_discoverer/builder.py
# 4. 安全护栏（元 Agent 写盘的底座）
cat apps/spec-author/spec_author/tools/safe_change_write.py
# 5. 复用 D07 的规则 critic 造 agent
sed -n '160,175p' apps/agent-creator/agent_creator/critic.py