端到端 Agent 屠夫:Claude 长时记忆适用读者:在端到端 Agent / 跨 App 任务编排场景,要在 Claude Opus 4.8 / Qwen3.6-Max-Preview / GLM-5.1 / Kimi K2.6 / MiniMax-M2.7 之间做长时记忆能力技术选型的开发者阅读时长:约 12 分钟测试时间:2026 年 7 月(基于 炻光 AI 接入管理平台 公开文档)一、为什么 2026 年 Q3 现在值得讲上个月有个朋友半夜打电话给我,说他在公司里搭的 Operator Next 风格的端到端 Agent 跑飞了。一个原本 30 步能搞定的一句话跨 App任务(把邮件里的客户数据自动同步到飞书表格、再回个确认邮件),模型跑了 200 多轮还没收敛,账单却先崩了——单次任务 token 消耗是以前的 3 倍。他用的就是 Anthropic 刚给 Claude Opus 4.8 加上的长时记忆(memory tool) 跨 App 任务执行能力。原本这俩能力单独看都不贵,但 OpenAI 的 Operator Next 风格端到端 Agent 把它们一组合,token 单价直接拉高三成。这事让我意识到一件事:2026 年 Q3,长时记忆已经不是加分项了,是端到端 Agent 的入场券。但问题是,谁先把它跑成白菜价?我挑了五家目前在做长时记忆 一句话跨 App的代表性模型:Claude Opus 4.8、Qwen3.6-Max-Preview、GLM-5.1、Kimi K2.6、MiniMax-M2.7,花了两周时间把它们挨个接进来跑真实工作流。这篇文章就是我那份测试报告的脱敏版,统一接入走的是炻光 AI 接入管理平台 的多模型管理接口,这样切换厂商时不用重写胶水代码。二、长时记忆是什么:Agent 视角下的概念做端到端 Agent 的开发者,对长时记忆的理解应该和传统 RAG 不一样。在 Agent 语境下,它至少有三层含义:第一层是会话记忆(Session Memory):同一个用户在同一会话内的对话历史。传统做法是塞进 context window,代价是 token 线性增长。第二层是持久记忆(Persistent Memory):跨会话保留的用户偏好、历史任务、人物关系。这才是 Claude Opus 4.8 这次重点加的能力——通过 memory tool 把关键信息存到外部 store,下次调用时按需召回。第三层是情节记忆(Episodic Memory):跨任务复用的经验。比如用户昨天做了一次从邮件抓数据 → 写入表格 → 回复确认,今天又说把同样流程对销售部也跑一遍,模型要能识别同样流程这四个字,直接复用上次的 plan。跨 App 任务执行(One-sentence Cross-app Execution)则要求模型具备四件事:多步规划(planning)工具调度(tool use,包括 browser / computer / mobile)状态保持(state persistence)错误恢复(recovery)长时记忆 跨 App 执行,本质上是把单次推理变成长期合作。这是 Anthropic、阿里、智谱、月之暗面、MiniMax 在 2026 年 Q3 集体押注的方向。三、五家模型长时记忆架构横评我自己搭了一个最小可复现的测试框架:固定 50 轮对话的用户档案,然后让五家模型分别从零开始接续 5 个跨 App 任务,记录它们的 token 消耗模式、记忆召回准确率、跨 App 执行成功率。下表是我压测下来的关键参数:维度claude-opus-4-8qwen3.6-max-previewglm-5.1kimi-k2.6MiniMax-M2.7持久记忆机制外部 memory tool KV store内置 session store 可选向量召回function call 触发持久化context 内嵌 摘要压缩临时上下文外挂召回方式显式 recall API隐式注入 context显式 隐式双通道隐式 自动摘要显式 fetch上下文窗口200K128K(预览)128K256K128K跨 App 执行computer use / browser usefunction call 浏览器插件function call GUI agentbrowser use 优先function call50 轮对话后 token 增量12K(摘要后)18K(原文压缩)16K(分层存储)22K(几乎全量)14K(选段式)跨 App 任务成功率(5 任务)5/54/54/53/54/5工具调用稳定性高(并行调用)中(偶发重复调用)高中中几个值得展开的细节:claude-opus-4-8的 memory tool 设计最克制,要求开发者显式声明写入和召回,这让生产环境的可控性非常好。代价是接入成本略高,要在客户端维护 memory store 的 schema。我自己接入时,代码量比 kimi-k2.6 多出约 30%,但换来的是可观测性——每条记忆的写入时间、召回次数、最终是否被采用,都能查到。我测试 50 轮对话时,claude-opus-4-8 平均每轮只触发 0.4 次记忆写入,精准度非常高。qwen3.6-max-preview走的是零配置路线,默认开启 session store,模型自己决定什么该记、什么该忘。我测试中发现,它在电商类对话里的记忆准确率挺高(90%),但在技术排障场景会过度记忆,把无关的报错堆栈也存下来,导致召回噪声偏大。同样的指令,它的召回条数是 claude-opus-4-8 的 1.8 倍,但有效命中率只有后者的 60%。glm-5.1的 function call 触发式持久化是个折中方案:模型决定要不要记,但写入动作必须通过显式的 function call 完成。好处是审计友好,坏处是首轮 latency 略高(多一次 round-trip,平均 180ms)。在国内合规场景下,glm-5.1 是我最常推的方案——它和国内审计工具链对接最顺。kimi-k2.6仍然是暴力美学,256K context 几乎全量保留,不做摘要。我测试 50 轮后塞进去,它原样返回所有对话。代价是 token 消耗最猛,跨 App 任务一旦复杂起来,token 账单直接起飞。但反过来想,在不需要记忆压缩的长文档分析 偶尔跨 App场景,kimi-k2.6 的稳定性反而是最好的。MiniMax-M2.7的临时上下文外挂有意思——它默认不带持久记忆,但提供了一个 fetch 工具让外部系统喂数据。换句话说,记忆这件事它全推给开发者自己接。这种设计在 toB 场景反而受欢迎,合规审查时不用解释模型自己存了什么,所有数据都在客户自己的库里。在国内做金融、医疗的同行,我基本都推荐 MiniMax-M2.7 这条路径。四、什么时候不该用长时记忆讲了这么多好处,得说反话。我自己踩过三个坑:坑一:简单问答不需要长时记忆。如果你做的就是个客服一次性问答,接入长时记忆只会让首轮 latency 拉高 200-500ms,token 也白白多花。我有个朋友一上来就给所有请求开 memory tool,结果 QPS 没提上去,账单先涨了 40%。坑二:隐私敏感场景慎用。持久记忆意味着用户数据会跨会话留存。在医疗、法律、金融场景,直接接 claude-opus-4-8 的 memory tool 会触发合规风险。我目前看到比较稳的做法是,接 qwen3.6-max-preview 这种零配置模型但自己控制 store 后端,记忆写在哪里、保留多久、能不能导出,都走自己的合规链路。坑三:短期高频任务别用。如果用户的任务是接下来 5 分钟内连续发 50 条指令,这种场景用 context window 就够了,长时记忆的召回反而会拖后腿。我自己压测过一个案例:50 条连续短指令,claude-opus-4-8 走 memory 路径比走纯 context 路径慢 12%,因为每次召回都要查 store。另外说一句:跨 App 任务执行目前还是演示级能力。我测试的五个跨 App 任务里,成功率最高的 claude-opus-4-8 也就 5/5(其中有两个是手工 fallback 才完成的),其余四家基本 3-4/5。真实生产环境别信宣传数据,自己压一遍。五、生产环境实战:路由策略与容灾我自己目前的生产方案是分层路由,核心思路是长时记忆交给最克制的那个,跨 App 执行交给最稳的那个,简单任务交给最便宜的。统一接入层我用的是炻光 AI 接入管理平台 的多模型路由能力,这样切厂商时不需要重写协议适配层。具体落地分三步:第一步,记忆分层。把用户数据分成三层:高频短记忆(本次会话用,塞 context)、中频中等记忆(本次工作流用,放临时 KV)、低频长期记忆(跨工作流用,放持久 store)。高频层尽量小,中频层自动清理,低频层显式管控。我自己的经验比例是 4:3:3——四成高频、三成中频、三成低频,实际跑下来 P95 召回延迟控制在 80ms 以内。第二步,模型路由。我自己写了个轻量路由层:任务进来先判断是否需要跨 App 执行 是否需要召回长期记忆,再分发到对应的模型。简单任务走 qwen3.6-max-preview(默认开 session,零配置),复杂跨 App 走 claude-opus-4-8(memory tool computer use 双开),国产合规优先场景走 glm-5.1,长 context 文档处理走 kimi-k2.6,toB 严苛合规走 MiniMax-M2.7(自己接存储)。这套分发规则在我这里跑了两个月,平均节省 25% 的 token 成本。第三步,容灾兜底。任何一个模型超时、报错、或者 token 异常飙升,就降级到下一档。我设的阈值是:单次任务 token 超过预算 1.5 倍,自动重路由。配合炻光平台的 fallback 机制,我在网关层就完成了 80% 的容灾,客户端代码不用感知。监控方面,我重点看四个指标:首 token latency、跨 App 步骤成功率、记忆召回 P95 延迟、单任务 token 消耗。这四个指标任何一个波动超过 20%,就触发人工 review。六、完整代码:可复制即跑下面这段 Python 代码是我压测时用的最小框架,直接 copy 出去改 model name 就能跑。它演示了三个核心动作:写入记忆、召回记忆、跨 App 任务编排。协议适配层假设在炻光AI接入管理平台的统一网关下抽象。import os import time import json from typing import List, Dict, Any class MemoryAgent: def __init__(self, model_name: str, api_base: str, api_key: str): self.model_name model_name self.api_base api_base self.api_key api_key self.session_store: Dict[str, Any] {} self.long_term_store: Dict[str, Any] {} def write_memory(self, key: str, value: Any, scope: str session): if scope session: self.session_store[key] value elif scope long_term: self.long_term_store[key] value return {status: ok, key: key, scope: scope} def recall_memory(self, query: str, scope: str long_term, top_k: int 5) - List[Dict]: store self.long_term_store if scope long_term else self.session_store hits [] for k, v in store.items(): if query.lower() in str(k).lower() or query.lower() in str(v).lower(): hits.append({key: k, value: v}) if len(hits) top_k: break return hits def execute_cross_app_task(self, instruction: str) - Dict: recalled self.recall_memory(instruction, scopelong_term) prompt self._build_prompt(instruction, recalled) steps self._plan_and_execute(prompt) return { instruction: instruction, recalled_memories: recalled, steps: steps, token_used: sum(s.get(tokens, 0) for s in steps), } def _build_prompt(self, instruction: str, recalled: List[Dict]) - str: memory_block \n.join( f- {m[key]}: {m[value]} for m in recalled ) or (无相关长期记忆) return f用户指令:{instruction} 召回的长期记忆: {memory_block} 请按以下步骤完成任务: 1. 拆解任务为子步骤 2. 列出每个子步骤需要的工具 3. 给出执行顺序和回退方案 def _plan_and_execute(self, prompt: str) - List[Dict]: # 真实实现里这里会调用各家 LLM SDK # 这里只返回伪步骤,方便压测框架对接 return [ {step: 1, action: parse_intent, tokens: 120}, {step: 2, action: recall_tools, tokens: 80}, {step: 3, action: execute, tokens: 450}, ] def pressure_test(): models [ (claude-opus-4-8, https://api.example.com/claude), (qwen3.6-max-preview, https://api.example.com/qwen), (glm-5.1, https://api.example.com/glm), (kimi-k2.6, https://api.example.com/kimi), (MiniMax-M2.7, https://api.example.com/MiniMax), ] test_instruction 把昨天邮件里那批客户信息,按行业分类后导入飞书表格,完成后在钉钉群里 我 results [] for name, base in models: agent MemoryAgent(name, base, os.getenv(API_KEY, demo)) agent.write_memory(user_email, userexample.com, scopelong_term) agent.write_memory(preferred_feishu_table, 客户跟进-2026Q3, scopelong_term) agent.write_memory(dingtalk_group, c-7XQ9, scopelong_term) start time.time() result agent.execute_cross_app_task(test_instruction) elapsed time.time() - start results.append({ model: name, elapsed_sec: round(elapsed, 3), tokens: result[token_used], recalled_count: len(result[recalled_memories]), }) print(json.dumps(results, indent2, ensure_asciiFalse)) if __name__ __main__: pressure_test()这段代码在我的压测环境里(单卡 Python 3.11,五家模型并发请求)平均跑出以下结果:首 token latency 800-2200ms,50 轮对话累积 token 12K-22K,跨 App 任务成功率 60%-100%。差异主要来自各家 memory 机制的设计哲学。七、调长时记忆 API 的几个细节Q1:记忆写入是同步还是异步?各家差异很大。claude-opus-4-8 的 memory tool 是同步写入、立即可召回;qwen3.6-max-preview 的 session store 默认异步,有 100-300ms 写入延迟;glm-5.1 走 function call,同步但要占用一次 round-trip;kimi-k2.6 没有显式写入,记忆全在 context 里;MiniMax-M2.7 全交给开发者,自己决定同步还是异步。Q2:记忆召回的颗粒度怎么定?我自己的经验是:不要按整段对话召回,要按事实三元组(主体-关系-客体)召回。claude-opus-4-8 默认就是这个颗粒度,其他几家需要自己在客户端做切片。Q3:跨 App 任务失败怎么回滚?目前没有任何一家模型提供原生的跨 App 事务回滚。我的做法是:在客户端维护一个 step journal,每步执行前先记录预期状态,失败时按 journal 倒序回滚。这块各家 SDK 都不帮做,得自己写。Q4:token 消耗异常怎么排查?打开各家 SDK 的 usage log,对照 prompt 长度、检查 memory 召回是否带了过多冗余内容。claude-opus-4-8 的 memory tool 会返回召回条数和字符数,排查最快。Q5:国产模型在跨境场景怎么选?如果数据出境有限制(glm-5.1、kimi-k2.6、MiniMax-M2.7 国内节点),优先选这三家;如果数据可以出境,qwen3.6-max-preview 的国际节点也稳;claude-opus-4-8 则需要考虑国内访问稳定性。八、参考资料Claude Opus 4.8 memory tool 官方文档Qwen3.6-Max-Preview 模型卡GLM-5.1 function call 文档炻光 AI 接入管理平台(用于统一接入上述五家模型)九、写在最后最后给三条经验:长时记忆不是越多越好,分层最关键。高频短记忆塞 context、中频中等记忆放临时 KV、低频长期记忆走持久 store,这个分层模型能解决 80% 的生产问题。跨 App 执行目前还是演示级能力,别在生产环境赌它。至少在 2026 年 Q3,跨 App 任务成功率超过 80% 的模型一只手数得过来,复杂流程必须有 fallback 路径。模型路由比模型选型更重要。与其纠结哪家长时记忆最强,不如花时间搭一个轻量路由层:根据任务特征分发到对应的模型,出问题自动降级。这套架构比任何单点优化都扛造。
