Agent Skills多平台实战：从订单抓取到技能复用

直接说结论：Agent Skills 这套玩法，真正跑通之后，最值钱的地方不是“让 AI 会个技能”，而是把这套技能拆成一个个标准化模块，扔到多个平台去复用。我见过太多人把精力耗在某个平台的单一自动化上，结果换一个平台、换一套系统，之前写的所有东西都要推翻重来。这篇文章就围绕“Agent Skills 多平台应用实战”这条主线，讲讲我在这套体系里怎么设计技能、怎么落地到跨境电商抓单、怎么配合 workbuddy 这类自动化工作流去跑，以及 link-os 这类多平台系统接入时踩过的坑和解决思路。

先说清楚一个概念：Agent Skills 不是某个具体的软件，也不是一套固定的代码，它更像是给 AI 智能体“装配技能”的方法论。你可以把它理解成机器人的外挂工具箱——每个技能解决一类特定问题，比如“识别图片中的订单号”“自动提取网页表格数据”“理解异常退款的原因分类”等等。而这个工具箱最大的优势在于“换平台不换技能”，只要你把技能模块做得足够标准和抽象，今天套在 Shopee 上能用，明天搬到 Lazada、Amazon 上照样能用，只需要改外层的数据接口或触发条件就行。我们这次实战，就是把这套思路完整走了一遍。

1. Agent Skills 在多平台场景下的核心思路与价值

1.1 为什么多平台场景最容易翻车

做跨境电商的朋友应该都有过这种经历：同一个店铺的订单，可能同时在 Shopee、Lazada、TikTok Shop 甚至独立站上都挂着。你可以打开每个平台的后台手动看一遍，但几个店铺并行，人根本盯不过来。于是很多团队会想到“搞自动化”，但自己为什么要做自动化、自动化到底要解决什么核心问题，往往没想清楚就直接上手了。结果就是不同的平台各写一套脚本，维护成本成倍上升，平台一改版就集体失效。

我个人的经验是，多平台场景最怕“为自动化而自动化”。如果你只是把某个平台的人工操作机械替换成脚本，那充其量是给自己找了一个新的麻烦。真正合理的做法是：先把所有平台的业务对象抽象出来。比如订单，不管哪个平台，订单的共性字段无非就是订单号、买家信息、商品明细、金额、收货地址、发货状态。先把这些共性抓出来，做成一套通用的订单数据模型，再针对不同平台差异化的细节做适配处理。

这套思路落地下来，管理成本立刻从“维护三套脚本”降为“维护一套核心模型 + 三份适配配置”。我在这次项目里就是把订单模型和抓取策略做成独立技能模块，这样每次接新平台时，只需要处理接口差异和页面结构差异，业务逻辑完全不用动。这也是为什么 Agent Skills 在多平台场景里这么好用的根本原因——它逼着你把技能从“数据源”中解耦出来。

1.2 技能模块的拆解思路

把 Agent Skills 落地的第一步，永远是设计技能目录。我这次的技能目录分了三层：基础技能、组合技能、业务技能。基础技能是最底层的能力单元，比如“网页内容提取”“API 数据拉取”“表格解析”“图片 OCR”；组合技能则是将基础技能按业务逻辑串联起来，比如“订单信息识别”=“网页内容提取 + 表格解析 + 异常校验”；业务技能是最上层直接面对用户的，比如“多平台订单同步抓取”“异常订单自动标记”。

这里有一个很容易被忽略的细节：基础技能必须保证“无状态”，也就是说同样一个输入，在任何时候、任何平台调用它，它都应该输出同样的结果。这点非常重要，因为多平台场景下，数据是频繁流转的，如果基础技能本身还带着平台特性，那组合技能在面对不同平台时，可能会出现各种奇奇怪怪的隐性 bug。比如提取网页上的订单号，不能写死“从第二个表格的第三列提取”，因为不同平台的页面布局完全不同，而是要交给模型去理解表格的语义，让技能自己定位到“订单号”所在的位置。只有做到这一点，同一个技能才能在不同平台上自由复用。

那怎么保证这个语义理解能力足够稳定呢？实测下来有几个关键点。第一，技能提示词的引导词尽量写得抽象，只描述任务目标，不描述具体平台特征；第二，输入数据的预处理很重要，HTML 转成纯文本、JSON 做字段清洗，减少干扰信息；第三，输出格式必须强约束，比如要求返回 JSON，必须包含 order_id、customer_name、total_amount 等固定字段，缺字段就报错重试。这三点做好了，技能的跨平台复用率会大幅提升。

2. 跨境电商多平台订单抓取实战

2.1 workbuddy 工作流搭建的底层逻辑

这次实战里，我们用了 workbuddy 来搭自动化工作流。有人可能会问，为什么不用 Python 直接写爬虫？答案很简单：需求变化太快，人工维护成本太高。电商平台的后台页面结构经常动，今天登录弹窗换了个位置，明天订单列表多了个筛选项，这些变化写死在代码里，你就得跟着改代码。但是用 workbuddy 这类 RPA（机器人流程自动化）工具，很多页面变化可以通过界面上的可视化配置快速调整，效率高不少。而且，非技术人员也能参与修改流程，团队协作的门槛会低很多。

workbuddy 的工作流本质上还是一套“触发器-动作-分支-结束”的流程模型，和我们平时写程序逻辑很像，只不过它把每一步封装成可视化的节点。我们这次搭的主流程是这样的：定时触发抓单任务 → 逐个登录电商平台后台 → 提取当天新增订单 → 对订单进行标准化清洗和转换 → 把结果同步到本地数据库或通知系统 → 异常情况触发人工告警。

这个流程看起来挺简单，真正动手做才发现问题不少。最大的坑在于“登录”这一步。很多平台后台都有验证码或者多因素认证，直接走自动化登录很不稳定。我们最终采用的方式是：首次认证用人工扫码登录的方式，把登录态缓存下来（比如保存 Cookie 或 Session），后续自动运行时优先使用缓存的登录态。这个方案能覆盖 80% 以上的场景，如果登录态失效，就触发通知让运营人员手动处理一次。用这种方式，稳定性提高了很多，但也要注意，各大平台对自动登录一般都有风险控制策略，所以实际使用时建议控制抓取频率，模拟人工操作的节奏，不要高频强制登录。

2.2 订单抓取的数据结构设计与流转

订单数据抓下来之后，怎么处理才是真正的分水岭。前面提到要抽出一个通用的订单数据模型，那具体这个模型长什么样？我们在这次实战中设计了这么一套核心字段结构：

• order_id：平台原始订单号，保留原格式，便于回查
• platform：来源平台标识，如 shopee、lazada、tiktok
• status：订单状态，统一映射为待付款、待发货、已发货、已完成、已取消五个标准状态
• customer_name：买家姓名
• items：商品明细列表，每个商品包含 sku_id、名称、数量、单价
• total_amount：订单总金额，统一换算为基础货币，并记录原始币种字段
• shipping_address：收货地址的标准化文本
• created_time：订单创建时间，统一转换成 ISO 8601 格式

这里有一个特别容易被忽视的点：每个平台返回的时间格式、币种、地址格式都不一样。Shopee 的时间可能是 “2024-05-01 14:30:00”，Lazada 可能是 “May 1, 2024 2:30 PM”，如果这些字段不先做标准化处理，后面做财务报表或库存同步一定会出问题。我们专门为这些差异写了一个清洗转换层，在数据进入核心系统之前完成统一格式化。这也是为什么我们要用 Agent（而不是简单脚本）来处理的主要原因：只有上下文理解能力足够强的人工智能模型，才能同时应对这么多格式差异并给出准确的转换结果。

清洗完数据之后，工作流接下来一步就是要把数据送到目的地。有的业务场景需要同步到 ERP 系统，有的只需要发到企业微信或钉钉群里提醒运营。我们这次采用了可配置的“输出插件”模式，每个输出渠道写成一个独立的技能插件，默认支持数据库写入、Webhook 通知、邮件发送、Excel 导出。要接新渠道就写个新插件，核心链路不需要改动。工作流变得灵活之后，后面添加新平台、新业务线都只是时间问题，不再需要推倒重来。

3. 核心技能模块的调优与系统接入

3.1 link-os 类多平台系统接入的适配策略

现在多平台系统越来越多，link-os 这类系统在市面上也火了一阵子。它们提供了一个统一入口去管理多个账户和多个平台，好处是不用频繁切换后台，坏处是接入配置稍微有点复杂。我们在这次项目里也接入了一个类似的系统，把前面 workbuddy 抓到的数据同步过去，形成一套“抓取+聚合管理”的闭环。

link-os 这类系统接进来之后，最大的收益在于数据的统一视图，你可以把不同平台的订单放在同一张列表里做筛选、分析、汇总，做运营决策舒服多了。但接入过程也没那么轻松。这类系统往往有自己的 API 规范和字段命名习惯，和前面我们定义的标准订单模型经常对不上。比如系统里可能叫 “order_number”，我们叫 “order_id”；系统里可能把状态拆成多级子状态，我们只映射成 5 个大类。这种情况下，必须写一层字段映射层，把我们的标准模型转换成系统能识别的结构。我建议直接在这层做“应用适配器”，采用适配器设计模式，让每个外部系统都有一个独立的转换类，互相不干扰。

另外一个细节是关于重复数据处理的。多平台系统接入后，同一个订单可能会从不同渠道重复流入（比如通过 API 拉取一次，又通过文件导入一次），如果不做幂等处理，数据库里迟早会充满重复订单。我们在这一层加了基于 order_id + platform 的唯一索引，每次写入前先检查。不要小看这一步，少了它，后面做任何统计都会发现数据对不上，排查成本非常高。

3.2 提示词工程与技能调优的具体经验

Agent Skills 的底层能力依赖大语言模型的理解和生成能力，所以提示词的质量直接决定了技能表现的上限。这次实战中，我反复调优了每个技能模块的提示词，总结下来有三条经验值得分享。

第一条是“先拆后合”。不要试图写一个大而全的提示词让模型完成所有任务，而是把任务拆成多个小而精的技能步骤，逐步执行。比如“提取订单信息”这个任务，我先让它定位表格区域，再让它提取每一列的字段名，再让它按标准格式输出结果。拆开之后，每步的诊断和改进都清晰很多，出现问题时也能快速定位是哪个环节出了问题。

第二条是“少给规则，多给案例”。比起告诉模型“订单金额是数字类型，必须是两位小数”，不如直接给几个“输入-输出”的例子更有用。模型在看例子的时候能自动总结出格式规律，我们只需要在例子里覆盖正常订单、含折扣订单、退款订单等几种典型情况即可。这个方法在处理地址清洗、金额格式化时效果立竿见影。

第三条是“输出必须强约束”。我在每次调用 Agent 的提示词后面都加了一句“请严格输出 JSON 格式，不要输出多余文字”，并且在代码层面对输出做 JSON 解析校验，解析失败就自动重试一次，重试仍失败才告警。这个小机制看起来简单，却避免了大量因为模型偶尔“话痨”导致的解析错误。在多平台场景里，这种细节决定自动化流程到底能不能真正无人值守地跑下去。

除了提示词层面的调优，还需要注意几个工程层面的细节。一个是超时控制。不同平台的响应速度差异极大，有的需要 5 秒，有的可能 30 秒还没返回，所以我给每个技能模块设置了独立的超时时间和重试策略。另一个是并发控制。多个平台抓单任务同时触发时，如果不限制并发数，极易触发平台风控，所以我们用信号量把同时运行的技能数控制在 3 个以内。再有就是日志数据，每个技能执行的关键步骤要打日志，记录输入摘要、处理结果、耗时、报错原因，形成完整的可追踪轨迹，出了问题才能快速定位。这些工程细节往往比模型选型更能决定项目的成败。

4. 常见问题与排查技巧实录

4.1 订单数据丢失或重复的排查方法

在跑了一段时间多平台抓单之后，最常遇到的就是数据“丢了”或者“重了”。先说丢数据的问题。丢数据往往是以下几个原因造成的：一是抓取时页面还没加载完，导致部分订单没有被提取到；二是登录态失效，订单列表没有刷新出最新数据；三是网络超时导致请求中断。排查逻辑建议从前到后：先查工作流日志有没有报错，再确认登录态是否有效，再看网络请求是否正常。实测中，登录态失效是最常见的原因，最好的办法是加一个“前置检查”节点，每次正式抓取之前先探测登录态，如果失效就提前告警，让运营人员处理。

重复数据的排查则相对简单，直接查数据库里 order_id + platform 的组合是否唯一即可。如果发现有重复，优先检查工作流是否被重复触发了。workbuddy 这类工具有时候会因为调度器重启或跨时区配置失误导致重复运行。我们当时就吃过这个亏，因为服务器时区没有配置正确，每天的定时任务多跑了一次，跑重复的任务把已经同步过的订单又重新同步了一遍。后面在调度器上加了个简单的锁标记，问题就解决了。

4.2 平台改版导致的抓取失效与应对

前面说，网页结构变化是 RPA 工作流最大的敌人。平台前端时不时调整一次样式，表格的 class 名变了、按钮的位置换了，甚至登录框变成了新的交互方式，都可能导致流程中断。应对这个问题的核心思路是：尽量让技能“依赖语义而不是依赖结构”。什么意思呢？不要让技能去精确匹配某个 DOM 元素的位置，而是让技能通过识别文本内容或业务含义来定位目标元素，普通用户盯后台时看的是“订单号”这三个字，而智能化处理机制同样也是通过语义识别来定位这三个字对应的内容，而不依赖它在 HTML 里的层级位置。这么做的好处是，即使页面局部样式变了，只要文案不变，技能依然能找到目标。

当然，像登录界面这种改动特别大的场景，语义定位也可能失效。我们的兜底方案是“分级响应”：如果登录步骤连续失败 3 次，工作流停止并通知人工处理，而不是无限重试。同时保留一套人工操作入口，让运营可以快速手动介入。这个兜底方案在实际运行中非常重要，因为它保证了即使整个流程掉链子，核心业务也不会被卡死太久。

4.3 常见问题速查表

这里把我在实战中遇到的高频问题整理成一张速查表，方便遇到类似情况时快速定位：

这张表看着简单，但每一条背后都对应着一次真实的事故处理经验。我第一次遇到“抓取结果为空”时，就开始无脑重试，结果越试越乱。后面养成“先看日志、再看登录态、最后看页面结构”的顺序之后，排查效率提升了很多。

5. 实战心得与后续扩展的方向

这次从零搭建 Agent Skills 多平台订单抓取体系，前后大概用了三周时间。从最初的单平台测试，到后面扩展至多个平台并行，再到接入统一管理平台，整个过程踩了不少坑，但也沉淀出了一套可复用的方案。核心收获在于：把技能模块化、平台适配层独立化、数据模型标准化，这三件事做到位，多平台自动化的维护成本会大幅下降。

后面我还计划把异常退款识别、客服消息分类这类场景也做成独立的 Agent Skills 模块，接到现有的工作流里。每次新加技能时，仍然沿用“基础技能-组合技能-业务技能”三层结构，这样整个体系会越来越强壮。如果你也在做类似的多平台自动化，我的建议是不要一上来就追求大而全，先拿一个平台把整条链路跑通，再逐步扩展。等核心链路稳定了，后面加平台就是顺水推舟的事。