俗话说，一图胜千言。日常工作中，当我们要表达自己的设计思路的时候，会画各式各样的图。但因为各自知识储备的差异，思维的差异，不同类型的系统侧重的架构设计点也不一样（C端高并发系统、B端复杂业务系统、大数据离线系统、流式计算系统、机器学习系统、客户端系统），导致在日常方案表达与沟通中，所画出来的图”五花八门“，没有一个相对标准化、通用的”技术方案沟通语言“，这给沟通带来歧义，同时也不利于个人的思维提升，不能形成一个体系化的思考方法。 本文综合了自己多年的架构设计实践和业界众多的软件工程方法论，总结出一个相对通用的“技术方案沟通语言”。思维即语言，语言即思维，一切不能用“语言”表达的思维，只能说明没思维。 更详细介绍，还可以参见作者出版的书籍《软件架构设计：大型网站技术架构与业务架构融合之道》
2025 年是 AI 智能体快速爆发的一年，从单智能体、多智能体到通用智能体的多种不同构建模式持续涌现出来，智能体开发也逐步从概念、Demo 开始走向生产落地，应用范围也从编程助手等几个少数领域，逐步拓展到企业内部业务、生活工作助手等多个领域。随着智能体开始在企业内部业务落地，Java 智能体的构建需求也呈现出爆发式增长的趋势，在智能体编程语言及平台领域，Python、Typescript 一直走在探索前沿，相对来说，Java 领域框架、平台及整体解决方案欠缺，Spring AI Alibaba 1.0 的发布，让 Java 智能体开发迎来一款生产可用的企业级框架与解决方案，助力企业智能体开发进入一个新阶段。上半年，以 Manus 为代表的通用智能体的火爆，让具备自主规划能力的通用智能体进入大众视线，另一方面，MCP 则将模型或智能体外部数据、外部系统的交互方式做了统一。结合这些技术趋势，在探索 Spring AI Alibaba 框架、Manus 通用智能体的过程中，我们正逐步构建起一套零代码快速构建垂直领域智能体的方案（JManus），我们相信它能弥补低代码、高代码框架的开发复杂度
在2025上海AWE焕新消费节的家享生活展馆中，3D数字导购「小淘」以近乎真人的形态与观众自然互动，生动诠释了淘天Meta技术团队最新技术——TaoAvatar的革新力量。这项融合3D高斯重建、AI语音驱动与端侧大模型的尖端技术，突破传统数字人局限，实现从“二次元偶像”到“3D真人复刻”的跃迁。通过高精度建模、多模态交互及工业级量产方案，TaoAvatar不仅以2K级拟真视觉、90FPS流畅动效和自然语音同步技术重塑虚拟交互体验，更将制作成本压缩至传统CG的1/30，周期缩短至一周内。从家电导购到XR沉浸场景，TaoAvatar正以“真实感、智能性、普惠性”三大突破，开启数字人规模化落地的新纪元。
本文是《vivo Pulsar万亿级消息处理实践》系列文章第2篇，Pulsar支持上报分区粒度指标，Kafka则没有分区粒度的指标，所以Pulsar的指标量级要远大于Kafka。在Pulsar平台建设初期，提供一个稳定、低时延的监控链路尤为重要。
ovCompose(online-video-compose)是腾讯大前端领域 TDF 端框架 Oteam 中，腾讯视频团队基于 Compose Multiplatform 生态推出的跨平台开发框架，旨在弥补 JetBrains Compose Multiplatform 不支持鸿蒙平台的遗憾与解决 iOS 平台原生 UI 混排受限的问题，便于业务构建全跨端 App 。同时腾讯视频深度参与 Oteam 并推出了 KuiklyBase，涵盖 Kotlin/Native 的鸿蒙适配、组件生态、鸿蒙编译、堆栈还原、工具链相关建设，助力业界 KMP 开发者提高鸿蒙适配效率。ovCompose&KuiklyBase 现已在 GitHub 开源，让我们一起深入实现细节。
Ray Data是构建于Ray之上的分布式数据处理库，提供了高性能且可扩展的API，可被有效结合到AI相关场景，例如批量推理、数据预处理等。Ray Data内部通过流式执行机制来有效处理大规模数据集，并可有效的利用异构架构，不让CPU或GPU成为数据处理的瓶颈。虽然Ray Data提供了简单易用的API，但其内部实现与执行原理较难理解，二次开发与问题排查有一定的难度，因此本文从Ray Data源码入手，重点分析了Ray Data流式执行的实现原理。
人人都在聊MCP，但人们口中的MCP往往只是一个拼凑而成的幻影。如今，各大厂商纷纷为它镀金包装，就像硅谷创投圈每隔几年就热炒一次的那个“改变世界”的万能工具。然而，当最初的狂热稍退，我们不得不面对更复杂的问题：MCP真的适用于所有场景吗？它是否被赋予了过高的期待？技术史上从不缺少“神话”，而真正的进步，往往始于祛魅之后的清醒认知。
在得物技术团队双周迭代模式下，前端自动化测试体系的建设已成为提升研发效能的关键突破口。当前技术部门推行研发自测的核心诉求，其核心诉求在于通过建立可信的质量保障机制释放测试资源，以此承接更多的业务需求，提升需求吞吐率。双周迭代的机制对研发流程提出了双重挑战：既要保障两周内完成需求开发、测试验证到交付上线的完整闭环，又需保障研发交付的代码质量稳定可靠且经过充分的测试验证。服务端已通过流量回放、代码覆盖率检测等成熟方案构建质量护城河。我们统计了各个前端业务域在2025 年Q1中的自测率，服务端实际自测率为：24.45%，而前端的实际自测率仅有：15.35% 。因此，在完成技术部研发自测率25% 的目标的情况下，前端是一个较大的短板。而制约前端实际自测率提升的一个重要的因素就是缺乏像服务端流量回放和代码覆盖率检测技术这样的自动化代码质量保障技术，导致测试同学对于前端自测质量的置信度存疑，无法检测和衡量负责该需求的前端是否已经完成了足够详尽的自测。因此，如果需要提升前端的研发自测率，我们首先需要从这些质量保障技术出发，夯实地基，构建属于前端的质量保障护城河。
