如果我希望在站内实现类似的功能，有没有现成的方案或部署思路？

现有方案可以直接分为三层来选用，并且尽量不让模型模拟点击屏幕。 第一层，站内对话入口本身，有现成的开源框架可以接入。 Vercel AI SDK、LangChain／LlamaIndex 的流式对话组件、CopilotKit 都能直接放进你的前端，让你有一个可以询问、可以下发指令的侧边栏或悬浮按钮。这类框架负责流式输出、工具调用和前端状态同步。CopilotKit 尤其适合“站内快捷指令”，它能把一些可执行 action 注册给模型，用户说“帮我找去年买的耳机订单”，模型调用的是你注册的 getOrders 函数，而不是让模型去点击 DOM。这是最关键的一点：对话层的底座应该采用工具调用（function calling），而不是浏览器自动化。 第二层，把站内可执行动作整理成一份动作清单。 你不需要改业务逻辑，只需要在现有 API 外面包一层“意图明确、参数简单”的工具集，例如 searchOrders、openOrderDetail、requestRefund、applyCoupon。每个工具都写清楚描述、参数和“不可逆”标记。这就相当于给视障用户准备一份语音可调用的快捷操作清单，比任何 DOM 识别方案都稳定。Playwright MCP、Chrome DevTools MCP 那套只适合在开发和测试阶段帮你探索，不要放到生产环境给终端用户跑，因为元素名一变，整条链路就崩。 第三层，无障碍接入方式，浏览器扩展只作为可选增强。 如果你真的要覆盖使用读屏软件的用户，主流做法是使用 aria-live 区域，并配合焦点管理，而不要只把文字打到聊天窗口里。具体来说，agent 每完成一步，都在页面上产生真实焦点变化和 aria-live 播报，让 NVDA、VoiceOver、TalkBack 能读到，而不是让用户再去看聊天框。确认机制和回退机制也要做到 UI 层：支付、删除这类操作必须读回金额和订单号并二次确认；用户说“停”就立刻可中断，并提供“回到上一步”的操作路径。 部署上的几个现实建议是：对话后端可以挂在你自己的服务上，用 SSE 或 WebSocket 流式返回，不要在前端直接放 key；对话历史和无障碍配置要能按用户保存，但不要保存敏感字段；如果你要做模型侧的人设和限制，系统提示里必须固定“不承诺、不代替用户确认支付、不确定就退回人工操作”。 还有一个容易忽略的点：这套东西本身必须通过无障碍验收。你可以拿 NVDA 或 VoiceOver 从头到尾走一遍“语音下单到支付”的全流程，能独立完成才算合格，否则这又是一个对视障用户不好用的功能。 如果你愿意告诉我你现在的站点是什么技术栈（React、Vue，还是小程序、原生），以及主要想覆盖桌面还是移动端，我可以直接给一套具体的组件和接口划分。