Scandiweb 10 月 2 日推出 Ari：Magento 店铺维护智能体，单次任务 5 分钟内完成、收费 2 至 10 美元

改一次 Magento 页面要多久？Scandiweb 给出的对照表里，老办法要 6 步：开工单、等开发、澄清需求、再等一遍、验收、退回 QA，约 3 天，每任务 500 美元以上。新办法是 4 步：用文字或语音描述任务、智能体按需澄清、一组智能体执行、批准后上线，平均 5 分钟内，每任务 2 到 10 美元。

2026 年 10 月 2 日，拉脱维亚电商技术服务商 Scandiweb 正式推出名为 Ari 的 Magento 智能体，主打店铺的日常维护与更新。商家不需要写代码，也不需要打开 IDE。

数字层面，Scandiweb 给出的口径是：单次任务平均执行时间 5 分钟以内，按信用点计价折合 2 至 10 美元；训练数据来自 2009 年以来积累的 50 万个以上真实 Magento 任务；目前运行在 300 多个线上店铺。面向商家的 Team 方案月费 99 美元，含每月 2000 个任务信用点，席位不限，支持按需加购信用点；另有定制价格的 Enterprise 方案。

对一个常年靠外包开发排期的独立站来说，这组数字指向的是同一件事：高频小改动的单位成本，第一次从「一个工单」降到了「一次对话」。问题随之而来：降下来的是哪一部分？

一、5 分钟、2 到 10 美元，账要怎么算

先把这套计费结构拆清楚。Team 方案 99 美元/月，含 2000 个任务信用点，官方写明平均每个任务消耗「a few credits」。按 2 到 10 美元的区间倒推，单个任务大致是几十到上百信用点的量级——但要注意，官方没有公布具体的换算比例，这是按公开价格做的推算，不是定价明细。

真正有参考价值的是那张新旧对照表。老流程是 6 步、约 3 天、每任务 500 美元以上；新流程是 4 步、5 分钟以内、每任务 2 到 10 美元。按这两个端点算，单个任务的成本降幅在数十倍到上百倍之间，时间降幅则在百倍以上。官方首页放的一个示范任务（让分类页的商品图支持移动端横向滑动）显示耗时 3 分 42 秒。

这笔账对跨境独立站的价值点很具体：多市场运营意味着多语言、多币种、多税制的反复微调，这类改动单次技术含量不高，但频次极高，恰恰是最容易被排期系统吞掉的那部分。Scandiweb 引用 Adobe 的一项调研说，47.3% 的受访商家把运营效率与自动化列为对开发者的首要期待——这个数字解释了为什么这类工具的入口在产品侧而不是工程侧。

还有一层反常识的地方：门槛下降不等于需求下降。Scandiweb 在同一组材料里提到，2026 年第二季度 Magento 店铺数量环比下降 6.7%，并把这一趋势解读为平台正在向技术要求更高的大型商家集中。小卖家离场留下的维护需求，反而会变成中大型商家身上更重的负担。

二、50 万个任务喂出来的能力边界

Ari 的能力清单分五类。技术改进：Magento 版本升级、物流与 ERP/CRM 对接、故障排查、安全补丁与兼容性修复、性能与技术 SEO。日常维护：装插件、升插件、清理兼容代码、配置店铺功能、为开发者验收准备改动。前台改动：改 header 与布局、调整页面行为、更新首页区块与 banner、优化移动端 UI。内容与商品运营：促销条与销售 banner、CMS 区块、商品文案、大批量目录调整。以及自定义模块、第三方集成、无头 API、支付流程、整站主题重写。

训练数据的来源值得留意。官网表述为「500K+ real-life Magento tasks processed to train Ari」，而 Scandiweb 在领英发布时的说法是「trained on 500K+ support tickets we have handled over the years」——两个口径都指向 50 万这个量级，但一个是「任务」，一个是「工单」，二者的构成并不一定相同。官方强调其中大部分来自带有三方扩展与遗留代码的高度定制店铺。

执行机制是「一组智能体」而非单个模型：任务描述进来后，智能体先就模糊点提问，然后在店铺副本上动手，完成后自行验证，再交给人工审批。落地为代码的部分会以 pull request 的形式进入你已有的 Git 仓库，保留完整 diff 与历史。官方称可以先向智能体索要一份技术方案再开工。

对 Magento 版本的支持，公开页面并未列出具体的小版本矩阵，只表述为 Magento 与 Adobe Commerce；公司自 2009 年起围绕这两个平台提供服务，是 Adobe Commerce 金牌伙伴与 Hyvä 白金伙伴，累计完成 2100 个以上电商项目，官网称每年为客户带来 40 亿美元以上收入，拥有 894 项以上认证，团队 500 多名内部专家。

三、护栏装在哪：先 staging，后上线

这套系统最值得肯定的设计，是它默认不碰生产环境。

官方把流程写成四道闸：第一，每一步改动都先在 staging 沙箱副本上跑，绝不在生产站点上直接操作；第二，每一次上线都要人工点一次确认，智能体不会自行推送；第三，任何改动都可以一键回滚；第四，全程有审计日志，记录了改了什么、什么时候改的。此外，每一次改动都落成 Git 仓库里的一个 PR，可以接回 Bitbucket、QA 和既有的发布流程。

运行方式给了三条路：自己跑（自己描述任务、审每个 diff、自己发布）；带着开发商或代理商跑（运营提任务，智能体出 PR，原有合作方审核并保留生产环境控制权）；带着 Scandiweb 的工程师跑（他们提供 QA、验收和按需的 Magento 开发者来收尾）。这个设计避免了「绕过现有供应商」的组织摩擦，对新工具的落地往往比技术本身更关键。

安全侧的资质写得很实：PCI DSS 合规，ISO 27001、27017、9001 认证，并提供 7×24 小时人工支持，企业级线上店铺承诺 1 小时响应。对于跑着支付的站点，这三条是采购流程里绕不开的字段。

四、官方自己划出的三件做不到的事

Ari 的 FAQ 明确列了负面清单，这部分的参考价值高于能力清单。

第一，架构决策仍在你手上。智能体执行你指定的东西，不会替你判断「这个店铺该不该做无头」。大型全新自定义模块、整站重构属于需要人在回路的项目，不是任务队列。

第二，它不碰 Magento 之外的系统。ERP 内部逻辑、第三方平台的配置都在范围外。

第三，它在大型任务上只能做到部分。官方给出的经验值是：像 Magento 版本升级这类大工程，智能体通常完成约 70% 的工作量，剩下的由你的或他们的开发收尾。原本数百小时的项目被压缩到天，但没有被压缩成零。

五、真正的风险：staging 与生产的一致性

对跨境独立站来说，这套工具的实际风险不在智能体本身，而在预发布环境与生产环境的差异。

多市场店铺的常见情况是：生产环境开着全页缓存与 CDN、挂着若干支付与物流插件、连着 ERP 的增量同步，而 staging 往往是简化版——缓存关着、插件授权不全、数据是一周前的快照。在这个前提下「在 staging 上验证通过」，不等于「上线后不会出现只在真实流量下才暴露的问题」。尤其是插件冲突、支付回调、库存同步这三类故障，通常只在生产条件的组合下才会触发。

所以落地建议是从低风险、低价改动开始试点，而不是从最有价值的改动开始。可以先跑三类任务：非高峰时段的 CMS 区块与促销条更新、meta 标题与 301 重定向这类别名规则维护、以及移动端 UI 微调。这几类改动回滚成本低、影响面可控，正好用来验证沙箱与生产的差异到底有多大。跑顺了，再往 extensions 安装与兼容代码清理这类中度任务推进。

第二件事是在采购前核对自家的内控要求。审计日志到底记了哪些字段、能不能导出、保留多久、回滚是否覆盖数据库层面的改动（比如 CMS 区块与配置项这类存在数据库里的东西），这些通常在官网上一句带过，但对走过 ISO 内审或 SOX 流程的公司是硬门槛。Scandiweb 的答复是「可以接入你现有的 Git 与发布流程」，但具体到「每一次改动是否都产生可归档的证据」，需要在线上 demo 之外，拿自己的权限模型去问。

第三件事是算清楚席位与吞吐。Team 方案席位不限，理论上运营、项目经理、外包代理商可以同时使用；但每月 2000 个信用点是一个共享池，多市场高频改动的团队要评估加购成本。官方未公布单个任务的信用点换算，这是试用阶段最该问清的一个数字。

把 Magento 的日常改动从「提工单等开发」变成「提需求即执行」，被改变的不是技术难度，而是响应速度的组织结构。真正的考验是：当改一次的代价降到 10 美元以下，团队是用来做更多测试，还是用来堆更多没验证过的改动？

六、参考资料

• withari.ai（Ari 官网）：《Ari — Agent for Magento | Build & fix your store with AI》
• SecurityBrief：《Scandiweb launches Ari AI for Magento store upkeep》
• WiseVoter：《Scandiweb Launched Ari AI for Magento Store Maintenance》
• eCommerceNews：《Scandiweb launches Ari AI for Magento store upkeep》
• Scandiweb：《New Ari: Agent for Magento》