Agent 时代的管理学：从三省六部到现代企业，哪些制度值得迁移

Hello，大家好，我是Punk，一名中科大管理学硕士。

前两天，我说可以给 GrokBot 弄一套“三省六部制”。有人质疑：都已经时至今日了，为什么还要用三省六部制这么不完善的制度？

我说三省六部，是借一个大家都知道的制度，让大家直观体会多个 Agent 怎么分工：有人起草，有人审核，有人执行。

但这个质疑有道理。光把分工和复核搬过来，Agent 还跑不顺。 真用起来，你很快就会碰到这些事：

• 交出去以后，它到底做了什么，你看不看得见？

• 哪些事它自己定，哪些必须问你？

• 它和自己的“审核员”吵起来，谁拍板？什么时候该停？

• 怎样才算真的做完了？

这些事，我们可以回到管理制度的历史里找办法。人类组织协作时，也一直在处理放权、检查、协调和交付的问题。

尤其是一个人用个人 Agent，很容易把自己用成批奏章的皇帝。所有事情最后都汇到你这里，你批得过来吗？

今天我挑了九种制度和方法，沿着时间讲：当时碰到了什么问题，怎么解决，哪里还有局限，今天有什么能用。最后用多个 Bot 协作、一个 Agent 干活这两种情况串起来，再留一张总结表和一份能直接用的任务单。

一、分封到郡县：交出去以后，还得看得见

西周靠分封扩展统治：王室把土地和人口交给诸侯，诸侯承担义务。在交通和通信都很有限的年代，这是把事情“交出去”的办法。

问题是，诸侯的权力可以世袭，又掌握人口和军事资源。地方实力增长以后，王室越来越难约束，春秋战国的兼并与秩序变化，也发生在这个过程中。

秦推行郡县，地方交给中央任命的官员，可以换人，也可以统一政令。但任命只是第一步，还得知道地方实际发生了什么，于是户籍、簿册、文书和考核变得重要。即便如此，汉代上计考课里仍有地方官虚报政绩。有报告，不等于报告是真的。

所以，任务交出去，至少得留住两样东西：它能做到哪一步，以及它实际做了什么。

比如让 Agent 整理邮箱。开始前讲清：能读哪些文件夹，能不能归档，能不能删除，能不能替你回复。做完以后，它要交一份清单：归档了哪些、哪几封需要你亲自看、为什么。它说“已经整理好了”，你得能打开记录，找到它处理过的邮件，不能只听汇报得好不好。

二、三省六部：起草、审核分开了，卡住以后怎么办

到了隋唐，中枢形成了我们熟悉的三省六部：中书省拟定政令，门下省审核、可以封驳退回，尚书省组织执行，六部分管具体事务。

它的好处在于把两件事放到了一起：专业的事有人接，政令发出前有人复核。

但分工以后，几个部门怎么协调，意见不同谁来定，仍然要处理。唐代有政事堂等共同议政安排，三省也始终在皇权之下运作，不同于现代的独立制衡。

Agent 也一样，一个写作 Agent 加一个核查 Agent，可能只是听起来很合理；如果没设好规则，就可能变成：核查退回，写作改一版，核查又退回……来回十轮，额度烧了一堆，稿子还没写好。

所以设计上需要给Agent补上三条规则：退回几次就停，冲突时谁拍板，停下以后交给谁。

比如规定修改次数：同一个问题修了两次还没过，就别再自动往返，把双方的理由整理好交给你决定。次数可以按任务轻重调整，关键是要有终点。

三、明代内阁：所有事都等皇帝批，皇帝就成了瓶颈

明初废除丞相，六部直接向皇帝负责，大量政务也就集中到了皇帝面前。

一个人批不过来，于是内阁逐步发展起来：阁臣通过“票拟”先替皇帝整理奏章、拟好处理意见，皇帝再批。这确实减轻了负担，但内阁的实际分量，受到皇帝信任、阁臣地位等因素影响。

使用 Agent 时，也很容易碰到这种情况。Agent 每做一步都弹窗问你“可以吗？”，你就是那个批不完奏章的皇帝；你烦了，干脆全部点“允许”，又等于把玉玺交了出去，出了事才知道。

要减少这种负担，就得提前分好：哪些直接做，哪些做完告诉你，哪些先问。比如你可以这样规定你的Agent：

已有明确授权的日常动作，就按约定执行，不用每次重新问。权限怎么分，还要结合实际影响，做个人的定制化。

票拟这种先整理、再交你决定的办法，也可以借一点：让 Agent 把需要你决定的事，整理成“背景 + 两三个选项 + 它的建议”。避免把一堆原始材料扔过来，再问你“怎么办”。

不过，还是需要留意，如果 Agent 只给你看它筛选过的摘要，你可能连它漏掉了什么都不知道。重要结论要能追溯到原始资料。

四、宪制：权力要写进制度，不能靠自觉

内阁解决了“批不过来”，但没解决“批错了怎么办”。近代西方宪制给出的思路是：掌权者本身也要被约束。

英国1688—1689年的政治变化和《权利法案》，限制了王权、强化了议会地位；美国1787年宪法让国会、总统、法院分担职能、相互制约。十九世纪，英国又推进职业文官制度，让专业执行人员相对稳定。这些安排的共同点是：谁能决定、能决定什么、谁负责执行，要有明确的制度安排。 这些制度也有协调成本，分权之后可能出现僵持，稳定的程序也可能变得僵化。

落到Agent的管理中，重要限制得落到工具和权限里，光在提示词里嘱咐一句，还不够。在提示词里写“不要删除文件”，只是一句口头嘱咐，模型误判或受到错误指令影响，仍可能调用删除操作。把删除命令设成必须确认，或者干脆不给它这个工具，才有实际的执行边界。

配置支持权限控制的工具时，可以区分允许、询问和禁止的操作；不想让 Agent 花钱，就别给它能付款的账号。同理，负责执行的 Agent 不能为了赶进度自己放宽验收标准，也不能给自己加权限。

五、泰勒：先摸清怎么做，再把做法固定下来

工业化以后，同一种活，每个工人做法不同，效率差别很大。弗雷德里克·泰勒提出科学管理：观察一项工作怎么完成，比较不同做法，把有效的方法整理出来，用于培训和执行。

它的价值是让重复工作不再靠个人摸索；局限是创造性工作很难提前规定每一步，过度追求计时提速，还会忽略人的经验和自主性。

这就很适合反复做的任务。先跑通、再验证，稳定下来以后，整理成 Skill 或固定流程。 还没摸清楚怎么做的，不用规则提前写死。比如每周的数据周报：数据从哪来、怎么清洗、怎么算、检查哪几项，验证好以后保存成脚本或 Skill。下次 Agent 只需要处理新数据和异常，不用重新摸索，你也不用每次重新交代。

但如果是研究一个陌生行业，最好的方法还不知道。这时只固定来源要求和记录格式，检索路线留给 Agent 调整。没验证过的步骤过早固化，只会让错误稳定地重复。

六、斯隆与通用汽车：业务自己管，总部管方向和协调

通用汽车有多个品牌和业务，全由总部决定会脱离实际，完全放任又会互相打架。阿尔弗雷德·斯隆推动的办法通常被概括为“分散经营、协调控制”：各业务单元自己经营、对结果负责，总部保留财务、政策和整体协调。事业部制由此成为大企业的常见组织方式，但是缺点是是重复建设、争资源和只顾局部。

你同时推进几条线的工作，就可以按项目分开管。每条线谁负责、交什么、能用多少资源，都先放在规则里。

如果你同时让 Agent 帮你写内容、做开发、整理数据，可以给每条线一个独立的项目文件夹、说明文件和会话，各自在约定的权限里推进。你把注意力放在整体进度、哪里卡住了、最后结果怎么样。共用的资料规范和模板放在一个地方统一管理。

反过来，只有一个小任务，却先建一个“总控 Agent”、三个“部门 Agent”，省不了事，只会多出转述和等待。多 Agent 本身就有协调成本，Agent 的数量和层级应该由工作量决定。

七、德鲁克：别只布置动作，要讲清要什么成果

1954年，彼得·德鲁克在《管理的实践》中系统提出“目标管理与自我控制”：让每个人的工作目标和整体目标连起来，执行者知道自己要产出什么，方法可以自己选，并能根据结果自我检查。

但是这个系统的风险也很突出：目标定错，或者指标替代了真正想改善的事。比如说职场里常见的问题，客服只考核接待时间和接待量，数据可能很亮眼，但客户的问题依然没有解决。

所以，给 Agent 布置任务时，需要多嘱咐两句：最后交付物是什么，我怎么判断它做对了。

比如，在写文章时，只去说“写五千字”“搜二十个来源”，这些只是规定的硬性动作，但你很难判断是否真的有满足你的需求。更好的写法是：这份东西给谁看、帮他做什么决定、关键结论需要什么证据、查不到的信息怎么标注。

Agent 可以自己选方法，但交付时要证明这些要求都满足了。验收时你看的是：比较全不全，来源撑不撑得住结论，不知道的有没有老实说。

八、丰田：按需要生产，发现异常就停下来

丰田生产方式有两大支柱：准时化和自动化。准时化是按下游的实际需要安排上游生产，减少无用的堆积；自动化是发现异常就停下来，不让缺陷继续流到后面——设备发现问题会停机，工人发现问题也可以发出信号、叫停生产。

它把注意力从“每个工位忙不忙”，转到“整条流程顺不顺、质量好不好”。

我们自己用 Agent，也要看整个生产线，去衡量整体的运营效率。前面做得再快，后面跟不上，交付照样慢。在运营管理里面，我们把制约整体效率的环节，成为瓶颈（bottleneck）。一条生产线的效率，是瓶颈处的效率决定的。

假设写作 Agent 一小时能出三篇，可你一天只看得过来一篇——瓶颈是你的审稿。这时再加写作 Agent，只会让待审稿件越堆越多。应该先限制同时进行的任务数，或者把一部分检查交给工具，再考虑加产出。

再比如，发现某个资料来源有问题，就让依赖它的写作、配图、发布文案都先停下，修正后再继续。停下时写清原因、谁来处理、什么情况下恢复，否则“停下”又会变成一个没人管的卡点。

这也不等于一味压缩资源。必要的备份和恢复能力还得留着，否则一个环节出问题，整条流程都可能停摆。

九、Scrum 与敏捷：先交一小块，看对不对，再往下做

二十世纪九十年代初，肯·施瓦伯和杰夫·萨瑟兰发展了 Scrum；2001年，17位软件开发实践者共同形成《敏捷宣言》，强调协作、可用成果和响应变化。

以 Scrum 为例，可以在短周期内先交出一部分可用成果，和使用者一起检查，再调整下一步。这样需求误解会更早暴露，返工范围更小。代价是反馈本身要花时间，每听到一个意见就推翻重来，团队会一直被打断。

长任务就可以借鉴这样的做法：先拿一小块出来，看方向对不对，再往下展开。

让 Agent 写一篇长文，先看提纲和第一段；做一个工具，先跑通一个核心功能。这时候先确认方向，逐字润色可以放到后面。确认之后，已经明确的部分就让它直接做，只有会改变方向或范围的问题才回来问你。

十、多个 Bot 怎么管？只有一个 Agent，又怎么管？

前面讲了这么多，我们放到两种情况里看看：一群 Bot 一起干活，以及你只带一个 Agent。

像 GrokBot 这样，几个 Bot 一起做一篇内容

比如我想让几个 Bot 合作，写一篇介绍新 AI 工具的文章，再配上我的 IP 插图。可以这样安排：一个查资料，一个写文章，一个做图，再指定其中一个兼任负责人。我只跟负责人交代目标，它负责分任务、追进度，最后交给我完整的图文。 不然四个 Bot 都来找我，我反而更忙了。

怎么避免各干各的？让它们看同一份任务单：写给谁看、讲哪几个点、谁交什么，都放在里面。查资料的把结果交给写作的，正文定下来再交给做图的。谁还没做完、谁在等谁，也记在这里。这样负责人才能知道该催哪一步，而不是让所有 Bot 一直输出。

写作 Bot 和查资料的 Bot 意见不一样怎么办？事实问题就拿来源核对；一般的表达取舍，负责人按我的要求定。真要改文章方向，再来问我。也可以约定：同一个问题改两轮还没解决，就带着分歧和建议来找我，别互相退稿没完没了。

最后，负责人把正文和图片放在一起检查，再交给我看。负责写稿、做图的 Bot 不需要发布权限，发布账号也不用每个都给。有分工，也得有人对整件事负责。 这就把前面讲的分工复核、统一协调和分级授权接起来了。

只有一个 Agent，帮我改网站

比如我只想给现有网站加个简单的报名功能。为什么不多叫几个 Agent 一起做？因为表单怎么填、信息怎么存，本来就得一起考虑，一个 Agent 顺着做就能完成。硬拆成几个，每个都得重新看一遍项目，还要互相等、对接口，最后再找一个合起来，可能更慢、也更费额度。

有几个步骤，不代表就需要几个 Agent。 等到任务里有几块能各自推进的工作，或者需要另一个 Agent 专门检查，再考虑拆开。

所以这次就交给一个 Agent，把结果说清楚：“用户能报名，我能看到名单。这次先做这两件事，做个预览给我看。”

接着把权限给到位：项目里的代码可以改、测试可以跑；这次没要求上线，就先不给它正式发布和改线上数据的权限。已经说好的事情让它自己推进，不用改一行就来问我。

先做出一个能报名的版本，我试过没问题，再把提示这些细节补好。如果一个错误反复改不好，就停下来告诉我卡在哪、试过什么，别一直重试消耗额度。

最后让它把做好的页面和检查结果一起交来，我实际报一次名，看看名单里有没有。跑通的开发、检查步骤可以存成 Skill，下次接着用。管一个 Agent，重点就是交代清楚、给对权限，最后看结果。

所以，一个 Agent 也需要管理；多个 Bot 在这基础上，还得解决谁分任务、怎么交接、意见不一致谁拍板。先把这些安排好，增加 Bot 才可能帮你省事。

十一、最后留一张总结表、一份任务单

一张表，回看前面的办法

任务单模板

【任务】一句话说清要做什么
【给谁用】谁使用，解决什么问题
【范围】这次做什么、不做什么；可改哪些文件、可用哪些资料
【验收标准】
- 开发：关键路径、异常处理、权限检查……
- 内容：事实、口吻、图文对应、文件完整……
- 无法验证的项目明确标出
【权限】
- 直接做：……
- 做完告诉我：……
- 尚未授权时先问我：发送、发布、删除、花钱、注册账号
- 不允许做：……
【预算与停止条件】最多花多少时间 / 额度；修复上限几次；到上限交给谁处理
【交付】交什么、放在哪；先交最小版本或样稿
【协作】谁负责哪部分，谁合并；冲突由谁处理
【外部动作】是否包含上线 / 发布，以及对应授权

回到最初那个质疑：三省六部当然不完善，但它让人一眼看懂“分工”。真要让 Agent 跑起来，还得把授权、记录、复核、调度、验收一块块补上，前面这些管理方法，就能帮我们少摸索一些。

先让一件真实的事从交办跑到验收，再决定需要几个 Agent、几层管理。

关于作者

Punk｜中科大管理学硕士｜AI提示词、AI小白教程｜Punk系列Skills作者｜3个月赚了8位数｜Learn in Public｜FDE文章浏览量240w｜@AdrianPunk115