1. 当 DHH 说“手写代码时代落幕”，他到底在说什么

DHH 这个名字，如果你写过 Rails，大概率不会陌生。Ruby on Rails 的作者、Basecamp 的联合创始人、那个永远带着点“反潮流”气质的丹麦程序员，最近又扔出了一颗炸弹——大意是：手写代码的时代正在落幕，Agent 正在重塑软件工程。这话一出来，圈子里立刻炸了锅。有人拍手叫好，有人嗤之以鼻，更多的人是懵的：Agent 到底是什么？它凭什么能“重塑软件工程”？我是不是该转行了？

先别慌。我做了十多年一线开发，从最早手写 SQL 拼字符串，到后来用 ORM，再到 CI/CD 自动化，每一次工具链的升级都伴随着“程序员要失业了”的论调。但这次不太一样。Agent 不是简单的代码补全，也不是你按 Tab 就帮你写完一行的 Copilot。它是一个能自己规划、自己执行、自己验证、自己修正的闭环系统。你给它一个目标，它会拆解任务、调用工具、读写文件、运行测试、根据报错调整策略，直到把事办成。这跟以前那种“你写一行它补一行”的辅助工具，完全是两个物种。

那 DHH 说的“手写代码时代落幕”到底是什么意思？我的理解是：不是说不写代码了，而是说“逐行手写业务逻辑”这件事，正在从主流开发方式退化成一种底层能力。就像今天你开车不需要懂化油器原理，但修车师傅得懂。未来大部分软件工程师的日常，会从“写实现”转向“定义问题、设计约束、审查结果”。Agent 负责把意图翻译成可运行的代码，人负责判断这个翻译对不对、好不好、安不安全。

这篇文章我想聊透几件事：Agent 到底怎么工作的，它跟传统 CLI 工具、跟 Rails 这种“约定优于配置”的框架是什么关系，实际落地时有哪些坑，以及作为一个普通开发者，你现在应该怎么上手。不吹不黑，只讲我踩过的坑和验证过的路。

2. Agent 不是魔法，拆开看就是四件事

2.1 从“补全”到“闭环”：Agent 的核心差异

很多人第一次接触 Agent，会觉得它跟 Copilot 差不多，都是 AI 帮你写代码。但用久了就会发现，Copilot 是“你写它猜”，Agent 是“你说它做”。这个差别看似微小，实则决定了整个工作流的重构。

Copilot 的工作模式是：你正在编辑器里敲代码，它根据上下文预测你接下来要写什么，给你一个建议，你按 Tab 接受或忽略。它的输入是你的光标位置和周围代码，输出是一段文本。它不关心这段代码能不能跑通，不关心项目结构，不关心依赖版本。它就是一个超级智能的自动补全。

Agent 的工作模式是：你给它一个任务描述，比如“给用户表加一个软删除字段，并更新所有相关查询”。它会先理解这个任务，然后规划步骤：第一步，找到用户表的定义文件；第二步，生成迁移脚本；第三步，找到所有查询用户表的地方；第四步，逐个修改查询条件；第五步，运行测试；第六步，如果测试失败，分析报错并修正。整个过程它自己驱动，自己验证，自己迭代。

这个闭环能力来自四个核心组件：规划器、执行器、记忆、工具集。规划器负责把大任务拆成小步骤；执行器负责调用工具去执行每一步；记忆负责保存上下文和历史操作，避免重复劳动和状态丢失；工具集就是它能调用的外部能力，比如读写文件、执行命令、访问网络、查询数据库。

2.2 规划器：Agent 的“大脑”怎么拆任务

规划器是 Agent 最核心也最脆弱的部分。它决定了 Agent 能不能把一个模糊的人类指令，翻译成一系列可执行的具体操作。我试过不少 Agent 框架，发现规划器的好坏直接决定了 Agent 是“智能助手”还是“智障助手”。

一个好的规划器，首先得理解任务的边界。比如你说“优化首页加载速度”，它得知道这不是一个单一操作，而是一个需要先诊断、再定位、再修改、再验证的复合任务。它得能区分“哪些事我现在能做”（比如读代码、跑性能分析），哪些事需要人类介入（比如决定要不要换 CDN 供应商）。

其次，规划器得能处理不确定性。实际开发中，你永远不知道下一步会遇到什么。可能你打开一个文件，发现它跟你预想的完全不一样；可能你跑一个命令，报了一个从没见过的错。规划器不能死板地按预设步骤走，它得能根据执行结果动态调整计划。我见过一些早期 Agent，规划器写得太死，遇到意外就卡住，最后只能报错退出。这种体验还不如自己动手。

最后，规划器得知道什么时候停下来。这听起来简单，其实很难。Agent 容易陷入两种极端：一种是过早放弃，遇到一点困难就说“我做不到”；另一种是无限循环，反复尝试同一个失败的操作。好的规划器会设置合理的重试上限和退出条件，并且在卡住的时候主动向人类求助，而不是自己瞎折腾。

2.3 执行器与工具集：Agent 的“手脚”怎么动

执行器负责把规划器拆出来的步骤，翻译成具体的工具调用。工具集就是 Agent 能用的“武器库”。这两者配合得好不好，决定了 Agent 的实操能力上限。

工具集的设计有个原则：工具要原子化，但语义要清晰。什么意思？比如“读写文件”是一个原子工具，“执行 shell 命令”是另一个原子工具。但你不能把“重构这个模块”当成一个工具，因为那太复杂了，执行器不知道怎么调。反过来，工具的名字和参数要足够清晰，让规划器一看就知道什么时候该用哪个。我见过一些框架，工具命名很随意，结果规划器经常选错工具，效率极低。

执行器还有个关键能力：错误处理。Agent 执行命令时，失败是常态。文件不存在、权限不够、依赖缺失、网络超时，各种问题都会遇到。执行器不能一报错就崩，它得能捕获错误、提取关键信息、反馈给规划器，让规划器决定是重试、换方案还是放弃。这个反馈循环的质量，直接决定了 Agent 的鲁棒性。

2.4 记忆：Agent 的“记性”为什么重要

记忆系统经常被忽视，但它其实是 Agent 能否处理复杂任务的关键。没有记忆的 Agent，每次操作都是“失忆”状态，它不知道刚才做了什么、为什么做、结果如何。这会导致两个问题：一是重复劳动，比如反复读同一个文件；二是状态丢失，比如改了一半的代码，下一步忘了改了什么。

记忆通常分短期和长期。短期记忆保存当前任务的上下文，比如已经执行了哪些步骤、遇到了哪些错误、当前的文件状态。长期记忆保存跨任务的知识，比如这个项目的代码规范、常用的命令、之前踩过的坑。短期记忆让 Agent 能连贯地完成一个任务，长期记忆让 Agent 能越用越聪明。

我实际用下来，记忆系统的设计难点在于信噪比。保存太多，上下文爆炸，Agent 处理不过来；保存太少，关键信息丢失，Agent 犯低级错误。好的记忆系统会做摘要和压缩，只保留对当前决策有用的信息。这个度很难把握，目前大部分框架还在摸索阶段。

3. 从 Rails 到 CLI：Agent 落地时绕不开的几个现实问题

3.1 Rails 的“约定优于配置”为什么天然适合 Agent

DHH 是 Rails 的作者，他谈 Agent 重塑软件工程，绕不开 Rails 这个背景。有意思的是，Rails 的设计哲学跟 Agent 的工作方式有天然的契合点。

Rails 最核心的理念是“约定优于配置”。这意味着项目结构是标准化的：模型放app/models，控制器放app/controllers，视图放app/views，迁移放db/migrate。路由有固定写法，数据库表名默认是模型名的复数形式。这些约定对人类开发者来说是减少决策负担，对 Agent 来说则是降低了探索成本。

你想想，如果一个项目的结构完全自由，Agent 要找一个用户模型的定义，可能得遍历整个代码库。但在 Rails 项目里，它直接去app/models/user.rb就行了。这种可预测性，让 Agent 的规划器能生成更确定的步骤，执行器能更高效地定位文件，整体成功率大幅提升。

另一个契合点是 Rails 的“全栈一体化”。Rails 自带 ORM、路由、模板、测试框架，所有组件都在一个体系内。Agent 不需要在多个工具之间切换，它可以用统一的命令完成迁移、测试、启动服务等操作。这种一致性，对 Agent 来说就是更少的工具调用、更短的反馈循环、更高的执行效率。

当然，这不意味着只有 Rails 适合 Agent。任何有清晰约定和标准结构的框架，都会让 Agent 更好用。但 Rails 确实是这方面的典范，DHH 的观察有他的道理。

3.2 CLI 才是 Agent 的主战场，不是 IDE

很多人以为 Agent 会以 IDE 插件的形式存在，毕竟 Copilot 就是这么做的。但实际用下来，我发现CLI 才是 Agent 最自然的交互界面。

为什么？因为 Agent 的工作方式是“执行命令、观察结果、调整策略”。这跟 CLI 的交互模式完全一致。你在终端里输入一个命令，看到输出，再输入下一个命令。Agent 也是这么干的，只不过它自己决定输入什么命令，自己解析输出。

IDE 插件的问题在于，它被限制在编辑器的上下文里。它能读写文件，但很难执行复杂的 shell 命令；它能分析代码，但很难启动服务、跑数据库迁移、管理进程。而 CLI Agent 没有这些限制，它可以在一个真实的终端环境里，像人类开发者一样操作整个系统。

我实际用 Codex CLI 和 Claude Code 这类工具时，最直观的感受就是：它像一个坐在你旁边的同事，你告诉它要做什么，它就在终端里敲命令，你看着它操作，随时可以打断或纠正。这种体验比 IDE 里那种“它悄悄改你代码”的方式要透明得多，也安全得多。

CLI Agent 的另一个优势是可组合性。你可以把它嵌到 CI/CD 流程里，让它自动处理一些重复性任务；你可以用脚本调用它，批量处理多个项目；你可以把它跟 Git hooks 结合，在提交前自动检查代码质量。这种灵活性，是 IDE 插件很难做到的。

3.3 Agent 的并发问题：为什么“扛并发”是个伪命题

热词里有个“ai agent 怎么扛并发”，这个问题我一开始也觉得挺重要，后来想明白了：大部分 Agent 场景根本不需要扛并发，因为 Agent 的工作模式是串行的。

你想想，一个 Agent 在执行任务时，步骤之间是有依赖的。它得先读文件，才能改文件；先改文件，才能跑测试；先跑测试，才能根据结果决定下一步。这种依赖关系决定了它很难并行化。你强行让它并发执行多个步骤，反而容易导致状态冲突和数据不一致。

那什么时候需要并发？一种是多个独立任务同时执行，比如同时处理多个项目的代码审查。这种场景下，你需要的不是单个 Agent 扛并发，而是多个 Agent 实例并行工作。每个实例处理一个独立任务，互不干扰。另一种是 Agent 内部某些步骤可以并行，比如同时读取多个文件。但这种并行通常由执行器内部处理，不需要 Agent 层面操心。

所以“Agent 怎么扛并发”这个问题，本质上是个架构问题，不是 Agent 本身的问题。你需要的是一个能调度多个 Agent 实例的任务队列，而不是一个能同时干多件事的超级 Agent。想清楚这一点，很多架构决策就清晰了。

4. 实操：从零搭一个能用的 Agent 工作流

4.1 工具选型：Codex CLI、Claude Code 还是自己搭

市面上 Agent 工具不少，我实际深度用过的主要是 Codex CLI 和 Claude Code，也试过一些开源框架自己搭。选哪个，取决于你的需求和动手能力。

Codex CLI 的优势是跟 OpenAI 生态集成好，安装简单，开箱即用。它的命令设计比较直观，适合快速上手。但它的定制能力有限，你很难深度修改它的规划逻辑或工具集。如果你只是想体验一下 Agent 的工作方式，或者做一些标准化的任务，Codex CLI 够用了。

Claude Code 的优势是上下文窗口大，处理复杂任务时不容易丢信息。它的工具集也比较丰富，支持文件操作、命令执行、网络访问等。但它的配置相对复杂，需要你理解它的权限模型和安全机制。另外，它在某些环境下的网络连接可能不太稳定，需要提前测试。

自己搭的话，LangChain、AutoGPT 这些框架都可以用。优势是完全可控，你可以按自己的需求设计规划器、工具集和记忆系统。劣势是工作量大，而且很多坑得自己踩。如果你有明确的定制需求，比如要接入内部系统、要遵循特定的代码规范，自己搭是值得的。否则，先用现成工具跑通流程，再考虑定制。

提示：不管选哪个工具，先在隔离环境里测试。Agent 会执行真实命令，改真实文件，跑真实测试。别一上来就在生产环境或重要项目上试。

4.2 环境准备：别小看这一步

Agent 工具对环境的要求比普通 CLI 工具高。它需要能执行命令、读写文件、访问网络，所以权限配置和安全隔离特别重要。

第一步，准备一个独立的开发环境。可以是 Docker 容器，也可以是虚拟机，或者至少是一个独立的用户账户。别用你的主账户跑 Agent，万一它误删文件或执行危险命令，后果很严重。

第二步，安装必要的运行时。大部分 Agent 工具需要 Python 或 Node.js 环境。以 Codex CLI 为例，它需要 Node.js 18 以上版本。安装命令很简单：

# 安装 Node.js（以 Ubuntu 为例） curl -fsSL https://deb.nodesource.com/setup_18.x | sudo -E bash - sudo apt-get install -y nodejs # 验证安装 node --version npm --version

第三步，配置 Agent 工具本身。以 Codex CLI 为例，安装命令是：

npm install -g @openai/codex-cli

安装完成后，你需要配置 API 密钥。这个密钥决定了 Agent 能调用哪个模型，也决定了你的使用成本。建议先用小额度测试，确认工作流没问题再加大投入。

第四步，准备一个测试项目。别拿空目录试，Agent 需要真实的代码上下文才能展示能力。可以克隆一个开源项目，或者用 Rails 快速生成一个：

gem install rails rails new agent-test --database=postgresql cd agent-test

这个项目结构清晰，有模型、控制器、测试，适合用来测试 Agent 的各种能力。

4.3 第一个任务：让 Agent 帮你加一个功能

环境准备好了，来跑第一个真实任务。我选的是一个很典型的 Rails 需求：给用户表加一个软删除功能。

任务描述我写成这样：

给 User 模型添加软删除功能。要求：1. 添加 deleted_at 字段；2. 默认查询排除已删除用户；3. 提供 soft_delete 和 restore 方法；4. 更新相关测试。

这个描述包含了目标、约束和验收标准，Agent 能理解得更准确。如果只写“加软删除”，它可能会漏掉某些要求，或者用你不喜欢的方式实现。

Agent 接到任务后，通常会先探索项目结构。它会读app/models/user.rb，看现有的模型定义；读db/schema.rb，看当前的表结构；读test/models/user_test.rb，看测试怎么写。然后它会生成一个计划，大概是：生成迁移文件、修改模型、更新测试、运行测试。

执行过程中，它会调用各种命令。比如生成迁移：

rails generate migration AddDeletedAtToUsers deleted_at:datetime

然后修改迁移文件，加上索引：

class AddDeletedAtToUsers < ActiveRecord::Migration[7.0] def change add_column :users, :deleted_at, :datetime add_index :users, :deleted_at end end

接着修改模型，加上默认作用域和方法：

class User < ApplicationRecord default_scope { where(deleted_at: nil) } def soft_delete update(deleted_at: Time.current) end def restore update(deleted_at: nil) end end

最后跑测试，看有没有问题。如果测试失败，它会读报错信息，分析原因，然后修正代码。这个迭代过程可能重复几次，直到测试通过。

我实际跑下来，这个任务 Agent 大概用了两分钟，中间失败了一次（默认作用域影响了测试里的计数），它自己发现并修正了。整体体验比我预想的顺畅。

4.4 关键配置：让 Agent 更懂你的项目

Agent 默认的行为可能不符合你的项目规范。比如它可能用Time.current而不是Time.zone.now，可能不写测试，可能不遵循你的代码风格。要让它更懂你的项目，你需要提供额外的上下文。

最直接的方式是写一个AGENTS.md文件放在项目根目录。这个文件告诉 Agent 你的项目有哪些约定、用什么命令、注意什么。比如：

# 项目约定 ## 代码风格 - 使用 RuboCop 检查代码风格 - 方法名用蛇形命名 - 避免使用 default_scope ## 测试 - 使用 RSpec，不用 Minitest - 每个功能都要有对应的测试 - 测试文件放在 spec/ 目录下 ## 常用命令 - 跑测试：bundle exec rspec - 代码检查：bundle exec rubocop - 启动服务：bin/dev

这个文件相当于给 Agent 的一份“入职指南”。它会在规划任务时参考这些约定，生成更符合你期望的代码。我试过加了这个文件之后，Agent 生成的代码质量明显提升，返工率大幅下降。

另一个技巧是给 Agent 提供示例。如果你希望它用某种特定的方式实现某个功能，可以在项目里放一个示例文件，然后在AGENTS.md里指出来。Agent 会参考这个示例，模仿它的风格和结构。

5. 踩坑实录：Agent 实际用起来有哪些坑

5.1 常见报错与排查思路

Agent 工具用起来，报错是家常便饭。我整理了几个高频问题，附上排查思路。

这些报错看起来吓人，但排查思路都差不多：先看日志，定位失败的具体步骤；再检查环境，确认依赖和配置没问题；最后简化任务，排除是任务本身太复杂导致的。

我遇到最多的问题是网络相关的。Agent 需要调用远程 API，网络不稳定时容易超时或失败。解决办法是配置合理的超时时间，并且在 Agent 卡住时能自动重试。有些工具支持配置重试策略，记得打开。

5.2 安全边界：哪些事千万别让 Agent 干

Agent 能执行真实命令，这意味着它也能造成真实破坏。我踩过的最大的坑，是让 Agent 在一个没有版本控制的项目上跑重构任务。它改了一堆文件，跑测试失败，然后试图“修复”问题，结果越改越乱。最后我花了一个下午才恢复原状。

从那以后，我给自己定了几个规矩：

第一，永远在版本控制下工作。Agent 改任何东西之前，先确保代码已经提交。这样即使它改坏了，你也能一键回滚。Git 是 Agent 时代最重要的安全网，没有之一。

第二，限制 Agent 的权限。别给它 sudo 权限，别让它访问生产数据库，别让它执行rm -rf这类危险命令。大部分 Agent 工具支持配置允许的命令白名单，一定要用起来。

第三，重要操作要人工确认。比如数据库迁移、部署、删除文件，这些操作应该让 Agent 先给出计划，你确认后再执行。有些工具支持“dry run”模式，先模拟执行，看看它会做什么，确认无误再真正跑。

第四，定期审查 Agent 的操作日志。Agent 可能会做一些你意想不到的事，比如修改了不该改的文件、安装了不必要的依赖、访问了外部服务。定期看日志，能及时发现这些问题。

注意：Agent 的安全问题不是技术问题，是流程问题。再好的工具，如果你不给它设边界，它就可能闯祸。把安全规则写进AGENTS.md，让 Agent 自己遵守，比事后补救有效得多。

5.3 成本控制：别让 Agent 烧光你的额度

Agent 调用大模型 API 是按 token 计费的。一个复杂任务可能消耗几十万甚至上百万 token，成本不低。我第一个月用下来，账单比我预想的高了不少。

控制成本有几个办法。一是限制上下文长度。Agent 每次调用模型时，会把当前的任务状态、历史操作、文件内容都塞进上下文。如果上下文太长，token 消耗就大。好的 Agent 工具会做上下文压缩，只保留关键信息。你可以配置压缩策略，比如只保留最近 N 步的操作记录。

二是用更便宜的模型做简单任务。不是所有任务都需要最强的模型。读文件、跑命令、解析输出这些操作，用便宜的小模型就够了。只有复杂的规划和决策，才需要用大模型。有些框架支持模型路由，根据任务类型自动选择模型，能省不少钱。

三是设置预算上限。大部分 API 平台支持设置月度预算，超过就停止服务。这个一定要设，防止意外情况导致账单爆炸。

四是缓存重复操作。如果 Agent 反复读同一个文件、跑同一个命令，可以缓存结果，避免重复调用模型。这个需要框架支持，自己搭的话可以加一层缓存。

我现在的做法是：日常开发用中等模型，复杂重构用大模型，简单查询用小模型。一个月下来，成本控制在可接受范围内。

6. 软件工程的新分工：人负责什么，Agent 负责什么

6.1 从“写代码”到“定义问题”

Agent 时代，软件工程师的核心能力在转移。以前你花 80% 的时间写代码，20% 的时间想需求。未来可能反过来：你花 80% 的时间定义问题、设计约束、审查结果，20% 的时间处理 Agent 搞不定的边角料。

“定义问题”听起来简单，其实很难。你得能把一个模糊的业务需求，翻译成 Agent 能理解的清晰指令。你得知道哪些约束是必须的，哪些可以放宽。你得预判 Agent 可能在哪里出错，提前给它指路。这些能力，本质上是对业务的理解和对技术的判断，不是写代码能替代的。

我实际用 Agent 做项目时，最大的感受是：写代码的时间确实少了，但思考的时间多了。以前拿到需求就开始敲键盘，现在得先想清楚：这个需求的核心是什么？有哪些边界条件？用什么方案最合适？Agent 可能会怎么实现？我该怎么验证它做对了？这些问题想清楚了，Agent 执行起来就顺畅；想不清楚，Agent 就会给你一堆需要返工的代码。

6.2 代码审查变成“结果审查”

传统代码审查，你看的是实现细节：变量命名对不对、逻辑有没有漏洞、边界条件处理了没有。Agent 生成的代码，你依然要看这些，但重点会转移。

因为 Agent 生成的代码，风格通常是一致的，低级错误也少。你更需要关注的是：它有没有理解对需求？有没有遗漏关键场景？有没有引入不必要的复杂度？这些问题，看代码本身不一定能发现，得结合需求文档和测试用例来判断。

我现在的审查流程是：先看 Agent 的任务计划，确认它理解对了；再看它改了哪些文件，确认范围合理；然后跑测试，看功能是否正常；最后抽查关键代码，看实现是否优雅。这个流程比逐行审查快，但要求你对业务和架构有更深的理解。

另一个变化是，测试变得更重要了。Agent 生成的代码，你得有足够的测试来验证。测试写得好，Agent 改完跑一遍就知道对不对；测试写得差，Agent 改完你还得手动验证，效率反而低。所以未来软件工程师的一项核心技能，是写出高质量的测试，让 Agent 能自己验证结果。

6.3 学习路线：现在该学什么

如果你还在学校，或者刚入行，面对 Agent 时代可能会焦虑：我该学什么？我的建议是：基础要扎实，工具要会用，思维要转变。

基础扎实指的是：数据结构、算法、操作系统、网络、数据库这些底层知识，依然重要。Agent 能帮你写代码，但不能帮你理解为什么这么写。遇到复杂问题时，你的基础决定了你能不能判断 Agent 的方案对不对。

工具会用指的是：熟练使用至少一种 Agent 工具，理解它的工作原理，知道怎么配置、怎么调试、怎么控制成本。这就像当年学 Git 一样，不是可选项，是必备技能。

思维转变指的是：从“我要写代码”变成“我要解决问题”。代码只是手段，解决问题才是目的。Agent 能帮你更快地实现手段，但定义问题、设计方案、验证结果，这些还是得你来。

我个人的学习路线是：先用 Agent 做小任务，熟悉它的能力和边界；然后逐步加大任务复杂度，观察它在哪些地方容易出错；最后尝试定制 Agent，让它更贴合自己的项目需求。这个过程不需要很久，但需要你主动去试、去踩坑、去总结。

7. 我个人的一些体会

用 Agent 做开发这几个月，我最大的感受是：它没有让我变懒，反而让我更勤快了。以前遇到重复性任务，我会拖着不想做，因为手动操作太烦。现在我会直接扔给 Agent，自己去做更有意思的事。结果就是，我做的事情更多了，项目的推进速度也更快了。

另一个感受是：Agent 放大了你的能力，也放大了你的问题。如果你对项目理解清晰、规范明确，Agent 会帮你高效执行；如果你自己都稀里糊涂、代码一团乱麻，Agent 只会把混乱放大。所以用好 Agent 的前提，是你自己得先想清楚。

最后分享一个小技巧：给 Agent 写任务描述时，多用“验收标准”。比如“完成后，所有测试通过，RuboCop 无警告，功能在浏览器里能正常使用”。这些标准让 Agent 知道什么时候算完成，也让你知道怎么验证它做对了。我试过加了这个之后，Agent 的返工率明显下降。

这个领域变化很快，今天好用的工具，明天可能就被替代了。但底层的逻辑不会变：理解问题、设计方案、验证结果，这些能力永远有价值。Agent 只是让这些能力的杠杆更大了。