# 我的客服 AI 服务多个客户，不能把甲公司的情况带给乙公司。 | EasyNet

Source: https://easynet.run/cases/problems/separate-client-agent-work

[easynet.run · 全部问题场景](https://easynet.run/cases#problem-scenarios)

# 我的客服 AI 服务多个客户，不能把甲公司的情况带给乙公司。

同一套客服助手给几家公司使用，回答流程可以相同，订单和售后政策却不同。最容易发现的是查错账号；更难发现的是它沿用上一次会话里的折扣、从缓存拿出另一家公司的联系人，回答还显得很自然。

若已有客服平台能可靠隔离不同客户，就保留它的租户与权限机制。自己搭建流程时，也可以先用独立部署减少混用风险。共享一套程序的理由应该是减少重复维护，而不是为了省配置，把所有客户放到一个管理员账号下面。

通过 EasyNet 调用业务函数时，可以把经认证的调用身份作为检查入口。提供方再根据可信的账号关系确定当前客户，只允许查询该客户的数据。客户归属不能来自模型自由填写的 company_id，否则一次错误参数就可能跨过隔离范围。

以查订单为例，函数接收订单号，在服务端确认这份订单属于当前获准客户，只返回客服需要的字段。各客户的资料检索也按同一可信范围执行。EasyRemote 接出的是这些已有业务方法，不会自动替底层数据库、向量索引和外部服务配置隔离。

对话历史、提示缓存和生成结果同样要带上客户范围，并在复用前检查。工程团队需要逐个梳理哪些存储会跨请求保留内容；只测试查询接口拒绝越权，不能证明模型上下文里没有上一家公司的资料。

准备两组可以明确区分的测试客户资料，让助手交替处理相似问题，再尝试引用另一方的订单。既核对读取记录，也检查回答和缓存。真正可复用的应该是服务方法，不是客户数据；这条界线落实到每一次读取与输出，团队才敢让同一套流程服务更多人。

01

确认调用者

从认证映射到客户，不信任模型自报。

02

检查订单归属

只读该客户有权访问的字段。

03

隔离回复与缓存

换客户后不能带出上一次的信息。

共享处理方法，按真实身份隔离订单和缓存。

订单归属检查的最小单元

本地业务检查示例，trusted_tenant必须由认证层提供，不能取自模型参数。
本地示例 · python

```
def order_summary(trusted_tenant, order):
    if order['tenant'] != trusted_tenant:
        raise PermissionError('Order outside caller scope')
    return {'id': order['id'], 'status': order['status']}

print(order_summary('client-a', {
    'id': 'demo-17', 'tenant': 'client-a', 'status': 'shipped'
}))
```

预期结果：返回demo-17的状态；将可信客户改为client-b会拒绝。

接入时的检查项

修改客户参数不能读取另一租户资源。

复用进程后回答和缓存不出现测试标记串用。

审查记录可按真实客户和请求者分别查询。

源码与接入资料

[函数接入指南](https://easynet.run/docs/connect/function)

[让 Agent 调用业务操作，而不是拿到后台凭证](https://easynet.run/cases/enterprise-tool-boundary)

[MCP 官方：授权规范（2025-11-25）](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization)