线上最容易踩的坑：把锁冲突抛给上游重试，流量一来直接雪崩。分层兜底才是正解。 数据库层：锁等设超时（30到100毫秒），超时走降级。开死锁检测让库自动回滚代价小的事务。 应用层：能改乐观锁就改。保留悲观锁时事务要短，事务里别调 RPC。乐观锁示例：UPDATE stock SET count=count-1 WHERE sku_id=? AND version=?，影响行数 0 即重试。 架构层：库存先预占再异步核销，丢单比挂掉强。Redis 锁挂了熔断返回本地缓存。 降级本质是延迟换可用性。钱强一致，库存容忍几秒，排行榜最终一致就行。... 展开详请

生产级 Agent 运行时中将 Harness 拆分为“路由层（Router）+ 多策略执行器（Executor）”的目的，是把自由 think-act-observe 循环里容易失控的不确定性（如停止时机、策略切换、降级回退、安全触发、成本与时延）通过路由层前置“控制面”而钉住；路由层根据请求特征与风险信号先决定使用哪种执行器，并下发停止/预算、工具与权限边界、合规安全规则以及输出结构合同，使执行器在固定策略下完成任务并输出可验证结果。若不拆合并在一层，线上最先暴露的往往是控制失效类故障，例如预算或停止条件失控导致成本与延迟爆炸、工具滥用/权限越界、合规与拒答策略不一致引发概率性事故，以及由于缺乏分层决策记录而造成可观测性与可复现性下降；因此当意图不适合自由循环、证据链不足、预算接近阈值、安全风险升高或历史轨迹显示发散时，应由路由层将其降级为确定策略而非继续自由循环。... 展开详请

如果预算只够认真做一层，我会优先补检查点与失败接管这一层。原因是：线上“模型变强但成功率不动”，往往不是推理能力不够，而是失败后无法收敛与恢复（超时、工具副作用、状态丢失导致反复重试）。有了检查点与可恢复状态，Agent 才能在预算耗尽、工具失败、异常注入时降级退出、回滚或续跑；这直接提升稳定性与可用性。权限清单与评测隔离也重要，但它们通常是“优化与治理”，而检查点/失败接管是“生存底座”。... 展开详请