分类为“AI技术”的页面如下
如何在不确定的大模型上,构建可靠的系统?——读《Agent 设计模式》
大模型的本质是预测下一个 token,它是概率性的。同样的输入,可能给出不同的输出;它会一本正经地胡说,也会在关键时刻掉链子。可我们偏偏想用它来搭建可靠的系统——能被信任、能上生产、能对结果负责的系统。
这就是横亘在整个 Agent 工程面前的核心命题,也是这篇文章的主线:
如何在不确定的大模型之上,构建确定性的可靠系统?
Harness 工程:当大模型变成 CPU,谁来写这个操作系统
为什么同一个 MiniMax-M3,接到 Claude Code 和 Workbuddy 上跑同一个任务,输出会完全不一样——语气不同、结构不同、深度不同、有没有抓到关键风险点都不同?
第一反应大概会怪模型。但模型从来没有变过。
变的是模型外面那一整套"包装"——业内有个正式名字叫 AI Agent Harness。
大模型是如何一步步提升回答质量的
用户点了 👎,反馈"答错了"。接下来该改什么?
这是每个做大模型产品的人每天都会遇到的问题。多数团队第一反应是"换更强的模型"或者"加更多 prompt",但这两条路都偏题。大模型答错是一个链路累积误差问题,工程上要做的是:先归因,再定位,最后在最优的那一层修。
这篇文章不讲玄学技巧,给一套可直接落地的优化框架。
Sequential Thinking MCP:CoT 时代的一个过渡性 MCP Server
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),就是这个"带徒弟"的过程。
腾讯混元 Hy3 深度解析:295B MoE、快慢思考融合、Agent 能力跃升
2026 年 4 月 23 日,腾讯混元发布并开源 Hy3 preview;7 月 6 日正式版(GA)上线,Agent 任务解决率跃升至 90%,ClawEval pass³ 拿到 68.5,超过 DeepSeek V4 Pro 的 62.4。本文围绕架构、创新点、性能表现和差异化四个维度,做一次系统梳理。
意图识别两条路:SLM 微调与 LLM Function-calling 横评与选型指南
意图识别(Intent Recognition)这件事,在 NLP 圈子里干了十几年,本来快成"已解决"的问题了。结果 2024 年 LLM Function-calling 起来之后,又被翻出来重新讨论——意图的边界变大了:以前只要分到 20 个固定类别,现在每个意图对应一个工具调用、一段 API 参数,甚至一个 Agent 子任务。
更关键的是多轮对话成了主流形态:用户说"查一下我上个月从深圳飞北京的那张机票,能改签到下周三吗?",这一句话里有"查询订单 + 修改订单"两个意图,还要继承上文的"深圳-北京"实体。多轮场景下的意图识别,跟单轮完全是两个问题。
本文从多轮对话视角出发,对比两条主流路线:微调 SLM(小语言模型)与LLM Function-calling + 结构化输出,最后给出选型决策树和混合架构。
从 CoT 到 ToT:大模型推理的思维进化与剪枝策略
过去一年,推理大模型(OpenAI o 系列、DeepSeek R1 等)让所有人见识到了"慢思考"的威力。但这场革命的源头,要从两条看似独立的技术路线说起:一条让模型学会调用工具,另一条让模型学会多路线探索。两条路线最终在 ToT(Tree of Thoughts)架构下合流,并靠剪枝策略解决了最棘手的组合爆炸问题。
OpenClaw ACP 会话:如何让 AI Agent 协同工作
你有没有想过,让 AI Agent 去调度其他 AI Agent(如 Claude Code、Codex)来协同工作?听起来像是科幻片的设定,其实在 OpenClaw 里已经实现了。
现代 AI 应用越来越复杂,单一 Agent 的能力往往有上限。想象一下:你需要一个 Agent 做代码审查,另一个做性能分析,还有一个负责汇总报告——这时候,Agent 之间的协同工作就成了刚需。
深度拆解:AI Agent Harness 的构造【译】
本文将深入探讨 Anthropic、OpenAI、Perplexity 和 LangChain 究竟在开发什么。我们将聊聊编排循环、工具、记忆、上下文管理,以及那些将"无状态"的大语言模型(LLM)转变为全能智能体(Agent)的底层机制。
你可能已经开发过聊天机器人,甚至可能用一些工具搭建了一个 ReAct 循环(ReAct:Reason + Act,一种让模型在行动前先进行推理的模式)。跑 Demo 的时候看着挺好,但一旦投入生产环境,系统就会开始掉链子:模型会忘记三步前做了什么,工具调用悄悄报错,上下文窗口(Context Window)里塞满了毫无意义的垃圾信息。
问题其实并不在模型本身,而在模型外围的基础设施。
Hermes Agent 如何实现自进化:一个内置学习闭环的 AI 智能体
在 AI Agent 领域,“自进化”(self-evolution)这个词已经被用滥了。大多数 Agent 框架所谓的"学习"不过是把对话历史塞进上下文窗口,或者用 RAG 检索一下相关文档。真正的自进化,是让 Agent 在不重新训练模型的前提下,从每次交互中沉淀出可复用的知识,并在未来的任务中自动调用它。
Nous Research 在 2026 年开源的 Hermes Agent 是目前少数把这个目标工程化得最系统的开源项目。它没有改模型权重,没有重新做 RLHF,而是用一套纯文本 + 外部状态的机制,把"成长"这件事拆解成四个可观测、可验证、可回滚的子系统。
一图看懂 Transformer 架构原理
Transformer 是当今大语言模型(GPT、BERT、T5 等)的基础架构,由 Google 在 2017 年论文 “Attention Is All You Need” 中提出。它彻底抛弃了 RNN 的递归结构,仅依靠注意力机制实现序列建模,在效果和效率上都带来了革命性突破。
本文通过一张架构图 + 核心公式 + 基础概念解释,帮你快速建立对 Transformer 的整体理解。
AI对劳动力市场的影响——Anthropic最新研究解读
最近Anthropic发布了一份关于AI对劳动力市场影响的研究报告,提出了一些挺有意思的发现。
核心结论
研究的核心发现很反直觉:
- AI的实际应用远低于理论潜力 — 理论可行 vs 实际使用,存在巨大差距
- 高学历白领反而更"危险" — 受AI影响最大的是程序员、客服等
- 目前失业率没有明显变化 — 但对年轻工人的招聘已放缓
RAG 召回率优化的主路线:Hybrid + Rerank + 强 Embedding 三件套
2023 年做 RAG,大家讨论的还是"Embedding 模型选哪个"、“要不要上 ColBERT”。2024 年话题变成了"Hybrid Search 到底怎么打分融合"。到了 2026 年,画风基本定了——
生产环境的 RAG 召回优化有三件套:强 Embedding 模型 + Hybrid Search + Rerank 精排。Query 改写、HyDE 这些"技巧"不是没用,而是从"主菜"降级成了"配菜"。
上一篇文章讲了 HyDE 这种"答案侧"技巧,今天这篇文章讲 2026 年的"主路线"。
RAG 召回率提升的另一条路:HyDE 让问题先伪装成答案
跑过 RAG 的同学大概都踩过这个坑:用户问"我的订单怎么取消?",向量库里明明有那段"如需取消订单,请前往’我的订单’页面……",但召回就是捞不回来。
问题出在哪?问题和答案在向量空间里隔得很远——“取消"虽然两边都有,但问句的语气、词汇结构、隐含的主语省略,都让它和那段陈述句形态的答案距离不近。BM25 兜不住(关键词只有两个字),向量检索也兜不住(语义结构差太大),怎么解?
HyDE(Hypothetical Document Embeddings) 就是专门处理这道题的。
从代码到知识:Graph RAG 如何打通「知识孤岛」
你是否有过这样的困惑?
明明记得某个知识点在某篇文章里,可当你需要它的时候,搜索引擎只能给你一堆关键词匹配的碎片。传统RAG(检索增强生成)就像一个"记性不好"的助手——你问什么,它从海量文档中找最相似的段落,但它不懂知识之间的关系。
而这恰恰是Graph RAG要解决的问题。
⚠️ 特别说明:本文是对 Graph RAG 概念的解读,源自对 AST-ASG-Graph-RAG 项目 README 的研究。该项目主要在探讨概念本身,而非一个完整的产品解决方案。
企业知识库问答 RAG:腾讯云原子引擎实战
把 RAG 链路拆开看,每一步(解析、拆分、Embedding、检索、重排)都有可以替换的实现。腾讯云知识引擎原子能力做的事情,本质上是把这些环节单独抽成高质量的 API,让开发者按需组合。
这篇文章不是入门教程,而是面向已经理解 RAG 全流程的 AI 应用开发者,重点聊在企业知识库问答场景下,怎么用这套原子能力,以及几个真实的取舍。
深度解析 OpenViking —— 字节跳动开源的 AI 上下文数据库
在 LLM(大语言模型)应用开发中,如何处理海量的、碎片化的上下文数据是开发者面临的最大挑战。字节跳动火山引擎团队开源了 OpenViking,这是一个专门为 AI Agent 和 RAG 场景设计的上下文数据库。它不仅继承了字节内部支撑抖音、豆包等产品的自研向量检索技术,更针对 AI 原生应用的需求进行了深度优化。
向量查询之跨语言语义搜索原理
用知识的摘要进行向量化查询的方式,找到相关知识。一篇英文的知识,也能找到相似的中文知识,这是为什么?
这是一个非常深刻且触及了现代自然语言处理(NLP)核心原理的问题。简单来说,之所以英文的摘要能搜索到中文的知识,是因为在向量化的世界里,语言不再是隔阂,“含义”(Semantics)才是坐标。
这种技术通常被称为跨语言语义检索(Cross-lingual Semantic Search)。其背后的原理可以拆解为以下几个关键层面:
RAG 精排算法全景:7 种 Rerank 方法的工程对比
RAG(Retrieval-Augmented Generation)的"检索"二字,背后是一整条工程流水线——从用户 query 出发,经过粗排、召回、精排、选样四步处理后,才把 top-K 文档喂给 LLM。这条流水线上每个环节都有专门的算法优化,但最容易出效果、也最容易被忽视的,是中间的Rerank 阶段。
本文用一张全景图把 RAG 检索流水线串起来,然后按"相关性、多样性、时效性"三个维度,对 7 种主流 Rerank 算法做横向对比。
RAG 核心:Embedding、向量检索与 Rerank
什么是 RAG?
RAG(Retrieval-Augmented Generation,检索增强生成)是大模型应用的核心架构。它通过"检索+生成"的两阶段模式,让 AI 能够利用私有知识库回答问题,而不是仅依赖模型内部的训练数据。
ReAct 论文解读:在语言模型中协同推理与行动
ReAct(arXiv 2210.03629)是姚顺雨 2022 年 10 月发表、2023 年 5 月在 Kigali 的 ICLR 2023 Oral(Notable Top 5%)上正式宣读的论文。它解决的问题很朴素:让大语言模型在同一个轨迹里同时"想"和"做"。在此之前,Chain-of-Thought(CoT)和"只行动"(Act-only)是两条互不往来的研究脉络,ReAct 是第一条把它们显式缝合起来的路径。