华为 车BU 软件算法

前情提要 本人29届毕业，这几天也是春招火热期，于是在boss上投了几个公司。发了几份简历之后，第四范式公司hr初步问我了一些vibe coding的经历，之后打算联系我进行面试。面试内容问：简历中AI Agents的开发经历是个人开发的还是在实习？答：前两个项目是个人开发，后一个是团队开发的（项目：工作流、AI框架、Agent多端应用）问：索要项目上线的网址和在这个Agent多端应用中负责什么方向？答：这个项目的后端是一个golang、python的微服务架构，其中golang负责后端，python负责ai层。前端则是web端为vue3，移动端为flutter。我负责的是全部的的ai层和golang后端的跨域通信和部分后端功能和web前端功能的改进设计。问：询问项目的主要功能，和如何实现？答：使用langchain、langgraph框架，首先把工具通过mcp-adapters进行打包，之后ReActAgent进行调用工具与数据库进行交互，另一方面在进行增删改操作时由于ai输出不一定满足用户的需求，我做了一个独立的确认节点作为拦截中间件，截断了数据的写入，而用户可以来自行编辑或保存删除。问：Agent的工作模式都有什么？答：ToolsCallingAgent、ReActAgent、ReflectionAgent、PlanAndSolveAgent（并粗略展开每一种大概机制，此处不多赘述）问：介绍一下你对RAG的理解？答：我平时不太喜欢用RAG，主要因为两点，自己开发的时候大多数用不到这个技术，RAG最好在垂直领域来使用，尤其是ToB或者专精某一特定领域，而且前段时间不少人说RAG已死，指的是现在很多东西能替代RAG的功能；其次RAG的召回率并不算太高，想要优化召回率只能花费大量人力财力来进行经验微调。知识库开发的流程一般是，先进行数据清洗，之后进行向量化储存到向量数据库，召回时在进行一个向量匹配的操作问： 看到你做了一个memory上下文记忆功能的处理，可以说一下处理逻辑吗？答： 记忆可以分成长期记忆和短期记忆，我在长期记忆这里使用的是RAG技术，将用户强调或者比较有价值的数据存入，这样可以作为一个跨对话窗口的上下文，而短期记忆我也是做了一个上下文压缩，用了一个经验值作为阈值，等上下午到一定程度之后就会进行精炼，而精炼又有两种模式，我分为智能模式和机械模式，智能模式是通过llm进行关键信息等提炼，机械模式是通过正则处理去除冗余的工具调用日志和结构化导致的上下文污染问：对于模型的选型你是否有考虑呢？答：之前自己做过coding agent等类似的项目，在多智能体系统中对于不同的任务采用的模型不同，比如plan使用主力模型opus，编写代码使用中等模型sonnet，而探索项目结构可以使用haiku等小模型，这样的话既可以节省token花销也可以不降低代码质量问：你是否有AI编程的经历和理解？答：略（先是说了市面上各ai编程工具的差异性优点及缺点和我自己的订阅情况，之后说了开发模式相关如spec driven。ps：可参考该文章 AI 原生工程）问：对于Agent有没有什么熔断机制？你有接触过么？比如你的基模直接卡死了，你的后端是否有什么保底机制？答：有的，在项目中我对tool calling做了一个熔断机制如果工具调用失败超过三次就会进行熔断处理，防止反复重试导致系统崩坏。如果基模卡死的话，完全可以弄一个集群来处理，如果一个服务器掉了可以快速转到另一个提供llm的服务器。最终也算是过了

最近有不少同学问我关于 AI 应用开发方向的求职思路，尤其是背景不算顶尖时该怎么规划。我自己是专升本出身、双非硕士，经历过两段实习——一家小厂和一家物流中厂，做的都是比较核心的业务，时至今日，也是拿了几个薪资还比较客观的offer。这篇帖子不讲鸡汤，只讲方法论，希望对正处于春招的同学们有参考价值。一、先把自己的背景看清楚，再谈规划很多人求职时第一步就去刷题、背八股，却没有想清楚一件事：自己究竟适合投哪类公司、哪类岗位？背景决定初始路径，这一点在 AI 应用开发方向尤为明显。以我的情况为例：专升本 + 双非硕，意味着在简历筛选阶段会被部分大厂直接过滤。接受这个现实，不是认命，而是为了把精力集中在...

记录一下今天的投递～有同方向的牛友一起加油！1、华为数字能源——AI应用工程师2、搜狐——AI Agent研发工程师3、软通动力——AI Agent开发4、星网锐捷——AI应用开发工程师5、中电福富——大模型应用开发工程师

最近大厂招 Agent 工程师的岗位非常多，没有入门的朋友可能觉得“Agent不就是调调 API 吗？”Agent 不同于传统的“一问一答”式 AI，它是在对话模型的基础上增加了一个自主循环，能够根据任务目标判断“还需要做什么”，并调用外部工具执行。理想中的Agent，人类一动嘴，LLM跑断腿，在我们还喝茶打哈欠的时候就把活全干完了，但在实际落地中，想做出一个稳定可用的产品，还是有很多难点的。首先是工具的适配。在一个可用的 Agent 系统中，AI 推理只占约 30% 的逻辑，剩下的 70% 都是非AI的工程化适配。Agent 必须能够稳定处理现实世界的接口边界问题，包括 OAuth 授权、Token 自动刷新、API 速率限制以及海量数据的分页处理。同时，工具的 Schema 定义直接影响调用准确率。优秀的 Agent 需要对工具的粒度和描述进行反复调优，确保模型在面对数十个可选工具时，指令遵循依然清晰稳定。其次是多步任务的可靠性管理。在长链条推理中，错误会随步骤指数级叠加。哪怕单步准确率达到 80%，连续执行五步后的综合成功率也会降至约 32.8%。这种概率衰减意味着一个微小的幻觉就能让整个任务偏航。好的 Agent 必须具备严密的状态管理，能够在执行异常时实现自动捕获、重试或逻辑回滚。在执行关键操作前，还需要设计逻辑校验环节，防止单个步骤的偏移导致整体任务崩溃。接着是上下文的信息治理。大模型在处理长周期任务时普遍面临指令丢失的问题，尤其是在频繁的工具调用产生大量冗余数据时，核心约束容易被边缘化，导致 Agent 出现“失忆”现象。优秀的工程实践需要实现动态内存管理，精准识别并保留关键指令和历史摘要，同时剔除无意义的中间日志。通过提高上下文的信息密度，不仅能降低幻觉风险，也能在多模型路由中有效控制 Token 成本。最近开源社区非常火的 OpenClaw就是一个典型的例子。它作为一个拥有极高系统权限的 Agent 框架，可以直接操作文件和执行命令，极大地扩展了 AI 的能力边界。但在实际应用中，它的提示词工程仍有提升空间。由于权限极高，如果提示词无法精准约束模型的行为，很容易在复杂的执行链条中产生误操作甚至安全风险，且频繁触发的记忆压缩和超高的token消耗也被人诟病。这也是目前高权限 Agent 在落地时面临的核心痛点之一。总的来说，Agent 开发的本质是构建一个以模型为核心的高可靠软件系统。调通接口只是基础，真正的护城河在于你如何处理那些繁杂的非 AI 细节，包括工具层的异常处理、上下文的动态压缩以及评估体系的建立。正在找相关工作的同学，可以看看你简历上的Agent项目，有没有针对以上的痛点做了有效改进，面试官会很感兴趣的。