第 1 篇拆的是 DeepSeek 的设计；这一篇只回答一个问题：这些机制怎么落到 AI 视频/图片站的后端。
9 条启发和一张映射表都是我的翻译，不是 DeepSeek 原文；重点是先授权再花钱、重试不 fork 账单、先对账再重试。
一句话：把第 1 篇里的授权、工单、执行与恢复机制，翻译成 AI 视频/图片站能直接落地的 9 条规则和一张映射表。
第 2 篇 · 媒体站落地
对 AI 视频/图片站的 9 条启发
下面是我认为可以直接迁移到媒体生成产品的部分。注意：这是我的翻译，不是 DeepSeek 的文章原文；DeepSeek 讨论的是通用 Agent 系统，不是视频生成。
- 把「生成任务」当工单，不要当聊天消息。 一次生成请求应该有一个不可变的 job id、一个授权范围、一个账单主体；聊天只是它的上下文，不是它的状态机。
- 钱必须是确定性 gate，不是模型判断。 余额、配额、模型/分辨率/时长白名单、单次成本上限、预审核，全部用代码做。模型只回答「这个 prompt 是否清楚、是否有政策风险」，不能决定价格或权限。
- 授权与上下文分离。 用户在同一个项目里补充「把背景换成海边」是上下文，可以直接进已有 job；但「从 720p 升到 4K、从 5 秒加到 10 秒」是扩大范围，必须重新报价、重新授权。聊天不能改预算。
- Ticket 与 Attempt 分离。 一个 job 可以有很多次 provider attempt；重试不 fork 订单、不 fork 账单、不换用户看到的 job id。每次 attempt 记录 provider、provider job id、请求 hash、原始响应。
- 先记账，再做副作用；重试前先对账。 先 reserve credits，再写 outbox，再提交 provider。provider 状态未知时，先查，不要重新提交；重启后先核对 provider，再决定 settle 还是 release。
- 每个任务独立工作区和资产前缀。 视频/图片站尤其要这样：临时文件、参考图、输出、缩略图都按 job id 隔离；provider 返回的 URL 不是存储，必须镜像到自己的 R2/S3，做 checksum、尺寸/时长校验和审核。
- 只暴露四种状态，异常才打扰人。 Working、Needs you、Ready、Failed。不要把 provider polling、重试日志、chain-of-thought 流到主界面；开发者轨迹放到单独的 trace 视图。
- 投机执行要降级。 DeepSeek 的投机执行假设后台算力相对便宜；视频全片渲染不是。可以投机做 prompt 清理、安全预检、成本估算、缩略图、480p 草稿；不要默认投机 1080p/4K 全片，更不要让它产生用户可见的扣费。
- 新 provider 先 observe 再 auto。 新模型/新渠道先 shadow：只报价、只记录「would route」，不真的提交；对比成本、延迟、失败率、人工验收质量，再按百分比放量。这就是把原型的 accept mode 用到 provider 路由上。
一张映射表：从 Agent 概念到媒体生成
| DeepSeek 概念 | 媒体站里的对应物 | 必须守住的规则 |
|---|---|---|
| Source | 网页上传、公开 API、Stripe、审核回调 | 按来源 event id 去重；先落库再处理。 |
| Trigger | 一次生成请求 / 支付回调 / 审核结果 | 不可变；客户端重试必须命中同一个 job。 |
| Thread | 项目、会话、素材血缘 | 提供上下文，不授予预算。 |
| Gate | 登录、额度、模型目录、分辨率/时长、成本上限、预审核 | 全部确定性；失败返回一个可行动的错误。 |
| Assessment | prompt 是否清楚、参考图是否合适、政策风险 | 只给建议；不能改价格、额度、权限。 |
| Decision | accept / clarify / reject / defer | clarify 一次只问一个具体问题。 |
| Mandate | 模型、分辨率、时长、最高成本、fallback 列表、版权范围 | 不可变；扩大范围 = 新 job + 新报价。 |
| Ticket | 一个可计费的生成 job | 拥有用户可见身份和账单主体。 |
| Assignment | 一次 provider attempt | 重试创建新 attempt，不 fork ticket。 |
| Executor | provider adapter / GPU worker | 独立工作区；只报告事实，不直接写 job 状态。 |
| Subscription | 项目/会话上下文 | 只给上下文，不扩权。 |
| Outbox | 扣款、退款、webhook、邮件、资产发布 | 先记录，commit 后执行；按 ticket 保序。 |
| Policy | 模型目录 + 价格表 + 安全规则 | 版本化；每个 quote 和 mandate 记录版本。 |
| Watchdog | 卡单、超预算、死循环、provider 故障 | 只能停/降级/释放，不能扩预算。 |
采用顺序与反模式
如果你现在只有一个原型，我建议按这个顺序做，而不是先搭「多 Agent 团队」：
- 01先做 schema、idempotency key 和 append-only credit ledger。
- 02再做 quote + 确定性 gate；没有这两层，不要接 provider。
- 03只接一个 provider、一个 worker，把 submit / poll / cancel 跑通。
- 04加 outbox 和 crash-safe submit；先证明重启不会重复提交。
- 05加 webhook + 轮询对账；重复 webhook 必须是 no-op。
- 06做资产镜像、checksum、尺寸/时长校验和审核。
- 07做四状态 UI 和异常队列；不要先做日志流。
- 08加确定性 watchdog；最后才考虑用模型判断「是否跑偏」。
- 09接第二个 provider，做 fallback 和 shadow routing。
不要抄的部分
- 11 个概念全搬。 两人团队做媒体站，先要 job、attempt、ledger、outbox 四个核心，别一开始就上 Correlation、Subscription、Policy 全套。
- 插件化架构。 DeepSeek Harness 的「一切皆插件」是它的底座优势，不是你的 MVP 必需项。
- 多 Agent 角色扮演。 一个队列 + 一组 worker + 一个异常面板，通常比「Router Agent、Planner Agent、Critic Agent」更可靠。
- 用 LLM 做 watchdog。 先把卡单、超预算、重复错误做成确定性检查；模型只处理「有进展但方向不对」这种模糊情况。
- 投机全片渲染。 视频的边际成本太高；投机只做便宜的前置步骤。
- 把 provider URL 当存储。 它会过期、会限流、会消失；你必须自己镜像。
- 先接五个 provider 再做对账。 一个 provider 的对账没跑通，接五个只会放大错账。
如果只记一句话：DeepSeek 值得抄的不是「多 Agent 角色扮演」，而是把一次「可以做」固化成一张可审计的凭证，然后把执行、重试、恢复、通知都挂在它下面。对 AI 视频/图片站，这意味着：先做 quote / gate / ledger，再做 provider 调度；先保证不重复扣费、不重复提交，再谈自治。
来源
这一篇是基于第 1 篇的拆解做的场景翻译，不是 DeepSeek 原文；DeepSeek 讨论的是通用 Agent 系统，不是视频生成。原始链接与核验方式见 第 1 篇的来源与核验。
接着读：第 3 篇把这里的规则落成 SKILL.md 与 harness.yaml；设计来源见 第 1 篇。