原创解读：把 Notion 当成 18 个 Agent 的控制平面，最先要解决的从来不是'自动化'

版权声明与免责声明 本文基于《I Turned Notion Into a Control Plane for my 18 OpenClaw AI Agents》进行原创解读。原文版权归原作者与原出处所有。本文不构成官方翻译，仅用于学习、研究与观点讨论。

原文参考 I Turned Notion Into a Control Plane for my 18 OpenClaw AI Agents — AWS Heroes：https://dev.to/aws-heroes/i-turned-notion-into-a-control-plane-for-my-18-openclaw-ai-agents-5624

开头：多数多 Agent 系统死得不壮观，它们是被调度噪声慢慢拖垮的

王芳第一次觉得事情不对劲，是在一个普通的周三下午。她的团队刚刚把第十二个 Agent 接入 Notion 控制平面，理论上这应该是一个里程碑——从单点自动化走向了多角色协作。但当她看着 Notion 看板上那一排排跳动的状态标签时，心里却只有不安。

“处理中""等待中""失败-待重试""异常-需人工确认""已超时""部分完成”——这些状态像一群彼此礼貌却并不真正理解边界的实习生，各自忙碌，却不知道对方在做什么。一个数据清洗任务失败了，但它阻塞了下游的三个分析 Agent；一个报告生成任务超时了，但它占着数据库连接池不释放；一个原本应该自动重试的失败，因为状态标签被误标成了”需人工确认”，已经在队列里躺了六个小时没人管。

这不是崩溃，这是慢性窒息。系统不是不工作，而是工作得太吵。每一个 Agent 都在”完成任务”，但任务之间的关系、失败后的责任、人工介入的时机，全部模糊不清。

那天晚上，王芳在团队群里发了一条消息：“我觉得我们需要停下来，重新定义控制平面到底要解决什么问题。“消息发出去后，群里沉默了很久。最后，技术负责人回复：“你说得对，但我们现在停不下来，明天要交付。”

这句话道出了一个普遍困境：团队被裹挟在”更多自动化”的惯性里，却忘记了问一个更根本的问题——当事情不顺的时候，谁知道现在发生了什么，谁有权接手，系统怎么停得下来？

把 Notion 或任何其他工具做成多 Agent 控制平面，第一优先级从来不是”让更多任务自动流起来”，而是先回答这个更现实的问题。

先判断你处在哪个阶段

如果你正在建设一个多 Agent 控制平面，我建议先判断自己处在哪个阶段，而不是一上来追求”完整平台”。王芳后来复盘时意识到，她的团队在没有明确阶段认知的情况下，盲目追求了超出当前能力的目标。

阶段一：能跑，但主要靠人脑兜底

这个阶段的典型特征是：每个 Agent 都能完成一些事，但系统运行秩序依然存在于团队成员的脑子里。谁失败了该找谁、谁超时了该重派给谁、什么状态意味着必须人工接管，这些都靠默契而不是系统。

王芳的团队在接入前五个 Agent 时就是这个状态。大家大致知道：数据清洗失败找小李，报告生成超时找小王，API 调用异常找小张。这种”人脑调度”在小规模时甚至显得高效——有问题喊一嗓子就行。但当 Agent 数量超过十个，人脑就开始过载了。谁记得住十二个 Agent 之间的依赖关系？谁能在凌晨两点准确判断一个跨 Agent 的失败该由谁接手？

阶段一的团队最大的风险是误以为”能跑”就是”可控”。系统确实在完成任务，但这些完成是靠组织层面的透支换来的。成员需要时刻在线、时刻警觉、时刻记住各种隐式规则。这种模式不可持续，规模稍大就会崩。

阶段二：开始形成状态流，但异常处理仍然松散

王芳的团队在接入第六到第十个 Agent 时进入了这个阶段。他们开始在 Notion 里建立任务表、状态列、触发规则，甚至做了自动回写。表面上，系统看起来更”自动化”了——任务状态会自动更新，完成会自动通知，失败会自动标记。

但异常处理仍然松散。系统能告诉你”哪里不对劲”，却不能告诉你”接下来谁必须行动”。一个任务失败了，它被标记为”失败”，但没有明确的升级规则：是自动重试？是转给人工？是终止整个链路？还是继续等待？这些决策仍然依赖于值班人员的临场判断。

更麻烦的是，阶段二的系统往往会制造一种”治理已经完成”的错觉。我们有任务追踪了，我们有状态面板了，我们有自动化规则了——看起来该有的都有了。但实际上，系统只是把混乱从”完全不可见”变成了”可见但无人负责”。失败状态被标记出来了，但没人明确负责处理它；超时任务被高亮显示了，但系统不知道下一步该做什么。

阶段三：控制平面开始承担真实治理职责

只有到了这个阶段，你的控制平面才不只是一个观察板，而是一个调度系统。它不仅记录任务，还定义责任；不仅展示状态，还约束流转；不仅支持协作，还提供背压与刹车。

王芳后来花了很多时间思考阶段三应该是什么样子。她认为核心区别是：阶段三的系统把”失败”也纳入了设计。它不是假设所有任务都会成功，而是假设一定比例的会失败，并为这些失败设计了明确的处理路径。谁负责什么类型的失败、处理时限是多久、升级链是什么、在什么情况下必须熔断——这些都有明确定义。

如果你还在前两个阶段，却想直接追求十八个 Agent 的优雅协同，十有八九会把系统做成一台高分辨率的混乱放大器。王芳的团队就是这样——他们在阶段二后期强行接入更多 Agent，结果只是把原本松散的混乱以更清晰的方式呈现出来。

这个阶段最该补的，不是更多 Agent，而是状态与责任模型

很多人一看控制平面，第一反应是想再接更多能力：再加一个审计 Agent、再加一个路由 Agent、再加一个补救 Agent。可在一线落地里，这往往是错的。

王芳在最焦虑的时候，也曾想过这个方案：既然系统这么乱，是不是应该加一个”调度 Agent”来专门协调？但她很快意识到，这个思路有问题。系统之所以乱，不是角色不够多，而是状态含义不够硬。只要”处理中""等待中""失败""已接管”这些状态没有清晰责任，新增 Agent 只会增加更多模糊动作。

真正该先补的是两件事：状态机和责任模型。

状态机意味着每一种状态都有明确的定义：它意味着什么、允许从哪里流转到哪里、卡住多久必须升级。在王芳他们最初的实现里，“处理中”这个状态可以同时表示”正在执行""等待依赖""临时挂起""可能已死锁”等多种情况。这种模糊性让系统无法做出准确判断，也让人工介入变得困难——当你看到一个任务处于”处理中”状态，你不知道它是正常进行还是已经出问题。

建立状态机需要团队坐下来，明确定义每一种状态的含义和流转规则。例如：

• “待处理”：任务已创建，等待资源分配，超过 5 分钟未分配则升级为”资源不足”，通知运维
• “处理中”：任务已分配给 Agent，正在执行，超过预计时间的 150% 则标记为”可能超时”，触发检查
• “等待依赖”：任务本身正常，但依赖的前置任务未完成，前置任务失败则本任务自动标记为”依赖失败”
• “失败”：任务执行出错，已停止，需根据错误类型决定下一步（自动重试/转人工/终止链路）
• “已完成”：任务成功完成，结果已写入指定位置

每一个状态都要有明确的进入条件、退出条件、超时处理和升级路径。

责任模型则意味着每一个状态背后是谁必须动作、什么时候动作、动作失败后谁接替。在王芳最初的系统里，“失败”状态只是被标记出来，但没有明确谁负责处理。是创建任务的人？是 Agent 的维护者？是值班工程师？还是系统应该自动处理？没有明确责任，失败就会一直挂在那里，直到有人偶然发现。

建立责任模型需要回答：

• 对于每种失败类型，第一责任人是谁？
• 责任人在多长时间内必须响应？
• 如果第一责任人未响应，升级给谁？
• 升级后的处理时限是多少？
• 如果所有升级链都未响应，系统应该做什么（默认重试/终止/保持现状）？

没有这两层，控制平面的漂亮程度毫无意义。它再像控制塔，本质也只是一个更高级的待办清单。

一个更现实的推进顺序

王芳后来和她的团队制定了一个新的推进顺序，这个顺序不那么性感，但更有可能成功。

第一步：先把”失败状态”定义清楚

不要先定义理想协作流，先定义失败流。哪些失败允许自动重试，哪些失败必须人工接管，哪些失败直接终止链路。王芳的团队花了一周时间，把系统中可能出现的失败场景全部列出来，然后为每种场景定义处理规则。

他们发现，大约 40% 的失败是可以安全自动重试的（如网络超时、临时资源不足）；30% 的失败必须转人工（如业务逻辑错误、数据格式异常）；20% 的失败应该直接终止链路（如前置依赖彻底失败、资源配额耗尽）；还有 10% 的失败需要更复杂的判断（如部分成功部分失败的情况）。

把这些规则写进系统后，值班工程师的压力立即减轻了很多。系统开始能够自动处理一部分失败，只在真正需要人工判断时才升级。

第二步：把人工接管设计成系统能力，而不是紧急姿势

一线团队最怕的不是要人工接手，而是不知道如何接。控制平面必须为接管提供固定入口：接手人是谁、交接上下文在哪里、当前卡点是什么、允许做哪些补救动作。

王芳他们设计了一个”接管工单”系统。当任务需要人工介入时，系统自动创建一个工单，包含：

• 任务基本信息（类型、创建时间、预期完成时间）
• 当前状态和历史轨迹
• 已完成的步骤和结果
• 失败原因和错误日志
• 建议的处理方案（基于失败类型自动推荐）
• 相关的上游和下游任务

工单会被分配给对应的责任人，责任人在系统中完成接管、处理、关闭的全流程。所有操作都有记录，方便事后复盘。

这个设计让人工接管从一个”紧急救火”变成了”标准流程”。值班工程师不再需要在凌晨两点对着模糊的状态标签猜测发生了什么，他们可以清晰地看到上下文，做出有依据的判断。

第三步：再去做扩容和角色细分

只有当前两步成立后，新增 Agent 才是放大生产力，而不是放大不确定性。王芳的团队在完善了状态机和责任模型后，才重新开始增加 Agent 数量。这一次，每增加一个 Agent，他们都会先回答：

• 这个 Agent 的失败模式是什么？
• 这些失败如何被检测和处理？
• 谁对这个 Agent 的失败负责？
• 它和现有 Agent 的依赖关系是什么？依赖失败如何处理？

否则你会发现角色越多，会议越长，最后大家反而更依赖一个知道全局的人临场调度。

哪些事现在不要急着做

如果你还没把状态和责任做硬，王芳建议有几件事先别急。

第一，别急着追求”全自动闭环”

很多团队最早死在这里，因为他们想跳过半自动阶段，直接做一个看起来像自治系统的东西。结果系统把错误也自治了。王芳见过一个团队，为了追求”全自动”，设计了复杂的重试和补偿逻辑，结果一个底层数据错误被系统自动重试了十几次，生成了大量脏数据，最后清理成本远超手动处理的成本。

在半自动阶段，系统的默认行为应该是”遇到不确定情况就升级给人工”，而不是”猜一个继续执行”。只有当你对某种失败模式的自动处理有足够信心时，才把它加入自动规则。

第二，别急着做过细粒度的 Agent 角色拆分

角色拆得越细，协作接口越多，状态解释成本越高。没有成熟状态机之前，细粒度只会制造调度债。王芳最初把”数据清洗”拆成了”格式检查 Agent""缺失值处理 Agent""异常值检测 Agent""数据转换 Agent”四个角色，结果任务在它们之间的传递和协调占据了大量系统资源，真正的业务逻辑反而被淹没在调度噪声里。

后来她把这些合并回一个”数据清洗 Agent”，内部用传统函数处理不同步骤，系统复杂度立刻降低了很多。

第三，别急着把控制平面当管理可视化大屏

大屏的价值建立在系统规则足够硬的前提上，否则你只是在把噪声可视化。王芳的团队曾经花大力气做了一个漂亮的实时看板，显示所有任务的分布、成功率、处理时长。但在状态机不完善的时候，这些数据都是可疑的——“处理中”的任务里有多少其实已经死锁？“已完成”的任务里有多少其实是部分完成？大屏让一切看起来都很美好，直到你深入调查时才发现数字背后的问题。

先让规则硬起来，再让可视化亮起来。顺序不能颠倒。

如果资源有限，最小可执行版本应该长什么样

如果资源有限，王芳会建议从一个很克制的 MVP 开始。

首先是只追踪一类高价值任务。不要试图把所有任务都纳入控制平面，先选一类最核心、最有代表性的。例如，如果你在做数据分析管道，就先只追踪”报告生成”这一类任务，把这一类做透，再扩展到其他类型。

其次是只接入少量关键 Agent。一开始可能只需要两三个 Agent，但它们应该覆盖完整的价值链条。例如：数据采集 Agent、数据处理 Agent、报告生成 Agent。这三个 Agent 协作完成一个完整的业务价值，比十个孤立的 Agent 各自做零散任务更有学习价值。

然后是状态数控制在最少但有明确责任含义的范围内。王芳建议一开始最多定义五种状态：待处理、处理中、失败、需人工介入、已完成。每一种都要有清晰的定义和处理规则。

再者是每个状态都绑定升级或接管规则。即使是”待处理”状态，也要定义超时时间和升级动作。例如：待处理超过 10 分钟自动标记为”资源不足”，通知运维人员。

最后是所有人工接管都留下结构化理由。当人工介入处理一个失败时，要求记录：失败原因分类、采取的动作、预计解决时间。这些记录会成为后续优化自动规则的宝贵数据。

这类最小系统看上去不酷，但它有一个巨大优点：它能很早暴露你真正的治理短板。是状态定义太糊？是升级链太长？还是大家根本没有统一理解”失败算谁的”？越早看见这些，后面扩展时的代价越低。

结语：控制平面的价值，不在于让系统显得更聪明，而在于让系统在失序时仍然有人能接住

王芳花了六个月时间，才把团队的多 Agent 系统从混乱调整到可控。回顾这个过程，她最大的感悟是：多 Agent 系统最容易骗到团队的地方，是它看起来特别像”未来已经来了”。任务在跳、状态在流、角色在协作，一切都像一个更高级的操作系统。

但真正决定它是不是生产系统的，从来不是这些表面动势，而是当协作失序时，系统是否还能把责任说清、把噪声关住、把人工接管变成一件不狼狈的事。

所以，如果你准备把 Notion 或别的工具做成 OpenClaw 的控制平面，王芳给的建议并不性感：先别想着做得多漂亮、多自动、多复杂。先把失败状态写清楚，把接管入口做硬，把责任链缩短。

因为控制平面的成熟，不是体现在它能调度多少 Agent，而是体现在它能不能让组织不再靠一个最懂全局的人熬夜救火。

上周，王芳的系统经历了第一次真正的考验：一个上游数据源在凌晨三点突然变更了格式，导致整个数据处理链路大面积失败。但这一次，系统按照预设规则，自动标记了失败类型，创建了工单，通知了责任人，并在人工介入前阻止了自动重试。值班工程师在二十分钟内完成了修复，没有数据丢失，没有服务中断。

这个结果在半年前是不可想象的。那时的系统可能会在混乱中尝试重试，生成脏数据，然后在一个完全不可预测的状态中等待人工发现。变化不是 Agent 变多了，而是控制平面开始真正承担治理职责了。

这才是王芳眼中”未来已来”的真正含义。

参考与致谢

• 原文：I Turned Notion Into a Control Plane for my 18 OpenClaw AI Agents — AWS Heroes：https://dev.to/aws-heroes/i-turned-notion-into-a-control-plane-for-my-18-openclaw-ai-agents-5624