Agent 越用越翻车，怎么破局？答案藏在经典管理学里

AI Agent 越来越强了，但我发现一个很有意思的现象：同样一套工具——Claude Code、Cursor、Codex——不同的人用出来的效果天差地别。

有的人能拿到 10 倍效能提升，有的人却在跟 Agent 来回拉扯，改了又改，烧了一堆 token，最后回头一看，还不如自己手写。

说实话，我自己也踩过这个坑。

后来我慢慢意识到，问题不在工具，在我自己。

这个时代，人的角色已经从"执行者"变成了"管理者"。

你不再是那个一行行写代码的人了，你是那个指挥 Agent 干活、审查产出、把控方向的人。但可惜的是，大部分人——包括曾经的我——根本不知道怎么"管"Agent。

没有人教过我们这个。

有一天我在翻书架的时候突然想到：管 Agent 这件事，不就是管理吗？管理学研究了一百多年的东西——怎么委托、怎么监督、什么时候该出手、什么时候该放手——这些智慧难道不能直接搬过来用？

于是我去翻了一些经典的管理学著作。Andy Grove 的《格鲁夫给经理人的第一课》、Goldratt 的《目标》、Brooks 的《人月神话》... 说实话，这些大部头我也不推荐你一本本硬啃，里面很多内容——比如人的动机、激励、组织政治——跟 Agent 管理确实不太搭。

但这些著作背后蕴藏的一些管理学思想，对当下的 Agent 管理仍然非常受用，甚至是解决我们用不好 Agent 的一剂良药。

接下来，我把这些著作里面对 Agent 管理最受用的部分拆解出来，结合我过去大量的 Agent 使用经验，把背后的心法和技巧全部分享给你。

公众号后台回复 "agent" 可获取我原创的 Agent 管理学秘籍，可直接线上访问。

温馨提示：内容比以往的文章都要长，记得先点赞收藏，也欢迎转发给需要的朋友，这篇文章绝对值得你二刷、反复品味。

一、不同的任务，管法完全不同

Agent 管理没有银弹。

这是我踩了无数坑之后得出的第一个结论。很多人用 Agent 的方式就是一刀切——不管什么任务，都扔给它一个 prompt，然后等结果。简单任务还好，复杂任务就翻车了。

Andy Grove 在《High Output Management》里提了一个概念，叫TRM——Task-Relevant Maturity，任务相关成熟度。他的意思是，不存在什么"最优管理风格"，你怎么管一个人，完全取决于他在这个具体任务上的成熟度。

这个概念放到 Agent 管理上简直完美适用。

你想想看，让 Claude Code 写个 CRUD 接口，和让它做一个跨三个模块的架构重构，这能是一样的管法吗？

我把 Agent 任务大致分成三档：

高 TRM 任务：放手让它干

比如写模板代码、重命名变量、生成测试用例。这些任务 Agent 闭着眼都能搞定，TRM 很高。你不需要盯着它，开个会话，扔个指令，回头拿结果就行了。

前两天我需要给一个项目加 20 多个 API 的 TypeScript 类型定义，直接跟 Agent 说了一句：

参考 swagger 文档，给所有 API 接口生成 TypeScript 类型定义

五分钟搞定，质量完全没问题。这种任务你要是还在那手把手指导，纯粹浪费时间。

中 TRM 任务：指导 + 点拨

比如重构一个函数、修复一个 bug、优化一段逻辑。Agent 能做，但你得给它足够的上下文，关键节点帮它 review 一下，发现跑偏了拨正方向。

举个例子，之前有个 bug，用户搜索的时候偶尔会返回空结果。我没有直接扔给 Agent 说"修这个 bug"，而是先跟它说：

搜索功能偶尔返回空结果，我怀疑是缓存过期的时序问题，你先看看 src/services/search.ts 和 src/cache/redis.ts 这两个文件，分析一下可能的原因

它分析完给了三个可能的原因，其中第二个命中了。然后我说"按第二个方案修"，它改完我快速 review 了关键逻辑，没问题，搞定。

整个过程中我的角色是提供上下文、审核关键点、把控方向，而不是放手不管，也不是手把手教。

低 TRM 任务：你来主导，Agent 来执行

比如系统级的架构设计、跨多个模块的复杂功能、涉及技术选型的重大决策。这些任务 Agent 的 TRM 很低，你必须有详细的 plan 或 spec，分步来做。

我之前犯过一个典型的错误：想让 Agent 一口气把一个 monorepo 的认证模块从 session 迁移到 JWT。直接给它一个大任务描述，让它自己规划、自己实现。

结果可想而知——它确实跑了，也确实写了几百行代码，但改了不该改的地方、漏了需要改的地方、还引入了两个安全漏洞。

后来我换了一个策略：

1. 先让 Agent 用 Plan Mode 分析现有的认证逻辑，列出所有涉及的文件
2. 我来定方案：先改 token 生成和验证的核心模块，再改中间件，最后改前端
3. 每一步都让 Agent 执行，我来检查和验收
4. 发现不对的立刻纠正，而不是攒到最后

这样分成五六步做下来，整个迁移干净利落，没有翻车。

核心就一句话：不要把错误的管理方式套在错误的任务上。简单任务你管太多，浪费时间。复杂任务你管太少，埋下炸弹。

给 Agent 扔了个任务就不管了，等到最后才发现翻车——这不叫委托，这叫甩锅：）

二、警惕 Agent 的锚定效应

这一点，很多人意识不到，但它的杀伤力极大。

Daniel Kahneman 在《思考，快与慢》里详细讲过锚定效应：当你面对一个不确定的问题时，最先接触到的信息会变成你心里的"锚"，你后续所有的判断都会不自觉地围绕这个锚来调整。

锚定效应在跟 AI Agent 打交道的时候简直无处不在。

你向 Agent 抛了一个复杂问题，它返回的第一个回答——功能架构、技术选型——会立刻变成你心中的参考点。后面即使你隐约觉得不太对，心理上也倾向于在原方案上"微调"，而不是推倒重来。

说实话，我自己也经常犯这个错。有一次让 Agent 设计一个 Chat 数据存储相关的功能，出了个方案，我看了觉得"嗯，看起来好像能用"，然后就在这个方案上来回优化。折腾了半天才突然意识到——我们的场景需要 Redis 发布订阅机制来做，很多问题瞬间迎刃而解。

如果我一开始就让它给我三个方案对比，可能五分钟就做出了正确的选择。

怎么破？

第一，让 Agent 给你多个方案。这是最简单也最有效的方法。不要只要一个答案，要两到三个备选：

给我 2-3 个可行的方案，分别说说各自的优缺点和适用场景

有了多个方案，你就不会被单一输出锚定了。你的角色是评估和取舍，而不是被动接受。

第二，在看 Agent 输出之前，先自己想一想。哪怕只是花两分钟列几个关键决策点，形成你自己的"锚"。这样你看到 Agent 的输出时，心里是有参照系的，不会被它牵着走。

三、善于苏格拉底式提问

这一点跟锚定效应有关，但更加隐蔽。

Agent 输出有一个特点：它永远都很自信。

不管对错，Agent 说话的语气都很笃定。"我建议使用工厂模式来解决这个问题"、"这个实现是线程安全的"、"这样修改不会影响现有功能"。

这种自信的语气会触发你大脑的一个机制——Kahneman 叫它"认知放松"（cognitive ease）。当信息看起来连贯、有条理、语气坚定的时候，你的系统 1（快速直觉思维）会自动判定"这个靠谱"，然后你的系统 2（慢速理性思维）就懒得再去验证了。你想想平时是不是被它的语气给蛊惑了？

但 Agent 输出的语气自信不代表内容正确。它可能正在用一种特别自信的口吻，给你挖一个特别大的坑。

怎么解决？很简单——苏格拉底式提问。

对 Agent 的每个关键结论追问：

• "这个方案在什么情况下会失败？"
• "你搞的这个改动有没有什么潜在的风险？"
• "有没有你没考虑到的边界情况？"
• "如果数据量增长 10 倍，这个设计还 hold 得住吗？"

这些问题的威力在于：它们强制 Agent 从另一个角度审视自己的输出。你会发现，同一个 Agent，当你让它"论证这个方案好"的时候，它说得头头是道；当你让它"找这个方案的问题"的时候，它也能找出一堆隐患。

前几天我让 Agent 写了一个文件上传的接口，它写完之后我问了一句："这个实现有什么安全风险？"

它自己就列出来了：没有限制文件大小、没有校验文件类型、可能有 XSS 攻击... 这些问题如果我不问，它是不会主动告诉我的。

从这个角度看，会提问这个能力在 Agent 时代真的是一个巨大的杠杆。你不需要是某个领域的专家，几个简单的反向问题，就能让你拿到远超你自身认知水平的洞察。

Kahneman 还讲过一个概念叫WYSIATI——What You See Is All There Is，意思是你的大脑会根据手头有限的信息编出一个"最好的故事"，但完全不会去想那些缺失的信息。

Agent 也一样。它给你的输出看起来"完整"，但你根本不知道它遗漏了什么。它不会主动跟你说"我其实还有些东西没考虑到"。

所以，养成一个习惯：每次拿到 Agent 的关键产出，追问一句——"你漏掉了什么？"。

四、避免 Agent 的过度设计

如果你经常 review Agent 的代码，你大概率会发现这些情况：

• 明明一个现成的库几行代码就能搞定的事，它偏要从零造轮子，洋洋洒洒写了几百行
• 同样的逻辑，它在不同地方重复写了好几遍，也不知道抽个公共函数
• 为了一些根本不可能出现的边界情况，写了一大堆防御代码
• 一个一次性操作，它也要给你封装成一个工具类，加配置项、加扩展点

不要奇怪，AI Agent 天生就有这个毛病。

Brooks 在《人月神话》里讲过一个概念叫第二系统效应——设计者在做第二个系统的时候，会把上次忍住没加的功能全塞进去，导致过度设计。Agent 更极端，因为代码生成的边际成本为零，加功能、堆代码量对 Agent 来说太容易了。你让它加功能，它绝不会跟你说"这个不该做"。

这也是 AI Coding 最大的坑之一。

功能以前所未有的速度堆积，维护负担指数级增长。只凭感觉编程的人，短期可能能撸出来一个像样的产品，但打开代码仓库一看，一大堆技术债，大量的垃圾代码，维护起来效率极低。

Vibe Coding 这个词最吸引眼球的当然是 "Vibe"，但危害最大的也正是这个 "Vibe"。

那怎么来约束呢？

第一，在 prompt 里明确要求。简单粗暴但有效：

最小化实现，不要过度设计，只做我要求的改动

或者在 CLAUDE.md 里写上规则：

Avoid over-engineering. Only make changes that are directly requested or clearly necessary.

第二，做完一个改动之后，让 Agent 自己清理。这个技巧我最近用得很多：

你觉得现在哪些代码是 over-engineering 的？给我清理和优化一下

Agent 其实很擅长做"减法"，前提是你要明确告诉它去做。

Agent 过度设计，本质上不是 Agent 的错，是你没有给它足够的约束。

五、找到你系统的瓶颈

最后一个点，也是我认为最重要的一个。

Goldratt 在《目标》这本书里讲了一个特别核心的思想：

每个复杂系统都由多个相互关联的活动组成，其中一个活动对整个系统构成约束——就是"链条中最薄弱的环节"。

换句话说：

• 整个系统的产出，只能在约束环节得到改善时才能提升
• 花时间优化非约束环节，不会带来什么显著收益
• 链条的强度由最弱的环节决定

你现在想一想，你日常用 Agent 工作的时候，整个工作流的瓶颈在哪？

说实话，在大多数人的工作流中，人类审查就是那个瓶颈。Agent 几分钟就能产出大量代码，但你的审查速度是有限的。

但我接下来要说的，不是让你提升自己审查的速度。

我真正想说的是：当你的 review 已经成为整个流程的瓶颈时，再去唤起更多的 Agent 其实没有任何意义。

Goldratt 在《目标》里讲了一个特别好的例子。Alex 的工厂花大价钱装了机器人，某些部门的生产率提高了 36%。听起来很厉害对吧？但实际上工厂一分钱都没多赚。为什么？因为机器人装在了非瓶颈环节。非瓶颈环节的效率提升，只是增加了库存，但最终出货量一点没变。

这就是经典的局部最优但全局恶化。

映射到 Agent 管理上：你同时开了 5 个 Claude Code 会话并行处理任务，Agent 产出了一大堆代码，但你审查不过来。API 费用上去了，待审代码在那堆着，但最终交付的高质量产出没有增加，而且 Agent 生成的代码之间可能还会冲突。

你的精力有限。当你只能一次跟进两个并行任务的时候，给你 20 个任务不会提升你的效率，只会让你焦头烂额。

那怎么办？围绕瓶颈来优化。

如果你的瓶颈是人的审查这一步，那就：

• 不要让 Agent 产出超过你能审查的量——宁可 Agent 等你，不要你追不上 Agent
• 用自动化测试减少人工审查的负担（CI/CD、lint、typecheck 这些配一次，永久生效）
• 提升 prompt 质量，让 Agent 一次性输出更可靠的代码，减少返工
• 高 TRM 任务直接跳过审查，中 TRM 任务只审关键节点，把精力留给低 TRM 任务

如果你的瓶颈是 prompt 编写——每次都从零开始写 prompt，效率当然低。那就把常用的 prompt 封装成 Skill 或者模板，一次投入，反复使用。

如果你的瓶颈是任务分解——你花大量时间在想怎么拆任务。那就让 Agent 先帮你拆，你来审核和调整，利用 Plan Mode 做这件事。

总而言之，找到瓶颈之后，尽可能优化瓶颈本身。你去优化瓶颈以外的因素，没有任何收益。

这些心法串在一起，就是一套完整的 Agent 管理方法

回头看一下，其实这五个点是一套完整的思维框架：

1. 用 TRM 判断管理力度——不同任务不同管法，不要一刀切
2. 用多方案对抗锚定效应——不要被 Agent 的第一个输出牵着走
3. 用苏格拉底式提问验证产出——越自信越要怀疑，反向追问
4. 用明确约束对抗过度设计——Agent 天生不会说"不"，你得替它说
5. 用瓶颈思维优化工作流——找到真正的约束，围绕它来改进

管理学研究了一百多年的核心问题，其实就是：怎么让你管的"人"产出最大化？

把这里面的"人"换成"Agent"，答案几乎原封不动地适用。

写在最后

其实，写这篇文章的过程中我自己也有新的感悟。

这个时代，大家都在聊 Agent 有多强、模型有多厉害、工具有多好用。但很少有人去想一个更本质的问题：你怎么管好这些强大的工具？

说实话，我现在已经不关心模型后面怎么进化了，因为光现在第一梯队模型的能力，就够我们消化至少五年时间了。

真正的瓶颈早就不是模型，那些天天说模型能力不行的、动不动降智的，其实有很多时候是自己成为了整个工作流的瓶颈，比如 prompt 上下文没有控制好、妄想一个 prompt 能完成一个复杂任务、最开始的方案路线就有问题等等。

当自己本身成为瓶颈，模型再怎么优化都只是杯水车薪。

Agent 加速了编码——但编码从来就不是瓶颈。设计、判断、审查、决策，这些才是真正难的部分。

如果你的 Agent 工作流一直不太顺，先别急着换工具、换模型。先检查你自己的系统和流程——prompt 设计合不合理？任务拆分清不清晰？瓶颈在哪？

管理 Agent 的最高境界，不是让 Agent 做更多的事，而是让 Agent 做正确的事，在正确的时机得到正确的干预。

这恰恰是 Andy Grove 40 年前对管理的定义。

学习资源推荐

如果你想更深入地学习大模型，以下是一些非常有价值的学习资源，这些资源将帮助你从不同角度学习大模型，提升你的实践能力。

一、全套AGI大模型学习路线

AI大模型时代的学习之旅：从基础到前沿，掌握人工智能的核心技能！​

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

二、640套AI大模型报告合集

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示

​因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

三、AI大模型经典PDF籍

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。 那以下这些PDF籍就是非常不错的学习资源。

因篇幅有限，仅展示部分资料，需要点击文章最下方名片即可前往获取

四、AI大模型商业化落地方案

作为普通人，入局大模型时代需要持续学习和实践，不断提高自己的技能和认知水平，同时也需要有责任感和伦理意识，为人工智能的健康发展贡献力量。