客服 Agent 查询 CRM：少给一份历史，少承担一份解释风险

客服知道用户买过什么不代表每一次对话都应该读取全部消费历史。用户问“如何修改邮箱”把历年订单和内部价值标签一起塞给模型既没有帮助还可能让回答泄露不应展示的分层信息。我会让前端先确定这次请求的目的再由服务端根据身份和租户挑选字段。模型只拿到回答所需的视图促销推荐另设开关不和售后帮助捆在一起。浏览器工具出现之后身份边界依然存在2026年10月21日Cloudflare与Commerce.com介绍了通过WebMCP向购物Agent暴露结构化工具的实践同时明确WebMCP仍是实验性浏览器提案。官方文章 页面能提供工具不意味着调用者自动拥有某个客户的权限。对自己的产品关键边界仍是服务端登录用户是谁属于哪个租户正在处理哪个工单。不要从模型参数里的customerId直接相信身份也不要因为数据库查到了结果就返回全部字段。图里的字段过滤发生在模型之前。隐藏字段不只是CSS不显示未授权字段不应进入响应体更不应进入模型上下文或浏览器日志。一个可以本地验证的投影视图下面用内存数据演示。租户和登录身份由调用方明确传入真实服务里应来自已经验证的会话。这不是完整的认证实现。const assert require(node:assert/strict); function supportView(actor, customer) { if (!actor || actor.tenantId ! customer.tenantId || actor.customerId ! customer.id) throw new Error(forbidden); return { plan: customer.plan, renewalDay: customer.renewalDay }; } const customer { id: c1, tenantId: t1, plan: basic, renewalDay: 12, internalValue: high, lifetimeSpend: 9999 }; const view supportView({ tenantId: t1, customerId: c1 }, customer); assert.deepEqual(Object.keys(view), [plan, renewalDay]); assert.equal(lifetimeSpend in view, false); assert.throws(() supportView({ tenantId: t2, customerId: c1 }, customer)); console.log(crm-view: 3 assertions passed);保存为crm-view.cjs运行node crm-view.cjs。它验证允许字段与跨租户拒绝不测试数据库权限、登录凭据或模型表现。员工代办、家庭账户等关系需要独立的授权规则不能把这段“本人查询”直接扩展成通用客服权限。推荐必须能解释为什么出现如果用户主动请求套餐建议可以使用当前套餐、明确表达的需求与可公开的套餐差异。内部“高价值”“容易流失”等标签不适合直接变成对用户的说法。建议卡应展示推荐原因、价格和替代方案而不是把预测写成事实。我也会把“获取帮助”和“接收营销”分成不同设置。关闭推荐后客服仍应正常工作退出营销不应导致用户失去支持。这些是产品设计选择需要结合实际业务与适用规则审查本文不替任何地区提供合规结论。比起让Agent显得什么都知道我更在意它知道的内容是否恰好够用。