电商 AI Agent：哪些工作它真能做完

设想这样一个场景：晚上 9 点，顾客发邮件要求取消订单。客服 AI 几秒内回复：“已处理，订单已取消，退款正在路上。”Shopify 后台也显示订单已取消、已退款。可这笔订单早已推送给第三方仓库，没有任何环节通知仓库停止发货。两天后包裹送到顾客手里，紧接着来了一封邮件：订单明明“取消”了，为什么还发了货？

这个场景是假设的，但其中每一步都对应着产品文档里写明的行为。以 Gorgias 为例，它的文档说明：在 Shopify 里取消订单，并不会同时在 3PL 仓库取消；如果订单已提交履约，需要另外配置仓库端的动作（Gorgias）。AI 理解了请求，也执行了真实的操作，但事情还是在最后一步、在它够不着的那个系统里失败了。

“给出回答”和“把事做完”之间的这段距离，是眼下挑选电商 AI Agent 最有用的视角。模型越来越擅长多步骤工作，你已经付费的软件也在接手更多这类工作。你能不能从中获益，取决于工具能否用到正确的业务数据、触达这件事涉及的每个系统，并留下可以核实的结果。

先说结论：

• AI Agent 是什么。 一种软件：接收一个目标（比如“如果符合政策，就取消这笔订单”），读取店铺数据，自己决定步骤，并用获准的工具去执行，做不下去时交给人。很多挂着“Agent”名号的产品其实更窄：内容生成、预测模型、推荐引擎、固定规则自动化。这些工具可能很有价值，但它们不会自己判断并行动。
• 哪些工作值得交出去。 重复性高、政策清楚、结果能在业务系统里查到的工作：订单状态咨询、符合条件的取消、营销流程审查、定期业绩报告、采购单草稿。需要判断的决定，比如上哪款新品、旺季前补多少货、是否给某个例外开绿灯，仍然要由人来拍板，AI 可以先把基础工作做好。
• 从哪里开始。 从你已经在付费的软件开始。2026 年 9 月到 10 月底，Amazon、Klaviyo、Intercom、Triple Whale 和 Shopify 都在商家已经在用的产品里加入了新的 Agent 功能。
• 什么时候新增工具或自己搭建。 只有当你能指出现有工具完成不了的那一步（通常是写入另一个系统、一条审批规则，或者它读不到的数据），而且新方案确实能完成这一步时。
• 怎么判断有没有效。 别数回复条数或草稿数量。去查业务记录，比如订单、退款、仓库状态、已发布的页面，数一数有多少件事最终落到了正确状态，再加上员工检查和返工花掉的时间。

你的第一个 AI Agent，可能已经在后台里了

一年前，“要不要买 AI Agent”通常意味着评估一家新供应商。过去三个月改变了这个起点：本来就掌握你数据的平台，开始自己推出 Agent。

这些内置 Agent 有一个新供应商短期内无法匹敌的优势：它们已经有你的数据、你的权限和你的付费关系。它们的短板正好是这个优势的另一面：每一个都在自家平台内最得心应手。连接器和 MCP 能扩大它们的触达范围，但不会自动把你的仓库、客服系统和采购单交给同一个 Agent 掌控。Klaviyo 看不到你的仓库；Sidekick 不和顾客对话；Moby 能解释广告花费，却补不上你从没录入过的商品成本。

所以，采购问题变了。不再是“哪个 AI Agent 最好”，而是“这件事里，我已有的 Agent 哪一步做不完”。如果答案是“没有重要的缺口”，你就省下了一笔采购。如果答案很具体，比如“它没法在我们的 3PL 那边拦住订单”，你就清楚第二个工具必须证明什么。

关于模型新闻，补充一句：Anthropic 表示，9 月底发布的 Claude Sonnet 5.5 在长流程、多步骤工作上更强，单个任务成本也比上一代低（Anthropic）。这是重新测试一项此前被你否掉的工作的好理由，但不能证明你的工具已经变强。用什么模型由供应商决定：Fin 4 发布时搭载的是 Intercom 自己的 Fin Apex 2.0 模型；我们 11 月 7 日查看时，AI by Zapier 的 Premium 档“Auto”选项默认用的是 Claude 4.6 Sonnet（Zapier）。模型发布改变的是“可能做到什么”，只有产品更新才改变“你能用上什么”。

“做完”分五个层级，先弄清你买的是哪一级

不同供应商会用同样的说法描述完全不同的结果。“能处理取消”可能是指起草一条回复，也可能是改了订单，还可能是改了订单并确认仓库已经停发。比较产品之前，先判断这件事需要哪一级：

市面上大多数工具做到第 1 到第 3 级，而这往往正是你需要的。一份每周替分析师省下两小时的报告就值得拥有。问题出在把第 4 级的操作当成第 5 级的结果，就像开头那个取消订单的故事；或者把第 1 级的报告说成“自主营销”。

这五个层级有两种用法。第一，确定这件事需要哪一级：销售总结只需第 1 级，退款需要第 5 级。第二，核对工具在你的实际配置下（你的仓库、你的套餐、你的权限）到底能做到哪一级。下表把 EcomAgentTools 收录的八类工作流，对应到代表性工具目前通常能达到的层级。

注意第 4 级和第 5 级出现在哪里：客服，以及你自己搭建的流程。所以最能说明问题的选择也在这两处。

同一笔取消，三个正确答案

就拿一件事来说：顾客要求取消订单，而你的政策规定，只要还没发货就可以取消。选哪个工具，与其说取决于哪个 AI 更聪明，不如说取决于你店里已经在用什么。

店铺 A 使用 Shopify、Gorgias 和 ShipBob。 Gorgias 的 AI Agent 自带 Shopify 预置操作，包括取消未履约订单并在 Shopify 中把商品退回库存；退款如何处理，要在你自己的配置里确认。单靠这个操作只能到第 4 级。Gorgias 另外为 ShipBob、ShipStation 等 3PL 提供了单独的操作，同一段对话就能在仓库端取消订单。两者都配好后，这家店不写代码也能接近第 5 级，再加一个 Agent 很难说得过去。需要注意一点：我们没有在 Gorgias 文档中找到像 Fin Procedures 那样、让单笔取消暂停等待人工签字的步骤。如果你的政策要求每笔退款都要审批，就把这类对话转给人处理，或者另外搭建审批环节。

店铺 B 使用 Intercom，仓库有自己的 API。 这时由 Fin 通过 Procedure 执行操作。Procedure 是你为某项任务写下的分步说明，再配合调用你系统的数据连接器（Intercom）。这比店铺 A 需要更多准备，因为得有人搭建并测试连接器调用。换来的是，你可以插入一个“Loop in teammate”步骤，让 Procedure 停下来，等人批准后再继续。如果规定时间内没人回应，对话会升级给你指定的负责人（Intercom）。

这套做法是否安全，关键在另一个名字相近的功能。Fin 的“Ask for input”升级规则目前是 beta，允许同事在 Fin 的回复发出前审核。如果你设了时限，而到时没人回应，Fin 会直接发出它原来的草稿（Intercom）。对于一条关于发货时间的回复，这样做没问题；用来把关退款决定，就是错误的控制方式。两个功能都叫“human in the loop”，没人回应时的行为却正好相反：一个停下并升级，另一个照常发出。供应商说“由人来批准”时，要追问一句：人没回应会怎样？

店铺 C 每月只有 40 笔取消，两个人负责。 老实说，这家店可能什么新工具都不需要。在 Shopify 后台取消一笔订单只要一两分钟，Sidekick 也能准备受支持的订单变更，由商家确认。搭建、测试和监控一个能执行操作的 Agent 要花不少小时，每月 40 笔取消很难很快赚回来。

无论走哪条路，成功的证据都一样：一笔已取消的订单，一笔币种和金额都正确的退款交易，一条仓库确认，以及一条与这三者一致的顾客消息。上线前，先测那些容易出事的情况：同一请求同时从邮件和在线聊天进来；订单部分已履约；仓库已经放单拣货；退款调用超时，没人知道钱到底退了没有。最后这种情况最要紧。结果不明时，Agent 应该先查一下是否已存在退款，而不是直接重试。

同样的工作量，不同的账单

客服 Agent 也说明了，计费单位能让比较结果完全反过来。Intercom 按坐席收费，再按 Fin 的每个“结果”（outcome）收费。Gorgias 按工单量和 AI 互动次数收费，不按坐席收费。要公平比较，必须把工作量固定住。

下面是一个计算示例，使用 2026 年 11 月 7 日查看的公开月付标价（美元）。这只是算术，不是报价，也不是测试结果。假设一家 Shopify 店有两名客服，每月通过邮件和在线聊天处理 300 个对话，全部是常见问题或只读的订单状态查询，不涉及退款或取消。其中 200 个由 AI 完整解决，100 个由人处理。假设两款产品都能做到这个结果。

按这些假设，Intercom 便宜 $69。但改一个条件，排序就会翻转：

• 增加人手。 如果 Intercom 需要四个完整坐席，这一侧就涨到 $354（$156 + $198），而 Gorgias 仍是 $345，因为 Gorgias 不按坐席收费。
• AI 解决得更少。 如果 AI 只解决 50 个对话而不是 200 个，Intercom 一侧降到 $127.50（$78 + $49.50），Gorgias 一侧降到 $120（$90 + 20 × $1.50），Gorgias 反而更便宜。

这个算例有几处限制。$345 是按公开组合价算出来的，不是 Gorgias 的最低可购价：Gorgias 允许提前提高 AI 额度以避免超额费，而我们没有拿到预购 200 次互动的价格。Intercom 定价页默认按年付展示，还标注新客户可享 35% 折扣，所以页面上的坐席价低于这里用的 $39 月付价。Fin 在两种情况下计一个结果：完整解决一个对话，或者把 Procedure 执行到设定的转人工节点；Intercom 说明，顾客主动要求转人工不收费，对话重新打开也会退还费用。最重要的是，这个只读场景完全说明不了：取消订单这件事所需的 Procedures、审批和 3PL 操作，是否包含在两家的基础套餐里。要给你真正想自动化的那件事算价，然后再加上定价页上永远看不到的成本：搭建时间、审核时间，以及出错后的修复。

营销：已有平台里的 Agent 往往就够了

“先用已经有的”这条原则，在营销上回报最明显，因为最新的能力恰好落在商家已经在用的平台里。

拿一项反复要做的事来说：检查一条正在运行的 Klaviyo 自动化流程，看有没有过期的折扣码、失效链接和已缺货的商品。在 Klaviyo 里，Composer 可以审查流程并给出修改建议；从 9 月起，它还能运行定时任务、复用团队保存的 Skills。每个 Klaviyo 客户都自动拥有一个免费 Composer 计划，每个周期 500 credits。$20 的月付计划含 2,000 credits；如果开启弹性超额，每超出一次会自动以 $10 购买 1,000 credits，即使只用了一部分，也按 $10 全额收费。Klaviyo 估计，审查一条流程、一个表单或一个模板会消耗相当于 $0.10 到 $4.50 的额度，具体取决于规模和复杂度（Klaviyo 帮助中心）。按付费计划的费率折算，免费额度约值 $5，几次大型审查就可能用完。

对 Klaviyo 店铺来说，这是一次便宜、低风险的试用。复制一条流程，跑一次审查，记下它发现了什么。然后把两个数字分开记：发现的问题，和修好的问题。发现问题是第 1 级。修复只有在有人实际改动、而且线上流程确实显示改动之后才算数。如果 Composer 标出一个过期折扣码，最后还是营销人员动手改的，你省下的是检查时间，而不是整件事。

由于 Klaviyo 开放了 MCP，你也可以在 Claude、ChatGPT 这类通用助手里做同样的审查。如果团队本来就在那里工作，这很方便，但也多了一个权限问题：一个能写入 Klaviyo 的外部助手，需要和 Composer 一样的审核规则。

BrazeAI 面向已经在用 Braze 的较大团队，它也说明了产品名里带“AI”并不代表能做到哪一级。BrazeAI Operator 帮员工用自然语言搭建内容、分群和 Canvas 旅程，这是草稿层级的制作辅助。Decisioning Studio 做的是另一件事：在团队批准的标题、优惠和发送频率范围内，由它决定每位顾客收到什么、什么时候收到。这是真正的自主执行，但只在你设定的边界之内。这两个工具都不足以成为更换邮件平台的理由。如果 Klaviyo 或 Braze 已经在承担你的营销消息，先测试平台内的 Agent，再考虑单独的营销 Agent。

一个库存数字，牵动五件事

流程审查发生在一个系统里。取消订单的故事已经说明了一件事跨两个系统会怎样。很多代价高昂的错误，出在要跨五个系统的事情上。再设想一个场景：你卖得最好的海军蓝毛衣 M 码只剩四件，下一批货两周后才到。这一个事实至少要传到五个地方：

1. 补货。 Inventory Planner 把预测转成建议数量和采购单，采购单会从草稿、批准走到开启状态（Inventory Planner）。它的 Shopify 连接器每天同步一次新订单和当前库存，并不是实时的，所以在相信“还能卖几天”之前，先看数据最后更新于什么时候（Inventory Planner）。Prediko 提供基于 Shopify 的采购表、补货提醒和采购单创建。无论哪种，生成采购单都不等于供应商已经接单。
2. 营销。 上一节那条 Klaviyo 流程，可能还在浏览放弃邮件或促销邮件里推这件毛衣。
3. 站内导购。 Rebuy 的推荐，或者对话式导购助手，可能还在推荐这个规格。Intercom 自己的 Fin for Ecommerce 设置指南也提醒：对于预售、定制或库存受限的商品，Fin 可能匹配到错误的商品页，给出不准确的可售信息；它建议为这些情况设置 Guidance 规则（Intercom）。如果顾客的需求能用颜色、尺码、价格、有货等筛选条件表达，Shopify 免费的 Search & Discovery 筛选功能也许就能解决，根本不需要对话式 Agent。
4. 客服。 客服人员，不论是人还是 AI，都需要同一个到货日期。如果还没人确认日期，就应该如实说明，而不是猜。
5. AI 购物渠道。 Shopify Catalog 会把商品的标题、描述、选项、图片、价格和可售状态提供给 AI 渠道，并持续更新库存和价格。如果关键数据放在自定义字段里，需要先做映射，这些渠道才能正确读取（Shopify 帮助中心）。

这些工具各有自己的规则或 Agent，却没有一个对这个共享的事实负责。这就是为什么多加 Agent 可能让情况更糟：每多一个，就多一个地方可能把过时的库存数字变成错误的承诺。真正有用的做法并不起眼：所有地方用同一个 SKU 或规格 ID；约定由哪个系统保存真实库存；每份副本都带时间戳；每个动作都有明确负责人，比如暂停邮件、修改到货说明、批准采购单。

商品内容也是同样的道理。Photoroom 和 Canva Magic Studio 让场景图、变体图和多尺寸图变得很便宜。两者都不是自主 Agent，而是停在第 3 级的内容工具。Photoroom 的 Shopify 工作流，只有在有人把编辑后的图片发布回店铺时才会改动店铺图片（Photoroom），真正的工作也就转移到了这一步审核。当图片几乎不花钱时，风险就转到了准确性上：颜色是否与实际面料一致，每个规格配的图对不对，生成的场景是否暗示了商品并不具备的尺寸或功能。AI 购物渠道会读取并转述你目录里写的一切，所以准确的商品数据如今影响的不只是你自己店里的销售。

只在需要判断的地方，才搭建连接流程

当一件事跨越的系统没有任何供应商帮你连起来时，就得自己搭。实用的原则是：每一步都用最简单的工具。

• 先用固定规则。 “某规格可用库存低于 5 件时打标签并通知采购”不需要 AI。Shopify Flow 是 Shopify 的免费应用，做这件事稳定可靠，也便于检查。
• 只在需要判断时才加 AI 步骤。 给一封表述混乱的顾客邮件分类，或判断某个例外该归三个团队中的哪一个，确实适合用模型。在 AI by Zapier 中，每次运行消耗的 task 数取决于模型档位和成功的工具调用次数。一次调用两个工具的运行，在 Advanced 档消耗 9 个 task，在 Premium 档消耗 15 个，而 Premium 是新步骤的默认档位。每月 300 次这样的运行，就是 2,700 或 4,500 个 task，还没算 Zap 里的其他步骤（Zapier）。除非你为每个工具单独开启“Require approval before running”，否则工具会直接运行，不会暂停等待确认。
• 迁移会改变行为。 Zapier 正在把 Zapier Agents 迁到 AI by Zapier。它还没定下停用日期，但迁移指南要求在发布转换后的 Zap 后关闭原来的 Agent，以免同一个操作执行两次。部分知识源暂不支持（Zapier）。我们的 Zapier Agents 页面 介绍的是旧产品。
• 控制越多，责任越大。 Make AI Agents 把 Agent 放进可视化场景里，按 credits 计费。n8n 可以自托管，你能掌控数据和运行环境，但也要自己负责凭证、监控、备份和升级。

不管用哪一个，都让模型负责提出方案，再用一个固定步骤在写入前核对订单号、金额、币种，以及这个操作是否已经执行过。这样的分工是你自己的设计选择，这些平台都不会默认替你保证。

Amazon 卖家的起点不一样

上面的内容都默认你经营的是 Shopify 或 DTC 店铺，客服系统、邮件平台和连接器都由你自己挑选。在 Amazon 上，Seller Central 就是记录业务状态的系统，它的 Agent 也在里面。

在选品研究上，Jungle Scout 和 卖家精灵 SellerSprite 是带 AI 功能的研究工具，不是 Agent。Jungle Scout 的销量估算和机会评分只能作为方向性参考，AI Assist 的可用次数随套餐不同。卖家精灵每天记录一次竞品的价格、排名和新上架商品，所以不会捕捉两次快照之间的每一次变化；它的 API 和 MCP 与网站订阅分开购买。两者都能帮你把一长串细分市场缩小到少数值得深入研究的几个，这属于第 1 到第 2 级。要不要下单备货，仍然需要供应商报价、到岸成本和毛利测算。没有这一步，别让一个销量估算变成一张采购单。

在日常运营上，Seller Assistant 的新工作流，是大多数 Amazon 卖家能用到的最接近第 4 级的 Agent。Amazon 表示，它能在你设定的限制条件内，监控并执行补货、调价等日常任务（Amazon）。真正的工作在于设好这些限制条件。价格下限应该是扣除平台费用和广告后的毛利底线，而不是随手定的整数。至少在初期，要定期查看审计记录。在围绕这个功能做计划之前，先确认你的账户在哪些站点可以使用。

两个渠道都经营的卖家，还要注意两点。Sidekick、Flow、Rebuy 这些 Shopify 工具不作用于 Amazon 商品，所以多渠道卖家需要两边共享的库存数据，而且连接器要实际验证，不能想当然。另外，“支持 100 种语言”不等于能在另一个市场卖好。顾客消息也许能完美翻译，工具却可能接不上那个市场的平台，处理不了当地币种和税务规则，也连不到你在那里的仓库。

怎么判断一次试用是否真的把事做完了

一次试用只需回答一个问题：这个工具能否可靠地把这件事做完，总成本与你现在的做法相比如何？要回答它，你需要四样东西。

写下来的终态。 用系统里的状态来描述：“Shopify 中订单已取消，3PL 确认已拦截，按原币种退款一笔。”不要写“顾客满意”这类结果。

所有方案用同一组输入。 让你现在的流程和每个候选工具跑同样的常规情况，也跑同样的棘手情况：重复请求、过时数据、缺少交期、权限不足、部分失败。我们的试用记录模板列出了 28 条这样的测试设计，每条都有初始状态、预期结果和需要核对的证据。它们只是设计，不是结果，“实际结果”等列留空，由你填写。

每次运行都留记录。 记下达到的层级、回读到的证据、审核和修复花的分钟数，以及消耗的用量单位。

用对衡量成功的单位。 用总成本（软件费用、审核时间、修复时间）除以经核实完成的任务数。起草了 20 条回复，和正确取消了 5 笔订单，不是一回事。然后再看这件事本该带动的业务指标，比如重复联系、退款差错、退货、响应速度或毛利。单件任务成本更高的工具也可能是对的选择，只要它回复更快、成交更多或差错更少；关键是把这些收益量出来，而不是默认它们存在。

这些业务指标本身也有陷阱。在让 Agent 解释上周毛利为什么下降之前，先确认数据能不能回答这个问题。Shopify 的利润报表只覆盖售出时已录入成本的商品和规格（Shopify 帮助中心）。Agent 照样会给出一个听起来可信的解释，哪怕这个毛利数字因为一半 SKU 没有成本而根本是错的。Triple Whale 的 Moby 能定期发送报告，在更高套餐中还能执行操作。它的“Ask every time”设置会把每个操作排队等你批准，而“Let Moby decide”可能在不逐一询问的情况下，直接在真实账户里执行受支持的操作（Triple Whale）。Polar Analytics 提供托管数据仓库和一套共享的指标定义，供看板、受众工具和它的 Headless MCP 共同使用。当问题出在口径不一致时，才值得为这种底层能力付费；别因为“分析 Agent”听起来很聪明就买。如果成本数据缺失，先把成本补上，任何模型都绕不过这一点。

2027 年可能改变什么，以及什么情况会推翻这些建议

以下是基于已经上线的功能作出的判断，不是带日期的预测。

平台内置 Agent 会覆盖更多日常工作。 Shopify、Amazon、Klaviyo 和 Intercom 都在一个季度内，从回答问题走向定时执行、实际操作。如果这个趋势持续，独立工具会越来越需要证明自己能完成平台完成不了的那一步。如果到 2027 年年中，原生功能仍然主要产出报告和草稿，而人手负担并没有减轻，这个判断就该修正。

审批会按单个操作来设计。 Fin 的例子说明，同样叫“human in the loop”，没人回应时的行为可以完全相反。可以预期，买方会逐个操作追问：谁批准，系统等多久，等不到之后会发生什么。

账单会跟着完成的工作走，所以模型变便宜不一定意味着账单变少。 按结果、按 credits、按 task 计费，本来就随用量增长。供应商可以用单任务更便宜的模型，同时跑更多步骤、更多重试或更高档位。持续跟踪“每个经核实完成任务的成本”，而不是默认它会下降。

商品数据会在你的店铺之外承担更多工作。 随着 AI 购物渠道直接读取商品目录，规格、可售状态和政策是否准确，会影响商品能否被正确推荐。被发现是一回事，完成结账是另一回事。Shopify 的文档说明，AI 渠道中的结账，要么转到商家自己的结账页面，要么在符合条件时直接完成（Shopify）。针对你的店铺和地区，逐一确认每一步。

运营人员花在具体步骤上的时间会减少，花在例外上的会增加。 当草稿和报告自动送到眼前，有价值的工作就变成设定目标、核对结果、处理系统处理不了的情况。上面这些工具已经让这种转变开始。它能走多远，取决于底层的共享事实，也就是库存、订单和成本，能否可靠到让人放心。

下一步

列出团队最常重复的三件事。每一件，写下它需要的“做完”层级，以及你现有工具在实际配置下能达到的层级。两者不一致的地方，就是新工具或一个小型自建流程必须补上的具体缺口。其余的事，用你已有的工具，并以真正完成的任务来衡量。