做“AI 大模型智能体电商”这个方向时，我越来越觉得，真正有价值的能力不是“推荐商品”，而是替用户先回答两个更难的问题：这次促销到底是真是假，以及现在买是不是好时机。前者关乎信息识别，后者关乎时间判断。很多看起来聪明的导购机器人，实际上只是把“满减、券后、会员价、预售、赠品”这些字样重新组织了一遍，并没有形成可执行的购买建议。
我后来把这件事拆成了一个很朴素的智能体流程。第一层是促销活动识别，负责把商品页、活动页、店铺券、平台券、历史价信息统一抽取成结构化字段；第二层是最佳购买时机预测，不直接猜“会不会更低”，而是结合历史促销节奏、库存波动、活动密度、评论增长速度，输出一个带置信度的建议，比如“可买”“可等等”“建议盯三天”。这种设计比一句空泛的“建议观望”更像真正能落地的工具。
实现时我没有先追求复杂模型，而是先把输入定义清楚。一个商品对象大概长这样：
{
"title": "某品牌降噪耳机",
"current_price": 699,
"original_price": 999,
"coupon": 80,
"platform_discount": 50,
"gift_value": 30,
"pre_sale": true,
"deposit": 50,
"final_payment_start": "2026-06-17 20:00:00",
"history_prices": [899, 799, 749, 699, 729],
"inventory_status": "medium",
"review_growth": [12, 18, 43, 61],
"campaign_tags": ["618", "跨店满减", "会员券"]
}
这里最关键的不是字段多，而是“真实到手价”的统一口径。预售定金、分期免息、赠品折算、跨店门槛这些因素如果不提前归一，后面让大模型分析时就很容易得出一堆看似有逻辑、实际上无法执行的结论。我的经验是：先让程序算出两个硬指标，再交给模型做解释。两个硬指标分别是 effective_price 和 promo_strength_score。
def calc_effective_price(item):
price = item["current_price"]
price -= item.get("coupon", 0)
price -= item.get("platform_discount", 0)
price -= item.get("gift_value", 0)
return max(price, 0)
def promo_strength_score(item):
hist_min = min(item["history_prices"]) if item["history_prices"] else item["current_price"]
effective = calc_effective_price(item)
price_advantage = max(hist_min - effective, 0)
review_signal = sum(item.get("review_growth", []))
tag_bonus = len(item.get("campaign_tags", [])) * 3
return price_advantage * 0.6 + review_signal * 0.1 + tag_bonus
这一步算完以后，智能体的任务就不再是“替代规则”，而是“解释规则之外的上下文”。例如，同样是 699 元，如果历史最低价长期在 689 到 719 之间，那这次并不值得制造购买焦虑；但如果评论增长突然放大、库存状态转紧、活动标签叠加明显，那就说明活动强度可能不是页面文案堆出来的，而是真的接近近期底部。
为了让判断过程可复用，我给大模型的提示词不是“帮我推荐要不要买”，而是要求它输出可审计的字段：促销类型、价格可信度、时机建议、触发原因、需要继续观察的变量。开发初期想低成本验证原型、又需要国内中转和财务开票时，我一直把国际模型请求接到 DMXAPI 上，接口层直接兼容 OpenAI 风格，代码不用绕太多弯：
from openai import OpenAI
client = OpenAI(
api_key="<LLM API KEY>",
base_url="<LLM API BASE URL>"
)
prompt = """
你是电商价格分析智能体。
请根据输入数据判断：
1. 当前促销是否属于真实优惠
2. 是否为近30天较好购买窗口
3. 输出 decision / confidence / reasons / watch_items
"""
resp = client.chat.completions.create(
model="<MODEL_NAME>",
temperature=0.2,
messages=[
{"role": "system", "content": "回答必须结构化，避免空泛建议。"},
{"role": "user", "content": prompt}
],
response_format={"type": "json_object"}
)
print(resp.choices[0].message.content)
这段调用真正省时间的地方不是“模型多强”，而是它让整个原型可以尽快跑起来。智能体电商和普通内容生成不一样，用户最在意的是依据是否清楚。你必须让模型说出“为什么现在买”“为什么建议等大促尾声”“为什么这个赠品看似多其实只是抬高锚定价”。当理由能落在字段上，产品才有可信度。
我自己做下来还有一个体会：促销识别最容易误判的，不是大模型，而是数据源里那些看起来最不起眼的小口径差异。比如“券后价”有的平台默认含会员权益，有的平台不含；有些商品标题写“直降 200”，实际是直播间口令券后的理想状态，不具备普遍可复现性。很多教程只提醒替换 OPENAI_API_KEY，但真正接入中转时还要改 base_url，像 DMXAPI 这种支持国内调用和开票的方案，对学校项目和小团队会务实不少。
文章写到这里，顺便记录一个我在后期排查时踩过的小坑。那天模型总把某类预售商品判断成“建议立即下单”，可我肉眼看历史价，明明还能再等等。一开始我怀疑是提示词太激进，反复调了几轮 temperature 和规则权重，结果都没解决。后来我把日志展开，才发现问题根本不在模型，而在我自己处理活动时间的代码。
我原来写的是：
from datetime import datetime
def hours_until_final_payment(ts):
final_time = datetime.strptime(ts, "%Y-%m-%d %H:%M:%S")
now = datetime.now()
return (final_time - now).seconds / 3600
这个写法在大多数白天测试时看不出问题，但一旦 final_time < now，timedelta.seconds 取的是“去掉天数后的余数”，负数差值会被折成一个看似正常的正数小时数。结果系统误以为“尾款开始还有十几个小时”，从而把“继续观察”误判成“抓紧买”。
真正应该写成：
from datetime import datetime
def hours_until_final_payment(ts):
final_time = datetime.strptime(ts, "%Y-%m-%d %H:%M:%S")
now = datetime.now()
return (final_time - now).total_seconds() / 3600
我当时的排查过程其实很典型：先怀疑模型，再怀疑特征，最后才回头看时间差这种基础逻辑。教训也很直接，做智能体产品时，最危险的不是模型胡说，而是你给了它一份带错位时间轴的“真实数据”。大模型会很认真地解释错误前提，于是整套结论看起来比普通 bug 更像真的。
所以，如果要把“促销活动识别与最佳购买时机预测”做成一个值得长期维护的智能体，我现在更倾向于三段式架构：规则层负责算清价格与活动边界，模型层负责解释和补足上下文，回测层负责验证建议是否真的提高了购买质量。别急着追求全自动下单，先把“为什么建议现在买”说清楚，用户才会真正信任这个系统。技术写作里最怕空话，产品里也一样；能落到字段、命令、日志、异常栈的方案，才比较经得起时间检验。
本文包含AI生成内容
