无框架智能体六栈实测与抽象税

2026年的Agent工程圈正在经历一场静默的"去框架化"运动。一家金融科技团队把基于LangChain的文档处理Agent，用200行裸Anthropic SDK重写后，响应时间从4.2秒降到2.5秒——整整40%的延迟被一个抽象层默默吃掉了。这不是孤例。当模型原生的function calling、tool use、多步推理已经把2022年LangChain要解决的问题在API层面解决掉之后，"框架到底是资产还是税"成了每个生产Agent团队必须回答的问题。

但硬币的另一面同样残酷：另一家医疗创业公司在模型小版本升级时花了400+工程小时恢复功能对等，因为新模型token输出涨了5倍、把JSON包进了markdown代码块、还自作主张给出诊断意见。这就是"供应商抽象税"——不是换框架的成本，而是不为此做规划的持续流血。

本期对六种Agent构建栈做实测拆解：裸Anthropic SDK、裸OpenAI Responses API、OpenAI Agents SDK、Claude Agent SDK、LangGraph、CrewAI，外加LangChain作为对照基准。核心结论先行：框架的价值不在编排，而在状态持久化、调试可见性和供应商隔离这三件裸代码写起来极其昂贵的事；只要你的Agent进入多步、有状态、需回放的生产形态，完全无框架几乎一定是亏的。

六栈核心维度对比

深度分析

一、抽象税的真相：LangChain为何被"毕业"

LangChain诞生于2022年底，那个时代模型不能可靠地调用函数，prompt链需要手工拼装，上下文管理是一门玄学。框架用可组合的抽象包装LLM调用，解决了真实而痛苦的工程问题。但到2025年，这些问题已经被模型自身解决了：OpenAI的function calling原生处理结构化工具调用，Anthropic的Claude把多步推理和工具使用直接烤进API契约。两家供应商的SDK都干净、文档完善、积极维护。

维度	裸Anthropic SDK	裸OpenAI Responses	OpenAI Agents SDK	Claude Agent SDK	LangGraph	CrewAI	LangChain(对照)
抽象税(延迟)	0	0	极低	极低	低(图编译)	中	最高
状态/检查点	自行实现	自行实现	内置	内置	一等公民	内置	弱
调试/时间旅行	无	无	Tracing	Tracing	Studio+回放	Tracing	LangSmith(外挂)
多Agent/Handoff	手写	手写	一等公民	一等公民	图节点	一等公民	弱
供应商锁定	单家	单家	OpenAI	Anthropic	多家	多家	多家
上手时长	30分钟	30分钟	1小时	1小时	半天	2小时	1小时
最适场景	单步高频	单步高频	OpenAI生态	Claude生态	复杂状态流	角色协作	已废弃

然而LangChain的链优先(chain-first)架构设计，仍把这些早已不存在的限制当作前提继承了下去。基准对比中，在相同的数据分析任务上，LangChain消耗的token和墙钟时间是所有受测框架里最多的。它的设计意味着每一步都要求LLM解释自然语言输入并选择工具，哪怕工具选择是确定性的。对于一个五步流水线，这种开销会复利累积：每一次不必要的LLM调用增加数百毫秒和一笔可观的token开销。

反观同门的LangGraph：它把任务定义成有向无环图(DAG)，每一步执行的工具是预先确定的——LLM只在真正模糊的决策点介入。在基准中，LangGraph是所有图类框架里延迟最低的。教训很清楚：开销并非编排所固有，而是LangChain特定设计选择所固有。这就是"毕业"现象的根因。

# 裸Anthropic SDK：一个完整研究Agent，约25行
import anthropic, json

client = anthropic.Anthropic()

def run_agent(user_msg: str, max_turns: int = 10) -> str:
    messages = [{"role": "user", "content": user_msg}]
    for _ in range(max_turns):
        resp = client.messages.create(
            model="claude-opus-4-8",
            max_tokens=4096,
            tools=TOOLS,                       # 直接声明，无包装
            system="你是研究助手，必要时调用工具。",
            messages=messages,
        )
        messages.append({"role": "assistant", "content": resp.content})
        if resp.stop_reason != "tool_use":      # 终止判定在API层
            return resp.content[-1].text
        # 执行工具，结果原样回灌——无中间抽象层
        tool_results = [{"type": "tool_result",
                         "tool_use_id": b.id,
                         "content": dispatch(b)} for b in resp.content if b.type=="tool_use"]
        messages.append({"role": "user", "content": tool_results})
    return "达到最大轮次"

二、裸SDK极简循环：调试可见性的赤字

无框架版不只是更快——它更容易推理、更容易调试、远更容易定制。一位把生产客服Agent迁移走的工程师总结道："我花了三天调试一个LangChain Agent，它悄悄截断工具输出。用裸SDK调用，我一小时就能抓到这个bug，因为我的代码和API之间没有任何东西。"

这段话点出了无框架的核心红利：透明的数据流。在裸实现里，整个Agent就是一个循环——带着system prompt调用模型、解析响应里的工具调用、执行工具、把结果追加到消息数组、重复直到完成。没有AgentExecutor、没有ToolRegistry、没有嵌套类层级。但也正是这里藏着无框架的赤字：你失去了框架免费送的那层调试基础设施。

LangGraph Studio能可视化状态图、实时编辑state、做时间旅行回放；OpenAI Agents SDK自带Tracing，把每一次工具调用、handoff、guardrail判定都结构化成span；CrewAI内置tracing把多Agent协作链路串成树。裸SDK里，你能依赖的只有print和日志。对于一次性脚本或高频单步调用，这不是问题。但当Agent开始跨窗口、跨会话、跨多小时运行时，"上次第7步为什么走错了分支"这种问题，在没有检查点的情况下几乎无法事后还原。

三、OpenAI Agents SDK：折中地带的赢家

OpenAI官方显然读懂了这个矛盾，于是Agents SDK走了一条"极薄但有形"的路线。它的核心抽象只有四个：Agent(带指令和工具的角色)、Handoff(一个Agent把控制权交给另一个)、Guardrail(输入/输出的安全校验)、Tracing(内建可观测)。没有LangChain式的链嵌套，也没有CrewAI式的重型编排引擎。

Handoff是这个SDK真正解决了一个裸代码写起来很啰嗦的问题：动态路由。当研究Agent判断"这个问题需要代码执行专家"时，它不用你手写一套router逻辑，直接声明handoff，SDK处理上下文传递和会话延续。基准测试里，OpenAI Agents SDK在"OpenAI生态内、2-5个Agent协作"这个区间，是延迟和心智负担的最优解。

from agents import Agent, Runner, handoff

triage = Agent(name="分诊", instructions="判断问题类型，转交专家",
               handoffs=[research_agent, code_agent])
result = Runner.run_sync(triage, "帮我把这段代码的性能分析一下")

代价是供应商锁定：Agents SDK深度绑定OpenAI的模型和Responses API。一旦你想换成Claude或Gemini，handoff和guardrail的语义并不完全可移植。这就是为什么裸SDK仍然有市场——当你把可移植性看得比便利性重时，那层薄抽象也是税。

四、LangGraph的图编译突围

LangGraph能从LangChain的沉重遗产里翻身，靠的是把"链"换成"图"这个根本性的转变。在链模型里，每一步都是一个LLM决策；在图模型里，节点之间的边可以是确定性的，LLM只在标注为"条件"的边上介入。这等价于把Agent从"解释执行"升级成"编译执行"——图的拓扑在运行前就确定了。

这是图编译的核心红利：可预测的延迟和确定性的工具路由。基准显示LangGraph是图类框架里最快的，正是因为它最小化了不必要的LLM调用。但LangGraph真正的杀手锏不是速度，而是它把状态(checkpoint)做成了一等公民：每一个节点的输出都被持久化，你可以从任意检查点重放(replay)、分叉(branch)出一条替代历史、甚至回滚到某个状态点修改后重跑。

对于需要人在回路(HITL)、长程任务可恢复、或要做A/B对比的Agent分支策略，这套能力几乎只能靠LangGraph或同等重型框架提供。裸SDK要做到同样的事，你得自己实现检查点存储、状态序列化、版本兼容——这是数周的工程量，且极易在生产里塌方。这就是"完全无框架几乎一定亏"的硬证据所在。

五、供应商抽象税：最隐蔽的债

前面讲的都是"框架税"，但还有一笔更隐蔽的债——供应商抽象税。它不是切换供应商的迁移成本，而是不为切换做规划的累计成本。前面那家医疗创业公司的案例是教科书式的：同一家供应商、只是模型小版本升级，结果400+工程小时才恢复功能对等，因为新模型token输出涨了5倍(吃掉所有预估的成本节约)、开始主动给出诊断意见(合规责任)、并把JSON包进markdown代码块(打挂所有下游解析器)。

表面层的供应商不兼容是真实但可航行的：OpenAI把system指令放在messages数组里，Anthropic要求它作为顶层system字段；OpenAI把工具调用参数作为需要JSON.parse的字符串返回，Anthropic返回预解析对象；Gemini用response_schema而非任何类似工具schema的约定。这些差异花一个下午映射、一周规范化就能搞定。

更深的税是行为税。量化prompt敏感性的研究发现，仅格式变化(空格、指令顺序、一个词)就能造成高达76个准确率点的摆动；GPT-3.5在代码翻译任务上跨prompt模板有高达40%的性能方差。实际含义是：一个为Claude精心调了几周的prompt，原封不动喂给GPT-4，可能产出可测量地更差的结果——不是灾难性地差，而是悄悄地差，那种能通过自动化eval(因为eval也是按原模型输出风格调的)的差。

graph TD
    A["需求:生产Agent"] --> B{"单步高频<br/>无状态?"}
    B -->|是| C["裸SDK<br/>延迟最低 抽象税0"]
    B -->|否| D{"2-5个Agent<br/>单供应商?"}
    D -->|是| E["OpenAI Agents SDK<br/>或Claude Agent SDK"]
    D -->|否| F{"复杂状态流<br/>需回放/分支?"}
    F -->|是| G["LangGraph<br/>检查点+时间旅行"]
    F -->|否| H{"角色化多Agent<br/>协作?"}
    H -->|是| I["CrewAI"]
    H -->|否| J["混合栈:裸SDK内核<br/>+轻量编排层"]
    C --> K{"是否多供应商<br/>可移植?"}
    K -->|是| L["+ LiteLLM抽象层<br/>承担行为税监控"]
    K -->|否| M["直连供应商SDK"]

六、级联失效：Agent链里的复利方差

在agentic流水线里，这种方差会复利累积。一个显示97%通过率的单轮评估，当同一个模型跑在五步链式调用上时变成完全不同的问题：那3%的失败案例不会保持孤立，它们会级联。团队在模型升级后跑回归测试，常常发现聚合失败率不是3%，而是远高于此——因为第一步的微小漂移，到第五步被放大成完全不同的轨迹。

这正是"裸SDK+单供应商"路线最危险的地方：它把抽象税降到了零，却也把行为风险全部裸露。框架(尤其是LangGraph这类带评估回放的)能在某种程度上缓冲这种风险，因为你可以把升级前的检查点轨迹和升级后跑同一输入的轨迹做diff，直观看到哪一步开始漂移。裸SDK里，除非你自己搭了等价的基础设施，否则行为税是在暗处复利增长的。

实务上的红线很清晰：任何超过3步、跨session、或承载真实业务后果的Agent，都不应该纯裸SDK运行。这跟"用不用框架"无关，跟"你有没有检查点和轨迹diff能力"有关——只是恰好这两样框架几乎免费提供，而裸写极其昂贵。

七、状态管理与持久化：框架的真正护城河

把六栈放在一起看，真正能把它们拉开档次的能力，不是"谁支持多Agent"，而是"谁的状态模型经得起生产考验"。裸SDK和OpenAI Responses API把状态完全留给你：消息数组就是状态，进程崩了就全没了。OpenAI Agents SDK和Claude Agent SDK内置了基础会话状态。CrewAI把crew的执行历史结构化。LangGraph则把检查点、时间旅行、人在回路中断恢复做成了文档完善的一等公民。

差异在"长程Agent"场景下被放大到极致：一个跨几小时、需要中途暂停让人审批、审批后继续的Agent，在裸SDK里需要你自己实现状态序列化、存储后端、版本迁移、并发锁——每一个都是独立的工程陷阱。在LangGraph里这是interrupt()和Command(resume=...)几行配置。

这就是框架抽象税的"对价"：你为它付出的延迟和心智成本，换回来的是状态持久化和恢复能力。对一个跑完即丢的脚本，这笔交易亏；对一个承载真实业务、不能容忍"重跑两小时"的Agent，这笔交易赚。判断标准只有一个：你的Agent如果在中途崩溃，重跑的成本是否可接受。不可接受，就用框架；可接受，裸SDK的延迟红利是真实的。

八、选型决策：把抽象放在对的层

六栈实测下来，2026年的成熟做法不是"选一个框架"，而是分层抽象：核心Agent循环用裸SDK写(拿到延迟红利和透明调试)，外面包一层薄编排(解决handoff和状态)，再在供应商边界放一个抽象层(LiteLLM或自写adapter)承担行为税的监控。O'Reilly《The AI Agents Stack (2026 Edition)》把生产Agent分成六层(LLM、SDK、编排、记忆、评估、部署)，每一层都可以独立做"裸/框架"的选择，这才是比"用不用LangChain"更对的问题。

Anthropic工程团队的建议可以直接当结论引用："先用LLM API直接调用——许多模式几行代码就能实现。"NVIDIA首席工程师岗位也明确要求候选人能"快速原型"并理解底层原理。这意味着：无框架不是反智退步，而是工程成熟度的标志——只有理解了框架在替你做什么，才能判断哪一层的抽象值得付费、哪一层是纯粹的延迟税。

推荐方案

场景	推荐栈	理由
单步高频调用(分类/抽取/翻译)	裸Anthropic/OpenAI SDK	零抽象税，延迟最优，调试透明
OpenAI生态内2-5 Agent协作	OpenAI Agents SDK	Handoff+Tracing解决动态路由，锁定可接受
Claude生态内工具密集Agent	Claude Agent SDK	原生tool use契约，tracing内建
复杂状态流/需回放/HITL	LangGraph	检查点和时间旅行是裸写的数周工程量
角色化多Agent研究/内容生产	CrewAI	Role-based抽象贴合这类语义
跨供应商可移植/规避锁定	裸SDK + LiteLLM	显式承担行为税，监控prompt方差
已有LangChain遗留	迁移到LangGraph或裸SDK	链优先架构的抽象税在生产不可接受

一句话决策红线：Agent是否需要"中途崩溃后不能重跑"或"事后回放某一步"——是，用LangGraph或同等带检查点的框架；否，裸SDK或薄SDK层(Agents SDK/Claude Agent SDK)是延迟和可控性的最优解。把抽象放在对的层，比纠结"用不用框架"重要十倍。