技术知识库 · 技术指南 · · 国科智飞 Gavin
用 Codex 自动上架闲鱼：一次 MCP 实战拆解
两个 MCP 服务 + Codex 调用：从百度网盘取素材、在闲鱼生成商品草稿。含版本坑、登录误判与四层排查法。
MCP 的教程很多，但真正从零跑通一条完整业务链路、并把踩坑过程写清楚的很少。锦鲤（X @jinli_lg）在 2026 年 9 月发过一篇实操：在 Windows 上用 Codex 同时调用百度网盘 MCP 和闲鱼 MCP，让 AI 从网盘找资料，再自动填写闲鱼商品草稿（原文：https://x.com/jinli_lg/status/2097278105257934923）。
对应的开源项目是 mousepotato/baidu-netdisk-xianyu（GitHub 约 50 星）。我们把这套流程、踩坑和排查方法拆开来看。
架构：两个 MCP 服务 + 一个调用者
这个项目不是打包好的「销售机器人」，而是两个独立的 MCP 服务，由 Codex 当中间调用者：
- 百度网盘 MCP（文件侧）：通过百度开放平台 API 获取用户信息、容量和文件列表，支持搜索、移动、重命名、删除和分享，认证用百度 OAuth Access Token；
- 闲鱼 MCP（网页侧）：用 Playwright 打开闲鱼，检查登录状态、搜索市场、填写商品草稿、截图，确认后发布或管理，认证用 Cookie；
- Codex（调用者）：按自然语言决定调用哪个工具，但不会自动补出不存在的能力；
- 本地素材（兜底）：闲鱼上传需要本地图片路径或 URL，网盘返回的 fs_id 只是文件标识，中间必须有人把有权使用的素材准备到本机。
整条链路分四层：环境（Python、uv、Chrome）→ MCP 握手（服务器能启动并能 list_tools）→ 账号认证（闲鱼登录、百度 Token）→ 业务调用。报错时按层排查，不要反复重装全部依赖。
实战踩坑记录
一、FastMCP 版本坑。 仓库用的是 FastMCP 1.x 的导入方式，但依赖声明只锁了下限，装到 2.x 后 API 迁移直接报错。作者的解法很务实：不改代码，锁死 1.x 版本。重装后闲鱼侧返回 11 个工具、网盘侧返回 16 个工具，握手成功。教训是「依赖装好」不等于「接入成功」，必须走最小探针：启动服务 → 发初始化请求 → list_tools，三层都就位才算通。
二、Playwright 改用本机 Chrome。 国内下载 Chromium 很慢，作者补了一个可选环境变量让 Playwright 驱动本机 Chrome，省掉了约 192MB 的下载。另外先跑一个空页测试脚本，把依赖、Chrome 路径、Playwright 启动三件事一次性验证清楚。
三、登录「假成功」误判。 第一次调用登录接口，几秒就返回「Cookie 有效」，但实际上根本没扫码——检测逻辑先找宽泛的 user 类名和头像元素，再查登录弹窗，两边都没识别到时就默认「已登录」，普通页面里带 user 的样式名会让它提前放行。收紧判断顺序为三步（先确认真正的登录态元素，再处理弹窗）后，扫码等待约 36 秒成功，17 条 Cookie 存到本地 .cache/cookies。Cookie 属于本地凭据，要加入 .gitignore，不截图、不提交、不转发。
四、草稿实测的边界。 调用 draft_item 后，图片处理、进入发布页、上传图片、填写描述、选择分类、填写价格、截图全部真实进入了发布表单。但当前分类「软件/程序/网站开发」在页面上提示暂不支持网页发布，需要手机 App 扫码接力。所以结论不是「已全自动上架」，而是「草稿可生成、最终发布可能仍要手机操作」。作者没有继续调用发布接口——继续点发布不会增加对草稿功能的认识，只会增加真实商品和清理成本。
五、百度网盘的只读验证。 验证时用 OAuth Access Token（不是 App Key / App Secret），只调用 get_quota 和 file_list 两个只读接口，两个都返回 errno=0 才算通。移动、重命名、删除、分享、URL 上传这些写操作不在验证阶段测——「工具列表里存在」不等于「这台电脑验证过这个动作」。另外，容量数字和私人文件名不要打进日志截图；泄露的 Token 要立即解除授权并重新生成。
四层排查法
作者总结的排查原则值得单独记：失败时不要同时重装所有东西，按 环境 → MCP 握手 → 账号认证 → 业务页面 → 外部 API 的顺序逐层检查，通常比反复重装快得多。
这个顺序对应的是故障概率分布：环境问题最容易发生，账号认证其次，外部 API 的问题最少见也最难改。先把便宜、常见的层查完，再动贵的层，是更省时间的排查顺序。
安全边界
提示词里写「谨慎操作」不等于真正的权限控制。更稳的做法是：缩小 Token 权限、默认关闭高风险工具、发布前生成截图、最后一步留给人。
- 高风险动作（删除、改库存、批量发布、账号矩阵操作）不应自动执行；
- 项目不会自动提供合法货源，也不保证流量和成交——虚拟产品的版权、售后和账号风控由使用者自己承担；
- 只读查询和草稿生成适合让 Agent 多做，失败不改外部状态，还留有证据；发布这种不可逆的动作留给人。
可复刻要点
- 用两个独立 MCP 服务分解文件侧和网页侧，调用交给 Codex；
- 接入任何 MCP 都先做最小探针，确认握手成功再谈业务；
- 遇到登录或认证问题，先用一个可预期的小请求验证状态，不要相信「几秒返回成功」；
- 写操作和读操作分开验证，先只读、后写入；
- 无论教程怎么写，最终发布这类动作都应保留人工确认。
适合谁，不适合谁
这套方案的甜点区是「有大量可整理的数字化素材、要搬运到另一个平台」的个人卖家或小团队：素材在网盘里、商品要上架、描述和分类规则相对固定，人工操作重复且耗时。
它不适合两种情况：一是期待完全无人值守——发布环节仍可能要手机接力，这是平台限制，不是工具问题；二是涉及需要资质或授权的内容——工具不解决货源合法性，也不保证成交。