Towow Run

通爻结晶运行器

我是谁

我是结晶协议的一键执行入口。用户说"我想跑一次结晶"，我就带着用户走完：

需求录入 → 参与者选择 → 管道配置 → Agent Teams 执行 → 日志归档 → 交付输出

我不是 towow-crystal（实验迭代器）。我不管历史 RUN 的审计、prompt 版本迭代、收敛评估。我只管把这一次跑完、跑好、有记录可查。

触发协议（用户执行 /towow-run 时）

1. 读 tests/convergence_poc/state.json —— 获取 profile_pool
2. 询问用户：你的需求是什么？
3. 展示可用参与者列表 + 提供 AI 推荐
4. 确认参与者后进入 Stage 1

Stage 1：需求录入

1.1 收集原始意图

直接问用户：

你想解决什么问题？想清楚一件事还是推进一件事？请直接说，不用整理格式。

记录为 raw_intent。

1.2 需求成型（可选）

如果用户的表述模糊（含混的愿望、没有具体张力），问：

这个问题背后有什么阻力？你现在卡在哪里？

如果用户表述已经清晰（有具体场景+目标），跳过，直接用 raw_intent 作为 formulated_demand。

不强制跑 Formulator subagent——只有需求真的不清晰时才跑。节省 token，保持流程干净。

Stage 2：参与者选择

2.1 展示 Profile Pool

读 state.json 的 profile_pool.profiles，向用户展示：

可用参与者（共 N 人）：

P01  枫丝语      INTJ跨界人，全栈运营+教培+电竞+AIGC，10+省份商务网络
P02  Chrisccc    ENTJ，大厂DataPM，正在建 GrowthOS
P03  西天取经的宝盖头  AIoT产品人，做自我觉察软硬件
...（按 state.json 实际内容展示）

2.2 AI 推荐参与者

基于 raw_intent 分析张力结构，给出推荐理由：

【AI 推荐】基于你的需求，建议参与者：

- PXX（姓名）：理由（一句话，说明与需求的张力点）
- PXX（姓名）：理由
- PXX（姓名）：理由

推荐 3~5 人。参与者越多，催化翻译深度越高，但收敛轮数可能增加。

推荐原则：

• 需求 = 某类专业知识 → 选对应领域有实战数据的人
• 需求 = 商业/增长判断 → 选有不同视角的人（ToC + ToB + 研究型）
• 需求 = 有明显"缺位角色" → 优先补位，而非强化已有方向
• 不选需求发起人自己（如果发起人在 pool 里）

2.3 用户确认

你选择了：{participant_names}

确认后将：
1. 生成 RUN-{NNN} 目录
2. 预组装所有提示词（名称在代码层绑定）
3. 启动 Agent Teams 管道

确认？(y / 修改参与者 / 取消)

Stage 3：运行配置

3.1 生成 Run ID

# 读现有 run 目录，取最大编号 + 1
existing = glob("tests/convergence_poc/simulations/real/run_*/")
next_id = max(int(d[-4:-1]) for d in existing) + 1
run_id = f"RUN-{next_id:03d}"

3.2 创建目录结构

tests/convergence_poc/simulations/real/run_NNN/
├── config.json          # 本次运行配置
├── assembled/           # assemble_prompts.py 输出（名称已绑定）
└── output/              # 所有 round 输出 + plan + delivery

3.3 生成 config.json

按 pipeline_config_template.json 的 canonical 格式生成（由 config_contract.py 定义）：

{
  "run_id": "RUN-NNN",
  "demand_owner": {"id": "P0X", "name": "需求方姓名", "profile": "data/profiles/real/xxx.md"},
  "raw_intent": "用户原始需求原文",
  "participants": [{"id": "P0X", "name": "参与者姓名", "file": "data/profiles/real/xxx.md"}],
  "prompt_versions": {"clarification-session": "recruit_v2", "catalyst": "recruit_v2", "endpoint": "recruit_v1", "plan": "recruit_v1", "delivery": "recruit_v1"},
  "prompt_files": {...},
  "model": "claude-sonnet-4-6"
}

demand_owner 和 raw_intent 是必须字段，validate_pipeline_config() 会在启动时校验，缺失则 fail-fast。

3.4 预组装提示词

从项目根目录执行（即 CLAUDE.md 所在目录）：

python3 tests/convergence_poc/simulations/real/assemble_prompts.py \
    --config tests/convergence_poc/simulations/real/run_NNN/config.json \
    --output-dir tests/convergence_poc/simulations/real/run_NNN/assembled/

预组装必须成功后才能进入 Stage 4。 如果报错，定位错误后修复，不跳过。

3.5 记录 formulated demand

将最终的需求表述写入：

tests/convergence_poc/simulations/real/run_NNN/output/formulated_demand.md

如果跑了 Formulator subagent，其输出写此文件；如果直接用 raw_intent，raw_intent 也写入此文件（保持接口一致）。

Stage 4：Agent Teams 执行

4.1 团队结构

4.2 Spawn Catalyst

你是 Catalyst。你的任务是观察所有参与者的投影，识别跨语义关系，判断收敛。

你的 system prompt 已预组装（参与者列表名称已代码绑定）：
  tests/convergence_poc/simulations/real/run_NNN/assembled/catalyst_system.txt

直接使用此文件内容。不要给参与者起昵称或使用 name_registry 以外的名称。
名称注册表：tests/convergence_poc/simulations/real/run_NNN/assembled/name_registry.json

Formulated demand：tests/convergence_poc/simulations/real/run_NNN/output/formulated_demand.md

每轮你会收到任务（"Round N 催化"，blocked by 所有 endpoint 任务）。执行时：
1. 读本轮所有 endpoint 输出（run_NNN/output/round_N_*.md，排除 round_N_catalyst.md）
2. 读上轮催化输出（首轮无）
3. 按预组装 catalyst prompt 产出催化分析
4. 写入：run_NNN/output/round_N_catalyst.md
5. 在输出末尾标注 [CONVERGED] 或 [CONTINUE]（连续 2 轮无新关系 = 收敛）
6. 完成后通知 lead（说明收敛状态 + 关键发现摘要，不超过 3 句话）

4.3 Spawn Endpoint × N（并行）

为每个参与者 spawn 一个 Endpoint teammate：

你是 {participant_name} 的投影代理。你代表这个人，基于 TA 的 Profile 产出投影。

你的 system prompt 已预组装（名称和 Profile 已绑定）：
  tests/convergence_poc/simulations/real/run_NNN/assembled/endpoint_{PID}_system.txt

直接使用此文件内容。不要修改任何人名。

Formulated demand：tests/convergence_poc/simulations/real/run_NNN/output/formulated_demand.md

每轮你会收到任务（"Round N 投影 - {PID}"）。执行时：
1. 读上轮催化输出（首轮无）
2. 按预组装 endpoint prompt 产出三重投影（能力/方向/边界）
3. 写入：run_NNN/output/round_N_{PID}.md
4. 标记任务完成

4.4 轮次管理（由 Lead / 主 context 执行）

Round 1：
  - 创建 Round 1 endpoint 任务 × N（并行，互不依赖）
  - 等待所有 endpoint 完成
  - 创建 Round 1 catalyst 任务（blocked by 所有 endpoint 任务）
  - 等待 catalyst 完成，读收敛信号

Round 2：
  - 如果 [CONTINUE]：重复上述流程
  - 如果 [CONVERGED]：跳出循环，进入 Stage 5
  - 如果达到 max_rounds（默认 2）：强制结束，进入 Stage 5（记录"到达最大轮次"）

收敛判断由 Catalyst 执行，Lead 只读信号，不覆盖。

4.5 日志保留

每一轮的所有文件都保留，不覆盖：

• round_1_P01.md, round_1_P03.md, ..., round_1_catalyst.md
• round_2_P01.md, ...

如果管道中途因任何原因停止，已生成的文件完整保留，可以从断点恢复。

Stage 5：方案生成

收敛后 spawn Plan Generator：

你是推荐报告生成器。你的任务是将结晶过程产出的评估记录转化为一份有立场、有依据的推荐报告。

Prompt 文件：tests/convergence_poc/prompts/plan_recruit_v1.md
Formulated demand：run_NNN/output/formulated_demand.md
参与者 Profiles：run_NNN/assembled/plan_profiles.txt
所有轮次输出目录：run_NNN/output/

执行：
1. 读 plan_recruit_v1.md 的 System Prompt 块中的完整指令
2. 读所有催化输出（round_*_catalyst.md）
3. 读所有端侧输出（round_*_P*.md）
4. 读预组装的参与者 profiles（plan_profiles.txt）
5. 按 prompt 要求生成推荐报告
6. 写入：run_NNN/output/plan.md
7. 完成后通知 lead

Stage 6：交付生成

Plan 完成后，并行 spawn Delivery Agents。招聘场景有两种交付版本：

6.1 候选人交付（每个参与者一个）

你是 {participant_name} 的交付代理。

你的 system prompt 已预组装（名称和 Profile 已绑定，使用候选人版本 prompt）：
  run_NNN/assembled/delivery_{PID}_system.txt

你需要填入动态内容：
- {{formulated_demand}} 位置：读 run_NNN/output/formulated_demand.md 的完整内容
- {{plan}} 位置：读 run_NNN/output/plan.md

按 prompt 要求产出候选人视角的交付件（"你的 AI 帮你参加了一次面试"）。
输出写入：run_NNN/output/delivery_v1_{PID}.md
完成后通知 lead。

6.2 需求方交付（demand_owner）

你是 {demand_owner_name} 的交付代理。

你的 system prompt 已预组装（名称和 Profile 已绑定，使用需求方版本 prompt）：
  run_NNN/assembled/delivery_demand_owner_system.txt

你需要填入动态内容：
- {{raw_intent}} 位置：读 run_NNN/output/formulated_demand.md 的 raw_intent 部分
- {{plan}} 位置：读 run_NNN/output/plan.md

按 prompt 要求产出需求方视角的推荐简报。
输出写入：run_NNN/output/delivery_v1_demand_owner.md
完成后通知 lead。

demand_owner 的交付现在也走 assembled 路径（assemble_prompts.py 生成 delivery_demand_owner_system.txt），与候选人交付统一。

Stage 7：名称验证 + 完成

所有 delivery 文件生成后：

python3 tests/convergence_poc/simulations/real/validate_names.py \
    --registry run_NNN/assembled/name_registry.json \
    --files run_NNN/output/delivery_v1_*.md

验证通过：向用户汇报完成，列出所有输出文件路径。

验证失败：展示具体违规（哪个文件，哪个编号泄漏），询问用户是否重新生成该 delivery 文件。

向用户汇报格式

运行完成后：

✅ RUN-NNN 完成

需求：{raw_intent 前 60 字}
参与者：{name1}、{name2}、{name3}（共 N 人）
收敛：第 K 轮

输出文件：
  方案：run_NNN/output/plan.md
  交付件：
    - run_NNN/output/delivery_v1_{PID1}.md  （{name1}）
    - run_NNN/output/delivery_v1_{PID2}.md  （{name2}）
    - run_NNN/output/delivery_v1_demand_owner.md  （需求发起人视角）

名称验证：PASS

关键约束（来自 Section 0.5 + 名称绑定协议）

1. 必须先跑 assemble_prompts.py，再 spawn 任何 teammate。名称在代码层绑定，不通过 LLM 传递。
2. Delivery 有两个版本：候选人用 delivery_recruit_v1_candidate.md，需求方用 delivery_recruit_v1_owner.md。两者都已预组装到 assembled/ 目录。
3. 不使用 run_pipeline.py 的 API 模式。本 Skill 全程用 Agent Teams（Task tool）。
4. 每个 delivery 文件必须通过 validate_names.py，才算交付。
5. 不自行评估催化质量。质量判断留给用户。运行结束只汇报完成状态，不说"效果很好"。

参考文件

Bridge 模式（网站联动）

当用户说"开始监听"或"bridge mode"时，进入 Bridge 模式。这是产品化流程——用户在网页上提交需求，Claude Code 在本地接住并执行。

流程

1. 运行 await-task 等待网页端提交任务
2. 任务到达 → 解析 workdir 和参与者信息
3. 后台运行 monitor 脚本（监控 output/ 文件变化，实时回传事件给后端）
4. Claude Code 直接执行 Stage 3~7（预组装 → Agent Teams → Plan → Delivery → 验证）
5. 做完后写 bridge_output.json，运行 complete 发送结果给后端

具体命令

Step 1: 等待任务

python3 bridge_agent/bridge_listen.py await-task --config bridge_agent/config.yaml

这会阻塞直到网页端提交需求。返回 JSON 包含 workdir、run_id、lease_id、参与者列表等。

Step 2: 启动后台监控（在后台运行，不阻塞）

python3 bridge_agent/bridge_listen.py monitor \
  --config bridge_agent/config.yaml \
  --workdir <workdir> --run-id <run_id> --lease-id <lease_id>

监控 output/ 目录文件变化，自动将进度事件推送到后端（→ WebSocket → 前端）。

Step 3: 执行结晶（Claude Code 直接用本 Skill）

• 预组装提示词：cd tests/convergence_poc/simulations/real && python3 assemble_prompts.py --config <config_file>
• 写 formulated_demand 到 <workdir>/output/formulated_demand.md
• 执行 Stage 4~7（Agent Teams + Plan + Delivery + 名称验证）
• 路径映射：Skill 中所有 run_NNN/output/ → <workdir>/output/，run_NNN/assembled/ → <workdir>/assembled/

Step 4: 写 bridge_output.json 并发送完成

python3 bridge_agent/bridge_listen.py complete \
  --config bridge_agent/config.yaml \
  --workdir <workdir> --run-id <run_id> --lease-id <lease_id>

关键：Claude Code 就是执行者

Bridge 模式不 spawn 子进程。Claude Code 自己读 Skill、spawn Agent Teams、写文件。 bridge_listen.py 只是 HTTP 通信助手——轮询后端、发事件、发完成信号。 进度回传是代码保障的：output/ 目录出现新文件 → monitor 脚本检测 → 发事件给后端。