MTurk停止运营后，众包任务如何迁移与替代？

Amazon Mechanical Turk简称 MTurk的停止运营公告对整个依赖众包任务的团队来说是一次必须认真对待的变更。MTurk 是亚马逊 2005 年推出的众包平台本质上是把机器做不好的小任务拆解出来交给真人用户在线完成。很多团队用它在短期内完成数据标注、内容审核、问卷回收、图片分类等工作也有团队已经通过 MTurk API 把任务发布、结果回收、账务结算全部自动化。按公告给出的时间点平台将在 9 月 30 日停止运营请求方、开发者、工人三类角色都需要在此之前完成各自的收尾动作。本文围绕这条时间线先讲清楚 MTurk 的任务模型再给出账号核对、数据导出、结算退出、API 迁移和排错的完整操作路径。1. 先理解 MTurk 的任务模型才知道关闭后哪些环节会断1.1 三类角色和一条任务链路MTurk 的核心参与者有三类请求方Requester、工人Worker和平台本身。请求方是发布任务的一方通常是需要大量人力处理数据的企业或开发者工人是在平台上认领并完成任务的人平台负责任务展示、结果收集、支付结算和质量规则执行。一条完整的任务链路是这样的请求方创建 HITHuman Intelligence Task人类智能任务并设置报酬平台把 HIT 展示给符合条件的工人工人认领后提交结果这条提交记录称为 Assignment请求方审核通过后平台从请求方账户扣款支付给工人同时平台按比例抽成。这个模型里任务发布、结果提交、审核、支付是环环相扣的任何一环断掉整个闭环都无法继续。下面是 MTurk 里最常用到的一组术语后面理解 API 和迁移时会反复用到术语含义对应说明HIT人类智能任务一次可发布的独立任务单元包含标题、描述、报酬、有效期Assignment任务提交记录一个工人对某个 HIT 提交的一份结果Reward任务报酬工人完成一个 Assignment 后获得的金额LifetimeInSecondsHIT 生命周期从发布到过期的时间窗口AssignmentDurationInSeconds单次答题时限工人认领后必须在时限内提交MaxAssignments最多提交数量一个 HIT 最多接收多少份提交AutoApprovalDelayInSeconds自动审核延迟到期后未人工审核则自动通过的时间Qualification工人资格条件用于限定哪些工人可以认领任务1.2 从 API 角度看关闭影响的是完整闭环很多团队不只是打开网页发布任务而是通过 MTurk API 把任务系统接入自己的业务。常见做法是服务端用 boto3 或 AWS SDK 调用create_hit创建任务通过list_assignments_for_hit拉取提交结果再调用approve_assignment或reject_assignment完成审核最后依赖 SNS 通知处理结果回调。一旦平台停止运营这些 API 都会失效。不是网页打不开的问题而是代码里的调用会报错、定时任务会失败、通知回调会中断。更隐蔽的是账户余额、待审核 Assignment、未导出的历史结果一旦错过处理时间可能无法通过程序化方式取回。所以不要把这次关闭当成“换一个前端页面”要从代码、数据、资金三条线分别排查。1.3 对三类人群的影响差异虽然所有人都会受到影响但处理优先级完全不同。角色最需要处理的事项处理截止时间请求方业务负责人停止发布新任务、审核存量提交、结算余额、导出数据9 月 30 日前开发者迁移 API 调用、修改回调链路、清理硬编码地址和密钥至少提前一周完成工人完成已认领任务、确认收款、保留收入记录平台关闭前一个常见的误区是先让开发改代码业务侧却还在发布任务。实际上应该先冻结新任务发布再做代码迁移最后处理数据存档。顺序反了会出现“代码已经切走但账户里还压着一批未审核任务”的局面。2. 停止运营前先确认账号、任务和历史数据现状2.1 先登录控制台确认账号和权限状态第一步不是写代码而是进入 Requester 控制台或 AWS 控制台确认账号状态。需要检查四类信息账号是否处于可用状态是否存在欠费或冻结。当前账户余额和未结算金额。IAM 用户下是否有 MTurk 相关权限策略比如iam:ListPolicies、mturk:CreateHIT等。访问密钥是否仍然有效是否散落在代码、配置中心或 CI 变量中。如果团队多人共用一套密钥建议在迁移期间重新梳理一次权限避免关闭后密钥仍暴露在外部系统里。这一步的目的是先知道自己账户里有什么、能用什么再决定怎么退出。2.2 导出 HIT 元数据和工人提交结果从 MTurk 能导出的核心数据分为两类HIT 元数据和 Assignment 提交内容。HIT 元数据包含标题、描述、报酬、创建时间、有效期Assignment 提交内容才是真正的业务结果比如标注结果、问卷答案、分类标签。很多团队只导出了 HIT 元数据却忘了拉取 Assignment结果迁移后手里只剩任务清单没有答案数据。下面这段 Python 代码用 boto3 遍历账号下的 HIT并拉取每个 HIT 的 Assignment是迁移前导出数据的最小可用脚本。import boto3 import json client boto3.client( mturk, region_nameus-east-1, aws_access_key_idYOUR_ACCESS_KEY, aws_secret_access_keyYOUR_SECRET_KEY, ) def list_all_hits(max_results100): hits [] next_token None while True: kwargs {MaxResults: max_results} if next_token: kwargs[NextToken] next_token resp client.list_hits(**kwargs) hits.extend(resp.get(HITs, [])) next_token resp.get(NextToken) if not next_token: break return hits def list_assignments(hit_id): assignments [] next_token None while True: kwargs { HITId: hit_id, AssignmentStatuses: [Submitted, Approved, Rejected], } if next_token: kwargs[NextToken] next_token resp client.list_assignments_for_hit(**kwargs) assignments.extend(resp.get(Assignments, [])) next_token resp.get(NextToken) if not next_token: break return assignments def dump_all(output_pathmturk_export.json): result [] for hit in list_all_hits(): hit_id hit[HITId] assignments list_assignments(hit_id) result.append({ HITId: hit_id, HITTitle: hit.get(Title), HITStatus: hit.get(HITStatus), CreatedAt: str(hit.get(CreationTime)), Assignments: assignments, }) with open(output_path, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2) print(fexported {len(result)} hits to {output_path}) if __name__ __main__: dump_all()这段代码有三个关键点。第一list_assignments_for_hit必须显式传入AssignmentStatuses否则可能只返回部分状态的结果导致审核过的数据丢失。第二建议分页遍历时保存NextToken避免单次调用超过接口上限导致数据不全。第三导出文件最好同时保存时间字段和状态字段方便迁移后和新系统对账。2.3 核对余额、账单和税务信息导出数据之后要核对资金相关记录。MTurk 的资金账户是预付费模式请求方需要先充值工人完成后平台从中扣款支付。平台关闭前余额可能有两种去向已经生成但未审核的任务会继续扣款未消费的余额需要走退款流程。具体退款规则要以 AWS 官方通知和账号账单为准不要根据传闻判断。建议在控制台的支付和账单页面导出最近六个月的回款记录、扣款记录、平台佣金和税务文件至少保留一份汇总表。核对口径包含总充值金额、总支付金额、平台费用、当前余额、未审核任务预计扣款。核对完后把结果发给财务或业务负责人确认避免关闭后才发现账单对不上。2.4 梳理业务链路中的 MTurk 依赖数据核对只是现状盘点的一部分。更关键的是代码链路盘点。在项目仓库里搜索以下关键词能快速找出所有对 MTurk 的依赖点mturk、boto3、MTurkcreate_hit、list_hits、get_hitlist_assignments_for_hit、approve_assignment、reject_assignmentmturk-requester、sandboxSNS 通知处理函数、回调接口搜索后把所有调用点整理成一张表字段包括所在服务、文件路径、调用方法、使用场景、是否有替代方案。这张表既是迁移工作量评估依据也是后续测试的覆盖清单。3. 作为请求方9 月 30 日前的有序退出流程3.1 停止新任务发布给存量任务留出处理时间停止运营前最容易被忽略的是新任务发布。团队习惯性继续发任务直到平台关闭前最后一刻才发现还有大量 HIT 没有过期而工人已经无法提交。建议把“停止发布新任务”的日期定在 9 月 30 日之前至少一周。这周时间用于处理存量的 Submitted、Approved、Rejected 状态任务。先冻结业务侧的任务创建入口无论从哪个系统进入都不再调用 MTurk 发布接口。对已经发布但还没到期的 HIT可以主动调用update_expiration_for_hit缩短有效期或直接等待其自然过期。不要让存量任务跨越关闭时间点否则可能出现“工人提交了但请求方无法审核”的空白期。3.2 处理提交和审核中的任务存量任务里最麻烦的是状态为 Submitted 和 Reviewable 的 Assignment。Submitted 代表工人已提交但请求方还没审核Reviewable 代表这个 HIT 有可审核的提交。审核时需要调用approve_assignment或reject_assignment。这里要注意一旦平台关闭审核接口不可用这些任务就无法完成支付闭环。因此要设定一个内部截止时间例如 9 月 25 日前完成所有审核。审核逻辑建议走一次全量脚本按 HIT 遍历所有 Submitted 状态 Assignment输出审核结果清单供人工确认后批量执行。批量审核脚本的模式是def bulk_approve(hit_id, approve_ids): for assignment_id in approve_ids: client.approve_assignment( AssignmentIdassignment_id, RequesterFeedbackapproved, )审核完成后把每个 HIT 的最终状态、每个 Assignment 的审核结果、打款金额写入本地数据库或 CSV 文件。这一步是后续对账和纠纷处理的基础。3.3 结算、退款和账务核对审核完成后资金会进入平台结算流程。请求方需要确认三件事所有 Approved Assignment 都能正常触发支付。未消费的平台余额是否符合退款条件。平台佣金、税务凭证是否已经下载。不要把眼光只放在业务数据上。如果余额退还需要人工申请表建议在退出流程的早期就发起申请因为审核处理时间不在自己控制范围内。退款到账后再关闭 AWS 侧的支付委托。整个过程保留截图和邮件记录至少保留到平台正式关闭后三个月方便财务审计。3.4 把业务记录归档下来最后一步是做归档。归档不是简单存一份 JSON而是包含HIT 元数据、Assignment 内容、审核记录、打款记录的完整导出。任务批次与业务订单的对应关系。导出时间、导出人、数据版本说明。平台沟通邮件和公告截图。归档文件建议放在带版本管理的对象存储或数据仓库中文件命名带上日期和批次号。这样即使新平台上线后数据格式不同也能通过映射关系回溯历史任务。4. 作为开发者如何从 MTurk API 迁移到替代方案4.1 先审计现有代码的调用点迁移的第一件事是审计而不是直接改代码。建议把上一轮搜索出的调用点按优先级排序阻塞型调用任务发布、结果拉取、审核接口停用后业务立即中断。非阻塞型调用数据统计、报表导出停用后可以复用本地数据。外部集成SNS 回调、通知推送、监控告警停用后需要切换消息通道。排序后先处理阻塞型调用再处理外部集成最后处理统计类逻辑。审计阶段还要确认代码里是否硬编码了 MTurk 的地址。生产环境常见的是https://mturk-requester.us-east-1.amazonaws.com沙箱地址则是另一个域名。如果代码里直接写死这些地址迁移时要一并替换成新平台的接口地址。4.2 替代方案怎么选MTurk 停用后替代方案大致分三类。方案类型代表方式优点限制AWS 生态内服务SageMaker Ground Truth与 AWS 服务集成方便适合大规模标注需要重新学习配置任务模型和 MTurk 不同专业众包平台Appen、Scale AI、Toloka 等国际平台或京东众智、百度众测等国内服务运营成熟质量控制机制完善接口、结算、定价规则各不相同需要逐一评估自建众包系统内部发布任务、按角色分配、人工或算法审核完全可控数据不出域开发维护成本高冷启动需要积累工人池选型要看业务量和数据敏感度。如果任务量小、数据敏感度高自建系统更合适如果任务量大、需要稳定工人供给专业众包平台更合适如果本身就重度使用 AWS 生态可以优先评估 SageMaker Ground Truth。不要只看报价要比较接口稳定性、结算周期、审核机制、数据保留策略和对审查流程的支持。4.3 用统一的 TaskProvider 接口隔离底层平台无论选哪条路代码层都建议抽象出一层统一的 TaskProvider 接口。这样把 MTurk 相关逻辑收拢到一个类里迁移时只改实现类业务代码不用大面积变动。迁移前的代码通常是直接调用 boto3def create_hit_on_mturk(client, title, description, reward, duration, lifetime, max_assignments, question_xml): return client.create_hit( Titletitle, Descriptiondescription, Rewardreward, AssignmentDurationInSecondsduration, LifetimeInSecondslifetime, MaxAssignmentsmax_assignments, Questionquestion_xml, )迁移后可以把任务创建逻辑抽象成接口class TaskProvider: def create_task(self, payload: dict) - str: raise NotImplementedError def get_submissions(self, task_id: str) - list: raise NotImplementedError def close_task(self, task_id: str) - None: raise NotImplementedError class NewPlatformProvider(TaskProvider): def __init__(self, api_url: str, token: str): self.api_url api_url self.token token def create_task(self, payload: dict) - str: resp requests.post( f{self.api_url}/tasks, jsonpayload, headers{Authorization: fBearer {self.token}}, timeout30, ) resp.raise_for_status() return resp.json()[task_id] def get_submissions(self, task_id: str) - list: resp requests.get( f{self.api_url}/tasks/{task_id}/submissions, headers{Authorization: fBearer {self.token}}, timeout30, ) resp.raise_for_status() return resp.json()[submissions] def close_task(self, task_id: str) - None: requests.post( f{self.api_url}/tasks/{task_id}/close, headers{Authorization: fBearer {self.token}}, timeout30, )这个设计的好处是业务方只依赖TaskProvider接口不依赖任何具体平台。迁移那天把入口处的TaskProvider实例从 MTurkProvider 换成 NewPlatformProvider 即可。接口定义要按自己业务的最小需求设计不要照搬 MTurk 的完整 API 面减少不必要的适配工作量。4.4 数据结构差异和回调改造MTurk 的数据结构和大多数新平台差异明显。MTurk 用 HITId、AssignmentId、WorkerId 关联数据提交内容通常是一段 XML Answer新平台通常用 task_id、submission_id、user_id提交内容多为 JSON 结构。迁移时要做两层映射。第一层是标识映射。数据库里如果存了 HITId 和 AssignmentId迁移后要么保留旧字段作为扩展字段要么建立 task_id 与旧 HITId 的映射表。第二层是内容映射。MTurk 的 Answer XML 需要解析成结构化字段例如把FreeTextcat/FreeText解析成{label: cat}。建议写一个解析函数把历史数据统一转换成新平台的数据模型后续统计和分析才不会断层。回调链路也要改造。MTurk 通常通过 SNS 通知请求方有新提交新平台通常提供 Webhook。改造时要注意签名校验和重试机制避免回调丢失。5. 常见问题和排查路径5.1 报错HIT 不再可用或任务队列满现象调用create_hit时返回Service Fault或提示任务创建失败旧任务链接打开后提示已过期。可能原因停止运营前平台已经开始限制新任务创建或任务有效期确实已经结束。检查方式先看控制台是否还能创建 HIT再看代码调用的环境是生产还是沙箱最后看报错中的错误码和请求 ID。处理建议若平台已限制创建立即切换到新平台若只是有效期结束重新发布并设置更长LifetimeInSeconds。排查时注意区分“平台关闭导致失败”和“任务过期导致失败”不要盲目重试。5.2 工人提交了结果但拉取不到 Assignment现象list_assignments_for_hit返回结果为空或只返回部分结果。可能原因调用时未指定完整AssignmentStatuses分页没有翻完整或数据实际上未从平台同步下来。检查方式在控制台手动打开该 HIT确认 Assignment 是否存在再确认代码的NextToken循环是否正常。处理建议一次性把所有状态全部拉下来并同时导出提交时间、提交内容和审核状态。若控制台和 API 结果不一致以控制台为准并截图留证。5.3 余额未退回或退款状态不明确现象平台关闭后账户仍显示余额退款没有到账。可能原因退款流程需要人工申请或还有未审核 Assignment 未处理资金被继续锁定。检查方式查看账单页面是否生成退款项检查是否有 Submitted/Reviewable 任务阻塞结算。处理建议提前完成审核尽早提交退款申请。申请后保留申请编号超过约定时间未到账再联系客服处理。5.4 代码里残留硬编码的 MTurk 地址现象切到新平台后某个服务仍在调用旧接口日志出现connection refused或UnknownHostException。可能原因代码里硬编码了 MTurk 端点或配置中心里没有覆盖到所有环境变量。检查方式全局搜索mturk、requester.amazonturk等关键字检查 CI/CD 中的环境变量和密钥文件。处理建议把所有外部服务地址抽到配置中心或环境变量里禁止在代码中写死。迁移完成后在 CI 中加入关键字扫描防止旧地址重新出现。5.5 历史数据格式无法解析现象导出数据后业务系统读不到旧的 Answer XML。可能原因旧数据是 XML 结构新系统只支持 JSON或字段命名不一致。检查方式抽样检查导出 JSON 文件中的 Answer 字段确认解析规则是否覆盖全部格式。处理建议写一个兼容解析层把 XML Answer 统一转为 JSON。解析时不要丢失原始字段可以在转换结果中保留raw_answer字段用于排查。6. 迁移后的工程架构建议6.1 任务幂等和重试新平台上线后第一类要解决的问题是任务不重复。发布任务时请求方可能因为网络超时重试导致同一批任务被创建多次。建议在任务创建接口里增加幂等键用业务订单号或唯一批次号作为idempotency_key。新平台如果支持幂等直接使用如果不支持在调用前先查询是否已存在相同批次。结果回调查回调也可能重复。接收 Webhook 时建议按 submission_id 做去重处理逻辑里先查询再插入避免重复写库。6.2 质量控制和数据安全众包平台的质量控制不能只依赖平台本身。迁移后建议采用组合策略设置黄金题Golden Task用已知答案的题目穿插在真实任务里评估工人准确率。设置最小工龄或历史通过率门槛限制低质量工人进入。对关键任务设置复审机制抽检比例按任务风险动态调整。数据安全方面工人的隐私字段、标注原文、审核结果都要加密存储。对外接口必须使用 HTTPS敏感接口增加签名和访问令牌。生产环境还要保留访问日志记录谁在什么时间读取了哪些任务数据。6.3 生产环境还要补齐的运维能力迁移完成后不能只验证主流程。生产环境还需要补齐以下能力监控任务创建失败率、提交回传延迟、Webhook 失败数、支付异常数。告警指标超过阈值时接入钉钉、企业微信、邮件等通知。日志统一输出结构化日志包含 task_id、submission_id、调用方、错误码和耗时。回滚新平台出现严重问题时能快速切换回备用通道或暂停任务发布。备份任务批次、提交结果、审核记录定期备份到独立存储。这些内容看起来是通用要求但在众包场景里尤其重要因为任务数据量大、人工参与多一旦出错很难像普通接口那样快速重放。7. 最佳实践和可复用清单7.1 9 月 30 日前退出清单事项负责角色完成状态冻结所有新 HIT 发布入口业务负责人导出全部 HIT 元数据和 Assignment 结果开发者审核所有 Submitted/Reviewable Assignment业务负责人核对余额、账单和税务文件财务/业务负责人申请未消费余额退款财务搜索代码中所有 MTurk 调用点并关闭旧密钥开发者完成替代平台选型和接口联调开发者、业务负责人归档导出文件、审核记录、公告截图开发者向团队同步新平台使用说明业务负责人这张表建议直接打印出来每周核对一次。退出越早完成越不容易被临近关闭的排队处理耽误。7.2 替代平台选型清单选型时逐项确认这些信息是否支持 API 创建任务和拉取结果。是否支持 Webhook 或消息通知。结算周期和手续费怎么计算。工人池规模和质量筛选机制。是否支持自定义任务页面和审批流。数据保留策略和删除能力。客服响应速度和 SLA 保证。费用是否与当前业务量匹配。把这三个方面结合评估任务模型匹配度、业务接入成本、运营维护成本。不要只看单次报价要看全链路成本。7.3 迁移后的后续维护平台关闭后的三个月内还需要持续做三件事每天检查旧历史数据的读取是否正常确认退款和税务文件全部到位更新内部文档删除所有关于 MTurk API 的过期示例替换为新平台的接入说明。对团队来说这次迁移也是一次不错的工程复盘。把调用日志、迁移决策、踩过的坑写成文档后续再遇到第三方平台变更就能直接套用这套流程。众包任务本身不会消失关键是把任务发布、结果回收、质量审核、资金结算这些能力从单一平台解耦出来让业务不再被某一个平台锁死。