AI Agent从并发到多模态：主流架构选型与工程落地指南

1. 这周的Agent圈，到底在吵什么

2026年9月第三周，AI应用和AI Agent领域的讨论热度，明显比前几周上了一个台阶。我翻了下这段时间的技术社区、开源仓库和各个技术群里大家转的内容，发现几个关键词出现频率极高："AI Agent怎么扛并发"、"主流架构选型"、"多模态大模型最新进展"、"AI智能体应用案例"。说实话，这几个词放在一起，基本就是2026年下半年Agent赛道的缩影——大家已经从"能不能做出来"的阶段，正式切换到"怎么做稳、做快、做得能上线"的阶段。

这一周最让我有感触的，是"AI Agent怎么扛并发"这个话题被反复讨论。前两年大家聊Agent，聊的是提示词怎么写、工具怎么调、记忆怎么管，属于功能验证期。但这周明显不一样了，讨论的核心变成了：多Agent实例同时跑的时候怎么不崩、怎么控制成本、怎么让用户的请求在5秒内拿到响应。这说明什么？说明Agent类应用已经有一批真实验收在跑了，不是Demo，不是玩具，是有人真的在用、真的有并发压力了。

这篇文章我想顺着这份日报的核心内容，把这一周行业里的热点做个梳理，重点聊聊几个被反复提及的话题：Agent并发处理、主流框架的选型逻辑、多模态模型进展对Agent开发的影响，以及几个值得关注的应用案例和学习路径。内容偏技术向，但我会尽量把"为什么这么做"讲透，结合实际部署场景来聊，而不是只会贴概念。

适合谁来读？两类人。一类是刚接触Agent开发、正在纠结框架选型和架构设计的开发者，这篇文章能帮你把当前主流方案的边界条件理清楚。另一类是已经在做Agent应用、但总感觉哪里不对劲的朋友，比如响应慢、经常超时、一旦用户量上来系统就扛不住——大概率是架构层面出了问题，不是提示词的问题。这篇文章会讲到一些我自己踩过的坑和排查思路，希望能有点帮助。

2. 扛并发：Agent从Demo走向生产的第一道坎

2.1 为什么"并发"突然成了Agent的生死线

先说个现象。我在不少技术群里看到有人晒自己做的Agent应用：能联网搜索、能调用工具、能记住对话上下文，看起来功能很全。但一上线，问题就来了——同时进来20个用户，系统直接卡死，或者响应时间从2秒变成30秒。这种情况不是因为模型不好，也不是因为代码写得烂，而是因为Agent的运行模式和传统Web服务完全不一样。

传统Web应用，一个请求进来，处理完返回，请求之间基本是隔离的。但Agent应用不一样，一个用户的一次任务，可能涉及多轮模型调用、多次工具调用、多步推理。每一步都会消耗Token，每一步都有网络延迟和模型推理时间。我把这个差距打一个比方：普通Web接口是一辆公交车，上来一拨人拉走就完事；Agent应用是一个导游带团，要不断确认路线、安排车、处理突发状况。同样的时间，导游只能带一个团，你要让他同时带100个团，不加人手就必然乱套。

所以"Agent扛并发"的本质问题，并不是简单的加机器、加负载均衡就能解决的。它涉及几个层面的改造：

• 请求本身就是长任务，不是普通HTTP请求能直接覆盖的
• 底层依赖的模型推理API有速率限制，不能无限发请求
• 工具调用的延迟不可控，外部API一慢，整个Agent就跟着慢
• 上下文管理和记忆存储会成为瓶颈，尤其是会话历史长的场景

这周讨论热度最高的几个帖子，基本都围绕这四层在聊。明白了"为什么难"，再谈"怎么解"才有意义——如果连问题本质都没搞清楚就盲目上K8s、搞自动扩缩容，大概率是花了钱但问题依旧。

2.2 从同步到异步：Agent服务化改造的核心路径

我这一周看了几个做得比较扎实的案例，包括基于FastAPI+LangChain+LangGraph的落地组合，也有一些团队直接用Spring AI搭了企业级方案。虽然框架不同，但架构设计的思路是高度一致的：把同步的Agent执行流程，改造成异步的任务队列模型。

这里面最核心的动作，是把"一次用户请求"拆成"一个任务"。用户发来请求后，系统立刻返回一个任务ID，然后把Agent的实际执行逻辑丢到后台异步队列里去跑，执行完成后通过Webhook、轮询或者SSE流式推送把结果返回给前端。这样做的好处很直接：用户侧不用干等，后端可以根据任务量动态调度资源，某个Agent实例卡住了也不影响其他任务继续执行。

用FastAPI+LangGraph做这个改造其实并不复杂。LangGraph本身就是一个面向Agent工作流的状态机框架，天然适合把执行过程拆成多个节点。配合Celery或者Redis Stream做任务队列，把LangGraph的编译结果丢到Worker里去执行，就能实现基本的异步化改造。我在实操中的做法通常是这样的：FastAPI层只负责接收请求、创建任务、返回任务ID，真正干活的Worker进程负责实例化LangGraph的StateGraph、跑完整的Agent执行流程、把结果写回指定的存储位置。这样一个Worker挂了，任务还在队列里，重启后可以接着跑，不会丢请求。

这个方案的踩坑点也很明确。Celery的任务超时时间要好好调，因为一个Agent任务跑几分钟很正常，默认的几秒钟超时肯定不够。还有任务幂等性——同一个任务被重复执行的时候，不能让外部API调用在副作用上重复发生，否则用户可能收到两笔扣款通知或者两条已发送的消息。这些细节，网上教程很少讲，但生产环境里全是坑。

2.3 工程化的几个关键参数与配置思路

关于并发，其实有几个参数是可以在配置层面直接落地的，我把这周大家讨论比较多的整理成了一个表格，方便对照参考：

这几个参数之间其实是联动的。我见过一个团队，把Worker并发数调到很高，以为能提升吞吐，结果把模型API的速率限制打爆了，大量请求返回429，重试又把Agent的执行时间拉长，整体吞吐反而掉了50%。所以并发调控的关键不是单一参数，而是整条链路的协调。简单来说：先算模型API能扛多少，再反推Worker数量，再根据Worker算队列长度，层层往下推，才是靠谱的思路。

另外一个容易被忽略的点是上下文管理。Agent在有状态的场景下运行，状态存在哪里、怎么扩展，决定了你系统最后能扛多大的会话规模。如果所有会话状态都丢在内存里，一旦进程重启全部丢光，而且多实例部署时状态还不共享。这周的讨论里比较一致的看法是：会话状态应该独立存储（Redis或专门的状态数据库），Agent实例只负责跑流程，不负责记忆。这样并发扩容才不会遇到状态孤岛的问题。

3. 主流架构与框架选型，别被技术名词带偏

3.1 LangGraph、Spring AI、Rust三股势力的定位差异

这一周"AI Agent主流架构"这个词被搜了很多次。说实话，架构这个词有点大，落地说其实就是两件事：第一，Agent的执行流程怎么编排；第二，Agent怎么和你现有的业务系统集成。围绕这两个问题，现阶段基本形成了三股力量。

第一股是LangGraph领衔的Python生态。LangGraph的核心理念是把Agent拆成图：节点是处理逻辑，边是流向。状态通过图在各节点间传递，开发者可以精确控制每一步做什么，什么时候停下来等用户确认、什么时候调工具、什么时候结束。跟早期的LangChain相比，LangGraph对复杂流程的把控力强了一个量级，这也是为什么这周的讨论里，FastAPI+LangChain+LangGraph会被认为是中小团队最常见、最稳妥的落地组合——生态成熟、易于调试、社区资料多。

第二股是Spring AI。Spring AI近两年在企业级开发里渗透很快，核心卖点不是它比LangGraph功能强，而是它完美融入了Java/Spring生态。对于已经用Spring Cloud搭了一整套微服务的团队来说，引入Spring AI几乎零成本，鉴权、配置中心、网关、链路追踪全都能复用现有组件。这周社区里聊到的一个观点我比较认同：Spring AI最大的价值不是技术栈本身，而是它降低了Agent入驻现有企业架构的摩擦系数。

第三股是以Rust为代表的高性能路线。用Rust写Agent，这周被反复提及，热度挺高。Rust做Agent的优势在于：内存安全、高并发能力强、资源占用低。对于延迟敏感、需要极致吞吐的场景，Rust确实有不可替代的优势。但劣势也很明显——开发效率比Python低不少，生态也不够成熟。我看了几个Rust写Agent的开源项目，目前最多能做到调用主流模型API、跑一些简单工具链，真要实现LangGraph那套复杂的图编排和状态管理，还需要大量造轮子。

这三股力量定位差别很明显：LangGraph适合快速迭代、流程复杂的场景，Spring AI适合企业存量系统的嵌入，Rust适合对性能和资源消耗要求极致的基础设施层。我的建议是别神话任何一个框架，结合自身团队能力来选。

3.2 FastAPI+LangChain+LangGraph：中小团队最常见的落地组合

这一周"让AI真的下地干活：基于FastAPI+LangChain+LangGraph的AI Agent实战"被多次提及，说明这套组合已经是当前Agent开发的事实标准之一。我详细拆一下这套组合为什么能打。

FastAPI负责接口层，它的异步特性天然匹配Agent的长任务场景。FastAPI基于Python的asyncio，一个进程可以同时处理大量并发连接，配合前面说的异步任务队列，能很好地承接用户请求和任务调度。LangChain负责组件层，提供模型调用封装、工具接入、Prompt管理这些基础能力。LangGraph负责流程层，把Agent的思考、调用、决策编排成图结构，让复杂的执行逻辑变得可观测、可控制、可恢复。

我这一周正好看到一个很典型的实战案例，是一个自动化内容发布Agent。流程大概是：用户输入一个主题，Agent先调用大模型生成内容框架，然后调用搜索工具获取参考资料，再调用内容生成模型产出完整内容，最后调用内容平台API完成发布。整个流程如果用普通的顺序代码写，每一步的中间状态处理、失败重试、人工审核介入都会非常痛苦。但用LangGraph把每个环节定义成节点，节点间通过共享状态传递数据，就能优雅地解决。

这套组合的落地上手门槛并不高，但要跑稳需要注意几个细节。第一个是LangGraph的状态Schema定义。状态是Agent流程的记忆，定义得太松会导致数据失控，定义得太严又会导致某些工具返回的数据塞不进去。我的经验是先分析Agent流程里哪些数据是必须跨节点传递的，只把这些放进状态里，中间过程的临时数据不要进状态。第二个是工具调用的错误处理。LangGraph里工具返回异常会导致整个流程中断，建议在每个工具节点外面做一层封壳，捕获异常后返回一个规范化的错误信息给模型，让模型决定是重试还是告知用户失败原因。

3.3 选型决策树：什么时候上Rust，什么时候用Spring

我发现很多朋友在群里问"到底学哪套框架"、"Rust写Agent是不是未来趋势"之类的问题。这类问题其实没有标准答案，因为不同团队的处境完全不同。我试着画了一个选型思路，不是严格意义上的决策树，但能帮你在做技术选型的时候理清思路：

1. 如果是从零开始、需要快速出Demo或者验证业务可行性 → 直接选Python生态：FastAPI+LangChain+LangGraph，社区资源和踩坑经验最多。
2. 如果团队现有技术栈是Java为主、系统重度依赖Spring全家桶 → 优先考虑Spring AI。它能嵌入现有微服务体系，不用双线维护两套技术栈。
3. 如果对单实例性能和延迟指标有极致要求（比如高频交易信号、实时监控预警） → 可以关注Rust方案。但要有心理准备，开发周期可能是Python方案的2-3倍。
4. 如果做的是个人项目或小工具，只追求快速好用地跑通功能 → 不必纠结框架，直接用模型API官方SDK加一个Python脚本就够了。很多个人场景用不上一整套Agent框架。

这周还有人在讨论"个人使用AI Agent可以做期货交易吗"——这类场景就是典型的第4种，先跑通、再优化。我自己见过有人用Python脚本加一个简单的循环，定时拉取行情数据，让模型判断是否触发报警，然后推送通知到手机。这个场景完全不需要Agent框架，几行代码就够。但如果要做自动化下单、风控、实时盯盘，那就需要更复杂的架构了，而且期货交易本身对延迟极其敏感，这种场景下Rust的性能优势才会真正体现出来。

选型这件事，我一直秉持一个观点：技术方案不是越先进越好，而是越匹配越好。先想清楚你的业务形态和团队能力，再去选框架，顺序不能反。反过来先挑了框架再去适配业务，大概率会做得很别扭。

4. 多模态大模型进展，Agent落地的"地基"在变

4.1 多模态2026年的几个关键变化

这周"多模态大模型最新进展2026"这个关键词热度很高，配套出现的是"AI智能体应用案例"。我梳理了一下，2026年多模态模型有四个变化对Agent开发影响极大。

第一个变化是图文输入已经是标配。现在的多模态模型不光能理解文字，还能看懂截图、文档、流程图、甚至手绘草图。这意味着Agent的能力边界大幅扩展了——以前需要单独写OCR、写图像理解模块的活儿，现在模型直接原生支持。比如"让AI真的下地干活"的场景里，Agent可以直接读取系统截图来感知当前页面状态，实现了真正的"看得见"。

第二个变化是视频理解开始进入商用阶段。模型能够从视频流中提取关键信息，这意味着Agent可以处理"监控视频分析"、"直播内容摘要"这类任务。这一周有团队在讨论把多模态Agent用在生产车间的视觉质检场景——摄像头拍摄生产画面，Agent实时识别缺陷并触发告警。这种场景在以前要单独训练一个视觉模型，现在用通用多模态Agent加提示词就能搭出原型。

第三个变化是音频和语音的融合更强了。模型不仅能把语音转文字，还能直接理解语音中的情绪和意图、输出带情感的语音回复。这让语音交互类Agent的体验上了一个大台阶，不再是那种冰冷的问答机器。

第四个变化是原生多模态的统一建模。以前的多模态方案大多是"图文分别处理完再接在一起"，现在的主流趋势是统一Transformer架构，模型从预训练阶段就用图文对联合学习，对跨模态的理解更深。反映在Agent体验上就是：给它一张图加一段文字描述，它能理解得更全面，幻觉率明显下降。

4.2 Agent在内容自动化、交易辅助等场景的落地细节

这周的热搜词里有两个挺有意思的应用场景：一个是"让小红书自动发消息"，一个是"个人使用AI Agent做期货交易"。这两个场景恰好代表了Agent应用的两个典型形态：内容自动化和决策辅助。

内容自动化场景是最容易跑通的Agent方向之一。以"小红书自动发消息"为例，实际的Agent流程大概是：从RSS或者其他信息源抓取热点话题 → 调用模型生成符合平台风格的内容 → 通过平台开放API自动发布 → 定期抓取互动数据反馈给模型做优化。这里面容易踩的坑其实很多：平台接口限流、内容审核不一致、发布频率过高触发风险控制等。我的建议是这类Agent一定要加一个人工审核节点，尤其早期阶段，不要全自动发布。让Agent生成候选内容，人拍板确认后再自动化发布，既提升效率又规避风险。

交易辅助类场景则完全不同。我看到有人在讨论"用AI Agent做期货交易"，首先得说，这个场景的复杂度和风险都比内容自动化高好几个数量级。即便只做辅助分析，Agent也需要处理实时行情流、技术指标计算、新闻情绪分析、风险事件监控等多路数据。这里有个容易被忽略的工程细节：数据源的时间对齐。期货行情毫秒级的变动，如果数据源时间戳没对齐，分析结论就有可能是错的。这周有讨论提到这个点，我深以为然——很多个人做的交易分析Agent跑出来的信号不准，不一定是模型能力问题，而是数据管道本身的脏活没干利落。

另外，交易场景对Agent的执行速度要求很高。如果用Python写Agent，加上模型推理的延迟，从"发现信号"到"通知到人"可能已经过了好几秒，对高频场景而言早就没意义了。所以交易类Agent比较合理的形态是：用高性能语言写信号检测层，用大模型做辅助决策和归因分析，用消息队列隔离这两层的节奏，而不是让大模型包揽所有环节。这也是前面聊到Rust Agent的一个实际切入场景。

4.3 从"能用"到"好用"：Agent产品化的三个观察

这一周关于AI智能体应用案例的讨论里，有几位做产品的朋友分享的实战经验很实在。我把他们的观点结合我自己的观察，整理了Agent产品化过程中的三个关键变化。

第一个观察是：Agent的判断力正在从"选工具"走向"定义问题"。早期的Agent应用，用户必须自己把需求说得很完整，Agent只是帮忙调用几个工具。但现在讨论得比较多的产品形态，是用户丢一个模糊的目标进来，Agent自己去拆解问题、规划步骤、选择工具甚至自主决定中间遇到障碍时该怎么调整策略。这个转变对产品设计的影响非常大——产品不再是一个"命令执行器"，而是一个"自主工作流引擎"。

第二个观察是：记忆机制开始分层。早期Agent的对话记忆就是简单的历史记录拼接。现在主流的设计会区分工作记忆、长期记忆和跨会话的语义记忆。工作记忆管当前任务上下文，长期记忆存用户偏好和历史习惯，语义记忆用于支持跨场景知识迁移。三者用不同的存储技术和处理策略，成本能被有效控制。这一周有帖子专门讨论Agent的Token问题——记忆长期堆积会显著拉高Token消耗，分层记忆是控制这个问题的关键解法。

第三个观察是：系统的可观测性成为刚需。当Agent从"一段代码"变成"一个系统"之后，运行过程中每一步发生了什么、模型为什么做这个决策、哪个工具调用拖慢了速度，都需要对开发者透明。这周多个讨论里都提到Agent tracing和日志可视化的必要性。我的建议是引入Agent专用的可观测工具，把模型调用、工具调用、Token消耗、耗时这些指标都埋点收集起来，这样出问题的时候不用猜，直接看数据就能定位。

5. Agent开发实战问题与排查经验分享

5.1 Token到底怎么算，为什么总超限

这周"AI Agent token是什么意思"上了热搜，说明有不少新手在这个概念上栽过跟头。Token这个概念说简单也简单，它是大模型处理文本的基本单位，一个Token大概是0.75个英文单词或者0.5个汉字。但实际开发中，Token的消耗量极其容易超预期。

我来算一笔账大家就清楚了。假设你搭了一个带工具调用的Agent，用户的提问占100个Token，Agent要把它重写并规划步骤，产生200个Token；然后它要调用一次搜索工具，把搜索结果塞回上下文，可能又是2000个Token；接下来要调用大模型基于搜索结果生成回答，输出500个Token；如果这次对话要保存历史，下一轮把上面的内容加上历史再跑一遍……单轮简单的交互可能就消耗3000-4000个Token。实际开发中，Agent会自动进行多轮推理，模型在内部"思考"的过程也要消耗Token，这类隐藏消耗经常占运行总成本的一半以上。

排查Token超限的思路有三个方向。第一，检查是否在每次模型调用时都塞入了完整的历史记录。第二，检查工具返回的内容是否被截断。很多工具返回的原始数据非常大——比如网页抓取动辄几万字——如果原样塞给模型，Token瞬间就爆了。第三，检查上下文窗口设置是否合理。如果模型支持的上下文窗口是128K，但你实际只需要8K，那过大的配置参数会带来更高的成本甚至超限风险。

实操建议是：给Agent加一个Token用量记录的中间件，每次模型调用都记录消耗并打点。这样你就能看到每个环节吃掉了多少Token，然后针对消耗最高的环节做优化。另外，工具返回的内容可以做摘要化处理，用一个小模型先把工具返回的大量文本压缩成关键要点，再交给主模型做推理。这个做法实战中很有效，能减少60%-70%的工具类Token消耗。

5.2 部署与运维的常见坑

这一周"AI Agent部署"的话题热度一直没下来。不少人Demo跑得欢，一到部署就各种翻车。我总结几个典型的坑，都是我亲眼见过甚至自己踩过的。

第一个坑是依赖管理失控。Python Agent项目通常依赖很多包，LangChain、LangGraph、FastAPI这些库的版本迭代快，相互之间的兼容性经常出问题。解决方案是容器化部署时锁死基础镜像版本，依赖全部用锁定版本安装，不要用"装最新版"的策略。AI项目尤其要注意pydantic这个库，它跟LangChain/LangGraph的版本联动比较多，一升级就容易搞出莫名其妙的类型校验错误。

第二个坑是模型API密钥的环境隔离。很多人把API密钥直接写在配置文件里，代码不小心推到公开仓库，密钥就泄露了。正确的做法是用环境变量或者密钥管理服务，不同环境（开发、测试、生产）用不同的密钥，权限控制到最小。我见过一个团队因为测试环境密钥泄露，被刷了几万块的账单才反应过来。

第三个坑是Agent的冷启动问题。如果部署在Serverless环境，第一次请求要冷启动模型加载、初始化LangGraph图结构，耗时可能高达几十秒。如果前端直接等答复，用户体验会很崩溃。解决方案是提供健康检查接口定时预热实例，或者在部署配置里设置最小实例数，让实例保持热状态。

5.3 学习路线的"顺序感"

"AI Agent学习路线"、"AI应用开发学习路线"、"运维工程师AI学习与应用"这几个词这周热度都不低，说明很多人在规划学习路径。我的学习路线建议和市面上大部分教程的排序不太一样，我认为核心顺序应该是：先懂业务场景，再懂工程架构，最后才碰算法和模型。

具体拆开是这样的。第一步，先选一个具体场景，比如做一个"自动整理邮件并生成待办事项"的Agent。不用选太复杂的，核心是把Agent跑通。第二步，学编排框架，把Agent的流程做结构化，学会用图的方式表达"如果条件A则做B否则做C"。第三步，学工程化能力：异步处理、任务队列、状态管理、服务部署、日志监控。这步是很多自学的人跳过的，但恰恰是最影响实战的环节。第四步，才根据具体需求，回头去补模型侧的细节知识，比如上下文窗口原理、微调、RAG等。

对于运维工程师来说，"AI应用学习"的切入点可以更聚焦在部署架构上。运维同学不需要从零开始学写提示词，而是把大模型服务和Agent应用当作新的业务负载来管理——学习模型API的监控指标、容器化下的GPU调度、模型服务的健康检查、安全访问控制这些东西。我认识一位运维朋友，他就是从"如何给Agent应用设计一套完整的可观测方案"切入的，结果在团队里成了Agent项目落地的关键角色，因为Agent这东西太需要运维积累的经验了。

5.4 别忽视"脚手架"类Agent的可用性工程

这周的热搜里还有几个关联词，比如"Spring AI Agent"、"用AI Agent开发Django"、"程序员AI应用"，这些词背后是一个共同的趋势——开发者开始拿Agent当生产工具来改自己的开发流程。这类Agent我称之为"脚手架Agent"，它们不直接面对终端用户，而是帮助开发者写代码、查问题、做重构、补测试。

这类Agent的可用性工程比功能实现更值得关注。我见过不少开发者兴致勃勃地写了一个帮自己Review代码的Agent，结果因为"误报率"太高——一会儿说这有Bug一会儿说要重构——最后弃用。这里面的核心矛盾是：模型给出的建议需要被信任，而信任的建立需要极高的准确率。

解决思路是降低Agent给出大判断的频率、提高小判断的频率。比如不用Agent直接说"这段代码有问题"，而是让它做"这段代码里出现了哪些重复模式、这些模式通常对应哪些风险点"，然后让开发者自己决策。当Agent从"决策者"降级为"信息增强器"，它的实际可用性反而提升了。这是我实战中感触最深的一个经验，值得拿出来分享。这个思路其实也适用于所有Agent类应用——产品的价值不完全取决于模型"想得对不对"，更取决于系统设计能不能让使用者信任它。

6. 实操心得与后续建议

这篇文章写了挺长，最后不做什么总结了，就分享几点我自己的真实体会。

第一个体会是：Agent开发正在从"写代码的活"变成"做架构的活"。以前做一个Agent应用，亮点在提示词写得多巧、工具调得多顺。现在决定一个Agent应用能不能活下去的，是异步架构、状态管理、并发控制、可观测性这些工程问题。这周的讨论热度分布已经说明了一切——"怎么扛并发"的帖子永远比"怎么写提示词"的帖子更热闹。这不是说提示词不重要，而是说它已经不值得占用一个团队大部分精力了。

第二个体会是：多模态能力会让Agent的"作业面"快速扩张。图文视频音频都打通以后，Agent能干的活比纯文本时代多了好几个量级。但多模态任务的工程复杂度也更高。给我的建议是，尽早把多模态能力进入你的Agent架构设计里，哪怕当前版本用不上，也需要在扩展性和数据输入设计上预留好接口。

第三个体会在选型上：不要在一个方案上赌死。我发现一个比较稳妥的打法，是用Python生态快速验证业务、用Java生态做企业系统集成、用Rust做性能敏感的基础组件。三者不是互相替代的关系，而是一套组合拳。当然这是针对有一定规模的团队而言的。个人开发者或者小团队，把Python这套玩熟就够了，等业务量上来了再逐步引入其他技术栈。

最后一个建议，也送给正在看这篇内容的朋友：做Agent项目，从开始就建好日志和监控体系，不要等出了问题再补。Agent系统的排障成本比传统系统高得多——因为错误可能出在提示词、模型调用、工具返回、状态管理任何一个环节。没有日志，你连猜都无从猜起。这一周的热搜词里有一句我很喜欢："让AI真的下地干活"。下地干活的前提，是你能看到它在干什么、干得好不好、卡在了哪里。可观测性，就是这双眼睛。