企业官网建设流程全解析

做二手交易自动化这件事，我一直觉得是被大多数人低估的赛道。直到看见那个 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 方案，结果很有意思。这里只列出我自己的数据，不代表所有场景，但足以说明问题：

真实的成交效率，在测试环境中从原来的一天 0 到 1 单，提升到一天 3 到 5 单的对话转化，但这里有个前提：大量关键节点我保留了人为确认。任何涉及付款、下单、要求卖家改价的敏感操作，Agent 只负责准备好文案和预判，最后由人工点击确认。这不是偷懒，而是我认为二手交易自动化必须守住的底线。

说到底线，就必须提一句合规。自动化的度一旦过了头，就成了抢单机器人、黄牛工具、甚至是规避平台规则的灰色操作。这个项目能为普通人创造价值，恰恰是因为它把尺度控制在了“辅助人”而不是“取代人”。你可以让 Agent 帮你盯商品、帮你回消息、帮你分析价格是否合理，但不要让脚本绕过平台约束去扰乱市场秩序，更不要用自动化手段进行欺诈或控盘。这不是一句口号，而是所有做这类工具的开发者都应该刻在代码注释里的第一条。

我在实际测试中还发现，平台本身也在迭代风控策略，会持续识别异常行为。所以任何自动化方案都是“有限时薪”的，今天的节流方式是安全的，明天可能就会触发标记。因此项目中要预留一个“急停按钮”，一旦检测到账号状态异常，立即停止所有外部操作，这个开关一定要有，并且一定要提前演练。

如果你也想做类似的东西，我的建议是：先用正则或简单规则跑通最小闭环，哪怕效果再烂，也能帮你理解业务流程；然后将大部分沟通环节切换到大模型，但千万要把状态管理和敏感操作从模型手里拆出来；最后再慢慢加策略层，让 Agent 从“会说话”进化到“会博弈”。每一步的坑，踩过才算你的。

我在实际使用这个项目时的体会是，它最珍贵的不是那些 Star 数，而是让我重新审视了一个问题：规则和模型之间的边界到底在哪里。规则负责确定性，模型负责模糊性，博弈负责策略性，三者组合在一起，才是一个真正能“接管二手交易流”的 Agent。对个人开发者来说，这套分层思路完全可以迁移到任何对话交易场景里——只要守住边界，剩下的交给时间和迭代去打磨。