DoneHub
0%

发表于 更新于 分类于 Valine：

2026 年 10 月 31 日晚，DeepSeek Harness 团队发布技术长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，同一时刻把一个名为 dsh-superagent-prototype 的仓库推上 GitHub，MIT 协议，TypeScript 编写。五天之后，仓库 star 数 1.92 万，fork 2186。同一个仓库只有一次提交，提交信息是一行 feat: add the dsh-superagent research prototype，216 个文件，九篇编号设计文档合计约十六万字符。

star 和 watcher 这两个数字是我从 GitHub API 取的，页面显示的数和接口返回的数还不太一样，我按接口的算了：19224 和 137。star 是收藏，看完点一下就完了；watcher 是跟踪，意味着愿意收邮件、跟进后续。137 个人留下来，其余一万九千人看完就走。issue 区关着这件事比 star 数字更说明问题，没有公开的缺陷清单、复现步骤和修复讨论，社区热度就没有办法转化成可验证的东西。

README 自己说可能有 bug，代码风格和工程实践可能不一致。放到研究原型身上这算不上丑闻，但它决定了这东西该怎么用。我把它当一份能跑起来读的架构文本来读，任何想拿它当依赖的用法都得先等等。

阅读全文 »

发表于 分类于 Valine：

2026 年 9 月 15 日，TypeSafe AI 发布了一个名叫 Jev 的 AI 模型。Jev 不是在通用模型能力上更进一步，而是在决策判定这个细分领域单开了一页。在一个所有人都在卷生成能力的时代，TypeSafe AI 选择了一条完全不同的路，专注于解决工程落地中对快速、准确且结构化的决策判定的诉求。

Jev 绝不仅仅是一个特别快、特别便宜的分类模型，它真正的目标是：AI 的输出是否可以不再是自然语言文本，而是直接成为程序控制流中的类型化值？ 所以我认为 Jev 是一种新的 AI 基础设施：判定模型（Decision Model）。

阅读全文 »

发表于 分类于 Valine：

一、问题的起点

在使用 OceanBase 的过程中，大家有几乎都遇到过一个场景：按时间范围分区的表，分区需要提前手动创建。忘记创建新分区，数据写入时直接报”找不到分区”的错误；手动建了太多分区，空分区的元数据又成了维护负担。对于日志表、订单流水表这类数据有明确生命周期的场景，DBA 还要定期清理过期分区，稍有不慎就可能导致数据丢失或线上故障。

OceanBase 从 V4.3.5 BP2 开始引入动态分区功能，试图将”分区的创建与删除”从 DBA 的日常运维中彻底剥离。需要首先澄清的是，动态分区不是一种全新的分区类型，而是在 RANGE / RANGE COLUMNS 分区之上叠加了一层自动化管理策略。理解它的设计逻辑和适用边界，比单纯掌握语法更有价值。

阅读全文 »

发表于 更新于 分类于 Valine：

一、背景

2026年8月13日，DeepSeek 正式开源了 Harness 开发者预览版。项目在 GitHub 上线一个多小时便突破 2 万 Star，一天后即突破 92 万 Star，影响广泛。
alt text
从 5 月份组建 Harness 团队，到 7 月开启内测，再到 8 月以 MIT 协议完全开源，前后不到 3 个月。这个节奏表明，DeepSeek 此次并非只是发布一个新工具，而是在产品战略上进行了一次方向性调整。

阅读全文 »

发表于 更新于 分类于 Valine：

2026 年 7 月 10 日，OpenAI 发布了 GPT-5.6。

如果只抓一个核心变化：大模型正在从聊天机器人变成能干活的智能体。过去你问它问题，它给你答案；现在你给它目标，它能自己规划步骤、调用工具、协调多个 Agent 并行工作，最终把任务完成。效率层面，GPT-5.6 在编程、知识型工作、网络安全和科学领域都交出了不错的数据，Token 用量和成本都在下降，任务完成率在上升。

阅读全文 »

发表于 更新于 分类于 Valine：

一、组件介绍

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

alt text

二、核心概念

阅读全文 »

发表于 更新于 分类于 Valine：

一、组件介绍

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。

二、核心架构

阅读全文 »

发表于 更新于 分类于 Valine：

背景

当系统从单个 Agent 进化到多个 Agent 协作，通信设计就成了决定系统成败的核心变量。系统跑起来之后，最大的挑战不是单个 Agent 的能力，而是 Agent 之间怎么高效、准确地传递信息。一个审查任务平均经过 4 个 Agent 的接力处理，每个环节的理解偏差都会在后续链路中被放大。

通信设计决定了 Multi-Agent 系统是高效协作还是各自为政。单个 Agent 像一个独立工作的程序员，能力再强也有天花板；多个 Agent 组成团队，就需要设计好沟通机制：谁向谁汇报、用什么格式交流、出了问题怎么兜底。

这篇文章从三个维度拆解 Multi-Agent 通信：拓扑（谁跟谁聊）、机制（数据怎么流）、协议（聊什么格式），然后分析工程落地中的失败模式和成本控制策略。

阅读全文 »

发表于 更新于 分类于 Valine：

过去 50 年，人机交互经历了 CLI 到 GUI 再到 Web 的演进。Shopify CEO Tobi Lütke 最近转发了一条动态，让我注意到了一个叫 flipbook.page 的实验性产品。它被描述为”一个完全按需实时生成的无限视觉浏览器”，核心理念是：你看到的每一页都是一张 AI 实时生成的图片，没有 HTML、没有 CSS、没有 JavaScript，一切皆为像素。

阅读全文 »

发表于 更新于 分类于 Valine：

背景

之前研究 Chrome DevTools MCP 的时候，解决的核心问题是让 AI 能操控浏览器。但那个方案有天然的局限性：必须配置 MCP Server、依赖 Chrome 调试端口、每个平台要单独写适配器。

OpenCLI 把这件事重新做了一遍，而且做得更彻底。它不只是让 AI 能操控浏览器，而是把任何网站变成标准化的命令行工具。GitHub 上 22K+ Stars，说明这个方向踩中了真实需求。

这篇文章讲清楚三件事：OpenCLI 是什么、架构怎么设计的、以及最核心的部分，如何在 Claude Code 等 Code Agent 里用它。

阅读全文 »