文章总结： 本文通过Hermes主代理调度三个子代理（A数据采集、B后端开发、C前端构建）协作完成AI大模型性能对比仪表板项目，展示了信号文件驱动的线性依赖链（A→B→C）机制。关键发现包括：信号文件有效实现任务同步与状态传递，主代理在任务分解中表现良好但生成子代理指令时存在冗余循环问题。可操作建议指出用户提供固化指令可提升协作稳定性，最终通过时间戳验证了顺序同步执行的有效性。 综合评分： 78 文章分类： 安全开发,解决方案,安全工具,技术标准,其他

Hermes的应用（三）：子代理二

白帽子

2026年5月4日 06:25 广东

在小说阅读器读本章

去阅读

以下文章来源于MicroPest ，作者MicroPest

MicroPest .

个人开发的小工具

上篇，调动了三个子代理开展工作，但被评判为三个独立无关联的子代理，虽同步但无联动。今天，我们来试个有联动的子代理。

一、设计题目

任务：构建一个“AI大模型性能实时对比仪表板”系统，要求三个子代理按顺序协作完成，最终交付一个可通过 Docker 一键启动的完整项目。

具体子任务分工如下：

Agent A（数据分析师）

• 从网上采集 2025 年最新的主流大模型基准测试数据（至少包含 Llama 3.3、Qwen2.5、Claude 3.5 家族中的代表模型）。
• 评测维度至少包含：GSM8K、MATH、MMLU、HumanEval、GPQA。
• 将数据清洗并整理成统一的 JSON 文件，保存到共享目录 ./shared/model_data.json。
• 数据就绪后，在 ./shared/ 下创建一个 data_ready.signal 信号文件。

Agent B（后端开发者）

• 监听 data_ready.signal 文件，一旦存在即开始工作。
• 使用 Python FastAPI 读取 model_data.json，构建 RESTful API。
• API 必须支持：获取所有模型列表、按模型名模糊搜索、一次请求返回多个模型的对比数据。
• API 应自动生成 Swagger 文档（/docs），方便前端查阅。
• 完成后端后，在 ./shared/ 下创建 backend_ready.signal 信号文件。

Agent C（前端开发者）

• 监听 backend_ready.signal 文件，一旦存在即开始工作。
• 使用 React + 可视化库（如 Recharts 或 D3）构建仪表板界面。
• 界面应包含：模型多选器、多指标柱状图或雷达图对比、数据来源说明。
• 通过调用 Agent B 的后端 API 获取数据。
• 为整个项目编写 README 和 API 使用文档。
• 提供 docker-compose.yml，确保最终可通过 docker-compose up 一键启动。

协作要求：

• Agent A 和 Agent B 必须协调好 JSON 字段结构；如果格式有分歧，允许 Agent B 在等待期间向 Agent A 提出修改要求。
• Agent B 和 Agent C 通过自动生成的 API 文档对齐接口格式。
• 所有代理的日志或代码注释中应体现出对前一阶段输出的依赖（例如引用共享文件路径或 API endpoint）。
• 整个流程要保证解耦：任一环节失败可以单独重跑，不影响已完成的部分。

最终交付标准：

• 在项目根目录执行 docker-compose up 后，浏览器打开能正确展示包含真实数据的对比图表。
• 共享目录中保留完整的信号文件和中间产物，以证明协作链条。
• 生成一份协作过程摘要，说明各代理之间的数据传递与触发顺序。

二、运行过程

图1：任务解析与全局规划

• 图2：为 Agent A 设计具体指令，包括数据采集、格式、文件路径和信号创建

• 图3：信号驱动的 Agent B 顺利执行

• 图4：启动最终环节 Agent C

Deepseek V4评判如下：

这四张图完整记录了 Hermes 主代理从接收任务到逐步调度子代理 A、B、C 的全过程，清晰展现了多代理协作中的任务拆分、依赖传递与逐级启动机制。以下是逐图分析。

🏞️ 图1：任务解析与全局规划

解决的问题

• 主代理接收到复杂任务后，解析任务要求，明确三个子代理的角色、依赖顺序（A→B→C）和最终交付标准。
• 建立协作基础：决定使用信号文件、共享目录 ./shared/、Docker Compose 一键启动等核心机制。
• 创建项目骨架：通过 todo 规划 8 个步骤，并实际创建了目录结构 shared/，为后续执行铺路。

关键产出

• 确认了“数据→后端→前端”的线性依赖链。
• 生成了可追踪的任务计划，避免遗漏环节。

🏞️ 图2：准备启动 Agent A，但陷入混乱

解决的问题

• 试图为 Agent A 设计具体指令，包括数据采集、格式、文件路径和信号创建。
• 暴露出两个问题：

1. 干扰性代码块：反复插入无关的 Python 脚本（transformers 加载、伪数据循环），与 Agent A 任务毫无关系，可能是主代理上下文污染或错误输出。
2. 指令冗余：多次重复“设计 prompt”的意图，却未给出最终可用的明确文本，说明主代理在提炼子代理 prompt 时遇到了表达困难。

实际进展

• 虽然混乱，但确认了 Agent A 需要 web 和 terminal 工具，并最终会用 delegate_task 启动。
• 为主代理后续修正提供了教训：子代理 prompt 必须简洁、无歧义，避免混杂无关内容。

🏞️ 图3：信号驱动的 Agent B 顺利执行

解决的问题

• 确认前置条件：检查 data_ready_signal 文件，证明 Agent A 已成功完成（尽管中间过程被省略）。

• 为 Agent B 制定精确、可执行的 prompt：

• 要求读取 /home/kali/shared/model_data.json。

• 明确三个 API 端点（GET /models、GET /models/search、POST /models/compare）。

• 包含 Swagger、CORS、日志记录等工程规范。

• 指定输出文件结构和信号文件名。

• 验证完成：Agent B 执行后，主代理立即检查 backend_ready_signal 并更新任务状态，体现了严格的依赖校验。

关键作用

• 展示了信号文件机制的实际运作：B 只有在 A 的信号出现后才启动，解决了上一轮并行任务中“无依赖传递”的问题。
• 给出了一个成功的子代理 prompt 模板（目标明确、路径绝对、输出可验证）。

🏞️ 图4：启动最终环节 Agent C，但陷入重复设计

解决的问题

• 检查前置信号：确认 backend_ready_signal 存在，满足 Agent C 的启动条件。
• 为 Agent C 设计任务大纲：包括 React 前端、图表库、调用后端 API、编写 docker‑compose.yml 和 README。
• 探索前端与后端的通信方式：反复权衡使用服务名 backend 还是 localhost，体现对 Docker 网络环境的适配思考。

存在的问题

• 严重的重复与冗余：多次复制粘贴相同的决策点（如“后端地址是 localhost:8000”），陷入了一种“循环设计”状态，反映出主代理在高复杂度任务下容易出现输出崩溃。
• 指令未最终固化：直到最后也没有给出 Agent C 的可直接执行 prompt，而是停留在“让我设计一个清晰的 prompt”的意图阶段。

实际意义

• 虽然执行受阻，但问题思考是到位的：明确了需要 Docker 多阶段构建、服务网络、文档路径等。
• 为人工介入或后续优化指出了方向：当主代理无法收敛时，应由用户给出更简洁的决策，或直接提供固化后的 prompt。

🔗 四张图之间的联系与作用

1. 依赖传导链 图1（总体规划）→ 图2（启动 A 的尝试）→ 图3（B 的成功执行，依赖 A 的信号）→ 图4（准备 C，依赖 B 的信号）。 整个过程严格遵循 A.signal → B → B.signal → C 的线性依赖链，体现了多代理协作的顺序性。

2. 信号机制作为协作的“神经传递” 图3和图4中，主代理两次主动检查信号文件（data_ready_signal、backend_ready_signal），这是这次多代理协作与之前“独立并行”的最大区别——有了可见的数据传递和状态同步。

3. 主代理的“协调者”角色与局限性

• 图1展现了协调者进行任务分解和路线规划的能力。
• 图2和图4暴露了协调者在生成子代理 prompt 时容易引入噪声或陷入死循环，说明当前版本的主代理在处理长链条、高细节任务时，需要更清晰的结构化提示或人机协作（例如用户提供固化指令）才能稳定前进。

4. 整体任务推进的“螺旋上升” 虽然图2和图4有波折，但最终依然实现了：目录创建 → Agent A 完成（信号可见） → Agent B 成功交付后端 → Agent C 的准备工作就绪。这种螺旋式进展（尝试→混乱→纠正→前进）正是多代理系统在现实任务中常见的执行特征。

总结：四张图连起来看，是一次成功的多代理顺序协作实验。它证明了信号文件驱动依赖的可行性（图3的顺畅执行），也如实反映了当前 Hermes 在自动生成复杂子代理 prompt 时容易出现冗余和循环的短板。对于使用者而言，最佳实践是由人给出类似图3中那种精确、无歧义的子代理指令，让主代理专注于调度和校验，从而兼顾灵活性与可靠性。

三、后面的事

我对上面的表述是心存疑的，所以让它给出了代码，以及最后的截图，如上。

我将hermes所有的输出都存放在这里了，可以下载来看：

通过网盘分享的文件：467.txt

链接: https://pan.baidu.com/s/1Ho6R_I6Ik_kEsS5c4sJvkg 提取码: wjrz

四、怎么确定三个代理是同步开展的呢？

我的疑虑，可以看出三个代理有前后的联动，但怎么确定三个代理是同步开展的呢？让hermes自证。

给出了四种自证方法。

✅ 结论

    从信号文件时间戳、任务完成时间记录和主线程执行逻辑三方面证据来看，三个子代理确实是按顺序同步执行的，严格遵循 A → B → C 的依赖链。

    每个阶段完成后都会在共享目录留下信号文件，既是触发下一阶段的依据，也是协作完成的永久证明。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：白帽子 《Hermes的应用（三）：子代理二》