在AI编程实践中，有一条基本共识想必许多开发者都已心领神会：适合Agent处理的，交给Agent；不适合Agent的，亲自上手。道理看似简单，但在实际工作中，识别哪些任务不应该交给Agent，往往比知道能用它做什么更为关键。毕竟，一旦把任务派错了对象，效率不但不会提升，反而可能下降。

坦白说，随着Agent编程能力爆发，它能胜任的工作越来越多。但真正有价值的思考方向恰恰是：哪些工作不该让它参与？以下几个典型场景，建议你务必亲力亲为。

Agent不适宜承担的任务类型

一、超大体量 / 超长上下文项目

Agent对上下文窗口极为敏感。当单个文件达到数万行，整个项目包含几十万行代码时——光是打开就卡顿，索引缓慢、内存飙升、延迟明显。更关键的是，模型的上下文窗口存在上限，一旦超出范围，逻辑就会断裂，甚至出现前后矛盾。大型遗留系统、巨型单体应用、超长配置文件，均不适合Agent介入。

二、深度架构设计与复杂系统重构

Agent善于局部精细操作，但缺乏全局视野。让它承担架构设计任务，容易陷入局部最优，整体结构反而混乱。至于大型重构，比如微服务拆分、架构迁移，Agent极有可能破坏依赖关系，引入隐蔽的缺陷。归根结底，它生成的代码风格偏向“Demo化”，中大型项目所需的规范与结构，它往往难以兼顾。核心架构设计、大规模重构、复杂分布式系统，建议回归人工主导。

三、强视觉 / 多模态前端精细化调试

Agent无法真正“看懂”页面效果、截图或设计稿，只能通过文字描述来揣摩。CSS像素级对齐、响应式细节、复杂动画调试——这些工作交给Agent，效率极低，反复试错后依然需要你来收尾。UI像素还原、复杂交互视觉调试、高精度设计稿转码，Agent确实力不从心。

四、高性能 / 底层与极致优化场景

底层内核、驱动、嵌入式开发，依赖对硬件细节、内存布局、时序的深入理解，而Agent恰恰欠缺这些。极致性能优化，比如高频算法、内存池、锁优化，Agent生成的代码往往低效，边界条件也容易遗漏。操作系统内核、驱动、嵌入式、高频交易、极致性能算法，这些领域Agent只能作为旁观者。

五、严格安全 / 合规与高风险系统

金融、医疗、支付、加密等强合规场景，容不得半点闪失。Agent容易引入安全漏洞，例如SQL注入、权限绕过。隐私数据处理更是雷区，模型可能无意中泄露敏感逻辑或数据。金融核心、医疗系统、支付网关、加密模块、隐私敏感服务，必须由人工主导，配合严格审计。

六、存量复杂代码的无监督改造

老项目、祖传代码、缺乏文档的遗留系统，Agent理解起来非常吃力，改错风险极高。没有人工审核的大规模自动修改，如同走钢丝——出了问题，回滚都困难。无文档遗留系统、高风险自动重构、核心业务逻辑的无监督修改，这些工作最好别交给Agent。

七、过度工程化与简单问题复杂化

Agent存在一种倾向：喜欢用复杂方案解决简单问题。滥用设计模式、装饰器、函数式语法糖，它玩得很熟练。但面对简单脚本、工具类，它反而可能写出冗余、难维护的代码。极简工具、一次性脚本、简单业务逻辑，追求的是轻量易维护，Agent往往帮倒忙。

八、离线 / 弱网与私有闭源依赖场景

离线模式下，Agent的能力大幅缩水，复杂生成和调试几乎不可用。内部私有框架、闭源SDK、自研库，Agent生成代码的准确率很低，还容易编造虚假代码。纯离线开发、重度依赖内部私有技术栈的项目，Agent基本派不上用场。

Agent 使用避坑指南

一、绝对不推荐使用

二、谨慎使用（需人工全程把控）

三、优先使用Agent的场景

1. 中小型项目、业务增删改查、接口开发
2. 快速原型、Demo、新功能试错
3. 代码注释、单元测试、简单 bug 排查
4. 通用开源技术栈（Vue/React/Node 等）常规开发

总结

Agent的核心优势在于快速原型、全栈Demo、中小型项目、日常增删改查以及辅助调试。这些任务交给它，效率确实显著。但涉及超大项目、核心架构、像素级UI、底层高性能、强安全合规、无监督遗留改造、简单问题复杂化以及离线私有依赖场景，还是亲自下场更为稳妥。只有清晰界定边界，Agent才能真正成为你的效率利器，而非添乱之源。