项目采用或参考了什么 Agent 框架，哪些部分由自己实现？

核心回答

以深度研搜项目为参考，它基于 Deep Agents 组装任务型 Agent，复用 LangChain 的模型与工具接口、LangGraph 的状态执行与检查点能力；应用层实现业务工具、专家配置、会话文件处理和前后端任务交互。

可以分三层介绍：

1. 框架提供运行机制：模型与工具循环、子任务委派、图状态和流式执行，避免应用重复编写整套执行器。
2. 项目定义业务能力：配置网络搜索、数据库查询和 RAGFlow 知识库三个自定义业务专家，并实现相应工具；主 Agent 还可读取附件、生成 Markdown 并转换 PDF。
3. 应用完成交付链路：FastAPI 接收任务，后台协程执行，按会话准备文件目录和上下文，监控模块通过 WebSocket 推送工具、专家调用与结果，前端展示进度和产物。

个人职责可以围绕实际参与的一条链路展开，讲清输入怎样处理成可用结果，而不是只报框架名称或代码文件数量。

框架和业务代码怎样衔接

模型通过 LangChain 的统一接口初始化，再交给 create_deep_agent。应用传入主提示词、文件工具、三个业务专家配置和 checkpointer，得到可以异步流式调用的主 Agent。

框架负责根据模型响应继续调工具或完成回答；项目负责定义工具到底访问哪个业务系统、接收什么参数、返回什么结果。专家的名称、职责描述、提示词与工具列表也由项目配置，主 Agent 通过 task 委派目标，专家完成后把结果交回。

例如数据库专家包含查看表、读取表结构与样本、执行 SQL 等工具。应用代码建立数据库连接，执行查询，读取列名和记录并组织返回内容，帮助模型依据实际表结构回答。网络专家包装 Tavily 搜索；知识库专家先取得可用助手列表，再访问相应 RAGFlow 助手。这些外部系统与业务口径都需要项目自行接入。

应用层具体做了哪些处理

任务入口与异步执行。 API 接收问题和会话标识，创建后台任务并登记活跃执行对象。主 Agent 使用 astream 输出运行片段，应用识别模型、工具及子任务事件，再转换成前端能够展示的进度。

文件与会话上下文。 上传材料先进入会话上传目录，执行前复制到本次输出目录，并把文件信息加入任务输入。ContextVar 让深层工具取得当前会话目录与事件标识，结束后恢复原上下文，减少后续任务串用信息的风险。

报告与可观测交付。 文件工具读取附件、写出 Markdown，再调用转换工具生成 PDF；监控代码上报工作目录、工具参数、专家委派和最终结果。前端能够看到过程，并浏览或下载生成产物。

这里的价值是把运行机制接到资料获取、文件处理和用户交互上。业务工具的错误反馈、结果格式与上下文传递，会直接影响 Agent 是否能继续做出正确决策。

怎样讲清自己负责的部分

例如实际负责数据库工具，就从一条查询说明：接收查询意图，取得表结构与字段，组织工具参数，执行数据库请求，转换查询结果，再把错误或数据交回 Agent。继续解释为什么先查真实表结构、怎样限制结果规模，以及查询失败时如何向上反馈。

如果负责前后端任务链路，则介绍任务 ID 怎样关联后台协程与推送通道，上传文件怎样进入当前会话，工具过程和最终结果怎样映射到前端。选一处实际实现的难点展开，比把所有框架能力都列成个人贡献更清楚。

已有机制和继续完善的方向

当前项目显式使用 InMemorySaver，检查点保留在进程内。要在服务重启后继续任务，可以接入持久化检查点、任务登记和执行接管，再处理外部操作的结果核对。框架提供可接入机制，应用仍要选择存储并定义恢复规则。

文件按会话分目录，有利于组织产物；面向多用户服务时，还要由服务端校验身份、资源归属和文件访问范围。数据库工具当前直接执行传入 SQL，真实业务接入可进一步使用只读账户、语句校验、数据范围限制和资源预算。

这些完善方向适合结合项目需求展开，不需要为了使用更多框架特性而重写已经清楚的业务流程。

常见追问

为什么没有全部从零写？ 这个场景需要动态选择工具、委派专家并持续获取信息，复用框架可以集中处理运行与接口机制。业务工具、任务约束和交付逻辑仍由应用控制；若某个固定流程用普通代码更清楚，也可以独立实现。

怎样证明自己的改动有效？ 选择与负责模块对应的任务：工具接入检查参数、返回结果和错误处理；文件链路检查上传、读取与产物；任务入口检查启动、进度、取消和失败反馈。性能或质量提升使用自己的对照结果，功能实现则用实际输入输出说明。

需要比较所有框架吗？ 重点说明选择依据和关键替代方案。更完整的取舍可看何时沿用框架、何时自行封装，本题重点是现有项目怎样组合、自己承担了哪部分实现。

对应教程

参考资料