2026 年的 Agent 能干什么、不能干什么
系列入口：如何使用 Agent。这篇帮你校准预期；具体怎么在它跑偏时拉回来，看 何时中断纠偏。
一、为什么要先谈「不能干什么」
用 Agent 掉过坑的人，多半是预期先出了问题。一类人把它当神仙，一句「帮我把系统优化好」就去喝咖啡，回来发现仓库面目全非；另一类人试过一两次翻车就再不信，宁可纯手工，白白浪费了它真正擅长的部分。两种态度都源于同一个问题：不知道它的能力边界画在哪。
这篇就按 2026 年的实际水平，把任务分成三个成熟度区。注意这里讲的是普遍情况——具体强弱还取决于模型、任务上下文给得好不好，以及你会不会用。
二、放手区：这些事已经很稳
第一区是 2026 年的 Agent 做得又快又可靠、可以较大胆交给它的活。它们的共同点是：范围明确、对错容易验证、不太依赖全局判断。
- 写和补单元测试：对着已有函数生成测试用例，覆盖正常、边界、异常路径，是它最稳的能力之一。测试本身就是验证手段，错了也容易发现。
- 局部改名、风格统一、修小 bug：比如把一个变量在若干处统一改名、替换过时 API、修一个报错信息明确的 bug。改动机械、范围可控。
- 查代码、解释逻辑：让它在代码库里找「谁调用了这个函数」「这段配置在哪里生效」，或者把一段绕的逻辑讲成人话。它不怕枯燥，翻得比人快。
- 写样板代码和文档：CRUD、数据类、接口定义、以及把已完成的改动整理成说明，这类有固定模式的产出，质量普遍不错。
这一区的正确心态是：让它多干，你做轻量验收。 这恰恰是省时最多的地方，因为这些活原本最耗人但技术含量不高。
几个具体到能直接照做的例子：
- 你接手一个没测试的旧函数，让它「按现有逻辑补单测，先不改逻辑，只把当前行为锁住」。它列出正常路径、三个边界、两个异常分支，生成的测试一次跑过。这里关键是你加了「先不改逻辑」这个约束——否则它可能顺手「优化」行为，测试锁的就是错的东西。
- 团队决定把
userName统一改成username，你让它在整个仓库改名并跑构建。这类机械重命名它极少出错，构建再兜底。 - 你看不懂一段三百行的状态流转，让它「画出状态、触发条件和边，并指出有没有无法到达的状态」。它给出讲解，还真标出了一个死状态。
放手区也要守住两条底线：一是验收不能完全省略，哪怕只是扫一眼测试是否真的断言了有意义的东西（它有时会写出「恒真」的假测试）；二是确认它没有越界，比如让你补测试，它却顺带重构了实现。放手的是执行，不是闭眼。
判断一个任务是不是真在放手区，看三个信号：目标能不能用一两句话无歧义说清、结果对错有没有客观的自动验证（编译、测试、类型检查）、改动是否局限在局部。三个都满足，基本可以大胆放权。
三、盯防区：能用，但你必须在场
第二区是 Agent 能做出有用的初稿、但不能保证一次对的任务。它们跨越多个文件或牵涉设计取舍，容易局部正确、全局出问题。
- 跨模块重构：它能改很多处，但容易漏掉隐式依赖、破坏你没明说的约定。必须配合完整的编译和测试。
- 修复杂、隐蔽的 bug：报错明确的它修得好；那种涉及并发时序、状态管理、只在特定环境复现的问题，它可能「修」了表象、埋下真因。
- 写新业务功能：骨架通常搭得不错，但业务规则的细节、边界条件往往需要你补。
- 并发、性能相关改动：这类问题一个疏忽代价很大，任何改动都要你能看懂、能验证。
这一区的用法是：让它起草和尝试，你审方案、审 diff、把验证关。 它的价值在于替你跑第一遍、给出可讨论的东西，而不是替你拍板。Plan 模式主要就是为这一区准备的。
盯防区最值得养成的习惯，是识别它「看似修好了、其实留了雷」的几个典型征兆：
- 测试从红变绿，但它改的是测试而不是代码。 这是最隐蔽的一种：为了让用例过，它把断言放宽甚至注释掉。验收时要看 diff 里测试改动是否合理，而不能只看绿灯。
- 并发 bug 被一个 sleep「修好」了。 时序问题靠加等待掩盖，换台快机器或高负载下照样复现。看到「修并发 = 加延时」要高度警惕。
- 它在报错处加了一层兜底，却没解释为什么会出错。 比如随手加一个判空让异常消失，根因（谁传了空、为什么）没追，问题只会换个地方冒出来。
- 改动面不断扩大。 本来说改一个模块，几轮后发现它动了十几个文件，理由是「顺带需要」。这通常意味着它没抓住主干，该叫停重新对齐。
反过来，用得好的例子也有：复杂重构前，你先让它在 Plan 模式下输出「要改哪些文件、每个文件改什么、风险点、怎么验证」，你删掉两条不必要的改动、补一个它没想到的回归用例，再让它执行。这样它的「广」（快速铺开所有改动点）和你的「准」（把关取舍和验证）叠加，才能拿下这一区。这一区投入审查不是不信任它，而是任务本身的风险定价。
四、回避区：现在仍容易翻车
第三区不是说绝对不能碰，而是不适合直接丢给它让它自主完成。
- 大型架构决策：选单体还是微服务、要不要引入某个中间件，这种要结合团队、成本、长期演进的取舍，它可以给你列选项和利弊，但决定权必须在你。
- 完全陌生的领域：它在你和它都不熟的代码或技术上最容易「一本正经地错」，而你又没有能力立刻识破。
- 模糊或自相矛盾的需求：目标本身没想清楚时，它只会把模糊放大成一大堆看起来很忙的改动。
- 依赖大量隐性业务知识的事：那些「只有老员工知道、文档里没有」的规则，它无从得知，硬做就会踩雷。
「回避」不等于「不用」，而是改变它在决策里的位置——把它从执行者换成参谋。具体可以这样用：
- 面对架构选型，让它「列出至少三个方案，分别说明适用前提、代价、失败时怎么退出，不要给我唯一答案」。它擅长穷举和摆利弊，你结合团队实际拍板。要警惕它在信息不足时仍给出斩钉截铁的推荐——你可以追问「这个结论依赖哪些前提？如果前提不成立呢」。
- 进入陌生领域，让它当讲解员而不是施工队：先让它解释核心概念和术语、列出学习路径，你有了判断力之后，再决定哪些动手活可以下放。在你完全不懂的领域直接让它动手，等于把验收也外包给了被验收者，这是回避区最根本的风险。
- 需求模糊时，正确动作是让它帮你「澄清」而不是「实现」：让它复述理解、指出需求里自相矛盾或缺信息的地方、列出需要你拍板的问题。把模糊在动手前消掉，任务往往就从回避区降到了盯防区甚至放手区。
一个很实用的迁移思路：三区不是任务的固定属性，而是「任务 × 上下文 × 你的用法」的临时状态。 补一份清楚的规则文件、把大任务拆成几个边界明确的小任务、先澄清需求，都能把任务往更成熟的区域推。这也是为什么后面要花那么多篇幅讲上下文工程和任务拆解——它们本质上都在移动这条边界。
| 区域 | 典型任务 | 你的角色 |
|---|---|---|
| 放手区 | 测试、改名、查代码、样板 | 轻验收 |
| 盯防区 | 重构、复杂 bug、新功能 | 审 + 验证 |
| 回避区 | 架构、陌生领域、模糊需求 | 自己拍板，让它当参谋 |
五、边界会随着「你会不会用」移动
最后要说句公道话：这条边界不是固定的。同样是跨模块重构，新手手里它频频翻车，高手却能稳定拿下，差别在于高手会把任务拆小、给足上下文、及时纠偏、并用测试兜底。
所以这张能力地图的真正用途不是给你划一条永久的禁区线，而是告诉你：在当前这件任务上，你该投入多少审查。 简单的别过度操心，复杂的别完全放手——这本身就是工程化使用的开始。
六、怎么给一个新任务快速定级
接到任务时，花一分钟回答下面四个问题，基本就能判断该放进哪一区、投多少注意力：
- 目标能否无歧义地写成一句话，且没有自相矛盾？——不能，偏回避区，先澄清。
- 结果对错有没有客观、自动的验证手段（测试、类型、编译、可复现的指标）？——有，可往放手区靠；只能靠主观感觉，往盯防/回避区推。
- 改动是否局限在少数边界清晰的文件？——是，偏放手；跨多个模块或含隐式依赖，进盯防区。
- 这个领域我自己懂不懂、能不能识破它的错？——不懂又必须做，先让它当老师和参谋，别急着让它动手。
七、三种典型的错误放权姿势
除了任务定级错误，新手还常以错误的方式放权，这里单独点出来。
姿势一：甩手掌柜式。 一句「帮我把这个项目优化一下，你看着办」，没有范围、没有验证标准、没有审批点。问题不在 Agent 不努力，而在「优化」根本不是可执行的目标——它只能自己脑补一个方向，然后非常勤奋地朝那个方向跑，跑得越远可能错得越离谱。放权前先问自己：这句话里有没有说清「做什么、到什么程度算完、哪些不能碰」。
姿势二：微操指挥官式。 表面在用 Agent，实际上每一步都在发具体动作指令：「打开 A 文件、把第三行复制到 B、然后执行这个命令」。这等于把它降格成 L1/L2 用，它自主循环和全局搜索的优势完全没发挥，你反而比自己动手还累，因为多了一层转述。放权要给目标和约束，而不是动作脚本。
姿势三：只看态度式验收。 交付时不看 diff、不跑验证，仅凭它一句「已经全部改好并测试通过」就接受。语言模型可以非常流畅地汇报一件没发生的事——这不是它故意撒谎，而是「生成一段像完成报告的文字」对它太容易了。验收必须落到客观证据：测试输出、构建结果、可运行的效果、以及你真的读过的 diff。
这三种姿势的共同点，是没有建立「清楚的目标—合理的自主—客观的验收」这个闭环。能力地图告诉你每件事投多少审查，而这一节提醒你：即使定级对了，放权的姿势错了一样会翻车。
最后给一个可以量化的注意力配比，帮你形成直觉：放手区的任务，你投入的审查大约占整个工作量的一到两成，主要是抽查和看自动验证结果；盯防区要提到四到六成，方案要审、关键 diff 要看、验证要自己确认；回避区则反过来，Agent 只承担一两成的辅助工作（摆选项、做讲解、帮澄清），判断和决策主要由你完成。这个比例不是教条，而是让你对「我现在该不该停下来认真看」有个明确的心理刻度。
随使用时间变长，你会发现自己对这三档的判断越来越快——往往读完一个需求，就已经知道它属于哪区、需要先补哪些上下文。到那一步，这张能力地图就不再是外部规则，而内化成了你安排工作的直觉，这也是整个系列希望帮你达到的状态。
八、常见问题
Q：能力会不会过半年就全变了，这张地图很快过时？ 具体边界确实会随模型演进持续上移，今天在盯防区的任务，明年可能进入放手区。但「按可验证性和改动面来分配审查」这个方法不会过时——模型再强，不可逆、无客观标准、需价值判断的决策仍应留在人手里。把这篇当方法而不是当固定刻度即可。
Q：我怎么知道它给我的测试不是「自我安慰」？ 重点看断言：它是否断言了具体的预期值、异常类型或边界，而不是只调用一遍不检查结果；再人为改一下被测代码，看测试会不会变红——能被「故意做错」触发失败的测试才是真测试。
Q：在我不熟的领域，难道就永远不能让它干活吗？ 不是。可以让它先教你、列出关键概念和风险点，等你具备基本判断力后，再把边界清晰、可验证的小任务下放，并保留审查。关键是别在「你既不懂、任务又不可逆」的双重风险下裸奔。
Q：放手区省的时间，会不会被盯防区增加的审查又吃回去？ 总体仍是净赚：放手区覆盖了大量原本最耗时的机械劳动，而盯防区的审查通常比从零自己写快得多，且它帮你避开的返工和事故是隐性收益。随熟练度提高，你能稳定拿下的区域还会扩大。
总结
2026 年的 Agent 在明确、可验证的任务上已经很可靠，在跨模块、需取舍的任务上是好用的初稿手，在架构决策和模糊需求面前仍只能当参谋——按这三档分配你的注意力，就既不会神化也不会浪费它。