MiamiFlow —— 由四个 AI 代理运营的舞蹈工作室 CRM

问题所在

一家舞蹈工作室靠上百件琐碎操作运转:给家长上手、销售会员卡、催收款、预订场地租赁、记录出勤,以及一整天回答同样的问题。这些几乎全压在一两个管理员身上,让他们在聊天和表格里做重复劳动。MiamiFlow 用一套真正的 CRM 取代这种煎熬——并把四个 AI 代理放到前线去真正 做 这些活,而不只是把它们记下来。

它做什么 —— 四个代理,四份工作

MiamiFlow 已为一家真实工作室在生产环境上线,四个 ReAct(tool-use)代理扛起了面向客户和运营的负担:

• Eva —— 面向家长和学员的 Telegram 代理。她给新客户上手、创建孩子的档案、把他们编入小组、销售会员卡,并回答关于课表、价格、规则和教练的问题。她发放支付 QR 码,甚至会读取支付截图来把它和对应的账单匹配起来——然后交给人工管理员去核验和激活。语气温暖,贴合品牌。
• Anna —— 面向前台的 web 聊天代理。员工不必在表单里一路点击,只要告诉 Anna 他们要什么:登记一笔付款、修改一张会员卡、查一个学员、给一个小组发消息——她就把平实的语言转换成 CRM 里正确的操作。
• Maya —— 管理员的管理副驾。问她出勤、财务、欠款或课表的情况如何,她就会拉出数字,并通过一套宽广的 ReAct 工具集在整个学校范围内执行动作——报表、财务、课表、教练等等。
• Vika —— 第二个 Telegram 代理,专门负责销售场地租赁:查可用时段、报价,并完成预订。

围绕这些代理是一套完整的后台界面——账单、会员卡、出勤记录、财务与欠款、教练收入、折扣、比赛、场地、代理监控,以及 LLM 成本核算。

我构建了什么

独立完成,从头到尾:FastAPI 后端(干净地分层为 API、服务、模型,以及带工具的代理)、用 Next.js + TypeScript 写的、有几十个界面的后台应用、两个 Telegram 机器人、数据库与迁移,以及代理本身。

这些代理是真正的 ReAct 循环,带类型化的工具——每一项能力(给孩子报名、销售会员卡、收一笔款、预订租赁、检索工作室文档、拉一份出勤报告)都是模型可以调用的工具。后台助手 Maya 通过 SSE 流式输出她的推理和工具调用,这样员工能看着她工作,而不是干等一个黑盒。

架构选择

一套自研的 LLM 网关。 当三个代理和两个机器人同时调用模型时,你会撞上提供商的速率限制,并悄无声息地丢请求(HTTP 429)。所以我构建了 LLM Gate——一个介于应用和提供商(OpenRouter、Groq)之间、与 OpenAI 兼容的内部代理,负责限流、请求排队、优先级调度和熔断。把任何服务切换到它,只是改一行 base_url。它就是那层韧性,在真实的并发负载下让代理保持可靠。

从设计上 model-agnostic。 每一次 LLM 调用都经由网关走 OpenRouter,所以模型只是一项设置——默认快而便宜,可以换成 Claude、GPT 或别的模型,而不必碰代理代码。还是我反复强调的那句:别跟某一个模型结婚。

钱在动的地方,留人在环里。 销售是自动化的;确认付款 不是。Eva 识别一张支付截图并把它附到账单上,但由人工管理员去核验它并激活会员卡。敏感的、不可逆的操作被刻意挡在人这一关。

成本和行为看得见。 每次 LLM 调用的日志与定价,加上一个代理监控视图,意味着工作室能看到代理在做什么、花了多少钱。可观测性是内建的,不是事后钉上去的。

clean architecture,带测试。 FastAPI 配 SQLAlchemy 与 Alembic 迁移、Redis、一个把代理和工具干净分离的分层后端、端到端 / 性能 / 安全测试套件,装进 Docker 并部署在 Railway 上。

当前状态

MiamiFlow 已在生产环境上线,地址是 miamistudio.org,支撑着一家真实工作室的日常——真实的客户、真实的账单、真实的钱。我独立构建了它,依据一份分阶段的规格来指挥 AI 代理,同时把架构、代理设计和审查都握在自己手里。它是我一直主张的那件事最完整的例子:AI 代理不只是聊天,而是真正把活干完——安全、可观测,并且在生产环境里。