長時間運行的智能體如何跨越上下文窗口：交接摘要 + 歸檔檢索模式的 3 個設計問題

作者注：以 openJiuwen WorkSwarm 的上下文切換機制爲案例，解讀“交接摘要 + 歸檔檢索”模式，梳理長時間運行的智能體在上下文窗口上限前的設計選項與取捨。

華爲支持的開源智能體社區 openJiuwen 近期發佈了 Hyper-Agent 集羣架構。其中一個細節值得開發者關注：當智能體的上下文窗口接近上限時，它會切換到新窗口，帶上一份包含目標、進展和下一步的交接摘要，需要細節時再去檢索歸檔歷史。這個機制只用一句話就講完了，背後卻是所有長週期智能體都要面對的工程問題。

這不是坊間傳言。相關能力已隨 openJiuwen WorkSwarm 發佈，代碼以 JiuwenSwarm 的名稱在 GitHub 開源。本文以這一機制爲案例，展開討論交接摘要應包含什麼、何時觸發切換、何時回查歸檔這三個設計問題，並比較“依賴更長上下文”和“摘要交接 + 檢索”兩種思路的取捨。

核心價值：讀完本文，你可以對照自己的智能體應用，梳理出處理上下文窗口上限的可選方案和各自的風險。

交接摘要 + 歸檔檢索：核心信息速覽

先把參考資料中能確認的事實整理清楚，再看它對開發者意味着什麼。下表中的信息均來自公開報道，未經報道確認的實現細節會在後文單獨標註。

爲什麼持久化智能體必須解決上下文窗口上限

WorkSwarm 的設計思路是讓智能體脫離單個聊天會話，作爲“數字員工”長期駐留在飛書、釘釘等工作羣裏。同一個智能體可以跟進多個第三方羣聊中的多項任務，在一個渠道接收請求，在另一個渠道交付結果。系統由網關連接即時通訊應用和 Web 界面，再由 AgentServer 調度智能體與工作會話。

在這種形態下，上下文窗口上限不再是偶發問題，而是必然會發生的事件。一個只回答單輪問題的聊天機器人很少把窗口用滿，但一個持續數天跟進項目的智能體，對話記錄、工具調用結果和文件內容會不斷累積。報道還提到 WorkSwarm 的活動面板會顯示每個智能體的 token 用量，這說明上下文消耗本身就是這類系統需要持續觀察的運行指標。

會話作爲資源：交接摘要的前提

理解交接摘要機制的關鍵，在於 WorkSwarm 把“智能體”和“會話”拆開了。智能體的身份與狀態是持續存在的，會話只是系統分配、併發調度、並可帶着上下文恢復的資源。既然會話可以被替換，那麼“窗口滿了就換一個新窗口”就成爲自然的設計選擇。

交接摘要扮演的角色，就是在舊會話和新會話之間傳遞最少但足夠的工作狀態。歸檔歷史則保證舊會話裏的細節不會真正丟失，只是從“隨時在場”變成了“按需調取”。

交接摘要設計問題一：應該包含什麼

報道給出的三要素是目標、進展和下一步。這個結構簡潔，但實際落地時每一項都需要進一步拆解。下表是我們基於這三要素展開的設計參考，屬於工程層面的建議，並非 JiuwenSwarm 的已確認實現。

其中“約束”和“索引”是我們額外補充的兩項。約束之所以重要，是因爲用戶在長對話中零散表達的偏好（如“報告不要超過一頁”）最容易在摘要壓縮時被丟掉。索引則是連接交接摘要與歸檔檢索的橋樑：摘要越短，就越需要告訴新窗口“細節在哪裏”。

在 WorkSwarm 的場景中，還要注意多羣、多渠道帶來的複雜性。報道提到跨羣分享需要用戶審批，可授予一次性或永久權限，並且可以撤銷。如果這類授權狀態沒有寫進交接摘要，新窗口裏的智能體可能會對權限狀態產生誤判，這類信息更適合作爲結構化字段而不是自由文本保存。

交接摘要設計問題二：何時觸發上下文切換

報道只說明了“接近上限時”切換，具體閾值以及摘要由模型生成還是規則生成，目前公開資料沒有披露，需要查閱 JiuwenSwarm 源碼或文檔確認。從工程角度看，觸發時機通常有以下幾種選擇。

需要特別注意的是，生成交接摘要本身也要消耗上下文。如果等到窗口完全用滿才觸發，模型可能已經沒有空間讀完歷史並寫出高質量摘要。因此無論採用哪種策略，都應爲摘要生成預留餘量。

關於摘要的生成方式，由模型生成的摘要更靈活，能理解任務語義；由規則生成的摘要（例如直接提取任務清單的狀態字段）更穩定，但難以捕捉對話中的隱含決策。實踐中常見的做法是兩者結合：結構化狀態由程序維護，模型只負責補充自然語言的進展說明。

如何實現交接摘要 + 歸檔檢索：一個極簡原型

下面是一個演示該模式思路的極簡原型，並非 JiuwenSwarm 的實現。它在估算的 token 用量接近閾值時，讓模型生成交接摘要，並把舊消息寫入歸檔。

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)

HANDOFF_PROMPT = "請將以上工作記錄整理爲交接摘要，包含：目標、進展、下一步、約束、關鍵信息索引。"

def make_handoff(messages, model="gpt-4o-mini"):
    resp = client.chat.completions.create(
        model=model,
        messages=messages + [{"role": "user", "content": HANDOFF_PROMPT}]
    )
    return resp.choices[0].message.content

import openai
from typing import List, Dict

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

MODEL = "gpt-4o-mini"
CONTEXT_LIMIT = 100_000      # 示例值，按所用模型實際窗口調整
SWITCH_RATIO = 0.7           # 預留空間給摘要生成
HANDOFF_PROMPT = (
    "請將以上工作記錄整理爲交接摘要，分爲五部分："
    "1.目標 2.進展（含關鍵決策及理由）3.下一步 4.用戶約束 5.關鍵信息索引（關鍵詞列表）"
)

class LongRunningAgent:
    def __init__(self, system_prompt: str):
        self.system_prompt = system_prompt
        self.messages: List[Dict] = [{"role": "system", "content": system_prompt}]
        self.archive: List[Dict] = []   # 歸檔歷史，生產環境可換成數據庫或向量庫

    def estimate_tokens(self) -> int:
        # 粗略估算，生產環境應使用對應模型的分詞器
        return sum(len(m["content"]) for m in self.messages)

    def maybe_switch(self):
        if self.estimate_tokens() < CONTEXT_LIMIT * SWITCH_RATIO:
            return
        resp = client.chat.completions.create(
            model=MODEL,
            messages=self.messages + [{"role": "user", "content": HANDOFF_PROMPT}]
        )
        summary = resp.choices[0].message.content
        self.archive.extend(self.messages[1:])      # 舊會話寫入歸檔
        self.messages = [
            {"role": "system", "content": self.system_prompt},
            {"role": "system", "content": f"【交接摘要】\n{summary}"}
        ]

    def search_archive(self, keyword: str, top_k: int = 5) -> str:
        hits = [m["content"] for m in self.archive if keyword in m["content"]]
        return "\n---\n".join(hits[-top_k:]) or "歸檔中未找到相關記錄"

    def chat(self, user_input: str) -> str:
        self.maybe_switch()
        self.messages.append({"role": "user", "content": user_input})
        resp = client.chat.completions.create(model=MODEL, messages=self.messages)
        answer = resp.choices[0].message.content
        self.messages.append({"role": "assistant", "content": answer})
        return answer

agent = LongRunningAgent("你是負責跟進項目週報的數字員工。")
print(agent.chat("請記錄：本週報告不要超過一頁。"))

這個原型的歸檔檢索只是簡單的關鍵詞匹配。報道沒有說明 JiuwenSwarm 使用向量檢索還是其他方式，實際項目中可以根據歸檔規模選擇全文檢索、向量檢索或兩者混合，也可以把 search_archive 註冊爲工具，讓模型自行決定何時調用。

🚀 快速開始：搭建此類原型時，摘要生成和主任務可以使用不同模型，例如用輕量模型生成摘要、用強模型處理主任務。通過 API易 apiyi.com 一個 API Key 即可調用 OpenAI、Claude、Gemini 等模型，方便在同一套代碼裏切換對比，新用戶有免費測試額度。

交接摘要設計問題三：何時回查歸檔歷史

歸檔檢索解決的是“摘要必然有損”這個根本問題。任何壓縮都會丟信息，關鍵在於丟失後能否找回。何時回查歸檔，大致有三種設計取向：

• 模型自主調用：把檢索作爲工具交給模型，模型發現信息不足時主動查詢。靈活，但依賴模型對“自己不知道什麼”的判斷。
• 規則觸發：當用戶提到摘要中沒有的實體、文件名或時間點時，程序自動檢索並注入結果。可控性強，但規則覆蓋面有限。
• 索引引導：交接摘要中保留關鍵信息的索引，新窗口遇到相關話題時按索引精確調取。依賴摘要階段的索引質量。

我們認爲最大的風險在於“不知道自己遺漏了什麼”。如果摘要漏掉了某個用戶偏好，而新窗口裏也沒有任何線索提示它存在，模型就不會想到去檢索。這正是前面建議在摘要中加入“約束”和“索引”字段的原因，它們爲回查歸檔提供了入口。

依賴更長上下文 vs 交接摘要：影響分析

面對上下文窗口上限，另一條路是直接換用上下文更長的模型。兩種思路並不互斥，但適用條件不同。下表是判斷性分析，不附帶效果數據。

💡 選擇建議：如果任務通常能在一個長窗口內完成，優先換用長上下文模型更省事；如果智能體需要像 WorkSwarm 的數字員工那樣長期駐留，交接摘要幾乎是必選項。可以先在 API易 apiyi.com 上用不同上下文規格的模型跑同一任務，觀察實際用量後再決定是否投入摘要機制的開發。

對開發者的影響

• 上下文管理成爲架構層問題：WorkSwarm 把會話作爲可調度資源，意味着上下文切換被納入系統設計，而不是出錯後的補救。
• 狀態需要顯式建模：交接摘要的質量取決於智能體是否清楚記錄了目標、決策和待辦，這反過來要求開發者在設計階段就規劃好狀態結構。
• 可觀測性更重要：WorkSwarm 在活動面板展示 token 用量和響應時間，長週期智能體同樣需要監控切換頻率和檢索命中情況。

對行業的影響

• 從會話型到常駐型：智能體從“一問一答”走向“長期駐留工作羣”，上下文跨窗口能力會成爲這類產品的基礎設施。
• 開源實現提供參考：JiuwenSwarm 開源後，開發者可以直接研究其切換閾值、摘要生成和檢索實現，而不必從零摸索。

常見問題 FAQ

交接摘要與上下文窗口核心要點 Key Takeaways

• 核心機制：窗口近滿時切換新窗口，攜帶目標、進展、下一步的交接摘要
• 前提條件：智能體身份與會話分離，會話成爲可調度、可恢復的資源
• 摘要設計：在三要素之外補充用戶約束和歸檔索引，降低遺漏風險
• 觸發時機：爲摘要生成預留空間，優先在任務邊界切換
• 歸檔回查：摘要必然有損，檢索入口決定信息能否找回
• 路線選擇：中等任務可換長上下文模型，長期駐留任務更需要摘要交接
• 快速驗證：可通過 API易 apiyi.com 多模型統一接口搭建原型對比

總結

openJiuwen WorkSwarm 的上下文切換機制，爲長時間運行的智能體提供了一個清晰的參考模式：

1. 交接摘要承載工作狀態：目標、進展和下一步是最小集合，約束與索引是實用補充。
2. 切換時機需要預留餘量：摘要生成本身消耗上下文，不能等窗口完全用滿才處理。
3. 歸檔檢索兜底信息損失：摘要只負責“記住要點”，細節交給按需檢索。

如果你的智能體正在從單次會話走向長期運行，建議先梳理狀態結構，再決定是換長上下文模型還是引入交接摘要。推薦通過 API易 apiyi.com 快速搭建原型，用多種模型對比摘要質量和上下文消耗。

📚 參考資料

1. Pandaily 報道：openJiuwen Hyper-Agent 集羣架構與 WorkSwarm 數字員工
2. 鏈接： pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees

3. 說明： 介紹持久化智能體、上下文切換與交接摘要機制的英文報道

4. JiuwenSwarm 開源代碼：openJiuwen WorkSwarm 的開源實現

5. 鏈接： github.com（搜索 JiuwenSwarm）
6. 說明： 查閱切換閾值、摘要生成與歸檔檢索的具體實現

作者: APIYI 技術團隊
技術交流: 歡迎在 API易 apiyi.com 網站首頁聯繫我們，更多資料可訪問 docs.apiyi.com 文檔中心

延伸閱讀

• 一個人最多盯 5 個會話？拆解 DeepSeek 超級智能體五大模塊:解讀 DeepSeek Harness 團隊的超級智能體（Super-agent）架構文章：五大模塊、實驗條件與數據、四個開放問題、小團隊落地清單，以及 Router 與 Worker 的模型搭配和成本估算。
• 搭一個定時運行的監控摘要 Agent：4 個組成與接口選擇指南:拆解定時運行的監控摘要 Agent 的 4 個組成部分，講清模型調用層如何藉助 OpenAI 兼容接口與具體 SDK 解耦，並給出可運行的 Python 示例。