★ FEATURED ARTICLE 1. 为什么我要手动备份豆包智能体的聊天数据先说说我自己的情况。我在豆包上搭了三个智能体一个用来做技术问答知识库一个用来跑销售话术演练还有一个是给团队新人做入职培训的。用了大概四个月积累的对话记录少说也有几千条。直到有一次我手贱清理浏览器缓存把本地存储的会话记录全干掉了那个知识库智能体的上下文记忆直接归零我才意识到问题的严重性。豆包智能体的聊天数据本质上存在两个地方一是服务端的会话历史二是你本地浏览器或客户端里的缓存。服务端的数据你没法直接控制但本地这部分如果你不主动备份一次误操作、一次系统重装、甚至一次客户端异常退出都可能让积累的对话记录灰飞烟灭。这不是危言耸听我身边至少有三个做智能体开发的朋友踩过这个坑。这篇内容就是把我自己摸索出来的手动备份方案完整拆解一遍。核心思路不复杂通过浏览器开发者工具或者客户端的数据接口把智能体的对话记录批量抓取下来然后结构化存储到本地。适合所有在豆包上搭建过智能体、并且希望保留对话数据做后续分析或迁移的人。不管你是刚接触智能体搭建的新手还是已经在做多智能体编排的老手这套方法都能直接抄作业。注意本文讨论的是对你自己创建的智能体、你自己产生的对话数据进行备份不涉及任何平台数据的非授权获取。所有操作都在个人使用场景下完成。2. 备份方案的整体设计与技术选型思路2.1 为什么不用截图和复制粘贴最原始的办法就是手动截图或者一条条复制粘贴。我试过一个两百条对话的智能体复制粘贴花了将近四十分钟而且格式全乱角色标识丢失时间戳也没有。截图就更不用说了后续想检索关键词根本不可能。所以我们需要的是一个批量导出方案。批量导出的核心诉求有三个第一能一次性拿到某个智能体的全部对话记录第二保留对话的结构化信息包括角色、时间、内容第三导出格式要方便后续处理JSON或者CSV都行。2.2 两条技术路线的取舍目前可行的方案大致分两类。一类是基于浏览器开发者工具的网络请求分析。豆包网页版在加载对话历史时会向服务端发送分页请求返回的数据是结构化的JSON。你可以在Network面板里找到这个请求分析它的参数规律然后手动构造分页请求把数据拉全。这个方案的好处是不依赖任何第三方工具纯手工操作可控性最强。缺点是每次都要手动翻页、手动复制对话量大的时候比较费时间。另一类是利用浏览器插件或脚本工具做半自动化抓取。比如通过Tampermonkey注入一段脚本自动遍历分页请求并把结果汇总下载。这个方案效率高但需要你对JavaScript有基本了解而且脚本需要根据页面结构变化做维护。我个人的建议是如果你只是偶尔备份一两个智能体用第一类方案就够了十分钟搞定。如果你有几十个智能体需要定期备份那值得花时间写一个脚本。下面我会把两种方案都讲清楚你根据自己的情况选。2.3 数据存储格式的选择导出后的数据存成什么格式这个看似小事其实影响后续使用。我对比过几种常见格式格式优点缺点适用场景JSON结构完整保留嵌套关系不方便直接用表格软件打开后续做程序化处理CSV可直接用Excel打开嵌套结构需要扁平化容易丢信息快速浏览和筛选Markdown可读性最好不适合程序解析归档和分享SQLite支持复杂查询需要额外工具打开大规模数据管理我的做法是JSON和CSV各存一份。JSON作为原始备份CSV作为快速查阅版本。如果你后续想把对话数据导入到其他智能体平台做训练或微调JSON格式是最通用的。3. 基于浏览器开发者工具的批量导出实操3.1 准备工作与环境确认首先确认你用的是豆包网页版并且已经登录了你的账号。然后打开你要备份的那个智能体进入对话界面。接下来按F12打开开发者工具切换到Network网络面板。这里有个关键操作在Network面板里勾选Preserve log保留日志否则页面跳转时之前的请求记录会被清空。然后选择Fetch/XHR过滤器这样只显示数据请求过滤掉图片、样式等无关请求。实操心得我习惯先把Network面板打开再刷新一次页面。这样能确保捕获到页面加载时的所有请求不会遗漏。3.2 定位对话数据接口刷新页面后在Network面板里滚动对话区域让页面加载更多历史消息。这时候你会看到新的请求不断出现。你需要找到那个返回对话记录的接口。怎么判断哪个是对话接口看响应内容。点击每个请求查看Response标签页如果返回的JSON里包含对话内容、角色标识、时间戳这些字段那就是它了。通常这个接口的URL里会带有conversation、message、history之类的关键词。找到之后重点看这个请求的几个信息Request URL接口地址Request Method通常是GET或POSTRequest Headers里面会有认证信息比如Cookie或TokenQuery Parameters或Request Payload分页参数比如offset、limit、cursor3.3 分析分页参数规律这是整个流程中最关键的一步。豆包的对话接口通常采用游标分页或偏移量分页。你需要通过对比多次请求的参数变化找出分页规律。举个我实际遇到的例子第一次请求的URL里带有offset0limit20第二次滚动后变成offset20limit20第三次是offset40limit20。这就很明确了每次偏移量增加20直到返回的数据为空为止。另一种常见的是游标分页参数可能是cursorxxxxx每次返回的JSON里会带一个next_cursor字段下次请求时把这个值传回去就行。注意不同版本的豆包网页端接口参数命名可能不同。有的用offset/limit有的用page/page_size有的用cursor。你需要根据实际抓到的请求来判断不要死记硬背。3.4 手动构造请求批量拉取搞清楚分页规律后就可以手动构造请求了。最简单的方式是在开发者工具的Console控制台里用fetch发请求。假设你找到的接口地址是https://www.doubao.com/api/conversation/messages分页参数是offset和limit认证信息在Cookie里浏览器会自动带上那么你可以这样操作// 在Console中执行批量拉取对话记录 async function exportMessages(conversationId, totalLimit) { let allMessages []; let offset 0; const limit 20; while (offset totalLimit) { const url https://www.doubao.com/api/conversation/messages?conversation_id${conversationId}offset${offset}limit${limit}; const response await fetch(url, { method: GET, credentials: include // 自动携带Cookie }); const data await response.json(); if (!data.messages || data.messages.length 0) { break; // 没有更多数据了 } allMessages allMessages.concat(data.messages); offset limit; // 加个延迟避免请求过于频繁 await new Promise(resolve setTimeout(resolve, 500)); } // 下载为JSON文件 const blob new Blob([JSON.stringify(allMessages, null, 2)], {type: application/json}); const a document.createElement(a); a.href URL.createObjectURL(blob); a.download doubao_backup_${conversationId}_${Date.now()}.json; a.click(); console.log(导出完成共 ${allMessages.length} 条消息); } // 调用时把conversationId换成你实际的会话ID exportMessages(your_conversation_id_here, 5000);这段代码的逻辑很直白从offset0开始每次拉20条拉完就增加偏移量直到没有数据或者达到你设定的上限。最后把所有消息合并成一个JSON文件下载到本地。实操心得那个500毫秒的延迟很重要。我一开始没加延迟连续发了十几个请求结果被限流了后面几个请求全部返回错误。加上延迟之后就很稳。3.5 导出后的数据整理下载下来的JSON文件结构大概是这样的[ { role: user, content: 帮我写一个Python的快速排序, timestamp: 1712345678000 }, { role: assistant, content: 好的这是一个快速排序的实现..., timestamp: 1712345685000 } ]如果你需要CSV版本可以用Python或者在线工具做转换。我一般用Python的pandas库三行代码搞定import pandas as pd import json with open(doubao_backup.json, r, encodingutf-8) as f: data json.load(f) df pd.DataFrame(data) df[timestamp] pd.to_datetime(df[timestamp], unitms) df.to_csv(doubao_backup.csv, indexFalse, encodingutf-8-sig)注意encodingutf-8-sig这个参数不加的话Excel打开中文会乱码。这个坑我踩过不止一次。4. 半自动化脚本方案与效率提升技巧4.1 什么情况下值得写脚本如果你只有一两个智能体手动方案完全够用。但如果你像我一样管理着多个智能体而且需要每周或每月定期备份那手动操作就有点折磨人了。这时候可以考虑用Tampermonkey写一个用户脚本把整个流程自动化。Tampermonkey是一个浏览器扩展允许你在特定网页上注入自定义JavaScript代码。你写一段脚本让它自动检测当前页面是哪个智能体、自动遍历分页请求、自动下载备份文件。整个过程你只需要点一下按钮。4.2 脚本的核心逻辑拆解脚本的核心逻辑分四步第一步识别当前页面。通过URL或者页面上的DOM元素判断当前打开的是哪个智能体。第二步获取认证信息。因为脚本运行在页面上下文里可以直接读取Cookie或者localStorage里的Token不需要手动处理认证。第三步遍历分页请求。和手动方案一样从offset0开始循环请求直到数据拉完。第四步触发下载。把汇总的数据转成Blob创建一个隐藏的a标签模拟点击下载。4.3 脚本方案的注意事项脚本方案虽然效率高但有几个坑需要注意。首先是页面结构变化。豆包的网页端会不定期更新接口地址、参数命名、返回结构都可能变。你的脚本需要跟着维护否则某天突然就不工作了。我的做法是在脚本里加一个版本检测如果接口返回的数据结构不符合预期就弹窗提醒我手动检查。其次是请求频率控制。脚本跑起来之后请求发得很快容易被限流。一定要在循环里加延迟我一般设置300到500毫秒。如果对话量特别大比如上万条建议分批执行每次拉一千条左右就停一下。最后是数据去重。有时候因为网络重试或者分页边界问题可能会拉到重复的消息。在保存之前最好做一次去重用消息ID或者时间戳加内容做唯一标识。提示如果你不熟悉JavaScript但又想用脚本方案可以找现成的开源脚本做参考。搜索关键词用豆包 对话导出 脚本或者智能体 聊天记录 备份 插件都能找到一些社区分享的代码。但要注意审查代码安全性不要运行来源不明的脚本。5. 常见问题排查与避坑指南5.1 请求返回401或403错误这是最常见的问题通常意味着认证信息失效了。解决方法很简单刷新页面重新登录然后重新抓取请求。如果你用的是脚本方案检查一下脚本读取Cookie的方式是否正确。有时候豆包会更新认证机制比如从Cookie换成Header里的Token你需要跟着调整。5.2 分页数据拉不全明明对话有几百条但只拉到了几十条就停了。这种情况一般是分页参数没搞对。回去检查一下是不是offset的步长设错了是不是limit有上限有些接口限制单次最多返回50条你设成100的话实际只返回50条但你的offset按100递增中间就漏掉了。解决办法是先用小limit测试确认单次实际返回的条数然后按实际返回条数来递增offset。5.3 导出的JSON中文乱码这个问题通常出现在后续处理环节而不是导出环节。JSON文件本身是UTF-8编码的但如果你用某些编辑器打开时选了错误的编码格式就会显示乱码。用VS Code或者Notepad打开时手动选择UTF-8编码即可。如果是转CSV之后乱码参考前面提到的utf-8-sig方案。5.4 对话内容中包含特殊字符导致解析失败有些对话内容里包含换行符、引号、emoji等特殊字符在转CSV的时候容易出问题。解决办法是在导出时对内容字段做转义处理或者直接用JSON格式保存避免CSV的转义问题。如果必须用CSV建议用专业的CSV库来处理不要手动拼接字符串。5.5 备份频率和版本管理最后一个容易被忽视的问题是备份文件怎么管理。我一开始是每次备份都存一个新文件结果文件夹里堆了几十个版本根本分不清哪个是哪个。后来我改成了按日期建文件夹每次备份的文件名里带上智能体名称和日期比如知识库智能体_20250115.json。同时保留最近三个月的备份更早的归档到移动硬盘。问题现象可能原因排查方向解决方案401/403错误认证失效检查Cookie/Token重新登录后重试数据拉不全分页参数错误对比多次请求参数调整offset步长中文乱码编码格式不对检查文件编码使用UTF-8或utf-8-sig解析失败特殊字符检查内容字段改用JSON格式请求被限流频率过高查看返回状态码增加请求间隔6. 备份数据的后续利用与扩展思路数据备份下来不是终点怎么用起来才是关键。我自己把导出的对话数据做了几件事这里分享一下。第一件是做知识库的增量更新。我把智能体对话中高频出现的问题和优质回答提取出来整理成FAQ文档再喂回给智能体做上下文增强。这样智能体的回答质量会越来越高。第二件是做对话质量分析。用Python对导出的数据做统计比如平均对话轮次、用户满意度关键词出现频率、常见问题分类等。这些数据对优化智能体的提示词很有帮助。第三件是迁移到其他平台。如果你后续想把这个智能体迁移到别的平台对话历史就是最宝贵的训练素材。JSON格式的数据几乎可以直接导入大多数智能体框架。实操心得导出数据里的时间戳字段很有价值。你可以用它来分析用户活跃时段从而优化智能体的响应策略。比如发现大部分对话集中在晚上八点到十点那你可以在这个时段之前提前预热智能体的缓存。另外如果你在做多智能体编排每个智能体的对话数据可以分别备份然后通过一个统一的索引文件来管理。索引文件里记录每个智能体的名称、备份时间、消息数量、文件路径。这样即使你有几十个智能体也能快速定位到需要的数据。最后说一个我踩过的坑不要把所有备份文件放在同一个文件夹里。我有一次不小心把整个文件夹删了幸好之前往移动硬盘同步过一份。现在我采用的是本地移动硬盘对象存储三副本策略虽然听起来有点过度但数据这东西丢了就真的找不回来了。
阅读完成 · 觉得有帮助？
