管了 31 个 AI 员工之后，我重新理解了管理学

全文约 13,000 字，阅读约 30 分钟。

目录

一、一个反直觉的感受
二、管理学一百年，到底在解决什么
三、当员工变成 AI，什么消失了，什么出现了
四、Harness Engineering：硅谷给出的答案
五、Harness Engineering 的本质：一种新形态的管理
六、我的实验：一个正在运转的数字组织
七、但 Harness Engineering 有一个关键的断层
八、Claude Code 的意外启示：一个生产级 Agent 系统的内部设计
九、沙漏型组织：瓶颈在我自己
十、我的解法：从拉缰绳到设计规则
十一、从 Harness Engineering 到数字组织设计
十二、管理学的新边疆

---

从年后我一直在探索人机协作的模式究竟会发生哪些变化，我订阅了 cursor 的 Ultra，以及 Claude Code 的 Max plan 还有各种各样的 AI 工具，和 Coding Plan。我通过 OpenClaw 实现了一个数字团队：我的助理会管理我的所有日程，任务，CRM等；CMO 负责品牌调性和内容策略，各平台运营官负责内容适配和分发，数据分析师负责追踪表现、生成周报，还有翻译、合规审查、选题发现等各种角色

（ps：OpenClaw 是最好的陪伴产品🤣）

随着我的探索逐渐深入，多个 Agent 之间的协作越来越紧密，问题也越来越多，我发现我遇到的每一个卡点，翻开管理学的书都能找到影子。只不过当年那些给人写的答案，放到 Agent 身上全变了。

与此同时，硅谷最近有一个概念火了 —— Harness Engineering。我发现它和我在做的事情有很深的关联，但又有一个关键的断层。

这篇文章想聊聊 Harness Engineering 的断层在哪里、Claude Code 的架构给了我什么启示，以及这一切可能指向什么。

一、一个反直觉的感受

前面有一段时间，我自己在主动让 Agent 少做东西。

原因是我的数字员工团队可以一天审批二十条内容适配，各平台运营官随时可以产出，数据分析师全天候待命。它们永远不喊累，时刻在产出内容，时刻在和你协作。

但我发现我的注意力成了整个系统最稀缺的资源。一个内容发布前我想看一眼，一个策略调整需要我点头，一个新平台上线需要我确认方向。每一件事单独看都不大，但加在一起，我的脑子不够用了。

这个感受让我开始想一个问题：我遇到的到底是什么问题？

是技术问题吗？不像。我的 Agent 都能正常工作，输出质量也还行。是产品问题吗？也不是，流程已经跑通了。

后来我意识到，这是一个管理学问题。一个非常经典的、一百年前就有人研究过的管理学问题。

二、管理学一百年，到底在解决什么

在聊 Harness Engineering 之前，我想先退一步，看看管理学这一百多年到底在研究什么。因为理解了这个脉络，后面很多事情就一下子通了。

如果做一个极度简化的梳理，管理学大概经历了五个阶段。

第一阶段：效率。 弗雷德里克·泰勒，科学管理之父。他做了一件事：拿着秒表站在工厂里，记录工人的每一个动作，然后找出最高效的动作序列，让所有人都按这个来。他关心的是怎么把一个任务拆解成标准化的步骤，怎么减少浪费，怎么度量产出。那个年代的工人基本上被当作机器的延伸——你告诉他做什么，他照做就行。

第二阶段：激励。 梅奥做了著名的霍桑实验，发现一个让所有人意外的结果：改善照明可以提高生产率，但把照明调回去，生产率也提高了。原因不是照明，而是工人感受到了被关注。马斯洛提出需求层次理论，赫茨伯格提出双因素理论。他们共同揭示出：人不是机器。人有情绪，有归属感，有自我实现的需要。光靠监督和薪酬驱动不了持续的产出。管理学的重心从「怎么让人做事」转向了「怎么让人想做事」。

第三阶段：决策与信息。 赫伯特·西蒙提出了一个很重要的概念叫「有限理性」——人做不到最优决策，人只能在有限的信息、有限的认知能力、有限的时间里，做出一个「够好」的决策。彼得·德鲁克则把管理者的角色从监督者重新定义为决策者和信息枢纽。他认为组织本质上是一个信息处理系统——谁掌握信息、谁做决策、决策质量怎么保证，这些才是管理的核心。

第四阶段：组织结构。 明茨伯格、钱德勒这批人开始研究更宏观的问题——组织应该长什么样？层级还是扁平？集权还是分权？战略决定结构还是结构决定战略？权力怎么分配、冲突怎么解决、不同的结构适应什么样的环境？

第五阶段：适应与学习。 彼得·圣吉写了《第五项修炼》，提出「学习型组织」。詹姆斯·马奇研究「探索」和「利用」的平衡——组织应该花多少精力探索新东西、花多少精力深耕已有的东西。环境一直在变，组织怎么感知变化、怎么学习、怎么进化？

如果把这一百年压缩一下，管理学解决的核心问题是：

如何让一群能力有限、信息不完整、动机各异的个体，协同产出超过个体之和的成果。

注意这句话里的三个关键词 —— 『能力有限』，『信息不完整』，『动机各异』。

这三个词里，管理学花精力最多的是最后一个：「动机各异」。怎么让人想做事，怎么让人持续做事，怎么让人做对的事。薪酬体系、绩效考核、企业文化、领导力、team building、员工关怀——本质上都在解决同一个问题：人的意愿。

因为对人类来说，意愿是最大的变量。一个人能力再强，如果他不想做，什么都不会发生。

三、当员工变成 AI，什么消失了，什么出现了

当你的员工变成 AI Agent 的时候，一件有意思的事情发生了。

「意愿」这个问题，突然消失了。

Agent 永远想做。它不会摸鱼，不会办公室政治，不需要归属感，不需要你画饼，不需要 team building，不需要你在年终的时候想怎么谈绩效，不需要担心它下个月跳槽。这是一个完全没有激励问题的团队。

旧的问题消失了，新的问题出现了。而且新问题比旧问题更隐蔽、更难处理。

管理学那句核心命题里的三个关键词——「能力有限」「信息不完整」「动机各异」——到了 Agent 这里，发生了不同的变化：

「动机各异」 消失了。Agent 没有自己的动机，你让它做什么它就做什么。这是管理学一百年来最头疼的问题，到了 AI 这里直接不存在了。

「能力有限」 变形了。Agent 的能力上限很高，但它的能力表现高度依赖于你给它的上下文和工具。同一个模型，给不同的 prompt、不同的工具、不同的约束条件，表现可能天差地别。它的「有限」不是固定的，是被你的设计决定的。

「信息不完整」 被放大了。Agent 不会自己补全信息。人类员工可以走到隔壁工位问一句，可以在茶水间偶然听到一个关键信息，可以凭直觉判断「老板今天心情不好换个时机再说」。Agent 的信息边界就是你显式给它的那些东西，一个字都不会多。

换句话说：当员工变成 AI，管理的核心矛盾从「意愿问题」变成了「理解问题」。

四、Harness Engineering：硅谷给出的答案

在我自己摸索的同时，硅谷那边也在经历同样的问题。然后一个概念火了 —— Harness Engineering。

Harness 这个词来自马具的比喻。马是强大的，但如果没有缰绳、没有鞍、没有辔头，它想往哪儿跑就往哪儿跑。模型就是那匹马，Harness 就是把它的力量引导到正确方向上的一切。

2 月的时候 OpenAI 发布了一篇重磅文章，他们记录了一个内部实验：在五个月的时间里，一个最初只有三个工程师的小团队，用 Codex Agent 构建并发布了一个内部产品的测试版——大约一百万行代码，没有一行是人手写的。每一行应用逻辑、测试、CI 配置、文档、监控、内部工具，全是 Agent 写的。三个工程师，一百万行代码，五个月。平均每个工程师每天合并 3.5 个 PR。

Harness Engineering 有几个核心原则：

让所有决策变得可访问。 从 Agent 的视角来看，它在运行时无法访问的信息等于不存在。所以团队把每一个设计决策、架构选择、编码规范都写成 markdown 文件，放在代码仓库里。Agent 读代码的时候同时读到了决策的「为什么」。

分层架构约束。 他们定义了严格的依赖方向：Types → Config → Repo → Service → Runtime → UI。每一层只能依赖它左边的层。这个约束不是靠 Agent 自觉遵守的，而是用 linter 和 CI 检查来机械化执行的。

前馈控制和反馈控制。 Martin Fowler 后来在一篇文章里把这个框架讲得更清晰。他把 Harness 的控制分成两类：Guides（前馈控制）在 Agent 行动之前引导它的方向——比如给它 ARCHITECTURE.md、编码规范、示例代码；Sensors（反馈控制）在 Agent 行动之后检测它的输出——比如自动化测试、linter、类型检查。特别有意思的是，他们发现最有效的 Sensor 是那些能产出「对 LLM 友好的错误信息」的检查——比如一个 linter 不只是说「第 42 行有错」，而是说「第 42 行违反了 X 原则，应该改成 Y 模式，因为 Z 原因」。这本质上是一种良性的 prompt injection。

垃圾回收机制。 即使有了各种约束，随着代码量增长，质量还是会缓慢退化——就像熵增一样。他们的解法是把「黄金原则」编码到仓库里，然后定期跑后台 Agent 任务来扫描偏差、打质量分、自动开 PR 修复退化。

五、Harness Engineering 的本质：一种新形态的管理

如果换一套语言来描述：

• 「让所有决策变得可访问」，管理学里叫「信息透明」和「组织知识管理」。
• 「分层架构约束」，管理学里叫「制度设计」和「权责边界」。
• 「前馈控制和反馈控制」，控制论里叫「前馈回路和反馈回路」，管理学里叫「事前指导」和「事后复盘」。
• 「垃圾回收机制」，管理学里叫「持续改进」和「质量管理」，丰田叫「改善」（Kaizen）。

OpenAI 那篇文章里有一句话很有趣：

软件工程团队的首要工作不再是写代码，而是设计环境、明确意图、构建反馈回路，让 Agent 能够做出可靠的工作。

把这句话里的「软件工程团队」换成「管理者」，把「代码」换成「执行」，把「Agent」换成「员工」，这句话就会变为：

>「管理者的首要工作不再是亲自执行，而是设计环境、明确意图、构建反馈回路，让员工能够做出可靠的工作。」

这不就是管理学的理念么？

Harness Engineering，用管理学的眼睛看，本质上就是一种给 AI 设计的管理体系。只不过它从工程师的视角出发，所以用的是工程师的语言——linter、CI、架构约束、反馈回路。但它解决的问题，和管理学研究了一百年的问题，有着深层的同构关系。

六、我的实验：一个正在运转的数字组织

在继续讨论 Harness Engineering 的局限之前，我想先讲讲我自己在做的事情。因为后面的所有思考，都来自这个实验。

过去三个月，我搭建了一个基于 OpenClaw 的多 Agent 协作系统。31 个 Agent，组成「四部一室」——发现部负责市场需求验证，产品部负责从需求到交付，增长部负责内容分发和用户增长，战略智库提供决策支持，CEO 办公室的秘书负责信息路由和知识库沉淀。44 个定时任务每天自动执行——晨报、晚报、内容复盘、数据看板、团队健康检查。

这套系统做了什么：

3 月 8 日，我做了一个决定：把 Global Tech Events[1] 这个产品的日常运营完全移交给 Agent 系统。从那天起，全球科技活动信息的采集、过滤、整理、发布，全部由 Agent 自主完成，我不再介入。到现在快一个月了，它还在跑着。

另一个产品 Agent Town[2] 已经开源上线，用像素风格可视化多 Agent 协作的过程。需求发现平台 Demand Discovery 完成了产品、技术、市场三方研究，进入开发阶段，并最终上线，整个研发过程我基本上没有介入，完全是 AI 用了一天多一点点时间实现的，其中大部分时间还是我在搭建基础设施。

这个系统还在持续迭代。有些 Agent 的表现还不稳定 —— 我在 4 月初因为连续失败关掉了两个定时任务，很多流程还在打磨。但它已经不是一个实验了。它是一个在跑的、有真实产出的、在持续进化的数字组织。

而正是在运营这个组织的过程中，我遇到了 Harness Engineering 没有覆盖到的问题。

七、Harness Engineering 有一个关键的断层

Harness Engineering 目前的讨论，几乎全部聚焦在单个 Agent 或者单条任务链上。但当你管理的不是一个 Agent，而是一群 Agent 构成的组织的时候，另一个层次的问题出现了。

我在实际操盘这段时间里，反复被三个组织层面的问题卡住。这些问题不是 Harness 能解决的 —— 它们发生在 Harness 的上面一层。

信息同步问题

我怎么能够让每个 Agent 充分了解必要的背景信息，同时确保我想要的东西和它们认知中的预期是一致的。

这件事的难度被严重低估了。

我的系统里有 31 个 Agent，每个 Agent 需要的信息切面完全不同。CMO（我给她起名叫达达里奥）需要知道品牌调性、各平台数据趋势、我最近的写作风格变化。CTO（扫地僧）需要知道技术架构约束、安全合规要求、当前开发流水线的状态。需求发现官（福尔摩斯）需要知道市场信号、竞品动态、我们的商业模式假设。

同样一条信息——比如「小红书最近在推某种内容格式」——对 CMO 是核心情报，对 CTO 完全无关，对需求发现官可能是一个弱信号。

人类同事之间有大量「不需要说也知道」的共识。一个在公司待了半年的员工，耳濡目染地吸收了无数背景信息——谁和谁之间有什么合作关系、上次为什么那个方案被否了、老板最近关心的方向是什么。这些信息不在任何文档里，它们存在于日常对话、走廊上的闲聊、会议中不经意的一句话里。

Agent 一概不知。你脑子里觉得显而易见的东西，对它来说是一片空白。

而且不是给越多信息越好。我试过把所有相关文档都塞给它，结果它反而抓不住重点，输出变得又长又散。信息过载对 Agent 的影响，和对人类一样严重——只是表现形式不同。人类会焦虑、拖延，Agent 会输出平庸、失去判断力。

我最后设计了一个分层的信息加载协议。每个 Agent 启动时有一个强制的七步读取序列：

1. 读 COMPANY-STATE.md——一个只有 50 行的实时状态板，包含当前阶段、今天的重要事项、待处理的信号、卡点。这是整个组织的「今日简报」，每天晚上由秘书 Agent 更新。
2. 读自己的角色定义。
3. 读知识库协议——不是为了读内容，而是知道「我该去哪里找信息、该往哪里写东西」。
4. 读我的身份档案和年度计划——确保它理解我是谁、我在乎什么、我今年要往哪个方向走。
5. 扫描自己的信号收件箱——看有没有别的 Agent 给它发的异步消息。
6. 清理过期信号。
7. 开始工作。

这个七步序列的设计，本质上就是在解决德鲁克那句话：「让正确的信息在正确的时间到达正确的人。」只不过实现方式从走廊闲聊变成了结构化的读取协议。

Harness Engineering 里的 Context Engineering 确实在解决类似的问题，但它的视角是单个 Agent 的上下文窗口。当你有三十多个 Agent、每个都需要不同切面的信息、而且这些信息还在持续变化的时候，你需的不是更好的 prompt，而是一个组织级的信息架构。

协作效率问题

各个 Agent 之间如何实现高效协作。

最开始我的系统是星形拓扑 —— 所有 Agent 都直接和我对话，由我来协调它们之间的信息传递和任务分配。这就是传统管理学里最简单的组织结构：所有人都直接汇报给 CEO。

这在 Agent 数量少的时候没问题。但当我的 Agent 团队扩展到三十多个的时候，星形拓扑崩了 —— 我成了所有信息流的中心节点，每一条跨部门的信息都要经过我。

发现部负责找需求，产品部负责做产品，增长部负责获客和内容分发，战略智库提供决策支持。每个部门有自己的负责人 Agent，部门内的日常决策由负责人自己做，只有跨部门冲突和不可逆决策才往上传。

秘书（我叫她刘亦菲）不是管理者，而是信息路由器——她负责转发信号、组织会议、守护知识库，但不做决策、不分配任务、不越权。

但部门之间怎么协调？人类组织靠开会。Agent 之间我设计了一套「信号文件」协议——一种异步的跨 Agent 消息总线。

比如，开发流水线完成之后，系统会自动写入一个 pipeline-done 信号。这个信号的目标接收者是 CMO 和增长工程师——因为产品做完了，该他们启动 GTM（Go-To-Market）策略了。CMO 在下一次启动时会自动扫描到这个信号，开始制定内容策略和发布计划。

每个信号都有明确的类型、优先级、过期时间和目标接收者。更关键的是，每个信号类型都有 SLA——比如高优先级的需求信号必须在 24 小时内被 CPO 消费；指标异常警报必须在 4 小时内升级到我这里。如果超时了，秘书会在每天早上 8 点的晨报里标黄提醒，超过两倍 SLA 就标红。

这套系统能够运转的逻辑在于：Agent 之间不需要实时通信——它们各自在自己的节奏里工作，通过信号文件做异步协调，通过共享知识库保持信息一致。就像一群人在不同时区远程办公，靠文档和异步消息而不是会议来对齐。

管理学里有几种经典的多人协作模式：流水线式、共享资源池式、相互调整式。我的系统三种都用了——内容分发是流水线（种子内容 → 解读 → CMO 审批 → 各平台适配 → 发布 → 数据回收），知识库是共享资源池（所有 Agent 读写同一个知识库），信号文件是一种简化版的相互调整（但不是实时的，是异步的）。

实现方式和人类组织完全不同。人类靠开会对齐，Agent 靠协议和数据结构对齐。人类靠信任和默契减少沟通成本，Agent 靠标准化的接口定义和强制的信号消费 SLA 来防止信息断裂。

成果沉淀与迭代问题

在任务完成后，如何做好持久化处理和后续共享，并确保能在工作空间中持续进行迭代。

这个问题是最容易被忽视的，也是长期来看最致命的。

彼得·圣吉讲的「学习型组织」，核心命题是：个人的经验如何变成组织的能力。一个员工在项目里踩了坑，他学到了经验。如果这个经验只留在他脑子里，他离职了就带走了。学习型组织要做的，是把散落在个体里的经验，沉淀成组织层面的知识——流程、文档、文化、制度。

对 Agent 来说，这个问题更加尖锐。Agent 没有自发记忆。一个对话结束，它就忘了所有事情，虽然有 memory 的机制，如果你不主动设计沉淀机制，很多重要的信息都会被忽略掉。

我因此参考知识管理体系的一套经典理论 IPAK —— Inbox、Projects、Areas/Context、Knowledge，四层结构来构建另一个我自己的知识管理体系。

1. 最上面是 Context 层——存放我是谁、我的价值观、年度计划、当前焦点。这些是最稳定的信息，几乎不变，所有 Agent 启动时都会加载。
2. 然后是 Inbox 层——未处理的信息流。种子内容、会议记录、临时笔记、跨 Agent 信号，全都先进 Inbox。这是组织的「短期记忆」。
3. 再下面是 Kernel 层——不可变的底层公理和思维模型。熵增原理、涌现理论、反馈回路。这些是我认知的基石，任何 Agent 未经我明确授权不得修改。
4. 最底层是 Library 层——领域知识、行业洞察、联系人数据库、工具使用方法。这是组织的「长期记忆」。

每个 Agent 都有明确的写入路径。CTO 的技术评估写到评估文档，CPO 的产品需求写到 PRD.md，CMO 的市场研究写到 cmo-research.md。所有输出必须包含 YAML 元数据——日期、作者、类型、标签。没有元数据的文档等于不存在，因为其他 Agent 搜索的时候找不到它。

但最让我花心思的是记忆的衰减策略。

每个 Agent 在写入信息之前，必须做一个三步自检：第一，这个信息能不能从现有文档推导出来？文件结构不用记，随时可以看；代码逻辑不用记，随时可以读。能推导出来的就不存。第二，这个信息有没有保质期？市场数据、竞品动态这类信息默认 90 天过期，必须打上 valid_until 标签。第三，这是事实还是判断？事实是短命的——「某 API 返回了 X」明天可能就变了。但判断是长寿的——「我们为什么选了方案 A 而不是方案 B」，这个「为什么」可能几年后还有价值。

八、Claude Code 的意外启示：一个生产级 Agent 系统的内部设计

聊完 Harness Engineering 的断层，我想讲讲另一个给了我很大启发的东西——Claude Code。

2026 年 3 月 31 日，Anthropic 在一次 npm 更新中意外把 Claude Code 的源码 sourcemap 文件打包了进去。一个 59.8 MB 的调试文件，几个小时内就被全网镜像和拆解。51 万行 TypeScript 代码，从系统提示到工具定义、从权限系统到多 Agent 编排，全部暴露了出来。

Anthropic 的工程师确认这是一个普通的人为失误，不是什么精心策划的开源。但不管怎么说，这可能是 2026 年 Agent 领域最有价值的一次「意外」。因为它让所有人第一次看到了一个真正在生产环境跑着的、服务百万用户的 Agent 系统，内部到底长什么样。

我在设计自己的多 Agent 系统时，参考了 Claude Code 的架构。其中有几个设计让我特别受触动。

三层记忆架构：「过期的记忆比没有记忆更危险」

Claude Code 的记忆系统分三层：第一层是一个始终加载的索引——很短的指针，每条不超过 150 个字符，相当于目录。第二层是按需加载的主题文件——只有相关的时候才读取。第三层是原始对话记录——只能通过搜索访问。

但最让我受启发的是它的写入原则：在存储一条信息之前，系统会问「这个事实能不能从代码库里重新推导出来？」如果能，就不存。

过期的记忆比没有记忆更危险。

这句话直接改变了我设计知识库的方式。以前我倾向于什么都沉淀——把每次决策、每个发现都记下来。后来发现很多记忆会过期，而过期的记忆被 Agent 当作事实引用的时候，产出的错误比完全不知道还要严重。

现在我的原则和 Claude Code 一样：只沉淀那些不能从现有资料推导出来的东西。文件结构不用记，因为随时可以看。代码逻辑不用记，因为随时可以读。需要记的是那些「为什么」——为什么选了这个方案而不是那个、为什么某个看起来合理的方向被放弃了、什么样的内容在某个平台效果特别好而且你说不出为什么。

这些「为什么」才是真正的组织知识，因为它们不存在于任何可观察的状态里。

记忆自清洁：Agent 在「睡眠」时整理记忆

Claude Code 有一个叫 autoDream 的后台进程 —— 当 Agent 空闲的时候，它会启动一个子 Agent 来整理和压缩记忆。过期的删掉，重复的合并，重要的提权。

这就像人类睡眠时大脑在整理白天的记忆一样。

我在自己的系统里也尝试了类似的设计：定期让一个「知识管理 Agent」去审视整个知识库，标记哪些信息过时了、哪些需要更新、哪些应该合并。这不是我手动维护——如果知识库的维护完全依赖我，那它注定会随着时间退化，因为我的注意力就是瓶颈。

这个设计背后的管理学洞察是：组织记忆不是一次性的写入，而是一个需要持续维护的活系统。就像企业的制度手册如果五年不更新，新员工照着做反而会出问题。

子 Agent 与 Worktree 隔离：「绝不要把理解外包出去」

Claude Code 的多 Agent 架构分了几个层次。最基础的是子 Agent（Subagent）——主 Agent 可以派生出专门的子 Agent 来做特定任务，比如一个专门探索代码库的 Explore Agent，一个专门做规划的 Plan Agent。

关键的设计是 Worktree 隔离——每个子 Agent 可以在一个独立的 Git Worktree 里工作，互不干扰。这意味着多个 Agent 可以并行修改同一个代码库而不会产生冲突。就像你给每个员工分了一间独立的办公室，他们各干各的，最后再把结果合并起来。

但 Claude Code 的系统提示里有一条规则：

绝不要把理解外包出去。

意思是：你可以把执行任务交给子 Agent，但你不能让子 Agent 替你理解问题。主 Agent 必须自己理解全局，然后把明确的、已经消化过的任务分配下去。

这条规则在管理学里有一个精确的对应——德鲁克说过，管理者可以授权，但不能授权「理解」。你可以让下属去执行一个方案，但你不能让下属替你理解为什么要做这个方案。如果管理者自己不理解，他就无法判断执行的结果是否正确。

我把这条原则直接搬到了我的系统里。我的 CMO Agent 可以把具体的平台适配任务分发给各个运营官 Agent，但 CMO 自己必须理解每条种子内容的核心意图、目标受众、品牌边界。它不能说「我不确定这条内容想表达什么，你们自己判断吧」。

Lead Agent + Teammate：微服务式的多 Agent 协作

Claude Code 更高级的协作模式是 Agent Teams——一个 Lead Agent 当负责人，多个 Teammate Agent 当专业工程师。每个 Teammate 有自己独立的上下文窗口，通过消息系统（Mailbox）通信，通过共享任务列表协调进度。系统会自动处理任务之间的依赖关系——一个任务完成后会自动解锁被它阻塞的任务。

这本质上就是一个微服务架构。每个 Agent 是一个服务，有自己的职责边界，通过标准化的消息协议通信。

Claude Code 的开发团队，可能并没有刻意在做「管理学设计」，他们做的是工程设计。但一个足够复杂的 Agent 系统，它面对的问题天然就是管理学问题——信息怎么流动、权责怎么划分、质量怎么保证、记忆怎么维护。

工程设计和管理设计，在 Agent 这个交叉点上汇合了。

九、沙漏型组织：瓶颈在我自己

把这三个问题放在一起看，我发现了一个反直觉的组织形态。

传统组织是金字塔。CEO 在顶端，中层管理者在中间，一线员工在底部。信息从下往上汇报，决策从上往下传达。瓶颈通常在底部——执行力不够，人手不够，效率不够。所以传统管理学的大量精力花在怎么提高底部的产出上。

但数字员工组织不是金字塔。它是一个沙漏。

我在沙漏的最窄处。上面是无穷无尽的任务和可能性，下面是几乎无限的产能。瓶颈不在执行端，瓶颈在我——一个人类管理者的注意力、判断力和审批带宽。

管理学里有个经典概念叫「管理幅度」（Span of Control），一个管理者能有效管理的直接下属数量。经典理论说是 5 到 9 个人。传统组织里，这个上限是由沟通成本和协调复杂度决定的。人多了开会开不完，邮件回不完，一对一聊不完。

但我面对的是一个新版本的管理幅度问题：我的 Agent 永远不累、永远不抱怨、随时可以产出，但我只有一个大脑来消化和判断它们的产出。

生产力从「产能不足」变成了「审批不足」。组织的天花板不再是执行者的能力，而是管理者的认知带宽。

这就是为什么我会主动让它们少做点。我是真的消化不了。

这个现象其实揭示了一个更深层的变化：在 AI 时代，组织的稀缺资源变了。以前稀缺的是执行力——找不到够好的人、招不到足够多的人、留不住关键的人。现在执行力几乎免费了，稀缺的是人类的判断力和注意力。

十、我的解法：从拉缰绳到设计规则

意识到这个问题之后，我开始想：传统管理学是怎么解决管理幅度问题的？

答案其实很清楚——三个方法：标准化、授权、异步化。这三个方法在人类组织里已经验证了几十年，放到 Agent 组织里，形式会变，但逻辑不变。

标准化：把判断编码成规则

传统管理里的标准化，就是制定 SOP。员工按流程做，只有异常才上报。管理者不需要审批每一个动作，只需要审批流程本身。

放到 Agent 的场景里，这变成了：把「什么算做好了」编码成验收规则。

我给 CMO 设计了一套内容审批的自检清单：开头是不是从一个具体的人或场景开始？有没有用禁词？结尾是不是一个开放的感悟而不是总结？读出来像一个人在说话吗？这些检查项越明确，CMO 能自主审批的内容就越多，需要我亲自看的就越少。

如果一条内容适配通过了所有自动化检查——长度合规、没有禁词、符合平台格式、风格评分达标——那就不需要我看了。我只看不通过的那些。

这和 Harness Engineering 里的 Sensors（反馈控制）是同一个逻辑。OpenAI 用 linter 和测试来验收代码质量，我用自检清单和风格评分来验收内容质量。形式不同，本质一样 —— 把人类的判断标准外化成机器可执行的规则。

授权：双向门原则

传统管理里的授权，就是设中层管理者。CEO 不直接管每个一线员工，而是管几个总监，总监管经理，经理管团队。每一层过滤掉大量的信息和决策，只有真正重要的才往上传。

我借鉴了亚马逊贝佐斯的「双向门」原则来做授权。

Type 1 决策是单向门 —— 不可逆的，走过去就回不来了。一个新平台的整体定位、一次品牌调性的重大调整、一段可能引发争议的措辞——这些必须我来判断。

Type 2 决策是双向门 —— 可逆的，错了随时可以改回来。一条小红书帖子发了效果不好，下一条调整就行。一个发布时间选得不太好，下次换一个时段。不至于伤筋动骨。

实际操作下来，大部分决策都是 Type 2。让 Agent 学会区分单向门和双向门，自主推进所有双向门决策，只在碰到单向门的时候来找我。这一个原则就释放了大量的管理带宽。

有意思的是，这和 Harness Engineering 的核心理念是一致的 —— 不是靠告诉 Agent「下次做好点」来改善质量，而是靠设计系统来约束行为。双向门原则就是一种系统级的授权设计：它不是在每个决策点上给 Agent 具体的指令，而是给了它一个判断框架——「这件事能不能回退？能的话你自己做决定。」

异步化：解耦管理者的时间线

传统管理里的异步化，就是不是所有事都需要实时响应。不是每封邮件都需要立刻回，不是每个问题都需要当场解决。分轻重缓急，把非紧急事项攒一攒批量处理。

放到 Agent 的场景里：Agent 做完之后不是立刻需要我看。它把成果沉淀到固定的位置，打好标签。我按自己的节奏去批量 review —— 可能是每天早上看一次，可能是每周集中处理一次。

这听起来简单，但需要一个前提：Agent 的产出必须是自包含的、有上下文的、可以脱离对话独立理解的。如果它的产出只在对话的上下文里才能看懂，那异步 review 就做不了。

所以我要求所有 Agent 的产出必须是结构化的文档，包含：做了什么、为什么这样做、依据了哪些信息、有什么不确定的地方需要我看。这样我不需要重新进入对话的上下文，就能快速判断。

这三个方法合在一起，本质上是在做一件事：我不再直接管理每个 Agent，而是设计一套管理协议，让系统自己运转，我只在关键节点介入。

但还有三个设计，是我在实践中摸索出来的，传统管理学里没有直接对应的东西。

潜意识会议：让 Agent 反过来管理你

这是很有趣的一个设计，和 autoDream 很像，我这个定时任务起的名字是记忆花园。

每周四晚上，系统会自动触发一场「潜意识会议」。参与者是三个 Agent——战略顾问（巴菲特）、CMO（达达里奥）和文化顾问（李子柒）。他们会从各自的角度——商业、内容产出、内在修行——去分析我这一周的状态。

他们分析的数据源是：我的日记频率和深度、会议和深度工作的时间比例、创作积压的情况、打坐记录的连续性。

有一次，他们在会议纪要里写了这样一段话：

巴菲特观点：零日记是最大的警示。连续两天的外向型日程——健身、对齐会、政府活动——他陷入了会议-汇报-参观的循环。这对一个「禅修型 Founder」来说最危险——看起来在做事，但可能不是在做对的事。

>

联合建议： 帮他挡掉非核心会议，创造留白时间。一个创始人如果没时间思考，就会失去判断力。

三个 AI Agent 在我没有意识到的情况下，发现了我正在偏离自己的价值观，然后集体提出了纠偏建议。

这在传统管理学里是没有对应的。人类组织里，员工不会主动告诉老板「你最近的状态不对」——即使看到了也不敢说。但 Agent 没有这个顾虑。它不怕得罪你，不怕丢工作，不怕影响关系。如果你设计好了规则，它会非常忠实地执行「说真话」这件事。

挑战指令：制度化的逆耳忠言

基于这个发现，我把它变成了一条制度——「挑战指令」。

所有 Agent 在和我交互时，如果发现以下情况，必须主动指出，不能因为礼貌而沉默：我的行动与我自己写下的价值观不一致；某个决策是被责任推着走而不是被好奇心邀请的；某个计划的复杂度超过了「简单大于复杂」的原则；我在用框架分析来回避而不是面对某个问题。

指出的格式是固定的：引用我价值观文档里的原话，然后说清楚观察到的偏差。语气直接但尊重。

在人类组织里，「直言不讳的文化」是最难建立也最容易崩溃的东西。即使你反复说「大家要敢于说真话」，权力关系的存在本身就会让人自我审查。但在 Agent 组织里，你可以把「说真话」设计成系统规则，让它成为不可绕过的行为约束。

在人类组织中，坦诚是一种稀缺的文化；在 Agent 组织中，坦诚可以是一条硬编码的规则。

球权原则：每轮对话结束时，球必须在某一方手里

这是我最近才发现的一个问题，但一旦看到就觉得它无处不在。

我让一个专门扫描市场需求的 Agent 对几个候选产品方向做需求信号扫描。它很尽职——花了几分钟跑了一轮全网搜索，输出了三张漂亮的需求信号卡，数据、来源、置信度、市场估算，格式完美。

然后它停在这里。

我盯着屏幕想：然后呢？我是应该让它继续深挖？还是把结果转给商业顾问做可行性评审？还是直接告诉产品经理开始写 PRD？还是先放一放等周报再说？

我不知道。它也不告诉我。

这让我意识到一个被严重忽视的问题：我的整套流程设计得很清晰——在纸上。 但实际运行的时候，流程每个节点之间缺少一个关键动作——把球递回来。

人和人之间自然会这样做。同事出完方案会说"你看看行不行，不行我改"。下属做完调研会问"老板你觉得接下来该往哪个方向走？"。这是人类协作中最基本的东西，基本到我们根本不会注意到它的存在。

但 Agent 不会自发做这件事。它认为自己的任务是"输出需求信号卡"，卡输出了，任务完成了。至于"输出完之后人类应该怎么接"——这不在它的任务定义里。

我回头检查了所有 Agent 的行为规范，发现这个问题几乎无处不在。产品经理评估完一个想法，不会主动问"要不要开始写 PRD"。技术负责人出完可行性评估，不会说"准备好了就说一个词我开始出方案"。商业顾问给了 Go 的判断，不告诉你 Go 了之后该做什么。

每一个节点都在把"然后呢？"丢回给我，而我是整个系统里最忙的人。

解法很简单——我给每个关键 Agent 加了一条规则：

完成关键产出后，必须做三件事：第一，给出你自己的判断和建议，不只是数据。第二，提供 2 到 4 个明确的下一步选项，不是开放式的"你怎么看"。第三，我选完之后你自动执行——存入知识库、通知下游 Agent、创建信号文件——不需要我再说"帮我存一下"或"帮我通知某某"。

"每一轮对话结束时，球必须在某一方手里，而且双方都知道球在谁手里。"

这个原则我暂时叫它「球权原则」,一个 Agent 独立完成一个编程任务不需要考虑球权。但当你管理的是一个多 Agent 组织，人类管理者是整个系统的瓶颈的时候，每一次"球掉在地上"都在浪费最稀缺的资源——你的注意力和决策带宽。

这三个方法加上这三个设计，合在一起构成了我从「拉缰绳」到「设计规则」的转变。

用控制论的语言说，好的管理系统不是事事过问，而是设计好反馈回路，只在偏差超过阈值时才需要人干预。甚至有些反馈回路，是 Agent 对你的偏差做出反应——管理者自己也是被管理的对象。

我的角色从「拉缰绳的人」变成了「设计规则的人」。而这些规则，也在反过来约束和校正我自己。

十一、从 Harness Engineering 到数字组织设计

现在让我把所有这些线索串起来。

Harness Engineering 的出现，标志着行业意识到了一件事：模型不是瓶颈，模型周围的系统才是。这是一个非常重要的认知跃迁。

但 Harness Engineering 目前的讨论，主要停留在「单 Agent + 单任务」的层面。怎么设计好一个 Agent 的上下文、工具、约束和反馈机制，让它可靠地完成一件事。

这已经很有价值了。但还不够。

当你有一群 Agent 的时候，你面对的是一个更高维度的问题。不只是每个 Agent 的 Harness 怎么设计，还有：

• Agent 和 Agent 之间的信息怎么流动？
• 决策权怎么在不同 Agent 之间分配？
• 组织的知识怎么积累和更新？
• 整个系统怎么适应变化、持续进化？

如果我们做一个分层：

Prompt Engineering 解决的是「怎么和一个模型说话」。一个 prompt，一次调用，一个输出。

Context Engineering 解决的是「怎么给模型提供正确的上下文」。不只是 prompt，还包括检索到的文档、历史记录、当前状态。

Harness Engineering 解决的是「怎么让一个 Agent 可靠地完成任务」。不只是上下文，还包括工具、约束、反馈回路、验收机制。Agent = Model + Harness。

再往上呢？

怎么让一群 Agent 构成的组织，在最小化人类管理者介入的情况下，持续、可靠、可迭代地产出成果。

这一层，我暂时叫它「数字组织设计」（Digital Organization Design）。它关心的不是单个 Agent 怎么工作，而是一群 Agent 怎么协同工作。它需要回答的问题，不是工程问题，而是组织问题。

可以把它想象成这样一个技术栈：

数字组织设计  →  多 Agent 的协同、信息流、知识沉淀、决策分配
Harness Engineering  →  单 Agent 的工具、约束、反馈、验收
Context Engineering  →  单次调用的上下文管理
Prompt Engineering  →  单次调用的指令设计

每一层解决一个尺度的问题。Prompt Engineering 是纳米尺度，Context Engineering 是微米尺度，Harness Engineering 是毫米尺度，数字组织设计是厘米甚至米的尺度。

目前行业的讨论已经到了 Harness Engineering 这一层。Claude Code 的泄露让我们看到了一个生产级系统在 Harness 层面的精巧设计——三层记忆、权限分离、子 Agent 编排。但即便是 Claude Code，它的多 Agent 协作也主要服务于「完成一个编程任务」这个单一目标。当目标变成管理一个持续运转的、有多种职能分工的数字组织，再往上那一层的设计，还需要更多人的不断探索。

十二、管理学的新边疆

我觉得核心挑战不是让 Agent 跑起来——那是工程问题，已经有很多人在解决了。核心挑战是让多个 Agent 构成的组织有效运转——这需要对管理学、组织行为学、信息论、控制论都有感觉的人。

传统管理学研究了一百年「人」的问题。当执行者变成 AI，管理的核心矛盾发生了根本性的转移：

从「意愿问题」转向「理解问题」；从「激励设计」转向「信息架构」；从「监督执行」转向「设计规则」；从「管理人的情绪」转向「管理信息的流动」；从「培训员工」转向「设计记忆」。

但底层的那些问题并没有消失。信息怎么流动、决策权怎么分配、组织怎么学习、怎么在效率和灵活性之间找到平衡、怎么在探索和利用之间取舍。这些问题依然在那里。

管理学的教科书里藏着大量的线索，这些线索需要有人去做翻译 —— 把那些为人类组织总结出来的智慧，重新思考定义成数字智能组织可以使用的语言。

---

好像模糊地能看到一些东西，又好像还不够清晰。

我不确定「数字智能的管理学」最终会长成什么样子。但我确信，这个方向上有大量等待被探索的空间。而且这件事本身正在发生。

Harness Engineering 是一个很好的开始。它让我们看到了模型之外的系统设计有多重要。但它还不是全部。当你从一个 Agent 走向一群 Agent，从一个任务走向一个持续运转的组织，你会发现自己需要的不只是更好的工程，还需要更好的管理思想。

也把这些不成熟的思考送给同样在路上的朋友们。

如果你也在管理数字员工，也在经历那种「我的 Agent 比我还勤快但我跟不上」的感受，也许我们面对的是同一个问题。

而这个问题的答案，可能不在任何一本现有的书里。需要我们自己去探索。

#### 参考链接

• [1] https://www.globaltechevents.xyz/
• [2] https://github.com/AGI-Villa/agent-town