Leptex 人工智能网关
连接经商家授权的人工智能助手与商家工作区，明确资料访问、操作权限和接入验证的边界。
Leptex 人工智能网关（Leptex AI Gateway）是商家工作区的 AI 接入能力。这里的“网关”，是外部助手接入商家业务系统的受控通道。它让经营者选择并授权的外部助手，在限定范围内读取顾客对话、查看订单，以及协助执行获准的业务操作。这里的工程问题，是怎样把助手的语言理解能力接到真实业务上，同时让资料范围、操作权限与处理结果保持清楚。
本文面向需要理解或接入这项能力的开发者、集成人员与经营者。当前实现通过模型上下文协议（Model Context Protocol，MCP）提供连接；具体客户端兼容性与开放安排仍需分别确认。文章说明现有工程能力和使用边界，不将接口实现等同于所有助手均已兼容。
从一项待办开始
Lucky Farm 是 Leptex 首个完成入驻的商家。它的山楂业务让这项接入面对具体的问题：顾客询问取货或配送，商家需要把咨询与订单分开处理，并知道哪些事项仍待自己确认。下文用这类农场待办解释工程要求，不表示 Lucky Farm 已启用外部代理或自动订单操作。
农场也是初期工程验证的重点。经营者可能同时采收、销售和安排取货，不应为了接待外部助手而承担另一套复杂系统的维护工作。前线部署工程师需要与农场明确哪些问题可由已有资料回答、哪些请求需要本人处理，再用使用反馈检验整合是否降低了总负担。具体的接入状态与效果，需要逐项确认。
例如，经营者希望先整理“哪些顾客在等回复，哪些订单需要核对”。助手需要根据获准访问的原始记录回答；顾客在聊天里询问能否改期，不应被整理成农场已经承诺改期。
先在农场业务中把这项区别处理清楚，才有依据向其他场景推广。不同经营者的交付条件可能不同，连接的起点相同：先核对待办与原始记录，再判断需要谁作出决定。
把助手接到业务系统
这项连接包含三个角色：
- AI 助手理解经营者的要求，读取获准的业务信息，并提出或执行相应操作。
- 商家工作区维护顾客对话与订单记录，承接既有的业务权限和状态规则。
- 人工智能网关为外部助手提供受控的访问通道，让调用落在商家授权的范围内。
Model Context Protocol 的架构说明定义了 AI 应用与外部服务交换上下文、调用工具的公共协议。MCP 提供连接方式；商家的价格、供货条件、订单状态与操作权限，仍然需要由业务系统管理。接入一个协议，不会自动完成业务集成。
Leptex CaaP（Chat as a Page，对话式页面）是商家面向顾客的产品入口。人工智能网关则是工作区面向授权助手的接入能力，两者服务于同一门生意的不同环节。本文中的网关指业务系统接入，不是通用的模型 API 路由服务。
先界定读取与操作
连接应从完成任务所需的最小范围开始。当前实现默认采用只读权限；其他能力需要分别授权。
左右滑动查看完整对比表 →| 业务需要 | 访问范围与影响 |
|---|---|
| 了解待办 | 默认可读取对话及相关订单记录，查看等待处理的事项 |
| 查询业务资料 | 读取项目知识资料需要额外授权 |
| 协助处理对话 | 回复顾客、接手或交回对话，需要对话操作权限 |
| 处理订单卡 | 确认或拒绝待处理订单卡，需要订单操作权限，并遵守既有业务状态限制 |
读取信息和改变业务状态，承担的责任不同。助手发出的回复以商家身份出现在对话中；订单操作会改变工作区里的业务记录。开启权限前，应先明确要把哪一项工作交给助手。
授予操作权限，不等于每次操作都会再次请求批准。当前连接没有为每次回复或订单操作增加独立的审批步骤，提示词中的“先问我”也不能代替这类控制。希望逐项亲自确认的经营者，可以保持只读连接，由自己在工作区完成回复和订单处理。
接入从只读验证开始
对于已开放连接设置的账户，建议按以下顺序验证：
- 在工作区查看连接设置，选择最小的只读范围并创建连接凭证。
- 按所选助手的接入方式配置连接，将凭证保存在其支持的凭证管理位置，不写入公开文档、截图或共享提示词。
- 先查询待处理事项，与工作区的原始记录核对，确认访问的是正确的业务资料，摘要没有补出不存在的承诺。
- 在受控测试场景中验证确有需要的额外权限，检查操作结果与工作区是否一致；业务状态不允许时，应明确显示失败，不能把尝试执行写成已经完成。
能连上接口，只是验证的开始。连接是否适合实际经营，还取决于资料是否完整、权限是否合适、失败是否清楚，以及经营者能否理解结果。
让安全边界可以检查
当前实现提供授权范围、凭证有效期、撤销入口和请求用量控制。业务操作仍受既有权限与状态规则约束。这些控制限定了连接可以做什么，但不意味着助手不会误解内容，也不构成对所有攻击的防御保证。
顾客在对话中写下的内容，是需要理解的业务资料，不应被当作授予助手额外权限的指令。接口应执行相应的访问与业务约束；集成也需要验证助手面对这类内容时的行为。MCP 的安全实践可以作为公开参考，不能代替具体系统的验证。
只读连接同样涉及数据共享。经营者需要知道外部助手会收到哪些对话或顾客资料，以及该服务如何使用这些信息。撤销连接会阻止该凭证后续访问，但不会自动删除外部服务已经收到的数据。
工程上的目标，是让普通经营者能够回答三个问题：助手能看到什么、能改变什么、怎样停止它继续访问。这也把《超越个人代理，走向个人智能》中关于知识边界与人的决定权的论点，转化为这项接入可以检查的要求。
区分接口实现、客户端兼容与开放范围
当前代码已经实现连接接口，商家工作区提供面向 Meta Muse 的设置与说明。具体客户端、账户与实际业务操作的兼容性，仍需逐项验证；这不表示获得 Meta 官方合作或认证。
支持 MCP，也不等于任意助手都能直接使用。接入时仍需核对客户端的连接方式、授权支持、工具行为和错误处理。定时检查与通知还取决于外部助手的能力，当前连接本身不承诺持续监控或即时提醒。
这个接口面向商家授权的助手。代表顾客来询价的代理，不会因为能访问公开店铺页面，就获得商家的内部资料或订单操作权限。更广泛的顾客代理接待、请求分流与其他助手接入，是需要另外设计和验证的方向。
用业务结果验收连接
接入验证至少需要覆盖以下几类结果：
- 读取：助手找到正确的对话与订单，摘要可以回到原始记录核对。
- 授权：未获准的资料和操作不可用，过期或撤销后的凭证不能继续访问。
- 操作：允许的业务变更正确落入工作区，不允许的状态转换被拒绝。
- 失败：助手区分成功、失败与结果尚未确定，不把未知状态报告为完成；结果不明时，应先核对记录再决定是否重试。
- 使用：经营者能够理解权限、检查结果，并结束不再需要的连接。
这些是接入应满足的验收要求，不是本文已经完成所有客户端实测的声明。判断价值时，还需要观察处理时间、纠错负担和遗漏情况。请求量增加或通知减少，本身都不能证明经营改善。
把协作建立在可核对的业务之上
AI 助手参与经营，需要可靠的业务信息，也需要明确的行动范围。Leptex 人工智能网关从工作区接入开始，把对话、订单与获准的操作提供给经营者选择的助手。工程上的进步，应当表现为任务更容易完成，信息更容易核对，出了问题也能清楚地知道下一步由谁处理。
CaaP 帮助顾客理解一门生意，工作区承接经营工作，人工智能网关让授权助手参与其中。先把一项任务的读取、授权、执行和失败处理验证清楚，再逐步扩大协作范围，是我们选择的接入路径。