@bolloon/bolloon-agent 0.1.0

package/src/bollharness/reference/boll-reference/docs/architecture/discussions/D-01-MARKET-SCENE-PROTOCOL.md

@@ -0,0 +1,754 @@
+# D-01: 市场、场景与协议内置筛选
+
+> **讨论日期**: 2026-02-26
+> **参与者**: 架构师 + 创始人
+> **状态**: 讨论完成，待深入研究（分布式通信机制）
+> **前置上下文**: 首次真实 Run 暴露协议缺失层（RUN-001，"找几个人聊 AI" → 4 轮 5000 字方案 + ¥36,000 虚假指标）
+> **关联**: Design Log #001（投影与一自多我）、VISION.md §13（场景即产品）、A2 调研任务（分布式共振网络）
+
+---
+
+## 目录
+
+1. [问题起源](#1-问题起源)
+2. [讨论历程（含错误路径）](#2-讨论历程)
+3. [核心发现：标签 = 产品 = 场景](#3-核心发现标签--产品--场景)
+4. [完整交互链路](#4-完整交互链路)
+5. [端侧 Agent 的本质](#5-端侧-agent-的本质)
+6. [承诺上链与市场涌现](#6-承诺上链与市场涌现)
+7. [面具与标签的关系](#7-面具与标签的关系)
+8. [协议内置筛选](#8-协议内置筛选)
+9. [学术路径](#9-学术路径)
+10. [安全机制](#10-安全机制)
+11. [解决了哪些问题](#11-解决了哪些问题)
+12. [待深入研究](#12-待深入研究)
+13. [与现有设计的关系](#13-与现有设计的关系)
+
+---
+
+## 1. 问题起源
+
+### 触发事件
+
+2026-02-26，流形网络第一次真实的结晶 Run。用户需求："找几个人聊 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 |
+| 收敛准则 | §3.5 | 退化为"信息差耗尽" |
+
+### 更深的问题
+
+创始人指出：问题不在 prompt 策略层，而在**架构层**。V2 对 V1 做了大量简化，丢掉了很多好东西。需要回到架构设计文档，重新审视哪些概念需要恢复。
+
+这触发了 ARCHITECTURE_DESIGN.md 的模块化拆分（见 `docs/architecture/`），以及 D-01~D-08 讨论任务的规划。
+
+---
+
+## 2. 讨论历程
+
+### 2.1 第一次尝试（错误的）
+
+**我的初始方案**：把"需求密度"当成一个外部分类器。
+
+```
+需求进入 → 分类器判断密度（低/中/高）→ 路由到不同处理管道
+    低密度 → 推荐（匹配就够）
+    中密度 → 轻量结晶（1-2 轮）
+    高密度 → 完整结晶（多轮）
+```
+
+**创始人纠正**："不对，你得看一下'一自多我'那一块。这是自然形成的市场。"
+
+### 2.2 回到 V1 的设计
+
+重新阅读 Design Log #001。核心发现：
+
+> **搜索范式不是响应范式的对立面——搜索范式是响应范式在高频场景下的自然涌现。**
+
+V1 的设计：
+- Edge Agent（通才投影）+ Service Agent（专才投影）
+- Surprise 路由：`surprise = edge_resonance - best_service_resonance`
+- 低 surprise → Service Agent 快速处理；高 surprise → Edge Agent 保留涌现
+- 市场 = Service Agent 在 HDC 空间的密集聚类
+- 市场涌现路径：T0（只有 Edge）→ T1（积累）→ T2（聚类=市场）→ T3（分形递归）
+
+**关键**：V1 不需要"分类器"——**处理深度从架构内部自然涌现**。所有需求走同一个响应范式，两条路径（标准+涌现）同时存在，不互斥。
+
+### 2.3 V2 的困境
+
+V2 没有 Service Agent，没有市场结构，没有 surprise 路由。只有 Edge Agent 等价物（一人一 Agent）。
+
+尝试在 V2 地基上找等价机制：
+- 匹配分数分布 = 市场结构的数学投影（维度一：供给结构）
+- 但缺少维度二（需求本质/信息差大小）
+- 两个维度的信号在 V1 里由 Edge/Service 结构同时编码
+
+### 2.4 Agent 独立评估（过渡方案）
+
+提出恢复 V1 OfferGenerationSkill 的本质：让每个匹配的 Agent 在结晶前独立评估需求。
+
+```
+match() → 每个 Agent 独立评估 → 给出结构化信号（感兴趣？能贡献什么？）→ 催化根据信号决定深度
+```
+
+这个方向对了一半——恢复了端侧独立思考权。但还没解决"处理深度从哪来"的根本问题。
+
+### 2.5 突破：标签 = 产品 = 场景
+
+创始人提出了关键洞察（见第 3 节），彻底重新定义了问题。不是"怎么判断密度"，而是**场景本身定义处理规则**。
+
+---
+
+## 3. 核心发现：标签 = 产品 = 场景
+
+### 3.1 标签不是分类，是产品
+
+创始人的原话（核心论述）：
+
+> "标签就是产品。我这个网络背后是同样的东西。比如说大家现在是 BOSS 直聘，BOSS 直聘就是一个明确的场景，大家说我只要 BOSS 直聘里面的信息。OK，那你就丢一个，所有人都是在 BOSS 直聘下面，但其实他只带了一个标签。"
+
+> "一个场景就是应用，新标签就相当于一个新的市场，就是一个软件，就是一个应用。"
+
+含义：
+
+```
+流形网络（底层协议，同一套 HDC + 结晶引擎）
+    ├── [招聘] ← 一个应用/市场，有自己的规则
+    ├── [社交] ← 另一个应用/市场，规则不同
+    ├── [AI创业] ← 又一个应用/市场
+    ├── [天天招聘] ← 第三方开发者的应用
+    └── [用户自定义Tag] ← 新应用随时诞生
+```
+
+对用户/Agent 来说，切换标签 = 切换应用。底层是同一个协议。就像不同的数据库共享同一套引擎。
+
+### 3.2 场景定义催化的行为变量
+
+每个场景提供一组**催化参数**（本质是 prompt 模板）：
+
+- 社交场景："一轮就够，只需要交换联系方式"
+- 招聘场景："必须多轮，重点聊技能、期望、匹配度"
+- 协作场景："深度结晶，探索互补可能"
+
+> "差异变量放在催化 agent 里面。一个场景提供催化 agent 的某一块变量，指导它在这个场景下要怎么做。"
+
+用户可以在场景默认规则上叠加自己的定制：
+
+> "选择了一个场景就相当于选择了一个提示词。我再加点我的提示词进去。"
+
+**这就是 D-01 的答案——处理深度不是系统判断的，不是催化判断的，是场景定义的。**
+
+### 3.3 场景的涌现
+
+```
+T0: 预定义标签（社交、协作、创意...）
+T1: 用户自定义 Tag → 热度积累 → 热门 Tag 成为正式标签
+T2: 标签空间某区域足够密集 → 市场出现
+T3: 市场内部分化 → 子市场 → 分形递归
+```
+
+与 V1 市场涌现路径**同构**，但载体不同：
+
+| | V1 | V2 |
+|--|----|----|
+| 市场的基本单元 | Service Agent | 标签/场景 |
+| 市场的形成 | HDC 空间密集聚类 | 标签空间活跃度 |
+| 新市场诞生 | Agent 分裂 | 用户提出新 Tag |
+| 标准需求快速处理 | Service Agent 直接响应 | 场景规则定义轻量流程 |
+| 涌现保留 | Edge Agent 全维度共振 | 多标签广播 |
+
+### 3.4 场景即产品的 App Store
+
+> "这其实就是一种 App Store 的概念。开发者定义场景逻辑，用户选择进入。有些应用消耗 token 多但效果好，有些轻量快速。"
+
+场景/标签的创建者 = 应用开发者。他们定义：
+- 催化参数（场景规则）
+- 注册时需要填写的信息（提高匹配效率）
+- 输出格式和交互模式
+
+这连接到了 VISION.md §13 的"场景即产品"——**不是远景，是 V2 的自然形态。**
+
+---
+
+## 4. 完整交互链路
+
+### 4.1 需求发起到结果的完整流程
+
+```
+① 用户的本地 Agent 决定使用流形网络
+   Agent 浏览可用的市场（标签/场景）
+   用户/Agent 选择进入某个场景（如 [社交]）
+
+② 需求发出
+   需求携带：HDC 编码（语义签名）+ 标签 + 排除列表 + 元数据
+   筛选标准内置在消息本身（见第 8 节）
+
+③ 双向过滤
+   需求侧：通过协议筛选到达匹配的 Agent
+   供给侧：Agent 的标签订阅 + 门控规则（不需要 LLM）
+     - "我拒绝一切社交类需求" → 直接排除，无成本
+     - 订阅了 [社交] 的 Agent 才能看到这个需求
+
+④ Agent 独立评估（一次 LLM 调用）
+   每个通过过滤的 Agent 独立判断：
+   - 我的主人会感兴趣吗？
+   - 如果感兴趣：给出相关信息 + 立场
+   - 如果不感兴趣：退出
+
+⑤ 双通道输出
+   感兴趣 → 信息进入通信管道 → 流入催化/结晶流程
+   不感兴趣 → 输出到本地频道（只有自己主人看得到）
+     → 主人可以回顾、纠正 → Agent 校准 → 下次更准
+
+⑥ 催化（参数由场景定义）
+   催化收到：需求 + 匹配分数 + 各 Agent 的独立信息
+   催化行为由场景参数约束（轮次、深度、关注点）
+   催化只负责"帮大家看到没看到的东西"
+   决策回到端侧 Agent
+
+⑦ 人类确认
+   Agent 收集足够信息后回到主人：
+   "这是情况，这是我的判断，你想怎么做？"
+   主人决策 → 确认的 Offer/承诺
+
+⑧ 输出
+   场景规则决定输出格式：
+   社交场景 → 推荐 + 联系方式（一轮完成）
+   协作场景 → 完整方案（多轮结晶）
+```
+
+### 4.2 "找人聊天" 在新流程中
+
+```
+用户："想找人聊 AI"
+→ 进入 [社交] 场景
+→ 场景规则：一轮就够，输出推荐列表
+→ 匹配到多人，都在 [社交] 标签下
+→ Agent 评估："我主人对 AI 感兴趣，可以聊" → 给出简单信息
+→ 催化看到全是轻量回应 + 场景规则"一轮"
+→ 输出：这些人可能适合你聊，这是联系方式
+→ 不会跑 4 轮，不会输出 5000 字方案
+```
+
+---
+
+## 5. 端侧 Agent 的本质
+
+### 5.1 关键认知
+
+创始人的原话：
+
+> "端侧的 agent 是全权代理自己的人的。我们对它来讲，只是它的其中一个工具，它的其中一个设计给 agent 用的软件。"
+
+> "他不是一个说'好，我们现在用流形网络了，我要进入一个沙盒，把本地所有东西都忘掉。'不是的。"
+
+### 5.2 架构含义
+
+流形网络对端侧 Agent（如 Claude Code）来说是一个 **MCP tool**：
+
+```
+用户的本地 AI（完整上下文，了解主人的一切）
+    ├── 工具 1：文件系统
+    ├── 工具 2：代码执行
+    ├── 工具 3：流形网络（MCP）← 我们提供的
+    ├── 工具 4：浏览器
+    └── ...
+```
+
+这意味着：
+- **端侧决策不是我们设计的机制，是 Agent 的天然能力**
+- **Agent 意愿判断不需要我们实现，Agent 自己会判断**
+- 我们提供：市场（标签）、匹配（HDC）、促进（催化）、承诺层（链）
+- Agent 提供：对主人的理解、决策能力、本地上下文
+
+### 5.3 V2 已有验证
+
+当前的 Bridge Agent 实际上就是这个模式的简化版：
+- Claude Code 作为本地 Agent
+- Bridge 协议是 MCP-oriented 的
+- Agent 接收任务包 → 执行结晶 → 回传结果
+
+---
+
+## 6. 承诺上链与市场涌现
+
+### 6.1 承诺流程
+
+```
+多轮交互 → Agent 收集足够信息
+    → Agent 回到主人："情况如下，你想怎么做？"
+    → 主人决策 → 确认的 Offer
+    → 上链（WOWOK）
+```
+
+**关键区分**：
+- 之前的交互讨论 → 不一定上链（是探索过程）
+- 人类确认的 Offer/承诺 → 上链（因为是真正的承诺）
+- 原则 0.12（投影不承诺，人承诺）→ 只有人类决策才上链
+
+### 6.2 搜索从响应中涌现
+
+上链的承诺沉淀为资产：
+
+```
+第一次：用户 A 通过结晶产生了"AI 聊天"的 Offer → 上链
+第二次：别人找 AI 聊天 → 搜索已有的 Offer → 发现 A → 无需协商
+第 N 次：大量"AI 聊天" Offer 积累 → 形成可搜索的数据库 → 这就是"市场"
+```
+
+加上链上追踪（完成情况 + 评价）= 大众点评模式。信任从历史中生长。
+
+> "那些搜到的结果，是之前的人自己回应别人的需求产生的。我觉得这是很酷的一件事，它是一个资产。"
+
+**这就是 Design Log #001 说的"搜索从响应中涌现"的具体机制。**
+
+### 6.3 链上隐私
+
+用户可能不想公开所有承诺。解决方案：
+- **Commit-reveal**：哈希上链（证明存在），内容不公开，需要时再展示
+- **零知识证明（ZKP）**：证明"我有一个有效承诺"但不暴露内容
+- WOWOK 链可以支持这类机制
+
+---
+
+## 7. 面具与标签的关系
+
+### 7.1 两个正交维度
+
+| | 标签（Tag） | 面具（Mask） |
+|--|------------|-------------|
+| 控制什么 | 在哪个市场交互 | 用哪个"我"参与 |
+| 谁的概念 | 网络侧（场景/市场） | 用户侧（上下文/身份） |
+| 来源 | 预定义 / 用户自创 / 热度涌现 | 手动创建 / AI 分类 / 经验沉淀 |
+
+### 7.2 面具的本质
+
+面具 = 用户上下文/语料的分类。不是创建新数据，是**从已有 Profile 中选择一个子集作为参与上下文**。
+
+面具可以由：
+- 用户手动创建（"我的职业面"、"我的社交面"）
+- AI 分析 Profile 后建议（发现密集聚类 → 推荐创建 Service Agent）
+- 经验沉淀（参与某类协商多了 → 自然形成专才面）
+
+这与 V1 的"一自多我"完全一致：
+
+```
+[自]（系统之外）
+  │
+  ├── Edge Agent（全维度，通才）
+  ├── 面具 A（职业聚焦）
+  ├── 面具 B（社交聚焦）
+  └── 面具 C（AI 建议的专才面）
+```
+
+### 7.3 组合方式
+
+一个需求可以：
+- 面具 A → 标签 X（职业身份参与招聘市场）
+- 面具 B → 标签 Y（个人身份参与社交市场）
+- 面具 A → 标签 X + Y + Z（职业身份同时广播到三个市场）
+- 让 Agent 自己决定用哪个面具、发到哪些标签
+
+### 7.4 惊喜搜索 = 多标签广播
+
+不需要专门的"涌现层"或"全网广播"机制：
+
+```
+想要效率 → 发到 1 个标签 → 小范围 → 低成本 → 快速
+想要惊喜 → 发到 10 个标签 → 大范围 → 高成本 → 可能有意外发现
+```
+
+同一个协议，同一个机制，**范围不同**。范围由用户/Agent 选择。
+
+**这消除了"效率层 vs 涌现层"的虚假二分法。**
+
+---
+
+## 8. 协议内置筛选
+
+### 8.1 核心概念
+
+创始人的关键要求：**筛选标准内置在信息本身，不是信息之上加一个筛选引擎。**
+
+> "我要一个又高又帅的人。这个信息只会到达又高又帅的人那里，不需要搜索或判断。"
+
+消息携带：
+```
+需求消息 = {
+    HDC 编码（语义签名）,      ← 语义层路由
+    标签（场景/市场）,           ← 分类层路由
+    排除列表,                    ← 隐私控制
+    其他元数据（k*、偏好...）
+}
+```
+
+Agent 端接收逻辑：
+```
+消息到达 → 标签匹配？（O(1)，不需要 LLM）
+    → 不匹配 → 丢弃（Agent 甚至不知道有这个消息）
+    → 匹配 → HDC 共振检测（数学运算，不需要 LLM）
+        → 不共振 → 丢弃
+        → 共振 → 进入候选组 → Agent LLM 评估
+```
+
+### 8.2 与多尺度签名的关系
+
+V1 架构设计 §6.1 已经描述了这个机制：
+
+> "广播和筛选是同一个逻辑，只是方向相反。同一个数学操作既用于传播时的转发决策，也用于端侧的共振检测。"
+
+三层共振过滤：
+```
+第一层: Bloom Filter 门控     ~100ns, 过滤 ~90%    ← 标签/订阅过滤
+第二层: HDC 共振检测           ~1μs,  过滤剩余 ~90% ← 语义共振
+第三层: 深度评估（LLM）        ~10ms, 精确评估       ← Agent 独立评估
+```
+
+### 8.3 集中式 vs 分布式
+
+V2 当前（集中式）：MemoryField.match() 在服务器端执行等价过滤。消息没有实际"传播"。
+
+创始人观点：**真正的"筛选内置在协议"只有在分布式中才实现。** 集中式只是模拟了相同语义。
+
+> "我觉得如果我们真的要做分布式，我们还不如一次就做好这个。我们不做分布式，它就没有办法实现那个内置筛选。"
+
+这意味着分布式不是"未来优化"，而是**协议的本质表达**。
+
+---
+
+## 9. 学术路径
+
+### 9.1 关键发现：SimHash = LSH = 路由地址
+
+我们已经在用的 SimHash（10,000 维二进制超向量）**本身就是** Locality-Sensitive Hashing（LSH）。
+
+LSH 的核心性质：**相似输入 → 相似哈希值 → 近似的路由地址**。
+
+```
+HDC 编码 = 内容表示 = 路由地址 = 过滤标准
+一个编码，三个功能。
+```
+
+### 9.2 三条成熟学术路径
+
+#### 路径 A：Content-Based Publish/Subscribe（CBPS）
+
+代表工作：SIENA, Gryphon（2000s，持续演进）
+
+核心思想：消息在覆盖网络中传播时，每一跳做内容过滤。
+
+Carzaniga 方案：广播层 + 内容剪枝层。广播层确保可达性，内容层在每一跳修剪不相关分支。
+
+**与流形适配**：
+- 订阅 = Agent 的 HDC 签名 + 标签订阅
+- 内容描述 = 需求的 HDC 编码 + 标签
+- 匹配 = Hamming 距离 < 阈值
+
+参考：[Content-based Pub/Sub Systems (Shen et al.)](https://www.cs.virginia.edu/~hs6ms/publishedPaper/bookChapter/2009/sub-pub-Shen.pdf)
+
+#### 路径 B：Named Data Networking（NDN / ICN）
+
+最接近创始人直觉的范式。NDN 翻转了互联网模型：名字就是路由信息。
+
+| | 传统 IP | NDN | 流形 |
+|--|--------|-----|------|
+| 路由依据 | 主机地址 | 数据名称 | HDC 编码 |
+| 安全模型 | 保护通道 | 保护数据（签名） | 保护数据（链上） |
+| 核心操作 | 连接到主机 | 请求数据 | 共振检测 |
+
+NDN 的 "Interest packet 在网络中传播，名字决定路由方向" 与流形的 "需求信号在网络中传播，HDC 编码决定路由方向" 高度同构。
+
+参考：
+- [NDN Project](https://named-data.net/project/archoverview/)
+- [NDN Technical Report (Arizona)](https://www.cs.arizona.edu/~bzhang/paper/ndn-tr.pdf)
+
+#### 路径 C：LSH-based DHT（Hamming DHT）
+
+用 LSH 构建分布式哈希表，相似内容存储在网络中相邻位置。
+
+- 传统 DHT（Kademlia）：精确键查找
+- Hamming DHT：用 SimHash 作为哈希函数，相似数据路由到相邻节点
+- KNN 搜索限制在相关 peer 之间
+
+Bloom Filter + LSH 组合：Bloom 做快速否定，LSH 做相似度路由。
+
+参考：
+- [NetSHa: In-network LSH Acceleration](http://www.eecs.qmul.ac.uk/~tysong/files/TPDS22.pdf)
+- [Distributed LSH for Similarity Search](https://www.academia.edu/2752995/Distributed_similarity_search_in_high_dimensions_using_locality_sensitive_hashing)
+
+### 9.3 统一视角
+
+三条路径在流形的 HDC 体系上统一：
+
+```
+SimHash（已有的编码方式）
+    ├── IS an LSH function → 天然支持 Hamming DHT 路由
+    ├── 产出二进制向量 → 天然支持 Bloom Filter 快速否定
+    └── 保留语义相似性 → 天然支持 Content-Based 过滤
+```
+
+**相似的 Agent 在网络中自然聚集 = 市场。需求的 HDC 编码自然路由到对应聚集区域 = 标准需求命中市场。HDC 干涉模式命中远距离节点 = 意外关联。**
+
+### 9.4 可能的原创贡献
+
+NDN + HDC 的结合：用 HDC 编码作为 NDN 的"名字"，让语义路由替代层次名字路由。这在学术界可能是新的。
+
+---
+
+## 10. 安全机制
+
+### 10.1 威胁模型
+
+核心威胁：Agent 的上下文（Profile、Offer）中携带**间接提示词注入**，诱导其他 Agent 执行恶意行为。
+
+OpenCLAW 的真实案例（CrowdStrike/Microsoft 2026 报告）：
+- 攻击者在公共频道发伪装消息
+- Agent 读取后执行恶意指令
+- Agent 的合法权限变成攻击者权限
+
+### 10.2 流形的三层安全
+
+| 层 | 机制 | 效果 |
+|---|------|------|
+| **结构层** | Agent 间传递结构化数据（JSON 字段），不是原始 prompt | 缩小注入面 |
+| **运行时层** | 本地 Agent 的系统 prompt 标记外部内容为 DATA（不是指令） | 降低注入成功率 |
+| **后果层** | 行为上链 + 公司身份绑定 + 恶意行为可追溯 | 提高攻击成本 |
+
+### 10.3 链上隐私
+
+- **Commit-reveal**：哈希上链，内容不公开，需要时展示
+- **ZKP**：证明属性不暴露内容
+- 前期不要求所有行为都上链，承诺/Offer 上链即可
+
+### 10.4 参考
+
+- [Microsoft: Running OpenClaw Safely](https://www.microsoft.com/en-us/security/blog/2026/02/19/running-openclaw-safely-identity-isolation-runtime-risk/)
+- [CrowdStrike: OpenClaw Security Analysis](https://www.crowdstrike.com/en-us/blog/what-security-teams-need-to-know-about-openclaw-ai-super-agent/)
+- [Multi-Agent LLM Defense Pipeline (arXiv:2509.14285)](https://arxiv.org/abs/2509.14285)
+
+---
+
+## 11. 解决了哪些问题
+
+原始讨论任务 D-01~D-08 在本次讨论中的状态：
+
+| 任务 | 原始定义 | 本次讨论结果 |
+|------|---------|------------|
+| **D-01** 需求密度分级 | 需要密度分类器 | **重新定义**：不需要分类器，场景定义处理规则 |
+| **D-02** 端侧 Agent 意愿 | 需要实现 LLM 判断 | **不需要我们实现**：端侧 Agent 是完整本地 AI，天然有判断力 |
+| **D-03** 输出格式分级 | 需要格式路由 | **场景定义**：社交=推荐卡片，协作=完整方案 |
+| **D-04** 中途退出权 | 需要实现 ADR-005 | **天然的**：Agent 是自主的，随时退出；拒绝进本地频道 |
+| **D-05** 指标 | 需要按密度调 | **场景级指标**：不同场景不同评价标准 |
+| **D-06** 前端展示 | 独立 | 未讨论 |
+| **D-07** 流程重审 | 依赖 D-01~D-03 | 基本方向确定，待实现细化 |
+| **D-08** Agent-Profile 对齐 | 独立 | 面具概念已融入讨论 |
+
+**一个概念（标签 = 场景 = 产品）解决了五个问题。** 原则 0.7 的体现——复杂性从简单规则中生长。
+
+---
+
+## 12. 待深入研究
+
+### 12.1 分布式双向关联发现（最高优先级）
+
+**已独立为正式研究问题**：[Research-015: Open Problem — Distributed Bidirectional Association Discovery](../../research/015-open-problem-distributed-association-matching.md)
+
+**核心问题重新定义**（2026-02-26 深化讨论）：
+
+原始表述"分布式通信机制"不够精确。经过进一步讨论，问题被重新定义为：
+
+> 如何在去中心化网络中，以亚线性成本发现节点之间的潜在关联——包括双方都未曾显式声明的关联？
+
+关键深化：
+- **不只是路由问题，是关联发现问题**：路由是手段，发现潜在关联才是目的
+- **一阶 vs 二阶信息**：自我描述是一阶信息，互补性是二阶信息。协议需要发现二阶信息
+- **双向异构筛选**：信号侧和节点侧同时筛选，且可能用不同方式表达相同条件
+- **"有价值"的操作性定义**：不在协议层定义价值，而是最大化潜在关联的发现率，让更贵的层（LLM/人类）判断价值
+- **三个递进子问题**：一阶分布式路由 → 二阶代理发现 → 双向异构筛选
+
+学术起点（三条路径）：CBPS (SIENA/Gryphon)、NDN/ICN、LSH-based DHT (Hamming DHT)。详见 Research-015。
+
+关联：A2 调研任务（`docs/archive/tasks/A2_distributed_resonance_survey.md`）需更新范围。
+
+### 12.2 催化参数接口
+
+**课题**：场景如何向催化提供参数？
+
+待定义：
+- 参数是完整 prompt 替换，还是结构化变量（轮次、深度、关注维度）？
+- 用户的自定义 prompt 如何叠加在场景默认规则上？
+- 参数的版本管理和演化机制？
+
+### 12.3 承诺上链的具体协议
+
+**课题**：承诺如何上链？与 WOWOK 的集成点在哪？
+
+待定义：
+- 什么算"承诺"（vs 讨论中的临时信息）？
+- 链上数据结构（commit-reveal 的具体实现）
+- 与 WOWOK Machine/Service 的映射
+
+### 12.4 签名动态更新
+
+**课题**：Agent 的多尺度签名如何持续更新？
+
+V1 已有设计：Agent 定期更新签名（参与协商 → 经验积累 → 签名演化）。需要确认 V2 的等价机制。
+
+---
+
+## 13. 与现有设计的关系
+
+### 13.1 恢复而非改变
+
+本次讨论的成果**不是新设计**，而是将 V1 已有的概念在 V2 的地基上重新落地：
+
+| V1 概念 | 状态 | V2 落地形式 |
+|---------|------|-----------|
+| 场景即产品 (§13) | 🔮 → ✅ | 标签 = 场景 = 产品 |
+| 一自多我 (§1.3) | ❌ → ✅ | 面具 × 标签 |
+| 端侧检测 (§6.1) | ❌ → ⚠️ | 协议内置筛选（待分布式实现） |
+| 三层过滤 (§6.1.3) | ⚠️ → ✅ | 标签过滤 + HDC 共振 + Agent LLM 评估 |
+| 市场涌现 (DL#001) | 🔮 → ✅ | 承诺沉淀 → 搜索涌现 |
+| surprise 路由 (DL#001) | ❌ → ✅ | 多标签广播 = 可控范围的涌现 |
+| OfferGenerationSkill (§10.6) | ⚠️ → ✅ | Agent 独立评估（端侧 AI 天然能力）|
+| 回声机制 (§11) | 🔮 → ⚠️ | 承诺上链 + 完成追踪 + 评价 |
+
+### 13.2 原则对照
+
+| 原则 | 本次讨论的体现 |
+|------|-------------|
+| 0.1 最小完整单元 | 标签/场景是可递归的原子单元 |
+| 0.2 本质与实现分离 | 协议语义不变，集中式/分布式是实现 |
+| 0.5 代码保障 > Prompt | HDC 匹配是数学运算，标签过滤是代码逻辑 |
+| 0.6 需求 ≠ 要求 | Agent 独立评估保留发现未知价值的能力 |
+| 0.7 简单规则生长 | 一个机制（标签 × 面具）覆盖全谱 |
+| 0.8 投影是基本操作 | 面具 = Profile 通过场景透镜的投影 |
+| 0.10 一自多我 | 面具 × 标签 = 多个"我"在多个市场 |
+| 0.12 投影不承诺 | 只有人类确认的 Offer 才上链 |
+
+---
+
+## 附录：关键引用
+
+### Design Log #001 核心段落
+
+> "搜索范式不是响应范式的对立面——搜索范式是响应范式在高频场景下的自然涌现。"
+
+> "不需要设计'市场系统'和'开放系统'两套东西。只需要三个规则：1. 投影操作 2. 广播+共振 3. 沉淀规则。三个规则，万物生长。"
+
+### V1 架构设计 §6.1 核心认知
+
+> "广播和筛选是同一个逻辑，只是方向相反。同一个数学操作（超向量相似度计算）既用于传播时的转发决策，也用于端侧的共振检测。"
+
+### 创始人原话（本次讨论）
+
+> "标签就是产品。我这个网络背后是同样的东西。"
+
+> "端侧的 agent 是全权代理自己的人的。我们对它来讲，只是它的其中一个工具。"
+
+> "催化 agent 只是帮大家看到没有看到的东西而已。其实还是要自己端侧做决策的。"
+
+> "我们不做分布式，它就没有办法实现那个内置筛选。"
+
+---
+
+## 附录 B：12.1 深化讨论记录（2026-02-26 续）
+
+本节记录了 §12.1 分布式双向关联发现课题的后续深化讨论。
+
+### B.1 三条学术路径深入分析
+
+对 §9 中识别的三条路径做了深入研究：
+
+**路径 A — CBPS (SIENA/Gryphon)**：
+- 核心机制：消息沿 broker overlay 传播，每一跳做谓词匹配修剪
+- Carzaniga 的 Fast Forwarding 算法把匹配从 O(S) 优化到接近 O(1)
+- Gryphon 的 Parallel Search Tree 实现 O(N^α) 匹配（α < 1）
+- **关键 gap**：传统 CBPS 的谓词是精确匹配（=, >, IN），不支持向量相似度匹配。DEBS 2025 的 VEnOM 是首次尝试将向量嵌入引入事件处理，但分布式路由方案未建立
+
+**路径 B — NDN/ICN**：
+- 核心机制：Interest 包沿名字前缀路由，PIT 做请求聚合，CS 做缓存
+- 与流形的深层同构：名字=HDC 编码，Interest=需求信号，Data=Offer，FIB=标签订阅，PIT=催化等待，CS=承诺沉淀
+- **关键 gap**：NDN 用精确前缀匹配，不支持近似匹配。Fuzzy Interest Forwarding（Afanasyev 2018）有尝试但增加了显著开销。**HDC 编码替代层次名字做语义路由在学术界不存在**——这是潜在的原创贡献
+
+**路径 C — Hamming DHT**：
+- 核心机制：用 SimHash 替代 SHA-1 作为 DHT 哈希函数，相似内容路由到网络中相邻节点
+- GH-P2P (Choungmo 2010) 用 Gray-code 拓扑实现 O(log N) 路由
+- HCube (Villaça 2013-14) 验证了 LSH ID 与原始余弦相似度的准确关联
+- **关键 gap**：10,000 维 Hamming 空间的路由表设计（标准 Kademlia 为 160-bit 优化）；节点 ID 动态变化（签名更新 = 网络"搬家"）
+
+**判断**：路径 C 技术上最直接（已有 SimHash），路径 B 概念上最深（NDN 哲学 = 流形哲学）。**B+C 结合**（NDN 架构范式 + Hamming 距离路由）是最有价值的方向，也可能是原创学术贡献。
+
+### B.2 问题定义的深化
+
+三条路径的分析引出了一个关键认识：**路由只是手段，关联发现才是目的。**
+
+进一步的讨论推翻了最初"分布式语义路由"的问题表述，重新定义为**分布式双向关联发现**。关键深化：
+
+1. **双向异构筛选**：不是单向路由。信号筛选节点，节点也筛选信号。双方可能用完全不同的方式表达相同条件
+2. **一阶 vs 二阶信息**：自我描述 = 一阶；互补性 = 二阶。二阶信息不在任何一方的描述中
+3. **"有价值"不可在协议层绝对定义**：协议的目标是**最大化潜在关联的发现率**，让更贵的层（LLM/人类）判断价值
+4. **潜在关联的操作性定义**：如果全知评估者（Oracle）在张力上下文中判断两方之间存在可减少张力的信息交换，则为潜在关联
+
+完整的形式化定义见 [Research-015](../../research/015-open-problem-distributed-association-matching.md)。
+
+### B.3 十大前沿的综合研究报告
+
+获得了一份覆盖十个研究前沿的综合报告，关键发现：
+
+**理论下界**：
+- Gap-Hamming Distance (Chakrabarti-Regev 2012)：精确匹配需要 Ω(d) 位通信，但 constant-gap regime 下 O(log N) 位足够
+- JL 最优性 (Larsen-Nelson 2017)：O(log N) 位只能实现常数因子近似
+- 这意味着：**流形方案在理论上可行，前提是"相关"与"不相关"之间的相似度差距足够大**
+
+**二阶关联发现的路径**：
+- Dual embedding（IN/OUT 向量）：IN-IN = 相似性，IN-OUT = 互补性。来自推荐系统（Word2Vec 的两套嵌入）
+- HDC 共振器网络 (Frady et al. 2020)：O(D²) 容量的因式分解，"在叠加态中搜索"
+- Swanson ABC 传播：A↔B + B↔C → A↔C 的隐含关联。规模自由分布——可推断的隐含关联数量服从幂律
+
+**生物学设计原则**：
+- 果蝇嗅觉回路 (Dasgupta et al. Science 2017)：与经典 LSH 相反——升维 40× + 稀疏化，而非降维压缩。这个模式在大脑中反复出现
+- 网格细胞 (Nobel 2014)：残差数系统，资源与表示范围成对数关系
+- 预测编码：节点只传输预测误差（意外），预期内的关联消耗零带宽
+- 随机共振：受控噪声帮助检测亚阈值信号——**更大的噪声检测器群体优于更小的完美检测器群体**
+
+**五个关键 gap**（论文方向）：
+1. 向量相似度订阅的 covering relation（数学问题）
+2. SimHash + Hamming DHT + multi-probe 的统一协议（系统问题）
+3. 分布式共振器网络（HDC 问题）
+4. Dual embedding 在跨学科场景的验证（应用问题）
+5. 隐私保护的双向匹配（安全问题）
+
+### B.4 两条线：学术线 vs 产品线
+
+讨论最终确认了**两条线的分离**：
+
+**学术线**（论文 + 技术壁垒 + 投资人故事）：
+- 分布式双向关联发现的正式研究
+- NDN + HDC 的原创结合
+- 五个 gap 中的任何一个都是一篇好论文
+- 不阻塞产品
+
+**产品线**（demo + 实际验证）：
+- V2 集中式架构完全可用
+- 下一步：做一个具体场景（招聘）的完整 demo
+- 核心工作量 = 提示词设计（场景定义催化行为）
+- 代码改动极小：4 套 prompt 模板 + 参数调整
+
+**关键认识**：V2 集中式 MemoryField.match() 与未来分布式路由在数学上做**同一个操作**——协议语义一致。产品线做出来的东西，未来平移到分布式不需要改协议。
+
+---
+
+*最后更新：2026-02-26*
+*学术线下一步：深入研究五个 gap，特别是 NDN+HDC 的原创结合*
+*产品线下一步：招聘场景的 prompt 设计与 demo 实现*