九角色 Agent 组织图：决策所有权、词汇纪律与资源绑定
系列：Idea-to-Production · 概念篇
给 Agent 起名字很容易，给它们划决策边界很难。当两个 Agent 都”觉得”自己该改同一份架构文档时，角色扮演就破产了。本文讲九角色组织图背后真正的工程问题：哪些决定归谁、词汇如何禁止漂移，以及为什么”角色”必须是资源绑定的单位，而不是提示词里的人设。
为什么值得看
多数多 Agent 系统的”角色”停留在角色扮演：同一个模型换个 system prompt，演产品经理、演工程师。这样的角色一遇冲突就失效——两个角色都”觉得”自己该改架构文档，谁说了算没有答案，因为”谁该改哪份文档”从来没人写下来。
我们的组织图是一份权限与工件所有权的分配方案：每个角色拥有什么决定、产出什么文档、运行哪些循环，全部写在定义里，并且有一个跨仓库的词汇纪律防止它腐化。
你将学到三点
- 角色 = 决策所有权 + 工件所有权 + 常驻循环三件套，缺一件就只是人设。给 Agent 分工，先分工”谁有权改哪份文档”。
- 一套词汇、两种拼写：角色的内容文件夹名与运行时 ID 严格 1:1 映射；改名必须全仓库清扫，否则作业路由会静默失效。
- 平台职能不要伪装成角色：锁回收、失联标记这类机件级职责，交给平台看门狗和文档化标准，比虚构一个”监督 Agent”更诚实。
组织图本体：谁拥有什么决定
九个角色，各自的答案是”独占一块决策权”：
| 角色 | 拥有的决定 | 常驻循环 |
|---|---|---|
| 产品与项目管理 | 战略、需求定义、任务派发（两棒）、每日 issue 分诊 | 分诊每日 09:00 |
| 工程架构 | 方案与核心模块设计、仓库脚手架、设计任务裁决、每日 PR 评审 | PR 巡检每日 09:00 |
| 全栈工程 | 详细设计、实现规划、按特性实现与单元/集成测试 | 随任务队列 |
| UI/UX 与文案 | 界面设计、交互流、产品文案、已发布应用文档 | 随任务队列 |
| QA 与发布 | E2E 策略与执行、CI/CD、发布、事故回滚 | E2E 每日门禁；发布每月 1/15 日 |
| 服务与数据运营 | 用量/订阅/健康/漏斗四类报告 | 双周派发、7 天窗口 |
| 市场与增长 | 社交内容、增长与竞品报告、需求回传 | 双周派发、7 天窗口 |
| 行政与财务 | 每周公司治理报告：效率与成本（含 token 用量）、迭代节奏、质量信号三章 | 每周一 09:00 |
| 自主迭代哨兵 | 平台侧：锁回收、失联实例标记；质量评审已溶解进检查点与发布门 | 常驻看护，无排班 |
三个观察，比表格本身更重要。
派发权只有一个来源
只有 PM 角色能批量造任务并派发（两棒派发），其他角色可以新建单条任务（如发现 bug 给全栈），但不能重组计划。这避免”谁都能插单”导致的依赖图腐烂。
质量不是角色，是机制
哨兵角色的历史版本曾是”全量质检员”，最终我们把它的评审职能溶解成两条规则：逐交付物评审检查点（无 PASS 不算 Done）和集成面发布门（BLOCK 即阻断）。剩下的机件职能——回收过期锁——本来就该由平台代码实现。让 Agent 去巡检锁表，等于给确定性机件加上不确定性执行者。
回滚不需要人，但需要写下来的标准
QA 角色的事故回滚不是临场判断，是文档化的决策标准：观察期内的部署回归、Sev-1、错误预算耗尽且回归信号为正——满足才回滚。回滚 = 用最后一个健康 tag 重跑部署链，随后仍走两阶段关闭，把 bug 交回需求环。
词汇纪律：两种拼写，一个真源
同一个角色在系统里有两种名字：知识层里的内容文件夹（如 agents/product-program-manager/）和调度层里的运行时 ID（如 agent-pm）。它们 1:1 映射，且这条映射被定为不容协商的不变式：
- 术语（角色 ID、阶段字母、任务词汇）只定义一次；
- 改名 = 跨仓库清扫，漏一处就是静默的路由断链——作业推给了一个不存在的角色，任务永远不会被认领；
- 同一条原则绝不在第二份文档里复述，要引用就链接真源。
这条纪律的成本极低（一次清扫），收益在故障模式上：词汇漂移的症状是”某类任务神秘地无人执行”，没有报错、没有日志，只有看板上的沉默积压。
给 Agent 系统做可维护性设计，首先是给它的命名空间做。
角色作为资源绑定的单位
组织图不只是文档结构，它是部署单位。工作实例创建时唯一的必填项就是角色；绑定该角色的全部资源——Agent 定义、技能、工作流、领域知识——自动进入实例工作空间。对比架构师与 PM 两个角色，绑定的技能与工作流几乎完全不重叠：
- 架构师：方案设计的
solution-architect、脚手架的repo-skeleton-creator、评审的pr-reviewer…… - PM：写需求的
requirement-writer、派发的task-batch-creator/publisher、分诊的issue-triage-daily……
这带来一个很实用的推论：改进某个角色的能力，只需要改知识层对应文件夹，所有同角色实例即刻生效（符号链接，详见《为什么要拆成三个仓库：知识、调度、档案的分离法则》）；而扩容某个角色的吞吐，只需要多开实例，不需要改任何定义。能力演进与容量伸缩沿着同一条角色边界解耦。
总结
- 画你的 Agent 组织图时，先写”决策与工件的所有权表”——谁能改哪份文档、谁能造任务、谁的标准触发回滚——再写角色简介；顺序反了就会得到一群互相踩线的聊天人格。
- 把角色名当作公共 API 管理：1:1 映射、单点定义、改名走清扫。命名空间纪律是多仓库 Agent 系统最便宜的可观测性。
- 检查你的”质检/监督”角色是不是机件伪装：凡是要求确定性、周期性、幂等性的职责（回收锁、巡检过期、去重），应该在平台代码里实现，而不是托付给一个 LLM 工位。
同系列下一篇：《人不在环内：一个 AI 自主交付组织的概念契约》，讲这套组织图背后的概念契约。