MTurk 停运倒计时：众包任务迁移与 API 集成全指南

Amazon Mechanical Turk 将于 9 月 30 日停止运营。这不是一次普通的功能调整，而是整个众包平台下线。对长期使用众包做数据标注、问卷回收、内容审核、图片分类的团队来说，这个消息意味着两件事：第一，存量任务必须在关闭日期前全部收口；第二，原本依赖 MTurk API 的外部系统，需要重新评估迁移成本。

我处理过不少平台停服和接口废弃的迁移，最重要的经验是：先不要急着找替代平台，先把账号、数据、任务、代码和权限全部盘一遍。很多团队以为关停只是“在控制台点一点”，实际上一旦 API endpoint 和结果存储停掉，任务、结果、奖励记录都可能在短时间内无法访问。下面按我建议的实际迁移顺序拆开写，尽量把容易被忽略的细节补上。

1. 关停影响面：谁最该在本月完成动作

1.1 MTurk 在众包生态里扮演什么角色

Amazon Mechanical Turk 是一个众包微任务市场。发布方可以创建 HIT，也就是人类智能任务，把图片标注、文本分类、视频片段审核、问卷填写、语音转写校验这类机器难以稳定处理的小任务分发给大量在线工人。工人完成一个任务单元，发布方审核通过后支付报酬。

它本质上是一种“人在回路”的基础设施。很多机器学习团队把它接入数据管道，用来给模型训练提供人工标准答案；也有很多运营团队把它当成内容审核的临时人工池。相比自建人工团队，它最大的优势是弹性大，可以在短时间内把任务拆成几千个小单元并行完成。这也意味着，一旦平台关闭，整个任务队列、结果回传、奖励结算链路都会受影响。

1.2 三类受影响角色：发布方、工人、开发者

受影响最大的不是偶尔发任务的个人，而是以下三类角色。

第一类是任务发布方。他们的管理后台里可能还有未审核的 HIT、未发放的奖励、未导出的结果。如果关闭前没有处理完，这些任务就会变成“临期资产”，越到最后越难清理。

第二类是工人。对长期在 MTurk 上接任务的人来说，平台关闭意味着收入渠道中断，需要重新找替代众包平台或转做其他工作。这部分更多是个人选择问题，但从任务发布方角度看，需要提前通知工人停止接单，避免产生纠纷。

第三类是开发者与集成方。很多团队不是直接打开 MTurk 控制台发任务，而是通过 API 把任务提交、结果拉取、状态通知包装成内部工具。平台关闭后，这些代码里的 endpoint、密钥、数据结构、回调逻辑全部失效。这类影响往往藏得最深，因为表面看起来只是账号无法登录，实际上是整个数据通道断了。

1.3 先从任务生命周期清单开始排查

我一般会在平台关闭通知发出后，先做一个任务生命周期盘点。不要一上来就写迁移代码，先回答几个问题：当前线上还有多少任务正在等待工人领取？有多少任务已经提交但还没有审核？有多少批次已经审核完成但结果没有下载？有多少奖励已经发放但流水没有保存？

把这些问题整理成表格，按任务类型、批次号、创建时间、状态、结果数量、支付金额列清楚。之后再做导出和迁移，心里就有底了。相反，如果先选替代平台，很容易出现旧数据还没导出，新平台已经上线的混乱局面。

提醒：平台关闭前的最后一周，控制台响应速度、客服响应时间都可能变差。不要把所有清理工作压到最后几天。

2. 关闭日期前，先处理这五类存量资产

2.1 存量任务与 HIT 生命周期

先检查所有 HIT 的状态。MTurk 里的任务会有几个典型状态：可领取、进行中、已提交、已审核、已拒绝、已过期。关闭后，这些状态可能无法继续流转。

处理方案比较简单：已经提交的任务尽快审核，能通过的就通过，不能通过的依据规则拒绝并填写理由。还没有人领取或者已经过期的任务，如果不再需要，可以直接取消或等待过期。若任务涉及外部依赖，比如需要根据工人结果再触发下一步流程，最好把结果全部落库，避免关闭后回调失败。

这里要特别留意“正在进行的任务”。有些工人已经领取任务但还没提交，关闭后这批任务可能无法再被提交，也不要强行要求工人到其他渠道交答案。最好的做法是提前公布截止时间，在最后一天前结束所有进行中的任务。

2.2 工人数据、审核记录与敏感信息

历史任务数据是这次迁移中最容易漏掉的部分。包括 Worker ID、工人提交的答案、审核状态、审核意见、奖励金额、任务时间戳、IP 或设备信息（如果有采集）、申诉记录等。

导出时不能只看网页，因为网页通常只能看到部分数据。如果有 API 调用记录，最好从 API 拉全量数据。拉取时注意分页限制和时间范围，不要用小页码循环，要用游标或按时间分段导出。导出后放到公司本地文件服务器或数据库，并做一次行数校验，确保结果数量与后台数字一致。

如果任务结果里包含个人身份信息或业务敏感信息，导出后要加密存储，并按已有数据安全规范处理。众包任务经常涉及图片、文本、语音，这些内容可能已经共享给众包工人，关闭平台后要确认历史数据是否仍被第三方存储，必要时联系平台服务商确认删除策略。不过网络上的规则描述未必准确，具体以平台官方说明为准。

2.3 余额结算、奖励发放和税务凭证

MTurk 账户里可能有两种钱：一种是预充值的任务预算，一种是待发放的工人奖励。关闭之前，要把待发放奖励处理掉。奖励拖欠时间越长，越容易引发投诉和争议。

结算顺序建议是：

1. 先导出所有已审核但未发放奖励的任务列表。
2. 按批次核对奖励金额，标注哪些已经支付、哪些还没支付。
3. 在平台关闭前完成所有应发奖励的支付。
4. 将支付流水、税务凭证、结算记录保存到本地。

如果账户还有余额，处理方式以平台官方的结算规则为准。不同账号状态、不同地区、不同支付渠道，最终结果可能不一样。不要轻信网上的“一定能退回”的说法，建议直接看控制台和通知邮件。

2.4 API 密钥、回调和外部系统依赖

这一步是开发者最容易忽略的。MTurk 不只是网页控制台，很多团队通过 AWS SDK 调用它。关闭后，旧的 API endpoint 会不可用，所有依赖都会报错。

建议梳理以下内容：

• 代码目录中有哪些地方包含mturk、mechanicalturk、HIT、Assignment等关键词。
• 哪些环境变量或配置文件里保存了 AWS Access Key 和 Secret Key。
• 哪些定时任务会创建 HIT 或拉取结果。
• 哪些服务通过 SNS 或回调接收任务完成通知。
• 沙盒环境和线上环境是否混用。

把这些调用点整理成一个清单后，再决定是替换 SDK，还是把这一块逻辑改成新平台接口，或者直接从 API 切换成内部人工审核流程。不要直接删除旧代码，先保存一个迁移前的副本，万一后期还要查历史数据，还能对照看。

2.5 内部文档和团队权限收口

最后是文档和权限。团队里可能有多个人有 MTurk 操作权限，平台关闭前，要把创建新任务的权限收拢到少数负责人手里，防止有人继续发布任务但没人负责后续处理。

同时更新内部流程文档，把 MTurk 相关章节标记为“即将废弃”，把新的替代流程写清楚。如果公司有数据字典或系统架构图，也要删除或注释掉 MTurk 的模块。这样后续新同学查文档时，不会被旧的调用方式误导。

3. 迁移到新方案：不要复制任务，先拆分场景

3.1 任务类型的四种典型场景

不同众包任务的底层需求差别很大。迁移时如果只是把旧任务的文字描述复制到新平台，大概率会出问题。

数据标注类任务，比如图片分类、文本实体识别、语音转写校验，需要关注任务难度、标注一致性、多人交叉验证和质检规则。你需要的不是一个简单的任务发布页面，而是一套能管理标注团队和审核标准的系统。

问卷调研类任务，比如用户偏好、满意度调查、行为习惯测试，通常有配额控制、防重复提交、数据清洗和样本有效性判断。这类任务更看重问卷设计能力，而不是“工人是否足够多”。

内容审核类任务，比如评论、帖子、视频片段是否违规，需要更完整的审核流程、审计日志和权限控制。数据敏感程度高，不建议直接放到完全公开的众包池里。

人工复核类任务，比如模型输出校验、搜索结果相关性判断、订单信息确认，重点在于结果格式、回调速度和失败重试。任务越短，越需要低延迟的信息反馈机制。

3.2 替代方案：托管众包平台、自建任务台、混合模式

选替代方案时，不要只看平台名称。要考虑任务类型、数据位置、支付方式、团队开发能力和合规要求。

托管众包平台仍然是最快的方式。市面上有 Amazon SageMaker Ground Truth、Toloka、Clickworker、Microworkers 等。每个平台的计费方式、任务模板、工人池规模、结果格式都不一样。我建议把候选平台列成一个对比表，重点看是否支持 API、是否支持自定义任务模板、是否支持结果回调、是否支持抽检和拒绝、是否有沙盒环境。

自建任务台适合长期稳定且数据敏感的团队。你可以用简单的内部页面把任务拆成列表，分给内部员工或固定外包团队，结果直接写入数据库。好处是数据不经过第三方，坏处是需要自己处理账号、任务分配、催办、审核和统计。如果任务量不大，自建成本可能比平台费用便宜；如果任务量大，自建系统反而会成为负担。

混合模式是更稳妥的选择。常规、低敏感、大规模任务走托管众包平台；敏感数据和核心验收任务走内部人工团队；固定且规则清晰的任务训练模型自动处理。这样迁移风险更分散。

3.3 迁移顺序：先小批次验证再放大

不要试图在一天之内把所有任务切换到新平台。正确做法是选一个任务类型，先用 20 到 50 条小样本跑通全流程。

小样验证要覆盖以下环节：

• 数据上传是否顺畅。
• 任务是否能够正常展示给工人。
• 工人提交结果后是否能够自动回到系统。
• 审核和拒绝流程是否可用。
• 导出格式是否满足下游系统要求。
• 奖励支付是否能批量完成。

我建议先定一个“成功标准”，比如提交率 90% 以上，抽检准确率 95% 以上，结果回调成功率 100%。如果小样验证没有达标，先找原因，不要急着放大批量。平台关闭前的迁移窗口通常不长，小样验证能帮你尽早暴露问题。

4. 开发者视角：API 集成迁移要拆开看

4.1 先找 API 调用点

如果你之前的系统不是通过网页手动发布任务，而是通过代码调用 MTurk API，迁移时最怕的是只换了账号，没有换接口。

先在代码仓库里搜索mturk、mechanicalturk、create_hit、list_assignments这些关键词，找到所有调用点。再查看日志，确认哪些服务在定时拉取结果，哪些服务依赖回调。最后画一张简单的调用关系图：谁创建任务、谁查询结果、谁发通知、谁做审核。

下面是一个迁移前的调用示意，不代表完整代码：

# 迁移前示意：通过 boto3 调用 MTurk 创建任务 # 实际项目中需要根据你的密钥和参数调整 import boto3 client = boto3.client( "mturk", region_name="us-east-1", aws_access_key_id="YOUR_ACCESS_KEY", aws_secret_access_key="YOUR_SECRET_KEY" ) response = client.create_hit( Title="判断图片中是否包含车辆", Description="根据给定图片做二分类判断", Reward="0.10", AssignmentDurationInSeconds=600, LifetimeInSeconds=86400, Question="<QuestionForm>...</QuestionForm>" ) print(response["HIT"]["HITId"])

这段代码在 MTurk 关闭后无法继续使用。迁移时要么替换成新平台的 SDK，要么改成调用内部接口。重点不是复制代码，而是梳理出“创建任务、获取结果、状态同步”三个核心动作。

4.2 任务结构：从 HIT 到新平台任务对象的映射

MTurk 的任务结构有一套自己的术语。迁移到新平台时，要做一个字段映射表。不同平台叫法不一样，但核心概念基本一致。

映射表至少要在小样验证前做出来。否则新平台的结果格式和旧解析脚本不兼容，拉回来一堆无用 JSON，还得重新清洗。

4.3 回调、幂等与失败重试

MTurk 时代，任务完成后通常靠 API 轮询或者 SNS 通知来感知。新平台不一定支持相同的回调方式，需要提前确认。

更关键的是结果入库的幂等性。同一个任务结果可能因为网络重试、平台重发、手动补拉而多次进入系统。如果没有幂等保护，数据库中会出现重复记录，后续统计直接失真。

我习惯把任务状态机定义清楚：创建、进行中、已提交、已审核、已完成、已拒绝。每次从外部接口拿到结果，都要先根据业务 ID 判断是否已经存在，再决定插入还是更新。失败重试同样重要，众包任务经常有超时、拒绝、退回，不能因为单个失败就中断整个批次。重试要有次数上限，并用指数退避代替死循环。

4.4 权限与数据合规

迁移到新平台，不只是技术问题，还要重新审视数据权限。

如果任务数据包含个人姓名、手机号、邮箱、身份证号、内部业务数据，就不适合直接公开到任意众包平台。即便新平台有隐私协议，你也要确认数据存储地、访问权限、外包工人可见范围。对于敏感数据，更合理的方案是自建一个小型任务台，或者先对数据做脱敏，再把脱敏后的样本发给工人。

权限方面，要遵循最小可用原则。给开发人员只开测试环境权限，给运营人员只开任务管理权限，减少误操作。平台关闭后，旧密钥要尽快在 AWS 控制台删除或轮换，避免已离职员工仍然留有访问权。

5. 迁移后的质量与成本控制

5.1 先用小样本来验收

迁移完成后，我建议不要立即把全部生产流量切到新平台。先用小样验证，然后逐步放大。

小样验证时，可以把同一批数据同时发给旧任务留存数据和新平台，跑完后对比结果分布。重点关注提交率、准确率、平均耗时、单条成本和结果格式一致性。

如果新平台的结果格式与旧平台不同，不要慌。写个清洗脚本把字段标准化，但脚本要单独测试，不要直接覆盖正式数据。任何一次清洗动作，尽量保留原始结果，方便追溯。

5.2 质量控制：审核规则、抽检比例和申诉通道

一个众包平台能不能用，不是看“能不能发布任务”，而是看“能不能保证结果质量”。我在迁移时通常会给新平台加三道质检：

第一道是提交校验。结果为空、格式错误、答案不在枚举值范围内的任务，直接标记为无效，不进入正式库。

第二道是抽检。按批次随机抽 5% 到 10% 的任务，由内部人员重新判断，比对一致性。如果一致率低于 90%，就需要调整任务说明或增加示例。

第三道是低质量工人限制。如果某个工人提交的任务连续多次不合格，冻结其后续接单资格。众包平台的“人多”并不等于“质量好”，没有控制策略，结果可能比机器批量生成还难用。

5.3 成本预期：平台费用、开发成本、人工审核成本

迁移后的成本不能只看任务奖励单价，还要算五笔账：

• 任务奖励：发给工人的钱。
• 平台手续费：托管平台通常按比例抽成。
• 开发迁移成本：改造代码、字段映射、清洗脚本、测试调试。
• 人工审核成本：抽检、复核、处理争议的时间。
• 失败重做成本：任务说明不清导致提交无效，重发需要再花钱。

我建议在迁移前把候选方案的总成本估算出来，给出一个上浮空间。如果新平台比旧平台贵 10%，但能省掉很多审核时间，整体未必更贵。反过来，如果单价便宜但结果不可用，补做成本会很高。

5.4 时间线：什么时候切流量最稳

MTurk 9 月 30 日关闭，我建议倒排时间节点，而不是等最后一周再动。

第一周，盘点存量任务和结果，停止所有可发可不发的新任务。第二周，确定替代方案，选择一个小任务跑通端到端流程。第三周，做字段映射、API 接入、回调测试和权限配置。第四周，小批量上线，开始抽检，记录指标。最后几天，停止旧平台 API 调用，保存日志，关闭权限。

如果业务不能中断，可以采用双跑模式：同一批任务在旧平台和新平台各跑一遍，但只入一套数据。这样切换时如果新平台有问题，还能用旧平台数据顶上。双跑成本更高，却是最稳妥的过渡方式。

6. 常见问题与排查顺序

6.1 存量任务突然打不开

后台打不开时，先确认是不是账号环境错误或登录过期。部分地区或网络环境切换会影响控制台访问，可以换回原来的登录环境再试。如果排除了环境问题，再看任务是否已经超过平台允许的操作时间。关闭之后无法通过界面访问时，只能依赖关闭前导出的备份数据。

这个问题的唯一解法是提前备份。不要等后台完全不可用再去截图和复制，接口和界面都可能有访问限制。

6.2 API 返回权限错误或资源不存在

迁移过程中，API 报错不一定都是旧接口关闭导致。先看错误码和请求日志，确认是否因为 AK/SK 过期、权限策略变更、endpoint region 写错或沙盒与正式环境混用。

如果确认旧接口已经不可用，那就不要再纠结调试，直接切换新平台的接口。调试新接口时遇到权限错误，优先检查新平台 API 密钥是否开通了对应权限，而不是反复测试同一段代码。

6.3 奖励和付款没到账

奖励没有到账，先确认是否在平台结算截止时间之前发起支付。然后检查账户余额和付款渠道，看是余额不足、收款账号错误还是批次号填错。

新平台如果出现付款失败，不要重复点击发送，先看订单记录中的状态码。重复支付会造成数据混乱，后面更难处理。所有付款动作都要有日志，至少要记录批次号、任务 ID、金额、时间、状态。

6.4 新平台结果格式不一致

新平台返回的字段和旧平台不同，这是正常情况。不要直接拿旧解析脚本硬套，先导出一条样例，看字段类型和层级。

我的处理步骤是：先建立字段映射表，再写清洗脚本，然后用 10 条左右样本验证脚本输出，最后才跑全量。清洗脚本中要增加异常兜底：遇到空值、重复值、未知枚举，直接落到异常队列，不阻塞主流程。

6.5 迁移期间要不要停新任务

最稳妥的做法是先冻结旧平台新任务，避免产生无法结算的“孤儿任务”。确认存量数据和审核已经收口后，再在新平台小量开启。

如果业务完全不能停，双跑模式是唯一推荐方案。但双跑也需要控制并发，不要一上来就开最大并发，先把一条任务跑完，确认新平台能接收到结果，再逐步增加任务量。这里最容易踩的坑是任务源系统重复提交，导致同一份数据被跑两次，成本翻倍。

迁移平台这件事，技术难度不一定高，但很考验对业务链路的熟悉程度。真正决定项目成败的不是换了哪个众包平台，而是任务定义、结果字段、质量校验和失败重试是否在新的环境里重新跑通。我个人更建议先把存量任务、奖励结算和 API 调用点梳理清楚，再动迁移。这样即使遇到突发情况，至少手里有完整数据，不会手忙脚乱。