在闲鱼上卖东西与其说是在卖货不如说是在当全天候客服。你说一句“在吗”我得回你说“真心想要便宜点”我得更便宜你说“今天能发货吗”我得保证。最烦的是同一套问题每天答几十遍。早些年不少人写正则匹配的自动回复脚本——匹配到“便宜点”就回“已是最低价”效果大家心里都有数买家换一种说法脚本就成哑巴了。最近我盯上一个GitHub上5.4K Star的开源自动化Agent它把正则匹配那套彻底换成了大模型博弈从商品监控、自动擦亮到多轮议价、成交通知整个二手交易流慢慢被它“接管”了。这篇就聊聊这个Agent的技术拆解以及怎么自己搭一个最小可用版本。1. 项目到底动了二手交易的哪块蛋糕1.1 这个5.4K Star的项目在做什么简单来说它是一个面向个人卖家的二手交易自动化Agent。卖家把自己的商品信息、底价、发货方式、可接受的话术风格配置好剩下的事情交给Agent定时监控闲鱼上的搜索热度、自动擦亮商品、解析买家发来的每条消息的意图、根据议价策略生成回复、在价格谈拢后通知卖家发货。这类项目这几年在开源社区一直有但做到5.4K Star、还被冠以“Agent”称号的核心变化在于决策层换了大模型。以前自动化工具只做“机械动作”——定时上架、定时擦亮、收到指定关键词就自动回复本质上是一个定时脚本加规则引擎。这个项目的思路是把“卖货”这件事当成一个完整的人机协作闭环能自动处理的绝不打扰人需要人类判断的关键节点再把人叫回来。我第一眼看到这个项目时觉得它切得很准。闲鱼上真正消耗卖家时间的不是上架本身而是“挂着等人问”和“反复讨价还价”这两个环节。前者靠定时任务就能解决后者是典型的对话博弈场景恰好是大模型最擅长的地方。这个项目把两者拼接起来等于给个人卖家配了一个不太会累的线上销售助理。1.2 它想解决的三个真实痛点第一个痛点是回复时效。闲鱼的流量分配和回复率挂钩消息发出去半天不回买家早就跑去别家下单了。但人不可能24小时盯着手机尤其是上班族。Agent的价值不是替你做决定而是保证“每一条消息都有反应”把响应时间从几小时压到几十秒。第二个痛点是议价疲劳。“最低多少钱”“便宜50我就拍”“别人家才卖XX”这些话看在卖家眼里都是重复劳动但又不能不理。有人说干脆设置成免打扰但那样直接丢掉转化。Agent把每一次议价都当作一次小博弈根据买家的出价、语气、购买意图动态生成回应而不是无脑拒绝或秒降价。第三个痛点是信息过载。一个卖家手上有几十件商品时哪些东西该降价、哪些该下架、哪些最近有人反复问但没成交靠脑子记根本记不住。Agent可以把这些信号汇总成结构化报表在关键节点给卖家推送提醒。这三个痛点指向同一个结论二手交易流的自动化不是要取代卖家而是把卖家从重复劳动中解放出来让人只做“拍板”这个环节。2. 从正则匹配到大模型博弈一次能力跃迁2.1 正则匹配时代能做什么、卡在哪正则匹配做自动回复的历史挺久了。核心逻辑非常简单把买家消息和一堆预设模式做匹配命中了就返回预先写好的话术。import re RULES [ (re.compile(r在吗|还在吗|在线吗), 在的亲请问有什么可以帮您), (re.compile(r便宜|降价|少点), 已经是最低价了哦诚心要可以再小让一点。), (re.compile(r包邮), 亲价格已经很低了暂时不包邮哈。), ] def auto_reply(message: str) - str | None: for pattern, reply in RULES: if pattern.search(message): return reply return None这套方案在五六年前是可行的因为闲鱼买家的消息模式相对固定。但它有几个硬伤。第一个硬伤是语义理解为零。“我是学生能再少点吗”和“你卖的是不是学生票”包含的关键词完全不同但前者是议价、后者是问商品性质正则很难区分。第二个硬伤是缺少状态。对话是多轮的买家上一句说“100卖不卖”卖家回了“不卖”买家下一句说“那110呢”正则没办法理解这个“那”指的是前一轮的出价。第三个硬伤是策略单一。正则只能“命中-回复”无法根据对话进程调整话术比如对方已经让步了一次是顺势接住还是再坚持一下正则完全做不了判断。这三个硬伤导致正则方案在实际使用中体验很差。我见过不少人部署了正则脚本后反而被买家投诉“像个机器人”因为稍微绕一点的表达就触发错误的固定话术观感极差。2.2 大模型博弈的本质变化大模型接管对话后自动回复从“查表”变成了“决策”。Agent把买家消息、历史对话、商品信息、卖家的底价和风格偏好打包成上下文交给大模型生成回复。表面上看只是换了回复引擎实际上整个问题被重新定义了。以前要回答的是“这条消息命中了哪条规则”现在要回答的是“在这个局面下卖家应该采取什么动作”。这个大模型额外引入了两个能力。第一个是意图识别。同样是“在吗”有些买家是真的想买有些只是来压价的有些是问售后。大模型可以结合对方的历史行为、已浏览时长、当前对话轮次综合判断而不是简单看关键词。第二个是多轮策略。大模型可以把整段对话当作博弈棋局记住对方出过什么价、自己拒绝过几次、谁在让步再决定下一步怎么走。我见过一个很有意思的实现Agent在每次生成回复前先让大模型输出一个“隐藏决策”内容是“对方意图压价对方可信度中建议动作还价到105建议话术……”然后再把建议话术发给买家。这个“决策先行”的设计就是典型的博弈思维——先判断棋局再落子。对比维度正则匹配大模型博弈语义理解关键词匹配无法处理复杂表达理解上下文和隐含意图多轮状态无状态只能单条回复维护对话历史和议价状态策略能力固定话术不会变通按底价、买家画像动态决策开发成本低半小时可上手高需要设计Prompt和Agent框架抗封风险机械感强容易被识别话术自然但仍需控制频率这个能力跃迁的本质是把“自动回复”从规则工程升级成了策略工程。正则负责处理80%的简单场景大模型负责剩下的20%复杂博弈两者配合才是这个Agent的核心思路。3. Agent核心模块拆解3.1 情报层监控、擦亮与商品解析Agent的底层是情报层负责采集和整理闲鱼上的各种信号。首先是商品监控Agent会定时检查卖家发布的商品数据包括浏览量、想要数、超时未擦亮提醒。其次是自动擦亮闲鱼的商品擦亮能提升曝光Agent会在设定的时间间隔内自动触发这个动作替代人肉打卡。更关键的是商品解析模块。卖家录入商品时Agent会把标题、描述、图片OCR结果、定价、新旧程度等信息结构化形成一份“商品画像”。这份画像不只是给Agent自己看的它会被拼接进对话上下文让大模型在议价时“知道自己在卖什么、成本底线在哪”。举个例子一件标注“几乎全新、带发票、原价399”的数码产品和一件标注“用了两年、无配件、按故障机出”的旧玩具同样收到“便宜点”的消息Agent生成的策略完全不同。前者可以坚持价格、强调发票价值后者应该快速出手、接受合理还价。没有结构化商品画像大模型就只能瞎猜。3.2 决策层意图分类、定价策略与状态机决策层是整个Agent的大脑通常是三层结构。第一层是意图分类。买家发来的消息先做一次粗分类询价、议价、售后、闲聊、到货约时间还是疑似骚扰。分类结果决定后续动作。这个分类不一定要用大模型用规则加小模型也能做但大模型的泛化能力更好能处理“你这东西卖得比官网还贵”这种暗含议价意图的表达。第二层是定价策略。卖家在配置阶段会设置几个关键价格参数一口价、心理底价、绝不放价线。Agent在收到出价后会先做规则判断出价高于心理价位直接接受出价低于放价线直接拒绝出价在中间地带进入大模型谈判。第三层是状态机。每一笔交易会话都会被标记为“待回应”“谈判中”“已成交”“已放弃”等状态状态决定Agent的行为边界。比如状态为“已成交”时Agent自动停止议价、转入发货通知流程状态为“已放弃”时如果买家重新发消息Agent会切换到挽留话术。这个三层结构的设计让我觉得是项目的精髓。它没有把决策权全部甩给大模型而是让规则做闸门、大模型做主战既控制了成本和风险又保留了谈判的灵活性。3.3 执行层工具调用、通知与人机交接决策层做完判断之后执行层负责落地。最小闭环里需要三类工具。第一类是会话工具包括“发送消息”“修改价格”“生成订单链接”“标记已售”。这些操作通过自动化方式完成大模型通过Function Calling决定调用哪个工具、传什么参数。第二类是通知工具在关键节点推送通知给卖家比如“买家已同意您的底价请手动确认发货”“买家出价异常低疑似同行比价请留意”。第三类是人机交接工具卖家随时可以接管会话Agent会自动把自己的状态和对话摘要同步给卖家避免接管后一头雾水。工具调用的设计有一点特别重要Agent不要做任何不可逆的操作尤其是“标记已售”和“修改价格”这种动作宁可让卖家点一下确认也不要全自动执行。二手交易里价格和状态错了很麻烦这个边界守住了Agent才敢放心用。4. 从零搭一个最小可用闲鱼Agent4.1 技术选型本地优先能省则省我建议第一版不要用重框架能跑通闭环就行。语言选Python因为它做自动化、调大模型API的生态最成熟。大模型选一个便宜的中小模型就够议价场景不需要太强的推理能力关键是Prompt要写好。如果你有本地算力也可以跑量化后的开源模型延迟会高一些但成本可控。存储方面SQLite就够了。每件商品、每个买家会话、每条对话记录都是结构化数据用SQLite存起来方便后面做状态恢复。消息获取这块很多人纠结要不要做协议逆向我的建议是第一版不要碰先用自动化方式处理通知栏和消息列表跑通流程后再看需求。不要一开始就追求全自动。我的建议是先做“半自动”Agent负责监控、意图识别、生成回复建议卖家确认后手动发送。跑两周积累一批真实对话数据后再逐步放权给Agent自动回复。这个路径比一步到位稳得多。4.2 核心循环观察-决策-行动整个Agent的运行逻辑可以收敛成一个循环观察新消息做意图分类生成博弈决策决定是否调用工具最后回复或通知卖家。from dataclasses import dataclass from typing import Optional dataclass class Product: product_id: str title: str starting_price: float floor_price: float description: str dataclass class ConversationState: session_id: str history: list[str] status: str # negotiating / accepted / rejected buyer_last_offer: Optional[float] None class AgentLoop: def __init__(self, product: Product, policy: str): self.product product self.policy policy self.sessions {} def on_new_message(self, session_id: str, message: str) - str: state self.sessions.setdefault(session_id, ConversationState(session_id, [])) state.history.append(f买家: {message}) # 1. 规则闸门最低价直接拒绝 offer extract_offer(message) # 模拟提取出价 if offer is not None and offer self.product.floor_price * 0.8: reply 这个价格确实卖不了不好意思哈。 state.history.append(f卖家: {reply}) return reply # 2. 大模型决策生成回应话术 llm_reply self.generate_bargain_reply(state) state.history.append(f卖家: {llm_reply}) return llm_reply def generate_bargain_reply(self, state: ConversationState) - str: # 这里调用大模型API传入商品信息、历史对话、卖家议价策略 prompt build_prompt(self.product, state.history, self.policy) response call_llm(prompt) return response这段代码是最小骨架但你可以看到关键设计先做便宜的规则判断再做贵的大模型判断。每一轮对话都更新历史记录为下一轮博弈提供上下文。实际部署时你需要加一个“会话锁”。同一时间只处理一个买家的会话避免多线程并发时上下文错乱。另一个经验是消息队列如果同时监控多个商品消息会产生竞争用一个简单的Redis列表或Python的queue就能解决。4.3 Prompt工程让大模型懂你的生意议价Agent的Prompt是整个项目里回报率最高的地方。我见过很多Agent效果不好问题不在模型而在Prompt写得像“通用客服模板”。一个合格的议价Prompt至少要包含五块信息角色定义、商品画像、价格红线、历史对话、输出约束。角色定义让模型进入“卖家助理”的状态商品画像告诉模型你卖的是什么价格红线是底价95元低于这个数不能答应历史对话是当前博弈进度输出约束规定回复不超过30字、不主动降价、不承诺发货时间以外的物流信息。我实际用过的一个Prompt片段长这样你是二手交易平台的个人卖家助理。 当前商品信息 标题全新未拆封蓝牙耳机支持7天无理由 价格一口价120元心理底价100元绝不放价线95元 卖家风格礼貌、直接、不纠缠 对话历史 买家东西还在吗 卖家在的。 买家100卖不卖 卖家100有点少了最低110可以吗 买家105我现在就拍。 当前需要你回复是接受105还是继续坚持110 要求 1. 回复控制在30字以内 2. 不要主动降价除非买家明确表达购买意愿 3. 不能透露绝不放价线 4. 如果买家出价低于100礼貌拒绝并引导结束对话。这个Prompt的核心价值是把“生意规则”显式告诉模型而不是让模型自己摸索。很多人改一下这里的表述Agent的成交率就能提升一截。4.4 部署与观察先当副驾驶再当驾驶员最小可用Agent跑起来之后我强烈建议先以“建议模式”运行三到五天。每天看Agent生成的回复重点看三类错误一是价格底线守不住二是话术太生硬三是误判买家意图。这三类错误修完基本就能放开自动回复了。放开自动回复前至少要加两个保险。第一个是所有包含“价格调整”“确认售出”的动作必须人工确认第二个是每天设置回复上限防止某一天消息量异常时Agent被高频调用既烧钱又可能触碰到平台的风控边界。5. 常见问题与排查实录5.1 问题速查表症状可能原因解决方案Agent回复答非所问上下文里混入了上一位买家的对话按会话ID隔离历史记录下单前重置记忆报价低于底价却答应了Prompt中价格红线表述不清晰把底价写进系统提示词并用规则层兜底拦截话术千篇一律、机械感强模型被要求“保持同一风格”过度约束放宽风格描述给2-3种语气模板轮换响应延迟高买家等得不耐烦每次对话都调用大模型高频问题走规则复杂场景才调用大模型一天扣费远超预期上下文越来越长token消耗膨胀对历史对话做摘要压缩只保留最近5轮全文自动回复触发了平台限制发送频率过高或模板痕迹明显加入随机延迟、轮换话术、控制单日会话数5.2 三个容易被忽视的细节第一个是上下文污染。如果Agent是一台机器跑多个商品非常容易出现“把A商品的买家和B商品的对话串在一起”的情况。我踩过这个坑后果是买家问“你那个耳机能卖吗”Agent回复“这个镜头没有盒子”……观感极其灾难。解决方案是每个商品、每个会话都用一个独立的上下文对象互不共享。第二个是承诺类幻觉。大模型有时候会为了促成交易瞎承诺比如买家问“有发票吗”Agent直接回“有”实际上你的商品根本没发票。这比回复慢更致命因为涉及售后纠纷。改进方式是在Prompt里加入“未知信息必须询问卖家”的硬约束同时把商品画像里的字段填全。第三个是长对话成本膨胀。一段30轮的讨价还价如果每次都把全部历史塞给模型token消耗会非常夸张。我的经验是超过10轮就把更早的对话压缩成一句摘要比如“前10轮双方在95-105元区间反复拉锯买家始终希望含邮费”。“摘要最近5轮全文”的结构既能保住关键信息又把成本控制在可接受的范围。5.3 风控与合规的基本姿势聊自动化绕不开“平台风控”这关。我必须先把话说清楚任何自动化行为都要遵守目标平台的用户协议和社区规则。Agent的定位是“辅助卖家提升回复效率”不是“批量骚扰用户”也不是“绕过平台机制薅流量”。如果你只是为了发垃圾消息、批量抬价、恶意压价这种用法我不建议也不在本文讨论范围内。合规使用的几个实操经验可以分享回复间隔加随机抖动不要每秒钟都秒回真实人没那么高效话术要多样化同一个模板反复用任何平台都可能判定为营销机器人单账号的日会话量设一个峰值超过后自动转人工模式。这些不是为了“对抗”什么而是为了让自动化行为更接近一个真实、负责的卖家。6. 再往前一步6.1 可以扩展的方向我搭建完第一版Agent后觉得最值得继续投入的方向有三个。第一个是售后流程Agent化。成交之后还有大量重复问题“发货了吗”“快递到哪了”“怎么有划痕”。这些问答完全可以交给Agent处理只有涉及退款、退货等高风险动作时才转人工。第二个是跨平台适配。二手交易不只闲鱼一个场子转转、拍拍、甚至社区团购群都有同样的对话博弈场景把意图识别和议价策略抽象成通用模块适配成本会大幅降低。第三个是数据复盘。把每次议价的对话、最终成交价、买家行为轨迹汇总起来跑一个简单的定价模型告诉卖家“你这个东西挂多少价位最容易成交”这才是Agent从工具变成顾问的关键一步。6.2 我个人在实际操作中的体会跑这个小项目的过程中我最大的感触是Agent的边界感比能力更重要。能力决定它能做多少事边界感决定你不敢放心让它做哪些事。把“不可逆操作必须人工确认”写死在架构里把“未知信息不许编造”写死在Prompt里把“高频率动作必须限流”写死在调度层里这三个边界守住Agent才能在真实交易流里长期稳定运行。还有一个小经验送给大家不要急着让Agent“全自动”。先用半自动模式跑两周你会积累很多真实买家的表达方式——有人上来就砍半价有人磨蹭三小时才下单有人货比三家后回头找你。这些数据是你调整Prompt、定价策略和状态机的最佳依据。等你把常见套路都摸清了再慢慢放权Agent自然会成为你二手交易流里最靠谱的那个“值班小二”。