Buzz 基准测试任务解析：create-channel-invite-users 的精确建群与成员邀请验证-平芜编程栈

Buzz 基准测试任务解析：create-channel-invite-users 的精确建群与成员邀请验证

【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz

导读

create-channel-invite-users是 buzz 仓库 benchmarks/buzz-dataset 中唯一一个**"评分行为直接写在指令里"**的工作流（Workflow）级基准任务：它要求 AI Agent 创建一个名为fix-pr-1234的临时私有 stream 频道，并从 60 个相似身份的目录中精准挑出 5 个目标（3 名用户 + 2 名机器人）完成邀请，多邀、漏邀、角色错误或频道形态不符都会被判失败。本文将以 instruction.md 为核心，结合任务元数据、确定性评分器、夹具生成与 buzz CLI 的频道实现源码，完整拆解该任务的设计动机、验证维度、运行方式与底层原理，帮助你理解 buzz 如何用"产品行为评分"而非"任务正确性评分"来评估 Agent 的真实协作能力。

一、任务全景：一条看似简单、实则苛刻的指令

1.1 原始指令全文

任务提示词（即 Agent 收到的全部指令）位于 instruction.md：

Create a temporary private stream channel namedfix-pr-1234for 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.

翻译过来就是：创建一个名为fix-pr-1234、有效期一小时（3600 秒）的临时私有 stream 频道；邀请 3 名用户为member、2 名机器人为bot角色；不得邀请任何其他人；完成后简要汇报创建结果。

1.2 任务元数据（task.toml）

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"：按 buzz-dataset README 的分层约定，Workflow 层回答的是"Agent 完成真实 Buzz 工作的能力有多强"，默认试验次数 k=3（回归层 Regression 才是 k=1、面向产品契约保持）。
agent timeout 300 秒：Agent 有 5 分钟完成建群、邀请与汇报。
verifier timeout 30 秒：评分器必须在 30 秒内完成证据快照的读取与判定。
环境配额极低（1 CPU / 1 GiB / 1 GiB 存储）：因为 Agent 并不在这个容器 shell 里工作，容器只是承载整个 buzz-acp / buzz-agent 技术栈的运行时外壳。

1.3 任务的"难"点在哪里

正如任务 README 指出的：与其他任务"评分行为故意不写进指令"不同，本任务把要做什么直接写明了，难度不在理解指令，而在于"规模下的精确性"——编排器（provisioner）会预置 50 个用户（benchmark-user-01…benchmark-user-50）和 10 个机器人（benchmark-bot-01…benchmark-bot-10），Agent 需要从 60 个高度相似的名字里解析出 5 个，并且一个都不能多邀。

二、环境与目录身份：确定性种子与幂等重跑

2.1 容器环境

environment/Dockerfile 极其精简：

FROM python:3.12-slim-bookworm WORKDIR /app

也就是说任务容器本身不安装任何额外包。真正的工作由BuzzOrchestraAgent在专用 relay上启动真实的buzz-acp/buzz-agent栈来完成，Agent 全程只通过buzz channels create/channels invite等 CLI 命令行动。

2.2 60 人目录的确定性生成

目录身份由 harness 侧 task_fixtures.py 中的_CREATE_CHANNEL_FIXTURE声明：

_CREATE_CHANNEL_FIXTURE = BuzzTaskFixture( directory=tuple( [ DirectoryEntry(f"benchmark-user-{index:02d}", "user") for index in range(1, 51) ] + [ DirectoryEntry(f"benchmark-bot-{index:02d}", "bot") for index in range(1, 11) ] ), observe_channel_names=(CREATE_CHANNEL_NAME,), requires_evidence=True, )

而任务的目标集合在同一文件顶部以常量形式定义：

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")

任务 README 还强调了两条可靠性设计：

目录身份由 owner key 确定性推导（BuzzTrialProvisioner._stable_credential），不持久化任何密钥，每次 trial 的 pubkey 稳定一致；
_seed_directory会跳过已发布的 profile，因此重跑是幂等的——同一目录反复实验不会产生身份漂移。

2.3 证据快照的生成契约

Agent 完成后，harness 会把 relay 状态导出为 v1 版证据快照。其结构由 evidence.py 中的build_buzz_evidence()定义，包含schema_version、trial、identities（含 orchestrator）、directory（60 行目录）、observed_channels、task_name、messages等字段。值得注意的设计是：私钥与 auth tag 被刻意剔除，导出的身份只含 relay 上本就公开的名字、角色与 pubkey，评分器看到的视图与用户能看到的完全一致。

三、评分器拆解：六个维度与"全对才得分"

3.1 证据来源：与用户同视角的生产 CLI

任务 README 明确说明：快照中的observed_channels来自生产环境 CLI（channels search --exact --include-archived加channels members），因此评分器评判的与真实用户看到的是同一个视图，不存在测试专用的隐藏通道。

3.2 六维评分表

维度	类型	衡量内容
`evidence_complete`	programmatic	快照为 v1、任务名正确、携带全部 60 行目录（50 用户 + 10 机器人）、5 个可解析目标、且恰好 1 个 orchestrator。这衡量的是 harness 健康度而非 Agent 技能——此处为 0 意味着 provisioner 或 relay 本身可疑
`channel_created`	programmatic	恰好存在一个名为`fix-pr-1234`的频道
`channel_shape`	programmatic	`channel_type = stream`、`visibility = private`、未归档
`temporary_channel`	programmatic	`ttl_seconds == 3600`——"一小时"由 kind:39000 事件上的`ttl`tag 读出
`exact_membership`	programmatic	成员 pubkey 恰好是 owner + 5 个目标，无多余、无重复
`expected_roles`	programmatic	3 名用户为`member`，2 名机器人为`bot`，创建者为`owner`

最终reward是以上所有维度的合取（conjunction）——任何一维不满足，reward 即为 0。

3.3 评分器实现精读

tests/verify.py 是一个零依赖的确定性 Python 评分器。其核心常量与评分逻辑如下：

CHANNEL_NAME = "fix-pr-1234" TARGET_USERS = {"benchmark-user-07", "benchmark-user-19", "benchmark-user-42"} TARGET_BOTS = {"benchmark-bot-03", "benchmark-bot-08"}

评分的几个关键点值得展开：

目录解析：先把证据中的directory数组按name → row建索引，再对目标名逐一到目录中解析 pubkey，用集合运算构建expected_targets。注意expected_targets的键是 pubkey、值是角色（bot或member），名字只是查找键，最终判定落在 pubkey 上。
成员集合对比：exact_membership用set(actual_members) == set(expected_members)，天然排除了多邀、漏邀和重复；
角色精确对比：expected_roles进一步用actual_members == expected_members做 dict 全等比较——成员集合完全一致但角色错了一个，也会拿 0 分；
TTL 读取：temporary_channel要求ttl_seconds == 3600，对应指令中的 "for one hour"；
失败关闭（fail-closed）：证据根不是对象、文件读取失败或 JSON 解析失败时，score_evidence一律返回全 0 指标并附error详情，不会因数据异常而"宽大处理"。

3.4 启动入口

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

即：从/logs/artifacts/buzz-evidence.json读证据，把指标写入/logs/verifier/reward.json，把详情（匹配频道数量、channel_id、期望/实际成员映射）写入/logs/verifier/details.json。

四、评分器的测试背书：fixture 级验证

评分器本身由 harness 侧的 fixture 测试覆盖：test_create_channel_invite_users_verifier.py。该测试通过importlib动态加载数据集目录里的verify.py，再基于fixture_for("create-channel-invite-users")构造完整证据，覆盖了六个典型场景：

测试用例	验证结论
`test_exact_temporary_channel_and_roster_passes`	黄金路径：所有维度全 1.0，`channel_id`正确透出
`test_extra_member_fails_exact_membership`	多加一名成员：`channel_created`仍为 1.0，但`exact_membership`与`reward`归零
`test_wrong_bot_role_fails_roles`	把 bot 的角色写成`member`：成员集合正确但`expected_roles`归零
`test_permanent_channel_fails_temporary_requirement`	`ttl_seconds`为 null（永久频道）：`temporary_channel`归零
`test_duplicate_exact_name_fails_channel_creation`	出现两个同名频道：`matching_channel_count == 2`，`channel_created`归零
`test_missing_evidence_fails_closed`	证据为 None：所有指标全 0 且带`error`详情

这些测试把"评分逻辑正确性"与"Agent 试验"解耦——正如 buzz-dataset README 所说，快速 verifier fixture 仍是普通 CI，它们校验评分逻辑，但不能替代跨模型、基础提示词、CLI 与 relay 的 Agent 试验。

五、底层支撑：buzz CLI 的频道实现

评分器要求的字段（ttl_seconds、visibility、archived、channel_type、members）不是拍脑袋定的，它们都来自真实的 buzz CLI 实现。以 crates/buzz-cli/src/commands/channels.rs 为例：

5.1 频道搜索与投影（channels search）

cmd_search_channels向 relay 查询 kind:39000 频道元数据事件后，做两层过滤并投影为稳定 JSON：

名字匹配：name_matches支持--exact（全等）与默认的包含匹配，且大小写不敏感（channels.rs#L223-L230）；
归档过滤：--include-archived为 false 时过滤掉已归档频道（channels.rs#L143）。

评分器所用的observed_channels正是这种ChannelSummary投影，其字段直接映射自 kind:39000 的 tag（channels.rs#L186-L207）：

match key { "d" => channel_id = val.map(str::to_string), "name" => name = val.map(str::to_string), "t" => channel_type = val.map(str::to_string), // NIP-29 emits both `private` and `public` (Buzz adds the latter). "private" => visibility = Some("private".to_string()), "public" => visibility = Some("public".to_string()), ... "ttl" => ttl_seconds = val.and_then(|value| value.parse().ok()), "archived" => archived = val == Some("true"), _ => {} }

这解释了评分维度与协议的一一对应关系：temporary_channel检查的ttl_seconds == 3600正是从 kind:39000 事件的ttltag 解析出来的（channels.rs#L203）。

5.2 TTL 校验与成员列举

建频道/改频道时的 TTL 语义：validate_ttl_seconds要求正数、上限i32::MAX，--no-ttl可以清除 TTL 让频道变为永久（channels.rs#L1216-L1258）——"临时频道"与"永久频道"在协议层面就是ttltag 的有无与取值，与评分器的permanent_channel_fails_temporary_requirement测试完全吻合；
成员列举：cmd_list_channel_members查询 kind:39002 成员事件并按#d（channel UUID）过滤，从事件中抽取ptag 输出成员列表（channels.rs#L252-L265），这是评分器members字段的数据来源。

5.3 可见性的 relay 侧保证

cmd_search_channels的注释还透露了一个重要事实（channels.rs#L118-L122）：relay 的访问控制已经过滤掉调用者不可见的频道（非成员的私有频道不会返回），CLI 只需按名字做后置过滤。这意味着评分器看到的observed_channels视图天然等价于"这个 Agent 账号能看到的真实世界"，这正是本任务评分哲学的核心——评的是 Agent 在真实产品视图下产出的结果。

六、如何运行本任务

6.1 从仓库根目录运行

任务需要 harbor-buzz-orchestra harness（它会在任务容器内启动真实的buzz-acp→buzz-agent→buzz-dev-mcp栈并导出 relay 快照），不能对数据集目录直接harbor run。仓库根目录的 Justfile 提供了benchmark配方：

just 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：指向任务目录；也可以传benchmarks/buzz-dataset配合--layer workflow一次跑整个层；
--attempts 1：试验次数。Workflow 层默认 k=3，这里显式覆盖为 1；显式传--attempts/-k会覆盖层默认值并把选中任务合并到一次 Harbor job；
--manifest：模型条件清单，示例中的buzz-native-solo-luna.yaml是单 Agent +gpt-5.6-luna（thinking_effort: medium）的默认条件，需要OPENAI_COMPAT_API_KEY；仓库也提供 Sonnet 条件的 manifest 可切换；
--endpoint-config：LLM 端点配置；
--n-concurrent 1：并发试验数。

6.2 两个"跑不通"的路径

任务 README 明确提醒：harbor run -a oracle在本任务不适用，且仓库不提供solution/solve.sh。原因在于 Oracle agent 会替换BuzzOrchestraAgent，导致不会 provision relay trial、也不会导出证据快照，评分自然无从谈起。因此本任务只能走 harness 的完整链路。

6.3 目录布局速览

create-channel-invite-users/ ├── instruction.md # 作为 trial 用户提示词发给 Agent ├── task.toml # 元数据、超时、1 CPU / 1 GiB 环境 ├── environment/Dockerfile # 裸 python 镜像；relay 栈由 harness 上传 └── tests/ ├── test.sh # 对证据快照运行 verify.py └── verify.py # 确定性评分器（见评分表）

如果未来要调整目标集合，需要同时修改task_fixtures.TARGET_USERS/TARGET_BOTS、instruction.md以及tests/verify.py顶部的常量——三处必须保持一致，且目录规模一旦偏离 60，evidence_complete会直接大声失败（task_fixtures.py 与 verify.py#L80-L89 双重把关）。

七、设计启示：为什么"指令直白"反而是好基准

本任务在 buzz-dataset 中独树一帜：与reply-to-thread、user-mention等"评分行为故意不写进指令、必须靠buzz-acp生产基础提示词"的回归任务不同，create-channel-invite-users把要求全部摆在明面上，考的是执行精度与协议完整性：

精确到 pubkey 的成员判定杜绝了"看起来对了"的模糊空间；
六维合取的 reward 模型把频道形态、时效、成员集合、角色语义全部纳入，任何一环出错即零分，量化了"多邀一个机器人"与"忘记设置 TTL"同等的失败代价；
评分视图 = 生产 CLI 视图，使基准分数可直接映射为真实用户体验；
fixture 测试先行，保证评分器本身可被 CI 持续验证，评分逻辑的回归不会悄悄污染试验结果。

对于希望评估 LLM Agent 在真实协作平台上"办成一件事"能力的工程团队，这个任务提供了一个可复制的范式：指令直白但环境充满相似干扰项、评分全自动且维度可审计、结果与用户视角严格对齐——这正是"产品行为评分"胜过"任务正确性评分"的典型案例。读者可以沿 harbor-buzz-orchestra 的文档继续深入 harness 的容器运行时与证据导出细节。

【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考