2026/9/12 4:20:05
FEATURED · 精选文章 
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.mdCreate a temporary private stream channel namedfix-pr-1234for one hour.Invite these users as members:benchmark-user-07benchmark-user-19benchmark-user-42Invite these bots with the bot role:benchmark-bot-03benchmark-bot-08Do 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.tomltask.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 工作的能力有多强默认试验次数 k3回归层 Regression 才是 k1、面向产品契约保持。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-10Agent 需要从 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( 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, )而任务的目标集合在同一文件顶部以常量形式定义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、directory60 行目录、observed_channels、task_name、messages等字段。值得注意的设计是私钥与 auth tag 被刻意剔除导出的身份只含 relay 上本就公开的名字、角色与 pubkey评分器看到的视图与用户能看到的完全一致。三、评分器拆解六个维度与全对才得分3.1 证据来源与用户同视角的生产 CLI任务 README 明确说明快照中的observed_channels来自生产环境 CLIchannels search --exact --include-archived加channels members因此评分器评判的与真实用户看到的是同一个视图不存在测试专用的隐藏通道。3.2 六维评分表维度类型衡量内容evidence_completeprogrammatic快照为 v1、任务名正确、携带全部 60 行目录50 用户 10 机器人、5 个可解析目标、且恰好 1 个 orchestrator。这衡量的是 harness 健康度而非 Agent 技能——此处为 0 意味着 provisioner 或 relay 本身可疑channel_createdprogrammatic恰好存在一个名为fix-pr-1234的频道channel_shapeprogrammaticchannel_type stream、visibility private、未归档temporary_channelprogrammaticttl_seconds 3600——一小时由 kind:39000 事件上的ttltag 读出exact_membershipprogrammatic成员 pubkey 恰好是 owner 5 个目标无多余、无重复expected_rolesprogrammatic3 名用户为member2 名机器人为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.0channel_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_requirementttl_seconds为 null永久频道temporary_channel归零test_duplicate_exact_name_fails_channel_creation出现两个同名频道matching_channel_count 2channel_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 searchcmd_search_channels向 relay 查询 kind:39000 频道元数据事件后做两层过滤并投影为稳定 JSON名字匹配name_matches支持--exact全等与默认的包含匹配且大小写不敏感channels.rs#L223-L230归档过滤--include-archived为 false 时过滤掉已归档频道channels.rs#L143。评分器所用的observed_channels正是这种ChannelSummary投影其字段直接映射自 kind:39000 的 tagchannels.rs#L186-L207match 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 成员事件并按#dchannel UUID过滤从事件中抽取ptag 输出成员列表channels.rs#L252-L265这是评分器members字段的数据来源。5.3 可见性的 relay 侧保证cmd_search_channels的注释还透露了一个重要事实channels.rs#L118-L122relay 的访问控制已经过滤掉调用者不可见的频道非成员的私有频道不会返回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 层默认 k3这里显式覆盖为 1显式传--attempts/-k会覆盖层默认值并把选中任务合并到一次 Harbor job--manifest模型条件清单示例中的buzz-native-solo-luna.yaml是单 Agent gpt-5.6-lunathinking_effort: medium的默认条件需要OPENAI_COMPAT_API_KEY仓库也提供 Sonnet 条件的 manifest 可切换--endpoint-configLLM 端点配置--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顶部的常量——三处必须保持一致且目录规模一旦偏离 60evidence_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），仅供参考
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.mdCreate a temporary private stream channel namedfix-pr-1234for one hour.Invite these users as members:benchmark-user-07benchmark-user-19benchmark-user-42Invite these bots with the bot role:benchmark-bot-03benchmark-bot-08Do 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.tomltask.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 工作的能力有多强默认试验次数 k3回归层 Regression 才是 k1、面向产品契约保持。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-10Agent 需要从 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( 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, )而任务的目标集合在同一文件顶部以常量形式定义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、directory60 行目录、observed_channels、task_name、messages等字段。值得注意的设计是私钥与 auth tag 被刻意剔除导出的身份只含 relay 上本就公开的名字、角色与 pubkey评分器看到的视图与用户能看到的完全一致。三、评分器拆解六个维度与全对才得分3.1 证据来源与用户同视角的生产 CLI任务 README 明确说明快照中的observed_channels来自生产环境 CLIchannels search --exact --include-archived加channels members因此评分器评判的与真实用户看到的是同一个视图不存在测试专用的隐藏通道。3.2 六维评分表维度类型衡量内容evidence_completeprogrammatic快照为 v1、任务名正确、携带全部 60 行目录50 用户 10 机器人、5 个可解析目标、且恰好 1 个 orchestrator。这衡量的是 harness 健康度而非 Agent 技能——此处为 0 意味着 provisioner 或 relay 本身可疑channel_createdprogrammatic恰好存在一个名为fix-pr-1234的频道channel_shapeprogrammaticchannel_type stream、visibility private、未归档temporary_channelprogrammaticttl_seconds 3600——一小时由 kind:39000 事件上的ttltag 读出exact_membershipprogrammatic成员 pubkey 恰好是 owner 5 个目标无多余、无重复expected_rolesprogrammatic3 名用户为member2 名机器人为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.0channel_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_requirementttl_seconds为 null永久频道temporary_channel归零test_duplicate_exact_name_fails_channel_creation出现两个同名频道matching_channel_count 2channel_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 searchcmd_search_channels向 relay 查询 kind:39000 频道元数据事件后做两层过滤并投影为稳定 JSON名字匹配name_matches支持--exact全等与默认的包含匹配且大小写不敏感channels.rs#L223-L230归档过滤--include-archived为 false 时过滤掉已归档频道channels.rs#L143。评分器所用的observed_channels正是这种ChannelSummary投影其字段直接映射自 kind:39000 的 tagchannels.rs#L186-L207match 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 成员事件并按#dchannel UUID过滤从事件中抽取ptag 输出成员列表channels.rs#L252-L265这是评分器members字段的数据来源。5.3 可见性的 relay 侧保证cmd_search_channels的注释还透露了一个重要事实channels.rs#L118-L122relay 的访问控制已经过滤掉调用者不可见的频道非成员的私有频道不会返回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 层默认 k3这里显式覆盖为 1显式传--attempts/-k会覆盖层默认值并把选中任务合并到一次 Harbor job--manifest模型条件清单示例中的buzz-native-solo-luna.yaml是单 Agent gpt-5.6-lunathinking_effort: medium的默认条件需要OPENAI_COMPAT_API_KEY仓库也提供 Sonnet 条件的 manifest 可切换--endpoint-configLLM 端点配置--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顶部的常量——三处必须保持一致且目录规模一旦偏离 60evidence_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），仅供参考 
)
