2026 Q2-Q3 找 remote SDE 经历 - (2)

去年相关帖子： https://www.1point3acres.com/bbs/thread-1134770-1-1.html

上一篇
https://www.1point3acres.com/bbs/thread-1188516-1-1.html

这章先share System Design，Knowledge Base，心得分享放在下一篇。
（Disclaimer： 有用AI润色，内容量很大，推荐电脑上看， 现在Senior/Staff level就要掌握这么多。。。）
System Design - Knowledge Base

Part 1 · 后端基础

1. 性能优化（读 / 写路径）

主题	核心条目	Gotchas
Speed up on Read Path	CDN + ETag/304 → 缓存 → 索引 → 读写分离 → 游标分页 → HTTP/2 / gRPC	建索引 → 加缓存 → 读副本 → 垂直切分 → 最后才分库分表
Speed up on Write Path	异步削峰 → 批量聚合 → LSM 引擎 → 分区/分片	先主动讲代价：放弃强一致；写多读少慎加唯一约束和索引
Query Optimization / Denormalization	EXPLAIN ANALYZE、覆盖索引、避免 SELECT *、连接池(pgbouncer)	Seq Scan vs Index Scan
N+1 Query	ORM 循环逐条查库	改 WHERE id IN (...) 复制代码 批量 / JOIN / dataloader；严禁 for 循环 query SQL
CQRS	写进写优化表，Kafka 异步计算，拼大 JSON to Redis	读 API 变成 O(1) 的 Redis GET——空间换时间
Pagination（Cursor vs Offset）	offset 可跳页有总数；cursor 用唯一有序列( WHERE id > last 复制代码 )	offset 深翻页线性扫描 + 数据漂移重复；cursor 不重不漏但不能跳页；双向滚动用 direction+cursor 一个端点

2. 缓存

主题	核心条目	Gotchas
Caching Strategies	Cache-aside / Read-through / Write-through / Write-back .1point3acres	默认答 cache-aside；write-through 强一致但写慢；write-back 高写吞吐但缓存挂了丢数据
缓存三大问题	Cache Penetration（不存在的 key）/
Cache Breakdown（热 key 过期）/
Cache Avalanche（批量过期）	穿透：负缓存必须短 TTL(~60s) + Bloom Filter 防攻击；雪崩：TTL with Jitter
Cache Breakdown — SingleFlight	同 key 同时刻只放行一个回源，其余挂起共享结果	1000 个请求只查 1 次 DB；用 in-flight future 字典 + 结果广播；Go singleflight 同款
Cache Warm-Up	Lazy（按需回填）vs Active（预载 top-N / 部署时跑 / 周期预取）	崩溃重启后是冷缓存，lazy 有 stampede 风险；配后台 worker 分批"治愈"
缓存一致性	Version + Lua 乐观写入（缓存存 {value, version}）	拒绝"延迟双删", sleep 500ms 是撞运气；回写被 Lua 判旧不需要也不允许重试
两类 Redis 用法	cache（DB 是源）vs counter/状态（Redis 可能就是源）	cache 该设 TTL；counter 不该 TTL（一过期计数就没了），靠冷热分级 + 从 ClickHouse/DB 重建

3. 数据库与存储

主题	核心条目	Gotchas
Index	primary vs secondary vs global；复合索引；唯一索引	最左前缀；范围列放最后；低基数/频繁更新/参与函数的列不建；单表 ≤5 个；线上建索引必须 CONCURRENTLY（普通 CREATE INDEX 写全阻塞）
when should create index (read heavy vs write heavy)
Partition vs Sharding vs Read Replica vs Snapshot	分区=单库更好布局；分片=多库；副本=读扩展；快照=备份	replica 解决"读太多"，shard 解决"数据大/写多"；Snapshot 既不服务读也不服务写；大多数公司到不了 shard 那步
View vs Materialized View	普通 View 只是保存的查询；MV 物化聚合结果	普通 View 不加速；MV 必须配 CONCURRENTLY 刷新；物化引入"两个真相"是金融类 bug 之源
ACID	原子 / 一致 / 隔离 / 持久	分片后失去跨库 ACID → Saga
MySQL vs NoSQL vs TimeSeries DB	关系+事务 / 灵活 schema+水平扩展 / 时间主轴	文档库没有 JOIN；TSDB 核心能力 = retention 自动删旧 + downsampling + 高压缩
OLAP vs OLTP	列存(ClickHouse) vs 行存(PG/MySQL)	判断句："要一个算好的数字（OLTP 点查），还是在海量明细上现场算（OLAP）？"；CH 逐条 INSERT 是灾难，必须攒批/CDC 灌入
ElasticSearch / ELK . .и	倒排索引、coordinating node、Query-Then-Fetch；ES+Logstash+Kibana	ES 7.x 起也是 VectorDB（dense_vector+HNSW）；全文检索 + 数据量大才上 ES
Consistent Hashing	加减节点只迁移小部分 key；虚拟节点	它均匀分布的是 key 数量不是访问量——热点仍要多副本/本地缓存另解
Migration	Big Bang vs Incremental；加新字段；合并小表（同时读写）	Expand-Contract 四步：加可空列→双写→回填→收缩；判断标准：回滚代码不需要回滚数据库
PostgreSQL tools	pg_partman / pg_cron / pg_search / pgvector / PostGIS / pg_stat_statements / shared_buffers	分区裁剪是优化器的能力，partman 只管生命周期；WHERE 必须带分区键；retention 先 detach 别直接 DROP
CAP theorem	AP vs CP	口诀："读到旧数据的后果是什么？"损失→CP；体验略差→AP；逻辑混乱→因果一致 . Χ
Geo	Geohash / QuadTree / R-tree(PostGIS)；进阶 H3 / BKD(ES)	Geohash 边缘突变必须查 8 邻居格；高频 LBS→Geohash+Redis；多边形拓扑→PostGIS；多维复合检索→ES BKD
File Sharing — CRDT	结合律/交换律/幂等，副本自动收敛；G-Counter/OR-Set/LWW/RGA	不能真删除→tombstone 占空间；vs OT：离线更佳、无需协调

4. 并发与锁

主题	核心条目	Gotchas
Pessimistic vs Optimistic lock	FOR UPDATE 行锁 vs version 乐观锁	冲突多→悲观，冲突少→乐观；timestamp 代替 version 有坑：时钟不同步/同毫秒精度/时钟回拨
SELECT FOR UPDATE vs UPDATE WHERE vs SKIP LOCKED	何时用哪个	优先级：条件 UPDATE > 行锁 > 分布式锁——很多时候根本不需要锁；SKIP LOCKED 只在"多实例 poll 同一张表抢行"时需要（从 Kafka 消费不需要）；短任务 SKIP LOCKED、长任务 lease
Distributed lock（Redis TTL + Lua）	SET NX EX 抢锁；Lua 校验 owner 才释放	TTL 防死锁 + watchdog 续期 + owner 校验防删别人的锁；主从切换可能丢锁——涉钱要 DB 兜底 . 1point 3acres
死锁预防	多行更新前按主键升序排序再申请锁	所有 worker 同序加锁永不成环——从根上消灭死锁
撮合/配对	Redis ZSET 按 Elo 入池 + 动态放宽窗口（10s ±50 → 60s 任意）	Lua 原子"检查双方在池+同时 ZREM"防双重配对；升级到股票撮合：同 symbol 单线程串行 + 成交强一致事务

5. 幂等与消息可靠性

主题	核心条目	Gotchas
Idempotency key	复杂度阶梯：Lv1 唯一键 → Lv2 状态机 → Lv3 version → Lv4 lease	按需叠加别全上；
Snowflake ID	41 位时间戳 + 10 位机器 + 12 位序列；全局唯一+分布式生成+天然有序	不能做实体幂等键（每次生成都是新 ID）——实体幂等键 = entity_id + version；UUID 无序、DB 自增单点都不行
乱序判定	必须用源头顺序标记（event_time / 源端单调 seq）	接收方生成的 ID 反映到达顺序不是发生顺序；条件 UPDATE WHERE last_event_time < :new 复制代码 + 终态不可回退
Transactional Outbox/Inbox	业务写入 + 事件写入同一本地事务；Relay 发 Kafka；Inbox check 去重；SKIP LOCKED 抢 pending (Relay)；version/timestamp check	Outbox（不丢）+ Inbox（不重）= 两大支柱；relay 崩溃靠租约超时回收（可砍心跳，不能砍回收）；监控 outbox_lag
Exactly-Once	At-least-once + 消费端幂等 = Exactly-once Effect	纯分布式 Exactly-once Delivery 不可能
本地事务 vs 远端 RPC	调外部 RPC 前用独立事务先落 PROCESSING	最深的坑：本地回滚抹不掉外部已发生的扣款 → 重试再扣一次；超时置 UNKNOWN（不是回滚）异步查清

6. 消息队列与异步处理

主题	核心条目	Gotchas
消息中间件选型	Kafka vs AWS SQS vs Redis + Celery	Kafka= 持久,高吞吐,可重放 的 commit log（不是任务队列）；SQS=点对点省运维；Redis Pub/Sub 不持久化——绝不用于不能丢的消息, 低延迟+瞬时广播+动态订阅；Celery 默认不保证顺序
Kafka	topic / partition key / consumer group / DLQ / how to handle hot key partition	只保证分区内有序——同实体串行不同实体并行；扇出必须用不同 consumer group（同 group 是分摊）；拉取有序 ≠ 处理有序（多线程/重试/rebalance 都会乱序）；严格有序场景 DLQ 会破坏顺序
Temporal Signal	精准投递给已存在的 workflow 实例	目标明确 → Signal；广播/削峰/重放/解耦 → Kafka；中间加 Kafka 是多此一举
WAL / CDC	Debezium 订阅 WAL → Kafka → 下游	CDC 是"持续同步"不是"删之前才搬"；零侵入不轮询
Stream / Batch	Flink（流、滑窗聚合）/ Spark（批、月度重算）
全局ID	Snowflake ID	全局唯一
大致有序
分布式生成
Orchestrator	Temporal / Restate vs Airflow vs Celery	Temporal=持久状态机（durable timer、Signal、Saga、可睡几个月）；
Airflow=数据 DAG；
Celery=短异步任务；
审计哲学：Temporal 永久事件账本可重放

7. 高可用与扩展

主题	核心条目	Gotchas
CP vs AP -baidu 1point3acres	强一致 vs 高可用	钱/库存/座位→CP；feed/点赞/推荐→AP
Sharing: Push vs Pull / Fanout vs Hotspot	写扩散 vs 读扩散；混合策略	普通用户 push、大 V pull——"读能靠缓存 scale，写放大是硬的"；大频道只推在线且正看的人
Usage Too High（连接数/CPU/内存/磁盘/缓存）	逐资源排查 + 扩容/优化	先分清"正常负载"还是"bug"（请求没涨 CPU 涨=修 bug 别加机器）；I/O 密集服务别按 CPU 扩容，用请求数/延迟/队列深度
3rd Party API connection	retry（带 max 次数)
exponential backoff with jitter circuit breaker
timeout
多 provider 路由 / local fallback	调用前先落 pending 状态；外部超时 ≠ 失败（可能已执行）——进 UNKNOWN 对账收敛；熔断三态 Closed→Open→Half-Open，Open 走降级并告警

8. API 设计与通信

主题	核心条目	Gotchas
RESTful vs GraphQL vs gRPC	对外开放 / 内部微服务	REST 能吃 HTTP/CDN 缓存；GraphQL 难缓存 + N+1 resolver 会冲垮 DB；混合模式：内部 gRPC + 对外 REST + 前端 GraphQL BFF
API Gateway vs LB	Gateway 管 API 治理（鉴权/限流/计费）；LB 管流量分发	WebSocket 要 L4（NLB）或显式支持 Upgrade 的 L7（idle timeout 调大）；可以串联：Gateway → ALB → 服务
HTTP 方法与幂等	POST（创建，不幂等）/ GET / PUT（替换，幂等）/ PATCH / DELETE（幂等）	创建必须 POST 不是 GET：有副作用、GET 会被预加载/爬虫重放、长 URL 进日志泄密；写接口带 Idempotency-Key
HTTP header / code / URL 参数	Authorization: Bearer、Content-Type、Cache-Control/ETag、X-Request-Id；401 vs 403 vs 429	401=未认证（名字误导）、403=已认证无权限、429 要带 Retry-After；资源标识放 path、过滤分页放 query；身份从 JWT 派生不放 body
Version control	URL /v1 最常用；header 版本；DB 配 Expand-Contract

9. 协议与实时通信

主题	核心条目	Gotchas
连接方案	WebSocket vs Long Polling vs Polling vs SSE vs Webhook	SSE 单向、自动重连、仅文本——LLM 流式输出首选；
WS 双向但有状态难扩展；Webhook 是服务器对服务器——必须幂等+重试+快速 ACK，且要轮询兜底（webhook 会静默丢）
Fanout 分层	internally：Redis Pub/Sub vs Kafka；
externally：WS vs SSE vs Webhook vs standard API	Pub/Sub 与 WS 是一条链路的两段：Pub/Sub 解决跨实例扇出、WS 推到浏览器；
要持久+重放→Kafka，瞬时广播+动态订阅→Redis Pub/Sub
Cookie vs Local Storage vs IndexedDB	自动随请求携带 / JS 读写 5MB / 结构化大容量	cookie 才有 CSRF 问题（SameSite+HttpOnly+Secure）；token 放内存/localStorage 由 JS 显式加头则天然免疫 CSRF

10. 认证、授权与安全

主题	核心条目	Gotchas
Auth：JWT vs Session	无状态验签 vs 服务端存储	JWT 难撤销→短 access + refresh / 黑名单；金融要能立即踢人→倾向 session 或 JWT+黑名单；payload 是 base64 可解码不是加密
Authorization	OAuth2、AWS IAM、VPC	概念分层：Bearer=怎么传、JWT=什么格式、OAuth2=谁来发（授权）、OIDC=登录认证；IAM 最小权限=blast radius 最小化；DB 放私有子网
Attacks	SQL injection / XSS / CSRF	SQLi→参数化查询（绝不拼 SQL）；
XSS→输出转义（React {} 默认转义；绝不 dangerouslySetInnerHTML）；CSRF→只在 cookie 认证时存在；
传输安全 → HTTPS TSL，encode/base64 不是安全措施

11. 部署

主题	核心条目	Gotchas
Stages	Dev vs Main vs Canary vs Prod；集成测试	Staging 用清洗过的 prod 数据保持 parity；Canary 1-5% 真实流量看指标自动回滚 (error rate、p99 latency、业务指标)
发布方式	Rolling deploy
Health check
rollback
downgradable
12-factor	铁律：code 和 schema 绝不同一次 deploy 里同时变；回滚代码不需要回滚库；worker 要 graceful shutdown（SIGTERM 处理完再退），队列里旧 task 引用旧 code 是经典坑
Batch migration	track status → atomic；分批回填	主键分批 id > last LIMIT 1000 复制代码 （不用 offset）+ 幂等条件(new_col IS NULL) + 每批独立提交 + 批间 sleep 看 replay_lag + atomic=False；migration 单独 job 跑一次且幂等

12. 文件上传与流媒体分发

主题	核心条目	Gotchas
文件上传	Client 直传 vs Server 中转；Pre-signed URL + Multipart	大文件必须 presigned 直传 S3（不占服务器带宽）；multipart 5MB 分片并行+断点续传；upload_id/UUID 幂等防重复；异步做缩略图/审核
流媒体（视频/音频分发）	切片(2-10s) → HLS/DASH manifest → CDN → ABR	切片是秒开与 ABR 的基础；
基于 HTTP 所以能走 CDN；
ABR 发生在客户端播放器；
直播=滚动 manifest（TTL 2s）、点播=完整 manifest；
CDN Cache Key 要忽略 token 参数否则命中率归零；
播放鉴权在"发签名 URL"时做，CDN 只管传

13. 搜索与检索（含 AI Search）

主题	核心条目	Gotchas
Embedding 检索	ANN vs cosine 精确计算；HNSW 索引	ANN 近似换速度，百万级毫秒返回；query 和 doc 必须用同一个 embedding 模型（同一向量空间）
BM25	TF-IDF 升级：词频饱和 + 长度归一化	唯一 ID/错误码/型号这类精确匹配向量搜不准——BM25 完胜；冷启动无需模型、可解释
Hybrid + RRF	BM25 + 向量并行召回 → RRF 融合（score=Σ 1/(k+rank)，k≈60）	只看名次不看不可比的分值；奖励双榜一致；无需训练
Rerank：bi-encoder vs cross-encoder	bi=分别编码可预计算（召回）；cross=query+候选一起进模型（精排）	cross 准但不能预计算——只对 Top-50 精排出 Top-5；两阶段=快,准
ES vs PgVector vs Pinecone	全文+多维复合 / 一库三索引 / 专用向量库	中小规模 pgvector 够（HNSW 百万级）；一个 Postgres 同时做向量+BM25+精确三种索引是架构简洁性论证；精确数字永远走结构化库不靠向量

14. 监控与可观测

Feature	Tool	Gotchas
APM	Scout	三大 golden signals：error rate + latency(p99) + saturation
Logging	Papertrail	诊断漏斗顺序不能倒：Metrics → Logs → Trace → Host（SSH 最后）
Alert	Grafana	告警要 paging-worthy 不只 dashboard；
成本类告警用 relative-to-p99 per tenant，不用绝对阈值
Protocol	OTel	trace_id 串全链路；span 上报必须异步 fire-and-forget，绝不阻塞主循环
AI logging	Langfuse	产品视角（对话好不好/成本/prompt 版本）；底层是 ClickHouse
Trace	Jaeger	工程视角（哪一段慢）；与 Langfuse 同一份 OTel span 扇出两个后端
方法论	SLI / SLO / SLA + Error Budget	SLI=测量、SLO=内部目标（更严）、SLA=对客承诺（更松要赔钱）；预算用完停新功能保稳定

15. Python 并发模型

主题 . 1point3acres.com	核心条目	Gotchas
多任务模型	Process（Pickle）vs Thread vs Coroutine;
multiprocessing / threading / asyncio	GIL 限制 CPU-bound 多线程；CPU 密集→multiprocessing,
I/O 密集→asyncio or multithread；
asyncio 工具	asyncio.Semaphore、asyncio.TaskGroup、gather	Semaphore 限并发防打爆下游；
独立调用用 gather 真并行
应用框架接口	ASGI vs WSGI	WSGI 同步一请求一线程；ASGI 异步支持 WS/SSE 长连接

16. 受监管行业铁律（Finance / Healthcare / Security / Logistics）

铁律	做法	Gotchas
Decimal	金额一律 DECIMAL，计算用 quantize(ROUND_HALF_UP)	绝不 float；也不是 int 截断
Append only	账本/审计表只插不改	改错追加反向分录；权限层只授 INSERT/SELECT 强制执行
Audit log	每次状态变更/数据访问留痕	关键不是存哪，是 何时写：与状态变更同一事务 ——"状态变了但审计没记"这种状态不存在
Idempotency	幂等键唯一约束(创单/打款/链上 nonce/事件）	见第 5 表阶梯；外部 RPC 超时进 UNKNOWN 不回滚
Consistency	钱=强一致；展示类=最终一致	按"不一致的后果"选级别，不是全上强一致
Tenant isolation	JWT 提取 → 代码强制注入过滤 → DB RLS 兜底	应用层 WHERE 漏一个就泄露——RLS 是"忘了也被挡"的保险
Double-entry ledger	每笔资金借/贷两条，同 transaction_group 必须平衡	不变式：借方总和=贷方总和，不平即资损 bug；可用余额 = allowance − spent − held
Reconciliation with source of truth	分层对账：即时（事件驱动）/小时/日终/月度	不是单一日终 cron；偏差分类处理（时序差/红冲/补分录/金额不符冻结+人工）；对账进程独立于 pipeline 代码

17. Redis Lua 六大原子场景

场景	原子逻辑	Gotchas
分布式限流	检查窗口内计数 < 限额？→ +1 允许，否则拒绝	检查+计数必须一体，分开发并发下会超限
支付/钱包授权	可用余额(balance−held) ≥ 金额？→ 冻结(held+)	防两个并发都读到"够"超额批准；余额为 nil 返回 −1 从 DB ledger 重建
库存扣减（秒杀）	库存 > 0？→ 减 1	防超卖；"谁需要谁顺手清理"过期预留也包进同一脚本
分布式锁释放	锁是我的？→ 才删除	防删别人的锁（自己的锁已过期被他人持有）；Redlock 的释放就是 Lua
原子计数 + 过期	INCR + 首次设 EXPIRE	否则 EXPIRE 可能永远没设上
令牌桶/漏桶	惰性回填计算令牌数 + 判断 + 扣减	tokens=min(cap, tokens+(now−last)×rate)，无需后台进程
通用边界	—	单条命令本身原子（INCR/SETNX）别包 Lua；慢脚本会卡死整个 Redis（单线程）；集群跨 slot 不支持

Part 2 · AI 系统

18. AI Agent 与 ReAct

主题	核心条目	Gotchas
Pattern：RAG vs ReAct	Retrieve-then-Reason（检索一次）vs Agentic RAG（检索在循环内）	query 模糊/检索质量参差 → 检索放循环内可重试；"先直接检索，结果差才改写"优于预判 query 质量
Function tool call	LLM 决定 WHAT，代码决定 HOW	LLM 永远拿不到 DB 凭证；工具输出截断 ~4000 字符防炸 context；"Errors are prompts" - 错误信息要可行动
Notepad / Launchpad	工作记忆累积工具结果	notepad 是 verifier 做 grounding 比对的真值来源；每步状态 checkpoint 到 DB 可断点恢复
Trace	Langfuse + OTel	每步一个 span（agent.step.n）；agent 以涌现方式失败，没 trace 无法复现——non-negotiable
Input/Output guardrail	注入/越界/PII 检测；输出防泄露防幻觉	便宜的先跑（规则/小模型）贵的后；输出端核心是确定性 Verifier 不只是过滤器
Citation / Grounding	SQL 结果带 entity_refs → 拼产品页 URL 作可点击引用	每个论断能追溯到工具结果；检索为空就说没找到，don't guess
Verifier vs Judge	Judge = response vs rubric（要标准答案，只能离线）；Verifier = response vs notepad+context（不要标准答案，能上生产）	"用 LLM 核对 LLM 不可靠"——核心必须确定性（实体存在/数字/引用/遗漏）；裁判跨厂商防偏袒；失败分级降级：宁可不流畅但正确
编排选型：Temporal vs LangChain vs LangGraph	跨进程持久执行 vs 快速原型链 vs 图状态机	LangGraph：supervisor 路由 + 共享 state + approval gate interrupt 等人、PostgresSaver 持久化；Temporal：长任务/崩溃恢复/durable timer/审计；LangChain 全家桶换确定性差——生产更常用 BAML+Temporal 自组

19. MCP 与工具设计

主题	核心条目	Gotchas
MCP	Tools / Resources / Prompt templates；stdio vs Streamable HTTP	解决 N×M→N+M；stdio 本地最常用零端口；"MCP is connection, Skills is instruction"
Tool description & schema design	说清用途 + 何时用 + 何时不用 ；窄输入任务导向	分页对 LLM 是敌意的→设计成 search+hint；工具 >15 个选择能力下降；每 agent 3-6 个工具一个领域
BAML	schema+prompt 一体、强类型容错解析（含流式 partial JSON）	可能被脏数据污染的字段用 Union/Optional 防契约击穿；允许 is_uncertain:true 绕去人工——别让 AI 硬顶边界异常
高危写操作（补充）	two-call confirmation：prepare→token→confirm；按可逆性分层限流	确认 UI 直接渲染给用户不经过 LLM（elicitation）；scope 服务端强制执行——永不信任 LLM 遵守 scope

20. 租户隔离与安全（AI 场景）

层	检查	Gotchas
API level check	JWT 提取 tenant_id 绑定请求（不可变）	整条请求链只认这个 tenant；LLM 碰不到 tenant_id（由代码控制）
Tool call 层	prompt injection check；SQL 强制注入 WHERE tenant_id	工具输出用 untrusted 标签包裹当数据；特权操作绝不由不可信内容触发；SQL 只读+白名单表+超时行数限制
Input/Output guardrail	入口挡注入/越界；出口查tenant isolation/ PII/hallucination
DB RLS	Row-Level Security as the backup

21. LLM 网关与路由

主题	核心条目	Gotchas
LLM Router	LiteLLM / Bifrost	铁律：不从 orchestrator 直连 LLM API， 网关做路由/failover/缓存/限流/成本打标；
分级路由	分类/解析→小模型；
复杂推理/生成 SQL→强模型	静态路由（按步骤写死）生产最常用；
用 eval 数据决定哪步能用便宜模型 ，不是拍脑袋；
成本护栏 SOFT 80% 降级 / HARD 100% 拒绝

22. AI Eval

主题	核心条目	Gotchas
LLM as Judge	任务+输出+rubric → 分数+理由（结构化、低 temperature）	三层金字塔：确定性规则先过滤（省 100% 裁判费）→ LLM judge → 人工抽 5% 校准；
"不校准就是新的随机数"；
跨厂商 judge 防偏袒；
硬事实用确定性 scorer 别用 judge
Save cost	Prompt Caching + Batch API + 分级模型 + smoke test / test leveling	缓存最左匹配——"死的放前面活的放最后"，改一个字后面全失效；Batch API 五折（24h 期限，回归专用）；
commit 只跑 smoke 10-20 个，merge/nightly 跑全量；
能确定性判的绝不用 LLM
Tool	Braintrust（+ Langfuse 沉淀数据集）	闭环：生产 trace → 在线打分圈选 → 数据集 → 离线回归 → 不退化才灰度；
golden 基线入 git
test-case	task/workspace/tools/expected/rubric/forbidden_actions 六字段	反作弊红线防 Lucky Pass（删测试/硬编码/吞报错）；每次运行打包 Episode Package（trace.jsonl 心智轨迹）可复现可审计

23. 多模态

模态	工具/模型	Gotchas
OCR	Tesseract / Amazon Textract / Google Document AI	传统 OCR 只有几何视觉、语义断裂；多模态大模型空间-语义统一（看懂表格线/加粗/手写并推断业务含义)， 但要接确定性校验
Voice	CLAP（声音气质）；
STT + 流式 ASR + VAD 端点检测 + TTS	STT 丢声音特征、音频 embedding 补"怎么说的"- 两路互补；
ASR - Deepgram vs Whisper
VAD 静音 300-500ms → AI 接话		.1point3acres
Video	CLIP（抽帧 + 池化聚合）	大部分场景抽帧够用；要动作/时序才上 VideoCLIP/SlowFast；query 与库同编码器同聚合
Text	text-embedding	跨模态（文字搜图/音）必须 CLIP/CLAP 统一空间，纯文本 embedding 做不到
Token control	接入层强制动态缩放	单图视觉 token 压 500-1000（否则 2000 patches 开销 ×10）；
多模态输出直接收敛到 BAML 强类型，别"请描述这张图"