译者按: 本文是 Armin Ronacher 于 2025-06-12 发表的《Agentic Coding Recommendations》的中文校对翻译。原文出处: https://lucumr.pocoo.org/2025/6/12/agentic-coding/。读原文时深受启发, 特将全文译出与中文读者分享, 感谢原作者的点醒与提携。译文仅供学习交流, 版权归原作者所有, 如有出入以原文为准。
说明: 原文约 3000 英文词, 是 Flask 作者 Armin Ronacher 对自己数月 agent 重度使用经验的系统总结。本文为精译编译版: 按原文小节逐一还原论点与例子, 用编者中文重述, 关键句直译标注。省略内容: 少量工具链接罗列与过渡句。原文链接见 frontmatter。
前言: 我的基本盘
Ronacher 开门见山交代自己的配置: 主力工具是 Claude Code, 用每月 100 美元的 Max 订阅, 而且几乎只用更便宜的 Sonnet 模型。他明确说对自己的场景而言, Sonnet 的输出他反而更喜欢 (相对更贵的 Opus)。写作动机: 太多人问他怎么用 agent, 与其一遍遍回答, 不如写下来。他同时提醒: 这个领域变化太快, 这篇文章会过时得很快, 但底层原则应该能活得久一点。
一、基础配置
- 他以「放开权限」的方式跑 agent (社区俗称 yolo 模式), 但放在 Docker 容器等隔离环境里控制风险。让 agent 每一步都请求许可, 会毁掉 agent 的核心价值: 不被打断地长时间干活。
- 对 MCP (Model Context Protocol) 的态度出人意料地冷淡: 他几乎不用。理由是 Claude Code 本身跑普通命令行工具已经足够强, 与其为 agent 写 MCP 服务器, 不如给它一个普通脚本。只有当某个能力用常规工具确实做不稳时, 才考虑 MCP。
- IDE 在他的流程里退化为「最后润色」的工具, 主要工作发生在终端里。
二、语言选择: 我为后端选 Go
全文流传最广的判断: 如果新开后端项目且语言可选, 他强烈推荐 Go。理由全部围绕「什么样的语言让 agent 犯错更少、迭代更快」:
- 显式的上下文传递: Go 的 context 机制让数据流向清清楚楚, agent 不需要理解隐式魔法。
- 测试快且有缓存: agent 的工作循环就是「改代码, 跑测试」, Go 的测试运行简单、增量、快, 直接放大 agent 效率。
- 语言简单, 惊喜少: 结构化接口、少继承、少元编程, agent 生成的代码不容易踩进语言陷阱。他有一句反直觉的直译: 「Go 是松垮的, 但这种松垮对 agent 是优点。」
- 生态稳定: 向后兼容性好, 训练数据里的老代码到今天还能跑。
对照组是他自己成名的 Python 生态: agent 在 pytest 的 fixture 注入、async 复杂度、解释器启动慢等问题上反复跌倒。前端方面他用 Tailwind + React + TanStack Query/Router + Vite, 但指出文件路由里的 $ 符号这类花哨约定会把 agent 搞糊涂。
三、工具, 工具, 还是工具
他给出一组工具设计铁律, 核心思想是: agent 的效率上限由它能调用的工具质量决定。
- 一切可交互的东西都应该做成工具 (脚本、make 目标、CLI)。
- 工具必须快: 响应慢的工具会拖垮整个 agent 循环。
- 工具必须输出得少而准: 大量无关输出会污染上下文。
- 工具必须把错误说清楚: agent 靠错误信息自我纠正。
- 工具必须防误用且可诊断: 他举了自己改造的进程管理器例子, 当 agent 试图重复启动开发服务器时, 工具直接回一句「开发服务器已经在跑了」, 并把日志写到文件里供 agent 事后翻查。
四、一切为了速度
agent 时代的一个反转: 决定生产力的常常不是模型推理速度, 而是工具链响应速度。编译快、测试快、启动快的生态在 agent 循环里获得复利; 反过来, 每次要等几十秒的工具链会把 agent 的优势磨光。他建议为此专门优化项目的构建与测试路径。
五、稳定性与复制粘贴
- 选稳定、向后兼容的生态 (他点名 Go 和 Flask 这类), 因为模型训练数据里的知识不会过期得太快。
- 升级依赖要保守, 别追新版本。
- 最反直觉的一条: 他越来越倾向于让 agent 直接生成代码, 而不是引入依赖库。以前「不要重复造轮子」是铁律, 但 agent 把造轮子的成本降到接近零, 而依赖带来的供应链与升级成本没变。直译: 「我做 agentic 编程越多, 越相信这一点。」
六、写简单代码
给 agent 维护的代码, 审美要向「傻直」倾斜:
- 函数名起得长而具体, 少用类和继承。
- 用平铺直叙的 SQL, 不用重度 ORM 魔法, 这样日志和代码能对上。
- 权限检查就写在用到的地方, 让 AI (和人) 一眼看到, 不藏在装饰器或中间件深处。
- 总原则的直译: 「能干活的最笨方案」优于聪明方案。
七、让工作可并行
单个 agent 其实不快, 真正的收益来自并行开多个。为此要解决环境隔离: 多个文件系统检出 (checkout)、Docker 容器等, 让几个 agent 互不踩脚。他提到 container-use 这类项目值得关注。
八、学会重构 (以及收尾)
agent 在代码库复杂度低时如鱼得水, 复杂度越过某个阈值后开始反复回归 (regression)。所以人的关键职责是掌握重构时机: 什么时候抽组件库、什么时候拆模块, 把复杂度重新压回 agent 能驾驭的水位。
收尾他重申: 具体工具建议很快会过时, 但四个原则会留下来: 简单、稳定、可观测、可并行。
原始来源
- 原文: https://lucumr.pocoo.org/2025/6/12/agentic-coding/
- HN 讨论: https://news.ycombinator.com/item?id=44240552 (296 分 203 评论, 可在 hn.algolia.com 检索核实)
原文出处: Agentic Coding Recommendations 原作者: Armin Ronacher 原文发表: 2025-06-12
本文收录于「X深度阅读」栏目: 精选全球 X/Twitter 与博客上最值得精读的 AI 长文, 逐篇校对翻译成中文。