何时沿用开源 Agent 框架，何时选择自行封装或从零开发？

核心回答

我会先看业务需要哪些执行能力、框架的控制方式是否匹配，以及团队长期维护的总成本。沿用框架、自行封装和从零开发可以按模块组合，不必给整个系统只选一种。

• 沿用开源框架：需要的模型接入、工具循环、状态流转、子任务调度等能力已有合适实现，扩展点也能接入业务，就优先复用。收益是少维护通用执行机制；代价是学习抽象、跟踪版本和处理兼容性。
• 局部自行封装：公司数据接口、身份权限、指标口径、结果事件等具有业务特性，可以在框架外围或扩展点实现。这样既保留成熟能力，也能控制关键业务行为。
• 直接用 SDK 或从零开发：流程简单且固定时，直接调用模型和工具可能更清楚；如果现有框架的状态、调度或部署方式持续不符合核心需求，也可以自建相应部分，但要评估谁负责状态恢复、重试、取消和后续维护。

例如研搜助手可以复用 DeepAgents 的主从调度，业务代码自己接入 Tavily、MySQL、RAGFlow，管理会话目录和前端进度。是否继续沿用这层框架，应通过实际任务质量、延迟、失败恢复和升级成本判断，而不是只看框架热度或 Demo 代码量。

展开说明

1. 先确定需要复用的是哪一层

模型 SDK 解决的是向模型发请求、接收响应等问题；Agent 框架可能进一步封装工具调用循环、状态和中间件；运行时还可能提供检查点、流式事件和中断恢复。不同项目提供的能力范围不同，不能把“用了一个框架”直接等同于“全部工程问题已经解决”。

如果业务只是“填充模板、调用模型、解析结果”，普通代码或较薄的封装就能表达清楚。若任务需要多轮工具反馈、分支、暂停和恢复，复用合适的 Agent 或工作流运行时更有价值。高层封装不合适时，也可以只使用它的模型适配、工具定义或底层状态图，而不是立即替换整个技术栈。

2. 框架能力与业务职责要有清楚边界

以研搜项目为参考例子，DeepAgents 负责把主智能体、专家子智能体和工具组织起来，底层使用 LangGraph 执行。网络搜索、数据库查询和 RAGFlow 接口仍由项目工具实现；会话目录、上传文件处理、结果文件和 WebSocket 进度也由应用代码接起来。

框架能调用数据库工具，并不代表它已经知道公司的数据权限和指标口径；框架支持检查点，也不代表当前项目已经具备重启恢复。该参考实现使用 InMemorySaver，若需要持久恢复，还要选择相应存储并处理业务操作的重复执行。这些边界应按实际配置和代码核对。

适合自行封装的通常是稳定的业务接口和契约。例如对上提供统一的“查询业务数据”接口，在内部管理鉴权、SQL 校验、超时和返回格式；框架节点调用这个接口。这样业务约束有明确实现位置，更换编排框架时也不必重写整套数据访问逻辑。

3. 什么时候值得自建执行部分

一种情况是需求本来很小：工具少、流程短、不需要持久化或复杂委派，直接用 SDK 和普通函数便于理解和调试。但即使没有框架，也要处理工具参数、错误反馈和循环停止条件。

另一种情况是核心执行语义不匹配。例如公司已有统一任务调度和状态系统，而框架强制维护另一套难以对接的生命周期，导致取消、恢复和状态归属经常冲突。应先验证适配层或扩展点能否解决；如果需要持续修改框架内部、承担大量绕行代码，自建受影响的执行层可能更合适。

自建的范围也可以很小：只替换调度、上下文组装或工具执行器，继续复用模型 SDK 和通用组件。只有当这些分层组合仍无法满足核心需求、且团队能维护完整执行链路时，才考虑更大范围的从零开发。

4. 用同一条业务链路评估维护成本

做选型验证时，可以选一条有代表性的真实任务，比较框架方案和薄封装方案：完成目标需要哪些适配，模型与工具的输入输出能否追踪，失败后能否按预期重试、取消和恢复，已有身份与部署体系能否接入。

结果质量、延迟、Token 和工具调用费用要一起看。框架本身可能主要增加本地抽象开销，也可能因为默认提示词、中间件、规划或子代理策略改变模型调用和上下文消耗；具体成本应通过运行轨迹确认，不能笼统说“框架一定慢”或“自研一定省钱”。

长期还要看升级影响：锁定依赖后能否回放同一批样例，工具消息格式或状态结构变化会影响哪些模块，旧任务和产物能否继续读取。自行封装一个稳定的业务接口有助于收拢变化，但不必为了隐藏所有框架类型，再写一层与框架接口完全相同的包装。

常见追问

已经用了框架，哪些工作可以体现自己的实现？

具体说明实现了哪项业务能力及其输入输出。例如把业务数据库接成工具，处理鉴权、查询约束和结果结构；或者把任务事件接到前端，支持进度、取消和结果下载。框架提供的执行机制与业务实现分别说明，就能把技术边界讲清楚。

框架不支持某个能力，是改源码还是自己写？

先确认是否已有公开扩展点，可以用自定义工具、节点、中间件或适配器接入。若需要修改核心代码，再比较上游贡献、维护补丁和替换局部组件的成本。关键是改动范围、兼容性和后续负责人明确，而不是默认修改源码或重写全部。

从零写出的代码更少，是否说明更适合生产？

不一定。代码量少可能是业务确实简单，也可能省略了持久化、限额、异常处理或观测。应比较满足同一需求后的实现与运维成本；同样，框架带有很多功能，也不代表这些功能都应该启用。

对应教程

参考资料