如果由你实现一个 Agent，整体架构及主要组件如何设计？

核心回答

我会围绕一次任务的执行链路，把 Agent 拆成五类职责：

1. 任务入口与会话管理：接收用户目标，建立任务标识，管理必要的输入、取消和进度返回。
2. 上下文与状态管理：组织当前目标、已确认条件、相关历史和知识，保存执行进度及工具结果；长期记忆按需要加入。
3. 模型决策与任务编排：模型判断下一步或生成计划，编排器控制依赖、分支、循环和退出条件。
4. 工具执行与结果反馈：登记工具及参数结构，校验调用与权限，执行 API、检索或文件操作，再把真实结果交回决策循环。
5. 验证、交付与运行保障：检查结果是否满足任务，生成最终回答或文件，并记录错误、耗时和调用轨迹，支持必要的重试与恢复。

主链路是：请求进入 → 组装上下文 → 模型提出动作 → 程序执行 → 写回状态与结果 → 继续决策或交付。最小 Agent 可以从模型、工具、状态和运行循环做起，规划、长期记忆和多 Agent 按业务需要扩展。

展开说明

1. 组件之间要交付明确的数据

任务入口把原始请求、可信用户身份和任务范围交给运行时，运行时建立当前任务状态。状态可保存用户目标、确认参数、计划、已完成步骤、结果引用和预算；上下文管理组件再从中选取当前决策需要的信息。

模型适配层负责调用模型并解析输出，返回的动作可以是调用工具、请求补充输入或完成回答。任务编排层决定这些动作如何进入合法路径，哪些分支需要等待依赖、哪些错误可以重试，以及何时停止。模型能力和流程控制可以由不同组件提供，也可以封装在同一个运行时中。

工具注册表提供名称、用途和参数 Schema，执行器根据模型提案找到实现，完成参数、身份和资源范围校验后调用。工具结果应有可识别的状态、数据或产物引用和错误信息；执行器把它们与原调用关联，再交给上下文与状态组件。这样模型下一轮看到的是实际反馈，而不只是自己提出的计划。

2. 用一次研搜报告请求串起来

以企业研搜参考架构为例，用户要求“分析上月某商品销量，结合内部资料和公开行业信息生成报告”。入口先接收问题和附件，明确商品、时间范围及交付形式，再进入主 Agent。

主 Agent 判断需要哪些信息：数据库专家取得内部结构化数据，知识库专家查询私有文档，网络专家搜索公开资料。各专家使用自己的工具完成子任务，结果回到主 Agent 汇总；主 Agent 的文件工具用于读取上传材料、写 Markdown 和转换 PDF。

实现时要让每次委派说明目标、输入范围和期望结果，汇总阶段检查时间与口径是否一致、是否缺少关键依据。需要补查就继续循环，已经满足交付要求就输出文件和说明。生成报告与查询数据是不同职责，工具成功也要经过业务验收才能算任务完成。

3. 参考实现中，各技术分别承担什么

研搜后端使用 Python，FastAPI 接收任务请求并启动后台执行，WebSocket 传递进度事件。Deep Agents 组织主 Agent、三个自定义业务专家及工具，LangChain 提供模型和工具接口，LangGraph 运行时支撑状态执行与流式过程。

业务能力通过工具接入：数据库查询、Tavily 网络搜索、RAGFlow 助手调用和文件处理分别取得或交付不同类型的信息。会话标识关联运行上下文与产物目录；当前检查点使用 InMemorySaver 保存同一进程内的上下文，跨进程恢复可进一步采用持久化后端和任务接管逻辑。

这些职责可以在一个后端中实现。若以后需要独立发布或扩缩容，再按实际服务边界拆分；组件名称本身不要求每层都成为单独服务。

4. 记忆、知识库和验证放在哪里

当前任务状态保存“这次正在做什么、已做了什么”；长期记忆保存需要跨任务复用的用户偏好或经验；知识库提供可检索的业务资料。上下文管理把相关信息选择性地送给模型，它们不必合成一份无限增长的聊天记录。

验证既可以出现在工具返回之后，也可以出现在最终交付之前。参数和字段格式适合用程序检查，数据口径、引用和业务验收按任务设计规则或评测。模型自评可以提供辅助意见，不能替代必要的实际证据。

运行保障贯穿这些组件：任务和调用标识用于追踪，预算限制循环，可靠检查点保存进度，写操作通过幂等与回执核对处理重试。职责明确后，框架可以承担一部分通用能力，业务工具和验收标准仍需应用实现。

常见追问

Planner、Executor 和 Memory 必须独立吗？

不必。简单任务可以由同一个模型逐步决策，运行时负责执行工具并更新状态；较长任务再增加显式计划。Memory 也可以先只保留当前会话状态，出现跨任务复用需求后再引入长期存储。是否拆组件，应看职责、复用与维护需求。

开源框架和自己封装怎样分工？

可以复用模型接口、工具调用、循环、状态和检查点，在外面封装业务身份、任务契约、工具适配和验收。需要更精确的控制时，局部自定义节点或中间件即可；架构设计不要求从零重写全部框架能力。

多 Agent 应该加在哪一层？

通常由编排层将独立子任务委派给具有相应工具和上下文的专家，再归并其结果。主干仍是任务输入、执行反馈和验收，增加 Agent 后还需明确交接契约、结果归属与失败处理。简单工具调用可以继续保留在单 Agent 内。

对应教程

参考资料