Agent 状态及同步数据存在哪里？

核心回答

先按数据职责分开：运行中的状态放在任务State，恢复执行需要的快照落到持久化检查点，跨Agent共享结果放到受控的共享存储，大文件只传引用。 不必把它们全部塞进向量数据库，也不必为了内部小平台同时部署很多存储系统。

例如一个Deep Research任务，State保存目标、计划、当前节点、已完成子任务和资料索引；检查点保存可恢复的执行位置及状态；报告、网页正文放文件或对象存储；各子Agent回传结构化结论和产物地址，由协调者合并。

State具体存什么

建议围绕后续执行确实需要的信息设计字段：任务ID与状态版本、用户请求及约束、计划和步骤状态、工具调用ID与结果摘要、证据引用、错误与重试信息。消息历史可作为一部分，但State不等于聊天记录。

工具返回的整份文档、图片和大日志不宜在每个节点复制，保存产物ID、存储位置、内容版本和简短摘要即可。服务连接、模型客户端等运行时对象不要混进需要序列化的状态；身份与授权由可信运行时提供，而不是让模型自由改写。

存储怎样选

小型单进程演示可以先用内存State和本地文件，接受重启后任务丢失的限制。需要重启恢复、多实例或任务查询时，用持久化数据库保存任务与检查点；缓存用于加速读取和短期协调，不能在未经设计时承担唯一事实来源。

以LangGraph为例，checkpointer按thread组织执行快照，Store用于跨thread的数据保存；两者职责不同。向量索引适合相似检索，不适合替代任务状态的精确更新。使用什么后端应取决于恢复、一致性和访问方式，不是看Agent框架流行什么。

Agent之间如何同步

协调者下发任务契约和必要上下文，子Agent写自己的结果分区，再发送完成事件。事件里带任务ID、步骤ID、结果版本与产物引用，接收方根据这些标识读取真实数据；消息队列本身不一定是结果的永久存储。

并行节点尽量写不同字段；需要聚合的列表定义合并规则，并按子任务ID去重。对同一个计划或状态的竞争更新，用单一写入者或版本比较解决，不能只靠“最后写入覆盖”。框架的reducer也不会自动解决业务语义冲突。

恢复时先加载任务状态和检查点，再核对外部动作是否已完成。发消息、创建订单等副作用要有幂等标识，避免状态保存失败后重放造成重复操作。按用户、会话和任务范围控制读取，过期任务及时清理。

面试中怎样讲清楚

沿一次写入说明“哪个节点产生、写什么表或文件、下一节点如何查、崩溃后从哪恢复”，比只报Redis或MySQL更有说服力。技术亮点是明确事实来源、状态所有者和合并方式，在可恢复的前提下保持架构与规模相称。

对应教程

参考资料