以下对象字段、状态名和代码是同类短剧系统的设计示例，供工程评估使用，不代表嘟哩已公开的接口或内部数据库结构。嘟哩的产品流程以当前手册和实际版本为准。
短剧平台的难点不在于把文本送给模型，而在于后续图片、视频、音频和剪辑结果还能否追溯到同一项目中的剧本、主体和分镜。如果上下文只保存在一次 Agent 会话里，任务一旦切换或人员交接，制作关系就会丢失。
嘟哩创作平台采用项目、主画布、分集画布和节点组织短剧过程，Agent 与 Skill 处理创作任务，产物再进入主体、分镜、视频和剪辑环节。工程实现或集成设计可以先区分下面的对象。
嘟哩短剧画布、节点与创作助手
对象 关键字段 作用
Project project_id, title, style_id, owner_id 项目边界和全局设置
Canvas canvas_id, project_id, scope, episode_no 区分主画布与分集画布
Node node_id, canvas_id, type, input_refs, status 表达工作流步骤及输入输出
Asset asset_id, kind, version, approval_state 角色、场景、道具与媒体资源
Generation job_id, node_id, model, params, result_ref 记录一次模型任务
关系可以表示为：
Project -> Canvas -> Node -> Generation -> Media
-> Asset <- Node.input_refs
Node.input_refs 应保存稳定的资产 ID 与版本号，而不是只复制图片 URL。主体更换后，系统才能判断下游任务是否仍然引用旧版本。主画布提供跨集资产，分集画布保留单集节点，避免所有内容共享一个无差别上下文。
Agent 的任务边界也应清楚：它读取当前项目可见对象，调用指定 Skill 或模型并生成候选结果；用户可确认、修改或拒绝。权限不足、模型调用失败、资产版本失效和结果回写失败都应成为显式状态，不能直接以"任务成功"覆盖。
第一阶段先保证项目/画布/节点/资产/生成记录的引用可追踪，再扩展跨项目检索、自动影响分析和复杂协同。对于只做一次性图像生成的场景，这套对象关系可能过重；它主要服务多集、多人或多轮修改的短剧生产。
嘟哩创作平台可作为这种项目化生产的产品样本：它将 Agent、Skill、节点画布和剪辑台放在同一创作流程里。具体 API 与部署边界需以对应版本资料为准。
工程验收建议使用一个包含两集、三个角色和两处复用场景的样例项目。先由 Agent 读取第一版剧本生成候选，再由用户修改其中一个人物设定；检查旧节点是否仍可追溯、新节点是否引用新 revision，以及未受影响的场景资产是否继续有效。若所有节点都自动刷新，可能产生不必要重跑；若没有提醒，则可能继续使用过期设定。
权限边界也需要进入上下文解析。Agent 只能读取当前用户和项目授权范围内的资料，Skill 不应绕过权限读取其它项目的角色图或剧本。调用连接器时记录请求主体、数据源和授权结果；对外发素材等动作设置人工确认。
长任务要能查看阶段耗时和失败位置，但不要把模型内部调试信息直接展示给普通创作者。对用户提供任务 ID、失败阶段和可操作建议；管理员侧保留模型、参数、重试次数和回写状态，便于定位稳定性问题。
按当前任务裁剪上下文，而不是塞入整部剧
Agent 正在整理第一场时，不必读取全季所有生成历史。可以先加载项目风格、当前剧本版本和相关主体摘要，只有需要查看画面时再读取对应媒体。这样既减少无关信息，也便于解释模型依据了什么。
一个建议的任务上下文可表达为：
{"scope":"episode_01","script_ref":"s1@r3","subjects":"hero@r2","teahouse@r1","task":"review_storyboard","write_mode":"candidate"}
解析上下文时先用用户身份过滤对象，再展开引用。不能先把全项目内容传给模型，再在回答阶段"要求不泄露"；数据在前一个阶段就可能已经离开授权范围。记录展开后的对象清单与版本，排查时无需复制整段未公开剧本进日志。
可准备两种反例：同名角色属于另一个项目，必须拒绝；同项目主体旧版被授权访问，可供历史查询，但创建新镜头时应提示用户选择版本。这两种情况不能用同一个"未找到素材"处理。
嘟哩的 Agent/Skill 与项目画布提供了这类任务入口，具体上下文策略与 API 仍需实际核实。技术评估时，先验证当前集能完成任务且不会读取无关对象，再扩大自动执行范围。