@bolloon/bolloon-agent 0.1.0 → 0.1.1

package/src/bollharness/reference/boll-reference/docs/architecture/INDEX.md

@@ -1,76 +0,0 @@
-# 流形网络架构文档（模块化）
-
-> 本目录从原 `docs/ARCHITECTURE_DESIGN.md`（2355 行，2026-02-08）拆分而来。
-> 原文档保留为历史参考。本目录是**当前权威来源**。
-
-## 状态标记
-
-| 标记 | 含义 |
-|------|------|
-| ✅ **已验证** | V2 已实现并验证 |
-| ⚠️ **待对齐** | V1 设计有价值，V2 实现偏离，需要讨论是否恢复/改造 |
-| 🔮 **远景** | 未来方向，当前不实现，保留供参考 |
-| ❌ **已迭代** | V1 概念已被 V2 更好的方案替代 |
-
-## 文档结构
-
-| 文件 | 内容 | 来源 Section |
-|------|------|-------------|
-| [PRINCIPLES.md](PRINCIPLES.md) | 设计原则（宪法） | §0 |
-| [PROTOCOL-CORE.md](PROTOCOL-CORE.md) | 协议核心：流程、Center 设计、状态、事件 | §1-4 |
-| [MODULE1-INTENT-FIELD.md](MODULE1-INTENT-FIELD.md) | 模块一：HDC 签名与共振检测 | §6 |
-| [MODULE2-CRYSTALLIZATION.md](MODULE2-CRYSTALLIZATION.md) | 模块二：协商/结晶引擎 + Skill 系统 | §2,3,10 |
-| [AGENT-PROFILE.md](AGENT-PROFILE.md) | Agent 接入、Profile、投影机制 | §1.3-1.4, §7 |
-| [VISION.md](VISION.md) | 远景层：P2P、递归、回声、经济、场景即产品 | §5,8,9,11,12,13 |
-
-## 讨论记录
-
-| 编号 | 标题 | 日期 | 状态 | 文档 |
-|------|------|------|------|------|
-| D-01 | 市场、场景与协议内置筛选 | 2026-02-26 | ✅ 讨论完成，待深入研究 | [discussions/D-01](discussions/D-01-MARKET-SCENE-PROTOCOL.md) |
-| D-02~D-05 | — | — | ✅ 被 D-01 重新定义/解决 | 见 D-01 §11 |
-| D-06 | 前端事件内容展示 | — | 待讨论 | — |
-| D-07 | 协议核心流程重审 | — | 待讨论（方向已由 D-01 确定） | — |
-| D-08 | Agent-Profile 模型对齐 | — | 面具概念已融入 D-01 | — |
-
-### D-01 核心结论（2026-02-26）
-
-**标签 = 产品 = 场景 = 应用。** 一个标签就是一个市场/应用。处理深度由场景定义，不需要系统判断。
-
-五个关键发现：
-1. **标签=场景=产品**：切换标签 = 切换应用，底层同一协议
-2. **端侧 Agent = 用户完整本地 AI**：流形是 MCP tool，不是沙盒
-3. **承诺上链 → 沉淀 → 搜索从响应中涌现**：市场从使用中长出来
-4. **面具 × 标签**：两个正交维度，组合覆盖所有场景
-5. **协议内置筛选**：HDC 编码 = 内容表示 = 路由地址 = 过滤标准
-
-**待深入**：分布式通信机制（NDN + HDC、Hamming DHT、语义 Gossip）
-
-### 原始讨论任务（已被 D-01 重新定义）
-
-<details>
-<summary>展开查看原始 D-01~D-08 任务定义</summary>
-
-```
-D-01: 需求密度分级 → 重新定义：场景定义处理规则
-D-02: 端侧 Agent 意愿 → 不需要我们实现：端侧 AI 天然能力
-D-03: 输出格式分级 → 场景定义
-D-04: 中途退出权 → 天然的：Agent 自主，拒绝进本地频道
-D-05: 指标公式 → 场景级指标
-D-06: 前端展示 → 独立，未讨论
-D-07: 流程重审 → 方向已定，待细化
-D-08: Agent-Profile → 面具概念融入 D-01
-```
-
-</details>
-
-## 阅读指南
-
-- **要快速了解设计哲学**: 读 PRINCIPLES.md
-- **要理解当前最大的 gap**: 读 MODULE2-CRYSTALLIZATION.md 的 V2 现实部分
-- **要理解已实现的部分**: 读 MODULE1-INTENT-FIELD.md
-- **要理解远景**: 读 VISION.md
-
-## 原始文档
-
-完整原始文档: [`docs/ARCHITECTURE_DESIGN.md`](../ARCHITECTURE_DESIGN.md)（2355 行，2026-02-08 最后更新）

package/src/bollharness/reference/boll-reference/docs/architecture/MODULE1-INTENT-FIELD.md

@@ -1,116 +0,0 @@
-# 模块一：HDC 签名与共振检测（意图场）
-
-> 来源: ARCHITECTURE_DESIGN.md §6
-> 状态: ✅ 大部分已实现
-> 实现位置: `backend/boll/field/`（12 文件，76 测试）
-
----
-
-## V2 实现现状
-
-| V1 设计 | V2 实现 | 状态 |
-|---------|---------|------|
-| 三层共振过滤（Bloom + HDC + LLM） | 只实现第二层（HDC） | ⚠️ 缺第三层 |
-| 端侧检测（每个Agent本地判断） | 集中式 MemoryField.match() | ❌ 已迭代（规模不需要端侧） |
-| SimHash + 10000维二进制超向量 | SimHash + 10000维 | ✅ |
-| k* 机制（期望响应数） | match_perspectives 返回 top-k | ✅ 概念实现 |
-| 信号广播 + Gossip 传播 | 集中式匹配 | ❌ 已迭代（规模不需要） |
-| sentence-transformers 编码 | sentence-transformers | ✅ |
-| 画像演化（数据源更新+重新投影） | DB profiles + 重新加载 | ✅ 简化版 |
-
-**V2 关键文件**: `encoding_pipeline.py`, `sim_hash.py`, `memory_field.py`, `match_engine.py`
-
----
-
-## 6.1 签名共振机制 ✅
-
-### 6.1.1 设计目标
-
-- **复杂度**: O(N+M)
-- **语义共振**: 不是标签匹配或分类，任何文本都能处理
-- **发现未知关联**: 通过超维干涉模式
-- **能量效率**: 99% 在低能耗层过滤
-
-### 6.1.2 核心机制：超维计算（HDC）
-
-所有信息表示为 D=10,000 维二进制超向量。
-
-| 操作 | 数学实现 | 作用 |
-|------|---------|------|
-| 绑定 (Bind) | XOR | 编码关系 |
-| 捆束 (Bundle) | 逐位加法+阈值化 | 创建复合画像 |
-| 相似度 | Hamming距离 | 判断共振强度 |
-
-**关键特性**: 捆束产生干涉模式——"分布式系统"+"共识"+"容错"捆束后会与"区块链治理"产生非零相似度。
-
-### 6.1.3 三层共振过滤 ⚠️ 第三层待恢复
-
-```
-第一层: Bloom Filter 门控     ~100ns, 过滤 ~90%    → 🔮 规模不需要
-第二层: HDC 共振检测           ~1μs, 过滤剩余 ~90%  → ✅ 已实现
-第三层: 深度评估（LLM）        ~10ms, 精确评估       → ⚠️ 未实现（关联 D-02）
-```
-
-**V1 决策**: 只实现第二层。第一层规模不需要，第三层用 LLM 替代。
-**V2 现实**: 第三层也没实现。匹配到就直接进结晶。
-
-### 6.1.4 编码流程 ✅
-
-```
-步骤一: 文本 → 语义嵌入（sentence-transformers, 768维浮点）
-步骤二: 浮点向量 → 二进制超向量（SimHash, 10000维）
-步骤三: 超向量绑定到 Agent 或消息（bundle 操作）
-```
-
-编码器可插拔：前期 sentence-transformers → 中期可换 OpenAI embedding → 后期可训练领域模型。
-
-### 6.1.5 Agent 画像生成与演化 ✅
-
-投影式画像生成（Design Log #003）:
-```
-ProfileDataSource.get_profile() → Profile Data
-    → 每项编码为超向量 → bundle → Agent 画像
-    = project(profile_data, lens)
-```
-
-画像不通过"融合"更新——数据源更新 + 重新投影。
-
-### 6.1.6 共振检测流程 ✅
-
-```
-需求文本 → 编码为 H_demand → 广播
-每个 Agent: similarity(H_agent, H_demand) > θ → 激活
-```
-
-### 6.1.7 传播机制
-
-- **V1/V2**: 简单广播（集中式匹配），1000 Agent 规模足够
-- **🔮 未来**: 语义 Gossip（万级以上规模）
-
-### 6.1.8 性能（1000 Agent, 100 消息/秒）✅
-
-| 指标 | 值 |
-|------|-----|
-| 每次共振检测 | < 100ns |
-| 1000 Agent 画像总内存 | ~1.2 MB |
-| CPU 占用 | ~1% |
-
-### 6.1.10 共振阈值策略（θ 与 k* 机制）⚠️ 概念实现
-
-> **V1 核心洞察**: θ 不是预设常数，从期望响应数 k* 计算。k* = 本质（业务参数），θ = 实现（技术参数）。
-
-**k* 为什么更好**:
-1. k* 是业务语言，θ 是技术参数
-2. k* 直接关联成本
-3. k* 与 N 解耦
-4. k* 可从场景语义推导
-
-**V2 实现**: `match_perspectives()` 和 `match()` 返回 top-k，本质上是 k* 的简化实现。
-
-**V1 场景示例**:
-- 黑客松（3-5人小队）→ k* = 15-20
-- 创业找联创 → k* = 5-10
-- 社交场景 → k* = 30-50
-- 专业服务 → k* = 3-5
-
-**🔮 V2+ 自适应策略**: 基于回声反馈自动调整 k*（Offer率 < 50% → k*减少；成功率 > 80% → k*增加）

package/src/bollharness/reference/boll-reference/docs/architecture/MODULE2-CRYSTALLIZATION.md

@@ -1,200 +0,0 @@
-# 模块二：协商/结晶引擎 + Skill 系统
-
-> 来源: ARCHITECTURE_DESIGN.md §2, §3, §10 + V2 结晶实验成果
-> 依赖: [PRINCIPLES.md](PRINCIPLES.md), [MODULE1-INTENT-FIELD.md](MODULE1-INTENT-FIELD.md)
-> **这是当前最大的 gap 所在——V1 设计有大量好东西被 V2 压缩掉了**
-> 关联讨论: D-01, D-02, D-03, D-04, D-05, D-07
-
----
-
-## V2 实现现状
-
-### 已验证的基础（不要忽略）
-
-- ✅ 结晶协议 13 条特性经 6 次实验验证
-- ✅ Bridge 全自动管道: dispatcher → Claude Code → 结晶 → complete → 前端
-- ✅ v2 基线固化: clarification-session_v1.1 + endpoint_v2 + catalyst_v2.1 + plan_v0
-- ✅ 159 tests passing
-- ✅ 产品化全栈: 注册、需求提交、匹配、结晶、进度推送、结果展示
-
-### 首次真实 Run 暴露的问题（2026-02-26）
-
-**现象**: "找几个人聊 AI"跑了 4 轮，输出 5000 字重型协作方案，指标失真（1500分钟节省、¥36,000）。
-
-**根因诊断**（不只是 prompt 问题，是流程层的决策点缺失）:
-
-| 缺失 | V1 设计位置 | 影响 |
-|------|------------|------|
-| Formulation 需求密度分级 | §1.2, §10.4 | 所有需求走同等重型流程 |
-| 端侧意愿判断 | §6.1.3 第三层, §10.6 | 匹配到就无条件投影 |
-| 中途退出权 | ADR-005 | 进来就跑完全程 |
-| 轻量输出路径 | §3.4 output_plan | 恒定输出完整 Plan |
-| 发送方偏好编码 | §1.2 | 双向编码只实现了接收方 |
-| 收敛准则 | §3.5 | 从"三准则"退化为"信息差耗尽" |
-
-### V2 vs V1 流程对比
-
-**V1 完整流程**（§10.2）:
-```
-① 用户意图
-② Formulation（密度判断 + 偏好编码 + 用户确认）
-③ HDC 共振（三层过滤）
-④ 并行 Offer（端侧独立生成，OfferGenerationSkill）
-⑤ 等待屏障（所有 Offer 到齐）
-⑥ Center 综合（工具调用模型）
-⑦ 工具执行（追问/发现/子需求/输出）
-⑧ 轮次控制（代码硬上限）
-```
-
-**V2 实际流程**:
-```
-用户提需求 → Formulation（单次 API，无密度判断）→ match()（只有第二层）→ 结晶（催化做 ②④⑤⑥⑦⑧ 的所有事）
-```
-
----
-
-## Skill 系统 ⚠️ 待对齐
-
-> **V1 设计**: 接口稳定 + 实现可进化，6 个 Skill 各有明确职责
-> **V2 现实**: 催化 prompt 吸收了多个 Skill 的职责，端侧 prompt 只做投影
-> **核心问题**: 催化承担太多，缺乏结构化约束
-
-### 设计理念 ✅
-
-Skill = 启用一个子 Agent。两层分离:
-- **接口层**（稳定）: 角色、职责、输入/输出、原则、约束
-- **实现层**（可进化）: 具体提示词、few-shot、CoT 引导
-
-两种类型:
-- **统一 Skill**: 所有实例同一逻辑（Center、SubNegotiation、GapRecursion）
-- **可定制 Skill**: 每个 Agent 有自己的版本（Formulation、Offer）
-
-### Skill 清单与生命周期
-
-| Skill | 类型 | 位置 | V2 状态 |
-|-------|------|------|---------|
-| **DemandFormulationSkill** | 可定制 | ② | ⚠️ 简化为单次 API，缺密度判断 |
-| **ReflectionSelectorSkill** | 可定制 | 注册/变更时 | ✅ 实现为 EncodingPipeline |
-| **OfferGenerationSkill** | 可定制 | ④ | ⚠️ 被催化吸收，端侧无独立 Offer |
-| **CenterCoordinatorSkill** | 统一 | ⑥ | ⚠️ 变为催化自由文本，工具模型丢失 |
-| **SubNegotiationSkill** | 统一 | ⑦ | 🔮 未实现 |
-| **GapRecursionSkill** | 统一 | ⑦ | 🔮 未实现 |
-
-### 10.4 DemandFormulationSkill ⚠️ 待对齐
-
-| 项目 | V1 设计 |
-|------|---------|
-| 角色 | 用户真实需求的理解者和表达者 |
-| 职责 | 基于 Profile 和上下文，将原始意图丰富化 |
-| 输入 | 用户原始意图 + Agent 的 Profile Data |
-| 输出 | 丰富化后的需求文本（供 HDC 编码和广播） |
-| 原则 | ① 理解"要求"背后的"需求" ② 保留意图，补充上下文 ③ 丰富化程度由用户控制 |
-| 约束 | 输出需经用户确认后才广播 |
-
-**V2 缺失**: 没有需求密度判断。V1 设计中这里应该决定低/中/高密度 → 影响后续轮次和输出格式。
-
-### 10.6 OfferGenerationSkill ⚠️ 待对齐
-
-| 项目 | V1 设计 |
-|------|---------|
-| 角色 | Agent 在协商中的发言人 |
-| 职责 | 基于真实 Profile，对需求给出诚实回应 |
-| 输入 | 需求文本 + Agent 自己的 Profile Data |
-| 输出 | Offer（我能贡献什么、什么相关经历） |
-| 原则 | ① 只描述 Profile 中记录的（不捏造）② 说清楚相关/不相关 ③ 元认知：意想不到的价值 |
-| 约束 | Prompt 中只有自己的 Profile，没有其他 Agent 信息 |
-
-**V2 现实**: 端侧 prompt（endpoint_v2）做的是"投影"——催化给上下文，端侧输出回复。没有独立的"我要不要参与"判断，也没有独立的 Offer 生成。
-
-**关键区别**: V1 端侧是**独立思考者**（读需求→判断要不要→生成 Offer）。V2 端侧是**催化的执行者**（催化问什么就答什么）。
-
-### 10.7 CenterCoordinatorSkill ⚠️ 待对齐
-
-| 项目 | V1 设计 |
-|------|---------|
-| 角色 | 多方资源综合规划者 |
-| 职责 | 综合所有 Offer，用工具推进协商 |
-| 输入 | 需求 + 所有 Offer + 用户偏好 + 历史（观察遮蔽） |
-| 工具集 | output_plan / create_machine / ask_agent / start_matching / create_sub_demand |
-| 核心规则 | 评估 Offer 能否满足需求，用工具推进 |
-| 约束 | 只在 Offer 到齐后调用；超过 2 轮限制工具集 |
-
-**V2 现实**: 催化做了 Center 的工作但没有工具约束。催化自由决定输出什么，没有程序层的结构化限制。
-
-### 10.10 Skill 优化机制（SkillPolisher）🔮
-
-接口稳定，实现可持续优化。SkillPolisher 不能改接口，只能优化 prompt。
-V2 用手动 prompt 迭代替代（实验驱动）。
-
----
-
-## V2 结晶协议已验证的特性
-
-> 来源: EXP-009 实验（SIM-001/002 + RUN-001~006）
-
-### 8 条已验证协议特性
-
-1. 投影函数张力依赖性
-2. 信息函数不变量多轮稳定性
-3. 投影张力锁定跨轮稳定性
-4. 收敛因=边界精度饱和
-5. 催化元认知
-6. 5轮=数据耗尽非带宽限制
-7. 逐对检查R1全覆盖
-8. Plan来源可追溯性
-
-### 关键实验结论
-
-- **v2 基线**在{模糊需求,精确需求}×{同质,差异化}的 2×2 条件空间验证通过
-- 催化元认知（"你看到了什么，你还没看到什么"）是有效的
-- 收敛 = 边界精度饱和，不是信息耗尽
-- 问题不在协议引擎层，在**流程决策层**（缺少门控和分级）
-
-### 当前 Prompt 版本链
-
-| Prompt | 版本 | 位置 | 备注 |
-|--------|------|------|------|
-| Formulation | v2 | `clarification-session.py:_SYSTEM_PROMPT` | PLAN-080 WP-04: 世界观注入 |
-| Formulation (实验) | v1.1 | `tests/convergence_poc/prompts/` | 四参数编码器 |
-| Endpoint | v2 | `tests/convergence_poc/prompts/` | |
-| Endpoint (收敛) | v3 | `endpoint_default.md` | PLAN-080 WP-01: [NEW_INFO]/[NO_NEW_INFO] 标记 |
-| Catalyst | v2.1 | `tests/convergence_poc/prompts/` | |
-| Plan | v0 | 同上 | |
-| Delivery | (催化内嵌) | — | |
-
----
-
-## 指标体系 ⚠️ 待对齐
-
-> **V2 公式**（ADR-015）:
-> - B1 节省时间 = total_output_chars / 100 × (1 + 2.0) 分钟
-> - B3 效率倍数 = 节省时间 / AI实际耗时
-> - B4 协作价值 = 参与人数 × 300元/小时 × 节省小时数
->
-> **问题**: 这些公式对高密度需求合理，对"找人聊天"产生 ¥36,000 的荒谬值。
-> **待讨论** (D-05): 指标基线跟需求密度走
-
----
-
-## 需要恢复的完整流程（讨论草案）
-
-> 这是 gap analysis 的初步方案，需要逐个讨论确认
-
-```
-模块 1（向量数学）→ 通过的 agent 列表
-    ↓
-模块 2 入口:
-    ├── 需求密度判断（分流: 低/中/高）     ← D-01
-    ├── 端侧 Agent 意愿判断                ← D-02
-    │     ├── 不感兴趣 → 退出
-    │     └── 感兴趣 → 进入结晶
-    ↓
-结晶循环（端侧投影 → 催化观察 → 下一轮）
-    ↓ 每轮端侧保留退出权                   ← D-04
-    ↓
-收敛 / 达到最大轮次
-    ↓
-输出格式跟密度走:                           ← D-03
-    低密度 → 推荐卡片
-    高密度 → 完整协作方案
-```

package/src/bollharness/reference/boll-reference/docs/architecture/PRINCIPLES.md

@@ -1,84 +0,0 @@
-# 设计原则
-
-> 来源: ARCHITECTURE_DESIGN.md §0
-> 状态: ✅ 全部有效——这是宪法，指导所有设计决策
-
-## 0.1 最小完整单元 ≠ MVP
-
-- 传统MVP：砍功能、简化、先上线再说
-- 最小完整单元：找到系统的原子，这个原子本身就是完整的、可递归的
-
-## 0.2 本质与实现分离
-
-- 本质（协议层）应该稳定
-- 实现（基础设施层）可以替换
-
-## 0.3 复杂度目标
-
-- 目标：O(N+M) 而非 O(N×M)
-- 方法：签名广播 + 端侧检测 + 分层过滤
-
-## 0.4 计算分布在端侧
-
-- 避免中心化瓶颈
-- 每个节点只处理自己相关的部分
-
-## 0.5 代码保障 > Prompt 保障（2026-02-06）
-
-- 凡是能用代码保障的确定性逻辑，绝不用 prompt 保障
-- 程序层控制流程（等待屏障、轮次计数、状态机），能力层提供智能（LLM 调用）
-- 研究支撑：LLM 有结构性偏见（第一提案偏见 10-30x），prompt 无法可靠消除，代码可以
-
-## 0.6 需求 ≠ 要求（2026-02-07）
-
-- 需求是抽象的张力（真正需要什么），要求是具象的假设性解法（以为怎么满足）
-- 不按用户的"要求"做硬筛选——会杀死发现未知价值的能力
-- 用户偏好通过需求 clarification-session 和 Center context 表达，不通过硬过滤
-
-## 0.7 复杂性从简单规则中生长
-
-- 好的架构不是设计出来的复杂性，而是简单规则递归产生的复杂性
-- 如果需要很多特殊情况处理，说明基础规则没有找对
-
-## 0.8 投影是基本操作（2026-02-07）
-
-- 系统中每一步都是同一个操作：丰富的东西通过透镜变成聚焦的东西
-- "自"→投影→"我"；需求→编码→签名；多Offer→聚合→方案；缺口→递归→子需求
-- 反过来：多个聚焦的投影重新组合，还原出比任何单一投影更丰富的东西（协商的本质）
-
-## 0.9 完备性 ≠ 完全性（2026-02-07）
-
-- 完全性：把所有信息复制一份装进来（不可能，也不必要）
-- 完备性：与信息场保持连通，需要时可以触达（全息原理）
-- "自"在系统之外。系统中只有"我"（投影）。Profile Data 是"自"的数据影子，不是"自"本身
-
-## 0.10 一自多我（2026-02-07）
-
-- 一个人可以有多个投影（Edge Agent + Service Agents / 面具），不是一人一Agent
-- 面具可以手动创建（场景透镜）或经验沉淀（聚类结晶），本质上是同一个操作：投影
-- 结构层数不预设，从使用中涌现
-
-## 0.11 协商是快照上的操作（2026-02-08）
-
-- 协商单元操作于世界的**快照**，不操作于世界的实时状态
-- 协商开始时拍快照：参与 Agent 的向量、需求的当前版本。整个协商在此快照上运行
-- 外部变化不影响进行中的协商，在下次协商中自然生效
-
-## 0.12 投影不承诺，人承诺（2026-02-08）
-
-- Agent 是投影，不是行为者。Agent 呈现信息、提供建议，人做最终决策
-- 系统只需保证：信息呈现的一致性（快照隔离）和操作的幂等性（唯一 ID 去重）
-
----
-
-## V2 对齐检查
-
-以下原则在 V2 实现中需要关注的偏离：
-
-| 原则 | V2 偏离情况 | 待讨论 |
-|------|-----------|--------|
-| 0.3 分层过滤 | 三层只实现了第二层，缺第三层（LLM 深度评估） | D-02 |
-| 0.4 端侧计算 | V2 全集中式（合理的阶段选择，非偏离） | — |
-| 0.5 代码保障 > Prompt | 催化的轮次控制、收敛判断都在 prompt 里 | D-07 |
-| 0.6 需求≠要求 | Formulation 没有做需求密度判断 | D-01 |
-| 0.10 一自多我 | V2 一人一 Agent（合理简化） | D-08 |

package/src/bollharness/reference/boll-reference/docs/architecture/PROTOCOL-CORE.md

@@ -1,209 +0,0 @@
-# 协议核心：流程、Center 设计、状态、事件
-
-> 来源: ARCHITECTURE_DESIGN.md §1-4
-> 依赖: [PRINCIPLES.md](PRINCIPLES.md)
-> 关联讨论: D-01, D-03, D-07
-
----
-
-## 1. 最小完整单元 ⚠️ 待对齐
-
-> **V1 设计**: 8 步完整流程，每步有明确的决策点和 Skill
-> **V2 现实**: 压缩为 需求→Formulation(单次API)→match()→结晶（催化做一切）
-> **讨论点**: 哪些被压缩掉的决策点需要恢复？
-
-### 1.1 V1 核心流程
-
-```
-用户表达意图（原始的、可能模糊的）
-    ↓
-【需求clarification-session】用户Agent基于Profile理解真实需求，丰富化
-    用户确认 → 编码为HDC签名 → 广播
-    ↓
-【供给方共振】端侧Agent本地共振检测：这个信号跟我有关吗？
-    ↓
-通过共振的Agent用大模型读取需求，给出Offer
-    ↓
-Offer收集完毕（等待屏障）
-    ↓
-中心Agent综合所有Offer，设计方案
-    （用户偏好/约束作为Center的context输入，Center有权建议放宽）
-    ↓
-判断是否有Gap → 如果有，递归处理子需求
-    ↓
-方案输出（协商的自然终止态）
-    ├─ plan → 文本方案（信息类/建议类需求）
-    └─ contract → 可执行合约 → WOWOK Machine → 执行阶段
-```
-
-### 1.2 需求 Formulation 与共振筛选 ⚠️ 待对齐
-
-> **V2 缺失**: Formulation 没有做需求密度判断，没有编织偏好进签名（双向编码只实现了接收方）
-
-**V1 设计要点**:
-
-- **需求 ≠ 要求**（原则 0.6）。需求是抽象张力，要求是假设性解法
-- 需求方偏好通过**两个位置**表达:
-
-| 位置 | 时机 | 机制 |
-|------|------|------|
-| 需求 clarification-session（前置） | 广播前 | 用户Agent丰富化需求，偏好编织进HDC签名 |
-| Center context（后置） | 综合时 | 用户偏好/约束作为Center输入 |
-
-- Formulation 是**可插拔**的：从"基本原样+补充Profile信息"到"Agent大幅重构需求"
-- **不做独立的需求方筛选**: HDC 共振已做语义过滤，Center 综合已包含选人智能
-
-### 1.3 "自-我"工程映射 → 见 [AGENT-PROFILE.md](AGENT-PROFILE.md)
-
-### 1.4 场景（Scene）→ 见 [AGENT-PROFILE.md](AGENT-PROFILE.md)
-
----
-
-## 2. 协作组内交流机制 ⚠️ 待对齐
-
-> **V2 现实**: 结晶协议重新实现了轮次管理。V1 的"端侧独立回复→Center聚合"变成了"催化统一编排"
-> **讨论点**: V1 的端侧独立性是否需要恢复？
-
-### 2.1 交流粒度
-
-**轮次级别（回合制）**——每次交流是完整轮次，中心Agent收集所有Agent本轮输入后聚合。
-
-### 2.2 交流拓扑
-
-**中心化架构**——主要: 端侧Agent ↔ 中心Agent（一对一）。例外: 端侧 ↔ 端侧（P2P，由中心触发）。
-
-### 2.3 轮次管理
-
-- 等所有Agent都回复才进入下一轮
-- Agent选择退出则立即退出（AI不需要"软性退出"）
-
-### 2.4 一个轮次的流程
-
-```
-中心Agent向所有端侧Agent发送本轮信息
-    ↓
-端侧Agent各自处理，生成回复
-    ↓
-中心Agent收集所有回复
-    ↓
-中心Agent聚合/分析/决策
-    ↓
-进入下一轮或结束
-```
-
----
-
-## 3. Center Agent 设计 ⚠️ 待对齐
-
-> **V1 设计**: Center = 拿着工具集的 Agent（tool use 模型）
-> **V2 现实**: Catalyst = 自由文本输出的协调者。工具调用模型丢失了。
-> **关键问题**: V1 的结构化约束 vs V2 的灵活性，怎么取舍？
-
-### 3.1 角色定位
-
-Center 是**多方资源综合规划者**。不是"传话筒"，也不是"绝对理性裁判"。
-设计原则：**用代码消除已知偏见，用 prompt 引导元认知**。
-
-### 3.2 输入
-
-- 需求文本（经 clarification-session 丰富化）
-- 所有 Offer（程序层等待屏障保障完整性）
-- 用户偏好/约束
-- 历史（观察遮蔽格式：保留推理，遮蔽原始 Offer）
-
-### 3.3 决策规则
-
-| 优先级 | 规则 |
-|--------|------|
-| 1 | 满足需求 |
-| 2 | 通过率（涉及各方会不会同意） |
-| 3 | 效率 |
-
-### 3.4 Center 工具集 ⚠️ 待对齐
-
-> **V1**: 5 个结构化工具，代码约束行为空间
-> **V2**: 催化自由文本输出，没有工具约束
-> **讨论点**: 是否恢复工具调用模型？
-
-| 工具 | 作用 | 程序层后续 |
-|------|------|----------|
-| `output_plan(content)` | 输出文本方案 | 协商终止 |
-| `create_machine(json)` | 创建 WOWOK Machine 草案 | 上链（V2 不涉及） |
-| `ask_agent(agent_id, question)` | 向指定 Agent 追问 | 转发问题，收回复后重新调用 Center |
-| `start_matching(a, b, reason)` | 触发发现性对话 | SubNegotiationSkill |
-| `create_sub_demand(gap)` | 生成子需求 | 启动新协商（递归） |
-
-**关键设计**: 工具不互斥（可组合）。工具集即边界（LLM 不能做工具集以外的事）。可扩展（新能力=新工具）。
-
-### 3.5 工作模式
-
-**程序层代码保障**（不依赖 prompt）:
-
-| 保障 | 机制 |
-|------|------|
-| 消除第一提案偏见 | 等待屏障：所有 Offer 到齐才调用 Center |
-| 防止无限循环 | 轮次计数器 |
-| 控制 context 质量 | 观察遮蔽 |
-| 限制行为空间 | 工具集本身就是边界 |
-
-研究支撑:
-- **多轮迭代**: Google DeepMind（2025）平均效果 -3.5%，错误放大 4.4x
-- **观察遮蔽**: JetBrains Research（2025）遮蔽比摘要更好，成本低 50%
-
-### 3.6 协议层事件语义
-
-> **对齐状态** (2026-04-03 PLAN-080 WP-03): Bridge 进度事件通过 `event_translator.py` 翻译为协议级事件。
-> 翻译层是事件字符串的单一真相源 (INV-4)。
-
-**协商阶段事件**:
-
-| 事件 | 语义 | Bridge 映射 |
-|------|------|-------------|
-| `demand.formulate` | 用户 Agent 将原始意图丰富化为需求表达 | `clarification-session.completed` |
-| `demand.broadcast` | 存在体向网络发出信号，表达状态张力 | — |
-| `offer.submit` | 存在体对需求信号产生响应 | `endpoint.completed` |
-| `catalyst.observe` | 催化者观察本轮响应，生成综合 | `catalyst.observation` |
-| `plan.generate` | 多个响应被聚合整合为综合方案 | `plan.generated` |
-| `delivery.complete` | 个性化交付生成完毕 | `delivery.completed` |
-| `gap.identify` | 方案中发现无法被现有响应满足的部分 | — |
-| `sub_demand.create` | 缺口转化为子需求，触发递归 | — |
-
-**方案确认**（V1 决策）: "确认"不是独立步骤，而是协商的三种穷举终止态——有异议（继续）、退出、无异议（即确认）。
-
----
-
-## 4. 状态管理 ⚠️ 待对齐
-
-> **V2 现实**: PostgreSQL runs 表 + status 字段（queued/running/done/failed）+ Bridge heartbeat
-> **V1 设计**: 更细粒度的协作组状态 + Agent 状态
-
-### 4.1 设计原则
-
-能少一个环节就少一个环节。
-
-### 4.2 协作组状态
-
-V1 只需两个状态: `negotiating` | `completed`（不需要 forming/confirming/failed/cancelled——协商总会有结果）
-
-### 4.3 Agent 状态 ⚠️ 待对齐
-
-> **V2 缺失**: 没有 Agent 级别的状态跟踪
-
-| 状态 | 描述 |
-|------|------|
-| `active` | 活跃，参与协商 |
-| `replied` | 本轮已回复 |
-| `exited` | 已退出 |
-
-### 4.4 状态检测
-
-**核心假设**: Agent 是 AI，不是人。AI 不会"忘记回复"或"拖延"。每个 Agent 要么回复，要么退出。
-**协议层不需要超时**——超时是基础设施层的容错。
-
-### 4.5 等待屏障（Barrier）⚠️ 待对齐
-
-> **V2 缺失**: 没有等待屏障。催化直接编排所有参与者。
-
-程序层维护"待响应列表"。每收到一个 Offer 或退出通知，从列表移除。列表为空 → 进入 Center 综合。
-
-**这是对抗第一提案偏见的结构性保障**（原则 0.5 代码保障 > Prompt 保障）。