这里说的"机器人"不是企微群里那个只能单向推送的 Webhook 机器人，而是一个由 API 驱动的企微账号——能收消息、能理解指令、能回复执行结果，行为像一个 7×24 在线的自动化助理。这篇讲机器人交互模式的设计。

一、两种交互模式的选择

机器人交互分两种模式，适用场景不同：

命令式交互。客户发固定格式的指令，机器人解析后执行。比如"查订单 20260916-001""帮我转人工"。适合功能明确、操作固定的场景，体验像命令行。

自然语言交互。客户随便说，机器人理解意图后执行。比如"我那个订单到哪了""不想聊了给我转人"。适合功能多、客户群体杂的场景，体验像和真人聊。

两种模式不是非此即彼。推荐命令式做骨架、自然语言做壳——底层是固定指令路由，但入口支持自然语言解析。客户说"查下我的订单"，机器人解析出"查订单"意图后，引导客户补充订单号。

二、指令路由的设计

命令式交互的核心是指令路由。每条指令有：触发词、参数解析、执行逻辑、回复模板。

COMMANDS = {
    "查订单": {
        "triggers": ["订单", "物流", "到哪了", "发货"],
        "params": ["order_id"],
        "handler": query_order,
        "reply_template": "tpl_order_status",
    },
    "转人工": {
        "triggers": ["人工", "客服", "真人"],
        "params": [],
        "handler": transfer_human,
        "reply_template": "tpl_transfer",
    },
    "查价格": {
        "triggers": ["价格", "多少钱", "报价"],
        "params": ["product_name"],
        "handler": query_price,
        "reply_template": "tpl_price",
    },
}

自然语言入口怎么路由到指令？两种做法：

• 关键词 + 意图分类：先匹配触发词，匹配不到再用小模型做意图分类。成本低、覆盖率一般

• 大模型做意图识别：直接把客户消息喂给模型，让模型输出意图标签。成本高、覆盖好

推荐前者起步，高频指令靠关键词能覆盖 80%，剩下 20% 的长尾再用模型兜底。

三、参数收集和补全

客户一句话往往信息不全。"查下订单"没带订单号，机器人要能引导补全。做法是多轮对话收集槽位：

def handle_query_order(msg, session):
    order_id = extract_order_id(msg)  # 尝试从消息提取
    if order_id:
        return query_and_reply(order_id)  # 参数齐了，执行
    else:
        session["pending_intent"] = "query_order"  # 标记待补全
        return "请提供您的订单号，形如 20260916-001"

下一轮消息进来时，先检查 pending_intent：如果有待补全的意图，先把这条消息当参数填进去，填满了就执行，没填满继续问。槽位补全是机器人交互里最常用的模式，比一次性收集所有参数体验好。

四、异步执行的回复策略

有些指令执行慢——查 ERP 订单状态、调外部 API、跑复杂逻辑。客户等不了几秒没响应。策略是先回确认、再补结果：

def handle_slow_command(msg, session):
    # 先回一句确认
    send_text(session.conversation_id, "正在为您查询，请稍候...")
    # 异步执行
    result = async_execute(msg, session)
    # 执行完补发结果
    send_text(session.conversation_id, format_result(result))

确认消息要具体，别只说"请稍候"。说"正在查询订单 20260916-001 的物流状态"——让客户知道机器人理解对了，不是敷衍。执行时间超过 10 秒的，中间补一条进度消息。

五、群聊和单聊的差异

机器人在群聊和单聊的行为要差异化：

单聊。每条消息都处理，回复可以直接发。适合一对一服务场景。

群聊。不能每条都回，只在被 @ 或命中明确关键词时才回。否则群里每条消息机器人都插嘴，严重干扰正常交流。

群聊里 @ 机器人的消息，报文里会有 isAtMe 之类标识。机器人收到 @ 后取消息内容（去掉 @ 自己的部分）再处理。回复时也要 @ 回对方，用富文本接口而非文本接口。

六、机器人的"人设"

机器人不是冷冰冰的指令执行器，最好有"人设"——名字、语气、性格。这不只是花架子，影响交互设计：

• 名字：让客户知道在和机器人聊，不是真人。"小助手""XX客服小帮手"都行

• 语气：统一风格，别一会儿"您好"一会儿"哈喽"

• 能力边界声明：主动告诉客户能做什么不能做什么。"我可以帮您查订单、查物流、转人工，其他问题为您转接客服"

有明确能力边界的机器人，比试图回答一切的机器人体验好。前者让客户知道怎么用，后者让客户不知道边界在哪。

七、机器人开发的几个红线

• 别做成无人值守的全自动。高风险动作（退款、改地址）一定要转人工确认，机器人只做信息查询和低风险操作

• 回复频率有上限。同一个会话短时间内回复不超过 3 条，避免刷屏

• 失败要兜底。指令解析失败、外部 API 超时、参数不全——每种失败都要有对应的兜底回复，不能沉默

• 日志留痕。每条指令的解析、执行、回复都记日志，出问题能追查

写在最后

机器人开发的核心在交互设计而非技术实现。指令路由清晰、参数补全流畅、回复策略贴心、人设边界明确——这四样到位，机器人就不再是个冷冰冰的接口转发器，而是一个客户愿意用的自动化助理。接口能力对照开发文档，先在Eyun平台开测试期验证链路。