你用一条命令把一个 Agent 框架装好，然后跑它自带的测试，屏幕刷出 59 条红色失败。第一反应通常是「我环境配坏了」，于是重装、换 Python 版本、清缓存，折腾一小时。
我这次遇到的正是这件事，只不过顺序反过来：先按项目自己的依赖清单装，跑出 3553 条全绿；再换成「装最新版」这条最自然的路径，同一套测试立刻挂掉 59 条。
这个项目叫 deepagents，LangChain 官方出的 Agent 框架，GitHub 上 3 万出头星。它把「怎么让 AI 长时间干活」这件事拆成了一套可组装的零件。这篇评测只回答一个问题：它到底稳不稳，以及那个「稳」是有条件的还是无条件的。
一、它是干什么的
先说人话。现在让 AI 帮你干活有两种路子：一种是你直接跟 ChatGPT 那样的对话框聊；另一种是你给它一个工作台——能读写文件、能跑命令、能把手上的活拆成几份派给不同的助手，干不完还能接着干。deepagents 属于后者，它提供的是那个工作台。
它自己不跑模型，也不带界面。你给它一个模型（OpenAI、Anthropic、本地跑的都可以），它把「读文件、写文件、派活给子助手、上下文太长就压缩、跨会话记东西」这些能力装好，还给你一个入口函数，一行代码就能起一个能自己干活的 AI。
它在官方文档里被归到三层结构的最上面：最底层是 LangGraph（负责流程怎么走、状态怎么存），中间层是 LangChain 的简易 Agent，最上面才是 deepagents——同样的零件，但把文件系统、子助手、上下文管理、技能库预先装好了。
装配方式是「中间件」，也就是一层层套上去的插件：请求从外往里传，每一层可以改一改再往下递。我数了一下它的核心库，一共 57 个源文件、3 万 1 千行代码，其中文件系统那层 3909 行、上下文压缩 2424 行、异步子助手 1751 行——这几个数字说明它的复杂度主要落在「管住 AI 的上下文和文件」上，不在「调模型」上。
二、我实测的两组数字
评测机是单核、内存不到 2G 的 Linux，整个项目关在隔离沙箱里跑：宿主上的密钥、配置、家目录在沙箱里都看不见，克隆和安装都在里面完成。下面两条命令你都能自己复现。
先看两组并排的结果：
| 我怎么装依赖 | 结果 |
|---|---|
| 按项目自带的依赖清单（版本全部锁死） | 3553 条通过 · 143 条跳过 · 5 条标记为预期失败 |
| 按「装最新版」——直接用 pip 装 | 3474 条通过 · 59 条失败 |
代码风格检查也一样干脆：用它锁定版本的那个检查工具跑一遍，全部通过，57 个文件格式整齐，一条警告都没有。
这里必须说清楚一件事：那 59 条失败里，没有一条是 deepagents 自己的代码写错了。我逐条看了报错来源，分成两类：
- 56 条来自 Anthropic 的 Python 客户端。deepagents 的测试里给这个客户端塞了一个自己造的 HTTP 连接对象，而新版客户端换了底层 HTTP 库，一看到旧库的对象就直接报错。报错原文写得很直白：这个参数来自旧库，而这个 SDK 现在用另一个库。
- 3 条来自视频支持。读视频帧需要两个可选的图像/视频处理库，我没装，于是断言里的消息数量对不上。
退回项目锁定的那个客户端版本，前 56 条立刻消失；补上那两个可选库，剩下 3 条也消失。所以准确的说法是：deepagents 的 3553 条测试真的全绿，但这个绿灯只在你使用它自己的依赖清单时才亮。
这不是鸡蛋里挑骨头。它暴露的是一个很常见的工程取舍：项目对「间接依赖」几乎不设上限。它声明自己需要 LangChain 的 Anthropic 适配层不低于 1.7.7、低于 2.0，而这个适配层往下依赖的 Anthropic 客户端，版本号从 0.120 一路走到 2.x，项目完全没有约束。于是同一条安装命令，今天跑和三个月后跑，拿到的可能不是同一套东西。
对照之下，它自己在别的地方做得相当扎实，值得记一笔：
| 它自己的要求 | 我跑的验证 | 结果 |
|---|---|---|
| 提交前代码必须过风格检查与类型检查 | 跑它锁定的检查工具 | 通过，57 个文件零告警 |
| 每个改动必须带测试 | 数测试资产 | 71 个测试文件、6 万 6 千行测试代码，是被测代码的两倍 |
| 报错不得被静默吞掉 | 看测试配置 | 意外的警告直接判失败，不许「带病通过」 |
| CI 必须分模块跑 | 数工作流文件 | 59 个，按包切分，lockfile 也单独校验 |
测试代码比被测代码多一倍，这个比例在开源项目里属于很高的。它换来的东西也真实可见：我故意装错依赖版本，它立刻用 59 条失败告诉我哪里不对，而不是等上线才发现。
三、一处自己没守住的规矩
再往里翻，我发现一处挺有意思的自相矛盾。
这个仓库有一份写给 AI 助手和贡献者看的开发规范，里面关于「屏蔽代码检查」写得很硬：单条豁免必须写明理由；不许用「整个文件豁免」的方式把一处违规藏起来；如果你没法为一次豁免说出理由，那多半是代码本身有问题。
我把这句话当成清单，去数它自己的代码：
| 它自己定的规矩 | 代码里的实际情况 |
|---|---|
| 单条豁免必须写明理由 | 175 处豁免里，116 处没有写理由 |
| 不许整个文件豁免 | 7 个文件在开头就整篇关掉了行宽检查 |
也就是说，一条被明确定义为「反模式」的写法，在这份规范生效后的代码里存在 7 处，而且集中在几个最核心的文件上——文件系统、记忆、评分中间件。这不是灾难，行宽检查本来就不影响运行；但它说明一件事：规范是靠人自觉执行的，没有机器在执行它。
同一类问题还有一处更实在的：核心库的测试配置里，少写了一项异步测试的事件循环设定。同一仓库的另一个包写上了，这个包没写。后果是使用新版测试框架时，一启动就崩，连一条测试都跑不起来，必须在命令行手动补上这项参数才能继续。我第一次跑就是这么卡住的。
四、和同类比，它站在哪
如果你的目标是「让 AI 自动改代码」，那 Claude Code、Cursor 这类产品是成品，装完就能用；deepagents 不是它们的竞品，它给你的是自己搭一个的零件。它的文档里也写得很清楚：这个项目最早就是受 Claude Code 启发，想搞清楚它为什么通用，然后做得更通用。
如果你已经在用 LangChain，那它是顺理成章的下一步：底下那套流程引擎和状态存储不用换，直接在上面加文件系统、子助手、技能库。代价是你会被绑在这套生态里——它的状态、存储、回溯全都建立在 LangGraph 之上。
如果你只是想让 AI 帮你处理文档、不想写代码，那这个项目现在不适合你。它没有界面，也不提供开箱即用的助手，第一步就要写 Python。
适合的人：要自己造 Agent 产品的团队，尤其是需要「长任务、多子助手、上下文要压住」这类场景的。
五、我的判断
deepagents 属于那种「工程质量确实在线，但边界要自己看清」的项目。3553 条测试、6 万 6 千行测试代码、59 个按模块切分的 CI 工作流，这些不是装样子的，我在沙箱里一条条跑过。它受得住「改错东西」这种压力测试。
但它的稳定有一个前提条件：你得像它自己那样装依赖。用 uv sync 或者照着它锁定的版本走，绿灯；用「pip 装最新版」，你会花一个小时怀疑人生。这个坑不算它独有的问题，几乎所有 Python 项目都在这个坑边上走，只是它这里表现得很明显——因为它依赖的模型客户端半年里跨了三个大版本。
值得一试，但请先照它的依赖清单装。 如果你打算把它放进生产，建议先把那个间接依赖的版本钉死，别让上游改一次库就冲垮你的测试。
顺带一提，这类「测试全绿但有前提」的情况我在别的项目上也遇到过：Cindy 是规范写得比代码严，Univer 是测试数字漂亮但能力边界在闭源侧。
关注 AI商业快讯，每天一篇 AI 热点深度解读。