feat(org): add standard parallel v0.1 blueprint, dispatch rules, and acceptance checklist
This commit is contained in:
Chen Gu
@@ -0,0 +1,158 @@
|
||||
# 标准并行 v0.1 实施蓝图
|
||||
|
||||
版本：v0.1
|
||||
日期：2026-03-09
|
||||
负责人：Val（提交谷老板拍板）
|
||||
|
||||
## 1) 目标与范围
|
||||
|
||||
### 目标
|
||||
在不追求全角色一次性上线的前提下，先完成最小可用标准并行闭环：
|
||||
|
||||
**Helix（规划）→ Sentinel（审计）→ Anvil（执行）**
|
||||
|
||||
### 本期范围
|
||||
- 角色实例化：Helix / Sentinel / Anvil
|
||||
- 调度规则：路由、并发、门禁、失败升级
|
||||
- 可观测：任务日志字段统一 + 每日摘要
|
||||
|
||||
### 非范围（后续迭代）
|
||||
- 全角色实例化（Vector / Quanta / Bastion / Prism / Catalyst / Echo）
|
||||
- 自动预算调优
|
||||
- 自动策略学习
|
||||
|
||||
---
|
||||
|
||||
## 2) 设计原则
|
||||
|
||||
1. **安全与可控 > 吞吐速度**
|
||||
2. **先跑通闭环，再扩并发规模**
|
||||
3. **默认可追溯（无日志即视为未执行）**
|
||||
4. **高风险动作必须可上报、可暂停、可回滚**
|
||||
|
||||
---
|
||||
|
||||
## 3) 角色职责（v0.1）
|
||||
|
||||
## 3.1 Helix（Architect）
|
||||
- 输入：用户意图/需求
|
||||
- 产出：结构化任务单（目标、范围、步骤、风险、验收）
|
||||
- 允许工具：read / web_search / web_fetch / memory_search / sessions_spawn / sessions_send
|
||||
- 禁止：直接执行高风险动作（外发、不可逆变更）
|
||||
|
||||
## 3.2 Sentinel（Auditor）
|
||||
- 输入：Helix 任务单
|
||||
- 产出：PASS / SOFT_BLOCK / HARD_BLOCK（含审计理由）
|
||||
- 审计维度：安全、逻辑、成本
|
||||
- 允许工具：read / memory_search / session_status
|
||||
- 禁止：直接执行工程动作
|
||||
|
||||
## 3.3 Anvil（Works）
|
||||
- 输入：已放行任务单
|
||||
- 产出：执行记录、产物、复验证据
|
||||
- 允许工具：read / write / edit / exec / process
|
||||
- 约束：未放行不得执行；失败必须先归档证据
|
||||
|
||||
---
|
||||
|
||||
## 4) 调度链路与状态机
|
||||
|
||||
状态流：
|
||||
|
||||
Intake → Draft(Helix) → Audit(Sentinel) → Dispatch → Execute(Anvil) → Verify → Report → Archive
|
||||
|
||||
### 审计决策语义
|
||||
- PASS：进入 Dispatch/Execute
|
||||
- SOFT_BLOCK：补充信息后可重审
|
||||
- HARD_BLOCK：直接回收并上报
|
||||
|
||||
---
|
||||
|
||||
## 5) 并发策略（v0.1）
|
||||
|
||||
- 全局并发上限：`3`
|
||||
- 单角色并发上限：`2`
|
||||
- 排队策略：优先级 + FIFO
|
||||
- 优先级：urgent > high > normal > low
|
||||
|
||||
### 触发保护
|
||||
- 任务队列长度 > 20：触发节流（只收不发）
|
||||
- 任一角色连续失败 >= 2：自动降并发为 1，并上报
|
||||
|
||||
---
|
||||
|
||||
## 6) 门禁与升级规则
|
||||
|
||||
### 强制上报谷老板（任一命中）
|
||||
- 对外发送
|
||||
- 不可逆操作
|
||||
- 隐私边界跨越
|
||||
- 预算超阈
|
||||
- 审计高不确定
|
||||
|
||||
### 双签规则（沿用组织约束）
|
||||
- 生产级工程执行需满足：Sentinel + Bastion 双签
|
||||
- v0.1 若 Bastion 未实例化：由 Val 代行安全签，并记录 `security_sign_proxy_by=Val`
|
||||
|
||||
### 失败处理
|
||||
- 所有失败进入 Failure 模板：
|
||||
- 失败阶段
|
||||
- 根因定位
|
||||
- 修复方案 A/B
|
||||
- 回滚策略
|
||||
- 是否升级
|
||||
|
||||
---
|
||||
|
||||
## 7) 可观测与日志规范
|
||||
|
||||
每个任务必须具备字段：
|
||||
- task_id
|
||||
- role
|
||||
- status
|
||||
- start_ts / end_ts
|
||||
- input_summary
|
||||
- tool_calls
|
||||
- artifacts
|
||||
- audit_decision
|
||||
- risk_level
|
||||
- token_cost
|
||||
- failure_reason
|
||||
- rollback_action
|
||||
- final_report
|
||||
|
||||
建议落盘：`org/logs/tasks/YYYY-MM-DD/<task_id>.json`
|
||||
|
||||
---
|
||||
|
||||
## 8) 验收标准（v0.1）
|
||||
|
||||
- [ ] 可并发处理 >= 3 条任务流且无串线
|
||||
- [ ] 每条任务可追溯决策/执行/审计责任
|
||||
- [ ] 任一失败可在 2 分钟内定位
|
||||
- [ ] 高风险动作 100% 命中上报门禁
|
||||
- [ ] 汇报格式统一：结论 + 证据 + 风险 + 选项
|
||||
|
||||
---
|
||||
|
||||
## 9) 实施节奏（3天）
|
||||
|
||||
### Day 1
|
||||
- 角色配置定稿（Helix/Sentinel/Anvil）
|
||||
- 工具白名单与禁止动作锁定
|
||||
|
||||
### Day 2
|
||||
- 调度器规则落地
|
||||
- 门禁/升级逻辑接入
|
||||
|
||||
### Day 3
|
||||
- 日志与看板打通
|
||||
- 并发压测 + 验收
|
||||
|
||||
---
|
||||
|
||||
## 10) v0.2 预告（可选）
|
||||
|
||||
- 新增 Vector（调度实例化）
|
||||
- 新增 Quanta（预算硬阈值自动刹车）
|
||||
- 新增 Bastion/Prism（安全签与失败收敛实例化）
|
||||
Reference in New Issue
Block a user