英特尔一面

Agent 就是一个“会自己想下一步该干嘛的数字员工”。普通 AI 只会回答问题。Agent 会想 → 做 → 看结果 → 再想 → 再做。它就像是一个“会行动的 AI”。举个简单的🌰：帮我订明天去东京的机票。普通 AI 会回答：你可以去携程或者航空公司官网订票。而 Agent 它会：查询航班 API → 比较价格 → 选最便宜的 → 调用下单接口 → 把订单发给你现在我们的生活也逐步走向 Agent，如最近很火的千问以对话的形式用 AI 帮你下单奶茶，十分便利我们的生活。

说实话，如果不是最近这段时间重新出来面试，我可能不会这么快把「AI 应用开发」当成一件必须要补的能力。我做过业务系统、做过中台、也踩过高并发和复杂业务的坑。这几年主要精力都在架构稳定性、业务抽象、工程能力上。直到最近一次次面试下来，我明显感受到一件事：各个企业都在想着把AI应用到自己的企业中”。经过一段时间的了解，我整理出 Java 学 AI 的大致方向，我将按照这个路子走下去。我理解的「Java 学 AI」，不是去做什么？在真正开始学之前，我先给自己定了几个边界：不去卷算法、不搞模型训练不从 Python 数学公式开始不追求“AI 专家”人设而是明确一件事：我还是一个 Java 后端，只是要...

ai时代其实做底层的基础模型开发永远都是少数人，而大部分人其实做的依然是开发方向，agent，rag，后端这些。可能有人说我学agent不需要学后端语言，其实并不是这样。我看了公司的ai项目，其实也会涉及到一些缓存，数据库的存储。agent开发不止需要的是对于大模型的基础性理解，还是需要一定的工程能力。刚开始企业在招聘的时候，主要考察ai是因为产品还在初始阶段，用户量不算很大。用户量大到一定程度就需要工程能力了，降级，容错，数据存储，性能优化，这是工程能力，而ai幻觉，输出质量稳定性，agent编排，微调需要的是ai能力。以下是更偏后端的ai开发的全栈能力1.  基础后端能力一门业务语言，框架，体系(java/golang/cpp)核心是构建后端服务，语言并不是最重要的，框架也不是最重要的。后端能力学框架并不是框架本身，而是涉及到底层的网络/io/数据存储/操作系统。为啥用多路复用，怎么结合业务逻辑配置缓存淘汰策略，其实是对计算机本质的理解。框架，中间件都是一层套一层的，最终会回归到最本质的io与trade off2.ai能力超越调用API，需理解大模型的核心原理（如Transformer架构、注意力机制）及其能力边界。ai应用侧的能力prompt，rag，mcp，langchainagent编排3.大数据处理能力随着互联网公司的数据量增大，普通的mysql以及不能支持高效的查询。对于一些复杂的聚合计算，报表这些通过简单的行式存储(tp)已经不能满足未来的需要，所以出现了列式存储(clickhouse/doris)。需要了解从tp数据库的清洗流程(flink流式处理/离线处理)ai时代我认为，数据的作用将会不断增大4.垂直领域的业务能力互联网(金融/电商/社交/内容/直播)都需要ai来赋能以我所在的跨境电商行业为例，你是否熟悉电商下单到跨境物流(头程，尾程)再到合规等业务，能否打通业务全链路形成闭环为什么未来需要全栈能力？(1)ai提升了代码开发的效率，如果我们把java，大数据，ai分成3个岗位，中间的沟通时间就会浪费掉，而ai更加擅长的其实是技术细节的coding(2)做ai开发prompt，rag，agent编排的偏向ai侧的工程师，其实是需要非常熟悉业务的，而java工程师最擅长的就是业务，不如让一个人去做，效率最高，不懂业务做ai开发效率是没那么高的就像美团履约团队，让前端去转后端一样，有可能未来，全栈正在成为一种趋势所以，先广度，再深度，先把工程能力和ai能力的广度建立起来，再对一些方面进行深挖最后再来谈谈为什么我认为ai是取代不了程序员的。我认为最核心的一点就是未来写代码有可能是一个需要情商的事情？什么叫需要情商，就是你废力去做的一个需求，可能用户根本不需要。举个例子，产品问开发，你认为这个需求最多能够承受多少数据量，开发问产品，你认为客户的需求能做到多少数据量就可以了。像saas公司，你真的要做到满足客户100%的需求嘛，不是的，因为你真满足了，你的服务器成本会很高，公司发现不划算。这就是一个trade off的问题所以本质上程序员开发涉及到情商/成本trade off/商业化思维的时候，ai做不了了还有一点就是行业的业务，以我在saas公司的经历，我认为saas公司其实就是在垂类赛道把行业的业务知识搞透了，赢得了客户的信赖，而其中一些业务设计，ai理解起来会非常困难。垂直领域的业务知识或许会成为程序的壁垒之一

原文链接：HikariLan's Blog 当提到“如何为大模型提供大规模的可用于检索的信息”时，我们第一反应想到的大概率是 RAG 一类的解决方案，但现在我要说，基于文件系统访问（FileSystem Access）的检索方式可能远比使用 RAG 更好。 什么是 RAG？为什么需要 RAG？ **Retrieval-Augmented Generation（检索增强生成，RAG）**是一种可以允许 LLM 从大规模非结构化信息中进行语义检索的技术方案。 我们之所以需要 RAG，是因为大模型内置的知识内容可能不符合我们的需要，例如这些内容可能已经过时（因为用于大模型训练的语料库并不会随着使用者...