26届 数分商分 简历 求锐评

第一次真正感受到“技术判断”这四个字，不是在写完代码的时候，而是在一次方案评审前。需求看起来并不复杂，业务要上线一个新能力，时间不算宽裕，但链路很长，涉及多个模块联动。导师把文档丢过来，只说了一句：先别急着写，先把可能出问题的地方找出来。 我最开始也和很多实习生一样，下意识会先看接口、看表结构、看怎么把功能做出来。但越往下梳理，越发现这不是一个“把需求实现”就结束的任务。高并发场景下，任何一个看起来正常的调用路径，都可能在流量起来之后变成瓶颈；任何一个默认重试、超时设置、依赖堆叠，都可能把局部问题放大成全链路抖动。 于是我先没动代码，反而花时间把调用链、异常路径和兜底逻辑一条条画清楚。哪些请求...

三月二十多号开始投，到现在投的要么挂了要么都还在简历筛选，是简历项目太简单了吗

1. 如果让你设计一个 Agent 的规划器，怎么避免它每一步都重新规划，导致路径震荡？规划器不能每拿到一个 observation 就整体重算，不然很容易出现前一步刚决定检索，后一步又改成总结，再下一步又回去检索，整个执行路径会来回抖动。更稳的做法是把规划分成“全局计划”和“局部调整”两层。全局计划只定义阶段目标，比如信息收集、证据校验、结果生成；局部调整只允许在当前阶段内微调具体动作。另外要给 planner 一个明确的状态表示，比如当前子目标、已完成步骤、失败原因、剩余预算。如果没有状态约束，模型会把每次新 observation 当成全新任务来理解。线上一般还会加“重规划阈值”，只有在...

，有没有什么老主神学，祝我一臂之力