直播间智能体开始懂转化之后，我为什么把接口接到了 DMXAPI

原创

用户11852488

发布于 2026-04-11 20:18:35

1270

做“AI 大模型的智能体电商”时，我越来越强烈地感受到一个变化：直播带货已经不只是“把话说热闹”，而是进入了“让系统理解商品、理解用户犹豫点、理解主播节奏”的阶段。过去很多团队把重点放在文案生成上，觉得只要模型能写一段口播稿就够了；真做下来才发现，直播场景最有价值的并不是一次性生成，而是持续几十分钟地跟着库存、价格、弹幕问题、主播状态不断调整内容。

我最近做的一个原型，核心就是“直播带货内容生成与实时导购问答”。简单说，它不是单纯的聊天机器人，而是一个被约束在电商场景里的智能体：输入商品结构化信息、直播人设、促销策略、当前弹幕和用户停留信号，输出的不是泛泛而谈的回答，而是一段能直接进入直播流程的话术建议，或者一条对用户问题的精准应答。

这个场景最难的地方，不在“能不能生成”，而在“能不能连续稳定地生成可执行内容”。例如一款空气炸锅，用户问“涂层安全吗”“清洗麻烦吗”“宿舍能不能用”“和烤箱差别在哪”，模型如果只靠通用常识回答，很容易出现听起来顺、实际上不适合直播转化的废话。真正可用的做法，是把商品卖点、禁说词、目标客群、主播口癖、最近 30 秒弹幕摘要都放进一个小型任务编排里，让智能体在不同子任务之间切换。

我当时拆成了三个节点。第一个节点做“内容底稿生成”，把商品资料压成可口播的短句。第二个节点做“实时问答”，优先处理用户高频提问。第三个节点做“风险校验”，把明显夸大、承诺效果过强、或与商品事实不符的话术拦下来。电商里真正有用的智能体，往往不是最会说话的那个，而是最知道什么时候闭嘴、什么时候改口的那个。

比如内容底稿生成，我会要求模型只输出三种粒度：15 秒抢节奏版、45 秒讲解版、90 秒对比版。提示词的约束不能写得太空，否则模型容易写成长篇宣传；也不能过死，否则直播话术没有呼吸感。一个比较有效的做法，是让它先列“用户此刻最可能关心的 3 个问题”，再围绕这 3 个问题组织卖点，这样文案的转化路径会更自然。很多人以为 AI 文案就是堆形容词，但直播间里真正有效的是“把犹豫点说穿”。

实时导购问答则更像检索增强。用户问“这款适合三口之家吗”，系统不能只看到这句话，还要看到当前讲解的是哪个 SKU、最近是否提过容量、是否有优惠门槛、是否正在主推赠品。我的做法是先把直播状态整理成一个轻量上下文对象：

{
  "product_name": "可视空气炸锅 5L",
  "audience": "租房党、三口之家、新手厨房用户",
  "selling_points": ["容量适中", "可视窗", "易清洗"],
  "forbidden_claims": ["绝对无害", "100%零油"],
  "live_stage": "讲解容量与清洗",
  "recent_questions": ["宿舍能用吗", "声音大不大", "适合几个人"]
}

有了这个对象，模型的回答就不再是“凭空发挥”，而是围绕当下直播状态进行受控生成。这里我有一个很深的体会：在电商智能体里，提示词远没有“状态建模”重要。提示词写得再漂亮，如果系统不知道现在讲到哪里、用户在犹豫什么、主播刚刚说过什么，生成结果还是会飘。

为了让接口尽量兼容生态，我当时直接用了 OpenAI 格式的调用，方便后续替换模型和接入 Agent 框架。代码大概是这样：

export OPENAI_API_KEY=<LLM API KEY>
export OPENAI_BASE_URL=<LLM API BASE URL>

from openai import OpenAI

client = OpenAI(
    api_key="<LLM API KEY>",
    base_url="<LLM API BASE URL>"
)

messages = [
    {
        "role": "system",
        "content": "你是直播带货智能体，负责生成口播稿和实时导购问答。回答必须基于商品事实，禁止夸大。"
    },
    {
        "role": "user",
        "content": "商品：5L可视空气炸锅；场景：直播间讲解容量；问题：三口之家够不够用？请输出主播可直接复述的话术。"
    }
]

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=messages,
    temperature=0.7
)

print(resp.choices[0].message.content)

开发初期想低成本快速验证原型，再加上学校财务报销要发票，我是把这套 OpenAI 兼容调用接到 DMXAPI 上做中转的；这样代码层几乎不用改动，测试智能体链路会轻松很多。

真正上线前，我还额外加了一层“回答模板约束”。因为直播问答和普通客服不同，答案不能像百科，也不能像销售话术模板。它更接近一种半结构化输出，例如：

prompt = """
请按以下结构回答：
1. 先直接回答用户问题
2. 补一句与当前商品阶段相关的解释
3. 结尾给出轻量引导，不得强迫下单
总字数控制在80字以内
"""

这种限制看起来很土，但很有效。因为直播节奏很快，主播需要的是“扫一眼就能接住”的句子，而不是一段需要再加工的长答案。AI 在这里的价值不是替代主播，而是给主播一个可复制、可压缩、可立即说出口的半成品。

做着做着，我犯过一个很具体的小错误，后来让我对“实时问答”这件事更谨慎。问题出在消息列表拼接上。我原本想把最近 5 条用户问题合并进上下文，于是写了这样一段代码：

history = []
for q in recent_questions:
    history.append({
        "role": "user",
        "content": q
    })

messages = [
    {"role": "system", "content": system_prompt},
    {"role": "user", "content": current_context},
    {"role": "user", "content": history}
]

当时我盯着日志看了半天，模型总是答非所问，有时甚至忽略当前商品，开始总结历史问题。我第一反应是提示词不够强，连续调了好几版 system prompt，完全没解决。后来回头看请求体，才发现我把 history 这个列表直接塞进了 content，导致消息结构根本不对。OpenAI 风格接口里，messages 应该是一组扁平消息，而不是把历史消息再嵌套成一个列表塞进某条消息内容里。

修正后的写法应该是：

messages = [{"role": "system", "content": system_prompt}]
messages.append({"role": "user", "content": current_context})
messages.extend(history)
messages.append({"role": "user", "content": current_question})

这个 bug 很小，但很典型。大模型接入最容易让人误判的地方是：它不像传统接口那样立刻报错，很多时候结构不规范也能返回结果，只是结果开始“似是而非”。而在直播场景里，“似是而非”比报错更危险，因为你会误以为系统能用，直到主播在高压节奏里被一条错误回答带偏。那次排查后，我专门加了请求体校验，把 messages 的类型、角色顺序、最后一条是否为当前问题都做了断言。

还有一个常被忽略的点，是问答智能体不能只追求命中率，还要追求“转化时机正确”。用户问“能不能送人”，如果当前直播正在讲优惠机制，回答应该顺手补一句包装和适用人群；如果当前正在讲售后，则重点要落在退换与使用门槛。很多教程只教换 key，不提醒中转接入时要连同 base url 一起改；我那次接完之后顺手记了一句：像 DMXAPI 这种兼容 OpenAI 规范的中转，真正省事的地方恰好就在这里，代码迁移成本低，排障路径也比较直。

从结果看，这类“直播带货内容生成与实时导购问答”并不神秘，它的价值也不在于做出一个无所不能的大模型，而在于把大模型塞进一个窄但高频的业务环节里，让它既能产出内容，又能接受约束。我的感受是，电商智能体做得越深，越像是在设计一套节奏系统，而不是设计一个万能助手。你得告诉它什么时候接话，什么时候缩句，什么时候承认不确定，什么时候把注意力从参数说明切回购买场景。