
Agent Zero Orchestrator 插件实战用 a0 headless 让另一个 Agent Zero 实例帮你干活【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero本文基于 Agent Zero 仓库中 Orchestrator 插件的a0适配器参考文档references/a0.md完整讲解如何通过a0 headless命令行把编码或仓库任务委派给另一个 Agent Zero 运行时或者让当前实例通过本地 headless 接口“自问自答”一个聚焦问题。读完本文你将掌握目标实例的选择规则、安装与探测命令、新建/继续会话的完整命令形态、受保护主机的认证方式以及这些命令背后的适配器源码实现与测试验证。什么是 a0 headlessOrchestrator 插件中的“自家人”适配器Agent Zero 仓库中的 _orchestrator 插件 提供了一套按需加载的技能skill体系它不常驻一个庞大的terminal_agent工具而是在用户明确要求委派终端编码代理时才加载 SKILL.md 中的编排规则并读取skills/orchestrator/references/目录下对应代理的命令参考文件。支持的代理包括 Agent Zero (headless)、OpenAI Codex CLI、Claude Code、Cursor CLI、Gemini CLI、Grok Build、Hermes Agent 和 OpenCode。在这些代理中a0Agent Zero Headless是特殊的它的 CLI 就是a0登录态复用实例自身的/login会话受保护主机则通过 shell 环境变量A0_USERNAME/A0_PASSWORD认证见 README.md 的 Supported Agents 表。a0适配器有两大用途委派给另一个 Agent Zero 运行时用户希望另一台或另起一个Agent Zero 实例帮忙完成任务自问自答secondary use case同一个 Agent Zero 实例通过本地 headless 接口向自己提一个聚焦问题。在插件的注册顺序上AgentZeroAdapter被放在适配器列表的第一位见 registry.py测试 test_status_adapters.py 中的test_registry_order_puts_a0_first专门断言了这一点。目标选择规则A0 是“安装流程的例外”references/a0.md 开宗明义地规定A0 是 setup 例外不要跑通用的登录流程。与其他代理“检查安装→缺失则安装→探测→冒烟测试”的标准循环不同a0 的准备工作核心是“确定目标实例”如果用户没有指定目标实例Agent Zero 应该先询问是用当前这个 Agent Zero 实例还是另一个/新启动的实例如果目标是另一个实例询问或使用已配置的 host来自设置界面或用户提供对于受保护主机优先使用 shell 中已配置的环境凭据避免递归循环必须告知目标 Agent Zero 实例直接作答不要再通过 terminal agents 反向委派回来。这一“例外规则”在测试中有明确验证——test_status_adapters.py 中的test_skill_documents_human_setup_loop_and_a0_exception断言了a0.md必须包含 “A0 is the setup exception” 字样同时 SKILL.md 的容器 Pal 流程中要求“For Agent Zero Headless, readreferences/a0.mdand follow its target-selection flow instead of the non-A0 setup loop”见 SKILL.md 的 Container Pal Flow 一节。安装与探测Install And Probe原参考文档给出的安装/探测命令是command -v a0 /dev/null || test -x /opt/venv/bin/a0 a0 --help /dev/null || /opt/venv/bin/a0 --help /dev/null这里有一个关键细节在 Agent Zero 的 Docker 容器内部a0可执行文件并不一定在PATH中而是捆绑在/opt/venv/bin/a0。这与源码完全对应——a0.py 定义了两个常量DEFAULT_HOST http://localhost:80 DEFAULT_DOCKER_A0_BINARY /opt/venv/bin/a0其resolve_binary方法的实现逻辑a0.py先走基类 base.py 的resolve_binary优先取配置块中的binary字段如果解析结果仍是默认的a0且shutil.which(a0)找不到则检查捆绑的/opt/venv/bin/a0是否存在存在则直接返回该路径。配置块 default_config.yaml 中a0.binary: a0的注释也写明了 “falls back to /opt/venv/bin/a0 in Agent Zero Docker”。如果a0CLI 完全缺失适配器给出的安装提示是a0.py 的install_hintpip install githttps://github.com/agent0ai/a0-connector.gitdevelopment探测阶段用a0 --help或捆绑路径下的--help验证 CLI 可正常运行而不是直接发任务。新建会话--new-chat一次性命令原参考文档的“New Chat”命令a0.mdcd $WORKDIR a0 headless --host http://localhost:80 --no-docker-discovery --output jsonl --new-chat --workspace $WORKDIR -p $TASK各参数要点--host http://localhost:80容器内部 WebUI 监听 80 端口因此默认目标就是“运行本插件的这个实例”。源码注释写得很直白“Inside the Agent Zero container, the local WebUI listens on port 80, so the default target is the instance running this very plugin.”a0.py。当设置界面或用户提供了远程 host 时应替换为配置的远程地址--no-docker-discovery跳过 Docker 发现避免容器环境下的探测干扰--output jsonl以 JSON Lines 格式输出便于机器解析任务结果--new-chat新建一次独立会话一次性的 one-shot 模式a0 headless的委托机制即建立在此之上见 a0.py 的类 docstring--workspace $WORKDIR显式指定工作目录。SKILL.md 全局规则强调“始终为仓库工作选择显式工作目录优先用户的项目路径而非 Agent Zero 默认 workdir”-p $TASK传入自包含的任务说明。SKILL.md 要求任务说明应包含目标、目标文件或仓库路径、约束、验证命令和期望输出。继续会话--chat复用上下文受保护主机用环境变量原参考文档的“Continue Chat”命令a0.mda0 headless --host $A0_HOST --no-docker-discovery --output jsonl --chat $CONTEXT_ID --workspace $WORKDIR -p $TASK与新建会话相比核心差异是把--new-chat换成了--chat $CONTEXT_ID即携带上次会话的上下文 ID 继续对话——这样可以在同一目标实例上多轮追问而不是每次都从零开始。对于受保护主机需要登录认证的 Agent Zero 实例文档明确使用 CLI 支持的环境变量例如A0_USERNAME和A0_PASSWORD而不是臆造 username/password 命令行参数。这与 README.md 中登录表的一致性说明相符a0 代理的凭据路径是“实例/login会话受保护主机用 shell 中的A0_USERNAME/A0_PASSWORD”。源码透视host 解析优先级与连接探测从 a0.py 的源码看a0适配器的目标解析遵循清晰的三级优先级resolve_host插件配置块default_config.yaml中a0.host字段非空即用环境变量AGENT_ZERO_HOST兜底http://localhost:80本地实例。配置块原文default_config.yamla0: binary: a0 # falls back to /opt/venv/bin/a0 in Agent Zero Docker host: # empty AGENT_ZERO_HOST env, else local instancehost留空时行为与参考文档一致先查环境变量否则打本地实例。认证状态检测则实现为一次轻量 TCP 探测auth_status 调用_probea0.py把 host 解析为http(s)://URL取默认端口80/443后以 2 秒超时尝试socket.create_connection成功即返回{connected: True, mode: external, ...}。注意这只是连通性探测——真正的会话认证仍由a0 headless自身与实例的/login会话机制处理a0 适配器不拥有独立的凭据存储因此也不提供 device login 或 disconnect 能力基类 base.py 中这些能力默认返回False/抛NotImplementedError只有 Codex 这类拥有已知凭据存储的适配器才覆写。在设置界面Settings External Services中a0适配器会展示其二进制路径、安装状态与上述探测到的连接状态注册流程见 registry.py 的get_adapter/list_adapters与 api 层。编排上下文命令如何被 Agent Zero 实际执行参考文档里的命令并非孤立存在SKILL.md 规定了它们被执行时的上下文执行位置判定容器 Pal 流程container 模式使用code_execution_tool在 Agent Zero 容器 shell 中运行host 模式使用code_execution_remote。a0 参考文档主要面向容器内场景——目标就是http://localhost:80的本实例或可达的另一实例见 SKILL.md 与 README.md 中 “The a0 adapter targets the local Agent Zero instance (http://localhost:80inside the container) when nohost/AGENT_ZERO_HOSTis configured”长任务策略SKILL.md 全局规则要求“对长时命令把 CLI 放进一个 shell 会话中并轮询该会话的输出不要自己加 timeout 包装”结果验证目标代理完成后Agent Zero 必须检查其输出、自行验证重要变更后再汇报成功多代理对比允许在同一工作流中同时咨询 host 与容器代理但要保持各自 shell 会话独立、标注答案来源比较后再行动。测试对参考文档的命令完整性也有硬性约束test_status_adapters.py 断言a0.md必须同时包含--new-chat和--chat $CONTEXT_ID两个关键用法防止参考文档在后续维护中丢失这两种会话形态。实践要点小结场景命令形态说明安装/探测command -v a0 /dev/null \|\| test -x /opt/venv/bin/a0等容器内优先探测/opt/venv/bin/a0捆绑路径新会话a0 headless --host http://localhost:80 --no-docker-discovery --output jsonl --new-chat --workspace $WORKDIR -p $TASK一次性问题远程目标替换--host继续会话同上--new-chat换--chat $CONTEXT_ID复用上下文多轮追问受保护主机shell 环境设置A0_USERNAME/A0_PASSWORD不要用不存在的 CLI 参数臆造认证方式防递归任务说明中要求目标实例直接作答禁止目标实例再反向委派 terminal agents参考文件命令参考本文主体plugins/_orchestrator/skills/orchestrator/references/a0.md编排技能总规则plugins/_orchestrator/skills/orchestrator/SKILL.md插件说明与适配器总表plugins/_orchestrator/README.md适配器源码plugins/_orchestrator/helpers/adapters/a0.py适配器基类契约plugins/_orchestrator/helpers/adapters/base.py适配器注册表plugins/_orchestrator/helpers/registry.py默认配置plugins/_orchestrator/default_config.yaml状态/技能回归测试plugins/_orchestrator/tests/test_status_adapters.py【免费下载链接】agent-zeroAgent Zero AI framework项目地址: https://gitcode.com/GitHub_Trending/ag/agent-zero创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考