浏览量涨了3.5倍之后，推荐系统和Agent的第一反应不一样
先看推荐系统。它的目标通常是“提高点击和转化”，看到某件球衣的点击率上升，就会把它推给更多相似用户。这在大部分时候是合理的，但它不会追问这次上涨从哪里来，也不会去看库存：如果这件球衣线上只剩几百件，推得越多，断货越快；如果上涨来自一条不实传闻，推得越多，后面的退货和积压越多。推荐系统本身也在进化，从“买了这个的人还买了那个”走向理解赛事和场景，体育电商推荐为什么要读懂上下文讨论过这一点；但即使是理解上下文的推荐，回答的仍然是“给谁推什么”，而不是“现在该不该做点什么”。
Commerce Agent 的出发点不同。它不是一个排序模型，而是一个带着目标去工作的流程：发现一个信号，判断值不值得处理，查清楚原因，估计影响，给出建议，执行之后继续跟踪。欧宝体育把这个流程写成五步：Detect → Analyze → Forecast → Recommend → Monitor。下面用那位中场球员的例子（以下均为模拟场景和示例数据）逐步走一遍。
Detect：先确认这是一个值得处理的信号
浏览量涨3.5倍，第一件事不是行动，而是排除噪声。Agent会检查几件事：
- 流量来源：上涨是否集中在单一来源，比如某个投放链接、某个合作方页面，甚至爬虫流量。
- 用户结构：新增的访问来自多少独立用户，是否有异常集中的设备或IP段。
- 内部因素：这件商品这两天是否刚被运营放上首页，或者正在做测试。
- 历史基线：同一时段、同类球员球衣过去的正常波动范围是多少。
在模拟场景里，排除一批爬虫流量后，真实浏览量仍是平时的2.8倍，来自约一万两千个独立用户，其中四成来自社交平台跳转。这个信号通过了第一关。
Analyze：顺着信号去查搜索、赛事、库存、门店和人群
接下来Agent会并行调用多个模块，把一个“浏览量上涨”拆成可以判断的事实：
- 搜索：这位球员的名字和号码在站内搜索里涨了2.2倍，站外相关讨论集中在他上一场比赛的一次长传助攻集锦。
- 赛事：球队周六有一场主场比赛，对手是同城球队，关注度本来就高。
- 库存：线上仓这件球衣剩420件，其中M码和L码合计不到200件；城市门店合计900件，体育场商店600件。
- 销售：浏览量涨了，但加购率只涨了40%，下单量几乎没有变化——很多人是看集锦跳过来的，还没有形成购买。
- 门店：线下门店里，这件球衣的销量集中在球队主场所在城市的三家店，其他城市基本没动。
- 用户人群：新增访问中，约三成是已有这位球员其他商品的老用户，七成是近三十天才注册的新用户。
这一步的产出不是一个结论，而是一组有来源的事实。它把“浏览量上涨”变成了一句更具体的话：一次比赛集锦带来的关注，主要是新用户，加购开始上升但尚未转化，周六有主场比赛，线上热门尺码偏紧，线下库存集中在主场城市。
Forecast：给出一个区间和几种情景，而不是一个数字
基于这些事实，Agent请 Forecast Model 估计未来七天的需求。合理的输出不是“会卖出800件”，而是带条件的区间：如果关注在两三天内回落，线上七天销量约在300到450件之间；如果周六比赛中这位球员再有突出表现，可能达到700到900件。同时，Forecast Model 还会给出按尺码的缺货概率：在第二种情景下，M码和L码大概率在周日前断货。
区间和情景的意义在于，它让后面的建议可以按情况分层，而不是被一个点估计绑死。这和判断一次热度到底是峰值还是趋势的问题是同一类问题，预测模型要明确说出自己不确定的地方。
Recommend：建议是写给运营看的，不是直接执行的
在模拟场景里，Agent最终给出了四条建议，每一条都附带证据、预期效果和做错的代价：
- 从区域总仓向线上仓调拨M码、L码各150件。依据：线上热门尺码偏紧，第二种情景下周日前断货；代价：如果关注回落，这300件会在线上多压两到三周。
- 在推荐位中，对近三十天新注册用户适度提高这件球衣的曝光，但设置曝光上限；对已购买过同款的老用户不重复推荐。
- 准备一套“球员表现突出”情景下的首页素材，周六赛后根据实际情况决定是否发布。
- 暂不做任何折扣，也不向体育场追加库存：体育场现有600件已足够覆盖一场主场比赛的正常需求。
注意这里的第四条：一个好的Agent不只是提出“要做什么”，也会明确说出“不需要做什么”。这对运营团队同样是有价值的信息。关于一次完整的运营流程里人和系统各自负责哪一段，欧宝体育官网的体育商品运营流程里有更完整的描述。
Monitor：执行之后继续盯着，并且知道什么时候停
建议被批准执行后，Agent会为每一条设置跟踪指标和停止条件。例如，推荐位曝光提升之后，如果两天内加购率没有继续上升、退出率反而上升，就自动撤回曝光调整；调拨完成后，每天对比实际销量和预测区间，一旦销量连续两天低于区间下限，就提示运营考虑暂停后续调拨。周六比赛结束后，Agent会根据实际情况重新运行一次 Analyze 和 Forecast，而不是沿用周二的判断。
Monitor 这一步也是 Agent 学习的来源：哪些信号最后被证明是真实需求，哪些是噪声，哪些建议被运营否决了、为什么被否决，都会成为下一次判断的参考。
Agent不是一个更大的聊天模型，而是调度一组专业模块
从上面的流程可以看出，真正的数字几乎都不是大模型“想”出来的。欧宝体育的 Sports Commerce Agent 更像一个调度者：
| 模块 | Agent向它要什么 | 返回什么 |
|---|---|---|
| Recommendation Engine | 当前推荐位的曝光与转化，可调整的权重范围 | 分人群的曝光、点击、加购数据和调整后的排序 |
| Forecast Model | 未来七天需求 | 按情景和尺码的需求区间、缺货概率 |
| Inventory Engine | 各位置可售库存和可调拨量 | 商品×尺码×位置的库存与调拨时效 |
| Retail Analytics | 各渠道、门店的销售速度 | 线上、门店、体育场的分渠道销售表现 |
| Market Intelligence | 站内外搜索与讨论的变化 | 热度来源、话题构成和持续性判断 |
大模型在其中负责的是：理解信号，决定该问哪些模块、按什么顺序问，把各模块返回的结果串成一条有证据的推理，并用运营看得懂的语言写出建议。它不应该自己去估计销量，也不应该凭“印象”判断库存够不够。把这些交给专门的模型和系统，Agent才可靠；把所有事情压给一个对话模型，结果往往是一段看起来很有道理、但数字无法核对的文字。这也是欧宝体育AI大模型在设计上坚持模块化的原因。
哪些事可以自动做，哪些必须等人点头
Agent 能发现机会，不代表它可以随意行动。欧宝体育建议按动作的影响范围和可逆程度划分三条边界：
| 边界 | 典型动作 | 理由 |
|---|---|---|
| 可自动执行 | 生成监测报告、发出预警、在预设上限内微调推荐权重、撤回自己此前做的推荐调整 | 影响小、可随时撤回 |
| 需要人工审批 | 超过阈值的库存调拨、首页和推送内容、与球员相关的纪念内容、补货和采购建议 | 涉及成本、品牌表达或难以撤回 |
| 禁止执行 | 改价和折扣、低于价格底线的任何操作、超出用户授权范围的触达 | 影响价格体系和用户信任，必须由人负责 |
在边界之外，还需要几条硬性的防护：每类动作设置每日次数和数量上限；同一商品在一次调整后有冷却期，避免来回摆动；所有自动动作都可以一键回滚；当关键数据源延迟超过设定时间，Agent只报告、不执行。
审计日志：每一个建议都要能追溯到证据
运营团队敢于采纳Agent的建议，前提是能看清它为什么这么建议。每一次从 Detect 到 Recommend 的过程，都应该留下完整记录：触发的信号和阈值、当时各模块返回的数据快照、使用的模型版本、生成的建议及其依据、审批人和审批结果、执行后的实际效果。这样一来，事后复盘时可以区分“建议本身错了”和“建议没错，但情况后来变了”；出现问题时，也能准确找到是哪一个环节的数据或判断出了偏差。
Agent最容易犯的三种错误
- 把虚假信号当成需求：爬虫流量、一条后来被澄清的转会传闻、某个合作方的误投放，都可能制造出漂亮的上涨曲线。防护办法是在 Detect 阶段做来源校验，并要求至少两类独立信号（例如浏览和站内搜索）同时成立才进入下一步。
- 自我强化的反馈回路：Agent提高了曝光，浏览量随之上涨，Agent又把这份上涨当成需求增强的证据，继续提高曝光。防护办法是给Agent自己引发的流量打标签，在判断需求时单独剔除，并保留一部分用户作为对照组。
- 用过期的数据做实时判断：库存数据延迟几个小时，Agent可能建议调拨一批已经卖掉的货。关键数据源必须带时间戳，超过时效就降级为只提示。
从一个品类、一个动作开始
从推荐商品走向主动发现库存和消费机会，这一步不需要一开始就把所有权限交给Agent。更实际的做法是选一个品类，比如球员球衣，只开放“发现信号并生成建议”这一项能力，让运营团队连续一两个月对照Agent的建议和自己的判断：哪些信号它比人更早发现，哪些建议被证明是对的，哪些误报需要调整阈值。等这些记录积累起来，再逐步把低风险、可回滚的动作交给它自动执行。衡量一个Commerce Agent好不好，不是看它自动做了多少事，而是看它有没有更早发现该发现的信号、有没有把证据核对完整，以及有没有把需要人判断的事情清楚地交还给人。
