四框架 trade-off 矩阵 + memory 厂商 benchmark 批判（ATAM 式 I）
四框架 trade-off 矩阵 + memory 厂商 benchmark 批判（ATAM 式 I）
日期: 2026-08-13 阶段: Phase 2 - AI-native 参考架构 标签: #framework-tradeoff #atam #memory-benchmark #vendor-claims
核心问题
今天两件事收口：(1) OpenAI Agents SDK 阅读级评审（不实现，避免在第四个框架上重复装配成本）+ 汇总四个数据点（AI SDK 6 实测、Claude Agent SDK 实测、OpenAI Agents SDK 阅读评审、W6 的 LangGraph/Temporal 分层笔记）→ trade-off 矩阵 v1；(2) memory 厂商 benchmark 的批判评审起步（ATAM 式）——核查一组矛盾到离谱的数字：第三方测 Mem0 在 LongMemEval 上 49.0%，Mem0 自己却报 94.4%，差近 2 倍。
这两件事是同一个架构师能力的两面：不被供应商的叙事牵着走。框架对比要剥离「作者熟谁谁赢」（Day 57-59 的三固定纪律），memory 选型要剥离「厂商自报 SOTA」。今天把这两套剥离方法论坐实——前者产出可信的四框架矩阵，后者证明「同一个产品的 benchmark 数字能因为换了配置和测评方而差 2 倍，所以任何单一厂商数字都不可作选型依据」。
关键内容
A. OpenAI Agents SDK 阅读级评审：第四种世界观
不实现的理由很实在：Day 57 三固定要求逐字符共享 prompt/工具/模型，但 OpenAI Agents SDK 的核心原语（handoffs/guardrails）与对账任务（单 agent、确定性判分）正交——硬塞会让实现充满与任务无关的脚手架，反而污染对比。所以它进阅读级评审，作为「设计哲学」第四个数据点。
OpenAI Agents SDK 的四原语：Agents / Tools / Handoffs / Guardrails。三个区别于前两框架的设计点：
- Handoffs = 全历史转移：agent A handoff 给 agent B 时，完整消息历史转交，B「看到整段对话仿佛从头参与」。这与 Anthropic orchestrator-worker（子 agent 独立 context）相反——handoff 是「换驾驶员不换车」，orchestrator-worker 是「派独立侦察兵回报」。
- Guardrails 三层：input（用户消息进 agent 前）/ output（响应出去前）/ tool（每次工具调用前后）。这是把「防灾」做成一等原语——与本仓 W8 风控网关「事前授权/事中拦截/事后审计」三段同构，但 OpenAI 把它内置进框架。
- Sessions 自动管理历史 + 每次 run 产出可检视 trace（模型调用/工具/handoff/guardrail/计时）。
反直觉洞察①（handoff 的「全历史转移」是便利也是成本炸弹）：handoff 全历史转移让接手 agent「无缝衔接」，体验上很顺。但成本上——每次 handoff 都把整段历史重新计费给下一个 agent 的 input，多次 handoff = 历史 token 被反复全价重发，叠加 Day 58 洞察①的单 agent 内二次增长，总成本是「步数 × handoff 次数」的乘性爆炸。这正是 ADR#1（Day 33）「暂不上多 agent」的另一条成本论据：handoff 链越长，token 账单越像复利。对账任务单 agent 就够（呼应 Princeton「多数任务单 agent 即够」——但该数字 D31 已核查须谨慎引用），无需 handoff，这本身就是「该不该用 OpenAI Agents SDK」的答案。
B. 四框架 trade-off 矩阵 v1
汇总四个数据点（质量/token/延迟数字执行当日从 bench/score.ts 回填；以下为结构与已知架构属性）：
| 维度 | Vercel AI SDK 6 | Claude Agent SDK | OpenAI Agents SDK | LangGraph + Temporal |
|---|---|---|---|---|
| 世界观 | 你拥有 loop / provider-neutral | harness 拥有 loop / Claude-shaped | 多 agent 原语 / OpenAI-tight | 显式状态图 / durable |
| loop 控制 | generateText/ToolLoopAgent 你数 step | query() async-iterable，harness 自治 | Runner.run，handoff 转移控制 | StateGraph 节点+边，你画图 |
| context 管理 | 手动（超窗 prompt_too_long） | 自动 compaction（SDKCompactBoundaryMessage） | Sessions 自动历史 | checkpointer 持久化 |
| 工具形态 | 裸 Record<string,Tool> | 进程内 MCP（createSdkMcpServer） | function tool + handoff | 节点内任意 |
| 安全原语 | 无内置（needsApproval 工具级） | permissionMode + hooks | Guardrails 三层内置 | 自己在节点写 |
| 成本可观测 | 你算 estimateCost(totalUsage) | 框架给 total_cost_usd（含缓存折扣） | trace 含计时（成本自算） | 自己埋 |
| durable/恢复 | 无 | sessions 持久化 | sessions | checkpoint 断点续跑（强项） |
| 本仓适配度 | 最高（已用 ai 包） | 高（W8 MCP 复用） | 低（多 agent 原语对账用不上） | 中（W5-6 已接 checkpointing） |
| 质量分（break_recall） | 回填 | 回填 | 不实现（阅读评审） | 回填（W6 数据） |
| 单案 token（totalUsage/裸口径） | 回填 | 回填（双口径） | — | 回填 |
| 延迟 p50 | 回填 | 回填 | — | 回填 |
矩阵的架构师读法（非「谁赢」）：选型是任务-框架匹配，不是「最强框架」。对账（单 agent / TS 栈 / 已用 ai 包）→ AI SDK 6；长自治任务（长上下文 / Claude 模型 / 要 compaction）→ Claude Agent SDK；多专家协作（客服路由式）→ OpenAI Agents SDK 的 handoff；跨会话崩溃恢复（HITL 审批等待 / 长事务）→ LangGraph+Temporal。四者不是竞品而是工具箱——这是 trade-off 矩阵区别于排行榜的本质。
C. memory 厂商 benchmark 批判：一个产品，三个数字，差 2 倍
切到 memory 选型（Mem0/Letta/Zep）。核查那组矛盾数字，结论触目惊心——同一个 Mem0 在同一个 benchmark（LongMemEval）上，能给出从 49.0 到 94.4 的数字：
| 数字 | 来源 | 性质 | 配置 |
|---|---|---|---|
| Mem0 49.0%（LongMemEval, GPT-4o） | 第三方 Vectorize.io 独立测 | 第三方 | Mem0 旧基线配置 |
| Zep 63.8%（LongMemEval, GPT-4o） | 同一第三方独立测 | 第三方 | — |
| Mem0 94.4%（LongMemEval） | Mem0 自报 | 厂商自报 | Mem0「新 token-efficient 算法」 |
| Zep 84%（LoCoMo） | Zep 自报原始声明 | 厂商自报 | Zep 原配置 |
| Zep 58.44%（LoCoMo） | Mem0 重算 Zep | 对手重算 | Mem0 称 Zep 含了规范排除的对抗类目 |
| Zep 75.14%（LoCoMo） | Zep 反驳重算 | 自报反驳 | Zep 称 Mem0 配错了它的评测 |
反直觉洞察②（厂商自报 benchmark 与第三方差 2×，不是造假，是「配置即结论」）：Mem0 自报 94.4 vs 第三方 49.0，差近 2 倍——但这不必然是撒谎。差异来自：(1) 换了算法版本（旧基线 vs 新 token-efficient）；(2) 自家测评用最优超参/检索配置，第三方用默认；(3) LongMemEval 子集与判分口径选择。memory benchmark 的可怕之处不在数字假，而在「同一产品换个配置就能从 49 跳到 94」——意味着 benchmark 数字几乎不携带选型信息。LoCoMo 的三方互撕（84 → 58.44 → 75.14）更直接证明：连「同一个系统在同一 benchmark 上到底几分」都没有共识。Atlan 的诚实结论一针见血：「treat any single benchmark number from either vendor with caution；benchmark construction for conversational memory is still immature」。选 memory 不能看 benchmark 排名，要看架构是否匹配场景（D 节）。
D. ATAM 式起步：从「比分数」转向「比质量属性-场景-风险」
既然分数不可信，memory 选型回到 ATAM（架构权衡分析法，本仓 docs/arch 已有方法论）的正道——不比单一指标，比「在我的场景下，各架构对关键质量属性的支撑与风险」。三家 memory 的架构分野（非分数）：
| 架构维度 | Mem0 | Letta (MemGPT 系) | Zep |
|---|---|---|---|
| 核心机制 | LLM 抽取事实 + ADD/UPDATE/DELETE/NOOP 自编辑 | OS 虚拟内存分页（核心/外部记忆换页） | 时间知识图谱（Graphiti） |
| 适合场景 | 事实型记忆、token 效率优先 | 长上下文「无限记忆」幻觉、显式分页控制 | 关系/时序推理（谁在何时做了什么） |
| 对 AML 的契合 | 中（案件事实抽取） | 低（AML 不需无限分页） | 高（资金流时序+地址关系=知识图谱原生） |
| 主要风险 | 自编辑误删关键事实（DELETE 误判） | 分页策略复杂、运维重 | 图构建成本、写入延迟 |
今天只起步（评审 I）：建立「分数不可信 → 转 ATAM」的方法框架 + 三家架构分野表。完整的「场景-质量属性-风险」ATAM 结构留 Day 61（评审 II 定稿）。对 AML Copilot 的初步指向：资金流是时序+关系问题，Zep 的时间知识图谱在架构上最契合——但这是架构匹配判断，不是「Zep benchmark 高所以选它」（恰恰相反，Zep 的 84% 自报已被打到 58.44，分数毫无参考价值）。
设计要点/决策表
| 要点 | 决策 | 理由 |
|---|---|---|
| OpenAI Agents SDK | 阅读级评审不实现 | handoff/guardrail 与单 agent 对账任务正交 |
| 矩阵读法 | 任务-框架匹配，非「最强框架」 | 四框架是工具箱不是排行榜 |
| memory 选型依据 | 禁用 benchmark 排名，用 ATAM | 同产品同 benchmark 数字可差 2×，不携带选型信息 |
| benchmark 数字归属 | 第三方/自报/对手重算严格标注 | 49.0(三方) vs 94.4(自报) 不可混 |
| AML memory 倾向 | 架构契合（时序+关系）指向 Zep 式图 | 资金流是关系推理，非「Zep 分高」 |
| ATAM 拆分 | 今日起步框架，Day 61 定稿 | 评审需「场景-质量属性-风险」完整结构 |
对本项目的落地
bench/score.ts汇总四数据点落 agent-lab：导出frameworkMatrix(scores)产出 B 节矩阵 JSON（AI SDK 6 / Claude SDK 实测 + LangGraph W6 数据 + OpenAI 阅读评审标记implemented:false），喂 agent-lab 的对比视图。token 列用 Day 58-59 钉死的双口径（totalUsage 裸口径 + Claude 实付口径分列），禁止单口径并排。- ADR 附注（trade-off 矩阵）：在 ADR#1（Day 33）追加附注——四框架矩阵 + 「本仓 orchestrator 升级 AI SDK 6 ToolLoopAgent 是装配重构非语义重写」（Day 58 结论）；handoff 成本复利（洞察①）作为「多 agent 暂缓」的补充论据。
- memory 评审材料
docs/aipa/longform/（长文#3 原料）：C 节 benchmark 归属表 + D 节 ATAM 架构分野表，作为「为什么 AML Copilot 的 memory 不照 benchmark 选」的证据；指向 P3 时若引入 memory 层，优先评估 Zep 式时间知识图谱对资金流时序的架构契合（复用本仓src/agent/memory/*三层接口适配）。 - 诚实标注：矩阵质量/token/延迟数字执行当日回填，未回填前不对外引用；memory 倾向标「架构契合判断，非 benchmark 结论」；OpenAI Agents SDK 行明确「阅读评审、无实测数据」。bench 与 memory 评审均为研究产物，不进阻断式 CI gate。
参考资料
- OpenAI — Agents SDK docs（developers.openai.com/api/docs/guides/agents；openai.github.io/openai-agents-python）：四原语 Agents/Tools/Handoffs/Guardrails；handoff 转移完整消息历史；guardrails 三层（input/output/tool）；Sessions 自动历史；每 run 可检视 trace（2026，执行当周确认版本）
- Atlan — Zep vs Mem0: Benchmarks, Pricing, and When to Use Each：LongMemEval GPT-4o Zep 63.8% / Mem0 49.0%（第三方 Vectorize.io 独立测）；LoCoMo Zep 自报 84% → Mem0 重算 58.44% → Zep 反驳 75.14%（GitHub issue getzep/zep-papers#5）；结论「任一厂商单一 benchmark 数字须谨慎对待，对话记忆 benchmark 构建仍不成熟」（2026）
- Mem0 — State of AI Agent Memory 2026 / research：Mem0 新 token-efficient 算法自报 LongMemEval 94.4 / LoCoMo 92.5 / BEAM 64.1·48.6（厂商自报，2026-06）
- Mem0 论文（2025-04）：LLM 抽取事实 + ADD/UPDATE/DELETE/NOOP 自编辑机制
- ATAM 方法论（本仓 docs/arch，架构 120 天）：质量属性-场景-风险权衡分析，非单指标比分
- 本仓物证：
src/agent/memory/*（三层记忆接口，memory 层适配对象）、src/agent/orchestrator/orchestratorAgent.ts（升级 AI SDK 6 的对照）、bench/score.ts（Day 58-59 双口径成本）、Day 33 ADR#1（多 agent 暂缓）(2026-06)
SOTA 检查 (2026-08-13)
- 四框架格局 2026-08 稳定：AI SDK 6（TS 生产首选）、Claude Agent SDK（Claude 自治）、OpenAI Agents SDK（多 agent 原语 + guardrails）、LangGraph+Temporal（durable）——四者各占生态位，无单一「最优」；执行当周复查各框架版本（OpenAI Agents SDK 2026-05-26 口径、其余见 Day 57-59）。
- memory benchmark 战争 2026-08 仍未解：LongMemEval 第三方 Zep 63.8 / Mem0 49.0 与 Mem0 自报 94.4 并存；LoCoMo 84→58.44→75.14 三方互撕未收敛——「benchmark 构建不成熟、单一厂商数字不可信」是当前 SOTA 共识（Atlan 2026），本笔记据此把 memory 选型从「比分」转为 ATAM「比架构契合」。
- 「配置即结论」是 memory benchmark 的根本病灶（洞察②）：同产品同 benchmark 因算法版本/超参/子集差 2×——这不是个别厂商问题，是对话记忆评测方法论尚不成熟的系统性现象；选型必须看架构匹配（D 节），不看排名。
- 过时认知警示：(1) 不可引「Mem0 94.4」「Zep 84%」作选型依据——均厂商自报且已被对手/第三方打折（洞察②）；(2) 不可把 trade-off 矩阵读成「框架排行榜」——是任务-框架匹配工具箱（B 节）；(3) handoff「全历史转移」便利但成本复利（洞察①），多 agent 非默认更优。
- 待跟踪：Day 61 ATAM 评审 II 完成「场景-质量属性-风险」完整结构，定 AML Copilot 是否引入 memory 层及选型；执行当日复查 LongMemEval/LoCoMo 是否出现社区统一的独立重测（若有标准化第三方榜，memory 选型可部分恢复用分数辅证）；OpenAI Agents SDK 是否补齐 TS 版（当前 Python 主导，影响本 TS 仓是否值得实测为第五数据点）。