01 / CONTEXT
能力散在两处，会用的人只有几个
一边是云端模型 API，一边是自建工作流引擎。两边各有各的账号、各有各的计费口径，能把它们跑起来的只有少数几个人，业务同事想试个想法只能提需求排队。
目标不是再做一个生图工具，而是把两条上游收进同一套账号、同一本账、同一个任务看板：登录就能用，花了多少钱看得见，且不让任何一个人的试验把整体预算烧穿。
02 / EVIDENCE
先证明这件事值得做，再动手
立项前做了一次全量扫描：把现网全部图像工作流的节点构成统计了一遍，确认出图实际上全部由云端 API 节点完成，本地推理节点一个都没有。
结论因此不是「重做一套推理」，而是「去掉中间一层代理」—— 工作量和风险差一个数量级。这次扫描是整个平台的立项依据。
- 离线测试用例
- 619
- 上游协议并行
- 4
- 立项依据·扫描节点
- 981
数据源：立项前的工作流节点扫描，与代码仓库的测试统计。本页不列服务器地址、密钥与内部域名。
03 / MY ROLE
我的工作：从一次判断做到一个能收费的平台
架构判断
确认能脱离原工具，并决定独立进程、独立部署、独立发版，不挂进已有看板以隔离失败域。
调度设计
把线程池升级成带租约与心跳的任务体系，让进程重启不丢任务、不重复扣费。
账务治理
设计估价、预占、日月额度、全站预算闸和待核账清单，让「花了多少」随时对得上。
权限与共享
独立用户表与角色模型，素材可见性在上传那一刻按角色盖章，不随角色变动而改写。
04 / SYSTEM
四种协议，一套任务体系
- 01
统一网关
把不同厂商的调用差异收敛到一个网关，按协议分流、抹平用量字段、对失败分级。
- 02
接回自建工作流
本地模型能力（抠图、分割、姿态）留在工作流引擎，作为第四种协议并入同一套任务体系，而不是另起一个服务。
- 03
租约式任务池
按协议分成出图、视频、工作流三个线程池；线程先在任务表上原子认领再心跳续租，重启后排队中的重新派发、已递交上游的凭单号接回。
- 04
额度与预占
建任务先估一笔记进预占，额度按「已结算 + 在途预占 + 本次估价」算，查额度与建任务在同一把锁里。
- 05
账要对得上
记不上钱的失败留一条自救路径：凭上游单号再查一次，不重新提交、不花新钱；取不回的进后台待核账清单由人工对账。
四种协议并入同一套任务体系，而不是各起一个服务 —— 独立服务就要重做用户、额度与画廊。
05 / COST
这个平台一半的工程量在算账
多轮对话的成本不是线性的 —— 每轮都要把历史重发一遍，累计输入随轮数平方增长。按每轮各 500 token 算，20 轮是 20 万 token，不是直觉上的 1 万；选贵模型还是便宜模型，同样 20 轮能差出近 40 倍。所以新会话默认挑最便宜的可用模型。
视频默认不生成音轨，也是算出来的：上游默认配乐，而自动配的音乐会撞版权过滤、连带毙掉整条已经付过费的视频。关掉音轨，等于用一个默认值消掉一类白花的钱。
还有一类钱是「明明扣了却记不上」的：任务交给上游之后取消不掉，上游照样生成、照样按全价计费。现在这类任务不允许取消，跑完按实际用量记账，记不上的进待核账清单由人工对账 —— 宁可账面难看，也不让花费凭空消失。
06 / REVIEW
最该验证的那件事，还没验证
已经还上的账
上一版只有两个执行位、没有队列；现在是按协议分的三个池子加租约与心跳，重启不丢任务，也不会重复付款。
悬着的前提
整个平台建立在「换直连不会让出图质量退化」上，而同题对比至今没做。这是唯一的判据，不过就该停止加功能。
下一步
补上同题质量对比，继续推进安全加固与保留策略，再考虑把 Worker 拆成独立进程。