XianyuAutoAgent：用 LLM 和 Cookie 给闲鱼卖家搭一个 AI 客服
智能闲鱼客服机器人系统：专为闲鱼平台打造的AI值守解决方案，实现闲鱼平台7×24小时自动化值守，支持多专家协同决策、智能议价和上下文感知对话。
秒懂
- 它是什么？
- XianyuAutoAgent 是一个面向闲鱼卖家的 Python 客服机器人，用 LLM 做意图分类和回复生成，靠网页 Cookie 驱动。本文拆解它的多专家架构、议价逻辑和运行方式，并指出它在合规与稳定性上的真实短板。
- 适合谁用？
- 如果你是闲鱼个人卖家，愿意接受账号风险，并且有基本的 Python 环境配置能力，XianyuAutoAgent 可以在你离线时替你回复询价和议价消息。它适合商品技术属性强、买家提问重复度高的场景，因为技术专家模块能减少你反复解释参数的工作。
- 能商用吗？
- 可以，但有条件。GPL-3.0 是 copyleft 许可证：如果你分发包含它的软件，就必须以同一许可证公开该软件的源代码。只在内部运行、不对外分发，则不会触发这项义务。
- 还在维护吗？
- 在维护。仓库最近一次提交在 98 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
闲鱼卖家缺的不是客服，是值守
闲鱼上的交易高度依赖即时聊天。买家问一句在不在，你半小时后才看到，这笔生意可能就没了。XianyuAutoAgent 解决的就是这个值守问题。它是一个 Python 写的机器人，用大语言模型生成回复，目标是让卖家在睡觉、上班、吃饭时，账号依然能回应询价、处理议价、回答技术问题。它的目标用户很明确：个人卖家，尤其是那些卖数码产品、需要反复解释参数和功能的卖家。项目 README 里列出的三个专家角色，客服、价格、技术，恰好对应闲鱼上最常见的三类消息。这不是一个通用聊天机器人，它的一切设计都围绕闲鱼这个具体平台的交易场景展开。
一次请求怎么变成一段回复
从仓库结构和 README 描述看，XianyuAutoAgent 的工作流程大致是这样：机器人通过网页 Cookie 登录闲鱼，监听新的聊天消息。收到消息后，先把历史对话和当前消息一起交给一个分类提示词，判断这条消息属于议价、技术咨询还是普通闲聊。分类结果决定后续交给哪个专家。价格专家按照阶梯降价策略给出可接受的让步幅度，技术专家可以调用网络搜索来回答参数问题，默认专家处理其他情况。所有专家的回复最终由 LLM 生成，再通过同一个 Cookie 会话发回给买家。整个流程里，上下文管理靠的是把完整会话历史塞进 LLM 的输入，没有额外的向量数据库或记忆模块。这个设计很直接，但也很费 token，长对话的成本会线性上升。
配置比想象中简单，但坑在 Cookie
安装本身没有意外。克隆仓库，pip install -r requirements.txt，然后复制 .env.example 成 .env，填上 API_KEY、MODEL_BASE_URL、MODEL_NAME 和 COOKIES_STR。默认模型是通义千问，想换其他家就改模型地址和名称。提示词文件在 prompts 目录下，四个文件分别对应分类、价格、技术、默认回复，你可以直接编辑，也可以把模板里的 _example 去掉直接用。真正麻烦的是 COOKIES_STR。README 要求你打开闲鱼网页端，按 F12 进控制台，在 Network 面板的 Fetch/XHR 请求里复制 Cookie。这个 Cookie 会过期，一旦失效机器人就静默罢工，而且你无法从仓库里看到任何自动续期或异常检测的代码。对非技术卖家来说，这一步是最大的门槛。
多专家协同是亮点，但路由质量全看提示词
项目把议价和技术支持拆成独立专家，这个思路比单个 prompt 硬扛所有场景要合理。价格专家只管降价策略，技术专家只管参数和功能问题，职责分离让每个提示词可以写得更专注。但分类这一步依赖 classify_prompt.txt 里的提示词，也就是说路由的准确率完全取决于你写的意图分类指令。如果买家说了一句模棱两可的话，比如这价格能再低点吗，顺便问下支持 5G 吗，分类器可能只识别出议价意图，技术问题就被忽略了。README 没有提供任何分类准确率的测试数据，也没有说明误分类时的兜底机制。默认专家存在，但它更像是接盘侠，而不是纠错机制。
模拟人工输入和接管开关，是给平台看的
环境变量里有两个值得注意的可选配置。SIMULATE_HUMAN_TYPING 设为 True 时，机器人会模拟人工回复的延迟，让消息看起来不像秒回。TOGGLE_KEYWORDS 默认是句号，买家输入句号就切换为人工接管，再输入句号切回 AI。这两个设计明显是为了降低被平台识别的风险。闲鱼对自动化脚本的态度并不友好，Cookie 登录本身就是灰色操作。模拟打字延迟能骗过普通买家，但骗不过平台的风控系统。频繁的 Cookie 失效、要求验证码、甚至账号限流，都是这类项目常见的结果。README 也承认项目仅供学习交流，可能随时停止更新或删除。这意味着你一旦依赖它，就要做好某天突然不能用的准备。
替代方案：自己写脚本，或者干脆用官方 API
如果你不想承担 Cookie 和反爬风险，最直接的替代是放弃网页端模拟，改用闲鱼官方提供的开放平台 API。官方 API 稳定、合规，但需要企业资质，个人卖家基本申请不下来。另一个方向是参考项目的底层依赖，它引用了 cv-cat/XianYuApis，这个库专门封装闲鱼的网页接口。你可以基于它自己写一个更轻量的消息监听器，只做关键词回复，不引入 LLM，这样成本和风险都低很多。差别在于，XianyuAutoAgent 用 LLM 理解语义，能处理没见过的问法，而关键词脚本只能命中你预设的模式。前者灵活但不可控，后者死板但可预期。对于只卖固定几款商品的卖家，后者可能更实用。
维护状态和许可证，决定你能不能长期用
仓库最后推送时间是 2026 年 6 月，没有发布任何 release，也没有提供版本号。README 明确写了开发团队可能随时停止更新或删除项目，这个声明本身就是一种维护风险的提示。代码基于 GPL-3.0 许可证发布，这意味着如果你修改了代码并对外分发，必须同样以 GPL-3.0 开源。个人自用不受影响，但如果你想基于它做商业产品，GPL 的传染性会是个问题。另外，项目依赖的 XianYuApis 也是第三方逆向库，它的稳定性同样没有保障。在决定采用之前，你应该检查这两个仓库最近的提交频率和 issue 处理情况，确认它们是否还在活跃维护。
编辑结论
如果你是闲鱼个人卖家，愿意接受账号风险，并且有基本的 Python 环境配置能力，XianyuAutoAgent 可以在你离线时替你回复询价和议价消息。它适合商品技术属性强、买家提问重复度高的场景，因为技术专家模块能减少你反复解释参数的工作。不适合企业或批量卖家，也不适合对账号安全零容忍的人。在部署前，务必先确认三件事：你的 API 服务商是否允许这种自动化调用，闲鱼平台对脚本登录的态度是否在你能承受的范围内，以及项目是否有新的维护提交。项目自身声明可能随时停止更新或删除，所以不要把它当作长期生产依赖。
社区笔记