为长时程 Agent 打造高效的 Harness

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

• JavaScript/TypeScript：ESLint、Biome
• Python：Pylint、Ruff、Flake8
• Go：golangci-lint
• Rust：clippy
• Shell：shellcheck

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

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

• 静态类型语言：TypeScript / Go / Rust / Java 编译期检查
• 动态语言加注解：Python 用 mypy / pyright / Pyre，Ruby 用 Sorbet

对 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 生成）在受限环境中跑，防止破坏宿主系统。隔离强度从弱到强：

• Docker (runc)：共享 kernel，弱隔离，启动 <1s
• gVisor：用户态 syscall 拦截，中隔离
• Firecracker / microVM：独立 kernel，强隔离，~100-300ms 冷启
• E2B：基于 Firecracker 的 SaaS，LLM Agent 代码执行首选
• 完全 VM：最强隔离，秒-分钟级冷启

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

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

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

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

• 业务指标：转化率、CSAT、留存——验证假设
• 代理指标：thumb up/down、refusal 率、对话轮数
• Guardrail metric：成本、延迟不能恶化超阈值
• 观察窗口：至少 1-2 周覆盖业务周期
• 统计显著性：t-test / Mann-Whitney 检验

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

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

• GMV (Gross Merchandise Value)：商品交易总额，电商核心指标。日均 GMV、月 GMV、增量 GMV（A/B 实验组比对照组多出来的）都是常见口径。
• UV (Unique Visitor) / DAU (Daily Active User)：独立访客数 / 日活用户。UV 看流量，DAU 看粘性。
• PV (Page View)：页面浏览量，UV × 人均浏览次数。
• CTR (Click-Through Rate)：点击率，曝光后点击占比；推荐系统核心指标。
• 转化率 (Conversion Rate)：漏斗各环节转化——列表页→详情页、详情页→订单页、详情页→支付。电商 / 旅行场景 +1pp 即显著、+1.5-2pp 算大幅提升。
• CSAT (Customer Satisfaction Score)：用户满意度评分（1-5 或 1-10），客服 Agent 必看。
• NPS (Net Promoter Score)：净推荐值，"你有多大可能推荐给朋友"，-100 到 100。
• 首轮解决率 / FCR (First Contact Resolution)：首次交互就解决问题的比例，客服 Agent 关键指标。

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

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

• 高风险操作前：转账、发邮件、删数据、合并 PR
• 置信度低时：模型自评 confidence < 阈值
• 法规要求：医疗诊断、信贷决策、招聘筛选（EU AI Act 高风险系统要求）

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

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

• SLI (Service Level Indicator)：一个指标——可观测的数字。如"成功率 99.5%"、"p99 延迟 280ms"、"任务完成率 92%"。
• SLO (Service Level Objective)：在 SLI 上设定的目标。如"成功率 SLO = 99.9%（30 天滑窗）"。是工程团队对内的承诺。
• SLA (Service Level Agreement)：和用户 / 客户的合约，违约要赔钱 / 退服务费。通常比 SLO 宽（SLO 99.9% → SLA 99.5%），留缓冲。
• Error Budget：1 - SLO。SLO 99.9% 意味着 30 天有 43.2 分钟"预算"可以不达标，预算用完就冻结非必要发布。

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 建议"刚刚够用户不抱怨"的水位。

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

• Cache TTL：Redis 缓存设 1h / 24h
• Prompt Caching TTL：Anthropic 默认 5 分钟，可选 1 小时
• Session TTL：用户会话 24h-7d
• 凭据 TTL：JWT、临时 AWS 凭据通常 1h
• Memory TTL：低 confidence 记忆短 TTL，高 confidence 长 TTL（Memory Corruption 防御之一）

• 英文：一个 token 通常对应 1 个常用词或半个长词（约 4 字符）
• 中文：一个 token 约对应 0.5-2 个汉字（取决于 tokenizer 训练）
• 代码：标点 / 缩进 / 符号都各占 token

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

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

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

主要用途：

• 检索：query embedding → 找最相似的 doc embedding（RAG 召回）
• 聚类：相似主题文档自动分组
• 分类：用相似度做 zero-shot 分类
• 去重：相似度 > 阈值视为重复

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

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

• GPT-4o：128k
• Claude 3.5 Sonnet / Opus：200k
• Gemini 1.5 Pro：1M-2M
• Llama 3.1：128k

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

• Prefill：把 prompt 所有 token 一次性喂入模型计算 KV cache。compute-bound（受 GPU 算力限制），一次能并行处理整段 prompt。延迟决定 TTFT。
• Decode：一次生成一个 token，每个 token 都要复用前面所有 token 的 KV cache。memory-bound（受显存带宽限制），延迟决定 TBT（time between tokens）。

两个阶段瓶颈不同，调优策略也不同——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，远超模型权重本身。

进阶优化：

• PagedAttention：分块管理，去碎片
• GQA/MQA：减少 K/V 头数，KV cache 减小到 1/8 ~ 1/H
• KV cache 量化：FP8 KV cache（H100 原生）显存减半
• prefix caching：跨 request 复用相同前缀的 KV

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）的场景：

• 计算 perplexity（评估模型对文本的"惊讶"程度）
• Self-Consistency 取候选 logprob 加权
• LLM-as-judge 用 yes/no logit 差值作 confidence
• DPO 损失函数直接用 logprob 计算
• Speculative decoding 用 logit 做 rejection sampling

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

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

• T=0：greedy，每次选 argmax，结果可复现（同输入同输出）
• T=0.7-1.0：通用对话推荐范围
• T>1：越大越随机，多样性高但容易胡说

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

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

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

工程意义：

• StreamingLLM：滑窗推理保留开头 sink token，可处理无限长序列
• 解释了 Lost in the Middle：中间 token 注意力被首尾压榨
• 解释了为什么截断序列开头会大幅伤害性能——sink 没了

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

• NTK-aware scaling：低频维度插值、高频近似不变
• YaRN（Peng 2023）：加 attention temperature + 按维度分段缩放，Llama-3.1 128k、Qwen2.5 用的就是这套

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

• NTK-aware scaling（NTK = Neural Tangent Kernel）：对低频维度做插值（拉伸 base），高频维度近乎不变。简单有效，不需重训。
• YaRN（Peng et al. 2023）：在 NTK 基础上加 attention temperature 调整 + 按频率维度分段缩放（高频严格保留、低频强插值），需少量长上下文数据微调（万级 token 长度样本）。

主流应用：

• Llama-3.1 128k → YaRN
• Qwen2.5 / Qwen3 → YaRN
• Mistral-7B 32k 早期版本 → NTK
• GPT-4 / Claude → 闭源，可能用自研方案 + 长上下文持续训练

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

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

• MQA：所有 Q 头共享一套 K/V（极端形态）
• GQA：把 H 个 Q 头分成 G 组，每组共享一套 K/V（折中），G=H/8 是常见配置

收益：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 就快。

演进：

• FA1（2022）：A100 上 ~25% 峰值 FLOPS
• FA2（2023）：优化并行划分、warp 调度，A100 ~50-72% 峰值
• FA3（Shah 2024）：针对 H100 用 WGMMA 异步张量核心 + TMA + producer/consumer warp，BF16 达 740 TFLOPS（75% 峰值），FP8 接近 1.2 PFLOPS

Kwon et al. 2023。解决传统推理 KV cache 的三类碎片问题：

• 内部碎片：预分配 max_seq_len 但实际只用一小部分
• 外部碎片：请求间隙无法复用
• 共享前缀无法去重

机制：KV cache 切成固定大小 block（如 16 token），每个序列维护 block table（逻辑→物理映射）。显存利用率从 ~20% 提到 >96%；同 prompt 多采样共享前缀 block；配合 continuous batching 吞吐相对 HuggingFace TGI 提升 2-4×，相对 FasterTransformer 24×。

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

• PagedAttention 显存管理
• Continuous Batching
• Prefix Caching 自动开启
• Chunked prefill（v0.6+ 默认，prefill/decode 交错调度降抖动）
• FP8 KV cache（H100/H200）
• 支持 GPTQ / AWQ 量化

对比：TGI（HuggingFace）、TensorRT-LLM（NVIDIA，私有更快）、SGLang（前缀复用更彻底）、LMDeploy（OpenCompass 出品）。

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

• 每个 decode step 后，已完成的 request 立刻退出
• 新到的 request 立刻插入空槽并先做 prefill，再加入 decode batch
• 配合 PagedAttention 无显存碎片

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

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。

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 的手段：

• Prefix Caching（命中后 TTFT 降 80%+）
• 减短 prompt（RAG 召回精度上去后能砍 chunk）
• FlashAttention / 更新硬件
• Speculative decoding
• Chunked prefill（不阻塞其他请求 decode）

伴生指标：TBT（time between tokens，单 token 间隔）— 由 decode 决定。

• FP16（half）：5 位 exp + 10 位 mantissa，动态范围窄，训练易溢出
• BF16（brain float）：8 位 exp + 7 位 mantissa，动态范围同 FP32，精度低但训练稳，A100/H100 起的默认训练精度
• FP8（H100/H200 原生）：E4M3（前向）+ E5M2（反向），动态范围比 INT8 大 ~10⁴×，几乎无精度损失，throughput 是 BF16 的 2×

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

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

• INT8：精度损失通常 <1%，部署友好
• INT4（GPTQ / AWQ）：7B 模型从 14GB 压到 ~4GB，普通显卡可跑大模型
• NF4（NormalFloat 4-bit，QLoRA 用）：信息论最优的正态分布量化，专为 LLM 权重分布设计

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 教模型学指令跟随。

经验数据量：

• 基于 chat 模型做格式/风格适配：500-5000 高质量样本
• 注入新领域知识：1-10 万样本 + 5-20% 通用数据混入
• 从 base 做完整 instruct tuning：百万级（Llama 3 用 ~1000 万）

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

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

显存：

• 全参微调 ≈ 16-20× 参数量字节，7B 需 >100GB
• LoRA：冻结原权重仍要 FP16 加载，7B 需 ~14GB + adapter

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

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%（反量化开销）。

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

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

• RM 训练需大量人类偏好标注（10 万对级），贵
• RM 容易被 hack（policy 学会迎合 RM 表面偏好）
• 主观任务的偏好本身嘈杂

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

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

常见弱点：

• Reward hacking：policy 学会迎合 RM 表面偏好（如长度、特定开头）
• Goodhart's Law：RM 一变成 RL 目标就不再代表真实人类偏好
• 泛化差：训练分布外 RM 打分不可信

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

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 正则。

效果：

• 显存省一半（无 critic），70B 级 RL 在合理资源内可行
• 组内归一化天然提供 baseline，方差比 PPO 的 GAE 还低
• 配合 RLVR，R1-Zero 直接从 base 模型纯 RL 涌现 long CoT

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

优势：

• 无标注成本
• 信号干净，无 RM hack 空间
• 可大规模并行 rollout

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

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

缓解组合（生产推荐）：

• 5-30% 通用数据混入新数据
• LoRA 而非全参（低秩约束）
• 小学习率（lr=1e-5 起）+ 短训练（1-2 epoch）
• 持续 eval MMLU / MT-Bench 监控

进阶：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。

三大效果：

• 把模型不知道的事实外化给工具，减少幻觉
• Reasoning 由 observation 引导，错了能纠偏
• 提供可解释的 trace 便于 debug

是现代 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：

• Self-Refine 单局优化、纯靠模型自评
• Reflexion 跨局学习、有外部 ground-truth verifier

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），开放生成不适用。

• Zero-shot：直接说要求，无示例。"翻译成英文：你好"
• Few-shot（in-context learning）：prompt 里给 1-N 个 (输入, 输出) 示例。GPT-3 论文最早系统化。

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

何时 zero-shot：通用任务现代模型已饱和（摘要、翻译、QA），加 example 反而引入偏差。

陷阱：example 顺序影响大（recency bias）；偶然规律会被学走；example 多了 Lost in the Middle。建议 ≤8 条。

标准 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"——是一个工程系统。

策略：

• Fixed：按 token + overlap，简单但易在句中段中断
• Recursive / Structural：按 markdown header / code block / paragraph 切，生产默认
• Semantic：按句间 embedding 相似度切
• Late Chunking（Jina 2024）：先 long-context embedding 整文档，再 token-level 切
• Contextual Retrieval（Anthropic 2024）：每个 chunk 加 LLM 生成的"上下文前缀"再 embed，retrieval 失败率降 49%

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 擅长精确词匹配，两者互补。

融合方法：

• RRF (Reciprocal Rank Fusion)：score(d) = Σ 1/(k + rank_i(d))，k=60。生产首选，无需归一化两路分数
• 加权和：α·dense + (1-α)·bm25，需要调 α 且分数归一化
• 学习式融合：把 top-N 喂 reranker 接管最终排序

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 模型对比：

• OpenAI text-embedding-3-large（3072 维）：英文 baseline，API 友好，$0.13/M tokens；中文一般。
• Cohere embed-v4（1024-1536 维，多模态）：MTEB v2 顶级，支持文本+图像同空间，多语言 100+；企业 SaaS 首选。
• Voyage-3-large（1024 维）：MTEB v2 综合第一，中文表现优秀，retrieval 任务略胜 Cohere。
• BGE-M3（BAAI，1024 维）：开源 SOTA，同时支持 dense + sparse + multi-vector (ColBERT-style) 三种模式，中英双语；自托管首选。
• Qwen3-Embedding-8B（阿里 2025）：开源中文 SOTA 之一，与 BGE-M3 各有胜场。
• Conan-Embedding（腾讯）/ Yi-Embedding（零一）：国产中文方案。

选型框架：

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

关键陷阱：

• MTEB 有版本差异（v1 / v2 / MMTEB），不同模型挂的版本不一样，直接横比误导——自家场景必须重测
• Dense vs Sparse 看场景：精确词命中（专有名词 / 编号）BM25 + dense 混合（hybrid search）比单 dense 提升 5-15pp

主流：

• Pinecone：SaaS，企业首选
• Milvus：开源 + 云
• Qdrant：Rust 写，性能好
• Weaviate：带知识图谱功能
• pgvector：Postgres 扩展，已有 PG 直接用
• Vespa / Elasticsearch：搜索引擎扩展向量
• Chroma：本地开发友好

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

朴素 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 类产品就是这一路。

实战选择：

• 普通 QA → 朴素 RAG + reranker
• 跨文档跨实体复杂推理 → GraphRAG
• 召回质量不稳 → CRAG
• 多跳推理 / 需迭代搜索 → Agentic RAG

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。

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

2024-2026 主流框架对比：

• LangChain（Harrison Chase / LangChain Inc.）：最早出圈的 LLM 应用框架，定位是"LLM 应用的胶水"——连 LLM、prompt 模板、工具、向量库、文档加载器。优点：生态最全；缺点：抽象层多容易过度封装，Anthropic Building Effective Agents 明确反对"过度抽象"。
• LangGraph（LangChain Inc.）：基于 LangChain 的有状态 graph 编排——把 agent / workflow 建模成节点 + 边，每个节点是 LLM 调用或工具，边可条件跳转。比 LangChain 更适合复杂多步 / 多 agent 协同；阿里飞猪等多 agent 业务系统主流选择之一。
• LlamaIndex（Jerry Liu）：聚焦 RAG，文档摄取 / 索引 / 检索 / 查询 pipeline 设计精细。RAG 重场景比 LangChain 更专业。
• Haystack（deepset）：开源 RAG 框架，企业级（含 K8s 部署 / API server），欧洲社区主导。
• Anthropic SDK 直调：Anthropic 在 Building Effective Agents 推荐——简单场景直接调 API 比裹一层 framework 更易理解、bug 更少。

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

2024-11 推出，2025-Q4 转入独立 Steering Committee（Anthropic / Block / OpenAI / Microsoft）。三种核心原语：

• Resources：可读资源（文件、DB 行）
• Tools：可执行函数（带 schema）
• Prompts：可复用 prompt 模板

解决"每接一个新工具就要写一遍 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 性能正比于工具描述清晰度"）：

• 工具描述像写 docstring：用途 / 参数 / 返回值 / 错误情况
• 粒度小、组合强（Read / Edit / Bash / Grep 而非 do_anything）
• 强制前置约束（Edit 强制 Read-before-Edit）
• 错误信息当 prompt（"command not found, did you mean X?"）
• Deny-first 权限

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 进入项目时自动读取。通常包含：

• 项目背景 / 架构概览
• 5 步会话开机协议：pwd → git log → progress 文件 → 启动 dev server → 跑基础测试
• 编码规范 / 风格约束
• 禁止操作（生产环境、敏感目录、unsafe 命令）
• 已知坑 / 反模式
• 测试运行方式

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

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

• git status allow
• git push --force deny（destructive）
• rm -rf 弹出用户确认
• cat ~/.ssh/* deny（敏感路径）

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

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

解法：

• progress.md / PLAN.md：agent 每完成一个里程碑写"已完成 X / 当前在 Y / 下一步 Z / 关键决策 / 风险点"
• git commit：每次代码改动强制 git commit + descriptive message，git log 本身就是工作日志，且能回退到任意状态

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

常见模式：

• 重试循环：tool 失败 → 重试一模一样的调用 → 再失败……
• 目标漂移：每步小修小补但整体没进展
• 互相否定：multi-agent 反复推翻对方决策
• 格式幻觉：死磕调不通的工具调用格式

防御纵深：

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

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

防御：

• 写入门槛：LLM 评估"事实可信度 + long-term value"双高才写
• 来源标记：每条 memory 带 source（user_said / tool_returned / inferred）+ confidence
• TTL 衰减：低 confidence 短 TTL
• 审计 trail：所有 memory 写入有 trace_id
• 用户可见可编辑：GDPR 合规 + 污染纠正
• prompt injection 防御：tool 返回数据标 untrusted，不直接写入

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

• Langfuse（开源 + SaaS）：开源 SOTA，self-hostable，trace + prompt 版本化 + eval + cost 跟踪一站式。中小团队首选。
• LangSmith（LangChain Inc.，闭源 SaaS）：LangChain 生态原生集成最深，trace 可视化好，eval framework 成熟。
• Phoenix（Arize AI 开源）：聚焦 LLM 应用的 trace + monitoring，集成 OpenTelemetry 好。
• Helicone（开源 + SaaS）：proxy 模式接入快，cost / cache hit / latency 监控直观。
• Patronus（SaaS）：聚焦"hallucination / safety detector"，做生产级实时拦截，企业方向。
• Datadog / Grafana / Prometheus：通用 APM / metrics 平台也开始支持 LLM trace（Datadog LLM Observability、Grafana Tempo）。

核心能力对齐项：

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。

按测什么能力分类：

• MMLU (Massive Multitask Language Understanding)：57 学科多选题，通用知识基准；GPT-4 ~88%。批评：题目泄漏严重、单选难辨细节差异。
• HumanEval（OpenAI 2021）：164 道 Python 编程题 + 单测验证，代码生成基准。已被刷穿（多数前沿模型 90%+），不再有区分度，推荐 SWE-bench Verified。
• MT-Bench（LMSYS 2023）：80 道多轮对话题，用 GPT-4 当 judge 1-10 打分。对话能力经典 benchmark，但 judge bias 严重。
• Chatbot Arena / LMArena（LMSYS / Berkeley）：真人盲评 pairwise，Elo 评分。最权威也最贵；2024 起被怀疑刷分（厂商针对性优化"问候 / 解释 / 列表格式"等 Arena 偏好）。
• LiveBench（Abacus AI 等）：月度更新题目防数据污染，coverage 推理 / 数学 / 代码 / 语言 / 数据 / 指令；持续更新性最强。
• BFCL (Berkeley Function-Calling Leaderboard)：Tool use / function calling 标准 benchmark，含 simple / multiple / parallel / multi-turn。
• GSM8K / MATH / AIME：数学推理基准，AIME 是 R1 / o1 当前主战场。

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

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

• Offline eval：在固定 dataset / 黄金集上跑模型 / prompt / pipeline，看指标。每次 prompt 改动跑回归，CI 上自动化。
• Online eval：线上流量上抽样评估，配合 A/B 看业务 metric 变化、bad case 检测、用户反馈打标。
• Pre-prod eval：上线前在预发流量上做 shadow eval（双跑不返回用户），对比新旧版本轨迹差异。
• Adversarial eval / Red team：人工 + 自动化构造对抗样本（jailbreak、prompt injection、edge case），评估安全护栏。

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 类型按打分方式：

• Reference-based（有标准答案）：精确匹配、BLEU / ROUGE、单测通过、答案集合命中——客观但需标注
• Reference-free（无标准答案）：LLM-as-judge 给 0-1 分或 1-5 分；适合开放生成、对话；judge bias 是大坑
• Pairwise：A vs B 对比，模型选型常用，agreement 比 pointwise 高
• User feedback：thumb up/down、CSAT、留存——业务侧最终验收

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

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

三大 bias：

• Position bias：pairwise 时 judge 偏 A 或 B
• Verbosity bias：偏好更长回答
• Self-preference：GPT-4 偏好 GPT-4 输出

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

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

工程缓解：

• 重排——把最相关 chunk 放最前/最后（reranker + 头尾穿插）
• 多轮检索 + 摘要而非一次塞满
• 用支持原生长上下文的模型（Claude / Gemini 1.5 Pro 在 RULER 上更稳）

OWASP LLM Top 10 的 #1。类型：

• 直接注入："ignore previous instructions, do X"
• 间接注入：恶意指令藏在 RAG 文档 / 网页 / PDF / 邮件 / 工具返回里——agent 时代的头号威胁
• 越狱（jailbreak）：DAN / role-play / many-shot
• Payload smuggling：Base64 / Unicode 同形 / 图片 OCR 注入
• Tool 滥用：让 agent 调敏感工具

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

来源：

• 训练数据偏差 / 过时
• RAG 召回不全或不准
• Context 太长信号被稀释
• 模型自由发挥（无 grounding）

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

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

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 的开，否则延迟/成本爆炸。

常见手法：

• DAN（Do Anything Now）：让模型扮演无限制 AI
• Role-play："我们写小说，角色 X 解释如何做 Y"
• Many-shot（Anthropic 2024 披露）：长 context 塞几十个假问答示例，让模型 ICL 后顺着回答
• Crescendo：多轮渐进式拉到敏感话题
• Encoding：Base64 / leetspeak / 低资源语言绕过

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