软件工程：变的是执行方式，不变的是工程问题

本文是「企业级应用中 Harness Engineering 的实践与思考」系列的第 11 篇。

Agentic 开发没有让软件工程问题消失

当 Agent 开始参与分析、实现、审查、测试和协调时，很容易产生一种感觉：软件开发是不是正在进入一个完全不同的时代？过去的软件工程方法是不是都要被重新发明一次？

这个问题需要拆开看。

软件工程里至少有四个层次：问题、思想、实践和工具。

问题，是软件开发长期面对的那些根本困难：需求不清、复杂度上升、多人协作、知识流失、实现偏差、质量风险、交付压力和责任归属。

思想，是软件工程为了应对这些问题沉淀出来的原则：先理解再实现，反馈链路要短，越早发现问题代价越低，协作需要共同事实源，质量不能靠自证，责任必须闭环。

实践，是这些思想在某个时代里的具体组织方式：需求评审、任务拆解、workflow、Spec、Code Review、QA、CI/CD、Human in the Loop、文档工程、Agent 分工。

工具，则是支撑这些实践落地的载体：Git、Jira、Trello、CI 系统、测试框架、静态检查工具、MCP、脚本、skill、agentic native 看板。

这四层不能混在一起看。工具会过时，实践形式会变化，但这不等于问题消失，也不等于思想失效。

Agentic 开发没有让软件工程的问题消失，也没有创造出完全陌生的问题。它真正改变的，是这些问题出现的形态，以及解决这些问题时所依赖的执行方式。

不变的是工程问题

需求仍然会不清楚。一个功能到底要解决什么问题，业务边界在哪里，异常情况怎么处理，和已有流程如何衔接，这些问题不会因为 Agent 能写代码就自动消失。相反，Agent 写得越快，错误理解越容易被快速放大。

复杂度仍然存在。企业级应用不是一个页面、一个接口或一个 demo，而是由业务规则、权限模型、数据边界、系统集成、历史决策和运维约束共同组成的长期系统。Agent 可以生成局部代码，但局部代码仍然要放回整个系统里判断。

协作仍然需要边界。谁负责分析，谁负责实现，谁负责 review，谁负责 test，谁可以修改代码，谁可以确认完成，谁只能提出问题而不能直接行动，这些边界在 Agent 进入之后不但没有变得不重要，反而更需要被明确。

实现仍然会偏离需求。代码看起来能跑，页面看起来像样，测试看起来通过，都不等于它真正实现了业务需要的东西。Agent 的自信输出，不能替代真实的理解和验证。

知识仍然会丢失。项目为什么这样设计，某个约束从哪里来，某次取舍为什么成立，某个坑为什么不能再踩一次，这些内容如果没有被记录、整理和触达，就会在 session 重启、人员流动、时间推移之后逐渐消失。

质量仍然需要验证。代码坏味道、架构偏移、测试缺失、边界遗漏、性能风险、安全风险、部署风险，都不会因为很多执行动作由 Agent 承担就自动得到解决。

责任仍然需要归属。一个系统能不能上线，一个 story 能不能完成，一个风险能不能接受，一个取舍是否值得，最终仍然需要有人承担判断和确认。

这些都是软件工程一直在面对的问题。Harness Engineering 之所以必要，不是因为它发现了过去不存在的问题，而是因为 Agent 进入开发过程之后，这些旧问题换了一种方式出现了。

不变的是工程思想

软件工程从来不是一套固定形式。

它不是一定要瀑布，也不是一定要敏捷；不是一定要 Jira，也不是一定要 Scrum；不是一定要某种文档模板，也不是一定要某种开发流程。

软件工程真正关心的，是如何在复杂系统中，稳定地把需求变成可运行、可维护、可验证的软件。

软件工程实践一旦被当成不能调整的教条，就会从解决问题的方法，退化成维持形式的仪式。真正重要的不是某个形式本身，而是这个形式背后的工程思想。

先理解再实现，是为了避免在错误方向上快速产出。需求越模糊，越不能直接进入代码。无论是过去的人类团队，还是现在的 Agent，都需要先把目标、边界、约束和验收标准说清楚。

反馈链路要短，是因为问题发现得越晚，修复代价越高。分析阶段发现理解偏差，可能只是改几句话；开发完成后发现方向错了，就可能牵连实现、测试、文档、状态和验收。

协作需要共同事实源，是因为一个人很难独自走完整个软件生命周期。过去团队需要围绕需求文档、设计文档、代码、测试和看板达成共识；现在人和 Agent 也需要围绕 Spec、报告、status、历史记录和文档工程达成共识。

质量不能靠自证，是因为实现者很容易被自己的假设说服。过去需要 Code Review、QA、自动化测试和质量门禁；现在 Dev Agent 也不能独自证明自己的代码正确，仍然需要 Code Reviewer Agent、QA Agent、工具和人的最终确认。

责任必须闭环，是因为执行和负责不是同一件事。Agent 可以执行大量工作，但它不能承担系统上线、风险接受、范围取舍和最终结果的责任。Human in the Loop 不是形式，而是责任机制。

这些思想没有因为 agentic 开发而过时。恰恰相反，Agent 让执行速度变快之后，这些思想变得更加重要。

变的是执行方式

真正发生变化的，是执行方式。

过去的软件工程实践，默认执行工作主要由人类团队完成。人读需求，人理解文档，人写代码，人做 review，人跑测试，人流转看板，人开会澄清，人负责交接。

现在，执行方式变成了人主导的人与 Agent 的混合协作。这里说的执行方式，不只是“谁写代码”，而是整个工程动作如何被完成：谁读取上下文，谁整理材料，谁修改代码，谁运行检查，谁生成报告，谁推动状态，谁准备 human gate。

这个变化很大，但它并不意味着人退出了软件工程过程。混合协作不是 Agent Team。Agent 可以承担大量分析、实现、审查、测试、整理和执行工作，但方向判断、范围取舍、风险评估、最终确认和责任归属仍然在人这里。

Agent 是新的执行参与者，不是新的责任主体。

正是因为执行方式变了，很多实践形式才必须改变。

过去文档可以散落在不同地方：代码在 Git，设计在 Figma，文档在 Google Drive，任务在 Jira，讨论在 Slack，决策在人脑子里。对人类团队来说，这虽然不理想，但仍然可以依靠经验、记忆、沟通和组织默契勉强运转。

但对 Agent 来说，这会变成触达灾难。Agent 不会天然知道某份文档存在，不会天然知道什么时候应该读它，也不会天然知道哪个系统里的哪段历史对当前任务重要。所以文档需要被工程化管理，需要有位置、格式、schema 和渐进式披露，让知识能够在合适的时候进入 Agent 的 Context。

过去的任务卡片主要给人看。人看到一个 story，可以根据自己的经验去找需求、问同事、查文档、拆任务、写代码。但 Agent 需要的不只是一张卡片，它需要 workflow 状态、Spec、Context、工具、权限、报告格式和 human gate。否则任务卡片只能记录状态，不能驱动执行。

过去的 code review 默认人写代码、人看代码。团队里的 TL 或 reviewer 不会逐行阅读每一次改动的全部细节，而是依靠经验、diff、测试、工具报告和风险判断。Agent 写代码之后，代码量和速度都被放大，完全依赖人逐行 review 更不现实，于是需要 Code Reviewer Agent、QA Agent、工具报告和 human gate 共同形成新的审查链路。

过去的需求分析依赖人之间的沟通。产品、BA、SA、TL、QA、PO 会从不同角度补足理解。但 Agent 参与之后，这些理解不能停留在一次对话里。它们需要被固化成 Spec，成为后续开发、review、test 和人类确认共同依赖的协作界面。

过去的工具主要由人使用。现在工具变成了 Agent 的手和眼睛。工具权限不再只是“能不能运行一个命令”，还关系到哪个 Agent 能在什么范围内访问什么系统、修改什么文件、触发什么动作。

这些变化不是对软件工程思想的背叛，而是对新执行方式的适配。问题没有变，假设变了；思想没有变，实践形式就必须跟着变。

Harness Engineering 继承了什么

从这个角度看，Harness Engineering 的每个部分都能在过去的软件工程实践中找到来源。

workflow 继承的是阶段划分、状态管理和反馈链路。一个 story 为什么不能从需求直接跳到完成，为什么要经历分析、实现、review、验证和 human gate，不是 AI 时代的新发明，而是软件工程长期以来对风险和反馈的管理。

文档工程继承的是知识管理。软件项目从来不只由代码组成，架构决策、业务规则、历史取舍、运行约束、团队规范、故障经验都是项目的一部分。文档工程只是进一步要求这些知识不能散落在人的脑子里、聊天记录里或工具孤岛里，而要能被 Agent 触达、被团队共享、被长期维护。

Spec 继承的是需求分析、设计澄清和验收标准。过去好的团队也不会在需求不清时直接动手写代码。Spec 在这里不是“写一个 md 就算有规范”，而是把分析阶段的理解固化下来，使实现、review、test 和 human gate 都有共同依据。

对抗式开发继承的是 Code Review、QA、自动化测试和质量门禁。它不是因为 Agent 之间要互相挑刺，而是因为软件工程早就知道：自己检查自己不够，写完代码不等于完成，质量需要来自不同视角的负反馈。

Agent 分工继承的是团队职责分工。Dev、QA、Code Reviewer、BA、TL、PM 这些名字并不神秘，它们来自软件开发中长期存在的职责。只是到了 Agent 这里，角色不能只是一句 prompt，而要变成职责边界、Context、工具、输入输出和交接物。

Human in the Loop 继承的是责任机制。过去团队里也需要 PO sign off、架构确认、质量确认、上线审批和风险接受。Agentic 开发没有取消这些机制，只是把人从大量重复执行中解放出来，让人更集中地承担判断、纠偏和最终确认。

Context Window 管理继承的是认知负载管理，也和 Lean 中限制 WIP 的思想有相通之处。过去人不可能同时记住项目所有文档、所有历史、所有代码和所有会议细节；现在 Agent 也一样。Context Window 不是仓库，而是注意力空间。管理 Context，本质上是在控制当前任务真正需要的信息量，让 Agent 的注意力保持在合适范围内。

工具管理继承的是自动化和权限控制。lint、test、build、static analysis、coverage、browser verification 都不是 AI 时代才出现的东西。变化在于，它们现在不仅服务人，也成为 Agent 执行和对抗的武器。

Agentic native 看板继承的是 Kanban、Sprint、Iteration 和项目可视化。任务拆分、泳道、状态流转、反馈链路仍然有效，只是未来的看板不能只给人看，还要能连接 Agent、Context、工具、权限和执行环境。

所以，Harness Engineering 并不是把过去的软件工程经验扔掉，而是把它们重新应用到人主导的人与 Agent 混合协作中。

Harness Engineering 发展了什么

继承不等于照搬。

如果只是把过去的流程、文档、看板和角色名字原封不动地套到 Agent 上，这些旧实践不仅不能解决问题，反而可能变成问题本身，让团队陷入新的困境。

Harness Engineering 的发展，在于它重新检查了旧实践背后的假设，并在假设不成立的地方改变形式。

过去可以假设人会主动问问题。现在不能假设 Agent 会在理解偏差时停下来。于是 workflow 中需要明确的 analyzing 阶段，需要 Spec review，需要 human gate。

过去可以假设团队成员拥有长期项目记忆。现在不能假设一个新的 session 能记得之前发生过什么。于是需要文档工程、status、报告、进度历史和知识沉淀。

过去可以假设任务卡片由人来解释。现在不能假设 Agent 能从一张普通卡片里还原出完整执行环境。于是 story 需要和 workflow、Spec、Context、工具、报告和状态流转结合起来。

过去可以假设 reviewer 会理解代码背后的团队规范。现在 Code Reviewer Agent 需要明确的项目规则、检查工具、review 标准和产出格式。

过去可以假设工具由人主动选择。现在 Agent 会在 Context 中看到工具、选择工具、执行工具。于是工具本身也要按职责配置，按权限约束，按范围管理。

过去可以假设沟通发生在人和人之间。现在沟通发生在人和 Agent、Agent 和 Agent 之间。如果这些沟通只停留在对话里，就会随着 session 结束而消失。于是 Spec、报告、status 和文档成为协作的载体。

过去可以假设软件工程实践主要服务一个人类团队。现在它需要服务人主导的人与 Agent 的混合协作。但这个变化的目的，仍然不是让 Agent 取代人，而是让 Agent 在工程约束下更好地为人工作。

这就是 Harness Engineering 的发展：它没有改变软件工程要解决的根本问题，却改变了这些问题在新执行方式下的组织方式。它是软件工程面对 agentic 开发时的一次演化，也是下一代软件工程实践的重要组成部分。

回到 Harness：软件工程仍然在发展

回到 Harness，Agentic 开发不会让软件工程消失。

相反，Agent 越强，越需要软件工程。

因为生成代码变得更容易之后，真正困难的事情会更加突出：需求是否被正确理解，边界是否被看见，风险是否被识别，质量是否被验证，知识是否被保存，责任是否被确认，系统是否能够长期演进。

这些问题不是模型参数变大就会自动消失的问题。它们属于软件工程。

Harness Engineering 不是软件工程的替代品，也不是对过去实践的否定。它是软件工程在 Agentic 开发时代继续发展的一种形态。

变的是执行方式。从只管理人类团队，到管理人主导的人与 Agent 的混合协作。

变的是实践形式。从人读文档，到 Agent 也能按需触达文档；从人解释任务卡，到 story 能驱动 Agent 执行；从人手动检查，到 Agent、工具和人共同形成反馈链路；从人使用工具，到人管理 Agent 使用工具。

不变的是工程问题。需求、复杂度、协作、反馈、质量、风险、交付、责任，这些仍然是软件开发最底层的问题。

不变的是工程思想。短反馈、可验证、可追踪、分工协作、共同事实源、责任闭环，仍然是软件工程最重要的底层追求。

不变的也是最终目的。软件最终是为人服务的，软件工程也是为开发软件的人服务的。Harness Engineering 也不例外。

它不是为了让 Agent 取代人，而是让 Agent 在软件工程的约束下为人服务。它把重复执行、信息整理、代码修改、验证检查和报告生成尽可能交给 Agent，把方向、判断、取舍、纠偏和责任留给人。

所以，Harness Engineering 不是在软件工程之外另起炉灶。

它只是提醒人们：当新的执行方式出现时，软件工程不能停在旧形式里；而当旧形式需要改变时，也不应该忘记那些已经被反复验证过的工程思想。

软件工程一直在发展。

Harness Engineering 是它在 Agentic 开发时代继续发展的一种形态。