---
id: engineering-trust
title: AI 会写代码之后，软件工程师的价值正在转移到哪里？
summary: 当 AI 能够自主完成越来越多的开发工作，工程师的价值正在从亲自实现功能，转向用技术建立信任。
tags:
  - AI
  - 软件工程
publishedAt: 2026-11-04T06:52:27.219Z
updatedAt: 2026-11-04T06:52:27.219Z
writtenAt: 2026-10-30
url: https://wuyanji.datiaomao.com/articles/engineering-trust/
markdownUrl: https://wuyanji.datiaomao.com/articles/engineering-trust/index.md
---

如果有一天，AI 不仅能写代码，还能自己分析需求、设计方案、运行测试，甚至完成部署，我们还需要软件工程师吗？

Coding Agent 的能力不断提高，让这个问题越来越现实。过去需要工程师花几天完成的工作，现在可能只需要向 AI 描述目标，一两个小时后它就能给出结果。

这让不少软件工程师都开始焦虑：如果 AI 写代码都能从头写到尾了，甚至写得比我们还要好，那我们多年积累的知识和技能，还有什么价值？

Katelyn Lesse 在 2026 年 10 月 25 日发表的[《The new set of problems for engineers to solve》](https://www.katelynlesse.com/blog/new-problems-for-engineers-to-solve)，他提供了一个值得思考的视角：**AI 没有让软件工程师的价值消失，但是这份价值的重心正在改变。**

过去，我们的主要工作是亲自设计并实现软件功能；未来，我们可能需要花更多精力，设计能够让 AI 自主、安全、可靠运行的系统。

这不是说写代码不重要，只是单独代码的能力，已经不足以代表软件工程师的全部价值。

![开篇图解：从亲自实现功能，到用技术建立值得信任的环境。](https://wuyanji.datiaomao.com/media/engineering-trust/f1ed977d19ec8b3279b451ab.png)

## AI 正在替代部分编码工作，但也在创造新的工程问题，甚至信任问题

刚开始，AI 只是辅助工具：工程师提出问题，AI 给出建议，或者帮忙生成一小段代码。整个开发过程还是由人来主导。

后来，Coding Agent 开始能够独立修改文件、调用工具、执行测试，甚至根据测试结果修复自己的错误。

现在，Agent 正在向长期自主运行和多 Agent 协作发展。一个 Agent 可以负责任务规划，另一个负责开发，第三个负责测试，还有 Agent 专门承担审查和验证工作。

如果我们继续沿着这个方向推演，未来可能出现数百甚至数千个 Agent 长期协作，共同完成复杂的软件开发、科学研究或硬件设计任务。

**单个 Agent 的工作能力越强，我们就越需要解决多个 Agent 组成的整个系统如何运行的问题。**

比如，怎么为几千个 Agent 分配计算资源？怎么决定它们可以访问哪些数据？怎么防止一个 Agent 的错误影响其他 Agent？如果整个系统偏离了目标，又怎么及时发现并停止？

这些问题不会因为 AI 更擅长写代码就自动消失。AI 能够执行的任务越复杂，它们就变得越突出。

Katelyn Lesse 将这些新挑战归纳为四个方向。分别是：基础设施、身份与权限、安全与隔离、监控与终止。

这些挑战都指向同一个词：**信任**。是工程师能不能建立一个值得信任的 Agent 工程环境。

我觉得，**信任**这个词，解释了软件工程师价值正在发生的变化。

## 1、基础设施：从保障软件运行，到保障大量 Agent 持续工作

我们熟悉的软件基础设施，大多围绕应用和服务来设计。例如 Kubernetes，可以帮助我们部署应用、管理容器、实现弹性扩缩容。

Agent 的运行方式有些不同。传统服务可能长期运行，持续处理请求；Agent 往往需要保存自己的执行状态，又可能长时间等待模型推理、工具调用、其他 Agent 的反馈，或者用户的审批。

如果让每个 Agent 始终占用一个完整的运行环境，系统可能浪费大量计算资源。但如果直接释放资源，又必须解决状态保存、任务恢复和执行隔离的问题。

系统里只有几个 Agent 时，这些问题也许不明显。但当成百上千个 Agent 同时运行，或者突然产生大量并行任务时，资源调度、状态管理、快速启动和故障恢复就会变得十分重要。

Kubernetes 仍然有价值，现有基础设施也需要适应这些新的工作负载。

**工程师需要考虑的，既有如何让一个程序运行起来，也有如何让大量自主行动的 Agent 高效、稳定地持续工作。**

AI 可以帮助编写这些基础设施的代码，但如何设计运行机制、处理资源约束和保证系统稳定，仍然是需要人来解决的工程问题。

![基础设施：保存状态、调度资源，让任务能够继续。](https://wuyanji.datiaomao.com/media/engineering-trust/03d1b6ea3d33b55260d989e6.png)

## 2、身份与权限：从用户能做什么，到 Agent 被允许替用户做什么

原文讨论的第二个问题是身份与权限，我认为它比基础设施更值得关注。

过去的软件系统，权限关系通常比较清晰：用户登录系统，服务器验证身份，再根据权限决定他可以访问什么、修改什么。Agent 的加入让这层关系变得复杂。

假设你授权一个 Agent 帮你开发项目，允许它访问代码仓库。它为了完成任务，又创建了几个子 Agent，分别负责修改代码、执行测试和管理部署。

主 Agent 可以把你的全部权限交给子 Agent 吗？如果其中一个子 Agent 想删除仓库、修改生产环境，或者访问与任务无关的数据，它是否应该被允许？

如果整个任务持续两周，你在第一天给予的授权，是否意味着 Agent 在两周内可以自行决定所有操作？

还有一个更基本的问题：当系统发现某项操作使用了你的账号时，如何判断这是你亲自执行的，还是 Agent 代表你执行的？

除了身份认证，这里还涉及授权、委托、信任和责任归属。

软件工程已经积累了 OAuth、工作负载身份、短期凭据等技术，但面对长期自主运行、不断分派任务的 Agent，授权机制还需要完善。

**过去，我们主要设计人与软件之间的权限关系；未来，还必须设计人与 Agent、Agent 与 Agent 之间的权限关系。**

AI 知道怎样调用 API 还不够，系统还得判断它有没有资格执行这次调用。解决这些问题，我们才能放心地把一部分工作委托给 AI。

![身份与权限：明确代理身份，限制委托范围。](https://wuyanji.datiaomao.com/media/engineering-trust/61f89a12d49aa33cc5bed49e.png)

## 3、安全与隔离：从保护单个软件，到限制 Agent 错误的传播范围

传统软件也存在漏洞和攻击，而 Agent 带来了新的安全风险：它不仅会读取信息，还可能根据读到的信息决定下一步行动。

例如，一个 Agent 在阅读网页或代码仓库时，遇到了一段恶意构造的内容。这段内容可能试图诱导它改变原本的任务目标，执行不该执行的操作。

如果这个 Agent 还会和其他 Agent 协作，它可能把受到污染的信息传递下去。错误信息还可能被写入共享记忆，影响之后运行的 Agent。一次原本局限在单个任务中的攻击，就可能扩散到整个多 Agent 系统。

这就是原文特别强调的 Blast Radius，也就是影响范围。

我们不可能保证所有 Agent 永远不出错，也不能保证它们读到的内容永远安全，但可以通过工程设计，尽可能限制错误的影响范围。

例如，让 Agent 在隔离环境中运行，限制它能够访问的文件和网络资源，防止它随意使用高权限凭据，并避免不同任务之间的不可信数据相互污染。

**过去，我们努力让软件不要出错；面对自主 Agent，我们还必须认真设计它出错之后会发生什么。**

错误是否能够被限制在局部？重要数据会不会受到影响？系统能否恢复？

这些问题需要可靠的工程机制来解决。模型能力再强，也不能代替外部安全边界的设计。

![安全与隔离：限制错误传播，控制影响范围。](https://wuyanji.datiaomao.com/media/engineering-trust/f1cc2857aaa38acd52f4af88.png)

## 4、监控与终止：从观察程序有没有故障，到判断 Agent 是否正在做正确的事

原文提出的第四个问题是监控与终止，可能也是最有挑战性的一个。

过去，我们监控软件系统，主要关注错误日志、异常、性能指标以及服务是否正常。

对于长期自主运行的 Agent，仅仅知道系统没有报错已经不够了。它完全可能在技术上运行正常，却正在执行错误的目标。

例如，一个 Agent 在执行任务时，反复尝试访问某个没有被授权的域名。它可能是为了完成任务，一直在寻找可用方案；也可能受到恶意指令影响，正在尝试突破权限限制。

这两种行为在日志中可能非常相似。怎样判断它是在积极解决问题，还是已经偏离了原本的任务？

这要求系统具备更完善的可观测性和控制能力。作者特别提到了跨 Agent 的调用追踪，以及不允许 Agent 自行篡改的日志记录。

当系统发现异常时，还需要具备真正有效的终止机制，不仅停止当前任务，还要能够终止相关 Agent、撤销凭据，防止任务继续扩散。

但**停止一个 Agent，并不意味着它之前执行的操作已经被撤销。**

例如，它可能已经修改了数据库、提交了代码，或者向外部系统发出了请求。系统怎样确认这些操作的影响？是否需要回滚或补偿？谁来判断任务应该继续还是终止？

这些问题其实与传统软件中的事务、一致性、审计和故障恢复密切相关，只是在 Agent 时代变得更加复杂。

未来的监控系统可能还需要帮助我们判断：**系统是否仍在朝着正确的目标前进？** 这已经超出了传统性能监控对“程序有没有正常运行”的关注。

![监控与终止：发现偏离、及时介入，并检查已发生的影响。](https://wuyanji.datiaomao.com/media/engineering-trust/6ed710244a93de5b0209b5d5.png)

## 四个问题背后，其实是一次价值迁移

基础设施、权限、安全、监控分属不同的技术领域，但在我看来，它们都在回答一个关于**信任**的问题。当软件有了更强的自主决策和行动能力，我们怎么能放心地把事情交给它？

过去，我们更多把软件看作按既定逻辑执行任务的工具：工程师设计规则、编写代码，软件按规则运行。现在，AI 可以根据目标，自行选择部分执行路径，不必每一步都由人预先确定。我们需要知道，它会在什么范围内行动，结果能否验证，出错以后又该怎么办。

这份信任需要技术来支撑。基础设施让 Agent 能持续工作，并在中断后恢复任务；身份与权限明确它代表谁、被允许做什么；安全与隔离限制错误的影响；监控与终止机制让我们能发现它是否偏离目标，并及时介入。

**软件工程师需要用技术建立一个值得信任的环境。** 我们不要求 Agent 永远不出错，但要能约束它的行动、验证它的结果，出了问题也有办法处理。有了这些保障，才有理由放心地把工作交给它。

**第一，从直接生产代码，转向设计和管理代码生产过程。**

当 Agent 可以承担越来越多的实现工作时，工程师需要更准确地定义目标、拆解任务、确定验收标准，并建立持续验证和反馈机制。这些检查让我们有依据判断，交付的代码是否可信。

**第二，从构建确定性的程序，转向治理具有自主行为的系统。**

工程师需要解决身份、权限、执行隔离和协作问题，明确我们在什么范围内信任 Agent。可以把某项任务交给它，同时限制它访问无关数据，以及向其他 Agent 转交权限。

**第三，从保证单个功能正确，转向保证整个系统持续可靠。**

这包括状态管理、异常检测、故障恢复、可观测性，以及必要时终止整个系统的能力。系统要持续运行，任务也会不断变化。一次成功的交付还不够，我们还得能持续判断它是否值得信任。

做好架构、权限、测试、日志和恢复机制，需要技术积累。我们敢于把工作交给 AI，靠的就是这些具体的保障。

## 但这不意味着所有软件工程师都会自动变得更重要

软件工程仍然重要，但是现在的软件工程岗位已经受到了冲击。

如果一项工作的核心价值只是根据明确需求，重复编写常规业务代码，那么随着 AI 能力提高，这部分工作的稀缺性确实可能下降。这也是很多工程师焦虑的真实原因。

如果一个工程师能深入理解复杂系统，设计架构、处理安全与可靠性问题，把不确定的任务变成可验证、可管理的执行流程，他的经验仍然能发挥重要作用。靠这些能力，他能判断一项工作是否可以交给 AI，并说明判断的依据。随着 Agent 自治程度提高，这种建立信任的能力可能变得更加关键。

不过，这些能力也不是人类永远独占的。AI 同样会逐步参与架构设计、验证和运维工作。

因此，工程师不能指望只靠过去积累的技术知识，就获得长期的职业保障。我们需要理解新的工程问题，借助不断进步的 AI，做好支撑信任的技术机制，并验证它们是否有效，能否让我们放心地委托这一次任务。

## 结语：AI 越强大，我们越需要回答一个问题

过去很多年，我们一直在追求更高的软件性能、更丰富的功能和更低的开发成本。

现在，AI 正在让软件获得一种过去很少具备的能力：自主完成复杂任务。但它能自主行动，我们就能放心地把工作交给它吗？

Agent 会写代码，不意味着我们就应该允许它直接部署生产系统；会调用工具，也不意味着它应该拥有所有工具的权限。一群 Agent 能共同完成任务，也未必能安全、可靠地协作。

我觉得，软件工程师不要再思考“怎样才能比 AI 写代码更快”，这已经没有意义。更值得思考的是：**当 AI 能做的事情越来越多，我们需要建立怎样的环境，才能放心地把工作交给它？**

读完 Katelyn Lesse 对基础设施与可信性问题的讨论，我的理解是：软件工程师的价值正在从亲自实现功能，进一步转向用技术建立信任，让能力越来越强的 AI 持续交付可靠的结果。

未来优秀的软件工程师，未必是亲手写出最多代码的人，也可能是能把这样的系统设计出来的人：大量 Agent 能持续工作，有明确的目标和合理的权限，工作结果也能得到可靠验证。

因为这样一套系统，人们对它产生信任，然后才使用它。

![总结：用技术建立值得信任的 Agent 环境。](https://wuyanji.datiaomao.com/media/engineering-trust/c41b84486d041f07210f0fcb.png)
