Agent 管理方法论：用经典管理学驯服 AI Agent#

核心观点#

人的角色已经从"执行者"变成了"管理者"。你不再是一行行写代码的人，而是指挥 Agent 干活、审查产出、把控方向的人。管理能力的高低，直接决定了你能从 Agent 身上拿到 2 倍还是 10 倍的效能。

以下四个经典管理学概念，分别对应 Agent 使用中最常见的四类问题。

TRM 任务分级管理#

来源：Andy Grove《High Output Management》中的 Task-Relevant Maturity（任务相关成熟度） 概念——不存在"最优管理风格"，管理力度取决于被管理者在具体任务上的成熟度。

高 TRM 任务：放手委托#

模板化、规则明确的任务，Agent 的完成质量稳定可靠，不需要人工介入。

典型场景：生成类型定义、写模板代码、重命名变量、生成测试用例。

# 实操 Demo：批量生成 TypeScript 类型定义
# 一句指令，直接拿结果，无需逐步盯控

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

# 预期效果：Agent 独立完成，产出质量稳定，人工只做最终确认

中 TRM 任务：协作共进#

跨模块、有一定复杂度的任务，Agent 能执行但无法自主把控全局方向，需要人分步引导。

典型场景：认证系统迁移、多模块联动修改、中等规模重构。

# 实操 Demo：认证系统从 Session 迁移到 JWT（分步协作）

# 第一步：让 Agent 分析现状（Plan Mode）
prompt: "用 Plan Mode 分析现有的认证逻辑，列出所有涉及的文件和依赖关系"

# 第二步：人定方案，拆解执行顺序
# → 先改 token 生成和验证的核心模块
# → 再改中间件
# → 最后改前端

# 第三步：逐步执行 + 逐步验收
prompt: "按照方案，先修改 token 生成模块，只改这一个文件"
# → 人工 review → 通过 → 进入下一步

# 核心：每一步执行完立刻检查，发现偏差立刻纠正，不要攒到最后

低 TRM 任务：紧密管控#

架构设计、复杂决策类任务，Agent 缺乏全局判断力，必须人主导、Agent 辅助。

典型场景：跨三个模块的架构重构、技术选型、安全相关的核心逻辑。

# 实操 Demo：低 TRM 任务的管控流程

# ❌ 错误做法：一句话甩给 Agent
prompt: "把整个项目的认证系统从 Session 迁移到 JWT"
# 结果：改了不该改的地方、漏了需要改的地方、引入安全漏洞

# ✅ 正确做法：人主导决策，Agent 只负责执行细节
# 1. 人来定架构方案
# 2. 人来拆执行步骤
# 3. 每步让 Agent 执行，人来验收
# 4. 关键节点人工复核安全性

一句话总结：简单任务管太多浪费时间，复杂任务管太少埋下炸弹。

对抗锚定效应#

来源：Daniel Kahneman《思考，快与慢》中的 锚定效应（Anchoring Effect）——人会不自觉地被第一个接收到的信息锚定，后续判断围绕这个锚点微调而非独立思考。

认知放松陷阱#

Agent 输出有一个危险特点：无论对错，语气都很笃定。"我建议使用工厂模式"、"这个实现是线程安全的"、"这样修改不会影响现有功能"——这种自信会触发大脑的认知放松机制，让你的系统 1（快速直觉）自动判定"靠谱"，系统 2（理性验证）就懒得启动了。

语气自信 ≠ 内容正确。Agent 可能正在用特别自信的口吻给你挖一个特别大的坑。

苏格拉底式提问#

对 Agent 的每个关键结论进行反向追问，强制激活你的系统 2 思维。

# 实操 Demo：对 Agent 产出的苏格拉底式追问模板

# 当 Agent 给出一个技术方案后，依次追问：

prompt: "这个方案在什么情况下会失败？"
prompt: "这个改动有没有潜在的安全风险？"
prompt: "有没有你没考虑到的边界情况？"
prompt: "如果数据量增长 10 倍，这个方案还能撑住吗？"

多方案对比#

不要接受 Agent 给出的第一个方案，要求它生成多个备选方案并对比优劣，打破锚定。

# 实操 Demo：强制生成多方案对比

prompt: "针对这个需求，给出三种不同的实现方案，
每种方案列出：
1. 核心思路
2. 优点
3. 缺点
4. 适用场景
5. 不适用场景

不要只推荐一种，我需要对比后自己做决策"

一句话总结：越自信越要怀疑，用多方案打破锚定，用反向提问验证结论。

抑制过度设计#

来源：Frederick Brooks《人月神话》中的 第二系统效应（Second-System Effect）——设计者在做第二个系统时，会把上次忍住没加的功能全塞进去，导致过度设计。Agent 更极端，因为代码生成的边际成本为零。

Agent 过度设计的典型症状#

• 重复逻辑不抽象：同样的逻辑在不同地方重复写了好几遍
• 过度防御：为根本不可能出现的边界情况写一大堆防御代码
• 过早抽象：一次性操作也封装成工具类，加配置项、加扩展点
• 功能膨胀：你让它加功能，它绝不会说"这个不该做"

明确约束#

在 prompt 中设定明确的边界，限制 Agent 的"创造力"。

# 实操 Demo：用约束条件限制过度设计

# ❌ 无约束 prompt（容易翻车）
prompt: "实现一个用户列表功能"

# ✅ 带约束的 prompt
prompt: "实现一个用户列表功能，要求：
- 只做分页查询和展示，不加筛选、排序、导出
- 不需要封装通用的 Table 组件，直接用 antd Table
- 不加 loading skeleton，用简单的 Spin 即可
- 不做乐观更新，走标准的请求-刷新流程
- 代码行数控制在 150 行以内"

# 实操 Demo：Code Review 时的过度设计检查清单

# 审查 Agent 产出时，逐项检查：
# □ 有没有为不存在的场景写防御代码？
# □ 有没有把一次性逻辑封装成"通用"工具？
# □ 有没有引入不需要的抽象层？
# □ 有没有重复代码应该抽取但没抽取的？
# □ 删掉这段代码，功能还能正常运行吗？如果能，删掉它

一句话总结：Agent 天生倾向堆代码，用明确约束控制范围，三行重复代码好过一个过早的抽象。

瓶颈理论优化#

来源：Eliyahu Goldratt《目标》中的 TOC 约束理论（Theory of Constraints）——任何系统的产出都受限于最薄弱的环节（瓶颈），优化非瓶颈环节对整体产出没有任何收益。

识别你的瓶颈#

人与 Agent 协作的完整链路中，瓶颈可能出现在任何环节：

针对性优化#

关键认识：当你的 review 已经成为瓶颈时，再唤起更多 Agent 没有任何意义。

# 实操 Demo：根据瓶颈类型选择优化策略

# 瓶颈一：人类审查（最常见）
# → 用 TRM 分级减少审查量
# → 高 TRM 任务直接跳过审查
# → 中 TRM 任务只审关键节点
# → 把精力留给低 TRM 任务
# → 提升 Agent 产出质量，减少返工

# 瓶颈二：Prompt 编写
# → 把常用 prompt 封装成 Skill 或模板，一次投入反复使用
prompt: "将这个 prompt 保存为 Claude Code Skill，
文件名：generate-api-types，
触发词：生成接口类型"

# 瓶颈三：任务分解
# → 让 Agent 先帮你拆，你来审核调整
prompt: "用 Plan Mode 把这个需求拆解成可独立执行的子任务，
每个子任务标注预估复杂度（高/中/低）和依赖关系"

# 瓶颈四：反馈迭代
# → 一次性把约束说清楚，减少来回修改
# → 在 CLAUDE.md 中沉淀项目规范，避免重复纠正

一句话总结：找到瓶颈再优化，优化非瓶颈环节的投入产出比为零。

完整框架#

四个理论串联起来，形成一套闭环的 Agent 管理方法：

核心原则：管理 Agent 的本质和管理人一样——根据任务匹配管理力度，验证而非信任产出，约束范围而非放任扩张，优化瓶颈而非平均用力。

延伸阅读#

• Andy Grove -《High Output Management》（格鲁夫给经理人的第一课）
• Daniel Kahneman -《Thinking, Fast and Slow》（思考，快与慢）
• Frederick Brooks -《The Mythical Man-Month》（人月神话）
• Eliyahu Goldratt -《The Goal》（目标）