异地第六年，我用一杯咖啡的时间定下了跨平台框架选型
上周六晚上十一点，我拖着行李箱从杭州东站出来，老婆递来一杯温热的拿铁：“上次说要重构那个App，选好框架没？”我苦笑：“这不正纠结着呢。”六年双城生活，让我对“效率”有了刻骨铭心的理解——时间太宝贵，容不得浪费在低效的框架选型上。
起因：一个要命的跨平台需求
七月初，部门老大要求做一个内部智能客服系统，前端跨平台（iOS、Android、Web），后端集成AI能力，九月底出MVP。我手下只有两个新人，自己负责架构和AI模块。
回到工位，我列出需求清单：
- 跨平台UI：一套代码覆盖三端
- AI Agent：编排多个智能体，处理复杂对话
- 快速集成：现成SDK，避免从零写RAG和Function Calling
脑子里蹦出两个关键词：FastGPT和OpenAI Agents SDK。
选型第一回合：Flutter vs React Native vs 其他
三年前用React Native做电商App，列表滑动卡顿调了两周，对JS Bridge序列化开销有阴影。虽然RN生态成熟，但心有余悸。Flutter渲染性能好，可Web端支持不温不火，而我们的项目明确需要Web端。
后来发现FastGPT，一个开源知识库问答系统，前端用Next.js，自研UI组件库支持移动端响应式。我决定直接基于它做二次开发：Web端天然支持，移动端用Capacitor打包。花两小时拉源码跑了一遍，其Monorepo架构、聊天界面的流式输出处理相当优雅，当场拍板。
选型第二回合：AI Agent框架的深度思考
智能客服需要多轮对话、调用多个业务接口，涉及复杂状态管理。LangChain抽象层次太多，调试像黑箱。转而研究OpenAI Agents SDK，其设计哲学深得我心：Agent定义为“带指令和工具的循环执行器”，通过Handoff机制交接任务，像搭积木。
上周六早上，我用它搭了三个Agent：Triage Agent负责意图识别，Order Agent查订单，Refund Agent处理退款。核心代码：
from agents import Agent, Runner, function_tool
@function_tool
def query_order(order_id: str) -> dict:
return {"status": "shipped", "tracking": "SF123456"}
order_agent = Agent(
name="OrderAgent",
instructions="你负责查询订单状态和物流信息",
tools=[query_order]
)
triage_agent = Agent(
name="TriageAgent",
instructions="根据用户意图，将任务分配给合适的Agent",
handoffs=[order_agent, refund_agent]
)
跑通时我很激动。这种“组合代替继承”的思路，让调用链路一目了然，彻底告别LangChain那种逻辑乱麻。
整合方案：FastGPT + OpenAI Agents SDK
最终架构：
- 前端：基于FastGPT UI二次开发，复用流式对话和Markdown渲染组件，省两周工时。Web直接部署，移动端Capacitor打包。
- AI层：OpenAI Agents SDK搭建多Agent协作体系，通过Function Calling调用业务API，实现真正的智能客服。
- 数据层：FastGPT自带知识库（向量数据库+RAG）存储产品文档，Agent优先检索，查不到再转人工。
核心优势：两个开源项目理念高度契合——FastGPT解决知识管理和前端交互，Agents SDK解决复杂任务编排。
写在最后：选择框架的本质是选择效率
没有银弹，只有适不适合。Flutter性能好但Web弱，RN成熟但调试痛苦，FastGPT非传统跨平台框架却恰好符合需求。LangChain功能强但抽象过度，Agents SDK轻量灵活但生态尚早。
选择框架的本质，是选择团队的效率上限。能让我准时赶高铁、周末陪家人的框架，就是好框架。建议先搞清楚最缺什么——开发效率、性能还是学习成本？花一个周末亲手跑Demo，感受写代码的体感，答案自现。
评论 0