跨平台功能开发编排器：基于 multi-platform-apps 插件的三阶段多 Agent 工作流实战指南

跨平台功能开发编排器基于 multi-platform-apps 插件的三阶段多 Agent 工作流实战指南【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents导读本文剖析 GitHub 推荐项目精选 / agents24 / agents 仓库中multi-platform-apps插件提供的一等公民能力——multi-platform斜杠命令。它是一个面向一次设计、多端交付的跨平台功能开发编排器以 API-first 为纲先在架构与 API 契约层对齐再并行推进 Web、iOS、Android、桌面端实现最后完成文档、测试与优化闭环。读完本文你将掌握该命令的完整执行协议3 个阶段、7 个步骤、2 个强制检查点、.multi-platform/状态机工作机制、每个步骤调用的 Agent 职责以及如何将该工作流接入 Claude Code / Codex / Cursor / OpenCode 等多 harness 环境。一、命令定位与使用方式1.1 命令在插件体系中的位置multi-platform命令位于 plugins/multi-platform-apps/commands/multi-platform.md是该插件唯一的命令文件。它与插件目录下的 6 个专业 Agent 协同工作Agent 文件角色在多平台工作流中的职责backend-architect.md后端架构师Phase 1 Step 1API 契约与共享数据模型设计ui-ux-designer.mdUI/UX 设计师Phase 1 Step 2跨平台设计系统与组件规范frontend-developer.md前端工程师Phase 2 Step 4a/4dWeb 与桌面端实现ios-developer.mdiOS 工程师Phase 2 Step 4bSwiftUI 原生实现mobile-developer.md移动端工程师Phase 2 Step 4cKotlin/Compose 实现flutter-expert.mdFlutter 专家可选的统一代码库评估方案按仓库 docs/usage.md 的说明插件安装后斜杠命令以/plugin-name:command-name [arguments]的命名空间形式调用/multi-platform-apps:multi-platform被归类在Development Features命令参考中。1.2 参数签名命令 frontmatter 给出了完整的参数提示argument-hint: feature description [--platforms web,ios,android,desktop] [--shared-code evaluate|kotlin-multiplatform|typescript]三个组成部分feature description功能描述即$ARGUMENTS中位于 flags 之前的部分全文统称$FEATURE--platforms目标平台列表默认web,ios,androiddesktop为可选追加平台--shared-code共享代码策略可选evaluate评估、kotlin-multiplatform、typescript默认evaluate。典型调用示例/multi-platform-apps:multi-platform real-time order tracking --platforms web,ios,android,desktop --shared-code kotlin-multiplatform1.3 输出目录约定整个工作流的全部产物统一落在运行目录下的.multi-platform/文件夹中编号即执行顺序.multi-platform/ ├── 01-api-contracts.md # Step 1 API 契约 ├── 02-design-system.md # Step 2 设计系统 ├── 03-shared-architecture.md# Step 3 共享业务逻辑架构 ├── 04a-web.md # Step 4a Web 实现 ├── 04b-ios.md # Step 4b iOS 实现按需 ├── 04c-android.md # Step 4c Android 实现按需 ├── 04d-desktop.md # Step 4d 桌面端实现按需 ├── 05-api-docs.md # Step 5 API 文档与测试 ├── 06-testing.md # Step 6 跨平台一致性测试 ├── 07-optimizations.md # Step 7 平台级优化 └── state.json # 会话状态机这一设计背后是文件即记忆的原则每个步骤必须先落盘再进入下一步后续步骤从文件读取前序产物而不是依赖上下文窗口记忆——保证了长流程中信息不丢失也支持中途断电后恢复。二、不可违反的行为铁律命令开篇以 CRITICAL BEHAVIORAL RULES 明示 6 条硬性规则任何违反都视为执行失败严格按顺序执行不得跳过、重排或合并步骤先写文件再继续每一步必须在.multi-platform/下产出对应文件后才能进入下一步且只能从先前步骤的文件读取信息在检查点强制停下到达PHASE CHECKPOINT时必须用 AskUserQuestion 工具给出清晰选项并等待用户明确批准失败即停机任一步骤失败Agent 报错、测试失败、依赖缺失必须立即停止向用户展示错误并询问处理方式不得静默继续仅使用本地 Agent所有subagent_type只引用本插件内置 Agent 或general-purpose不允许跨插件依赖禁止自主进入 Plan 模式不得调用 EnterPlanMode——这条命令本身就是计划直接执行。这 6 条规则把可控性提到了与完成度同等的高度本质是把一次不可逆的大规模开发拆解为可审查、可回滚、可恢复的确定性流水线。三、Pre-flight Checks会话恢复与状态初始化3.1 已有会话检查执行前先检查.multi-platform/state.json是否存在存在且status: in_progress读取状态展示当前步骤向用户二选一Found an in-progress multi-platform development session: Feature: [name from state] Current step: [step from state] 1. Resume from where we left off 2. Start fresh (archives existing session)存在且status: complete询问是否归档后重新开始。这一机制让中断的工作流具备真正的可恢复性——所有进度都持久化在state.json而非模型上下文。3.2 状态机初始化创建.multi-platform/目录与state.json初始模板如下{ feature: $ARGUMENTS, status: in_progress, platforms: [web, ios, android], shared_code: evaluate, current_step: 1, current_phase: 1, completed_steps: [], files_created: [], started_at: ISO_TIMESTAMP, last_updated: ISO_TIMESTAMP }随后解析$ARGUMENTS中的--platforms与--shared-code两个 flag未指定时使用上述默认值并从$ARGUMENTS中提取 flag 之前的文本作为$FEATURE。状态机的字段演进规律每个步骤完成后current_step递增Step 3 完成后置为checkpoint-1Step 4 完成后置为checkpoint-2已完成的步骤号追加进completed_steps全部完成后status置为complete并刷新last_updated。checkpoint-*字符串值实际上充当了等待人工批准的暂停标志。四、Phase 1架构与 API 设计Steps 1–3串行Phase 1 的定位是先对齐再动手用一份 API 契约、一份设计系统、一份共享架构文档锁定三端或多端实现的事实基础。Step 1功能需求与 API 契约调用 Task 工具启动multi-platform-apps-backend-architect对应 backend-architect.md产出 OpenAPI 3.1 规范要求覆盖使用正确 HTTP 方法与状态码的 RESTful 端点复杂数据查询场景下的 GraphQL schema实时功能所需的 WebSocket 事件带校验规则的请求/响应 schema认证与授权要求限流rate limiting与缓存策略错误响应格式与错误码。同时要求定义所有平台共同消费的共享数据模型交付物包括完整 API 规范、共享数据模型、认证流程设计、各平台集成指南。从 backend-architect.md 的源码可见该 Agent 的能力矩阵横跨 REST/GraphQL/gRPC/WebSocket/SSE/Webhook、API 版本化与分页策略、契约测试Pact 等、SDK 生成其核心行为特征是contract-first清晰定义接口边界从第一天就内建熔断、重试、超时等韧性模式——与 Step 1 的要求完全吻合。产出保存为.multi-platform/01-api-contracts.md随后更新state.jsoncurrent_step置 2Step 1 加入completed_steps。Step 2设计系统与 UI/UX 一致性读取01-api-contracts.md调用ui-ux-designer对应 ui-ux-designer.md要求交付跨平台设计系统各平台组件规范Material Design、iOS HIG、FluentWeb 响应式布局移动优先iOS 原生模式SwiftUI与 Android 原生模式Material You桌面端专项考量键盘快捷键、窗口管理可访问性要求WCAG 2.2 Level AA深色/浅色主题规范动画与转场指南。从 Agent 源码看ui-ux-designer.md 具备原子设计方法论、design token 管理、Figma Variables/Style Dictionary、多品牌设计系统治理等能力其行为特征是系统性、可扩展的设计方案而非一次性设计并用研究与测试数据验证设计决策。注意该 Agent 的 frontmatter 指定了model: sonnet属于模型分层中的 Tier 3文档、测试、调试类任务——详见仓库 ARCHITECTURE.md 的模型分层表。产出保存为.multi-platform/02-design-system.md。Step 3共享业务逻辑架构同时读取01-api-contracts.md与02-design-system.md调用general-purposeAgent 完成共享代码架构设计需定义核心领域模型与实体平台无关业务规则与校验逻辑状态管理模式MVI/Redux/BLoC缓存与离线策略错误处理与重试策略平台特定适配器模式。同时要求考虑共享方案选型移动端用 Kotlin MultiplatformWeb/桌面用 TypeScript。交付物为共享代码架构文档、平台抽象层设计、状态管理策略、离线/缓存方案与实施指南。产出保存为.multi-platform/03-shared-architecture.mdcurrent_step置为checkpoint-1。五、PHASE CHECKPOINT 1首次人工审查此处必须强制停下向用户展示三份文档的核心要点关键 API 端点、设计系统组件、共享逻辑方案并给出三选一Architecture and API design complete. Please review: - .multi-platform/01-api-contracts.md - .multi-platform/02-design-system.md - .multi-platform/03-shared-architecture.md 1. Approve — proceed to platform implementation 2. Request changes — tell me what to adjust 3. Pause — save progress and stop here只有用户选择选项 1 才能进入 Phase 2选 2 则修订后重新走检查点选 3 则更新state.json状态并停止。这是架构先行理念的人机闭环——在投入并行开发之前先用人类判断锁死方向。六、Phase 2并行平台实现Steps 4a–4d先读取 Phase 1 的三份产物随后仅针对state.json中列出的平台用多个 Task 调用并行发起实现任务。Step 4aWeb 实现React/Next.js调用multi-platform-apps-frontend-developer技术栈约定React 18 与 Next.js 14 App RouterTypeScript 类型安全TanStack Query 做 API 集成Zustand/Redux Toolkit 状态管理Tailwind CSS 配合设计系统 tokensPWA 能力按需 SSR/SSG 优化Web Vitals 优化LCP 2.5s、FID 100ms。对应 Agent frontend-developer.md 的能力覆盖 React 19、Next.js 15、RSC、Server Actions、ISR、Core Web Vitals 与无障碍实现其行为特征是用户体验与性能同等优先从设计阶段就考虑可访问性。产出存为.multi-platform/04a-web.md。Step 4biOS 实现SwiftUI调用ios-developer约定SwiftUI iOS 17 特性Swift 5.9 与 async/awaitURLSession Combine 集成 APICore Data/SwiftData 持久化平台特性Face ID、Haptics、Live Activities可测试的 MVVM 架构。对应 Agent ios-developer.md 覆盖 Swift 6、SwiftUI 5、UIKit 互操作、Core Data/CloudKit、App Store 合规与 ASO行为特征是严格遵循 Apple HIG编译期安全优先。产出存为.multi-platform/04b-ios.md。Step 4cAndroid 实现Kotlin/Compose调用multi-platform-apps-mobile-developer约定Jetpack Compose Material 3Kotlin coroutines 与 FlowRetrofit/Ktor 集成 APIRoom 本地数据库Hilt 依赖注入Material You 动态主题平台特性生物认证、widgetsClean Architecture MVI。对应 Agent mobile-developer.md 的能力覆盖 React Native / Flutter / 原生多路线Step 4c 中它扮演的是 Android 原生专家角色。产出存为.multi-platform/04c-android.md。Step 4d桌面端实现可选Electron/Tauri仅当desktop出现在 platforms 列表时执行仍调用multi-platform-apps-frontend-developer要求 Tauri 2.0 或 Electron并注入 Web 实现产物以最大化复用同时补充原生 OS 集成系统托盘、通知按需文件系统访问自动更新代码签名与公证配置键盘快捷键与菜单栏多窗口支持。产出存为.multi-platform/04d-desktop.md。全部平台任务完成后current_step置为checkpoint-2。值得留意的是仓库还内置了 flutter-expert.md 这一统一代码库方案专家Flutter 3.x 覆盖移动/Web/桌面/嵌入式支持 Material 3 与 Cupertino 双设计系统当--shared-code评估结论偏向单代码库策略时它是 Step 3 架构选型的自然备选。七、PHASE CHECKPOINT 2二次人工审查展示全部平台实现摘要再次给出批准/变更/暂停三选一未批准不得进入 Phase 3Platform implementations complete. Please review: - .multi-platform/04a-web.md - .multi-platform/04b-ios.md (if applicable) - .multi-platform/04c-android.md (if applicable) - .multi-platform/04d-desktop.md (if applicable) 1. Approve — proceed to integration and validation 2. Request changes — tell me what to adjust 3. Pause — save progress and stop here八、Phase 3集成与验证Steps 5–7Step 5API 文档与测试读取01-api-contracts.md与全部04*.md调用general-purpose技术写作专家产出交互式 OpenAPI/Swagger 文档各平台集成指南各平台 SDK 示例认证流程图示限流与配额信息错误处理最佳实践API 版本化策略。并要求用平台实现实测全部端点。产出存为.multi-platform/05-api-docs.md。Step 6跨平台测试与功能一致性读取全部04*.md与05-api-docs.md调用general-purposeQA 工程师验证功能测试矩阵各平台行为一致UI 一致性核验遵循设计系统各平台性能基准可访问性测试平台专用工具网络韧性测试离线、弱网数据同步校验平台特定边界场景端到端用户旅程测试。交付功能一致性矩阵、各平台测试结果、性能基准、发现的平台偏差与修复建议存为.multi-platform/06-testing.md。Step 7平台专项优化读取06-testing.md与全部04*.md调用general-purpose性能工程师按平台逐项优化Web包体积、懒加载、CDN、SEOiOSApp 体积、启动时间、内存、电量AndroidAPK 体积、启动时间、帧率、电量Desktop二进制体积、资源占用、启动时间API响应时间、缓存、压缩。要求在维持功能一致性的前提下发挥平台优势并记录优化技术与取舍。产出存为.multi-platform/07-optimizations.mdcurrent_step置为complete。九、完成与验收标准最后将state.json的status置为complete并刷新last_updated呈现最终摘要。命令内置的 Success Criteria 可作为团队验收清单API 契约在实现前已定义并验证所有平台达成功能一致差异 5%性能指标满足各平台标准可访问性达标WCAG 2.2 AA 为最低要求跨平台测试显示行为一致所有平台文档完整适用场景下平台间代码复用率 40%。后续动作建议逐平台审查生成的代码与文档 → 运行平台专用测试套件 → 按平台创建 PR → 用平台专用流水线部署 → 上线后监控跨平台指标。十、设计原理与最佳实践总结10.1 与仓库架构规范的呼应从 ARCHITECTURE.md 可以确认本命令遵循仓库的两条核心约定一是插件为安装单元命令/Agent/技能随插件整体安装/plugin install multi-platform-apps后即可使用二是源内容可移植命令文件以纯 Markdown 编写由tools/adapters/下的适配器在生成期映射到各 harness 的原生格式如 Codex 的 TOML、OpenCode 的 command 目录、Copilot 的 commands-as-skills、Antigravity 的插件格式因此本文描述的工作流在多个 harness 中均可运行只是调用语法随平台略有差异。10.2 可借鉴的三条工程实践文件即状态用state.json 编号 markdown 产物替代上下文记忆使长流程可恢复、可审计、可中断续跑人机检查点两个强制 PHASE CHECKPOINT 把大规模并行开发拆成架构批准 → 实现批准 → 集成验证三个可逆阶段把返工成本前置到最低点契约先行 并行收敛先锁定 API 契约与设计系统再并行实现多端最后用一致性矩阵与性能优化收口——这正是跨平台交付减少返工、提高复用的关键路径。10.3 使用前提与限制本命令依赖插件内置的 6 个 Agent 与general-purpose需保证所在 harness 支持 Task/subagent 机制产物目录.multi-platform/为运行时生成命令本身不修改仓库内容生成的代码与文档由用户决定如何提交--platforms中列出的平台会决定 4a–4d 的执行分支--shared-code的三种取值会影响 Step 3 的架构选型方向建议在调用前明确两者。相关文件速查命令定义 multi-platform.md Agent 组 backend-architect.md、ui-ux-designer.md、frontend-developer.md、ios-developer.md、mobile-developer.md、flutter-expert.md 使用手册 docs/usage.md 架构规范 ARCHITECTURE.md【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考