北京
一场购物对话的成本，可以压到不到1美分。这是团队在测试中给出的数字：用 Claude Haiku 5.5 在低算力档位运行，平均一次对话花费低于 0.006 美元。他们要做的，是一个跑在商家自己服务器上的购物代理。
这个代理藏在店铺聊天窗口里，用商家自己的商品数据干活：搜索目录、对比商品、把商品加进购物车、按店铺自己的配送方式报运费、查订单状态。商家则在 Sylius 后台配置它、教它、看它带来的销售。
它和市面上常见方案的区别在于形态。团队调研发现，知名度最高的电商代理如 Fin 和 Gorgias 只服务 Shopify；Sylius 生态里能找到的多是托管式聊天机器人，靠一个连接器插件把商品目录同步到厂商服务器，对话也在那边发生。
这种模式能用，但代价是：目录副本存在别处，代理只能通过同步了解购物车和运费规则，用哪个模型、每次对话花多少钱，都由厂商说了算。团队的说法很直接——如果选 Sylius 就是为了掌控店铺和基础设施，这等于把初衷丢了。
他们的做法是做成 Sylius 原生插件。目录从商家数据库实时读取，不存在需要同步的副本；API 密钥是商家自己的，模型也由商家选，Claude、OpenAI 等都可以，甚至能按任务分配不同模型，比如用更便宜的模型跑后台工作。离开店铺的，只有对话本身。
购物者这端能做什么
- 搜索与对比：找到商品、并排比较，还能拼出多件组合方案，比如“阳台种菜入门全套”。
- 帮选：在开启导购式销售后，针对有购买指南的品类先问两三个相关问题，再根据选择推荐搭配商品。
- 操作真实购物车：在 Sylius 购物车里增加、修改、删除商品。
- 按结账逻辑报运费：调用店铺自己的配送方式计算费率。
- 回答政策问题、追踪订单：从店铺自己的文档里取退换货、配送、支付信息，并查询已登录客户的订单。
- 记住偏好：把购物者这次说过的喜好带到下一次访问。
- 以卡片流式呈现：商品轮播、对比、组合方案、订单状态、购物车摘要边生成边显示。
代理负责把订单搭好，付款仍然发生在店铺自己的结账页。
商家后台能管什么
在 Sylius 管理后台，商家可以读每一次对话的完整记录；查看代理协助过的购物车与订单、协助产生的收入以及 AI 成本；按渠道开关助手、选模型、配置该渠道自己的 API 密钥（加密存储）并设置花费上限。
语气和销售风格也能调：选一套现成的销售风格再按店铺需要调整，或者自定义。店铺专属规则同样写在后台，比如“有人买礼物时，主动提供礼品包装”；政策文档和购买指南也在后台管理，带草稿、版本历史和版本对比。
底层是一套开源核心。团队参照 Anthropic 关于构建购物与商家代理的指南（含一份 Python 参考实现），把它移植到 PHP 和 Symfony，保留原有架构，并把与电商无关的部分抽成一个 MIT 许可的开源 Symfony 包：代理循环、技能、工具校验、围栏、记忆、预算、评测和浏览器流式输出都在里面。购物代理只是建在这套核心上的一个垂直应用。
准确性靠代码而不是提示词来兜底。指南里把这叫“在框架层强制执行”，这些护栏放在开源核心里，任何人都能查看其工作方式：
- 来源约束：代理只能展示或添加本次对话中由工具返回过 ID 的商品，作用类似数据库外键约束。
- 展示工具：卡片通过工具渲染，模型只负责指认商品，价格、库存、图片和链接由服务器从目录填入。
- 有据可查：涉及目录、店铺政策或订单的问题，先查询再回答。
- 围栏：商品描述、店铺文档和工具结果都以明确分隔的数据形式传给模型，藏在这些内容里的提示注入不会被当成指令执行。
每条流程都配有评测用例，让代理对着一个店铺跑，检查它调用了哪些工具、最后把购物车留成什么状态。
目前大部分功能已经可用，在 Sylius 2.0 到 2.3 上做过测试。团队正在找第一批愿意实际跑起来的店铺。暂时没有公开演示，插件会在打磨完成后开始分发。后续计划包括用并行工具调用加快响应、用更好的提示缓存降低每轮成本，以及在真实店铺中运行的进展更新。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
