文章核心观点 - 文章通过历史类比，提出“控制论”是理解AI时代软件工程演进的核心理念，工程师的角色正从直接编写代码转向设计能让AI智能体（agent）自动运转的系统[2][6][13] - 大型语言模型（LLM）首次使得在“架构决策”层面构建自动化反馈回路成为可能，这要求工程师将隐性的架构知识、质量标准和团队规范显式化、机器可读化，否则AI智能体将无法有效工作[16][22] - 采用AI智能体进行工程开发（Agentic engineering）并未改变优秀软件工程实践的本质，但极大地提高了不遵循这些实践（如缺乏文档、测试、架构约束）的即时和持续代价，使得建立高效的验证与评估体系变得至关重要[23][24] 软件工程模式的演进与控制论 - 历史上出现过三次工程师角色从“直接操作”转向“设计自动控制系统”的相似模式：18世纪80年代瓦特改进离心调速器用于蒸汽机自动控制[9]、Kubernetes通过控制器实现容器化应用的声明式管理与自动修复[10]、以及当前OpenAI提出的由AI智能体自动编码的“harness engineering”[6][13] - 这三次模式转变的共同驱动因素是：出现了足够强大的“传感器”和“执行器”，能够在特定层面（如机械转速、容器状态、代码质量）将反馈回路闭合起来[15] - 控制论是这一模式的理论基础，其核心是设计系统以实现自动调节与目标对齐，工程师的角色从“拧阀门”转变为“掌舵”[13] LLM如何改变软件工程反馈回路 - 在LLM出现之前，代码库的自动化反馈回路（如编译器、测试、Linter）仅存在于底层，处理可机械检验的问题，而更高层次的架构决策、技术方案选择等缺乏自动化机制，完全依赖人工[16] - LLM同时改变了反馈回路的两端：既能像人一样感知和判断代码质量，也能执行复杂的代码改动，这使得在关键的“架构决策”层面首次有可能构建闭合的自动化反馈回路[16] - 然而，闭合回路仅是必要条件，要让LLM智能体有效工作，必须为其提供经过精心校准的“传感器”和“执行器”，即明确、机器可读的系统规则与质量标准[17][18] 实施AI智能体工程的关键挑战与解决方案 - 主要挑战在于将工程师脑中关于系统“何为正确”的隐性知识（如架构偏好、设计模式、质量审美）转化为机器可读的形式，否则智能体会持续重复相同的错误[22] - 解决方案包括：编写描述真实架构的文档、配置带有修复指引的自定义Linter、将团队规范编码成“黄金原则”等 OpenAI通过将自身标准编码进“harness”，从根本上解决了每周花费20%时间清理“AI slop”（低质量AI生成代码）的问题[22] - 设计精良的测试基础设施和反馈机制是智能体协作成功的关键，如Carlini让16个智能体协作构建C编译器的案例所示，其大部分精力花在了设计智能体周围的环境上[18] AI智能体时代对软件工程实践的倒逼 - 文档、自动化测试、编码化的架构决策和快速反馈回路等经典优秀工程实践，在AI智能体时代从“推荐”变为“必需” 跳过这些实践的代价被急剧放大和加速[23] - 具体表现包括：缺乏文档会导致智能体在所有PR（拉取请求）上持续违反规范；缺乏测试会使反馈回路无法闭合；缺乏架构约束会导致“代码漂移”的速度远超人工修复速度[23] - 核心方向从“比机器更快地生成代码”转向“更高效地评估机器产出” 研究证明，训练LLM验证答案正确性比直接生成正确答案更容易，这为工程实践指明了重点：定义“正确”、识别偏差、判断方向[24][25]