最近手里一个项目要用消息队列，正好赶上它接入 AI 这件事，然后我把 RocketMQ 重新捡起来研究了一下。五月底发布的 RocketMQ 5.5.0，把专门为 AI 场景设计的 LiteTopic 消息模型放进了开源版本，也就是社区提案 RIP-83 里定义的那套东西。我之前用 RocketMQ，跑的都是订单、日志这一类传统场景，这次看到官方针对 AI 负载专门做了消息模型，还顺手把 MCP、A2A 这些智能体协议的支持也做了，就花时间把官方文档和代码都翻了一遍。先说清楚一个容易误会的地方，RocketMQ 接入 AI，它自己并没有变成大模型，干的还是消息队列的老本行。变化主要在这套新的主题模型上，它是照着 AI 应用的通信特点做出来的。另外 LangChain、CrewAI、AutoGen、Dify 这些主流 Agent 框架也都能对接。这篇文章就说两件事：它是怎么接入 AI 的，以及对比以前的 RocketMQ，到底多解决了哪些问题。
最近各个厂商都在深入研究多智能体协作。让多个智能体工协作，各自负责一块任务，共同完成一个复杂目标。听起来逻辑很通，一个智能体搞不定的事情，多叫几个一起来干不就行了？但真正搭过的人都知道，这里面的水比看上去深。系统跑起来了，效果却未必好，有时还不如单个智能体单独干。问题出在哪？是模型不够强，还是提示词没写好，或者根本没有一套可遵循的最佳实践？
Kotlin Serialization 框架通过 @Serializable 注解提供自动序列化功能。与 Gson、Moshi 等基于运行时反射的框架不同，Kotlin Serialization 在编译期生成序列化代码，因此在类型安全、运行性能和混淆兼容性方面具有天然优势。在控制序列化格式、处理第三方类或实现动态序列化策略等高级场景中，仅靠注解往往无法满足企业级需求。本文将系统性地介绍如何创建、绑定和使用自定义序列化器，涵盖从基本实现到高级上下文序列化的完整知识体系。全文在讲解 API 用法的同时，会适度展开编译期与运行期的协作机制，以帮助开发者建立更稳固的工程化认知。
多 Agent 工作流里，真正拉高 Token 消耗的往往不是代码本身，而是长上下文在多轮请求中被反复携带。本文结合轻量云的一次真实研发实践，拆解如何通过渐进式加载、响应级批量和批量编辑工具减少不必要的模型往返。
