2026 Q2-Q3 找 remote SDE 经历 - (2)跳槽
robin888
去年相关帖子： 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. 性能优化（读 / 写路径）
2. 缓存
3. 数据库与存储
4. 并发与锁
5. 幂等与消息可靠性
6. 消息队列与异步处理
7. 高可用与扩展
8. API 设计与通信
9. 协议与实时通信
10. 认证、授权与安全
11. 部署
12. 文件上传与流媒体分发
13. 搜索与检索（含 AI Search）
14. 监控与可观测
15. Python 并发模型
16. 受监管行业铁律（Finance / Healthcare / Security / Logistics）
17. Redis Lua 六大原子场景
Part 2 · AI 系统
18. AI Agent 与 ReAct
19. MCP 与工具设计
20. 租户隔离与安全（AI 场景）
21. LLM 网关与路由
22. AI Eval
23. 多模态
上一篇
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 | 默认答 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 兜底 |
| 死锁预防 | 多行更新前按主键升序排序再申请锁 | 所有 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 | 强一致 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 并发模型
| 主题 | 核心条目 | 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 接话 | ||
| Video | CLIP（抽帧 + 池化聚合） | 大部分场景抽帧够用；要动作/时序才上 VideoCLIP/SlowFast；query 与库同编码器同聚合 |
| Text | text-embedding | 跨模态（文字搜图/音）必须 CLIP/CLAP 统一空间，纯文本 embedding 做不到 |
| Token control | 接入层强制动态缩放 | 单图视觉 token 压 500-1000（否则 2000 patches 开销 ×10）； |
| 多模态输出直接收敛到 BAML 强类型，别"请描述这张图" |
已获得 31 大米
+2
共0条回复
