Agentic Coding 是什么？2026年最火的AI编程方式，我花了一周搞明白了
上周有个朋友问我："你现在写代码还自己写吗？"
我说大部分不写了。他说那你在干嘛？我说我在"管人"。
他一脸懵。
我说，管的不是人，是 AI Agent。现在写代码的方式已经变了——你不再是一行一行敲代码的那个人，你变成了给 AI 下任务、审结果、把方向的那个角色。这个东西有个名字，叫 Agentic Coding。
这篇文章是我花了一周时间研究和实践之后写的，把 agentic coding 的概念、工具、工作流和踩过的坑都整理了一遍。如果你也在用 AI 写代码，或者在考虑要不要用，看完应该能少走点弯路。
从 Vibe Coding 到 Agentic Coding：一年之隔，两个世界
去年我写过一篇 Vibe Coding 的文章，讲的是 Karpathy 提出的"氛围编程"——你跟着感觉走，AI 帮你写代码，能跑就行。Karpathy 的原话特别到位："I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works."
当时我觉得这东西挺酷，但说实话只适合做 demo 和小玩具。你真拿它去搞生产环境？翻车概率太高了。我试过用纯 vibe coding 的方式给网站加功能，代码是生成出来了，跑也跑了，但回头看那代码质量……一言难尽。变量命名随缘，错误处理约等于没有，测试更是别想。
Vibe Coding 有个致命问题：代码质量不可控。 生成出来的东西能跑，但没人知道它能跑多久。安全漏洞？性能瓶颈？可维护性？这些 vibe coding 根本不关心。Karpathy 自己也说了，他写代码的时候直接 "Accept All"，根本看都不看 diff。
2026 年情况变了。
Karpathy 自己也改口了。他在回顾的时候说：
"At the time [February 2025], LLM capability was low enough that you'd mostly use vibe coding for fun throwaway projects, demos and explorations. Today, programming via LLM agents is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny."
翻译过来就是：以前 LLM 能力不够，vibe coding 只能玩玩。现在 LLM Agent 已经强到可以搞"真正的工程"了，专业开发者开始把它当成默认工作流——当然，有更多的审查和把控。
他管这个叫 agentic engineering——Agent 工程。
简单来说：Vibe Coding 是跟 AI 一起玩，Agentic Coding 是让 AI 帮你干活。
区别在哪？Vibe Coding 的时候你可能直接说"帮我搞个登录页面"，AI 给你一坨代码，你看看能跑就用。Agentic Coding 的时候你会说："这个模块需要重构，把用户认证从 session 迁移到 JWT，保持向后兼容，写好测试，跑通 CI 再提 PR。"然后 Agent 自己去分析代码、制定计划、执行修改、跑测试、修 bug，搞完了给你看结果。
你从"写代码的人"变成了"下任务的人"。
这中间的角色转变比想象中大。以前你的核心技能是写代码——语法、API、框架、调试。现在你的核心技能变成了：想清楚要做什么、写清楚需求、判断结果好不好。代码本身越来越不值钱，工程判断力越来越值钱。
为什么 2026 年突然火了
说突然也行，说早有预兆也行。几个原因叠加在一起：
模型能力上来了。 2023 年的时候，SWE-bench（一个衡量 AI 解决真实 GitHub issue 能力的基准测试）上最好的模型通过率才 4%。你没看错，4%。100 个真实 bug 里只能修好 4 个。到 2026 年，Claude Opus 和 GPT-5 搭配好的 agent 框架，通过率能到 70-90%。SWE-bench Pro（更难的版本）也能到 50-77%。从 4% 到 90%，你品品这差距。
工具链成熟了。 2024 年的 AI 编程工具基本上就是个高级补全——你写半行，它帮你补后半行。2026 年的工具已经是真正的 Agent 了：能理解整个项目结构、跨文件修改、跑测试、做 code review、甚至帮你部署。Claude Code、Cursor、Codex CLI、GitHub Copilot Agent Mode，每一个都在往"自主开发"的方向狂奔。
工作流标准化了。 现在 agentic coding 工具普遍支持几个关键能力：持久化项目上下文（比如 CLAUDE.md 文件）、集成终端和 Git、多 Agent 协作、长时间运行任务。一年前这些还是各家各搞一套，现在基本趋同了。
企业开始用了。 TELUS 报告说用 agentic coding 节省了超过 50 万开发者工时。Goldman Sachs 在用 Devin 做企业级代码迁移。Cursor 的 ARR 接近 20 亿美元。不再是极客玩具了，是真金白银的生产力工具。
Agentic Coding 的核心架构
用了一段时间之后，我总结出 agentic coding 的几个核心特点。这些不是某个工具特有的，而是整个领域趋同的架构模式。
1. 持久化上下文
以前用 ChatGPT 写代码，最烦的就是它记不住你之前说的东西。每次新对话都得重新解释项目背景、技术栈、代码规范。说了八百遍它还是会用错命名风格。
现在好的 agent 工具都有"项目记忆"。比如 Claude Code 用 CLAUDE.md 文件存储项目约定、架构决策、常用命令。Cursor 有 .cursorrules。OpenAI Codex 用 AGENTS.md。名字不一样，但思路一样：把项目知识持久化到文件里，让 Agent 每次启动都能自动加载。
我在用 Hermes Agent 的时候也有类似体验——它的 memory 系统可以跨 session 记住你的偏好和项目细节。第一次配的时候觉得麻烦，后来发现真香。不用每次都跟它解释"这个项目用 TypeScript"、"测试框架是 vitest"、"部署平台是 Vercel"。
这种持久化上下文看起来不起眼，但对效率的影响巨大。Agent 不用每次都从零开始理解你的项目，直接带着背景知识干活，速度和质量都上去了。
2. 自主反馈循环
这是 agentic coding 最核心的能力，也是跟传统 AI 编程助手最大的区别。
传统 AI 编程助手是"你问我答"：你给个 prompt，它给个回答，完事。你得自己去验证对不对、跑不跑得通、有没有 bug。
Agentic coding 的 agent 是一个循环：
| 1 | |
听起来简单，但实现起来差别巨大。我试过几个工具，有的 agent 跑测试失败了就卡住不动了，等着你告诉它怎么办。有的会自动分析错误原因、修改代码、重跑测试，直到通过。后者才是真正的 agentic coding。
举个真实的例子。我让 Claude Code 帮我重构一个 API 模块。它先读了相关文件，列出了要改的文件清单，然后一个一个改。改到第三个文件的时候 TypeScript 类型检查报错了——一个接口的字段名改了但引用的地方没跟着改。它自己去 grep 了所有引用，找到漏改的地方，改好，重新跑类型检查，通过了。然后继续改下一个文件。
整个过程我没插手。如果是以前的 AI 助手，类型检查报错的时候它会停下来，等你告诉它哪里错了。
3. 多 Agent 协作
这是 2026 年最明显的变化。不再是单个 AI 干所有事，而是多个专门化的 Agent 分工合作。
Anthropic 的 2026 Agentic Coding 趋势报告专门提到了这一点——多 Agent 协调是今年最大的赌注。 不是让一个 Agent 做所有事，而是让专门的 Agent 各司其职。
一个典型的架构：
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
我在用 Hermes Agent 的时候体验过这个模式。它的 delegate_task 功能可以拆分任务给子 Agent 并行处理，主 Agent 负责协调和汇总。搞复杂任务的时候效率确实高不少——比如同时改三个不相关的模块，三个 Agent 并行干活，比串行快多了。
但多 Agent 也有坑。最明显的是状态管理——多个 Agent 同时改同一个文件会打架。解决方案是给每个 Agent 独立的工作空间（比如用 Git worktree），改完了再合并。这个我在后面"实战经验"部分会详细说。
4. 工具集成
Agentic coding 的 Agent 不只是会"说话"，还会"动手"。
它们能直接操作你的开发环境：读写文件、跑终端命令、用 Git 管理版本、调浏览器做测试、连数据库查数据。这才是真正能干活的基础。
我之前用 Claude Code 的时候，给它一个需求，它会自己去：
- 读相关文件，理解代码结构
- 用 grep/find 找到所有相关代码
- 做代码修改
- 跑
npm test - 看测试结果，如果有失败就分析错误
- 修 bug，重跑测试
- 跑 lint 和类型检查
- 全部通过了才给你看结果
整个过程我基本不用插手。它不只是生成代码，它是在你的开发环境里实际干活。
主流 Agentic Coding 工具对比
2026 年的工具格局大概是这样。我每个都用过一阵子，说说真实感受：
Claude Code — Anthropic 出品，终端里的 Agent。这是我用得最多的。优势是推理能力强，处理复杂重构和大项目特别稳。支持超过 100 万 token 的上下文窗口，意味着它能"看到"更多代码。用 CLAUDE.md 管理项目上下文。缺点是没有 GUI，全靠终端操作，对新手不太友好。另外它是 Electron 应用，有点重。适合喜欢终端工作流、追求控制力的开发者。
Cursor — 基于 VS Code 的 AI 编辑器。好处是 IDE 集成做得好，写代码的体验流畅。它的 Composer 功能可以做多文件 Agent 任务。支持多个模型后端（Claude、GPT 等），可以按需切换。据说 ARR 已经接近 20 亿美元了，用户量很大。缺点是有时候 Agent 模式响应慢，大项目里上下文管理偶尔出问题。适合喜欢 IDE、不想折腾终端的开发者。
GitHub Copilot Agent Mode — GitHub 的方案，最大优势是跟 GitHub 生态深度绑定。可以直接从 issue 生成 PR，跑 CI，做 review。支持 VS Code 和 JetBrains。适合已经在用 GitHub 的团队。缺点是 Agent 能力相比 Claude Code 和 Cursor 还是差一截，特别是复杂任务。
OpenAI Codex — 云端 Agent，用 GPT-5 模型。特点是支持多 Agent 并行（用 worktree 隔离），基于 AGENTS.md 文件管理上下文。适合需要并行处理多个任务的场景。缺点是主要在云端运行，对本地文件系统的访问有限。
Devin — Cognition Labs 出品，自主性最高的一个。从规划到编码到测试到部署，全流程自动化。Goldman Sachs 在用它做企业级迁移。但价格不便宜，适合企业级用户。
其他值得关注的： Gemini CLI（Google 出品，免费额度大，上下文窗口大）、Windsurf（大代码库优化）、Cline（开源，可定制）、Aider（终端配对编程，Git 集成好）。
选工具的核心标准其实就两个：你习惯什么工作环境（终端 vs IDE）和你需要什么级别的自主性（辅助 vs 全自动）。没有最好的工具，只有最适合你的。
Spec-Driven Development：最重要的新技能
用了一段时间 agentic coding 之后，我发现一个规律：Agent 的输出质量，90% 取决于你给它的 spec 质量。
你给它一句话的需求，它就给你一坨能跑但质量堪忧的代码。你给它一个详细的 spec——包括功能需求、技术约束、接口定义、测试要求——它就能给你生产级的代码。
这个模式有个名字，叫 Spec-Driven Development（规格驱动开发）。
一个 spec 大概长这样：
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
| 17 | |
| 18 | |
有了这个 spec，Agent 就能自主干活了。没有这个 spec，你得全程盯着它，随时纠正方向。
我发现花 10 分钟写 spec，能省 1 小时的返工。这笔账怎么算都划算。
写 spec 有几个技巧：
- 说清楚"做什么"，不用说"怎么做"。 Agent 很擅长自己找实现路径。你告诉它目标就行，不用手把手教它写代码。
- 写清楚约束和边界。 什么不能改、什么必须兼容、性能要求是什么——这些得写清楚。
- 写验收标准。 怎么算做完了？跑通什么测试？达到什么效果？有明确的验收标准，Agent 才知道什么时候可以停下来。
- 保持 spec 更新。 别把 spec 当一次性文档。每次改了代码，回头更新 spec。这样 spec 永远是活的。
10 条实战经验
用了一段时间 agentic coding，踩了不少坑，也总结了一些好用的技巧。这些经验来自我自己的实践，也来自 Simon Willison、Armin Ronacher 等大佬的分享。
1. 先写 spec 再让 Agent 动手。 别上来就说"帮我加个功能"。你给的信息越模糊，Agent 越容易跑偏。花 10 分钟写清楚需求，能省 1 小时返工。
2. 测试是你的安全网。 Agent 改代码的速度很快，但改对了没有？没有测试你根本不知道。投入时间写端到端测试，这笔投资绝对值得。有个大佬说得好：测试记录的是"做什么"，代码记录的是"怎么做"——测试比代码更持久，因为实现可以换，行为不应该变。
3. 保留"为什么"。 代码记录了"怎么做"，测试记录了"做什么"，但只有文档记录了"为什么"。写清楚你的设计意图——为什么选这个方案而不是那个？为什么有这个约束？下次 Agent（或你自己）才能做出一致的决策。
4. Spec 要跟着代码一起更新。 别把 spec 当一次性文档。每次改了代码，回头更新 spec。这样 spec 永远是活的，Agent 每次都能拿到准确的信息。Spec 过期比没有 spec 更危险——Agent 会按照过期的 spec 干活，产出跟当前代码不一致的东西。
5. 找到真正难的部分。 简单的 CRUD、配置文件、模板代码，这些 Agent 搞得又快又好。但性能优化、安全审计、系统架构——这些才是真正需要你花时间的地方。别被 Agent 的效率迷惑了，把省下来的时间花在刀刃上。有句话说得好：任何人都能 vibe 出简单的部分，难的部分才是价值所在。
6. 速度很重要。 Agent 迭代的速度取决于反馈的速度。编译快、测试快、工具响应快，Agent 就干得快。如果你的项目 build 一次要 5 分钟，Agent 的效率会大打折扣。投入时间优化构建速度，这对 agentic coding 的效率影响巨大。
7. 别让多个 Agent 抢同一个资源。 如果你跑多个 Agent 并行工作，给它们各自独立的状态（不同的目录、不同的数据库），别让它们互相打架。用 Git worktree 给每个 Agent 一个独立的工作空间，改完了再合并。
8. 培养你的品味。 Agent 生成代码很快，但代码好不好？这得靠你自己的判断。你对领域、用户、技术栈理解得越深，你就越能在关键时刻做出正确的判断。品味是没法 delegate 的。
9. 经验会被放大。 有经验的开发者用 Agent 效率更高，因为你知道该问什么问题、该怎么描述需求、该怎么判断结果。Agent 放大的是你现有的能力——如果你是新手，它放大的是你犯错的速度。这不是说新手不该用，而是说你得更加小心，多验证。
10. 代码免费，但维护不免费。 Agent 生成代码很快，但这些代码谁来维护？谁来处理安全漏洞？谁来应对需求变更？生成只是开始，维护才是大头。有人把 agentic code 比喻成"免费的小狗"——领养不要钱，养起来花钱花时间。
局限性：别太乐观
说了这么多好处，也得说说问题。这些问题不是理论上的，是我实际遇到的。
Agent 还是会犯错。 特别是在复杂场景、模糊需求、或者它没见过的代码模式面前。我遇到过好几次 Agent 生成的代码"看起来对"——编译通过、测试通过、但逻辑上有 subtle bug。比如有一次它把一个应该异步执行的操作写成了同步，功能上没问题但性能差了 10 倍。如果我不仔细 review，这种问题就漏过去了。
成本不低。 这些 Agent 背后跑的是大模型，调用一次就要花钱。复杂的任务可能需要几十轮交互，费用加起来不便宜。Claude Code 用 Opus 模型跑一个大重构可能要几美元。一天下来如果高强度使用，成本可以到几十美元。小团队和个人开发者得算算账。
安全风险。 你给 Agent 终端权限、文件系统权限、甚至数据库权限。如果 Agent 被 prompt injection 攻击了怎么办？如果它执行了不该执行的命令怎么办？这不是理论问题，是实际风险。至少要在沙箱环境里跑 Agent，别直接给它生产环境的权限。
人类审查仍然必需。 根据不同任务的复杂度，80-100% 的 Agent 输出仍然需要人类审查。Agent 不是万能的，至少现在还不是。别因为 Agent 生成代码快就跳过 review，这跟不写测试一样危险。
对开发者技能的要求变了。 不是降低了，是变了。以前你需要精通语法和框架。现在你需要：会写 spec、会做架构设计、会判断代码质量、会管理 Agent 工作流。写代码的技能可能在贬值，但工程判断力更值钱了。
CLAUDE.md 和 AGENTS.md：被低估的项目知识库
前面提到了持久化上下文，这里展开说说，因为这个模式真的太好用了。
核心思路很简单：把项目知识写成文件，让 Agent 每次启动时自动读取。
以 Claude Code 的 CLAUDE.md 为例，你可以在这个文件里写：
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | |
| 12 | |
| 13 | |
| 14 | |
| 15 | |
| 16 | |
| 17 | |
| 18 | |
| 19 | |
有了这个文件，Agent 启动的时候就知道：这个项目用什么技术栈、什么命名规范、怎么跑测试。不用你每次都说一遍。
OpenAI Codex 用 AGENTS.md 做同样的事。Hermes Agent 的 memory 系统类似，只是存在数据库里。效果一样——跨 session 的项目知识持久化。
这个模式看起来简单，但对效率的影响巨大。没有它的时候，Agent 每次都从零开始理解你的项目，浪费大量 token 在"认识项目"上。有了它，Agent 直接带着背景知识干活，从第一轮交互就能产出有意义的代码。
我的建议是：每个项目都建一个这样的文件。 花 10 分钟写好，后面每次用 Agent 都能省时间。而且这个文件本身也是很好的项目文档——新加入的开发者看了也能快速了解项目。
怎么开始
如果你也想试试 agentic coding，我的建议：
从一个你熟悉的小项目开始。 别上来就拿公司的核心项目练手。找个 side project，用 Agent 从头搭一遍，感受一下工作流。熟悉了再逐步用到更重要的项目上。
选一个工具深入用。 别同时学五个工具。选一个（推荐 Claude Code 或 Cursor），把它用熟了再考虑其他的。工具之间的差异没有你想象的那么大，核心工作流是类似的。
先学会写好 spec。 这是 agentic coding 最核心的技能。你的 spec 写得好，Agent 的输出就好。你的 spec 写得烂，Agent 再强也没用。练习的方式很简单：每次让 Agent 干活之前，先花 10 分钟把需求写成文字。
投资测试。 再说一遍，测试是你的安全网。没有测试的 agentic coding 就是在裸奔。先写测试，再让 Agent 写代码——Agent 能跑通你的测试，你才能信它的代码。
保持学习。 这个领域变化太快了。上个月的最佳实践这个月可能就过时了。关注几个靠谱的信息源，保持更新。Anthropic 的官方报告、Simon Willison 的博客、Hacker News 上的讨论——这些都值得看。
后面的打算
最近在研究多 Agent 协作的工作流，想试试用 Hermes Agent 的子任务功能搭一套完整的开发流水线：规划、编码、测试、部署全自动。等搞出来了再写篇文章分享。
另外 Anthropic 刚发布了 2026 Agentic Coding 趋势报告，里面提到了 8 个关键趋势。我打算仔细读一遍，结合自己的经验写个解读。
有啥问题评论区聊。如果你也在用 agentic coding，欢迎分享你的经验——踩了什么坑、发现了什么好用的技巧、或者有什么困惑，都可以说说。
补充：Agentic Coding 不会让你失业，但会改变你的工作
最后聊个大家可能关心的问题：agentic coding 会不会让程序员失业？
我的看法是：不会，但会改变你的工作内容。
Agent 能替代的是那些重复性的、模式化的编码工作——CRUD、配置文件、模板代码、简单 bug 修复。这些东西以前占了开发者大量时间，现在 Agent 几分钟就搞定了。
但 Agent 替代不了的是：理解需求、设计架构、做技术决策、判断代码质量、处理复杂的业务逻辑。这些需要人类的工程判断力和领域知识。
所以 agentic coding 时代的开发者，更像是一个"技术经理"——你管理的不是人，是 AI Agent。你的核心价值不再是"我能写多少行代码"，而是"我能做出多好的技术决策"。
对于新手来说，这意味着一个挑战：你不能跳过学习基础的过程。如果你不理解代码是怎么工作的，你就没法判断 Agent 的输出对不对。Agent 放大的是你现有的能力——如果你什么都不懂，它放大你的无知。
对于有经验的开发者来说，这是个好消息。你的经验和判断力现在能产生 10 倍的价值，因为 Agent 帮你把执行的时间压缩了。
不管你怎么看这个趋势，它已经在发生了。与其抗拒，不如先试试。