本文永久链接 – https://tonybai.com/2025/07/05/agentic-coding-is-the-future

大家好，我是Tony Bai。

软件开发的范式正在经历一场深刻的变革。从 GitHub Copilot 的惊艳亮相，到各种IDE中集成的代码生成功能，我们已经习惯了 AI 在编码过程中的“自动补全”。但这仅仅是序幕。如今，一种更强大、更具颠覆性的模式正在兴起，它就是——Agentic Coding (智能体驱动编码)。

最近，Flask 和 Jinja2 等知名开源项目的作者 Armin Ronacher 分享了他近几个月沉浸式体验 Agentic Coding 的感受。他认为，这开启了人机协作编程的新篇章，带来了前所未有的生产力飞跃。

Agentic Coding 不再是简单的代码提示，而是开发者与 AI Agent 之间的实时协作 (real time collaboration)。它预示着软件开发的未来，一个我们都应该主动了解和拥抱的未来。

超越“自动补全”：Agentic Coding 是什么？

要理解 Agentic Coding 的变革性，首先要明白它与我们熟悉的“自动补全”工具的本质区别。如果说 Copilot 是你的“智能导航仪”，那么编码 Agent 就是你的“编程搭档”。它能够：

• 理解和分解复杂任务： 将一个宏大的目标（如“为这个项目添加用户认证功能”）分解为一系列可执行的子任务。
• 自主使用工具链： 像人类开发者一样，运行编译器 (go build)、测试框架 (go test)、linter、formatter 等。
• 与开发环境深度交互： 直接创建、修改、删除文件；与 Git 进行交互；浏览文件系统。
• 基于反馈进行迭代： 当编译失败或测试不通过时，Agent 会阅读错误信息，理解问题所在，并尝试进行修复，形成一个“试错-反馈-修正”的闭环。
• 长时间、持续地工作： 甚至可以运行数小时来完成大型任务。

Agentic Coding 的核心，是将 LLM 的推理能力与实际的开发工具链和环境深度结合，使其从一个“代码片段生成器”进化为一个能够自主执行复杂编程任务的“智能体”。

浪潮已至：Agentic Coding 为何在当下爆发？

Armin 认为，这场浪潮的兴起主要源于三个因素的共同作用：

1. 模型能力的突破： OpenAI o3 、Claude 4 Opus、Gemini 2.5 pro等最新一代模型，在“工具使用 (tool usage)”能力上取得了质的飞跃。
2. 官方 Agent 的引领： Anthropic 的 claude-code 等官方 Agent 实现，为社区提供了最佳实践的范本。
3. 更优的成本效益： 通过订阅服务使用 Agentic Coding，使得长时间、高强度的 Agent 运行在经济上变得可行。

如何高效拥抱 Agentic Coding：来自一线的实践指南

要驾驭好这位强大的“编程搭档”，并非易事。Armin 分享了大量宝贵的实践经验，总结起来，核心在于：构建一个“Agent 友好”的环境，并学会如何有效管理上下文。

语言和代码库的选择：“简单”是 Agent 的朋友

• 简单的语言更受欢迎

Armin 发现，像 Go、PHP、基础 Python 这样的语言，对 Agent 更友好。它们的语法结构清晰，概念相对较少，使得 AI 更容易理解和生成代码。Go 语言的简洁性、强大的标准库和较少的生态系统变动，使其成为 Agentic Coding 的理想选择之一。

• 生态系统稳定性很重要

生态系统变动越少的语言或框架，效果越好。

• 代码库内部模式要统一

如果一个代码库中存在多种相互冲突的设计模式，Agent 会感到困惑。

• 命名要清晰

长且独特的函数名能帮助 Agent 更好地理解和定位代码，避免不必要的代码重复。

优化你的开发环境：为 Agent “铺路”

• 构建“Agent友好”的工具

你的工具在被误用时，应该明确报错并提供有用的错误信息，而不是静默失败。Armin 举例说，Rust 的测试框架在未选中任何测试时会报告“成功运行0个测试”，这就是一个反例。

• 统一的、纯文本的日志系统

Agent 需要的是简单、清晰的文本日志来理解系统状态。将浏览器控制台日志、SQL 日志等统一输出到 Agent 可以访问的日志文件中，能极大地帮助它进行端到端的调试。

• 为 Agent 提供“草稿空间”

在项目中明确告知 Agent 在哪里可以安全地创建和运行一次性的测试或探索性代码。

上下文管理是关键：避免“信息过载”与“迷失方向”

• 审慎使用 MCP，拥抱命令行工具

作者发现，当前模型对命令行工具的理解和使用能力，远胜于对 MCP 的。Agent 可以轻松地将多个 CLI 工具组合进 Shell 脚本来完成复杂任务。

• 主动提供摘要，避免 Agent “闲逛”

为 Agent 提供关键 API 或代码模块的摘要，或者构建一个工具来生成摘要，能极大地节省上下文并提高效率。

• 避免在“混乱”的环境中启动 Agent

如果你的开发环境本身是坏的，Agent 会花费大量上下文去修复环境，而不是解决你真正想解决的问题。

• 使用子任务分解复杂问题

将大任务分解为清晰的子任务，是管理复杂性和上下文的有效手段。

拥抱前需理解的关键点：从挑战看发展方向

面对 Agentic Coding 的强大能力，一些开发者可能会有疑虑。我们不必将其视为障碍，而应看作是推动技术向更成熟阶段发展的方向。

• 关于代码质量： Agentic Coding 对开发者的审查能力和架构判断力提出了更高的要求。我们的角色将更多地从“代码生产者”转变为“代码质量的最终负责人和架构师”。我们始终对合并到 main 分支的代码负责。
• 关于“幻觉”问题： 通过工具链（编译、测试、lint）形成的闭环反馈，Agentic Coding 正在有效地缓解“幻觉”问题。这也指明了未来 Agent 开发平台需要重点投入的方向——构建更健壮的验证和反馈机制。
• 关于不擅长特定语言： Agentic Coding 的发展将推动语言和生态系统向更“Agent 友好”的方向演进。正如 Armin 所说，Go 语言因其恰到好处的类型安全、广泛的标准库和推崇惯用法的文化，在这方面已展现出天然优势。
• 关于安全风险（YOLO 模式）： 当前重度用户为了最大化 Agent 能力而给予其完全系统权限的“YOLO 模式”，是一种早期探索阶段的高风险行为。未来，成熟的 Agentic Coding 平台必然会提供更安全、更可靠的权限管理和沙箱环境，这是该领域走向普及的必经之路。

注：YOLO 是 “You Only Live Once” (你只活一次) 的缩写。这个词最初流行于社交网络，表达的是一种活在当下、大胆尝试、不畏惧风险的人生态度。在技术领域，特别是 Armin Ronacher 在谈论 Agentic Coding 时使用的语境下，“YOLO 模式”特指一种大胆甚至有些“鲁莽”的使用方式，即给予 AI Agent 极高的、几乎不受限制的系统访问权限。

Go 语言在 Agentic Coding 时代的独特机遇

在 Armin 的分享中，Go 语言被特别提及，并被认为是 Agentic Coding 的理想选择之一。这并非偶然，Go 的诸多特性使其在这场人机协作的新范式中占据了有利位置：

1. 简洁性与可预测性： Go 语言“简单为王”的设计哲学，使其语法结构清晰、概念少、没有复杂的隐式行为。这使得 AI Agent 能更容易地理解、分析和生成高质量的 Go 代码。
2. 强大的工具链与高效的反馈闭环： Go 的快速编译、内置测试、静态检查等工具，为 Agent 提供了极其高效的“试错-反馈-修正”闭环。Armin 提到的 Go Test Caching 功能，能让 Agent 更智能地只运行受影响的测试，这是一个绝佳的例子。
3. 并发与系统编程能力： Go 语言本身非常适合编写 Agent 所需的各种命令行工具、后端服务、以及处理并发任务的 CI/CD 流程。我们可以用 Go 来为 AI Agent 构建高效、可靠的“武器库”。
4. 清晰的错误处理： Go 显式的 error 返回值机制，相比于异常，为 Agent 提供了更清晰、更可预测的错误处理路径。

小结：拥抱 Agentic Coding，就是拥抱软件开发的未来

Agentic Coding 正在开启一个软件开发的新篇章。它标志着我们与 AI 的关系，从简单的“主仆”（人命令，AI补全），演进为更深度的“伙伴”（人规划，AI协作执行）。

这场变革要求我们主动进化。开发者需要将重心更多地从繁琐的代码实现，转移到复杂问题的分解、系统架构的设计、以及对 AI Agent 的精准引导和结果验证上。

对于我们 Gopher 而言，这是一个激动人心的机遇。Go 语言的设计哲学和工程特性，使其在这场变革中具有天然的优势。与其对新范式感到疑虑或观望，不如主动去学习、实践，探索如何驾驭这位强大的“编程搭档”，让它成为我们提升自身能力、加速项目交付、并最终能专注于更有创造性工作的强大助力。

技术的浪潮滚滚向前，拥抱 Agentic Coding，就是拥抱软件开发的未来。

资料链接：https://www.youtube.com/watch?v=nfOVgz_omlU

聊一聊，也帮个忙：

• 你认为 Agentic Coding 将在哪些方面最先深刻地改变我们的日常开发工作？
• Armin Ronacher 提出的这些实践技巧，哪一点你认为最重要，并计划在自己的工作中尝试？
• 你认为 Go 语言为了更好地成为 Agentic Coding 时代的首选语言之一，社区或官方还可以在哪些方面发力？

欢迎在评论区留下你的思考和经验。如果你觉得这篇文章为你描绘了软件开发的未来图景，也请转发给你身边的开发者朋友们，一起迎接 Agentic Coding 时代的到来！

想与我进行更深入的 Go 语言、AI 赋能开发与技术趋势交流吗？ 欢迎加入我的“Go & AI 精进营”知识星球。

[此处放置知识星球二维码]

我们星球见！

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/07/05/go-is-8020-language

大家好，我是Tony Bai。

如果你写了一段时间的 Go，你可能会有一种独特的感觉。一方面，它简洁、高效、可靠；另一方面，你又会时常觉得它“缺少”了点什么——没有其他语言里那些功能强大、眼花缭乱的特性。

有人因此热爱 Go，有人因此“憎恨” Go。但这种“爱”与“恨”的背后，其实都指向了 Go 语言一个最核心、也最常被误解的设计哲学。最近，一篇精彩的博文《Go is 80/20 language》用一个简单而强大的心智模型，完美地诠释了这一切。

这个模型就是——Go 是一门“80/20”语言。

它旨在用 20% 的复杂度，提供 80% 的实用功能。

正如 Go 语言的创造者之一 Rob Pike 所言：“没人否认 87% 的功能比 80% 好，但问题是，那额外的 7% 功能，往往需要付出 36% 的额外工作。”

这“额外的工作”，不仅是语言实现者的负担，更是我们每一个使用者的隐性成本。

Go 的 80/20 设计实例

让我们通过几个具体的例子，来感受 Go 如何将“80/20 法则”贯彻到底。

1. 并发：Goroutines vs. C#/Rust Async

Go 的并发模型极其简单：一个 go 关键字，加上用于通信的 channel。相比于 C# 或 Rust 中复杂的 async/await 语法、函数“着色”问题、以及需要开发者精细控制的运行时，Go 的并发模型的功能点和“旋钮”要少得多。

这正是 80/20 的体现。Goroutine 和 Channel 提供了 80% 最常用的并发场景解决方案，但其心智负担和实现复杂度，可能只有 async/await 的 20%。它放弃了那“额外 7%”的极致灵活性，换来的是绝大多数开发者都能轻松写对的并发程序。

2. 测试：testing 标准库 vs. Java JUnit

Go 的 testing 标准库只有几百行代码，数年间几乎没有大的变化。它提供了 t.Run, t.Error, b.N 等最核心的测试和基准测试功能。

相比之下，Java 的 JUnit 框架，拥有数万行代码和永无止境的开发迭代，提供了无数便捷的注解和高级功能。但这些功能，真的是我们日常测试所必需的吗？

Go 的 testing 库再次做出了 80/20 的选择：用 20% 的代码量和复杂度，满足了 80% 的测试需求，保持了核心库的稳定与简洁。

3. 元编程：Struct Tags vs. Annotations/Macros

有人抱怨 Go 的 Struct Tags 不如 Java 的注解或 Rust 的宏那么强大。是的，它的功能确实有限，只能附加简单的字符串元数据。

但这恰恰是 80% 的场景所需要的：JSON/XML 的序列化、ORM 映射、配置校验。它用最简单、最直白的方式解决了核心问题，而没有引入宏所带来的编译时复杂性、调试噩梦和陡峭的学习曲线。

4. 泛型：内建泛型先行

当 Go 在 1.0 版本发布时，并没有提供用户自定义泛型。但它为最需要泛型的内建类型——arrays/slices, maps, channels——提供了泛型能力(基于interface{})。

这个决策，是 Go 80/20 哲学最经典的体现。它在当时用最小的实现成本，解决了最痛的 80% 的问题，并让这个设计平稳地服务了 Go 社区超过十年。直到社区和语言本身都准备好了，才谨慎地引入了用户自定义泛型。

警惕“功能跑步机”与“双重成本”

许多其他语言，如 C#, Swift, Rust，它们的目标是“100% 的设计，哪怕付出 400% 的成本”。它们似乎陷入了一场永无止境的“功能跑步机”竞赛，不断地增加新特性。

博文作者一针见血地指出了“增加功能”背后，那常常被忽视的“双重成本”：

1. 实现者成本

每一个新功能，都会增加语言实现的复杂性。以 Swift 为例，尽管有苹果的无限预算和顶尖人才，其编译器在很长一段时间内都以慢、不稳定而闻名，跨平台能力也迟迟未能完善。这正是因为其设计的复杂性远超出了能够被完美实现的范畴。相比之下，Go 的简洁性保证了它从 1.0 版本开始，就拥有一个快速、稳定、全平台支持的编译器。

2. 用户成本

这是更巨大、更隐性的成本。对于我们开发者来说，学习一个新功能，绝不仅仅是学习它的语法。你需要：

• 学习新的编程范式和设计模式。
• 学习在何种场景下应该使用它，以及更重要的，在何种场景下不应该使用它。
• 即使你决定不使用这个新功能，你的同事、你依赖的开源库也可能会用，你最终还是被迫要去理解它，整个生态的认知负荷都在上升。

功能丰富的语言，最终往往需要制定严格的编码规范来限制其使用。比如 Google 的 C++ Style Guide，其存在目的就是为了将一个“95% 功能”的语言，人为地降级到“90% 功能”的子集来使用，以保证大型团队的协作效率。这恰恰从反面证明了“少即是多”的智慧。

小结：少即是多，一种克制的智慧

Go 的 80/20 哲学，并非是懒惰或能力不足，而是一种深思熟虑后的、极其克制的工程决策。它承认了复杂性的巨大代价，并选择把“简单”作为最高优先级。

它为你提供了一套足够强大、但又不至于让你迷失的工具集。它相信，通过组合这些简单的工具，你足以构建出任何复杂的系统。

所以，下一次当你感觉 Go “缺少”某个你习以为常的特性时，不妨换个角度思考：或许，这并非是 Go 的缺陷，而是它最宝贵的财富。

资料地址：https://blog.kowalczyk.info/article/d-2025-06-26/go-is-8020-language.html

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。