bixiu/bixiweave
2
0
Fork 0
Code Issues 22 Pull requests Projects 2 Releases Packages Wiki Activity Actions

[RFC] Actor 注册模型重构：从「能力声明」到「角色声明」 #41

New issue
Open
opened 2026-06-14 14:11:03 +08:00 by orion · 2 comments
orion commented 2026-06-14 14:11:03 +08:00
Owner
Copy link

背景

当前的 Actor 注册模型基于 Capability（能力声明）：

actor = Actor(actor_id="analyst-a", capabilities=[
    Capability(type="analysis", name="需求分析", priority=9),
])
Bazaar 通过匹配 type 来分配任务。

但这个模型有两个根本问题：

问题 1：LLM 的能力声明不可靠

Actor 背后的 LLM 什么都能做。Capability(type="analysis") 不约束它实际能做什么，也无法验证——一个 Actor 声称有 "safety_audit" 能力，但 LLM 调用时完全可能做错或拒绝。集市不应该依赖 Actor 对自身能力的声明来做匹配。

问题 2：Actor 实例可被淘汰，但角色的期望是固定的

集市的目的之一是让 Actor 可被替换。今天跑的是 analyst-001（Claude），明天可以换 analyst-002（GPT-5）。但集市需要的不是一个特定实例，而是一个能满足架构评审需求的可信方。当前按 actor_id 或 capability.type 匹配的方式，把实例身份和能力类型耦合在一起，违背了集市的设计初衷。

提议：从「能力声明」到「角色声明」

将 Actor 的注册单元从 Capability（能力） 改为 Role（角色）。

# ─── 角色注册表（集中管理）───
ROLE_REGISTRY = {
    "architect": {
        "description": "关注系统的抽象完整性和架构一致性",
        "system_prompt": "你是一位架构师...",
    },
    "analyst": {
        "description": "需求分析、流程梳理",
        "system_prompt": "你是一位分析师...",
    },
    "developer": {
        "description": "编码实现",
        "system_prompt": "你是一位开发工程师...",
    },
}

# ─── Actor 注册（只注册 role）───
actor = Actor(actor_id="architect-001", role="architect", llm=llm)
bazaar.register_actor(actor_id="architect-001", role="architect")

# ─── 任务发布（指定 required_role）───
await bazaar.post_subtask(
    parent_task_id=...,
    required_role="architect",
    description="对认证模块做架构评审...",
)

关键变化

当前 提议
Actor.capabilities（dict[str, Capability]，以 type 为 key） Actor.role: str
Capability(type, priority, max_concurrency) 并发控制独立为 LoadSlot(max_concurrency)
Bazaar 匹配：按 type 匹配 + score() 排序 Bazaar 匹配：按 required_role == actor.role 精确匹配
Actor 自定义 Capability.description 做 system prompt Role Registry 统一管理每个 role 的 system prompt

改动范围

  1. bootstrap/actor.py — Actor 简化，去掉 capabilities 字典，改为 role: str + 一个轻量并发槽
  2. bixiweave/actor.py — 同上，to_capability_list() → to_role_declaration()
  3. bootstrap/bazaar.py — _actor_scores 删除，认领逻辑只匹配 required_role == actor.role
  4. bootstrap/v2_demo.py — 注册方式改为 register_actor(id, role)，ROLE_REGISTRY 集中定义
  5. bootstrap/warden.py — 展示 role 而非 capability 列表
  6. 新文件 bootstrap/role_registry.py — Role 注册表（含默认 system prompt 模板）
  7. 示例 examples/meta_review_v2/run_review.py — 三个 reviewer Actor 用 role = architect/safety_auditor/ecosystem_observer 注册

向后兼容

现有的 v2_demo 中 analyst-a / designer-b / dev-c 三个 Actor 改为注册 role = "analyst" / "designer" / "developer"，逻辑不变。参考实现中的系统提示词（不含工具的模拟模式）暂放在 v2_demo 内，不要求立即提取到 ROLE_REGISTRY——register_actor 增加 description: str = "" 可选参数兜底自定义提示。

追问

  1. role 的粒度和原子性怎么定？——一个 Actor 可以有多个 role 吗（一个 Actor 同时是 developer 和 reviewer）？
  2. required_role 可由谁指定——只有 Bazaar 可以，还是 Actor 也能在 publish_subtask 时指定？
  3. 元评审场景中三个评审角色（architect/safety_auditor/ecosystem_observer）的 role 是否应隔离在独立的 role 名称空间？
## 背景 当前的 `Actor` 注册模型基于 **Capability（能力声明）**： ```python actor = Actor(actor_id="analyst-a", capabilities=[ Capability(type="analysis", name="需求分析", priority=9), ]) Bazaar 通过匹配 type 来分配任务。 ``` 但这个模型有两个根本问题： ### 问题 1：LLM 的能力声明不可靠 Actor 背后的 LLM 什么都能做。`Capability(type="analysis")` 不约束它实际能做什么，也无法验证——一个 Actor 声称有 "safety_audit" 能力，但 LLM 调用时完全可能做错或拒绝。集市不应该依赖 Actor 对自身能力的声明来做匹配。 ### 问题 2：Actor 实例可被淘汰，但角色的期望是固定的 集市的目的之一是让 Actor 可被替换。今天跑的是 `analyst-001`（Claude），明天可以换 `analyst-002`（GPT-5）。但集市需要的不是一个特定实例，而是一个**能满足架构评审需求的可信方**。当前按 `actor_id` 或 `capability.type` 匹配的方式，把实例身份和能力类型耦合在一起，违背了集市的设计初衷。 ## 提议：从「能力声明」到「角色声明」 将 Actor 的注册单元从 **Capability（能力）** 改为 **Role（角色）**。 ```python # ─── 角色注册表（集中管理）─── ROLE_REGISTRY = { "architect": { "description": "关注系统的抽象完整性和架构一致性", "system_prompt": "你是一位架构师...", }, "analyst": { "description": "需求分析、流程梳理", "system_prompt": "你是一位分析师...", }, "developer": { "description": "编码实现", "system_prompt": "你是一位开发工程师...", }, } # ─── Actor 注册（只注册 role）─── actor = Actor(actor_id="architect-001", role="architect", llm=llm) bazaar.register_actor(actor_id="architect-001", role="architect") # ─── 任务发布（指定 required_role）─── await bazaar.post_subtask( parent_task_id=..., required_role="architect", description="对认证模块做架构评审...", ) ``` ### 关键变化 | 当前 | 提议 | |------|------| | `Actor.capabilities`（dict[str, Capability]，以 type 为 key） | `Actor.role: str` | | `Capability(type, priority, max_concurrency)` | 并发控制独立为 `LoadSlot(max_concurrency)` | | Bazaar 匹配：按 `type` 匹配 + `score()` 排序 | Bazaar 匹配：按 `required_role == actor.role` 精确匹配 | | Actor 自定义 `Capability.description` 做 system prompt | Role Registry 统一管理每个 role 的 system prompt | ### 改动范围 1. **`bootstrap/actor.py`** — `Actor` 简化，去掉 `capabilities` 字典，改为 `role: str` + 一个轻量并发槽 2. **`bixiweave/actor.py`** — 同上，`to_capability_list()` → `to_role_declaration()` 3. **`bootstrap/bazaar.py`** — `_actor_scores` 删除，认领逻辑只匹配 `required_role == actor.role` 4. **`bootstrap/v2_demo.py`** — 注册方式改为 `register_actor(id, role)`，`ROLE_REGISTRY` 集中定义 5. **`bootstrap/warden.py`** — 展示 role 而非 capability 列表 6. **新文件 `bootstrap/role_registry.py`** — Role 注册表（含默认 system prompt 模板） 7. **示例 `examples/meta_review_v2/run_review.py`** — 三个 reviewer Actor 用 role = architect/safety_auditor/ecosystem_observer 注册 ### 向后兼容 现有的 v2_demo 中 analyst-a / designer-b / dev-c 三个 Actor 改为注册 role = "analyst" / "designer" / "developer"，逻辑不变。参考实现中的系统提示词（不含工具的模拟模式）暂放在 v2_demo 内，不要求立即提取到 ROLE_REGISTRY——`register_actor` 增加 `description: str = ""` 可选参数兜底自定义提示。 ### 追问 1. role 的粒度和原子性怎么定？——一个 Actor 可以有多个 role 吗（一个 Actor 同时是 developer 和 reviewer）？ 2. `required_role` 可由谁指定——只有 Bazaar 可以，还是 Actor 也能在 publish_subtask 时指定？ 3. 元评审场景中三个评审角色（architect/safety_auditor/ecosystem_observer）的 role 是否应隔离在独立的 role 名称空间？
orion commented 2026-06-14 14:23:56 +08:00
Author
Owner
Copy link

已提交实现：0330c37

改动总结

文件 状态
bootstrap/role_registry.py 新增 — 角色注册表（analyst/designer/developer/architect/safety_auditor/ecosystem_observer）
bootstrap/actor.py 重写 — Actor 不再有 Capability，只持有 role: str
bootstrap/bazaar.py 重写 — register_actor(id, role)，认领按 required_role 匹配
bixiweave/actor.py 重写 — 同上，to_capability_list() 删除，to_role_declaration() 替代
bootstrap/v2_demo.py 更新 — 使用新接口

未解决的问题（见 issue 中的追问）

  1. 一个 Actor 可以有多个 role 吗？ 当前设计是一个 Actor 一个 role，如果需要多个角色（如 developer+reviewer），是注册多个 Actor 还是允许多 role 绑定？
  2. required_role 的指定权 — 当前只有 Bazaar 的 post_subtask 能指定 required_role，Actor 发布子任务时也能指定（通过 post_subtask 的参数传递）
  3. 元评审的 role 命名空间 — architect/safety_auditor/ecosystem_observer 这三个评审角色要不要跟 analyst/designer/developer 共用名称空间？我的倾向是共用，评审也是集市中的标准角色
已提交实现：`0330c37` ### 改动总结 | 文件 | 状态 | |------|------| | `bootstrap/role_registry.py` | 新增 — 角色注册表（analyst/designer/developer/architect/safety_auditor/ecosystem_observer） | | `bootstrap/actor.py` | 重写 — Actor 不再有 `Capability`，只持有 `role: str` | | `bootstrap/bazaar.py` | 重写 — `register_actor(id, role)`，认领按 `required_role` 匹配 | | `bixiweave/actor.py` | 重写 — 同上，`to_capability_list()` 删除，`to_role_declaration()` 替代 | | `bootstrap/v2_demo.py` | 更新 — 使用新接口 | ### 未解决的问题（见 issue 中的追问） 1. **一个 Actor 可以有多个 role 吗？** 当前设计是一个 Actor 一个 role，如果需要多个角色（如 developer+reviewer），是注册多个 Actor 还是允许多 role 绑定？ 2. **required_role 的指定权** — 当前只有 Bazaar 的 `post_subtask` 能指定 required_role，Actor 发布子任务时也能指定（通过 `post_subtask` 的参数传递） 3. **元评审的 role 命名空间** — architect/safety_auditor/ecosystem_observer 这三个评审角色要不要跟 analyst/designer/developer 共用名称空间？我的倾向是共用，评审也是集市中的标准角色
orion commented 2026-06-14 15:08:21 +08:00
Author
Owner
Copy link

元评审 v2 示例已完成：4a2a00b

examples/meta_review_v2/run_review.py — 集市模式三轮深度评估

用法

# 模拟模式（验证流程走通）
python3 examples/meta_review_v2/run_review.py --mock

# LLM 模式（调用 DeepSeek，MCP 读取源码）
export DEEPSEEK_API_KEY=sk-xxx
python3 examples/meta_review_v2/run_review.py

三轮评审

  • 第一轮：3 个 review 子任务同时发布，按 required_role 精确路由到对应 Actor
  • 第二轮：每个 Actor 以其第一轮产出为 parent，继承 artifacts 后发布质疑
  • 第三轮：同理，基于两轮产出发表最终独立意见

模拟模式试验结果（--mock）

  • 10 个任务全部完成（1 goal + 9 review）
  • 3 个 Actor 各认领 3-4 个任务（architect 额外领了 goal）
  • 角色精准匹配，无错配

配套改进

  • bootstrap/actor.py: required_role 匹配时 100% 认领，不随机
  • bootstrap/bazaar.py: retry.claim 事件处理，解决负载满并发竞态
元评审 v2 示例已完成：`4a2a00b` `examples/meta_review_v2/run_review.py` — 集市模式三轮深度评估 **用法** ```bash # 模拟模式（验证流程走通） python3 examples/meta_review_v2/run_review.py --mock # LLM 模式（调用 DeepSeek，MCP 读取源码） export DEEPSEEK_API_KEY=sk-xxx python3 examples/meta_review_v2/run_review.py ``` **三轮评审** - 第一轮：3 个 review 子任务同时发布，按 `required_role` 精确路由到对应 Actor - 第二轮：每个 Actor 以其第一轮产出为 parent，继承 artifacts 后发布质疑 - 第三轮：同理，基于两轮产出发表最终独立意见 **模拟模式试验结果**（`--mock`） - 10 个任务全部完成（1 goal + 9 review） - 3 个 Actor 各认领 3-4 个任务（architect 额外领了 goal） - 角色精准匹配，无错配 **配套改进** - `bootstrap/actor.py`: `required_role` 匹配时 100% 认领，不随机 - `bootstrap/bazaar.py`: `retry.claim` 事件处理，解决负载满并发竞态
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v3
v2-architecture
No results found.
Labels
Clear labels   
RFC
设计评审 / Request For Comments

  
bootstrap
自举流程标记 — 进入 bixiweave 自举流水线的 Issue

  
discuss
需讨论设计后再动手

  
dsl
DSL 模板、编译、校验

  
epic
长期跟踪的大功能，跨多个 PR/commit

  
feat
新功能

  
pipeline
Pipeline 引擎相关

  
v2
v2 架构相关

No labels
RFC
bootstrap
discuss
dsl
epic
feat
pipeline
v2
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
bixiu/bixiweave#41
No description provided.