企业官网建设流程全解析

buzz 基准测试实战：user-mention 任务如何用事件级p标签守卫生成式 Agent 的通知契约

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

导读

benchmarks/buzz-dataset/user-mention是 Buzz 仓库中一个"看起来像算术题、实际考通知协议"的基准测试任务：Agent 只需计算 12 份软件许可的年度总价，但真正被评分的是它是否把回合交还给请求者时，在事件上携带针对请求者 pubkey 的p标签（事件级 mention），让用户收到真实的通知而不是一条需要主动发现的普通消息。本文以该任务 README 为主体，结合buzz-acp生产环境基础提示词、harbor-buzz-orchestra编排器的证据快照导出与 fixture 测试源码，完整讲解任务设计意图、环境、验证器六个维度、目录布局与运行方法，帮助你理解并复跑这一"隐式行为基准"。

任务目标：算术是附带品，mention 才是被测对象

user-mention 任务从表面看是一道纯计算题。任务的指令文件只有一句话：

Calculate the annual cost of 12 software licenses priced at $37 per license per month. Reply with the annual total in one concise sentence.

翻译过来即：计算 12 份软件许可（每份每月 $37）的年度总成本，并用一句简洁的话回复年度总额。

但任务的 README 开宗明义地指出：

The arithmetic is incidental — this task measures whether the agent hands the turn back with anevent-level mentionof the requesting human, so the user gets a real Buzz notification instead of a message they have to notice.

即：算术是附带性的，任务真正衡量的是 Agent 在把回合交还给请求者时，是否携带了事件级（event-level）mention——这样用户收到的是 Buzz 里真实的通知，而不是一条必须自己去注意的消息。

这是buzz-dataset的核心理念。数据集根 README 明确写道：这些任务"评分的是 Buzz 产品行为，而不仅仅是任务正确性（scoreBuzz product behavior, not just task correctness）"——每个任务都摆出一个看似普通的问题，真正被评分的是 Agent 如何通过 Buzz 回答它：回复落在哪里、通知了谁、愿意读取什么。

对reply-to-thread与user-mention这类任务还有一个特殊约束：被评分的"隐式行为"刻意不出现在指令里，它必须来自buzz-acp的生产环境基础提示词（production base prompt）。README 特别警告：

The instruction deliberately says nothing about mentioning anyone.The mention is the behavior under test and must come frombuzz-acp's production base prompt. Do not add "mention the user" to the instruction.

因此任何编辑instruction.md的人都不得往指令里添加"请提到用户"之类的字样，否则测试就会失去意义。

三个词显示名：逼出"多词身份 → pubkey"的解析能力

任务试验用户（trial user）被预置了稳定的三词显示名John Vincent Doe，这个常量定义在编排器 fixtures 中：

USER_MENTION_DISPLAY_NAME = "John Vincent Doe" USER_MENTION_TASK = "user-mention" _USER_MENTION_FIXTURE = BuzzTaskFixture( user_display_name=USER_MENTION_DISPLAY_NAME, requires_evidence=True, )

选三词名字是有意的设计。如果用户显示名只有一个 token（比如alice），Agent 可能靠猜测就能蒙对；而John Vincent Doe这样的多词身份迫使 Agent 走真实的解析路径：把多个词的显示名解析为一个 pubkey，而不是猜一个单词的 handle。README 原文为 "forces the agent to resolve a multi-word identity to a pubkey rather than guessing a single-token handle"。

从task_fixtures.py可以看到该 fixture 没有脚本化消息（scripted_messages 为空）、没有目录（directory 为空），只有user_display_name与requires_evidence=True两项——后者表示本任务验证的是导出的中继快照，快照导出失败会导致任务报错。

运行环境：裸 Python 容器 + 真实 Buzz 栈

任务的环境 Dockerfile 极其简单：

FROM python:3.12-slim-bookworm WORKDIR /app

python:3.12-slim-bookworm，不安装任何额外包。README 解释了这个看似简陋的设计："the agent never runs in this container's shell"——Agent 根本不会在这个容器的 shell 里运行。真正干活的是BuzzOrchestraAgent，它会在专用中继（dedicated relay）上拉起真实的buzz-acp/buzz-agent栈（对应数据集 README 描述的buzz-acp→buzz-agent→buzz-dev-mcp链路）。Agent 超时 300 秒。

任务的元数据文件 task.toml 给出了完整的资源与超时声明：

schema_version = "1.3" [task] name = "buzz-native/user-mention" description = "Answer a calculation and mention the three-word user identity." authors = [{ name = "Buzz" }] keywords = ["buzz-native", "messaging", "mentions"] [metadata] evaluation_layer = "regression" difficulty = "easy" category = "collaboration" tags = ["messaging", "mentions", "implicit-behavior"] [agent] timeout_sec = 300.0 [verifier] timeout_sec = 30.0 [environment] network_mode = "public" cpus = 1 memory_mb = 1024 storage_mb = 1024

值得注意的关键配置：

• evaluation_layer = "regression"：本任务属于回归层。数据集根 README 定义了两种评估层——Regression 回答"Buzz 是否守住了已知产品契约"（默认 k=1，用于定向 PR、夜间或预发布），Workflow 回答"Agent 处理真实 Buzz 工作的能力有多强"（默认 k=3，夜间或周度）。README 建议回归结果按行为单独报告，而不是平均成一个能力分。
• difficulty = "easy"、category = "collaboration"、tags 含implicit-behavior（隐式行为）：点明了本任务"行为藏在指令之外"的属性。
• 环境资源：1 CPU、1024 MB 内存、1024 MB 存储，network_mode = "public"（Agent 需要访问 LLM 端点与中继）。
• 验证器超时 30 秒，Agent 超时 300 秒。

验证器：六个程序化维度，reward 取全部合取

任务验证器读取 Agent 运行后的/logs/artifacts/buzz-evidence.json快照。README 指出每个维度都是程序化（programmatic）判定，reward是全部维度的合取（conjunction）——任何一个维度失败，reward 即为 0。

源码级逐维解析

验证器实现在 tests/verify.py 的score_evidence函数中，可以通过源码精确还原每个维度的判定逻辑：

• three_word_user：要求user_name == "John Vincent Doe"且该名字按空格切分恰好为 3 个词（len(USER_DISPLAY_NAME.split()) == 3），验证预置器确实注入了三词身份。
• evidence_complete：要求schema_version == 1、task_name == "user-mention"、truncated is False、task_event_id是字符串、根事件（id 等于task_event_id的消息）恰好一条、channel_id是字符串、编排器恰好一个、用户恰好一个、候选回复存在。这是快照的健康自检——如果证据导出本身出了问题，任务直接判负，而不是把锅甩给 Agent。
• expected_author：候选回复集合按"消息 id 在根事件之后、且 pubkey 等于编排器 pubkey"筛选，取最后一条作为final；该维度要求final.pubkey == agent_pubkey。
• same_channel：要求final.channel_id == channel_id且tags 中确实存在["h", channel_id]这一项——即事件上真正带有通道h标签，而不仅是内容里的文本。
• user_p_tagged（核心被测行为）：通过_has_p_tag检查 tags 中是否存在tag[0] == "p"且tag[1] == user_pubkey的项；同时要求user_pubkey in final.get("mentioned_pubkeys", [])。注意mentioned_pubkeys是证据构建器从事件的原始p标签推导出的字段，因此这一维度完全锚定在签名事件之上。
• answer_correct：用正则(?<![A-Za-z0-9_])-?\$?\d[\d,]*(?:\.\d+)?从回复内容中抽取所有数字，只要存在一个与 5328.0 的差的绝对值 ≤ 1.0 即通过——允许 ±1 的容差。

reward的最终计算是六者合取：

reward = float( all( metric == 1.0 for metric in ( evidence_complete, expected_author, same_channel, three_word_user, user_p_tagged, answer_correct, ) ) )

为什么纯@text不算数：事件即投递证据

user_p_tagged维度的存在，把"展示性提及"与"投递性提及"明确区分开来。README 的原话是 "Presentation-only@textdoes not count"。这背后是 Buzz 的产品语义：在 buzz-acp 基础提示词 的 Mentions 一节中明确写道：

The success JSON'smention_pubkeyscomes from the signed event and is the delivery evidence; no follow-up verification command is needed.

也就是说，--mention <hex-or-npub>传入的显式身份会被签进事件、形成p标签，mention_pubkeys来自签名事件，这才是投递证据。仅仅在正文里写@John Vincent Doe而不传身份，无法触发事件级通知。

fixture 测试如何覆盖验证器

验证器逻辑由 harbor-buzz-orchestra 的测试 覆盖。它通过importlib直接加载数据集里的verify.py，配合 transcripts 目录 下的两条真实形状的会话 fixture（threaded.json与top-level.json）构建证据。五个测试用例恰好卡住行为边界：

• test_correct_answer_with_user_p_tag_passes：threaded.json中编排器回复携带了用户的p标签，全部维度通过，reward = 1.0；
• test_answer_text_without_p_tag_fails_delivery_mention：回复正文写作@John Vincent Doe, the annual cost is $5,328.，answer_correct = 1.0 但 user_p_tagged = 0.0，reward = 0.0——这正是"纯展示性 @text 不算数"的精确印证；
• test_p_tag_without_visible_display_name_passes：即使正文没有可见的显示名，只要p标签在，行为即通过；
• test_wrong_answer_fails_correctness_only：答案错误只扣answer_correct，mention 行为仍然得分；
• test_missing_evidence_fails_closed：证据缺失时全部维度为 0 并带 error 详情——失败关闭（fail closed）。

对比threaded.json与top-level.json也能直观看出两种回复形状的差异：threaded.json中编排器回复携带["e", <root_id>, "", "reply"]与["p", <user_pubkey>]标签（且两个事件同属一个h通道），而top-level.json的回复只有h标签、没有e和p标签——后者恰好构造出user_p_tagged = 0的失败场景。

目录布局

benchmarks/buzz-dataset/user-mention/ ├── instruction.md # 以试验用户身份发布给 Agent 的提示 ├── task.toml # 元数据、超时、1 CPU / 1 GiB 环境 ├── environment/Dockerfile # 裸 python 镜像；中继栈由外部上传 └── tests/ ├── test.sh # 对证据快照运行 verify.py └── verify.py # 确定性评分器（见上文维度表）

其中 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

它把评分器接到三个固定路径上：证据快照读入、奖励 JSON 与详情 JSON 写出。verify.py的main()也会在快照读取失败或 JSON 解析失败时返回全零指标与 error 详情，保证评分不会在异常中崩溃。

运行方法：just benchmark 与编排器 manifest

从仓库根目录运行（任务 README 给出的原版命令）：

just benchmark \ --path benchmarks/buzz-dataset/user-mention \ --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：回归层任务默认就是 k=1，显式给出更清晰；
• --manifest：编排器使用的运行条件 manifest。默认的 buzz-native-solo-luna.yaml 描述的是"一个生产 Buzz Agent + gpt-5.6-luna +thinking_effort: medium"条件，模型上下文窗口 200k tokens、最大输出 4096 tokens，试验预算超时 300 秒（与任务自身的timeout_sec = 300.0对齐）；
• --endpoint-config：LLM 端点配置（OPENAI_COMPAT_API_KEY所在处）。manifest 注释特别说明端点解析属于部署配置、刻意放在 manifest 之外，必须用--endpoint-config显式传入，因为默认值是anthropic-live.json；
• --n-concurrent 1：单并发。

just benchmark配方定义在仓库根 Justfile 中，其实现是调用benchmarks/harbor-buzz-orchestra/scripts/benchmark.py（经uv run在 testbed 项目环境下执行），并自带一套 Docker 栈；--gui可打开实时观察的 spectator 桌面应用。

为什么harbor run -a oracle在这里不可用

README 特别注明：harbor run -a oracle在本任务不适用，且任务没有随附solution/solve.sh。原因在于：Oracle agent 会替换掉BuzzOrchestraAgent，于是不会预置中继试验、也不会导出证据快照——验证器无据可评。验证器的正确性改由 fixture 测试 保证。这是整个 buzz-dataset 的通用约定：普通harbor run对数据集根目录不可用，必须经由harbor-buzz-orchestra编排器。

隐式行为的来源：buzz-acp 基础提示词

user-mention 任务最有趣的一点是：事件级 mention 的"行为规范"来自生产环境提示词，而非任务指令。在 crates/buzz-acp/src/base_prompt.md 中，"Callback Mentions"一节正是这条契约的出处：

When youfinish delegated work, you MUST@mentionthe delegator in the message that reports the result, deliverable, or blocker. This is the #1 cause of stalled collaboration.

即：完成被委托的工作时，必须在报告结果/交付物/阻塞的消息中 @ 提及委托者——这是协作停滞的首要原因。同时它限定"仅针对已完成的工作"：不得为了接受任务、确认收到或闲聊式收尾而 @。

配套的 Mentions 一节给出了可落地的操作细节：

• 通知性 @ 必须使用用户在 Buzz 中显示的精确显示名（如@Alice Smith而非@Alice），不要为了称呼而扩写、推断或搜索"更全"的名字——不完整或不精确的名字会静默失败；
• 不要用加粗、斜体或反引号格式化 mention，这会破坏通知投递；
• 当已知接收者 pubkey 时，正文写可读的@Name文本，同时在同一命令中用--mention <hex-or-npub>显式传入身份（可重复传入多个）——"任何显式身份（--mention或nostr:npub...）都允许未解析或有歧义的@Name文本仅作展示；唯一解析出的成员名仍会添加各自的接收者"；
• 不带--mention时，CLI 会针对当前通道成员解析@Name，遇到未解析/歧义的名字或非成员 pubkey 会在发送前停下。

这些生产提示词约束与验证器的user_p_tagged维度一一对应：提示词要求"显式身份 + 事件级投递"，验证器检查"事件 tags 中的p标签 + 推导出的mentioned_pubkeys"。README 之所以强调"行为必须来自 base prompt"，正是因为默认 manifest 中buzz-acp会从检出的源码构建提供crates/buzz-acp/src/base_prompt.md，而 persona（personas/buzz-native-solo.md）只负责确立"没有团队"这一事实——弱模型 + 中等思考强度下的失败会被解读为提示词问题（prompt finding），而非模型问题（model finding）。

证据快照契约：验证器看到什么

验证器读取的/logs/artifacts/buzz-evidence.json由证据构建器 的build_buzz_evidence生成。该模块定义了面向验证器的稳定契约（EVIDENCE_SCHEMA_VERSION = 1），对每条消息做归一化：保留签名协议证据（原始tags数组），并派生便捷字段——channel_id（取h标签）、reply_to_event_id（取带reply标记的e标签）、mentioned_pubkeys（所有p标签的第二元素）。

快照顶层结构包括schema_version、trial（run_id / trial_id / channel_id）、task_event_id、completion_message_id、identities、directory、message_count、truncated与messages。刻意不含私钥与 auth 标签，只导出中继上本就可见的公开名字、角色与 pubkey。

truncated字段由len(raw_messages) >= transcript_limit判定——这正是evidence_complete中"快照未截断"的来源。verify.py中"恰好一个编排器、恰好一个用户"的要求，则对应于build_buzz_evidence里 identities 的构造方式：试验用户恒为role="user"，编排器凭据的 role 为orchestrator。

与兄弟任务的关系

user-mention 不是孤立任务。数据集根 README 列出了 10 个任务，其中与 mention 语义直接相关、且在验证维度上形成递进关系的有：

• reply-to-thread：回归层，考"在用户的线程里回复，而不是发一条新的顶层消息"；
• narrative-agent-names：回归层，考"在叙述中提及 Agent 名字时不唤醒它们"——即不加p标签；
• ambiguous-user-mention：工作流层，通道里存在两个显示名完全相同的真实身份（都是三词名Taylor Morgan Lee），其about字段携带不同路由码，Agent 必须发现目标 pubkey、只通知它一次、绝不通知孪生身份，并另行回调请求者——该任务在自身 README 中注明守卫的是"静默歧义"问题族，对应block/buzz#4303与block/buzz#6257报告的缺陷。

三者合起来构成一条完整的产品行为谱系：该通知的要通知（user-mention）、不该通知的绝不通知（narrative-agent-names）、通知必须精确到唯一 pubkey（ambiguous-user-mention）。user-mention 作为回归层中最基础的一环，用最低的成本（一条算术题）把"完成工作必须事件级回调请求者"这条契约钉死在基准里。

适用前提与限制

• 运行本任务需要harbor-buzz-orchestra编排器及其 Docker 栈，普通harbor run不可用；需要真实可用的 LLM 端点（默认gpt-5.6-luna对应OPENAI_COMPAT_API_KEY，经--endpoint-config传入）。
• 任务是单轮协作检查（单次试验），不是长时自主运行；回归层默认 k=1，README 建议回归结果按行为报告、用工作流层的通过率与趋势作为基准头条指标。
• instruction.md中不得添加任何关于 mention 的指示——该行为必须由buzz-acp的生产基础提示词驱动，否则任务失去测量意义。
• 验证器是确定性、纯程序化的：所有维度依据签名事件的 tags 判定，纯展示性@text、正文格式美化都无法替代事件级p标签。

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