★ FEATURED ARTICLE 做二手交易自动化这件事我一直觉得是被大多数人低估的赛道。直到看见那个 5.4K Star 的开源 Agent 项目我才意识到自己的思路落后了整整一代它早期完全靠正则匹配在硬扛后来才切到大模型博弈中间那条演进曲线几乎是个人开发者做 AI 工具的教科书。这篇文章就把这个项目从前到后拆开讲从正则匹配怎么“能用但憋屈”到大模型博弈怎么把二手交易流完整接管再到那些文档里不会写的踩坑细节、架构取舍和合规红线一次说透。1. 5.4K Star 背后二手交易流里到底有哪些事值得自动化二手交易这个盘子看起来只是“把闲置卖掉”这么简单真正每天在平台上泡着的人才知道这里面藏着大量重复、低效、又极其消磨耐心的动作。某个闲置群里的朋友为了蹲一张限量版显卡连续刷了半个月不是在抢就是在错过一个偶尔出清旧物的卖家每个商品都要应付十几条“还在吗”“能便宜吗”回得心累。这些场景天然适合 Agent 介入但很多开发者第一反应是“没必要”直到项目 Star 数涨到 5.4K大家才意识到需求是真实存在的。拆开来看一条完整的二手交易流可以分成五个环节信息获取、筛选评估、沟通议价、下单支付、售后跟踪。其中信息获取对应的是监控新上架商品筛选评估对应的是判断商品的真实价值沟通议价是最耗心力的环节要应对砍价、质疑、催发货订单跟进则是从付款到确认收货之间的大量状态同步。传统意义上的爬虫脚本只能解决前两个后三个环节必须靠一个能和真人对话、能判断意图、能制定策略的系统也就是 Agent。这个项目能拿 5.4K Star核心不是技术炫技而是它第一次把“自动蹲货”和“自动议价”真正打通了。对个人开发者来说它的参考价值在于不需要花哨的界面不需要复杂的前后端一套本地跑的调度器加一个对话 Agent就能把二手交易里最耗时的沟通环节干掉大半。尤其对于副业玩家、闲鱼捡漏党、出清库存的小卖家这套思路几乎是可以直接抄作业的。但很多人容易高估这一步的难度低估后面那步的复杂性。我见过不少尝试者第一次写出来的工具就是个“正则匹配轮询”的爬虫能把新商品抓回来能在标题里匹配关键词但一遇到自然语言就全面溃败。这也就是为什么这个项目的第一版和第二版之间隔着完全不同的工程哲学。2. 第一代实现正则匹配的“能用”与“天花板”在哪里老版本的做法很直白用 Python 写一个轮询脚本每隔几十秒扫一次平台的新上架列表用正则匹配去判断商品描述里有没有目标关键词、价格是不是在设定区间、卖家信用分是不是够高。这样的工具在 2020 年前后非常流行跑起来也确实能捡到一些便宜货尤其是那些标题规范、价格明确的商品命中率看起来还不错。代码大概长这样我把核心细节简化成一个可运行的思路import re import requests PATTERNS [ re.compile(r显卡|RTX\s*30\d{2}, re.I), re.compile(r几乎全新|仅用|无磕碰, re.I), ] def match_product(desc: str) - bool: if not desc: return False score 0 for pat in PATTERNS: if pat.search(desc): score 1 return score 2这段代码的硬伤用过的人都知道。商品描述是自然语言不是结构化数据。卖家说“公版煤气灶”你正则根本不认识说“习武之人”和“闲置吃灰”都能指代同一样东西更别提大量暗语、缩写和带讽刺意味的表达。你加规则它就变种你扩关键词误报率就飙升。到了后期维护一个正则库的代价已经超过手动刷商品列表了。而且正则匹配还有个致命问题它只会“匹配”不会“理解”。比如卖家写了“刚买的没几天孩子不喜欢”你无法判断这是“成色极好”还是“冲动消费后的瑕疵品”卖家写“不刀”你到底该不该问价正则也完全给不出建议。筛选环节的问题还能靠堆积规则勉强缓解沟通议价环节直接卡死因为议价需要的不是匹配而是策略。我见过有人在这个阶段加了一堆补丁比如用异常检测识别恶意卖家、用聚类给描述分类但那种补丁式的做法治标不治本。真正打破天花板必须换一套引擎把“匹配”升级成“理解”再把“理解”升级成“博弈”。3. 为什么必须转向大模型先是语义识别后是策略博弈这个项目转向大模型的契机我在其早期版本的聊天记录里看到的是一场典型的正则翻车。一个买家 Agent 匹配到一条“仅支持自提请勿问快递”的商品描述正则规则库里的“快递”规则恰好命中于是直接给卖家发送了“支持发货吗”的询问。卖家非常不耐烦地回复“说了自提自提自提”然后拉黑了账号。那一刻正则匹配的荒谬暴露无遗它能读出一堆字样却读不出这句话背后的潜台词。大模型在这里解决的第一个问题是语义理解。同样是“还能少吗”买家可能是诚心想买、是试探底价也可能是随口一问卖家回“真心要的话给你少点”是释放诚意信号还是套路话术。让模型去分析这些对话几乎不需要喂规则它天然知道什么话是客套、什么话是底线、什么话背后带着情绪。这一点直接让 Agent 的沟通能力向前跨了一大步。但语义理解只是第一步真正让这个项目跳出“聊天机器人”范畴的是把交易建模成一场博弈。我们拆开看一场议价买家想以最低价成交卖家想以最高价出手双方都有心理价位和底价谁先暴露底牌谁就输。所以 Agent 的策略层不能只是“理解对方在说什么”还要决定“自己接下来该说什么、不说是什么、让一步还是不让”。这就是标题里说的“大模型博弈”。博弈策略落实下来其实是几个很朴素的原则第一Agent 必须先扮演一个“可信买家”不能一上来就疯狂砍价那只会触发卖家的防御心理第二提问节奏要像真人不要连续追问多个问题否则会被标记成骚扰第三出价序列要有设计先给一个低于心理价位的试探价然后根据卖家的反应逐步调整而不是一次性报出心理价。这些策略不写死逻辑而是通过提示词和上下文让模型自行生成再约束到一套边界里。引入大模型后的第二个好处是 Agent 能处理“非标准表达”。二手交易里卖家写“9.9 新”、买家问“刀多少”、平台上全是表情包和口头语这些靠正则根本没法穷举。但模型天然对模糊语言有容忍度它可以结合上下文推断“刚刚买来用了一天”等于“几乎全新”“箱说齐全”是加分项“验货宝”是交易保障机制。这相当于把 Agent 的感知能力从“字节级”提升到了“语义级”。4. 核心架构一个“意图-策略-执行”三层 Agent 的搭建过程我自己重新实现了一遍这个项目的精简版才真正理解它为什么能跑得稳。整体架构如果压缩成一句话就是三层意图识别层、策略博弈层、执行调度层。每一层各管一件事层与层之间用清晰的接口通信而不是让模型一口气把所有事都干了。意图识别层的职责是判断进来的每一条消息“是什么”。是买家问价、是卖家发链接、是系统通知发货还是对方直接表达不卖了。我一开始图省事想用一个大的提示词把所有判断和回复一起生成结果模型经常在“判断”和“回复”之间互相污染。后来学乖了先把消息转成结构化字段比如intent: query_price、tone: neutral、mentions_shipping: False再做下一步。这里是简化版的消息解析示意重点看结构化的思路from pydantic import BaseModel class ParsedMessage(BaseModel): intent: str mentions_price: bool mentions_shipping: bool urgency: str # low / medium / high raw: str def parse_message(model, text: str) - ParsedMessage: prompt f你是一个二手交易对话解析器。 请判断用户消息的意图、是否谈到价格、是否谈到发货、紧急程度。 消息内容{text} 只输出 JSON。 result model.invoke(prompt) return ParsedMessage.model_validate_json(result.content)策略博弈层是这个 Agent 的灵魂。它会读取当前对话状态、历史消息、卖家的信用信息、该商品的浏览量和收藏数然后决定下一步动作报一个新价、追问成色、表达犹豫、或者直接结束谈判。我建议这一步不要完全交给模型裸跑而是用一组“策略基元”做约束比如COUNTER_OFFER、CONFIRM_ASK、BREAK_CONTACT让模型只能在受控动作集合里做选择。否则你很快会碰到模型自己发明动作、说出“我加钱你发货”这种完全不合理的策略。执行调度层负责把策略转换成实际的平台操作发送消息、刷新商品列表、更新本地数据库、设置提醒。这一层尽量用轻量代码实现不要什么都塞给大模型。我自己用 SQLite 存对话记录用 APScheduler 做定时任务用 FastAPI 起一个很小的本地服务整个 Agent 跑在 Docker 里数据流非常清晰平台新消息到达 → 意图识别层解析 → 策略层决策 → 执行层发送 → 状态更新回数据库。关于模型选型我得说点个人经验。意图识别这种任务用本地的轻量小模型就够延迟低、成本接近零而且不会把对话内容传到外部服务策略生成则建议用云端更强的对话模型因为它需要角色扮演和长上下文理解。两个模型各干各的分工明确比一个全能模型好用得多。很多人上来就要上最好的大模型结果成本和延迟都撑不住得不偿失。5. 踩坑记录幻觉、频控、话术翻车的完整排查链路这个项目真正“好用”和“看起来能用”之间隔着一大堆坑。我挑三个最典型的把排查链路写出来这些才是真实项目里没法从文档中习得的部分。第一个坑是模型幻觉表现形式特别隐蔽。Agent 在卖家说“已经发货”之后居然在本地状态里给自己标记了一个“已完成交易”并触发了一条好评引导消息。当时我查了很久日志里根本没有下单记录卖家也没收到任何付款整个状态是空的。排查到最后发现根因在策略层模型看到了卖家说“发货”这两个字自动在续写上下文中补了一段“交易完成”的推断然后把它写进了系统状态字段。换句话说模型不是在记录事实而是在编故事。解决方式是把状态维护权从模型手里彻底收回来。模型只负责产出“动作”所有状态变更都由执行层的代码完成并且在变更前必须校验真实事件源比如平台回调、支付通知而不是听模型在语境里说一句就算数。打个比方模型可以帮你写“这段对话可以进入发货阶段了”但真正把状态翻到“已发货”的只能是代码里的一个函数。第二个坑是平台风控的频控问题。初版 Agent 轮询间隔设为 10 秒运行两小时后账号被限制了。排查时我先看了本地日志发现多次请求在 1 秒内被快速重复发送原因是我把“重新登录”逻辑和“轮询”逻辑写在了同一个协程里导致掉线重连时会瞬间发起多个请求。修复并不难所有外部请求都统一经过一个带熔断器的客户端加随机退避轮询间隔改为 30 到 60 秒之间的随机值并且保证任何“重试”都带上指数退避的延迟。被限号之后再去解封代价远大于代码调整那几分钟。第三个坑更微妙是话术翻车。Agent 的第一个版本有一个预设动作当用户说“有人也要买你出多少”时策略层会自动让利 5%。跑了两周后我发现这个策略被多次触发而且每次都是同一个卖家。直觉告诉我不对查对话记录才发现那个卖家已经识别出对面是个机器人专门用“有人出价”这句话来套路。为什么能识别出来因为 Agent 每次回答的句式结构一模一样开头永远固定中间永远让步连标点风格都不变。修复方案是在策略层增加“底牌保护”逻辑当 Agent 判断对方是在复用同一话术、且信用记录可疑时不进入让利分支反而转为“考虑一下再回复”。同时把回复模板改成多样式生成同一个语义点可以有多种表达方式让对方感知不到机器人的重复感。从那以后我再没盲目迷信“大模型自动生成的回复一定自然”越是在真实交易环境里越要刻意抹掉机器痕迹。这三个坑背后其实是一个共性Agent 的任务不是“能说话”而是在复杂且容易被利用的环境里“不被识别成呆子”。模型负责聪明工程负责稳固缺一不可。6. 效果对比与边界自动化做到哪一步以及必须守住的规则完全体跑通之后我用一套固定测试集对比了旧版正则方案和新版 Agent 方案结果很有意思。这里只列出我自己的数据不代表所有场景但足以说明问题维度正则匹配方案大模型博弈 Agent语义理解能力低依赖关键词覆盖高可处理近义表达与暗语议价策略无只能发送固定话术动态调整可应对多种砍价套路误报率高规则叠加导致误伤较低结合上下文判断维护成本每周追加规则变种不停只需维护策略边界调参少对平台规则的冲击单点高频访问易被限随机节流后风险可控真实的成交效率在测试环境中从原来的一天 0 到 1 单提升到一天 3 到 5 单的对话转化但这里有个前提大量关键节点我保留了人为确认。任何涉及付款、下单、要求卖家改价的敏感操作Agent 只负责准备好文案和预判最后由人工点击确认。这不是偷懒而是我认为二手交易自动化必须守住的底线。说到底线就必须提一句合规。自动化的度一旦过了头就成了抢单机器人、黄牛工具、甚至是规避平台规则的灰色操作。这个项目能为普通人创造价值恰恰是因为它把尺度控制在了“辅助人”而不是“取代人”。你可以让 Agent 帮你盯商品、帮你回消息、帮你分析价格是否合理但不要让脚本绕过平台约束去扰乱市场秩序更不要用自动化手段进行欺诈或控盘。这不是一句口号而是所有做这类工具的开发者都应该刻在代码注释里的第一条。我在实际测试中还发现平台本身也在迭代风控策略会持续识别异常行为。所以任何自动化方案都是“有限时薪”的今天的节流方式是安全的明天可能就会触发标记。因此项目中要预留一个“急停按钮”一旦检测到账号状态异常立即停止所有外部操作这个开关一定要有并且一定要提前演练。如果你也想做类似的东西我的建议是先用正则或简单规则跑通最小闭环哪怕效果再烂也能帮你理解业务流程然后将大部分沟通环节切换到大模型但千万要把状态管理和敏感操作从模型手里拆出来最后再慢慢加策略层让 Agent 从“会说话”进化到“会博弈”。每一步的坑踩过才算你的。我在实际使用这个项目时的体会是它最珍贵的不是那些 Star 数而是让我重新审视了一个问题规则和模型之间的边界到底在哪里。规则负责确定性模型负责模糊性博弈负责策略性三者组合在一起才是一个真正能“接管二手交易流”的 Agent。对个人开发者来说这套分层思路完全可以迁移到任何对话交易场景里——只要守住边界剩下的交给时间和迭代去打磨。
阅读完成 · 觉得有帮助？
