机器人只会聊天不够用，真正的价值是做业务系统的前端入口——客户在企微里说"查下我的订单"，机器人调 ERP 查完回结果，客户不用打开别的系统。这篇讲机器人怎么连业务系统，做信息查询和操作执行的中间层。

一、机器人作为业务入口的定位

先明确定位：机器人不是业务系统的替代品，是轻量入口。适合做这些事：

• 查询类：订单状态、库存、物流、账户余额

• 提醒类：待办提醒、到期提醒、异常告警

• 触发类：发起审批、创建工单、提交申请

不适合做这些事：

• 复杂数据录入（表单类操作在 H5 页面做更好）

• 大量数据浏览（列表展示在企微里体验差）

• 高风险操作（退款、删除，必须人工确认）

定位想清楚，后面设计接口路由时就知道哪些该接、哪些该挡回去。

二、指令到接口的映射

机器人收到客户消息后，要翻译成对业务系统的调用。映射关系：

客户消息 → 意图识别 → 参数提取 → 调业务接口 → 格式化回复
"查下订单20260916-001" → 查订单意图 → order_id=20260916-001 → ERP.queryOrder() → 格式化状态

每个业务指令的映射逻辑独立封装：

BUSINESS_COMMANDS = {
    "query_order": {
        "intent_triggers": ["查订单", "物流", "到哪了"],
        "extract": {"order_id": r"\d{8}-\d{3}"},
        "api": "erp.query_order",
        "reply_template": "tpl_order_status",
    },
    "check_inventory": {
        "intent_triggers": ["库存", "有没有货"],
        "extract": {"sku": r"[A-Z]\d+"},
        "api": "erp.check_stock",
        "reply_template": "tpl_inventory",
    },
}

关键在参数提取。客户不会规规矩矩给你"订单号:20260916-001"这种格式，说的是"那个9月16号的订单"。参数提取要做两步：正则提取有格式的（订单号、SKU），提取不到的走多轮对话补全。

三、业务接口的适配层

业务系统的 API 和企微 API 是两套东西，中间需要适配层。适配层做几件事：

协议转换。业务系统可能是 REST、GraphQL、gRPC，统一适配成内部调用协议。机器人侧不关心业务系统用什么技术。

鉴权传递。企微侧的 appid 对应业务系统的哪个账号，适配层维护映射关系。机器人调业务接口时，适配层把企微侧的用户 ID 翻译成业务系统的用户 ID，带上对应权限。

数据格式转换。业务系统返回的数据结构大概率不能直接发给客户。适配层做格式化：ERP 返回的订单 JSON，转成客户能看懂的"您的订单已发货，物流单号 SF1234567"。

def adapt_order_response(erp_data):
    """把ERP返回转成客户能懂的消息"""
    status_map = {"shipped": "已发货", "delivered": "已签收", "pending": "待发货"}
    status = status_map.get(erp_data["status"], "处理中")
    msg = f"订单 {erp_data['order_id']}\n状态：{status}"
    if erp_data.get("tracking_no"):
        msg += f"\n物流单号：{erp_data['tracking_no']}"
    return msg

四、异步查询的体验处理

业务接口查询可能慢，特别是 ERP 这类系统。客户发消息后等 5 秒没响应会觉得坏了。处理策略：

即时确认。收到消息后 1 秒内回"正在查询订单 20260916-001 的状态，请稍候"。确认消息要带具体参数，让客户知道机器人理解对了。

超时降级。业务接口 10 秒没返回，先回一条"查询超时，已为您转人工，客服会帮您查询"。别让客户干等。

结果补发。业务接口返回后，不管多久，把结果格式化后发出去。确认消息和结果消息之间有时间差，客户能看到进度。

五、多业务系统的编排

一个机器人可能连多个业务系统：ERP 查订单、CRM 查客户、OA 发审批。编排时要考虑：

数据依赖。查订单需要先知道客户是谁（CRM 查客户 ID）→ 用客户 ID 查订单（ERP 查订单列表）→ 用订单号查物流（物流 API）。串行调用，每步结果喂给下一步。

def query_customer_orders(user_msg, session):
    # 1. 从企微侧拿到客户标识
    customer_id = map_to_crm_id(session.user_id)
    # 2. 查CRM拿客户关联的订单号
    orders = crm_api.get_orders(customer_id)
    if not orders:
        return "暂未找到您的订单记录"
    # 3. 查ERP拿订单详情
    latest = erp_api.get_order(orders[0])
    # 4. 查物流
    if latest["tracking_no"]:
        logistics = logistics_api.track(latest["tracking_no"])
        return format_logistics(latest, logistics)
    return format_order(latest)

错误隔离。一个业务系统挂了不影响其他。ERP 挂了查不了订单，但还能查 CRM 里的客户信息。每个业务调用有独立超时和降级。

六、权限和安全

机器人连业务系统，权限要管好：

• 用户级权限。客户 A 通过机器人只能查 A 自己的订单，不能查 B 的。适配层做用户隔离

• 操作审计。每次机器人调业务系统，记录：哪个客户、通过哪个指令、查了什么数据、结果是什么

• 敏感操作拦截。退款、改地址这类操作，机器人不做执行，只生成工单转人工

七、从查询到操作

机器人的成熟路径是"先查询后操作"。查询类功能做稳了，客户信任机器人能给出正确信息后，再开放操作类功能。

操作类功能必须加二次确认：

客户：帮我取消订单 20260916-001
机器人：确认取消订单 20260916-001（¥12,800）吗？回复"确认"执行，"取消"放弃
客户：确认
机器人：订单已取消，退款将在3-5个工作日原路退回

二次确认的规则：金额超过阈值必须确认、删除类操作必须确认、不可逆操作必须确认。接口能力对照开发文档，先在Eyun平台开测试期验证查询类功能。

写在最后

机器人连业务系统的价值在于"让客户不用切系统"。查询类功能做扎实、适配层设计好、异步体验处理到位、权限管住——这四样做到位，机器人就从"聊天工具"升级成"业务助手"，价值完全不同。