ag-kit 移动后端模式指南为 iOS/Android 客户端设计高可用 API 的完整实践【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit本指南以.agents/skills/mobile-design/mobile-backend.md为核心系统讲解面向移动客户端的后端与 API 设计模式。移动端与 Web 端有着截然不同的约束——不稳定的网络、有限的电量与存储、频繁被打断的会话、参差多样的设备、缓慢的应用商店审核周期这些都需要后端主动补偿。读完本文你将掌握推送通知、离线同步与冲突解决、移动 API 优化、版本管理、令牌认证、移动错误格式、媒体处理、安全加固与监控分析九大领域的落地模式并能结合 ag-kit 仓库中的源码证据理解每一条规则背后的实现原理。一、移动后端思维客户端不同后端就必须不同mobile-backend.md开篇就强调了一个核心论断移动后端不等于 Web 后端。移动客户端面临以下结构性差异Mobile clients are DIFFERENT from web clients: ├── Unreliable network (2G, subway, elevator) ├── Battery constraints (minimize wake-ups) ├── Limited storage (cant cache everything) ├── Interrupted sessions (calls, notifications) ├── Diverse devices (old phones to flagships) └── Binary updates are slow (App Store review)这六条约束决定了后端设计的出发点约束对后端的含义网络不可靠2G、地铁、电梯需要离线能力、同步队列、断点续传电量受限尽量减少网络唤醒推送代替轮询批量请求代替逐个请求存储有限不能全量缓存需要字段选择、分页、增量同步会话被中断令牌认证代替会话认证静默续期状态可恢复设备多样需要设备信息上报型号、OS 版本以定位问题二进制更新慢版本检查端点、强制更新机制、功能开关feature flags这条原则在 ag-kit 的移动设计体系中同样被列为关键参考在 mobile-design/SKILL.md 的必读文件表中mobile-backend.md被标记为CRITICAL与mobile-design-thinking.md、touch-psychology.md等同级说明后端模式是移动全链路设计中不可割裂的一环。SKILL.md 的哲学也与之呼应Touch-first. Battery-conscious. Platform-respectful. Offline-capable.——离线能力正是移动后端补偿网络缺陷的核心手段。二、AI 移动后端反模式先认识默认错误再谈正确做法mobile-backend.md用一张对照表总结了 AI 在构建移动后端时最容易犯的八个错误。这些反模式的价值在于它们揭示了对 Web 后端正确的方案放在移动场景下恰恰是错误。❌ AI 默认做法为什么错✅ 移动端正确做法Web 与移动共用同一套 API移动端需要紧凑响应独立移动端点或字段选择返回完整对象浪费带宽与电量部分响应 分页完全不考虑离线无网络时应用崩溃离线优先设计、同步队列一切皆用 WebSocket持续连接耗电推送通知 轮询兜底不做应用版本管理无法强制升级破坏性变更失控版本头Version headers 最低版本检查通用错误信息用户无法自助解决移动专属错误码 恢复动作基于 Session 的认证移动应用会被系统反复杀进程重启基于令牌Token认证 refresh 机制忽略设备信息出问题无法定位请求头携带 Device ID、App 版本这些反模式在 ag-kit 的配套审计脚本中得到了可执行化的印证。.agents/skills/mobile-design/scripts/mobile_audit.py的8. MOBILE BACKEND CHECKS一节实现了三条自动化检查文件头部注释标注了对应关系8.1 安全存储检查检测代码中是否存在AsyncStorage与token|jwt同时出现且缺少SecureStore|Keychain|EncryptedSharedPreferences的情况命中即报[Security]级 issue——这正是令牌不能明文存储反模式的机器化版本8.2 离线处理检查检测到fetch|axios|netinfo等网络调用但无offline|isConnected|netInfo|cache.*offline相关处理时给出离线处理缺失的警告8.3 推送通知支持检查检测到Notifications|Firebase.messaging|PushNotificationIOS等推送库但缺少onNotification|addNotificationListener|notification.open处理器时提示可能丢失通知。该脚本可用python .agents/skills/mobile-design/scripts/mobile_audit.py 项目路径运行支持--json输出结构化报告它会自动识别 React Native / Flutter 项目并对全部移动文件执行 50 项检查其中后端相关的部分就是上述三条。这意味着本文讲到的每条后端模式在 ag-kit 中都有对应的自动化验收规则。三、推送通知让消息主动找到用户而不是让用户轮询3.1 平台架构推送通知是移动后端区别于 Web 后端最典型的机制。服务端不直接连接设备而是通过两大平台通道下发┌─────────────────────────────────────────────────────────────────┐ │ YOUR BACKEND │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ │ ┌──────────┴──────────┐ │ │ ▼ ▼ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ FCM (Google) │ │ APNs (Apple) │ │ │ │ Firebase │ │ Direct or FCM │ │ │ └────────┬────────┘ └────────┬────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Android Device │ │ iOS Device │ │ │ └─────────────────┘ └─────────────────┘ │ └─────────────────────────────────────────────────────────────────┘两条链路的关键差异Android 通过 FCMFirebase Cloud Messaging下发iOS 可以直接走 APNs也可以通过 FCM 代理转发。文档特别提醒不能因为接入了 FCM 就跳过 APNs 的适配——FCM 单独使用并不保证 iOS 的投递成功。3.2 推送类型类型使用场景用户可见性Display展示型新消息、订单更新通知横幅Silent静默型后台同步、内容更新无后台执行Data数据型由应用自定义处理取决于应用逻辑三种类型的划分本质上是对用户打扰程度与后台唤醒成本的权衡展示型用于必须让用户立刻感知的事件静默型用于利用系统后台窗口完成数据预取数据型则把完整的控制权交给应用。3.3 反模式对照❌ 绝不✅ 始终在推送中发送敏感数据推送只提示有新消息内容由 App 拉取推送过载轰炸批量合并、去重、尊重免打扰时段对所有人推同一消息按用户偏好、时区细分忽略失效的令牌定期清理无效令牌iOS 跳过 APNsFCM 单独使用不能保证 iOS 投递3.4 令牌生命周期管理设备令牌是推送链路中的核心状态其完整生命周期如下TOKEN LIFECYCLE: ├── App registers → Get token → Send to backend ├── Token can change → App must re-register on start ├── Token expires → Clean from database ├── User uninstalls → Token becomes invalid (detect via error) └── Multiple devices → Store multiple tokens per user实践要点启动即重注册令牌可能因系统升级、应用重装而变化App 每次冷启动都应重新获取并上报失败令牌的检测与清理推送投递返回无效令牌错误时后端应据此标记并从数据库移除审计脚本 8.3 检查的onNotification处理器缺失问题也会直接导致这类错误无法被应用感知多设备支持一个用户可能有手机、平板多个设备后端应为一对多存储令牌并支持按设备维度管理这也与后面多设备登出的认证设计呼应。四、离线同步与冲突解决网络不可靠时的数据一致性方案4.1 按数据类型选择同步策略离线能力不是全有或全无mobile-backend.md给出了一个按数据类型分层的决策树WHAT TYPE OF DATA? │ ├── Read-only (news, catalog) │ └── Simple cache TTL │ └── ETag/Last-Modified for invalidation │ ├── User-owned (notes, todos) │ └── Last-write-wins (simple) │ └── Or timestamp-based merge │ ├── Collaborative (shared docs) │ └── CRDT or OT required │ └── Consider Firebase/Supabase │ └── Critical (payments, inventory) └── Server is source of truth └── Optimistic UI server confirmation这个决策树在 ag-kit 的 decision-trees.md 5. Offline Strategy Selection一节中得到了一致且更细化的展开可有可无Nice to have缓存最近数据并展示陈旧内容配合staleTimeTanStack Query与最后更新时间提示核心必需Essential离线优先架构——本地数据库作为事实源联网后同步必须设计冲突解决策略并把待同步动作排队实时关键Real-time criticalWebSocket 本地队列配合乐观更新与最终一致性冲突处理复杂度最高。decision-trees.md 还归纳了四种离线实现模式缓存优先 / 陈旧时重新验证 / 离线优先 / 同步引擎其中同步引擎可直接选用 Firebase、Realm Sync、Supabase realtime 这类自带冲突解决的服务属于拿来即用的降级方案。4.2 冲突解决策略对比策略工作原理最适合Last-write-wins最后写入胜出最新时间戳覆盖旧值简单数据、单用户Server-wins服务端胜出服务端始终权威关键事务Client-wins客户端胜出优先保留离线变更重度离线应用Merge字段级合并逐字段合并变更文档、富内容CRDT无冲突复制数据类型数学上保证无冲突实时协作选择原则数据越简单策略越简单数据越关键服务端权威性越高。支付、库存这类数据绝不能让客户端时间戳决定胜负。4.3 同步队列模式同步队列是离线优先架构的落地骨架客户端与服务端各司其职CLIENT SIDE: ├── User makes change → Write to local DB ├── Add to sync queue → { action, data, timestamp, retries } ├── Network available → Process queue FIFO ├── Success → Remove from queue ├── Failure → Retry with backoff (max 5 retries) └── Conflict → Apply resolution strategy SERVER SIDE: ├── Accept change with client timestamp ├── Compare with server version ├── Apply conflict resolution ├── Return merged state └── Client updates local with server response关键设计决策队列条目结构{ action, data, timestamp, retries }四要素缺一不可——action 用于服务端理解操作语义data 是负载timestamp 参与冲突裁决retries 控制重试上限FIFO 顺序为保证操作语义的一致性队列必须先进先出处理指数退避 上限失败重试带退避backoff文档给出的上限是5 次重试防止无限重试耗尽电量服务端返回合并态服务端不能只回成功/失败应返回合并后的完整状态客户端据此更新本地保证两端收敛。五、移动 API 优化每字节都在烧钱、耗电、占时间5.1 响应体积缩减技术mobile-backend.md给出了一组量化的带宽节省数据这些是该文档给出的设计目标值实际效果取决于具体数据形态技术节省量实现方式字段选择30-70%?fieldsid,name,thumbnail压缩60-80%gzip/brotli自动分页视情况移动端优先使用游标分页图片变体50-90%/image?w200q80增量同步80-95%仅返回时间戳之后的变更记录字段选择是移动端专属端点之外的轻量替代方案对应第一节反模式表中独立移动端点 OR 字段选择。增量同步则与第四章的同步策略天然衔接——只同步updated_since之后的记录是读写型数据的带宽最优解。5.2 分页游标 vs 偏移量OFFSET (Bad for mobile): ├── Page 1: OFFSET 0 LIMIT 20 ├── Page 2: OFFSET 20 LIMIT 20 ├── Problem: New item added → duplicates! └── Problem: Large offset slow query CURSOR (Good for mobile): ├── First: ?limit20 ├── Next: ?limit20aftercursor_abc123 ├── Cursor encoded (id sort values) ├── No duplicates on data changes └── Consistent performance偏移量分页在移动场景的两个致命伤数据变化导致重复/遗漏新插入记录会错位、大偏移量查询变慢。游标分页把位置编码进cursor通常是 id 排序值的组合客户端无需知道页码服务端直接跳到游标位置天然免疫数据插入导致的错位且性能恒定。5.3 批量请求移动网络的成本大头是连接建立与等待round trip而非字节本身。批量请求把多次往返压缩为一次Instead of: GET /users/1 GET /users/2 GET /users/3 (3 round trips, 3x latency) Use: POST /batch { requests: [ { method: GET, path: /users/1 }, { method: GET, path: /users/2 }, { method: GET, path: /users/3 } ]} (1 round trip)这也是 ag-kit 中 mobile-performance.md Request Optimization一节强调的BATCH原则10 个小请求合并为 1 个批量请求减少连接开销无线电模块只开启一次更省电。批量、缓存、压缩被该文档列为网络优化的三大支柱。六、应用版本管理掌控无法频繁更新的二进制6.1 版本检查端点由于应用商店审核周期漫长后端必须承担门禁职责。文档给出了一个完整的配置端点设计GET /api/app-config Headers: X-App-Version: 2.1.0 X-Platform: ios X-Device-ID: abc123 Response: { minimum_version: 2.0.0, latest_version: 2.3.0, force_update: false, update_url: https://apps.apple.com/..., feature_flags: { new_player: true, dark_mode: true }, maintenance: false, maintenance_message: null }响应字段语义字段用途minimum_version强制升级门槛低于此版本的客户端被拦截latest_version当前最新版本用于提示可选升级force_update是否进入强制升级模式update_url跳转商店的链接feature_flags功能开关无需发版即可控制功能maintenance/maintenance_message服务端维护状态与提示文案6.2 版本比较与功能开关逻辑CLIENT VERSION vs MINIMUM VERSION: ├── client minimum → Continue normally ├── client minimum → Show force update screen │ └── Block app usage until updated └── client latest → Show optional update prompt FEATURE FLAGS: ├── Enable/disable features without app update ├── A/B testing by version/device └── Gradual rollout (10% → 50% → 100%)三段式判断清晰定义了客户端的三种命运正常放行、强制升级拦截、可选升级提示。而feature_flags的威力在于把发版才能改功能变成改配置即可灰度发布10% → 50% → 100%、按版本/设备做 A/B 测试、紧急关闭问题功能kill switch都不再依赖漫长的审核周期。这一节与 ag-kit 的 api-patterns/versioning.md 互补后者回答API 本身如何演进URI/v1/users、HeaderAccept-Version、Query?version1的取舍本节的/api/app-config则回答客户端二进制如何受控。两者共同构成移动应用的版本治理体系。七、移动认证令牌三元组与静默续期7.1 三类令牌的分工移动端会话会被系统随时杀死Session 认证天然不适用。文档给出的是三级令牌体系ACCESS TOKEN: ├── Short-lived (15 min - 1 hour) ├── Stored in memory (not persistent) ├── Used for API requests └── Refresh when expired REFRESH TOKEN: ├── Long-lived (30-90 days) ├── Stored in SecureStore/Keychain ├── Used only to get new access token └── Rotate on each use (security) DEVICE TOKEN: ├── Identifies this device ├── Allows log out all devices ├── Stored alongside refresh token └── Server tracks active devices设计要点访问令牌短命且仅存内存即使被窃取15 分钟1 小时的有效期将损失面压到最小刷新令牌长命但仅存安全存储3090 天有效期放在 Keychain / SecureStore且每次使用都轮换rotate——刷新一次换一个新令牌旧令牌作废抵御令牌重放设备令牌支持多端管理服务端跟踪每个用户的活跃设备清单实现登出所有设备的能力。ag-kit 的审计脚本 8.1 对存储位置做了强制校验检测到令牌相关代码使用AsyncStorage而非常规安全存储时直接报[Security]级别 issue。这条规则的依据可追溯到 decision-trees.md 的存储策略决策树敏感数据令牌、密码、密钥必须走 iOS Keychain / Android EncryptedSharedPreferences / expo-secure-store其 Auth Token Storage 一节同样明确禁止在 AsyncStorage、Redux 全局状态、日志中出现令牌。这与 api-patterns/auth.md 的 JWT 原则短过期 refresh 令牌、不存放敏感数据保持一致。7.2 静默重新认证流程用户无感知的令牌续期是移动体验的关键REQUEST FLOW: ├── Make request with access token ├── 401 Unauthorized? │ ├── Have refresh token? │ │ ├── Yes → Call /auth/refresh │ │ │ ├── Success → Retry original request │ │ │ └── Failure → Force logout │ │ └── No → Force logout │ └── Token just expired (not invalid) │ └── Auto-refresh, user doesnt notice └── Success → Continue实现要点收到 401 时先区分令牌过期与令牌无效——过期走自动刷新无效直接登出刷新成功服务端返回新 access token同时轮换 refresh token后重放原始请求用户全程无感知刷新失败refresh 令牌也被吊销才强制登出避免死循环。八、移动错误处理让用户知道下一步该干什么8.1 移动专属错误格式通用错误信息如 Error 500对移动用户毫无帮助。文档给出了结构化的移动错误响应{ error: { code: PAYMENT_DECLINED, message: Your payment was declined, user_message: Please check your card details or try another payment method, action: { type: navigate, destination: payment_methods }, retry: { allowed: true, after_seconds: 5 } } }这个格式的精妙之处在于三个层次的解耦message给开发者看的机器可读描述user_message给用户看的可理解文案action指导 UI 行为——navigate到payment_methods页面让错误处理从展示升级为导航retry明确告知是否可以重试、多久后重试配合限流头的Retry-After。8.2 错误分类与移动端处置策略状态码范围类别移动端处理400-499客户端错误展示消息需要用户操作401认证过期静默刷新或重新登录403禁止访问展示升级/权限页404资源不存在从本地缓存移除409冲突展示同步冲突 UI429限流按Retry-After头退避500-599服务端错误退避重试提示稍后再试网络层无连接使用缓存数据进入同步队列注意 404 的移动端特殊处理从本地缓存中移除该资源——既然服务端已不存在本地缓存必须同步清理否则离线状态下会展示幽灵数据。网络层错误则明确走缓存 队列的离线路径与第四章的同步机制闭环。九、媒体与二进制处理图片、大文件与流媒体9.1 图像优化CLIENT REQUEST: GET /images/{id}?w400h300q80formatwebp SERVER RESPONSE: ├── Resize on-the-fly OR use CDN ├── WebP for Android (smaller) ├── HEIC for iOS 14 (if supported) ├── JPEG fallback └── Cache-Control: max-age31536000要点客户端按显示尺寸请求变体对应 5.1 节的图片变体50-90% 带宽节省服务端按平台返回最合适的编码Android 用 WebP、iOS 14 用 HEIC、兜底 JPEG配合Cache-Control: max-age31536000一年的长缓存让图片基本只下载一次。从 mobile-performance.md 的视角看这同时解决了客户端的内存问题——按 4 字节 RGBA 计算一张 1080p 图占 8.3MB永远不要原图直出。9.2 大文件分块上传移动网络随时可能中断整文件上传必然失败。分块上传三步协议UPLOAD FLOW: 1. POST /uploads/init { filename, size, mime_type } → { upload_id, chunk_size } 2. PUT /uploads/{upload_id}/chunks/{n} → Upload each chunk (1-5 MB) → Can resume if interrupted 3. POST /uploads/{upload_id}/complete → Server assembles chunks → Return final file URLInit 阶段客户端申报文件元信息服务端返回upload_id与chunk_size1-5MB 是文档建议的单块大小Chunk 阶段逐块上传断点续传能力由upload_id chunk n的幂等寻址天然提供——中断后从失败的块号继续即可Complete 阶段服务端校验并组装返回最终 URL。9.3 音视频流式传输REQUIREMENTS: ├── HLS (HTTP Live Streaming) for iOS ├── DASH or HLS for Android ├── Multiple quality levels (adaptive bitrate) ├── Range request support (seeking) └── Offline download chunks ENDPOINTS: GET /media/{id}/manifest.m3u8 → HLS manifest GET /media/{id}/segment_{n}.ts → Video segment GET /media/{id}/download → Full file for offline流媒体三要素自适应码率多档质量弱网自动降档、Range 请求支持拖动进度条 seek、离线下载端点把分片下载到本地供无网观看。manifest.m3u8描述了分片清单segment_{n}.ts是具体分片download端点则服务于官方离线下载功能。十、移动安全设备不可信但要让它可验证10.1 设备认证Device AttestationVERIFY REAL DEVICE (not emulator/bot): ├── iOS: DeviceCheck API │ └── Server verifies with Apple ├── Android: Play Integrity API (replaces SafetyNet) │ └── Server verifies with Google └── Fail closed: Reject if attestation fails核心原则是fail closed设备认证失败就拒绝而不是放行观察。iOS 用 DeviceCheck API、Android 用 Play Integrity APISafetyNet 的继任者服务端与 Apple/Google 校验凭证确认请求确实来自真实硬件而非模拟器或脚本。10.2 请求签名CLIENT: ├── Create signature HMAC(timestamp path body, secret) ├── Send: X-Signature: {signature} ├── Send: X-Timestamp: {timestamp} └── Send: X-Device-ID: {device_id} SERVER: ├── Validate timestamp (within 5 minutes) ├── Recreate signature with same inputs ├── Compare signatures └── Reject if mismatch (tampering detected)请求签名防篡改的完整链路客户端用共享密钥对timestamp path body做 HMAC服务端在5 分钟时间窗内用同样输入重算签名并比对。时间戳窗口既防止重放攻击超窗拒绝又容忍客户端与服务端的时钟偏差。10.3 移动限流限流维度必须比 Web 更细MOBILE-SPECIFIC LIMITS: ├── Per device (X-Device-ID) ├── Per user (after auth) ├── Per endpoint (stricter for sensitive) └── Sliding window preferred HEADERS: X-RateLimit-Limit: 100 X-RateLimit-Remaining: 95 X-RateLimit-Reset: 1609459200 Retry-After: 60 (when 429)按设备限流是移动端特有的——一个设备 ID 对应一个物理设备能有效拦截脚本与模拟器刷量滑动窗口优于固定窗口避免固定窗口边界处的突发穿透。限流响应头与 api-patterns/rate-limiting.md 完全一致Limit/Remaining/Reset 429后者补充了算法选型的完整视角令牌桶允许突发适合多数 API、滑动窗口平滑分布适合严格限制、固定窗口简单计数仅适合基础需求。十一、监控与分析没有设备上下文就无法定位移动问题11.1 每个请求必须携带的头Every mobile request should include: ├── X-App-Version: 2.1.0 ├── X-Platform: ios | android ├── X-OS-Version: 17.0 ├── X-Device-Model: iPhone15,2 ├── X-Device-ID: uuid (persistent) ├── X-Request-ID: uuid (per request, for tracing) ├── Accept-Language: tr-TR └── X-Timezone: Europe/Istanbul这批头的设计意图X-App-Version/X-Platform/X-OS-Version/X-Device-Model构建设备-版本矩阵回答哪个版本在什么设备上出问题X-Device-ID持久化的设备唯一标识区别于会话级 ID支撑按设备维度的限流与统计X-Request-ID每次请求唯一用于跨服务链路追踪对应 8.1 节错误日志的关联Accept-Language/X-Timezone本地化与按时段分析的基础如推送尊重时区策略的数据来源。11.2 日志与告警FOR EACH REQUEST: ├── All headers above ├── Endpoint, method, status ├── Response time ├── Error details (if any) └── User ID (if authenticated) ALERTS: ├── Error rate 5% per version ├── P95 latency 2 seconds ├── Specific version crash spike ├── Auth failure spike (attack?) └── Push delivery failure spike告警阈值示例文档给出的建议值按版本错误率 5%、P95 延迟 2 秒、特定版本崩溃骤增通常是新发版的回归信号、认证失败骤增疑似撞库攻击、推送投递失败骤增令牌批量失效或通道故障。十二、移动后端检查清单mobile-backend.md以一份可勾选的清单收尾覆盖 API 设计前、端点级、认证、推送、发布五个阶段### Before API Design - [ ] Identified mobile-specific requirements? - [ ] Planned offline behavior? - [ ] Designed sync strategy? - [ ] Considered bandwidth constraints? ### For Every Endpoint - [ ] Response as small as possible? - [ ] Pagination cursor-based? - [ ] Proper caching headers? - [ ] Mobile error format with actions? ### Authentication - [ ] Token refresh implemented? - [ ] Silent re-auth flow? - [ ] Multi-device logout? - [ ] Secure token storage guidance? ### Push Notifications - [ ] FCM APNs configured? - [ ] Token lifecycle managed? - [ ] Silent vs display push defined? - [ ] Sensitive data NOT in push payload? ### Release - [ ] Version check endpoint ready? - [ ] Feature flags configured? - [ ] Force update mechanism? - [ ] Monitoring headers required?这份清单可以直接作为团队评审移动后端 API 设计稿的模板也可以与 ag-kit 的自动化审计互补mobile_audit.py负责代码层的机器检查本清单负责设计层的人工把关。结语移动后端的底线用mobile-backend.md的结语作总结移动后端必须对恶劣网络有韧性、尊重电池寿命、优雅处理被打断的会话。客户端不可信但也绝不能把它挂起——提供离线能力与清晰的错误恢复路径。整套模式的内在逻辑是一以贯之的用后端的能力补偿客户端的环境缺陷——推送替代轮询补偿电量与实时性离线同步与冲突解决补偿网络不稳定紧凑 API 与批量请求补偿带宽版本端点与功能开关补偿审核周期令牌体系补偿会话不可靠结构化错误补偿用户自助能力设备认证与签名补偿客户端不可信监控头补偿问题不可定位。如果你正在基于 React Native / Flutter 构建移动应用可进一步阅读本仓库 mobile-design 技能集 下的离线决策树 decision-trees.md 与性能参考 mobile-performance.md并用 mobile_audit.py 对现有代码执行一次全面的移动后端合规扫描。【免费下载链接】ag-kit项目地址: https://gitcode.com/GitHub_Trending/an/ag-kit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考