Harbor Buzz Orchestra 编排器 Persona 全解M1 hello-world 团队协作基准的角色设计【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz导读benchmarks/harbor-buzz-orchestra/personas/orchestrator-m1.md是 Harbor Buzz Orchestra 基准中 M1 hello-world 关卡为编排器orchestratorAgent 设计的系统提示词persona它定义了编排器如何通过 Buzz 频道与 worker 协作、如何拆解任务、如何验证结果并最终向用户交付DONE:报告。本文以这份 persona 为主体结合同目录下的 worker persona、m1-hello-world.yaml清单、BuzzOrchestraAgent适配器源码与测试完整解析这套一人编排、多人执行、全量经频道发布的多 Agent 协作协议并说明如何在本地复现这一基准。一、M1 hello-world 在基准体系中的定位1.1 为什么需要一个编排器 persona在 benchmarks/harbor-buzz-orchestra/README.md 描述的架构中Harbor 只见一个BuzzOrchestraAgent自定义 Agent在这个适配器背后一个编排器与 N 个 worker 通过生产环境 relay/Postgres 进行协作。每个 Agent 都运行在 Harbor 任务容器内复用桌面应用启动的同一套buzz-acp→buzz-agent→buzz-dev-mcp进程树完整的生产 MCP 工具集shell、文件工具、todo且buzzCLI 已在 shell 的 PATH 上。M1 是这条链路的最小验证关卡wiring proof清单文件头注释明确写着M1 清单中的端点只是本地占位符用于证明 wiring 成立pilot/2.1 清单才会携带精确的 Databricks serving 端点修订与冻结的价格表。因此orchestrator-m1.md本质上是一份最小可行团队中领导角色的行为规范。1.2 与 TB 编排器 persona 的关系同目录下另有 orchestrator-tb.md 用于 Terminal-Bench 团队。两者核心一致但 TB 版本新增了一条关键约束每个验证步骤必须指派给与被执行工作不同的 worker——独立验证禁止自审且不得仅凭 worker 声称就报告完成。M1 版本则保持最小集编排器自行对照任务成功标准核验 worker 输出即可。二、persona 全文精读编排器的四条铁律orchestrator-m1.md篇幅精炼但信息密度很高可拆成三条结构性设定加五条操作规则。2.1 结构性设定角色边界、发布通道与可见性原文开篇即声明三条身份约束编排器自己不执行命令You do not run commands yourself; workers do. You coordinate over a Buzz channel. 所有终端操作都由 worker 完成。buzzCLI 已在 PATH 且已认证编排器的 shell 工具里有一个已认证的buzzCLI这是它与团队、与用户通信的唯一途径。未发布即不可见Nothing you write is visible to anyone unless you publish it——任何消息步骤指派、验证请求、最终DONE:都必须通过buzz messages send --channel channel-id --content text发送。轮次只有在消息发布后才算结束。这套设定从机制上杜绝了Agent 在本地自言自语、团队却一无所知的静默失败协作状态全部落在 Buzz 频道的事件时间线上可审计、可回放。2.2 五条操作规则详解规则原文要点设计意图1. 拆解任务阅读任务指令拆成最小的具体步骤让步骤可独立验证、可并行/串行调度2. 按步指派每步用一个消息指派给一个 workermention该 worker写明确切目标与成功检查而非仅给命令防止 worker 只机械执行命令而不理解验收标准3. 串行依赖指派下一个依赖步骤前必须等待该 worker 的报告保证数据依赖与文件系统状态一致4. 自行验证worker 报告输出后编排器要自己对照任务成功标准核验再继续防止把未经核验的声明当作事实向上传递5. 显式交付任务完成时发布以DONE:开头的最终消息mention用户总结产物与验证方式消息未发布即任务未完成绝不静默收尾保证用户Human 侧 CLI总能收到明确的交付信号2.3 两个容易被忽视的细节约束原文还包含两条非常具体、直接影响任务能否通过评分的约束不要发明绝对路径。任务在 worker 的终端工作目录中运行除非任务指令本身指名路径否则用裸相对文件名如hello.txt引用文件绝不发明绝对路径。这一条与 worker persona 中的警告呼应mkdir -p一个虚构路径会把文件放进 grader 永远不会查看的位置从而静默失败。逐字转述任务要求不加戏。不得添加任务未声明的约束路径、编码、字节级规则例如禁止末尾换行任务未说明之处让标准工具默认值生效。这条约束直接服务于基准评分的公平性——任何编排器自创约束导致输出不符都算作 Agent 的缺陷。2.4 沟通风格与真实性底线最后一段是三句纪律消息保持简短绝不捏造命令输出若 worker 报告含糊要求其用精确的验证命令重跑。这与 worker persona 的报告失败必须原文照录、不得擅自改换方案互为镜像共同构成对模型幻觉的对抗设计。三、worker persona协议的另一半理解编排器必须同时看它的协作者 worker-m1.md只有被mention才行动Act only on steps assigned to you by the orchestrators mention.每条报告必须以 mention 开头编排器只会被提及它的消息唤醒A report that mentions nobody is invisible and the task will stall. 若上下文可见指派的 event id还需用--reply-to event-id把报告挂到线程下。报告固定格式一条消息包含所执行的命令、退出码、相关输出截断但绝不虚构。失败即停止命令失败就原文报告失败并停下不擅自换方案。没有验证输出就不算成功Never claim success without showing the verifying output.可以看到编排器的规则 2写明成功检查、规则 4自己核验与 worker 的规则 5展示验证输出是咬合的编排器不能仅凭 worker 的成功字样放行worker 必须给出可核验的真实输出。四、清单级证据m1-hello-world.yaml 如何把 persona 焊进条件manifests/m1-hello-world.yaml 是 M1 条件的完整定义它把上述 persona 以字节级固定byte-pinned方式纳入实验条件schema_version: 1 condition: M1-hello-world roster: - id: orch kind: orchestrator role: lead count: 1 endpoint: local/placeholder-orchestrator model_revision: m1-placeholder prompt: path: personas/orchestrator-m1.md sha256: af64b515de914c99fbdfc5a50830909ac10ab3a4f37e8352a354019a6be74151 generation: max_output_tokens: 4096 context_window_tokens: 128000 - id: worker kind: worker role: implementer count: 1 endpoint: local/placeholder-worker model_revision: m1-placeholder prompt: path: personas/worker-m1.md sha256: f3fef3d2c42105c256ff019d71ef99506b31a23e8cb252cac727c8bc470eb304 generation: max_output_tokens: 4096 context_window_tokens: 128000 prices: local/placeholder-orchestrator: input_per_million_usd: 0 cached_input_per_million_usd: 0 output_per_million_usd: 0 local/placeholder-worker: input_per_million_usd: 0 cached_input_per_million_usd: 0 output_per_million_usd: 0 trial_budget: timeout_seconds: 1800关键点逐一说明prompt.sha256persona 文件被 sha256 固定任何对提示词的改动都会改变条件哈希使实验条件不可变、可复现。实现见 src/harbor_buzz_orchestra/manifest.pycanonical_bytes()把清单规范化为排序键的紧凑 JSON 后计算sha256作为这两个运行是否是同一实验的答案。generation每个角色独立设置max_output_tokens: 4096与context_window_tokens: 128000。源码中的GenerationConfig还支持temperature默认0.0与可选的thinking_effortnone/minimal/low/medium/high/xhigh/max未显式钉住thinking_effort时运行在运行时默认值THINKING_EFFORT当前为medium且不改变条件哈希保证在 effort 轴引入之前写成的清单保持身份与可比性见 tests/test_manifest.py 的回归测试。prices每个端点冻结每百万 token 的输入/缓存输入/输出美元价格M1 占位端点为 0。ExperimentManifest的校验器会强制roster 恰好一个 orchestrator、roster id 唯一、所有 endpoint 都有价格任何未知字段extraforbid都会被拒绝——防止拼写错误悄悄改变实验条件。trial_budget.timeout_seconds: 1800整个 trial 的硬超时30 分钟由运行期强制而不是异步收据。endpoint_config将端点映射到 provider、URL 与 API key 环境变量。testbed/endpoints/m1-local.json 显示 M1 两个占位端点都指向provider: openai、api_key_env: OPENAI_COMPAT_API_KEY、OPENAI_COMPAT_BASE_URL: http://127.0.0.1:8091/v1——即本地串行模型的 OpenAI 兼容接口。五、协议背后的工程保障适配器、provisioner 与运行期5.1 BuzzOrchestraAgentpersona 的装载点src/harbor_buzz_orchestra/agent.py 中的BuzzOrchestraAgent是 Harbor 自定义 Agent 入口构造参数包括manifestYAML/JSON 路径或字典加载即校验provisioner_factoryprovisioner_config必须成对提供通过harbor.utils.import_path.import_symbol导入工厂如harbor_buzz_testbed:provisioner_from_dictartifact_rootendpoint_config同样成对前者是产物根目录后者把端点名映射到EndpointLaunchConfigbuzz_acp_binary/buzz_agent_binary/buzz_dev_mcp_binaryLinux构建会上传到任务容器musl-static任意 Linux 基础镜像可用buzz_cli_binary是宿主机 CLI测试台用它扮演 trial 用户。run()的流程与 persona 的发布才算完成理念一致以 Harborcontext_id作为 trial join keyprovisioner.create_trial创建 trial校验返回的manifest_hash与trial_id必须与本地一致随后runtime.run()驱动整支队伍最后在finally中teardown。token 与费用会写回 Harbor 的AgentContext并把manifest_sha256、condition、buzz_channel_id、run_id、trial_id写入 metadata。单元测试 tests/test_agent.py 验证了生命周期、运行时失败仍会 teardown、缺少集成时显式报错M1 wiring is incomplete。5.2 每次 trial 的安全边界testbed/src/harbor_buzz_testbed/provisioner.py 的BuzzTrialProvisioner保证了四条不变量create_trial同步且按(run_id, trial_id)幂等通过 Postgres advisory lock 保证并发安全每个 trial 一个私有频道成员恰好是该 trial 的凭据集合跨 trial 读取被构造性阻断每次 trial 生成全新密钥绝不复用teardown归档频道并打上archived_at戳事件永不删除——relay/Postgres 事件时间线与每个 Agent 的 acp/agent 日志下载到 trial 的buzz/产物中都可供事后分析。若设置了user_secret_key所有 trial 共享同一个用户身份人类对等体GUI 以其登录即可看到所有 trial 频道逐条累积。5.3 运行期快照与证据导出Agent 停止后运行期会把公开 relay 状态源消息及任务声明的频道与成员快照到/logs/artifacts/buzz-evidence.json快照导出失败则 trial 直接判失败而非 0 分——harness 故障与模型故障保持可区分——原因写入 trial 的buzz/buzz-evidence-error.txt。relay 凭据与数据库访问从不暴露给模型或验证器。六、本地复现 M1如何跑起这个编排器 worker 团队在 README 中一次完整运行在生产 compose 栈 模型端点已就绪的前提下执行核心命令harbor run直接驱动uv run --project benchmarks/harbor-buzz-orchestra/testbed harbor run --yes -p TASK_OR_DIRECTORY \ --agent harbor_buzz_orchestra:BuzzOrchestraAgent \ --agent-kwarg manifestCONDITION.yaml \ --agent-kwarg provisioner_factoryharbor_buzz_testbed:provisioner_from_dict \ --agent-kwarg provisioner_configPROVISIONER.json \ --agent-kwarg endpoint_configENDPOINTS.json \ --agent-kwarg artifact_rootbenchmarks/harbor-buzz-orchestra \ --agent-kwarg buzz_acp_binaryLINUX_BIN/buzz-acp \ --agent-kwarg buzz_agent_binaryLINUX_BIN/buzz-agent \ --agent-kwarg buzz_dev_mcp_binaryLINUX_BIN/buzz-dev-mcp \ --agent-kwarg buzz_cli_binarytarget/debug/buzz \ --agent-kwarg run_idbench-$(date -u %Y%m%dT%H%M%SZ) \ --agent-timeout-multiplier 15 --n-concurrent 1要点--n-concurrent 1是串行本地模型的安全笔记本设置并非编排要求just benchmark会自动交叉构建 musl-static 的 acp/agent/dev-mcp 二进制部分 TB grader 会在验证时从公共包仓库安装依赖应避开会拦截此类安装的网络如企业 VPNjust benchmark单命令路径会拉起专用 Docker 栈buzz-benchmarkcompose 项目relay :3600、Postgres :5633--gui可打开 Buzz 桌面应用以钉住用户身份实时观看频道累积——但只准旁观人类中途发消息会污染 trial。验证整个 harnesspersona 校验、清单哈希、适配器单元测试等cd benchmarks/harbor-buzz-orchestra uv run --extra dev pytest -q uv run --extra dev ruff check . cd testbed uv run --extra dev pytest -q uv run --extra dev ruff check .七、从这份 persona 提炼的多 Agent 协作设计要点作为一份最小可行编排器行为规范orchestrator-m1.md浓缩了可复用的设计原则协作通道必须外置且强制所有消息经buzz messages send发布到频道消息未发布则轮次未结束。静默完成never conclude silently被明确定为违规从提示词层面消除了最常见的 Agent 失败模式。指派要写验收标准而非命令本身State the exact goal and the success check, not just the command to run. 这让 worker 在执行偏离时有判断依据。约束最小化不发明路径、不加戏、任务沉默处交给工具默认值。这对任何在受控环境中评分的 Agent 基准都适用。验证责任在编排器worker 报告输出后编排器必须自行对照成功标准核验TB 版本更进一步要求验证步骤交给不同的 worker杜绝自审。交付以显式DONE:消息为准向用户mention并总结产物与验证方式让用户侧Human CLI有明确的完成信号。延伸阅读编排器 persona本文主体worker persona协议另一半TB 团队编排器 persona含独立验证规则M1 清单 与 适配器源码清单 schema 与条件哈希实现、清单校验测试基准总览 README【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Harbor Buzz Orchestra 编排器 Persona 全解：M1 hello-world 团队协作基准的角色设计
Harbor Buzz Orchestra 编排器 Persona 全解M1 hello-world 团队协作基准的角色设计【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz导读benchmarks/harbor-buzz-orchestra/personas/orchestrator-m1.md是 Harbor Buzz Orchestra 基准中 M1 hello-world 关卡为编排器orchestratorAgent 设计的系统提示词persona它定义了编排器如何通过 Buzz 频道与 worker 协作、如何拆解任务、如何验证结果并最终向用户交付DONE:报告。本文以这份 persona 为主体结合同目录下的 worker persona、m1-hello-world.yaml清单、BuzzOrchestraAgent适配器源码与测试完整解析这套一人编排、多人执行、全量经频道发布的多 Agent 协作协议并说明如何在本地复现这一基准。一、M1 hello-world 在基准体系中的定位1.1 为什么需要一个编排器 persona在 benchmarks/harbor-buzz-orchestra/README.md 描述的架构中Harbor 只见一个BuzzOrchestraAgent自定义 Agent在这个适配器背后一个编排器与 N 个 worker 通过生产环境 relay/Postgres 进行协作。每个 Agent 都运行在 Harbor 任务容器内复用桌面应用启动的同一套buzz-acp→buzz-agent→buzz-dev-mcp进程树完整的生产 MCP 工具集shell、文件工具、todo且buzzCLI 已在 shell 的 PATH 上。M1 是这条链路的最小验证关卡wiring proof清单文件头注释明确写着M1 清单中的端点只是本地占位符用于证明 wiring 成立pilot/2.1 清单才会携带精确的 Databricks serving 端点修订与冻结的价格表。因此orchestrator-m1.md本质上是一份最小可行团队中领导角色的行为规范。1.2 与 TB 编排器 persona 的关系同目录下另有 orchestrator-tb.md 用于 Terminal-Bench 团队。两者核心一致但 TB 版本新增了一条关键约束每个验证步骤必须指派给与被执行工作不同的 worker——独立验证禁止自审且不得仅凭 worker 声称就报告完成。M1 版本则保持最小集编排器自行对照任务成功标准核验 worker 输出即可。二、persona 全文精读编排器的四条铁律orchestrator-m1.md篇幅精炼但信息密度很高可拆成三条结构性设定加五条操作规则。2.1 结构性设定角色边界、发布通道与可见性原文开篇即声明三条身份约束编排器自己不执行命令You do not run commands yourself; workers do. You coordinate over a Buzz channel. 所有终端操作都由 worker 完成。buzzCLI 已在 PATH 且已认证编排器的 shell 工具里有一个已认证的buzzCLI这是它与团队、与用户通信的唯一途径。未发布即不可见Nothing you write is visible to anyone unless you publish it——任何消息步骤指派、验证请求、最终DONE:都必须通过buzz messages send --channel channel-id --content text发送。轮次只有在消息发布后才算结束。这套设定从机制上杜绝了Agent 在本地自言自语、团队却一无所知的静默失败协作状态全部落在 Buzz 频道的事件时间线上可审计、可回放。2.2 五条操作规则详解规则原文要点设计意图1. 拆解任务阅读任务指令拆成最小的具体步骤让步骤可独立验证、可并行/串行调度2. 按步指派每步用一个消息指派给一个 workermention该 worker写明确切目标与成功检查而非仅给命令防止 worker 只机械执行命令而不理解验收标准3. 串行依赖指派下一个依赖步骤前必须等待该 worker 的报告保证数据依赖与文件系统状态一致4. 自行验证worker 报告输出后编排器要自己对照任务成功标准核验再继续防止把未经核验的声明当作事实向上传递5. 显式交付任务完成时发布以DONE:开头的最终消息mention用户总结产物与验证方式消息未发布即任务未完成绝不静默收尾保证用户Human 侧 CLI总能收到明确的交付信号2.3 两个容易被忽视的细节约束原文还包含两条非常具体、直接影响任务能否通过评分的约束不要发明绝对路径。任务在 worker 的终端工作目录中运行除非任务指令本身指名路径否则用裸相对文件名如hello.txt引用文件绝不发明绝对路径。这一条与 worker persona 中的警告呼应mkdir -p一个虚构路径会把文件放进 grader 永远不会查看的位置从而静默失败。逐字转述任务要求不加戏。不得添加任务未声明的约束路径、编码、字节级规则例如禁止末尾换行任务未说明之处让标准工具默认值生效。这条约束直接服务于基准评分的公平性——任何编排器自创约束导致输出不符都算作 Agent 的缺陷。2.4 沟通风格与真实性底线最后一段是三句纪律消息保持简短绝不捏造命令输出若 worker 报告含糊要求其用精确的验证命令重跑。这与 worker persona 的报告失败必须原文照录、不得擅自改换方案互为镜像共同构成对模型幻觉的对抗设计。三、worker persona协议的另一半理解编排器必须同时看它的协作者 worker-m1.md只有被mention才行动Act only on steps assigned to you by the orchestrators mention.每条报告必须以 mention 开头编排器只会被提及它的消息唤醒A report that mentions nobody is invisible and the task will stall. 若上下文可见指派的 event id还需用--reply-to event-id把报告挂到线程下。报告固定格式一条消息包含所执行的命令、退出码、相关输出截断但绝不虚构。失败即停止命令失败就原文报告失败并停下不擅自换方案。没有验证输出就不算成功Never claim success without showing the verifying output.可以看到编排器的规则 2写明成功检查、规则 4自己核验与 worker 的规则 5展示验证输出是咬合的编排器不能仅凭 worker 的成功字样放行worker 必须给出可核验的真实输出。四、清单级证据m1-hello-world.yaml 如何把 persona 焊进条件manifests/m1-hello-world.yaml 是 M1 条件的完整定义它把上述 persona 以字节级固定byte-pinned方式纳入实验条件schema_version: 1 condition: M1-hello-world roster: - id: orch kind: orchestrator role: lead count: 1 endpoint: local/placeholder-orchestrator model_revision: m1-placeholder prompt: path: personas/orchestrator-m1.md sha256: af64b515de914c99fbdfc5a50830909ac10ab3a4f37e8352a354019a6be74151 generation: max_output_tokens: 4096 context_window_tokens: 128000 - id: worker kind: worker role: implementer count: 1 endpoint: local/placeholder-worker model_revision: m1-placeholder prompt: path: personas/worker-m1.md sha256: f3fef3d2c42105c256ff019d71ef99506b31a23e8cb252cac727c8bc470eb304 generation: max_output_tokens: 4096 context_window_tokens: 128000 prices: local/placeholder-orchestrator: input_per_million_usd: 0 cached_input_per_million_usd: 0 output_per_million_usd: 0 local/placeholder-worker: input_per_million_usd: 0 cached_input_per_million_usd: 0 output_per_million_usd: 0 trial_budget: timeout_seconds: 1800关键点逐一说明prompt.sha256persona 文件被 sha256 固定任何对提示词的改动都会改变条件哈希使实验条件不可变、可复现。实现见 src/harbor_buzz_orchestra/manifest.pycanonical_bytes()把清单规范化为排序键的紧凑 JSON 后计算sha256作为这两个运行是否是同一实验的答案。generation每个角色独立设置max_output_tokens: 4096与context_window_tokens: 128000。源码中的GenerationConfig还支持temperature默认0.0与可选的thinking_effortnone/minimal/low/medium/high/xhigh/max未显式钉住thinking_effort时运行在运行时默认值THINKING_EFFORT当前为medium且不改变条件哈希保证在 effort 轴引入之前写成的清单保持身份与可比性见 tests/test_manifest.py 的回归测试。prices每个端点冻结每百万 token 的输入/缓存输入/输出美元价格M1 占位端点为 0。ExperimentManifest的校验器会强制roster 恰好一个 orchestrator、roster id 唯一、所有 endpoint 都有价格任何未知字段extraforbid都会被拒绝——防止拼写错误悄悄改变实验条件。trial_budget.timeout_seconds: 1800整个 trial 的硬超时30 分钟由运行期强制而不是异步收据。endpoint_config将端点映射到 provider、URL 与 API key 环境变量。testbed/endpoints/m1-local.json 显示 M1 两个占位端点都指向provider: openai、api_key_env: OPENAI_COMPAT_API_KEY、OPENAI_COMPAT_BASE_URL: http://127.0.0.1:8091/v1——即本地串行模型的 OpenAI 兼容接口。五、协议背后的工程保障适配器、provisioner 与运行期5.1 BuzzOrchestraAgentpersona 的装载点src/harbor_buzz_orchestra/agent.py 中的BuzzOrchestraAgent是 Harbor 自定义 Agent 入口构造参数包括manifestYAML/JSON 路径或字典加载即校验provisioner_factoryprovisioner_config必须成对提供通过harbor.utils.import_path.import_symbol导入工厂如harbor_buzz_testbed:provisioner_from_dictartifact_rootendpoint_config同样成对前者是产物根目录后者把端点名映射到EndpointLaunchConfigbuzz_acp_binary/buzz_agent_binary/buzz_dev_mcp_binaryLinux构建会上传到任务容器musl-static任意 Linux 基础镜像可用buzz_cli_binary是宿主机 CLI测试台用它扮演 trial 用户。run()的流程与 persona 的发布才算完成理念一致以 Harborcontext_id作为 trial join keyprovisioner.create_trial创建 trial校验返回的manifest_hash与trial_id必须与本地一致随后runtime.run()驱动整支队伍最后在finally中teardown。token 与费用会写回 Harbor 的AgentContext并把manifest_sha256、condition、buzz_channel_id、run_id、trial_id写入 metadata。单元测试 tests/test_agent.py 验证了生命周期、运行时失败仍会 teardown、缺少集成时显式报错M1 wiring is incomplete。5.2 每次 trial 的安全边界testbed/src/harbor_buzz_testbed/provisioner.py 的BuzzTrialProvisioner保证了四条不变量create_trial同步且按(run_id, trial_id)幂等通过 Postgres advisory lock 保证并发安全每个 trial 一个私有频道成员恰好是该 trial 的凭据集合跨 trial 读取被构造性阻断每次 trial 生成全新密钥绝不复用teardown归档频道并打上archived_at戳事件永不删除——relay/Postgres 事件时间线与每个 Agent 的 acp/agent 日志下载到 trial 的buzz/产物中都可供事后分析。若设置了user_secret_key所有 trial 共享同一个用户身份人类对等体GUI 以其登录即可看到所有 trial 频道逐条累积。5.3 运行期快照与证据导出Agent 停止后运行期会把公开 relay 状态源消息及任务声明的频道与成员快照到/logs/artifacts/buzz-evidence.json快照导出失败则 trial 直接判失败而非 0 分——harness 故障与模型故障保持可区分——原因写入 trial 的buzz/buzz-evidence-error.txt。relay 凭据与数据库访问从不暴露给模型或验证器。六、本地复现 M1如何跑起这个编排器 worker 团队在 README 中一次完整运行在生产 compose 栈 模型端点已就绪的前提下执行核心命令harbor run直接驱动uv run --project benchmarks/harbor-buzz-orchestra/testbed harbor run --yes -p TASK_OR_DIRECTORY \ --agent harbor_buzz_orchestra:BuzzOrchestraAgent \ --agent-kwarg manifestCONDITION.yaml \ --agent-kwarg provisioner_factoryharbor_buzz_testbed:provisioner_from_dict \ --agent-kwarg provisioner_configPROVISIONER.json \ --agent-kwarg endpoint_configENDPOINTS.json \ --agent-kwarg artifact_rootbenchmarks/harbor-buzz-orchestra \ --agent-kwarg buzz_acp_binaryLINUX_BIN/buzz-acp \ --agent-kwarg buzz_agent_binaryLINUX_BIN/buzz-agent \ --agent-kwarg buzz_dev_mcp_binaryLINUX_BIN/buzz-dev-mcp \ --agent-kwarg buzz_cli_binarytarget/debug/buzz \ --agent-kwarg run_idbench-$(date -u %Y%m%dT%H%M%SZ) \ --agent-timeout-multiplier 15 --n-concurrent 1要点--n-concurrent 1是串行本地模型的安全笔记本设置并非编排要求just benchmark会自动交叉构建 musl-static 的 acp/agent/dev-mcp 二进制部分 TB grader 会在验证时从公共包仓库安装依赖应避开会拦截此类安装的网络如企业 VPNjust benchmark单命令路径会拉起专用 Docker 栈buzz-benchmarkcompose 项目relay :3600、Postgres :5633--gui可打开 Buzz 桌面应用以钉住用户身份实时观看频道累积——但只准旁观人类中途发消息会污染 trial。验证整个 harnesspersona 校验、清单哈希、适配器单元测试等cd benchmarks/harbor-buzz-orchestra uv run --extra dev pytest -q uv run --extra dev ruff check . cd testbed uv run --extra dev pytest -q uv run --extra dev ruff check .七、从这份 persona 提炼的多 Agent 协作设计要点作为一份最小可行编排器行为规范orchestrator-m1.md浓缩了可复用的设计原则协作通道必须外置且强制所有消息经buzz messages send发布到频道消息未发布则轮次未结束。静默完成never conclude silently被明确定为违规从提示词层面消除了最常见的 Agent 失败模式。指派要写验收标准而非命令本身State the exact goal and the success check, not just the command to run. 这让 worker 在执行偏离时有判断依据。约束最小化不发明路径、不加戏、任务沉默处交给工具默认值。这对任何在受控环境中评分的 Agent 基准都适用。验证责任在编排器worker 报告输出后编排器必须自行对照成功标准核验TB 版本更进一步要求验证步骤交给不同的 worker杜绝自审。交付以显式DONE:消息为准向用户mention并总结产物与验证方式让用户侧Human CLI有明确的完成信号。延伸阅读编排器 persona本文主体worker persona协议另一半TB 团队编排器 persona含独立验证规则M1 清单 与 适配器源码清单 schema 与条件哈希实现、清单校验测试基准总览 README【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考