Agent Zero Orchestrator 插件中 Hermes Agent 的无头委派流程与认证检测机制

Agent Zero Orchestrator 插件中 Hermes Agent 的无头委派流程与认证检测机制【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero本文以 Agent Zero 仓库中 orchestrator 技能的 Hermes 参考文件 为主体完整讲解通过 Hermes Agent CLI 执行“安静无头聊天”quiet headless chat的委派流程安装探测、冒烟提示词、人工介入登录、真实任务四步操作并结合插件源码适配器、配置、状态 API 与测试说明hermes配置块每个参数的含义以及 Agent Zero 如何自动检测 Hermes 的认证状态。读完本文你既能复制参考文档中的命令直接完成一次 Hermes 委派也能在仓库层面理解这些命令背后的设计契约与校验依据。Hermes 参考文件在 Orchestrator 中的位置Orchestrator 是 Agent Zero 的内置插件plugins/_orchestrator/README.md它为 Agent Zero 提供按需加载的外部终端编码智能体委派能力。插件刻意没有内置terminal_agent工具而是把委派逻辑放在技能里全局编排规则集中在 skills/orchestrator/SKILL.md而每个智能体各自的“安装、探测、认证、冒烟、真实任务”命令则存放在 references/ 目录下的一个 markdown 文件中——hermes.md就是其中针对 Hermes Agent 的一份。SKILL.md 的 frontmatter 中明确列出了delegate to hermes这一触发词意味着当用户在聊天中要求“delegate to hermes”时该技能才会被加载避免把冗重的委派指令塞进每个智能体的提示词。插件 README 的“Supported Agents”表格对 Hermes 的定义是AgentCLILoginHermes AgenthermesExternal Hermes/provider setup,~/.hermes/.env,~/.hermes/auth.json, or provider env vars这一行就是hermes.md参考文档与源码适配器 hermes.py 认证逻辑之间的契约。四步命令流程从安装探测到真实任务hermes.md的核心内容是一条完整的操作链。四步命令全部给出可按顺序复制执行。第一步安装与探测Install And Probecommand -v hermes /dev/null || curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes --version || hermes --help第一条命令的含义是先用command -v检查hermes是否已在 PATH 中未安装时才执行官方安装脚本第二条做版本/帮助探测确认 CLI 可运行。这个安装命令与源码中的声明是一致的——HermesAgentAdapter 类把install_hint设置为同一条 curl 命令说明设置界面Settings External Services Orchestrator在检测到 Hermes 未安装时展示给用户的安装提示与参考文档完全同源。基类 TerminalAgentAdapter.is_installed() 的探测逻辑也对应这一步配置了绝对路径的二进制会检查文件存在且可执行否则用shutil.which(binary)在 PATH 中查找。第二步冒烟提示词Smoke Promptcd $WORKDIR hermes chat --quiet --source tool -q Respond exactly: TERMINAL_AGENT_SMOKE_OK --yolo这是hermes.md中最关键的命令各参数的作用cd $WORKDIR先切换到显式工作目录。这是 SKILL.md 的强制规则——“Always choose an explicit working directory for repository work. Prefer the users project path over Agent Zeros default workdir.”在宿主 CLI 模式下应cd到宿主机项目路径而不是容器内的/a0/usr/workdir。--quiet安静模式不输出交互界面信息适合脚本化调用。--source tool标记本次会话来源是工具调用便于 Hermes 侧区分交互式与程序化调用。-q Respond exactly: TERMINAL_AGENT_SMOKE_OK要求模型精确复述固定字符串TERMINAL_AGENT_SMOKE_OK。这是其他参考文件通用的冒烟约定测试 test_status_adapters.py 中同样断言 Gemini 参考文件包含该字符串固定输出让“CLI 装好且模型链路通”这件事可被机器校验而不依赖主观判断。--yolo跳过审批对应文档首行“Use Hermes Agent for quiet headless chat. Skip approvals by default for non-interactive delegation.”的语义也与默认配置中的yolo: true呼应见下文配置节。第三步登录Login人工介入参考文档对登录环节只给出一条条件指令If Hermes needs setup, runhermes setup --portalwhen available, relay the OAuth/browser instructions to the user, wait for confirmation, and retry the smoke prompt. If it asks for a provider API key, have the user type it into the CLI prompt or set it as an environment variable outside chat.即当冒烟提示词暴露出未配置问题如需要 provider 凭据时执行hermes setup --portal如可用把 OAuth/浏览器步骤的原文转发给用户等待用户确认后再重跑冒烟提示词如果它索要的是某个 provider 的 API key则让用户直接输入到 CLI 自己的提示框中或在聊天之外的环境里设置环境变量——绝不让用户把密钥粘贴进聊天。这条指令不是孤立的它是 SKILL.md 全局规则的 Hermes 特化“Keep authentication human-in-the-loop”——可启动登录命令、转发 URL/设备码/提示内容但必须在用户确认完成前等待“Never start a full-screen CLI/TUI as a login fallback”——不要拿裸hermes命令当登录兜底“If login/setup shows a menu or provider choices, show those choices to the user in chat and ask which one to select”——菜单选项要转述到聊天里由用户选择而不是让用户自己开 Docker shell 去点。测试用例 test_status_adapters.py 中有一行专门校验assert hermes setup --portal in hermes_text保证这条登录指令不会被后续维护从参考文件中意外删掉。第四步真实任务Real TaskReplace the smoke prompt with $TASK. Add --model, --provider, or --toolsets only when the user or settings provide them.真实任务的命令形态就是把冒烟提示词中的-q内容替换为自包含的任务简报$TASK可选追加--model、--provider或--toolsets参数——但只有当用户或插件配置提供了这些值时才追加。这里的“settings”指的就是插件的default_config.yaml下一节展开三个参数与hermes配置块中的model、provider、toolsets一一对应默认值为空字符串时就不传把选择权留给 Hermes 自身。SKILL.md 对$TASK的写法有明确要求任务简报必须自包含——目标、目标文件/仓库路径、约束、验证命令、期望输出并且任务结束后Agent Zero 要“inspect its output and verify important changes yourself before reporting success”先检查并自行验证终端智能体的产出再向用户报告成功。配置块default_config.yaml中的 hermes 段插件默认配置 plugins/_orchestrator/default_config.yaml 中 Hermes 的配置块如下hermes: binary: hermes model: provider: toolsets: yolo: true逐项说明参数默认值含义binaryhermesCLI 二进制名。TerminalAgentAdapter.resolve_binary() 会优先取配置值配置为空时回落到类属性binary。也允许配置成绝对路径此时is_installed()检查该路径是否文件存在且可执行。model对应命令行的--model。空串表示不传该参数。provider对应命令行的--provider。空串表示不传由 Hermes 自行决定。toolsets对应命令行的--toolsets。空串表示不传。yolotrue对应--yolo非交互委派默认跳过审批。参考文档首句“Skip approvals by default”即来源于此默认值。配置块的读取路径在源码中是 registry.py 的adapter_config()从插件配置字典里取hermes键对应的 dict非 dict 则返回空字典。SKILL.md 还提到运行时可选项默认值可存放在/a0/usr/plugins/_orchestrator/config.json使用时只读所需适配器块且“never print secrets”绝不打印密钥。源码级实现HermesAgentAdapter 的三级认证检测参考文档描述“怎么用”helpers/adapters/hermes.py 则回答“设置界面如何判断 Hermes 是否已就绪”。HermesAgentAdapter继承自 TerminalAgentAdapter声明id hermes、title Hermes Agent、description Nous Research Hermes Agent CLI in quiet headless chat mode.这段描述正是参考文档“quiet headless chat”措辞的出处。其auth_status()方法按优先级做三级检测进程环境变量维护了一个约 30 个候选 provider 密钥的白名单_AUTH_ENV_VARShermes.py包括OPENAI_API_KEY、ANTHROPIC_API_KEY、GEMINI_API_KEY、GITHUB_TOKEN、OPENROUTER_API_KEY、XAI_API_KEY、KIMI_API_KEY、OLLAMA_API_KEY等。按字典序遍历取第一个非空的变量名返回{connected: True, mode: env, auth_path: 变量名}。注意它只把变量名作为auth_path上报不触碰变量值。.env文件Hermes 的家目录由HERMES_HOME环境变量决定未设置时为~/.hermes见_home()。.env的检测函数_env_file_has_key()逐行解析跳过空行、注释和不含的行检查白名单内的键是否有非空值值两侧引号会被剥离后判断命中则返回mode: external并指向该.env路径。auth.json凭据库检测函数_auth_store_has_credentials()要求文件存在、非空且为合法 JSON然后递归搜索_contains_secret是否存在六个“秘密键”之一——access_token、agent_key、api_key、id_token、refresh_token、runtime_api_key、token——且对应字符串长度大于 3。这与 README 表格中“~/.hermes/auth.json”这一登录来源精确对应。三级都未命中则返回{connected: False, mode: , auth_path: }。这一检测结果被 api/status.py 聚合状态 API 遍历 registry 中注册的全部 8 个适配器a0排首位Hermes 在grok之后、opencode之前对每个适配器调用auth_status()异常被捕获并转为connected: False加error字段连同installed、install_hint、supports_device_login、can_disconnect等元信息返回供“Settings External Services Orchestrator”状态界面渲染——用户可以在界面上看到hermes二进制路径、安装状态和检测到的认证来源。两个值得注意的设计边界适配器是“纯状态”的。测试 test_adapters_are_status_only() 断言所有适配器都没有install_command、build_command、parse_session_id、format_output属性——也就是说插件代码不组装也不执行任何 Hermes 命令命令的唯一权威来源就是references/hermes.md这份人类可读文档。这正是 README 所说“noterminal_agenttool”的落点执行发生在技能驱动的 shell 会话中插件代码只负责“检测”。Hermes 不支持插件侧的 device login。基类的supports_device_login()默认返回FalseHermesAgentAdapter未覆盖它所以状态界面不会为 Hermes 提供一键设备码登录——登录必须走参考文档描述的hermes setup --portal 人工确认流程这与 Codex 等支持插件自有设备码登录的适配器形成对比。参考文件背后的全局编排契约hermes.md只有 25 行但它是 SKILL.md 全局规则的“可复制命令化”。以下几条全局契约直接约束 Hermes 委派的每一步值得在执行前通读 SKILL.md先决定执行位置宿主机的hermes通过 A0 CLI 桥接用code_execution_remote还是 Agent Zero 容器内的hermespal 场景用code_execution_tool。用户未指明时先查记忆中是否有该智能体的执行位置偏好没有就问一句用户选择后用memory_save固化偏好。禁止 Computer Use不允许用“操控屏幕”的方式驱动编码智能体的终端、菜单或 TUI只允许无头 CLI 命令做不到就停下来问用户。安装即工作流的一部分“check whether the CLI is installed, install only the requested CLI if missing, probe its version/help, run a tiny smoke prompt, then run the real task”——与hermes.md的四节结构逐一对应。长命令用轮询而非超时包装对长时间运行的命令启动 shell 会话后轮询该会话输出不要给终端智能体套自制的 timeout 包装。多智能体对比可以在一个工作流中同时咨询宿主与容器的智能体但保持各自 shell 会话隔离、标注每个答案的来源比较后再行动。参考目录自身的 AGENTS.md 还规定了每份参考文件的必备要素何时使用该智能体、安装/探测命令、认证/设置行为、冒烟命令、真实任务命令形态——hermes.md的四个小节Install And Probe / Smoke Prompt / Login / Real Task恰好是这一契约的最小实现文件名与适配器 idhermes保持一致。在仓库中验证这些行为插件自带的测试脚本 plugins/_orchestrator/tests/test_status_adapters.py 覆盖了三类与 Hermes 直接相关的行为可运行只读查看输出不需要修改仓库test_registry_order_puts_a0_first()确认注册表顺序为a0, codex, claude, cursor, gemini, grok, hermes, opencode即状态界面的展示顺序test_skill_documents_human_setup_loop_and_a0_exception()断言hermes.md中包含hermes setup --portal保证登录指令在文档演进中不被删除test_adapters_are_status_only()固化“命令在文档、检测在代码”的职责边界。小结回到 hermes.md 本身它的价值在于把“委派给 Hermes Agent”这件重事压缩成了四个可直接复制的命令块安装探测command -v 官方脚本 --version、冒烟提示词hermes chat --quiet --source tool -q ... --yolo校验TERMINAL_AGENT_SMOKE_OK、人工介入登录hermes setup --portal确认前不重试、真实任务$TASK替换冒烟内容--model/--provider/--toolsets按需追加。围绕它的仓库实现则补齐了另一半default_config.yaml 的hermes块决定默认参数HermesAgentAdapter 用“环境变量 →~/.hermes/.env→~/.hermes/auth.json”三级检测回答“是否已就绪”api/status.py 把结果聚合进设置界面而测试用例把这些约束全部钉死在仓库里。理解这套“文档管命令、代码管检测、测试管契约”的分工也适用于阅读该插件其余七个智能体参考文件。【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考