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

流模板系统 — 元策略模板的注册、选择与填充机制 #2

New issue
Open
opened 2026-06-11 06:56:00 +08:00 by shaotao · 4 comments
shaotao commented 2026-06-11 06:56:00 +08:00
Owner
Copy link

目标

让用户能注册和选择元策略模板（如对偶机、链式、分段审议），填入 Agent 的状态机定义后，编译器自动生成多 Agent 协作系统。

需要讨论和确定

  • 流模板的格式定义（JSON Schema）
  • 模板注册机制（注册到哪？代码目录？配置中心？策略库？）
  • 用户选择模板的方式（CLI？Python API？配置文件？）
  • 模板参数填充的校验机制
  • 与现有编译器的接口对接

依赖

  • 现有 DSL + compiler 基础设施已就绪
  • bootstrap/flows/ 目录已有一些 JSON 定义可以作为模板素材

产出

  • 一个可用的流模板注册 + 填充 + 生成链路
  • 至少一个验证过的模板（如对偶机）

隶属于里程碑：v0.2 — 流模板系统

## 目标 让用户能注册和选择元策略模板（如对偶机、链式、分段审议），填入 Agent 的状态机定义后，编译器自动生成多 Agent 协作系统。 ## 需要讨论和确定 - 流模板的格式定义（JSON Schema） - 模板注册机制（注册到哪？代码目录？配置中心？策略库？） - 用户选择模板的方式（CLI？Python API？配置文件？） - 模板参数填充的校验机制 - 与现有编译器的接口对接 ## 依赖 - 现有 DSL + compiler 基础设施已就绪 - `bootstrap/flows/` 目录已有一些 JSON 定义可以作为模板素材 ## 产出 - 一个可用的流模板注册 + 填充 + 生成链路 - 至少一个验证过的模板（如对偶机） 隶属于里程碑：v0.2 — 流模板系统
shaotao added this to the bixiweave project 2026-06-11 16:49:04 +08:00
shaotao self-assigned this 2026-06-12 07:23:38 +08:00
shaotao removed their assignment 2026-06-12 07:24:32 +08:00
shaotao commented 2026-06-12 07:30:41 +08:00
Author
Owner
Copy link

关于流模板设计的思考

昨晚在 examples/decoupled_demo/ 里写了一个解耦 demo（已提交 main），核心想法是 Agent / DSL / Tools 三层分离。

现状问题

现在 bootstrap/flows/ 里的每个 Agent 定义（aligner_agent.json、dev_agent.json...）都绑死了具体的状态机 JSON，Python 代码和 JSON 互相引用、互相依赖。加一个新场景就要新建 JSON + 写一堆 Python handler。

解耦思路

Agent = 角色 + 能力（谁来做）

  • 定义：name, role, system_prompt, model, tools
  • 可复用：Writer / Reviewer / Tester / Analyzer / Aligner
  • 不关心谁来用、怎么用

DSL（流模板） = 步骤声明（做什么）

  • 一个有向无环图（DAG）的任务声明
  • 只声明需要什么角色，不指定具体 Agent
  • 可复用：code_review / cross_review(3x) / write_review_test

Tools = 工具（用什么做）

  • MCP 工具注册，独立于 Agent 和 DSL
  • 可插拔：Git / ForgejoAPI / 文件系统 / 搜索

Pipeline = 组合以上三者（怎么组织）

  • 运行时将 DSL 的角色绑定到 Agent 池
  • 传入 context（代码、需求、配置）

这样做的好处

  1. 加新场景 → 写个 DSL 就行，不用动 Agent
  2. 换模型/工具 → 改 Agent 配置就行，不用动 DSL
  3. 多 Actor 交叉评审 → pool 里放多个同角色 Agent
  4. 模板注册 → DSL 就是模板，注册到策略库即可
  5. 模板选择 → 用户选 DSL，系统自动匹配 Agent

跟现有编译器的关系

compiler 目前处理的是状态机（SM）的编译，而流模板是更上层的编排层。两者可以共存：

  • 流模板定义"谁在什么时候做什么"
  • 状态机定义"单个 Agent 内部怎么决策"
  • 编译器负责把两者合起来生成可运行的系统

下一步建议

  1. 定义 DSL 的 JSON Schema（流模板格式）
  2. 把 examples/decoupled_demo/ 的 demo 抽象成真正的模板
  3. 注册到 bootstrap/flows/ 作为内置模板
  4. compiler 对接模板系统
## 关于流模板设计的思考 昨晚在 examples/decoupled_demo/ 里写了一个解耦 demo（已提交 main），核心想法是 **Agent / DSL / Tools 三层分离**。 ### 现状问题 现在 `bootstrap/flows/` 里的每个 Agent 定义（aligner_agent.json、dev_agent.json...）都绑死了具体的状态机 JSON，Python 代码和 JSON 互相引用、互相依赖。加一个新场景就要新建 JSON + 写一堆 Python handler。 ### 解耦思路 **Agent** = 角色 + 能力（谁来做） - 定义：name, role, system_prompt, model, tools - 可复用：Writer / Reviewer / Tester / Analyzer / Aligner - 不关心谁来用、怎么用 **DSL（流模板）** = 步骤声明（做什么） - 一个有向无环图（DAG）的任务声明 - 只声明需要什么角色，不指定具体 Agent - 可复用：code_review / cross_review(3x) / write_review_test **Tools** = 工具（用什么做） - MCP 工具注册，独立于 Agent 和 DSL - 可插拔：Git / ForgejoAPI / 文件系统 / 搜索 **Pipeline** = 组合以上三者（怎么组织） - 运行时将 DSL 的角色绑定到 Agent 池 - 传入 context（代码、需求、配置） ### 这样做的好处 1. **加新场景** → 写个 DSL 就行，不用动 Agent 2. **换模型/工具** → 改 Agent 配置就行，不用动 DSL 3. **多 Actor 交叉评审** → pool 里放多个同角色 Agent 4. **模板注册** → DSL 就是模板，注册到策略库即可 5. **模板选择** → 用户选 DSL，系统自动匹配 Agent ### 跟现有编译器的关系 compiler 目前处理的是状态机（SM）的编译，而流模板是**更上层**的编排层。两者可以共存： - 流模板定义"谁在什么时候做什么" - 状态机定义"单个 Agent 内部怎么决策" - 编译器负责把两者合起来生成可运行的系统 ### 下一步建议 1. 定义 DSL 的 JSON Schema（流模板格式） 2. 把 examples/decoupled_demo/ 的 demo 抽象成真正的模板 3. 注册到 bootstrap/flows/ 作为内置模板 4. compiler 对接模板系统
orion commented 2026-06-12 07:36:41 +08:00
Owner
Copy link

用 orion 的身份测试评论 ✅

用 orion 的身份测试评论 ✅
orion commented 2026-06-12 08:00:35 +08:00
Owner
Copy link

解耦遇到的实际问题

在尝试把 demo 跟核心 Pipeline 对接时，发现了一个结构性问题。

Pipeline 的现状

核心 Pipeline 的步骤原语是 start / wait / send：

{"action": "start", "agent": "reviewer", "event": "START_REVIEW"}
{"action": "wait",  "agent": "reviewer", "state": "review_done"}

这些原语直接操作 Agent 内部状态机（发什么事件、等什么状态）。这意味着：

  1. DSL 作者必须知道 Agent 内部有哪些事件和状态
  2. Pipeline 跟 Agent 状态机强耦合
  3. 换一个 Agent 实现（比如换状态机定义），DSL 就要跟着改

问题本质

Pipeline 入侵了应用层。 它干的活本应是"谁做什么、结果给谁"的编排，却变成了直接操控 Agent 内部状态机的底层操作。

缺少一层抽象：

应用层 → 声明"谁做什么，需要什么输入"
编排层 → 解析依赖、调度执行、传递数据  ← 这里缺了
Agent 层 → 内部状态机

建议新增的编排层原语

Pipeline 应该只有编排语义的原语：

原语 语义 说明
run 执行 Agent 给 Agent 输入，等它输出结果，不关心内部状态名
parallel 并行 多个步骤同时执行
judge 条件分支 根据上一步结果选择不同路径
transform 数据转换 步骤间数据格式映射
foreach 循环 对列表中的每一项执行子流程

这样 DSL 变成：

{"action": "run", "agent": "reviewer", "role": "REVIEWER",
 "input": "$context.code", "output_key": "review_result"}

而不是：

{"action": "start", "agent": "reviewer", "event": "START_REVIEW"}
{"action": "wait",  "agent": "reviewer", "state": "review_done"}

对 v0.2 流模板的影响

如果这个抽象层做对了，流模板可以变得更纯粹：

  • 模板只声明"需要什么角色、做什么事"
  • 不关心 Agent 内部状态机叫什么状态、发什么事件
  • Agent 池负责把角色映射到具体实例
  • Pipeline 只做 DAG 解析和调度

跟 examples/decoupled_demo/ 的关系

现在的 demo 已经提交到 main，但它展示了错误的方向——它尝试用现有的 start/wait/send 原语来构建高层 DSL，结果发现被核心 API 的底层性卡住了。

建议：

  1. 先讨论清楚这层抽象的定义（上面的原语表只是一个起点）
  2. 确定后再修改 Pipeline 核心
  3. demo 重写为使用新原语的版本
## 解耦遇到的实际问题 在尝试把 demo 跟核心 Pipeline 对接时，发现了一个结构性问题。 ### Pipeline 的现状 核心 Pipeline 的步骤原语是 `start / wait / send`： ```json {"action": "start", "agent": "reviewer", "event": "START_REVIEW"} {"action": "wait", "agent": "reviewer", "state": "review_done"} ``` 这些原语直接操作 Agent 内部状态机（发什么事件、等什么状态）。这意味着： 1. DSL 作者**必须知道** Agent 内部有哪些事件和状态 2. Pipeline 跟 Agent 状态机**强耦合** 3. 换一个 Agent 实现（比如换状态机定义），DSL 就要跟着改 ### 问题本质 **Pipeline 入侵了应用层。** 它干的活本应是"谁做什么、结果给谁"的编排，却变成了直接操控 Agent 内部状态机的底层操作。 缺少一层抽象： ``` 应用层 → 声明"谁做什么，需要什么输入" 编排层 → 解析依赖、调度执行、传递数据 ← 这里缺了 Agent 层 → 内部状态机 ``` ### 建议新增的编排层原语 Pipeline 应该只有编排语义的原语： | 原语 | 语义 | 说明 | |------|------|------| | `run` | 执行 Agent | 给 Agent 输入，等它输出结果，不关心内部状态名 | | `parallel` | 并行 | 多个步骤同时执行 | | `judge` | 条件分支 | 根据上一步结果选择不同路径 | | `transform` | 数据转换 | 步骤间数据格式映射 | | `foreach` | 循环 | 对列表中的每一项执行子流程 | 这样 DSL 变成： ```json {"action": "run", "agent": "reviewer", "role": "REVIEWER", "input": "$context.code", "output_key": "review_result"} ``` 而不是： ```json {"action": "start", "agent": "reviewer", "event": "START_REVIEW"} {"action": "wait", "agent": "reviewer", "state": "review_done"} ``` ### 对 v0.2 流模板的影响 如果这个抽象层做对了，流模板可以变得更纯粹： - 模板只声明"需要什么角色、做什么事" - 不关心 Agent 内部状态机叫什么状态、发什么事件 - Agent 池负责把角色映射到具体实例 - Pipeline 只做 DAG 解析和调度 ### 跟 examples/decoupled_demo/ 的关系 现在的 demo 已经提交到 main，但它展示了错误的方向——它尝试用现有的 `start/wait/send` 原语来构建高层 DSL，结果发现被核心 API 的底层性卡住了。 建议： 1. 先讨论清楚这层抽象的定义（上面的原语表只是一个起点） 2. 确定后再修改 Pipeline 核心 3. demo 重写为使用新原语的版本
orion commented 2026-06-12 08:13:10 +08:00
Owner
Copy link

完成：编排层原语 + AgentCapability 契约

提交 986e41c，关联 #2。

改了什么

Pipeline 新增两层原语体系：

原语 语义 输入 输出
run 按角色执行 Agent 任务 agent, role 自动取结果到 context
parallel 并行执行多个分支 branches: [{steps}] 合并子 context
judge 条件分支 condition, cases: [{value, steps}] 匹配分支执行
transform 步骤间数据映射 from_key, to_key 复制 context 字段
foreach 列表循环 items_key, item_key, sub_steps 每项执行子流程

底层原语（start/wait/send）保持向后兼容。

AgentCapability 契约 — 定义 Agent 角色的交互接口：

REVIEWER = {
    "start_event": "START_REVIEW",
    "done_state": "review_done",
    "output_key": "review_result",
}

run 原语通过契约驱动 Agent，DSL 作者不需要知道内部状态机细节。

Demo 对比

改写前 cross_review_3x（12 步底层原语）：

{"action": "start",  "agent": "reviewer_1", "event": "START_REVIEW"},
{"action": "wait",   "agent": "reviewer_1", "state": "review_done"},
// ... 重复 3 次，再手动 send 给 aligner

改写后（2 步编排层原语）：

{"action": "parallel", "branches": [
    {"steps": [{"action": "run", "agent": "reviewer_1", "role": "REVIEWER"}]},
    {"steps": [{"action": "run", "agent": "reviewer_2", "role": "REVIEWER"}]},
    {"steps": [{"action": "run", "agent": "reviewer_3", "role": "REVIEWER"}]},
]},
{"action": "run", "agent": "aligner", "role": "ALIGNER"}

未完成（留给后面）

  • 模板注册机制（注册到哪？代码目录？配置中心？策略库？）
  • 流模板 JSON Schema 正式定义
  • compiler 对接模板系统
## 完成：编排层原语 + AgentCapability 契约 提交 `986e41c`，关联 #2。 ### 改了什么 **Pipeline 新增两层原语体系：** | 原语 | 语义 | 输入 | 输出 | |------|------|------|------| | `run` | 按角色执行 Agent 任务 | `agent`, `role` | 自动取结果到 context | | `parallel` | 并行执行多个分支 | `branches: [{steps}]` | 合并子 context | | `judge` | 条件分支 | `condition`, `cases: [{value, steps}]` | 匹配分支执行 | | `transform` | 步骤间数据映射 | `from_key`, `to_key` | 复制 context 字段 | | `foreach` | 列表循环 | `items_key`, `item_key`, `sub_steps` | 每项执行子流程 | 底层原语（`start/wait/send`）保持向后兼容。 **AgentCapability 契约** — 定义 Agent 角色的交互接口： ```python REVIEWER = { "start_event": "START_REVIEW", "done_state": "review_done", "output_key": "review_result", } ``` `run` 原语通过契约驱动 Agent，DSL 作者不需要知道内部状态机细节。 ### Demo 对比 改写前 `cross_review_3x`（12 步底层原语）： ```json {"action": "start", "agent": "reviewer_1", "event": "START_REVIEW"}, {"action": "wait", "agent": "reviewer_1", "state": "review_done"}, // ... 重复 3 次，再手动 send 给 aligner ``` 改写后（2 步编排层原语）： ```json {"action": "parallel", "branches": [ {"steps": [{"action": "run", "agent": "reviewer_1", "role": "REVIEWER"}]}, {"steps": [{"action": "run", "agent": "reviewer_2", "role": "REVIEWER"}]}, {"steps": [{"action": "run", "agent": "reviewer_3", "role": "REVIEWER"}]}, ]}, {"action": "run", "agent": "aligner", "role": "ALIGNER"} ``` ### 未完成（留给后面） - 模板注册机制（注册到哪？代码目录？配置中心？策略库？） - 流模板 JSON Schema 正式定义 - compiler 对接模板系统
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
discuss
需讨论设计后再动手

  
dsl
DSL 模板、编译、校验

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

  
feat
新功能

  
pipeline
Pipeline 引擎相关

No labels
discuss
dsl
epic
feat
pipeline
Milestone
Clear milestone
No items
Projects
Clear projects
No items
No project
bixiweave
Assignees
Clear assignees
No assignees
orion
2 participants
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#2
No description provided.