AI Agent 为什么经常把简单问题搞复杂？

从任务拆解、工具调用到“过度自动化”，看看 Agent 到底哪里容易出问题

这两年写代码的人应该都有类似经历。

给 AI 一个简单任务：

“把这个接口增加一个字段。”

结果它开始：

• 分析整个项目；

• 搜索几十个文件；

• 修改 DTO；

• 修改 Service；

• 修改数据库；

• 修改前端；

• 顺手重构一个工具类；

• 最后告诉你：“已经完成”。

你打开 Git Diff 一看：

本来改 20 行就能解决的问题，最后改了 300 多行。

更麻烦的是，其中还可能混进一些你根本没要求的修改。

这就是 Agent 很典型的问题：

它很擅长执行任务，但不一定擅长判断“这个任务到底需要做到什么程度”。

Agent 的问题很多时候不是能力不够，而是自主性和边界没有控制好。

一、为什么 Agent 会把简单问题复杂化？

先看一个很简单的需求：

用户列表增加“手机号”字段。

正常情况下可能只需要：

UserVO
↓
SQL
↓
返回字段

但 Agent 可能会进一步判断：

增加手机号
↓
需要修改用户实体
↓
需要增加数据库字段
↓
需要增加手机号校验
↓
需要增加脱敏
↓
需要修改缓存
↓
需要修改接口文档
↓
需要增加测试
↓
需要修改前端

这些事情有些可能确实合理。

问题是：

你只是让它增加一个返回字段。

Agent 却自己扩大了需求范围。

这就是第一个问题：

任务边界膨胀

二、Agent 有一个天然倾向：把“完成任务”理解成“把所有相关问题都解决”

普通聊天模型更多是在回答问题。

Agent 不一样。

它会尝试完成目标。

比如：

目标：

修复订单查询接口报错。

Agent 可能认为：

发现空指针
↓
修复空指针
↓
发现异常处理不规范
↓
顺便统一异常
↓
发现代码重复
↓
顺便重构
↓
发现SQL可以优化
↓
顺便优化SQL

最后：

一个 Bug 变成了一次小型重构。

这其实非常符合 Agent 的行为逻辑。

因为从它的角度：

“我发现了问题，为什么不一起解决？”

但从开发人员的角度：

“我只让你修这个 Bug。”

这两个目标完全不同。

三、最危险的不是“改多了”，而是“改对了一部分”

如果 Agent 改了一堆明显错误的代码，反而容易发现。

真正麻烦的是：

它改的东西看起来全部合理。

例如：

原来的：

if (user == null) {
return null;
}

Agent 觉得：

if (user == null) {
throw new BusinessException("用户不存在");
}

从代码规范来看：

可能更合理。

但是其他调用方可能依赖：

null

作为业务判断条件。

于是：

局部优化
↓
改变原有行为
↓
其他模块出现问题

这就是大型项目最麻烦的地方：

代码之间存在大量隐性依赖。

四、Agent 最大的问题之一：过度推断

比如你说：

“这个接口性能有点慢，帮我优化。”

一个普通开发人员通常会先问：

慢在哪里？

Agent 则可能直接开始：

查代码
↓
看SQL
↓
增加缓存
↓
修改SQL
↓
增加索引

问题来了。

你甚至还没确定瓶颈在哪里。

这就是：

没有证据就开始优化

软件性能优化最忌讳这一点。

正确方式应该是：

发现慢
↓
测量
↓
定位
↓
确认瓶颈
↓
提出方案
↓
修改
↓
验证

而不是：

感觉慢
↓
开始优化

Agent 特别容易陷入后者。

五、工具越多，Agent 不一定越好

现在很多开发环境可以给 Agent 接：

Git
MySQL
Docker
文件系统
浏览器
终端
日志
CI/CD

看起来能力越来越强。

但工具数量增加之后，也会出现一个问题：

Agent 开始有太多事情可以做。

比如：

一个接口报错

它可以：

搜索代码
查Git
查数据库
查日志
查Docker
查配置
运行测试

如果没有明确的策略：

它可能全部调用一遍。

最后：

问题：
一个参数为空。

Agent：
执行了20个工具调用。

这就属于典型的：

工具过度调用。

六、工具调用本身也会产生噪声

假设 Agent 第一次搜索：

UserService

得到：

UserService.java
UserServiceImpl.java
UserServiceTest.java
UserServiceOld.java
UserServiceBackup.java

它继续全部读取。

然后又发现：

UserUtils
UserHelper
UserManager
UserFacade

再继续搜索。

很快上下文就变成：

真正相关代码
+
历史代码
+
测试代码
+
工具类
+
废弃代码

信息越来越多。

但有效信息比例越来越低。

这和前面讲的 Context Engineering 是直接相关的。

Agent 的工具调用能力越强，对上下文管理的要求反而越高。

七、Agent 还有一个很典型的问题：自己验证自己

这是开发中非常值得注意的一点。

Agent：

写代码
↓
运行测试
↓
测试通过
↓
告诉你完成

看起来没有问题。

但是：

测试通过不等于代码正确。

例如原来只有：

正常登录

Agent 增加了：

验证码

测试：

正常登录 → PASS

但是没有测试：

验证码错误
验证码过期
验证码为空
重复提交
并发登录

于是：

测试通过
≠
功能正确

如果测试用例本身不完整，Agent 可能只是证明：

自己写的代码通过了自己设计的测试。

八、所以 Agent 真正需要的是“刹车系统”

很多人研究 Agent，关注的是：

怎么让它拥有更多工具？

实际上还应该关注：

怎么让它知道什么时候停下来？

一个比较成熟的 Agent 流程应该是：

任务
↓
理解
↓
拆解
↓
判断影响范围
↓
执行
↓
验证
↓
停止

而不是：

任务
↓
执行
↓
发现问题
↓
继续执行
↓
发现新问题
↓
继续执行
↓
无限扩张

九、怎么限制 Agent 不要乱改？

第一条：明确修改范围

不要说：

“优化用户模块。”

最好说：

只允许修改：

UserService
UserMapper
UserVO

禁止：

修改数据库结构
修改公共模块
修改其他业务模块

边界越清晰，结果越稳定。

十、第二条：先分析，后执行

这是我比较推荐的一种方式。

第一阶段：

分析问题。

不要修改代码。

告诉我：

1. 问题原因
2. 影响范围
3. 修改文件
4. 修改方案
5. 潜在风险

等方案确认后：

按照确认方案进行修改。

这样可以避免：

Agent 一上来就动手。

十一、第三条：限制每次任务的目标

不要一次让 Agent：

重构整个订单系统。

可以拆成：

任务1：

分析订单查询性能。

然后：

任务2：

优化SQL。

再：

任务3：

补充测试。

这样虽然看起来步骤增加了。

实际上：

总成本往往更低。

因为减少了错误修改和返工。

十二、第四条：让 Agent 输出 Diff，而不是直接修改

对于重要模块，可以要求：

先给出修改方案和Diff。

不要直接写入文件。

这样开发人员可以先看：

– 原代码
+ 新代码

确认之后再执行。

这个方式特别适合：

• 核心业务；

• 数据库代码；

• 支付；

• 权限；

• 公共组件。

十三、第五条：给 Agent 设置“停止条件”

这一点很多人没有注意。

例如：

如果无法确认问题原因：

停止。

如果需要修改数据库：

停止并询问。

如果需要修改公共模块：

停止并询问。

如果需要修改超过5个文件：

先说明原因。

这其实就是：

给 Agent 设置工程边界。

十四、Agent 不应该拥有无限权限

比较合理的权限设计：

开发阶段

读取代码 √
修改业务代码 √
运行测试 √
查看Git √

数据库

查询 √
修改结构 ×
删除数据 ×

生产环境

读取日志 √
查询状态 √
修改代码 ×
修改数据库 ×
重启服务 ×

这就是：

最小权限原则。

Agent 能力越强，权限控制越重要。

十五、真正靠谱的 Agent，不是“完全自主”

很多人想象中的 Agent：

给我需求
↓
自己开发
↓
自己测试
↓
自己部署
↓
上线

这种模式看起来很先进。

但真实项目里风险非常高。

更现实的方式：

需求
↓
Agent分析
↓
人确认
↓
Agent开发
↓
自动测试
↓
Agent Review
↓
人确认
↓
部署

也就是：

Human in the Loop

人在关键节点做决策。

Agent 负责执行大量机械工作。

十六、Agent 最适合解决什么？

如果把开发任务分类，会发现：

非常适合

代码搜索
代码补全
CRUD
测试生成
日志分析
错误定位
Git分析
代码重构建议
文档生成

需要人工确认

架构设计
数据库核心设计
业务规则
权限设计
核心算法
技术选型
生产环境变更

不应该完全交给 Agent

生产数据库删除
生产环境直接部署
核心数据迁移
权限系统修改
支付逻辑修改

不是说 Agent 做不到。

而是：

错误成本太高。

十七、Agent 的核心能力，其实是“任务管理”

如果把 Agent 拆开看：

Agent
│
├── Planning
│ └── 任务规划
│
├── Context
│ └── 获取上下文
│
├── Tool Use
│ └── 调用工具
│
├── Execution
│ └── 执行任务
│
├── Validation
│ └── 验证结果
│
└── Memory
└── 保存状态

真正困难的并不是：

“生成代码。”

而是：

下一步应该做什么？

以及：

什么时候应该停止？

十八、这也是为什么 Agent + MCP + Coding Rule 必须放在一起看

前面几篇文章其实可以串起来。

Context Engineering

解决：

AI 应该知道什么？

Coding Rule

解决：

AI 应该遵守什么？

MCP

解决：

AI 可以使用什么工具？

Agent

解决：

AI 如何把这些东西串起来完成任务？

最终：

Context
+
Coding Rule
+
MCP
↓
Agent
↓
Task
↓
Execution
↓
Validation

这才是一套完整的工程体系。

十九、未来 Agent 真正值得发展的方向

我并不认为最终的软件开发会变成：

一个Agent
+
一句需求
=
整个软件

更可能是：

┌── Coding Agent
│
需求 → Orchestrator ├── Test Agent
│
├── Review Agent
│
└── DevOps Agent

不同 Agent 负责不同事情。

例如：

Coding Agent

负责实现代码。

Test Agent

负责测试。

Review Agent

负责检查代码。

DevOps Agent

负责构建和部署相关任务。

再由一个 Orchestrator 负责协调。

这种模式反而更符合软件工程本身的分工方式。

总结：Agent 最大的问题不是“不够聪明”

很多人使用 Agent 后发现：

它为什么总喜欢把简单问题搞复杂？

答案其实比较简单。

因为 Agent 的目标是：

完成任务。

但软件工程真正需要的是：

在正确的范围内完成任务。

两者差别很大。

一个好的 Agent 不应该：

看到什么改什么

而应该：

理解任务
↓
确定边界
↓
获取必要信息
↓
选择工具
↓
执行最小修改
↓
验证结果
↓
停止

所以，Agent 工程真正需要解决的并不是：

怎么让 Agent 更自主？

而是：

怎么让 Agent 在拥有足够自主性的同时，仍然保持边界、可控和可验证。

这可能才是 Agent 真正进入软件研发之后，最值得研究的问题。

代码生成只是第一步。

真正困难的，是让一个能够自主行动的系统，学会：

什么时候做、做什么、做到什么程度，以及什么时候停。