同花顺一面面经（10.9）

《面试题目》

1. 请做一下个人介绍，重点说明你的教育背景、核心技术栈和实习经历。
2. 研究生阶段的主要科研方向是什么？具体研究了哪些问题？
3. 实习期间遇到过哪些比较复杂的技术问题？你是如何解决的？
4. 如何应对接口错误和网络波动，保证整个流程能够稳定执行？
5. 重试机制是如何设计的？
6. 跨系统调用过程中如何保证接口幂等？
7. 如何保证并发安全和状态一致性？
8. 平时会如何使用 AI 辅助技术方案选型？
9. 线上出现报错或测试结果不符合预期时，如何利用 AI 定位问题？
10. Agent 系统上线后，如何收集用户对话流程和 Trace，并通过定时分析生成缺陷评估报告？
11. 如何根据缺陷的严重程度确定优化优先级，并持续改进 Agent Runtime、CLI 和 Skills？

《参考解析》

接口错误与网络波动下的稳定性。这类问题的答题骨架是「先分级，再分别给手段」。第一层是超时：所有跨进程调用都必须显式设置连接超时与读超时，且超时要沿着调用链逐级收敛——上游给下游 800ms，下游再往下最多只能留 500ms，否则会出现上游已经超时返回、下游还在跑的空转请求。第二层是重试，只对幂等的、可恢复的失败重试（连接超时、连接被重置、502/503/504、限流），对参数错误、鉴权失败、业务拒绝这类 4xx 一律不重试，重试只会放大错误。第三层是熔断与降级：连续失败到阈值就快速失败，别让线程都堵在一个已经挂掉的下游上；降级路径要提前定义好返回什么（兜底数据、稍后重试队列、明确报错），而不是临时写个空对象糊过去。第四层是隔离与限流：不同下游用不同线程池/信号量做舱壁隔离，入口按租户或接口限流。最后一定要说验证方式：用混沌注入（延迟、丢包、下游 5xx）跑一遍，看监控里的成功率、P99、重试次数和线程池队列深度，而不是纸上说「我会重试」。

重试机制具体怎么设计。几个必须讲到的点：① 退避策略用指数退避加抖动（1s、2s、4s… 再乘一个随机因子），纯固定间隔会在下游恢复的瞬间形成重试风暴；② 有重试预算，比如单请求最多 3 次、整体重试次数不超过总请求量的 10%，超了就快速失败；③ 重试要带上「为什么失败」的上下文，并把每次重试都打进日志和 metric，否则线上根本分不清是首次成功还是第三次才成功；④ 幂等前提，非幂等写操作要重试必须先拿到幂等键；⑤ 位置选择，网关层、SDK 层、业务层各重试一次就是 27 次，必须约定只在最贴近业务的那一层重试，其余层关掉默认重试——很多超时雪崩就是这么来的。

跨系统调用如何保证幂等。核心是「每次请求都带一个全局唯一的业务键，服务端按这个键去重」。落地有三条常见路子：一是数据库唯一索引或去重表，插入冲突即视为重复请求，返回上一次的结果；二是状态机 CAS，update order set status='paid' where id=? and status='created'，用受影响行数判断是否第一次执行；三是 Redis 的 SET key value NX PX 做短期去重，但它只适合挡瞬时重复，不能当最终一致性保障。要注意响应也要可重放：重复请求应返回与首次一致的结果，而不是报「重复提交」，否则上游会把它当失败继续重试。跨系统还需要最终一致性的兜底——本地消息表、事务消息或定时对账补偿，任何一端都可能丢消息。

并发安全与状态一致性。单机内先分清楚竞争的是共享内存还是共享数据：内存用锁或无锁结构（Atomic、CAS），要讲清锁的粒度和顺序加锁避免死锁。跨进程的共享状态则分两类：乐观锁（版本号，冲突少时吞吐好，失败要能重试）和悲观锁/分布式锁（冲突多或临界区耗时长时用，必须设过期时间并做续期、释放时校验持有者）。金融类场景还要特别强调一致性等级：能用数据库事务保证的绝不放到应用层用「先扣减再补偿」凑，需要跨库时走 TCC 或事务消息，并且每个状态流转都要单向、可重入、可审计。

用 AI 做技术选型与排障。选型时别直接问「用哪个好」，那只会得到一堆正确的废话。有效问法是给约束：数据量、QPS、延迟要求、团队熟悉度、运维成本、不能引入什么，让它列出候选方案的对比维度和各自的失效模式，自己再拿这些维度去查证。排障时 AI 最大的价值是「帮你提出假设」和「帮你读日志」：把异常栈、关键日志片段、监控指标、最近的变更一起给它，让它列出可能原因并按概率排序，然后你逐个去验证——顺序永远是先验证再相信。绝不把 AI 的结论直接当根因写进复盘。

Agent 上线后的可观测性与迭代闭环。要让每一轮对话有贯穿的 trace_id，把用户输入、模型请求与响应、工具调用及其参数和耗时、最终输出都按结构化日志落下来；采样上做到全量留错误、按比例留成功，注意脱敏。定时分析跑的是「把非结构化的失败对话聚成可归类的缺陷」：按失败模式聚类（工具报错、模型反复调用同一工具、格式不合法、答非所问、超时），统计每类的频次与影响用户数，生成一份能直接看的评估报告。优先级用影响面 × 频次 × 修复成本排序，别按「哪个好修先修哪个」；修完必须有回归用例，否则同一个缺陷会反复回来。迭代对象也要分清：Runtime 的问题（超时、重试、并发）改引擎，CLI 的问题（参数、报错信息）改工具，Skills 的问题（触发不准、步骤缺失）改提示与流程——分不清这三层就会一直在改 prompt 却治不好工程问题。