让AI写一段代码、生成一个函数，已经不是软件研发中最值得讨论的问题。真正值得关注的是：如果把一项工程任务交给AI Agent，让它从需求分析开始，经过系统设计、代码实现，直至测试验证，它究竟能够走多远？
当Agent能够跨越多个工程环节，承担越来越多原本由软件工程师完成的工作，一个无法回避的问题随之出现：大部分软件工程师会被取代吗？
最近，我围绕开源3D打印固件开发，使用OpenCode和大模型开展了一次Agent工程实践。我们尝试让Agent沿着一条相对完整的工程链条开展工作：
需求工程 → 规约分解 → 需求评审与整改 → 系统设计 → 设计评审与整改 → 组件实现 → 单元测试与代码评审。
这里所说的“完整工程活动”，并不是说本次实验已经完成了一个产品的全生命周期交付，而是希望观察Agent能否跨越传统研发中的多个工程阶段，持续完成相互关联的任务。
近一年来，围绕Agent参与需求、设计、编码和测试的探索并不少见。这次实践的价值，也不在于宣称Agent首次做到了什么，而在于我们尝试将多轮评审与整改、较大规模的结构化工程产物，以及UTDD等工程方法结合起来，观察Agent在真实工程任务中的表现。
一、沿着工程链条做一次实践
这次实验选择3D打印固件项目，把原来的代码及其逆向分析等清空，重新输入一份21页的用户需求PDF文档。整个过程分为七个环节。
需求工程与规约分解。
Agent首先从原始文档中提取出186条源需求，经过分析、分类和归并，形成188条系统叶子需求，并建立12条顶层聚合视图。在此基础上，进一步分解出130条软件需求、49条硬件需求和53条软硬件接口契约（HSI），同时形成9条关键行为契约和62条验证场景。
这不是简单地将原始文档拆成更多条目。Agent需要理解系统功能和运行场景，识别软硬件职责边界，明确接口关系，并将描述性的用户要求转化为相对清晰、可追溯、可验证的工程规约。
多轮需求评审与整改。
我们没有让需求生成结果直接成为最终结果，而是引入独立评审和多轮整改。第一轮评审发现16项主要问题、13项次要问题和4条改进建议；整改后，第二轮又发现5项新问题。经过后续整改和复核，需求规约最终形成v1.0定稿。
（全量追溯矩阵，截取其中很小的一部分）
在追溯方面，128条M级需求全部建立了验证场景映射，覆盖率达到100%；环境、EMC和安规相关的9条专项需求也全部建立了对应场景。
系统设计与设计评审。
需求规约确定后，Agent进一步完成系统设计，形成230项结构化设计元素，包括21项架构设计、53项组件定义、23项数据结构设计、13项数据流设计、8项状态机设计、11项时序设计、19项算法设计、72项接口设计和10项配置设计。
随后，独立评审Agent对设计进行检查。第一轮发现10项问题，其中包括1项严重问题、4项主要问题和5项次要问题。经过整改和第二轮复核，10项问题全部关闭，没有发现新的问题。
其中一个问题涉及温度保护逻辑，判断条件的方向出现了反转。这类错误如果没有经过专业评审，很容易随着设计进入编码阶段，最终成为实际的软件缺陷。
组件实现、UTDD与代码评审。
最后，我们选择运动子系统中的7个组件开展实现，包括Motion、Planner、Bezier、Stepper、Endstops、Kinematics和FtMotion。
这次没有采用“让Agent直接生成代码，再看能不能运行”的方式，而是引入UTDD（单元测试驱动开发）：先理解设计契约，分析测试要求，设计测试用例并建立测试骨架，再由Agent完成实现；随后根据测试结果不断修复、重构，并开展覆盖率分析。
Motion组件最终生成约3,700行代码和测试，涉及33个文件，包括8个源文件、12个头文件和10个测试文件。
测试覆盖Motion组件等Cartesian、CoreXY、SCARA、Polar和Delta五种运动学配置。各配置分别执行79或80条测试用例，全部通过，没有失败用例。全量行覆盖率达到96.86%，分支覆盖率达到71.36%；Motion、Planner和Stepper三个核心组件的行覆盖率达到95.68%～99.01%，分支覆盖率达到70.00%～83.33%。
代码完成后，还进行了对照设计契约的代码评审。评审结论为有条件通过，记录了2项主要问题、3项次要问题和4项改进建议，没有严重问题，也没有尚未处理的阻塞项。
需要说明的是，本次完成的是基于设计契约的运动（Motion）组件自包含实现和Native环境下的单元测试，但没有进行ISR实时性和真实硬件并发行为验证。
因此，这次实践不是一个已经完成全部交付的产品项目，而是一次覆盖需求、设计和部分实现环节的Agent工程化探索。
二、这次实践，哪些地方值得关注？
我认为，这次实验有三个方面值得关注。
首先，是工程活动覆盖范围和产物规模的扩展。
这次实验形成了188条系统需求、130条软件需求、53条接口契约、62条验证场景，以及230项结构化设计元素。后续又完成组件代码的实现和单元测试。
如果完全依靠人工维护这么多工程元素及其关联关系，需要投入大量时间。Agent可以帮助完成需求提取、分解、编号、关联和更新，人类则可以把更多精力放在关键约束、技术方案和质量判断上。
但数量多不等于质量高，追溯关系完整也不意味着语义正确。工程产物越多，越需要明确的结构、关系和验证机制。否则，Agent只会更快地生成一批彼此不一致的文档和代码。
其次，多轮评审和整改比一次生成更重要。
这次需求和设计阶段都经历了独立评审、问题记录、逐项整改和再次评审。尤其是温度保护逻辑中的错误，说明Agent生成的内容即使结构完整、表达专业，也可能包含实质性的工程问题。
这与传统软件质量管理的基本规律是一致的：质量不是靠最后一次检查“检”出来的，而是要通过过程中的评审、验证和纠错逐步建立起来。
Agent可以提高工作效率，但不能因为它生成得快，就降低工程评审的要求。
第三，UTDD让Agent的实现有了更明确的约束。
让Agent写代码并不难，难的是让它按照设计要求写出行为正确、可验证的代码。
这次采用UTDD，不是把测试当作代码生成之后的补充，而是让测试用例从一开始就参与实现过程。设计契约提供实现依据，测试用例提供行为约束，测试结果和覆盖率则提供验证证据。
这使Agent不只是根据自然语言“猜”应该怎么实现，而是在明确的工程约束下完成代码，并通过测试反馈持续修正。
我认为，随着Agent执行速度越来越快，测试、评审和质量门禁的重要性只会进一步提升。否则，代码生成效率的提升，很可能转化为更大的缺陷排查和返工成本。
三、大部分软件工程师会被取代吗？
我的判断是：软件工程师这个职业不会因为Agent的出现而整体消失，但相当一部分传统软件开发工作将被自动化，软件工程师的岗位结构、工作方式和能力要求都会发生显著变化。
首先，要区分“工作任务被替代”和“职业岗位被替代”。
一个软件工程师每天要完成很多具体任务，其中一些任务可以被Agent直接接手。例如，常规代码编写、简单功能修改、接口文档整理、测试用例初步生成、重复性缺陷修复和基础代码检查等。这些工作的边界相对清晰，输入和输出比较明确，也容易通过测试或规则进行验证。
随着Agent能力提高，这类工作的人工投入必然会减少。过去需要多人完成的工作，未来可能由少数工程师组织Agent完成。对于企业而言，研发团队的人员配置和岗位分工也会因此调整。
因此，不能简单地说“AI只是工具，不会替代人”。事实上，一些以重复性编码和标准化任务为主要内容的岗位，确实会面临很大压力。
但软件工程并不只是完成一组明确的编码任务。
在真实项目中，需求往往不完整，业务目标可能相互冲突，系统约束也可能随环境和产品变化而变化。架构设计需要在性能、成本、可靠性、安全性和可维护性之间做权衡；复杂故障需要结合业务场景、运行环境和历史经验进行分析；高可靠性软件还涉及安全责任、合规要求和最终交付决策。
这些工作并非简单地生成一个结果就能完成。它们需要理解问题、识别风险、权衡方案，并对决策后果负责。
Agent可以提供分析和建议，也可以执行其中相当一部分具体工作，但最终的工程判断和责任不能仅靠代码生成或测试通过来替代。
尤其在汽车、航空、能源、工业控制等领域，软件质量直接关系到产品安全和运行可靠性。工程师需要判断规约是否充分、设计是否合理、验证证据是否足够，以及系统是否具备交付条件。这些责任不会因为使用了Agent就自动消失。
所以，真正面临替代压力的，不是所有软件工程师，而是那些工作内容高度重复、专业判断较少、主要依靠手工完成标准化任务的岗位和工作方式。
而能够理解复杂业务、驾驭系统架构、管理工程风险、组织Agent协作并对质量结果负责的工程师，其价值反而可能更加突出。
四、软件工程师应该如何改变自己？
如果Agent能够承担越来越多的工程任务，软件工程师应该怎么办？
我认为，最危险的不是不会使用某个AI工具，而是仍然把自己的价值局限在“我能写多少代码”、“我能完成多少具体任务”上。
未来，工程师需要从亲自执行具体工作，转向设计、组织和驾驭工程活动。至少有五方面能力值得重视。
系统思维。不只是理解一个函数或一个模块，而是能够从业务目标出发，理解系统边界、架构关系、功能依赖和运行环境，识别局部修改对整个系统的影响。
需求与规约能力。能够把模糊的业务目标转化为清晰、完整、可验证的工程要求，明确系统要做什么、受到哪些约束、哪些行为不能发生，以及最终如何验收。这将成为组织Agent工作的重要基础。
工程组织与Agent协作能力。能够合理分解工程任务，为Agent提供上下文、知识、工具和权限，组织多个Agent协同工作，并建立必要的执行约束和反馈机制。
质量保证与验证能力。不轻信Agent给出的结果，而是能够设计评审机制、测试策略和质量门禁，判断工程产物是否正确、完整、一致，验证证据是否充分。
专业判断与责任意识。能够在复杂、不确定的场景下作出技术决策，识别关键风险，对系统安全、质量和交付结果承担责任。
这里还有一个值得关注的问题：初级软件工程师怎么办？
过去，很多工程师是从简单编码、修改缺陷、编写测试等工作逐步成长起来的。这些工作恰恰是最容易被Agent自动化的部分。如果企业只追求短期效率，大量减少初级岗位，可能会影响未来资深工程师的培养。
因此，软件企业不仅要思考如何用Agent减少重复劳动，也要重新设计工程师的培养路径：让新人在Agent辅助下参与真实工程活动，学习需求分析、设计、评审、测试和质量判断，而不是仅仅把Agent生成的代码当作自己的工作成果。
未来的软件工程师，不应该只是比Agent写代码更快，而应该比Agent更懂系统、更懂工程、更懂风险，也更善于组织和判断。
结语：被取代的，可能是旧的工作方式
回到文章标题：AI Agent可以承担完整的工程活动，大部分软件工程师会被取代吗？
我的判断是，大部分软件工程师不会作为一个职业群体整体消失，但软件研发中的大量具体工作将被重新分配，部分岗位会减少，传统的软件工程能力结构也将受到冲击。
软件工程师面临的不是一个简单的“人和AI谁更强”的问题，而是必须重新思考：哪些工作应该交给Agent，哪些决策必须由人来做，怎样才能让Agent可靠地参与复杂工程活动？
从软件工程的发展来看，我们正在经历新的范式变化。
软件工程1.0以传统软件工程为代表，强调规范化、结构化和过程纪律；软件工程2.0以敏捷、CI/CD和DevOps为代表，强调快速迭代和持续交付；软件工程3.0则正在走向AI和Agent驱动的智能化软件工程。
在这一新范式下，软件工程的核心逻辑可以概括为：
规约为核心，Agent为执行主体，人做决策和判断，验证证据为质量依据。
这次Marlin固件实践还只是一个探索性案例，距离真正实现规模化、自主化、可信赖的端到端工程交付，还有不少问题需要解决。但它已经说明，Agent不再只是辅助工程师写代码，而是开始进入软件工程的核心活动。
我想，未来真正拉开软件工程师差距的，可能不再是一个人一天能写多少行代码，而是他能否理解复杂系统、定义正确的问题、组织Agent完成工程任务，并用可靠的证据证明结果值得信任。
被取代的，未必是软件工程师这个职业；更可能首先被取代的，是那些可以被自动化的工作方式，以及仅仅依赖这些工作方式建立起来的岗位价值。