1. 这场争论到底在吵什么
DHH 这个名字在后端圈子里基本不用多介绍，Rails 的作者，Basecamp 的联合创始人，常年以“反潮流”著称。他最近关于“手写代码时代落幕、Agent 正在重塑软件工程”的表态，在开发者社区里炸开了锅。有人觉得他是在蹭热度，有人觉得他终于说了句实话。我把相关的讨论、热词和实际动手体验捋了一遍，发现这件事远不是“AI 会不会取代程序员”这种老掉牙的争论，而是关于软件工程的协作单元正在从“人”变成“人 + Agent”。
先把结论摆前面：Agent 不会让手写代码这件事消失，但它会彻底改变“谁在写、写多少、写什么”。以前一个 Rails 项目，从rails new到跑通第一个 CRUD，你得自己敲命令、改配置、写 migration、调路由。现在你完全可以把这一整套交给一个 CLI 里的 Agent，你只负责描述意图和验收结果。这不是未来时，是现在进行时。
这篇文章适合几类人看：一是还在观望 Agent 到底能干什么的后端开发者；二是已经在用 Codex CLI、Claude Code 这类工具但总觉得“差点意思”的人；三是想搞清楚 Agent 架构、Agent 记忆、Agent 编排这些概念到底怎么落地的人。我会从设计思路、核心细节、实操流程、踩坑排查四个维度展开，尽量把每个“为什么”讲透，而不是丢一堆名词让你自己猜。
核心关键词先埋进来：DHH、Agent、软件工程、Rails、CLI。这五个词基本构成了整件事的骨架——一个 Rails 作者，用 CLI 里的 Agent，重新定义软件工程的协作方式。
2. 为什么是 Agent，而不是又一个代码补全
2.1 从“补全一行”到“完成一个任务”的质变
很多人对 AI 编程的印象还停留在 Copilot 那种“你打字它猜下一行”。那个阶段的核心价值是降低击键次数，但你的大脑仍然是主控，你得知道下一步写什么，它只是帮你省点力气。Agent 的逻辑完全不同：你给它一个目标，比如“给这个 Rails 项目加一个带分页的用户列表接口”，它会自己去读代码、找路由文件、写 controller、加 gem、跑 migration、甚至写测试。你的角色从“执行者”变成了“验收者”。
这个转变为什么重要？因为软件工程里真正耗时的从来不是敲键盘，而是理解上下文、定位改动点、验证结果。Agent 恰好在这三件事上都能插上手。DHH 说“手写代码时代落幕”，我理解他说的不是没人写代码了，而是“逐行手写”不再是主要工作方式。
2.2 Agent 和传统脚本、代码生成器的本质区别
有人会说，代码生成器早就有了，Rails 的 scaffold 不就是吗？区别在于决策能力。scaffold 是确定性的，你给它模型名，它生成固定模板。Agent 是概率性的，它会根据你项目的实际情况做判断：你这个项目用的是 UUID 主键还是自增 ID？分页用的是 kaminari 还是 pagy？测试框架是 RSpec 还是 Minitest？它会先读再写，而不是无脑套模板。
这就是为什么 Agent 框架里“记忆”和“编排”这两个词出现频率极高。没有记忆，它每次都要重新读一遍项目；没有编排，它没法把“读代码→改代码→跑测试→修错误”串成一个闭环。热词里出现的agent记忆、agent框架与编排、agent架构，说的都是这件事。
2.3 为什么 CLI 成了主战场
你可能会问，为什么这些 Agent 都往 CLI 里钻，而不是做成 IDE 插件？我的实际体验是：CLI 是最接近“可编排”的界面。IDE 插件受限于宿主环境，能做的事有限；而 CLI 里一个 Agent 可以调用任意命令、读写任意文件、串联任意工具。Codex CLI、Claude Code、GitLab CLI 这些工具的火爆，本质上是因为它们把“命令行”变成了“Agent 的操作系统”。
而且 CLI 天然适合脚本化和自动化。你可以让一个 Agent 在 CI 里跑，也可以在本地终端里交互。这种灵活性是 GUI 给不了的。热词里codex cli 安装、codex cli使用教程、codex cli如何更新搜索量高，说明大量开发者正在把 CLI Agent 纳入日常工作流。
3. Agent 落地软件工程的核心细节
3.1 Agent 的四个关键能力拆解
要把 Agent 用明白，得先知道它靠什么干活。我把它拆成四块：
- 上下文读取：能读项目文件、git 历史、依赖清单、甚至 issue 描述。这是它做判断的基础。
- 工具调用：能执行 shell 命令、调 API、读写文件。没有工具调用能力的 Agent 只是个聊天机器人。
- 记忆管理：短期记忆是当前会话，长期记忆是项目级的知识沉淀。热词里的
agent记忆和a-memguard就是在解决记忆的安全和持久化问题。 - 自我修正：跑测试失败后能读错误日志、定位问题、重新改代码。这个闭环是 Agent 和“一次性代码生成”的分水岭。
这四块里，自我修正是最难也最有价值的。我实测下来，一个没有自我修正能力的 Agent，产出代码的可用率大概在六成左右；加上“跑测试→读报错→改代码”这个循环后，可用率能拉到八成以上。剩下的两成，基本是需求本身描述不清导致的。
3.2 Rails 项目里 Agent 能接哪些活
拿 Rails 举例，因为 DHH 的背景，也因为 Rails 的约定优于配置特性特别适合 Agent 发挥。我列一下实际能交给 Agent 的任务类型：
| 任务类型 | 具体例子 | Agent 适合度 |
|---|---|---|
| 脚手架生成 | 新建 model、controller、migration | 极高，几乎零风险 |
| 业务逻辑 | 写 service object、加校验规则 | 高，需人工验收 |
| 测试编写 | 补 RSpec 用例、加请求测试 | 高，但需检查断言质量 |
| 重构 | 提取 concern、拆分胖 controller | 中，需明确边界 |
| 性能优化 | 加索引、改 N+1 查询 | 中，需压测验证 |
| 架构决策 | 选型、分层设计 | 低，仍需人来拍板 |
你会发现，越是有明确验收标准的任务，Agent 干得越好。因为验收标准就是它的“目标函数”。反过来，那些“你觉得怎么好就怎么来”的任务，Agent 反而容易跑偏。
3.3 一个容易被忽略的点：Agent 的“人格”配置
热词里有个很有意思的条目叫cli切换人格的6个步骤。这说的其实是 Agent 的 system prompt 配置。同一个模型，你给它不同的角色设定，产出质量差异巨大。比如你让它“你是一个严谨的 Rails 专家，所有改动必须先写测试”，和“你是一个快速原型助手，优先跑通功能”，出来的代码风格完全不同。
我的做法是给不同任务配不同人格：写业务逻辑时用“保守派”，强调测试和边界；做原型时用“激进派”，先跑通再说。这个技巧在官方文档里基本不会写，但实际用起来效果立竿见影。
4. 完整实操：用 CLI Agent 跑通一个 Rails 功能
4.1 环境准备与工具选型
先说工具。目前主流的 CLI Agent 有几类：Codex CLI、Claude Code、以及各种开源 Agent 框架。选哪个取决于你的需求：
- 追求开箱即用：Codex CLI 或 Claude Code，安装完配个 key 就能跑。
- 追求可定制：用开源 Agent 框架自己搭，能接自己的模型、自己的工具。
- 追求团队协作：考虑带 Git 集成的方案，方便 code review。
安装环节常见的坑是运行时依赖。热词里unable to locate the codex cli binary or required runtime components和node_modules\@opencode\cli\bin\opencode.exe 与你运行的 windows 版本不兼容都是典型的环境问题。我的建议是：优先用官方推荐的安装方式，别自己手动挪二进制文件。Node 版本用 nvm 管理，Python 版本用 pyenv 管理，能省掉一大半兼容性问题。
# 以 Node 环境为例，先确认版本 node -v npm -v # 用官方渠道安装，不要手动下载二进制 npm install -g @xxx/cli # 验证安装 xxx --version4.2 给 Agent 下达第一个任务
假设你有一个现成的 Rails 项目，想加一个“文章列表带分页和搜索”的功能。不要一上来就说“帮我加个文章列表”，太模糊。好的任务描述应该包含目标、约束、验收标准三要素：
目标：在现有 Rails 项目中新增文章列表页，支持按标题搜索和分页。 约束：分页用 pagy，搜索用 ransack，不要引入新的重型依赖。 验收标准：访问 /articles 能看到列表，搜索框输入关键词能过滤，每页 20 条，测试通过。
这样描述之后，Agent 的产出质量会明显提升。我试过用模糊描述和结构化描述各跑一次，后者的一次通过率高出将近一倍。
4.3 观察 Agent 的执行过程
Agent 开始干活后，你会看到它的一系列动作：读 Gemfile、读 routes.rb、读现有 controller、生成 migration、写 controller、写 view、跑测试。这个过程你要盯着，但不是盯着它写的每一行，而是盯着它的决策点。比如它决定用 ransack 还是自己写 where 条件，决定把搜索逻辑放 controller 还是 model，这些决策点才是你该介入的地方。
我一般会在 Agent 跑完第一轮后做三件事：看 git diff、跑一遍测试、手动点一遍页面。git diff 看它改了什么，测试看它有没有破坏现有功能，手动点看用户体验对不对。这三步走完，基本能拦住九成的问题。
4.4 参数与配置的选择逻辑
Agent 工具通常有一堆配置项，比如最大 token 数、温度、工具白名单。这些参数怎么调？我的经验是：
- 温度：写代码用低温度（0.1-0.3），保证确定性；做头脑风暴用高温度（0.7-0.9）。
- 最大 token：别设太小，否则它读到一半上下文就被截断了，容易做出错误判断。
- 工具白名单：生产环境一定要限制，别让 Agent 能执行
rm -rf这种命令。
热词里agent安全和a-memguard说的就是这类问题。Agent 能力越强，越需要边界约束。这不是不信任它，而是工程上必须有的防护。
5. 踩坑实录与排查技巧
5.1 常见问题速查表
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| Agent 无法发送消息 | 网络或 key 配置问题 | 检查 API key 和网络连通性 |
| 提示更新 Agent 沙盒 | 沙盒环境过期 | 按提示更新或重建沙盒 |
| 执行命令报 internetopenurl 失败 | 系统代理或证书问题 | 检查系统网络配置 |
| 二进制与系统不兼容 | 架构或版本不匹配 | 用官方安装渠道重装 |
| Agent 反复改同一处代码 | 上下文丢失或目标不清 | 补充验收标准，重启会话 |
| 测试一直失败但代码看着对 | 环境依赖缺失 | 先手动跑一遍测试确认环境 |
5.2 三个我踩过的坑
第一个坑：让 Agent 在没有测试的项目里干活。没有测试，Agent 就没有反馈信号，它改完代码自己也不知道对不对。我现在的做法是，哪怕项目再小，也先让 Agent 补一套基础测试，再让它做业务改动。测试是 Agent 的“眼睛”。
第二个坑：一次给太多任务。我试过让 Agent 一口气做“加用户认证 + 加权限 + 加审计日志”，结果它做到一半上下文就乱了，前面改的东西和后面改的冲突。后来我改成一次只做一个功能，做完验收再下一个，成功率大幅提升。
第三个坑：忽略 Agent 的记忆污染。长期记忆用久了会积累错误信息，比如它记住了某个已经删掉的模型，后面就会引用不存在的类。定期清理或重建记忆是必要的维护动作。
5.3 关于并发和部署的现实问题
热词里ai agent 怎么扛并发是个很实际的问题。Agent 本身跑在单机上问题不大，但如果你想让多个 Agent 并行处理任务，就得考虑任务队列、状态隔离、结果合并。我的建议是：初期别碰并发，先把单 Agent 工作流跑顺。等你能稳定地用 Agent 完成日常任务了，再考虑用队列把独立任务分发出去。
部署方面，Agent 跑在容器里是常见做法。热词里docker容器里的ros2 humble, micro-ros agent虽然是机器人领域的，但思路相通：把 Agent 和它的依赖打包进容器，保证环境一致。这样换台机器也能跑，不会出现“在我电脑上好好的”这种问题。
6. 我对这件事的真实看法
DHH 说的“手写代码时代落幕”，我理解成两层意思。一层是逐行手写确实在减少，Agent 接管了大量重复性、模板化的编码工作。另一层是软件工程的评价标准在变，以前看你代码写得好不好，现在看你能不能把 Agent 编排好、能不能设计出清晰的验收标准、能不能在 Agent 产出基础上做高质量的把关。
我自己的体感是，用了 CLI Agent 之后，我花在“敲代码”上的时间大概少了六成，但花在“想清楚要什么”和“验收结果”上的时间多了。这不是坏事，因为后者本来就是软件工程里更值钱的部分。Agent 把脏活累活接走了，留下的是真正需要判断力的活。
如果你现在还没开始用 Agent，我的建议是从一个小任务开始，比如让它帮你补一个模块的测试，或者重构一个胖方法。别一上来就搞大项目，先建立对它的信任和边界感。用顺了之后，你会发现它不是一个“更聪明的补全”，而是一个能跟你协作的工程伙伴。
最后分享一个我最近常用的技巧：让 Agent 在改代码前先写一段“改动计划”，说明它打算改哪些文件、为什么这么改。你看完计划再让它执行，能拦掉很多方向性错误。这个动作花不了几秒钟，但省下的返工时间是以小时计的。
