跨境电商团队最常见的痛点不是「缺一个 ChatGPT 账号」，而是五条业务线各自半自动化：客服在 Helpdesk 里复制粘贴、选品靠表格、广告投手盯 ROAS、仓库用 ERP 导单、售后在邮件和平台工单之间来回切。把这几块用 AI Agent 串成一条可审计的流水线，核心只有三件事：统一事件总线（订单/消息/广告指标都变成事件）、分域 Agent + 明确工具权限、人工审批闸门（退款、改价、下架、大额预算）。
下面按从 0 到 1 可落地的顺序写：先画架构与数据契约，再分别实现客服、选品、广告、订单、售后五个 Agent，最后讲编排、观测与合规。示例以 Shopify + Amazon Seller + Meta/Google Ads 常见组合为主；自建栈可用 Webhook + 队列 + 任意 LLM API。若 Agent 网关需要 7×24 常驻进程，可把编排节点放在固定区域的 Cloud Mac 上跑 cron 与本地脚本，业务 API 仍走各平台官方接口。
总架构：事件总线、编排器与工具层
不要把「一个超级 Agent」塞进所有 API。可维护的做法是薄编排 + 厚工具：
- 事件总线：Kafka、Redis Streams、SQS 或 Postgres
outbox表均可。所有入站消息统一成 JSON Schema，例如order.created、ticket.opened、ads.campaign.overspend。 - 编排器：根据事件类型路由到对应 Agent Worker；维护订单级状态机（待回复 → 待发货 → 异常 → 已结案）。
- 域 Agent：每个 Agent 只有本域工具（客服读 KB、订单读 WMS），共享只读「客户画像」视图。
- 审批队列：退款、改价、下架、预算 > 阈值等写入
pending_approvals，Slack/飞书卡片一点批准才执行。
数据与凭证：先把「单一事实来源」钉死
Agent 乱答，九成是数据分叉。上线前至少对齐：
- 商品主数据：SKU、变体、海关申报要素、禁运国家 — 以 ERP 或 PIM 为准，店铺后台只读同步。
- 订单状态：平台订单 ID ↔ 内部
order_id↔ 物流单号 三张表要有映射表，Agent 查询只走映射层。 - 客户时间线：把邮件、站内信、WhatsApp、平台消息归到同一
customer_id。 - 凭证托管：Shopify Admin API、Amazon SP-API、Meta Marketing API 的 token 放密钥管理（Vault / KMS），Agent 运行时短期换票，禁止写进 prompt。
每个 Agent 的输出强制结构化（例如 intent、confidence、proposed_actions[]）。自由文本只给用户看，编排器只解析 JSON，才能做回放与审计。
客服 Agent：多渠道意图、知识库与升级
输入：Gorgias、Zendesk、Shopify Inbox、Amazon Buyer-Seller Messaging 等 webhook。工具：检索政策库（退货天数、保修）、查订单物流、创建工单备注。策略：
- 意图分类：物流查询 / 缺件 / 质量 / 取消订单 / 威胁差评 — 每类绑定允许动作白名单。
- RAG 知识库用版本号：政策变更时 bump 版本，旧对话不混新规则。
- 低置信度或情绪激烈 →
escalate_to_human，并附上 Agent 已查过的订单事实，减少人工重复劳动。
回复语言跟买家站点语言走；多语言用同一套结构化意图，不要每个语言一个 Agent。
选品 Agent：信号、打分与人工池
选品 Agent 不负责「拍板上架」，负责压缩信息：把趋势、竞品价、毛利、合规风险打成一张决策卡。
- 信号源：平台热搜、第三方销量估算、广告库创意、专利/商标简单检索（仍须律师终审）。
- 打分模型：规则 + LLM 摘要；输出
score、risks[]、suggested_moq。 - 人工池：score 高于阈值进「待采购会」看板；Agent 自动写竞品对比表，不自动创建采购单。
广告 Agent：创意、出价与异常熔断
广告域最容易烧钱。Agent 权限应读多写少：
- 只读监控：每小时拉 campaign 级 spend、CTR、ROAS；异常（花费突增、CTR 断崖）发事件
ads.anomaly。 - 建议模式：生成「缩预算 / 换素材 / 扩受众」建议卡，默认不自动改预算。
- 自动模式（可选）：仅在 ROAS > 目标且花费 < 日上限时，允许 ±5% 预算微调；上调仍走审批。
- 创意文案 Agent 单独跑：输出 3 套 headline + primary text，人工选一套再推送 Meta/Google。
订单 Agent：履约、异常与对账
订单 Agent 监听 order.paid、inventory.low、shipment.exception：
- 校验地址（邮编、偏远附加费）、黑名单、重复下单。
- 路由仓库：按库存、时效、头程成本选仓；缺货触发拆单或客服 Agent 通知买家。
- 回写跟踪号到店铺与平台；异常件自动开售后预备工单。
- 日终对账：平台结算 ↔ 支付网关 ↔ ERP 应收，差异 > 阈值报警。
售后 Agent：RMA、退款与平台纠纷
售后与客服共享客户时间线，但工具更敏感：
- RMA：校验是否在退货窗内、是否拆封、是否跨境退运 — 输出
approve_rma建议，执行需审批。 - 退款：部分退 / 全额退 / 退运费分档写进策略表；Agent 只填金额建议。
- 平台纠纷：Amazon A-to-z、PayPal dispute — Agent 拉证据包（物流签收、聊天记录、政策截图），人类提交。
编排：n8n / 自研状态机 / Agent 框架怎么选
| 方案 | 适合 | 注意 |
|---|---|---|
| n8n / Make | 10 人以内、Webhook 多、要快 | 复杂状态机会变「面条图」；版本管理用 Git 导出 JSON |
| Temporal / 自研状态机 | 订单长流程、要可靠重试 | 开发成本高，适合订单/售后核心链 |
| LangGraph / 同类 Agent 框架 | 单域内多步推理 | 跨域仍建议事件总线，不要一个图包全场 |
| OpenClaw 等多通道网关 | 要把审批、告警推到 Telegram/Slack | 网关只管消息与工具路由，业务状态仍在你的 DB |
推荐路径：第 1 周用 n8n 打通「新工单 → 查单 → 草稿回复」；第 2–3 周把订单状态机迁到代码；第 4 周再接广告只读监控。
观测、成本与安全基线
- 追踪：每个 Agent 调用记
trace_id、模型、token、工具名、是否触发审批。 - 回放：保存输入事件 + 结构化输出，方便纠纷时证明「按政策回复」。
- 成本：客服用较小模型做分类，大模型只用于成稿；选品/广告日报可批处理。
- 合规：GDPR/个人信息最小化进 prompt；平台规则禁止自动刷评、操纵排名 — Agent 动作白名单要写法务可读。
四周落地路线图
- 周 1：事件 schema + 订单/客户映射表；客服 Agent 只读查单 + 草稿回复（人工发送）。
- 周 2：订单 Agent 自动分仓 + 回传跟踪号；异常升级售后预备。
- 周 3：选品日报 + 广告异常告警；审批流上 Slack/飞书。
- 周 4：售后 RMA 建议 + 对账差异报警；全链路 trace 与周报 ROAS/CSAT。
FAQ
文末结构化 FAQ 见页面 JSON-LD；此处摘要：能否一个 Agent 做完、Shopify 与 Amazon 能否共用客服、广告能否全自动、如何防 prompt 注入、编排节点放哪里最稳。