DoneHub

背景

做 RAG 系统的开发者，大概都会经历过这样一个过程：

Demo 阶段跑几个测试用例，效果不错。一上真实业务数据，准确率直接掉到 60% 甚至更低，用户投诉不断，自己也说不清问题出在哪。

我曾经连续三周每天晚上对着 Bad Case 分析表发呆，改了 Prompt 没用，换了大模型没用，调了 TopK 还是没用。最后发现，问题根本不在大模型那一环，而是在大模型之前的整条链路上。

这篇文章通过深度讲解四步优化，每一步都能量化地拉高准确率，最终从 60% 做到 85%。

“任务越复杂越该用多Agent”，听起来好像没毛病，但这句话背后藏着一个巨大的陷阱。很多人一拍脑袋就上多Agent，结果延迟爆表、成本失控、日志一团浆糊，最后发现单Agent加个工具调用就能搞定。上一篇我们聊了 Multi-Agent 系统的设计原理，今天换个角度：什么时候该用多Agent？用完之后，怎么评判这套设计到底好不好？

构建 Agent 时需要解决的一个核心问题是让它跨会话记住用户偏好、项目背景、之前犯过的错误。大部分人的做法是搞一个文件，把所有「需要记住的东西」往里塞。文件越来越大，token 成本越来越高，而且大部分内容跟当前对话根本没关系。

Claude Code 的记忆系统给出了一个反直觉的设计原则：工程量最大的部分不是「怎么存」，也不是「怎么取」，而是「什么该存、什么不该存」。

背景

2026年4月24日，DeepSeek 正式发布了 V4 系列模型。这不是一次普通的版本迭代，它解决了一个困扰 AI 行业多年的根本问题：长上下文的效率瓶颈。

本文将深入解读 DeepSeek V4 的核心技术创新，帮助你理解这次发布为何值得关注。

阿里云百炼 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 工具，实际代码量和工程复杂度远超这个定位。

你在手机上打开 Telegram，给 Claude Code 发一条消息，它就开始在电脑上工作。Channel 系统的本质是打破了 AI 编程助手只能在终端中交互的限制，让任何 IM 平台都能成为远程控制入口。它通过六层访问控制和权限中继机制来保障安全性，同时基于 MCP 协议实现了对多种 IM 平台的兼容。

Claude Code 没有使用 ReAct 模式来驱动 Agent 循环。这个选择在 2025 年的 AI Agent 领域几乎是反直觉的，因为 ReAct（Reasoning + Acting）已经是 LangChain、AutoGPT 等框架的默认范式。但 Claude Code 选择了 Async Generator 状态机，用一套 while (true) + state = next + continue 的结构替代了传统的思考-行动-观察循环。这个设计决策解决了 ReAct 在流式交互和故障恢复上的根本性限制。