Agent时代软件工程基础该学什么：从编码到系统构建

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提供任务的背景信息比如“数据库连接池用的是HikariCPMapper框架是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再怎么演进也无法从你身上夺走的。