三个 Agent 框架，我用同一个项目各实现了一遍

三个 Agent 框架我用同一个项目各实现了一遍为什么做这个事情从 GPT-3.5 开始我们见证了 AI 这几年的发展Agent 已经成为主流Agent 的编程框架也多了起来。其中 LangChain、Pydantic AI 和 eve 是我主要关注的几个。问题是一个 QuickStart 体现不出各个框架的不同。三家的入门代码长得都差不多建一个 agent、挂两个工具、跑一轮对话。照着写完之后对各个框架的理解还是不深刻、不到位。所以我想用一个小项目采用三个不同的框架各实现一遍对比它们的实现方式。三个框架的简单介绍LangChain官网https://www.langchain.com/文档https://docs.langchain.com/oss/python/langchain/overviewLangGraph 文档https://docs.langchain.com/oss/python/langgraph/overview一句话定位。LangChain v1 给自己的定位是一条公式Agent Model Harness特点。官方文档里列了四条 Core benefitsStandard model interface统一的模型接口。一套接口覆盖 chat model、embedding 等跨各家 provider。换模型只需要很小的代码改动需求演进时应用仍然是可移植的。Highly configurable harness高度可配置的 harness。从create_agent这个最小 harness 起步通过 middleware 增量地加能力——护栏、重试、路由、自定义工具策略你的场景需要什么就组合什么。Built on top of LangGraph建立在 LangGraph 之上。LangChain 的 agent 建在 LangGraph 上因此能享受 LangGraph 的持久化执行、human-in-the-loop 支持、持久化等能力。Debug with LangSmith用 LangSmith 调试。在一个地方查看 trace、工具调用、状态转换和延迟定位失败模式、评估质量、用执行数据改进 agent 行为。此外Langchain的版本迭代快** 这次用的是 v1langchain 1.3.x和网上大量 v0 教程已经对不上LangGraph 是它下面那一层。官方对它的定位是LangGraph 为任何长时间运行的有状态工作流或 agent 提供低层的支撑基础设施。LangGraph 不抽象提示词也不抽象架构。它俩最重要的区别是LangGraph 不替你决定 prompt 怎么写、agent 长什么样只给你状态、持久化和调度。这就是它和 LangChain 那层的分界——一个给你 harness一个给你地基。LangGraph 的 Core benefits官方列了六条Mix deterministic and agentic steps确定性步骤和 agent 步骤混着用。在同一张图里把手写的确定性逻辑和 LLM 驱动的决策组合起来——需要可靠和可预测的地方用确定性步骤需要灵活的地方用 agent 步骤从而对 agent 行为的每一部分都有精确控制。Persistence持久化。让 agent 扛过失败、长时间运行并从中断的地方接着跑。Human-in-the-loop人在环路中。可以在任意时刻检查和修改 agent 的状态把人的监督嵌进流程。Comprehensive memory完整的记忆。既有支撑当前推理的短期工作记忆也有跨会话的长期记忆。Debugging with LangSmith。用可视化工具追踪执行路径、捕获状态转换、提供详细的运行时指标深入看清复杂 agent 的行为。Production-ready deployment生产级部署。有为「有状态、长时间运行的工作流」这类特殊挑战设计的可伸缩基础设施。官方文档建议如果你刚接触 agent先从 LangChain 那层高级抽象开始别直接上 LangGraph。Pydantic AI官网 / 文档https://pydantic.dev/docs/ai/overview/一句话定位。它的 slogan 是GenAI Agent Framework, the Pydantic way特点官网「Why use Pydantic AI」列了十一条这里挑和这个项目直接相关的Built by the Pydantic Team。Pydantic Validation 本身被 OpenAI、Google、Anthropic 和很多主流框架用着——它是在自己最擅长的地方做 agent 框架。Fully Type-safe。支持 IDE 自动补全在写代码的时候就报错不用等运行时。output_type约束输出。用 Pydantic 模型声明 agent 必须交出什么模型交不出合格的就重来。Output Validators。官方的说法是「基于反思的自我纠正」——校验不过把理由带回给模型让它重新生成。依赖注入。通过RunContext把数据和连接传进工具类型安全。Model-agnostic。支持 OpenAI、Anthropic、Gemini、DeepSeek 等 20 多个 provider。Durable Execution。在 API 失败和应用重启之间保住进度。注意这一条是靠接外部编排实现的DBOS、Temporal 这类不是框架自带一个存储。Streamed Outputs。流式输出结构化数据边流边校验。Seamless Observability。和 Pydantic Logfire 打通追踪、调试、算成本。Powerful Evals。系统性地测试和评估 agent 的表现。多 agent 怎么组织官方分了五级从「模型说了算」一路排到「代码说了算」级别是什么下一步谁决定1单 agent模型靠 instructions 和它自己的推理2Agent delegationagent 通过工具调另一个 agent模型全程由它掌控3Programmatic agent hand-off应用代码或人决定下一个调谁代码4Graph-based control flow显式配置的图官方说是「最复杂的情况」代码5Deep Agents会规划、能操作文件、能委派任务、带沙箱执行模型和代码分担这张表值得记住因为它才是「谁决定下一步」这个问题的正确答案形状——不是「这个框架属于哪一类」而是「你选第几级」。第 5 篇会说我为什么选了第 3 级。「the Pydantic way」这句 slogan 很准确如果你在 Python 后端里习惯了拿 pydantic 定义边界这一家几乎不需要额外学习成本。它没有图也没有 DSL编排就是普通 Python要循环三轮就写for要并行就写asyncio.gather。没有丰富的封装agentAgent(model,deps_typeReviewDeps,output_typeReview,# agent 交出什么由类型声明retries3,# 校验不过重试几次构造参数)agent.output_validatordefenforce_guards(ctx,review:Review)-Review:ifproblem:check_blocker_has_harm(review.findings):raiseModelRetry(problem)# 带着反馈让模型重做returnrevieweve仓库https://github.com/vercel/eve文档https://vercel.com/docs/eve/concepts发布公告https://vercel.com/changelog/introducing-eve-an-open-source-agent-framework一句话定位。这是三家里最新的一个Vercel 在 2026 年 6 月开源。官方给自己的定位是一个 filesystem-first 的框架用来构建持久化的 AI agent。官方文档开头那句把它的世界观说得很清楚eve 把一个文件系统项目变成一个持久化的后端 AI agent。你在agent/目录下编写 agenteve 发现这些文件、校验它们、编译出一份 manifest然后把运行时作为一个可部署的应用提供出去。最核心的一条目录就是契约接线交给框架。这是它和另外两家最本质的差别也是我认为理解 eve 的关键——你不用管数据怎么传递不用管 agent 怎么调用、怎么注册。编排、工具调用、上下文在角色之间的传递全部由框架实现。你要做的只是把 tools、skills、subagents 各自写好放进对应目录框架在构建时自动发现它们、编译成一份 manifest、运行时自己去调。于是你真正关注的东西只剩下**「这个角色要做什么」**——而那件事写在 markdown 里。同一件事三家要你写的东西差别很大加一个工具数据怎么传给工具谁调用谁Pydantic AIagent.tool(read_draft)一行行注册deps_type声明RunContext取自己写for循环和gatherLangGraphtools[...]传进create_agentstate schema reducer 声明怎么合并自己连边、自己写条件跳转eve在tools/下加一个文件不用管不用管其余特点一个文件一个工具文件名就是模型看到的工具名。持久化是框架自带的。session 跑在 Vercel Workflows 上「把进度作为事件日志持久化并确定性地重放来重建状态」所以一个 session 能扛过冷启动、重新部署和长时间等待。每个 agent 都有一个 sandbox。官方描述是「隔离的、bash 风格的计算环境有自己的文件系统」框架自带的bash、read_file、write_file都指向它。skill 和 subagent 是两个东西。官方的区分是skill 给正在运行的 agent 加指令而 subagent「作为一个独立的 agent 运行有全新的对话历史和状态」。channels 是平台入口。HTTP、Slack 这些接入方式各是一个文件共用同一个 agent 运行时。可观测开箱即用。Vercel 面板里直接有 Agent Runs能看 session、turn、工具调用、推理、耗时和 token 用量不用写instrumentation.ts。模型串走 AI Gateway。部署到 Vercel 之后可以用 OIDC不用自己管各家 provider 的 key。官方列出的目录约定agent/ instructions.md 始终生效的系统提示词 agent.ts 运行时配置通过 defineAgent 指定模型等 tools/*.ts 一个文件一个类型化工具文件名就是工具名 skills/* 按需加载的流程模型只在相关时才载入 subagents/* 子 agent模型把聚焦的子任务委派给它 channels/* 平台入口比如 HTTP 和 Slack connections/* 与外部服务的类型化集成 sandbox/* agent 隔离的计算环境「接线交给框架」这件事落到代码上就是几乎没有代码。agent.ts短到出乎意料exportdefaultdefineAgent({description:编辑视角审核查事实性错误、编造的数据、跑不通的命令……,model,});一个 agent 的声明就这么多它的行为全部写在同目录的instructions.md里。工具也一样放进tools/就能用不需要在任何地方登记一笔。对于用的人来说注意力被强行拉回到**「这个角色该做什么、该怎么判断」**上——这些恰恰是最该花时间的地方。另外两点体感差异一是默认工具面。另外两家默认是空的要什么自己写eve 默认都给你bash、文件读写、glob、grep、web_fetch不需要的自己关掉。二是编排本身也可以是一个 agent。你不写编排代码而是写一份指令交给一个「主编」agent让它决定这一步该调谁。这一条官方没有直接强调但这个很重要。一句话对照读完官方文档有一件事得先纠正——我一开始也想当然了三家的默认其实都是「模型决定下一步」。这很自然因为 agent 框架的出发点就是「把决策交给模型」。LangChain 的create_agent、Pydantic AI 的前两级、eve 的主编 agent都是模型看着 prompt 自己判断这一步该干什么。真正的差别在于当你想把决定权收回到代码手里时各自要付出什么。框架给的编排方式想让代码决定的话默认工具面持久化官方可观测方案LangChain / LangGraphcreate_agent或StateGraph下沉一层到 LangGraph 画图。middleware 只管得了重试、提前终止这类事路由管不了空自带 checkpointerLangSmithPydantic AI官方五级从单 agent 到图选第 3/4 级编排写成普通 Python空接外部编排Pydantic Logfireeve主编 agent subagents没有现成的路只能用 prompt 去约束模型自带 sandbox 和 harness自带Vercel WorkflowsVercel Agent Runs我们要做什么单个 Agent 没什么难度。挂几个工具、写段提示词、跑一轮对话三个框架写出来的东西差不多还是看不出区别——这跟 QuickStart 是一个问题。所以我想用一个稍微成熟一点的项目来做也就是多 Agent。角色一多事情才开始有意思谁先谁后、能不能并行、上下文怎么在角色之间传、一个角色能不能干另一个角色的活、某个角色跑歪了谁来兜。这些正好能体现出来各个框架的不同单 Agent 根本碰不到。想来想去选了写博客。这个场景天然就是多角色的有一个人写有用户来读。在这个基础上我还加了一个编辑来 review。三个角色各管一段角色干什么执笔把主题和笔记写成初稿按意见修订。唯一有写权限的角色读者视角照着做能不能跑通、哪里看不懂、哪里会卡住编辑视角查事实性错误、编造的数据、跑不通的命令、逻辑断裂做的过程中又补了一个运营视角标题跟搜索词匹不匹配、标签怎么打、开头能不能留住人凑成三个审核视角。串起来是这样一条流水线执笔写初稿 ↓ 三个视角并行审核编辑 / 读者 / 运营互相不看对方的意见 ↓ 汇总判定纯函数算的不由模型说了算 ↓ 不通过 → 执笔按意见修订 → 复审最多三轮有两条设计要在这里先说因为后面每一篇都会回到它们一、加编辑这个角色不是为了凑数。AI 写技术文章会犯一些很稳定的错而且 prompt 劝不住二、判定权不在模型手上。分工是这样的模型只负责按等级给意见每条意见标上blocker/major/minor能不能发布由一个函数按这些等级算——有 blocker 就是不可发布只剩 major 就是建议修订后发布都没有才是可以发布。ifmissingorblockers0:statusblocked# ❌ 不可发布elifmajors0:statusneeds_revision# ⚠️ 建议修订后发布else:statuspublishable# ✅ 可以发布模型压根没有「宣布可以发」这个动作可用。它能影响结论的唯一方式是把某条意见标成什么等级——而标完之后怎么算是计数和比大小的事。这么分是因为模型会为了让流程走完而说「可以发了」函数不会。missing那一项也是同理少一个视角的意见直接判不可发布没审完等于没审模型没法靠跳过一轮审核来让文章通过。具体会犯哪些错、五道结构性防护分别怎么设计第 02 篇细讲。这里只要记住一件事这些跨角色的约束正是三个框架差别最大的地方——有的框架你写了约束它静默失效有的默认会把整条流程炸掉有的写上就跑。项目结构仓库长这样csdn-blog-agent/ ├── CONTRACT.md 三家必须一致的部分落盘布局、指纹算法、判定规则、HTTP 接口 ├── fixtures/ 共享测试语料4 篇人造草稿 期望的检查结果 ├── docs/ 系列文章和视频大纲 └── impl/ ├── eve/ TypeScript端口 2000 ├── pydantic-ai/ Python端口 2100 └── langgraph/ Python端口 2200后续安排先说清楚我们要实现的功能从 LangChain 、Pydantic AI、eve 依次来实现我们的功能最后横向对比各个框架