最近，OpenClaw在国内讨论度很高。“养龙虾”成了高频词，不少厂商也开始围绕可执行 Agent 持续推出新产品。
围绕企业自建 Agent 难以进入对客服务这一现实问题，合力亿捷智能客服 Agent 现已支持调用企业专属的OpenClaw。
对很多企业来说，关注OpenClaw，不是为了跟热点，而是因为一个更实际的问题已经摆在眼前：内部已经养出了一个能查数据、调接口、跑流程的专属 Agent，接下来怎么把它接进客服体系，去处理外部客户的问题。
不少企业现在的情况都差不多。内部已经有一个Agent，在飞书、企微等环境里用得不错；但一旦想让它直接面对客户，顾虑马上就来了。
原因并不复杂。内部使用时，Agent偶尔理解偏一点、动作慢一点，通常还有调整空间；但客服场景面对的是外部客户，要求完全不一样。哪些问题能处理，哪些不能处理；哪些场景可以自动执行，哪些必须有人兜底；处理完之后能不能转人工、生成工单、进入后续流程，这些都需要先想清楚。
企业当然可以自建 Agent，但多数企业在把自建Agent 面向外部客户时，都会优先考虑边界控制、人工兜底和后续流程衔接。
主控协同式调用：给自建 Agent 一条可控的接入路径
围绕这类需求，合力亿捷MPaaS可以形成一套主控+协同式的 Agent 调用关系。放到实际业务里，可以理解为：客户消息进入客服体系后，处理路径不再只有一种。
对于标准咨询、高频问答，以及常规的查订单、改预约等标准化业务，继续由合力亿捷自身的智能客服Agent能力处理。对于企业已经通过OpenClaw跑通、并且希望继续保留的特定能力，则可以由MPaaS按需调用企业自己的OpenClaw，让这部分已有能力参与对客服务。
这样一来，企业专属的OpenClaw不再局限于内部环境使用，而是可以在明确边界内参与一部分真实客户诉求的处理。
拒绝“裸接”：从接口联通到业务闭环的 4 个动作
让内部 Agent 进入客服场景，中间差的并不只是一个接口，而是几步必要的业务动作。
第一步，是统一承接。客户问题不管来自在线客服、电话还是其他联络入口，都先进入统一的服务体系。前台联络产品负责承接咨询，MPaaS负责后续流程判断与任务编排。
第二步，是判断与分配。不是所有问题都交给OpenClaw。系统会先做意图识别和流程判断，明确哪些由合力亿捷直接处理，哪些才适合调用企业的自建 Agent。
第三步，是补充上下文并限定处理范围。客服场景下的调用，不是把客户原话直接丢给大模型。MPaaS在转发给OpenClaw之前，会补充必要的业务上下文，并通过流程配置限定它本次处理的范围。
第四步，是衔接后续流程。客服不是“答一句话”就结束。依托合力亿捷现有的工单系统、知识库和 AI 工作台，OpenClaw的调用结果还能继续进入后续处理链路，完成状态流转或转交人工接续。
各司其职：主控体系下的明确分工
引入OpenClaw，不是为了替代现有的智能客服，而是为了把企业已经沉淀好的特定能力接进客服体系。
前台接待、意图识别、会话控制、知识问答、流程判断，以及人工坐席、工单系统、后续服务的衔接，仍然由合力亿捷智能客服体系承接，负责高频标准咨询和已有规则的服务流程。
企业自建OpenClaw负责的是：企业已经在内部通过OpenClaw跑通、并且希望继续保留的那部分特定能力。比如某类复杂设备的故障排查逻辑、特定产品的组合规则处理，或者某段已经接入内部系统的专属流程。
至于人工坐席，重点仍然放在高敏情绪和复杂纠纷上。对于投诉升级、责任不清的售后纠纷，企业更看重的是人工的共情能力，以及完整的服务留痕和后续处理衔接。
把自建Agent真正接进客户服务
这次能力更新带来的变化很直接：企业已经在内部使用的OpenClaw，不再局限于内部试用场景，而是可以在明确边界内进入客服体系，参与一部分真实客户问题的处理。
当客户诉求进来之后，先由客服体系承接，再由系统做判断和调度。标准化问题由原生系统处理，企业已经沉淀在OpenClaw中的特定能力按需调用，处理完成后再继续衔接人工与业务流程。
对企业来说，这不是多接了一个热门平台，而是让已经沉淀好的自建 Agent 能力，开始以更可控的方式进入客户服务场景。
