Buzz 基准任务解析create-channel-invite-users 精确频道创建与成员邀请的端到端评测设计【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz本文深入剖析 buzz 仓库中benchmarks/buzz-dataset/create-channel-invite-users基准任务的完整设计从提示词instruction、环境供给provisioning、证据快照evidence到六维确定性评分器verifier。你将理解这套以真实 CLI 视角评分的 Agent 评测机制如何把创建一个带 TTL 的私有流频道并精确邀请 5 个目标身份这一协作场景转化为可复现、可审计、可回归的程序化指标以及如何通过just benchmark一键运行该任务。任务概览一次高精度、低歧义的频道编排create-channel-invite-users是 benchmarks/buzz-dataset 评测套件中的一个 Buzz-native 任务。它要求 Agent 完成一件在表面上非常直白的工作创建一个名为fix-pr-1234的临时私有流频道lifetime 一小时并从预置目录中邀请精确的目标子集——3 个具名用户作为成员、2 个具名机器人授予bot角色。这个任务与其他同类任务最大的不同在于评分的行为标准直接写在了指令里。正如 任务 README 所指出的Unlike the other tasks in this suite, the graded behaviorisstated in the instruction. 它真正难的地方不是理解该做什么而是在规模下的精度供给器provisioner会预置 50 个用户benchmark-user-01…50和 10 个机器人benchmark-bot-01…10Agent 必须从 60 个高度相似的名字中解析出 5 个特定身份并且一个都不能多邀请。任务元数据定义在 task.toml 中schema_version 1.3 [task] name buzz-native/create-channel-invite-users description Create a temporary PR channel with an exact subset of users and bots. authors [{ name Buzz }] keywords [buzz-native, channels, membership, cli] [metadata] evaluation_layer workflow difficulty medium category collaboration tags [channels, membership, cli] [agent] timeout_sec 300.0 [verifier] timeout_sec 30.0 [environment] network_mode public cpus 1 memory_mb 1024 storage_mb 1024可以看到任务被标注为evaluation_layer workflow、难度medium、类别collaborationAgent 的超时上限为300 秒验证器超时为 30 秒运行环境为 1 CPU / 1 GiB 内存 / 1 GiB 存储网络模式public。指令原文评分行为完全透明Agent 收到的用户提示就是 instruction.md全文如下Create a temporary private stream channel named fix-pr-1234 for one hour. Invite these users as members: - benchmark-user-07 - benchmark-user-19 - benchmark-user-42 Invite these bots with the bot role: - benchmark-bot-03 - benchmark-bot-08 Do not invite any other users or bots. When finished, reply briefly with what you created.这段指令浓缩了全部评分约束临时temporary、私有private、流频道stream channel、精确成员精确 5 个目标、不得多邀请、角色区分用户为member机器人为bot。与此同时它刻意制造了信息检索压力目标名字是benchmark-user-07 / 19 / 42与benchmark-bot-03 / 08而目录里同时存在benchmark-user-01…50与benchmark-bot-01…10共 60 个相似条目Agent 必须先通过 CLI 检索目录、解析身份再执行邀请。环境设计Agent 从不进入评测容器任务的环境镜像为python:3.12-slim-bookworm不安装任何额外包——因为 Agent 根本不会在这个容器的 shell 里运行。真实执行模型是BuzzOrchestraAgent启动真实的buzz-acp/buzz-agent栈连接一个专用的 relayAgent 的所有工作都通过buzz channels create/channels invite这类生产级 CLI 完成。换言之任务容器只是评测沙箱而真正被测试的是 Agent 对真实工具链的调用能力。确定性身份派生无秘密持久化、可重复执行README 明确了两条供给原则确定性凭据目录身份directory identities的凭据由 owner key 通过BuzzTrialProvisioner._stable_credential确定性派生不持久化任何秘密幂等重放_seed_directory会跳过已经发布过 profile 的条目因此同一目录可被多次 seed重复运行rerun保持幂等且 pubkey 在多次 trial 之间保持稳定。这两条保证了评测结果的可复现性同样的任务、同样的目录、同样的 pubkeyAgent 每次面对的检索空间完全一致。从供给层面看任务目录由 task_fixtures.py 中的_CREATE_CHANNEL_FIXTURE声明CREATE_CHANNEL_TASK create-channel-invite-users CREATE_CHANNEL_NAME fix-pr-1234 TARGET_USERS (benchmark-user-07, benchmark-user-19, benchmark-user-42) TARGET_BOTS (benchmark-bot-03, benchmark-bot-08) ... _CREATE_CHANNEL_FIXTURE BuzzTaskFixture( directorytuple( [ DirectoryEntry(fbenchmark-user-{index:02d}, user) for index in range(1, 51) ] [ DirectoryEntry(fbenchmark-bot-{index:02d}, bot) for index in range(1, 11) ] ), observe_channel_names(CREATE_CHANNEL_NAME,), requires_evidenceTrue, )DirectoryEntry同文件第 8-21 行携带name、role与可选的identity_idstable_id属性用于派生确定性凭据。每个DirectoryEntry最终会映射为 provisioning.py 中的DirectoryIdentity公开的、可通过 Buzz 发现的基准身份仅含 name/role/pubkey 等非秘密信息并通过TrialHandle.directory挂载到 trial 上。该 fixture 同时设置了observe_channel_names(CREATE_CHANNEL_NAME,)与requires_evidenceTrue表明任务依赖证据快照导出且观察器需要关注fix-pr-1234频道的状态。验证器用用户视角的 CLI 快照做六维评分任务验证的核心输入是 Agent 运行结束后导出的/logs/artifacts/buzz-evidence.json证据快照。README 特别强调快照中的observed_channels来自生产 CLI 本身——通过channels search --exact --include-archived加上channels members采集——因此验证器评分的正是用户实际会看到的那一屏。这保证了评测不依赖 Agent 的自述也不依赖测试代码对 relay 内部状态的私有窥探而是与真实用户体验对齐。六个评分维度维度类型衡量内容evidence_completeprogrammatic快照为 v1 版本、指名本任务task_name create-channel-invite-users、携带全部 60 行目录50 用户 10 机器人、5 个可解析目标、且恰好 1 个 orchestrator。它衡量的是 harness 健康度而非 Agent 技能——此处为 0 意味着供给器或 relay 可疑channel_createdprogrammatic恰好存在一个名为fix-pr-1234的频道channel_shapeprogrammaticchannel_type stream、visibility private、未归档not archivedtemporary_channelprogrammaticttl_seconds 3600——一小时从 kind:39000 的ttl标签读出经channels search暴露exact_membershipprogrammatic成员 pubkey 集合恰好等于 owner 5 个目标——无多余、无重复expected_rolesprogrammatic3 个用户持有member角色、2 个机器人持有bot角色、创建者持有owner角色reward是以上全部维度的合取conjunction任何一个维度为 0总奖励即为 0。评分器源码逐行解析评分逻辑位于 tests/verify.py入口为score_evidence(evidence)第 28 行起。核心判定值得逐条对应目录解析第 32-39 行从evidence[directory]中过滤出 dict 行按name建索引作为 pubkey 解析的依据频道定位第 40-45 行从observed_channels中筛出name fix-pr-1234的频道要求恰好一个否则视为未创建orchestrator 解析第 51-56 行从identities中找出 role 为orchestrator的身份恰好一个时取其 pubkey 作为 owner期望成员构建第 58-67 行用目录中的 pubkey 组装{owner: owner, 目标用户: member, 目标机器人: bot}的期望映射evidence_complete第 80-89 行校验 schema 版本、任务名、目录恰好 60 行、50 用户 10 机器人、5 个目标全部可解析、恰好 1 个 orchestratorchannel_created第 90 行channel is not Nonechannel_shape第 91-96 行channel_type stream、visibility private、archived is Falsetemporary_channel第 97-99 行ttl_seconds 3600指令中的 for one hour 被精确映射为秒数exact_membership第 100-103 行成员行数与去重后一致且 pubkey 集合与期望集合完全相等expected_roles第 104 行actual_members expected_members即 pubkey→role 映射逐项一致reward第 105-117 行六项指标全部为 1.0 才得 1.0。main()第 136-153 行从命令行读取--evidence证据快照路径、--reward与--details输出路径把指标与详情分别写为 JSON任何文件读取或 JSON 解析错误都会走 fail-closed 的_zero_metrics()路径——出错即全零绝不静默通过。包装脚本 tests/test.sh 展示了验证器的实际调用方式#!/bin/sh set -eu python3 /tests/verify.py \ --evidence /logs/artifacts/buzz-evidence.json \ --reward /logs/verifier/reward.json \ --details /logs/verifier/details.json验证器的 fixture 回归测试由于harbor run -a oracle在此任务上不适用详见下文运行方式验证器本身的正确性由 fixture 测试保证test_create_channel_invite_users_verifier.py。该文件通过importlib直接加载数据集里的verify.py并围绕六个失败模式做了断言test_exact_temporary_channel_and_roster_passes完整证据全部指标为 1.0test_extra_member_fails_exact_membership多邀请一个成员 →channel_created仍为 1.0但exact_membership归零、reward归零验证精确性被单独惩罚test_wrong_bot_role_fails_roles把机器人角色改成member→exact_membership不受影响但expected_roles归零说明集合与角色是正交的两个维度test_permanent_channel_fails_temporary_requirementttl_seconds置空 →temporary_channel归零test_duplicate_exact_name_fails_channel_creation出现两个同名频道 →matching_channel_count 2channel_created归零恰好一个的约束test_missing_evidence_fails_closed传入None→ 全部归零且带error详情。这套测试直接印证了 README 中Every dimension is programmatic; reward is the conjunction of all of them的设计每个维度都单独可诊断、可回归且总奖励是严格合取。目录结构数据集如何组织create-channel-invite-users/ ├── instruction.md # Prompt posted to the agent as the trial user ├── task.toml # Metadata, timeouts, 1 CPU / 1 GiB environment ├── environment/Dockerfile # Bare python image; the relay stack is uploaded └── tests/ ├── test.sh # Runs verify.py against the evidence snapshot └── verify.py # Deterministic scorer (see table above)instruction.md——以试用用户身份投递给 Agent 的提示词前文已全文引用task.toml——任务元数据、超时、1 CPU / 1 GiB 环境规格environment/Dockerfile——裸露的 python 镜像relay 栈由 harness 上传tests/test.sh——对证据快照运行verify.pytests/verify.py——确定性评分器对应上文的六维表格。修改目标集的三处联动约束README 特别提醒若要更换目标身份集合必须同步修改三处且三者必须一致否则评分会失败task_fixtures.TARGET_USERS/TARGET_BOTStask_fixtures.pyinstruction.md中的名字列表tests/verify.py顶部的同名常量verify.py。如果目录规模偏离 6050 用户 10 机器人evidence_complete会响亮地失败fail loudly从而避免目录被悄悄改动而评分器不自知的静默漂移。运行方式通过 just benchmark 一键评测任务的标准运行命令摘自 READMEjust benchmark \ --path benchmarks/buzz-dataset/create-channel-invite-users \ --attempts 1 \ --manifest benchmarks/harbor-buzz-orchestra/manifests/buzz-native-solo-luna.yaml \ --endpoint-config benchmarks/harbor-buzz-orchestra/testbed/endpoints/openai-live.json \ --n-concurrent 1参数含义--path指向数据集目录本任务--attempts 1单次尝试--manifest指定 Agent 栈的 manifest示例使用 buzz-native-solo-luna.yamlsolo 形态的 Luna 模型配置同目录下还有buzz-native-solo-sonnet.yaml等其他 manifest--endpoint-config指向真实 LLM 端点的配置示例为 openai-live.json--n-concurrent 1并发度为 1。为什么harbor run -a oracle在此任务上不可用README 明确指出harbor run -a oracle在此任务上不适用且任务不提供solution/solve.sh。原因是Oracle 模式会替换掉BuzzOrchestraAgent导致没有 relay trial 被供给no relay trial is provisioned没有证据快照被导出no evidence snapshot is exported。因此 Oracle 无法运行本任务验证器的正确性改由前文介绍的 fixture 测试 覆盖。这也从侧面说明本任务评测的是Agent 在真实 relay 栈上的完整工具调用链路而不是已知答案的对照实验。与评测套件其他任务的定位差异从 task_fixtures.py 可以看到create-channel-invite-users是套件中较直白的任务之一它没有 scripted messages不像interleaved-agent-reports、cross-thread-requests那样注入合成报告没有 memory seeds不像memory-retrieval那样预热冷记忆也没有重名用户制造歧义那是ambiguous-user-mention的考点。它的评测价值集中在精确性与工具纪律上在 60 个相似命名的身份中精确定位 5 个目标、以正确角色邀请、严格遵守 TTL 与可见性约束、并且一个都不多邀——每一个约束都由独立的程序化维度度量任何偏差都能被精确定位到具体维度从而为 Agent 的行为调试提供可操作的反馈信号。小结create-channel-invite-users展示了一套可借鉴的 Agent 评测范式评分视角与用户一致证据来自生产 CLIchannels search --exact --include-archivedchannels members而非测试私有接口维度正交可诊断创建、形态、TTL、成员精确性、角色五个业务维度 一个 harness 健康度维度各自独立打分reward严格合取fail-closed 与 fail-loud 并重证据缺失时全零归零目录规模漂移时evidence_complete大声失败可复现供给确定性凭据派生 幂等 seed保证跨 trial 的 pubkey 稳定可回归验证评分器自身有 fixture 测试覆盖全部失败模式防止评分逻辑回归。若要在实践中复用这套设计可参考 verify.py 的score_evidence结构纯函数、输入输出均为可序列化 JSON并仿照 test_create_channel_invite_users_verifier.py 为每个维度编写独立的失败用例从而构建评测器可被评测的闭环。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Buzz 基准任务解析：create-channel-invite-users 精确频道创建与成员邀请的端到端评测设计
Buzz 基准任务解析create-channel-invite-users 精确频道创建与成员邀请的端到端评测设计【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz本文深入剖析 buzz 仓库中benchmarks/buzz-dataset/create-channel-invite-users基准任务的完整设计从提示词instruction、环境供给provisioning、证据快照evidence到六维确定性评分器verifier。你将理解这套以真实 CLI 视角评分的 Agent 评测机制如何把创建一个带 TTL 的私有流频道并精确邀请 5 个目标身份这一协作场景转化为可复现、可审计、可回归的程序化指标以及如何通过just benchmark一键运行该任务。任务概览一次高精度、低歧义的频道编排create-channel-invite-users是 benchmarks/buzz-dataset 评测套件中的一个 Buzz-native 任务。它要求 Agent 完成一件在表面上非常直白的工作创建一个名为fix-pr-1234的临时私有流频道lifetime 一小时并从预置目录中邀请精确的目标子集——3 个具名用户作为成员、2 个具名机器人授予bot角色。这个任务与其他同类任务最大的不同在于评分的行为标准直接写在了指令里。正如 任务 README 所指出的Unlike the other tasks in this suite, the graded behaviorisstated in the instruction. 它真正难的地方不是理解该做什么而是在规模下的精度供给器provisioner会预置 50 个用户benchmark-user-01…50和 10 个机器人benchmark-bot-01…10Agent 必须从 60 个高度相似的名字中解析出 5 个特定身份并且一个都不能多邀请。任务元数据定义在 task.toml 中schema_version 1.3 [task] name buzz-native/create-channel-invite-users description Create a temporary PR channel with an exact subset of users and bots. authors [{ name Buzz }] keywords [buzz-native, channels, membership, cli] [metadata] evaluation_layer workflow difficulty medium category collaboration tags [channels, membership, cli] [agent] timeout_sec 300.0 [verifier] timeout_sec 30.0 [environment] network_mode public cpus 1 memory_mb 1024 storage_mb 1024可以看到任务被标注为evaluation_layer workflow、难度medium、类别collaborationAgent 的超时上限为300 秒验证器超时为 30 秒运行环境为 1 CPU / 1 GiB 内存 / 1 GiB 存储网络模式public。指令原文评分行为完全透明Agent 收到的用户提示就是 instruction.md全文如下Create a temporary private stream channel named fix-pr-1234 for one hour. Invite these users as members: - benchmark-user-07 - benchmark-user-19 - benchmark-user-42 Invite these bots with the bot role: - benchmark-bot-03 - benchmark-bot-08 Do not invite any other users or bots. When finished, reply briefly with what you created.这段指令浓缩了全部评分约束临时temporary、私有private、流频道stream channel、精确成员精确 5 个目标、不得多邀请、角色区分用户为member机器人为bot。与此同时它刻意制造了信息检索压力目标名字是benchmark-user-07 / 19 / 42与benchmark-bot-03 / 08而目录里同时存在benchmark-user-01…50与benchmark-bot-01…10共 60 个相似条目Agent 必须先通过 CLI 检索目录、解析身份再执行邀请。环境设计Agent 从不进入评测容器任务的环境镜像为python:3.12-slim-bookworm不安装任何额外包——因为 Agent 根本不会在这个容器的 shell 里运行。真实执行模型是BuzzOrchestraAgent启动真实的buzz-acp/buzz-agent栈连接一个专用的 relayAgent 的所有工作都通过buzz channels create/channels invite这类生产级 CLI 完成。换言之任务容器只是评测沙箱而真正被测试的是 Agent 对真实工具链的调用能力。确定性身份派生无秘密持久化、可重复执行README 明确了两条供给原则确定性凭据目录身份directory identities的凭据由 owner key 通过BuzzTrialProvisioner._stable_credential确定性派生不持久化任何秘密幂等重放_seed_directory会跳过已经发布过 profile 的条目因此同一目录可被多次 seed重复运行rerun保持幂等且 pubkey 在多次 trial 之间保持稳定。这两条保证了评测结果的可复现性同样的任务、同样的目录、同样的 pubkeyAgent 每次面对的检索空间完全一致。从供给层面看任务目录由 task_fixtures.py 中的_CREATE_CHANNEL_FIXTURE声明CREATE_CHANNEL_TASK create-channel-invite-users CREATE_CHANNEL_NAME fix-pr-1234 TARGET_USERS (benchmark-user-07, benchmark-user-19, benchmark-user-42) TARGET_BOTS (benchmark-bot-03, benchmark-bot-08) ... _CREATE_CHANNEL_FIXTURE BuzzTaskFixture( directorytuple( [ DirectoryEntry(fbenchmark-user-{index:02d}, user) for index in range(1, 51) ] [ DirectoryEntry(fbenchmark-bot-{index:02d}, bot) for index in range(1, 11) ] ), observe_channel_names(CREATE_CHANNEL_NAME,), requires_evidenceTrue, )DirectoryEntry同文件第 8-21 行携带name、role与可选的identity_idstable_id属性用于派生确定性凭据。每个DirectoryEntry最终会映射为 provisioning.py 中的DirectoryIdentity公开的、可通过 Buzz 发现的基准身份仅含 name/role/pubkey 等非秘密信息并通过TrialHandle.directory挂载到 trial 上。该 fixture 同时设置了observe_channel_names(CREATE_CHANNEL_NAME,)与requires_evidenceTrue表明任务依赖证据快照导出且观察器需要关注fix-pr-1234频道的状态。验证器用用户视角的 CLI 快照做六维评分任务验证的核心输入是 Agent 运行结束后导出的/logs/artifacts/buzz-evidence.json证据快照。README 特别强调快照中的observed_channels来自生产 CLI 本身——通过channels search --exact --include-archived加上channels members采集——因此验证器评分的正是用户实际会看到的那一屏。这保证了评测不依赖 Agent 的自述也不依赖测试代码对 relay 内部状态的私有窥探而是与真实用户体验对齐。六个评分维度维度类型衡量内容evidence_completeprogrammatic快照为 v1 版本、指名本任务task_name create-channel-invite-users、携带全部 60 行目录50 用户 10 机器人、5 个可解析目标、且恰好 1 个 orchestrator。它衡量的是 harness 健康度而非 Agent 技能——此处为 0 意味着供给器或 relay 可疑channel_createdprogrammatic恰好存在一个名为fix-pr-1234的频道channel_shapeprogrammaticchannel_type stream、visibility private、未归档not archivedtemporary_channelprogrammaticttl_seconds 3600——一小时从 kind:39000 的ttl标签读出经channels search暴露exact_membershipprogrammatic成员 pubkey 集合恰好等于 owner 5 个目标——无多余、无重复expected_rolesprogrammatic3 个用户持有member角色、2 个机器人持有bot角色、创建者持有owner角色reward是以上全部维度的合取conjunction任何一个维度为 0总奖励即为 0。评分器源码逐行解析评分逻辑位于 tests/verify.py入口为score_evidence(evidence)第 28 行起。核心判定值得逐条对应目录解析第 32-39 行从evidence[directory]中过滤出 dict 行按name建索引作为 pubkey 解析的依据频道定位第 40-45 行从observed_channels中筛出name fix-pr-1234的频道要求恰好一个否则视为未创建orchestrator 解析第 51-56 行从identities中找出 role 为orchestrator的身份恰好一个时取其 pubkey 作为 owner期望成员构建第 58-67 行用目录中的 pubkey 组装{owner: owner, 目标用户: member, 目标机器人: bot}的期望映射evidence_complete第 80-89 行校验 schema 版本、任务名、目录恰好 60 行、50 用户 10 机器人、5 个目标全部可解析、恰好 1 个 orchestratorchannel_created第 90 行channel is not Nonechannel_shape第 91-96 行channel_type stream、visibility private、archived is Falsetemporary_channel第 97-99 行ttl_seconds 3600指令中的 for one hour 被精确映射为秒数exact_membership第 100-103 行成员行数与去重后一致且 pubkey 集合与期望集合完全相等expected_roles第 104 行actual_members expected_members即 pubkey→role 映射逐项一致reward第 105-117 行六项指标全部为 1.0 才得 1.0。main()第 136-153 行从命令行读取--evidence证据快照路径、--reward与--details输出路径把指标与详情分别写为 JSON任何文件读取或 JSON 解析错误都会走 fail-closed 的_zero_metrics()路径——出错即全零绝不静默通过。包装脚本 tests/test.sh 展示了验证器的实际调用方式#!/bin/sh set -eu python3 /tests/verify.py \ --evidence /logs/artifacts/buzz-evidence.json \ --reward /logs/verifier/reward.json \ --details /logs/verifier/details.json验证器的 fixture 回归测试由于harbor run -a oracle在此任务上不适用详见下文运行方式验证器本身的正确性由 fixture 测试保证test_create_channel_invite_users_verifier.py。该文件通过importlib直接加载数据集里的verify.py并围绕六个失败模式做了断言test_exact_temporary_channel_and_roster_passes完整证据全部指标为 1.0test_extra_member_fails_exact_membership多邀请一个成员 →channel_created仍为 1.0但exact_membership归零、reward归零验证精确性被单独惩罚test_wrong_bot_role_fails_roles把机器人角色改成member→exact_membership不受影响但expected_roles归零说明集合与角色是正交的两个维度test_permanent_channel_fails_temporary_requirementttl_seconds置空 →temporary_channel归零test_duplicate_exact_name_fails_channel_creation出现两个同名频道 →matching_channel_count 2channel_created归零恰好一个的约束test_missing_evidence_fails_closed传入None→ 全部归零且带error详情。这套测试直接印证了 README 中Every dimension is programmatic; reward is the conjunction of all of them的设计每个维度都单独可诊断、可回归且总奖励是严格合取。目录结构数据集如何组织create-channel-invite-users/ ├── instruction.md # Prompt posted to the agent as the trial user ├── task.toml # Metadata, timeouts, 1 CPU / 1 GiB environment ├── environment/Dockerfile # Bare python image; the relay stack is uploaded └── tests/ ├── test.sh # Runs verify.py against the evidence snapshot └── verify.py # Deterministic scorer (see table above)instruction.md——以试用用户身份投递给 Agent 的提示词前文已全文引用task.toml——任务元数据、超时、1 CPU / 1 GiB 环境规格environment/Dockerfile——裸露的 python 镜像relay 栈由 harness 上传tests/test.sh——对证据快照运行verify.pytests/verify.py——确定性评分器对应上文的六维表格。修改目标集的三处联动约束README 特别提醒若要更换目标身份集合必须同步修改三处且三者必须一致否则评分会失败task_fixtures.TARGET_USERS/TARGET_BOTStask_fixtures.pyinstruction.md中的名字列表tests/verify.py顶部的同名常量verify.py。如果目录规模偏离 6050 用户 10 机器人evidence_complete会响亮地失败fail loudly从而避免目录被悄悄改动而评分器不自知的静默漂移。运行方式通过 just benchmark 一键评测任务的标准运行命令摘自 READMEjust benchmark \ --path benchmarks/buzz-dataset/create-channel-invite-users \ --attempts 1 \ --manifest benchmarks/harbor-buzz-orchestra/manifests/buzz-native-solo-luna.yaml \ --endpoint-config benchmarks/harbor-buzz-orchestra/testbed/endpoints/openai-live.json \ --n-concurrent 1参数含义--path指向数据集目录本任务--attempts 1单次尝试--manifest指定 Agent 栈的 manifest示例使用 buzz-native-solo-luna.yamlsolo 形态的 Luna 模型配置同目录下还有buzz-native-solo-sonnet.yaml等其他 manifest--endpoint-config指向真实 LLM 端点的配置示例为 openai-live.json--n-concurrent 1并发度为 1。为什么harbor run -a oracle在此任务上不可用README 明确指出harbor run -a oracle在此任务上不适用且任务不提供solution/solve.sh。原因是Oracle 模式会替换掉BuzzOrchestraAgent导致没有 relay trial 被供给no relay trial is provisioned没有证据快照被导出no evidence snapshot is exported。因此 Oracle 无法运行本任务验证器的正确性改由前文介绍的 fixture 测试 覆盖。这也从侧面说明本任务评测的是Agent 在真实 relay 栈上的完整工具调用链路而不是已知答案的对照实验。与评测套件其他任务的定位差异从 task_fixtures.py 可以看到create-channel-invite-users是套件中较直白的任务之一它没有 scripted messages不像interleaved-agent-reports、cross-thread-requests那样注入合成报告没有 memory seeds不像memory-retrieval那样预热冷记忆也没有重名用户制造歧义那是ambiguous-user-mention的考点。它的评测价值集中在精确性与工具纪律上在 60 个相似命名的身份中精确定位 5 个目标、以正确角色邀请、严格遵守 TTL 与可见性约束、并且一个都不多邀——每一个约束都由独立的程序化维度度量任何偏差都能被精确定位到具体维度从而为 Agent 的行为调试提供可操作的反馈信号。小结create-channel-invite-users展示了一套可借鉴的 Agent 评测范式评分视角与用户一致证据来自生产 CLIchannels search --exact --include-archivedchannels members而非测试私有接口维度正交可诊断创建、形态、TTL、成员精确性、角色五个业务维度 一个 harness 健康度维度各自独立打分reward严格合取fail-closed 与 fail-loud 并重证据缺失时全零归零目录规模漂移时evidence_complete大声失败可复现供给确定性凭据派生 幂等 seed保证跨 trial 的 pubkey 稳定可回归验证评分器自身有 fixture 测试覆盖全部失败模式防止评分逻辑回归。若要在实践中复用这套设计可参考 verify.py 的score_evidence结构纯函数、输入输出均为可序列化 JSON并仿照 test_create_channel_invite_users_verifier.py 为每个维度编写独立的失败用例从而构建评测器可被评测的闭环。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考