智能体选型：自建循环还是采用框架

给产品接一个 Agent，先装 LangGraph，还是自己写循环？作者的答案很明确：单 Agent、几分钟跑完、失败可以重试的任务，默认用 SDK 处理模型接入，自己掌握执行循环；需要跨重启恢复、多 Agent 路由或大规模排查运行记录时，再选框架。

这篇值得读的地方，是把选型从功能清单拉回维护成本。作者写过并持续使用一个约 200 行的 TypeScript harness，也踩过自建恢复机制的坑。不过，文中的工时模型来自个人估算，产品能力与价格则是原文给出的 2026 年 11 月快照，需要分开看。

选框架之前，先看谁掌握执行循环

Agent harness 可以理解为模型外面的整套执行装置：调用模型、分发工具、组装上下文、检查预算、拦截未授权操作，再验证结果。模型负责提出下一步，这套装置决定下一步能不能执行、执行到哪里停。

采用 LangGraph、Mastra 这类框架，相当于进入它们的运行时，用图、节点、工作流、检查点等概念表达业务。自己写 harness，则由团队直接管理消息数组、工具注册表和执行循环。

作者最看重的是调试距离。自写循环出错时，可以直接检查模型收到的消息和工具返回值；框架增加了一层排查对象：到底哪个组件拼出了提示词，又漏掉了什么上下文？

但这也不是只有两个选项。作者实际选择的是中间路线：让 Vercel AI SDK 负责供应商适配、流式输出和工具调用解析，业务循环仍由自己控制。独立的小任务可以使用 ToolLoopAgent，OpenAI Agents SDK 也被归入提供 Agent 基础能力的轻量选择。

这里要看具体边界。调用某个 SDK，并不自动代表运行时仍归自己掌握；循环、状态和退出条件到底由谁控制，才是判断依据。

对于读文件、改代码、运行命令、执行测试的任务，作者另选 Claude Agent SDK。它提供的是一套现成 harness，包含会话与权限机制。代价是接受 Anthropic 模型和商业条款的约束。

保存聊天记录，为什么还不算任务能恢复

保存了对话，不等于保存了任务的执行进度。

原文用一个很实际的区别解释持久化：进程在连续调用五个工具的中途崩溃，恢复时到底从最后一轮已保存的对话开始，还是知道哪些工具已经执行完成？

按原文描述，OpenAI Agents SDK 的 sessions 保存的是对话，不能据此推断它具备逐工具调用的运行恢复能力。LangGraph 的 checkpointer 则在每个 super-step 保存图状态，并提供 exit、async、sync 三种持久化模式，供使用者权衡崩溃时可能丢失的状态。Mastra 的 workflows 支持通过快照挂起和恢复。

真正困难的部分，还包括恢复后如何避免重复执行已完成步骤，以及外部操作能否承受重放。作者自建过这套机制，承认它能工作，却也是系统里测试最不足、最让他担心的部分。

所以，等待人工审批两天、成本很高的研究任务、执行到一半的数据迁移，都可能让框架的学习成本变得划算。重新跑一遍已经不能满足业务承诺。

另外两个转向框架的条件，也足够具体：多个 Agent 共享状态，并根据结果分配后续工作；每天有数千次运行，团队需要随时解释某次回答的来龙去脉。前者需要清楚、可测试的路由，后者需要可查询的 trace tree。

工具数量多，不等于已经需要多 Agent。一个 Agent 调十几个工具，仍可能只是一个普通循环。

工时账能参考，但不能当作选型跑分

作者用累计工程师天数比较两条路线。在默认的单 Agent、分钟级任务下，他估算框架需要约 6 天学习和接入，之后每月花 1 天处理升级与抽象层调试；自写循环约需 2 天。

这些数字来自作者交付经验，并非受控实验。原文没有给出不同团队的样本、统一任务或对照测试。可以参考成本如何变化，不能据此认定自己的项目一定能省下几天。

作者提供的另一个成本线索是依赖更新。据原文所述，JavaScript LangGraph 包从 10 月初的 1.4.21 更新到 11 月 10 日的 1.7.3，OpenAI Agents SDK 大致每月发布一个 minor 版本。频繁发布会增加评审负担，但版本数量本身不能证明发生了兼容性问题。

平台费用也要单独算。原文列出的 LangSmith 免费档为 1 个席位、每月 5,000 条 traces；Plus 为每席位每月 $39，包含 10,000 条 traces，compute 和 storage 另按每单位 $1.50、$1.00 计费。5 人团队仅席位费就是每月 $195，尚未计入用量费用。

这些是原文的价格快照。框架库免费、平台收费、模型 token 两条路线都要付，是三笔不同的账。

作者把自建路线的对应平台费用写成零，这个口径偏窄。日志留在自家系统，依然需要存储、检索和维护；只是可能复用了已有设施，没有单独购买平台。

我的判断

我赞同作者把需求限定到今天：能指出正在缺少的能力，才有充分理由承担框架成本。对已有 TypeScript 产品的团队，SDK 加自有循环确实是一条容易理解的起点。

但「200 行」只能说明核心循环可以很短，不能代表完整生产系统的维护规模。工具参数校验、权限、日志、预算和结果验证，都需要有人持续负责。作者用 stub model、不带 API key 验证了轮数上限、成本预算、重复调用拦截和未授权写入阻断，这些检查比代码行数更值得借鉴。

框架一侧也不能只记负账。团队如果已经熟悉某套运行时，学习成本会下降；已有成熟追踪平台，排查体验也可能优于临时拼接日志。作者关于框架调试的抱怨有参考价值，但缺少对照数据，仍属于经验判断。

检查点记录执行状态，幂等机制约束副作用，两者都需要。

即使框架能恢复进度，发通知、提交修改、创建记录等工具仍要处理重复执行。原文建议用 run 和 step 派生幂等键，这比笼统地承诺「支持恢复」更接近生产问题。

作者认为预先解耦后迁移循环只需几天，同样不能视为工期承诺。工具协议、状态结构和副作用越清楚，迁移越容易；已经积累多少业务耦合，原文没有替一般团队回答。

能拿来做什么

• 给 Next.js 或 NestJS 产品接入单 Agent 时，先列明任务时长、失败能否重跑、是否等待人工、是否共享状态，再决定使用自有循环还是框架。采用框架时，要说清购买的是哪项能力、哪一周就会用到它。
• 用 stub model 检查循环的轮数上限、单次费用上限、重复工具调用拦截和写入审批。工具参数通过 Zod 等 schema 校验后再进入 handler，避免把模型输出直接当可信输入。
• 在测试环境中途杀掉进程，观察任务究竟重跑、恢复还是留下不一致状态。记录实际发给模型的完整请求，并为有副作用的工具设计幂等键，把恢复承诺落实到可观察的行为上。
• 把工具的 schema 与 handler、模型接口、限制和审批函数分开组织，并提前写下迁移触发条件。例如开始等待数天、多个 Agent 按结果协作，或升级持续消耗每月一天，再重新评估 LangGraph、Mastra 或现成 harness。