大模型的本质是预测下一个 token，它是概率性的。同样的输入，可能给出不同的输出；它会一本正经地胡说，也会在关键时刻掉链子。可我们偏偏想用它来搭建可靠的系统——能被信任、能上生产、能对结果负责的系统。

这就是横亘在整个 Agent 工程面前的核心命题，也是这篇文章的主线：

如何在不确定的大模型之上，构建确定性的可靠系统？

大语言模型（LLM）的训练与部署，是一个横跨数据工程、分布式系统、GPU 架构、强化学习、推理服务等多个领域的综合工程。本文把从原始数据到线上推理的完整技术栈梳理清楚，让你对"模型是如何炼成的、又是如何跑起来的"有一个系统性认知。

为什么同一个 MiniMax-M3，接到 Claude Code 和 Workbuddy 上跑同一个任务，输出会完全不一样——语气不同、结构不同、深度不同、有没有抓到关键风险点都不同？

第一反应大概会怪模型。但模型从来没有变过。

变的是模型外面那一整套"包装"——业内有个正式名字叫 AI Agent Harness。

用户点了 👎，反馈"答错了"。接下来该改什么？

这是每个做大模型产品的人每天都会遇到的问题。多数团队第一反应是"换更强的模型"或者"加更多 prompt"，但这两条路都偏题。大模型答错是一个链路累积误差问题，工程上要做的是：先归因，再定位，最后在最优的那一层修。

这篇文章不讲玄学技巧，给一套可直接落地的优化框架。

Sequential Thinking MCP 是 Anthropic 官方 modelcontextprotocol/servers 仓库里的一个示范性 server（现已 archived）。它在 Claude 还没有原生 extended thinking 的窗口期承担了一个关键角色——把"思维链"（Chain-of-Thought, CoT）从 prompt 技巧，外化成了一个可被工具调用协议观察、干预、编排的对象。今天 Claude 的 thinking block、ReAct 循环、Tree-of-Thoughts 这些已经成为标配的设计模式，都和它解决的问题有直接血缘。

你是一家百年老店的老板。你有一位镇店的老厨师——做菜几十年，火候精准、味觉敏锐，客人赞不绝口。但问题是，他一个月薪要 5 万，切菜慢、脾气大、还时不时请假。

现在你要开分店，需要 10 个能做出 80% 味道的厨师，便宜、听话、能加班。怎么办？

最直接的方法：让他们去新东方烹饪学校重学三年。但太慢了。

更聪明的办法：让老厨师手把手带徒弟。不要求徒弟复制老厨师的一切，只要他们能学到老厨师的"味觉直觉"和"调味逻辑"——几个月后，这些徒弟就能做出味道相近、薪资只需老厨师十分之一的菜。

大模型蒸馏（Knowledge Distillation），就是这个"带徒弟"的过程。

2026 年 4 月 23 日，腾讯混元发布并开源 Hy3 preview；7 月 6 日正式版（GA）上线，Agent 任务解决率跃升至 90%，ClawEval pass³ 拿到 68.5，超过 DeepSeek V4 Pro 的 62.4。本文围绕架构、创新点、性能表现和差异化四个维度，做一次系统梳理。

意图识别（Intent Recognition）这件事，在 NLP 圈子里干了十几年，本来快成"已解决"的问题了。结果 2024 年 LLM Function-calling 起来之后，又被翻出来重新讨论——意图的边界变大了：以前只要分到 20 个固定类别，现在每个意图对应一个工具调用、一段 API 参数，甚至一个 Agent 子任务。

更关键的是多轮对话成了主流形态：用户说"查一下我上个月从深圳飞北京的那张机票，能改签到下周三吗？"，这一句话里有"查询订单 + 修改订单"两个意图，还要继承上文的"深圳-北京"实体。多轮场景下的意图识别，跟单轮完全是两个问题。

本文从多轮对话视角出发，对比两条主流路线：微调 SLM（小语言模型）与LLM Function-calling + 结构化输出，最后给出选型决策树和混合架构。

过去一年，推理大模型（OpenAI o 系列、DeepSeek R1 等）让所有人见识到了"慢思考"的威力。但这场革命的源头，要从两条看似独立的技术路线说起：一条让模型学会调用工具，另一条让模型学会多路线探索。两条路线最终在 ToT（Tree of Thoughts）架构下合流，并靠剪枝策略解决了最棘手的组合爆炸问题。

2026年6月18日，SK海力士正式宣布已向主要客户（以英伟达为主）交付12层堆叠 HBM4E 工程样品，这是目前已知业界最先进的 HBM4E 产品之一。从 JEDEC 发布 HBM4 标准规范（2025年4月）到工程样品落地，只用了一年出头，节奏远超预期。本文深入解析 HBM 家族的技术演进路径、HBM4E 的核心突破点，以及当前 SK 海力士、三星、美光三家的竞争态势。

本文将深入探讨 Anthropic、OpenAI、Perplexity 和 LangChain 究竟在开发什么。我们将聊聊编排循环、工具、记忆、上下文管理，以及那些将"无状态"的大语言模型（LLM）转变为全能智能体（Agent）的底层机制。

你可能已经开发过聊天机器人，甚至可能用一些工具搭建了一个 ReAct 循环（ReAct：Reason + Act，一种让模型在行动前先进行推理的模式）。跑 Demo 的时候看着挺好，但一旦投入生产环境，系统就会开始掉链子：模型会忘记三步前做了什么，工具调用悄悄报错，上下文窗口（Context Window）里塞满了毫无意义的垃圾信息。

问题其实并不在模型本身，而在模型外围的基础设施。

在 AI Agent 领域，“自进化”（self-evolution）这个词已经被用滥了。大多数 Agent 框架所谓的"学习"不过是把对话历史塞进上下文窗口，或者用 RAG 检索一下相关文档。真正的自进化，是让 Agent 在不重新训练模型的前提下，从每次交互中沉淀出可复用的知识，并在未来的任务中自动调用它。

Nous Research 在 2026 年开源的 Hermes Agent 是目前少数把这个目标工程化得最系统的开源项目。它没有改模型权重，没有重新做 RLHF，而是用一套纯文本 + 外部状态的机制，把"成长"这件事拆解成四个可观测、可验证、可回滚的子系统。

就像人类会做梦来巩固白天的经历一样，OpenClaw也有自己的"睡眠周期"。

如果你在用 OpenClaw 作为私人AI助手，日复一日的对话会产生大量的短期记忆碎片——哪些任务完成了、用户纠正了哪些错误、下次要注意什么。这些信号如果不做任何处理，要么被遗忘，要么塞进 system prompt 里导致上下文膨胀。

Dreaming 就是来解决这个问题的。

TradingAgents-CN-Skill 是基于 TradingAgents 框架的中文股票分析 Skill。用户输入股票截图、文字描述或股票代码，Agent 自动完成 4 位分析师 + 2 轮多空辩论 + 风控三方辩论 + 五级评级，输出完整 PDF 报告。

2006 年，NVIDIA 推出了 CUDA（Compute Unified Device Architecture）——一套针对自家 GPU 的并行计算平台和编程模型。在此之前，GPU 的职责单一，仅限于图形渲染；CUDA 的出现，使得开发者可以用熟悉的 C/C++ 语言直接调用 GPU 的算力。

大语言模型训练、深度学习推理、科学计算——这些涉及 TB 级数据处理的任务，底层几乎都运行在 CUDA 之上。本文以中立视角，剖析 CUDA 的核心设计，并透过一个实战例子展示其并行计算模型。

Transformer 是当今大语言模型（GPT、BERT、T5 等）的基础架构，由 Google 在 2017 年论文 “Attention Is All You Need” 中提出。它彻底抛弃了 RNN 的递归结构，仅依靠注意力机制实现序列建模，在效果和效率上都带来了革命性突破。

本文通过一张架构图 + 核心公式 + 基础概念解释，帮你快速建立对 Transformer 的整体理解。

上一篇《OpenClaw 的 QMD 记忆引擎：从尝鲜到放弃》里，我因为 2 核 4G 服务器跑不动 QMD 的 3 个本地 LLM 模型，切回了内置引擎。当时以为内置引擎只有关键词搜索——其实不是。

OpenClaw 有一套内置的 Memory 系统，基于 SQLite 实现，开箱即用。但对于需要更高搜索质量、更广索引范围的场景，OpenClaw 提供了一个更强大的选项——QMD Memory Engine。

本文梳理 QMD 的核心概念、架构原理、配置方法，以及它在 OpenClaw 记忆体系中的实际角色，最后与 OpenViking 方案做对比。

最近在研究 AI Coding Agent 的工程化实践，绕不开两个概念：Harness Engineering 和 OpenSpec。两者都跟 AI 写代码有关，但解决的问题完全不同。写篇文章梳理一下。

最近给 OpenClaw 装上了 OpenViking——字节跳动火山引擎开源的 AI Agent 上下文数据库。装的过程很顺，但有一个隐藏代价直到我翻官方文档才意识到，本文把这个关键点讲清楚。

AI 编程工具层出不穷，但真正的问题不是"AI 能不能写代码"，而是"如何让 AI 按照软件工程的标准流程开发"。2026 年，两个开源项目——Superpowers 和 OpenSpec——形成了一套被业内称为"黄金搭档"的开发范式。

在 AI Agent 应用开发中，如何让前端与后端 Agent 高效通信一直是个难题。AG-UI 协议的出现就是为了解决这个核心问题。本文将详细介绍 AG-UI 是什么、为什么这样设计，以及它与以往流式输出的区别。

什么是 AG-UI ？

AG-UI（Agent User Interaction Protocol）是一个开放、轻量级、基于事件的标准协议，用于规范 AI Agent 与前端应用之间的通信方式。

它由 CopilotKit 提出，来源于 LangGraph、CrewAI 等项目的生产实践经验，旨在解决 Agent 特有的交互模式问题。

最近Anthropic发布了一份关于AI对劳动力市场影响的研究报告，提出了一些挺有意思的发现。

核心结论

研究的核心发现很反直觉：

1. AI的实际应用远低于理论潜力 — 理论可行 vs 实际使用，存在巨大差距
2. 高学历白领反而更"危险" — 受AI影响最大的是程序员、客服等
3. 目前失业率没有明显变化 — 但对年轻工人的招聘已放缓

2023 年做 RAG，大家讨论的还是"Embedding 模型选哪个"、“要不要上 ColBERT”。2024 年话题变成了"Hybrid Search 到底怎么打分融合"。到了 2026 年，画风基本定了——

生产环境的 RAG 召回优化有三件套：强 Embedding 模型 + Hybrid Search + Rerank 精排。Query 改写、HyDE 这些"技巧"不是没用，而是从"主菜"降级成了"配菜"。

上一篇文章讲了 HyDE 这种"答案侧"技巧，今天这篇文章讲 2026 年的"主路线"。

对 AI 说"帮我写个用户注册功能"，它给出了一套完整的注册、登录、验证码、邮箱验证、数据库迁移脚本——然后你发现，你其实只想要一个接口。

同样是使用 AI Coding，不同开发者之间的表现差异巨大。有人能让 AI 在几分钟内完成一天的工作量，有人却总是在 AI 的错误方向上浪费半天。

本质差异不在于 AI 工具，而在于使用者的能力。 本文从三个维度评估：需求分析与拆解、编程基础与工程实践、AI 协作与交互。

跑过 RAG 的同学大概都踩过这个坑：用户问"我的订单怎么取消？"，向量库里明明有那段"如需取消订单，请前往’我的订单’页面……"，但召回就是捞不回来。

问题出在哪？问题和答案在向量空间里隔得很远——“取消"虽然两边都有，但问句的语气、词汇结构、隐含的主语省略，都让它和那段陈述句形态的答案距离不近。BM25 兜不住（关键词只有两个字），向量检索也兜不住（语义结构差太大），怎么解？

HyDE（Hypothetical Document Embeddings） 就是专门处理这道题的。

你是否有过这样的困惑？

明明记得某个知识点在某篇文章里，可当你需要它的时候，搜索引擎只能给你一堆关键词匹配的碎片。传统RAG（检索增强生成）就像一个"记性不好"的助手——你问什么，它从海量文档中找最相似的段落，但它不懂知识之间的关系。

而这恰恰是Graph RAG要解决的问题。

⚠️ 特别说明：本文是对 Graph RAG 概念的解读，源自对 AST-ASG-Graph-RAG 项目 README 的研究。该项目主要在探讨概念本身，而非一个完整的产品解决方案。

把 RAG 链路拆开看，每一步（解析、拆分、Embedding、检索、重排）都有可以替换的实现。腾讯云知识引擎原子能力做的事情，本质上是把这些环节单独抽成高质量的 API，让开发者按需组合。

这篇文章不是入门教程，而是面向已经理解 RAG 全流程的 AI 应用开发者，重点聊在企业知识库问答场景下，怎么用这套原子能力，以及几个真实的取舍。

在 LLM（大语言模型）应用开发中，如何处理海量的、碎片化的上下文数据是开发者面临的最大挑战。字节跳动火山引擎团队开源了 OpenViking，这是一个专门为 AI Agent 和 RAG 场景设计的上下文数据库。它不仅继承了字节内部支撑抖音、豆包等产品的自研向量检索技术，更针对 AI 原生应用的需求进行了深度优化。

用知识的摘要进行向量化查询的方式，找到相关知识。一篇英文的知识，也能找到相似的中文知识，这是为什么？

这是一个非常深刻且触及了现代自然语言处理（NLP）核心原理的问题。简单来说，之所以英文的摘要能搜索到中文的知识，是因为在向量化的世界里，语言不再是隔阂，“含义”（Semantics）才是坐标。

这种技术通常被称为跨语言语义检索（Cross-lingual Semantic Search）。其背后的原理可以拆解为以下几个关键层面：

TradingAgents-CN 是一个基于 LLM 的多智能体股票交易分析框架，其精心设计的 prompt 体系值得深入研究。本文完整记录该项目中的所有 prompt 设计。

RAG（Retrieval-Augmented Generation）的"检索"二字，背后是一整条工程流水线——从用户 query 出发，经过粗排、召回、精排、选样四步处理后，才把 top-K 文档喂给 LLM。这条流水线上每个环节都有专门的算法优化，但最容易出效果、也最容易被忽视的，是中间的Rerank 阶段。

本文用一张全景图把 RAG 检索流水线串起来，然后按"相关性、多样性、时效性"三个维度，对 7 种主流 Rerank 算法做横向对比。

什么是 RAG？

RAG（Retrieval-Augmented Generation，检索增强生成）是大模型应用的核心架构。它通过"检索+生成"的两阶段模式，让 AI 能够利用私有知识库回答问题，而不是仅依赖模型内部的训练数据。

ReAct（arXiv 2210.03629）是姚顺雨 2022 年 10 月发表、2023 年 5 月在 Kigali 的 ICLR 2023 Oral（Notable Top 5%）上正式宣读的论文。它解决的问题很朴素：让大语言模型在同一个轨迹里同时"想"和"做"。在此之前，Chain-of-Thought（CoT）和"只行动"（Act-only）是两条互不往来的研究脉络，ReAct 是第一条把它们显式缝合起来的路径。

跑过 RAG 的同学大概率踩过这个坑：Embedding 模型选得很好、向量库也没问题，但召回质量就是不行。

排查一圈下来，原因往往出乎意料——不是 Embedding 不行，而是用户的问题太"糙"：

"这个东西怎么用？"           ← 缺主语
"为什么我那个又不行了？"      ← 全是代词
"性能怎么样？"              ← 完全没头没尾
"a 和 b 哪个好？"           ← 缺上下文

在 AI 时代，向量数据库是 RAG（检索增强生成）系统的核心基础设施。但它究竟是如何工作的？为什么能实现"语义搜索"而非传统的关键词匹配？本文用通俗的方式解释其背后的原理。

在 AI 应用开发中，让大模型稳定地输出我们想要的格式是一个常见需求。本文介绍如何使用 LangChain 的 Golang 版本 langchaingo 实现 Prompt Template，并结合主流 LLM 的 JSON Mode 实现可靠的结构化输出。

什么是 Prompt Template

Prompt Template 是将提示词模板化的技术，通过占位符动态注入变量，让同一套提示词可以处理不同输入。类似于 Web 开发中的模板引擎。