企业官网建设流程全解析

把多智能体系统从demo推到真正可用的状态，最让人头疼的往往不是你选的模型强不强，而是任务跑到一半突然卡住。网上搜Hermes多智能体相关配置时，能看到不少类似的报错：unexpected status 502 bad gateway、gateway: not reachable at ws://127.0.0.1:18789、the agent execution provider did not respond in time。这些问题看起来散，根子上都指向同一件事——任务状态不持久、通信链路不清晰、失败恢复没兜底。Hermes多智能体方案第2集把Kanban看板和Gateway网关放在一起，本质上就是在补这三块。

这篇文章不只是把看板和网关是什么讲一遍，我更想回答一个更实际的问题：为什么单Agent跑得很顺，一旦进入多Agent协作就容易崩？以及，要做到标题里说的“Agent 7×24待命”，到底需要满足哪些工程条件？

1. 多智能体系统真正的瓶颈，不是Agent不够聪明

1.1 单Agent demo和多Agent系统，差距不在模型

现在跑一个单Agent demo其实不难。给模型一段提示词，挂上几个工具函数，就能看到它一步步思考、调用、输出结果。这种模式有一个隐含前提：整个任务的生命周期都在同一次会话里，状态在内存或上下文里就能维护。

多Agent系统就不一样了。任务要在多个Agent之间流转，Agent A负责理解需求，Agent B负责检索资料，Agent C负责写报告。这时候问题就变了：

• A做完之后，结果怎么交给B？
• 如果B执行到一半崩了，A的结果还在吗？
• 如果重启了整个服务，任务应该从哪一步继续？
• 如果两个Agent同时处理同一张任务卡，会不会重复执行？

这些都不是模型能力强弱的问题，而是流程和状态的问题。Hermes多智能体在第2集把Kanban看板、Gateway网关和任务持久化放在一起讲，说明作者很清楚：多Agent能稳定跑起来，真正的门槛在编排层，不在模型层。

1.2 多智能体协作的常见交互模式

在设计多Agent系统之前，先要知道Agent之间有哪些协作方式。业界讨论比较多的四种模式大致是：

无论采用哪种模式，都会碰到同一个问题：任务状态放在哪里。层级式需要主控知道每个子任务的进度，协作式需要知道中间产物在哪，仲裁式需要知道任务是否被认领、是否超时。这些信息如果散落在各个Agent的内存里，整个系统就是不可控的。

Kanban看板恰好能解决这个问题：它是所有Agent共享的任务状态层，状态不随单个Agent进程消失。

1.3 状态、路由、恢复：三个绕不开的问题

我把多Agent系统的工程化难点概括成三件事。

• 状态：任务目前处在什么阶段？由哪个Agent在处理？输入、输出、错误信息记录在哪里？
• 路由：一条新任务应该交给哪个Agent？请求应该发到哪个地址？走HTTP还是WebSocket？
• 恢复：Agent宕机、网络抖动、执行超时之后，任务怎么继续？是重试、换人、还是进入阻塞队列等人介入？

单个Agent demo里，这三条都可以靠写代码绕过去。但一旦Agent数量变多，任务频次变高，任何一条不解决，系统就会频繁出现“跑着跑着就没了”的现象。

Hermes这套组合的思路是把这三件事显式化：Kanban管状态，Gateway管路由，两者配合做恢复。后面几节分别展开。

2. Kanban看板：把任务状态从进程内存里搬出来

2.1 看板是任务队列，也是状态机

Kanban起源于生产管理，核心是“可视化流程”和“限制在制品数量”。在多Agent系统里，看板可以理解为带状态的任务队列。

常见状态列包括：

• todo：任务已创建，等待被Agent拾取。
• doing：任务已被某个Agent领取，正在处理。
• done：任务完成，结果已写入。
• blocked：任务多次失败或需要人工介入。

这个模型比直接调Agent接口要稳，因为任务状态不保存在某个Agent的内存里，而是保存在看板里。Agent崩溃了，任务还在；Gateway重启了，任务还在；整个系统重启了，任务状态依然能还原。

这也是标题里“任务持久化”的核心含义：不是把数据临时写在内存里，而是让任务状态变成可查询、可恢复的持久化记录。

2.2 任务卡片该记录哪些信息

看板上的每一张卡片，本质是任务在执行过程中的完整档案。字段设计得好不好，直接影响排查问题的速度。通用情况下，一张任务卡片建议至少包含以下字段：

下面是一个示意结构，落地时按你的系统逻辑调整字段即可：

{ "task_id": "task_20250101_008", "status": "doing", "input_payload": { "query": "整理多智能体架构的落地步骤" }, "output_payload": null, "assigned_agent": "researcher", "retry_count": 1, "last_error": "gateway 502, agent not reachable", "created_at": "2025-01-01T10:00:00Z", "updated_at": "2025-01-01T10:15:00Z" }

retry_count和last_error这两个字段特别容易忽略，但对7×24待命来说非常关键。没有错误信息，失败任务只能从头查日志；有了last_error，至少能快速判断是网络层问题、Agent执行问题还是任务本身的输入问题。

2.3 任务持久化最容易踩的坑

从工程经验看，看板持久化最常踩的坑有四个。

第一个坑：只把看板放在内存里。框架自带的内存队列用起来很爽，但进程一重启，所有任务状态全部丢失。结果就是第二天早上发现昨晚的任务全都不见了，Agent状态和看板状态完全对不上。如果要做持久化，至少落到本地SQLite或文件，而不是依赖进程内存。

第二个坑：任务做完不归档。看板表无限增长，查询越来越慢。建议done状态的任务定期归档到历史表，当前看板只保留未完成任务和近期完成记录。

第三个坑：状态更新不是原子的。两个Agent可能同时读到同一张todo卡片，然后同时把它改成doing。如果不是原子更新，就会出现一个任务被两个Agent重复处理。解决思路是给任务状态加版本号，或者在更新时用“条件更新”：只有当前状态是todo时，才能更新为doing。

第四个坑：重试没有幂等设计。Agent执行失败后重试，如果任务涉及对外发送通知、扣减库存这类有副作用的操作，重复执行会产生重复结果。这时要引入幂等键，或者在任务卡片里记录每次执行的进度，避免从头执行。

2.4 从队列到看板：为什么不是简单消息队列

有人可能会问：直接用Redis或者MQ不也能做任务分发吗？

可以，但队列和看板解决的不是同一层问题。消息队列主要保证“消息被消费”，它不关心“这个任务现在卡在哪个Agent手里”“失败了几次”“中间产物在哪”。这些信息如果全部塞到消息体里，生产者消费者都要维护一堆约定，耦合度很高。

看板的价值是把任务生命周期显式化。队列更像是“任务来了谁有空谁接”，看板更像是“任务的每一步都有记录、有状态、可回顾”。在多Agent系统里，后者通常更接近实际需求。

注意：不要一上来就用分布式消息队列。先本地把看板状态管好，跑通一个最小闭环，再谈扩展。多数项目的问题不是队列不够强，而是状态不够清晰。

3. Gateway网关：多智能体系统的统一入口和路由层

3.1 没有Gateway时，多Agent通信是什么样

没有网关时，每个Agent都是独立的网络服务，客户端要记录所有Agent地址。Agent之间互相调用更麻烦：Agent A要直接请求Agent B的HTTP接口，Agent B又可能回调Agent C的WebSocket端口。谁重启了、谁换地址了、谁改了端口，所有依赖方都得跟着改。

这还只是网络层面的问题。更深层的问题是：认证怎么做、健康检查怎么做、路由规则写在哪里。如果客户端可以直接访问任意Agent，权限控制和限流也很难做统一。

Gateway就是用来解决这些问题的。

3.2 Gateway在多Agent系统里做了什么

Gateway在多Agent系统里承担的角色，可以理解为“统一入口 + 路由层”。

• 统一入口：客户端只需要跟Gateway通信，不需要关心背后有多少个Agent。
• 路由：根据请求路径、任务类型或消息内容，把请求转发到对应Agent。
• 协议转换：HTTP、WebSocket等不同协议可以在Gateway层统一收敛，避免调用方各自处理。
• 鉴权：通过Gateway Token校验请求合法性，防止未授权访问。
• 健康检查：Gateway定期探测Agent状态，发现不可用的Agent可以及时摘除，避免请求打到坏节点上。

这和传统API网关有些像，但在多Agent系统里，它更重要的能力是维护Agent注册表和会话路由，让Agent可以灵活上下线，而不影响客户端。

3.3 配置Gateway时最常见的三类故障

搜索Hermes相关配置时，能看到很多报错信息，整理下来基本围绕三类问题。

第一类：Gateway根本没有启动或无法连接。有些环境会直接提示“Gateway 未启动 · 请先运行 windows-start.bat 或 mac-start.command”。还有一种情况是客户端配置了错误的地址，比如gateway: not reachable at ws://127.0.0.1:18789，这说明客户端尝试用WebSocket连Gateway，但服务端没有在这个端口监听。

第二类：Gateway起来了，但后端Agent不可达。典型报错是unexpected status 502 bad gateway: unknown error, url: http://127.0.0.1:1572。502的含义通常是网关作为中间层，没有从后端服务拿到有效响应。这时候问题往往不在Gateway本身，而是后端Agent服务没启动、端口配错、或者Agent正在启动中还没就绪。

第三类：鉴权失败。报错类似unauthorized: gateway token missing。通常是客户端没有配置Token，或者Token和Gateway侧不一致。这个在换机器、换配置时非常常见。

这三类故障，恰好对应Gateway配置的三个关键点：服务是否监听、后端是否就绪、Token是否匹配。

3.4 配置Gateway的推荐顺序

结合常见故障，我建议按下面的顺序配置，不要一上来就把所有Agent都挂上去。

1. 先启动Gateway服务，确认它监听的端口和协议。
2. 确认Gateway健康检查接口或Dashboard可访问，先确认Gateway自身是好的。
3. 启动第一个Agent，并完成注册，确认Agent状态在Gateway侧可见。
4. 用一个最简单HTTP请求验证路由，比如直接让Task类型匹配到对应Agent，确认能拿到正常响应。
5. 接入看板任务，让任务从看板流转，而不是直接调用Agent接口。

这个顺序的核心是：先把每一条链路的小单元各自验证通，再做组合。很多人Debug耗时很久，就是因为Gateway还没确认就绪，就直接跑完整链路，结果一旦出错，不知道是Gateway的问题、Agent的问题还是看板任务的问题。

4. 从502到超时：Gateway相关异常的完整排查链路

4.1 502 Bad Gateway 到底在说什么

502一般出现在Gateway作为中间层的场景。客户端请求到了Gateway，Gateway又去请求后端Agent，但后端没有返回有效响应，Gateway只能向上抛出一个错误状态码。

看到502，先不要急着改客户端，优先排查后端Agent。常见原因有：

• 后端Agent服务没有启动。
• Agent启动脚本执行了，但进程没监听在配置的端口上。
• Gateway配置的后端地址端口不对。
• Agent服务正在启动，还没就绪，Gateway请求恰好打进来。
• 后端处理时间太长，超过Gateway超时时间。

所以排查起点，应该是“后端Agent到底有没有正常监听”。可以用curl http://127.0.0.1:1572这类方式验证，也可以先查看端口监听状态，而不是反复重启Gateway。

4.2 WebSocket连不上和Agent执行超时，是两类不同问题

很多人把连接问题超时混在一起排查，实际上它们非常不同。

gateway: not reachable at ws://127.0.0.1:18789这种错误，发生在连接建立阶段。它的常见原因是端口错误、协议路径错误、服务未监听、或者Agent进程没起来。问题核心是“连不上”。

而the agent execution provider did not respond in time这类错误，发生在连接已经建立之后。Gateway已经连上了Agent，但Agent处理任务的时间超过了系统设定的阈值。问题核心是“任务处理太慢”，可能因为模型响应慢、工具调用卡住、外部API没有返回。

区分这两类问题很重要。连不上，是配置和网络层问题；执行超时，是任务和资源层问题。修的方向完全不一样。

4.3 一套可复制的排查顺序

遇到Gateway相关异常，我一般按这个链路排查：

1. 看现象：是502、连接失败、鉴权失败，还是执行超时？先把报错原样记录下来。
2. 看输入：请求地址、端口、路径、Token、请求体，是否与配置一致。
3. 看环境：Gateway进程是否存活？Agent进程是否存活？端口是否在监听？同一台机器上打开Dashboard或健康检查接口确认。
4. 看配置：Token是否一致？Agent是否注册成功？协议是HTTP还是WebSocket？版本是否兼容？
5. 看日志：Gateway日志、Agent日志、任务日志，按时间对齐看报错上下文。

下表是常见的现象和优先排查项的对照：

建议先把小样本跑通再批量化。一个任务能从todo走到done，并且能在看板里看到完整的错误记录，这个过程本身就是最好的调试手段。批量任务的问题，大多在单任务阶段就已经存在。

4.4 调试时，保留现场比急着解决更重要

很多Agent框架在调试阶段最缺的不是推理能力，而是“现场信息”。任务失败后，如果能从看板里看到last_error、retry_count、assigned_agent，再配合Gateway日志，通常几分钟就能定位问题方向。

反过来，如果任务失败后所有状态被清空，报错日志也不完整，就只能靠猜测。这就是为什么我在2.2节强调任务卡片要记录错误字段。它看起来不起眼，但在7×24运行里，是救命的信息。

5. 让Agent 7×24待命，不是挂在后台，而是状态可恢复

5.1 7×24待命的真实含义

很多人理解“7×24待命”，是Agent进程永远不退出。但真实生产环境下，没有进程敢保证永不退出。系统更新、服务器重启、资源耗尽、网络抖动，任何一个原因都会导致Agent进程退出。

真正的7×24待命，应该是“状态不受进程存活影响”。进程可以挂，但任务不能丢；Agent可以换，但上下文不能断。要实现这个目标，不能只靠Agent自身的高可用，还要靠状态层和路由层的配合。

这里的状态层就是Kanban看板，路由层就是Gateway。任务状态持久化在看板里，客户端请求统一走Gateway。某个Agent挂了，任务还在，可以由其他Agent接管，或者等Agent恢复后继续。

5.2 三个必要条件

要让Agent做到可恢复的7×24待命，我认为至少需要三个条件：

第一，任务状态持久化。看板必须落盘，不能只存在内存里。任务当前状态、输入输出、重试次数、错误信息，都要能跨重启查询。

第二，健康检查。Gateway要能感知Agent是否活着。如果一个Agent已经失联，还继续给它派发任务，就会产生大量502和超时。健康检查机制可以把不可用Agent从路由表里摘除。

第三，失败重试和人工接管。任务失败后，要有重试策略；重试多次仍然失败，要进入blocked状态，等待人工介入。不能把失败任务静默丢弃，也不能无限重试死循环。

这三个条件缺一个，7×24就只是表面存活。

5.3 从“先跑通”到“稳定批量”的工程化路径

结合常见实践，我建议按以下阶段推进。

• 阶段一：单Agent + 最小看板。先把任务从todo走到done，确认状态能持久化。
• 阶段二：引入Gateway。客户端请求统一走网关，验证路由和Token鉴权。
• 阶段三：注册多个Agent。任务按类型路由到不同Agent，确认看板状态与Agent执行结果一致。
• 阶段四：设计异常处理。设置超时时间、最大重试次数，失败进入blocked列。
• 阶段五：补可观测性。日志集中、任务指标、看板数据备份、告警通知。

这里有一个容易走的弯路：在阶段一还没跑通时，就急着上多Agent、上分布式队列、上复杂监控。结果就是系统复杂度远高于任务复杂度，一出问题完全不知道从哪排查。

5.4 长期维护还需要补什么

看板和Gateway解决的是“状态”和“路由”问题，但长期稳定运行还需要额外几块拼图。

• 日志集中：多Agent产生的日志分散在各进程里，排查时要能按task_id串起来。
• 任务指标：记录每分钟处理任务数、失败率、平均执行时长。没有指标，就无法判断系统是否在退化。
• 看板数据备份：状态层是核心资产，定期导出备份。机器故障时，可以快速从备份恢复。
• 告警：任务blocked数量超过阈值，或Gateway健康检查异常，应该触发通知，而不是等到用户发现问题。
• Token安全：Gateway Token不要硬编码在代码里，放配置文件或环境变量，并定期轮换。权限上遵循最小化原则，不同Agent使用不同凭据。

6. 这套方案的适用边界与我的建议

6.1 适合谁，不适合谁

Hermes多智能体 + Kanban + Gateway这套组合，比较适合以下场景：

• 想系统学习多Agent编排原理的人。
• 在本地或小规模环境运行多Agent，需要看清任务状态的人。
• 想把自己的临时脚本体系改造成有状态、可恢复的任务系统。
• 团队需要一个可视化任务流转方案的场景。

不太适合的场景：

• 超大规模高并发生产系统。它需要更完整的服务发现、负载均衡、分布式事务和消息中间件。
• 对状态一致性要求极高的场景，比如金融交易。单一Kanban存储不足以作为唯一状态来源，需要更严格的事务机制。
• 如果Agent数量很少，任务逻辑简单，也不必引入Gateway，直接函数调用反而更直接。

这不是说这套方案不行，而是要选对场景。它更适合“中小规模、需要看得见状态、需要可控恢复”的多Agent应用。

6.2 给新手的落地建议

如果你准备照着“Kanban看板 + Gateway网关”这套思路落地，我的建议是：

1. 先跑最小闭环。一个Agent、一个看板、一个本地Gateway，跑通一个任务。
2. 先本地持久化。SQLite或者本地文件都行，关键是任务状态不依赖进程内存。
3. 记录错误现场。任务卡片里保留last_error，比任何日志都直观。
4. 做一次故障演练。手动杀掉Agent进程，看任务状态是否还在、能否恢复。这一步能验证你的“持久化”到底有没有真正落盘。
5. 再逐步扩展。一个Agent稳定后，再加第二个、第三个，再设计路由和重试。

当前首要目标不是把所有Agent一次性挂上去，而是确认“任务状态不会因为进程退出而丢”。这一条验证通过，后面的Gateway路由、批量任务、长期监控才是有意义的上层建筑。

6.3 回到核心判断

多Agent系统能不能长期稳定跑，底线不是模型能力，而是三件事：任务状态是否持久化、请求路由是否清晰、失败后是否能恢复。

Hermes多智能体把Kanban和Gateway作为核心组件，正是围绕这三件事做的设计。Kanban把任务变成可管理的卡片，Gateway把Agent通信变成可控的链路。两者都到位后，7×24待命才不是一个噱头，而是可恢复、可维护、可观测的工程能力。

如果你正被“Agent跑着跑着就断了”折磨，下一步该检查的不是模型，而是任务状态落在哪里、请求走的是哪条路径、失败之后有没有留下可追溯的记录。这三件事理清了，多Agent系统才真正从“能跑”走向“能一直跑”。