1. 为什么我要把百度网盘交给 Agent 去操作百度网盘自动化这件事听起来像是写个脚本调 API就完事真动手才发现坑比想象中多。我最初的目标很朴素让 Hermes Agent 自己完成数字商品的交付闭环——找到指定文件、生成分享链接、把提取码回填到订单系统。这套动作如果每次都要人工点一遍那 Agent 就只是个聊天玩具谈不上自动化。问题出在怎么让 Agent 操作网页这一步。我试过两条路都撞墙了。第一条是 Hermes 自带的 browser-use 工具。它启动的是独立的浏览器实例打开百度首页就直接弹滑块验证码页面根本进不去。原因不难理解一个全新的、没有任何浏览历史的浏览器环境在百度的风控模型里就是高危对象。第二条是我自己写的 computer-use-win能控制本地桌面靠截屏 大模型理解画面 点坐标来操作。听起来很酷实际很鸡肋。百度网盘的页面结构复杂按钮位置随窗口大小、缩放比例、页面滚动状态变化点偏是常态。更麻烦的是每次网页改版都要重新适配坐标维护成本高得离谱。而且每点一次都要过一次视觉理解token 烧得心疼操作还卡顿。两条路走下来我得到一个很关键的判断Agent 需要的是网页里的数据不是网页里的像素。既然我已经在 Chrome 里登录了百度网盘为什么不让 Agent 直接复用这个登录态去调页面自己的接口这就是 bb-browser 的切入点。它不新开浏览器而是连接你正在用的 Chrome在页面上下文里执行 JS直接调网页自身的 fetch 接口。你的登录态、你的 cookie、你的浏览习惯全都现成可用。本文就把这套方案的 adapter 配置骨架和 Chrome 侧验证动作完整拆开你可以照着在本地复现。2. TaoToken 前置给 Agent 一个稳定的模型底座在讲 adapter 之前得先解决一个容易被忽略的前置问题Hermes Agent 本身需要调用大模型来理解任务、生成操作序列。如果你的模型接入层不稳定Agent 会在思考阶段就卡住后面的浏览器自动化根本跑不起来。我现在的做法是把模型调用统一走 TaoToken。它的定位是给开发者和 Agent 应用提供模型接入能力官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。对这套百度网盘自动化来说它承担的是 Hermes Agent 的大脑角色——解析我的自然语言指令、决定调用哪个 adapter、处理返回的 JSON 结果。为什么单独拎出来说因为浏览器自动化是长链路任务一次完整操作可能涉及十几轮模型调用。如果模型侧频繁超时或限流整个流程的稳定性会被拖垮。把模型接入层固定下来后面排查问题时才能确定到底是浏览器的问题还是模型的问题。你需要先在控制台创建一个 API Key地址是 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。拿到 Key 之后Hermes Agent 的模型配置里填上对应的 base_url 和 key 即可。如果你用的是 Claude Code 这类编码工具来辅助写 adapter可以参考 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里的接入说明。这一步不复杂但它是后面所有操作的前提。模型底座稳了我们再谈浏览器侧的事。3. bb-browser 的 adapter 配置骨架bb-browser 的核心思路一句话概括你的真实浏览器就是 API。它启动一个 daemon 连接你正在用的 Chrome通过 Chrome DevTools 协议在页面上下文里执行 JS。整个链路是这样的你的 Chrome已登录百度网盘 └─ bb-browser daemon连接 Chrome DevTools ├─ site adapter封装高频网站操作 ├─ eval在页面跑任意 JS └─ fetch用页面登录态调接口它内置了 site adapter 机制社区包里已经封装了百度、GitHub、知乎等几十个常用网站的命令。百度网盘不在其中所以需要自己写。先安装并拉取社区 adapter 包npm install -g bb-browserlatest bb-browser site updateadapter 的目录结构约定如下每个操作一个 JS 文件在pan.baidu.com域名的 tab 上下文里执行~/.bb-browser/bb-sites/baidu-pan/ ├── list.js # 列文件 ├── find.js # 按文件名查找 └── share.js # 创建分享链接以find.js为例它的骨架长这样// ~/.bb-browser/bb-sites/baidu-pan/find.js // 在 pan.baidu.com 页面上下文执行复用当前登录态 export default async function ({ args, page }) { const keyword args[0]; if (!keyword) throw new Error(usage: find filename); // 调用百度网盘页面自身的搜索接口 const url /api/search?key${encodeURIComponent(keyword)}dir/; const res await page.fetch(url, { method: GET }); const data await res.json(); // 只返回结构化字段避免把整个响应体丢给模型 return (data.list || []).map((item) ({ name: item.server_filename, path: item.path, fs_id: item.fs_id, size: item.size, })); }这里有几个设计要点值得说明。第一adapter 里用的是page.fetch而不是 Node 的fetch前者在页面上下文执行自动带上当前 Chrome 的登录 cookie后者在 Node 进程里跑拿不到登录态。第二返回值做了裁剪只保留name/path/fs_id/size这几个字段因为完整响应体可能有几十 KB全塞给模型既浪费 token 又干扰判断。第三参数校验放在最前面参数缺失时直接抛错避免 Agent 拿到一个语义不明的空结果。list.js和share.js的结构类似区别在于调用的接口路径和返回字段。share.js需要额外处理提取码参数把用户传入的 4 位码拼进请求体。配置完成后用一条命令验证 adapter 是否被正确加载bb-browser site baidu-pan/list --json如果返回结构化 JSON 而不是报错说明 adapter 骨架已经通了。4. Chrome 侧验证从列文件到生成分享链接adapter 写好了不代表能用得在真实 Chrome 里逐步验证。我习惯按由简到繁的顺序走一遍每一步都确认输出符合预期再往下。4.1 确认 Chrome 处于可连接状态bb-browser 需要连接一个已经启动、且开启了调试端口的 Chrome。如果你平时用的就是普通 Chrome需要以调试模式重启一次# macOS 示例Windows 把路径换成 chrome.exe 的实际位置 /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \ --remote-debugging-port9222 \ --user-data-dir$HOME/.chrome-bb-profile注意--user-data-dir指向一个独立目录这样不会污染你日常的 Chrome 配置。启动后在这个 Chrome 里手动登录百度网盘保持标签页打开。然后确认 bb-browser 能看到这个 tabbb-browser tab list --json输出里应该能找到pan.baidu.com对应的短 ID比如713c。这个 ID 后面会用到。4.2 验证列文件bb-browser site baidu-pan/list --json预期返回一个数组每项包含文件名、路径、大小、fs_id。如果返回空数组先确认当前 tab 确实停在网盘文件列表页而不是某个子目录或分享页。4.3 验证按文件名查找bb-browser site baidu-pan/find earn-50-rmb-product.zip --json我实测下来这一步返回的目标文件信息是这样的name: earn-50-rmb-product.zip path: /earn-50-rmb-product.zip fs_id: 295531441272474 size: 7080拿到fs_id是关键后面的分享操作要靠它定位文件。4.4 验证创建分享链接bb-browser site baidu-pan/share earn-50-rmb-product.zip a8k2 --json第二个参数a8k2是自定义提取码。返回结果里会包含永久分享链接和提取码。到这一步文件查找和分享链接生成已经全自动化了。4.5 上传最难的一关adapter 只能在页面上下文跑 JS没法读取本地任意路径的文件——这是浏览器安全模型决定的绕不过去。所以上传改用本地脚本 浏览器上下文的组合Node 本地读取文件、计算 MD5然后通过 bb-browser 在网盘 tab 上执行一段自定义 JS依次调用网盘的内部接口完成文件创建和写入。先找到网盘 tab 的短 IDbb-browser tab list --json # 找到 pan.baidu.com 的短 ID比如 713c然后执行上传脚本BB_BROWSER_TAB713c node scripts/baidu-pan-upload.js \ --file upload-test.txt \ --name bb-upload-test.txt预期输出{ ok: true, path: /bb-upload-test.txt, size: 59, create: { fs_id: 288039632014397, server_filename: bb-upload-test.txt, errno: 0 } }最后用 find 确认文件确实存在bb-browser site baidu-pan/find bb-upload-test.txt --json能查到就说明整条链路通了。上传脚本目前只处理 20MB 以内的小文件不做覆盖操作也不涉及删除和重命名这是有意加的安全边界。5. 本篇常见错排查这套方案跑通之前我在几个地方反复卡过。把排查清单列出来你遇到类似现象时可以对照。现象一bb-browser tab list看不到网盘 tab。大概率是 Chrome 没以调试模式启动或者--user-data-dir指向的目录和你登录网盘的那个 Chrome 不是同一个。确认启动命令里的 profile 目录一致并且网盘页面确实在这个 Chrome 里打开着。现象二adapter 执行报fetch is not defined。说明 adapter 里用了 Node 的全局 fetch而不是page.fetch。在页面上下文里必须用 bb-browser 注入的page.fetch才能带上登录态。现象三find 返回空数组但文件明明存在。检查搜索接口的dir参数。默认我写的是根目录/如果文件在子目录里需要把dir改成对应路径。另外文件名大小写敏感Earn-50和earn-50搜出来结果不同。现象四share 返回errno: -6。通常是fs_id传错了或者提取码格式不合法必须是 4 位字母数字组合。先用 find 拿到正确的fs_id再调 share。现象五上传脚本卡在 MD5 计算。大文件计算 MD5 会阻塞脚本里应该用流式读取。如果你传的是几百 MB 的文件先确认脚本是否支持分片当前版本只处理 20MB 以内。现象六Agent 调用 adapter 时参数顺序错乱。这是模型侧的问题不是 adapter 的问题。可以在 Hermes Agent 的工具描述里把参数顺序和示例写清楚或者干脆把 adapter 封装成带命名参数的原生工具减少模型自由发挥的空间。排查时有个通用思路先用命令行手动跑一遍 adapter确认它本身没问题再去查 Agent 的调用逻辑。把浏览器侧和模型侧的问题分开定位效率会高很多。6. 把这条链路接进你的 Agent 工作流到这里百度网盘的 list、find、share、upload 四个操作都已经能在命令行里稳定复现了。接下来要做的是把它们接进 Hermes Agent 的工具层。如果你只是想让 Agent 能对话式地操作网盘可以直接在模型对话里测试指令解析效果地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 。输入类似帮我找到 earn-50-rmb-product.zip 并生成提取码 a8k2 的分享链接看 Agent 能否正确拆解成 find share 两步调用。如果你打算长期跑这套自动化比如做成数字商品交付的常驻服务建议用 Coding Plan 来承载 Agent 的编码和调度逻辑地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。它更适合这种需要持续迭代、频繁调试的场景。接入相关的细节比如工具描述怎么写、参数 schema 怎么定义可以参考接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。API Key 的管理在 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。这套方案最关键的判断不是某个技术细节而是方向上的选择让 Agent 用你已登录的浏览器干活比让 Agent 假装成你干活靠谱得多。你已经登录了Agent 就直接用——不需要处理验证码、不需要构造 cookie、不需要无头浏览器。你的登录态就是 Agent 的能力底座。下一步我打算把这套操作封装成 Hermes Agent 的原生工具让找文件、上传、生成分享链接都能一条命令完成。adapter 目录已经沉淀在本地下次直接复用不用重新适配。