长文#3 定稿 — 四框架 trade-off：同一桩 AML 调查，谁来编排？

日期: 2026-08-15 阶段: Phase 2 - AI-native 参考架构 标签: #longform #agent-frameworks #langgraph-temporal #framework-selection

核心问题

长文#3 不是「框架综述」，而是把一个具体 AML 任务丢给四个框架，从架构师视角看它们各自怎么塌、怎么扛——并钉死本项目的主栈选择与理由。

具体任务(贯穿全文的试金石)：「一桩疑似 layering 的多步调查」——系统收到告警 → 拉取该地址 90 天链上流水(可能调 5-10 次外部 API，每次秒级，偶尔超时) → LLM 推理判断是否符合 layering 类型学 → 若是，起草 SAR 叙事 → 人工合规官审核(可能挂起数小时甚至跨天) → 通过后提交。

这桩任务把所有框架选型的张力压在一起：(1) 长时运行(人工审核跨天)；(2) 强副作用(外部 API 调用、最终提交不可重复)；(3) 不可预测的推理循环(LLM 决定还要不要拉更多数据)；(4) 崩溃不可接受(worker 宕机不能丢掉半桩调查)；(5) 人在环(合规强制)。

四个候选：LangGraph 1.0、OpenAI Agents SDK、Microsoft Agent Framework 1.0、Vercel AI SDK 6。外加一个"第五者"——Temporal(durable execution 运行时)。本文的反直觉结论是：这五者不是互斥的"选一个"，最优解是分层组合。

关键内容

A. 同一 AML 任务下四框架的架构师视角对比

不看 GitHub star，看这桩任务的五个张力各框架怎么应对：

① LangGraph 1.0(2025-10 首个稳定版，Python) 把 agent 工作流建模为显式 state machine(节点+边)，内置 checkpointing/durable execution——每步状态存到持久 store，中断后可从最后记录点恢复(LangChain docs 2026)。Uber/Klarna/LinkedIn/JPMorgan 等 400+ 公司生产在用(speakeasy 2026)。

• 扛：张力③(不可预测推理循环)——图天然表达「LLM 决定回到拉数据节点还是进 SAR 节点」的环。
• 塌：张力①(跨天人工审核)——LangGraph 自己的 checkpoint 适合分钟级;节点跑超过几分钟就有可靠性风险(agentmarketcap 2026-04)，跨天挂起不是它的甜区。p95 在并发负载下达 16,891ms，单进程内存 150-250MB(同源)。

② OpenAI Agents SDK(2025-03 发布，2026-05 更新，Python) 轻量多 agent 框架，重点是 tool loop + tracing + guardrails，26.9K star、月下载 1030 万(speakeasy 2026)。

• 扛：张力③的简单形态——单 agent tool 循环极简上手。Temporal × OpenAI Agents SDK 已 GA(2026-03，Codex 在用)，可补 durability。
• 塌：张力①④——本体是「简单 tool 循环」，跨天、崩溃恢复、Saga 补偿都不在其原生范围;复杂多步调查的状态机表达力弱于 LangGraph。绑 OpenAI 模型生态最顺。

③ Microsoft Agent Framework 1.0(2026-04-03 GA，.NET + Python) AutoGen + Semantic Kernel 的统一后继——SK 作基础层(kernel/plugin/connector 不变)，上面重建 AutoGen 的图式多 agent 编排引擎;AutoGen 与 SK 双双进维护模式(只修 bug 不加新特性)(VentureBeat / cloudsummit 2026)。LTS 承诺、稳定版本化 API。

• 扛：张力④——企业级治理、稳定 API、长期支持;.NET/Azure 团队的唯一正经选项。
• 塌：对本项目是生态错配——本仓是 TS 主栈(Next.js)，引入 .NET/Python Agent Framework 等于跨语言运行时，运维与本仓 src/agent/ 现有 TS 代码割裂。技术不差，契合度差。

④ Vercel AI SDK 6(2025-12，TypeScript) v6 把 Agent 提升为一等抽象(Agent 类 + ToolLoopAgent)，统一 25+ provider(OpenAI/Anthropic/Bedrock/Azure...)，流式 web UI 最强(speakeasy 2026)。

• 扛：张力③(tool loop)+ 本仓生态——TS-native，与 Next.js / 现有 src/agent/ 无缝;统一 provider 接口契合 Day 后续的 gateway 策略;流式 UI 直接喂 /agent-lab trace 面板。
• 塌：张力①④——v6 的 Agent 抽象是推理循环级，不是 durable workflow 引擎;跨天人工审核、崩溃恢复、Saga 补偿需外接(如 Inngest / Temporal)。

反直觉洞察①(语言先于能力,砍掉一半选项)：架构师的第一刀不是「谁功能最全」，而是**「我们是什么栈」**。speakeasy(2026)直言「语言选择消掉一半选项」——TS 团队实际只在 Vercel AI SDK / Mastra 之间选，Python 团队在 LangGraph/OpenAI SDK 等之间选，.NET 只有 Microsoft Agent Framework。本仓是 TS(Next.js)主栈，Microsoft Agent Framework 哪怕企业治理最强也直接出局——不是它差，是引入它要养一个跨语言运行时，这个隐性运维成本远超它带来的治理收益。最强的框架 ≠ 最该选的框架。

B. 选型决策框架：先分层，再选每层的工具

本文的核心方法论：别问「选哪个框架」，先问「这桩任务有几个编排层」。AML 调查任务天然两层：

• 宏观层(macro)：整桩调查的 durable 生命周期——拉数据(重试)、跨天人工审核挂起、最终提交(Saga 补偿:若提交失败要回滚前置副作用)。这一层要的是 durability，不是推理灵活性。
• 微观层(micro)：单个 LLM 步骤内的推理循环——「证据够不够、要不要再拉一次链上数据、判 layering 还是放行」。这一层要的是动态控制流，不是 durability。

2026 的分层共识(agentmarketcap / kinde / cordum 2026-04)：Temporal 管宏观工作流，LangGraph(或等价 reasoning 引擎)管微观推理循环。Temporal activity 里 spin up 一个 reasoning agent 处理推理子任务，返回结果，Temporal workflow 再决定下一步。

Temporal Workflow (宏观, durable, 跨天/跨崩溃存活)
  │
  ├─ activity: fetchChainData(addr, 90d)   ← 自动重试,幂等
  │
  ├─ activity: runLayeringReasoning(evidence)
  │     └──► [micro] reasoning agent 的 tool 循环:
  │            判证据是否够 → 不够则请求再拉 → 够则产出判定
  │            (本仓 TS 栈用 Vercel AI SDK 6 的 Agent/ToolLoopAgent)
  │
  ├─ activity: draftSAR(finding)
  │
  ├─ ◄── 人工审核挂起 (Temporal 信号等待,可跨天,worker 重启不丢)
  │
  └─ activity: submitSAR(approved)   ← Saga: 失败则补偿(撤销/告警)

决策框架的判据表(把 A 节的「扛/塌」收敛成可执行规则)：

判据来自 agentmarketcap(2026-04-08)的 LangGraph vs Temporal 决策表：Temporal 赢在「workflows run for hours or days」「business operations depend on completion(financial/compliance)」「worker crash 丢工作不可接受」——AML 三条全中。

反直觉洞察②(durability 与推理灵活性是两个正交问题,别用一个框架硬扛)：常见错误是「LangGraph 也有 checkpointing，那就全用 LangGraph，不要 Temporal」。但 LangGraph 的 checkpoint 是为推理循环恢复设计的，不是为「跨天人工挂起 + Saga 补偿 + 外部查在途状态」设计的——硬用它扛宏观 durability，会在节点跑超过几分钟时撞可靠性风险。「都有 durable execution 这个词」不等于「解决同一个问题」:LangGraph 的 durable 是 step 级恢复，Temporal 的 durable 是业务级保证完成 + 补偿。把推理框架当工作流引擎用，是 2026 最常见的过度集中化踩坑。

C. 本项目主栈选择与理由

结论:Vercel AI SDK 6(micro 推理层) + Temporal(macro durable 层)，不选单一框架包打天下。逐条理由:

1. TS 生态契合(决定性)：本仓 Next.js + src/agent/ 全 TS。Vercel AI SDK 6 是 TS 主栈生产首选(2025-12，Agent 一等抽象)，与现有代码、/agent-lab 流式 trace 面板零摩擦。LangGraph(Python)虽生产最成熟，但引入 = 跨语言;Microsoft Agent Framework(.NET/Py)同理出局。
2. AML 任务确实是长时 + 强副作用 + 人在环——B 节判据表 Temporal 三条全中，micro 层 durability 不够用，必须有 macro 层。Temporal × OpenAI Agents SDK 已 GA(2026-03)证明这套分层在生产可行;Temporal 对 micro 层框架不挑(activity 里调什么都行)。
3. 统一 provider 接口接 gateway：Vercel AI SDK 6 统一 25+ provider，天然契合后续 AI gateway(LiteLLM/语义缓存)的多模型路由——micro 层换模型不改编排代码。
4. 可降级路径：若未来某子任务推理拓扑复杂到 Vercel Agent 表达不下(多 agent 动态路由)，可在该 Temporal activity 内局部换 Mastra(TS-native，durable workflow + HITL 原语)，不影响 macro 层——分层架构的好处正是局部可替换。

设计要点/决策表

对本项目的落地

• 新建 ADR 入仓：本长文的决策写为 docs/aipa/adr/ADR-1-agent-framework.md(对应 P2 交付件 ADR#1)，记录「micro=Vercel AI SDK 6 + macro=Temporal」及四框架出局理由，供作品集展示「架构师怎么选型」而非「试了哪个 SDK」。
• 编排切口：P2 拟在 src/aml/orchestration/ 下新增 investigationWorkflow.ts(Temporal workflow 定义，宏观:拉数据→推理→起草→人工挂起→提交+Saga)与 layeringReasoningAgent.ts(Vercel AI SDK 6 Agent，微观 tool 循环)。现有 src/agent/orchestrator/orchestratorAgent.ts(Lead-Subagent + Budget)是单进程编排原型，演进为「Temporal activity 内运行的 reasoning agent」——把 Budget 逻辑搬进 activity，把生命周期交给 Temporal。
• 人在环对接：合规官审核用 Temporal signal 实现可跨天挂起;现有 src/components/aml/ 的 SAR 审核屏(Day 5 HITL UX)发出 approve/reject 信号到在途 workflow——HITL UI 已有，P2 接 Temporal signal API。
• trace 复用：Vercel AI SDK 6 的流式输出喂 src/agent/trace/useTraceStore.ts;Temporal 的 workflow history 与 step/toolCall 结构(Day 8/26)互补——macro 层的 activity 边界天然映射 trace 的 step。
• 诚实标注：ADR 头注明确本选型为 P2 架构决策;investigationWorkflow.ts/layeringReasoningAgent.ts 在 P3 接真实 LLM + Temporal 集群后落地;框架版本号(Vercel AI SDK 6 / Temporal TS SDK)在实现当周重新确认。

参考资料

1. speakeasy — Choosing an agent framework: LangChain vs LangGraph vs CrewAI vs PydanticAI vs Mastra vs Vercel AI SDK(2026):语言选择消掉一半选项;LangGraph 400+ 公司生产(Uber/Klarna/LinkedIn/JPMorgan);OpenAI Agents SDK 26.9K star/月下载 1030 万;Vercel AI SDK 6 Agent 类/ToolLoopAgent/25+ provider;Mastra TS de facto
2. agentmarketcap — LangGraph vs. Temporal for Long-Running Agent Workflows: 2026 Decision Guide(2026-04-08):决策判据(分钟 vs 小时/天、副作用、崩溃容忍、在途查询);两层模式(Temporal 宏观 + LangGraph 微观);LangGraph p95 16,891ms、内存 150-250MB/进程;Temporal 赢在 financial/compliance 完成保证
3. VentureBeat / cloudsummit.eu — Microsoft retires AutoGen and debuts Agent Framework / production-ready convergence(2026):MS Agent Framework 1.0 GA 2026-04-03;AutoGen+SK 进维护模式;SK 作基础层、上建 AutoGen 图式编排;LTS + 稳定 API
4. LangChain Docs — Durable Execution(2026):LangGraph 内置持久层,step 级状态存储,中断可从最后记录点恢复
5. Temporal — Prototype to production-ready agentic AI(Grid Dynamics) / Temporal × OpenAI Agents SDK GA(2026-03):durable execution 运行时,Saga 补偿,跨基础设施事件状态持久;Codex 在用
6. 本仓物证:src/agent/orchestrator/orchestratorAgent.ts(单进程 Lead-Subagent 原型)、src/agent/trace/useTraceStore.ts、src/components/aml/(HITL 审核屏)(2026-06)

SOTA 检查 (2026-08-15)

注:本笔记日历日为 2026-08-15;事实核查与一手原文检索在 2026-06-11 完成,实现当周需按下方待跟踪项重新确认框架版本。

• 四框架格局 2026 年中清晰且按语言分层:speakeasy/firecrawl/strapi 多源一致——TS(Vercel AI SDK 6 / Mastra)、Python(LangGraph / OpenAI SDK / PydanticAI)、.NET(MS Agent Framework)。「语言先于能力」选型法是当前主流,未被替代。
• Temporal+reasoning 框架分层是 2026 mission-critical 共识:agentmarketcap/kinde/cordum/appscale 多源确认「macro=Temporal,micro=reasoning 引擎」;Temporal × OpenAI Agents SDK GA(2026-03)是该模式的官方背书。本文用 Vercel AI SDK 6 替换 micro 层(因 TS 栈)符合此模式精神。
• MS Agent Framework 是新合并体,引用须用 1.0(2026-04-03)而非 AutoGen/SK:AutoGen 与 SK 已进维护模式,新集成不应基于二者——这是本日的过时认知警示之一。
• 过时认知警示:(1) 不可把 LangGraph checkpoint 等同 Temporal 业务级 durable(正交问题);(2) 不可基于 AutoGen 做新集成(维护模式);(3) Vercel AI SDK 须用 v6(2025-12,Agent 一等抽象),v4/v5 无原生 Agent 抽象。
• 待跟踪(实现当周必做):重新确认 Vercel AI SDK 6 与 Temporal TS SDK 的当周版本号;复查 Temporal 是否出 TS-native agent 模板降低集成成本;若本项目某子任务推理拓扑复杂,评估 Mastra(TS durable workflow + HITL)作为 micro 层替代,回填决策表。