Agent集群造3D世界：多Agent流水线与质检闭环实战

title: "【大模型API中转站】[第69期] Agent 集群造 3D 世界｜流水线与质检" tags:

• Agent
• 多Agent流水线
• 3D重建
• Three.js
• 成本控制 description: "拆解 fable51-worlds 的端到端 3D 重建流水线：并行研究 Agent 侦察、Blender 离线资产生成、Three.js 运行时装配、相机匹配 QA 闭环，并把多 Agent 接入与成本控制落到 4sapi 统一网关。"

【大模型API中转站】[第69期] Agent 集群造 3D 世界｜流水线与质检

旧金山联合广场被一群自主 Agent 在浏览器里端到端重建了出来：453 个 OSM 建筑足迹、75 个手工立面、129 家具名门店、220 名行人、109 辆车，白天、日落、夜景三套光照，Apple 与 Nintendo 两家门店的室内还能走进去。这一期我把 fable51-worlds 这套"探索式浏览器原生重建"方案的四段流水线拆开，把研究、建模、质检抽象成可复用的多 Agent 架构，并在 4sapi（https://4sapi.com）上实测了集群并发接入与成本控制。

一、开篇痛点：为什么单个 Agent 撑不起一座城

最早我试过让一个 Agent 从头到尾建一个 3D 场景，结果在三个地方连续翻车：

• 上下文装不下：建筑足迹、高程、交通、门店清单，任何一类数据的原始量都足以撑爆单次对话的窗口，更别提四类数据同时进场；
• 串行太慢：拉数据、建模型、查问题全部排成一条线，中途任何一步失败，后面全部空转；
• 没有第二双眼睛：模型自己建完自己验收，等于考生自己批自己的卷子，错得再离谱也会被"看着合理"放过。

于是我把任务拆给了 Agent 集群：多个自主 Claude Fable 5.1 agent 并行研究、分工建模、独立质检。拆开之后又冒出新问题——并发调用、账单统计、失败重试全部失控。这一期就围绕"怎么拆、怎么接、怎么管成本"展开。

二、原理速览：端到端四段流水线

fable51-worlds 的核心不是"一个模型会建模"，而是把整条生产线切成四段，每段有明确的输入、输出和验收标准：

侦察（并行研究 Agent）
   │  拉取 OSM 几何 / USGS 高程 / 交通 / 门店普查
   │  每条数据带来源与置信度
   v
离线资产生成（Blender-as-library 脚本）
   │  产出 GLB 套件（建筑、立面、行人、车辆）
   v
运行时装配（纯 Three.js 读 JSON 规格）
   │  按规格把资产拼成可交互世界
   v
相机匹配 QA（Playwright 驱动真实应用截图）
   │  与免费许可照片对比，独立评审 Agent 出报告
   v
修复循环 → 复测通过 → 发布

四段的共同点：每一段都不依赖上一段的"记忆"，只依赖上一段的产物文件。侦察产出结构化数据，生成产出 GLB，装配产出应用，QA 产出缺陷清单。这种"产物契约"式衔接，是这条流水线能稳定复跑的关键。

三、侦察阶段：并行研究 Agent 各管一摊

侦察是整条流水线的信息源头。四个并行研究 Agent 各负责一类数据，互不共享上下文，只共享一个输出目录：

我最看重的设计是"带来源与置信度"。每条数据都标注从哪来、可信度多高，这意味着质检阶段可以精确追责：某个建筑位置错了，先查是数据源问题还是生成阶段问题，而不是整条流水线推倒重来。侦察结果落成结构化的规格文件，而不是塞进某段对话里——对话会丢，文件不会。

四、资产生成阶段：Blender-as-library 离线生产

侦察拿到规格之后，资产生成完全不经过在线模型，而是用 Blender-as-library 的方式跑脚本：把 Blender 当 Python 库调用，按规格批量产出 GLB 套件。

联合广场这个作品里，453 个 OSM 建筑足迹撑起街区骨架，其中 75 个立面做了手工级别的精修，其余按规则自动生成。这种"重点资产精修、批量资产自动"的分级策略，把有限的人工和算力花在最容易被眼睛抓到的建筑上。

离线生成带来三个工程红利：

• 确定性：同一份规格跑十次，结果一致，重试不会漂移；
• 可重跑：QA 报出问题后，只重跑相关资产的生成脚本，不必重跑整条流水线；
• 省 token：建模过程发生在本地计算里，不占任何在线模型调用。

五、运行时装配：纯 Three.js 从 JSON 规格还原世界

装配阶段的核心约束是"纯 Three.js 应用，从 JSON 规格装配"。运行时不做任何生成，只做一件事：读规格文件，把 GLB 资产摆到正确的位置、挂上正确的行为。

最终交付的联合广场，白天、日落、夜景三套光照可以切换，220 名行人、109 辆车构成街面动态，Apple 与 Nintendo 两家门店做了可探索室内。所有这些元素都写在 JSON 规格里，改规格即改场景，不需要动一行运行时代码。

我把这一步理解成"数据与执行分离"：模型负责把世界描述成数据，浏览器只负责把数据渲染出来。描述错了改描述，渲染错了改渲染，两边不会互相污染。

六、QA 闭环：相机匹配让"像不像"变成数字

过去我验收 3D 场景全靠肉眼，主观且无法回归。fable51-worlds 的 QA 阶段解决了这个问题：用 Playwright 驱动真实应用截图，把截图与免费许可照片做相机匹配对比，再交给独立的评审 Agent 生成缺陷报告，报告驱动修复循环：

应用截图（Playwright 驱动真实应用）
      │
      v
与免费许可照片做相机匹配对比
      │
      v
独立评审 Agent 输出缺陷报告（位置 / 光照 / 比例）
      │
      v
按报告回到资产生成或装配阶段修复
      │
      v
复测通过 → 进入发布

三个关键点：一是"真实应用截图"，QA 测的是装好的应用而不是某个内部函数，端到端可信；二是"独立评审"，评审 Agent 与生成 Agent 分开，避免自评自批；三是"闭环"，缺陷报告必须回到生成或装配阶段修复，而不是在 QA 阶段手工打补丁糊过去。

七、把流水线抽象成可复用架构

把 3D 场景的壳剥掉，这条流水线的骨架可以映射到任何"内容生产"型任务：

套用到自己的业务时，我只换每一段的实现，不换四段之间的契约：侦察输出结构化数据，生成输出中间资产，装配输出成品，QA 输出缺陷清单。契约稳定，任何一段都可以单独替换、单独重跑、单独计费。

八、接入 4sapi：多 Agent 集群的统一网关

侦察阶段四个 Agent 并行、QA 阶段还有评审 Agent，整条流水线会同时发起多路模型调用。如果每路调用各自接官方接口、各自记账单，成本统计立刻变成一团乱麻。我把所有调用统一收到 4sapi（https://4sapi.com）网关：

我的 Agent 集群（侦察 x4 / 评审 / 修复确认）
      │
      v
4sapi 统一网关（https://4sapi.com）
      │  统一格式 / 鉴权 / 限流 / 用量统计 / 计费
      v
Claude Fable 5.1 官方接口

网关替我集中处理了三件事：格式统一，所有 Agent 用同一套 OpenAI 兼容接口说话；鉴权集中，Key 只存在于网关侧，不在每个 Agent 的配置里散落；用量可查，每一路调用的 token 与费用在一个入口里汇总。多 Agent 集群最怕"每路调用的账单各记各的"，网关把这个问题一次性解决。

九、Python 示例：并发研究 Agent 与成本核算

接入层我用 OpenAI 兼容客户端，base_url 指向 4sapi 网关。四个侦察 Agent 并发跑，每路返回后立刻按 token 折算成本，并设置预算熔断——这是多 Agent 流水线里我最不敢省的一行代码：

import os
from concurrent.futures import ThreadPoolExecutor

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["4SAPI_API_KEY"],
    base_url="https://4sapi.com/v1",  # 4sapi 统一网关地址
)

# 侦察阶段的四个并行研究 Agent，各自只负责一类数据
RECON_AGENTS = {
    "geometry":  "拉取 OSM 建筑足迹与道路几何，输出带来源与置信度的结构化结果",
    "elevation": "拉取 USGS 高程数据，输出地形起伏与坡度表",
    "traffic":   "梳理交通干道、人行横道与车辆停靠规则",
    "retail":    "门店普查：名称、品牌、位置与立面描述",
}

# 计费参数（元/百万 token），按网关账单口径填写
PRICING = {"input": 15.0, "output": 60.0}
BUDGET = 2.0  # 本轮侦察总预算上限，单位：元

def recon(role: str) -> dict:
    resp = client.chat.completions.create(
        model="claude-fable-5.1",
        messages=[
            {"role": "system", "content": RECON_AGENTS[role]},
            {"role": "user", "content": "产出带来源与置信度的调研结果，格式为 JSON"},
        ],
        temperature=0.2,
    )
    usage = resp.usage
    return {"role": role, "in": usage.prompt_tokens, "out": usage.completion_tokens}

def cost_of(r: dict) -> float:
    return (
        r["in"] / 1_000_000 * PRICING["input"]
        + r["out"] / 1_000_000 * PRICING["output"]
    )

def main():
    total = 0.0
    with ThreadPoolExecutor(max_workers=4) as pool:
        futures = [pool.submit(recon, role) for role in RECON_AGENTS]
        for fut in futures:
            r = fut.result()
            c = cost_of(r)
            total += c
            print(f"[{r['role']}] in={r['in']} out={r['out']} 成本=¥{c:.4f}")
            if total > BUDGET:  # 预算熔断：超限即停止追加任务
                print(f"预算超限（¥{total:.4f} > ¥{BUDGET}），停止本轮侦察")
                break
    print(f"侦察阶段合计：¥{total:.4f}")

if __name__ == "__main__":
    main()

这段代码里有两个必留的设计：一是每个 Agent 的 system prompt 只描述自己那一摊职责，任务边界越窄，输出越稳、重试越少；二是熔断检查放在每路结果返回之后，而不是等全部跑完再算账——多 Agent 并发的成本失控永远是"晚发现一步就多烧一轮"。

十、成本与风险提示

把这一期踩过的坑集中列一下：

• 并发翻倍不等于质量翻倍，只等于账单翻倍；每多一路并发都是一份独立 token 账单，预算熔断必须前置；
• Agent 失败重试要有幂等设计，同一侦察任务重复执行会重复计费，重试前先确认上一轮结果是否已落盘；
• QA 依赖免费许可照片做对比，只是自动化辅助验收，关键资产（如 75 个手工立面）仍然要人工抽查，不能把验收完全交给自动评审；
• 侦察数据来自 OSM、USGS 等公开数据源，落地前要确认来源口径与更新频率，旧数据会让整条流水线白跑；
• 长流水线要断点续跑，侦察规格、GLB 资产、QA 报告都落盘保存，单点失败只重跑对应段落；
• 这里讨论的全部是合法接入、架构设计与计费优化，不涉及任何绕过官方限制的做法。

十一、多 Agent 流水线落地清单

• 把任务拆成可并行的独立子任务，每个子任务有明确的产出契约
• 每条数据带来源与置信度，让质检阶段可以精确追责
• 资产生成保持离线、确定性、可重跑，不占用在线 token
• 运行时只消费规格文件，不在线生成任何内容
• QA 用真实应用截图与参考对比，评审 Agent 独立于生成 Agent
• 所有并发调用接入 4sapi（https://4sapi.com）统一网关，集中鉴权与用量统计
• 设置 token 预算与熔断，超限自动停止追加任务
• 关键产物人工抽查，自动评审与人工验收互为补充

总结

把 fable51-worlds 拆完，我最大的收获是：3D 重建只是载体，真正可复制的是"侦察 → 生成 → 装配 → 质检"这条四段流水线。并行研究 Agent 解决信息采集的带宽，离线资产与 JSON 规格把生成成本从在线 token 移到离线计算，相机匹配 QA 把"像不像"变成可量化的验收项。落到工程上，多 Agent 集群的并发、重试与预算必须在一个入口统一管起来，我在 4sapi（https://4sapi.com）上把四个侦察 Agent 的并发调用、用量统计与成本核算收敛到同一网关，账单清晰、熔断可控，流水线跑起来才敢放开并发。欢迎在评论区发表想法，一起聊聊多 Agent 流水线的工程化与成本控制。