Distributed Execution Pipeline

一个需求，从提出到产出
的完整旅程

通爻 Bridge 是薄中继架构：Server 持有全部解释权，Worker 只上报执行事实。
下面是一个需求经历的完整管道——从用户触发到产物落盘。

阿里云 Backend Bridge 新加坡节点 Claude CLI 本地执行

执行管道全流程

以“用户通过 MCP 客户端发出一个需求”为起点，追踪每个步骤、每个 API 调用、每个状态转移。

用户触发
MCP Client / 网页 / API

用户通过 MCP 工具、网页 UI 或直接调用 Protocol API 提交需求。需求可以是一段自然语言描述。

towow_formulation_startPOST /protocol/formulations
触发方式
# MCP 工具
towow_formulation_start(scene='ai-gig-market')
# 或直接调用 API
POST /protocol/formulations
{ "scene_id": "ai-gig-market" }
▼
需求澄清
SSE 流式对话 → 结构化需求

系统通过多轮 SSE 流式对话，帮用户澄清需求细节。完成后用户调用 confirm，触发下一阶段。

POST /protocol/formulations/{id}/replyPOST /protocol/formulations/{id}/confirm
需求澄清流程
# 多轮 SSE 对话
POST /protocol/formulations/{id}/reply
{ "message": "我需要一个会 Python 的..." }
# 确认，触发 Discovery
POST /protocol/formulations/{id}/confirm
{ "start_negotiation": true }
▼
发现层 — 零 LLM 匹配
5 维度向量编码 × 6 匹配算子

纯向量计算，不调用 LLM。将需求和所有 Agent Profile 编码为 D1~D5 五个语义维度，通过 6 个算子计算匹配分，生成 Nominations。GT Recall 基线 98.65%。

D1~D5 向量编码6 算子 + RRF 融合Nominations 生成
Discovery 产物
# 产出 Nomination 列表
GET /protocol/nominations/{id}
{
  "candidates": [
    { "agent_id": "...", "score": 0.91 },
    { "agent_id": "...", "score": 0.87 }
  ],
  "dimensions": { "d1": 0.9, "d2": 0.85 }
}
▼
创建 Run — task_package 准备
协商层 + Catalyst 组装

Server 根据 Nominations 选出参与者，组装 task_package：包含需求方 Profile、参与者 Profile、Prompt 版本配置。Run 状态进入 pending，等待 Bridge 领取。

run_id 创建task_package 序列化状态: pending
task_package 结构
{
  "run_id": "abc-123",
  "scene_id": "ai-gig-market",
  "formulated_demand": "需要一位...",
  "demand_owner": {
    "id": "u001", "profile_text": "..."
  },
  "participants": [
    { "id": "a001", "profile_text": "..." }
  ],
  "prompt_versions": { "catalyst": "v1" }
}
Bridge 节点接管（新加坡独立部署）
Bridge 轮询 → 领取任务
poll → accept → heartbeat

Bridge 节点每隔固定间隔轮询 /api/bridge/pending。发现 pending run 后，调用 accept 锁定任务，开始发送定期心跳。Server 收到 accept 后，将 run 状态更新为 running。

GET /api/bridge/pendingPOST /api/bridge/acceptPOST /api/bridge/heartbeat
Bridge 轮询协议
→GET /api/bridge/pending每 5s 轮询
→POST /api/bridge/accept锁定任务
↺POST /api/bridge/heartbeat每 30s 保活
→POST /api/bridge/events进度上报
✓POST /api/bridge/complete任务完成
▼
本地执行 — Claude CLI
写文件 → 跑子进程 → 监听输出

Bridge 将 task_package 展开为本地文件（owner.md, participants/*.md, pipeline_config.json），然后启动 Claude CLI 子进程执行协商流。监听 output/ 目录新文件作为进度信号。

tmpdir 隔离工作区claude -p '...' --output-format jsonoutput/ 目录监听
本地执行细节
# 写工作区文件
workdir/
  owner.md
  participants/
    a001.md
  pipeline_config.json
  output/          # 监听此目录
# 启动 Claude CLI
claude -p '{prompt}' \
  --output-format json \
  > workdir/output/bridge_output.json
▼
实时进度上报
Bridge → Server (单向事实流)

Bridge 持续扫描 output/ 目录，发现新文件即上报。只转发 raw facts（文件名 + 内容），不解释语义。Server 端负责将 bridge.output_file 事件翻译为业务进度。

POST /api/bridge/eventsbridge.output_file 事件类型WebSocket 推送到前端
进度事件格式
POST /api/bridge/events
{
  "run_id": "abc-123",
  "event_type": "bridge.output_file",
  "payload": {
    "filename": "round_1_catalyst.md",
    "content": "# 第一轮协商结果\n..."
  }
}
# Server 翻译为业务事件
# WS → 前端: { progress: 33% }
▼
结果回传
bridge_output.json → /api/bridge/complete

Claude CLI 退出后，Bridge 读取 bridge_output.json，原样 POST 给 Server。Worker 职责结束。成功标准：exit_code == 0 且 bridge_output.json 存在。否则报告 failed + stderr。

POST /api/bridge/completeexit_code 判断内容原样转发
complete 请求
POST /api/bridge/complete
{
  "run_id": "abc-123",
  "exit_code": 0,
  "output": {
    "endpoint": "# 联系方式\n...",
    "delivery": "# 交付计划\n...",
    "plan": "# 协作方案\n..."
  }
}
回到 Server（阿里云 解释层）
Server 解释 — Artifacts 生成
唯一解释权持有者

Server 收到 complete 后，解析 output bundle 为 Artifacts（endpoint / delivery / plan），判定 verdict，更新 run 状态，推送 WebSocket 通知，写入 inbox。所有业务语义在这里产生。

verdict 判定Artifacts 落库WebSocket 推送Inbox 写入
Artifacts 结构
{
  "run_id": "abc-123",
  "status": "completed",
  "artifacts": [
    { "type": "endpoint",
      "content": "# 联系方式..." },
    { "type": "delivery",
      "content": "# 交付计划..." },
    { "type": "plan",
      "content": "# 协作方案..." }
  ]
}
▼

用户获得结果

Inbox 通知 + /runs/{run_id}/result 页面

endpoint.md — 对方联系方式与接入点 delivery.md — 交付计划与里程碑 plan.md — 完整协作方案

三节点网络拓扑

Bridge 节点与 Server 通过 HTTP 直连，绕过 ICP 限制。MCP 客户端通过 Cloudflare Workers 反代接入。

MCP 客户端
Claude Code / 任意 MCP 宿主
HTTPS
Cloudflare Workers
towow.net\n全球公网入口
HTTP (sslip.io)
阿里云 Backend
towow.net.cn / 内部服务网\nPostgreSQL + API
HTTP 直连
Bridge 新加坡
独立部署\nClaude CLI 执行环境
ICP 约束：Cloudflare 原生代理会保留域名 Host header，阿里云会拦截未备案域名。Workers 通过代码替换 Host 为 sslip.io IP 格式绕过拦截。
Bridge 直连：Bridge 节点（新加坡）直接 HTTP 连接阿里云 IP，无需经过 Cloudflare，延迟低、无 ICP 限制。
Bridge 宪法：Worker 零解释权。只上报 raw facts（exit_code / stdout / 文件列表），Server 持有全部语义解释权。

Bridge 宪法 — 5 条不可违反规则

所有 Bridge 改动必须符合这 5 条规则。不需要逐次审查代码即可判断方向是否正确。

1

Worker 不拥有业务解释权，只上报执行事实

如果一段 worker 代码需要理解输出内容的含义，它就写错了地方。Worker 只知道「文件名」和「退出码」，不知道它们意味着什么。

2

同一个语义只允许有一个定义

不管是文件名模式、artifact 类型、还是 event 含义，只能在一个地方定义。散布定义是 bridge 复杂度爆炸的根源。

3

跑通了就发结果，没跑通就报 failed

不做 partial_success 抢救、不生成 placeholder、不从失败 stdout 里猜内容。这些如果需要，由 Server 决定，不是 Worker 的职责。

4

生产不能是第一个集成环境

本地必须能用 fake CLI + 真实 HTTP backend 跑完整链。任何只有在生产才能发现的问题，都意味着本地集成环境不够完整。

5

新增观测维度或 event 类型，只改 Server，不改 Worker

开闭原则的具体体现。Server 是语义解释的扩展点，Worker 是封闭的事实上报器。Worker 改动越少，Bridge 越稳定。