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-levelmention——这样用户收到的是 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-acps 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_nameUSER_MENTION_DISPLAY_NAME, requires_evidenceTrue, )选三词名字是有意的设计。如果用户显示名只有一个 token比如aliceAgent 可能靠猜测就能蒙对而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_evidenceTrue两项——后者表示本任务验证的是导出的中继快照快照导出失败会导致任务报错。运行环境裸 Python 容器 真实 Buzz 栈任务的环境 Dockerfile 极其简单FROM python:3.12-slim-bookworm WORKDIR /apppython:3.12-slim-bookworm不安装任何额外包。README 解释了这个看似简陋的设计the agent never runs in this containers 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 是否守住了已知产品契约默认 k1用于定向 PR、夜间或预发布Workflow 回答Agent 处理真实 Buzz 工作的能力有多强默认 k3夜间或周度。README 建议回归结果按行为单独报告而不是平均成一个能力分。difficulty easy、category collaboration、tags 含implicit-behavior隐式行为点明了本任务行为藏在指令之外的属性。环境资源1 CPU、1024 MB 内存、1024 MB 存储network_mode publicAgent 需要访问 LLM 端点与中继。验证器超时 30 秒Agent 超时 300 秒。验证器六个程序化维度reward 取全部合取任务验证器读取 Agent 运行后的/logs/artifacts/buzz-evidence.json快照。README 指出每个维度都是程序化programmatic判定reward是全部维度的合取conjunction——任何一个维度失败reward 即为 0。维度类型度量内容evidence_completeprogrammatic快照为 v1、未截断、指明本任务且恰好解析出一个编排器、一个用户和一个候选回复。属于 Harness 健康检查而非 Agent 能力three_word_userprogrammatic预置器确实注入了三词显示名。fixture 自检expected_authorprogrammatic被评分的消息由编排器发布same_channelprogrammatic回复携带试验通道的h标签user_p_taggedprogrammatic回复为用户的 pubkey 携带p标签——即被测行为。纯展示性的text不算数answer_correctprogrammatic年度总额为 5,32812 许可 × $37 × 12 月误差 ±1源码级逐维解析验证器实现在 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-onlytextdoes not count。这背后是 Buzz 的产品语义在 buzz-acp 基础提示词 的 Mentions 一节中明确写道The success JSONsmention_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 目录 下的两条真实形状的会话 fixturethreaded.json与top-level.json构建证据。五个测试用例恰好卡住行为边界test_correct_answer_with_user_p_tag_passesthreaded.json中编排器回复携带了用户的p标签全部维度通过reward 1.0test_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.0reward 0.0——这正是纯展示性 text 不算数的精确印证test_p_tag_without_visible_display_name_passes即使正文没有可见的显示名只要p标签在行为即通过test_wrong_answer_fails_correctness_only答案错误只扣answer_correctmention 行为仍然得分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回归层任务默认就是 k1显式给出更清晰--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-configLLM 端点配置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 MUSTmentionthe 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而 personapersonas/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、trialrun_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 的构造方式试验用户恒为roleuser编排器凭据的 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、通知必须精确到唯一 pubkeyambiguous-user-mention。user-mention 作为回归层中最基础的一环用最低的成本一条算术题把完成工作必须事件级回调请求者这条契约钉死在基准里。适用前提与限制运行本任务需要harbor-buzz-orchestra编排器及其 Docker 栈普通harbor run不可用需要真实可用的 LLM 端点默认gpt-5.6-luna对应OPENAI_COMPAT_API_KEY经--endpoint-config传入。任务是单轮协作检查单次试验不是长时自主运行回归层默认 k1README 建议回归结果按行为报告、用工作流层的通过率与趋势作为基准头条指标。instruction.md中不得添加任何关于 mention 的指示——该行为必须由buzz-acp的生产基础提示词驱动否则任务失去测量意义。验证器是确定性、纯程序化的所有维度依据签名事件的 tags 判定纯展示性text、正文格式美化都无法替代事件级p标签。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 buzz 基准测试实战：user-mention 任务如何用事件级 `p` 标签守卫生成式 Agent 的通知契约
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-levelmention——这样用户收到的是 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-acps 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_nameUSER_MENTION_DISPLAY_NAME, requires_evidenceTrue, )选三词名字是有意的设计。如果用户显示名只有一个 token比如aliceAgent 可能靠猜测就能蒙对而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_evidenceTrue两项——后者表示本任务验证的是导出的中继快照快照导出失败会导致任务报错。运行环境裸 Python 容器 真实 Buzz 栈任务的环境 Dockerfile 极其简单FROM python:3.12-slim-bookworm WORKDIR /apppython:3.12-slim-bookworm不安装任何额外包。README 解释了这个看似简陋的设计the agent never runs in this containers 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 是否守住了已知产品契约默认 k1用于定向 PR、夜间或预发布Workflow 回答Agent 处理真实 Buzz 工作的能力有多强默认 k3夜间或周度。README 建议回归结果按行为单独报告而不是平均成一个能力分。difficulty easy、category collaboration、tags 含implicit-behavior隐式行为点明了本任务行为藏在指令之外的属性。环境资源1 CPU、1024 MB 内存、1024 MB 存储network_mode publicAgent 需要访问 LLM 端点与中继。验证器超时 30 秒Agent 超时 300 秒。验证器六个程序化维度reward 取全部合取任务验证器读取 Agent 运行后的/logs/artifacts/buzz-evidence.json快照。README 指出每个维度都是程序化programmatic判定reward是全部维度的合取conjunction——任何一个维度失败reward 即为 0。维度类型度量内容evidence_completeprogrammatic快照为 v1、未截断、指明本任务且恰好解析出一个编排器、一个用户和一个候选回复。属于 Harness 健康检查而非 Agent 能力three_word_userprogrammatic预置器确实注入了三词显示名。fixture 自检expected_authorprogrammatic被评分的消息由编排器发布same_channelprogrammatic回复携带试验通道的h标签user_p_taggedprogrammatic回复为用户的 pubkey 携带p标签——即被测行为。纯展示性的text不算数answer_correctprogrammatic年度总额为 5,32812 许可 × $37 × 12 月误差 ±1源码级逐维解析验证器实现在 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-onlytextdoes not count。这背后是 Buzz 的产品语义在 buzz-acp 基础提示词 的 Mentions 一节中明确写道The success JSONsmention_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 目录 下的两条真实形状的会话 fixturethreaded.json与top-level.json构建证据。五个测试用例恰好卡住行为边界test_correct_answer_with_user_p_tag_passesthreaded.json中编排器回复携带了用户的p标签全部维度通过reward 1.0test_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.0reward 0.0——这正是纯展示性 text 不算数的精确印证test_p_tag_without_visible_display_name_passes即使正文没有可见的显示名只要p标签在行为即通过test_wrong_answer_fails_correctness_only答案错误只扣answer_correctmention 行为仍然得分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回归层任务默认就是 k1显式给出更清晰--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-configLLM 端点配置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 MUSTmentionthe 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而 personapersonas/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、trialrun_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 的构造方式试验用户恒为roleuser编排器凭据的 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、通知必须精确到唯一 pubkeyambiguous-user-mention。user-mention 作为回归层中最基础的一环用最低的成本一条算术题把完成工作必须事件级回调请求者这条契约钉死在基准里。适用前提与限制运行本任务需要harbor-buzz-orchestra编排器及其 Docker 栈普通harbor run不可用需要真实可用的 LLM 端点默认gpt-5.6-luna对应OPENAI_COMPAT_API_KEY经--endpoint-config传入。任务是单轮协作检查单次试验不是长时自主运行回归层默认 k1README 建议回归结果按行为报告、用工作流层的通过率与趋势作为基准头条指标。instruction.md中不得添加任何关于 mention 的指示——该行为必须由buzz-acp的生产基础提示词驱动否则任务失去测量意义。验证器是确定性、纯程序化的所有维度依据签名事件的 tags 判定纯展示性text、正文格式美化都无法替代事件级p标签。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考