How we built our multi-agent research system · 中文翻译
原文发布:2025-06-13 · 中文译稿:2026-05-14
本文为社区学习用途的非官方中文翻译。技术名词以括注英文原文为准;最终解释以英文原文为准。
Claude 现在具备 Research 能力,可以跨网页、Google Workspace 和各类集成进行搜索,以完成复杂任务。
这套多 Agent 系统从原型走到生产的过程,让我们在系统架构、工具设计、提示词工程这几方面学到不少关键经验。所谓多 Agent 系统,是由多个 agent(即在循环中自主使用工具的 LLM)协同工作组成。我们的 Research 功能由一个 agent 根据用户的 query 来规划研究流程,然后使用工具创建若干并行 agent 同时搜索信息。多 Agent 系统会引入 agent 之间的协同、评估和可靠性这些新挑战。
本文拆解我们用下来有效的原则——希望对你构建自己的多 Agent 系统也有用。
研究工作本质上是开放式问题:你很难事先预测需要哪些步骤。复杂话题的探索过程是高度动态、路径依赖的,你没法把固定路径写死。人类做研究时,会随着发现不断调整思路,跟着调查过程中冒出的新线索往下走。
这种不可预测性恰恰让 AI agent 特别适合研究类任务。研究需要随时调头、或顺着旁支去探索的灵活性。模型必须能自主运行多轮,根据中间结果决定下一步走向哪个方向。线性的、一次成型的流水线无法胜任。
搜索的本质是压缩:从巨大的语料里萃取出洞见。子 agent(subagents)让压缩成为可能——它们并行运转、各自拥有独立的上下文窗口,同时探索问题的不同侧面,再把最重要的 token 浓缩后回传给主 agent(lead research agent)。每个子 agent 还提供了关注点分离——独立的工具、prompt 和探索轨迹——从而降低路径依赖、支持彻底且独立的调查。
智能一旦越过某个门槛,多 Agent 系统就成为扩展能力的关键路径。打个比方:过去 10 万年里,单个人类并没有变得指数级聪明,但人类社会在信息时代变得指数级强大,靠的是集体智能和协同能力。即使是通用智能 agent,作为个体也有极限;一群 agent 能做到的事远超个体。
我们的内部评估显示,多 Agent 研究系统特别擅长广度优先的查询——那种需要同时沿多个独立方向并行调研的任务。我们发现:以 Claude Opus 4 作为 lead agent、Claude Sonnet 4 作为子 agent 的多 Agent 系统,在内部研究评估上比单 agent 的 Claude Opus 4 高出 90.2%。例如让它"列出 S&P 500 信息技术板块所有公司的董事会成员",多 Agent 系统会把任务拆给子 agent 并行处理,最终给出正确答案;而单 agent 系统因为只能慢速串行搜索,根本搜不到。
多 Agent 系统能行得通,主要是因为它们让你舍得花足够的 token 去解决问题。在我们对 BrowseComp(一个测量浏览类 agent 找到难找信息能力的评估)的分析里,三个因素解释了 95% 的性能差异:仅 token 用量本身就解释了 80% 的差异,剩下两个解释因子是工具调用次数和模型选择。这一发现验证了我们的架构方向——把工作分配给拥有独立上下文窗口的多个 agent,给并行推理腾出更多容量。最新版本的 Claude 模型起到了 token 用量的大幅效率倍增器作用:把模型从 Claude Sonnet 3.7 升级到 Claude Sonnet 4 带来的性能提升,比把 Claude Sonnet 3.7 的 token 预算翻倍还大。多 Agent 架构能为单 agent 容量装不下的任务有效扩容 token 使用。
但有代价:这类架构非常烧 token。在我们的数据里,agent 通常比聊天交互多用约 4 倍的 token,多 Agent 系统则比聊天多用约 15 倍的 token。要做到经济上划算,多 Agent 系统需要瞄准任务价值足够高、能负担起这种性能溢价的场景。此外,有些领域要求所有 agent 共享同一上下文,或者 agent 之间依赖很密集,在今天还不适合多 Agent 系统。例如,大多数编程任务可并行的子任务比研究类任务少,而且 LLM agent 还不擅长实时地与其他 agent 协调和委派。我们的体感是:多 Agent 系统在高价值、可大量并行、信息量超过单一上下文窗口、并需要对接大量复杂工具的任务上表现最佳。
我们的 Research 系统采用多 Agent 架构 + 编排者-工作者(orchestrator-worker)模式:一个 lead agent 协调整体流程,并把任务派发给若干并行运转的专门子 agent。
当用户提交一条 query 时,lead agent 先分析它、形成策略,然后派生(spawn)出多个子 agent 并行探索不同方面。如上图所示,子 agent 充当智能过滤器——以本例(2025 年的 AI agent 公司)为例,它们迭代地使用搜索工具搜集信息,然后把公司列表回传给 lead agent,由其汇总成最终答案。
传统做法(Retrieval Augmented Generation, RAG)使用静态检索:把和输入 query 最相似的若干 chunk 取回来,用这些 chunk 生成回复。而我们的架构使用多步搜索(multi-step search)——动态地寻找相关信息、随新发现调整、并对结果进行分析以形成高质量答案。
多 Agent 系统与单 Agent 系统有关键差异,其中之一是协同复杂度迅速膨胀。我们早期的 agent 出过这些错:为简单 query 派生 50 个子 agent、为不存在的来源在网上无止境地搜、互相用过多更新打扰对方。由于每个 agent 都由 prompt 引导,提示词工程就是我们改进这些行为的主要杠杆。我们总结的一些原则:
我们的 prompting 策略注重灌输好的启发式,而不是写死硬规则。我们研究了高水平人类怎么做研究,再把这些策略编码进 prompt——比如把难题拆成小任务、谨慎评估来源质量、根据新信息调整搜索路径、知道何时该深挖(深入研究一个话题)vs 该铺开(并行探索多话题)。我们也主动设置显式护栏来抑制意外副作用,防止 agent 失控。最后,我们专注打造带可观测性和测试用例的快迭代循环。
构建可靠的 AI 应用离不开好评估,agent 也不例外。但评估多 Agent 系统面临独特挑战。传统评估往往假设 AI 每次都遵循相同步骤:输入 X,系统按路径 Y 产出 Z。但多 Agent 系统不是这样工作的。即使起点相同,agent 也可能走完全不同但都有效的路径——一个可能搜 3 个来源,另一个搜 10 个;它们也可能用不同的工具找到同一个答案。因为我们不一定知道"正确步骤"是什么,所以通常没法用"是否按预设步骤"来评判。我们需要灵活的评估方法——既看 agent 是否达到了正确结果,也看它过程是否合理。
立刻就开始评估,从小样本做起。 Agent 开发的早期,改动的影响通常巨大——因为低垂果子还多。一个 prompt 调整可能把成功率从 30% 拉到 80%。在这种效应规模下,几个测试用例就能看出变化。我们一开始用约 20 个能代表真实使用模式的 query 作为评估集,跑这些 query 通常足以让改动的效果一目了然。我们常听到 AI 团队拖延做评估,理由是"非得有几百用例的大评估才算有用"。最好的做法恰恰相反:先用几条用例做小规模测试立刻起步,而不是等"做完厚实评估"才开始。
LLM-as-judge 评估做得好就能规模化。 研究类输出难以程序化评估——它们是自由文本,很少有唯一正确答案。LLM 天然适合给输出打分。我们用一个 LLM 评审,依据一个评分卡(rubric)对每个输出打分:事实准确性(主张是否与来源一致?)、引用准确性(被引用的来源是否支持主张?)、完整性(要求的方面是否都覆盖到?)、来源质量(是否用了一手来源而非低质二手来源?)、工具效率(是否用对工具、调用次数合理?)。我们试过用多个评审分别评估不同维度,但发现一次 LLM 调用 + 一个 prompt + 输出 0.0–1.0 分数与通过/未通过判断这种方式最稳定、和人类判断最一致。当评估用例有清晰答案(比如"列出研发预算前三的制药公司")时尤其有效——可以让 LLM 直接判断回答是否正确。用 LLM 做评审让我们可规模化地评估数百个输出。
人类评估能发现自动化遗漏的问题。 实测 agent 的人会找到评估漏掉的边角情况。包括:罕见 query 上的幻觉、系统级故障、隐蔽的来源选择偏差。在我们这里,人工测试员注意到我们早期的 agent 总倾向于优先选择 SEO 内容农场,而忽视权威但排名不高的来源(如学术 PDF、个人博客)。我们在 prompt 里加入来源质量启发式才解决这一问题。即便有了自动化评估,手工测试仍然不可或缺。
多 Agent 系统具有涌现行为(emergent behaviors)——这些行为不是被显式编程出来的。例如,lead agent 的小改动会以不可预测的方式改变子 agent 的行为。成功的关键是理解交互模式,而不只是单个 agent 的行为。因此,针对这些 agent 的最佳 prompt 不是死板的指令,而是协作的框架——定义分工、问题求解方法、以及精力预算。把这件事做对,依赖于细致的 prompt 与工具设计、扎实的启发式、可观测性、紧密的反馈闭环。可以在 我们 Cookbook 的开源 prompt 中看到我们系统的示例 prompt。
传统软件里,一个 bug 可能让某个功能挂掉、让性能下降、或导致一次故障。在 agentic 系统里,微小的改动会级联放大成巨大的行为变化——给那种需要在长时间运行过程中维护状态的复杂 agent 写代码因此格外困难。
Agent 是有状态的,错误会复合。 Agent 可能长时间运行,跨越大量工具调用维持状态。这意味着我们需要持久化地执行代码、并在过程中妥善处理错误。没有有效的缓解措施,微小的系统故障对 agent 来说可能是灾难性的。出错时不能简单地从头重启:重启代价高、用户体验差。我们因此构建了能从错误发生处恢复的系统。我们也利用模型的智能去优雅地处理问题——例如,让 agent 知道某个工具正在失败、由它自行调整,效果出奇地好。我们把基于 Claude 的 agent 的适应能力,与确定性的安全措施(如重试逻辑、定期 checkpoint)结合在一起。
调试需要新方法。 Agent 做动态决策,即便 prompt 完全一样,跨 run 也是非确定性的,这让调试更难。例如用户反馈说 agent "找不到明显的信息",但我们看不出原因——是搜索 query 不好?选了差的来源?还是工具失败?我们引入完整的生产追踪(production tracing)之后,就能系统性地诊断为何失败、修复问题。除了标准的可观测性,我们还监控 agent 的决策模式与交互结构——同时不监控具体对话内容以保护用户隐私。这种高层级的可观测性帮我们诊断根因、发现意外行为、修复常见失败。
部署需要精细协同。 Agent 系统是高度有状态、几乎不停运行的 prompt-工具-执行逻辑组成的网。所以每次部署更新时,agent 都可能正处在流程中的任意位置。我们必须防止善意的代码变更打断正在运行的 agent——不能同时把所有 agent 切到新版本。我们采用 彩虹部署(rainbow deployments):保持新旧两个版本同时运行,逐步把流量从旧版本切到新版本,避免打扰仍在跑的 agent。
同步执行带来瓶颈。 目前,我们的 lead agent 是同步执行 subagent 的——每批 subagent 跑完才能继续。这简化了协调,但在 agent 之间的信息流上形成瓶颈:lead agent 没法对 subagent 进行航向修正,subagent 之间也不能互相协调,整个系统可能因为等一个 subagent 搜完而被卡住。异步执行可以解锁更多并行——agent 并发工作、按需创建新 subagent。但这种异步性会引入结果协调、状态一致性、跨 subagent 的错误传播等新挑战。随着模型能处理更长、更复杂的研究任务,我们相信性能收益会值回这部分复杂度。
构建 AI agent 时,最后一公里往往就是整段旅途的大部分。在开发者机器上能跑的代码库,要变成可靠的生产系统还需要大量工程投入。Agentic 系统中错误的复合性意味着:传统软件里只是小问题的事,在 agent 这里足以让它整个偏航。一步失败,就可能让 agent 走上完全不同的轨迹,导致不可预测的结果。基于本文所述的种种原因,原型与生产之间的鸿沟,往往比预期更宽。
尽管挑战重重,多 Agent 系统在开放式研究任务上已经证明了价值。用户告诉我们,Claude 帮他们找到了原本没想过的商业机会、梳理了复杂的医疗选项、解决了棘手的技术 bug,通过挖掘出自己一个人不会发现的研究关联,省下了数天的工作量。多 Agent 研究系统可以在规模化场景下可靠运行——前提是:细致的工程、全面的测试、对细节苛刻的 prompt 与工具设计、扎实的运维实践,以及对当下 agent 能力有清晰认知的研究、产品、工程团队之间的紧密协作。我们已经看到这些系统在改变人们解决复杂问题的方式。
由 Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox、Daniel Ford 撰写。本工作凝结了 Anthropic 多个团队让 Research 功能落地的集体努力。特别感谢 Anthropic apps engineering 团队——他们的投入把这个复杂的多 Agent 系统送到了生产。同样感谢早期用户提供的宝贵反馈。
以下是关于多 Agent 系统的一些零散补充建议。
对跨多轮修改状态的 agent 做 end-state 评估。 评估那些在多轮对话中修改持久化状态的 agent 有独特挑战。和只读式的研究任务不同,每个动作都会改变后续步骤所处的环境,形成依赖关系,传统评估方法很难处理。我们的成功做法是聚焦 end-state 评估而不是逐轮分析——不去判断 agent 是否走了某条特定流程,而是评估它是否到达了正确的最终状态。这种方法承认 agent 可以用不同路径达到同一目标,同时仍然保证它交付了预期结果。对复杂工作流,把评估拆成离散的 checkpoint,在那些应当发生特定状态变化的关键节点验证,而不是试图校验每一个中间步骤。
长时程对话管理(Long-horizon conversation management)。 生产环境中的 agent 经常进行跨数百轮的对话,需要细致的上下文管理策略。对话越拉越长,标准上下文窗口很快就不够用,必须引入智能压缩与记忆机制。我们实现了这样的模式:让 agent 在完成阶段性工作后做总结,把核心信息存到外部记忆,再去做新任务。当上下文逼近上限时,agent 可以派生一个上下文干净的新 subagent,通过细致的交接保持连续性。此外,agent 还能在到达上下文上限时从记忆里取回研究计划等已存信息,避免丢失先前工作。这种分布式做法既防止上下文溢出,又能跨长时间交互保持对话一致性。
子 agent 直接输出到文件系统,避免"传话游戏"。 某些类型的结果让 subagent 直接绕过 lead agent 输出反而能提升保真度和性能。与其逼 subagent 把所有东西都通过 lead agent 传,不如建立产物(artifact)系统:让专门 agent 各自创建可独立持久化的产物。Subagent 调用工具把自己的产出存到外部系统,然后只把轻量引用回传给 coordinator。这能避免多阶段处理中的信息丢失,也能降低把大段输出反复复制到对话历史里产生的 token 开销。这个模式对结构化输出(如代码、报告、数据可视化)特别有效——专用 subagent 的 prompt 写出的结果,往往比让通用 coordinator 过滤一遍要好得多。
答案中以
[术语]标记的概念都可点击跳到本表对应条目并自动展开。本表按 10 个主题分组收录 60+ 高频术语,默认全部收起——遇到不熟的术语再展开看精要解释,避免被信息淹没。
不实际运行代码的情况下分析源码,识别潜在 bug、未使用变量、风格违规、可疑用法。常见工具:
在 Agent 工程中,lint 经常被用作 harness 的硬约束——把 lint 错误反馈给模型重写代码,比单纯在 prompt 里说"请遵守编码规范"可靠得多(Augment Code 把这叫做 Constraint Harness)。
确保代码中变量赋值、函数调用的类型一致:
对 Agent:让 agent 写完代码后强制跑 tsc --noEmit / mypy . / cargo check,类型错误作为反馈喂回模型继续修。比让 agent 自己"声明检查过类型"可靠得多——这是 harness 工程的典型做法。
CI(Continuous Integration):每次代码提交自动跑测试、构建、lint、type check 等校验。
CD(Continuous Deployment):通过校验后自动部署到测试 / 预发 / 生产环境。
常见工具:GitHub Actions、GitLab CI、Jenkins、CircleCI、Buildkite。
在 Agent 工程里,CI 是最重要的 deterministic 反馈源——LLM 自评不可靠,但 CI 通过/失败是 0/1 信号,可以直接作为 ground truth。Hashimoto 的 harness engineering 强调"能不能解决问题强相关于 agent 能不能验证自己的工作"。
让不可信代码(用户上传、LLM 生成)在受限环境中跑,防止破坏宿主系统。隔离强度从弱到强:
Agent 跑用户/LLM 生成代码必须沙箱,并叠加纵深防御:网络出口白名单 + 文件系统只读 + 时间/内存配额 + 不挂载 host 凭据。
来自煤矿用金丝雀检测毒气的典故。部署流程典型为:shadow(双跑不返回)→ 1% → 5% → 25% → 50% → 100%,每阶段观察核心指标无回归才推进。
对 LLM 应用:新 prompt / 新模型 / 新 agent harness 上线必走 canary,关键指标(解决率、CSAT、refusal 率、p99 延迟、单次成本)任何一个恶化 > 阈值就回滚。LLM 应用的"非确定性"特性让 canary 比传统软件更重要。
按 user_id hash 切流量保证一个用户始终进同一桶(避免体验跳变)。判定要素:
LLM 应用调 prompt / 换模型 / 改 RAG 都应过 A/B;只靠 offline eval 上线常翻车(线上流量分布与黄金集差异大)。
业务侧验收 Agent 是否上线最看的几个指标:
Agent 工程关注:把模型 / prompt / RAG 改动放进 A/B 看这些业务指标,而非只看离线 benchmark 分数。改动让 benchmark 涨但 GMV / CSAT 跌的情况非常常见。
Agent 自治走到关键节点时暂停等待人工:
设计原则:"Humans steer. Agents execute."(OpenAI Harness Engineering)。Agent 不是替代人,是放大人的判断——把人放在制定计划、设定约束、审核结果的位置,agent 处理执行。
Google SRE 体系定义的四个术语:
1 - SLO。SLO 99.9% 意味着 30 天有 43.2 分钟"预算"可以不达标,预算用完就冻结非必要发布。Agent 应用怎么用:
经验法则:SLO 不是越严越好——99.99% 比 99.9% 贵 5-10 倍,且大概率超过用户感知阈值。Google 建议"刚刚够用户不抱怨"的水位。
到期自动失效。常见用法:
经验换算:1000 英文单词 ≈ 1300 token;1000 汉字 ≈ 1500-2000 token。
为什么重要:context window、API 计费、推理速度都按 token 算。控制 token 数 = 控制成本和延迟。Anthropic / OpenAI / Google 各自的 tokenizer 不同,相同文本 token 数差 ±20% 很常见。
文本 → 神经网络 → 一个 768 / 1024 / 1536 / 3072 维的浮点数向量。同义词 / 同主题文本的向量在空间中距离近(cosine similarity 高)。
主要用途:
主流模型 2026:OpenAI text-embedding-3-large、Cohere v4、Voyage-3、BGE-M3(开源 SOTA,中英双语 + dense/sparse/multi-vector 三合一)。
包含 system prompt + 历史对话 + 用户输入 + 模型输出,所有都计算在内。2026 主流模型:
注意:宣称窗口 ≠ 有效窗口。RULER 基准显示多数模型在窗口 1/4 之外性能急剧下降(Lost in the Middle)。工程建议把"应当塞入 context"的阈值定在 8-32k,更长走 RAG 或层级摘要。
两个阶段瓶颈不同,调优策略也不同——prefill 优化靠并行 / FlashAttention,decode 优化靠 continuous batching / speculative decoding。
生成第 t 个 token 时需要前面所有 token 的 K/V 参与注意力计算。把它们缓存下来避免每次重算,是 LLM 推理的最基础优化。
显存占用:2 × num_layers × num_heads × head_dim × seq_len × batch × bytes_per_elem。70B 模型上 128k 上下文的 KV cache 可达数十 GB,远超模型权重本身。
进阶优化:
GPT 类 decoder-only 模型的生成方式:P(x_t | x_1, ..., x_{t-1})。每生成一个 token 都要跑一次完整 forward(虽然能复用 KV cache),所以输出长度直接决定延迟。
对比:BERT 是非自回归(masked LM,一次预测所有 mask 位置),扩散模型(diffusion)也是非自回归(一次去噪整段)。
自回归的代价催生了大量加速技术:speculative decoding、parallel decoding、Medusa、EAGLE 等。
decoder 最后一层输出 [vocab_size] 维的 logit 向量;过 softmax 后得到下一个 token 的概率分布。
工程上能拿到 logit(或 top-k logprob)的场景:
注意:OpenAI / Anthropic 商用 API 默认只返回采样结果,需显式开 logprobs 选项。
P(token) ∝ exp(logit / T):
何时调高:Self-Consistency 需要多样路径、creative writing、brainstorm。
何时调低:代码生成、数学推理、严格格式输出,T=0.1-0.3。
陷阱:T=0 不完全等同 deterministic——浮点 GPU 算子的非确定性 + 并发调度可能让相同 prompt 的输出仍有微差。
Xiao et al. 2023 发现:长序列推理时,靠后的 token 往往把不成比例多的注意力分给了序列最前面的几个 token(即使它们语义无关)——这些 token 成为"sink",吸收掉 softmax 必须分配的归一化质量。
工程意义:
LayerNorm:y = (x - μ) / σ * g + b,沿 hidden 维度求均值方差。与 batch 无关,天然支持变长序列与单条推理——这是 Transformer 选 LayerNorm 而非 BatchNorm 的原因。
RMSNorm(Zhang & Sennrich 2019):y = x / sqrt(mean(x²)+ε) * g,去掉减均值和 bias。Llama / PaLM / Mistral 等现代 LLM 几乎都改用 RMSNorm,省 7-64% 归一化耗时且效果不降。
Pre-LN vs Post-LN:LN 在残差前做(Pre-LN)训练比放残差后(Post-LN)稳定,可去掉 warmup,GPT-2 起几乎统一用 Pre-LN。
Su et al. 2021。把位置 m 表示为旋转矩阵 R_m 作用在 Q/K 上,使得 <R_m·q, R_n·k> = f(q, k, m-n)——注意力得分只依赖相对距离。
优点:(1) 无额外参数;(2) 天然编码相对位置;(3) 可与线性注意力兼容。已成 Llama / Qwen / Mistral 等绝大多数现代 LLM 的位置编码方案。
外推问题:纯外推 2k→32k 会崩——高频分量旋转角度落入未见区域。缓解:
RoPE 纯外推会崩——高频分量在训练上下文外旋转角度落入未见区域。两种工程化方案:
主流应用:
经验数字:YaRN 在 4× 上下文扩展(2k→8k 或 32k→128k)几乎无损;8× 以上仍有性能下降。极致长上下文(1M+)通常需要重训而非仅靠 YaRN。
标准 multi-head attention:H 个头各有独立 Q/K/V。
收益:KV cache 减小到 1/8 ~ 1/H,推理吞吐显著提升,效果几乎无损。Llama-2 70B / Llama-3 / Mistral / Qwen2 等都用 GQA。
把传统 dense FFN 换成 N 个并行的 expert FFN + 一个 router。每个 token 通过 router 选 top-k 个 expert(k 通常 1-2),只激活这部分 expert 计算。
优点:参数量大、算力省。Mixtral 8x7B 总参数 47B,激活参数仅 13B;DeepSeek-V3 671B 总参数,激活仅 37B。同等推理成本下 capacity 远超 dense 模型。
挑战:(1) 训练时负载均衡(防一两个 expert 被过度使用);(2) 显存占用按总参数计而非激活参数;(3) 通信开销大(expert parallelism)。
单头注意力对每对 token 只产生一个 attention 分布——一种"关系视角"。多头(h=8/32/64/128)让模型同时学多种关系——句法头关注短距离依赖,语义头关注共指、远程实体。
为什么单头加大维度不行:多头是 h 个低秩注意力的混合,表达能力严格更强;单头是一个高秩注意力,自由度反而少。
进阶变体:GQA / MQA 在 KV 侧减头省显存,Q 侧仍保多头。
Dao 2022。标准 attention 显存 O(N²)(要存 N×N 的 attention matrix),长序列瓶颈。FlashAttention 把 Q/K/V 分块加载到 GPU SRAM 计算,不写出完整 attention matrix,显存降到 O(N),速度也快——attention 是 memory-bound,少读 HBM 就快。
演进:
Kwon et al. 2023。解决传统推理 KV cache 的三类碎片问题:
机制:KV cache 切成固定大小 block(如 16 token),每个序列维护 block table(逻辑→物理映射)。显存利用率从 ~20% 提到 >96%;同 prompt 多采样共享前缀 block;配合 continuous batching 吞吐相对 HuggingFace TGI 提升 2-4×,相对 FasterTransformer 24×。
2023 年起的事实标准开源推理服务器。核心特性:
对比:TGI(HuggingFace)、TensorRT-LLM(NVIDIA,私有更快)、SGLang(前缀复用更彻底)、LMDeploy(OpenCompass 出品)。
也叫 in-flight batching,Yu et al. ORCA 2022 提出。对比 static batching(等齐 batch 再一起跑,长短请求混在一起时 GPU 利用率经常 <30%),continuous batching:
vLLM 数据:吞吐相比 static 提升 5-23×。已成所有现代推理引擎的默认。
Leviathan et al. 2023。流程:
数学上保证输出分布与原模型完全一致(rejection sampling)。
收益条件:(1) draft 与 target 分布相似(接受率 >60%);(2) 大模型受 memory bandwidth 限制,并行验证不增延迟。代码生成接受率 70-90%,开放生成 30-50%。变体:EAGLE-2/3、Medusa、Llama 3.1 self-speculative。
KV cache 是单 request 内复用;prefix caching 是跨 request 复用——多个 request 共享 system prompt / few-shot / agent 历史时,首次计算后缓存这部分 KV,后续 request 直接命中跳过 prefill。
效果:agent / RAG / 多轮对话场景,system prompt 通常 1-4k token、几乎所有请求共享,TTFT 可下降 10-100×。
实现:vLLM --enable-prefix-caching、SGLang RadixAttention(用 radix tree 自动管理所有历史前缀)、Anthropic prompt caching API(5min TTL,cached 部分 0.1× 价格)。
主要由 prefill 决定(处理 input 所有 token)。计费、监控的核心指标之一。
降低 TTFT 的手段:
伴生指标:TBT(time between tokens,单 token 间隔)— 由 decode 决定。
混合精度训练:权重和梯度用 BF16/FP16,optimizer state 仍用 FP32。
部署阶段把权重量化到低 bit 整数,推理时反量化回浮点计算。
INT8 / INT4 量化通常需要校准集(128-512 样本),AWQ 更智能(保护 1% salient 通道)。极致显存场景再用 GGUF(llama.cpp 格式)+ 3-bit / 2-bit 量化跑手机端。
Lin et al. 2023。核心洞察:只需保护 ~1% 的"重要权重通道"(由激活幅值识别)即可保住精度。对这些通道按 per-channel scale 放大再量化。
对比 GPTQ:实现更简单,Llama-2 上困惑度更低,已成 vLLM / TensorRT-LLM 默认。
Frantar 2022。用 OBQ 启发的逐层最小化量化误差,需要少量校准集(128 样本)。优点:早、生态全(exllama / vllm / TGI 都支持);缺点:对激活分布敏感,重要通道可能被压坏。
2026 部署选型:H100/H200 → FP8;A100/3090 → AWQ INT4;手机/边缘 → INT4 + GGUF。
最基础的指令微调方式:把 (输入, 期望输出) 对当做监督学习样本,cross-entropy loss 教模型学指令跟随。
经验数据量:
LIMA 论文:1000 条精选样本即可让 65B base 接近 GPT-4 对话质量——质量 >> 数量。
Hu et al. 2021。把权重更新分解为两个低秩矩阵 ΔW = BA(r=8/16/64),只训练这两个矩阵,可训参数减少 100-10000×。
显存:
优点:可训参数少 / 多个 adapter 可热切换 / 缓解 灾难性遗忘。
Dettmers et al. 2023。三项关键:
65B 模型 QLoRA 约 33GB,单 A100-48G 或双 RTX 3090 可跑。代价:训练慢 30-40%(反量化开销)。
三步走:(1) SFT 训出 base policy;(2) 人类标注 (chosen, rejected) 偏好对训出 Reward Model;(3) 用 RM 给 policy 输出打分,PPO/RLOO/REINFORCE 等算法更新 policy。
InstructGPT、ChatGPT 让 RLHF 出圈。三大痛点:
RLHF 第二步训出。输入:(prompt, response),输出:一个 scalar reward。训练 loss 是 Bradley-Terry:让 RM 在 (chosen, rejected) 对上给 chosen 更高分。
常见弱点:
Rafailov et al. 2023。证明:在 Bradley-Terry 偏好模型 + KL 约束下,最优 policy 有闭式解,可直接用偏好对 (chosen, rejected) 做监督式损失:
L_DPO = -log σ(β(log π(y_w)/π_ref(y_w) - log π(y_l)/π_ref(y_l)))
优势:(1) 无 RM / 无在线采样 / 无 critic,仅 policy + ref 两个模型;(2) 用 SFT 同样的训练栈;(3) 超参稳定。
劣势:严重依赖偏好数据质量;容易过拟合 chosen 的表面模式;reward hacking 风险大。
Llama-3、Qwen2 后训练主路径都是 DPO 或其变种(IPO、KTO、SimPO)。
Schulman 2017。Actor 学策略,critic 学 value function 估计 advantage,clip 限制每步策略更新幅度防崩。
RLHF 中需同时载入 actor / ref / critic / reward 四个模型,显存 ≥4× 单模型。超参敏感(KL 系数、clip ratio、advantage 归一化),训练不稳定。
催生了 DPO(去 RL)、GRPO(去 critic)、RLOO(用平均 reward 当 baseline)等简化方案。
DeepSeek-Math 2024 提出,R1 验证。核心创新:去掉 critic(value 网络),对同一 prompt 采样 G 个 response(典型 G=64),用组内 reward 的均值/标准差做 advantage 归一化:A_i = (r_i - mean(r)) / std(r),再做 PPO-like 的 clipped objective + KL 正则。
效果:
在数学、代码、形式逻辑等可自动验证的任务上,直接用程序判定 reward:答案匹配、单测通过、定理证明器验证。
优势:
DeepSeek-R1、DAPO(ByteDance 开源 SOTA)都属此类。局限:仅适用可验证任务,开放对话仍需 RLHF / DPO。
机制:参数被新任务 loss 拉走,原本编码通用知识的方向被覆盖。
缓解组合(生产推荐):
进阶:EWC(按 Fisher 信息加权 L2 正则)、Model Souping(微调模型与原模型权重平均)、MoE 路由扩展。
Wei et al. 2022。最简形式:"Let's think step by step"(Kojima 2022 zero-shot CoT)。
为什么有效:(1) 增加有效 compute(更多 forward step);(2) 把"系统 1"直觉答题转成"系统 2"分步推理;(3) 暴露错误推理便于 self-consistency 投票纠正。
是涌现能力,<10B 模型几乎无效。Long CoT(R1 / o1 用 RL 训出,含回溯/自我验证,数千 token 长)是 2025 的新范式。
Yao et al. 2023。CoT 是线性单链,错了无法回头;ToT 每步生成多个候选 thought,LLM 自评估状态价值(promising / sure / impossible),BFS/DFS 展开可回溯剪枝。
Game of 24 上 GPT-4 CoT 4% vs ToT 74%。代价:LLM 调用数从 1 涨到 50-200。
适合:解空间需显式搜索(puzzle、规划、定理证明),中间状态可评估。不适合:闲聊、摘要、翻译。
Yao et al. 2022。结构 Thought → Action → Observation 循环:模型先 "Thought: 我需要查 X",输出 "Action: search[X]",工具结果作为 "Observation: ..." 喂回 prompt,再下一轮 Thought。
三大效果:
是现代 agent 框架(Claude tool use、OpenAI function calling、LangChain、AutoGPT)的概念原型。
Shinn et al. 2023。Agent 在一次任务失败后(由外部 verifier 给二元 reward),用 LLM 把失败原因总结成自然语言 lesson 存入 episodic memory,下一次任务时把 lesson 加进 prompt 影响行为。
vs Self-Refine:
HumanEval 上 GPT-4 Reflexion 91%,超过 GPT-4 baseline 80%。
Madaan et al. 2023。在一个 trajectory 里循环 N 轮,无外部 reward、无跨任务记忆。7 个任务平均提升 20%。
陷阱:弱模型自评不准,可能越改越差。生产常组合 Self-Refine(局内)+ Reflexion(跨局)。
Wang et al. 2022。temperature>0 采样 N 条 CoT 路径,对最终答案投票。GSM8K 上比 greedy CoT 提升 ~17 个百分点(PaLM 55%→74%)。
收益大场景:(1) 答案空间离散(数字、选择题);(2) 模型错误率 <50%;(3) 推理路径多样(temperature 0.7-1.0)。代价:N×(典型 N=5-40),开放生成不适用。
何时 few-shot:(1) 任务格式新颖/输出结构复杂(JSON schema、特定 markdown);(2) 分类任务标签多。
何时 zero-shot:通用任务现代模型已饱和(摘要、翻译、QA),加 example 反而引入偏差。
陷阱:example 顺序影响大(recency bias);偶然规律会被学走;example 多了 Lost in the Middle。建议 ≤8 条。
标准 pipeline = Ingestion + Retrieval + Generation:
每段都有瓶颈:chunking 切大小、embedding 选型、召回率不足、context 顺序、模型不忠于 context。生产 RAG ≠ "embedding + 向量库 + LLM"——是一个工程系统。
策略:
Okapi BM25。文档与 query 的相关性按 Σ IDF(qi) · f(qi,d) · (k+1) / (f + k·(1-b+b·|d|/avgdl)) 计算。强项:精确词命中、稀有词高权重、专有名词、数字。短板:同义词不通("医生" vs "doctor")。
与 dense embedding 互补——hybrid search 把两者融合,召回率比单 dense 提升 5-15 个百分点。
dense embedding 擅长语义近似,BM25 擅长精确词匹配,两者互补。
融合方法:
score(d) = Σ 1/(k + rank_i(d)),k=60。生产首选,无需归一化两路分数α·dense + (1-α)·bm25,需要调 α 且分数归一化Anthropic Contextual Retrieval 实验:单 embedding → +contextual embedding → +BM25 → +rerank,失败率 5.7% → 4.0% → 3.7% → 1.9%。
Bi-encoder(embedding):query / doc 分别编码再 cosine 比对,快但无交互。
Cross-encoder(reranker):query + doc 拼接喂 transformer,每层 self-attention 交互,相关性建模能力强 20-40%(NDCG@10),慢 100×。
生产标配:bi-encoder 召回 top-100 → cross-encoder rerank 到 top-10 → 喂 LLM。
主流:Cohere Rerank v3/v4、BGE-reranker-v2-m3(开源 SOTA 中英)、Jina Reranker v2、Mixedbread。
陷阱:召回 top-100 里没有相关文档,rerank 也救不了——reranker 锦上添花,不能替代召回。
2026 主流 embedding 模型对比:
选型框架:
关键陷阱:
主流:
ANN 算法:HNSW(最常见)、IVF、ScaNN(Google)。索引时间 vs 检索精度 vs 显存有 trade-off。
朴素 RAG 在多文档跨实体推理、召回质量不稳、多跳查询场景下都会力不从心。四个常见进阶方案:
实战选择:
Es et al. 2023。四大指标:
生产阈值:4 个指标都 ≥0.7 算合格;Faithfulness < 0.7 优先修;Context Recall < 0.7 调 retriever。
Mitchell Hashimoto 2026 命名:"anytime you find an agent makes a mistake, take the time to engineer a solution such that the agent never makes that mistake again."
不是模型微调,而是工程化环境让模型物理上无法以同样方式再犯错。
两条法则:
OpenAI 公式:Agent = Model + Harness;"Humans steer. Agents execute."
2024-2026 主流框架对比:
经验:先用 SDK 直调写原型;workflow 模式(routing / parallelization / orchestrator-workers)成熟后再考虑 LangGraph;纯 RAG 场景考虑 LlamaIndex;避免一上来就 LangChain "全家桶"。
2024-11 推出,2025-Q4 转入独立 Steering Committee(Anthropic / Block / OpenAI / Microsoft)。三种核心原语:
解决"每接一个新工具就要写一遍 adapter"的 N×M 问题。2026 年增速最快的单一技能,97M+ 月下载,已是 Anthropic Applied AI Engineer JD 显式必备。
模型输出 {"name": "search", "arguments": {"query": "..."}} JSON,runtime 解析后真实执行函数,结果回喂模型。Anthropic Tool Use API、OpenAI function calling 都是同思路。
设计原则(Anthropic 实测:"agent 性能正比于工具描述清晰度"):
Anthropic 2024-Q4 推出 Computer Use。流程:截屏 → LLM 看图 + 推理 → 输出鼠标键盘动作(click X,Y / type text / scroll)→ 系统执行 → 再截屏循环。
Browser Use(开源框架)类似但限于浏览器,基于 Playwright + DOM 增强(把可点击元素加序号叠加到截图)。
实用场景:无 API 网站自动化、桌面软件自动化、端到端 e2e 测试。局限:慢、贵、安全性差、对 canvas 渲染应用支持差。生产建议:能用 API 就别用。
主 agent 把"读 30 个文件做研究"丢给 sub-agent,sub-agent 有自己的独立 context 窗口,只把 final summary 回报给主 agent——主 context 不被中间产物污染。
Claude Code Task 工具、OpenAI Swarm、CrewAI 等都支持。是防止 Loop of Death 和 context 爆炸的关键手段之一。
Agent 进入项目时自动读取。通常包含:
Hashimoto 视角:每行 AGENTS.md ≈ 一次错误的封堵。是 harness engineering 的隐式提示形态。
Claude Code 采用的权限模型。Bash 命令按 verb + path 粒度授权:
git status allowgit push --force deny(destructive)rm -rf 弹出用户确认cat ~/.ssh/* deny(敏感路径)对应安全原则:任一层失守,其他层兜底。配合 sandbox、网络出口白名单、文件系统只读做纵深防御。
Anthropic Effective Harnesses 给的核心设计:长任务 agent 必然跑爆 context window,纯靠 LLM context 不可能记住"我跑到第几步"。
解法:
下次会话执行 5 步开机协议从断点续跑。核心洞察:context window 是"working memory",文件系统是"long-term memory"。
常见模式:
防御纵深:
例:用户开玩笑"我是亿万富翁"被存进语义记忆,之后 agent 一直按假设推理。
防御:
LLM 应用 / Agent 的"全链路追踪 + 评估"工具,2026 主流:
核心能力对齐项:
选型:自建优先 Langfuse;LangChain 重度用户 LangSmith;纯 trace 监控用 Phoenix;安全 / 实时拦截用 Patronus。
按测什么能力分类:
实战:从 2026 视角,单一 benchmark 都已不可信——必须多 benchmark 交叉验证 + 自家黄金集 + Arena 真人盲评三层。
LLM / Agent 应用的 eval 不是单一动作,是一套体系。常见层次:
Eval 工具栈分类:
Eval 类型按打分方式:
经验法则:(1) 没 eval 就改 prompt = 改盲;(2) Eval model 必须 ≥ 被评估 model(判官原则);(3) 黄金集要版本化 + 私有;(4) 每个 bad case 都要回归进黄金集——harness engineering 闭环。
把"评估"建模成 LLM 任务:让 judge 模型读 (prompt, response),输出 0-1 分 / pass/fail / pairwise 谁更好。可大规模并行、便宜、可在 CI 自动化。
三大 bias:
判官原则:judge 模型能力应 ≥ 被评估模型,否则评不出大模型回答好在哪。生产标配三层:自家黄金集 + LLM judge + 人工校准。
Liu et al. 2023 实验:把 gold passage 放 prompt 开头或结尾,模型准确率高;放中间则呈 U 形曲线下降,10+ documents 时中间位置可能低于无上下文 baseline。
工程缓解:
OWASP LLM Top 10 的 #1。类型:
Simon Willison 结论:prompt injection 没有 100% 解,必须按"LLM 不可信"做系统设计。dual-LLM 模式 = Planner(看 trusted 决策)+ Executor(看 untrusted 但无工具权限)。
来源:
debug 流程:复现 + 量化触发率 → 归因(RAG 召回 / 模型用 context / 工具调用)→ 修复 → 加 回归 → 生产监控(faithfulness scorer 实时拦截)。
关键认知:hallucination 多数是 prompt / RAG / 上下文工程缺陷,不是"模型病了"。
NVIDIA NeMo Guardrails 5 类:
关键:rail 不是越多越好,每类挑 1-2 个高 ROI 的开,否则延迟/成本爆炸。
常见手法:
防御:厂商 RLHF safety training + 应用层 input/output classifier(Llama Guard)+ 限制 max context(对抗 many-shot)+ red team 定期演练。