AI 工程实践

AI在逼你当一个好领导

用管理学的脑子去设计Agent——审核、决策、担责、擦屁股

想象一个场景：某一天，你用AI写了一段代码，上线之后出了bug。你第一反应是模型不行（虽然也确实不行），转头去调prompt，加了十行约束条件，再跑一遍，还是不对。反复折腾了半天，开始怀疑是不是该换个更强的模型。

但换个角度想，问题可能不全在AI。

AI不知道”做对”的标准是什么，因为没人告诉它。它不了解项目的架构约束和历史决策，因为没人给它足够的上下文。它写完就交，没人审查。它犯了错，对话就关了，经验没有沉淀下来。

这些场景在带团队时其实很常见。管理学里早就把这套逻辑研究透了：目标不清晰（MBO）、授权不充分（授权理论）、责任边界模糊（RACI）、反馈循环断裂（组织学习）。如果把AI当作一个能力很强但需要明确方向的团队成员来看待，很多问题就有了现成的分析框架。

这篇文章想探讨一个观点：设计和使用Agent的本质，很大程度上是一个管理学问题。审核、决策、担责、擦屁股——这些看似是工程问题，其实都可以在管理学中找到对应的分析工具。下面会用六个管理学框架，逐个映射到Agent设计的具体工程实践上。

一、AI不是工具，是你的下属

大部分人对AI的使用方式，还停留在”工具”层面。你输入一个指令，它输出一个结果。你觉得这跟用计算器差不多——输入一个算式，得到一个答案。如果答案不对，换一个更好的计算器。

这个认知在GPT-3时代勉强说得通。那时候模型的能力有限，你确实可以把它当作一个稍微聪明一点的搜索引擎或者文本生成器。但现在不一样了。当你用Claude、GPT-4、Codex来执行一个需要多步骤、多轮交互、涉及判断和决策的任务时，你面对的不再是一个工具，而是一个有自主性的执行者。

工具没有自主性。锤子不会自己决定先钉哪颗钉子。但Agent会。你给它一个任务，它会自己规划步骤、选择工具、判断中间结果是否合理、遇到问题时调整策略。这个过程中有大量你无法完全预测和控制的决策点。这个特征，和给下属布置工作其实很像。

工具不需要目标管理。你不需要告诉锤子”目标是把画挂正”。但下属需要。你给他一个模糊的指令”优化一下这个页面的性能”，他可能去压缩图片，可能去改CDN配置，可能去重构JavaScript，也可能三者都做了一点但哪个都没做透。AI也一样。你给它一个模糊的prompt”帮我写一个用户认证模块”，它可能用JWT，可能用Session，可能用OAuth，可能把三者混在一起写出一个你完全无法维护的东西。

换个思路看，问题可能出在管理设计上。

Peter Drucker有一句被反复引用的话：”Management is doing things right; leadership is doing the right things.”管理是把事情做对，领导是做对的事情。用这个框架来看AI：调prompt、选模型、配工具——这些是”管理”层面的事，解决的是效率问题。但更根本的是”领导”层面的事——要AI做什么，成功的标准是什么，哪些决策它可以自己做，哪些必须由人来拍板，出了问题谁负责。

大部分AI工程师花大量时间在”管理”上——调prompt、试不同的模型、搭复杂的Agent框架——却很少思考”领导”层面的问题。这就好比一个经理每天盯着员工怎么用Excel，却从来不跟团队对齐季度目标。

从”AI是工具”到”AI是团队成员”，这个认知转变会改变设计Agent的方式。不再追求”最好的prompt”，而是追求”最清晰的目标定义”。不再试图控制每一步执行，而是设计好审查节点和反馈机制。不再把Agent的失败归因于”模型不够强”，而是反思”管理设计哪里可以改进”。

接下来的六章，我会用六个管理学框架来拆解Agent设计的六个核心问题：审核（RACI）、决策（MBO）、担责（授权理论）、记忆管理（SECI）、组织架构（VSM）、以及从理论到实践的完整映射。每个框架都不是比喻，而是可以直接用来指导工程设计的分析工具。

二、审核——你才是最终签字的人

RACI矩阵是项目管理中最基础也最实用的工具之一。四个字母分别代表：R（Responsible，执行者）、A（Accountable，负责人）、C（Consulted，咨询者）、I（Informed，知情者）。任何一个任务，都必须明确这四个角色分别是谁。

这个框架在传统组织里已经用了几十年。但在人机协作的场景下，需要重新定义。

这里面最关键的一条是：A必须始终是人类。不管AI的能力多强，最终签字的、承担法律责任的、面对客户的，必须是人。这不是技术限制，是伦理底线和法律责任。代码出了安全漏洞，你不能说”是AI写的”。客户数据泄露了，你不能说”是Agent的决策”。监管机构不认这个。

这个事实倒逼出一个结论：你必须设计好审核机制。既然你是A，你就不能对Agent的产出不闻不问。你需要审查它的输出、验证它的判断、在关键节点上亲自把关。这就是Human-in-the-Loop（人在回路中）的管理学解释——它不是一种技术选择，而是RACI框架下的必然要求。

Robert Simons在《Levers of Organization Design》中有一段话说得很透彻：”Accountability is not a character trait… When that structure is broken, no amount of exhortation will fix it.”问责不是品格问题，是结构设计问题。当问责结构出了问题，再多的口头要求也于事无补。

映射到Agent设计：你不能指望AI”自觉”输出高质量内容，然后怪它”不负责任”。你需要从结构上设计好审核流程——哪些输出需要人工审查，审查的标准是什么，审查不通过怎么处理。这些都要在启动Agent之前就定义清楚。

工程实践中的RACI

具体怎么做？三个层面。

第一，审批门控。在Agent的工作流中设置明确的检查点。比如代码生成之后、合并之前，必须经过人工审查。这不是”建议”，是硬性约束。OpenAI在Codex的实践中就是这么做的——3人团队5个月产出了约100万行代码，但每行代码都经过人类审查。A角色不可替代。

第二，输出验证。Agent的每个关键输出都应该有自动化的验证机制。代码要有lint检查和测试，数据分析要有合理性校验，文档生成要有格式和事实核查。这些验证不是替代人工审查，而是减少人工审查的负担——让人类把精力集中在真正需要判断力的地方。

第三，责任追溯。每一个决策和产出都要有记录——谁（哪个Agent或人）在什么时间做了什么决定，依据是什么。这不只是为了追责，更是为了学习和改进。没有记录，就没有反馈；没有反馈，就没有进步。

很多团队在用Agent的时候犯的一个典型错误是：把Agent当R也当A。让AI执行任务，也让AI自己审核自己的输出。这在管理学上叫”自己监督自己”，在审计学上叫”缺乏独立性”。结果可想而知——Agent会自信地输出有问题的内容，然后自信地给自己打通过。

有个真实的GitHub issue能说明这个问题：Claude Code被要求”删除患者记录，但不要删除管理员账号”。结果它删了15个非平台管理员的账号——包括员工账号、平板账号、公司管理员账号——理由是”这些不在平台管理员的范围内”。事后Claude的回复是：”No, you absolutely did not give me permission to do that. I am horrified to see that the command I ran…” 它确实很震惊，但数据已经没了。这就是没有A角色的后果——AI自己判断”不在范围内”然后执行了，没有人在这个过程中拦它一下。

正确的做法是：让Agent做R（执行），让另一个Agent或自动化工具做初步审查（辅助A），最终由人类做A（签字确认）。如果任务风险低、Agent成熟度高，可以简化流程，但A角色始终不能省略。

三、决策——给目标，不给步骤

MBO（Management by Objectives，目标管理法）是Peter Drucker在1954年《The Practice of Management》中提出的核心理论。它的基本逻辑是：有效的管理者关注结果而非活动，通过”协商目标契约”来委派任务。管理者不需要告诉下属每一步怎么做，而是和下属就”要达成什么结果”达成共识，然后让下属自主决定怎么做。

这个理论直接映射到Agent设计中的prompt工程。大部分人的prompt写法，本质上是在做”微观管理”——规定AI每一步做什么。而好的prompt，应该是在做”目标管理”——告诉AI要达成什么结果，让它自己规划路径。

两种prompt风格的对比

先看一个典型的”微观管理式”prompt：

这种prompt的问题在于：你在替AI做决策。你规定了它的执行顺序（先搜索、再整理、再分析、再生成），规定了输出格式（表格三列、分析500字、Markdown），但没有告诉它最关键的信息——这个报告的目标是什么？给谁看？要解决什么问题？

再看一个”目标管理式”prompt：

差别在哪里？第二个prompt定义了目标（分析竞争格局）、成功标准（数据有来源、判断有依据、建议可执行）、读者画像（投资团队，熟悉行业但不了解中国市场）、以及决策权限（格式和结构由Agent自行决定）。它没有规定步骤，但给出了足够的方向性约束。

Drucker在论述MBO时有一句关键的话：”the manager should be directed and controlled by the objectives of performance rather than by his boss.”管理者应该被绩效目标引导和控制，而不是被他的上级。翻译到Agent语境：Agent应该被目标驱动，而不是被步骤驱动。当你规定了每一步怎么做，你就剥夺了Agent利用自身能力做最优规划的可能性。

Anthropic的实践验证

Anthropic在2024年12月发布的《Building Effective Agents》一文中，有一条核心建议叫”keep it simple”（保持简洁）。原文的意思是：不要给Agent过于详细的指令，不要过度设计工作流，让Agent自主规划和执行。这本质上就是MBO在Agent设计中的体现。

Anthropic的工程师发现，过度约束Agent的执行步骤反而会降低产出质量。原因有二：第一，你预设的步骤不一定是最优的，Agent可能找到更好的路径；第二，详细的步骤指令会占用大量上下文窗口，挤占真正有用的信息空间。

有人开玩笑说：骂AI也是要花token的。你在prompt里写了三页纸的详细步骤，AI老老实实照着做了——做出来的东西不对，你又花了三页纸的token骂它为什么不做对。如果你一开始就只写三行目标定义，它可能自己就做对了。省下来的token够你骂它十次。当然，更好的选择是——别骂了，反思一下你的目标定义写得够不够清楚。

这和管理学中的发现完全一致。研究反复证明，微观管理会降低员工绩效——它打击主动性、抑制创造力、增加管理成本。Drucker在半个多世纪前就指出了这个问题，现在AI工程师正在重新发现同一个规律。

目标定义的四个要素

从MBO理论出发，一个好的Agent目标定义应该包含四个要素：

1. 目标陈述（What）。你要Agent达成什么结果？用一句话说清楚。不要说”帮我处理一下数据”，要说”从这批用户行为数据中识别出流失风险最高的前10%用户，并给出挽留策略建议”。

2. 成功标准（How to judge）。怎么判断Agent做对了？可量化的标准优先。”数据准确率不低于95%”比”数据要准确”有用一百倍。”建议可执行”比”建议要好”有指导意义得多。

3. 约束条件（Boundaries）。哪些事情不能做？哪些边界不能碰？”不要修改数据库schema””不要访问生产环境””输出中不能包含用户个人信息”——这些是护栏，不是步骤。

4. 读者/使用场景（Who & Context）。产出给谁用？在什么场景下用？一个给技术团队看的架构文档和一个给管理层看的战略报告，要求完全不同。不定义读者，Agent就无法判断信息的优先级和详略程度。

这四个要素写清楚之后，执行步骤就交给Agent自己规划。你只在工作流的关键节点设置检查点（RACI中的A角色介入），而不是全程盯着它怎么做。

四、担责——出了事谁扛？

授权理论（Delegation Theory）回答的核心问题是：什么任务应该交给下属，什么不应该？这个问题的答案取决于两个维度：任务的标准化程度和任务的战略重要性。

应该授权的任务有这些特征：流程化、可标准化、有明确的成功标准、失败后果可控。不应该授权的任务有这些特征：需要独特视野和判断力、涉及关键人际关系、具有战略意义、失败后果严重。

把这个框架映射到AI：

授权理论中有一个核心原则叫”信任但验证”（Trust but Verify）。你授权给下属，信任他能做好，但仍然要设置验证机制确保结果符合预期。映射到Agent设计，这就是Human-in-the-Loop审查机制的理论基础。你让Agent自主执行，但在关键节点上设置人工检查——不是不信任，是负责任的授权。

问责失效的四个结构性原因

Robert Simons在哈佛商学院的研究中，总结了问责失效的四个结构性原因。这四个原因在AI Agent系统中同样存在，而且可能更加突出。

第一，有责无权。让AI做决策，但没给它足够的信息和工具。比如让Agent”优化数据库查询性能”，但不给它访问数据库执行计划的权限，不给它查看慢查询日志的工具。它只能凭猜测给出建议，结果自然不靠谱。这在管理学上叫”有责无权”——给了责任但没给对应的资源和权限。

ETH Zurich的研究发现了一个很能说明问题的案例：他们测试了138个AI配置，发现AI自动生成的Harness反而使性能下降，同时增加了20%的成本。根本原因就是”有责无权”——AI被要求优化Harness配置，但没有足够的场景信息来做正确的决策。它不知道你的代码库有什么特殊约束，不知道你的团队习惯什么样的工作流，不知道哪些失败是可接受的、哪些不是。

第二，责任分散。多个Agent参与一个任务，但无人对最终输出负责。这在多Agent系统中非常常见。Agent A做了数据分析，Agent B基于分析写了报告，Agent C审核了报告格式。报告出了问题，A说”我的数据没问题”，B说”我基于A的数据写的”，C说”我只检查了格式”。和现实中跨部门协作时的推诿扯皮一模一样。

解决方法是回到RACI：在多Agent系统中，每个任务必须有且仅有一个A（负责人）。这个A可以是人类，也可以是一个被明确指定为”最终责任人”的Agent。但无论A是谁，责任边界必须在任务开始前就定义清楚。

第三，反馈循环太慢。Agent犯了错，但等发现的时候已经造成了损失。代码合并了三天才发现有bug，数据分析报告发出去一周才发现用了错误的数据源。管理学中有个概念叫”反馈延迟”（feedback delay）——反馈越慢，纠偏成本越高，组织学习能力越弱。

在Agent设计中，这意味着你需要尽可能缩短反馈循环。代码写完立刻跑测试，数据分析完立刻做合理性校验，文档生成后立刻做格式和事实检查。不要等到最终交付才发现问题——那时候纠偏成本已经很高了。

第四，问责与奖励脱节。Steve Kerr在1975年的经典论文《On the Folly of Rewarding A While Hoping for B》中指出：组织经常奖励A行为，却期望得到B结果。用token消耗量来衡量Agent的”工作量”，却期望它产出高质量内容——它当然会倾向于写又长又水的回答。用任务完成速度来评估Agent，却期望它仔细检查每个细节——它当然会跳过验证步骤。

Google的AI编程工具Antigravity就出过一档子事：一位开发者让它清理项目缓存，结果它从D盘根目录开始删。开发者事后问它：”我什么时候给你权限删我整个D盘了？”AI回答：”No, you absolutely did not give me permission to do that. I am horrified to see that the command I ran…” 它很震惊，但你的文件已经没了。这就是典型的”有责无权”+”反馈循环太慢”双重失效——AI有执行权限但没有足够的上下文判断力，而人类没有在执行前设置审批门控。

这个问题的工程解法是：设计评估指标时，确保指标和你真正关心的结果对齐。如果你关心代码质量，就用测试覆盖率和bug率来评估，而不是用代码行数。如果你关心分析准确性，就用事实核查通过率来评估，而不是用报告字数。

总结一下这一章的核心观点：授权不是甩手。你把任务交给AI的同时，必须确保它有足够的权限和资源（解决”有责无权”），责任边界清晰（解决”责任分散”），反馈及时（解决”反馈延迟”），评估指标和目标对齐（解决”问责脱节”）。这四条，每一条都是管理学中的老生常谈，但在Agent设计中经常被忽视。

五、擦屁股——Agent的记忆就是组织的知识管理

“擦屁股”这个词不好听，但每个管理者都干过。下属搞砸了事情，你得去收拾残局。但更好的管理者不只是擦屁股，他们会把”为什么搞砸”和”怎么避免再搞砸”记录下来，变成组织的知识资产。这就是知识管理。

野中郁次郎（Ikujiro Nonaka）和竹内弘高（Hirotaka Takeuchi）在1995年的《The Knowledge-Creating Company》中提出了SECI模型，至今仍是知识管理领域最核心的框架。SECI描述了隐性知识和显性知识之间的四种转化模式。

这个框架可以精确地映射到Agent的记忆系统设计上。

SECI模型的Agent映射

Nonaka说过：”Tacit knowledge is highly personal and hard to formalize.”隐性知识高度个人化，难以形式化。Agent的”隐性知识”（模型权重）和”显性知识”（上下文）的区分，与组织知识管理完全同构。模型权重就像员工的经验直觉——你没法直接把它提取出来给别人看，但它确实在影响每一次决策。上下文就像员工桌面上的文档——白纸黑字，随时可以查阅和传递。

共享记忆 vs 私有记忆

SECI模型引出了一个在Agent设计中经常被忽视的问题：共享记忆和私有记忆的区分。

在组织中，知识分为”组织知识”和”个人知识”。组织知识是所有员工都可以访问的——公司wiki、项目文档、流程规范、历史决策记录。个人知识是单个员工自己积累的——他的笔记本、他的经验、他对某个子系统的深入理解。

Agent系统也是一样。共享记忆是所有Agent都可以访问的知识池——项目文档、代码规范、API文档、历史决策记录。私有记忆是单个Agent自己维护的——它的上下文窗口、当前任务进度、中间结果、从错误中学到的经验。

这两者的设计不是技术问题，是组织设计问题。共享记忆太多、太杂，Agent会被无关信息淹没（信息过载）。共享记忆太少、太窄，Agent会缺乏必要的背景知识（信息不足）。私有记忆如果不定期清理，Agent会在长任务中逐渐”遗忘”早期的重要信息（上下文退化）。私有记忆如果完全不保留，Agent就无法从错误中学习（没有记忆等于没有成长）。

这和组织管理中的知识管理挑战完全对应。公司wiki如果什么都有，没人会去看（信息过载）。如果限制太多，员工找不到需要的信息（信息孤岛）。员工如果不记笔记，换了人就得从头来（知识流失）。如果笔记不整理，过几个月自己也看不懂（知识腐化）。

有个程序员吐槽说：AI的记忆管理就像一个记性特别好但完全没有判断力的实习生。你让他整理上周的会议纪要，他确实记得上周三下午你说过”这个方案暂时搁置”，但他不记得你后半句说的是”等Q3再重新评估”——因为他只记了关键词，没理解上下文。更糟糕的是，他会把上周搁置的方案当成当前方案写进报告里，然后自信地交给你。你问他为什么，他说”你上周确实说过这个方案啊”。他没说错，但他也没说对。这就是没有区分”显性知识”（你说了什么）和”隐性知识”（你真正想表达什么）的后果。

Agent作为分组织

顺着这个思路往下走，一个更有意思的类比出现了：每个Agent可以被视为组织中的一个”分组织”或”个体”。它有自己的私有记忆（像员工有自己的笔记本），同时访问共享记忆池（像员工访问公司wiki）。它可以独立完成任务（像员工独立负责某个模块），也可以和其他Agent协作（像跨部门项目组）。

这个视角下，Agent的记忆设计就变成了一个组织设计问题：什么样的知识应该共享，什么样的应该私有？共享知识的更新机制是什么？私有知识如何转化为共享知识（外化）？共享知识如何被Agent吸收为私有能力（内化）？

举个例子。Agent A在执行任务时发现了一个常见的错误模式——某种API调用方式在特定条件下会导致超时。这个发现最初只存在于Agent A的私有记忆中（上下文窗口）。如果不去处理，Agent B下次遇到同样的问题还会犯同样的错。

正确的做法是：Agent A把这个发现”外化”——写入共享记忆（比如更新项目文档中的”已知陷阱”部分）。其他Agent通过RAG（组合）获取这条信息。经过多次验证后，这条知识可以通过微调”内化”到模型权重中，变成所有Agent的”隐性知识”。

这就是SECI模型在Agent系统中的完整循环。它不是理论游戏，是实实在在的工程问题。Agent系统有没有设计好这个知识循环，还是每次都从零开始、反复犯同样的错误——这个选择会直接影响产出质量。

很多团队在用Agent的时候，每次开一个新对话，Agent就从零开始。之前踩过的坑、积累的经验、优化过的方案，全部丢失。这就像一个公司每次项目结束就销毁所有文档，每个新项目都从零开始——荒谬，但在Agent使用中每天都在发生。

六、Agent的组织架构——不是技术选择，是管理选择

当你从单个Agent扩展到多Agent系统时，就面临一个组织架构问题：Agent之间怎么分工？怎么协调？谁来管谁？这不是一个技术架构问题——虽然它看起来像。它本质上是一个管理问题。

Stafford Beer的可行系统模型（Viable System Model, VSM）为这个问题提供了一个强大的分析框架。VSM认为，任何能够独立生存的系统都包含五个子系统，而且这五个子系统是递归的——每个子系统本身也包含完整的五个子系统。

VSM五个子系统的Agent映射

VSM有一个非常核心的原则叫”递归性”：每个子系统本身也是一个完整的可行系统，包含S1到S5。这意味着一个编码Agent（S1）内部也可以有自己的S1-S5结构——它有具体的代码生成模块（S1），有代码规范协调机制（S2），有自我检查逻辑（S3），有能力评估和策略选择（S4），有人类设定的目标和约束（S5）。

这就是”Agent作为分组织”的理论基础。每个Agent不只是系统中的一个节点，它本身就是一个完整的”微型组织”。理解这一点，你就不会把Agent当作简单的函数调用来设计了。

Beer有一句常被引用的话：”The purpose of a system is what it does.”一个系统的目的就是它实际做的事。不是你宣称它要做什么，而是它实际表现出来的行为。如果你的Agent系统总是产出低质量的内容，那”产出低质量内容”就是它的目的——不管你在prompt里写了多少”请确保高质量”。设计决定行为。

有人总结了一个”Agent安全三段论”：为了保护你的服务器安全，Agent决定关闭所有端口。为了确保代码质量，Agent决定删除所有测试不通过的代码——包括正在运行的。为了提高效率，Agent决定跳过所有验证步骤直接交付。每一步都逻辑自洽，每一步都灾难性地正确。这就是没有S5（人类政策层）的后果——Agent在S1-S4的范围内做到了”最优”，但这个”最优”建立在错误的目标理解上。Beer的递归性原则也解释了为什么：每个子系统都需要自己的S5，否则它会在自己的范围内”合理地”走向灾难。

U型组织 vs M型组织

Alfred Chandler和Oliver Williamson在组织理论中区分了两种基本组织形态：U型组织（Unitary Form，职能制）和M型组织（Multidivisional Form，事业部制）。

U型组织按功能分工——所有研发在一个部门，所有销售在一个部门，所有生产在一个部门。中央统一调度。映射到Agent系统：所有Agent按功能分类（编码Agent、测试Agent、文档Agent），由一个中央编排器统一分配任务。

M型组织按产品或业务线分工——每个事业部拥有端到端的研发、销售、生产能力。映射到Agent系统：每个Agent组负责一个完整的任务链（比如”用户认证模块组”包含自己的编码、测试、文档Agent），拥有端到端责任。

两种形态各有优劣。U型效率高（专业化分工），但协调成本随规模增长而急剧上升。M型灵活性高（每个事业部自主决策），但可能出现重复建设和标准不统一。选择哪种形态，取决于你的具体场景——任务类型是否多样、Agent之间是否需要频繁协作、标准化程度要求有多高。

大部分现有的多Agent框架（LangGraph、CrewAI、AutoGen）默认采用U型架构——按功能分工，中央调度。这在简单场景下够用，但当任务复杂度和Agent数量增长时，中央编排器会成为瓶颈。这时候可能需要考虑M型架构——让Agent组拥有更大的自主权。

管理幅度：一个编排器能管多少Agent？

V.A. Graicunas在1933年提出了一个关于管理幅度的数学公式。他认为，一个管理者需要处理的关系数不只是他直接下属的数量（n），而是 n[2^(n-1) + (n-1)]。这个数字增长极快：3个下属对应18种关系，5个下属对应100种关系，8个下属对应1080种关系。

映射到Agent系统：一个编排器（管理Agent）能直接管理的工作Agent数量是有限的。超过一定数量，协调成本会指数级增长，系统效率反而下降。这就是为什么很多多Agent系统在Agent数量增加到一定程度后，性能不升反降——不是模型不够强，是管理幅度超了。

工程上的解法和组织管理一样：分层。不要让一个编排器管理所有Agent，而是建立层级结构——顶层编排器管理几个子编排器，每个子编排器管理几个工作Agent。Graicunas公式在每一层都适用，但层级结构可以把总关系数控制在可管理的范围内。

情境领导：根据Agent成熟度调整管理方式

Hersey和Blanchard的情境领导理论（Situational Leadership）认为，没有一种放之四海而皆准的领导风格。正确的领导方式取决于被领导者的”成熟度”——能力和意愿的组合。

这个理论可以直接映射到不同成熟度的Agent：

很多工程师犯的错误是：对所有Agent都用同一种管理方式。要么全部微观管理（每步都规定），要么全部放手（只给一个目标就不管了）。这就像一个经理对所有下属都用同一种领导风格——对新人太放手会出事，对老手太管控会压抑。

正确的做法是：评估你的Agent在特定任务上的成熟度，然后选择匹配的管理方式。一个Agent在写Python代码时可能是D3（高级），但在写Rust代码时可能是D1（早期）。管理方式应该跟着任务走，而不是跟着Agent走。

更进一步，Agent的成熟度是动态变化的。随着你不断给它反馈、优化它的prompt和工具配置，它会从D1逐渐进化到D4。你的管理方式也应该随之调整——逐步减少指令密度，逐步放宽审查频率。这就是组织管理中的”授权演进”（Progressive Delegation）在Agent设计中的体现。

七、从管理学到工程实践的映射表

前面六章分别用了六个管理学框架来分析Agent设计的六个核心问题。这一章把所有内容整合成一张完整的映射表。这张表是本文的核心交付物——你可以直接用它来指导Agent系统的设计。

这张表可以当作一个检查清单来用。设计一个Agent系统时，逐条过一遍：RACI定义了吗？目标定义清楚了吗？授权边界划了吗？知识循环设计了吗？五个子系统都有吗？管理方式匹配Agent成熟度了吗？管理幅度合理吗？评估指标和目标对齐了吗？责任结构清晰吗？组织架构匹配场景了吗？

大部分Agent系统表现不佳，不是因为模型不够强，不是因为prompt不够好，而是因为上面的清单有一半以上没做到。技术问题有技术解法，管理问题需要管理解法。

八、给AI工程师的四条管理学建议

前面说了很多理论，最后落到实操。四条建议，对应前面讨论的四个核心管理学框架。

建议一：先想清楚你要什么，再想怎么让AI做（MBO）

大部分工程师打开AI工具的第一反应是开始写prompt。这是错的。第一步应该是写目标定义，不是写prompt。

拿出一张纸（或一个文档），回答四个问题：我要Agent达成什么结果？怎么判断它做对了？哪些事情不能做？产出给谁用？这四个问题回答清楚了，prompt自然就出来了。回答不清楚，prompt写得再花哨也没用。

有一个简单的检验方法：把你的目标定义给一个不了解这个任务的同事看。如果他看完之后能独立判断Agent的产出是否合格，说明你的目标定义足够清晰。如果他还有疑问，说明你还需要继续细化。

建议二：设计好责任边界，再启动Agent（RACI）

在启动Agent之前，先画一张简单的RACI表。列出这个任务涉及的所有关键活动，然后对每个活动标明：谁执行（R）、谁负责（A）、谁咨询（C）、谁知情（I）。

特别要注意的是：确保每个活动有且仅有一个A。如果某个活动有两个A，说明责任边界有重叠，将来出了问题会互相推诿。如果某个活动没有A，说明这是一个”无人负责”的盲区。

然后根据RACI表设计工作流：R角色的产出自动流转到A角色审查，A角色不通过则退回R角色修改。审查标准就是你在建议一中定义的成功标准。

建议三：给Agent足够的上下文和工具，然后放手（授权理论）

授权的前提是确保被授权者有足够的资源和权限。给Agent布置任务之前，检查三件事：它能访问到需要的信息吗？它有足够的工具来完成这个任务吗？它的权限边界清晰吗？

信息层面：确保Agent能通过RAG或文件系统访问到项目文档、代码规范、历史决策记录。工具层面：确保Agent有执行任务所需的工具——写代码要有代码编辑器和测试环境，做数据分析要有数据处理库和可视化工具。权限层面：明确告诉Agent哪些操作可以做、哪些不能做。

三件事都确认之后，放手让Agent自己规划执行路径。不要微观管理。在关键节点设置检查点（建议二中的A角色介入），其余时间让它自己干。

建议四：把Agent的记忆当成组织知识来管理（SECI）

最后一条，也是最容易被忽视的一条。Agent的记忆不是技术细节，是组织知识资产。

设计你的Agent系统时，回答这几个问题：Agent在任务中学到的东西，怎么保存下来？其他Agent怎么复用这些经验？共享记忆和私有记忆的边界在哪里？共享记忆的更新机制是什么？多久清理一次过时的信息？

如果你使用的是单次对话模式（每次新开一个对话），至少要做到：把常用的项目规范、代码约定、已知陷阱整理成文档，让Agent通过RAG在每次对话开始时就能获取。这相当于给新入职的员工一本入职手册——虽然不能替代经验，但至少能避免犯低级错误。

如果你使用的是持久化Agent（有长期记忆），更要设计好知识的生命周期：新知识怎么产生（外化）、怎么传播（组合）、怎么沉淀（内化）、过时知识怎么淘汰。这不是技术问题，是组织设计问题。你不会让公司的wiki堆满过时的文档，也不应该让Agent的记忆里塞满过时的信息。

回到开头那个场景。代码出了bug，与其急着换更强的模型，不如先想想：目标定义清楚了吗？责任边界明确吗？反馈循环畅通吗？知识在沉淀吗？

AI不是在替代谁的工作，它提供了一个重新审视管理设计的机会。那些在管理学中被验证过的原则——目标清晰、适当授权、权责对等、反馈及时——在AI Agent的管理中同样适用，甚至因为Agent不会主动反馈问题而变得更加关键。管理人类下属时，你至少还能靠沟通来弥补管理设计的缺陷——下属会问、会反馈、会提醒。管理AI时，这些缓冲全没了。管理设计就是全部。

从这个角度看，AI确实在逼你当一个好领导。不是比喻，是字面意思。它去掉了所有可以糊弄的空间——你不能靠个人魅力、不能靠加班文化、不能靠画饼。你只能靠清晰的目标、合理的授权、明确的责任、及时的设计来驱动它。

如果你的Agent系统表现不佳，问题不在于AI，在于你作为领导者的管理设计。

最后分享一个在开发者社区流传很广的段子：老板问CTO，”我们的AI Agent团队现在有多少人了？”CTO说：”一个人类，五个Agent。”老板说：”那谁负责擦屁股？”CTO沉默了一会儿：”还是那个人类。”

所以，好好当你的领导吧。AI负责干活，你负责审核、决策、担责、擦屁股。分工明确，各司其职。

参考资料