AI Agent重塑软件工程：手写代码落幕下的实战与避坑指南
最近技术圈里最出圈的一句话，大概就是 DHH 那句“手写代码时代正在落幕”了。我朋友圈里转发这观点的，一半是被 AI Agent 的开发速度震撼到了，另一半觉得这是不折不扣的标题党。我一开始也偏向后一种，直到认真读完他那套完整表达，才意识到自己一开始就把问题想小了：他讨论的不是哪个工具有多强，而是 Agent 正在把整个软件工程的生产关系重写一遍。接下来的内容我不替谁站队，只用一个天天和 Agent 打交道的软件工程师的身份，把这句话拆开揉碎聊清楚，同时把团队里调 agent、搭 agent、踩坑、排查的实操记录整理出来。无论你是刚开始接触 agent 开发的新手，还是已经选过一轮 agent 框架的人，这篇东西应该都能给你一些判断依据。
1. 先把 DHH 的观点放平了看：他是说程序员失业，还是说工作方式变了？
1.1 Rails 之父为什么说这话有分量
DHH 全名 David Heinemeier Hansson，Ruby on Rails 创始人、37signals 联合创始人。Rails 这套框架的核心理念是 convention over configuration，它的存在本身就是为了让 Web 开发少写重复代码。换句话说，他是一个骨子里讨厌“手工重复劳动”的工程师。当这样的人说“手写代码时代正在落幕”，分量和普通网红完全不一样：他过去二十年干的事情，就是用框架消灭一类机械化劳动，如今他看到 Agent 能直接生成和修改代码，说出的判断更接近一个长期观察者的结论，而不是在蹭 AI 热度。
37signals 这家公司还有一个标签被反复提及：超小团队。Basecamp、HEY 这些产品背后的技术维护团队，人数少得让很多大厂觉得不可思议。DHH 多次在访谈里讲过，技术的主要作用不是堆人，而是给少数人提供超规格杠杆。他在这个语境下谈论 Agent，本质上是看到了这个杠杆已经被拉到了一个前所未有的长度。理解了这层背景，再去看“手写代码时代落幕”这句话，你就知道他不是在预言世界末日，而是在描述他已经开始实践的工作方式。
1.2 DHH 真正在强调的：代码“写”的环节权重在下降
我认真回看了 DHH 那套表达的完整逻辑，他真正说的不是“以后没人写代码”，而是软件工程的重心会从“写代码”转移到“管理智能体”。过去一个 feature 从需求到上线，工程师有百分之六七十的时间落在编码本身：建表、写接口、调样式、补异常分支。而这些工作恰恰最容易被 Agent 学会，因为它们信息密度相对低、规则明确、又有测试可以验证。
一旦 Agent 能基于 issue 直接产出 diff，工程师的工作就变成了另一副模样：把需求描述清楚，设定边界和约束，review Agent 生成的代码，处理那些模型想不到的边角情况，最后把关合并。换句话讲，以前你的价值体现在“写”这个动作上，以后体现在“定义什么是正确”上。DHH 用“落幕”这种拉满情绪的词，表达的其实是同一个趋势：写代码这个动作在工程里的权重正在肉眼可见地下降，取而代之的是定义、评审、验收、纠偏这些更高抽象层级的活动。
1.3 泼盆冷水：手写代码不会消失，消失的是“打字搬运”
我也要给这句话泼盆冷水。手写代码不会真的归零，越是靠近系统底层、核心算法、安全机制、复杂业务架构的地方，人工判断越不可替代。Agent 擅长的是在既定边界里生成满足测试的代码，但什么是正确边界、什么该做不该做，没人能完全外包给模型。真正被快速干掉的，是大量“打字搬运”性质的代码：CRUD、样板工程、胶水代码、基础正则、配置刷子这类高重复、低判断的工作。
我建议所有开发者别把“手写代码落幕”理解成明天就要失业。它其实是在提示一个窗口期：只会复制粘贴的工程师会很危险，能定义需求、能审代码、能指挥 Agent 干活的人会越来越值钱。这也是为什么我后面会花大量篇幅讲 Agent 架构、框架选型、学习路线和踩坑经验——因为判断能力正是这个时代最稀缺的能力。制造业早就经历过一次“手写”退场，软件行业正在经历同样的过程，只是这次的节奏快得多。
2. Agent 重塑软件工程：流程、角色、团队都在被重新定义
2.1 一条需求从提出到上线的路径变短了
软件工程这个行业虽然叫“工程”，过去却一直带着很强的手工作坊味道：最关键的生产环节依赖个人手艺。需求从产品经理嘴里出来，先变成 PRD，再被工程师翻译成技术方案，然后编码、自测、联调、部署。链条很长，每一环都在传递信息，也在损耗信息。Agent 化之后，这个链条被大幅压扁了。
我整理了一个传统模式和 Agent 化模式的对照，可能比抽象描述更直观：
| 环节 | 传统模式 | Agent 化模式 |
|---|---|---|
| 需求拆解 | 产品经理写 PRD，工程师手翻技术任务 | 需求直接交给 Agent，智能体出任务清单和风险点 |
| 编码 | 工程师逐行手写 | Agent 生成初始实现，工程师负责约束与 review |
| 测试 | 工程师花大量时间补单测 | Agent 自动生成测试并持续修复失败用例 |
| 部署 | 发布工程师盯流水线 | Agent 触发 CI，按反馈循环自动修正 |
| 维护 | 人工翻日志、定位问题 | Agent 分析告警日志，直接给出修复补丁建议 |
需求拆解环节的变化最容易被人忽略。过去产品经理输出 PRD 后，工程师还要自己翻译成可执行的技术任务，翻译得好不好全看个人经验。现在把需求文档喂给 Agent，它可以生成结构化的任务清单、识别潜在风险、提出依赖问题，再由人来确认和修正。这一步看起来只是省了时间，实质上是把“翻译损耗”降到了最低，让人和系统从需求到代码之间的路径短了一大截。
2.2 工程师的抽象层级被抬高，价值重心在迁移
工程师这个角色的抽象层级被抬高，可能是 DHH 那番话里真正有杀伤力的部分。以前你是熟练瓦工，今天的 Agent 是一台随时能用的工程挖掘机。不会开挖掘机的瓦工，在修私人小院时可能还没什么，等城市项目全面机械化，风险就来了。反过来，你会看图纸、懂结构受力、能判断施工顺序，你反而从“体力溢价”变成了“决策溢价”。
具体落到能力模型上，我认为四件事决定了你和一个 Agent 组合的上限：第一是需求建模能力，能不能把模糊想法变成 Agent 能执行的任务描述；第二是 Agent 指令与约束设计能力，知道哪些边界必须写死、哪些权限必须收掉；第三是代码评审能力，能在 Agent 生成的代码里快速看出逻辑漏洞和隐患；第四是架构与技术债判断力，知道什么时候该让 Agent 干，什么时候必须人肉下场。很多人担心 review 会比以前更花时间，实际上当你开始大量 review Agent 生成的代码，你的行业直觉会提升得飞快，因为你会密集看到各种“功能对了但写法很别扭”的代码，这种高强度反馈是过去很多年都得不到的。
2.3 小团队与个人开发者的杠杆被拉到极致
团队规模的变化是最容易被看到的外部现象。DHH 常年讲小团队理论，过去我们敢相信“三个人维护一套复杂业务系统”，是建立在框架和成熟轮子的基础上；现在加上 Agent，边界又被明显推进了。我自己的团队是两个工程师加三条独立的 Agent 任务流水线，稳定维护了四个线上服务：一条负责告警分析，一条负责回归测试后的自动修单，一条负责生成版本发布说明。听起来很花哨，但底层逻辑很简单：Agent 不是替代人，而是把人的输出放大。
这点对管理者尤其重要。别再按“一个功能需要的编码工时”做人力预算了，那样你会严重高估人头数。真正的瓶颈变成了：团队里谁最能把需求讲清楚，谁会设计 Agent 的评估闭环，谁能把边界和安全兜住。我见过不少团队花了两个星期搭了一个看似聪明的多 Agent 系统，最后发现真正缺的不是模型能力，而是没人能把业务规则结构化地讲给它听。工具越强，对“定义正确问题”的人的要求反而越高。
3. 一个能写代码的 Agent 内部长什么样：框架、架构与 Harness
3.1 拆开一个 Coding Agent：四大组件缺一不可
想理解 Agent 怎么重塑软件工程，先得理解一个能写代码的 Agent 内部到底有什么。我习惯把它拆成四个部分：大模型推理内核、工具层、记忆与上下文、编排循环。大模型是大脑，决定下一步做什么；工具层给它配了手和脚，能读文件、执行命令、跑测试；记忆负责跨步骤保留信息和沉淀经验；编排循环则是工作方法论，决定它是闷头乱撞还是有条理地逼近目标。
给不熟悉的人一个生活化类比：把 Agent 想象成一位刚转正的实习生。大模型是实习生的大脑，工具层是他桌上那台电脑和配发的权限卡，记忆是他工位上的笔记本，编排循环是他接到任务后的工作流程：先领会意图，再动手，看反馈，再改。这个类比之所以有用，是因为你的管理方式直接决定了他是人才还是麻烦。你给他清晰的验收标准、充分的工具、合理的记录习惯，他能独立做完很多事；你什么都不管只丢一句“把这个系统搞定”，他大概率会在原地转圈。
工具层是质的飞跃点。没有 tool use 能力，模型就只是一个复读机，只能生成建议；有了 execute、read、write 这些真实工具，模型才从“能说话”变成“能动手”。现代 Coding Agent 的基本工具集离不了这么几样：读取文件、写入文件、执行测试、运行 shell 命令、搜索代码、git 操作。每个工具的本质都是把一个外部能力封装成模型可以调用的函数，并约定好输入输出格式。
3.2 主流 Agent 框架选型：别被名词搞晕
现在市面上的 Agent 框架多到让人选择困难，我先把最常见的几类整理成一张表，再讲选型逻辑：
| 框架 | 定位 | 适合场景 | 上手难度 |
|---|---|---|---|
| LangGraph | 有向图状态编排 | 需要精细控制流程的软件工程任务 | 中高 |
| CrewAI | 多角色协作框架 | 快速搭 demo、研究角色分工 | 低 |
| AutoGen | 多智能体对话框架 | 研究试验、学术原型 | 中 |
| OpenAI Agents SDK | 轻量单 Agent 工具调用 | Python 快速实现单个 Agent | 低 |
| OpenHands / Codex | 直接操作代码仓库的编码 Agent | 真实 Coding Agent 替代人工编码 | 中高 |
| Spring AI | Java 生态 Agent 集成 | JVM 背景团队 | 中 |
选型不是越复杂越好。我的建议很朴素：如果你是软件工程背景，想长期做 Coding Agent，重点看 LangGraph 这类状态机方案，因为它把分支、重试、终止条件都显式化了，排查问题时有据可循；如果只是为了理解 Agent 开发是怎么回事，CrewAI 十分钟就能跑通一个多角色 demo。还有一种情况是直接用 OpenHands、Codex 这类已经封装好的编码 Agent，相当于不自己造轮子，把精力集中在任务分解和结果评审上。
Python 生态依然是 Agent 开发的主战场，因为 AI 领域的工具链、模型接口、数据处理库几乎都以 Python 为第一优先。哪怕你团队主力是 Java，我也建议先在 Python 里把概念跑通，再用 Spring AI 那套东西搬到 JVM 生产环境，这样心智负担会小很多。框架本身不重要，状态流转、工具调用、记忆读写、评估反馈这四个核心机制才是真正要理解的东西。
3.3 Harness 和 Agent 不是一回事：排查报错先分清边界
热词里高频出现“harness 和 agent 区别”“codex 无法发送消息”“显示更新 agent 沙盒”这类问题，这里专门说清楚。Harness 和 Agent 是两回事：Agent 是决策大脑，Harness 是它活动的场地和工具包。Agent 负责理解任务、决定调用哪个工具、解释结果、规划下一步；Harness 负责加载工具、准备代码仓库快照、隔离沙盒、限制权限、控制资源与终止条件、把模型输出解析成可执行动作。
这个边界对排查问题特别重要。当你看到“agent execution terminated due to error.”这类报错，我的第一反应不是怀疑模型笨，而是先查 harness：是不是工具输出格式没被正确解析？是不是最大迭代次数设得太小？是不是沙盒里依赖没装全？是不是执行超时被强制结束了？这些问题十有八九出在运行环境而不是模型本身。反过来，如果模型反复做出错误决策，那才是 Agent 层的问题，需要调整提示词、换模型或者补充领域知识。
理解了 harness 和 agent 的分工，你就能理解为什么会有“沙盒更新”这种操作。沙盒是给 Agent 准备的临时工作区，每次任务应该在干净的环境里启动，依赖锁定、权限最小化、日志可审计。生产环境千万不要直接丢给 Agent 摆弄，先让它在副本里折腾，验证没问题再走正常发布流程，这是 Agent 工程化的安全底线。
4. 从零搭一个极简 Coding Agent：Python 实操与并发笔记
4.1 环境准备与最小实现
理论讲太多容易虚，这里上一个能跑的最小实现。我的环境是 Python 3.11，核心依赖是 langgraph 和 openai，本地调试时也可以换成 ollama。安装命令很简单：
没必要一上来就上完整 LangGraph 图，先用一个带循环的极简 Agent 把概念跑通。核心思想是让模型每次只输出一个 JSON，字段固定为 action、params、thought。我定义三个工具：run_test 执行 pytest、read_file 读文件、write_file 写文件。
主循环的逻辑是：把用户任务和工具返回结果拼进对话历史，调用模型，解析模型输出的 JSON，然后分发到对应工具。模型输出解析失败就让它重来，同时保留错误信息，避免它反复犯同样的格式错误。真实项目里 call_llm 可以是 OpenAI 接口的封装，也可以是 ollama 的本地模型，关键是这个“结构化输出”约定，它把所有不确定性都收敛到了可控的解析层。
这个实现虽然简陋，但把 Agent 最核心的机制都包含了：工具调用、上下文积累、循环执行、终止条件。看懂这一个循环，后面再去学 LangGraph 的状态图、CrewAI 的角色协作，都是在这个地基上做扩展。
4.2 让 Agent 自动修一个 bug 的现场记录
理论代码跑通之后，我实际测过一个小任务：仓库里有一个 sample.py，函数 divide(a, b) 直接做除法，测试用例里包含除零场景，一跑 pytest 就挂。任务描述是“修复 divide 函数的除零问题，并让测试通过”。
第一次让 Agent 跑的时候，它犯了一个典型错误：没读文件就直接写文件，自作主张把除零时返回 0。测试期望其实是抛出 ValueError，结果越改越错。这就是缺少“观察”环节的表现。我在提示词里强制要求“修改前必须 read_file 一次，修改后必须 run_test 验证，失败就继续迭代”，行为立刻变好。
第二次执行流程很标准：先 read_file 看当前实现和测试文件里的断言，然后 write_file 补上除零保护逻辑，再 run_test 验证测试通过，最后 finish 返回结论。就这么一个几十行的例子，完美展示了 Agent 的工作循环为什么是“观察-行动-再观察”：没有观察就是盲改，不验证就是自嗨。把这套循环放大到真实项目里，再配上并发和安全控制，就是一个能干活的最小 Coding Agent 产品。
4.3 并发问题：AI Agent 怎么扛得住真实业务
热词里“ai agent 怎么扛并发”出现频率很高，这确实是从 demo 走向生产绕不开的问题。先说一个容易误解的点：单个 Agent 内部不要搞多线程并发。模型推理本身是串行的，一个 Agent 会话内部应该一次只做一件事，否则状态会乱。真正的并发应该是任务级并发：同时跑多个彼此隔离的 Agent 会话，每个会话处理一个独立的任务。
我在实际项目里用的方案是“任务队列加 Worker 池”：每个任务先投递到 Redis 队列，后端跑固定数量的 Worker，比如 4 个，每个 Worker 内启动一个独立的 Agent 会话。会话之间用独立沙盒隔离，不共享任何全局变量。这么做的好处是单点失败不会污染其它任务，坏处是要额外做任务状态管理和结果回收。
这里特别强调幂等设计。Agent 的工具调用如果有副作用，重复执行就会出问题。我的经验是写文件前先备份、git 操作先开独立分支、所有可写操作加版本标记。实测下来，并发数的瓶颈往往不在模型而在工具执行时间和 token 速率限制。无脑加 Worker 会遇到模型服务限流，正确做法是先压测出单 Agent 的平均耗时和 token 消耗，再反推合适的并发数。
5. 从吴恩达教程到 2026 年风向：Agent 开发到底该怎么学
5.1 吴恩达总结的四种 Agent 设计模式为什么是地基
前阵子吴恩达那个 Agent 教程出圈，他把 Agent 设计模式归纳成四种：反思 Reflection、工具使用 Tool Use、规划 Planning、多智能体协作 Multi-Agent Collaboration。很多刚接触 agent 开发的人把它当概念听，但在软件工程语境下，这四个模式每一项都对应具体动作。
反思对应代码自审：让 Agent 生成完代码后先给自己挑毛病，检查边界和异常处理，相当于把开发者的人工 review 前置了一轮。工具使用对应“能动手”：没有工具，Agent 只能给建议，有了 pytest、git、docker 这些外挂，它才能真正改代码、跑流程。规划对应任务拆解：把一个大 issue 拆成可执行的子任务，再逐个完成。多智能体协作对应角色分工：架构 Agent 拆模块，编码 Agent 写实现，测试 Agent 做验证，各司其职。把这四条吃掉，再看任何 Coding Agent 产品都会觉得眼熟。
5.2 2026 年 AI Agent 产品会在哪些方向扎堆
从 2026 年的时间点回看，国内外的 AI Agent 产品已经在几个明确方向扎堆。第一是编码助手与代码评审工具，这是离软件工程最近的一类；第二是自动化测试生成与回归反馈闭环，让 Agent 看完失败用例直接出修复建议；第三是运维排障，读取告警、聚合日志、定位根因；第四是数据分析与报表生成；第五是知识库问答和企业内部流程自动化。
这些方向形态不同，底层结构却出奇一致：工具加记忆加编排。区别只是工具集不同、知识库不同、业务约束不同。我建议初学者不要把精力放在“哪个产品最好用”上，而是抓住底层的 Agent 架构，理解一个 Agent 怎么被构建、评测、安全地放到生产环境。换产品容易，换架构认知很难，后者才是真正可迁移的技能。
5.3 三个月入门路线与高频面试题思路
最后给一条亲测可行的 Agent 开发学习路线。第一个月打好基础：搞懂大模型基本原理，熟练编写和调试提示词，同时补一下 Python 和软件工程基础，起码能写工具函数。第二个月进入核心：做工具调用，学会用函数封装外部能力；做上下文管理，理解 token 限制和消息结构；再给 Agent 加长期记忆，用向量库存关键信息。第三个月上工程化：多智能体协作、安全沙盒、评测闭环、并发控制，把项目部署成可用的服务。
配合这条路线，列几个高频面试题和答题思路。Agent 与普通 Chatbot 的本质区别是什么，核心是 Agent 有工具调用和外部反馈闭环，能对环境产生作用。如何防止 Agent 陷入死循环，答案是设置最大迭代次数、终止条件、重复动作检测。如何给 Agent 增加长期记忆，答案是会话上下文加外部持久化，把关键决策和历史结论存进向量库或数据库。如何评测一个 Coding Agent，答案是一组带测试的 golden tasks，统计通过率、平均步数、token 成本、耗时。两个 Agent 共享工具状态时的并发问题怎么解决，答案是任务级隔离，不要共享可变状态。Harness 与 Agent 的边界，合前面讲的，运行时与决策的划分。
6. 踩坑实录与排查技巧：把 Agent 放进真实工程里
6.1 高频报错速查表
Agent 工程化过程中，我收集到的高频问题基本都集中在运行环境、状态管理、工具调用上。整理成一张速查表，方便你照着排：
| 现象 | 常见原因 | 排查思路 |
|---|---|---|
| agent execution terminated due to error. | 连续工具执行失败，或达到最大迭代次数 | 翻日志看最后一次工具输出，检查是否缺 try/except，再适当调大 max_iterations |
| codex 无法发送消息 | 客户端会话卡死，或服务端限流 | 重启会话，检查网络与认证状态，清理残留进程 |
| 显示更新 agent 沙盒 | 沙盒缓存与仓库依赖不一致 | 强制重建沙盒，锁定依赖版本，避免漂移 |
| Agent 记忆丢失 | 每次请求都新建上下文，没有持久化 | 引入记忆表，把历史决策和文件状态落库 |
| 并发出错 | 多个任务共享了可变全局状态 | 任务级沙盒隔离，禁止跨任务共享变量 |
这些坑看起来五花八门，根子上都是“边界没划清楚”。Agent 的工作环境必须是可重建、可丢弃的，任何任务都该从一个干净状态开始，跑完留下结果和日志，然后销毁环境。一旦你养成了这个习惯，一半的诡异报错都会自动消失。
6.2 Agent 安全和权限最小化
Agent 越能干，权限越要收得紧。你不能因为模型聪明就给它生产环境的最大权限，这和“不能让实习生直接动生产库”是同一个道理。我的安全基线是四条：最小权限，Agent 只能读指定代码库、写指定目录、跑白名单命令；沙盒隔离，工作区可随时销毁重建；资源限制，CPU、内存、执行时间都要设上限；审计日志，每次工具调用都要留痕。
安全不是“上线前加一步”，而是从搭 Agent 第一天就要考虑的设计约束。尤其是那些要自动改代码的 Agent，如果它能写文件，就必须想清楚自己到底被允许写哪些文件、改完有没有人工 review 环节。我见过一个团队让 Agent 直接改了生产配置，导致线上故障，后来才补上权限控制。工具越强，边界就必须越硬。
6.3 给 Coding Agent 上评测，别让 demo 骗了你
最后想认真说一句：很多 Agent 演示看起来在干活，但离“能交付”还差得远，关键差距在评测。我习惯给 Coding Agent 建一套 golden tasks：选一个固定的仓库，里面准备好十个带测试的失败任务，每次改完 Agent 都跑一遍，统计通过率、平均步数、token 成本和平均耗时。没有这套评测，你根本不知道自己改提示词是变好了还是变差了。
评测粒度也不需要一开始就做得很重。最小的闭环就是“任务描述加测试断言加终止条件”，能跑通就算过，跑不过就是失败。随着任务集变大，再把分类维度加进来：简单 bug 修复、新增小功能、重构局部模块。评测跑得多了，你会发现很多看似聪明的方案，在指标面前完全站不住脚，而这种“被数据打脸”的过程，恰恰是 Agent 工程能力成长最快的时候。
我个人在这个过程中的体会是：接受 Agent 重塑软件工程，不等于把自己交给工具，而是把自己从重复劳动中腾出来，去做定义和把关的事。我现在接手新需求，已经从“先写代码”变成“先让 Agent 出一版，我负责拆清楚边界、审出问题、把住验收”。DHH 那句话是不是夸张，每个人会有自己的答案，但把它当成一次自我检查的机会，怎么都不亏。后面有时间，我再把 Agent 跑真实项目的完整评测记录和调优过程整理出来，这篇就当给这一年的变化留个坐标。