最佳实践

本章把 Anthropic 案例中可复用的工程原则提炼为检查清单，覆盖对齐、可解释性、推理优化、安全治理与算力策略五个维度。

对齐：把宪法当工程输入

• ✅ 宪法版本化：把原则集合纳入版本控制，记录每条原则的来源与修改原因；模型对齐结果应可追溯到具体宪法版本。
• ✅ critique-revise 可复现：Constitutional SL 的修订数据应可重放，便于回归与审计。
• ✅ 人类职责上移：让人专注于"写/审宪法"，而非"逐条标偏好"——这是 RLAIF 相对 RLHF 的核心杠杆。
• ✅ HHH 显式量化：用 Helpful/Honest/Harmless 设计评估集，定期度量模型在三者间的权衡。
• ❌ 不要把宪法当静态文档：能力演进后，旧原则可能失效或不足，需定期回顾。

可解释性：研究产出要能进工程

• ✅ 特征 → 监控：把 SAE/dictionary learning 发现的高风险特征（欺骗、双重用途）接入运行时监控，作为安全信号。
• ✅ 可解释性 artifact 入库：每次发布附带可解释性报告（特征清单、关键电路），与 Model Card 并列。
• ✅ 复用开源基线：基于 transformer-circuits 公开方法建立内部可解释性管线，而非从零造轮子。
• ✅ 解释 + 评估双轨：黑盒评估（benchmark/红队）与白盒解释互为补充，不互相替代。

推理优化：prompt caching 优先

• ✅ 结构优先：tools → system → messages，静态前缀前置，动态后缀断点之后。
• ✅ 断点放在稳定块：最后一个跨请求相同的块；避免时间戳/用户输入块。
• ✅ 按频率选 TTL：>5min 间隔用 1h，否则用 5m（命中免费刷新）。
• ✅ 核对模型档位：最小可缓存长度按模型分档（512–4096 token），缓存读倍率也分档（0.1x / 0.05x / 0.025x；Haiku 5.5 为 0.1x + 双档计价）——选型与成本模型要一起更新，且要跟随官方每季度的降价动作重算（2026 Q3 就有三次缓存读调价）。
• ✅ 用足 2026 新协议能力：新型号支持 mid-conversation system 与 inline tools，别再用"重发全量前缀"的旧姿势。
• ✅ 预热首请求：低峰期 max_tokens=0 写入 system/tools（官方正式用法）。
• ✅ 监控命中率：目标 > 80%；持续低命中先排查断点位置与 TTL。
• ✅ Agent 循环必缓存：多步工具调用重放历史，缓存几乎必需。
• ✅ Haiku 分流：简单/高并发请求路由到 Haiku 档位（Haiku 5.5 运行成本低约 75%），Opus/Fable 留给复杂推理。
• ✅ Batch 叠加：非实时任务走 Batch API 折扣，与缓存倍率叠加。
• ❌ 不要在 Bedrock/Vertex 上期待 automatic caching：旧版 Bedrock 只支持显式断点。

安全治理：用 RSP 思想搭门禁

• ✅ if-then 承诺：定义"能力达阈值 → 防护须就绪"的发布门禁，写入 CI/CD。
• ✅ 分类器即服务：输入/输出 guardrails 作为独立可演进的服务（参见 安全详解）；对高能力模型可借鉴 Fable 5 的"分类器路由"模式——可疑请求自动降级到更保守的模型。
• ✅ Risk Report 模板化：能力 / 威胁模型 / 缓解 / 残余风险四段式，作为发布 artifact；跟踪 RSP v3.x 的 CB-1/CB-2 阈值表述。
• ✅ 引入嵌入式第三方评估：借鉴 2026-10 独立评估者计划——给可信第三方"近似员工级"访问与独立发表权（预设删节项），把"自证"升级为可外部复核的监督。
• ✅ 红队自动化：建立自动化红队（变异 prompt、jailbreak 语料），人工红队聚焦长尾。
• ✅ 权重安全分级：参考 RAND SL 等级评估模型权重保护强度。
• ❌ 不要把安全当事后补丁：未达防护不得上线——这是 RSP 的硬约束，也是企业应借鉴的纪律。

智能体工程：从循环到运行时

• ✅ 沙箱是一等公民：工具执行必须有文件系统/网络/凭据边界；优先考虑 Managed Agents 这类托管运行时或等效自建（gVisor/Firecracker 级隔离）。
• ✅ 目标 + rubric 分离：借鉴 Outcomes 模式，用独立评估智能体按验收标准打分，而不是让执行者自评。
• ✅ 跨会话记忆受控：借鉴 Dreaming 模式让 agent 复盘历史，但记忆写入要可审计、可回滚。
• ✅ 多智能体要有共享状态与审计 trace：派单、并行、共享文件系统、完整 trace 四件套缺一不可。
• ✅ 订阅额度与 API 计费打通核算：Max/Team 已含月度 API 额度，企业成本模型要把订阅席位与按量调用合并计算。

算力策略：芯片多元化与容量前置

• ✅ 避免单一供应链：同时持有自研/专用芯片（类 Trainium）与通用 GPU，对冲供应与价格风险。
• ✅ 软件栈抽象：训练/推理框架在多硬件间可移植，避免被单一 SDK 锁死。
• ✅ 容量领先需求 6–12 个月：算力交付周期长，需求预测要前置。
• ✅ 多云托管：关键模型多云可用，提升可用性与议价能力。
• ✅ 电力/散热纳入规划：GW 级算力的瓶颈往往是能源而非芯片。

检查清单（上线前自检）

• [ ] prompt 结构是否符合 tools → system → messages 且断点在稳定块？
• [ ] 是否核对所用模型的最小可缓存长度与缓存读倍率？
• [ ] 是否监控 cache_read / cache_creation / input 三段式并达到目标命中率？
• [ ] 是否按用例选定了云（特性 vs 数据驻留）与 TTL？
• [ ] extended thinking budget 是否按任务难度动态配置？
• [ ] tool/computer use 是否运行在受限沙箱（自建或 Managed Agents）？
• [ ] 是否有输入/输出 guardrails 服务与红队流程？
• [ ] 是否有"能力阈值 → 防护门禁"的发布流程？
• [ ] 多智能体系统是否有共享状态、评估 rubric 与审计 trace？
• [ ] 是否有多源算力与多云托管的可用性预案？

反模式

• 把 cache_control 放在每请求变化的块上，零命中还付写入费。
• 在旧版 Bedrock 上误用 automatic caching 语义。
• thinking block 在不支持保留的模型上来回传递，污染上下文与缓存。
• 把 RSP/ASL 当营销话术而非发布门禁。
• 单一芯片 + 单一云，无容量对冲。
• 让长时程 agent 直接持有生产凭据跑在无审计的本地循环里。

小结

Anthropic 的最佳实践可浓缩为一句：让对齐管线化、让可解释性工程化（并进入运行时监控）、让缓存极致化、让安全门禁化、让算力多元化、让智能体运行时化。下一章用面试题检验对这些原则的理解。