1. 这个时代的焦虑，其实是一个信号
最近几年，我经常收到两类截然相反的留言。一类是还在校的学生，问“现在AI写代码这么强，我是不是不用再死磕数据结构了”；另一类是工作三五年的工程师，问“Agent都自己写代码了，我这套传统的软件工程基本功，还有没有价值”。
这两类问题放到一起，答案其实并不矛盾——正因为Agent开始承担越来越多机械性的编码工作，软件工程的基础能力反而变得更加值钱了。但它值钱的地方，跟十年前不一样了。过去我们强调“写代码的能力”，现在更强调的是“定义问题的能力”、“拆解任务的能力”和“验证结果的能力”。
我自己是从Agent开始被大规模讨论的那个节点开始，有意识地把一部分日常工作交给工具去做的。踩过不少坑，也交过不少学费。在这个过程中，我慢慢形成了一个很强烈的感受：Agent不会让软件工程基础变得无用，它只会把“基础”这个词的边界往外推了一大圈。以前你会写循环、会写递归、会设计数据库表，算是基础扎实；现在你得会描述目标、会划分任务边界、会设计Agent的工作流、会判断它输出的结果到底靠不靠谱——这些才是新的基础。
我很早就发现一个真相：最典型的Agent翻车，往往不是因为它不会写代码，而是因为它根本不知道你真正想要什么。它能秒写一个排序算法，但它不知道你的排序场景里数据量只有几百条，用最简单的冒泡就够了，引入复杂算法纯属增加理解成本。它能生成一整套REST API，但它不知道你的团队约定是错误码统一走业务异常。这些信息，它需要你“喂”给它，而你之所以知道要喂什么，靠的正是传统软件工程里需求分析、系统设计的能力。
所以，这篇文章我想认真聊聊，在Agent时代，软件工程基础到底应该学什么、怎么学，以及哪些过去被认为是基础的东西，现在的位置发生了变化。不谈太虚的，尽量给些我自己验证过的方法和思路。
2. 基础的地壳运动：哪些能力被Agent削平了，哪些被抬高了
2.1 被Agent“接管”的领域：机械性、模式化的编码工作
这个变化不是突然发生的，而是渐进积累的结果。最早是代码补全，帮我们把一个函数体写完整；后来是代码生成，给个注释就能产出一段逻辑；再后来是智能体，给它一个任务描述，它能自己改好几个文件然后跑测试给你看。
被压缩最厉害的部分，是我称之为“搬砖型编码”的那类工作。比如：
- 写CRUD接口，从Controller到Service再到Mapper的固定套路
- 生成单元测试的骨架、Mock数据、边界断言
- 根据接口文档生成DTO、VO、枚举类
- 把一批符合规则的代码从旧框架迁移到新框架
- 整理配置文件、依赖版本升级后的兼容性适配
这些工作的共同特征是：模式清晰、重复度高、验证标准明确。这类活儿交给Agent，效率确实是人的数倍，质量也相对稳定。我自己现在写新项目，这类代码几乎不手写了，描述清楚需求，Agent半小时能产出我以前至少要干一天的模板代码。
但这带来一个很微妙的问题：以前新人入职，是靠写三个月CRUD来熟悉业务、理解项目结构、培养代码审美的。现在这条路径被切断了——如果新人上来就直接用Agent写代码，他可能连项目底层的请求链路都还没弄明白，就已经“产出”了一堆看起来正常、实则跟团队规范格格不入的代码。
这不是工具的问题，是学习路径没有跟着调整的问题。所以我会在后面专门说，Agent时代，新人到底该怎么用工具来学习，而不是被工具替代掉学习过程。
2.2 被“抬高”的基础：描述能力、验证能力、决策能力
机械性工作被压缩之后，人的精力应该重新分配到哪里？我的答案很明确：描述、验证、决策。这三个词，本质上就是新的软件工程基础。
先说说描述能力。我给团队讲过一个很生动的对比：同样让Agent“写一个用户注册接口”，新人可能就一句话，Agent交出来的东西漏洞百出；但一个有经验的工程师会这样描述：
“实现一个用户注册接口，逻辑如下：校验邮箱格式和密码强度；邮箱不能重复注册；注册成功返回用户ID和Token；如果邮箱已存在，返回业务错误码1001；所有字段校验失败时返回第一个错误信息。数据库表结构参考users表的现有设计，不要加不必要的冗余字段。”
同样一个任务，两种描述，产出的质量天差地别。差别在哪里？不是文笔，是这位工程师脑子里已经有了一整套对业务规则、异常路径、数据模型、代码规范的理解。他把这些理解转化成Agent能执行的指令，这才是这个时代真正的“编程能力”——用自然语言把问题定义到机器能够理解的程度。
再来说验证能力。以前写代码，写完跑一遍，看个结果对不对就完了。现在Agent生成的代码，表面上看着天衣无缝，实际上隐藏的问题是跑一遍根本发现不了的。你得会做代码评审，知道哪些位置容易出现并发问题、事务问题、空指针问题；你得会设计测试用例，知道边界值要覆盖哪几个点；你得能判断，一个功能它写完了，但“写完了”和“写对了”之间还有多长的路。
最后是决策能力。这个更抽象一点。举个例子：同样一个需求，Agent给了三种实现方案，各有优劣，你怎么选？选错了后面要返工。这种决策不是拍脑袋，而是基于你对系统架构、团队能力、业务优先级、运维成本的综合评估。这种东西，工具给不了你，只有理解系统的本质，才能做出靠谱的判断。
2.3 一个核心判断：基础没有失效，而是向“上游”转移了
经常有人问我，那你觉得软件工程基础到底有没有过时？我的看法是，它不是过时了，而是向“上游”转移了。
想象一条河流。以前我们要在下游做很多事情，比如亲手烧砖搬砖，现在机器帮我们把砖都烧好了，我们就不用在河边做苦力了。但我们要把精力转移到哪里？转移到决定这条河往哪流、水坝建在哪里、如何分配灌溉、如何防洪防汛——这些是上游的事情。这些事以前被忽视了，因为下游那堆杂活已经耗尽了所有人的精力。现在杂活被Agent接过去了，我们终于有余力去思考上游的问题。
对新人和在校生来说，这意味着什么？意味着你不能再抱着“先学三年Java基础语法再去找工作”的心态，因为Agent已经把你学的那三年语法压成了三天的工作量。你要学的是：如何把一个模糊的诉求转成清晰的系统设计；如何通过工具快速验证自己的设计是否正确；如何在一个大型代码库里找到问题的根源。
那是不是说算法、数据结构、操作系统、网络协议这些就不重要了？恰恰相反，这些变得更重要了。因为你指挥Agent写代码时，如果你根本不知道B+树和哈希索引的区别，你就无法判断它给你选的数据库索引方案是否合理；如果你不懂TCP三次握手，你甚至不知道它写的网络超时处理代码根本不可靠。只是说，这些知识的考核方式变了——以前是笔试填空，现在是实战判断。
3. 面对不确定的Agent输出：软件工程最核心的素养反而凸显了
3.1 代码评审的新维度：从“读代码”到“理解意图”
代码评审这件事，在Agent时代变得既痛苦又关键。痛苦是因为，你不再只是评审同事写的代码，还得评审Agent写的代码，而且Agent产出的代码量远大于人类同事，你可能一天要看清几千行AI生成的代码。
但关键的地方在于，评审的维度变了。以前我们主要看代码本身是否合理、有没有bug、风格是否统一。现在这些当然也看，但更重要的是，你要判断Agent是否真的理解了你的意图。因为Agent很容易写出一段“看起来对但其实隐含了错误假设”的代码。
举一个我实际踩过的坑。一次我让Agent给一个支付模块增加超时自动关闭订单的功能。它很高效地写完了逻辑，代码结构、命名、异常处理都挑不出毛病。表面看一切正常。但我仔细追了一下它的实现链路，发现它在判断“超时”时用的是create_time + 30分钟 > now这样的表达式，这本身没问题，问题是它压根没考虑时区问题。
后来我在评审意见里加了一条：所有时间相关字段必须在UTC时区统一处理，展示层负责转换。重新让它改了一遍。这种问题，如果不具备分布式系统、时间处理这些基础素养，你是根本发现不了的。你只会看到那堆代码“跑得通”，然后某天凌晨突然被电话吵醒，说线上订单不在商城系统里。
这个案例说明，代码评审这个传统软件工程环节，其实是Agent时代最不该丢掉的阵地。它从“看代码是否规范”升级成了“看Agent的操作是否符合你的设计意图”，而要做到这一点，你必须对自己的系统、业务、基础设施有极其清醒的认知。
3.2 测试与验证：别信“它跑通了”，要信“它能扛住变化”
以前我们写测试，主要是为了回归，防止自己哪天改东西把旧功能弄坏了。Agent时代的测试，价值更重了一层：它是你验证Agent工作成果最核心的手段。
我的经验是，凡是Agent写的重要代码，至少要过三关：
第一关是单元测试。让Agent自己写测试是有点偷懒的，但它确实能写出不错的单测骨架，你要做的是把边界值补全。第二关是集成测试，验证它在整个系统里的协作能力，比如数据库事务是否正常回滚、缓存与数据库是否一致。第三关是压力测试与故障演练，这在涉及并发、分布式场景时尤其重要，Agent的代码在正常负载下跑得很好，一上量就崩的情况我见过很多次。
说得直接一点，Agent时代“验证”这个基本功的门槛，比过去更高了。过去你可以直接拿生产环境的流量来验证，出了问题再改。现在不行——Agent的生产力太高了，如果你每次都拿生产环境当测试环境，你的故障率会被它成倍放大。所以，一套完整的CI/CD流水线、每个环境可复现、自动化测试全覆盖，这些纯软件工程实践的重要性，在Agent时代被极大地抬升了。
3.3 系统稳定性与可观测性：Agent帮你写的代码越多，你越得看得懂系统
Agent帮你写的代码越多，你的系统就越像一个黑盒。你不知道它在里面做了什么决策、绕过什么逻辑、以什么顺序执行。这时候，可观测性就变得生死攸关了。
说实话，以前我对日志、链路追踪这些东西没有特别上心，总觉得能跑就行，出了问题再F12看看就行。但自从大量使用Agent之后，我变得极其依赖可观测性体系。因为Agent改代码的速度太快了，如果我没有一套实时系统状态视图，我根本无法判断它改完之后的系统到底是健康的还是亚健康的。
现在我的项目里，日志记录、Metrics指标、链路追踪这些是强制要求，任何一段Agent写入生产环境的代码，都必须有完整的日志和监控覆盖。这不是为了看日志自嗨，而是为了让问题能被快速定位——Agent代码出问题的时候，错误信息往往是抽象的、不完整的，你只能靠系统监控还原它当时的运行轨迹。
这些做法的底层支撑，依然是你对分布式系统、网络协议、操作系统的理解。你以为你在学“可观测性”这个单一技能，其实你是在把大学里学的操作系统、计算机网络、数据库原理这些知识，全部调动起来、真实用起来。
4. Agent时代真正值得深耕的四项核心基础
4.1 任务拆解与流程设计：工程能力的新核心
如果让我从整个技能树里挑一个最重要的东西，我会选“任务拆解与流程设计”这一项。它不只是把需求拆成小任务，更是把一个模糊的目标变成一系列机器可以逐步执行、中间有验证关卡的工作流。
举个例子。以前我接到一个“给系统加一个导出报表功能”的需求，脑子里就是：写接口、写导出类、调工具库、加权限。现在我是这样想的：
- 第一层：用户在前端点什么按钮，触发什么事件
- 第二层：这个事件需要什么参数，这些参数从哪里来
- 第三层：后端拿到参数后，先做什么校验，再怎么做数据查询
- 第四层：数据量很大时，走同步还是异步，超时怎么办，失败怎么提示
- 第五层：文件生成之后存哪里，怎么给用户下载，怎么清理过期文件
然后把每一层变成Agent的输入，让它去完成每一层的编码工作。中间每一层完成后，我都会设置一个检查点，要么跑测试，要么肉眼评审。这样即使Agent某个环节出错了，我也可以在最小的范围内修正，不至于整条链路崩掉。
这套方法论，本质上就是传统软件工程里“模块化”、“高内聚低耦合”思想的现代版本。只是以前这些思想用在自己写代码上，现在用在指挥Agent干活上。
4.2 大语言模型交互能力：Prompt工程与Agent编排
这一项比较新，但正在快速变成基础中的基础。我指的不仅是“怎么写好Prompt”，还包括“怎么设计Agent的编排流程”。
简单理解，Prompt工程是“用自然语言让模型准确理解你的微观指令”，Agent编排是“用流程让模型在宏观上沿着你的思路去执行复杂任务”。
以我自己常用的Agent开发框架为例，一个复杂的任务通常会被拆成Role、Task、Context几个部分：
- Role：告诉Agent它现在是什么角色，比如“资深后端工程师”
- Task：具体到它能执行的步骤，比如“先读取配置目录下的XXX.yml，再根据schema生成对应的Java DTO”
- Context：提供任务的背景信息，比如“数据库连接池用的是HikariCP，Mapper框架是MyBatis Plus”
- Constraints：明确边界，比如“不要修改pom.xml，不要引入新依赖”
这些经验，跟软件工程里的“面向对象思想”是一脉相承的——你需要给Agent一个明确的上下文对象，否则它只能从自己的“先验知识”里找答案，找到的往往是不适配你的场景的答案。
而且，Prompt工程不只是文字技巧的问题，它更考验你对模型本身工作机制的理解。比如，你知道模型是逐token预测的，你就知道长上下文的注意力会衰减，就该把最关键的信息放在最前面或最后面；你知道模型有幻觉问题，你就会在编排Agent时加入“引用来源”“输出置信度”这类机制来缓解。
4.3 分布式架构与系统设计：Agent技术栈的地基
很多做Agent开发的朋友，一开始只关注Prompt和框架，完全忽略了系统设计能力，结果吃得亏不少。
典型问题包括：Agent异步任务的队列积压、调用外部大模型API的超时重试、多个Agent并发执行时的状态管理、分布式环境下Agent记忆的共享与一致性、Agent节点的水平扩容和故障转移。这些问题，没有一个不依赖分布式系统的基础。
拿Agent记忆来说，现在几乎所有Agent框架都支持记忆功能，让Agent能跨会话记住用户偏好。但如果你不懂分布式存储，你永远不会意识到Agent记忆的底层实现会带来多少一致性、容量、安全上的问题。比如，把记忆直接存在本地内存里，第一个问题是服务重启会丢，第二个问题是水平扩容后不同节点的记忆不互通。这两个问题，任何一个不懂分布式基础的人，都需要踩坑之后才能体会到。
所以我的建议是，分布式架构与系统设计，不但要学，而且要往深了学。你现在学的每一个概念——一致性、可用性、分区容错、分布式事务、消息队列——都在未来Agent系统的设计和运维中等着你。
4.4 数据建模与领域驱动：从“会写代码”到“会定义边界”
传统软件工程里，数据建模和领域驱动设计是一项高级能力，一般是在做到资深工程师或架构师之后才被重点要求的。但在Agent时代，这项能力变成了基础中的基础。
原因很简单：Agent最擅长的是“实现逻辑”，最不擅长的是“理解业务边界”。你不知道业务边界，就没有办法告诉Agent哪些逻辑应该属于订单域，哪些属于支付域；哪些状态是订单固有的，哪些是外部系统同步过来的。没有这些边界的定义，Agent写出来的代码会是一团乱麻，越叠越厚，最终恶化到没人能改得动。
我最近一个项目，要求Agent把“用户邀请有礼”功能从主业务里拆出来，变成一个独立服务。如果我对领域边界定义不清楚，这个问题根本没法分给Agent去做——它会一头雾水地问我：邀请关系数据属于用户域还是活动域？奖励发放的消息该由谁来发送？用户查询邀请状态时要不要实时检查过期？
这些问题的答案，都来自领域建模。所以我会建议每个做Agent开发的人都刻意练习这门功课：拿到一个业务需求，先花半天时间做领域建模、画清上下文边界、定义好核心概念和关系，再把结果喂给Agent去实现。看起来前期多花的时间，在返工成本上能几十倍地节省回来。
5. 跨学科的新基本功：从“程序员”到“系统构建者”
5.1 为什么Agent开发需要认知科学、心理学和批判性思维
我最近越来越觉得，Agent开发的难点，有一大半不是技术，而是人本身的思维模型。
为什么这么说？因为Agent本质上是模拟人类智能的东西，你要去揣摩“它认为什么是对的”“它可能在哪里偷懒”“它的注意力会被什么吸引”，这不就是对人类认知的研究吗？一点不夸张，懂一点认知科学和心理学，对理解Agent的行为模式帮助很大。
举个例子，Agent经常在长任务中间忘记最初的约束条件。这个现象特别像人的工作记忆有限——一开始你跟它说的十条规则，它可能只记住了头两条和最后一条。为什么？因为它处理长文本的时候，注意力会被临近的信息牵引。如果你理解了这个认知机制，你在给它安排任务时就会刻意把重要的事情重复说三遍、放在任务的多个节点上反复强调，而不是觉得“我说过了它就该记得住”。
批判性思维就更重要了。我在用Agent的这两年里，最大的体会是：它给你的任何答案，都不能直接采信，而是要当成一个“需要验证的假设”来对待。就像你带了个效率极高的实习生，他给你的每一行代码，你都得用自己的判断力过一遍。这种习惯的培养，本质上是批判性思维在工程实践中的运用。
5.2 人机协作中的沟通基本功：把复杂意图翻译成机器可执行的指令
现在这个时代，写代码的能力正在变成一项“翻译能力”——把人类复杂、模糊、充满隐含信息的意图，翻译成机器能理解、能执行的精确指令。
这个能力怎么练？我自己的方法是刻意练习“无歧义描述”。比如，我经常让自己做一个小游戏：拿一个技术需求，先自己写一遍自然语言描述，然后让不同的大模型根据描述实现，再看看它们的产出和我的预期差在哪里。每次有差距，就回头改我的描述，直到它们都能产出我预期中的结果。
这个练习看似简单，实际上非常考验人的系统思维。你需要知道哪些信息机器无法凭空推理出来，必须显式写清楚。比如“对列表进行排序”，你得告诉它排序规则是升序还是降序、排序字段是哪个、null值怎么处理、稳定排序还是不稳定排序。这些细节，一个没有经验的新手根本不会想到要写清楚，而Agent也不会主动问你——它会直接替你做决定，然后你验收时才发现不是你想要的东西。
5.3 领域知识：你永远不会被替代的护城河
写代码这件事本身是最容易被AI替代的，但你脑中积累的领域知识，反而是最难的替代品。我甚至觉得，当代码生成变得像喝水一样容易时，对一个业务领域的深刻理解，会成为工程师之间最根本的分水岭。
举一个很直白的例子：两个工程师，都用同一个Agent框架，都让Agent给金融风控系统写一个“逾期率计算模块”。Agent生成的代码结构是差不多的，但两个工程师对“逾期”这个领域的理解天差地别——一个知道“逾期”要分M1/M2/M3阶段，计算口径要考虑容差期、还款顺序、节假日顺延；另一个只知道“超过还款日没还钱就是逾期”。前者的Agent能生成可以直接投产的代码，后者的Agent生成的东西上线第二天就会被业务方骂得狗血淋头。
所以我始终认为，基础不只是代码层面的东西，对业务的理解同样是基础。你越懂一个行业、一个领域里的业务逻辑，你指挥Agent的能力就越强，你的产出就越不可替代。
6. 写给不同阶段的你：一条Agent时代的软件工程基础学习路径
6.1 在校生/转行者：从“写代码”到“构建系统”的思维切换
如果你还没毕业，或者正在转行，那我给你一个比较务实的学习顺序：
第一步，还是要把经典基础课学透。数据结构与算法、操作系统、计算机网络、数据库原理，这四门课是无论如何都不能跳过的。你不需要成为算法竞赛高手，但你必须理解时间复杂度和空间复杂度意味着什么，必须知道TCP和UDP的区别，必须能解释数据库事务的ACID。因为这些概念，是你未来判断Agent产出质量的基本标尺。
第二步，熟练掌握一门主力开发语言，以及这门语言的主流框架。注意，是“熟练掌握”而不是“看过教程”。对照Java或Python或Go，你得能独立完成一个包含用户认证、数据库操作、日志记录、异常处理的小项目，全程不用Agent代劳。这个过程是为了建立肌肉记忆和代码感觉，是后面跟Agent协作的前提。
第三步，刻意练习“拆解和验证”。找一个中等复杂度的开源项目，尝试不看源码只读文档，把它的启动流程、核心模块、数据流转画出来。再用Agent让它实现一个小功能模块，然后自己写测试用例验证它的输出。反复这样练，你的“拆解和验证”能力就会快速生长。
6.2 在职开发者：把日常工作变成训练场，而不是等系统化培训
很多在职开发者的困惑是，白天要写业务代码，哪有时间系统学新东西？我的答案是：不用额外花时间，你的日常工作就是最好的训练场。
每次用Agent之前，先花两分钟想一想：这次我要不要让它做？如果让它做，我该怎样描述它才能一次做对？做完之后，我要怎么验证？这个“想一想”的过程，就是在训练你作为指挥者的核心能力。
另外，主动承担一些跨模块的活儿。比如，以前你只负责写接口，现在主动去参与部署架构的调整、性能调优、故障排查。这些工作强迫你接触更底层的基础知识，也让你的Agent工具在这些场景里发挥作用——你可以让它查日志分析故障原因，让它写一个压测脚本，让它模拟线上流量评估系统容量。用着用着，你的系统设计能力、运维能力、问题排查能力就全提升上来了。
6.3 架构师/技术领导者：重构团队的基础能力模型与招聘标准
最后聊一聊Leader视角。我带过几年团队，现在最大的感受是，招人标准一定要变。过去我们看候选人会不会写Spring、会不会调优JVM，现在这些虽然还有一定参考价值，但我更看重的是另外几项：
- 能不能把一个复杂问题讲得清清楚楚，其他人听到就能落地执行
- 能不能在拿到一个需求后，快速找到其中的模糊地带并主动澄清
- 遇到Agent给出的错误结果，有没有一套自己的排查和验证思路
- 对业务的理解是不是停留在“跟产品对齐需求”的层面，还是能更深一层看到业务本身的目标
团队的基础能力模型，我会建议从“编写能力”转向“构建能力”。同样是写代码，过去强调对语言和框架的精通，现在更重要的是对整个系统生命周期、从需求到上线到监控到迭代的理解和执行，形成一套完整的构建闭环。
7. 回头看：Agent没有改变软件工程，它只是加速了软件工程的进化
写到这里，回到文章标题的那个问题：Agent时代，软件工程基础该学什么？
我的总结很简单：算法、数据结构、网络、系统原理、数据库原理这些“地基”不会过时，它们只是从“笔试考点”变成了“实战判断依据”。更强的变化在于，你需要在经典基础上叠一套新的能力层：任务拆解、Prompt工程、验证与纠错、系统设计、领域建模、跨学科思维。这些东西的组合，才是Agent时代一个真正合格的软件工程师应该具备的“基础”。
我自己也在持续学习这套体系，过程中犯了很多错。早期我犯的最大错误，是太信任Agent的输出，跳过了一些本该严谨的评审和测试环节，结果线上出了几次不大不小的事故。现在我把所有Agent产出都当成“临时工的作业”，每一份都严格审、严格测、严格记录。这样做下来，虽然过程变慢了，但整体效率反而提升了——因为返工才是最耗时的环节。
所以，与其焦虑Agent会替代软件工程师，不如重新审视一下自己对“基础”的定义有没有过时。与其花时间学各种花哨的Agent框架，不如先把那些最朴素的能力打磨好：说清楚问题、验证好结果、守住系统边界、真正理解业务。这些能力，在任何一个时代都不会贬值。
最后再分享一个小小的个人体会：我现在每天都会花一点时间，拿一个自己不太熟悉的技术领域，让Agent给我设计一个学习路径，然后自己动手实现一个相关的小项目。这个习惯算不上多聪明，但它让我既保持了跟前沿技术的接触，又持续锻炼了那些“人之所以为人”的核心能力——判断力、好奇心、责任心。这些东西，才是Agent再怎么演进，也无法从你身上夺走的。
