我们是如何构建多 Agent 研究系统的

How we built our multi-agent research system · 中文翻译

原作者:Jeremy Hadfield、Barry Zhang、Kenneth Lien、Florian Scholz、Jeremy Fox、Daniel Ford(Anthropic)

原文发布:2025-06-13  ·  中文译稿:2026-05-14

原文链接:anthropic.com/engineering/multi-agent-research-system

本文为社区学习用途的非官方中文翻译。技术名词以括注英文原文为准;最终解释以英文原文为准。

Claude 现在具备 Research 能力,可以跨网页、Google Workspace 和各类集成进行搜索,以完成复杂任务。

这套多 Agent 系统从原型走到生产的过程,让我们在系统架构、工具设计、提示词工程这几方面学到不少关键经验。所谓多 Agent 系统,是由多个 agent(即在循环中自主使用工具的 LLM)协同工作组成。我们的 Research 功能由一个 agent 根据用户的 query 来规划研究流程,然后使用工具创建若干并行 agent 同时搜索信息。多 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 系统的架构概览

我们的 Research 系统采用多 Agent 架构 + 编排者-工作者(orchestrator-worker)模式:一个 lead agent 协调整体流程,并把任务派发给若干并行运转的专门子 agent。

多 Agent 架构实战示意
多 Agent 架构实战示意:用户 query 流经 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 Research 系统完整工作流
多 Agent Research 系统完整工作流。用户提交 query 后,系统创建一个 LeadResearcher agent 进入迭代式研究过程。LeadResearcher 先思考方法、把计划存到 Memory 以持久化上下文——因为一旦上下文窗口超过 20 万 token 就会被截断,保留计划至关重要。然后它创建若干带特定研究任务的专门 Subagent(图中画了两个,实际可以是任意数量)。每个 Subagent 独立执行网页搜索,用 interleaved thinking(交错思考) 评估工具结果,再把发现回传给 LeadResearcher。LeadResearcher 汇总结果、判断是否需要更多研究——如需,可以再创建额外 subagent 或调整策略。信息收集充分后,系统退出研究循环,把所有发现交给 CitationAgent,由它处理文档与研究报告以确定具体的引用位置,确保每条主张都正确归因到来源。最终带引用的研究结果返回给用户。

面向 research agent 的提示词工程与评估

多 Agent 系统与单 Agent 系统有关键差异,其中之一是协同复杂度迅速膨胀。我们早期的 agent 出过这些错:为简单 query 派生 50 个子 agent、为不存在的来源在网上无止境地搜、互相用过多更新打扰对方。由于每个 agent 都由 prompt 引导,提示词工程就是我们改进这些行为的主要杠杆。我们总结的一些原则:

  1. 像你的 agent 那样思考。 想迭代 prompt,你必须理解 prompt 的作用。为此我们在 Console 上用系统里完全相同的 prompt 和工具搭建模拟,逐步观察 agent 工作。这立刻让失败模式浮出水面:已有充足结果还继续搜、搜索 query 写得过于冗长、选错工具等等。有效的 prompting 依赖于你对 agent 建立一个准确的心智模型——心智模型对了,最该改的地方就显而易见。
  2. 教编排者如何派活。 在我们的系统里,lead agent 负责把 query 拆成子任务并描述给子 agent。每个子 agent 都需要明确的目标、输出格式、可用工具与信息源的指引、以及清晰的任务边界。任务描述不够详细,agent 就会重复劳动、留下盲区、或找不到必要信息。一开始我们让 lead agent 给简短指令(如"研究一下半导体短缺"),结果发现这种指令含糊到子 agent 误解任务、或与其他 agent 做完全一样的搜索。比如一个子 agent 跑去研究 2021 年汽车芯片危机,另外两个子 agent 各自又在调研 2025 年的供应链——分工完全失效。
  3. 让投入与 query 复杂度匹配。 Agent 难以自己判断该投入多少精力,所以我们把伸缩规则写进 prompt:简单的事实查询只用 1 个 agent + 3-10 次工具调用;直接比较类需要 2-4 个子 agent,每个 10-15 次调用;复杂研究可能用 10+ 个子 agent、职责清晰划分。这些显式指引让 lead agent 合理分配资源,避免对简单 query 过度投入——这是我们早期版本里常见的失败模式。
  4. 工具设计与选择至关重要。 Agent-工具接口和人机界面一样重要。用对工具不仅高效,往往是绝对必要的——比如让 agent 去网上搜只存在于 Slack 里的上下文,注定一开始就要失败。在 MCP 服务器给模型接入外部工具之后,这个问题被放大了:agent 会遇到大量没见过、质量参差不齐的工具描述。我们给 agent 一些显式启发式规则:先检视所有可用工具、把工具用途匹配到用户意图、做广义外部探索时用网页搜索、能用专用工具就别用通用工具。糟糕的工具描述会把 agent 引到完全错误的路径上,所以每个工具都需要有清晰独立的用途和清晰的描述。
  5. 让 agent 自我改进。 我们发现 Claude 4 模型本身就能当出色的 prompt 工程师。给它一个 prompt 和一种失败模式,它能诊断出 agent 为何失败并提出改进。我们甚至专门做了一个工具测试 agent:给它一个有缺陷的 MCP 工具,它会尝试调用并改写工具描述以规避失败。通过反复测试这个工具几十次,这个 agent 发现了关键的细节坑和 bug。这种改进工具人机工效的做法,使后续 agent 用新描述完成任务的耗时下降 40%——因为它们能避开大部分错误。
  6. 先广再窄。 搜索策略应该模仿专家级人类研究者:先扫描全景再钻细节。Agent 默认倾向于写又长又具体的 query,结果返回很少。我们用 prompt 反向纠正:先用简短、宽泛的 query,评估能拿到什么,再逐步收窄聚焦。
  7. 引导思考过程。 扩展思考(Extended thinking)模式让 Claude 在可见的思考过程中输出额外 token,可以作为可控的草稿纸。Lead agent 用 thinking 规划方法、评估哪些工具匹配任务、确定 query 复杂度与子 agent 数量、定义每个子 agent 的角色。我们的测试表明,扩展思考改善了指令遵循、推理和效率。子 agent 也先规划,再在工具结果之后用 交错思考(interleaved thinking)评估结果质量、识别遗漏、调整下一次 query。这让子 agent 更善于适应各种任务。
  8. 并行工具调用大幅改变速度与性能。 复杂研究任务天然要探索很多来源。我们早期的 agent 串行执行搜索,慢得令人发指。为提速,我们引入两层并行:(1) lead agent 并行派生 3-5 个子 agent 而非串行;(2) 子 agent 内部并行调用 3+ 个工具。这两处改动让复杂 query 的研究耗时最多缩短 90%,让 Research 能在几分钟而非几小时内完成更多工作,同时覆盖比其他系统更多的信息。

我们的 prompting 策略注重灌输好的启发式,而不是写死硬规则。我们研究了高水平人类怎么做研究,再把这些策略编码进 prompt——比如把难题拆成小任务、谨慎评估来源质量、根据新信息调整搜索路径、知道何时该深挖(深入研究一个话题)vs 该铺开(并行探索多话题)。我们也主动设置显式护栏来抑制意外副作用,防止 agent 失控。最后,我们专注打造带可观测性和测试用例的快迭代循环。

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 能力有清晰认知的研究、产品、工程团队之间的紧密协作。我们已经看到这些系统在改变人们解决复杂问题的方式。

Clio 嵌入图:Research 功能的主要使用方式
一张 Clio 嵌入图,展示了人们当前使用 Research 功能最常见的方式。排在前面的使用场景类别包括:跨专业领域开发软件系统(10%)、开发与优化专业技术内容(8%)、制定业务增长与营收策略(8%)、辅助学术研究与教学材料开发(7%)、研究与核实关于人/地/组织的信息(5%)。

致谢

由 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+ 高频术语,默认全部收起——遇到不熟的术语再展开看精要解释,避免被信息淹没。

软件工程基础

lint 软件工程 — 静态代码检查工具,扫描源码找潜在 bug 与风格问题

不实际运行代码的情况下分析源码,识别潜在 bug、未使用变量、风格违规、可疑用法。常见工具:

在 Agent 工程中,lint 经常被用作 harness 的硬约束——把 lint 错误反馈给模型重写代码,比单纯在 prompt 里说"请遵守编码规范"可靠得多(Augment Code 把这叫做 Constraint Harness)。

type check / 类型检查 软件工程 — 验证变量、参数、返回值类型是否匹配

确保代码中变量赋值、函数调用的类型一致:

对 Agent:让 agent 写完代码后强制跑 tsc --noEmit / mypy . / cargo check,类型错误作为反馈喂回模型继续修。比让 agent 自己"声明检查过类型"可靠得多——这是 harness 工程的典型做法。

CI/CD 软件工程 — 持续集成 / 持续部署流水线

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 能不能验证自己的工作"。

sandbox / 沙箱 软件工程 — 隔离的代码执行环境,限制对外部资源的访问

让不可信代码(用户上传、LLM 生成)在受限环境中跑,防止破坏宿主系统。隔离强度从弱到强:

Agent 跑用户/LLM 生成代码必须沙箱,并叠加纵深防御:网络出口白名单 + 文件系统只读 + 时间/内存配额 + 不挂载 host 凭据。

canary / 金丝雀发布 软件工程 — 先给少量流量上新版本,观察无异常再全量

来自煤矿用金丝雀检测毒气的典故。部署流程典型为:shadow(双跑不返回)→ 1% → 5% → 25% → 50% → 100%,每阶段观察核心指标无回归才推进。

对 LLM 应用:新 prompt / 新模型 / 新 agent harness 上线必走 canary,关键指标(解决率、CSAT、refusal 率、p99 延迟、单次成本)任何一个恶化 > 阈值就回滚。LLM 应用的"非确定性"特性让 canary 比传统软件更重要。

A/B test 软件工程 — 对照试验,把流量切成两组分别用新旧版本,比较关键指标差异

按 user_id hash 切流量保证一个用户始终进同一桶(避免体验跳变)。判定要素:

LLM 应用调 prompt / 换模型 / 改 RAG 都应过 A/B;只靠 offline eval 上线常翻车(线上流量分布与黄金集差异大)。

GMV / UV / CSAT / NPS / 转化率 业务指标 — 电商 / 旅行 / 客服业务最常用的几个北极星指标

业务侧验收 Agent 是否上线最看的几个指标:

Agent 工程关注:把模型 / prompt / RAG 改动放进 A/B 看这些业务指标,而非只看离线 benchmark 分数。改动让 benchmark 涨但 GMV / CSAT 跌的情况非常常见。

HITL / human-in-the-loop 软件工程 — 关键决策点引入人工审核 / 确认

Agent 自治走到关键节点时暂停等待人工:

设计原则:"Humans steer. Agents execute."(OpenAI Harness Engineering)。Agent 不是替代人,是放大人的判断——把人放在制定计划、设定约束、审核结果的位置,agent 处理执行。

SLO / SLI / SLA / Error Budget 软件工程 — 服务质量的"目标 / 指标 / 合约 / 预算"四件套,来自 SRE

Google SRE 体系定义的四个术语:

Agent 应用怎么用:

  1. 每个 Agent 场景定 1-3 个 SLO:如"客服 Agent 解决率 SLO = 85%"、"p99 端到端延迟 SLO ≤ 5s"、"单任务平均成本 SLO ≤ $0.05"
  2. 触发告警:实时 SLI 跌破 SLO 80% 警告,跌破 SLO 直接 page oncall
  3. 冻结发布:error budget 烧完了,禁止合并非紧急修复
  4. 业务 SLO vs 技术 SLO:业务 SLO(转化率 / CSAT / GMV)属于产品验收,技术 SLO(延迟 / 错误率 / cost)属于工程兜底,两层都要

经验法则:SLO 不是越严越好——99.99% 比 99.9% 贵 5-10 倍,且大概率超过用户感知阈值。Google 建议"刚刚够用户不抱怨"的水位。

TTL / Time To Live 软件工程 — 数据 / 缓存 / 凭据的有效期

到期自动失效。常见用法:

LLM 基础概念

token LLM 基础 — LLM 的最小输入/输出单位,由 tokenizer 切分得到

经验换算:1000 英文单词 ≈ 1300 token;1000 汉字 ≈ 1500-2000 token。

为什么重要:context window、API 计费、推理速度都按 token 算。控制 token 数 = 控制成本和延迟。Anthropic / OpenAI / Google 各自的 tokenizer 不同,相同文本 token 数差 ±20% 很常见。

embedding LLM 基础 — 把文本/图片映射为高维稠密向量,语义相近的向量距离近

文本 → 神经网络 → 一个 768 / 1024 / 1536 / 3072 维的浮点数向量。同义词 / 同主题文本的向量在空间中距离近(cosine similarity 高)。

主要用途:

主流模型 2026:OpenAI text-embedding-3-large、Cohere v4、Voyage-3、BGE-M3(开源 SOTA,中英双语 + dense/sparse/multi-vector 三合一)。

context window / 上下文窗口 LLM 基础 — 模型单次能处理的 token 上限

包含 system prompt + 历史对话 + 用户输入 + 模型输出,所有都计算在内。2026 主流模型:

注意:宣称窗口 ≠ 有效窗口。RULER 基准显示多数模型在窗口 1/4 之外性能急剧下降(Lost in the Middle)。工程建议把"应当塞入 context"的阈值定在 8-32k,更长走 RAG 或层级摘要。

prefill / decode LLM 基础 — LLM 推理的两阶段:处理输入 → 逐 token 生成

两个阶段瓶颈不同,调优策略也不同——prefill 优化靠并行 / FlashAttention,decode 优化靠 continuous batching / speculative decoding。

KV cache LLM 基础 — 注意力中已计算过的 K (Key) / V (Value) 矩阵缓存

生成第 t 个 token 时需要前面所有 token 的 K/V 参与注意力计算。把它们缓存下来避免每次重算,是 LLM 推理的最基础优化。

显存占用:2 × num_layers × num_heads × head_dim × seq_len × batch × bytes_per_elem。70B 模型上 128k 上下文的 KV cache 可达数十 GB,远超模型权重本身。

进阶优化:

autoregressive / 自回归 LLM 基础 — 一次生成一个 token,下一个 token 的生成依赖前面所有 token

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 等。

logit LLM 基础 — 模型输出的原始未归一化得分,每个词汇表 token 一个值

decoder 最后一层输出 [vocab_size] 维的 logit 向量;过 softmax 后得到下一个 token 的概率分布。

工程上能拿到 logit(或 top-k logprob)的场景:

注意:OpenAI / Anthropic 商用 API 默认只返回采样结果,需显式开 logprobs 选项。

temperature LLM 基础 — 控制采样随机性的超参数,0 = 确定性,>1 = 高随机

P(token) ∝ exp(logit / T):

何时调高:Self-Consistency 需要多样路径、creative writing、brainstorm。
何时调低:代码生成、数学推理、严格格式输出,T=0.1-0.3。

陷阱:T=0 不完全等同 deterministic——浮点 GPU 算子的非确定性 + 并发调度可能让相同 prompt 的输出仍有微差。

attention sink LLM 基础 — 模型把大量注意力集中到序列开头几个 token 的现象

Xiao et al. 2023 发现:长序列推理时,靠后的 token 往往把不成比例多的注意力分给了序列最前面的几个 token(即使它们语义无关)——这些 token 成为"sink",吸收掉 softmax 必须分配的归一化质量。

工程意义:

Transformer 架构

LayerNorm / RMSNorm 架构 — Transformer 主流归一化层,沿 feature 维度对单样本归一化

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。

RoPE / Rotary Position Embedding 架构 — 旋转位置编码,把位置信息编码进 Q/K 旋转矩阵

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 会崩——高频分量旋转角度落入未见区域。缓解:

NTK-aware scaling / YaRN 架构 — RoPE 长度外推方案,让 2k 训练的模型能跑 32k / 128k context

RoPE 纯外推会崩——高频分量在训练上下文外旋转角度落入未见区域。两种工程化方案:

主流应用:

经验数字:YaRN 在 4× 上下文扩展(2k→8k 或 32k→128k)几乎无损;8× 以上仍有性能下降。极致长上下文(1M+)通常需要重训而非仅靠 YaRN。

GQA / MQA 架构 — Grouped/Multi Query Attention,多个 Q 头共享同一组 K/V 头

标准 multi-head attention:H 个头各有独立 Q/K/V。

收益:KV cache 减小到 1/8 ~ 1/H,推理吞吐显著提升,效果几乎无损。Llama-2 70B / Llama-3 / Mistral / Qwen2 等都用 GQA。

MoE / Mixture of Experts 架构 — 混合专家模型,每个 token 只激活部分 expert FFN

把传统 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)。

multi-head attention / 多头注意力 架构 — 把 d_model 拆成 h 份独立投影 Q/K/V,每头学不同子空间的关系

单头注意力对每对 token 只产生一个 attention 分布——一种"关系视角"。多头(h=8/32/64/128)让模型同时学多种关系——句法头关注短距离依赖,语义头关注共指、远程实体。

为什么单头加大维度不行:多头是 h 个低秩注意力的混合,表达能力严格更强;单头是一个高秩注意力,自由度反而少。

进阶变体:GQA / MQA 在 KV 侧减头省显存,Q 侧仍保多头。

推理加速

FlashAttention 推理加速 — 通过 tiling + online softmax 不实例化完整 attention 矩阵的 attention 计算

Dao 2022。标准 attention 显存 O(N²)(要存 N×N 的 attention matrix),长序列瓶颈。FlashAttention 把 Q/K/V 分块加载到 GPU SRAM 计算,不写出完整 attention matrix,显存降到 O(N),速度也快——attention 是 memory-bound,少读 HBM 就快。

演进:

PagedAttention 推理加速 — vLLM 提出,把 KV cache 像 OS 虚拟内存一样切成固定大小 block 管理

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×。

vLLM 推理加速 — UC Berkeley 开源的高吞吐 LLM 推理引擎,实现 PagedAttention

2023 年起的事实标准开源推理服务器。核心特性:

对比:TGI(HuggingFace)、TensorRT-LLM(NVIDIA,私有更快)、SGLang(前缀复用更彻底)、LMDeploy(OpenCompass 出品)。

continuous batching 推理加速 — 按 token 级别动态调度,请求结束即退出、新请求随时插入

也叫 in-flight batching,Yu et al. ORCA 2022 提出。对比 static batching(等齐 batch 再一起跑,长短请求混在一起时 GPU 利用率经常 <30%),continuous batching:

vLLM 数据:吞吐相比 static 提升 5-23×。已成所有现代推理引擎的默认。

speculative decoding 推理加速 — 小 draft 模型快速猜 K 个 token,大模型一次 forward 并行验证

Leviathan et al. 2023。流程:

  1. 小 draft model(1-7B)自回归生成 K 个 token(K=5 典型)
  2. 大 target model(70B+)一次 forward 并行验证 K+1 个位置
  3. 前 j 个被接受 + 第 j+1 个拒绝 → 保留前 j 个 + 采样一个新 token

数学上保证输出分布与原模型完全一致(rejection sampling)。

收益条件:(1) draft 与 target 分布相似(接受率 >60%);(2) 大模型受 memory bandwidth 限制,并行验证不增延迟。代码生成接受率 70-90%,开放生成 30-50%。变体:EAGLE-2/3、Medusa、Llama 3.1 self-speculative。

prefix caching 推理加速 — 跨 request 缓存相同前缀的 KV cache,跳过 prefill 重新计算

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× 价格)。

TTFT / Time to First Token 推理加速 — 从 request 发出到第一个 token 返回的延迟

主要由 prefill 决定(处理 input 所有 token)。计费、监控的核心指标之一。

降低 TTFT 的手段:

伴生指标:TBT(time between tokens,单 token 间隔)— 由 decode 决定。

量化

FP16 / BF16 / FP8 量化 — 低精度浮点格式,省显存省算力

混合精度训练:权重和梯度用 BF16/FP16,optimizer state 仍用 FP32。

INT4 / INT8 / NF4 量化 — 整数量化,把 FP16 权重压到 4/8 bit 整数

部署阶段把权重量化到低 bit 整数,推理时反量化回浮点计算。

INT8 / INT4 量化通常需要校准集(128-512 样本),AWQ 更智能(保护 1% salient 通道)。极致显存场景再用 GGUF(llama.cpp 格式)+ 3-bit / 2-bit 量化跑手机端。

AWQ / Activation-aware Weight Quantization 量化 — 保护 1% salient 通道的 INT4 权重量化

Lin et al. 2023。核心洞察:只需保护 ~1% 的"重要权重通道"(由激活幅值识别)即可保住精度。对这些通道按 per-channel scale 放大再量化。

对比 GPTQ:实现更简单,Llama-2 上困惑度更低,已成 vLLM / TensorRT-LLM 默认。

GPTQ 量化 — 较早的 post-training 4-bit 权重量化

Frantar 2022。用 OBQ 启发的逐层最小化量化误差,需要少量校准集(128 样本)。优点:早、生态全(exllama / vllm / TGI 都支持);缺点:对激活分布敏感,重要通道可能被压坏。

2026 部署选型:H100/H200 → FP8;A100/3090 → AWQ INT4;手机/边缘 → INT4 + GGUF。

微调与对齐

SFT / Supervised Fine-Tuning 微调 — 监督微调,用 (prompt, response) 对数据训练模型

最基础的指令微调方式:把 (输入, 期望输出) 对当做监督学习样本,cross-entropy loss 教模型学指令跟随。

经验数据量:

LIMA 论文:1000 条精选样本即可让 65B base 接近 GPT-4 对话质量——质量 >> 数量。

LoRA / Low-Rank Adaptation 微调 — 冻结原权重,只训练低秩 adapter 矩阵

Hu et al. 2021。把权重更新分解为两个低秩矩阵 ΔW = BA(r=8/16/64),只训练这两个矩阵,可训参数减少 100-10000×。

显存:

优点:可训参数少 / 多个 adapter 可热切换 / 缓解 灾难性遗忘。

QLoRA 微调 — 4-bit 量化冻结权重 + LoRA adapter,单卡 24G 跑 65B 微调

Dettmers et al. 2023。三项关键:

  1. 4-bit NF4 量化冻结权重:7B 从 14GB 压到 ~4GB
  2. Double Quantization:把量化常数也量化,省 ~0.4 bit/param
  3. Paged Optimizer:NVIDIA unified memory,OOM 时溢出到 CPU

65B 模型 QLoRA 约 33GB,单 A100-48G 或双 RTX 3090 可跑。代价:训练慢 30-40%(反量化开销)。

RLHF 对齐 — Reinforcement Learning from Human Feedback,用人类偏好做 RL 训练

三步走:(1) SFT 训出 base policy;(2) 人类标注 (chosen, rejected) 偏好对训出 Reward Model;(3) 用 RM 给 policy 输出打分,PPO/RLOO/REINFORCE 等算法更新 policy。

InstructGPT、ChatGPT 让 RLHF 出圈。三大痛点:

催生了 DPO、GRPO、RLVR 等简化/改良方案。

RM / Reward Model 对齐 — 用人类偏好训出来的"打分模型",给 LLM 输出打分

RLHF 第二步训出。输入:(prompt, response),输出:一个 scalar reward。训练 loss 是 Bradley-Terry:让 RM 在 (chosen, rejected) 对上给 chosen 更高分。

常见弱点:

替代方案:DPO 完全去掉 RM,RLVR 用程序判定 reward。

DPO / Direct Preference Optimization 对齐 — 从数学上证明可以不用 RM、直接监督式优化偏好

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)。

PPO / Proximal Policy Optimization 对齐 — RLHF 经典算法,actor-critic + clipped objective

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)等简化方案。

GRPO / Group Relative Policy Optimization 对齐 — DeepSeek 提出,去掉 critic,用组内 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 正则。

效果:

RLVR / RL with Verifiable Rewards 对齐 — 用程序判定的 0/1 reward 做 RL,无需 RM

在数学、代码、形式逻辑等可自动验证的任务上,直接用程序判定 reward:答案匹配、单测通过、定理证明器验证。

优势:

DeepSeek-R1、DAPO(ByteDance 开源 SOTA)都属此类。局限:仅适用可验证任务,开放对话仍需 RLHF / DPO。

catastrophic forgetting / 灾难性遗忘 微调 — 在新任务上微调后,原通用能力显著下降

机制:参数被新任务 loss 拉走,原本编码通用知识的方向被覆盖。

缓解组合(生产推荐):

进阶:EWC(按 Fisher 信息加权 L2 正则)、Model Souping(微调模型与原模型权重平均)、MoE 路由扩展。

提示词与推理范式

CoT / Chain of Thought 提示词 — 让模型先输出推理步骤再给答案

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 的新范式。

ToT / Tree of Thoughts 提示词 — 把推理建模为树搜索,每步多候选 + 自评估 + 回溯

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、规划、定理证明),中间状态可评估。不适合:闲聊、摘要、翻译。

ReAct 提示词 — Reasoning + Acting,思考-行动-观察循环

Yao et al. 2022。结构 Thought → Action → Observation 循环:模型先 "Thought: 我需要查 X",输出 "Action: search[X]",工具结果作为 "Observation: ..." 喂回 prompt,再下一轮 Thought。

三大效果:

是现代 agent 框架(Claude tool use、OpenAI function calling、LangChain、AutoGPT)的概念原型。

Reflexion 提示词 — 跨 episode 的"言语强化学习",把失败原因存为 lesson

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%。

Self-Refine 提示词 — 单任务内迭代:generate → self-feedback → refine 循环

Madaan et al. 2023。在一个 trajectory 里循环 N 轮,无外部 reward、无跨任务记忆。7 个任务平均提升 20%。

陷阱:弱模型自评不准,可能越改越差。生产常组合 Self-Refine(局内)+ Reflexion(跨局)。

self-consistency 提示词 — 对同一问题采样 N 条 CoT,对最终答案做 majority vote

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 / zero-shot 提示词 — Prompt 中给/不给示例

何时 few-shot:(1) 任务格式新颖/输出结构复杂(JSON schema、特定 markdown);(2) 分类任务标签多。

何时 zero-shot:通用任务现代模型已饱和(摘要、翻译、QA),加 example 反而引入偏差。

陷阱:example 顺序影响大(recency bias);偶然规律会被学走;example 多了 Lost in the Middle。建议 ≤8 条。

RAG

RAG / Retrieval-Augmented Generation RAG — 检索增强生成:先检索相关文档,再让 LLM 基于上下文回答

标准 pipeline = Ingestion + Retrieval + Generation:

  1. Ingestion:document loader → chunking → embedding → 向量库写入
  2. Retrieval:query rewriting → embedding → vector search → reranker → top-k
  3. Generation:构造 prompt(含 retrieved chunks)→ LLM 生成 → 后处理 + citation

每段都有瓶颈:chunking 切大小、embedding 选型、召回率不足、context 顺序、模型不忠于 context。生产 RAG ≠ "embedding + 向量库 + LLM"——是一个工程系统。

chunking RAG — 把文档切成适合 embedding / 检索的小块

策略:

BM25 RAG — 基于词频 + IDF 的经典稀疏检索算法

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 个百分点。

reranker / cross-encoder RAG — 把召回 top-N 用更精确(更慢)的模型重新打分

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 锦上添花,不能替代召回。

主流 embedding 模型选型 RAG — BGE-M3 / Cohere v4 / Voyage-3 / OpenAI text-3-large / Qwen3-Embedding 怎么选

2026 主流 embedding 模型对比:

选型框架:

  1. 中文为主 → BGE-M3 / Voyage-3 / Qwen3-Embedding
  2. 多模态 → Cohere v4
  3. 纯英文 + API → OpenAI text-3-large
  4. 自托管私有部署 → BGE-M3

关键陷阱:

vector DB / 向量数据库 RAG — 专门存 embedding 并支持近似最近邻 (ANN) 检索;Pinecone / Milvus / Qdrant 等

主流:

ANN 算法:HNSW(最常见)、IVF、ScaNN(Google)。索引时间 vs 检索精度 vs 显存有 trade-off。

GraphRAG / Self-RAG / CRAG / Agentic RAG RAG — 朴素 RAG 的 4 个进阶变体,各解决不同短板

朴素 RAG 在多文档跨实体推理、召回质量不稳、多跳查询场景下都会力不从心。四个常见进阶方案:

  1. GraphRAG(微软 2024):先用 LLM 从文档抽 entity + relation 建知识图谱,按社区做层次摘要;query 时既能 vector search 又能图遍历。解决"跨多文档跨实体推理时朴素 RAG 召回不全"。代价:ingestion 成本大涨(每 chunk 一次 LLM 抽取)。
  2. Self-RAG(Asai 2023):训练单一 LM 自己生成 reflection token 决定 (a) 要不要检索 (b) retrieved 是否相关 (c) answer 是否被 context 支撑 (d) 整体 utility。解决"什么时候检索、检索后怎么用"的判断。需训练。
  3. CRAG (Corrective RAG,Yan 2024):retrieved chunks 经 lightweight evaluator 打分,分高直接用、中等触发 web 重新搜索、低退回基础生成。解决"召回质量参差不齐"时盲目使用 retrieved。
  4. Agentic RAG:让 agent 决定 query rewriting → 多轮检索 → 子 agent 分工。解决多跳问题、需迭代检索。DeepResearch 类产品就是这一路。

实战选择:

RAGAS RAG — RAG 评估事实标准,4 大核心指标都用 LLM-as-judge 实现

Es et al. 2023。四大指标:

  1. Faithfulness(忠实度):答案中每个 claim 能否从检索 context 推出。<0.7 = 模型在编造
  2. Context Precision(检索精度):top-K 中真正相关的占比。低 = retriever 召回噪声
  3. Context Recall(检索召回):ground truth 信息是否都被检索到。低 = 召回不全
  4. Answer Relevancy(答案相关性):答案是否真的回答了原问题

生产阈值:4 个指标都 ≥0.7 算合格;Faithfulness < 0.7 优先修;Context Recall < 0.7 调 retriever。

Agent 工程

harness / harness engineering Agent — 包裹 LLM 的代码骨架与工程化体系,让 agent 物理上无法重复犯错

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."

不是模型微调,而是工程化环境让模型物理上无法以同样方式再犯错。

两条法则:

  1. 强约束:能用 deterministic 约束(lint / type check / sandbox / CI 硬失败)就不用 prompt
  2. 自愈循环:agent 能从环境拿 ground truth、自我评估、失败可 checkpoint 恢复

OpenAI 公式:Agent = Model + Harness;"Humans steer. Agents execute."

LangChain / LangGraph / LlamaIndex / Haystack Agent — 主流 Agent / LLM 应用开发框架

2024-2026 主流框架对比:

经验:先用 SDK 直调写原型;workflow 模式(routing / parallelization / orchestrator-workers)成熟后再考虑 LangGraph;纯 RAG 场景考虑 LlamaIndex;避免一上来就 LangChain "全家桶"。

MCP / Model Context Protocol Agent — Anthropic 推出的开放协议,让 LLM 客户端用统一接口连接外部工具/数据源

2024-11 推出,2025-Q4 转入独立 Steering Committee(Anthropic / Block / OpenAI / Microsoft)。三种核心原语:

解决"每接一个新工具就要写一遍 adapter"的 N×M 问题。2026 年增速最快的单一技能,97M+ 月下载,已是 Anthropic Applied AI Engineer JD 显式必备。

tool use / function calling Agent — LLM 通过结构化 schema 调用外部函数

模型输出 {"name": "search", "arguments": {"query": "..."}} JSON,runtime 解析后真实执行函数,结果回喂模型。Anthropic Tool Use API、OpenAI function calling 都是同思路。

设计原则(Anthropic 实测:"agent 性能正比于工具描述清晰度"):

Computer Use / Browser Agent Agent — 让模型操作桌面 GUI 或浏览器

Anthropic 2024-Q4 推出 Computer Use。流程:截屏 → LLM 看图 + 推理 → 输出鼠标键盘动作(click X,Y / type text / scroll)→ 系统执行 → 再截屏循环。

Browser Use(开源框架)类似但限于浏览器,基于 Playwright + DOM 增强(把可点击元素加序号叠加到截图)。

实用场景:无 API 网站自动化、桌面软件自动化、端到端 e2e 测试。局限:慢、贵、安全性差、对 canvas 渲染应用支持差。生产建议:能用 API 就别用。

sub-agent Agent — 主 agent 派出的、有独立 context 的子任务 agent

主 agent 把"读 30 个文件做研究"丢给 sub-agent,sub-agent 有自己的独立 context 窗口,只把 final summary 回报给主 agent——主 context 不被中间产物污染。

Claude Code Task 工具、OpenAI Swarm、CrewAI 等都支持。是防止 Loop of Death 和 context 爆炸的关键手段之一。

AGENTS.md / CLAUDE.md Agent — 给 agent 看的项目说明书,写明协议 / 约束 / 启动流程

Agent 进入项目时自动读取。通常包含:

Hashimoto 视角:每行 AGENTS.md ≈ 一次错误的封堵。是 harness engineering 的隐式提示形态。

deny-first Agent — 默认禁止所有工具/命令,显式白名单才允许

Claude Code 采用的权限模型。Bash 命令按 verb + path 粒度授权:

对应安全原则:任一层失守,其他层兜底。配合 sandbox、网络出口白名单、文件系统只读做纵深防御。

progress 文件 / progress.md Agent — 把 agent 任务进度持久化到文件,跨会话续跑

Anthropic Effective Harnesses 给的核心设计:长任务 agent 必然跑爆 context window,纯靠 LLM context 不可能记住"我跑到第几步"。

解法:

下次会话执行 5 步开机协议从断点续跑。核心洞察:context window 是"working memory",文件系统是"long-term memory"。

Loop of Death Agent — Agent 进入无限循环烧 token 直到耗尽

常见模式:

防御纵深:

  1. 硬性 max iteration(5-30 步)
  2. Execution timeout(5-30 分钟)
  3. Token budget(per-task hard cap)
  4. 进度检测(连续 N 步无 diff 强停)
  5. 失败重复检测(同 tool call 失败 3 次跳出)
  6. 成本告警 + HITL
Memory Corruption / 记忆污染 Agent — 错误事实进入长期记忆后污染所有后续决策

例:用户开玩笑"我是亿万富翁"被存进语义记忆,之后 agent 一直按假设推理。

防御:

评估与安全

Trace + Eval 工具栈 评估 — Langfuse / LangSmith / Phoenix / Helicone / Patronus 等可观测平台

LLM 应用 / Agent 的"全链路追踪 + 评估"工具,2026 主流:

核心能力对齐项:

  1. Trace:prompt → tool_call → response → cost / latency 串成完整 trace
  2. Prompt 版本化:每次 prompt 改动一个 hash,可在 dashboard 切换并对比
  3. Eval:CI 上跑黄金集,回归报警
  4. Cost & Cache hit rate:单 trace 成本、cache 命中分布
  5. User feedback / thumb up-down:直接打到 trace 上做 bad case 入库

选型:自建优先 Langfuse;LangChain 重度用户 LangSmith;纯 trace 监控用 Phoenix;安全 / 实时拦截用 Patronus。

主流 LLM eval benchmark 评估 — MMLU / MT-Bench / Chatbot Arena / HumanEval / LiveBench / BFCL 各测什么

按测什么能力分类:

实战:从 2026 视角,单一 benchmark 都已不可信——必须多 benchmark 交叉验证 + 自家黄金集 + Arena 真人盲评三层。

Eval / Evaluation 评估 — LLM 应用 / Agent 的"打分"环节:offline / online / CI 三层评估

LLM / Agent 应用的 eval 不是单一动作,是一套体系。常见层次:

Eval 工具栈分类:

  1. 通用 framework:OpenAI Evals、DeepEval、Promptfoo、Inspect AI——CLI / 库形式跑评估
  2. 集成在可观测平台:Langfuse / LangSmith / Phoenix 都内置 eval framework,与 trace 联动
  3. RAG 专用:RAGAS(faithfulness / context relevancy 等 4 维)
  4. Tool use 专用:BFCL(Berkeley Function-Calling Leaderboard)
  5. 领域专用:每家自家黄金集 + LLM-judge rubric

Eval 类型按打分方式:

经验法则:(1) 没 eval 就改 prompt = 改盲;(2) Eval model 必须 ≥ 被评估 model(判官原则);(3) 黄金集要版本化 + 私有;(4) 每个 bad case 都要回归进黄金集——harness engineering 闭环。

LLM-as-judge 评估 — 用强 LLM 给候选输出打分,替代人工评估

把"评估"建模成 LLM 任务:让 judge 模型读 (prompt, response),输出 0-1 分 / pass/fail / pairwise 谁更好。可大规模并行、便宜、可在 CI 自动化。

三大 bias:

判官原则:judge 模型能力应 ≥ 被评估模型,否则评不出大模型回答好在哪。生产标配三层:自家黄金集 + LLM judge + 人工校准。

Lost in the Middle 评估 — 长上下文 QA 中,关键信息放中间时模型准确率显著下降

Liu et al. 2023 实验:把 gold passage 放 prompt 开头或结尾,模型准确率高;放中间则呈 U 形曲线下降,10+ documents 时中间位置可能低于无上下文 baseline。

工程缓解:

prompt injection 安全 — 用户或外部内容劫持模型行为,绕过 system prompt

OWASP LLM Top 10 的 #1。类型:

Simon Willison 结论:prompt injection 没有 100% 解,必须按"LLM 不可信"做系统设计。dual-LLM 模式 = Planner(看 trusted 决策)+ Executor(看 untrusted 但无工具权限)。

hallucination / 幻觉 评估 — 模型生成看似合理但实际错误的内容

来源:

debug 流程:复现 + 量化触发率 → 归因(RAG 召回 / 模型用 context / 工具调用)→ 修复 → 加 回归 → 生产监控(faithfulness scorer 实时拦截)。

关键认知:hallucination 多数是 prompt / RAG / 上下文工程缺陷,不是"模型病了"。

guardrails 安全 — 围绕 LLM 的输入/输出/工具/对话各环节的安全护栏

NVIDIA NeMo Guardrails 5 类:

  1. Input rails:PII 脱敏、prompt injection 检测、topic 限定
  2. Dialog rails:基于 Colang DSL 控制对话流,硬编码关键决策点
  3. Retrieval rails:剔除低质 / 敏感 / 不可信 chunk
  4. Execution rails:工具调用前参数白名单 / 授权检查
  5. Output rails:幻觉检测 / 敏感数据外泄过滤 / 毒性过滤

关键:rail 不是越多越好,每类挑 1-2 个高 ROI 的开,否则延迟/成本爆炸。

jailbreak / 越狱 安全 — 绕开模型安全训练让它输出有害内容

常见手法:

防御:厂商 RLHF safety training + 应用层 input/output classifier(Llama Guard)+ 限制 max context(对抗 many-shot)+ red team 定期演练。