AI Agent 重构跨境电商：选品与广告投放自动化架构实战

跨境电商这个行业过去几年我最大的感受就是选品和广告投放这两件事本质上都是信息处理密集型工作但绝大多数团队还在用人肉Excel的方式硬扛。一个运营每天要翻几十个榜单、对比十几家竞品的价格和评论、盯着广告后台调竞价做完一轮天都黑了第二天数据一变又得重来。AI Agent 架构之所以在这两年被反复提起不是因为它是个新概念而是因为它恰好能嵌进这条信息采集—分析决策—执行反馈的链路里把重复劳动接过去。这篇内容我想聊的是怎么用 Agent 的思路去重构选品和广告投放的工作流包括架构怎么分层、每个环节用什么能力、实际落地时会遇到哪些坑。不管你是刚接触跨境电商的新手还是已经在带团队做多平台运营的老手应该都能从中找到可以直接抄的部分。1. 先搞清楚 AI Agent 到底解决的是跨境电商的哪个环节1.1 选品和投放的本质是同一件事的两个面很多人把选品和广告投放当成两件独立的事选品归选品投放归投放。但做过一段时间就会发现这俩其实是同一个决策闭环的两端。选品是在回答卖什么投放是在回答怎么把选出来的东西卖出去而投放跑出来的数据又会反过来告诉你当初选品选得对不对。传统做法里这个闭环是靠人手动串联的运营选品运营建广告计划运营看报表运营再回去调整选品方向。问题在于人的带宽是有限的一个运营同时盯三个平台、五个品类就已经到极限了。AI Agent 的价值就在于它能把这个闭环自动化。注意我说的是闭环不是单点自动化。市面上很多工具能做到自动抓取榜单数据也能做到自动调竞价但它们之间是断开的数据抓完要人导出、分析完要人手动录入广告后台。Agent 架构的核心区别是它有一个持续运行的决策循环能自己判断现在该做什么做完之后看结果再决定下一步。这跟 RPA 那种你告诉它点哪里它就点哪里的脚本有本质区别。1.2 Agent、LLM、AI 模型这三个词到底怎么区分热词里有人问agent 和 llm 和 ai 模型有什么区别这个问题特别典型我拿跨境电商的场景来解释。AI 模型是个大范畴任何能从数据里学出规律的都算比如一个预测某品类下个月销量的回归模型它是 AI 模型但它不是 LLM也不是 Agent。LLM 是大语言模型它的核心能力是理解和生成自然语言比如你把一堆竞品的评论丢给它它能总结出用户最不满意的三个点是续航、包装、客服响应。但 LLM 本身是被动的你不问它它不动。Agent 则是把 LLM 当成大脑再给它配上手脚和记忆。手脚就是工具调用能力比如调用爬虫去抓数据、调用广告平台的 API 去改预算记忆就是它能记住之前做过什么、结果如何。所以一个完整的选品 Agent它的工作方式是LLM 负责理解我要找的是客单价 15-30 美元、月销 500 以上、评论数少于 200 的蓝海品这个指令然后自己决定去哪个数据源抓、抓完怎么筛选、筛完要不要生成一份报告。DeepSeek 这类模型属于 LLM它可以作为 Agent 的推理内核但 LLM 本身不等于 Agent。1.3 为什么是现在三个条件同时成熟了Agent 架构在跨境电商落地不是突然冒出来的。我观察下来是三个条件凑齐了。第一是 LLM 的推理成本降下来了以前调一次 GPT-4 级别的模型做复杂分析成本高到没法高频跑现在国产模型把价格打下来之后一个 Agent 每天跑几百次决策循环在成本上完全可接受。第二是跨境电商平台的数据接口和自动化工具成熟了不管是亚马逊的 SP-API 还是各种 RPA 工具能拿到的数据维度比三年前丰富太多。第三是业务侧的需求真的到了临界点平台流量越来越贵粗放式投放的 ROI 已经撑不住了必须靠精细化运营而精细化运营靠人堆是堆不出来的。提示不要一上来就想着搭一个全自动的 Agent。我见过太多团队花三个月搭了个全自动系统结果因为平台风控或者数据口径问题跑出来的结果还不如人工。正确的做法是先做半自动Agent 负责采集和分析人负责最终决策跑顺了再逐步把决策权交出去。2. 选品 Agent 的架构拆解从数据采集到决策输出2.1 数据层选品 Agent 的眼睛该看哪些数据选品这件事数据源的质量直接决定结论的质量。我一般把选品需要的数据分成四类。第一类是平台榜单数据比如亚马逊的 Best Sellers、Movers Shakers、New Releases这些是公开的抓取难度低但信息密度也低只能告诉你什么在涨。第二类是竞品详情数据包括价格、评分、评论数、上架时间、变体数量这些需要针对具体 ASIN 去抓信息密度高能帮你判断一个品的竞争格局。第三类是评论内容数据这是最容易被忽略但价值最高的因为评论里藏着用户的真实需求和痛点。第四类是外部趋势数据比如搜索引擎的搜索量变化、社交平台上的讨论热度。Agent 架构里数据层要做的事情不是抓得越多越好而是按需抓取。具体来说Agent 的推理内核会根据当前任务决定去哪个源抓什么数据。比如你让它找最近 30 天销量增长快但评论数还很少的品它就会优先去抓榜单数据和竞品详情数据而不是去抓评论内容。这种按需抓取的逻辑比传统那种先把所有数据抓下来再慢慢分析的做法效率高得多也省成本。2.2 分析层LLM 在选品里到底做什么判断数据抓回来之后分析层是 Agent 真正体现智能的地方。传统做法是用规则引擎比如评分大于 4.5 且评论数小于 100 且价格在 20-30 美元之间就标记为潜力品。规则引擎的问题是它只能处理结构化数据评论内容这种非结构化数据它处理不了。LLM 的强项恰恰在这里。我实际用下来LLM 在选品分析里主要做三件事。第一是评论聚类和痛点提取把几百条评论丢进去让它归纳出用户最在意的几个维度以及每个维度上的满意度。第二是竞品差异化分析把几个竞品的卖点、定价、评论对比之后找出哪个价格带还有空白哪个功能点还没人做好。第三是风险识别比如某个品类的评论里频繁出现侵权专利相关的词LLM 能提前预警。这三件事如果用人工做一个运营一天最多分析两三个品类用 LLM 可以做到几十个。2.3 决策层怎么让 Agent 输出可执行的选品建议分析做完之后最关键的是输出。我见过很多团队的分析报告做得很漂亮但运营看完不知道下一步该干嘛。Agent 的决策层要解决的就是这个问题它输出的不是这个品类有潜力这种模糊结论而是建议优先测试 A 和 B 两个细分方向A 的切入点是改进续航B 的切入点是做套装组合建议首批各备货 200 件测试周期两周。要做到这一点Agent 的决策层需要接入一些业务约束条件比如你的资金能压多少库存、你的供应链能支持多快的翻单、你的广告预算能承受多高的测试成本。这些约束条件不是 LLM 自己知道的需要你在架构里显式地配置进去。我的做法是给 Agent 一个业务规则库里面存着这些约束LLM 在做决策时会参考这些规则。这样输出的建议才是可执行的而不是纸上谈兵。2.4 记忆层让 Agent 记住上次选品的结果记忆层是很多人在搭 Agent 时会漏掉的部分但它特别重要。选品不是一次性的事你这个月选的品下个月要复盘要对比。如果 Agent 没有记忆每次都是从零开始那它就永远在重复劳动。记忆层要存的东西包括历史选品记录、每个品的实际表现数据、当时的决策理由、后续的调整动作。有了记忆层之后Agent 就能做归因分析。比如它发现上个月推荐的某个品实际表现不好它会去对比当时的分析结论和实际数据找出偏差在哪里。是评论分析漏掉了某个关键痛点还是竞品数据抓取时漏掉了某个新入局的对手。这种自我修正的能力是 Agent 架构相比传统工具最大的优势之一。3. 广告投放 Agent 的工作流从竞价调整到素材优化3.1 投放 Agent 和选品 Agent 的架构差异虽然选品和投放是同一个闭环的两端但它们的 Agent 架构差异很大。选品 Agent 是低频高深度一天跑一次或者一周跑几次就够了每次要处理大量数据、做复杂分析。投放 Agent 是高频低深度可能每半小时就要跑一次每次只做一个小决策比如这个关键词的竞价要不要从 0.8 调到 0.9。这个差异决定了架构设计上的不同。选品 Agent 可以容忍较高的延迟所以可以用更大的模型、更复杂的推理链。投放 Agent 对延迟敏感而且决策频率高所以要用更轻量的模型甚至很多决策可以用规则引擎加 LLM 兜底的方式来做。我一般的做法是80% 的常规竞价调整用规则引擎20% 的异常情况交给 LLM 判断。这样既保证了响应速度又保留了处理复杂情况的能力。3.2 竞价调整Agent 怎么判断该加价还是降价竞价调整是投放 Agent 最核心的功能。传统做法是设一个 ACOS 目标值高于目标就降价低于目标就加价。这个逻辑太粗糙了因为它没有考虑这个关键词处在什么阶段。一个刚开的新词前期 ACOS 高是正常的这时候降价反而会扼杀它。一个已经跑成熟的老词ACOS 突然升高可能是竞品在抢量这时候降价是合理的。Agent 的做法是引入上下文。它会综合考虑这个词的历史表现、当前竞争环境、所在广告组的目标、整体预算消耗进度等因素再决定调价幅度。比如同样是 ACOS 超标如果这个词是新品测试期Agent 可能会选择维持竞价但优化 listing如果是成熟期Agent 会直接降价。这种上下文感知的决策是规则引擎做不到的。3.3 素材优化LLM 怎么帮你想广告文案广告素材优化是 LLM 最能发挥价值的地方。传统做法是运营自己想文案想不出来就抄竞品抄来抄去同质化严重。LLM 的优势是它能快速生成大量变体而且能基于数据来生成。具体怎么做呢我会把产品的核心卖点、目标人群的评论关键词、竞品的文案风格一起喂给 LLM让它生成 20 个版本的标题和 5 个版本的描述然后 Agent 会自动把这些版本分配到不同的广告组去测试。测试跑一段时间之后Agent 会收集每个版本的表现数据再反馈给 LLM让它基于表现好的版本生成新一轮变体。这个生成—测试—反馈—再生成的循环就是 Agent 在素材优化上的完整工作流。我实测下来用这种方式跑两周广告点击率平均能提升 15%-20%因为它是数据驱动的迭代而不是靠人的灵感。3.4 预算分配跨广告组的动态调拨逻辑预算分配是投放里最考验决策水平的环节。一个账户里有十几个广告组每个组的转化效率不一样但你不能把所有预算都给表现最好的那个组因为那样会导致单组预算消耗过快、边际效益递减。传统做法是手动调一周调一次调完就不管了。Agent 的做法是动态调拨每天甚至每几个小时就重新分配一次。具体的逻辑是Agent 会计算每个广告组的边际转化成本也就是每多花一块钱能带来多少额外转化。然后把预算从边际成本高的组往边际成本低的组转移。这个计算需要实时数据支持所以投放 Agent 必须和广告平台的数据接口打通。我一般会设一个调拨阈值比如两个组的边际成本差异超过 20% 才触发调拨避免频繁调整导致数据波动。4. 多 Agent 协作选品和投放怎么联动起来4.1 为什么单个 Agent 不够用如果你只做一个选品 Agent 或者只做一个投放 Agent那单 Agent 架构是够的。但如果你想让选品和投放真正联动起来单 Agent 就会遇到瓶颈。原因是这两个任务的上下文差异太大选品 Agent 需要的是市场趋势、竞品格局、供应链信息投放 Agent 需要的是实时竞价、转化数据、素材表现。把这些都塞进一个 Agent 的上下文里会导致 prompt 过长、推理变慢、准确率下降。更好的做法是拆成多个 Agent每个 Agent 专注一个领域然后通过一个协调层来串联。这就像公司里的部门分工选品部负责选品投放部负责投放但两个部门之间要有信息同步机制。多 Agent 架构的核心挑战就是设计好这个同步机制。4.2 协调层的设计谁来决定信息怎么流转协调层是多 Agent 架构的中枢神经。它的职责不是做具体决策而是决定什么时候让哪个 Agent 做什么。比如投放 Agent 发现某个品的转化率持续下降协调层会判断这是投放问题还是选品问题。如果是投放问题就让投放 Agent 去优化如果是选品问题就把信号传给选品 Agent让它重新评估这个品。协调层的实现方式有两种。一种是中心化有一个主 Agent 负责调度其他 Agent 都是它的工具。另一种是去中心化每个 Agent 都能主动发起协作请求。我实际用下来中心化更适合跨境电商场景因为业务逻辑相对清晰中心化调度更容易控制和调试。去中心化虽然更灵活但容易出现Agent 之间互相踢皮球的情况排查起来很痛苦。4.3 共享记忆让所有 Agent 看到同一份数据多 Agent 协作的另一个关键点是共享记忆。如果每个 Agent 都有自己的记忆那它们看到的数据就是割裂的。比如选品 Agent 记录了这个品在测试期表现良好但投放 Agent 不知道它看到的是这个品的广告转化率在下降两个 Agent 就会得出矛盾的结论。共享记忆的设计要点是有一个统一的事实库所有 Agent 的观察结果都写进去所有 Agent 做决策时都从这里读。这个事实库要区分原始数据和结论数据。原始数据是客观的比如这个品过去 7 天的转化率是 3.2%。结论数据是主观的比如这个品处于衰退期。区分这两者的好处是当结论出现矛盾时可以回溯到原始数据去验证。4.4 冲突处理当两个 Agent 给出相反建议时怎么办多 Agent 架构一定会遇到冲突。选品 Agent 说这个品值得加大投入投放 Agent 说这个品的广告效率在下降建议缩减。这时候协调层怎么处理我的做法是设一个优先级规则涉及资金安全的决策优先涉及长期战略的决策优先于短期优化。具体到这个例子投放 Agent 的信号是短期的、基于实时数据的选品 Agent 的信号是长期的、基于趋势分析的。协调层会先采纳投放 Agent 的建议缩减预算同时通知选品 Agent 重新评估如果选品 Agent 坚持认为这个品有长期价值那就进入人工介入流程。这个冲突处理机制的核心思想是Agent 不是要取代人而是要把人从重复劳动中解放出来让人专注于处理真正需要判断力的例外情况。5. 落地实操从零搭一个最小可用的选品 Agent5.1 技术选型别一上来就上重型框架很多人一提到搭 Agent 就想到 LangChain、LangGraph 这些框架觉得不用框架就不专业。我的经验是如果你只是做一个最小可用的选品 Agent完全不需要这些。一个 Python 脚本加一个 LLM 的 API 调用就够了。框架的价值在于处理复杂的多 Agent 协作和状态管理如果你还没到那个复杂度上框架只会增加调试成本。我建议的起步方案是用 Python 写主逻辑用 requests 或者 httpx 做数据抓取用 pandas 做数据处理用 OpenAI 或者国产模型的 API 做推理。整个系统跑起来可能就几百行代码。等你发现状态管理好乱Agent 之间传数据好麻烦的时候再考虑引入框架。这时候你已经对业务逻辑很清楚了用框架也能用得更顺手。5.2 数据抓取合规和稳定性的平衡数据抓取是选品 Agent 最容易出问题的环节。两个坑一是合规问题二是稳定性问题。合规方面能用官方 API 的就用官方 API虽然申请麻烦、有调用限制但胜在稳定合法。没有官方 API 的用 RPA 工具模拟人工操作比直接写爬虫要安全因为 RPA 的操作节奏更像真人。稳定性方面一定要做重试机制和降级方案。比如某个数据源挂了Agent 要能自动切换到备用源或者至少能告诉你这次分析缺少了某个维度的数据。注意抓取频率一定要控制。我见过有人为了数据新鲜把抓取频率设成每分钟一次结果 IP 被封、账号被限。合理的频率是榜单数据一天一次竞品详情数据一天两次评论数据一周一次。数据不是越新越好够用就行。5.3 Prompt 设计怎么让 LLM 输出结构化的选品结论Prompt 设计是决定 Agent 输出质量的关键。我的经验是不要指望 LLM 一次就输出完美结果要用分步推理的方式。具体来说把选品分析拆成几个步骤第一步让 LLM 提取评论里的关键痛点第二步让它对比竞品的差异化点第三步让它基于前两步的结论给出建议。每一步都要求它输出结构化的 JSON而不是自由文本。为什么要结构化因为后续的 Agent 逻辑要基于这些结论做判断自由文本没法程序化处理。我一般会在 prompt 里明确给出 JSON 的 schema比如{pain_points: [{point: ..., frequency: ...}], differentiation: [...], recommendation: {...}}。这样 LLM 输出的结果可以直接被程序读取不需要再做解析。5.4 验证环节怎么判断 Agent 的选品建议靠不靠谱Agent 跑出来的建议不能直接拿去执行一定要有验证环节。我的做法是小成本实测Agent 推荐的品先不备货而是用少量广告预算去测试。比如给每个推荐品分配 50 美元的测试预算跑一周看点击率和加购率。如果数据达标再进入备货流程如果不达标就把数据反馈给 Agent让它分析偏差原因。这个验证环节还有一个作用积累训练数据。每次实测的结果不管是成功还是失败都是宝贵的反馈。把这些反馈存进记忆层Agent 下次做推荐时就会更准。我实测下来一个选品 Agent 跑三个月推荐准确率能从最初的 40% 提升到 70% 左右靠的就是这种持续反馈。6. 踩过的坑和实际效果复盘6.1 数据口径不一致导致的误判这是我踩过最大的坑。不同数据源对同一个指标的定义可能不一样比如月销量亚马逊榜单上的月销量是平台估算的第三方工具抓的月销量是另一个算法估算的两者可能差 30% 以上。如果 Agent 在分析时混用了这两个数据源得出的结论就会失真。解决办法是在数据层做口径统一。所有进入分析层的数据都要标注来源和口径Agent 在做对比分析时只对比同口径的数据。如果必须跨源对比要在结论里注明此对比存在口径差异仅供参考。这个细节看起来小但不处理的话Agent 的结论会越来越偏。6.2 LLM 幻觉在选品场景里的具体表现LLM 幻觉在选品场景里最常见的表现是编造数据。比如你让它分析某个竞品的评论它可能会说该产品有 1200 条评论其中 35% 提到续航问题但实际上你只给了它 200 条评论的数据。它把数字放大了而且看起来很合理你不仔细核对根本发现不了。防范方法是所有涉及数字的结论都要求 LLM 引用原始数据。比如 prompt 里明确要求每个结论后面必须附上支撑该结论的原始数据条数和具体引用。另外关键数字要用程序做二次校验不能完全信任 LLM 的输出。我现在的做法是LLM 负责定性分析定量计算交给 pandas 做两者结合。6.3 广告平台风控对 Agent 操作的限制广告投放 Agent 如果操作太频繁很容易触发平台风控。我一开始把调价频率设成每 15 分钟一次结果账户被限制了。后来改成每小时一次并且每次调价幅度不超过 10%就稳定了。另外Agent 的操作要模拟人工节奏不要在同一秒内对几十个关键词同时调价要分散开。还有一个细节Agent 的操作日志要完整记录。万一账户被风控你可以拿着日志去申诉证明这些操作是系统性的优化行为不是恶意操作。日志要包含时间、操作对象、操作前后的值、决策理由。这些信息在排查问题时也很有用。6.4 实际跑下来的效果数据最后说一下实际效果。我在一个中等规模的亚马逊店铺上跑了这套架构选品环节Agent 每周推荐 10-15 个潜力品人工筛选后实际测试 3-5 个测试成功率即测试后决定备货的比例从人工选品的 20% 左右提升到了 45% 左右。投放环节Agent 管理的广告组 ACOS 平均下降了 8-12 个百分点主要来自更及时的竞价调整和更合理的预算分配。当然也有不理想的地方。素材优化环节的提升没有预期那么大因为广告素材的效果受产品本身影响很大LLM 生成的文案再好产品不行也白搭。另外多 Agent 协作的调试成本比预期高尤其是冲突处理逻辑改了三四版才稳定下来。总体来说这套架构适合有一定数据基础的团队如果你连基础的数据采集都没做好建议先把数据层搭起来再考虑上 Agent。这个方向后续还能扩展的地方很多比如把供应链数据接进来做备货预测或者把客服对话数据接进来做产品改进建议。但我的建议是一次只加一个环节跑稳了再加下一个别贪多。