2026年开源Agent工具栈

存活于生产的七个层级，以及每层的开源选择

AI拉呱：洞察AI技术前沿

你花了三周交付一个Agent。Demo里它跑得很好。然后生产环境来了，你发现选的框架没有checkpointing，记忆层是扁平的向量堆没有时间推理，浏览器工具遇到canvas元素就崩溃，评估套件是某个Notion文档——总有人忘记更新。

2026年构建Agent的开源工具栈已经解决了大部分这些问题。代价是每个问题都有十几种不兼容的解决方案。在LoCoMo（标准长对话记忆基准）上胜出的记忆框架，每对话开销比第二名高340倍——这个差距没有基准列会显示。基准分数与生产行为之间的同样差距出现在每一层。

所以最好的方式是锁定你的系统在负载下最先碰到的约束：延迟预算、审计追踪、模型可移植性、语言栈。搞错了，第三周就得重写状态schema。

TL;DR

如果你读过AI Agent技术栈（2026版），这是开源那一半。围绕什么是AI Agent？中think-act-observe循环的同样七层：编排、记忆、工具接口、浏览器/CUA、编码Agent、评估与可观测性、推理。以下是每层的起点。

每层如何选择

选择每层工具时，问三个问题：

1. 主导约束是什么？ 四个约束决定大多数层级选择。延迟预算是你每轮能花多少token或毫秒。审计追踪是每个动作是否必须可追溯以满足合规。模型可移植性是你的栈有多绑定一个供应商。语言栈是团队用Python、TypeScript还是两者。通常每层有一个主导。
2. 选错了的替换成本？ 换一个MCP server改一行配置。换编排层要重写状态schema、节点和边。重写越大，越应该先按约束选。
3. 是开源还是open-core？ Open-core意味着项目以开源许可证发布，但生产功能（多租户认证、复制、SSO、审计日志）只在托管云产品中运行。仓库的功能列表告诉你买的是哪一边。

第1层：编排与运行时控制

编排层运行Agent的推理循环。LLM选一个动作，运行时执行，运行时观察结果，LLM再选。跳过框架就得自己写循环——意味着在交付前重新发明重试、checkpointing和人机交互门控。

LangGraph是Python生产工作的默认选择。基于图的状态机，通过PostgresSaver实现持久执行、时间旅行调试，以及该领域最大的已验证企业名单（Klarna、Uber、LinkedIn、JPMorgan、Replit）。图状态映射到监管行业的需求：每个状态转换是一条审计日志，任何失败运行回滚到前一个节点并从那里重放。上限：它很冗长。一个两Agent流程仍需要状态schema、节点、边和编译。对于”顺序调用三个工具”，它是杀鸡用牛刀。

CrewAI在四个编排框架中设置开销最低。你声明角色如研究员、写手、审查者，选一个协调模式，运行crew——无需先定义状态schema。上限：CrewAI以原型速度为代价优化生产持久性。框架无法从失败处恢复崩溃的运行，错误处理在crew层级而非每个节点，没有可检查的状态schema记录Agent何时做了什么决定。团队在生产状态管理开始比角色隐喻更重要时从CrewAI迁移到LangGraph。

Pydantic AI将每个Agent输出视为类型化的Pydantic模型，验证、重试和下游序列化免费获得。FastAPI风格的装饰器用于工具和依赖。上限：多Agent原语比CrewAI或LangGraph弱。最适合Agent是单循环、必须返回验证数据给下游服务的场景。