Agent Architecture / Durable Execution / Context Engineering / Memory / Creative Workflow
做一支产品短片，往往要经历需求沟通、参考素材整理、分镜、画面生成、视频生成和反复修改。中间有些工作几秒钟就能完成，有些需要等待几分钟；有些适合交给模型决定，有些必须由用户确认。做完第一版以后，工作还远没有结束。
AI 时代来临后，就很少写技术文章了，更多时间留给了不同落地场景的 AI 探索。
很多人认为，AI 时代最大的受益者是产品经理（PM），因为想法与落地之间的距离被极大缩短了。但在我看来，AI 对技术人的赋能或许更加深远。它正在逐渐打破技术实现对创造力的束缚，让技术人有机会跳出代码与工程细节，重新审视产品、架构乃至人机交互的本质。
过去，我们花费大量时间思考如何让机器正确执行指令；如今，我们终于可以将更多精力放在一个更有意思的问题上：如何让机器真正理解人的意图，并以更自然的方式与人协作。
最近，我们在 Lomote AI 上线了 Lomo Agent。借这个机会，想聊聊它从构思到落地过程中的一些思考、架构设计与工程实践。
文章会涉及任务组织、消息路由、持久化执行、异步任务、上下文工程、长期记忆、自主推进和共享创作工作区。其中有些设计已经落地，有些仍在探索和验证。我也会结合 DeepSeek、Manus、Claude Code 等优秀产品和技术实践，分享我在不同方案之间的思考与取舍。
Lomote AI 和 Lomo Agent
Lomote AI 是我们打造的一站式 AI 创作平台。有意思的是，在这个项目中，我更多地扮演了产品经理（PM）的角色，同时也参与了底层基础架构的设计与建设。这也让我有机会从产品和技术两个视角，重新思考 AI 创作工具应该具备怎样的形态与体验。
目前，Lomote AI 集成了多种图像、视频和 3D 生成与增强模型，并提供素材库、灵感板以及 Flows 可视化工作流 等能力。我们希望让创作者能够在统一的工作空间中管理素材、组合模型、编排创作流程，让 AI 创作从零散的模型调用逐渐走向完整、连贯的创作体验。
这些能力在很大程度上解决了 AI 创作工具分散的问题，但随着使用的深入，我们逐渐发现，工具的整合只是第一步，如何让它们真正协同起来解放用户的生产力，才是更值得探索的问题。
在传统的 AI 创作流程中，用户仍然需要自行规划步骤、选择模型、组织素材，并在不同任务之间反复传递上下文和中间产物。当创作流程变得复杂，用户往往需要花费大量精力协调各个环节。
Lomo Agent 正是在这样的背景下诞生的。我希望让 AI 从单纯的创作工具，逐渐成为能够理解意图、规划任务并持续协作的智能体。用户只需描述目标，Agent 便可以调用平台已有的模型与工具，组织创作流程，并在执行过程中根据用户反馈持续调整。
而要实现这样的体验，传统的单轮工具调用显然不够。任务如何组织、上下文如何管理、异步执行如何协调，以及 Agent 如何在用户离开后继续推进工作，都成为了我们需要解决的架构问题。
从一个反复修改的创作任务说起
假设用户周一说："帮我做一组复古风格的品牌海报。" Agent 整理需求，开始生成参考图。 期间用户又插入了另一项任务："顺便把昨天的猫图做成五秒视频。" 到了周三，用户再次提起："之前那组海报再暖一些，文字位置也调整一下。"
这在人与人的日常协作中再正常不过，但对于 Agent 来说，背后涉及多个任务的并行管理、异步生成、上下文关联和历史素材检索。随着任务不断推进，还会遇到取消、重试、预算控制、用户偏好变化以及多端协作等问题。
大约一个月前，我就开始思考一个问题：Agent 为什么一定要以会话（Session）为中心？
现有大多数 Agent 产品仍然沿用 Chatbot 的交互范式，用户需要主动创建、查找和维护会话。对于重度用户来说，会话越积越多，原本应该由 AI 承担的上下文管理工作，反而成为了用户的负担。
而在现实生活中，人们并不会刻意维护所谓的"会话"。我们可以随时切换话题，也可以在几天后自然地接着之前的事情聊下去。理想中的智能体，或许也应该具备这样的能力。
于是，我们尝试在 Lomo Agent 中弱化用户侧的会话概念，将任务识别、上下文隔离和历史关联交给系统处理。当然，这只是整个架构设计中的一环。要真正支撑持续创作，还需要解决执行恢复、异步调度、长期记忆、预算授权以及共享产物管理等一系列工程问题。
在 Demo 制作中，我恰好读到了 DeepSeek 团队关于 Super-agent 的架构设想。很有意思，大家在任务组织和上下文管理上遇到了相似的问题。DeepSeek 团队的《Super-agent设计探索：迈向更自主的 Agent 系统》一文中 Router / Worker 的职责划分，以及后续消息路由的设计，给了我不少启发，也帮助我进一步完善了 Lomo Agent 的整体架构。
下面就结合实际的设计与实现，聊聊我在一些问题上的思考和取舍。
1. 任务组织：从用户请求到可持续推进的事项
回到前面的例子，用户可能在几分钟内切换多个话题，也可能隔了几天才重新提起某个任务。对 Agent 来说，收到消息只是开始，更重要的是理解这条消息属于哪个目标，以及如何找到此前的执行进度和相关素材。
这就涉及一个架构上的取舍：如果所有任务共用一份上下文，不同目标的信息容易相互干扰，模型的上下文窗口也会迅速膨胀；如果完全按照会话进行隔离，又会割裂不同任务之间的历史关联。
因此，我们在 Lomo Agent 中将交互入口、执行上下文和长期记忆分成了三个相对独立的层次：
| 概念 | 解决的问题 | Lomo Agent的处理方式 |
|---|---|---|
| 交互入口 | 用户在哪里表达需求 | 用户侧统一主线，无须手动新建和切换会话 |
| 执行上下文 | 哪些信息应该一起供模型推理 | 系统根据目标创建独立事项，各有上下文边界 |
| 长期记忆 | 跨事项、跨时间哪些信息值得保留 | 来源可追溯的画像、事实和情景摘要，按需召回 |
用户只需要在统一入口中自然地表达意图，系统负责识别任务归属，并为需要持续推进的工作创建独立事项。每个事项拥有自己的上下文、执行状态和产物引用，必要时可以通过受控的检索与共享机制获取其他事项的信息。
在这一设计上，我们也参考了现有产品的不同实践。
例如，ChatGPT 通过跨会话记忆增强了不同对话之间的信息连续性；Claude 则通过 Projects 等机制，让用户能够围绕特定项目组织知识与上下文。这些设计各有优势：显式会话和项目边界便于理解、管理和分享，也让用户对上下文范围拥有更直接的控制权。
但对于需要长期、频繁切换任务的创作场景，用户仍然需要承担一部分上下文组织工作。跨会话记忆可以帮助 Agent 了解用户的偏好和历史，却无法完整表达一个正在执行的任务及其进度。
Lomo Agent 因此选择将更多任务组织工作交给系统，让用户尽可能摆脱日常的会话管理。当然，自动识别也意味着可能出现任务归属错误。为此，我们保留了显式事项入口和纠错机制，并在目标明确时优先采用确定性路由，减少不必要的模型判断。
图 1：Lomo Agent 的任务组织模型
2. 系统总览：协调层、执行层与共享工作区
确定了任务组织方式后，下一步就是考虑如何让这些事项真正运转起来。
一个能够持续协作的 Agent，需要同时处理用户的新请求、推进已有任务、等待外部生成结果，以及响应用户对作品的修改。如果这些工作全部交给同一个 Agent 处理，上下文会迅速膨胀，任务之间也容易相互干扰；如果每个请求都创建独立的 Agent，又会引入额外的协调成本。
基于这样的考虑，我为 Lomo Agent 设计了 Main / Task 双层结构，并在执行层引入持久化运行时，让不同任务能够独立推进，同时通过共享工作区访问和修改创作产物。
2.1 整体架构
整个系统可以分为四个主要部分：
-
Main（主线）：用户持续交互的入口，负责理解新请求、关联已有任务、处理简单问题，以及协调不同事项的执行和反馈。
-
Task（事项）：承载具体创作目标的独立执行空间。每个事项维护自己的任务书、上下文、执行计划、消息收件箱和运行状态。
-
Agent Runtime（运行时）：管理模型推理、工具调用、异步等待、状态持久化和执行恢复，并在每一步检查预算、权限与停止条件。
-
Shared Workspace（共享工作区）：保存图像、视频、3D、文档、素材集与 Flows 工作流等创作产物，允许用户和不同事项在权限范围内共同访问与修改。
在角色划分上，Main 主要承担 Router 的职责，Task 内部则由 Worker 推进具体任务。Router 和 Worker 是逻辑上的运行角色，并不要求使用不同的基础模型。
图 2：Lomo Agent 整体分层架构
这套架构的一个重要特点，是让任务执行与创作产物拥有各自独立的生命周期。
例如，用户在主线发起海报创作，系统为其建立独立事项。后续的参考图、生成记录和修改历史由该事项维护，最终产物则保存在共享工作区。即使用户切换到其他任务，海报事项仍可以继续等待生成结果，并在需要时恢复执行。
主线只需要维护事项的概要和当前状态，无须长期保留每一次模型调用和工具执行的完整过程。这样可以避免随着使用时间增长，主线上下文无限膨胀。
从 DeepSeek Super-agent 中得到的启发
在设计过程中，DeepSeek 团队的 Super-agent 架构设想给了我们不少启发。
它同样采用协调与执行分离的思路，通过 Router / Worker 组织不同目标，并利用 Ticket / Executor 等机制维护任务归属。这种设计尤其适合长期运行、需要反复接收新指令的 Agent。
不过，DeepSeek 公开的研究原型主要面向代码仓库场景。仓库任务通常有相对明确的工作范围、文件变更和交付结果，而 AI 创作的任务边界要模糊得多。
例如，一次简单的图像生成可能只需要几十秒，但用户后续的几次修改，又可能让它逐渐演变成一个长期创作项目。与此同时，同一份素材还可能被多个任务引用和修改。
因此，我们保留了 Router / Worker 的基本分工，同时针对创作场景增加了轻量事项、共享产物身份及异步等待等设计。
这种方式也引入了新的复杂度，例如任务归属判断、共享对象权限和跨事项状态同步。我们会在后续章节分别展开。
2.2 并非每个请求都需要独立 Worker
多 Agent 架构很容易陷入一个误区：既然可以拆分任务，就尽可能把每件事都交给独立 Agent。
但独立执行空间本身存在成本。每创建一个 Worker，都意味着需要维护额外的上下文、运行状态和消息路由关系，模型调用与协调开销也可能随之增加。
以 Lomo Agent 的创作场景为例：
用户询问"这个视频模型支持哪些分辨率"，Main 可以直接处理；
用户要求"生成一张橘猫图片"，可能只需要一次生成任务；
而"制作一组风格统一的品牌海报"，则涉及规划、素材管理、多轮生成和后续修改，更适合创建独立事项。
为此，我们将执行任务进一步区分为 轻量事项（Lightweight Task） 和 正式事项（Persistent Task）。
轻量事项主要用于承载单次生成、执行状态和结果卡片，无须长期占据用户的事项列表。当用户围绕生成结果持续修改，或任务逐渐演变为复杂创作目标时，系统可以将其升级为正式事项，保留后续协作所需的上下文和执行记录。
正式事项则拥有相对完整的生命周期，可以持续接收消息、执行计划、等待外部任务，并在跨天甚至更长时间后恢复工作。
这种划分也是对去会话化设计的一种补充。我们希望减少用户管理会话的负担，自然也不希望最终只是把它替换成另一个需要频繁整理的任务列表。
2.3 一次协作是如何流转的
回到前面品牌海报与猫咪视频的例子。
用户首先在 Main 中发起海报制作，Router 判断这是一个需要持续推进的目标，于是创建对应事项，由 Worker 负责后续规划和生成。
在海报制作期间，用户又要求把之前的猫咪图片生成视频。系统识别出这是另一项独立工作，为其建立新的执行空间。两个事项分别维护上下文，可以根据各自的状态独立推进。
当海报方案需要确认时，Agent 通过事项卡片向用户呈现候选方案。用户直接在卡片上选择，消息便可以根据明确的事项身份送回对应 Worker，无须重新进行语义判断。
几天后，用户在主线中说"之前那组海报再暖一点"，Router 则结合事项索引和历史信息，将这条新指令关联到原来的海报事项。
图 3：Main / Task 多事项协作时序图
这里有一个值得注意的设计细节：消息的归属和消息的执行是两个不同的阶段。
Router 可以将消息分配给对应事项，但 Worker 未必会立即处理。例如，它可能正在等待视频生成，也可能暂停在用户确认节点。新消息需要先进入持久化收件箱，再由运行时根据当前状态安排消费。
这也意味着任务组织只是第一步。随着事项数量增加，如何准确识别用户的后续意图、避免误路由，以及处理执行过程中插入的新消息，会成为整个架构的重要问题。
3. 消息路由：让每条消息找到正确的执行单元
统一交互入口让用户能够自然地切换任务，但也将一个原本由用户完成的工作交给了系统：判断每条新消息应该交给谁处理。
例如，用户刚生成了一张图片，又突然说："把刚才那个换成蓝色。"
这里的"那个"可能指向最新生成的图片，也可能是之前某个海报事项中的素材。
如果归属判断出现偏差，轻则创建重复事项，重则让 Agent 修改错误的作品。
因此，消息路由的准确性会直接影响整个系统的可靠性。我们不希望所有消息都依赖模型重新猜测归属，而是采用了一个相对简单的原则：能够通过明确关系确定的，直接由程序处理；只有缺少明确归属时，才交给模型进行语义判断。
3.1 确定性路由与语义路由
Lomo Agent 的消息接入大致分为三个阶段。
第一层：明确目标的直接路由。
当用户在某个事项面板中回复、点击事项卡片上的操作按钮，或针对明确绑定的作品发起修改时，系统已经知道消息属于哪个目标，可以直接根据 Task ID 或对象关联关系投递。
这种情况下，再调用模型判断一次归属，反而增加了延迟和误判风险。
第二层：Router 进行语义判断。
对于从主线发送、没有明确目标归属的消息，Router 需要结合当前请求、近期交互和已有事项索引进行判断。
可能的结果包括：
-
由 Main 直接处理的简单请求。
-
只需要一次生成的轻量事项。
-
可以关联到某个已有事项的后续指令。
-
需要创建正式事项的新目标。
-
归属存在明显歧义，需要用户进一步确认。
这里还有一个容易忽略的问题：Router 并不需要读取所有事项的完整历史。通常只需要提供事项的目标、摘要、最近状态及相关对象引用，在识别到候选目标后，再按需读取具体信息。
这样可以避免随着任务数量增加，路由本身逐渐演变成另一个不断膨胀的上下文。
我们目前会优先提供最近活跃的一些事项，包括目标、摘要和状态等索引信息；如果用户提起更早的工作，再通过关键词与摘要向量相似度进行检索，将少量相关候选交给 Router 判断。这样一来，事项数量增加主要影响的是检索范围，而不是每次推理必须携带的上下文长度。
还有一种容易发生的错误，是把用户原本想继续的工作当成新目标。为此，在创建正式事项前，系统还会与最近 50 个进行中的事项做一次相似度检查。如果发现可能重复的目标，就把最相似的几个候选交给模型，让它判断应该沿用已有事项还是确认新建。这样的检查可以拦住一部分重复创建，但不能代替所有语义歧义的澄清。对于证据不足的情况，仍然需要让用户明确选择。
第三层：执行前的归属与状态检查。
确定消息目标后，系统仍需要检查事项是否有效、是否允许接收当前操作，以及相关对象是否仍处于可访问状态。
例如，用户可能引用了一个已经归档的事项，或者试图修改已经删除的素材。Router 给出正确的语义归属，并不意味着后续操作一定能够执行。
图 4：Lomo Agent 消息路由流程。
3.2 消息送达，不代表立即执行
消息路由还有一个容易被忽略的细节：消息被分配给某个 Worker，与 Worker 真正开始处理这条消息，可能发生在不同时间。
例如，Agent 正在执行视频生成，用户突然补充："背景改成室内。"
此时视频生成请求可能已经提交给上游服务，无法立即修改。系统需要先保存这条新指令，等 Worker 到达合适的执行边界后，再结合当前进度判断下一步操作。
因此，我们为事项维护持久化的消息收件箱（Inbox）。Router 负责将消息送到正确的收件箱，运行时则负责决定何时读取、如何合并到上下文，以及是否需要调整已有计划。
这里还需要区分几种情况：
-
尚未被 Worker 消费的消息，可以在满足条件时撤回或替换；
-
已经进入模型推理的消息，需要等待当前执行边界；
-
对于已经提交的外部生成请求，当前无法直接撤回。新指令需要等待 Worker 到达合适的执行边界后，再根据任务进度决定是否重新生成，或将新的约束应用到后续步骤。
这种分离也为后续的中断恢复、异步任务与用户随时介入提供了基础。
3.3 从协作产品中借鉴消息归属的设计
在交互设计上，我们也参考了 Slack、飞书等协作产品的消息组织方式。
以 Thread（话题回复）为例，用户在特定话题下回复时，系统天然知道这条消息属于哪个讨论，不需要重新分析整段聊天来判断归属。这种显式关联的优势是稳定、可预测，而且几乎没有额外的语义识别成本。
不过，Lomo Agent 面对的交互场景更加灵活。用户可能直接在事项卡片上回复，也可能回到主线，随口提起几天前的某项工作。
因此，我们保留了两种方式：对于明确的事项操作，直接使用结构化身份路由；对于主线中的自然语言，则由 Router 结合历史事项进行关联。
这种混合策略能够减少模型参与路由的次数，但无法完全消除歧义。例如，用户同时制作了两套海报，却只说"上次那套改一下"，系统可能没有足够证据判断目标。这时主动询问，通常比自行选择一个看似最相关的事项更可靠。
随着事项数量增长，如何在召回率、路由准确性和交互成本之间取得平衡，仍然需要通过真实使用情况持续优化。
不过，归属判断并不是整个链路的最后一道检查。多创建一个事项，通常还可以合并或关闭；如果消息被错误地关联到作品修改、素材删除或付费生成，代价就可能大得多。因此，我们把消息路由与实际执行授权分开：前者判断工作应该交给哪个事项，后者仍要独立检查权限和费用边界。
例如，删除素材、遗忘记忆等不可撤销操作，每次都需要用户确认；付费生成则先给出报价，超出免确认额度、当日免确认上限或者已批准的计划预算时，再要求用户确认。通过开放 API 发起的付费操作也逐笔确认。即使 Router 判断了正确的事项，也不能因此获得超出用户授权范围的执行权。
消息进入正确事项后，执行仍可能跨越数分钟甚至数天，并遭遇进程重启、网络超时或用户取消。可靠恢复由持久化执行机制承担。
4. 持久化执行：中断恢复、重试与并发控制
消息被正确路由到事项之后，接下来要解决的是执行过程的可靠性。
对于普通的 Chat Completion，一次请求通常在几秒到几十秒内完成。但创作 Agent 的工作流程复杂得多：一次视频制作可能涉及多轮模型推理、几十次工具调用，以及多个耗时数分钟的外部生成任务。执行期间，用户还可能随时修改需求或主动停止任务。
考虑一个很常见的故障场景：Agent 向视频生成服务提交了请求，上游实际上已经成功创建任务，但服务进程恰好在收到响应前重启。
恢复后应该怎么处理？如果直接重试，可能重复生成并再次扣费；如果认为请求已经成功，又可能永远等不到一个实际上并未创建的任务。
这类问题让我们意识到，Agent 的执行过程需要有独立于模型上下文和服务进程的持久状态。
因此，我在 Lomo Agent 中引入了 Durable Execution（持久化执行） 机制。数据库记录关键执行状态、模型决策及工具调用结果；任务队列负责执行调度与恢复；实时事件则用于向用户反馈进度。即使执行进程中断，系统仍能根据已保存的事实判断下一步应该做什么。
在设计上，我们参考了 Temporal 的 Durable Execution 思路。Temporal 通过工作流历史、任务调度和重试机制，让业务流程能够跨越单个进程的生命周期，其优势在复杂、长时间运行的工作流中尤其明显。
不过，通用工作流引擎也有相应的建模与运行成本。Lomo Agent 的执行过程还需要管理模型推理、动态工具调用、创作状态和用户交互，因此我们围绕 Agent 自身的数据结构实现了执行台账与事件调度机制。这里借鉴的是持久化执行的工程思想，并不意味着直接使用了 Temporal 的方案。
4.1 先持久化决策，再执行工具调用
传统的 Agent Loop 通常遵循一个简单流程：
读取上下文 → 模型推理 → 调用工具 → 获取结果 → 继续推理。
在短任务中，这种实现相对直接。但当执行过程跨越多个进程、外部服务和计费系统时，任何一步中断都可能造成状态不一致。
我们将执行过程划分为一系列 Step。每个 Step 可以包含一次模型推理，以及模型提出的一组工具调用。
在执行工具之前，运行时首先持久化模型的决策结果和待执行调用。每次工具调用都有稳定的业务标识，并在执行台账中记录其状态、输入及结果。
这样一来，Worker 恢复时就可以根据台账判断哪些操作已经完成、哪些可以重试，以及哪些需要先核对外部状态，无须重新调用模型生成同一轮工具决策。
图 5：Agent 的持久化执行流程。
这里涉及一个关键概念：幂等性（Idempotency）。
假设用户批准生成一段视频，系统因为网络超时重复提交了同一请求。理想情况下，两次提交应当对应同一笔生成订单，不能产生两段重复视频，更不能重复扣费。
对于支持幂等键的下游服务，可以使用稳定的调用标识进行去重；对于平台内部的订单和计费流程，也可以通过调用 ID、订单 ID 和唯一约束保证重复请求不会产生新的业务效果。
但如果上游生成接口既不支持幂等键，也无法查询请求结果，那么网络超时之后，系统实际上无法确认任务是否已经创建。
此时，持久化执行并不能凭空提供 Exactly-once（恰好一次执行）保证。
我们需要进一步区分两种情况：对于少数不可幂等的工具，如果执行台账已经记录 started，却始终没有结果，运行时不会直接重新执行，而是将带有 outcome_unknown 标记的结果交给模型，让它先检查当前状态，再决定后续动作。对于支持幂等的调用，则可以沿用原来的调用标识重放。
还有一层不确定性发生在生成服务与上游接口之间。这里我们采取了更保守的策略：如果提交结果不明，就将这次提交判为失败，不自动再次向上游发起请求。两者看似都叫"结果未知"，但一个是在处理 Agent 工具调用的恢复，另一个是在避免重复创建实际收费的生成任务。
Temporal 在 Activity 重试方面同样面临这一问题。工作流引擎可以可靠地调度和重试执行，但外部 API 的副作用仍然需要业务幂等机制配合。
对于付费生成服务，这一边界尤其重要。一次执行失败可以恢复，重复扣费却未必能够自动弥补。
4.2 Worker 接管与 Fencing Token
持久化执行解决了进程中断后的恢复问题，但还有一种更隐蔽的情况：原来的 Worker 可能并没有真正退出。
例如，Worker A 在执行过程中因为网络抖动暂时失联。系统检测到超时后，由 Worker B 接管任务并继续执行。几秒钟后，Worker A 恢复连接，尝试提交自己刚才完成的结果。
此时系统中可能同时存在两个认为自己拥有执行权的 Worker。如果不加限制，旧 Worker 就可能覆盖新状态，甚至让已经停止的任务重新进入执行流程。
为此，我们采用类似 Fencing Token（栅栏令牌） 的执行代次机制。
每当任务被新的执行者接管，运行时就提升该任务的执行代次。Worker 在提交状态变更时，必须携带并校验自己所持有的代次。
如果当前数据库中的代次已经更新，旧 Worker 的提交便会被拒绝。
这一机制可以理解为：系统允许新的执行者接管工作，同时撤销旧执行者继续修改内部状态的资格。
用户主动停止任务时，也需要通过运行状态与执行代次检查，阻止旧 Worker 在恢复后继续推进。
不过，Fencing Token 保护的是系统自身的状态一致性。如果旧 Worker 已经向外部平台发起了视频生成请求，内部执行权失效并不能自动撤销远端操作。
因此，即使用户已经停止事项，先前提交的外部生成仍可能继续运行。生成服务会继续跟踪任务结果并完成相应的费用结算，但迟到的完成事件不会重新唤醒已停止的事项，也不会改变已经取消的执行状态。
4.3 执行过程中如何处理用户的新消息
还有一类问题来自用户的实时介入。
假设 Agent 正在调用模型，准备生成一组海报。此时用户发来："背景不要白色，换成深蓝色。"
这条消息可能在模型推理结束之前就已经到达服务器，但当前模型请求实际上并没有读取它。
如果系统只按照消息的创建时间拼接历史，就可能出现一种状态错乱：模型看起来是在用户修改要求之后作出的决定，实际上却完全不知道这条新指令。
为了解决这个问题，我们将消息接收和消息消费分开处理。
新消息首先进入对应事项的持久化 Inbox。Worker 在下一次安全执行边界读取这些输入，并将它们与当前任务状态一起组织进模型上下文。
系统记录消息在哪个 Step 被实际消费，而不单纯依赖消息发送时间判断先后关系。
这样可以明确区分用户指令已经送达、模型已经理解，以及相关操作已经执行这几个阶段。
当然，如果生成请求已经提交到上游，后来的修改不会自动改变正在生成的内容。当前版本也无法撤回这类请求，Worker 只能在下一次安全执行边界决定是否重新生成，或者把新的约束应用到后续步骤。如果用户已经停止事项，旧生成即使随后完成，也不会让事项重新开始执行。
对于用户而言，界面也需要准确反馈这一状态，避免将"消息已收到"误解为"当前生成已经按新要求调整"。
对于视频、音频和 3D 等耗时生成任务，Worker 还需要在等待外部结果时释放执行资源，并在事件到达后准确恢复。
4.4 执行台账与调度一致性边界
前面讨论了模型决策的持久化，以及如何通过执行代次避免旧 Worker 在任务接管后继续修改状态。但在实际运行中，还有一个容易被忽略的问题：如果数据库已经记录了待执行的工作，负责唤醒 Worker 的队列消息却丢失了，任务该如何恢复？
在 Lomo Agent 中，我们通过轮次（Turn）和工具调用台账维护执行状态。轮次记录运行状态、执行代次、租约及检查点（Checkpoint），工具调用则以"轮次 + 步号 + 调用序号"作为稳定标识。模型返回后，运行时会在同一个事务中保存决策结果、待执行调用和已消费的 Inbox 消息；工具执行前记录 started，完成后将结果与 done 状态一并保存。这样，恢复时便能根据已有记录复用结果或安全重试，而无须让模型重新推测之前发生了什么。对于无法安全重试的调用，则保留结果未知的状态，交由后续决策处理。
在任务调度上，我们没有为轮次入队引入事务性 Outbox，而是将数据库作为执行事实的来源，队列主要负责唤醒 Worker。轮次提交后再发送调度消息，如果入队失败，后台看门狗会根据数据库状态重新发现任务。目前，看门狗每 10 秒检查一次，主要关注租约过期、长时间排队以及存在未处理消息却没有活动轮次的事项。队列任务以轮次 ID 和执行代次标识，减少同一代次的重复入队；即使发生重复调度，运行时仍会通过执行状态与代次校验防止过期写入。这意味着我们接受有限的恢复延迟，换取更简单的调度机制；界面事件推送和外部生成任务则分别保留各自的可靠投递与补偿机制。
另一类风险来自新旧 Worker 的并发执行。Fencing Token 能阻止旧 Worker 覆盖内部状态，却无法撤销已经发出的外部请求。对此，我们将付费生成的幂等键固定为"轮次 + 步号 + 调用序号"，不包含执行代次。即使新旧 Worker 重复提交同一调用，平台生成层也会通过"工作区 + 幂等键"的唯一约束关联到同一笔订单，并对内部扣费进行去重。这能够控制平台内部的重复订单与计费，但不意味着外部上游天然具备 Exactly-once 保证。相比之下，模型决策尚未持久化时发生故障，可能导致该步重新推理。考虑到当前以媒体生成为主的成本结构，我们选择接受这部分相对有限的重复推理成本。
更难处理的是上游提交结果不明确的情况。请求超时可能意味着提交失败，也可能是上游已经创建任务、响应却未能返回。为避免重复生成，当前生成服务不会自动重新提交此类请求；成功获得上游任务 ID 后，则会立即持久化，以便中断后继续轮询。但如果进程恰好在取得 ID 与保存之间崩溃，目前还无法反查这笔任务。系统只能在超时后按规则处理退款，由平台承担可能已经产生的上游费用。
这些设计并不能消除所有故障窗口，但明确了不同情况下的处理边界：能够确认完成的直接复用，能够安全重试的继续执行，无法确认的则避免盲目重复提交。 对于持续运行的 Agent，可靠性并不意味着每一步都不会失败，而是发生中断后，系统仍能依据已有事实作出可控的恢复决策。
5. 异步生成：任务生命周期与事件唤醒
前面介绍的持久化执行，主要解决了 Agent 在运行过程中如何记录状态、处理故障以及恢复执行的问题。但在 AI 创作场景中，还有一个绕不开的特点：大量工具调用本身就是异步的。
例如，图像生成可能只需要几秒钟，视频和 3D 任务却可能持续数分钟，甚至更长。任务提交后，上游服务通常只返回一个任务 ID，真正的生成结果需要通过轮询或回调才能获取。
如果让 Worker 一直等待外部任务完成，不仅会占用执行资源，也会将模型推理与不可控的外部生成耗时耦合在一起。
因此，我们将 Agent 的执行生命周期 与 外部生成任务的生命周期 分开管理。
5.1 提交、等待与恢复执行
当 Worker 调用生成工具时，工具首先向对应服务提交请求，并返回生成任务的标识。运行时随后保存任务与当前事项之间的关联关系，包括任务 ID、等待状态及后续执行所需的信息。
完成提交后，Worker 可以挂起当前执行，不需要持续调用模型，也无须维持一个长时间运行的推理请求。
在等待期间，生成服务的进度变化可以直接通过业务事件推送给前端，由事项卡片展示当前状态。
等到任务完成，运行时再根据后续步骤是否依赖生成结果，决定是否重新唤醒 Worker。
图 6：异步生成任务的执行流程（正常路径）。
这个设计带来的直接收益是资源利用率的改善。等待视频生成的几分钟里，系统只需要维护持久化状态和必要的事件处理，不必持续占用 Agent 推理资源。
同时，生成进度与用户界面也可以独立更新。用户能够实时看到任务状态，而不需要等待 Worker 再次调用模型。
5.2 异步事件也需要可靠处理
把生成任务改成事件驱动之后，还需要考虑事件本身的可靠性。
例如，上游服务可能因为网络问题重复发送完成通知，也可能在某次回调失败后无法立即重试。对于同时运行的多个生成任务，进度事件还可能乱序到达。
因此，事件处理不能简单地理解为"收到回调就继续执行"。
我们需要以持久化的任务状态为依据，对生成任务进行状态更新，并确保重复事件不会导致重复写入、重复计费或重复唤醒 Worker。
对于可能发生乱序的事件，也需要避免旧进度覆盖最终结果。例如，任务已经完成，随后又收到一条延迟到达的"生成中"通知，就不应该让状态重新回退。
此外，外部回调不一定可靠。对于长时间没有收到结果的任务，可以结合任务 ID 和上游查询接口进行状态核对，必要时使用补偿轮询恢复任务进度。
这里与前面介绍的 Durable Execution 是相互配合的：运行时负责维护可信的执行状态，异步任务系统负责将外部生成过程中的变化转化为可恢复的业务事件。
5.3 什么情况下需要唤醒 Worker？
还有一个与模型调用成本直接相关的问题：生成任务完成后，是否每次都需要重新调用模型？
答案取决于任务后续是否还有需要 Agent 决策的工作。
例如，用户只是要求"生成一张猫咪图片"。生成完成后，系统直接展示结果即可，没有必要再唤醒 Worker，让模型重复描述已经生成的图片。
但如果用户要求"制作一组风格一致的品牌海报"，当前生成结果可能会成为后续步骤的输入。Agent 需要检查已有产物、读取执行清单，并根据当前目标决定下一步是否继续生成或等待用户确认。
因此，我们将生成完成事件与 Agent 续跑决策分开处理。
生成服务负责报告结果；运行时根据任务计划、等待关系、授权和当前执行状态判断是否需要恢复 Worker。
这也避免了将大量进度事件直接交给模型处理。对于一个持续数分钟的视频任务，上游可能产生很多状态变化，但绝大多数变化只需要更新前端，不值得触发新的推理。
这种事件驱动的设计，与通用工作流引擎和任务队列中的异步等待机制相近。对于 Lomo Agent，我们进一步关注的是如何将它与创作目标、执行清单和用户审阅流程结合起来。
比如，一个视频镜头生成完成后，如果后续还有其他镜头需要制作，且用户已经授权继续执行，运行时便可以恢复对应事项；如果当前阶段需要用户审阅，则应停留在等待确认的状态。
生成完成，只代表某个工具调用已经结束。至于整个创作任务是否应该继续，还需要结合计划、预算与授权进行判断。
这也引出了后续的自主推进机制：当 Agent 完成一个阶段，甚至准备结束本轮推理时，系统如何判断任务是否真正完成，以及是否应该继续执行。
6. Context 工程：在有限窗口内维护有效状态
随着 Agent 开始处理长时间、多阶段的创作任务，上下文管理逐渐成为影响执行质量和成本的重要因素。
一个持续数天的创作事项，可能积累数百条消息、几十次工具调用，以及大量图像、视频和工作流状态。即使模型的上下文窗口越来越大，将这些信息全部塞进每次推理也并不现实。
一方面，长上下文会带来更高的 Token 成本和推理延迟；另一方面，过多的历史信息还可能干扰模型对当前目标的判断。尤其当用户多次修改要求时，早期已经失效的约束如果仍然混在上下文里，很容易影响后续生成。
因此，我们将上下文管理视为一个独立的工程问题：在每一步推理时，如何让模型获得足够、相关且仍然有效的信息。
6.1 上下文分层与 Prompt Cache
Lomo Agent 将模型上下文组织为几个层次，包括相对稳定的系统前缀、经过压缩的历史、近期交互，以及当前执行步骤所需要的动态状态。
图 7：Lomo Agent 的上下文组织方式。
这里有一个与实际推理成本密切相关的因素：Prompt Caching（提示词缓存）。下文的 Prompt Cache 指模型服务商在 API 层提供的提示词缓存能力；其具体实现及可复用范围由服务商决定。
支持该能力的模型服务可以复用符合其缓存规则的提示词前缀，减少重复处理成本。因此，我们尽量保持系统规则、核心工具和相对稳定的画像信息处于上下文前部，而将每一步都可能变化的任务状态放在后部。
如果把高度动态的信息插入前缀开头，后续原本稳定的内容也可能无法有效复用缓存。
不过，Prompt Cache 的实际命中率还受到模型服务商、请求路由和缓存策略的影响。上下文布局只能为缓存复用创造条件，最终收益仍需要通过实际调用数据验证。
此外，稳定前缀也不意味着画像可以长期不更新。当用户修改偏好或要求忘记某些信息时，相关画像快照必须及时失效，避免缓存复用导致过期信息继续参与推理。
6.2 工具按需加载，能力越多，上下文越昂贵
Lomote AI 集成了多种创作模型与工具，涉及图像生成、视频生成、3D、素材管理、文档编辑以及 Flows 工作流等不同领域。
如果将所有工具的名称、参数和使用说明都放进每一次模型请求，不仅会增加 Token 消耗，还可能让模型在大量相似工具之间做出错误选择。
因此，我们将工具分成两类：一类是需要长期可见的核心工具，另一类则按照能力领域动态加载。
例如，当 Agent 正在进行分镜规划时，可能只需要文档和素材相关工具；进入视频制作阶段后，再加载视频生成与工作流能力。
对于不再活跃的工具领域，可以在上下文压缩边界移除其详细定义，减少无关信息对后续推理的影响。
这种设计也存在代价。工具集合发生变化时，模型上下文的结构可能随之改变，影响 Prompt Cache 命中率；历史中已经出现的工具调用，也可能与当前可见的工具定义不完全一致。
在这一点上，Manus 的 Context Engineering 实践 给了我们一个值得思考的反例。
Manus 更倾向于保持工具定义稳定，通过约束当前可用动作来降低工具选择复杂度。这样有助于减少工具定义变化造成的前缀失效，并更容易维持历史工具调用与当前上下文的一致性。这里讨论的是稳定上下文对缓存复用的影响，不将 API 层的 Prompt Caching 与模型推理内部的 KV Cache 机制直接等同。
Lomo Agent 选择按领域加载，主要是考虑到创作平台的工具类型和参数结构相对庞大，长期保留全部工具定义可能带来较高的上下文开销。
两种策略各有适用条件：稳定工具集合更有利于缓存与行为一致性，动态加载则可能减少无关工具带来的 Token 成本和选择干扰。
对于我们的方案，实际效果需要结合工具切换频率、缓存命中率、工具调用准确率和整体推理成本持续评估。另外，工具是否出现在模型上下文里，只影响模型当前能够选择什么。真正的工具执行权限依然由服务端控制，不能依赖 Prompt 中的工具可见性作为安全边界。
6.3 历史压缩：摘要之外，保留回读能力
长期执行过程中，历史消息和工具结果会持续增长。即使采用较大的上下文窗口，也需要在适当阶段进行压缩。
常见的做法是让模型不断总结之前的历史，再使用最新摘要继续对话。但这种方式存在一个问题：摘要在反复压缩过程中可能逐渐丢失细节，甚至将模型自己的推测固化为历史事实。
因此，我们采用分段摘要的思路，将较早的历史按区间压缩，同时保留近期交互的完整内容。
新产生的摘要尽量追加到已有摘要序列中，避免每次都重新改写整段历史。
对于大型工具输出，例如素材列表、工作流节点信息或复杂的生成结果，系统可以只在当前上下文中保留必要摘要，将完整内容放在外部存储中。
当 Agent 后续需要检查某个具体参数或历史细节时，再通过检索或分页读取恢复相关信息。
这与 Manus 提倡的将文件系统作为外部上下文载体有相通之处。模型无需长期携带所有信息，但必须能够在需要时重新找到可靠的原始依据。
这里还有一个值得注意的区别：摘要是为了降低当前推理的上下文负担，并不应该成为唯一的历史事实来源。 尤其当用户纠正了某项信息，或者某个历史约束已经失效时，系统需要能够定位相关来源，避免旧摘要继续影响后续执行。
6.4 让当前任务始终保持在模型视野内
上下文压缩解决了历史过长的问题，但另一个同样重要的问题是：Agent 执行到一半时，是否还清楚自己正在完成什么目标？
对于长时间运行的任务，模型可能在多轮工具调用后逐渐偏离最初目标。例如，用户要求完成一套品牌海报，Agent 却将大量精力花在反复优化某一张参考图上，忽略了整体交付。
因此，我们会在 Worker 的动态上下文中持续提供当前任务书、执行清单、关键约束、等待状态和相关作品的最新变化。
这些状态来自持久化运行时，而不只是模型对前面聊天内容的总结。
例如：
-
任务书记录用户最终批准的视觉方向
-
执行清单记录哪些步骤已经完成、哪些仍需继续
-
工作区状态则告诉模型某个素材是否被用户替换，以及当前文档处于哪个版本。
当用户直接修改 Flows 工作流或共享文档时，下一轮执行也可以收到对象变更提示，并在需要时读取最新内容。
这样一来，即使部分历史已经被压缩，Agent 依然能够根据可信的任务状态继续工作。
在这方面，Manus 通过持续呈现待办清单来维持模型对目标的关注，也给了我们不少启发。Lomo Agent 则进一步将这些清单与运行时状态结合，使其既能为模型提供上下文，也能支持后续的自动续跑和停止判断。这部分也会在自主推进章节详细介绍。
6.5 上下文工程的实际取舍
综合来看，Lomo Agent 的上下文工程主要围绕三个目标展开：
-
减少无关信息
-
控制推理成本
-
保证当前决策所依据的信息仍然有效
但这些目标之间并不总是一致。
更激进的压缩可以降低 Token 消耗，却可能遗漏重要细节。动态工具加载可以缩小工具选择空间，却可能影响缓存命中。长期保留稳定画像能够增强连续性，但又必须处理偏好变更和记忆撤销。
因此，上下文管理很难依靠一种固定策略解决所有问题。它需要与任务状态、记忆系统、工具权限和实际模型表现共同调整。
对于 Lomo Agent，我们更关注的是模型能否在需要的时候找到正确的信息，并基于当前有效的任务状态继续推进。而当协作跨越多个事项、多个日期，甚至持续数月时，仅靠事项内部的上下文管理仍然不够。用户长期形成的偏好、历史项目以及曾经作出的决定，需要由另一套机制进行组织和检索。
7. Memory 工程：来源、版本与可撤销性
上一章讨论了如何在有限的上下文窗口中组织信息。但对于需要长期协作的 Agent，还有一个更深层的问题：当某段对话已经离开当前上下文，甚至相关事项早已结束，系统应该记住什么？
在 Lomo Agent 的创作场景中，用户可能持续使用平台数月，逐渐形成相对稳定的视觉偏好、常用创作流程和品牌规范。这些信息不应每次都要求用户重新描述。
与此同时，用户的偏好也会发生变化。某个项目采用的临时风格，未必适用于之后的所有创作；过去成立的品牌规范，也可能在一次改版后彻底失效。
因此，我们希望长期记忆能够跨越事项和时间提供连续性，同时保留事实的来源与有效范围。
7.1 从历史消息到长期记忆
长期记忆首先需要解决的是信息筛选。
例如，用户说"我通常喜欢低饱和度的配色"，这可能是一条值得长期保存的偏好；但如果他说"这次先试试高饱和的红色"，则更可能只是当前作品的局部要求。
两句话都涉及颜色，却具有不同的适用范围。如果系统将所有用户消息直接写入向量数据库，再依靠语义检索回填，就很容易混淆长期偏好、临时要求和已经失效的历史信息。
为此，我们将 Lomo Agent 的记忆划分为几个层次：
| 记忆层次 | 保存内容 | 主要用途 |
|---|---|---|
| 原始证据（Evidence） | 用户消息、来源、时间及有效状态 | 为事实抽取、纠正和撤销提供依据 |
| 原子记忆（Atomic Memory） | 用户偏好、项目事实、常用习惯等，记录来源与版本 | 支持跨事项的按需检索 |
| 情景摘要（Episodic Memory） | 一段交流或某个事项的阶段性概要 | 帮助 Agent 找回历史项目及其进展 |
| 用户画像（User Profile） | 少量相对稳定、价值较高的信息 | 为日常协作提供低成本背景 |
这些层次之间存在一定的关联，但承担的职责不同。
原始消息是可追溯的证据。系统可以从中抽取候选记忆，再根据来源、时间、适用范围和已有记录判断是否需要保存、补充或更新。
情景摘要则更关注一段协作发生了什么。例如，用户上周制作了一组品牌海报，最终选择了暖色系方案，并决定暂缓后续的视频制作。这些信息未必都值得进入长期画像，但可能在用户下次提起项目时发挥作用。
用户画像需要更加克制。它应当保留少量相对稳定的信息，避免随着使用时间增长变成另一份不断膨胀的历史对话。
在实际召回时，系统再根据当前事项的目标和权限，选择需要提供给模型的记忆，而不必每轮加载完整历史。
这里还有一条重要原则：记忆必须区分用户明确表达的事实与模型自己的推测。
例如，Agent 因为用户连续生成几张赛博朋克图片，就推断他长期偏好赛博朋克风格。这可以作为候选判断，却不能直接等同于用户明确表达的偏好。
同样，网页内容、工具返回结果和 Agent 自己生成的摘要，也不能在没有可靠依据的情况下，被重新包装成用户的个人事实。
7.2 从现有记忆架构中得到的启发
在长期记忆的设计上，我们参考了几种不同的技术路线。
OpenClaw 的记忆实践强调可检查、可维护的存储方式，以及记忆与原始上下文之间的关系。其优势在于透明度较高，便于用户或开发者检查保存了什么；但当记忆规模持续增长时，检索、维护和冲突处理仍然需要额外机制。
Mem0 更关注如何从对话中抽取有价值的信息，并在后续交互中通过检索恢复相关记忆。这种方式适合长时间、跨话题的智能体使用，但记忆质量高度依赖抽取准确性和召回策略。如果把临时指令误判成长期偏好，后续检索反而可能持续放大错误。
Zep / Graphiti 则提供了另一种思路：在记忆中显式维护实体关系和时间信息。这对于处理不断变化的事实尤其有价值。例如，某个品牌过去使用蓝色作为主色，后来改成了绿色，两条记录并不一定互相矛盾，它们可能分别对应不同的有效时间。
不过，时态关系和知识图谱也会引入更高的维护复杂度，包括实体归一、关系更新、冲突处理和检索成本。
结合 Lomo Agent 的创作场景，我们更关注三个问题：
-
用户偏好是否有可靠来源
-
历史事实是否仍然有效
-
用户纠正或撤销信息后，相关记忆能否同步更新
因此，除了常见的分层存储与语义检索，我们也为记忆维护来源、版本和派生关系。
7.3 "忘记"为什么比"记住"更难
长期记忆还有一个容易被忽略的问题：当用户明确要求忘记某些内容时，系统应该如何处理？
假设用户最初说："我们品牌的主色是蓝色。"
后来又补充："蓝色搭配米白，整体会更柔和一些。"
记忆系统可能将两次表达整合成一条新的品牌偏好：
"该品牌偏好蓝色与米白色搭配，整体视觉倾向柔和风格。"
如果用户随后要求忘记最初关于蓝色的设定，只删除第一条原子记忆显然不够，因为整合后的版本仍然包含相关信息。
随着系统持续运行，这条信息还可能进入情景摘要、用户画像，甚至被合并进其他派生记忆。
因此，我们为记忆维护来源与派生关系，用来描述一条记忆由哪些历史证据和旧版本演变而来。
图 8：记忆撤销流程。
在实际实现中，我们通过版本链维护记忆的演化过程。以前面的品牌主色为例，最初关于蓝色的表达会形成有效版本 v1，并关联原始证据（ORIGIN）；当用户补充米白色的搭配要求时，系统产生新版本 v2，将原有版本标记为 SUPERSEDED，同时记录新增的修正证据（REFINE）。如果后续只是确认已有结论，则可以记录为 CONFIRM，而无须重新生成一条记忆。
当用户要求忘记最初的蓝色设定时，系统会撤销对应证据的使用资格，并沿版本关系定位受影响的记忆。依赖该证据的版本会被删除并清空内容，再根据剩余有效证据重新抽取；仅起确认作用的证据则可以解除关联，而不影响独立成立的记忆。
这一撤销过程还会传播到用户画像和情景摘要。相关画像条目失效后，系统会更新画像版本，让后续推理不再使用旧快照；受影响的摘要则需要重新构建。同时，系统会删除相应的检索向量，并抑制已删除内容被再次抽取，降低旧信息重新进入上下文的风险。
需要注意的是，已经发出的模型请求无法被即时撤销。为此，我们还会追踪回复与工具结果所依据的消息和记忆，在后续推理中排除受到影响的派生内容，避免已遗忘的信息通过 Agent 自己的历史输出重新被引入。
这里讨论的"忘记"，主要针对长期记忆及其派生上下文的使用资格，并不等同于删除所有原始聊天记录、生成素材或交易数据。后者属于不同的数据生命周期和隐私管理问题，需要独立处理。
7.4 记忆的可靠性与降级策略
来源追踪和版本管理能够提高记忆系统的可控性，但并不能彻底消除模型理解错误。
例如，同一段对话可能同时包含多个候选事实，其中一条符合保存条件，另一条只是模型误解的临时指令。如果将整批抽取结果视为一个不可拆分的整体，单条异常就可能影响其他有效记忆。
因此，候选记忆需要逐条校验与处理，区分来源不支持、内容冲突和输出格式异常等不同情况。
当记忆服务发生故障时，也不应该让正常的创作任务完全停摆。
例如，召回超时可以暂时跳过记忆补充；后台抽取失败可以在后续重新处理；单条候选格式异常，不必让其他有效记录一起丢失。
这种降级策略意味着 Agent 在部分情况下可能无法使用完整的历史偏好，但仍然能够根据当前任务书和已有执行状态继续工作。
相比让一个有问题的记忆结果影响整个任务，我们更倾向于保留正常执行路径，并在记忆恢复后重新提供相关背景。
长期记忆的价值，最终还需要通过实际协作来验证。除了召回准确率，我们也关心记忆是否过时、是否能够解释来源，以及用户完成纠正或撤销后，旧信息是否仍然影响后续决策。
随着记忆与任务上下文逐渐完善，Agent 已经能够获得跨时间的背景信息。但知道用户过去做过什么，并不意味着能够判断当前任务是否应该继续。
对于一个包含多个创作步骤的事项，还需要有明确的执行计划、停止条件和用户授权边界。这也是下一章自主推进机制要解决的问题。
8. 自主推进：计划、停止条件与用户授权
前面的几套机制，让 Agent 能够维护长期任务、恢复中断的执行，并在需要时找回历史信息。但对于一个需要持续推进的创作目标，还有一个问题没有解决：Agent 如何判断自己是否应该继续工作？
例如，用户要求制作一支品牌短片。Agent 完成剧本和分镜后，可能会给出一段总结，然后结束当前轮次。此时模型并没有出错，它确实完成了当前阶段的工作，但距离用户最终希望得到的成片还有很长一段距离。
在早期 Demo 和场景演练中，我们遇到过类似情况。用户需要反复发送"继续"，Agent 才会进入下一个阶段。
另一方面，如果简单地要求模型"在完成全部任务前不要停止"，又容易产生另一个问题：Agent 可能反复尝试已经失败的操作，持续生成没有必要的素材，或者在缺少用户确认的情况下自行扩大创作范围。因此，我们需要让任务目标和执行进度独立于单轮模型回复，并由运行时控制自动推进的边界。
8.1 将计划转化为可持续维护的执行清单
我们引入了 Execution Checklist（结构化执行清单），用来记录一个创作目标从计划到交付的主要步骤。
与模型在聊天中生成的普通 TodoList 不同，执行清单是由系统持久化维护的结构化状态。每个步骤可以关联执行状态、产物、完成证据和必要的用户确认要求。
例如，制作一支品牌短片，可以组织为：
| 执行阶段 | 主要任务 | 完成依据 |
|---|---|---|
| 剧本与分镜 | 确定叙事和镜头设计 | 分镜文档及用户确认 |
| 角色与场景 | 准备视觉参考素材 | 对应素材与版本记录 |
| 镜头生成 | 调用视频模型生成镜头 | 外部生成任务及结果 |
| 方案审阅 | 检查镜头与整体方向 | 用户反馈或授权的验收结果 |
| 最终交付 | 整理可交付产物 | 最终作品及关联素材 |
当用户批准执行方案后，清单成为后续推进的依据。Worker 可以根据当前步骤进行规划和工具调用，运行时则能够在每轮执行结束后检查进度。
需要注意的是，执行清单并非不可修改的固定计划。
创作过程经常发生变化。例如，用户在镜头生成阶段决定更换角色设定，原有步骤和部分产物可能需要重新调整。此时系统需要根据新的用户指令更新计划，并维护步骤与产物之间的关联。
执行清单解决的是目标和进度的持续性。它让 Agent 在上下文压缩、异步等待或进程恢复之后，仍然能够找到当前任务的执行位置。
8.2 模型停止输出之后，任务是否应该继续？
计划持久化以后，还需要回答一个更具体的问题：当模型完成当前轮次，运行时应该如何处理？
在设计这部分机制时，我们参考了 Codex Goals 和 Claude Code Hooks 的相关思路。
Codex Goals 将目标与持续执行状态结合，使 Agent 能够围绕尚未完成的目标继续推进；Claude Code 的 Stop Hook 则允许在模型准备停止时执行额外检查，并根据检查结果决定是否阻止当前停止行为。
这两种设计给我的启发是：模型结束一次回复，并不一定代表整个任务已经完成。运行时需要有独立的目标状态和停止检查机制。
不过，代码 Agent 与创作 Agent 的完成标准存在明显区别。
在代码任务中，测试通过、构建成功或预期文件完成修改，通常可以提供比较明确的执行证据。创作任务则很难拥有统一的客观标准。一段视频成功生成，并不能说明角色一致性、镜头节奏和整体视觉效果已经符合用户预期。
因此，我们将流程进展 与作品验收分开处理。
前者可以依据执行清单、工具调用记录和产物状态进行判断；后者则需要结合多模态理解、具体任务要求以及必要的人工审阅。
运行时在每轮执行结束后，检查当前任务是否仍有待推进步骤、是否存在外部等待、是否需要用户确认，以及是否已经达到执行限制。
图 9：运行时根据持久化任务状态决定是否继续执行，而非单纯依赖模型是否结束输出。
这里需要特别关注实质进展（Meaningful Progress）。
例如，新增了可用的创作产物、完成了某个清单步骤，或者成功提交了新的生成任务，都可以作为执行进展的参考。
但如果 Agent 只是在反复修改计划描述，或者不断将步骤状态从"待办"切换到"进行中"，并没有产生新的有效结果，就不应无限续跑。
我们通过进展检查与执行限制，尽可能降低此类空转带来的推理成本。
当然，这种判断依然有局限。生成了新素材，只能证明系统执行了操作，不能直接证明素材质量达标。更完整的多模态质量验收仍然是后续需要持续探索的方向。
8.3 Human-in-the-Loop：让用户参与关键决策
在创作过程中，用户往往希望将重复性操作交给 Agent，同时保留对关键创作方向的控制权。
例如，品牌视觉方向、角色设定、分镜方案和最终镜头选择，通常具有较强的主观性。如果 Agent 在这些节点自行决定并继续生成，后续可能产生大量无效成本。
因此，我们引入 Human-in-the-Loop Checkpoint（人工把关点），在需要用户参与的阶段暂停自动推进。
到达把关点时，Agent 可以通过结构化卡片展示当前方案、候选结果和建议操作。用户直接选择"确认继续"或"调整方案"，系统再根据明确的操作结果更新任务状态。
这类交互也参考了 Claude Code 等产品的权限确认方式：对于具有明显副作用的操作，系统应当提前告知用户执行内容，并由用户决定是否继续。
不过，创作场景中的人工把关不仅涉及权限，还涉及审美与创作方向。用户可能已经授权 Agent 生成视频，却仍然希望在镜头设计完成后亲自选择方案。因此，把关点需要作为独立的执行状态保存，而不能仅依靠模型在回复中表示"等待确认"。
在开发期演练中，我们就遇到过类似问题：Agent 已经进入需要用户确认的阶段，却只回复一句"请确认是否继续"，没有提供可直接操作的确认卡片，导致用户不得不再次输入"继续"。
为此，我们在运行时增加了兜底机制：当事项停在把关点，而模型没有发起相应提问时，系统会自动补充确认卡；对于用户批准后才执行的生成，如果执行清单仍有待完成步骤，生成结束后也会自动唤醒事项。这样，等待确认与恢复执行不再完全依赖模型的交互行为，而是由运行时根据任务状态协调。
当然，把关并不意味着每一步都需要用户介入。对于不可撤销或超出授权范围的操作，系统始终要求明确确认；而重复性、低风险的步骤，则可以在授权范围内连续推进，避免过多确认打断创作过程。
8.4 自主程度、预算与授权边界
在 AI 创作平台中，Agent 可以调用不同模型厂商提供的文本、图像、视频、音频和 3D 等生成能力，而这些操作往往伴随着实际费用。因此，自主程度与预算控制需要分开设计。
用户允许 Agent 自动执行，不意味着同意无限制地调用付费模型；同样，用户批准了一笔预算，也不代表所有操作都可以跳过审阅。
我们在运行时分别维护三个维度：
| 控制维度 | 解决的问题 | 典型机制 |
|---|---|---|
| 自主程度（Autonomy Level） | Agent 可以连续推进到什么程度 | 每步确认、关键节点确认、授权范围内自动执行 |
| 预算控制（Budget Control） | 当前任务允许消耗多少资源 | 单次额度、计划预算、余额检查、追加预算确认 |
| 目标授权（Execution Scope） | Agent 被允许完成哪些工作 | 已批准的任务书、计划和明确的用户修改 |
例如，用户批准制作三段视频，并允许 Agent 在预算范围内自动完成。
如果执行过程中发现需要额外制作角色参考图，Agent 可以判断这些操作是否属于原有计划和预算。如果需要扩大执行范围或增加费用，则应重新请求用户确认。
这里涉及一个重要的安全边界：模型提出的计划和模型声称的授权，都不能自行成为真实的用户授权。
系统应根据用户在界面中的明确操作，以及服务端保存的授权状态进行判断。
对于不同工具，也需要结合实际副作用采用不同的控制策略。
-
只读查询通常风险较低
-
文档写入需要处理版本和权限
-
付费生成需要检查预算
-
删除素材或撤销记忆等不可逆操作，则应采用更严格的确认机制
相比 Coding Agent，创作平台的 Agent 还存在一个特殊约束：很多外部生成操作一旦提交，费用可能已经产生，即使用户随后停止任务，也未必能够完整撤销。因此，预算和授权检查需要发生在真正产生副作用之前，并与前面介绍的持久化执行机制结合。
从目前的实践来看，自主执行的难点同样在于判断何时应该停止。遇到余额不足、用户暂停、外部任务等待、必要的人工审阅，或连续执行没有取得有效进展时，运行时都需要保留当前状态，等待满足条件后再恢复。
这也意味着，自主程度并非越高越好。不同创作任务的风险、成本和可验证性存在明显差异，Agent 应当在用户授权的范围内尽可能减少不必要的干预，同时在关键节点保留用户的控制权。
更长期来看，我们也希望通过多模态质量评估，让系统能够更准确地判断角色一致性、镜头连贯性和视觉效果。随着自动验收能力逐步完善，部分原本需要人工确认的环节，也有机会交给 Agent 自主完成。
当然，持续协作还涉及任务执行之外的另一个问题：用户可能不通过对话，而是直接在工作区中修改作品。当 Agent 和用户同时编辑同一份文档或工作流时，系统又该如何维护状态一致性？
这需要共享工作区在任务执行之外，维护人和 Agent 对作品的共同访问与修改。
9. Shared Workspace：让用户与 Agent 修改同一份作品
前面讨论的机制，主要解决了 Agent 如何理解任务、维护上下文并持续推进工作。但在实际创作过程中，用户与 Agent 的协作并不只发生在聊天窗口里。
例如，Agent 正在根据分镜生成视频，用户可能直接在右侧工作区调整某个镜头的提示词，替换参考素材，或者修改 Flows 工作流中的模型节点。
这些操作没有经过对话，却实实在在地改变了作品。如果 Agent 仍然依据此前的上下文继续执行，就可能使用过期参数，甚至覆盖用户刚刚完成的修改。
因此，我们在 Lomo Agent 中将创作产物作为独立于对话和任务上下文的持久对象，通过 Shared Workspace（共享工作区） 组织人和 Agent 的协作。
9.1 让作品拥有独立的生命周期
在传统的对话式 Agent 中，生成结果往往附着在某条聊天消息上。用户可以查看、下载或继续追问，但随着对话增长，作品的管理和后续修改会逐渐受到会话结构的限制。
Lomo 的创作流程则包含大量需要长期维护的对象，例如图像、视频、3D 资产、分镜文档、素材集，以及 Flows 可视化工作流。
这些对象需要有稳定的身份、版本和访问权限，能够被用户直接编辑，也能够在不同事项之间引用。
因此，我们将对话上下文与创作产物分别管理：
-
对话与任务上下文负责维护用户意图、执行过程和 Agent 当前掌握的信息。
-
共享工作区负责保存真正需要持续编辑和交付的作品，包括对象身份、内容、版本和相关引用。
例如，用户最初在 Main 中讨论品牌短片的分镜，后续由视频制作事项继续推进。两个执行空间可以在权限允许的范围内引用同一份分镜文档，而无须各自创建副本。
同样，某个视频生成事项结束后，其产物仍然可以被新的工作流引用，不依赖原来的 Worker 是否继续运行。
这种设计让作品能够跨越单轮对话和单个事项的生命周期，也为后续的素材复用与多任务协作提供了基础。
9.2 让 Agent 感知工作区中的变化
共享对象解决了作品如何保存的问题，但还需要解决另一个问题：Agent 如何知道作品已经被修改？
假设 Agent 读取了一份分镜文档，准备根据其中的镜头描述继续生成。就在此时，用户直接在工作区修改了第二个镜头的内容。
如果系统只记录聊天消息，Agent 的下一轮推理就无法知道这次修改。
因此，我们为共享对象维护版本信息，并记录相关事项上一次读取或修改该对象时所看到的版本。
当文档、素材或工作流发生变化时，系统可以向关联事项留下持久化的变更提示。例如：
分镜文档已从 v3 更新到 v4，第二个镜头的描述发生变化。继续执行前请读取最新版本。
这里我们没有选择让每一次工作区编辑都立即触发 Agent 推理。
原因很简单：用户调整工作流时，可能连续拖动节点、修改参数或替换素材。如果每次变化都唤醒 Worker，不仅会产生大量无意义的模型调用，还可能让 Agent 在用户尚未完成编辑时反复介入。
因此，变更提示主要用于让 Agent 在下一次执行时发现自己的信息已经过期。只有当相关任务确实需要继续推进，运行时才会根据当前状态决定是否恢复执行。
对于 Flows 这样的可视化工作流，Agent 也无须在每轮推理中读取完整的节点数据。系统可以先提供简要的变化信息，等模型确实需要处理相关节点时，再按需获取最新内容。
这种处理方式与前面介绍的上下文工程也形成了联系：工作区保存完整的作品状态，上下文只提供当前决策需要的信息。
9.3 版本冲突与乐观并发控制
能够感知变化，还不足以保证并发修改的安全性。
考虑一个更具体的场景：
Agent 读取了分镜文档 v3，准备调整第三个镜头。与此同时，用户直接编辑了同一份文档，并保存为 v4。
如果 Agent 随后直接提交基于 v3 生成的修改，就可能覆盖用户在 v4 中刚刚完成的内容。
为此，我们采用 Optimistic Concurrency Control（乐观并发控制）。
Agent 在读取对象时获得当前版本，提交修改时需要携带所依据的版本信息。服务端在写入前检查对象是否仍处于预期版本。
如果版本一致，修改可以正常提交；如果对象已经更新，系统则拒绝可能覆盖新内容的操作，并要求 Agent 重新读取最新状态。
不过，不同类型的创作对象，对版本冲突的判断粒度并不相同。
对于文档，整篇重写需要携带所依据的版本。如果用户已经修改过文档，系统会拒绝覆盖；局部修改则通过精确且唯一的文本片段定位，只有所有预期替换都成立时才提交。
对于 Flows 工作流，我们采用了更细粒度的冲突检查。用户可能正在调整某个镜头节点，而 Agent 同时修改另一个节点。如果只要工作流发生变化就拒绝提交，频繁的自动保存会让双方很难并行编辑。因此，系统主要检查 Agent 准备修改的节点是否发生变化：如果同一节点已被用户修改，就要求 Agent 重新读取；如果变化发生在其他节点，则允许在最新工作流上应用不冲突的修改，并向 Agent 提示相关变化。
这并不是自动合并双方对同一内容的不同修改，而是通过适当的版本粒度，让互不冲突的编辑尽可能独立完成，同时避免旧状态覆盖新内容。
图 10：共享作品的版本控制。
这里还有两个相互配合的机制：变更通知让 Agent 及时感知作品更新，版本校验则在提交时提供最终保护。即使通知出现延迟，Agent 也不能直接使用过期状态覆盖用户的修改。
当然，乐观并发控制解决的是状态一致性，而不是创作意图的冲突。例如，用户希望镜头采用冷色调，Agent 却仍然按照原计划使用暖色调。即使没有发生版本冲突，最终采用哪种方案仍然需要结合最新的用户意图和任务约束判断。
9.4 从 Artifacts 和 Canvas 到共享创作空间
在交互设计上，我们参考了 Claude Artifacts 和 ChatGPT Canvas 等产品的思路。
这些产品让生成内容从普通聊天消息中独立出来，用户可以在对话旁边直接查看和编辑文档或代码，减少反复通过自然语言描述修改细节的成本。
这种交互方式对 Lomo Agent 很有参考价值。创作者很多时候更希望直接拖动一个节点、修改一段分镜或者替换一张图片，而不是把所有操作重新描述给 Agent。
不过，Lomo Agent 的共享工作区还需要处理不同于普通文档编辑的场景。
一方面，创作对象的类型更加复杂，除了文本，还包括图像、视频、3D 资产和具有节点依赖关系的 Flows 工作流。另一方面，同一份作品可能被多个事项引用，同时存在异步生成任务和用户直接修改。系统需要维护的不只是作品内容，还包括版本、关联任务以及执行过程中对作品状态的认知。
因此，我们将可编辑工作区与 Agent 的执行状态连接起来，让用户能够直接操作作品，也让 Worker 在后续执行时重新获取有效的对象状态。
从目前的实践来看，共享工作区带来的一个重要变化，是用户可以通过自然语言和直接编辑两种方式参与同一个创作过程。但这也让系统承担了更多状态同步和并发控制的责任。尤其当一份素材同时影响多个事项时，如何管理对象依赖关系，以及上游修改后哪些下游产物需要重新生成，仍然是我们继续探索的方向。
10. 创作能力编排：从模型调用到完整作品交付
对于 Lomote AI 这样的创作平台，Agent 面对的不仅是如何选择和调用工具，还需要理解不同创作能力之间的关系。
生成一张图片相对简单，但制作一支完整的短片，可能涉及剧本、分镜、角色设定、场景参考、镜头生成以及后期处理等多个环节。每个阶段都可能使用不同的模型，前一个阶段的结果又会直接影响后续制作。更重要的是，单个生成任务成功，并不代表整个创作流程能够顺利完成。
例如，Agent 规划了一套制作方案：先生成角色与背景，再将人物抠出，最后合成到指定的视频画面中。如果平台当前不具备对应的抠像或视频合成能力，即使前面的素材生成得很好，整个方案仍然无法形成最终作品。
因此，我们需要让 Agent 在规划阶段就理解平台实际具备的能力，以及不同工具和产物之间的依赖关系。
10.1 让 Agent 理解创作流程与能力边界
Lomote AI 已经集成了多种图像、视频和 3D 生成与增强模型，同时提供素材管理和 Flows 可视化工作流。
这些工具各有适用场景，不同模型在输入条件、生成质量、成本和输出形式上也存在差异。
对于 Agent 来说，选择工具需要综合考虑当前创作目标、已有素材和后续制作要求。
例如，在制作一支包含固定角色的短片时，Agent 需要考虑如何建立角色参考、哪些模型支持参考图输入、不同镜头如何维持视觉一致性，以及生成结果能否进入后续制作流程。如果只根据用户的最终目标直接调用模型，很容易产生大量看起来不错、却无法用于最终作品的中间素材。
为此，我们将创作经验和工具能力约束整理成可按需读取的指引，包括角色一致性、分镜规划、参考素材使用、工作流编排，以及平台当前支持的制作能力。这些指引会在相关任务中提供给 Agent，帮助它规划可执行的创作步骤，而不必将所有领域知识长期放入系统 Prompt。
这部分设计也与前面介绍的 Context Engineering 相互配合：Agent 根据当前制作阶段获取需要的工具与创作知识，再结合实际能力完成规划和执行。
当然，依靠模型理解工具说明仍然存在局限。模型可能提出看似合理、实际却无法完成的制作方案。因此，对关键工具能力、输入输出约束和执行条件，仍然需要由系统提供明确的校验依据。
10.2 从 ViMax 看多智能体视频制作
在探索创作能力编排时，我也关注了 ViMax 等面向视频生成的多智能体系统。
ViMax 将剧本、角色、分镜、镜头生成和视频组装组织在一套制作流程中，通过不同角色或执行阶段的协作，处理视频创作中相互关联的任务。
这种思路很有参考价值。视频制作天然具有阶段性，不同环节需要关注的问题也不同。剧本规划更侧重叙事结构，角色设计需要关注视觉一致性，而镜头生成则要考虑具体模型的输入条件和生成效果。
通过专业化的执行分工，可以让不同阶段围绕相对明确的职责工作，也有利于组织复杂的制作流程。
不过，这类架构同样存在需要权衡的地方。一方面，多 Agent 协作会增加上下文传递、状态同步和协调成本；另一方面，预先定义的制作流水线未必能够覆盖用户不断变化的创作需求。
Lomo Agent 面对的场景更加开放。用户可能只需要制作一张海报，也可能希望基于已有素材生成视频，或者直接要求 Agent 修改某个 Flows 工作流。如果为所有创作需求都引入固定的多 Agent 流水线，反而可能增加不必要的执行层级。
因此，现阶段我们更倾向于通过统一的任务执行体系，结合按需加载的创作指引和工具能力，让 Worker 根据具体目标组织制作步骤。对于需要长期维护的复杂创作任务，再逐步探索更明确的专业化分工与任务依赖管理。这里的取舍也与前面 Main / Task 的设计保持一致：只有当独立执行空间能够带来实际收益时，才值得增加额外的协调层级。
10.3 制作依赖图：从线性执行走向依赖管理
目前，结构化执行清单已经能够帮助 Agent 维护创作进度，但当任务涉及大量相互关联的素材和生成步骤时，线性的清单结构仍有一定局限。
例如，一支短片包含多个镜头，它们可能共享相同的角色设定，却使用不同的场景和生成模型。
部分镜头可以独立生成，部分镜头必须等待上游参考素材完成。如果用户中途修改角色形象，相关镜头可能需要重新生成，但不应影响完全无关的场景。
这类关系更适合通过 Production DAG（制作有向无环图） 来表达。
图 11：设想中的制作依赖图。
在这样的结构中，每个节点代表一项制作步骤或中间产物，节点之间的连接则描述其依赖关系。
进一步将这些关系结构化后，系统便有机会实现几个能力：
-
依赖调度：只有当必要的上游素材准备完成后，才执行对应的下游步骤。
-
并行生成：没有直接依赖关系的镜头，可以在资源和预算允许的情况下并行执行。
-
变更传播：当角色或场景设定发生变化时，定位可能受到影响的下游结果，避免无差别地重新生成。
-
增量制作：尽可能复用仍然有效的素材与生成结果，减少重复调用和不必要的制作成本。
不过，依赖图也会带来额外的工程复杂度。尤其是创作任务中的依赖关系未必完全确定，某个上游素材发生变化后，下游结果是否必须重新生成，还需要结合修改范围和具体制作要求判断。
此外，即使依赖关系正确，也无法保证生成结果在视觉上达到预期。角色一致性、镜头连贯性和整体节奏仍然需要独立的质量评估机制。
因此，Production DAG 目前更多是我们正在探索的演进方向。现阶段，我们优先确保 Agent 能够在 Lomote AI 已有的模型与工具能力范围内，完成可执行的创作流程，并控制中间产物的成本与有效性。
随着任务依赖、自动验收和多模态理解能力逐步完善，未来也有机会将这些机制结合起来，让 Agent 从按步骤执行创作任务，进一步走向对完整制作流程的管理。而要判断这些设计是否真正有效，仅靠一次顺畅的演示还远远不够。复杂创作任务中还会出现工具失败、用户修改、状态恢复以及重复生成等情况。
这些设计是否有效，仍需要通过故障恢复与端到端协作演练验证。
11. 工程验证：从故障恢复到端到端协作
Agent 系统有一个很有意思的特点：单个模块运行正常，并不意味着整个协作过程就一定可靠。
例如，消息正确路由到了对应事项，工具调用也成功返回，但 Agent 可能在生成完成后忘记继续执行；又或者每一步都符合预期，最终却产生了多份重复文档，让用户不知道哪一份才是最新版本。
这类问题很难通过传统的单元测试或几轮简单对话发现。
因此，在 Lomo Agent 的开发过程中，除了验证各个模块的正确性，也尝试让 Agent 在接近真实的使用场景中走完完整流程，观察各项机制组合之后的实际表现。
11.1 运行时的可靠性验证
对于持久化执行、消息收件箱、异步生成和用户授权等机制，很多问题只会出现在特定的状态转换过程中。
例如：
-
视频生成请求已经提交，但 Worker 在保存结果前重启
-
旧 Worker 失联后被新进程接管，随后又恢复执行
-
用户点击停止时，恰好有一条生成完成事件到达
这些情况在正常演示中很少出现，却可能直接影响执行状态、用户作品甚至实际费用。因此，我们在开发阶段通过故障注入测试，重点验证系统在这些异常情况下的处理能力。
具体测试覆盖了以下关键执行边界：
| 验证场景 | 重点关注 |
|---|---|
| 执行中断与恢复 | 能否从已持久化的状态恢复，避免重复执行 |
| 重复投递与网络超时 | 是否正确处理幂等请求及结果未知的情况 |
| Worker 并发接管 | 旧执行者能否被阻止写入过期状态 |
| 取消与异步事件竞争 | 已停止的任务是否可能被迟到事件重新唤醒 |
| 预算与授权变化 | 恢复执行时是否重新检查当前权限 |
| 共享对象并发修改 | 是否可能用旧版本覆盖用户的新修改 |
| 记忆纠正与撤销 | 失效信息是否仍会通过摘要或画像被使用 |
对于能够稳定复现的模型输出，我们可以使用固定结果进行回放，重点验证运行时的状态转换。外部生成服务则可以模拟超时、重复回调和乱序事件，避免每次都依赖真实的付费模型。这部分测试的重点是系统行为的确定性。即使模型本身具有一定的随机性，任务状态、执行权限和计费约束也应当有明确且可验证的规则。
一个比较有代表性的测试，是模拟 Worker 在工具执行过程中突然"卡死"。测试中，模型使用固定输出，先决定调用一个查询工具；第一个 Worker 已经保存模型决策，并将工具调用记录为 started，随后被人为挂起。等它的租约过期后，第二个 Worker 接管，执行代次提升到 2，并从 checkpoint 继续：由于这一步的模型决策已经保存，它不需要重新推理，而是用相同的幂等键完成工具调用。最后恢复第一个 Worker，让它尝试提交迟到的结果。
测试结果符合预期：轮次最终进入 completed，执行代次为 2；模型只调用了一次，工具结果也只有一条，旧 Worker 的状态写入被拒绝。我们还通过集成测试覆盖了队列消息丢失后的重新投递、批准后生成任务的幂等恢复、已取消轮次阻止新事项创建、费用授权限制和记忆撤销等情况。
11.2 端到端协作演练
运行时测试可以验证系统是否正确处理异常状态，却无法完整反映 Agent 的实际协作体验。
例如，Agent 成功完成了分镜规划，却在下一阶段直接停止，直到用户再次输入"继续"才开始生成视频。从程序执行角度看，这可能不算故障，但对于用户来说，整个过程显然不够自然。
为此，我尝试引入了场景演练的方式。
在隔离环境中，使用真实文本模型，配合模拟生成服务和预设行为的模拟用户，让 Agent 完成一段相对完整的创作流程。
演练场景涵盖系列海报、短片制作、Flows 工作流修改、3D 创作、多事项切换、历史任务恢复，以及记忆纠正与遗忘等情况。这些场景既涉及连续的模型与工具调用，也包含用户确认、异步等待和跨事项上下文关联。
例如，在短片制作场景中，模拟用户首先提出创作目标，Agent 需要组织分镜、准备素材并提交生成请求。在执行过程中，用户可能调整方案、选择镜头，或者临时插入另一项任务。我们希望观察的不只是某一步能否成功，而是 Agent 能否在这些变化之后，仍然围绕原有目标持续推进。
我会重点观察：
-
Agent 是否在正确的节点暂停或继续
-
用户是否需要反复发送"继续"才能推进任务
-
是否出现不必要的确认或重复生成
-
新消息能否正确关联到已有事项
-
用户修改作品后，Agent 是否能够获取最新状态
-
同一份作品是否被意外拆分成多个副本
-
记忆纠正或撤销后，旧信息是否仍然影响后续协作
相比直接调用真实的媒体生成服务，模拟环境能够控制测试成本，也更容易重复构造特定场景，观察跨模块交互中可能出现的问题。
不过，这种方式也有明确的局限。模拟生成结果无法验证真实作品的视觉质量，预设策略的模拟用户也无法完全反映真实创作中的复杂行为。因此，这些演练主要用于检查任务组织、执行状态与协作流程的连续性，不能直接代表真实用户任务的成功率。最终作品的质量和实际使用体验，仍然需要结合真实生成结果与用户反馈进一步评估。
11.3 如何衡量一次协作的质量
在这些演练中，我逐渐意识到，仅凭模型回答是否流畅、工具调用是否成功，很难完整衡量一个长期运行的 Agent。
用户更在意的可能是另外一些问题：
-
我需要重复解释多少次？
-
Agent 有没有记住已经确定的要求？
-
能否在几天后自然接着之前的工作？
-
当我修改作品时，它是否知道发生了什么？
因此，除了传统的执行正确性，我也开始关注任务连续性、用户介入成本、重复操作以及产物一致性等维度。
实际演练也暴露了一些单独测试模块时不容易发现的问题。
例如，在英文系列海报的创作过程中，Main 能够正确理解用户需求并创建事项，但 Worker 在后续规划中却切换成了中文。问题并不在于任务路由，而是事项只接收了主线整理后的目标描述，缺少用户原始表达中的语言信息。后来，我们调整了用户语言的传递方式，让事项能够根据用户实际输入维护回复语言，而不再完全依赖模型从任务描述中推断。
另一个问题出现在人工把关与异步生成的衔接处。Agent 已经推进到需要用户确认的阶段，却没有提供可操作的确认卡；或者用户批准生成后，外部任务虽然正常完成，事项却没有继续推进。针对这些情况，我们在运行时增加了确认卡兜底和生成完成后的自动唤醒机制，减少对模型交互行为的依赖。
这些问题单独来看，都不一定表现为明显的执行故障，却会直接影响用户感受到的协作连续性。它们也让我更加明确：模型负责理解意图与规划步骤，而等待、授权和恢复执行等关键状态，需要由运行时提供确定性的保障。
当然，这些维度并不能单独代表 Agent 的智能水平。对于创作平台，流程完成与作品质量仍然需要分别评估。Agent 可以按照计划生成全部镜头，却未必能保证最终视频在视觉风格、角色一致性和叙事节奏上达到用户预期。更可靠的多模态验收，仍是我们希望继续完善的能力。
从目前的实践来看，端到端演练为我们提供了一种相对可控的验证方式。它不仅帮助我们发现跨模块协作中的问题，也让架构设计中的一些原则真正经受了完整执行流程的检验。相比单纯增加模型能力，如何让这些能力在长期协作中稳定衔接，同样值得持续投入。
12. 尚未解决的问题与后续探索
Lomo Agent 目前已经具备了多事项组织、持久化执行、上下文管理和共享工作区等基础能力，但距离我理想中的创作智能体，还有不少值得继续探索的问题。
首先是跨事项协作。
当前 Router / Worker 的结构能够让多个事项独立推进，并在需要时访问共享产物。但如果进一步允许 Worker 之间主动求助、委派任务，甚至协商共享预算，就需要解决更复杂的权限、状态同步和并发一致性问题。
多 Agent 协作看起来很有吸引力，但更多的 Agent 并不天然意味着更高的效率。额外的协调开销和上下文传递也可能抵消专业化分工带来的收益。我希望先从实际需求中找到值得拆分的工作，再逐步扩大协作范围。
其次是创作流程的依赖管理。
前面提到的 Production DAG 是我比较关注的方向。对于包含多个镜头、角色和场景的复杂制作任务，显式的依赖关系有助于支持并行执行、增量更新和结果复用。
不过，创作任务中的依赖并不总是确定的。用户修改了一个角色设定，哪些镜头必须重新生成，哪些仍然可以沿用，往往还需要结合实际内容进行判断。
异步生成的可靠性也还有进一步完善的空间。
目前，对于已经提交到上游的生成任务，系统还无法主动取消；如果任务已经创建，却在保存上游任务 ID 之前发生故障，也缺少反向查询和恢复关联的能力。
这些情况已经有相应的状态处理与费用兜底机制，但仍可能产生不必要的生成成本。后续希望逐步接入上游服务的取消与任务查询能力，让系统能够更准确地处理执行中断和用户临时修改需求的情况。
多模态质量验收同样是一个难题。
目前，工具返回成功、清单步骤完成，只能证明系统完成了相应操作。真正的作品质量还涉及视觉一致性、运动连贯性、音画同步以及用户主观审美等因素。
随着多模态模型的发展，我希望逐步将这些评估能力引入执行流程，让 Agent 能够更准确地判断何时需要调整、何时值得重新生成，以及何时应该把决定权交还给用户。
另外，长期记忆的准确性、任务路由的可靠性与主动跟进的边界也需要持续验证。
来源追踪与版本管理能够提高记忆的可控性，但无法彻底避免模型抽取错误或历史信息误召回。同样，虽然目前的路由机制已经结合事项索引、历史检索和相似任务查重来减少误判，但对于长期积累的大量事项，仍然需要通过真实使用数据进一步衡量任务关联的准确性，以及用户需要主动纠正的频率。
对于主动跟进，系统可能知道某个任务还有后续工作，却未必知道用户此刻是否希望被打扰。我们希望未来的 Agent 能够更加主动，但这种主动性需要建立在用户授权、任务价值和实际使用习惯之上。
这些问题短期内未必都有成熟的解法。随着 Lomo Agent 逐渐进入更多真实的创作场景，我们也会不断重新审视现有架构，验证哪些设计确实有效，哪些需要调整。
结语
回头看 Lomo Agent 从最初构思到上线的过程，我越来越觉得，Agent 的发展正在让软件架构面对一些很有意思的新问题。
过去，我们设计软件时，通常需要先定义清晰的功能、流程和交互边界，再让用户按照这些规则完成操作。而当 AI 开始具备理解意图、调用工具和自主决策的能力，很多原本由用户承担的组织与协调工作，也有机会逐渐交给系统。
但模型能力的提升只是其中一部分。
一个能够长期协作的 Agent，还需要知道自己正在完成什么、已经做过什么、哪些信息仍然有效，以及在什么情况下应该继续或停止。它需要处理现实系统中的中断、并发、费用和权限，也需要允许用户随时改变主意。
这次 Lomo Agent 的架构设计，正是围绕这些问题展开的一次实践。其中不少思路来自 DeepSeek、Manus、Claude Code、Temporal 等优秀产品和工程实践，也有一些是在我自己的创作场景中逐渐摸索出来的。
目前的实现还是早期探索阶段，距离理想形态还有很长一段路，很多设计也需要继续接受真实使用者的检验。
不过，我始终觉得，随着模型能力不断向前发展，未来软件与人的交互方式仍然有很大的想象空间。
也许有一天，我们不再需要学习如何使用一个软件，而只需要告诉它，我们想完成什么。
这也是我们希望 Lomo Agent 能够不断接近的方向。
如果你也正在构建 Agent，欢迎交流架构设计与工程实践中的经验和问题；
如果你是创作者，也欢迎带着真实的创作需求体验 Lomo Agent。
体验 Lomo Agent： Lomote AI
参考资料与延伸阅读
以下链接主要用于说明架构启发与研究背景，不代表各项目在所有能力上与 Lomo Agent 具有相同的实现或设计目标。
-
Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
-
LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory
注：文中"已有机制"与"演进方向"尽可能分别标明。对于外部服务的幂等保证、遗忘所覆盖的数据范围、模型缓存行为及自动验收效果，实际能力均受具体实现与依赖条件约束。