在闲鱼上卖东西，与其说是在卖货，不如说是在当全天候客服。你说一句“在吗”，我得回；你说“真心想要，便宜点”，我得更便宜；你说“今天能发货吗”，我得保证。最烦的是同一套问题每天答几十遍。早些年不少人写正则匹配的自动回复脚本——匹配到“便宜点”就回“已是最低价”，效果大家心里都有数：买家换一种说法，脚本就成哑巴了。最近我盯上一个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；建议话术：……”然后再把建议话术发给买家。这个“决策先行”的设计就是典型的博弈思维——先判断棋局，再落子。

这个能力跃迁的本质，是把“自动回复”从规则工程升级成了策略工程。正则负责处理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. 从零搭一个最小可用闲鱼Agent

4.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 问题速查表

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自然会成为你二手交易流里最靠谱的那个“值班小二”。