成为赞助商——支持中文 Agent 生态
了解赞助团队平台工程；披露 21 仓雪花服务、四工程师、单层约十仓/人/日、十二层全跑流水线；强调 mutation 边界与 implement/validate 成对，跨仓关联仍靠人。
面向多服务基础设施迁栈不能「一句 migrate」的平台团队：把「分层工作流 + 读写边界 + 并行会话报告」写成门禁，区别于产品迁移动真靠 setup 与并行票据编排。
Serhii Vasylenko 在 devDosvid《Harness Engineering: Layers Made It Universal》（JSON-LD datePublished 2026-04-07 → 2026-04-07）写明：21 个雪花服务的 ECS→EKS 收官波，既不能指望一条万能脚本，也不能对代理说「migrate this service」——后者会产出 21 套漂移实现，比什么都不做更糟。
他们把 harness（有序提示流水线+mutation 边界+校验）当作主交付物，用 Claude Agent SDK 包装并行仓会话，让四工程师按层推进（约十仓/人/日量级目标），十二层跑完同一套机械。提示进共享仓像生产代码一样评审扩散。作者强调 implement/validate 成对是最高杠杆，且跨仓关联仍留在人侧。
本场景据此输出「多服务迁移 harness」提纲。禁止把「四而非四十」写成任意组织编制承诺，或跳过校验层直接批量合 MR。
你是平台迁栈顾问。只根据用户约束写 harness，不要编造已完成的仓数或人天。
仓/服务列表：{{repos}}
迁移层：{{layers}}
并行度与人审点：{{parallelism}}
输出 Markdown：
1. 每层编号步骤（标 READ ONLY / MAKES CHANGES / PLANNING ONLY）
2. 脚本确定性步骤 vs AI 发现步骤切分
3. implement 与 validate 成对工作流
4. 并行 worktree 报告字段与禁止合入条件
禁止建议「一句 migrate this service」；禁止伪造「四工程师万能」。流水线报告全绿但预发失败，或两仓同层改法互相矛盾。请写复盘提纲。
现象：{{symptom}}
输出：
1. 缺 validate 配对、缺跨仓关联，还是 mutation 边界被打破
2. 最小修补
3. 下次验收标准
4. 人工确认清单
不要伪造「更多并行会话等于更少回归」。