1. 自我介绍2. 如何在工程上实现兜底机制？具体到代码层面怎么做？答案：兜底机制不能只写一句“失败后重试”，要按失败类型分层。模型层可能超时、限流、返回格式错误；检索层可能无结果、召回低相关；工具层可能参数错误、权限失败、下游服务不可用；生成层可能答案无引用或不符合 schema。不同错误要有不同兜底，不能统一重跑。工程上我一般会做三层兜底：第一层是重试，比如超时、临时网络错误可以指数退避重试；第二层是降级，比如大模型失败就切小模型，rerank 失败就用召回分数排序；第三层是安全返回，比如证据不足就拒答，工具失败就返回部分结果和失败原因。对于有副作用的工具，不能盲目重试，必须加幂等 key...

真没招了，没人要

识别阻塞风险：死锁排查与线程推进保障实战 在并行 C++ 开发中，理解“阻塞”与“非阻塞”操作的本质区别是构建高性能并发系统的关键。许多性能瓶颈并非源于算法逻辑的复杂性，而是源于线程间不当的资源竞争导致的相互等待。本文将通过一个具体的累加任务案例，深入剖析基于互斥锁的阻塞实现与基于原子操作的非阻塞实现之间的差异，并揭示其背后的底层机制。 阻塞式实现的陷阱 为了直观展示阻塞带来的性能问题，我们首先构建一个基于 std::mutex 的同步场景。在这个示例中，八个线程协作完成一个共享变量的递增任务，总迭代次数为 （即 32768 次）。 代码结构分析 在阻塞版本中，大部分线程运行常规的 work ...