4.存怎么设计？过期时间是多少？
每个技能的历史版本写完就固定死了，缓存放心长久存放不用频繁过期； 只有正在线上运行的那个版本标识会经常改动，不靠缓存自动过期更新，后台一改配置就主动通知所有服务删掉旧缓存； 怕通知丢了，额外配一个短 TTL 保底纠错； 修改数据必须先写入数据库，再通过可靠机制推送缓存清理信号，同时删掉 Redis 缓存 + 服务器本机缓存； 所有缓存过期时间加点随机值错开，避免同一时刻大批量缓存集体失效压垮数据库。
- L1 缓存：服务本机内存缓存（进程里的 Map、Caffeine 之类，读取最快）
- L2 缓存：Redis 分布式缓存（多实例共用）
- CDC：监听数据库 binlog 日志，数据变动自动感知
- Outbox：事务消息表，和业务数据在同一个数据库事务，保证数据和消息原子成功
- 热 Key 使用
singleflight或按 Key 合并回源请求，避免缓存击穿。 - 不存在的数据可短时间负缓存，但权限结果和高风险策略不应长时间缓存。
- Key 必须包含租户、环境、版本和 Schema 版本，防止数据串用。
- Redis 故障时，普通配置可使用最近一次正确版本；权限和风险决策应 Fail Closed。
到底设置30秒还是30分钟？先由业务给出最大允许陈旧时间，在结合事件失效。不可变版本可以长缓存，可变指针只能短缓存或实时校验。
数据库更新成功但删缓存失败怎么办？使用事务Outbox或CDC重试失效事件，TTL只作为最终安全网。
本地缓存怎么同步？Redis Pub/Sub、消息队列或配置中心广播失效事件，并保留版本校验避免旧消息覆盖新值。
5.如果重新设计，我不会推翻现有的双层解耦，因为LLM推理层负责决策，确定性执行层负责变更是正确方向。我会重点补强五个方面。
第一，把Skill注册、评测和发布做成控制面，把任务执行做成数据面，Skill和Prompt都使用不可变版本，支持灰度和一键回滚。第二，把当前断点和快照进一步升级持久化状态或事件日志，使实例重启后也能精确恢复。第三，统一模型和工具网关，在一个位置处理超时、限流、熔断、幂等和成本预算。第四，减少同步链路中的重复查询，通过运行上下文快照、批量查询和分层缓存降低放大效应。第五，建立按Skill版本切分的SLO、轨迹回放和线上评测。是否引入Temporal一类工作流引擎，要根据任务时长和团队规模决定，小规模阶段自研状态机更轻，规模扩大后在考虑成熟引擎。
-
快照可以从文件级
difflib差分升级为内容寻址分块，降低大文件快照和恢复成本。 -
每个任务固定模型、Prompt、Skill 和工具版本，保证回放时环境可重建。
-
对外部副作用采用幂等键和补偿动作，不能只依赖文件快照。
-
优化顺序由压测与故障数据决定，避免为了"架构先进"提前引入过重组件。
-
当前系统最大的不足是什么？
当前测试和故障注入较充分，但缺少能够证明大规模生产运行的长期数据，这是后续最需要补齐的部分。
-
为什么不一开始就使用成熟工作流引擎？
它能提供持久化调度和重试，但也增加部署、学习和运维成本，早期需求尚未稳定时可能过度设计。
-
只能优化一个地方会选什么？
先补版本化发布与全链路 Trace，因为它们直接决定故障能否快速定位和回滚。
6.上线后接口耗时增加，怎么排查？
先确认"哪里慢、从什么时候开始慢"，在通过Metrics、Trace、Log分层定位，而不是直接猜数据库。
我会先比较P50、P95、P99和错误率，确认是整体变慢、尾延迟变差，还是某个接口、实例、Skill或模型版本异常；同时关联最近发布、流量和配置变更。然后用Trace将耗时拆成网关排队、应用处理、缓存、数据库、RPC、模型首Token和生成阶段，在检查CPU、GC、线程或Goroutine、连接池等待、缓存命中率、慢SQL和下游限流。
如果影响扩大，先回滚最近变更、限流或降级非核心能力。定位根因后再修复，并补充相应告警和回归压测。再传音项目中使用的traceId、OpenTelemetry、Prometheus和Open Search，就是为了把这三类证据串起来。
-
流式接口要分别观察排队时间、TTFT 和完整响应时间，不能只看请求总耗时。
-
重试会造成延迟和流量双重放大，应查看每个请求的尝试次数及重试原因。
-
若只有少数实例异常，应比较实例级 CPU、GC、连接池和依赖延迟，并先摘除异常实例。
-
数据库方向继续使用慢查询日志、
EXPLAIN ANALYZE、锁等待和连接池指标验证。 -
没有 Trace 怎么办？
先利用网关和应用日志中的请求 ID 做分段计时，同时尽快为关键依赖补埋点。
-
CPU 不高为什么还慢？
可能在等待数据库连接、网络、锁、模型配额或队列，低 CPU 并不代表系统没有饱和。
-
应该先扩容还是先回滚？
最近发布与退化高度相关时优先回滚；确认是合法流量增长且下游有余量时再扩容。