Lomo Agent：面向創作型、持續協作 Agent 的架構設計與工程實踐

製作一支產品短片，往往要經歷需求溝通、參考素材整理、分鏡、畫面生成、影片生成和反覆修改。其中有些工作幾秒鐘就能完成，有些需要等待幾分鐘；有些適合交給模型決定，有些必須由使用者確認。做完第一版以後，工作還遠遠沒有結束。

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 中把互動入口、執行上下文和長期記憶分成了三個相對獨立的層次：

使用者只需要在統一入口中自然地表達意圖，系統負責識別任務歸屬，並為需要持續推進的工作建立獨立事項。每個事項擁有自己的上下文、執行狀態和產物引用，必要時可以透過受控的檢索與共享機制取得其他事項的資訊。

在這項設計上，我們也參考了現有產品的不同實踐。

例如，ChatGPT 透過跨對話記憶增強了不同對話之間的資訊連續性；Claude 則透過 Projects 等機制，讓使用者能圍繞特定專案組織知識與上下文。這些設計各有優勢：明確的對話和專案邊界便於理解、管理和分享，也讓使用者對上下文範圍擁有更直接的控制權。

但對需要長期、頻繁切換任務的創作場景來說，使用者仍然需要承擔一部分上下文組織工作。跨對話記憶可以幫助 Agent 了解使用者的偏好和歷史，卻無法完整表達一個正在執行的任務及其進度。

因此，Lomo Agent 選擇把更多任務組織工作交給系統，讓使用者盡可能擺脫日常的對話管理。當然，自動識別也意味著可能出現任務歸屬錯誤。為此，我們保留了明確的事項入口和糾錯機制，並在目標明確時優先採用確定性路由，減少不必要的模型判斷。

flowchart TD
    U["使用者"] --> E["統一互動入口"]
    E --> R["任務識別與路由"]
    R --> A["事項 A：品牌海報"]
    R --> B["事項 B：影片製作"]
    R --> C["簡單請求：主線直接處理"]
    A <--> M["長期記憶"]
    B <--> M
    C <--> M
    A --> S["共享素材與產物"]
    B --> S

圖 1：Lomo Agent 的任務組織模型

2. 系統總覽：協調層、執行層與共享工作區

確定任務組織方式後，下一步就是思考如何讓這些事項真正運轉起來。

一個能夠持續協作的 Agent，需要同時處理使用者的新請求、推進既有任務、等待外部生成結果，以及回應使用者對作品的修改。如果這些工作全部交給同一個 Agent 處理，上下文會迅速膨脹，任務之間也容易相互干擾；如果每個請求都建立獨立的 Agent，又會帶來額外的協調成本。

基於這樣的考量，我為 Lomo Agent 設計了 Main / Task 雙層結構，並在執行層引入持久化執行環境（runtime），讓不同任務能夠獨立推進，同時透過共享工作區存取和修改創作產物。

2.1 整體架構

整個系統可以分為四個主要部分：

• Main（主線）：使用者持續互動的入口，負責理解新請求、關聯既有任務、處理簡單問題，以及協調不同事項的執行和回饋。

• Task（事項）：承載具體創作目標的獨立執行空間。每個事項維護自己的任務書、上下文、執行計畫、訊息收件匣和執行狀態。

• Agent Runtime（執行環境）：管理模型推理、工具呼叫、非同步等待、狀態持久化和執行恢復，並在每一步檢查預算、權限與停止條件。

• Shared Workspace（共享工作區）：保存圖像、影片、3D、文件、素材集與 Flows 工作流程等創作產物，允許使用者和不同事項在權限範圍內共同存取與修改。

在角色劃分上，Main 主要承擔 Router 的職責，Task 內部則由 Worker 推進具體任務。Router 和 Worker 是邏輯上的執行角色，並不要求使用不同的基礎模型。

flowchart TB
    U["使用者：自然語言 / 卡片操作 / 工作區編輯"] --> UI["統一協作介面"]
    UI --> GW["接入層：站內介面 / 開放 API / 即時事件"]
    GW --> CMD["指令與訊息接入"]

    subgraph CORE["Agent Core"]
      ROUTER["Main / Router：理解與協調"]
      ROUTING["目標歸屬與確定性路由"]
      W1["Task A / Worker：系列海報"]
      W2["Task B / Worker：短影片"]
      CTX["上下文編排 / 壓縮 / 按需工具"]
      RT["持久化執行引擎"]
      GUARD["授權 / 預算 / 自主程度"]
    end

    CMD --> ROUTING
    ROUTING --> ROUTER
    ROUTING --> W1
    ROUTING --> W2
    ROUTER --> RT
    W1 --> RT
    W2 --> RT
    RT --> CTX
    RT --> GUARD
    RT --> TOOLS["創作工具：圖像 / 影片 / 音訊 / 3D / 畫布 / 素材"]
    RT <--> DB[("持久化資料庫：執行事實與狀態")]
    RT <--> M["長期記憶：畫像 / 事實 / 情境摘要"]
    TOOLS --> ASSET["共享產物與工作區"]
    ASSET --> UI
    DB --> EVENTS["佇列 / 事件發布 / 即時推送"]
    EVENTS --> UI

圖 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 則結合事項索引和歷史資訊，將這則新指令關聯到原來的海報事項。

sequenceDiagram
    participant U as 使用者
    participant R as Main / Router
    participant A as Task A：海報
    participant B as Task B：影片
    U->>R: 做一套品牌系列海報
    R->>A: 建立事項與任務書
    R-->>U: 在主線展示事項卡片
    U->>R: 順便把昨天的貓做成影片
    R->>B: 建立另一個事項
    Note over A,B: 獨立上下文，並行推進
    A-->>U: 海報方案待確認
    U->>A: 在卡片上選擇方案 B
    B-->>U: 影片生成完畢
    U->>R: 上次那套海報再暖一點
    R->>A: 將追問轉回既有事項

圖 3：Main / Task 多事項協作時序圖

這裡有一個值得注意的設計細節：訊息的歸屬和訊息的執行是兩個不同的階段。

Router 可以把訊息分配給對應事項，但 Worker 未必會立即處理。例如，它可能正在等待影片生成，也可能暫停在使用者確認節點。新訊息需要先進入持久化收件匣，再由執行環境根據目前狀態安排消費。

這也意味著任務組織只是第一步。隨著事項數量增加，如何準確識別使用者的後續意圖、避免誤路由，以及處理執行過程中插入的新訊息，會成為整個架構的重要問題。

3. 訊息路由：讓每則訊息找到正確的執行單元

統一互動入口讓使用者能夠自然地切換任務，但也把一項原本由使用者完成的工作交給了系統：判斷每則新訊息應該交給誰處理。

例如，使用者剛生成了一張圖片，又突然說：「把剛才那個換成藍色。」

這裡的「那個」可能指向最新生成的圖片，也可能是之前某個海報事項中的素材。

如果歸屬判斷出現偏差，輕則建立重複事項，重則讓 Agent 修改錯誤的作品。

因此，訊息路由的準確性會直接影響整個系統的可靠性。我們不希望所有訊息都依賴模型重新猜測歸屬，而是採用了一個相對簡單的原則：能透過明確關係確定的，直接由程式處理；只有缺少明確歸屬時，才交給模型進行語意判斷。

3.1 確定性路由與語意路由

Lomo Agent 的訊息接入大致分為三個階段。

第一層：明確目標的直接路由。

當使用者在某個事項面板中回覆、點擊事項卡片上的操作按鈕，或針對明確綁定的作品發起修改時，系統已經知道訊息屬於哪個目標，可以直接根據 Task ID 或物件關聯關係投遞。

這種情況下，再呼叫模型判斷一次歸屬，反而會增加延遲和誤判風險。

第二層：Router 進行語意判斷。

對於從主線發送、沒有明確目標歸屬的訊息，Router 需要結合目前請求、近期互動和既有事項索引進行判斷。

可能的結果包括：

• 由 Main 直接處理的簡單請求。

• 只需要一次生成的輕量事項。

• 可以關聯到某個既有事項的後續指令。

• 需要建立正式事項的新目標。

• 歸屬存在明顯歧義，需要使用者進一步確認。

這裡還有一個容易忽略的問題：Router 並不需要讀取所有事項的完整歷史。通常只需要提供事項的目標、摘要、最近狀態及相關物件引用，在識別出候選目標後，再按需讀取具體資訊。

這樣可以避免隨著任務數量增加，路由本身逐漸演變成另一個不斷膨脹的上下文。

我們目前會優先提供最近活躍的一些事項，包括目標、摘要和狀態等索引資訊；如果使用者提起更早的工作，再透過關鍵字與摘要向量相似度進行檢索，將少量相關候選交給 Router 判斷。如此一來，事項數量增加主要影響的是檢索範圍，而不是每次推理必須攜帶的上下文長度。

還有一種容易發生的錯誤，是把使用者原本想繼續的工作當成新目標。為此，在建立正式事項前，系統還會與最近 50 個進行中的事項做一次相似度檢查。如果發現可能重複的目標，就把最相似的幾個候選交給模型，讓它判斷應該沿用既有事項還是確認新建。這樣的檢查可以攔下一部分重複建立，但無法取代所有語意歧義的澄清。對於證據不足的情況，仍然需要讓使用者明確選擇。

第三層：執行前的歸屬與狀態檢查。

確定訊息目標後，系統仍需要檢查事項是否有效、是否允許接收目前操作，以及相關物件是否仍處於可存取狀態。

例如，使用者可能引用了一個已經封存的事項，或者試圖修改已經刪除的素材。Router 給出正確的語意歸屬，並不代表後續操作一定能夠執行。

flowchart TD
    M["收到使用者訊息或互動事件"] --> A{"是否帶有明確的事項身分？"}
    A -->|是| V["檢查既有目標與存取權限"]
    A -->|否| B{"是否存在明確的物件關聯？"}
    B -->|是| V
    B -->|否| R["Router 語意判斷"]

    R --> Q["簡單請求：Main 直接處理"]
    R --> L["單步生成：建立輕量事項"]
    R --> E["既有目標：關聯既有事項"]
    R --> N["獨立目標：準備建立正式事項"]
    R --> C["存在歧義：請求使用者確認"]
    N --> S{"是否命中進行中事項查重？"}
    S -->|是| H["提供相似候選，由模型判斷"]
    H -->|關聯既有事項| E
    H -->|確認新建| CREATE["建立正式事項"]
    S -->|否| CREATE
    CREATE --> NV["驗證新事項和操作權限"]
    L --> NV
    NV --> I["建立執行狀態並投遞輸入"]

    E --> V
    V --> D{"既有目標狀態是否有效？"}
    D -->|是| T["寫入對應事項 Inbox"]
    D -->|否| F["提示使用者或重新選擇目標"]
    C --> U["使用者回覆後重新判斷"]
    U --> R

圖 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 恢復時就可以根據帳本判斷哪些操作已經完成、哪些可以重試，以及哪些需要先核對外部狀態，無須重新呼叫模型生成同一輪工具決策。

flowchart TD
    S["讀取 Inbox 與目前執行狀態"] --> L["模型推理，生成回覆與工具呼叫意圖"]
    L --> P["原子提交模型結果與待執行呼叫"]
    P --> X{"呼叫是否已有持久化結果？"}
    X -->|是| REUSE["重用既有結果"]
    X -->|否| K{"先前是否可能已經執行？"}
    K -->|否| EXEC["提交工具呼叫"]
    K -->|是| I{"是否支援冪等重試？"}
    I -->|是| EXEC
    I -->|否| UNKNOWN["標記結果未知，交還給模型"]
    EXEC --> SAVE["持久化工具結果與業務狀態"]
    REUSE --> NEXT["繼續下一個呼叫或 Step"]
    SAVE --> NEXT
    UNKNOWN --> CHECK["先查詢目前狀態，再決定是否重試"]
    CHECK --> NEXT

圖 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。

sequenceDiagram
    participant W as Task Worker
    participant G as 生成服務
    participant S as 持久化執行環境
    participant UI as 事項卡片

    W->>G: 提交生成請求（穩定業務識別碼）
    G-->>W: 回傳任務 ID
    W->>S: 保存任務關聯與等待狀態
    Note over W,S: 以上為正常路徑；提交後未能保存的異常見 4.4
    S-->>UI: 更新為生成中

    Note over W: Worker 掛起，釋放執行資源

    G-->>S: 生成進度事件
    S-->>UI: 更新進度（無需模型推理）

    G-->>S: 生成完成事件
    S->>S: 更新任務狀態並保存產物
    S-->>UI: 展示生成結果

    alt 後續步驟依賴生成結果
        S->>W: 投遞恢復執行事件
        W->>W: 讀取最新狀態並繼續執行
    else 目前無需繼續推理
        Note over UI: 只更新結果與事項狀態
    end

圖 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 將模型上下文組織為幾個層次，包括相對穩定的系統前綴、經過壓縮的歷史、近期互動，以及目前執行步驟所需要的動態狀態。

flowchart LR
    A["穩定前綴：系統規則 / 核心工具 / 畫像快照"] --> B["分段歷史摘要"]
    B --> C["近期訊息與關鍵工具結果"]
    C --> D["動態尾部：任務書 / 清單 / 預算 / 物件變化"]
    D --> E["本步輸入與按需召回"]

圖 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 的記憶劃分為幾個層次：

這些層次之間存在一定的關聯，但承擔的職責不同。

原始訊息是可追溯的證據。系統可以從中抽取候選記憶，再根據來源、時間、適用範圍和既有紀錄，判斷是否需要保存、補充或更新。

情境摘要則更關注一段協作中發生了什麼。例如，使用者上週製作了一組品牌海報，最終選擇了暖色系方案，並決定暫緩後續的影片製作。這些資訊未必都值得進入長期畫像，但可能在使用者下次提起專案時發揮作用。

使用者畫像需要更加克制。它應當保留少量相對穩定的資訊，避免隨著使用時間增長，變成另一份不斷膨脹的歷史對話。

在實際召回時，系統再根據目前事項的目標和權限，選擇需要提供給模型的記憶，而不必每輪都載入完整歷史。

這裡還有一條重要原則：記憶必須區分使用者明確表達的事實與模型自己的推測。

例如，Agent 因為使用者連續生成了幾張賽博龐克圖片，就推斷他長期偏好賽博龐克風格。這可以作為候選判斷，卻不能直接等同於使用者明確表達的偏好。

同樣，網頁內容、工具回傳結果和 Agent 自己生成的摘要，也不能在沒有可靠依據的情況下，被重新包裝成使用者的個人事實。

7.2 從現有記憶架構中得到的啟發

在長期記憶的設計上，我們參考了幾種不同的技術路線。

OpenClaw 的記憶實踐強調可檢查、可維護的儲存方式，以及記憶與原始上下文之間的關係。其優勢在於透明度較高，便於使用者或開發者檢查保存了什麼；但當記憶規模持續增長時，檢索、維護和衝突處理仍然需要額外的機制。

Mem0 更關注如何從對話中抽取有價值的資訊，並在後續互動中透過檢索恢復相關記憶。這種方式適合長時間、跨話題的智慧體使用，但記憶品質高度依賴抽取的準確性和召回策略。如果把臨時指令誤判成長期偏好，後續檢索反而可能持續放大錯誤。

Zep / Graphiti 則提供了另一種思路：在記憶中明確維護實體關係和時間資訊。這對處理不斷變化的事實尤其有價值。例如，某個品牌過去使用藍色作為主色，後來改成了綠色，兩筆紀錄並不一定互相矛盾，它們可能分別對應不同的有效時間。

不過，時態關係和知識圖譜也會帶來更高的維護複雜度，包括實體正規化、關係更新、衝突處理和檢索成本。

結合 Lomo Agent 的創作場景，我們更關注三個問題：

1. 使用者偏好是否有可靠來源

2. 歷史事實是否仍然有效

3. 使用者更正或撤銷資訊後，相關記憶能否同步更新

因此，除了常見的分層儲存與語意檢索，我們也為記憶維護來源、版本和衍生關係。

7.3 「忘記」為什麼比「記住」更難

長期記憶還有一個容易被忽略的問題：當使用者明確要求忘記某些內容時，系統應該如何處理？

假設使用者最初說：「我們品牌的主色是藍色。」

後來又補充：「藍色搭配米白，整體會更柔和一些。」

記憶系統可能把兩次表達整合成一條新的品牌偏好：

「該品牌偏好藍色與米白色搭配，整體視覺傾向柔和風格。」

如果使用者隨後要求忘記最初關於藍色的設定，只刪除第一條原子記憶顯然不夠，因為整合後的版本仍然包含相關資訊。

隨著系統持續運作，這條資訊還可能進入情境摘要、使用者畫像，甚至被合併進其他衍生記憶。

因此，我們為記憶維護來源與衍生關係，用來描述一條記憶是由哪些歷史證據和舊版本演變而來。

flowchart TD
    U["使用者指定需要忘記的內容"] --> A["撤銷相關證據的記憶使用資格"]
    A --> B["定位受影響的記憶版本"]
    B --> C["沿衍生關係查找後續版本"]
    C --> D["停用受影響內容，檢查仍有效的證據"]
    D --> E["基於剩餘有效證據重新抽取"]
    E --> F["更新原子記憶、摘要與使用者畫像"]
    F --> G["使相關檢索索引與上下文快取失效"]

圖 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 的完成標準有明顯區別。

在程式開發任務中，測試通過、建置成功或預期檔案完成修改，通常可以提供比較明確的執行證據。創作任務則很難有統一的客觀標準。一段影片成功生成，並不能說明角色一致性、鏡頭節奏和整體視覺效果已經符合使用者預期。

因此，我們把流程進展與作品驗收分開處理。

前者可以依據執行清單、工具呼叫紀錄和產物狀態進行判斷；後者則需要結合多模態理解、具體任務要求以及必要的人工審閱。

執行環境在每輪執行結束後，檢查目前任務是否仍有待推進的步驟、是否存在外部等待、是否需要使用者確認，以及是否已經達到執行限制。

flowchart TD
    E["目前執行輪次結束"] --> A{"執行清單是否完成？"}
    A -->|是| END["結束執行，進入結果展示或驗收"]
    A -->|否| B{"任務是否暫停、受阻或超出限制？"}
    B -->|是| STOP["停止自動推進並記錄原因"]
    B -->|否| C{"是否正在等待外部事件？"}
    C -->|是| WAIT["掛起，等待對應事件"]
    C -->|否| D{"是否到達人工把關點？"}
    D -->|是| GATE["展示確認或選擇卡片"]
    D -->|否| F{"是否存在實質進展？"}
    F -->|否| LIMIT["停止自動續跑，避免空轉"]
    F -->|是| NEXT["排程下一輪 Worker 執行"]
    NEXT --> E

圖 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 自動執行，不代表同意無限制地呼叫付費模型；同樣，使用者批准了一筆預算，也不代表所有操作都可以跳過審閱。

我們在執行環境中分別維護三個維度：

例如，使用者批准製作三段影片，並允許 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 提示相關變化。

這並不是自動合併雙方對同一內容的不同修改，而是透過適當的版本粒度，讓互不衝突的編輯盡可能獨立完成，同時避免舊狀態覆寫新內容。

sequenceDiagram
    participant A as Agent
    participant O as 共享作品
    participant U as 使用者

    A->>O: 讀取分鏡文件 v3
    U->>O: 修改分鏡並儲存為 v4
    O-->>A: 記錄版本變更提示
    Note over O,A: 變更提示等待下一次執行時讀取

    A->>O: 基於 v3 提交修改
    O-->>A: 版本衝突，拒絕覆寫
    A->>O: 重新讀取 v4
    A->>A: 根據最新內容調整修改方案
    A->>O: 基於 v4 重新提交

圖 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（製作有向無環圖） 來表達。

flowchart LR
    BR["創作需求"] --> SCRIPT["劇本 / 分鏡"]

    SCRIPT --> CHAR["角色設定"]
    SCRIPT --> SCENE["場景設定"]

    CHAR --> SHOT1["鏡頭 1"]
    CHAR --> SHOT2["鏡頭 2"]

    SCENE --> SHOT1
    SCENE --> SHOT2

    SHOT1 --> REVIEW["驗收與組合"]
    SHOT2 --> REVIEW

    REVIEW --> FINAL["最終交付"]

圖 11：構想中的製作依賴圖。

在這樣的結構中，每個節點代表一項製作步驟或中間產物，節點之間的連線則描述其依賴關係。

進一步把這些關係結構化之後，系統便有機會實現以下幾項能力：

• 依賴排程：只有當必要的上游素材準備完成後，才執行對應的下游步驟。

• 並行生成：沒有直接依賴關係的鏡頭，可以在資源和預算允許的情況下並行執行。

• 變更傳播：當角色或場景設定發生變化時，定位可能受到影響的下游結果，避免不加區分地重新生成。

• 增量製作：盡可能重用仍然有效的素材與生成結果，減少重複呼叫和不必要的製作成本。

不過，依賴圖也會帶來額外的工程複雜度。尤其是創作任務中的依賴關係未必完全確定，某個上游素材發生變化後，下游結果是否必須重新生成，還需要結合修改範圍和具體製作要求來判斷。

此外，即使依賴關係正確，也無法保證生成結果在視覺上達到預期。角色一致性、鏡頭連貫性和整體節奏仍然需要獨立的品質評估機制。

因此，Production DAG 目前更多是我們正在探索的演進方向。現階段，我們優先確保 Agent 能夠在 Lomote AI 既有的模型與工具能力範圍內，完成可執行的創作流程，並控制中間產物的成本與有效性。

隨著任務依賴、自動驗收和多模態理解能力逐步完善，未來也有機會把這些機制結合起來，讓 Agent 從按步驟執行創作任務，進一步走向對完整製作流程的管理。而要判斷這些設計是否真正有效，僅靠一次順暢的展示還遠遠不夠。複雜的創作任務中還會出現工具失敗、使用者修改、狀態恢復以及重複生成等情況。

這些設計是否有效，仍需要透過故障恢復與端到端協作演練來驗證。

11. 工程驗證：從故障恢復到端到端協作

Agent 系統有一個很有意思的特點：單一模組運作正常，並不代表整個協作過程就一定可靠。

例如，訊息正確路由到了對應事項，工具呼叫也成功回傳，但 Agent 可能在生成完成後忘記繼續執行；又或者每一步都符合預期，最後卻產生了多份重複的文件，讓使用者不知道哪一份才是最新版本。

這類問題很難透過傳統的單元測試或幾輪簡單對話發現。

因此，在 Lomo Agent 的開發過程中，除了驗證各個模組的正確性，我們也嘗試讓 Agent 在接近真實的使用場景中走完完整流程，觀察各項機制組合之後的實際表現。

11.1 執行環境的可靠性驗證

對於持久化執行、訊息收件匣、非同步生成和使用者授權等機制，很多問題只會出現在特定的狀態轉換過程中。

例如：

• 影片生成請求已經提交，但 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： lomo agent

點擊放大

點擊放大

參考資料與延伸閱讀

以下連結主要用於說明架構上的啟發與研究背景，不代表各專案在所有能力上與 Lomo Agent 具有相同的實作或設計目標。

1. DeepSeek Super-agent Prototype

2. Temporal — Design Patterns

3. OpenAI — Using Goals in Codex

4. Anthropic — Effective Harnesses for Long-Running Agents

5. Claude Code — Hooks

6. Anthropic — How We Built Our Multi-Agent Research System

7. Manus — Context Engineering for AI Agents

8. Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory

9. Zep / Graphiti: A Temporal Knowledge Graph Architecture

10. LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory

11. OpenClaw — Memory Architecture

12. ViMax — Multi-Agent Video Generation

註：文中「既有機制」與「演進方向」已盡可能分別標明。對於外部服務的冪等保證、遺忘所涵蓋的資料範圍、模型快取行為及自動驗收效果，實際能力均受具體實作與依賴條件約束。