app-agent
ngo275/app-agent加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
如果你做过独立开发，你大概率经历过这样的循环：应用写完了，上架了，然后呢？用户打开 App Store 搜索框，输入"记账"、"todo"、"壁纸"，搜索结果前排全是 Sensor Tower、AppTweak、App Radar 这类专业 ASO 工具推荐的成熟竞品。
App Radar 的订阅价格让个人开发者肉疼，功能复杂到要专门学；AppTweak 便宜些但英文市场优化能力一般；Sensor Tower 面向的是发行商和买量团队，价格更像企业采购。App Store Connect 本身也在发版流程里添堵——同一个"What's New"更新说明，你要为英语、日语、德语、法语……十几个地区各填一遍，纯手工搬运。
AppAgent 就是针对这两件事做的：一个 AI 优先的自主 ASO + 应用发版管理平台，定位是上述商业产品的开源替代品。
这个项目的作者 ngo275 是独立开发者（solopreneur），项目于 2024 年 12 月 17 日创建，官网 app-agent.ai 同步运营。作者的出发点很直接：AI 让"做出一个应用"变得前所未有地容易，但应用做出来之后的"被发现"环节，工具链却还停留在高成本、手工、非自动化的旧时代。于是他从零搭建了 AppAgent，主张"自主运行（autonomous）"——不是给你一堆图表让你自己分析，而是系统自己去找竞品、自己研究关键词、自己生成多语言文案、自己把改动推到 App Store Connect。
有意思的是它的自我定位也相当坦率。官网"是否适合你"一节明确写："不适合你——如果你只做英语市场的精细 ASO"。也就是说它追求的不是单点极致，而是全球多地区、多语言、自动化的效率优先。
把 AppAgent 想象成一位 7×24 小时不休息的应用运营助理，而不是一份要你自己解读的体检报告。
传统 ASO 工具给你的是仪表盘：某日搜索量上升了 15%、某个关键词竞争度变高、某款竞品改版了——然后要你自己判断该怎么办。AppAgent 的工作方式相反：它直接去 App Store 拉竞品列表，用大模型从竞品标题和描述里抽取关键词，再把汇总去重的候选词交给模型重排打分，人工只保留你管理的那份竞品清单。它还内置了每个地区的停用词表和黑名单词表，以及中日韩这类无空格语言的特殊分词处理——这些细节是踩过坑才知道的。
关键词猎手（src/lib/aso/keyword-hunt/）走的是一条五步流水线，每步通过流式 writer 向前端推送进度：先从竞品标题/描述抽取关键词（每款竞品最多 10 个），最多并行处理 20 个竞品、分批 10 个并发以避开限流；然后用 LLM 重排（rerank）候选词；再由模型生成更多 ASO 关键词并做地区合理性检查（locale sanity check）；最后用自研打分算法（score.ts）结合竞品覆盖情况、搜索量等信号给出关键词得分。抽取出的竞品关键词会回写进数据库缓存，避免重复调用模型。
src/lib/aso/optimize.ts 负责把关键词落地成商店字段。它按各商店的字符上限（FIELD_LIMITS）切分标题、副标题和描述，处理单复数变体（-s / -es / -ies），对中日文这类无空格语言逐字处理，并剔除标题里已经出现过的词以避免重复扣分。所有生成走 openai/helpers/zod 的结构化输出，保证返回可校验的类型化结果。
发布管理是它相对同类工具的差异化部分：自动生成多语言更新说明，与 App Store Connect API 双向同步元数据，一键推送变更、一键提交审核。src/lib/app-store-connect/ 下覆盖了 appInfos、metadata、versions、submission、analytics 等完整链路，并对 FORBIDDEN.REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED 这类协议过期错误做了专门的中文提示。Google Play 侧已在搭骨架（仓库含 @googleapis/androidpublisher 依赖和 src/lib/google-play/），但官方仍标注"即将上线"。
前端是 Next.js 14 App Router + TypeScript + Tailwind + shadcn/ui，数据层 Prisma + PostgreSQL，鉴权 NextAuth.js，另有 PostHog 埋点、Resend 发信、Stripe 订阅、Upstash Redis 缓存与限流。界面支持英语和日语（locales/en.json、ja.json），配合 next-intl 国际化。
好的一面：这是一个自带完整 Web 界面的应用，不是 CLI 工具。克隆仓库后 cp .env.sample .env → yarn → prisma generate && prisma migrate deploy → yarn dev，浏览器打开 localhost:3000 就有营销页和仪表盘，README 的部署步骤写得相当清楚，.env.sample 里列了全部环境变量及其用途说明。本地跑通大约半小时。
需要心理准备的另一面：这是一个典型的 B 端 SaaS 全栈应用，而不是开箱即用的单体小工具。你需要自备 PostgreSQL（本地或 Supabase/Neon）、OpenAI API Key，还要有 Apple Developer 的 App Store Connect API 密钥（Key ID、Issuer ID、.p8 私钥）才能真正完成发版同步；Google OAuth、Stripe、Resend、PostHog 视需求配置。没有 Dockerfile 也没有 docker-compose，官方推荐路径是直接扔到 Vercel 上跑（仓库带 vercel.json，还为几个重内存的 API 路由单独设了 3009MB 的内存上限，说明作者踩过 Vercel 函数内存不足的坑）。对只想"看一眼它怎么工作"的人来说，最省事的其实是直接访问官网 demo。
AGPL-3.0 许可证是一道现实的墙。 这是最需要注意的一点。AGPL 要求网络服务使用者也能获得源码，对想把它嵌入自己产品、闭源商用、或直接拿去做托管 SaaS 的团队来说，义务比 MIT/Apache 重得多。README 里写"任何后续版本采用 AGPL 或更新版本"，条款是明确的。
测试几乎为零。 仓库里有 jest.config.ts，但整个文件从第一行到最后一行全被注释掉了，仓库中不存在任何 *.test.ts 或 *.spec.ts 文件（全文树扫描仅命中 "specified-commercial-transactions" 这类误命中的业务页面）。yarn test 存在但没有任何实际测试在跑。对于一个要处理用户密钥、调用 Apple 审核接口的付费 SaaS 底座来说，这是相当明显的质量缺口。
维护节奏偏慢。 2025 年 1 月是最密集的提交期（功能迭代几乎都在那个月），此后进入长尾。2025 年 12 月有一个来自外部贡献者的安全修复（React Server Components CVE），2026 年 2 月把已废弃的 o1-mini 换成 o3-mini，2026 年 10 月 25 日（就在几天前）合并了一个关于 deprecated 模型的修复 PR。最近的活跃几乎都停留在"修依赖、改模型名"这类维护性动作上，核心功能迭代节奏明显放缓。
维护者体量有限。 contributors 接口显示总贡献者约 5-6 人，与 README 强调的"社区驱动"相比，社区参与度很淡，实质上是单人主导项目。
密钥管理是硬性门槛。 App Store Connect 私钥、JWT、Stripe 密钥、OpenAI Key 全部要由部署方自己填进环境变量；错误提示做了中文化，但首次配置仍然繁琐。
AppAgent 所在的位置很有意思：它不是又一个"AI 帮你写文案"的玩具，而是把 LLM 塞进了一条有明确输入输出、可验证信号（关键词得分、商店字段长度限制、竞品覆盖）的垂直工作流里。关键词抽取→重排→打分→落地→推送这条链路，每一步都有传统的 ASO 领域经验做约束——停用词表、黑名单、字符上限、单词复数归一化、地区分词差异，这些恰恰是通用聊天机器人做不扎实、而"AI-first from the ground up"的垂直产品才能沉淀下来的部分。
从这个角度看，它映照出 2025-2026 年开源 AI 产品的一个共同趋势：不追求通用能力，而是把 LLM 塞进一个有确定业务边界的管道里，让自动化真正闭环到"一键提交审核"这种需要外部系统配合的终点。191 stars、31 forks 的体量说明它还是小众工具，但 AGPL 开源 + 自托管 + 数据不出自己服务器这套组合，对被商业 SaaS 定价卡住、又不愿把自己的 App Store Connect 凭据交给第三方的独立开发者和小团队，是一条现实可走的替代路径。
AppAgent 把"发版"这件苦差事和"ASO"这件烧钱事绑在了一起，用自主代理的思路重做了一遍。它的短处同样清楚：许可证偏重、测试为零、维护节奏放缓、配置门槛高。适合想低成本试水、且愿意自己动手处理基础设施的技术型独立开发者；不适合追求英语单市场极致优化、或需要企业级稳定 SLA 的发行商团队。