@bolloon/bolloon-agent 0.1.0

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

@@ -0,0 +1,76 @@
+# 流形网络架构文档（模块化）
+
+> 本目录从原 `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

@@ -0,0 +1,116 @@
+# 模块一：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

@@ -0,0 +1,200 @@
+# 模块二：协商/结晶引擎 + 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

@@ -0,0 +1,84 @@
+# 设计原则
+
+> 来源: 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

@@ -0,0 +1,209 @@
+# 协议核心：流程、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 保障）。