企业官网建设流程全解析

去年我们团队接到一个电商直播间的智能化改造需求，目标很明确：用AI Agent把主播从重复问答里解放出来。当时我觉得这活儿不复杂，做个弹幕机器人，关键词匹配加固定回复，一星期就能上线。真正跑起来才发现，直播是AI落地最苛刻的场景之一——画面在动、弹幕爆炸式增长、观众随时进随时走，更别提查库存、改价格、发优惠券这些真实业务动作。我们一路从"关键词机器人"迭代成了"能看图、能听声、能调接口、能记住老粉丝"的完整Agent。这篇分享把验证过的核心技能清单、架构决策和踩坑记录整理出来，适合正在做直播中台、电商SaaS，或者想用Agent改造直播业务的团队参考。

1. 直播场景的独特之处：为什么Agent比脚本更值得做

1.1 三个决定技术方案的场景特性

直播和图文、录播视频最大的区别是三件事：强实时、群体性、业务强耦合。

强实时意味着决策窗口极短。短视频用户刷到一条不喜欢的内容划走，损失只有几秒；直播间观众一旦觉得无聊，下一秒就退出去了。弹幕里问"多少钱""有没有蓝色"，如果30秒内没有回答，这个人多半已经滑到隔壁直播间。所以直播Agent的每一步都要围绕延迟做设计，这是一切架构选择的出发点，后面所有方案取舍都绕不开这个前提。

群体性指的是直播间的交互不是一对一，而是一对N。同一个瞬间可能有几百条弹幕同时刷过，问题重复率极高，同时还存在群体情绪——主播说错话，弹幕会集中嘲讽；主播展示爆款，弹幕齐刷刷催链接。Agent如果只逐条处理，不仅效率低，还会因为缺少上下文而闹笑话。

业务强耦合更直接：直播最终是为了成交。观众问完"有没有货"，下一步就是"怎么买"。Agent不能只输出一句话，它必须能查库存、改状态、发券、引导下单，也就是要真正操作业务系统。这一点把Agent和纯聊天机器人彻底区分开，也是直播场景对Agent要求远高于普通客服机器人的根本原因。

1.2 脚本与Agent的真正分界线

在团队内部我经常用一句话区分：脚本是"如果A，则回复B"，Agent是"感知现状、做出决策、执行动作"的闭环。

传统弹幕机器人面对"这个多少钱"只能匹配"多少钱"关键词，回复固定话术。但它不知道"这个"指的是主播手里那件商品，不知道提问用户是不是会员，不知道库存其实只剩两件。Agent则把这些信息全部纳入上下文：当前讲解的商品、用户的历史互动、实时库存数据，再决定是直接回答、调用查询接口，还是引导用户私信客服。

举个具体例子：弹幕问"还有优惠吗"，脚本机器人顶多回复"有优惠，点击下方链接"。Agent会先看当前商品上下文，发现主播五分钟前刚说过"今晚限时减20"，再看用户标签是老粉丝，于是回复"您上次买过同品牌，今晚额外有老客券，已帮您查过能用，点购物车自动抵扣"。这两种体验的差距，观众体感非常明显。

这句话说起来简单，实际做起来需要对上下文管理、工具调用、状态维护有一套完整的工程方案，后面的章节会逐个拆。

1.3 直播Agent能落地的五个位置

根据我们和几家直播业务方聊下来的需求，Agent最有价值的落点集中在五个位置：

• 主播副驾：实时生成话术建议，提醒价格、卖点、催单节奏，相当于给主播配了个脑子里装着整场脚本的合伙人。
• 智能导购：回答弹幕商品咨询，配合工具完成查库存、发券、加购，这是目前落地最成熟、收益最直接的位置。
• 场控助手：处理垃圾广告、恶意刷屏，维护评论区秩序，解放真人场控的精力。
• 数据助理：把实时观看、转化、弹幕情绪浓缩成可读结论，每三分钟给运营一条简报，不用再盯着一堆图表。
• 内容理解引擎：自动抽取精彩片段，生成切片、标题和商品标签，一场直播结束半小时内就能产出几十条短视频素材。

这五个位置的技术底座高度重合，都建立在后面要讲的技能之上。区别只是"感知"的输入不同，"执行"的动作不同。所以先把核心技能打磨好，往上搬场景会快很多。

2. 直播Agent的六大核心技能拆解

这一节是重点。所谓"技能"，在Agent语境里就是一组由模型驱动、可被调用的能力封装。直播场景下最终验证下来，以下六项缺一不可。

2.1 视觉理解技能：看懂画面才能聊画面

直播间里画面承载了大量关键信息：主播手里举着什么商品、屏幕上的促销信息、演示效果、甚至主播的表情状态。如果Agent只能看到字幕和弹幕，它就是个瞎子，弹幕里问"这个颜色好看吗"，它连"这个"是什么都不知道。

我们的做法是对直播画面按1秒到2秒一次的频率抽帧，送入视觉语言模型识别场景，输出结构化结果，比如"主播正在展示一款白色无线耳机，画面左上角有买一送一贴片"。这个结果写入当前的直播上下文，作为Agent回答弹幕的背景信息。

一个经验是：抽帧频率不是越高越好。高频抽帧会带来大量重复推理，成本翻几倍，信息增量却趋近于零。真正需要触发视觉识别的是关键事件——新商品上架、主播切换展示角度、促销信息变化。判断要不要抽帧，可以先用一个轻量的画面变化检测做闸门，比如计算相邻帧的感知哈希距离，超过阈值再调用视觉模型，能省下80%以上的无效推理。

另外，视觉结果必须和相关语音、弹幕做时间对齐。我们踩过一个坑：抽帧识别结果晚到了十几秒，Agent把上一件商品的描述安到了当前商品身上，观众直接开骂。后来所有视觉事件统一打上时间戳，进入消息队列按序消费，才彻底解决。

2.2 语音链路技能：听清、听懂、说好

直播间语音处理比想象中难。主播语速快、有口音、直播间背景嘈杂、大量行业黑话和新品型号出现。自动语音识别不做定制，准确率会惨不忍睹，经常会听错产品型号。

我们的方案是三件事：一是定制热词表，把本场商品名、品牌名、优惠词全部灌进去，专有名词识别率能提升一大截；二是用语音活动检测切分，只对有人声的片段做识别，避免把背景音乐和观众噪音也转成文本，浪费token；三是做流式部分识别，不等主播一整句话说完就输出中间结果，把感知延迟降低一半以上。

TTS的方向常见于数字人直播间。这里给个避坑建议：不要只关注音色像不像真人，更要关注"打断"机制。观众弹幕插话时，数字人需要能停下来、停顿、再继续，否则交互感极差。端到端语音模型越来越成熟，但当前阶段，ASR加LLM加TTS的串联架构仍然更可控，出了问题容易定位是哪一环的锅。

2.3 意图识别与多轮对话技能：弹幕不是关键词匹配

弹幕文本有多碎，做过的人都懂。一条完整的弹幕往往被切成几个字半个词，错别字和缩写满天飞，"这款有xl吗"和"这有S码?"说的是同一件事。用传统意图分类器需要维护大量规则，换个品类就失灵，维护成本高到想放弃。

LLM把这件事简化了很多。我的做法是定义一套固定的结构化输出schema，让模型把每条弹幕归类为"商品咨询、比价议价、物流售后、闲聊、违规"等几个意图，并抽取关键实体，比如商品名、规格、颜色、数量。注意要用JSON Schema约束输出格式，让模型只输出JSON，程序侧再做校验和重试，格式不稳定是所有LLM应用的常见翻车点。

多轮对话是另一个坎。直播弹幕的特点是每个问题都很短，大量依赖上下文："这个有蓝色的吗"——"这个"指什么？答案可能在十分钟前的讲解里。我们的做法是维护一个"当前对话主题"状态，默认把弹幕问题关联到主播正在讲解的商品上。实现就是Redis里存一个当前商品ID，弹幕进来时自动注入对应的商品信息。这个设计简单，但效果比任何花哨的"全局记忆"都好，强烈推荐新手从这里入手。

2.4 工具调用技能：让Agent能干实事

最能体现Agent价值的，是它能执行业务动作。查真实库存、发优惠券、把商品加入购物车、标记恶意用户，这些都是通过工具调用实现的。模型不能只动嘴，它得能动手。

工程上就是给模型声明一组函数的JSON Schema，模型根据对话内容决定"现在应该调用哪个函数、传入什么参数"，然后由程序实际执行，把执行结果回传给模型，模型再生成面向用户的回复。关键点有三个。

第一，参数校验不能省。模型填的参数偶尔会出现非法值，比如把用户ID传成弹幕文本。所有工具执行前必须做类型和格式校验，宁可拒绝也不要带病执行。第二，工具要幂等。直播场景下网络重试很常见，发券接口如果不做幂等，重试一次就多发一张券，这是重大事故。第三，错误处理要让模型"看得懂"。工具返回的错误信息应该结构化，比如返回{"error": "out_of_stock", "product_id": "123"}，模型才能在下一步合理推荐相似款，而不是胡编一个库存数字。

2.5 记忆与上下文技能：跨场次记住老观众

直播间的记忆分两个层次：单场记忆和跨场记忆。单场记忆是这场直播前面讲了什么、回答了哪些问题、主播承诺过什么。跨场记忆是这位观众昨天来过吗、买过什么、在评论区提过什么偏好。

单场记忆最简单的实现是"滚动摘要"：每处理30到50条对话，就让模型把前面的内容压缩成一段摘要，和最近的消息一起作为上下文。这个方案比把所有历史都塞进上下文省钱得多，效果也够用——直播是强实时场景，真正重要的上下文窗口很窄，开播半小时前的细节大部分已经不关键了。

跨场记忆建议配合RAG来做。把用户的历史互动、购买行为离线清洗后写入向量库，弹幕进来时先做向量检索，命中再注入上下文。注意控制检索到的片段数量，两三条足够，别把prompt撑爆。这里还要考虑隐私边界，用户画像只取"他主动问过什么、买过什么"，太细的行为数据不该进prompt，既有隐私风险，也会让模型输出变得冗余甚至怪异。

2.6 内容安全与审核技能：不出错的兜底

直播评论区鱼龙混杂，广告引流、恶意刷屏、人身攻击都可能出现。Agent做场控的时候，光靠关键词黑名单一定被绕过，"加V""看主页"这种变体每天都在换。我们在关键词的基础上叠加了一个语义分类模型，判断弹幕是否属于垃圾营销或攻击性内容，综合打分。

这里有一个很重要的工程原则：审核要走快慢两条路。快路径是词表和规则，命中立即处置，用于处理明确的垃圾信息；慢路径是语义模型，用于判断模棱两可的弹幕。模型推理有延迟，可以异步处理，不阻塞弹幕主流程。处置也要分级：轻度警告、中度禁言、重度移出直播间并同步举报给平台，不能一刀切全踢。

还有一个细节：判断一条弹幕是否违规，要结合上下文。"你完了"这种话，接在主播开玩笑后面和接在争执后面，性质完全不同。所以审核模型也要拿到最近几条弹幕作为上下文，误判率会明显下降。这一条常常被忽略，但恰恰是审核系统能不能用的分水岭。

3. 技能之外的工程底座：实时架构怎么搭

技能是"术"，底座是"道"。直播Agent的技能再强，如果底层架构扛不住延迟和并发，产品照样起不来。这个章节讲架构层面的关键决策。

3.1 事件驱动是直播Agent的命脉

直播间的所有输入都可以抽象成事件：弹幕消息、礼物打赏、商品上下架、库存变动、画面变化、语音片段。Agent本质上是一个事件消费者，拿到事件后走"感知到决策到行动"的流程。

架构上我强烈建议引入消息队列作为事件总线，把采集、处理、回复三段解耦。弹幕网关只负责收消息和写队列，Agent实例只管从队列拉消息处理，回复服务再异步把Agent的输出发回直播间。这样任何一个环节抖动都不会把上游打挂，也方便横向扩容。数据量没到Kafka那种夸张程度的话，Redis Stream或者RocketMQ都够用，关键是事件要有序、可回溯。

直播间是有状态机的：待开播、直播中、暂停、已结束。Agent要随状态机切换行为模式，不能用直播中的逻辑处理开播前的消息。这个状态建议放在Redis里统一维护，多实例共享，不要塞在单个进程的内存里，否则一扩容状态就丢了。

3.2 延迟预算：每个环节能花多少毫秒

做实时AI应用，最忌讳"所有环节都追求最低延迟"。正确做法是先定端到端目标，再往回拆分预算。

以弹幕智能回复为例，我们的目标是端到端3秒以内。拆解下来：

合计约2到3秒，留了一些余量。拆完预算有两个直接作用：一是知道该优化哪里，二是知道哪里不该花冤枉钱。比如弹幕网关和Agent之间的网络传输如果从50ms压到10ms，对整体意义不大，不值得为此引入复杂的底层优化方案。

从实测来看，最值得优化的是大模型生成环节。用流式输出让首token尽快到达、对高频问题做结果缓存、把"多少号""多少钱"这类查询类问题直接走"工具结果加固定话术"的模板，能省下大量延迟。记住：不是所有弹幕都需要LLM生成完整回复，大多数查询类问题用模板就够了。

3.3 工具层设计：Agent与业务系统的边界

Agent不能直接连数据库，这是我们的一条铁律。所有业务动作都要通过统一工具网关转发。原因有三：一是Agent调用的参数不可完全信任，必须有网关做权限校验；二是业务系统需要限流和审计，网关天然适合干这个；三是方便灰度，新工具先让网关放一部分流量，出问题随时熔断。

工具网关暴露给Agent的是统一的函数schema，内部再转换成对各业务系统的调用。每个工具必须有超时设置，比如查库存最多等800ms，超时立刻返回一个特定错误码，让Agent走兜底流程，而不是傻等。曾经有个工具没有设超时，库存服务抖动了一下，Agent消息全部卡在等待上，整个直播间的智能回复停摆了十分钟，这个教训很深刻。

3.4 可观测性与回放：Agent犯错怎么追溯

LLM应用的排错思路和传统程序完全不同。传统程序是断点、日志、堆栈；LLM应用你只能看到"输入了什么，输出了什么"，中间全黑盒。所以从第一天起就要做全链路trace，记录每个决策点：模型输入了哪些上下文、调用了哪个工具、工具返回了什么、最终生成了什么回答、耗时多少、token消耗多少。

直播间出了事故，比如Agent说错话被截图传播，你需要能在五分钟内还原：当时Agent看到的是哪一帧画面、收到了哪几条弹幕、为什么决定这么回复。没有回放机制，你连复盘都做不了。目前主流做法是把关键数据落到对象存储，按直播间ID加时间分片，配合一个简单的管理后台查询。这块投入不大，但出了事故就是救命稻草。

4. 实操：搭一个"直播间自动导购"Agent

理论讲完，上代码。我用一个最小可运行的示例演示核心骨架，框架层面用了目前主流的Function Calling方案——模型负责理解和决策，业务动作全部走工具函数，后面换模型、加技能都不需要动主流程。这里以OpenAI兼容接口为例，换成其他兼容层的模型也成立。

4.1 选型逻辑：为什么用Function Calling而不是写死流程

一开始我们也纠结过：是让模型自由决定调用什么，还是我们写死一个"先查库存再回复"的流程？答案是混合。简单查询类问题用写死流程，快且稳定；复杂对话让模型自由编排工具，灵活但需要约束。

Function Calling的价值在于，模型知道"有什么工具可用"，并且能根据上下文自动选择。比如用户问"这手机有蓝色吗"，模型会发现需要调用查询库存接口并传入"颜色=蓝色"；如果库存为零，模型会看到工具返回的缺货状态，转而推荐白色款。这种自然衔接用if-else写会写死人的，而且每来一个新品类就得重新梳理一遍逻辑。

4.2 核心代码与运行效果

先定义一个最简单的工具集：查库存、发优惠券。

import asyncio, json from openai import AsyncOpenAI client = AsyncOpenAI() INVENTORY = { "p1001": {"name": "无线耳机Pro", "colors": {"白": 50, "蓝": 0}}, "p1002": {"name": "便携充电宝", "colors": {"黑": 120}}, } def query_inventory(product_id: str, color: str = None): """模拟库存查询，实际项目里替换成真实接口调用""" info = INVENTORY.get(product_id) if not info: return {"error": "product_not_found"} if color: stock = info["colors"].get(color, 0) return {"product_id": product_id, "name": info["name"], "color": color, "stock": stock} return {"product_id": product_id, "name": info["name"], "colors": info["colors"]} def send_coupon(user_id: str, coupon_id: str): """模拟发券，注意生产环境要做幂等控制""" return {"ok": True, "user_id": user_id, "coupon_id": coupon_id}

接着定义工具schema，并且写一个处理单条弹幕的函数：

TOOLS = [ { "type": "function", "function": { "name": "query_inventory", "description": "查询商品库存、规格和颜色", "parameters": { "type": "object", "properties": { "product_id": {"type": "string"}, "color": {"type": "string", "description": "可选，颜色名称"} }, "required": ["product_id"] } } }, { "type": "function", "function": { "name": "send_coupon", "description": "给用户发放优惠券", "parameters": { "type": "object", "properties": { "user_id": {"type": "string"}, "coupon_id": {"type": "string"} }, "required": ["user_id", "coupon_id"] } } } ] async def handle_danmaku(user_id: str, text: str, product_ctx: dict): messages = [ {"role": "system", "content": ( "你是直播间智能导购助手。回答要简短口语化，不超过40个字。" "涉及价格、库存等事实信息，必须先调用工具获得结果，禁止编造。" f"当前主播正在讲解的商品：{json.dumps(product_ctx, ensure_ascii=False)}" )}, {"role": "user", "content": f"用户{user_id}：{text}"} ] # 第一轮：让模型决定是否调工具 resp = await client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=TOOLS, tool_choice="auto", ) msg = resp.choices[0].message messages.append(msg) # 把模型回复（可能带tool_calls）加入上下文 if msg.tool_calls: for tc in msg.tool_calls: args = json.loads(tc.function.arguments) if tc.function.name == "query_inventory": result = query_inventory(args["product_id"], args.get("color")) elif tc.function.name == "send_coupon": result = send_coupon(args["user_id"], args["coupon_id"]) else: result = {"error": "unknown_tool"} messages.append({ "role": "tool", "tool_call_id": tc.id, "content": json.dumps(result, ensure_ascii=False) }) # 第二轮：把工具结果交给模型生成最终回复 final_resp = await client.chat.completions.create( model="gpt-4o-mini", messages=messages, tools=TOOLS, tool_choice="none", ) return final_resp.choices[0].message.content return msg.content or "没听清你说什么，能再问一次吗？"

运行逻辑很清楚：第一轮模型可能返回工具调用请求，程序执行工具、把结果塞回上下文，再调用第二轮生成最终回复。整个过程用一个消息数组贯穿，保证了多轮工具调用的连贯性。实际测试里，弹幕"这个有蓝色吗"，Agent会自己调库存接口，发现蓝色缺货后回复"蓝色暂时没了，白色现货50件，今天下单送收纳包"。

4.3 对接直播SDK的注意事项

真实项目里，弹幕源是直播平台或自研直播服务的消息通道。无论哪种，接入时都要注意三件事。

第一，消息去重。弹幕消息在弱网下会被客户端重发，服务端要按消息ID去重，否则Agent会对同一条弹幕回复多次，观众会觉得这个机器人疯了。第二，用户聚合。几十条弹幕同一个用户问的可能是同一件事，按用户加主题做聚合，能省token，还能防止刷屏式回复。第三，回复频率限制。直播间对弹幕发送有频率限制，Agent的输出要经过节流，严格限制每秒钟最多发几条，避免被平台判定为机器刷屏导致整个直播间被限流。

5. 实测踩坑记录：延迟、幻觉、成本三座大山

理论方案再漂亮，上线一测全是问题。我们把影响最严重的几个坑列出来，每个都是真金白银换来的经验。

5.1 第一座山：延迟

第一个版本上线，端到端延迟平均6到8秒。弹幕都刷过去两屏了，Agent的回复才到，观众体验非常差。

回溯下来，瓶颈有三个：第一，所有弹幕都等大模型完整生成后再发送，没有用流式；第二，每个直播间一个Agent进程，消息在进程间多次转发；第三，每个回复都先过一遍参数量很大的模型，哪怕是"这件多少钱"这种简单问题。

修复方案分三条线：查询类问题走"意图识别加工具加模板"快速通道，不经过LLM生成；复杂对话换成延迟更低的模型档位，并开启流式输出；进程内做事件聚合，减少网络往返。优化后端到端稳定在2秒左右，产品体验才算是可接受。

5.2 第二座山：幻觉

一次真实事故：用户问"这个耳机支持LDAC吗"，Agent回复"支持哦"，实际产品压根没有LDAC。原因是训练数据里这类产品描述太多，模型自己脑补了。观众把截图发到群里，主播当场尴尬，我们团队恨不得找地缝钻进去。

总结出的铁律是：所有事实信息一律以工具查询结果为准，模型不得直接生成价格、库存、参数。具体做法：商品参数表在开场前就注入系统prompt，prompt里明确写"未在参数表中出现的信息一律回答以商品页为准"；涉及库存、价格必须走工具；查不到就明确说不知道，并引导用户联系客服。加了这三道闸之后，事实性错误基本绝迹。这条建议放在任何业务型Agent上都适用。

5.3 第三座山：成本

一场三个小时的直播，弹幕量轻松上万条。如果条条都过LLM，费用一天下来非常可观。我们做过统计，高峰时段单场token消耗可以到几百万。

成本控制靠分流：第一层过滤，把"哈哈""666""来了来了"这类无意义弹幕直接丢弃，根本不进Agent；第二层聚合并去重，同一主题重复问题合并回答一次；第三层模型分级，意图识别和简单回答用便宜的小模型，只有复杂对话才升级到大模型。这样综合成本能降到原来的三成左右，用户感知几乎没有下降。做这个的同学一定要有成本意识，否则Agent越火，老板越肉疼。

5.4 并发与扩容：几百个直播间同时开播

服务几十个直播间和几百个直播间，是完全不同的工程问题。一开始每个直播间起一个Agent实例，管理成本巨大不说，模型接口的限流额度也被瞬间打满，高峰期大量请求超时。

后来改成无状态架构：Agent实例只保留最少的状态，直播间的上下文、当前商品、用户画像全放Redis；实例可以随时水平扩缩容，消息队列按直播间ID做分区，保证同一个直播间的事件有序到达同一个实例。模型侧限流用令牌桶做全局控制，等不到的就先排队，超时直接降级用模板回复。这套方案让单个实例可以同时服务多个直播间，整体成本降低一半，也扛住了大促时的流量峰值。

6. 从单Agent到Agent团队：下一步该怎么走

6.1 多Agent协作的分工与通信

单Agent做好之后，自然延伸方向就是多Agent。直播业务的节奏不是一个人能盯过来的：编导要规划整场脚本，主播要持续输出话术，场控要盯着评论区，运营要看实时数据。每个角色都有不同的输入源和行动目标，全塞进一个Agent会让prompt变得臃肿、行为变得混乱。

多Agent设计上建议按角色拆分，每个Agent只负责一个明确的职责域：

Agent之间的通信不建议走点对点调用，统一走消息总线。编导Agent产出的节奏计划发布到topic，主播Agent订阅后动态调整话术风格；场控Agent发现负面情绪扩散时，给编导Agent发一条事件，编导决定是否切入互动环节。这种松耦合的好处是任何一个Agent挂了都有降级方案，其他角色照常跑。

主控Agent或者说编排层的存在是必要的。多Agent并行处理同一个弹幕时，必须有一个仲裁者决定谁来回答，否则会出现两个Agent同时抢答、话术互相矛盾的情况。最简单的编排策略是"职责优先级加类型路由"：违规类走场控Agent，商品类走主播Agent，用户专属问题走导购Agent，都不明确归属的才落到兜底回复。

6.2 一个务实的忠告：稳定压倒一切

最后说点个人的真实体会。做直播Agent这一年，最大的领悟是：直播场景容错率极低。一次尴尬的回复错误可能被录屏传播，连带品牌形象受损，代价远超过技术本身。所以我们在上线前制定了几条硬性规则，也建议每个团队参考。

第一，越权操作必须有人工兜底。Agent可以推荐加购、发券，但涉及退款、改价等敏感动作，一律转人工审批，宁可慢一点也不要出错。第二，灰度上线。先让Agent在测试直播间跑两周，积累足够多的bad case再切正式。第三，随时能一键接管。直播间必须留一个开关，运营发现Agent状态不对可以立刻把全部回复切换到人工模式，这个开关要极其显眼、极其顺手。第四，持续收集bad case做回归测试。我们维护了一个几千条的评测集，每次换模型、改prompt都要跑一遍，确保修复A问题没有引入B问题。

说实话，直播Agent这块还没有标准答案，各家都在快速迭代。但有一点是确定的：观众对机器人的容忍度非常低。宁可让Agent少说话，也不要让它乱说话；宁可多走一次工具查询，也不要让它编一个答案。把稳定性和可控性当成第一优先级，这个产品才能真正在直播间里站住脚。