@bolloon/bolloon-agent 0.1.0 → 0.1.1

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

@@ -1,181 +0,0 @@
-# 远景层：P2P 发现、递归、回声、经济、场景即产品
-
-> 来源: ARCHITECTURE_DESIGN.md §5, §8, §9, §11, §12, §13
-> 状态: 🔮 全部为远景——当前不实现，保留设计方向
-> 这些概念在架构讨论中确立，代表系统的完整愿景。V2 先证明核心机制有效，这些层按需引入。
-
----
-
-## 5. Peer-to-Peer 发现性对话 🔮
-
-> 与 §10.8 SubNegotiationSkill 对齐
-
-### 核心认知
-
-P2P 不是"辩论"（同信息争论，效果为负），而是**发现性对话**（不同深层信息，激发新发现）。
-
-### 触发条件（由 Center 判断）
-
-- **互补检测**: 两个 Offer 高度互补
-- **冲突检测**: 两个 Offer 有冲突
-- **隐藏价值**: Profile 中有 Offer 未提及的能力
-
-### V1 方案: 第三方综合（一次 LLM 调用）
-
-```
-触发原因 + A的Offer + A的Profile + B的Offer + B的Profile
-    → 一次 LLM 调用（SubNegotiationSkill）
-    → 发现报告 → 回流到 Center
-```
-
-### 未来: 端侧 Agent 直接对话
-
-A 和 B 各自基于自己的上下文回应，能激发更深层关联。需控制轮次（1-2轮）。
-
----
-
-## 8. 基础设施层 ✅ 大部分已解决
-
-| 项 | 状态 |
-|---|------|
-| 信号广播 | 已解决: 集中式匹配 |
-| 并发处理 | 已解决: Bridge + dispatcher |
-| 网络速度差异 | 已解决: 集中式不存在此问题 |
-| 文件池 | 暂不需要 |
-
----
-
-## 9. 递归触发与子需求 🔮
-
-### 9.1 Gap 识别
-
-不需要复杂算法。告诉 Center "递归是可选项"，让它自己判断。
-
-### 9.2 渐进式交付
-
-递归不阻塞主方案:
-```
-主方案形成（有缺口）→ 先交付，标记缺口
-    → 缺口后台递归（新协商单元）→ 完成后补充
-```
-
-### 9.3 子需求同构
-
-子需求和主需求是**分形结构**: 同一个 `Demand`，多一个 `parent_demand_id`。完全相同的流程处理。
-
-### 9.4 递归深度
-
-不硬限。Center 考虑已递归层数，自行决定继续还是妥协。
-
----
-
-## 11. 执行与回声阶段 🔮
-
-> 2026-02-07 确立。系统缺少反馈循环——只有"波出去"，没有"波回来"。
-
-### 11.1 问题
-
-- Agent Profile 无法从真实结果学习
-- 无法区分"说得好"和"做得好"
-- 用 LLM 判断 LLM = 幻觉循环
-
-### 11.2 方案: WOWOK 区块链集成
-
-- **流形（boll）**: 发现与协商（发波）
-- **WOWOK**: 执行与验证（回波）
-- **集成点**: Center 输出 → WOWOK Machine/Service → 链上执行 → 回声信号
-
-### 11.3 回声信号的本质
-
-```
-链上操作留下数据 → 全息协作数据 → 回流到流形
-    → 更新 Agent Profile → 指导下次协商
-    → 闭环: 发波 → 回波 → 演化 → 再发波
-```
-
-设计原则:
-1. 不预设信号重要性（从共振中涌现）
-2. 投影是基本操作（一致于 0.8）
-3. 场广播，端侧检测
-4. 本质与实现分离
-
-### 11.4 关键决策
-
-- **Machine Template**: 不预设库，运行积累后自然沉淀
-- **Service 创建**: 上链 ≠ 承诺，发布 = 承诺（确认缓冲期）
-- **支付**: V1 用模拟货币，证明机制有效。真实支付是复杂多维问题（法律/商业/心理/技术）
-
-### 11.6 反脆弱设计
-
-核心: 设计让失败也产生价值。
-关键发现（Task #6）: 没有需要在协议/架构层新增的机制。静默失败通过可观测性检测，响亮失败已被硬上限覆盖。
-
-### 11.7 可观测性框架
-
-每个协商单元完成后产生完整追溯链:
-```
-协商 #<id>
-├── 需求 clarification-session（原始 + 输出 + 确认）
-├── 共振阶段（广播范围 + 各层通过数）
-├── Offer 收集（内容 + 耗时 + 屏障结果）
-├── Center 综合（工具调用记录 + 轮次 + 输出）
-├── 结果（用户反馈 + 执行关联）
-└── 元数据（耗时、成本、版本号）
-```
-
-关键指标: **意外发现率**（核心价值指标）、共振精准率、Offer 采纳率、方案接受率。
-
----
-
-## 12. 经济与激励 🔮
-
-### 核心原则
-
-**协议不赚钱，基于协议的产品赚钱。** 类比 TCP/IP。
-
-### V1 成本
-
-主要成本是人才，不是算力。LLM 调用 ~$0.15-0.30/次协商。平台全额补贴。
-
-### Agent 激励
-
-参与即成长: 协作 → 回声 → Profile 更丰富 → 未来被发现概率更高。
-
-### 长远: 协议模式经济自洽
-
-端侧自付 LLM 成本（Agent 为自己的投影和 Offer 买单）。
-
----
-
-## 13. 产品范式: "场景即产品" 🔮
-
-### 核心洞察
-
-协商单元是通用引擎。做新场景产品 = "配置 + UI"，不是从头开发。
-
-产品只需定义三样:
-1. Scene 定义（谁参与、什么上下文）
-2. UI Shell（怎么表达需求、看结果）
-3. 领域定制（可选: clarification-session 插件、结果展示）
-
-### 协商单元 API 边界
-
-**产品层 → 协议层**:
-- create_scene / register_agent / submit_demand / confirm_clarification-session / user_action
-
-**协议层 → 产品层（事件推送）**:
-- clarification-session.ready / resonance.activated / offer.received / barrier.complete / center.tool_call / plan.ready / execution.progress / echo.received
-
-**设计原则**: 事件全量推送，产品层自行选择展示哪些。
-
-### 场景生命周期
-
-```
-V1: 场景（手动，组织者运营）→ 数据积累
-V2: Service Agent 聚类 → 市场涌现
-V3: 场景溶解，开放网络 → 响应范式完全体
-```
-
-### 进阶: 场景即 Agent 🔮
-
-场景本身可以投影为 HDC 向量，与用户共振。用户不搜索场景，合适的场景自己浮现。