这段时间越来越强烈的一个感受是：现在不少人对 Agent 开发的理解，还停留在“接个大模型接口 + 配几个工具 + 跑个演示页面”这个阶段。但只要项目开始往真实场景走，问题立刻就会从“能不能跑起来”，变成“能不能稳定工作”。也就是说，Demo 阶段拼的是搭建速度，落地阶段拼的是系统能力。真正折磨人的，从来不是那几行 API 调用代码，而是后面一整串工程问题：工具该怎么组织，模型才能正确选用？检索链路怎么设计，召回效果才足够稳定？上下文越来越长时，记忆如何管理？模型一本正经胡说八道时，系统如何收口？想让体验更自然，流式输出该怎么处理？这些才是 Agent 开发真正开始“见水平”的地方。先说一个现实：AI 能力正在变成开发岗位里的加分项，甚至是筛选项这两年看招聘信息，一个很明显的变化是：很多原本偏传统的开发岗，也开始把“大模型应用经验”“AI 能力优先”写进 JD。这不是写着玩的。原因很直接：一边是常规业务开发岗位越来越卷，另一边是 AI 应用侧的需求还在快速增长。尤其是搜索、客服、内容、运营提效、企业知识库这些场景，几乎都在试图用 LLM 或 Agent 方案重做一遍。你现在看到很多大厂产品里陆续出现的 AI 搜索、AI 助手、AI 问答，本质上都不是一个单纯的聊天框。它们背后往往对应的是一套更复杂的任务系统：理解意图、选择动作、访问工具、检索信息、组织输出。所以今天很多岗位说的“需要 AI 能力”，实际想看的是：你是不是具备把大模型接进业务系统、并把它做得可用的能力。那工程岗到底需要懂到什么程度？很多人会卡在这个问题上：做 Agent / LLM 应用开发，到底需要学到算法岗那种深度吗？通常不用。如果你走的是工程落地路线，不一定非要像研究岗一样追论文、啃前沿训练细节。但有些基础原理不能只停留在“听说过”。至少下面这些，最好不是模糊概念：Transformer 的基本工作方式Attention 为什么能处理上下文关系LLM 输入输出有哪些约束token、上下文窗口、采样这些因素如何影响结果为什么模型会幻觉、为什么长上下文会退化原因也很简单：Agent 的很多设计问题，最终都会回到“模型本身是怎么工作的”。如果对底层行为没有基本理解，你会发现自己只能停留在“调参数碰运气”的层面。而一旦线上效果不稳定，就很难判断问题到底出在 Prompt、检索、工具设计，还是模型本身的边界上。Agent 开发最难的部分，不是搭框架，而是处理这些工程细节很多人第一次做 Agent，最自然的路径就是：选一个现成框架套一个 ReAct 或函数调用模板接几个工具跑起来看效果这个阶段当然没问题，入门都得这么开始。但项目往前走一步，你就会发现真正复杂的是下面这些问题。1）工具不是“注册进去”就结束了，关键是模型能不能正确理解和调用很多人说做 Agent，本质只是“让模型学会用工具”。但实际难点不是“工具有没有”，而是“模型会不会在对的时候用对的工具”。这里面至少有几个层面：工具描述写得是否清晰输入参数是否容易被模型抽取多个工具功能相近时如何避免误选工具之间有没有依赖关系调用失败时是否能恢复或改道如果这些设计得不好，模型表面上“具备工具能力”，实际使用时却可能频繁选错、漏调、乱调。所以所谓的 skills / tool embedding，不只是把函数挂进去这么简单。本质上是在做一件事：让模型形成对工具能力边界的准确感知。2）RAG 最大的坑往往不在“接没接检索”，而在“检索质量是否足够支撑回答”很多 Demo 做 RAG 都很快：切文档、做 embedding、建索引、召回、拼上下文——看起来链路完整。但一旦文档复杂起来，问题就来了。最典型的是 chunk 怎么切。切得太碎，信息上下文断裂，召回回来也是残缺的；切得太大，噪声太多，检索相关性又会下降；固定长度、按段落、按语义边界、带不带 overlap，不同场景下效果差异可能非常明显。而且这件事没有万能模板。FAQ、规章制度、技术文档、长报告、表格型内容，它们适合的切分方式经常完全不同。所以 RAG 的核心不是“我用了向量库”，而是：文档结构怎么理解索引怎么组织召回和重排怎么配合切分策略如何贴合业务内容真正做过的人都知道，RAG 里的很多优化，本质是在跟数据结构和业务语义较劲。3）Memory 管理，决定了 Agent 能不能越聊越像“同一个系统”只要涉及多轮对话，记忆一定是绕不过去的问题。因为对话越长，历史越多，token 消耗越高，模型的关注能力也会变差。这时候不能简单粗暴把所有历史都往上下文里塞。比较常见的做法包括：保留最近若干轮的滑动窗口对历史内容做摘要压缩把关键信息结构化存储将长期信息放到向量库里按需检索不同策略会直接影响两件事：系统是不是记得住重要信息系统的回答是不是还能保持稳定和连贯所以 Memory 不是“要不要加”的问题，而是“你打算怎么平衡成本、连续性和命中率”的问题。4）幻觉不是一句“接了 RAG 就好了”能解决的很多人刚接触 LLM 时，最容易低估的一点就是幻觉。模型给错答案最麻烦的地方，不只是“错”，而是它往往会很自信地错。如果这个问题出现在客服、搜索、企业知识库、流程问答里，用户体验会非常差，严重一点甚至会直接带来业务风险。所以真实系统里，RAG 通常只是第一层兜底，不是全部。更稳妥的做法往往还包括：要求答案绑定引用依据对检索结果做可信度判断在低置信场景下触发拒答对关键结果加规则校验或二次验证明确让模型学会输出“不确定”或“不知道”换句话说，落地时要接受一个现实：你不能只想让模型更会答，还要让它在不该答的时候收得住。5）流式输出看起来是体验细节，实际背后也是系统设计题很多产品都希望模型能像打字一样边生成边输出，因为用户会觉得更自然、更快。但只要你做过，就会发现流式输出远不止是“打开 stream=true”这么简单。你要考虑的事情很多：用户看到的是中间思考过程，还是整理后的最终答案工具调用前后怎么切换展示状态输出到一半被打断时怎么处理前端交互怎么避免抖动和错乱长任务执行时如何让用户知道系统没卡住这些问题本质上都在影响一件事：Agent 的行为在用户看来是否连贯、可信、可控。很多 Demo 可以跑，但体验很糙；真正能上线的系统，往往在这种“细枝末节”上花了很多工夫。工程侧真正被看重的，是你能不能把“大模型能力”变成“系统能力”做 Agent 到后面，你会越来越觉得，这件事其实非常像后端和系统设计问题的延伸。不是单纯“会不会调模型”，而是：如何设计模块边界如何编排复杂流程如何处理异常和重试如何做状态管理如何做观测、评估和迭代所以面试里真正容易拉开差距的，也往往不是“你用过哪个框架”，而是你有没有思考过这些工程问题。框架本身当然重要。像 LangGraph、LlamaIndex，或者一些多 Agent 协作方案，面试里经常会被问到。不是因为它们本身有多神，而是因为它们代表了一种工程化思路：流程怎么拆、状态怎么传、节点怎么控、检索怎么接。说白了，面试官想知道的是：你是不是具备把一个大模型 Demo，推进到接近真实业务系统的能力。语言不是重点，重点是你有没有把东西拆开研究过很多人担心自己原来做 Java、Go、后端开发，不知道转大模型应用会不会很难。我的看法是，语言切换反而经常不是最大问题。Python 真正上手没有那么高门槛，工程能力强的人适应起来通常很快。难的是另一件事：你愿不愿意把黑盒拆开看。比如：去读成熟项目的源码跑通一个完整开源方案自己改 prompt、改检索、改工具逻辑观察失败案例，再一点点修对比不同实现的差异只有你真正改过、撞过墙，才会知道哪些地方是文档不会告诉你的。而这些“踩坑经验”，恰恰最容易在面试和工作中体现出价值。最后一句话：Agent 的门槛，从来不是把模型连起来，而是把系统做扎实如果只是做一个演示页面，门槛确实不高。但只要你想让它进入真实场景，事情立刻就会变复杂。真正需要补的，不是“再学一个新框架”，而是这两层能力：对 LLM 工作方式的理解对工程系统设计的把控前者决定你知不知道模型为什么会这样表现；后者决定你能不能把它变成一个可维护、可扩展、可上线的东西。如果你也在往 AI 应用或 Agent 方向转，不用一开始就焦虑自己是不是懂得不够多。先找一个真实项目，跑通，拆开，修改，复盘。很多认知不是“看懂”的，是“做懂”的。