从族谱到事件总线：FROST-SOP 如何把"家族治理"变成可运行的调度引擎
一、从一句"听起来很美"说起
昨天我们聊了 FROST 的六层治理宪法模型------从宪法层到结果层，层层嵌套、层层约束。
评论区有人问了一个很实在的问题：
"这套家族治理的理念听起来很完整，但它怎么跑起来？总不能靠嘴遁吧？"
问得好。
任何治理模型，如果不能被编码成可执行的系统，那就只是哲学，不是工程。
FROST 是思想源头，FROST-SOP 就是让思想落地开花的工程实现。今天这篇文章，我想把 FROST-SOP 的核心调度引擎拆开给你看------从事件总线到角色生命周期，从族谱记录到记忆沉淀，一步一步讲清楚：
"祖辈-父辈-子辈"这套听起来像封建制度的东西，到底是怎么变成一行行跑在服务器上的代码的。
二、核心挑战：为什么不能是简单的"主从模式"？
在讲实现之前，先回答一个更根本的问题：
为什么要搞"家族"这么复杂的概念？一个主 Agent 管一堆子 Agent，不行吗？
我们做过，然后翻车了。
翻车现场：主从模式的三个死穴
死穴1：主 Agent 是单点瓶颈。
所有任务都经过主 Agent 拆解、分配、回收。任务量小的时候没问题，一旦并行任务超过 5 个，主 Agent 的注意力就被严重稀释------它记不住每个子任务的细节，回收质量急剧下降。
就像一个创业公司，CEO 直接管 20 个员工，每个人做什么他都记不清。
死穴2：没有中层，信息全靠传话。
主 Agent 派子 Agent 做任务，子 Agent 做完返回结果。如果子 Agent 在执行中发现问题、需要调整方向，它只能汇报给主 Agent，等主 Agent 决策。
一来一回，延迟爆炸。更糟的是，主 Agent 没有一线信息，决策质量也不高。
死穴3：用完即散，记忆不沉淀。
子 Agent 用完就删，下一次做类似任务，又是从零开始。每一次都是"第一次"，没有任何积累。
你做了 100 次日报任务，每次的错误、经验、最佳实践，全都随子 Agent 一起消散了。
破局：引入"家族"结构
FROST 的解法，是在"主从"之间加了一层------父辈。
传统主从： 主Agent → 子Agent（扁平，无积累）
FROST家族： 祖辈 → 父辈 → 子辈（分层，有中层，有记忆）这不是拍脑袋的设计，而是从组织行为学里搬来的经验：
| 层级 | 类比 | 核心职责 | 生命周期 |
|---|---|---|---|
| 祖辈 | CEO / 创始人 | 任务拆解、资源分配、全局协调 | 常驻 |
| 父辈 | 项目经理 | 子任务管理、质量把控、记忆沉淀 | 按项目存活 |
| 子辈 | 执行者 | 具体任务执行 | 用完即散 |
关键在于父辈这一层 ------它是整个体系的"中层管理"，向上对祖辈负责，向下管理子辈执行，同时它还是记忆的闸门------所有执行经验必须经过父辈筛选、整理，才能进入家族知识库。
好，理念讲完了。下面进入硬核部分：这套东西在代码里长什么样？
三、调度引擎的骨架：事件驱动架构
FROST-SOP 的调度引擎，核心是一条事件总线（Event Bus）。所有角色------祖辈、父辈、子辈、长老------都通过发布和订阅事件来协作，没有任何直接调用。
3.1 为什么是事件驱动？
事件驱动架构有三个好处，恰好对应家族治理的三个需求：
- 解耦：祖辈不需要知道父辈的实现细节，它只需要发布一个"任务创建"事件。谁来接、怎么接，祖辈不管。
- 可观测：所有事件都流过总线，天然形成一条完整的审计链。这就是族谱记录的技术基础。
- 弹性：角色可以随时上下线------子辈执行完就销毁，父辈在项目结束后撤场，祖辈常驻。一切由事件驱动，不需要中心化的调度器。
3.2 事件总线的极简实现
python
# core/event_bus.py
from typing import Callable, Any
from collections import defaultdict
from dataclasses import dataclass, field
import uuid
import time
@dataclass
class Event:
"""事件是FROST-SOP中一切协作的载体"""
event_type: str # 事件类型：task_created / agent_spawned / task_completed ...
payload: dict # 事件数据
source: str # 发出者：ancestor / father_001 / child_007 ...
event_id: str = field(default_factory=lambda: uuid.uuid4().hex)
timestamp: float = field(default_factory=time.time)
lineage: list = field(default_factory=list) # 血缘链：谁触发了谁
class EventBus:
"""全局事件总线
所有Agent通过事件总线通信，不直接调用。
这是族谱记录的基础设施------每一条事件都是一条族谱记录。
"""
def __init__(self):
self._subscribers: dict[str, list[Callable]] = defaultdict(list)
self._event_log: list[Event] = [] # 完整事件日志 = 族谱
def subscribe(self, event_type: str, handler: Callable):
"""订阅某类事件"""
self._subscribers[event_type].append(handler)
def publish(self, event: Event):
"""发布事件，触发所有订阅者"""
self._event_log.append(event)
for handler in self._subscribers.get(event.event_type, []):
try:
handler(event)
except Exception as e:
# 订阅者异常不影响其他订阅者
self.publish(Event(
event_type="handler_error",
payload={"error": str(e), "handler": handler.__name__},
source="event_bus",
lineage=[event.event_id],
))
def get_genealogy(self, task_id: str) -> list[Event]:
"""查询某个任务的完整族谱（血缘链追溯）"""
return [e for e in self._event_log
if e.payload.get("task_id") == task_id]
# 全局单例
bus = EventBus()这段代码看起来很简单，但它是整个 FROST-SOP 的骨架。
理解了事件总线，你就理解了为什么说**"族谱不是事后写的，是实时流淌出来的"**------每一个事件都是族谱的一笔，自动记录、不可篡改、完整可追溯。
四、角色生命周期：祖辈如何召唤府兵
有了事件总线，角色之间的协作就变成了"发布事件 → 触发响应 → 产生新事件"的循环。
下面我们看一个完整的任务生命周期：祖辈接到任务 → 召唤父辈 → 父辈召唤子辈执行 → 子辈消散 → 父辈沉淀记忆 → 父辈撤场 → 祖辈验收。
4.1 祖辈：任务拆解者和全局协调者
祖辈是唯一常驻的角色。它的核心工作是两件事：
- 接收外部任务，拆解成可以交给父辈独立完成的子任务
- 监控全局状态，在必要时召唤长老做审计
python
# agents/ancestor.py
from core.event_bus import bus, Event
from agents.base import BaseAgent
class AncestorAgent(BaseAgent):
"""祖辈Agent------家族常驻代表
职责：
1. 接收外部任务，拆解为子任务
2. 召唤父辈Agent执行子任务
3. 汇总结果，交付给外部
4. 必要时召唤长老审计
"""
agent_type = "ancestor"
agent_id = "ancestor_001" # 全局唯一祖辈
def __init__(self):
super().__init__()
# 订阅：有新任务来了
bus.subscribe("external_task_received", self.on_task_received)
# 订阅：父辈完成了子任务
bus.subscribe("father_task_completed", self.on_father_completed)
def on_task_received(self, event: Event):
"""收到外部任务，拆解并召唤父辈"""
task = event.payload["task"]
task_id = task["task_id"]
# Step 1: 任务拆解（由LLM完成，产出结构化子任务列表）
subtasks = self._decompose_task(task)
# Step 2: 为每个子任务召唤一个父辈Agent
for i, subtask in enumerate(subtasks):
father_id = f"father_{task_id}_{i}"
# 发布"父辈召唤"事件------父辈工厂会监听这个事件
bus.publish(Event(
event_type="agent_spawn_requested",
payload={
"agent_type": "father",
"agent_id": father_id,
"task": subtask,
"parent_task_id": task_id,
},
source=self.agent_id,
lineage=[event.event_id],
))
# Step 3: 记录待完成的子任务
self._pending_subtasks[task_id] = len(subtasks)
self._results[task_id] = []
def on_father_completed(self, event: Event):
"""父辈完成任务，回收结果"""
task_id = event.payload["parent_task_id"]
result = event.payload["result"]
self._results[task_id].append(result)
self._pending_subtasks[task_id] -= 1
# 所有子任务都完成了
if self._pending_subtasks[task_id] == 0:
final_result = self._synthesize_results(task_id, self._results[task_id])
bus.publish(Event(
event_type="task_delivered",
payload={"task_id": task_id, "result": final_result},
source=self.agent_id,
lineage=[event.event_id],
))4.2 父辈：中层管理者和记忆闸门
父辈是整个架构中最关键的一层。它不只是"传声筒"，而是承担了三个核心职责：
- 子任务管理：把祖辈给的任务进一步拆给子辈执行
- 质量把关：子辈的产出必须经过父辈审核才能上交
- 记忆沉淀：从执行经验中提炼可复用的SOP片段，存入家族知识库
python
# agents/father.py
from core.event_bus import bus, Event
from agents.base import BaseAgent
from core.store import FamilyStore
class FatherAgent(BaseAgent):
"""父辈Agent------项目经理
生命周期：从被召唤到任务完成，随项目而存在
核心价值：质量把关 + 记忆沉淀
"""
agent_type = "father"
def __init__(self, agent_id: str, task: dict, parent_task_id: str):
super().__init__()
self.agent_id = agent_id
self.task = task
self.parent_task_id = parent_task_id
self.store = FamilyStore() # 家族知识库连接
# 订阅：子辈完成任务
bus.subscribe(f"child_task_completed:{agent_id}", self.on_child_completed)
def start(self):
"""父辈启动：召唤子辈开始执行"""
# 先查家族知识库，看看有没有类似任务的经验
similar_experience = self.store.query_similar_tasks(self.task)
# 如果有现成的SOP，直接复用；没有则重新拆解
if similar_experience:
subtasks = self._apply_experience(self.task, similar_experience)
else:
subtasks = self._decompose_fresh(self.task)
self._pending = len(subtasks)
self._results = []
for i, subtask in enumerate(subtasks):
child_id = f"child_{self.agent_id}_{i}"
bus.publish(Event(
event_type="agent_spawn_requested",
payload={
"agent_type": "child",
"agent_id": child_id,
"task": subtask,
"father_id": self.agent_id,
},
source=self.agent_id,
))
def on_child_completed(self, event: Event):
"""子辈完成任务，父辈审核"""
result = event.payload["result"]
child_id = event.payload["agent_id"]
# Step 1: 质量审核（调用质量Gate，上周讲过的三分离机制）
audit_result = self._audit_result(self.task, result)
if audit_result.passed:
self._results.append(result)
self._pending -= 1
# Step 2: 把子辈的执行经验沉淀到知识库（父辈是记忆闸门）
experience = self._extract_experience(result, audit_result)
self.store.add_experience(experience)
# 子辈消散（FROST铁律：府兵用完即散，只留记忆）
bus.publish(Event(
event_type="agent_terminated",
payload={"agent_id": child_id, "reason": "task_completed"},
source=self.agent_id,
))
else:
# 质量不达标，打回重做
bus.publish(Event(
event_type="child_rework_requested",
payload={
"agent_id": child_id,
"task": event.payload["task"],
"feedback": audit_result.feedback,
},
source=self.agent_id,
))
# 所有子任务都完成了
if self._pending == 0:
self._finish_task()这里有一个非常 FROST 的设计------子辈用完即散，只留记忆。
这不是浪费，而是刻意的设计选择。为什么？
- 防止状态污染：子辈在执行中可能产生各种中间状态，如果复用，这些状态可能悄悄影响下一次执行
- 强制记忆显式化：因为子辈会消散，所以有用的经验必须主动提炼出来存入知识库，而不是"顺便记住"
- 保持架构干净：每次都是全新的执行者，行为可预测、可复现
这就是 FROST 铁律之一：
府兵用完即散，记忆归于家族。个人会消亡，标准会传承。
五、角色工厂：Agent 的"召唤"机制
你可能会问："发布一个 agent_spawn_requested 事件，Agent 就出来了？谁来创建它？"
答案是Agent 工厂------一个监听召唤事件、按需创建 Agent 实例的模块。
python
# core/agent_factory.py
from core.event_bus import bus, Event
from agents.ancestor import AncestorAgent
from agents.father import FatherAgent
from agents.child import ChildAgent
from agents.elder import ElderAgent
class AgentFactory:
"""Agent工厂------按需召唤角色
这是"家族治理"的工程化实现：
- 不是一开始把所有Agent都创建好
- 而是需要的时候才召唤，用完就遣散
"""
def __init__(self):
self._active_agents: dict[str, BaseAgent] = {}
bus.subscribe("agent_spawn_requested", self._on_spawn_request)
bus.subscribe("agent_terminated", self._on_terminate)
def _on_spawn_request(self, event: Event):
agent_type = event.payload["agent_type"]
agent_id = event.payload["agent_id"]
if agent_id in self._active_agents:
return # 已存在，不重复创建
# 根据类型创建不同的Agent
if agent_type == "father":
agent = FatherAgent(
agent_id=agent_id,
task=event.payload["task"],
parent_task_id=event.payload["parent_task_id"],
)
agent.start() # 父辈启动后会自己召唤子辈
elif agent_type == "child":
agent = ChildAgent(
agent_id=agent_id,
task=event.payload["task"],
father_id=event.payload["father_id"],
)
agent.start()
elif agent_type == "elder":
agent = ElderAgent(
agent_id=agent_id,
target_event_id=event.payload["target_event_id"],
)
agent.start()
else:
return
self._active_agents[agent_id] = agent
bus.publish(Event(
event_type="agent_spawned",
payload={"agent_type": agent_type, "agent_id": agent_id},
source="agent_factory",
lineage=[event.event_id],
))
def _on_terminate(self, event: Event):
agent_id = event.payload["agent_id"]
if agent_id in self._active_agents:
del self._active_agents[agent_id]
# 全局工厂实例
factory = AgentFactory()这个工厂模式，就是 FROST 家族治理中"召唤府兵"的工程化表达。
不是所有角色都常驻，而是按需召唤、随用随散------这既是工程上的资源优化，也是治理上的设计选择。
六、族谱记录：流淌的审计链
讲完了调度引擎，最后回到一个 FROST 最有特色的机制------族谱记录。
昨天我们聊治理的时候提到，治理的核心是"可追溯"。在 FROST-SOP 中，这个追溯能力不是事后构建的，而是事件总线的天然副产品。
6.1 族谱是怎么自动生成的
每一个事件都有三个关键字段：
event_id：事件唯一IDsource：谁发出的lineage：血缘链，即触发本事件的上游事件ID列表
通过这三个字段，任何一个事件都可以追溯到它的完整上游链------从最终结果，一直回溯到最初的任务输入。
python
# core/genealogy.py
from core.event_bus import bus
class GenealogyTracer:
"""族谱追溯器
从任意一个事件出发，向上追溯完整的血缘链，
还原一个任务从接收到交付的全过程。
"""
def trace(self, event_id: str) -> dict:
"""追溯某个事件的完整族谱"""
event = self._find_event(event_id)
if not event:
return {}
return {
"event": event,
"parents": [self.trace(parent_id)
for parent_id in event.lineage
if parent_id],
}
def generate_report(self, task_id: str) -> str:
"""生成某个任务的族谱报告"""
events = bus.get_genealogy(task_id)
report = [f"# 族谱报告：任务 {task_id}", ""]
# 按时间排序
events.sort(key=lambda e: e.timestamp)
for i, event in enumerate(events):
report.append(f"## E{i+1}: {event.event_type}")
report.append(f"- 发出者：{event.source}")
report.append(f"- 时间：{event.timestamp}")
report.append(f"- 内容：{self._summarize_payload(event.payload)}")
report.append("")
return "\n".join(report)
def _find_event(self, event_id: str):
for e in bus._event_log:
if e.event_id == event_id:
return e
return None
def _summarize_payload(self, payload: dict) -> str:
# 简化摘要，避免报告过长
keys = list(payload.keys())[:5]
return ", ".join(f"{k}: {str(payload[k])[:50]}" for k in keys)6.2 族谱有什么用？
族谱不只是"事后复盘"的工具，它还是实时治理的基础设施：
- 长老审计：长老收到审计请求后，不需要问任何人，直接拉族谱就能看到完整的执行过程
- 质量回溯：如果最终结果有问题，可以沿着族谱一层一层往下找，精准定位是哪个环节出了错
- 经验提炼：父辈沉淀记忆时，可以引用族谱中的具体事件作为证据，让经验不是"感觉"而是"有依据"
- 宪法合规检查：宪法层规则可以订阅所有事件，实时检测违规行为
七、真实数据：这套架构跑得怎么样？
说了这么多架构，最后用数据说话。我们在 GOAI 大赛项目「新明鉴教育APP MVP」中完整跑了一轮 FROST-SOP，结果如下：
| 指标 | FROST-SOP 家族调度 | 传统主从模式 | 变化 |
|---|---|---|---|
| 任务交付时间 | 平均 18 分钟 | 平均 42 分钟 | ↓ 57% |
| 并行任务上限 | 12 个无明显降质 | 5 个开始降级 | ↑ 140% |
| 首次通过率 | 71% | 58% | ↑ 13pp |
| 可追溯性 | 100%（完整族谱） | 30%（仅有最终结果） | --- |
| 经验复用率 | 第10次任务时达 42% | 接近 0% | --- |
最让我意外的是经验复用率这个指标。
前 3 次任务，因为知识库是空的，复用率很低。但从第 4 次开始，父辈们开始频繁地从知识库中调取类似任务的经验，复用率稳步上升。
到第 10 次同类型任务时，超过 40% 的子任务可以直接复用已有 SOP，不需要重新拆解和试错。
这就是 FROST 的核心理念------
个人会消散，但家族会成长。每一次执行都不只是完成任务，更是在为家族积累能力资产。
八、回到那个问题：它怎么跑起来？
回到文章开头的问题："家族治理怎么跑起来？"
答案分三层：
第一层（技术）：事件驱动架构。 所有角色通过事件总线通信，解耦、可观测、有弹性。
第二层（机制）：祖父子三层角色。 祖辈拆任务、父辈管质量、子辈做执行，各司其职，各有生命周期。
第三层（理念）：记忆归于家族。 府兵用完即散，但经验会被父辈筛选、提炼、存入家族知识库，成为下一次任务的起点。
FROST 是思想------告诉你"为什么要这么做"。 FROST-SOP 是工程------告诉你"具体怎么做、代码怎么写"。
思想没有工程，就是空谈。 工程没有思想，就是堆砌。
两者结合，才是完整的 FROST 生态。
写在最后
这篇文章讲了 FROST-SOP 的调度引擎核心，但这只是冰山一角。
完整的 FROST-SOP 还包含：
- SOP 工作流引擎：标准化流程的定义和执行
- Gate 质量门禁：上周聊过的三分离验证机制
- Store 记忆系统：家族知识库的存储和检索
- Skill 能力市场：跨家族的技能流通
如果你对哪个部分感兴趣，欢迎留言，我们下周接着拆。
FROST（教学框架） ：gitee.com/liao_liang_... FROST-SOP（工程平台） ：gitee.com/liao_liang_...
Star 一下，见证一个 AI Agent 家族的成长。