跨平臺功能開發(fā)編排器基于 multi-platform-apps 插件的三階段多 Agent 工作流實戰(zhàn)指南【免費下載鏈接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity項目地址: https://gitcode.com/GitHub_Trending/agents24/agents導(dǎo)讀本文剖析 GitHub 推薦項目精選 / agents24 / agents 倉庫中multi-platform-apps插件提供的一等公民能力——multi-platform斜杠命令。它是一個面向一次設(shè)計、多端交付的跨平臺功能開發(fā)編排器以 API-first 為綱先在架構(gòu)與 API 契約層對齊再并行推進(jìn) Web、iOS、Android、桌面端實現(xiàn)最后完成文檔、測試與優(yōu)化閉環(huán)。讀完本文你將掌握該命令的完整執(zhí)行協(xié)議3 個階段、7 個步驟、2 個強(qiáng)制檢查點、.multi-platform/狀態(tài)機(jī)工作機(jī)制、每個步驟調(diào)用的 Agent 職責(zé)以及如何將該工作流接入 Claude Code / Codex / Cursor / OpenCode 等多 harness 環(huán)境。一、命令定位與使用方式1.1 命令在插件體系中的位置multi-platform命令位于 plugins/multi-platform-apps/commands/multi-platform.md是該插件唯一的命令文件。它與插件目錄下的 6 個專業(yè) Agent 協(xié)同工作Agent 文件角色在多平臺工作流中的職責(zé)backend-architect.md后端架構(gòu)師Phase 1 Step 1API 契約與共享數(shù)據(jù)模型設(shè)計ui-ux-designer.mdUI/UX 設(shè)計師Phase 1 Step 2跨平臺設(shè)計系統(tǒng)與組件規(guī)范frontend-developer.md前端工程師Phase 2 Step 4a/4dWeb 與桌面端實現(xiàn)ios-developer.mdiOS 工程師Phase 2 Step 4bSwiftUI 原生實現(xiàn)mobile-developer.md移動端工程師Phase 2 Step 4cKotlin/Compose 實現(xiàn)flutter-expert.mdFlutter 專家可選的統(tǒng)一代碼庫評估方案按倉庫 docs/usage.md 的說明插件安裝后斜杠命令以/plugin-name:command-name [arguments]的命名空間形式調(diào)用/multi-platform-apps:multi-platform被歸類在Development Features命令參考中。1.2 參數(shù)簽名命令 frontmatter 給出了完整的參數(shù)提示argument-hint: feature description [--platforms web,ios,android,desktop] [--shared-code evaluate|kotlin-multiplatform|typescript]三個組成部分feature description功能描述即$ARGUMENTS中位于 flags 之前的部分全文統(tǒng)稱$FEATURE--platforms目標(biāo)平臺列表默認(rèn)web,ios,androiddesktop為可選追加平臺--shared-code共享代碼策略可選evaluate評估、kotlin-multiplatform、typescript默認(rèn)evaluate。典型調(diào)用示例/multi-platform-apps:multi-platform real-time order tracking --platforms web,ios,android,desktop --shared-code kotlin-multiplatform1.3 輸出目錄約定整個工作流的全部產(chǎn)物統(tǒng)一落在運行目錄下的.multi-platform/文件夾中編號即執(zhí)行順序.multi-platform/ ├── 01-api-contracts.md # Step 1 API 契約 ├── 02-design-system.md # Step 2 設(shè)計系統(tǒng) ├── 03-shared-architecture.md# Step 3 共享業(yè)務(wù)邏輯架構(gòu) ├── 04a-web.md # Step 4a Web 實現(xiàn) ├── 04b-ios.md # Step 4b iOS 實現(xiàn)按需 ├── 04c-android.md # Step 4c Android 實現(xiàn)按需 ├── 04d-desktop.md # Step 4d 桌面端實現(xiàn)按需 ├── 05-api-docs.md # Step 5 API 文檔與測試 ├── 06-testing.md # Step 6 跨平臺一致性測試 ├── 07-optimizations.md # Step 7 平臺級優(yōu)化 └── state.json # 會話狀態(tài)機(jī)這一設(shè)計背后是文件即記憶的原則每個步驟必須先落盤再進(jìn)入下一步后續(xù)步驟從文件讀取前序產(chǎn)物而不是依賴上下文窗口記憶——保證了長流程中信息不丟失也支持中途斷電后恢復(fù)。二、不可違反的行為鐵律命令開篇以 CRITICAL BEHAVIORAL RULES 明示 6 條硬性規(guī)則任何違反都視為執(zhí)行失敗嚴(yán)格按順序執(zhí)行不得跳過、重排或合并步驟先寫文件再繼續(xù)每一步必須在.multi-platform/下產(chǎn)出對應(yīng)文件后才能進(jìn)入下一步且只能從先前步驟的文件讀取信息在檢查點強(qiáng)制停下到達(dá)PHASE CHECKPOINT時必須用 AskUserQuestion 工具給出清晰選項并等待用戶明確批準(zhǔn)失敗即停機(jī)任一步驟失敗Agent 報錯、測試失敗、依賴缺失必須立即停止向用戶展示錯誤并詢問處理方式不得靜默繼續(xù)僅使用本地 Agent所有subagent_type只引用本插件內(nèi)置 Agent 或general-purpose不允許跨插件依賴禁止自主進(jìn)入 Plan 模式不得調(diào)用 EnterPlanMode——這條命令本身就是計劃直接執(zhí)行。這 6 條規(guī)則把可控性提到了與完成度同等的高度本質(zhì)是把一次不可逆的大規(guī)模開發(fā)拆解為可審查、可回滾、可恢復(fù)的確定性流水線。三、Pre-flight Checks會話恢復(fù)與狀態(tài)初始化3.1 已有會話檢查執(zhí)行前先檢查.multi-platform/state.json是否存在存在且status: in_progress讀取狀態(tài)展示當(dāng)前步驟向用戶二選一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詢問是否歸檔后重新開始。這一機(jī)制讓中斷的工作流具備真正的可恢復(fù)性——所有進(jìn)度都持久化在state.json而非模型上下文。3.2 狀態(tài)機(jī)初始化創(chuàng)建.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未指定時使用上述默認(rèn)值并從$ARGUMENTS中提取 flag 之前的文本作為$FEATURE。狀態(tài)機(jī)的字段演進(jìn)規(guī)律每個步驟完成后current_step遞增Step 3 完成后置為checkpoint-1Step 4 完成后置為checkpoint-2已完成的步驟號追加進(jìn)completed_steps全部完成后status置為complete并刷新last_updated。checkpoint-*字符串值實際上充當(dāng)了等待人工批準(zhǔn)的暫停標(biāo)志。四、Phase 1架構(gòu)與 API 設(shè)計Steps 1–3串行Phase 1 的定位是先對齊再動手用一份 API 契約、一份設(shè)計系統(tǒng)、一份共享架構(gòu)文檔鎖定三端或多端實現(xiàn)的事實基礎(chǔ)。Step 1功能需求與 API 契約調(diào)用 Task 工具啟動multi-platform-apps-backend-architect對應(yīng) backend-architect.md產(chǎn)出 OpenAPI 3.1 規(guī)范要求覆蓋使用正確 HTTP 方法與狀態(tài)碼的 RESTful 端點復(fù)雜數(shù)據(jù)查詢場景下的 GraphQL schema實時功能所需的 WebSocket 事件帶校驗規(guī)則的請求/響應(yīng) schema認(rèn)證與授權(quán)要求限流rate limiting與緩存策略錯誤響應(yīng)格式與錯誤碼。同時要求定義所有平臺共同消費的共享數(shù)據(jù)模型交付物包括完整 API 規(guī)范、共享數(shù)據(jù)模型、認(rèn)證流程設(shè)計、各平臺集成指南。從 backend-architect.md 的源碼可見該 Agent 的能力矩陣橫跨 REST/GraphQL/gRPC/WebSocket/SSE/Webhook、API 版本化與分頁策略、契約測試Pact 等、SDK 生成其核心行為特征是contract-first清晰定義接口邊界從第一天就內(nèi)建熔斷、重試、超時等韌性模式——與 Step 1 的要求完全吻合。產(chǎn)出保存為.multi-platform/01-api-contracts.md隨后更新state.jsoncurrent_step置 2Step 1 加入completed_steps。Step 2設(shè)計系統(tǒng)與 UI/UX 一致性讀取01-api-contracts.md調(diào)用ui-ux-designer對應(yīng) ui-ux-designer.md要求交付跨平臺設(shè)計系統(tǒng)各平臺組件規(guī)范Material Design、iOS HIG、FluentWeb 響應(yīng)式布局移動優(yōu)先iOS 原生模式SwiftUI與 Android 原生模式Material You桌面端專項考量鍵盤快捷鍵、窗口管理可訪問性要求WCAG 2.2 Level AA深色/淺色主題規(guī)范動畫與轉(zhuǎn)場指南。從 Agent 源碼看ui-ux-designer.md 具備原子設(shè)計方法論、design token 管理、Figma Variables/Style Dictionary、多品牌設(shè)計系統(tǒng)治理等能力其行為特征是系統(tǒng)性、可擴(kuò)展的設(shè)計方案而非一次性設(shè)計并用研究與測試數(shù)據(jù)驗證設(shè)計決策。注意該 Agent 的 frontmatter 指定了model: sonnet屬于模型分層中的 Tier 3文檔、測試、調(diào)試類任務(wù)——詳見倉庫 ARCHITECTURE.md 的模型分層表。產(chǎn)出保存為.multi-platform/02-design-system.md。Step 3共享業(yè)務(wù)邏輯架構(gòu)同時讀取01-api-contracts.md與02-design-system.md調(diào)用general-purposeAgent 完成共享代碼架構(gòu)設(shè)計需定義核心領(lǐng)域模型與實體平臺無關(guān)業(yè)務(wù)規(guī)則與校驗邏輯狀態(tài)管理模式MVI/Redux/BLoC緩存與離線策略錯誤處理與重試策略平臺特定適配器模式。同時要求考慮共享方案選型移動端用 Kotlin MultiplatformWeb/桌面用 TypeScript。交付物為共享代碼架構(gòu)文檔、平臺抽象層設(shè)計、狀態(tài)管理策略、離線/緩存方案與實施指南。產(chǎn)出保存為.multi-platform/03-shared-architecture.mdcurrent_step置為checkpoint-1。五、PHASE CHECKPOINT 1首次人工審查此處必須強(qiáng)制停下向用戶展示三份文檔的核心要點關(guān)鍵 API 端點、設(shè)計系統(tǒng)組件、共享邏輯方案并給出三選一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 才能進(jìn)入 Phase 2選 2 則修訂后重新走檢查點選 3 則更新state.json狀態(tài)并停止。這是架構(gòu)先行理念的人機(jī)閉環(huán)——在投入并行開發(fā)之前先用人類判斷鎖死方向。六、Phase 2并行平臺實現(xiàn)Steps 4a–4d先讀取 Phase 1 的三份產(chǎn)物隨后僅針對state.json中列出的平臺用多個 Task 調(diào)用并行發(fā)起實現(xiàn)任務(wù)。Step 4aWeb 實現(xiàn)React/Next.js調(diào)用multi-platform-apps-frontend-developer技術(shù)棧約定React 18 與 Next.js 14 App RouterTypeScript 類型安全TanStack Query 做 API 集成Zustand/Redux Toolkit 狀態(tài)管理Tailwind CSS 配合設(shè)計系統(tǒng) tokensPWA 能力按需 SSR/SSG 優(yōu)化Web Vitals 優(yōu)化LCP 2.5s、FID 100ms。對應(yīng) Agent frontend-developer.md 的能力覆蓋 React 19、Next.js 15、RSC、Server Actions、ISR、Core Web Vitals 與無障礙實現(xiàn)其行為特征是用戶體驗與性能同等優(yōu)先從設(shè)計階段就考慮可訪問性。產(chǎn)出存為.multi-platform/04a-web.md。Step 4biOS 實現(xiàn)SwiftUI調(diào)用ios-developer約定SwiftUI iOS 17 特性Swift 5.9 與 async/awaitURLSession Combine 集成 APICore Data/SwiftData 持久化平臺特性Face ID、Haptics、Live Activities可測試的 MVVM 架構(gòu)。對應(yīng) Agent ios-developer.md 覆蓋 Swift 6、SwiftUI 5、UIKit 互操作、Core Data/CloudKit、App Store 合規(guī)與 ASO行為特征是嚴(yán)格遵循 Apple HIG編譯期安全優(yōu)先。產(chǎn)出存為.multi-platform/04b-ios.md。Step 4cAndroid 實現(xiàn)Kotlin/Compose調(diào)用multi-platform-apps-mobile-developer約定Jetpack Compose Material 3Kotlin coroutines 與 FlowRetrofit/Ktor 集成 APIRoom 本地數(shù)據(jù)庫Hilt 依賴注入Material You 動態(tài)主題平臺特性生物認(rèn)證、widgetsClean Architecture MVI。對應(yīng) Agent mobile-developer.md 的能力覆蓋 React Native / Flutter / 原生多路線Step 4c 中它扮演的是 Android 原生專家角色。產(chǎn)出存為.multi-platform/04c-android.md。Step 4d桌面端實現(xiàn)可選Electron/Tauri僅當(dāng)desktop出現(xiàn)在 platforms 列表時執(zhí)行仍調(diào)用multi-platform-apps-frontend-developer要求 Tauri 2.0 或 Electron并注入 Web 實現(xiàn)產(chǎn)物以最大化復(fù)用同時補(bǔ)充原生 OS 集成系統(tǒng)托盤、通知按需文件系統(tǒng)訪問自動更新代碼簽名與公證配置鍵盤快捷鍵與菜單欄多窗口支持。產(chǎn)出存為.multi-platform/04d-desktop.md。全部平臺任務(wù)完成后current_step置為checkpoint-2。值得留意的是倉庫還內(nèi)置了 flutter-expert.md 這一統(tǒng)一代碼庫方案專家Flutter 3.x 覆蓋移動/Web/桌面/嵌入式支持 Material 3 與 Cupertino 雙設(shè)計系統(tǒng)當(dāng)--shared-code評估結(jié)論偏向單代碼庫策略時它是 Step 3 架構(gòu)選型的自然備選。七、PHASE CHECKPOINT 2二次人工審查展示全部平臺實現(xiàn)摘要再次給出批準(zhǔn)/變更/暫停三選一未批準(zhǔn)不得進(jìn)入 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調(diào)用general-purpose技術(shù)寫作專家產(chǎn)出交互式 OpenAPI/Swagger 文檔各平臺集成指南各平臺 SDK 示例認(rèn)證流程圖示限流與配額信息錯誤處理最佳實踐API 版本化策略。并要求用平臺實現(xiàn)實測全部端點。產(chǎn)出存為.multi-platform/05-api-docs.md。Step 6跨平臺測試與功能一致性讀取全部04*.md與05-api-docs.md調(diào)用general-purposeQA 工程師驗證功能測試矩陣各平臺行為一致UI 一致性核驗遵循設(shè)計系統(tǒng)各平臺性能基準(zhǔn)可訪問性測試平臺專用工具網(wǎng)絡(luò)韌性測試離線、弱網(wǎng)數(shù)據(jù)同步校驗平臺特定邊界場景端到端用戶旅程測試。交付功能一致性矩陣、各平臺測試結(jié)果、性能基準(zhǔn)、發(fā)現(xiàn)的平臺偏差與修復(fù)建議存為.multi-platform/06-testing.md。Step 7平臺專項優(yōu)化讀取06-testing.md與全部04*.md調(diào)用general-purpose性能工程師按平臺逐項優(yōu)化Web包體積、懶加載、CDN、SEOiOSApp 體積、啟動時間、內(nèi)存、電量AndroidAPK 體積、啟動時間、幀率、電量Desktop二進(jìn)制體積、資源占用、啟動時間API響應(yīng)時間、緩存、壓縮。要求在維持功能一致性的前提下發(fā)揮平臺優(yōu)勢并記錄優(yōu)化技術(shù)與取舍。產(chǎn)出存為.multi-platform/07-optimizations.mdcurrent_step置為complete。九、完成與驗收標(biāo)準(zhǔn)最后將state.json的status置為complete并刷新last_updated呈現(xiàn)最終摘要。命令內(nèi)置的 Success Criteria 可作為團(tuán)隊驗收清單API 契約在實現(xiàn)前已定義并驗證所有平臺達(dá)成功能一致差異 5%性能指標(biāo)滿足各平臺標(biāo)準(zhǔn)可訪問性達(dá)標(biāo)WCAG 2.2 AA 為最低要求跨平臺測試顯示行為一致所有平臺文檔完整適用場景下平臺間代碼復(fù)用率 40%。后續(xù)動作建議逐平臺審查生成的代碼與文檔 → 運行平臺專用測試套件 → 按平臺創(chuàng)建 PR → 用平臺專用流水線部署 → 上線后監(jiān)控跨平臺指標(biāo)。十、設(shè)計原理與最佳實踐總結(jié)10.1 與倉庫架構(gòu)規(guī)范的呼應(yīng)從 ARCHITECTURE.md 可以確認(rèn)本命令遵循倉庫的兩條核心約定一是插件為安裝單元命令/Agent/技能隨插件整體安裝/plugin install multi-platform-apps后即可使用二是源內(nèi)容可移植命令文件以純 Markdown 編寫由tools/adapters/下的適配器在生成期映射到各 harness 的原生格式如 Codex 的 TOML、OpenCode 的 command 目錄、Copilot 的 commands-as-skills、Antigravity 的插件格式因此本文描述的工作流在多個 harness 中均可運行只是調(diào)用語法隨平臺略有差異。10.2 可借鑒的三條工程實踐文件即狀態(tài)用state.json 編號 markdown 產(chǎn)物替代上下文記憶使長流程可恢復(fù)、可審計、可中斷續(xù)跑人機(jī)檢查點兩個強(qiáng)制 PHASE CHECKPOINT 把大規(guī)模并行開發(fā)拆成架構(gòu)批準(zhǔn) → 實現(xiàn)批準(zhǔn) → 集成驗證三個可逆階段把返工成本前置到最低點契約先行 并行收斂先鎖定 API 契約與設(shè)計系統(tǒng)再并行實現(xiàn)多端最后用一致性矩陣與性能優(yōu)化收口——這正是跨平臺交付減少返工、提高復(fù)用的關(guān)鍵路徑。10.3 使用前提與限制本命令依賴插件內(nèi)置的 6 個 Agent 與general-purpose需保證所在 harness 支持 Task/subagent 機(jī)制產(chǎn)物目錄.multi-platform/為運行時生成命令本身不修改倉庫內(nèi)容生成的代碼與文檔由用戶決定如何提交--platforms中列出的平臺會決定 4a–4d 的執(zhí)行分支--shared-code的三種取值會影響 Step 3 的架構(gòu)選型方向建議在調(diào)用前明確兩者。相關(guān)文件速查命令定義 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 架構(gòu)規(guī)范 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創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考