AIPA 长文#3：四框架 trade-off
日期：2026-08-15
同一个金融 agent，四种框架：架构师视角的 trade-off
日期：2026-08-15
AIPA-120 长文#3。本文以一个真实的金融 agent 任务（对账异常调查）为统一基准，把同一套 golden set 与同一套 eval 分别落在 Vercel AI SDK 6、Claude Agent SDK、OpenAI Agents SDK、LangGraph 1.0 上，从架构师（AISA/SA）视角拆解四者的抽象层次、durable execution、可观测性与生态四个维度，再对 memory 层（Mem0/Letta/Zep）的 benchmark 矛盾做一次冷静的批判，最后给出一套可复用的选型决策框架。
1. 引言：框架选型是 AISA/SA 的日常，不是一次性决定
做 AI 系统架构（AISA）和软件架构（SA）这几年，我越来越确信一件事：Agent 框架选型不是"选一个最强的"，而是"在一组约束下选一个最不后悔的"。约束包括团队的主力语言栈、是否需要长流程 durable execution、合规对可观测性的要求、以及你愿意为生态锁定付出多少迁移成本。
这件事之所以是"日常"，是因为框架本身在以季度为单位演进。仅 2025 年底到 2026 年中这半年，四个主流框架就各自发了关键版本：
- Vercel AI SDK 6（2025-12-22 发布）首次把 Agent 抽象提升为一等公民；
- LangGraph 1.0（2025-10-22 GA）把 durable execution 与 checkpoint 做成了卖点；
- OpenAI Agents SDK（2026-04-15 公布新一代 harness/sandbox，TypeScript 支持随后跟进，PyPI 上 0.17.x 系列于 2026-05-26 前后稳定）补齐了 code mode 与 sandbox；
- Claude Agent SDK（2026-06 文档与 Managed Agents 形态完善）则强调长流程 harness 与 context compaction。
一个半年前还成立的选型结论，今天可能已经过时。所以本文不写"哪个最好"，而写怎么判断——用一个固定的金融任务把四者放在同一张台子上称重。
2. 基准任务：对账异常调查 agent（同 golden、同 eval）
为了让对比公平，我固定了一个贴近我金融零售背景的任务，而不是泛泛的 "chatbot"。
任务定义：对账异常调查 agent（Reconciliation Exception Investigator）
输入是一条对账差异工单（例如"账户 A 在 T 日清算金额与对手方报文相差 ¥3,180.00"），agent 需要：
- 调用
getLedgerEntries(account, date)拉取我方分户账流水； - 调用
getCounterpartyMessages(account, date)拉取对手方报文； - 调用
classifyDiscrepancy(...)把差异归因到 {时点差 / 币种换算 / 手续费口径 / 重复入账 / 疑似欺诈} 五类之一； - 对"疑似欺诈"类别，必须经人工审批（human-in-the-loop）才能写入
flagForReview工单； - 产出一份结构化调查结论（JSON：
{rootCause, confidence, evidence[], recommendedAction}）。
这个任务故意覆盖了四个考点：多步工具循环、结构化输出、人审断点、长流程可恢复（对账批次可能跨多个工作日等待对手方回函）。
统一基准物（保证横向可比）：
| 基准物 | 内容 | 规模 |
|---|---|---|
| Golden set | 人工标注的差异工单 + 期望归因 + 期望证据链 | 120 条 |
| 工具 mock | 同一套确定性 mock（同输入必同输出），跨框架共享 | 4 个工具 |
| Eval 维度 | 归因准确率 / 证据召回率 / 人审触发正确率 / p95 端到端时延 / 每案 token 成本 | 5 维 |
| 评分器 | LLM-as-judge + 规则校验（欺诈类强制人审命中） | 1 套 |
四个框架跑的是同一个 golden、同一套 eval、同一组 mock，差的只是编排层。这样测出来的差异才归因于"框架"，而不是"prompt 或数据不同"。
3. 四框架逐一架构剖析
3.1 Vercel AI SDK 6（2025-12-22）—— TS 原生、抽象克制
AI SDK 6 把 Agent 升为一等抽象：一次定义 model + instructions + tools，全应用复用，并自动接上类型安全的 UI streaming 与结构化输出（来源：Vercel 官方博客，2025-12）。ToolLoopAgent 是生产级实现，默认最多跑 20 步工具循环：调 LLM → 执行工具 → 把结果回灌对话 → 重复直到完成。人审用一个 needsApproval: true 标记即可，配合 useChat 在前端弹出确认。
对我的对账 agent，落地极顺：四个工具用 tool() 定义，classifyDiscrepancy 的输出用 Zod schema 约束成那五类枚举；欺诈类工具挂 needsApproval，前端直接拿到 approval 事件。@ai-sdk/mcp 现已稳定，能把外部对账系统当 MCP server 接入。
架构定位：抽象层次"中等偏低"——它给你 agent 循环和工具协议，但不替你管长流程状态。跨工作日等待对手方回函，需要你自己把会话状态落到 Postgres/Redis，AI SDK 不提供内建 checkpoint。
适合：TS/Next.js 主栈、需要前端深度集成（streaming + 人审 UI）、流程不超过单次会话生命周期的场景。
3.2 Claude Agent SDK（2026-06）—— 长流程 harness、状态外置
Claude Agent SDK 的设计哲学是"模型即 harness"：内建 20+ 工具、session resumption、以及 context compaction（自动压缩上下文，让 agent 不撑爆窗口就能跑长任务）。但它把"持久化"明确划给应用层——官方文档（2026-06）直说：超过单轮的 agent 都需要把 durable state 放进 Postgres/Redis/对象存储，SDK 的 session 视为 ephemeral，对话日志才是 source of truth。retry、durable execution、多 agent 协调都要你自己搭，或者改用 Claude Managed Agents（托管形态，server 端存会话历史/sandbox 状态/输出，stateful by design）。
对账 agent 在这里的落法：跨日等待用 Managed Agents 的长会话 resume 能力，或自己把日志写库后用 SDK 的 session resume 重放。compaction 在证据链很长（几十条流水）时很实用。
架构定位：抽象层次"中等"——harness 强、长上下文友好，但 durable 是"自带电池可选"，自建则重，托管则省心但有平台绑定。
适合：长 horizon、上下文密集、且愿意用 Managed Agents 换取省心的团队；或本就重度使用 Claude 的栈。
3.3 OpenAI Agents SDK（2026-04-15 新 harness / 0.17.x）—— sandbox 与 code mode
2026-04-15，OpenAI 公布新一代 Agents SDK：核心是 model-native harness + 原生 sandbox，让 agent 能在受控环境里读文件、跑命令、改代码、做 long-horizon 任务（来源：OpenAI / TechCrunch，2026-04）。新 harness 与 sandbox 先在 Python 落地，TypeScript 随后跟进；code mode 与 subagents 是后续路线。PyPI 上 openai-agents 0.17.x 系列在 2026-05 稳定，RealtimeAgent 默认模型升到 gpt-realtime-2，sandbox 的本地源物化也收紧了路径授权。
对账 agent 的契合点：如果归因逻辑里需要"动态写一段 SQL/脚本去交叉核对流水"，sandbox + code mode 是独门优势——别的框架要么没有沙箱，要么得自己搭。Runner + Agent + handoffs 的编排适合把"调查"和"上报"拆成两个子 agent。
架构定位：抽象层次"中等"，但sandbox 这一维独占。代价是 TS 一等支持滞后于 Python，且生态强绑 OpenAI 模型族。
适合：需要 agent 真正"执行代码"的调查/分析类任务；Python 团队;不介意模型供应商绑定。
3.4 LangGraph 1.0（2025-10-22）—— durable execution 与 checkpoint 是亲儿子
LangGraph 1.0（2025-10-22 GA，号称"durable agent framework 第一个 stable 大版本"）把我前面三家都"外置"的东西做成了内建：durable state 自动持久化、每个 node 执行都 checkpoint、server 重启或流程中断后从断点精确恢复、多天审批流程一等支持。human-in-the-loop 是 first-class API：runtime 暂停、存状态、等人审（几秒或几小时后）再从原点恢复，不阻塞线程。1.0 还承诺无 breaking change，向后兼容（来源：LangChain changelog，2025-10）。
对账 agent 在这里几乎是"为它设计的"：跨工作日等对手方回函 = 一个 checkpoint 挂起；欺诈类人审 = interrupt() 暂停等审批；流程图把"取数 → 归因 → 分支（人审/直写）→ 出结论"画成显式 graph，确定性节点和 agentic 节点混编。
架构定位：抽象层次"高"——graph 模型 + 内建持久化，最适合长流程、强可恢复、强人审。代价是概念多（graph/node/edge/checkpointer/store），上手曲线最陡，且生态偏 Python（JS 版有但成熟度与社区量级不及 Python）。
适合：跨天/跨周的 stateful 工作流、合规要求"任意时刻可恢复+可审计"、团队接受 graph 心智模型。
4. 四维 trade-off 横向对比
把上面四节压成一张可决策的表（评级为架构师主观判断，A 最优 / D 最弱，针对"对账异常调查"这一类金融 long-horizon 任务）：
| 维度 | Vercel AI SDK 6 | Claude Agent SDK | OpenAI Agents SDK | LangGraph 1.0 |
|---|---|---|---|---|
| 抽象层次 | 中低（Agent+ToolLoop，克制） | 中（强 harness+compaction） | 中（Runner+sandbox/code mode） | 高（graph/node/checkpoint） |
| Durable execution | C（需自建状态库） | B（自建重 / Managed 省心） | C（需自建，sandbox≠durable） | A（内建 checkpoint，断点恢复） |
| 可观测性 | B（DevTools：step/token/timing/raw req） | B（日志即真相+平台 trace） | B（Traces+平台 dashboard） | A（每 node 状态可查，时间旅行调试） |
| 生态/语言 | A（TS 一等，Next.js 原生，2000万+月下载） | B（多语言，绑 Claude 模型族） | B（Python 一等，TS 滞后，绑 OpenAI） | B（Python 强，JS 次之，集成最广） |
| 人审 HITL | B（needsApproval 标记+useChat） | B（需配合状态层） | B（handoffs+审批逻辑自写） | A（interrupt 一等 API，挂起数小时） |
| 首选场景 | TS 前端深度集成、单会话流程 | 长上下文、重 Claude 栈 | 需执行代码的调查类、Python 栈 | 跨天 stateful、强合规审计 |
第二张量化表：同一对账 golden（120 条）跑出来的工程化成本对比（数字为我在统一 mock 下的相对量级估算，用于体现"框架开销"而非模型能力差异；归因准确率因共享同一模型与 prompt 而趋同，故此处只列工程维度）：
| 工程指标 | Vercel AI SDK 6 | Claude Agent SDK | OpenAI Agents SDK | LangGraph 1.0 |
|---|---|---|---|---|
| 实现"单会话版"代码行数（编排层） | ~120 行 | ~140 行 | ~150 行 | ~210 行 |
| 加上"跨日 durable"额外代码 | +180 行（自建状态机） | +90 行（接日志库）/ 0（Managed） | +180 行（自建） | +15 行（配 checkpointer） |
| 人审断点接入复杂度 | 低 | 中 | 中 | 最低（interrupt） |
| 可观测开箱程度 | DevTools 开箱 | 需接平台 | Traces 开箱 | 状态全程可查 |
| 供应商锁定风险 | 低（多 provider） | 中（Claude） | 中（OpenAI） | 低（多 provider） |
结论一句话：短流程比拼"上手快+前端集成"，AI SDK 6 赢；长流程比拼"durable+人审+审计"，LangGraph 1.0 赢；要 agent 真去执行代码，OpenAI 的 sandbox 独一档；重 Claude 长上下文栈，Claude Agent SDK 顺手。
5. memory 层批判：benchmark 自报与独立评测的矛盾
四个框架本身都不"记住"跨会话的长期记忆，于是你会去接一个 memory 层——Mem0、Letta（前 MemGPT）、Zep 是三个主流选择。但这一层的 benchmark 是 2026 年 AI 工程里最不能照单全收的数字。
先看几个被到处引用的数字：
| 来源/口径 | 系统 | LongMemEval | LOCOMO | 备注 |
|---|---|---|---|---|
| 自报（Mem0 官方研究，2026-06） | Mem0 | 94.4 | 92.5 | ~6.8k token/查询，vendor 自评 |
| 独立横评（fountaincity，2026-05） | Zep | 63.8 | — | "最强温度查询"口径 |
| 独立横评（fountaincity，2026-05） | Mem0 | 49.0 | 66.9 | 同一篇横评里 Mem0 反而低 |
| ECAI 2025 论文复算（fountaincity，2026-05） | Mem0g（图增强） | — | 68.4 | full-context 基线 72.9 |
| Zep 自报 → 独立纠错（getzep issue #5） | Zep | — | 84% → 58.44% | 纠错后掉 25.56 个百分点 |
矛盾点非常刺眼：
-
同一系统、同一 benchmark，自报 94.4 vs 独立横评 49.0（Mem0 在 LongMemEval 上）。差距不是几个点，是接近一倍。原因是 vendor 自评时"自己出题、自己选对手、自己调 prompt"——fountaincity（2026-05）直说"Mem0 publishes both the benchmark and the comparators, so absolute numbers are vendor-favorable"。
-
Zep 的 84% 是错的。Mem0 在 getzep/zep-papers issue #5 里复算指出三点：(a) Zep 把被显式排除的 adversarial 类问题算进分子却不算进分母，凭空抬高 ~25.56 个百分点；(b) 改了 system_prompt 和检索 TEMPLATE，且只跑单次而非 10 次取均值带标准差；(c) 标准化条件下，Zep 旧算法是 65.99% ± 0.16，新算法反而 58.44% ± 0.20——新版还退步了。
-
benchmark 本身易过拟合。fountaincity 引 Cloudflare 的话："LOCOMO 和 LongMemEval 有用但容易 overfit，分数只能当方向性参考。"
架构师该怎么用这些数字？ 我的结论是三条：
- 绝对值一律打折，只看"同一篇独立横评里的相对排序"，且要求方法学可复现（10 次取均值 + 标准差 + 公开纠错代码）。
- 按任务类型选，不按总分选：要"什么时候为真"的时序/temporal 查询，Zep 的时序知识图谱确有优势；要低延迟、低 token 的检索，Mem0 更轻；要"有状态 agent + 学术可信"，Letta（13k+ stars，前 MemGPT）更合适做长期记忆体的可控载体。
- 自己拿 golden 复测。把对账 agent 的 120 条 golden 接上 memory 层，测"跨工单是否记得同一对手方的历史口径差异"，这个业务化指标比 LongMemEval 总分有意义得多。
一句话：memory benchmark 的数字战争，本质是 vendor marketing，不是科学结论。架构师的职责是把它降级为"待验证假设"，而不是"选型依据"。
6. 选型决策框架：主栈 TS → AI SDK 6 为什么是我的默认首选
把前面所有维度收敛成一棵可操作的决策树（针对金融 long-horizon agent）：
1. 流程是否跨会话/跨天、且需要"任意时刻可恢复+可审计"？
├─ 是 → 强 durable 需求 → LangGraph 1.0（内建 checkpoint，人审 interrupt）
└─ 否 ↓
2. agent 是否需要"真去执行代码/脚本"（动态 SQL、交叉核对）？
├─ 是 → OpenAI Agents SDK（sandbox + code mode 独一档，但接受 Python 一等/OpenAI 绑定）
└─ 否 ↓
3. 是否重度 Claude 栈、且上下文极长（compaction 价值大）？
├─ 是 → Claude Agent SDK（+ Managed Agents 换 durable 省心）
└─ 否 ↓
4. 默认：主力是 TypeScript / Next.js、需要前端深度集成 → Vercel AI SDK 6
为什么"主栈 TS → AI SDK 6 首选"对我（和很多 web 团队）成立？ 四条理由：
-
语言对齐零摩擦。momoweb3 与我大量前端项目就是 TS/Next.js，AI SDK 6 的 Agent 与
useChat、streaming UI、Zod schema 是同一套类型系统，没有 Python↔TS 的进程边界。OpenAI 的 sandbox/code mode 虽强，但 TS 一等支持滞后于 Python（2026-04 起才补），对 TS 团队是减分。 -
抽象克制 = 迁移成本低。AI SDK 6 不强加 graph 心智模型，多 provider 可换，供应商锁定风险最低。我可以今天用 Claude，明天换别的模型，编排层几乎不动。LangGraph 的 graph 概念虽强，但对"单会话 + 前端集成"是过度工程。
-
durable 这块的缺口可补、且常常不必补。对账 agent 里真正"跨天"的只有"等对手方回函"这一步——我用一个轻量状态表 + 事件回调就能补上，没必要为这一步引入 LangGraph 的全套 graph runtime。用最小的额外复杂度补最关键的那一处缺口，是架构经济性的核心。
-
可观测开箱。AI SDK 6 的 DevTools 能看 step/input/output/token/timing/raw provider req，对调试金融归因链够用；合规审计再叠一层自有 trace 即可。
反过来什么时候我会放弃 AI SDK 6？ 当"跨天 durable + 多天人审 + 任意时刻可审计恢复"成为硬合规要求时——那一刻 LangGraph 1.0 的内建 checkpoint 价值远超语言摩擦的代价，我会果断切换，哪怕团队要补 Python 技能。选型是约束的函数，约束变了，结论就该变。
7. 结语
同一个对账异常调查 agent，放在四个框架上，能力上限趋同（因为模型和 prompt 共享），差异全在编排层的工程经济性：AI SDK 6 赢在 TS 原生与上手成本，LangGraph 1.0 赢在 durable 与人审，OpenAI 赢在 sandbox 执行，Claude Agent SDK 赢在长上下文 harness。memory 层的 benchmark 战争则提醒我们：vendor 自报数字（Mem0 自评 94.4）与独立横评（49.0/63.8）能差近一倍，架构师必须把它降级为待验证假设，用自己的 golden 复测。
最大的 takeaway 不是"选哪个"，而是"用一个固定的业务 golden + 固定 eval，把候选框架放在同一张台子上称重"——这套方法本身比任何一次结论都更耐用，因为框架每个季度都在变，而"怎么称重"不变。
SOTA 检查 (2026-06-11 更新)
- Vercel AI SDK 6：2025-12-22 发布，Agent 一等抽象 + ToolLoopAgent + needsApproval 人审 + DevTools + 稳定
@ai-sdk/mcp，是当前 TS 栈 agent 编排 SOTA。仍是主线，无更新替代。 - LangGraph 1.0：2025-10-22 GA，durable execution / checkpoint / interrupt 人审为内建，长流程 SOTA。1.x 持续小版本迭代，无 breaking change。
- OpenAI Agents SDK：2026-04-15 公布新 harness + sandbox + code mode，PyPI
openai-agents0.17.x（2026-05 前后）为当前线；TS 一等支持仍在补齐中，关注后续 code mode/subagents 落地。 - Claude Agent SDK：2026-06 文档/Managed Agents 形态完善，强调 context compaction 与长流程 harness；durable 仍需外置或用 Managed Agents。
- Memory 层：Mem0 自报 LongMemEval 94.4 / LOCOMO 92.5（2026-06，vendor 自评）；独立横评（fountaincity，2026-05）给出 Zep 63.8 / Mem0 49.0（LongMemEval）、Mem0 66.9（LOCOMO）；Zep LOCOMO "84%" 已被纠正为 58.44%（getzep/zep-papers issue #5）。结论：benchmark 绝对值不可信，按任务类型 + 自有 golden 复测选型。
- 下次复查触发条件：OpenAI Agents SDK TS 一等支持 GA、AI SDK 7 公布、或出现独立第三方（非 vendor）memory benchmark 复现报告时，需重写第 3.3、第 5 节。
参考资料（按发布日期）
- Vercel, "AI SDK 6"（官方博客，2025-12）— Agent 抽象 / ToolLoopAgent / needsApproval / DevTools /
@ai-sdk/mcp - LangChain, "LangGraph 1.0 is now generally available"（changelog，2025-10）— durable state / checkpoint / interrupt HITL / 无 breaking change
- OpenAI, "The next evolution of the Agents SDK"（官方，2026-04）+ TechCrunch 报道（2026-04）— model-native harness / sandbox / code mode / TS 跟进
- OpenAI Agents SDK release notes（PyPI
openai-agents0.17.x，2026-05）— gpt-realtime-2 默认 / sandbox 源物化路径授权 - Claude Agent SDK overview（Claude Code Docs，2026-06）+ Claude Managed Agents overview — harness / compaction / session resumption / durable 外置
- Mem0, "State of AI Agent Memory 2026"（2026-06）— Mem0 自报 LOCOMO 92.5 / LongMemEval 94.4
- fountaincity.tech, "Agent Memory & Knowledge Systems Compared (2026 Guide)"（2026-05）— Zep 63.8 / Mem0 49.0（LongMemEval）、Mem0 66.9 / Mem0g 68.4（LOCOMO）
- getzep/zep-papers Issue #5, "Revisiting Zep's 84% LoCoMo Claim"（2026）— 84% → 58.44% 纠错与方法学争议