一、背景
2026年8月13日，DeepSeek 正式开源了 Harness 开发者预览版。项目在 GitHub 上线一个多小时便突破 2 万 Star，一天后即突破 92 万 Star，影响广泛。
从 5 月份组建 Harness 团队，到 7 月开启内测，再到 8 月以 MIT 协议完全开源，前后不到 3 个月。这个节奏表明，DeepSeek 此次并非只是发布一个新工具，而是在产品战略上进行了一次方向性调整。
GPT-5.6 来了
2026 年 7 月 10 日，OpenAI 发布了 GPT-5.6。
如果只抓一个核心变化：大模型正在从聊天机器人变成能干活的智能体。过去你问它问题，它给你答案；现在你给它目标，它能自己规划步骤、调用工具、协调多个 Agent 并行工作，最终把任务完成。效率层面，GPT-5.6 在编程、知识型工作、网络安全和科学领域都交出了不错的数据，Token 用量和成本都在下降，任务完成率在上升。
JetCache 使用手册
一、组件介绍
JetCache 是阿里巴巴开源的通用缓存访问框架（开源地址），它做了一件事：用统一的 Cache<K, V>接口，把本地内存缓存和远程 Redis 缓存无缝组合起来，再通过注解、API 两种方式定义出标准的缓存协议接入层，让业务代码以最简洁的方式使用缓存。
和 Spring Cache 比，JetCache 的核心优势：
| 能力 | Spring Cache | JetCache |
|---|---|---|
| TTL（超时时间） | 不原生支持，需自定义 | 原生支持，注解上直接写 expire |
| 两级缓存 | 不支持 | 原生支持 CacheType.BOTH（本地 + 远程） |
| 缓存自动刷新 | 不支持 | 支持 @CacheRefresh，分布式全局唯一刷新 |
| 穿透保护 | 不支持 | 支持 @CachePenetrationProtect |
| 分布式锁 | 不支持 | 内置 tryLock / tryLockAndRun |
| 异步 API | 不支持 | 支持（Lettuce 客户端下真正非阻塞） |
| 统计监控 | 需第三方 | 内置 命中率、加载次数等统计 |
| 更新/删除缓存注解 | 有但功能弱 | @CacheUpdate / @CacheInvalidate 支持 SpEL |
二、核心概念
JD-HotKey 使用手册
一、组件介绍
JD-HotKey 是京东开源的实时热点 key 探测与缓存中间件（开源地址），它做了一件事：在高并发场景下，自动发现热点 key，毫秒级推送到所有应用节点的 JVM 内存中，让热点请求直接在本地内存响应，不再打到 Redis 和数据库。
经典场景：某明星突然官宣，相关商品瞬间涌入海量请求。你事先根本不知道这个商品 ID 会变热，Redis 某个节点被这些请求打得 CPU 飙升——这就是典型的不可预知突发热点。
这时候你就需要 JD-HotKey：它能自动发现这类热点，把数据”镜像”到每台应用服务器的本地内存里，后续请求直接从内存读，RT 从几十毫秒降到 < 1ms。
和直接用本地缓存（比如 Caffeine）比，JD-HotKey 的核心优势：
| 能力 | Caffeine 本地缓存 | JD-HotKey |
|---|---|---|
| 热点发现 | 手动配置，你得提前知道哪些 key 要缓存 | 自动探测，根据访问量实时判定 |
| 动态性 | 静态的，配了就一直在 | 自动加入 / 退出热点，冷了自动释放内存 |
| 多节点一致性 | 各节点独立，互不知情 | 全局统一判定，所有节点同步感知 |
| 适用场景 | 已知高频数据（如字典、配置） | 不可预知的突发热点（如秒杀、热搜） |
| 部署复杂度 | 低（纯 SDK） | 中等（需要 etcd + worker） |
| 热用户 / 热接口探测 | 不支持 | 支持（不只限 key，接口、用户也能探） |
简单总结：已知的热点用本地缓存就够了，不可预知的热点用 JD-HotKey。
二、核心架构
Multi-Agent 通信深度解析
背景
当系统从单个 Agent 进化到多个 Agent 协作，通信设计就成了决定系统成败的核心变量。系统跑起来之后，最大的挑战不是单个 Agent 的能力，而是 Agent 之间怎么高效、准确地传递信息。一个审查任务平均经过 4 个 Agent 的接力处理，每个环节的理解偏差都会在后续链路中被放大。
通信设计决定了 Multi-Agent 系统是高效协作还是各自为政。单个 Agent 像一个独立工作的程序员，能力再强也有天花板；多个 Agent 组成团队，就需要设计好沟通机制：谁向谁汇报、用什么格式交流、出了问题怎么兜底。
这篇文章从三个维度拆解 Multi-Agent 通信：拓扑（谁跟谁聊）、机制（数据怎么流）、协议（聊什么格式），然后分析工程落地中的失败模式和成本控制策略。
Flipbook 深度解析：当浏览器不再需要 HTML
过去 50 年，人机交互经历了 CLI 到 GUI 再到 Web 的演进。Shopify CEO Tobi Lütke 最近转发了一条动态，让我注意到了一个叫 flipbook.page 的实验性产品。它被描述为”一个完全按需实时生成的无限视觉浏览器”，核心理念是：你看到的每一页都是一张 AI 实时生成的图片，没有 HTML、没有 CSS、没有 JavaScript，一切皆为像素。