前阵子帮一位做跨境电商的朋友处理订单流程，他同时在四个平台开了店，每天要反复登录后台、导出订单、手工合并地址、再回填到 ERP 里。搞了一个月，他最大的体会不是单量有多大，而是重复操作能把人磨疯。后来我用 Agent Skills 配合 WorkBuddy 搭了一套自动化工作流，把多平台订单抓取、清洗、回传全部串起来，现在他每天只需要处理异常订单和平台消息。这篇文章会把整套思路、工作流搭建过程以及实际踩坑记录写清楚，适合正在做多平台运营、想用 Agent 替代重复劳动的朋友参考。
1. Agent Skills 到底在解决什么问题
1.1 从"对话助手"到"能干活的执行者"
很多人第一次接触 Agent 时，觉得它就是个升级版聊天机器人，问啥答啥。真正让 Agent 产生生产力的是它开始"动手干活"：读取订单、调用接口、写数据库、发通知。要做到这一点，单靠模型本身不够，必须有一组可以被 Agent 调用的能力单元，这就是 Agent Skills。你可以把 Agent 看成大脑，把 Skills 看成手和脚。大脑负责任务拆解和决策，手脚负责具体动作。两者配合，Agent 才能从一个"会说话的顾问"变成"能交付结果的员工"。
在跨境电商这种多平台场景里，Agents 的意义更直接。平台之间数据不互通，账号体系不同，订单格式也不同，任何自动化方案都要面对这些差异。Agent Skills 的核心贡献，是让"差异处理"不再是一堆写死的 if-else，而是变成了按需调用的技能包。每次遇到新平台，你只需要新增一个 Skill，而不是把整个系统推翻重来。
1.2 它和 API、RPA 有什么差别
传统 API 集成是把所有逻辑硬编码在服务里，平台一改字段就要跟着改代码；RPA 靠模拟点击，界面一更新就经常失灵。Agent Skills 的方案多了一层"编排"：Agent 根据当前任务和上下文，自动选择要调用哪些 Skill、按什么顺序调用。这意味着面对小改动时，你只需要调整提示词或者新增一个 Skill，而不是重写整条链路。
多平台场景的价值就在这：平台数量越多、差异越大，这种动态编排的优势越明显。订单抓取只是其中一种应用，库存同步、售后退款、商品上架都是类似的问题结构。如果你只是在两个平台间做固定搬运，写脚本或者 RPA 都够了；一旦超过三个平台，还要频繁处理字段差异和平台策略变化，Agent Skills 的维护成本优势就会体现出来。
2. 多平台订单抓取：先想清楚再动手
2.1 痛点拆解
跨境电商的订单抓取，比听起来麻烦得多。平台 A 返回的是美元和州省地址，平台 B 返回的是人民币和详细地址，平台 C 可能需要先登录卖家后台才能拿到数据，而每个平台还有各自的上传限制、时区和字段命名。数据落到本地之后，还要做统一格式化才能进入 ERP。人工做这套流程，操作繁琐且容易漏单，尤其是大促期间订单量一上来，漏一单就是实实在在的损失。
自动化的核心难点不是"抓"，而是抓完之后怎么让数据可靠、一致、可追溯。直接写脚本能解决单点问题，但很难兼顾所有平台的异常情况。比如平台临时限流、接口报错、某个订单字段缺失，这些都需要有兜底机制。Agent Skills 的思路是把采集、清洗、匹配、回写拆成独立技能，每个技能只做一件事，再由工作流串联起来。这样任何一个环节出问题，都能快速定位，不会把整个自动化流程都拖垮。
2.2 流程设计原则
设计 WorkBuddy 工作流时，我遵循一个原则：尽量让 Agent 做决策，让脚本做执行，让工作流做保障。决策包括判断订单状态、匹配发货仓库、识别问题订单；执行包括调用平台 API、写入数据库、发送 webhook；保障包括定时触发、失败重试、人工审批。这个分层让每个环节职责清晰，排错时不用把整个流程翻一遍。
举个例子，抓取订单时，Agent 会先检查当前店铺的授权状态，如果 token 即将过期，就优先走刷新流程，再决定是否继续抓取。这个决策放到脚本里很难写全面，因为不同平台的 token 有效期和刷新方式都不一样，但放到 Agent 的提示词里，它就是一句话的事。执行层面完全交给脚本，确保数据准确性。工作流层面则负责定时触发和失败重试，保证整个系统能长期稳定运行。
2.3 整条链路的文字说明
因为工作流比较复杂，我先用文字描述整条链路，方便你建立体感：
定时触发器启动 → 采集订单 Skill 从各平台拉取新订单 → 清洗 Skill 将字段统一为内部格式 → 匹配 Skill 判断订单归属仓库和发货渠道 → 回写 Skill 写入 ERP → 通知 Skill 发送汇总消息 → 任何一环失败进入人工异常队列。
每个 Skill 之间通过一个统一的 order 对象传递数据，字段固定，但内容可以根据平台不同做适配。这个设计很关键，它让 Agent 不需要关心每个平台的数据细节，只需要操作统一格式的对象就行。
3. 实操搭建：WorkBuddy 里的完整工作流
3.1 定义 Skill 的输入输出
我习惯先把 Skill 当函数来设计：明确输入、输出、副作用。这样做的好处是，Agent 知道在什么场景调用它，并且知道调用后拿到的数据长什么样。下面是一个抓取某平台订单的 Skill 定义示例：
id: fetch_shop_orders name: 抓取店铺订单 description: 根据店铺ID和时间范围，从平台拉取订单列表 input: - name: shop_id type: string required: true description: 店铺唯一标识 - name: start_time type: datetime required: true description: 开始时间 - name: end_time type: datetime required: true description: 结束时间 output: - name: orders type: array<Order> description: 标准订单对象列表这里有一点要特别说明：description 不是写给人看的，是写给 Agent 看的。Agent 会根据描述判断这个 Skill 能不能解决当前问题。描述写得越清楚，Agent 调用错误的概率越低。我见过不少朋友把 Skill 当成普通函数写，参数名含义模糊，结果 Agent 经常传错参数，后来把所有 description 补齐，调用准确率立刻上来。
3.2 数据清洗与字段对齐
不同平台的订单字段差异非常大，我的做法是定义一个内部的 Order 标准结构，然后在清洗阶段把各平台数据映射到这个结构上。标准结构包含订单号、平台、店铺、买家姓名、电话、地址、商品明细、金额、币种、下单时间、支付时间、订单状态这几个核心字段，其余信息全部放到 extra 字段里。
清洗逻辑用 Python 写比较顺手。下面这段代码处理了三个问题：金额统一转成人民币、时间统一转成 UTC、地址字段去重合并：
import hashlib from datetime import datetime def clean_order(raw_order: dict, platform: str) -> dict: # 金额转换：按平台币种汇率折算，简化示例 amount_map = { "USD": 7.2, "EUR": 7.8, } currency = raw_order.get("currency", "CNY") amount = float(raw_order.get("amount", 0)) cny_amount = round(amount * amount_map.get(currency, 1), 2) # 时间统一为 UTC raw_time = raw_order.get("create_time", "") if platform == "platform_a": dt = datetime.fromisoformat(raw_time.replace("Z", "+00:00")) else: dt = datetime.utcfromtimestamp(int(raw_time)) utc_time = dt.astimezone(timezone.utc).isoformat() # 地址去重合并 raw_addr = raw_order.get("address", {}) full_addr = " ".join( filter(None, [ raw_addr.get("province", ""), raw_addr.get("city", ""), raw_addr.get("detail", ""), ]) ) return { "order_id": raw_order["order_id"], "platform": platform, "shop_id": raw_order["shop_id"], "buyer_name": raw_order.get("buyer_name", ""), "phone": raw_order.get("phone", ""), "full_address": full_addr, "amount": cny_amount, "currency": "CNY", "order_time": utc_time, "status": raw_order.get("status", "pending"), "extra": raw_order.get("extra", {}), } def dedup_key(order: dict) -> str: return hashlib.md5( f"{order['platform']}:{order['order_id']}:{order['shop_id']}".encode() ).hexdigest()清洗后的数据会自动加一个 dedup_key，用于后续去重。这一步非常重要，因为不少平台在接口重试时会把同一张订单返回两次，没有唯一键做约束，ERP 里就会出现重复单。我实际遇到过一次：平台那边网络超时，我做了重试，结果重复拉取了同一批订单，第二天 ERP 里多出 37 条重复单，全部要人工核对删除。从那以后，去重键成了所有订单类 Skill 的标准配置。
3.3 限频、重试、超时参数怎么定
这类参数最容易拍脑袋，但拍脑袋往往会在高峰期付出代价。我的经验是，每个平台接口都要单独确定限频参数，不能“一套参数走天下”。下面是我常用的一个参考模板：
| 平台类型 | 接口限制 | 推荐间隔 | 单次超时 | 重试次数 | 重试退避 |
|---|---|---|---|---|---|
| 接口开放的电商平台 | 每分钟 60 次 | 1200ms | 10s | 3 | 1s/2s/4s |
| 限制较严的平台 | 每分钟 10 次 | 6500ms | 15s | 2 | 2s/4s |
| 内部中间件（Link-OS） | 每分钟 300 次 | 250ms | 5s | 5 | 0.5s/1s/2s/4s/8s |
推荐间隔怎么算出来的？其实很简单：如果接口限制是每分钟 60 次，那理论间隔就是 1000ms，但你不能顶着上限跑，必须留出 20% 的余量，所以变成 1200ms。这样做是为了避免网络抖动时瞬时请求数超限。重试退避用指数退避而不是固定间隔，因为固定间隔重试容易造成“重试风暴”——所有任务同时失败、同时重试，反而把接口打挂。
超时参数要分两个层面：单次 HTTP 超时和控制整体抓取时间。单次超时设太长，会拖慢整个工作流；设太短，慢接口又会误判失败。实际项目中，普通查询接口我设 10 秒，导出类接口设 30 秒。整体抓取时间则通过分批控制，比如每次只抓 15 分钟的订单，避免单次任务运行太久。
3.4 WorkBuddy 工作流搭建步骤
WorkBuddy 里的工作流搭建，核心就是把上一节定义的 Skill 串起来。我这里说一遍可复现的步骤：
- 创建定时触发器。我设置每 15 分钟运行一次，每次抓取前一个时间窗口内的订单。为什么不是实时？因为大部分电商平台的订单创建到可抓取之间有秒级到分钟级的延迟，太频繁不仅浪费额度，还会触发风控。
- 注册 Agent Skills。把采集、清洗、匹配、回写、通知都注册成独立的 Skill，并填好输入输出描述。注册完成后，可以先单独测试每个 Skill，确保单点可用。
- 搭建主流程。以 WorkBuddy 的节点编辑器为例，把触发器连接到 Agent 节点，再依次连接采集、清洗、匹配、回写和通知节点。节点之间传参用上一步定义的标准 Order 对象。
- 设置失败策略。每个节点都可以配置重试次数和失败出口。我的配置是“重试 3 次，仍然失败就进入人工异常队列”。人工队列接一个通知消息，把失败原因和原始数据贴出来。
- 配置运行监控。WorkBuddy 自带执行日志，我会额外加一个统计节点，每天统计抓取数量、失败数量、耗时中位数，发到群里。
整套流程第一次跑通后，我用了大概一周时间观察数据，核对每天抓取的订单数和平台后台是否一致。确认没有漏单后，才慢慢把人工操作全部切到自动化上。
4. Link-OS 多平台使用的关键细节
4.1 Link-OS 在多平台场景里的角色
Link-OS 在多平台场景里解决的是“多平台接入”的共性问题：统一账号授权、统一数据格式、统一消息推送。你可以把它看成中间层，上面连着各个电商平台，下面面向业务系统。它的价值在于让 Agent Skills 的调用不需要关心每个平台各自的鉴权细节，只需要调用 Link-OS 提供的统一接口。
在我这套订单抓取工作流里，Link-OS 承担了所有平台 API 的网关角色。Agent 不需要知道某平台是 OAuth 1.0 还是 OAuth 2.0，不需要关心 token 存在哪里，只需要告诉 Link-OS“我要拉哪个店铺的订单”，剩下的鉴权和请求转发都由它处理。这让 Agent 的提示词变得很干净，也降低了因为鉴权细节写错导致的故障概率。
4.2 多店铺、多租户的数据隔离
如果多个店铺共用同一套 Link-OS，权限模型一定要设计好，否则订单数据混乱只是时间问题。我见过一个团队把几十个店铺的订单放在一个共享表里，查询时只靠一个字段区分店铺，结果某次 Agent 误把店铺 ID 传空，直接把全量订单都拉出来了，差点造成数据事故。
我的建议是：所有数据表必须有 tenant_id 或 shop_id 字段，所有查询强制带范围条件，代码里禁止出现不带租户条件的查询方法。Agent 在调用链路中要自动传入店铺标识，不能靠模型“猜”。比如 Skill 定义里 shop_id 设成 required，这样 Agent 每次调用必须显式传入，参数不全会直接报错，而不是静默用默认值。
另一个容易被忽略的点是：授权信息也要按店铺隔离。A 店铺的 token 不能拿到 B 店铺的数据。即便 Link-OS 做了统一鉴权，业务层也要再做一层校验，防止“合法身份越权访问”。我在排查数据异常时，经常发现是某个店铺的 token 被误配到其他店铺的上下文里，这类问题加一层“数据归属校验”能直接拦截掉。
4.3 把 Link-OS 封装成 Agent Skill 的小技巧
实际对接时，我建议把 Link-OS 的接口封装成粗粒度的 Skill，而不是一个接口一个 Skill。比如只提供 get_shop_orders、push_order_status、sync_inventory 这三个，而不是把 Link-OS 底层每个 REST 接口都暴露给 Agent。原因很简单：Agent 调用次数越少，出错概率越低，token 消耗也越少。
粗粒度 Skill 还有个好处，就是内部可以封装掉一些跨步骤的操作。比如 get_shop_orders 内部可以先刷新 token，再拉订单列表，再标记已读。对 Agent 来说，它只看到一次调用，但底层其实完成了三个动作。这样即便平台接口有变化，你只需要改这个 Skill 内部实现，Agent 侧完全不用动。
5. 常见问题与排查技巧实录
5.1 登录态失效、验证码、风控
这是多平台自动化里最头疼的一类问题。不同平台的处理逻辑差别很大，但经验法则是一致的：能用官方开放接口就别模拟登录，能在后台配置授权就别走脚本点击。官方接口即使有限频，也比走网页登录稳定得多。
如果必须处理登录态失效，一定要做到“失败即停止”。不要让 Agent 在 token 失效后反复重试，那样只会加快触发风控。我之前的做法是：所有请求先判断返回状态码，如果是 401 或类似权限错误，立即停止当前店铺的抓取任务，发送告警通知，并保留现场日志。等人工刷新授权后再继续。
验证码问题更麻烦。我的原则是：尽量用官方提供的刷新机制，实在不行才考虑人工辅助。与其研究复杂的验证码识别，不如把流程改成“该店铺暂停自动抓取，进入人工补单队列”，这样至少保证数据不漏，只是处理速度慢一点。对电商场景来说，漏单比慢更可怕。
5.2 Agent 幻觉导致的数据错误
Agent 在大模型基础上工作，难免有“幻觉”。在多平台订单场景里，幻觉最常出现在两个地方：一是字段映射错误，比如把平台的“退款状态”当成“发货状态”；二是条件判断错误，比如把“待支付”订单当成“已支付”订单回传到 ERP。
我给的解决方案是：所有数据变更类 Skill 必须加二次校验。最简单的做法是在 Skill 内部加规则引擎，比如“金额大于 0”“订单状态必须在合法枚举值内”“时间不能晚于当前时间”。违反规则的数据直接拦截，不让它进入下一环。更稳妥的做法是设置 dry_run 参数，先跑一次不走真实回写，只输出将要执行的动作，由 Agent 或人工确认后再真正执行。
还有一个笨但有效的办法：在 Agent 的系统提示词里写死边界条件。比如“你只能处理 status 为 paid 或 pending 的订单，其他状态一律丢弃并报告”。看似简单，但能避免 90% 的误回写问题。
5.3 工作流卡死与任务堆积
自动化跑久了，最烦人的就是“静默卡死”。程序没有报错，工作流状态还是 running，但实际上某个环节早就阻塞了。常见原因有三个：外部接口响应慢导致超时、数据库连接池耗尽、队列里积压了太多失败任务。
排查思路很直接：先看监控，哪个节点耗时异常，再去看对应日志。如果是接口响应慢，就把超时时间和重试策略调一下；如果是数据库问题，检查连接池配置和慢查询；如果是任务堆积，确认是否有没有消费完的死信队列。
更重要的预防措施是：给工作流加“看门狗”。WorkBuddy 里可以配置执行超时，超过设定时间就强制标记失败并告警。不要相信无限期运行的流程，任何长时间运行的任务最终都会出问题。我之前吃过一次亏，一个抓取任务因为平台接口 bug 挂了整整 8 个小时，期间积压了几万条消息，恢复后直接冲垮了数据库。加看门狗之后，类似问题最多影响一个批次。
5.4 问题速查表
| 现象 | 可能原因 | 处理办法 |
|---|---|---|
| 某个店铺抓不到订单 | token 失效 / 店铺授权过期 | 检查授权状态，人工刷新后重跑 |
| 同一订单重复入库 | 接口重试导致脏数据 | 用 platform + order_id + shop_id 做唯一约束 |
| 工作流一直 running | 外部接口慢 / 数据量大 | 增加超时时间或分批处理，设置看门狗 |
| Agent 传错参数 | Skill 描述不清晰 | 补全 description，增加参数约束 |
| 平台触发风控 | 请求频率过高 | 拉大间隔，启用限流，使用官方接口 |
| 金额字段为负数 | 退款订单被当成普通订单 | 增加状态校验，拦截退款单 |
6. 一点个人体会和后续扩展
6.1 我的实际感受
整套方案跑下来，我最直观的感受是：自动化最值钱的部分不是代码本身，而是把原来需要人工记忆的业务规则变成了可维护的配置和流程。以前新员工入职要花一周熟悉各个平台后台，现在只要看工作流日志和异常队列就能理解整套订单处理逻辑。Agent Skills 真正的价值是让规则显性化，让系统的每一步都可解释、可追溯。
当然，这套方案也不是万能的。平台接口频繁变动时，维护 Skill 仍然需要成本；Agent 模型偶尔的“自作主张”也需要靠规则约束。我的态度是：既不要迷信 Agent 能解决一切，也不要因为它有缺点就放弃。把能用脚本固化的事情固化成脚本，把需要灵活决策的事情交给 Agent，两者结合才是正路。
6.2 后续还能往哪些方向扩展
订单抓取只是多平台自动化的一个入口。同样的架构完全可以扩展出去：售后工单自动分类和回复、商品信息批量同步、库存多仓联动、平台对账差异分析、客服话术智能推荐。你只需要把新场景里的操作拆成 Skill，再挂到 WorkBuddy 工作流里，Agent 就能帮你处理大部分重复性的流程环节。
我下一步的计划是接着做“多平台售后异常检测”。逻辑和订单抓取类似，但数据源换成了售后单和退款单，判断规则更复杂一些。等这套跑稳定之后，再来写一篇更详细的实战复盘。
