白板周围的智能体：在AI原生环境中解决运营问题

博途PLC工程智能体 | 梯形图转SCL | 自然语言生成梯形图 | 自然语言生成SCL | 逆向生成程序块文档 | 梯形图在线查看 | 博途编程文档MCP | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI

2023年我第一次构建多智能体系统时，它是一个由子智能体驱动的专家系统：顶部是一个编排器，下面分派专家，每个专家做一项工作并将结果报告回链条。这是当前智能体框架中的主导模式。它在一定程度上有效。

但它是金字塔形的。虽然金字塔产生了一些令人印象深刻的结果——从字面意义上说，金字塔——但现代技术中最重要的东西大多不是来自金字塔。它们来自白板。来自共享笔记本、RFC、设计文档、版本控制、同行评审、开源代码库、维特基。这个模式比计算机更古老：一个共享工件（科学家称之为边界对象），许多贡献者从中读取和写入，其中工件是协调机制，贡献者彼此大多独立。

那么，如果我以这种方式构建一个智能体系统呢？不是顶部有编排器的金字塔，而是一个白板，几个自主智能体向它写入，人类被放置在需要判断的确切位置。

这就是本文其余部分的内容。

1、工作：在小型B2B SaaS中处理客户反馈

• 从客户那里获取一封德语邮件，
• 将其转化为工程工单，
• 发布修复，
• 用简单的语言告诉客户经理。

四个智能体和一个工程层完成这项工作，通过公司现有工具中已经存在的两个数据片段（一个Jira标签和一个问题链接）进行协作。其中三个智能体是定时驱动的自主运行；其他的是人类在环对话，被放置在判断很重要的确切位置。

在三个企业客户的前两周生产流量中，16个客户问题通过这个管道顺利关闭。从邮件到工程关闭的中位周转时间：16小时。56%在当天关闭。

让它工作的不是智能体。而是我用白板替换了金字塔，并把人类放在了判断所在的地方。

2、多智能体系统的问题

多智能体系统现在很流行。每个会议演讲都是关于编排的。每个框架对智能体应该如何相互通信都有自己的看法。主导模式，通常是编排器分派专家或智能体A调用智能体B的API，是分层的：顶部的一个智能体将工作分派给其他人，读取他们的自然语言报告，决定下一步做什么。

这在单个会话中对单个任务非常有效。这正是Claude Code在你要求它做复杂事情时内部的工作方式：编排器委托给专家，获取报告，集成它们，产生最终输出。子智能体的"输出"是一个报告，而不是结构化负载；LLM智能体返回散文，而不是模式，这实际上是它们的新颖之处之一。对于返回的内容没有契约。

重要的是副作用：写入的文件、打开的工单、编辑的代码。

就像编辑工件有工件被更改的副作用一样，智能体通过副作用工作。

对于单个会话中的一次性任务，金字塔没问题。当你希望工作流持久化时，问题就出现了：重复运行、处理持续的工作流、在数周内逐部分修改。

具体来说：每个LLM智能体都有自己的临时上下文。金字塔顶部的编排器必须在一个窗口中保持目标、计划、运行状态和每个子智能体报告的摘要。当会话结束时，所有这些都消失了。跨会话唯一幸存的是作为副作用写入持久位置的内容：文件、工单、标签、页面。明天的运行从一个空白的编排器开始，必须从这些副作用中重建世界。

所以如果你正在构建一个长期运行的系统（在cron上运行、处理持续工作、逐部分修改的东西），你有两个选择。

1. 保持金字塔，接受每个会话从头开始，并通过上下文重建你离开的地方，或者智能体会慢慢漂移，无论是hermes、openclaw还是只是打开的编码会话
2. 从一开始就围绕副作用进行设计。使共享状态（文件、工单、标签、页面）成为持久的支柱。每个智能体读取当前状态，执行其工作，写入其副作用，然后完成。系统的"记忆"存在于共享状态中，而不是任何智能体的上下文窗口中。

第二个选项是白板模式。第一个是金字塔。对于需要跨时间存在的系统，只有其中一个真正可组合。

金字塔自动化还有一个第二个、更深层次的问题：

如果你完全自动化循环，就没有人类参与其中，这意味着没有判断，这意味着你会快速发布错误的东西。

客户项目不能1:1映射到工程工单。一个七项反馈列表可能缩减为两个工程工单（共享根本原因）或扩展为四个（一个项目实际上是研究，另一个已经设计，第三个超出范围）。这种映射需要产品判断。LLM可以幻觉一个并运行它，但它不应该。

这种模式同时解决了两个问题。第一个解决方案是数据集成：智能体读取和写入共享存储，从不相互调用。想想白板，而不是金字塔。

第二个是刻意的人类在环瓶颈，结构上放置在需要判断的位置，围绕记录什么以及如何记录有治理纪律。

3、案例

四个智能体、一个工程层、一个客户反馈循环。

这是一个实际例子。在我工作的公司，客户反馈过去在三个经典差距中腐烂：

1. 收件箱 → 分类差距：重要邮件在客服主管的收件箱中死亡，特别是如果它们是德语而客服主管不读德语。
2. 分类 → 工程差距：客户项目不能1:1映射到工程工单。映射是工作，通常手工完成且做得很差。
3. 工程 → 客户差距：工程师发布，客户经理不注意，客户蒙在鼓里。
4. （还有第四个额外差距，工单到记忆差距：有用的情报，如新联系人、产品提及、逐字功能请求永远被困在工单正文中。）

这个循环用四个智能体和一个工程层关闭了所有四个差距，每个智能体只做一件事：

• 邮件分类：在夜间计划中读取收件箱，对每封德语邮件进行结构化读取（索赔、紧急性、语域信号、翻译），创建客户反馈Jira工单，如果需要操作则发布Slack警报。定时驱动。没有人类在环。
• 规范编写：当新的客户反馈工单到达时，我运行此技能（在Claude Code内部）将其转化为工程工作。它将客户请求与现有源代码和计划工单进行比较，引导我通过2-3种候选方法及其权衡，一次询问一个澄清问题，并且只有在我批准设计后才编写规范。输出是一个Jira用户故事，描述中包含完整规范，并有一个指向客户反馈工单的Resolve链接。人类在环设计：产品判断瓶颈。
• 工程层：一旦用户故事到达看板，工程师的Claude Code会话（运行在仓库CLAUDE.md下的Superpowers技能流水线）将其拾取并转化为代码。测试工具在工作进展时读取和写入Jira：从实施计划创建子任务，转换反映真实的子智能体状态，父故事只有在工程师手动完成预发布检查后才会翻转为已发布。人类在环设计：技术判断瓶颈。关于此流水线的更多信息见下文。
• CF工单同步：夜间运行。对于每个反馈工单，读取链接的工程工单，计算反馈工单的正确状态，修复任何缺失的客户标签，当某些内容实际发布时向客户经理渠道发布简单的Slack摘要。定时驱动。
• 客户档案刷新器：夜间运行。对于每个客户，查询自上次运行以来的新工单，提取联系人、产品和逐字声明，并更新Confluence客户档案页面。定时驱动。

没有人手动输入Jira，但它在那里保持决策的完整审计跟踪——故事、实施任务、关于开发过程中发现的开放问题和问题的评论交流。工单通过AI自动推进。

这是四个智能体和一个工程层。其中三个智能体是定时驱动的自主运行。规范编写技能和工程层是循环中两个刻意的人类在环瓶颈：产品判断存在于第一个中，技术判断存在于第二个中。

每个承载产品决策都进入带有归因标签（[ADAM]、[ADAM-accepted-CLAUDE-offer]、[CLAUDE-research]、[CLAUDE-assumption]）的决策日志，这些标签会进入Jira用户故事。工程层在下游携带自己的归因纪律，编码在Superpowers流水线中（更多信息见下文）。

两个瓶颈，两个判断域，两个人类。一个Jira审计跟踪将它们全部联系在一起。

所有五个部分（三个自主智能体、规范技能、工程层）通过公司现有工具中已经存在的两个数据片段进行协作：一个Jira标签（client-XXX）和一个Jira问题链接（反馈和工程工单之间的Resolve链接）。

这就是整个共享契约。

4、为什么这有效：五条设计规则

这个模式比例子更有趣。构建这个产生了五条规则，它们是我现在应用于每个多智能体系统的规则。

4.1 规则1：数据集成，而不是API集成

每个智能体通过共享契约读取和写入：一个Jira标签、一个问题链接、一个Confluence页面、一条Slack消息。没有智能体调用任何其他智能体。没有智能体需要知道任何其他智能体存在。

好处是在变化下的可组合性。当我重写邮件分类智能体的结构化读取格式时，其他三个智能体都不需要知道。当我在其他智能体之后几个月添加档案刷新器时，我给它读取反馈工单和写入Confluence页面的权限；其他三个智能体继续运行，未修改，没有意识到一个新的智能体现在正在读取它们的输出。

这与使Unix管道持久的洞察相同。契约是数据形状，而不是进程边界。每个工具读取stdin并写入stdout，只要数据形状保持不变，你就可以换出任何一个。Doug McIlroy在1964年提出了这一点；六十年后仍然正确，现在对LLM驱动的工作者也是如此。

4.2 规则2：抑制纪律

每个智能体都有一个硬性规定，除非有真正的新内容，否则保持沉默：

• 如果邮件中的每个索赔在工程中已经解决，邮件分类会跳过Slack警报。
• 只有当至少有一个工单在当晚完成时，同步才会发布到客户经理渠道。
• 只有当至少一个客户档案实际被编辑时，档案刷新器才会发布。

在一个多个智能体按定时计划发布到多个渠道的系统中，默认静默是一个主要的UX选择，是你和通知疲劳之间唯一的障碍。一旦人类静音一个渠道，循环就被打破：智能体产生没有人读取的警报，"在发布内容时告诉客户经理"的全部意义就崩溃成噪音。

我开始写入每个我接触的智能体规范的规则是：静默成功，大声失败。如果一切正常，智能体什么也不说。如果出了问题，智能体会尖叫。这颠倒了大多数监控系统的默认设置，即确认成功，只在硬错误时大声失败。对于智能体，你想要相反的，因为智能体本身已经足够嘈杂了。

4.3 规则3：每个边界处的幂等性

每个智能体都是可重新运行的。如果定时任务触发两次，不会重复。如果智能体在批次中途崩溃，它会从离开的地方继续。如果两个智能体尝试更新同一条记录，最后一次写入干净地胜出。

对于LLM驱动的智能体来说，这比听起来更难，因为LLM是非确定性的。相同的输入不会产生相同的输出。因此，幂等性必须存在于边界处，而不是智能体内部：当智能体的输出到达共享存储时，你需要一个去重信号供下次运行读取。

客户反馈循环使用三种不同的模式来实现这一点：

• 邮件分类中的两层去重。邮件分类智能体通过数据库有自己的内部状态，只是为了记住已经处理了什么。由于它运行最频繁，它是最重要的。
• CF工单同步中的惰性字段水合。批量JQL省略了描述字段，每个工单可能有80KB。描述是单独获取的，只针对实际移动到完成的少数工单。这与去重是同一类问题：处理重新运行而不会因响应大小而崩溃。
• 档案刷新器中的水印。每个客户页面都带有一个包含最后刷新时间戳的HTML注释。下次运行只查询该水印之后创建的工单。部分运行不会推进水印，因此失败会导致下次传递时的干净重试。

所有三种情况的原则相同：不要相信智能体会记住它做了什么。将记忆写入共享存储，下次读取回来。

4.4 规则4：每个字段一个写入者

共享存储中的每个字段都有一个写入者和一个有记录的读取者集。

• 反馈工单正文 = 客户声音（逐字，从不意译）。由邮件分类写入。由规范编写和档案刷新器读取。
• 反馈工单标签 = 哪个客户。由邮件分类写入。所有人读取。
• 反馈↔工程Resolve链接 = 工程覆盖范围。由规范编写写入。由同步读取。
• 工程工单标签 = 工程工作针对哪个客户。由规范编写写入（有时），由同步填写（始终）。由报告读取。
• Confluence档案页面 = 综合客户情报。由档案刷新器写入。由人类读取。

这是应用于智能体系统的标准CRUD纪律，但在这里比平时更重要，因为智能体会愉快地在你授予他们权限的任何地方写入。没有明确的写入者分配，你最终会得到三个智能体都在更新同一个字段，每个都覆盖其他人的内容，以及需要一周时间才能解开的调试会话。

推论：某些字段是仅限人类的。客户注册表本身是仅限人类的。每个客户档案页面的"备注"部分是仅限人类的。这些区域在智能体规范中是明确的硬性规则，而不是隐式约定。否则，智能体会"为了清晰起见"乐于编辑你的仅限人类区域，你会丢失不应该被触及的信息。

4.5 规则5：人类只处理判断调用

这是区分有用的AI工作流与产生自信错误答案的自动化的规则。

智能体在这里做行政工作。人类做出所有判断——他们只做判断。

在客户反馈循环中，正好有两个类人类在环瓶颈，它们处理不同类型的判断。

第一个是规范编写技能：产品判断。七个客户项目是缩减为两个工程工单还是扩展为四个；某些内容是在范围内还是超出范围；适用哪个合规范围；客户的逐字引用是否确实意味着我们认为的意思。我做出这些调用。该技能通过禁止智能体默默地做出承载决策来强制执行：每个非机械调用上的[CLAUDE-assumption]标签都被视为智能体应该询问人类的问题。

第二个是工程师的实施瓶颈：技术判断。哪种架构模式适合代码库；新代码如何与现有迁移交互；故障模式是什么；运行的实施是否确实做了规范所说的内容。工程师针对规范运行Superpowers技能流水线（头脑风暴、计划、子智能体驱动的实施，每个任务有两次AI审查、PR），归档跟踪每个计划任务的Jira子任务，然后在将父故事翻转为已发布之前手动完成每个预发布检查。规范是输入；实时Jira树加上验证的已发布状态是工程师的响应。

定时任务处理中间的所有内容，无聊的部分：分类、同步、档案更新。其余的是判断，判断发生时带有姓名和记录它的Jira工件。

这是将多智能体系统与管理科学联系起来的规则。

管理者的工作不是做出每个调用：而是做出需要判断的调用，并设计系统，使其他所有内容在没有他们干预的情况下围绕他们流动。生成变得廉价；判断保持昂贵；工程工作是设计循环，使判断在正确的位置发生，并带有归因。

5、治理层：每个仓库一个CLAUDE.md

上面的五条规则是关于我如何设计智能体的。还有第二层纪律，治理循环的工程师侧：一旦规范到达Jira并且工程师拾取它后会发生什么。每个客户试点仓库都在根目录下携带一个CLAUDE.md文件，该文件硬编码它，在每次会话中由Claude Code自动加载。

有趣的部分是CLAUDE.md要求工程师运行什么。功能工作必须端到端通过Superpowers技能流水线，这不是"使用功能分支并编写一些测试"：它是一个四阶段流程，有自己的内部审查循环：

1. 规范/头脑风暴 ——产生规范的技术对话，存储在docs/superpowers/specs/中。
2. 编写计划 ——将规范转化为docs/superpowers/plans/中的精简TDD计划，每个任务足够小，一个子智能体可以一次完成。
3. 子智能体驱动开发 ——对于计划中的每个任务：一个新的实现子智能体完成工作，然后一个规范合规审查子智能体根据规范检查它，然后一个代码质量审查子智能体检查其工艺。只有当三个都通过时，任务才算完成。
4. 完成开发分支 ——打开PR并关闭jira任务。

计划中的每个任务都成为一个Jira子任务。当其实现子智能体开始时，子任务转换为进行中；当实现者加上两个审查者都通过时，它转换为完成。父故事保持进行中，直到每个子任务完成并且工程师手动完成预发布检查清单，这是最后的人类关卡。只有这样，故事才会被翻转为已发布。

结果是Jira最终以子任务粒度保存每个客户问题的完整实时记录：带有逐字客户声音的原始CF工单、带有规范和决策日志的链接用户故事、每个TDD计划任务的子任务，其流水线状态反映现实，以及仅在人类签署手动验证后才设置为已发布。所有这些文档都不是作为单独的步骤产生的。它是按照CLAUDE.md要求的方式执行工作的副产品。每个关闭的子任务意味着三个不同的AI实例查看了一个原子工作（一个编写它，两个独立审查它），人类将在父故事发布之前再次查看整个内容。

如果你想迂腐一点，这是开发工作流的宪法文档。工程师不执行它；测试工具执行它。智能体不执行它；测试工具执行它。规则凌驾于它们之上。它们恰好编码了一个多阶段流水线，内置自我审查，没有测试工具每次会话提醒，任何工程师都不会持续运行。

6、关于智能体记忆

当人们谈论长时间运行的智能体时，对话通常转向记忆：mem0、向量存储、图数据库、Obsidian保险库、自定义嵌入管道。但组织记忆已经是一个解决了二十年的问题。大多数公司已经将其保存在工单管理系统和wiki中：Jira、Linear、ServiceNow、Confluence、Notion、SharePoint。

你的工单系统和你的wiki就是你的组织记忆

人类可读、人类可编辑、跨年持久、可查询，并且已经包含智能体需要的上下文，格式正确（本质上是markdown）。给定正确的提示，智能体读取Jira工单或Confluence页面就像新员工加入团队一样好，而且通常更好，因为智能体读取每个页面。

这个循环中的四个智能体没有自定义记忆层。它们有针对Jira和Confluence的JQL/CQL查询。它们的"记忆"是公司现有的运营现实，这意味着人类可以通过与正常工具的正常交互来审计、覆盖或扩展它。智能体的记忆和团队的记忆是相同的记忆。

7、你放弃了什么

瓶颈就是瓶颈。规范技能每个反馈工单需要30分钟到2小时；工程层在此之上添加更多。完全自主会更快。它也会更频繁地发布错误的内容，方式很难检测，直到客户注意到。在具有真实客户和真实合规风险的B2B环境中，这种权衡显然是一方面的；在不同的环境（消费者、低风险、快速迭代）中，它可能是另一方面的。

这些都不是AI替代工程判断。

全部意义是确保判断在正确的地方应用，并带有归因。如果你想要学术框架，这是黑板架构（Hayes-Roth，1985），更新为碰巧是LLM的智能体和碰巧是现成SaaS的黑板。顺便说一句，这也是良好管理一直以来的样子：判断重要的人类，其他地方确定性工作，每次调用都有归因。智能体行业一个设计模式一个设计模式地重新发现管理科学。

在三个企业客户的两周生产流量中，该循环产生了16个关闭的客户反馈周期，中位数16小时，56%在当天。规范编写技能用我的产品判断确定了每一个的范围；Superpowers流水线在工程师技术判断下将每个规范带入代码；每个已发布转换都遵循手动预发布检查。Jira看板保存每个问题的完整路径，决策日志和AI与人类的归因端到端幸存。

这就是模式。智能体不是系统：共享契约是，治理文件是，人类在环瓶颈是。智能体只是工作者。白板是工作，瓶颈是重点，审计跟踪是使整个东西足够可信以在生产中实际使用的原因。

原文链接：Agents around the whiteboard: solving operations in AI-native environments

汇智网翻译整理，转载请标明出处