背景
2026 年存储芯片行业几件大事值得关注:三星市值突破新高,HBM 订单排到明年;海力士股价暴涨,成为英伟达最大 HBM 供应商;美光宣布 HBM3e 量产;长鑫存储融资成功,中国 DRAM 再获突破。这些新闻背后涉及的内存条、固态硬盘、HBM,归根结底都属于两大技术体系:DRAM 和 NAND Flash。
搞清楚这两者的区别和关系,上面那些新闻就读得通了。
“任务越复杂越该用多Agent”,听起来好像没毛病,但这句话背后藏着一个巨大的陷阱。很多人一拍脑袋就上多Agent,结果延迟爆表、成本失控、日志一团浆糊,最后发现单Agent加个工具调用就能搞定。上一篇我们聊了 Multi-Agent 系统的设计原理,今天换个角度:什么时候该用多Agent?用完之后,怎么评判这套设计到底好不好?
构建 Agent 时需要解决的一个核心问题是让它跨会话记住用户偏好、项目背景、之前犯过的错误。大部分人的做法是搞一个文件,把所有「需要记住的东西」往里塞。文件越来越大,token 成本越来越高,而且大部分内容跟当前对话根本没关系。
Claude Code 的记忆系统给出了一个反直觉的设计原则:工程量最大的部分不是「怎么存」,也不是「怎么取」,而是「什么该存、什么不该存」。
阿里云百炼 Coding Plan 官方宣称”仅限编程工具使用”,但实际上其 endpoint 基于 OpenAI 兼容协议,Java/Python 应用完全可以调用。本文分享如何用 LangChain4j 和 OpenAI SDK 突破这一限制,直接消耗 Coding Plan 额度。
如果最近关注 AI Agent 领域,可能会注意到一个新名字:Hermes Agent。它来自 Nous Research,在短短两个月内从一个小型内部项目成长为功能完备的 AI Agent 平台。这篇文章聊聊它到底有什么不一样,以及为什么值得你花时间了解。
Anthropic 开源 Claude Code 之后,社区里一个常见的疑问是:为什么不用 LangChain 或者 LangGraph?这两个框架在 Agent 开发领域已经是事实标准,跳过它们自己造轮子,总得有个理由。读完源码后,我发现这个选择背后的原因比多数人猜测的更具体。不是框架好不好的问题,而是 Claude Code 的产品形态和 LangChain 的设计前提存在根本性的不匹配。
2026 年 3 月 31 日,Anthropic 的 Claude Code 源码意外泄露。作为目前使用最广泛的 AI 编程助手之一,它的源码首次让社区有机会看到这类产品的内部实现。读完源码后,我发现它的架构设计和多数人的直觉判断有明显出入。大多数开发者最初认为它只是一个套壳 API 调用的 CLI 工具,实际代码量和工程复杂度远超这个定位。
Claude Code 没有使用 ReAct 模式来驱动 Agent 循环。这个选择在 2025 年的 AI Agent 领域几乎是反直觉的,因为 ReAct(Reasoning + Acting)已经是 LangChain、AutoGPT 等框架的默认范式。但 Claude Code 选择了 Async Generator 状态机,用一套 while (true) + state = next + continue 的结构替代了传统的思考-行动-观察循环。这个设计决策解决了 ReAct 在流式交互和故障恢复上的根本性限制。