跳到主要内容

角色与权责矩阵

本文定义 FinTec AI Ecosystem 各角色的职责、边界和协作关系。角色分为人类角色和 Agent 角色两类，通过四层协作关系相互配合。

1. 角色清单​

角色类型范围主要责任
生态发起人 / Sponsor人类整个 ecosystem拍板生态级变更、解最高级别冲突
Program Controller人类 / Agent某个生态对象（产品 / 系统）跨材料、跨仓库、跨 Agent 控制台，维护推进状态与对齐
项目 Controller人类 / Agent某个 projects/<id>/项目内上下文分发、阶段衔接、回写闭环
议题 Maintainer人类 / Agent某个 for-agents/topics/<topic>/议题内材料维护、Agent pack 维护
个人域 AgentAgent个人域内按任务读取最小上下文、产出 evidence / proposal / gap
团队域 AgentAgent团队内多 Agent基于 task-packet 或 handoff-anchor 执行
外部协作者人类 / Agent受限接入在指定范围内分析 / 建议 / 实现
Contributor（默认态）人类全仓可读、受限写入刚加入团队、尚未被任命为特定角色的成员

Contributor 默认态​

刚加入团队、尚未被生态发起人或项目 Controller 任命为特定角色的成员，默认为 Contributor：

  • 可读：全部知识库内容
  • 可写：L0-L1 变更（文档勘误、typo 修正、frontmatter 更新等可直接 commit 或 1 人 review）
  • 可提议：通过 governance/proposals/inbox/ 提议任何级别的变更
  • 不可：自行合并 L2+ 变更；不可直接修改 governance/ 核心协议（需走 L3/L4 流程）
  • 升级路径：由项目 Controller 或生态发起人任命为更高权限角色（如项目 Controller、议题 Maintainer）

2. Program Controller 定义​

Program Controller 是某个生态对象的跨材料、跨仓库、跨 Agent 控制台。

FinTec AI Ecosystem 的五个核心对象会逐步进入并行推进阶段：

  • Data Horizon / 数据视界
  • FinClaw
  • AI Trading Matrix
  • Reinforcement Learning Engine
  • Financial Expert Foundation Model

每个对象都可能拥有自己的产品文档、工程仓库、参考材料、项目 owner、个人域 Agents 和团队域协作流程。为避免所有上下文集中在单一会话或单一仓库中，需要为每个对象建立专属 Program Controller。

负责​

#职责
1读取并继承本仓库中的上游事实
2维护该产品 / 系统的当前推进状态
3将产品定义、参考材料和工程现状对齐
4识别需要工程执行、产品裁决、生态同步或升级的问题
5把可执行工作交给工程仓库、个人域 Agents、团队域 Agents 或协同任务
6把稳定结果回写为正式文档、sync 或 escalation 候选

不负责​

#不负责事项
1替代 ecosystem owner 做最终生态级裁决
2替代工程仓库保存代码和运行证据
3替代协同任务执行做复杂任务执行
4替代本仓库成为事实源
5承担日常个人 todo 或项目 backlog

3. 四层协作关系​

3.1 生态治理仓库（本仓库）​

负责：

#职责
1生态事实源
2产品定义
3MVP 边界
4参考材料与来源材料
5风险边界
6sync / escalation
7被接受结论的正式回写位置

不承担：

#不承担事项
1工程实现
2日常任务执行
3具体系统对接设计
4每个项目内部 backlog

3.2 Program Controller​

负责：

  • 对某个产品 / 系统做持续控制台；
  • 汇总上游事实、工程现状和参考材料；
  • 维护当前对齐状态；
  • 决定哪些事项应进入工程、协同任务、sync 或 escalation。

3.3 协同任务​

负责：

  • 承接复杂协作任务；
  • 形成任务契约；
  • 分派执行；
  • 收集证据；
  • 支持评审和验收；
  • 输出可回写结论。

3.4 工程仓库​

负责：

  • 保存实现代码；
  • 保存工程设计、测试和运行证据；
  • 承载具体系统对接设计；
  • 承接项目内部任务和代码评审。

工程仓库的 Controller 配置和运行时细节保存在各工程仓库内部，不在本治理仓库中维护。

4. 推荐工作流​

  1. 本仓库给出上游事实源和验收口径；
  2. Program Controller 读取上游事实源，并盘点目标工程仓库；
  3. Program Controller 输出工程对齐报告或协同输入；
  4. 适合多人多 Agent 执行的任务进入协同任务流程；
  5. 工程实现发生在对应工程仓库；
  6. 执行证据和评审结果回到 Program Controller；
  7. 稳定产品 / 生态事实通过 sync、escalation 或正式文档更新回写本仓库。

5. 权责矩阵（RACI）​

角色 \ 目录ecosystem/projects/<id>/commons/governance/for-agents/
生态发起人ACCAI
Program ControllerCARII
项目 ControllerCARII
议题 MaintainerICRIA（仅自己 topic）
个人域 AgentR（提议）R（提议）R（提议）R（提议）—
团队域 Agent—R（执行）R（执行）——
外部协作者—C（受限）C（受限）——

字段：R 主提案 / A 拍板 / C 必须咨询 / I 知会即可；"—" 表示无角色。

6. 任命与撤销​

6.1 Controller 任命​

  • 由生态发起人指定或确认；
  • 任命时必须明确：负责对象、权限边界、回写路径；
  • 任命记录保存在项目目录的 Controller state 或 ADR 中。

6.2 Controller 撤销​

  • 当 Controller 长期不活跃或职责转移时，由生态发起人决定撤销或交接；
  • 撤销前必须完成状态交接文档。

6.3 空窗期处理​

  • Controller 空窗期间，项目进入只读状态，不接受重大变更；
  • 紧急事项通过 escalation.md 升级至生态发起人处理。

7. 约束​

  • 不以 Program Controller 会话替代正式文档；
  • 不以协同任务替代生态事实源；
  • 不以本仓库替代工程仓库；
  • 不把工程实现细节提前固化进生态治理仓库；
  • 不让参考项目直接覆盖产品定义；
  • 不让早期工程 PRD 反向压缩上位战略和产品定义。