给企业采购场景做 AI，有两条看起来都合理、走到底都会出问题的路。
第一条是纯大模型路线：把商品资料喂进去，让模型回答”帮我找灭菌型医用外科口罩，50 只装”，再让它生成一份采购建议。体验很流畅，但价格、库存、起订倍数、规格编码都可能是模型”觉得应该是”的结果——说话好听，数字不可信，也写不进系统。
第二条是纯接口路线：每个操作都做成严谨的表单与按钮，数据准确、事务可靠，但一页二十行的采购清单要来回二十趟，用户还得自己把流程拼起来。数据准确，理解成本全留给人。
结论：企业采购场景要的不是更聪明的模型，也不是更密的表单，而是把两者按职责切开——让 AI 做理解，让系统做交易。 商派B2B（DMS）业务系统里的 AI 智能采购助手，就是按这条分界线设计的。它不是新的商城，而是长在采购门户右下角的第二扇门。
一、先把”同一个系统”说清楚
智能采购助手最容易被误解成”另开一个 AI 商城”。产品材料用三个”同一”把这件事钉死：
- 同一套账号：登录平台即有，无需额外注册或二次授权；身份、企业与权限沿用平台原有体系。
- 同一套商品与价格：助手查到的商品、规格、库存与价格就是门户那一套，不存在第二个价格体系，也不存在”智能体专享价”。
- 同一个购物车与订单：助手加购的货在门户购物车里看得见，助手提交的单在订单中心查得到，两边是同一份数据。
因此官网操作与助手对话是同一条需求的两条路径：路径 A 是门户搜索 → 商品详情 → 加入购物车 → 结算下单；路径 B 是一句需求 → 商品卡片与比价 → 确认卡 → 下单。落点是同一个业务系统。
这一点决定了后面所有设计的取向：AI 的价值来自它依附于一条真实交易链路，而不是来自它自己生成了一条链路。
二、职责分工：理解与交易，各归各位
| 大模型负责 | 平台接口负责 |
|---|---|
| 听懂一句口语里的真实需求 | 查商品、规格与实时价格 |
| 信息不足时主动追问关键参数 | 核库存与可购条件 |
| 把系统返回整理成人能读的回答 | 加购、改数量、清空购物车 |
| 处理”差不多就行”这类模糊表达 | 提交订单、查订单与物流 |
一句话：理解交给模型，事实交给系统。 商品与交易事实来自业务接口，回答中的数字还需经过来源校验；金额由业务系统计算，交易操作由业务接口执行，每一笔都是数据库事务，不是语言生成。
在医疗物资采购的演示链路里，这个分工体现得很具体：用户说”找灭菌的医用外科口罩，要 50 只装”，助手命中商品编码后返回的 5 袋起订、5 袋整包，是系统给出的规格与倍数，不是模型背出来的；加购前先核验可购条件与当前有无阻断项，避免加到一半才发现受限；同名商品存在灭菌型与非灭菌型两个规格时，助手不替用户决定，而是弹选择卡把差异并排列出，由用户选。
“信息不足时主动追问，而不是猜一个给你”——这句话比任何模型能力描述都更能说明产品取向。
三、五道闸：模型没有权力，系统才有权
企业最常问的一句是：”这个 AI 到底能替我做什么、不能做什么？”答案不在提示词里，在权限架构里。
助手采用三层架构：前端挂件负责对话、流式事件消费与生成式界面渲染；智能体宿主（Python + FastAPI）集中管理会话与轮次、五道闸、预算、写授权、复核、审计与模型密钥；平台业务服务复用既有商品、交易与订单服务，以标准化工具协议对接宿主；模型网关按场景路由不同模型档位。业务能力留在服务里，判断权留在宿主里，模型只负责理解。
模型能做的只有一件事：请求宿主执行一个白名单工具。身份、预算、写权限、数字复核，全在宿主这一侧。五道闸门依次是：
- 身份作用域隔离：租户、企业、用户身份由系统注入，模型既看不到也带不走，工具参数里根本没有身份字段；企业 A 查不到企业 B 的数据，商品可见性沿用平台既有规则。
- 工具白名单管控：每个工具经过审核与放行；模型提到一个不存在的工具名，会被直接拒绝并记入事件。下单提交走宿主内部通道，这一动作根本不在模型可见的工具白名单里。
- 预算前置扣减：调用次数、时长、令牌消耗都有硬上限，用完即停；同一动作原地打转三次，直接判为无进展并收口。
- 写入授权确认：任何写操作先做一次独立判定，逐字比对用户原话；引用对不上，一律按”不允许写入”处理，不弹卡、不提交。
- 数字溯源与复核：交易数据以工具结果为准，用户原话与附件也纳入数字溯源，受限推导须经校验；候选回答先过本地校验与模型复核，失败时修订重试；复核异常可在本地校验通过后降级交付并记录标记。
每一道闸门都有独立单元测试覆盖，启动期多重断言失败即拒绝服务——安全优先于可用。每轮对话、每次工具调用、每次模型调用、每张确认卡全部落库，事后能完整回放”这单是怎么下的”。
这不是”给聊天机器人加个确认按钮”，而是一整套交易级机制。 权限不是靠提示词约束出来的，是靠系统边界切出来的。
四、确认卡：三条铁律，把最后一步交还给人
下单、支付这类写入操作，智能体不能自行完成。系统生成确认卡，逐字引用商品、数量、金额、收货地址等关键信息供用户核对，确认后才凭一次性令牌提交。三条铁律：
- 点确认后才会下单：未点确认，订单不会产生；助手加购后只会展示最新合计，不会自行提交。
- 金额一字不差：卡片上的商品、数量与结算金额按业务系统返回呈现，金额由系统计算；确认卡携带一次性令牌，120 秒有效，用过即废。
- 购物车变了，卡片作废：确认卡绑定作用域与购物车版本；点击确认时服务重新校验购物车版本，如已变化则拒绝提交并要求重新确认；同一张卡不能确认第二次，也不能拿到别的会话去用。
配套机制还包括令牌绑定身份与乐观并发控制、确认提交成功后可在订单中心查看状态并继续办理付款。
值得注意的是”购物车只有一份真相”：用户在门户里删了商品、改了数量，助手看到的是最新状态，不会拿着旧数据下单。这个细节把”同一套数据”从口号变成了可执行的一致性约束。
五、工程治理：把不确定性关在门外
支撑稳定运行的四件事，没有一件是靠”更聪明的模型”解决的：
- 循环与流式：回答逐字流式输出，事件带序号、断线可续传；多个工具调用依次过闸执行、按序回灌；出现确认卡或选择卡后中断剩余动作。输入框上沿实时显示当前在做什么（理解需求、查询商品、整理回答、复核数字），不做黑箱转圈。
- 契约先行：工具协议、事件协议、错误码全部机读契约化管理并版本化，双端类型同源生成、变更漂移自动检测；提示词资产做指纹校验，被改动一处即拒绝启动。
- 模型治理：对话、复核、写授权判定分别路由到合适的模型档位；供应商能力先探测再放行，关键要求用单测锁死，成本靠预算前置扣减控制。换一家兼容模型供应商只改配置，不动业务代码，也不改前端。
- 轻量嵌入：挂件与门户同域部署、共用登录态，不改造门户也能接入；工具可逐个从模拟实现切到真实接口，灰度验证，出问题随时退回；新增业务能力等于注册一个新工具。
三条数据底线也写得很明确：录音与扫描件由助手服务内的本地引擎识别处理，文本再经模型网关理解；模型网关按场景多路由，密钥加密存储、接口只回显末位；租户、企业、用户三层边界由系统注入。
六、体验：六个词，六个承诺
| 关键词 | 含义 |
|---|---|
| 长在平台里 | 同一套账号、价格、购物车与订单，不是另一个商城 |
| 能交易 | 从找货、比价、加购到下单确认，全流程闭环，医疗物资采购场景端到端实测已通过 |
| 数字准 | 价格、库存、金额全部溯源系统返回，交付前再复核一遍 |
| 权限严 | 五道闸层层收口，模型没有身份、预算与写权限，越界即拒绝 |
| 可沉淀 | 商品结果、商品对比、业务记录自动收进产物面板，可搜、可定位原对话、可续办 |
| 体验佳 | 语音、附件、选择卡、确认卡、阶段提示，都是为采购场景做的 |
具体体验上：语音输入由服务端本地引擎识别，文字再经模型整理去口水词、纠同音字、统一数量与商品术语，识别结果先回填输入框供核对修改；附件支持表格、文档、演示稿、PDF 与图片扫描件，单件不超过 10MB、单轮最多 5 件，无文本层的扫描件走本地 OCR；多会话之间独立上下文，运行中可排队下一条指令并拖拽调整顺序；产物面板按品名、厂家、销售商检索，每条标注来源回复与时间。
与通用 AI 助手、开源智能体平台、自建方案相比，差异集中在三处：真实业务执行（已接入平台，而非只给建议）、数字准确性（溯源加复核，而非靠生成）、写操作安全（授权加确认卡，而非无此概念）。产品材料对”需自研”的表述也留了分寸：指该方案本身不提供、需企业另行建设，并非能力优劣的绝对判断。
七、边界，比承诺更重要
- 已交付：采购全流程闭环、语音输入、附件解析、产物收纳面板、全链路审计留痕；知识库问答与上下文压缩、长期记忆已实现并随对话自动生效。
- 已验证场景：医疗物资采购，医用外科口罩从选型到下单端到端实测已通过。
- 可扩展方向：卖家侧上架助手，产品定位覆盖买家与卖家两侧交易场景。
- 当前形态：门户右下角挂件、与门户同域部署、共用登录态；单实例部署，多实例所需的运行态外置方案在规划中。
- 尚未统计：耗时对比数据将在试点后按真实样本统计补充，目前只描述操作路径差异，不写效率提升比例。
- 数据安全说明：语音与 OCR 在助手服务内完成；身份与租户严格分域。机制说明不等于任何合规认证结论。
把边界列清楚，是因为这类产品最容易被一句”AI 自动下单”带偏。它恰恰不自动下单——它把理解的成本承担下来，把交易的责任留在系统与人手里。
常见问题解答
问：AI 会不会绕过用户自己下单？
– 结论：不会。写操作须经独立判定、确认卡与一次性令牌，未点确认不生成订单。
– 依据：写入授权逐字比对用户原话，引用对不上按”不允许写入”处理；下单提交走宿主内部通道，不在模型可见的工具白名单里；确认卡 120 秒过期、绑定购物车版本、用过即废。
– 边界：机制防的是越权与数据漂移，不替代用户对商品、数量、金额与收货信息的人工核对。
问：AI 报的价格和规格准吗？
– 结论：商品与价格来自平台业务接口，规格选项来自平台商品库，回答中的数字还需经过来源校验与复核。
– 依据：核心分工是”让 AI 做理解，让系统做交易”；金额由业务系统计算；同名多规格时弹选择卡由用户决定；数字溯源与复核为第五道闸。
– 边界：展示的是查询时点的同步快照，价格与库存以重新核验为准，产物面板已明确提示这一点。
问：原来的门户操作会被替换吗？
– 结论：不会。助手是加法不是替换，两条路径落点是同一个业务系统。
– 依据：与门户共用同一套账号、商品与价格、购物车与订单；门户一切照旧，想用就用，不用也不打扰。
– 边界：助手当前以右下角挂件形态交付，是否已按客户品牌风格适配属于项目范围。
问：企业数据会不会串到其他租户？
– 结论：租户、企业、用户三层身份由系统注入，模型侧不带身份字段，商品可见性沿用平台既有规则。
– 依据：身份作用域隔离为第一道闸；语音与 OCR 由助手服务本地引擎处理；模型网关密钥加密存储、接口只回显末位。
– 边界：当前为单实例部署形态，多实例所需的运行态外置方案在规划中；大规模并发部署时应单独评估。
收尾：让下一次采购从一句话开始，前提不是这句话被听懂得多漂亮，而是这句话后面的每一个数字都有出处、每一次写入都有授权、每一步都能回放。商派B2B（DMS）业务系统里的 AI 智能采购助手，价值正来自它与真实交易链路的耦合：理解可以交给模型，交易必须留给系统。
