尧图网页设计 
Agent Zero 会话导出机制详解chat_export 端点从请求契约到上下文序列化的完整链路【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero在 Agent ZeroA0中一次 Agent 会话context不仅是内存中的运行状态还是一份可导出、可迁移、可再导入的 JSON 数据。本文以 chat_export 端点的 DOX 档案 为核心骨架结合 端点实现、API 基础框架 与 会话持久化模块 的源码完整讲清/api/chat_export的请求/响应契约、鉴权与 CSRF 约束、上下文序列化格式以及它与chat_load、压缩备份等功能如何构成导出—导入闭环帮助你理解 A0 会话数据的可编程存取方式。端点的职责边界与 DOX 契约A0 的api/目录采用刻意保持扁平intentionally flat的结构每个 HTTP 端点对应一个文件且每份实现文件旁边都有一份同名的.py.dox.md档案文件。chat_export.py.dox.md 明确了两者的分工chat_export.py 拥有运行时实现chat_export.py.dox.md 拥有关于该实现的持久化说明——职责、契约、副作用与验证方式并要求随源码同步更新。DOX 档案对实现做了如下约束性描述与源码逐项对应DOX 契约项源码印证ExportChat必须继承helpers.api.ApiHandlerHTTP 处理器基类WebSocket 处理器则继承helpers.ws.WsHandlerapi/chat_export.py 第 5 行class ExportChat(ApiHandler)定义process(self, input: Input, request: Request) - Output异步方法api/chat_export.py 第 6 行观察到的副作用区域文件系统写入filesystem writes导出内容来源于会话数据同模块的持久化写入见 persist_chat 常量定义导入的依赖区域helpers、helpers.apiapi/chat_export.py 第 1–3 行调用的关键 helper/类self.use_context、persist_chat.export_json_chat、Exception分别在实现体内被调用DOX 的 Work Guidance 部分还给出维护规范除非端点契约显式变更必须保留鉴权、CSRF、loopback 与 API key 检查payload 形状变化时要同步更新前端调用方、插件调用方和测试非 JSON 响应文件、重定向、特定状态码应使用helpers.api.Response。这些约束下文会逐条落到源码上验证。端点实现逐行剖析请求、上下文定位与响应形状chat_export.py 全文仅 17 行但完整覆盖了参数校验 → 上下文定位 → 序列化 → 响应四步from helpers.api import ApiHandler, Input, Output, Request, Response from helpers import persist_chat class ExportChat(ApiHandler): async def process(self, input: Input, request: Request) - Output: ctxid input.get(ctxid, ) if not ctxid: raise Exception(No context id provided) context self.use_context(ctxid) content persist_chat.export_json_chat(context) return { message: Chats exported., ctxid: context.id, content: content, }契约可以归纳为请求JSON bodyPOST参数类型必填说明ctxidstring是要导出的上下文会话ID缺失或为空时抛出No context id provided响应成功时HTTP 200 JSON字段类型说明messagestring固定为Chats exported.ctxidstring实际导出上下文的 ID取自context.idcontentstring整个上下文序列化为 JSON 后的字符串即可直接落盘/传输的备份内容失败路径process抛出的任何异常会被基类的handle_request捕获经format_error格式化后以 500 text/plain返回见 helpers/api.py 第 92–95 行。use_context在锁内定位 AgentContextself.use_context(ctxid)是ApiHandler提供的便捷方法helpers/api.py 第 98–100 行 将其转发到 helpers/context_utils.py 中的共享实现。其逻辑值得注意def use_context(lock: ThreadLockType, ctxid: str, create_if_not_exists: bool True): with lock: # 在服务器线程锁内操作 got AgentContext.use(ctxid) if got: return got if create_if_not_exists: context AgentContext( configinitialize_agent(), idctxid, set_currentTrue ) return context else: raise Exception(fContext {ctxid} not found)从源码结构看chat_export调用时未传create_if_not_exists因此走默认的True分支若指定ctxid在内存中不存在会创建一个空壳上下文再对其序列化。这意味着对不存在的 ID 调用导出不会 404而是返回一个仅含该 ID 与默认值的最小会话 JSON——调用方在集成时应先确认ctxid的有效性例如通过前端会话列表。路由分发与安全契约端点如何被挂载、如何被保护DOX 要求保留 authentication, CSRF, loopback, and API-key checks这些检查的实际执行位置在 helpers/api.py 的框架层而非端点自身。声明式安全开关ApiHandler 基类 通过类方法声明每个端点的安全属性ExportChat全部继承默认值类方法默认值对 chat_export 的语义requires_auth()True需要会话级登录鉴权requires_csrf()返回requires_auth()即True请求必须携带有效的 CSRF tokenrequires_api_key()False不要求X-API-KEYrequires_loopback()False不限制为仅回环地址get_methods()[POST]仅接受 POST其余方法返回 405装饰器栈的组装register_api_route 启动时向 Flask 注册单一动态规则/api/path:path第 267–272 行所有内置端点按文件名即路径分发请求/api/chat_export时解析到api/chat_export.py用load_classes_from_file取出其中第一个ApiHandler子类再按开关从内到外包裹安全装饰器第 249–264 行handler_fn call_handler if handler_cls.requires_csrf(): # chat_export: True handler_fn csrf_protect(handler_fn) if handler_cls.requires_api_key(): # chat_export: False handler_fn requires_api_key(handler_fn) if handler_cls.requires_auth(): # chat_export: True handler_fn requires_auth(handler_fn) if handler_cls.requires_loopback(): # chat_export: False handler_fn requires_loopback(handler_fn)具体检查逻辑requires_auth取login.get_credentials_hash()若服务端配置了凭据哈希而当前 session 不匹配则重定向到登录页未配置凭据时直接放行csrf_protect要求请求的X-CSRF-Token头或csrf_token_runtime_idCookie 与 session 中的 token 一致否则 403handle_request解析 JSON body 为input解析失败时退化为空 dict调用processdict 返回值自动序列化为application/json200 响应Response实例则原样透传。因此对chat_export的标准调用形态是POST/api/chat_export携带登录 session、有效 CSRF token 与 JSON body{ctxid: 上下文ID——这正是 DOX Work Guidance 中不要绕过安全层的运行时含义。此外分发层支持插件扩展形如plugins/plugin_name/handler的路径会到插件目录下的api/子目录加载处理器第 229–240 行且 watchdog 会在api/目录的.py文件变化时清空处理器缓存register_watchdogs所以端点代码是热加载的。序列化核心export_json_chat 与上下文字段格式真正决定导出内容质量的是 helpers/persist_chat.py 中的持久化逻辑。导出入口export_json_chat 只有两行核心逻辑def export_json_chat(context: AgentContext): Export context as JSON string data _serialize_context(context) js _safe_json_serialize(data, ensure_asciiFalse) return js它与会话的常规落盘save_tmp_chat写入usr/chats/ctxid/chat.json见 CHATS_FOLDER 与 CHAT_FILE_NAME 常量 及 save_tmp_chat共用同一套序列化函数——导出的 JSON 与 A0 磁盘上存储的会话文件是同构的这是导出文件可直接用chat_load导入的根本保证。_serialize_context输出的字段表_serialize_context 生成的顶层结构如下字段来源说明idcontext.id上下文 IDnamecontext.name会话名created_at/last_messagecontext.created_at/context.last_message经Localization.get().serialize_datetime(...)本地化序列化缺失时回退为纪元时间_fallback_datetime_isotypecontext.type.value上下文类型枚举值字符串agents_serialize_agent沿DATA_NAME_SUBORDINATE链遍历主 Agent 及其整条从属 Agent 链每个元素含number、agent_profile、data、historystreaming_agentcontext.streaming_agent.number当前流式 Agent 的编号无则为 0导入时据此在从属链中重新定位agent_profilecontext.agent0.config.profile等会话级 agent 档案名log_serialize_log日志 GUID、进度与日志条目序列化时持log._lock防并发修改且只保留最近LOG_SIZE 1000条常量定义data/output_datacontext.data/context.output_data过滤掉以_开头的内部键后原样导出_serialize_agent 对每个 Agent 输出number、agent_profile、非下划线前缀的data以及agent.history.serialize()产生的历史——即完整的消息与工具调用历史都在导出范围内。_safe_json_serialize对不可序列化值的防御性裁剪_safe_json_serialize 用一个json.dumps探测函数is_json_serializable递归遍历对象dict/list 中不可序列化的项被整体剔除其他不可序列化值置None。可以推断这一层防御是为了保证任何运行态上下文即使内存里挂着不可 JSON 化的对象都不会让导出抛异常——导出总是成功代价是极个别字段被静默丢弃。ensure_asciiFalse则保留中文等非 ASCII 字符的可读性。闭环chat_load 导入与压缩备份对同一序列化的复用chat_export并不是孤立端点。反向端点 api/chat_load.py 的LoadChats接收{chats: [JSON 字符串, ...]}调用 load_json_chatsdef load_json_chats(jsons: list[str]): Load contexts from JSON strings ctxids [] for js in jsons: data json.loads(js) if id in data: del data[id] # remove id to get new ctx _deserialize_context(data) ctxids.append(ctx.id) return ctxids注意del data[id]注释导入时主动删除原 ID为会话分配全新 ID——导出文件是模板反复导入会生成多份独立副本而不会覆盖原会话。反序列化由 _deserialize_context 完成它按streaming_agent编号沿DATA_NAME_SUBORDINATE链重建从属 Agent 关系。除导出→导入迁移外export_json_chat还被 压缩插件的备份逻辑 复用_save_pre_compaction_backup在压缩compaction会话前调用export_json_chat把原始会话快照写入usr/chats/ctxid/backups/pre-compact-timestamp.json——即同一份序列化既是用户备份格式也是内部安全网格式。测试侧同样围绕这一契约构建tests/test_api_chat_lifetime.py 用export_json_chat序列化上下文、断言data中的自定义字段如lifetime_hours存活再用_deserialize_context反序列化验证往返一致tests/test_chat_compaction.py 则对压缩流程中的export_json_chat做 mock 验证。这也回应了 DOX Verification 一节运行端点级或 API 测试无聚焦测试时做冒烟检查的要求。前端调用方式与外部集成A0 WebUI 中保存会话按钮的完整调用链位于 chats-store.js// Save current chat async saveChat() { const context this.selected || getContext(); const response await sendJsonData(/chat_export, { ctxid: context }); if (!response) { toast(No response returned., error); } else { this.downloadFile(response.ctxid .json, response.content); toast(Chat file downloaded., success); } }即对当前选中会话调用/chat_export拿到content后以ctxid.json为文件名触发浏览器下载配套的 loadChats 则让用户选择多个.json文件上传经FileReader读为字符串数组后 POST 给/chat_load成功提示 Chats loaded.。这构成 WebUI 侧完整的导出/导入配对。对于外部集成脚本或 API 客户端基于 helpers/api.py 的分发与安全层事实调用要点是# 1) POST /api/chat_exportbody 仅一个字段 curl -c cookies.txt -X POST http://host/api/chat_export \ -H Content-Type: application/json \ -d {ctxid: CONTEXT_ID} # 2) 若服务端启用了登录需先通过登录流程获得 session 与 CSRF token # 并在导出请求中携带X-CSRF-Token 头或 csrf_token_runtime_id Cookie # 见 csrf_protect 与 requires_auth 的实现 curl -b cookies.txt -c cookies.txt -X POST http://host/api/chat_export \ -H X-CSRF-Token: TOKEN -H Content-Type: application/json \ -d {ctxid: CONTEXT_ID}成功响应形如{ message: Chats exported., ctxid: 6f1c2a..., content: {\id\: \6f1c2a...\, \name\: \...\, \agents\: [...], \log\: {...}} }把content原样写入磁盘即得到一个可被chat_load重新导入的会话文件。需要注意的前提该端点默认requires_auth()True且仅接受 POST未带有效 session/CSRF token 的请求会被拦截而不是返回数据。小结维护该端点时的核对清单以 DOX 档案 为契约基线改动 chat_export.py 时应核对契约不变请求只依赖ctxid响应保持message/ctxid/content三字段改 payload 时按 DOX 要求同步更新 chats-store.js 前端调用、插件调用方与测试序列化格式稳定content的结构由 _serialize_context 决定任何字段增删都会同时影响磁盘存储usr/chats/ctxid/chat.json、chat_load导入与压缩备份应结合 tests/test_api_chat_lifetime.py 的往返测试回归验证安全层不动ExportChat未覆写任何requires_*开关鉴权、CSRF、仅 POST 均由 ApiHandler 默认值与 register_api_route 的装饰器组装 保证除非契约显式变更不应为其追加requires_api_key之外的新豁免。按上述清单核对chat_export端点即可在保持 DOX 契约、前端行为与测试预期一致的前提下安全演进。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Agent Zero 会话导出机制详解：chat_export 端点从请求契约到上下文序列化的完整链路
Agent Zero 会话导出机制详解chat_export 端点从请求契约到上下文序列化的完整链路【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero在 Agent ZeroA0中一次 Agent 会话context不仅是内存中的运行状态还是一份可导出、可迁移、可再导入的 JSON 数据。本文以 chat_export 端点的 DOX 档案 为核心骨架结合 端点实现、API 基础框架 与 会话持久化模块 的源码完整讲清/api/chat_export的请求/响应契约、鉴权与 CSRF 约束、上下文序列化格式以及它与chat_load、压缩备份等功能如何构成导出—导入闭环帮助你理解 A0 会话数据的可编程存取方式。端点的职责边界与 DOX 契约A0 的api/目录采用刻意保持扁平intentionally flat的结构每个 HTTP 端点对应一个文件且每份实现文件旁边都有一份同名的.py.dox.md档案文件。chat_export.py.dox.md 明确了两者的分工chat_export.py 拥有运行时实现chat_export.py.dox.md 拥有关于该实现的持久化说明——职责、契约、副作用与验证方式并要求随源码同步更新。DOX 档案对实现做了如下约束性描述与源码逐项对应DOX 契约项源码印证ExportChat必须继承helpers.api.ApiHandlerHTTP 处理器基类WebSocket 处理器则继承helpers.ws.WsHandlerapi/chat_export.py 第 5 行class ExportChat(ApiHandler)定义process(self, input: Input, request: Request) - Output异步方法api/chat_export.py 第 6 行观察到的副作用区域文件系统写入filesystem writes导出内容来源于会话数据同模块的持久化写入见 persist_chat 常量定义导入的依赖区域helpers、helpers.apiapi/chat_export.py 第 1–3 行调用的关键 helper/类self.use_context、persist_chat.export_json_chat、Exception分别在实现体内被调用DOX 的 Work Guidance 部分还给出维护规范除非端点契约显式变更必须保留鉴权、CSRF、loopback 与 API key 检查payload 形状变化时要同步更新前端调用方、插件调用方和测试非 JSON 响应文件、重定向、特定状态码应使用helpers.api.Response。这些约束下文会逐条落到源码上验证。端点实现逐行剖析请求、上下文定位与响应形状chat_export.py 全文仅 17 行但完整覆盖了参数校验 → 上下文定位 → 序列化 → 响应四步from helpers.api import ApiHandler, Input, Output, Request, Response from helpers import persist_chat class ExportChat(ApiHandler): async def process(self, input: Input, request: Request) - Output: ctxid input.get(ctxid, ) if not ctxid: raise Exception(No context id provided) context self.use_context(ctxid) content persist_chat.export_json_chat(context) return { message: Chats exported., ctxid: context.id, content: content, }契约可以归纳为请求JSON bodyPOST参数类型必填说明ctxidstring是要导出的上下文会话ID缺失或为空时抛出No context id provided响应成功时HTTP 200 JSON字段类型说明messagestring固定为Chats exported.ctxidstring实际导出上下文的 ID取自context.idcontentstring整个上下文序列化为 JSON 后的字符串即可直接落盘/传输的备份内容失败路径process抛出的任何异常会被基类的handle_request捕获经format_error格式化后以 500 text/plain返回见 helpers/api.py 第 92–95 行。use_context在锁内定位 AgentContextself.use_context(ctxid)是ApiHandler提供的便捷方法helpers/api.py 第 98–100 行 将其转发到 helpers/context_utils.py 中的共享实现。其逻辑值得注意def use_context(lock: ThreadLockType, ctxid: str, create_if_not_exists: bool True): with lock: # 在服务器线程锁内操作 got AgentContext.use(ctxid) if got: return got if create_if_not_exists: context AgentContext( configinitialize_agent(), idctxid, set_currentTrue ) return context else: raise Exception(fContext {ctxid} not found)从源码结构看chat_export调用时未传create_if_not_exists因此走默认的True分支若指定ctxid在内存中不存在会创建一个空壳上下文再对其序列化。这意味着对不存在的 ID 调用导出不会 404而是返回一个仅含该 ID 与默认值的最小会话 JSON——调用方在集成时应先确认ctxid的有效性例如通过前端会话列表。路由分发与安全契约端点如何被挂载、如何被保护DOX 要求保留 authentication, CSRF, loopback, and API-key checks这些检查的实际执行位置在 helpers/api.py 的框架层而非端点自身。声明式安全开关ApiHandler 基类 通过类方法声明每个端点的安全属性ExportChat全部继承默认值类方法默认值对 chat_export 的语义requires_auth()True需要会话级登录鉴权requires_csrf()返回requires_auth()即True请求必须携带有效的 CSRF tokenrequires_api_key()False不要求X-API-KEYrequires_loopback()False不限制为仅回环地址get_methods()[POST]仅接受 POST其余方法返回 405装饰器栈的组装register_api_route 启动时向 Flask 注册单一动态规则/api/path:path第 267–272 行所有内置端点按文件名即路径分发请求/api/chat_export时解析到api/chat_export.py用load_classes_from_file取出其中第一个ApiHandler子类再按开关从内到外包裹安全装饰器第 249–264 行handler_fn call_handler if handler_cls.requires_csrf(): # chat_export: True handler_fn csrf_protect(handler_fn) if handler_cls.requires_api_key(): # chat_export: False handler_fn requires_api_key(handler_fn) if handler_cls.requires_auth(): # chat_export: True handler_fn requires_auth(handler_fn) if handler_cls.requires_loopback(): # chat_export: False handler_fn requires_loopback(handler_fn)具体检查逻辑requires_auth取login.get_credentials_hash()若服务端配置了凭据哈希而当前 session 不匹配则重定向到登录页未配置凭据时直接放行csrf_protect要求请求的X-CSRF-Token头或csrf_token_runtime_idCookie 与 session 中的 token 一致否则 403handle_request解析 JSON body 为input解析失败时退化为空 dict调用processdict 返回值自动序列化为application/json200 响应Response实例则原样透传。因此对chat_export的标准调用形态是POST/api/chat_export携带登录 session、有效 CSRF token 与 JSON body{ctxid: 上下文ID——这正是 DOX Work Guidance 中不要绕过安全层的运行时含义。此外分发层支持插件扩展形如plugins/plugin_name/handler的路径会到插件目录下的api/子目录加载处理器第 229–240 行且 watchdog 会在api/目录的.py文件变化时清空处理器缓存register_watchdogs所以端点代码是热加载的。序列化核心export_json_chat 与上下文字段格式真正决定导出内容质量的是 helpers/persist_chat.py 中的持久化逻辑。导出入口export_json_chat 只有两行核心逻辑def export_json_chat(context: AgentContext): Export context as JSON string data _serialize_context(context) js _safe_json_serialize(data, ensure_asciiFalse) return js它与会话的常规落盘save_tmp_chat写入usr/chats/ctxid/chat.json见 CHATS_FOLDER 与 CHAT_FILE_NAME 常量 及 save_tmp_chat共用同一套序列化函数——导出的 JSON 与 A0 磁盘上存储的会话文件是同构的这是导出文件可直接用chat_load导入的根本保证。_serialize_context输出的字段表_serialize_context 生成的顶层结构如下字段来源说明idcontext.id上下文 IDnamecontext.name会话名created_at/last_messagecontext.created_at/context.last_message经Localization.get().serialize_datetime(...)本地化序列化缺失时回退为纪元时间_fallback_datetime_isotypecontext.type.value上下文类型枚举值字符串agents_serialize_agent沿DATA_NAME_SUBORDINATE链遍历主 Agent 及其整条从属 Agent 链每个元素含number、agent_profile、data、historystreaming_agentcontext.streaming_agent.number当前流式 Agent 的编号无则为 0导入时据此在从属链中重新定位agent_profilecontext.agent0.config.profile等会话级 agent 档案名log_serialize_log日志 GUID、进度与日志条目序列化时持log._lock防并发修改且只保留最近LOG_SIZE 1000条常量定义data/output_datacontext.data/context.output_data过滤掉以_开头的内部键后原样导出_serialize_agent 对每个 Agent 输出number、agent_profile、非下划线前缀的data以及agent.history.serialize()产生的历史——即完整的消息与工具调用历史都在导出范围内。_safe_json_serialize对不可序列化值的防御性裁剪_safe_json_serialize 用一个json.dumps探测函数is_json_serializable递归遍历对象dict/list 中不可序列化的项被整体剔除其他不可序列化值置None。可以推断这一层防御是为了保证任何运行态上下文即使内存里挂着不可 JSON 化的对象都不会让导出抛异常——导出总是成功代价是极个别字段被静默丢弃。ensure_asciiFalse则保留中文等非 ASCII 字符的可读性。闭环chat_load 导入与压缩备份对同一序列化的复用chat_export并不是孤立端点。反向端点 api/chat_load.py 的LoadChats接收{chats: [JSON 字符串, ...]}调用 load_json_chatsdef load_json_chats(jsons: list[str]): Load contexts from JSON strings ctxids [] for js in jsons: data json.loads(js) if id in data: del data[id] # remove id to get new ctx _deserialize_context(data) ctxids.append(ctx.id) return ctxids注意del data[id]注释导入时主动删除原 ID为会话分配全新 ID——导出文件是模板反复导入会生成多份独立副本而不会覆盖原会话。反序列化由 _deserialize_context 完成它按streaming_agent编号沿DATA_NAME_SUBORDINATE链重建从属 Agent 关系。除导出→导入迁移外export_json_chat还被 压缩插件的备份逻辑 复用_save_pre_compaction_backup在压缩compaction会话前调用export_json_chat把原始会话快照写入usr/chats/ctxid/backups/pre-compact-timestamp.json——即同一份序列化既是用户备份格式也是内部安全网格式。测试侧同样围绕这一契约构建tests/test_api_chat_lifetime.py 用export_json_chat序列化上下文、断言data中的自定义字段如lifetime_hours存活再用_deserialize_context反序列化验证往返一致tests/test_chat_compaction.py 则对压缩流程中的export_json_chat做 mock 验证。这也回应了 DOX Verification 一节运行端点级或 API 测试无聚焦测试时做冒烟检查的要求。前端调用方式与外部集成A0 WebUI 中保存会话按钮的完整调用链位于 chats-store.js// Save current chat async saveChat() { const context this.selected || getContext(); const response await sendJsonData(/chat_export, { ctxid: context }); if (!response) { toast(No response returned., error); } else { this.downloadFile(response.ctxid .json, response.content); toast(Chat file downloaded., success); } }即对当前选中会话调用/chat_export拿到content后以ctxid.json为文件名触发浏览器下载配套的 loadChats 则让用户选择多个.json文件上传经FileReader读为字符串数组后 POST 给/chat_load成功提示 Chats loaded.。这构成 WebUI 侧完整的导出/导入配对。对于外部集成脚本或 API 客户端基于 helpers/api.py 的分发与安全层事实调用要点是# 1) POST /api/chat_exportbody 仅一个字段 curl -c cookies.txt -X POST http://host/api/chat_export \ -H Content-Type: application/json \ -d {ctxid: CONTEXT_ID} # 2) 若服务端启用了登录需先通过登录流程获得 session 与 CSRF token # 并在导出请求中携带X-CSRF-Token 头或 csrf_token_runtime_id Cookie # 见 csrf_protect 与 requires_auth 的实现 curl -b cookies.txt -c cookies.txt -X POST http://host/api/chat_export \ -H X-CSRF-Token: TOKEN -H Content-Type: application/json \ -d {ctxid: CONTEXT_ID}成功响应形如{ message: Chats exported., ctxid: 6f1c2a..., content: {\id\: \6f1c2a...\, \name\: \...\, \agents\: [...], \log\: {...}} }把content原样写入磁盘即得到一个可被chat_load重新导入的会话文件。需要注意的前提该端点默认requires_auth()True且仅接受 POST未带有效 session/CSRF token 的请求会被拦截而不是返回数据。小结维护该端点时的核对清单以 DOX 档案 为契约基线改动 chat_export.py 时应核对契约不变请求只依赖ctxid响应保持message/ctxid/content三字段改 payload 时按 DOX 要求同步更新 chats-store.js 前端调用、插件调用方与测试序列化格式稳定content的结构由 _serialize_context 决定任何字段增删都会同时影响磁盘存储usr/chats/ctxid/chat.json、chat_load导入与压缩备份应结合 tests/test_api_chat_lifetime.py 的往返测试回归验证安全层不动ExportChat未覆写任何requires_*开关鉴权、CSRF、仅 POST 均由 ApiHandler 默认值与 register_api_route 的装饰器组装 保证除非契约显式变更不应为其追加requires_api_key之外的新豁免。按上述清单核对chat_export端点即可在保持 DOX 契约、前端行为与测试预期一致的前提下安全演进。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考