Agentic Coding：从“让 AI 写代码”到“让 AI 完成软件工程任务”

最近看到一个新词：Agentic Coding，了解了一下。

近几年，AI 写代码已经从一个新鲜功能变成了开发者日常工作的一部分。

最开始，我们让 AI 补全一行代码；后来可以让它生成一个函数、一段 SQL，甚至生成一个完整的页面。再后来，Cursor、Claude Code、GitHub Copilot 等工具开始能够读取整个代码库、修改多个文件、执行命令和运行测试。

这时候，事情开始发生变化。

以前我们更习惯说：

「让 AI 帮我写代码。」

现在越来越接近：

「把这个开发任务交给 AI，让它自己完成。」

这就是 Agentic Coding 值得讨论的地方。

它并不是简单地把代码生成能力做得更强，而是把 AI 在软件开发中的角色从「代码助手」进一步推向「任务执行者」。

从代码补全到 Coding Agent

最早一代 AI 编程工具解决的问题其实非常明确：预测开发者接下来可能要写什么代码。

开发者输入前面的代码，AI 根据当前文件和上下文预测后面的内容。

这种模式本质上还是：

开发者
  ↓
写代码
  ↓
AI 提供建议
  ↓
开发者确认

后来，AI Coding 进入了第二个阶段。

开发者不再需要逐行告诉 AI 怎么写，而是可以直接描述一个需求：

给用户登录接口增加 Refresh Token。
Access Token 有效期 30 分钟，
Refresh Token 有效期 7 天，
并增加 Token 刷新接口。

AI 可以生成多个文件、修改已有代码，并根据项目结构调整实现。

这已经不只是代码补全，而是基于任务生成代码。

再往前一步，Coding Agent 开始拥有更多实际操作能力。

例如 Claude Code 官方将自己定义为 Agentic Coding 工具，可以读取代码库、编辑文件、执行命令，并与开发工具协同工作。GitHub Copilot 的 cloud agent 也可以研究 Repository、制定实现计划、修改分支上的代码，并创建 Pull Request。

于是开发过程逐渐变成：

开发者提出目标
       ↓
       AI
       ↓
分析代码库
       ↓
制定方案
       ↓
修改代码
       ↓
运行测试
       ↓
发现问题
       ↓
继续修改
       ↓
再次验证
       ↓
提交结果

这就是 Agentic Coding 与传统 AI Coding 最重要的区别。

Agentic Coding 到底是什么

「Agentic Coding」目前并不是一个像 HTTP、Git 那样有严格标准定义的技术协议，更适合把它理解为一种软件开发模式。

它的核心不是「AI 能不能生成代码」，而是：

AI 能否围绕一个软件工程目标，自主完成多个连续步骤，并根据执行结果不断调整自己的行为。

这里有几个非常关键的词：

目标、规划、执行、观察、反馈、验证。

例如开发者提出：

给订单系统增加退款功能。
要求：
1. 支持部分退款；
2. 不能超过原订单金额；
3. 增加退款记录；
4. 增加接口测试；
5. 保持现有接口兼容。

普通 AI Coding 可能直接给你一份代码。

Agentic Coding 更接近：

理解需求
   ↓
分析现有订单模块
   ↓
找到 Order / Payment / API / Test
   ↓
制定修改计划
   ↓
修改多个文件
   ↓
运行测试
   ↓
发现测试失败
   ↓
分析失败原因
   ↓
修改实现
   ↓
重新运行测试
   ↓
检查 Git Diff
   ↓
输出结果

所以，Agentic Coding 的核心变化不是「代码生成能力增加了多少」，而是 AI 开始参与完整的软件工程闭环。

Anthropic 发布的《2026 Agentic Coding Trends Report》也已经把工程角色变化、多 Agent 协作以及 Human-AI 协作模式等作为 Agentic Coding 的重要趋势进行讨论。

Agentic Coding 和传统 AI Coding 有什么区别

理解这个概念，最简单的方法就是比较两种工作方式。

传统 AI Coding 更像一个非常聪明的程序员助手：

整个过程中，人仍然负责组织任务和推动流程。

Agentic Coding 则更接近：

你：
“实现用户注册功能，并增加邮箱验证和测试。”

AI：
1. 查看项目结构
2. 找到 User 模型
3. 找到注册接口
4. 查看现有验证逻辑
5. 修改相关文件
6. 添加邮箱验证
7. 编写测试
8. 执行测试
9. 修复失败测试
10. 检查最终修改

两者的差别可以概括为：

对比维度	传统 AI Coding	Agentic Coding
工作单位	代码片段	软件工程任务
AI 角色	Assistant	Agent
上下文	当前代码、Prompt	Repository、任务、工具、历史状态
文件修改	通常由人控制	Agent 可以自主修改
命令执行	通常由人执行	Agent 可以执行
测试	人主动运行	Agent 可以主动运行
Debug	人主导	Agent 可以循环修复
任务连续性	较弱	较强
最终目标	生成代码	完成任务

这里有一个很重要的区别：

Agentic Coding 并不是让 AI 取代程序员写代码，而是让 AI 从“代码生成器”变成“软件工程任务执行者”。

一个 Coding Agent 是怎么工作的

如果把一个 Coding Agent 简化，可以把它理解成：

                ┌──────────────┐
                │    用户任务   │
                └──────┬───────┘
                       ↓
                ┌──────────────┐
                │     Agent    │
                └──────┬───────┘
                       ↓
                  理解当前状态
                       ↓
                    制定计划
                       ↓
                ┌──────┴───────┐
                ↓              ↓
             读取代码         调用工具
                ↓              ↓
             修改文件       执行命令
                └──────┬───────┘
                       ↓
                    获取结果
                       ↓
                  判断是否完成
                   ↙        ↘
                 否          是
                 ↓            ↓
              继续执行      输出结果

其中最重要的并不是模型本身，而是 Agent Loop。

一个典型循环可以抽象成：

Observe
   ↓
Think
   ↓
Plan
   ↓
Act
   ↓
Observe
   ↓
Think
   ↓
...

例如 Agent 修改完 PHP 代码以后运行：

php vendor/bin/phpunit

如果测试失败，Agent 得到测试输出：

Expected: 200
Actual: 500

它就可以继续分析错误、定位代码、修改实现，然后重新测试。

因此，真正让 Coding Agent 与普通代码生成模型产生区别的，并不是「它会生成代码」，而是：

它可以根据执行结果继续行动。

这也是为什么工具调用对于 Agentic Coding 非常重要。文件系统、Shell、Git、测试框架、浏览器、数据库等，都可以成为 Agent 能够使用的外部能力。

Anthropic 的 Claude Agent SDK 文档也明确将 Agent 的工具、Agent Loop 和 Context Management 作为 Claude Code 工作方式的一部分。

为什么 Coding Agent 需要工具

如果没有工具，AI 实际上只能「看」和「说」。

例如：

AI：

“我认为应该修改 UserService.php。”

但它不能真的修改文件。

有了工具之后：

AI
 │
 ├── File Read
 ├── File Write
 ├── Search
 ├── Shell
 ├── Git
 ├── Test
 └── Browser

它就可以真正参与软件开发。

例如：

用户：
修复这个订单退款 Bug，并增加测试。

Agent：
→ 搜索 refund
→ 读取 OrderService.php
→ 读取 RefundService.php
→ 读取现有测试
→ 修改代码
→ 修改测试
→ 执行 PHPUnit
→ 查看测试结果
→ 修复失败
→ 再次执行 PHPUnit
→ 查看 git diff

这里可以看到一个非常重要的变化：

代码不再是 Agent 唯一的输出。

Agent 的输出实际上是：

代码修改
+ 命令执行
+ 测试结果
+ 工具调用
+ 最终状态

这也是后面理解 MCP 的重要基础。

MCP 解决的其中一个核心问题，就是如何以标准化方式让 AI 应用连接外部工具和数据。GitHub 官方文档也将 MCP 描述为用于扩展 Copilot 能力、连接其他系统的协议。

Agentic Coding 改变的不是“写代码”，而是开发流程

如果只看代码本身，Agentic Coding 似乎没有什么特别。

最终还是：

.php
.js
.py
.go
.sql

这些文件。

真正变化的是软件开发流程中的任务分配方式。

过去：

需求
 ↓
程序员分析
 ↓
程序员设计
 ↓
程序员编码
 ↓
程序员测试
 ↓
程序员 Debug
 ↓
程序员提交

现在可以变成：

需求
 ↓
程序员定义目标和约束
 ↓
Agent 分析
 ↓
Agent 实现
 ↓
Agent 测试
 ↓
Agent Debug
 ↓
程序员 Review
 ↓
Merge

这意味着程序员的工作重心开始发生变化。

以前我们大量时间花在：

写重复代码；
查找文件；
修改机械性的代码；
编写基础测试；
查找简单 Bug；
整理配置；
执行重复命令。

而 Agent 更擅长处理这些连续、明确、有反馈机制的工作。

程序员则越来越需要关注：

需求是否正确；
架构是否合理；
技术方案是否可行；
边界条件是否完整；
数据是否安全；
权限是否正确；
测试是否覆盖关键路径；
AI 的修改是否符合项目规范。

所以一个很有意思的变化正在发生：

程序员的价值正在从“写出每一行代码”，逐渐向“定义正确的问题、设计正确的系统、验证正确的结果”移动。

这并不意味着代码能力不重要。

恰恰相反，当 AI 能够快速生成大量代码以后，判断代码是否正确会变得更加重要。

Agentic Coding 并不等于完全自动编程

这里非常容易产生一个误解：

Agentic Coding = AI 自己开发软件，程序员以后什么都不用做。

目前显然不是这样。

Coding Agent 的能力虽然已经明显超过简单的代码补全，但软件工程本身仍然存在大量需要人判断的问题。

例如：

“实现订单退款”

这句话对于人来说可能已经有一定业务含义，但对于 Agent 来说仍然存在大量未知信息：

退款是否需要审核？

部分退款怎么处理？

退款金额精度是多少？

支付失败怎么办？

退款接口是否幂等？

数据库事务怎么处理？

第三方支付超时怎么办？

重复请求怎么办？

退款成功后订单状态如何变化？

是否需要发送通知？

这些问题不是多生成几行代码就能解决的。

因此，Agentic Coding 的真正边界并不是：

AI 能不能写代码？

而是：

AI 是否拥有完成这个任务所需要的：

上下文
+
工具
+
权限
+
业务规则
+
验证机制

这也正好引出了后面几篇文章要讨论的问题。

为什么 Agent 有时候明明模型能力很强，却仍然会做错？

一个重要原因就是：

它没有获得正确的 Context。

这就是 Context Engineering 要解决的问题。

Agentic Coding 真正困难的地方

从工程角度来看，Agentic Coding 当前真正困难的并不是让模型生成更多代码，而是让整个 Agent 系统变得可靠。

至少有几个问题必须解决。

Context

Agent 必须知道：

项目结构
代码规范
架构
数据库结构
业务规则
相关历史代码
测试
当前任务

信息太少，Agent 无法正确完成任务。

信息太多，又可能造成 Context 污染、成本增加和注意力分散。

因此，如何把正确的信息在正确的时间提供给 Agent，会成为 Agent Engineering 的核心问题之一。

Tools

Agent 必须能够使用合适的工具。

例如：

读取代码
搜索代码
修改文件
执行测试
查看 Git Diff
操作 Git
查询数据库
访问 API

工具越强，Agent 能完成的事情越多，但风险也越大。

Permissions

如果 Agent 可以执行：

rm -rf

可以读取：

.env

可以访问生产数据库，可以 Push 代码，那么它的权限边界就必须认真设计。

AI 能做什么和 AI 应该被允许做什么，是两个完全不同的问题。

Verification

最后是验证。

Agent 说：

“已经修复。”

并不意味着 Bug 真的修复了。

更可靠的流程应该是：

修改
 ↓
测试
 ↓
静态分析
 ↓
Diff Review
 ↓
CI
 ↓
人工 Review
 ↓
Merge

因此，Agentic Coding 最终不会简单变成：

人 → AI → 代码

而更可能变成：

人
 ↓
目标 + 约束
 ↓
Agent
 ↓
Context + Tools
 ↓
代码修改
 ↓
自动验证
 ↓
人工 Review
 ↓
CI/CD

这才是它真正具有工程价值的地方。

从 AI Coding 到 Agentic Software Engineering

如果把整个发展过程放在一起看，会发现 Agentic Coding 并不是突然出现的。

大致可以看到这样一条路径：

代码补全
   ↓
AI 代码生成
   ↓
AI 对话编程
   ↓
AI Coding Agent
   ↓
Agentic Coding
   ↓
Agentic Software Engineering

前面的变化主要发生在「代码生成」层面。

后面的变化开始发生在「软件工程」层面。

这也是为什么 GitHub 已经把 Copilot agent 描述为可以独立执行软件开发生命周期中的任务，而不是简单的代码补全工具。

未来的开发方式很可能不是：

程序员写 1000 行代码
AI 写 0 行代码

也不是：

程序员写 0 行代码
AI 写 1000 行代码

更现实的变化是：

程序员负责：

目标
架构
约束
判断
Review
质量
最终决策

AI Agent 负责：

搜索
实现
修改
测试
Debug
重复劳动
工具调用

换句话说，AI 正在减少“写代码”在软件开发中的比重，但并没有减少“软件工程”本身的重要性。

甚至可以认为，随着 Agent 能够承担越来越多的实现工作，架构、测试、代码审查、工程规范和系统设计的重要性反而会进一步提高。

Agentic Coding 之后会发生什么

Agentic Coding 真正值得关注的地方，并不是「AI 能不能替程序员写代码」。

更重要的问题是：

当 AI 可以自主执行越来越长的软件工程任务以后，我们应该如何让它获得正确的信息、使用正确的工具，并在正确的边界内行动？

这会把我们带向几个新的问题：

Agent
  ↓
需要什么 Context？
  ↓
Context Engineering
  ↓
需要什么 Tools？
  ↓
Tool Calling
  ↓
如何连接外部系统？
  ↓
MCP
  ↓
如何让 Agent 正确使用这些工具？
  ↓
Tool Design

因此，Agentic Coding 并不是一个孤立的概念。

它更像是 AI 软件开发范式变化中的一个起点：

AI 不再只是生成代码，而开始参与完成任务；而当任务越来越复杂，Context、Tools、Memory、MCP、Verification 等工程问题就会逐渐成为核心。

这也是接下来值得继续研究的方向。

从代码补全到 Coding Agent#

Agentic Coding 到底是什么#

Agentic Coding 和传统 AI Coding 有什么区别#

一个 Coding Agent 是怎么工作的#

为什么 Coding Agent 需要工具#

Agentic Coding 改变的不是“写代码”，而是开发流程#

Agentic Coding 并不等于完全自动编程#

Agentic Coding 真正困难的地方#

Context#

Tools#

Permissions#

Verification#

从 AI Coding 到 Agentic Software Engineering#

Agentic Coding 之后会发生什么#

官方资料#