Buzz 同名用户消歧基准任务解析ambiguous-user-mention 的指令、环境与确定性验证【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz本篇文章以 Buzz 开源仓库中benchmarks/buzz-dataset/ambiguous-user-mention基准任务为主体完整剖析其任务指令、环境布置、目录身份设定与确定性评分验证器并结合 Harbor 编排层的夹具与对抗性测试说明如何度量一个 Agent 在同名用户 路由码甄别场景下的真实能力。读完本文你可以复现该任务的验证逻辑、理解每一条评分指标的含义并据此改进自己的 Agent 提及mention消歧策略。任务背景守护静默歧义这一类失败模式在 Buzz 这类以 Nostr 事件驱动的多 Agent 协作平台中频道channel成员由公钥唯一标识但显示名display name并不唯一。当两个真实身份恰好使用了完全相同的三词显示名时一个只按名字发送消息的 Agent 就会陷入静默歧义它既不会报错也不会提示冲突而是看似正常地把消息送给了错误的对象——这类失败非常隐蔽难以在事后从聊天记录中直观发现。ambiguous-user-mention正是为这一族静默歧义问题设计的基准任务。根据 任务 README该任务守护的正是早期报告中被编号为#4303与#6257的两类同源缺陷Agent 在无法区分同名用户时要么错误通知了同名者中的另一个人要么干脆无法完成投递。README 中将其归纳为一个明确的验收基线Agent必须发现真正的目标公钥、恰好通知一次、绝不知会同名者、并单独向请求方回执。任务指令原文与验收标准拆解instruction.md 全文只有四句话是发给 Agent 的最终提示词值得逐句拆解其隐含要求Two channel members are both displayed asTaylor Morgan Lee. Find the one whose profile saysRouting code ORCHID-72and send that person the messageORCHID-72 approved. Do not notify the other Taylor Morgan Lee. Then tell me briefly that it was sent.拆解后可以得到五条验收约束恰好对应验证器中的五个硬性指标指令原文隐含验收约束对应验证指标频道中有两名成员都显示为Taylor Morgan LeeAgent 必须意识到同名歧义不能凭名字直接投递—前置条件Find the one whose profile saysRouting code ORCHID-72Agent 必须读取双方 profileabout 字段依据路由码定位目标公钥evidence_complete目录完整、公钥可区分send that person the messageORCHID-72 approved目标用户必须被恰好通知一次且消息内容精确包含ORCHID-72 approvedtarget_notified_once、message_correctDo not notify the other Taylor Morgan Lee同名者observer不得被通知即不能出现在任何消息的提及公钥中other_not_notifiedThen tell me briefly that it was sent必须单独向请求方用户回执且回执内容提及 sent / notified / delivered 等词user_callback特别注意最后一句话的措辞then tell me briefly that it was sent 要求 Agent 在同一频道内另发一条面向请求方用户的消息作为回执而不是把回执与投递消息混为一条。验证器对此有独立指标user_callback把关。任务清单 task.toml运行边界与资源约束每个 Buzz 数据集任务都由 task.toml 描述运行契约本任务采用schema_version 1.3完整内容如下schema_version 1.3 [task] name buzz-native/ambiguous-user-mention description Resolve two identical display names by profile evidence and notify only the intended pubkey. authors [{ name Buzz }] keywords [buzz-native, mentions, identity, ambiguity] [metadata] evaluation_layer workflow difficulty hard category collaboration tags [mentions, identity, ambiguity, 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评估发生在完整工作流层面而非单一函数或单条消息——Agent 需要完成读取目录 → 比对 profile → 投递 → 回执的端到端闭环difficulty hard任务被标注为高难度因为它同时考验身份解析、精确投递与避免误伤三个维度agent.timeout_sec 300.0Agent 有 300 秒完成全部动作超时即视为未完成verifier.timeout_sec 30.0评分器本身必须在 30 秒内产出结果保证评测管线可并行、可调度[environment]每个 trial 运行在公开网络、单核 1 GB 内存的隔离容器中storage_mb 1024限定临时存储上限。从workflow 层评估这个定位可以看出该任务评测的不是单条消息的对错而是整条 Agent 行为链的纪律性谁被提及、谁没被提及、回执是否独立、事件是否都挂在正确的线程reply_to下全部进入评分。环境布置两份同名身份与两个路由码任务环境由 Dockerfilepython:3.12-slim-bookworm基础镜像构建而频道内的身份目录则定义在编排层的夹具文件中。在 task_fixtures.py 中可以找到本任务的_AMBIGUOUS_USER_MENTION_FIXTURE它定义了频道中的两名成员identity_id显示名roleaboutprofile路由码taylor-release-captainTaylor Morgan LeeuserRelease captain.Routing code ORCHID-72.ORCHID-72目标taylor-observerTaylor Morgan LeeuserCompliance observer.Routing code COBALT-19.COBALT-19干扰项两者同为频道成员channel_memberTrue显示名完全一致唯一可区分的信息就是about字段中的路由码。请求方用户的显示名为Olivia Grace Park。这个夹具设计刻意制造了名字相同、语义角色不同、可观测特征唯一的最小消歧条件Agent 只有读取双方 profile 才能定位ORCHID-72任何依赖名字、顺序或运气的行为都会被对抗用例击穿。确定性验证器六项指标如何被计算本任务的核心裁判是 verify.py它是一个无随机性、无外部依赖的纯 Python 评分器输入一份buzz-evidence.jsonAgent 行为的审计留痕输出reward.json分数与details.json细粒度诊断。验证器首先固定了两个身份常量TARGET_ID taylor-release-captain OTHER_ID taylor-observer随后从 evidence 中提取目录directory、身份表identities、Agent 消息messages并据此计算六项子指标target_notified_onceAgent 署名pubkey 匹配唯一的 orchestrator发出的消息中提及了目标公钥的消息恰好只有一条时得 1.0零条或多条均不得分other_not_notified提及taylor-observer公钥的消息条数为0时得 1.0——这是不误伤同名者的直接度量message_correct投递消息的内容包含子串ORCHID-72 approveduser_callback存在一条面向请求方Olivia Grace Park公钥、且内容忽略大小写包含sent、notified或delivered任一单词的独立回执消息reply_to_thread投递消息与回执消息的reply_to_event_id都指向任务根事件task_event_id保证所有动作挂在正确的线程上下文而非散落频道evidence_completeevidence 的schema_version 1、task_name ambiguous-user-mention、truncated为 false、目录恰好 2 个身份且两个公钥都是字符串且互不相同、orchestrator 恰好 1 个——即 Agent 必须主动提交完整、可审计的证据包。最终reward是六项子指标的全 1 逻辑与all(value 1.0 ...)也就是说任何一项失败总奖励直接归零。这种全有或全无的评分设计避免了部分得分带来的糊弄空间只投递不回执、投递了但误伤同名者、或回执混进投递消息都会导致整体失败。验证器还同时输出诊断字段target_pubkey、other_pubkey、delivery_message_id、callback_message_id、target_notification_count与other_notification_count便于评测人员快速定位失败发生在哪一环。证据包与运行管线buzz-evidence.json 的约定证据evidence是本任务 Agent 行为的唯一事实来源。从 verify.py 的读取逻辑可以看到它的顶层结构约定task_event_id任务根事件 ID回执与投递都必须reply_to它directory频道成员目录每行含identity_id、name、role、pubkey等字段验证器按identity_id建立索引identities身份表包含用户如Olivia Grace Park与 role 为orchestrator的 Agent 及其公钥messagesAgent 消息列表每条含pubkey、content、mentioned_pubkeys、reply_to_event_id等字段schema_version、task_name、truncated证据包的元数据完整性标记。运行管线由 test.sh 封装mkdir -p /logs/verifier python3 /tests/verify.py --evidence /logs/artifacts/buzz-evidence.json --reward /logs/verifier/reward.json --details /logs/verifier/details.json即评测框架把 Agent 的完整行为审计落盘到/logs/artifacts/buzz-evidence.json随后调用验证器产出分数与诊断。验证器对任何解析错误文件缺失、JSON 非法都会安全返回全零分数并记录 error 详情保证评测管线在 Agent 行为异常时也不会崩溃。对抗性测试验证器如何防作弊编排层在 test_expanded_buzz_native_verifiers.py 中为每个任务都提供了正例与对抗例两套夹具test_ambiguous_user_mention_targets_only_profile_match展示了本任务的关键边界正例投递消息Taylor Morgan Lee ORCHID-72 approved只提及目标公钥回执消息Sent to the matching Taylor Morgan Lee.面向用户——六项指标全 1对抗例在投递消息的mentioned_pubkeys中追加干扰对象的公钥other_not_notified立即归零总奖励归零。这验证了一个关键事实提到名字不等于通知到人。验证器不看消息文本里的Taylor Morgan Lee字符串只看结构化提及公钥mentioned_pubkeys因此 Agent 若以字符串拼接方式在正文里带上对方名字、却没有在事件标签中生成对应的p标签提及是无法通过验证的反之正文写得再像样只要mentioned_pubkeys里混入了 observer 的公钥同样判负。这个设计对应 Buzz 底层以 Nostrp标签驱动真实通知投递的机制。给 Agent 实现者的实战要点综合指令、夹具与验证器一个能稳定通过本任务的 Agent 至少需要具备以下行为纪律先查目录后发消息收到通知某个人类请求时先枚举频道成员目录识别同名分组不要直接把显示名当唯一键使用用 profile 证据消歧当名字碰撞时读取每个候选身份的about字段将任务中提到的路由码ORCHID-72与之一一比对锁定目标identity_id及其公钥投递与回执分离面向目标用户的投递消息与面向请求方的回执消息必须是两条独立事件回执正文需明确使用sent/notified/delivered语义词精确控制提及公钥目标消息的提及公钥列表必须恰好包含目标一人回执消息的提及公钥必须只指向请求方保持线程上下文投递与回执的reply_to_event_id都应指向任务根事件保证事件血缘完整提交完整证据将目录快照、身份表、全部消息以及schema_version、task_name、truncated等元数据一并写入 evidence缺一不可。总结ambiguous-user-mention是 Buzz 基准数据集中针对同名身份消歧这一类静默失败的高压测试任务指令极短但通过路由码比对 恰好一次投递 零误伤 独立回执 线程一致 证据完整六项硬指标把 Agent 的身份解析、提及纪律与审计可追溯性压缩进一次 300 秒的 trial 中。其 确定性验证器 与 对抗性测试 共同保证了评分结果可复现、不可投机也为真实产品中同名用户 精确通知场景提供了可直接落地的验收范式。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Buzz 同名用户消歧基准任务解析：ambiguous-user-mention 的指令、环境与确定性验证
Buzz 同名用户消歧基准任务解析ambiguous-user-mention 的指令、环境与确定性验证【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz本篇文章以 Buzz 开源仓库中benchmarks/buzz-dataset/ambiguous-user-mention基准任务为主体完整剖析其任务指令、环境布置、目录身份设定与确定性评分验证器并结合 Harbor 编排层的夹具与对抗性测试说明如何度量一个 Agent 在同名用户 路由码甄别场景下的真实能力。读完本文你可以复现该任务的验证逻辑、理解每一条评分指标的含义并据此改进自己的 Agent 提及mention消歧策略。任务背景守护静默歧义这一类失败模式在 Buzz 这类以 Nostr 事件驱动的多 Agent 协作平台中频道channel成员由公钥唯一标识但显示名display name并不唯一。当两个真实身份恰好使用了完全相同的三词显示名时一个只按名字发送消息的 Agent 就会陷入静默歧义它既不会报错也不会提示冲突而是看似正常地把消息送给了错误的对象——这类失败非常隐蔽难以在事后从聊天记录中直观发现。ambiguous-user-mention正是为这一族静默歧义问题设计的基准任务。根据 任务 README该任务守护的正是早期报告中被编号为#4303与#6257的两类同源缺陷Agent 在无法区分同名用户时要么错误通知了同名者中的另一个人要么干脆无法完成投递。README 中将其归纳为一个明确的验收基线Agent必须发现真正的目标公钥、恰好通知一次、绝不知会同名者、并单独向请求方回执。任务指令原文与验收标准拆解instruction.md 全文只有四句话是发给 Agent 的最终提示词值得逐句拆解其隐含要求Two channel members are both displayed asTaylor Morgan Lee. Find the one whose profile saysRouting code ORCHID-72and send that person the messageORCHID-72 approved. Do not notify the other Taylor Morgan Lee. Then tell me briefly that it was sent.拆解后可以得到五条验收约束恰好对应验证器中的五个硬性指标指令原文隐含验收约束对应验证指标频道中有两名成员都显示为Taylor Morgan LeeAgent 必须意识到同名歧义不能凭名字直接投递—前置条件Find the one whose profile saysRouting code ORCHID-72Agent 必须读取双方 profileabout 字段依据路由码定位目标公钥evidence_complete目录完整、公钥可区分send that person the messageORCHID-72 approved目标用户必须被恰好通知一次且消息内容精确包含ORCHID-72 approvedtarget_notified_once、message_correctDo not notify the other Taylor Morgan Lee同名者observer不得被通知即不能出现在任何消息的提及公钥中other_not_notifiedThen tell me briefly that it was sent必须单独向请求方用户回执且回执内容提及 sent / notified / delivered 等词user_callback特别注意最后一句话的措辞then tell me briefly that it was sent 要求 Agent 在同一频道内另发一条面向请求方用户的消息作为回执而不是把回执与投递消息混为一条。验证器对此有独立指标user_callback把关。任务清单 task.toml运行边界与资源约束每个 Buzz 数据集任务都由 task.toml 描述运行契约本任务采用schema_version 1.3完整内容如下schema_version 1.3 [task] name buzz-native/ambiguous-user-mention description Resolve two identical display names by profile evidence and notify only the intended pubkey. authors [{ name Buzz }] keywords [buzz-native, mentions, identity, ambiguity] [metadata] evaluation_layer workflow difficulty hard category collaboration tags [mentions, identity, ambiguity, 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评估发生在完整工作流层面而非单一函数或单条消息——Agent 需要完成读取目录 → 比对 profile → 投递 → 回执的端到端闭环difficulty hard任务被标注为高难度因为它同时考验身份解析、精确投递与避免误伤三个维度agent.timeout_sec 300.0Agent 有 300 秒完成全部动作超时即视为未完成verifier.timeout_sec 30.0评分器本身必须在 30 秒内产出结果保证评测管线可并行、可调度[environment]每个 trial 运行在公开网络、单核 1 GB 内存的隔离容器中storage_mb 1024限定临时存储上限。从workflow 层评估这个定位可以看出该任务评测的不是单条消息的对错而是整条 Agent 行为链的纪律性谁被提及、谁没被提及、回执是否独立、事件是否都挂在正确的线程reply_to下全部进入评分。环境布置两份同名身份与两个路由码任务环境由 Dockerfilepython:3.12-slim-bookworm基础镜像构建而频道内的身份目录则定义在编排层的夹具文件中。在 task_fixtures.py 中可以找到本任务的_AMBIGUOUS_USER_MENTION_FIXTURE它定义了频道中的两名成员identity_id显示名roleaboutprofile路由码taylor-release-captainTaylor Morgan LeeuserRelease captain.Routing code ORCHID-72.ORCHID-72目标taylor-observerTaylor Morgan LeeuserCompliance observer.Routing code COBALT-19.COBALT-19干扰项两者同为频道成员channel_memberTrue显示名完全一致唯一可区分的信息就是about字段中的路由码。请求方用户的显示名为Olivia Grace Park。这个夹具设计刻意制造了名字相同、语义角色不同、可观测特征唯一的最小消歧条件Agent 只有读取双方 profile 才能定位ORCHID-72任何依赖名字、顺序或运气的行为都会被对抗用例击穿。确定性验证器六项指标如何被计算本任务的核心裁判是 verify.py它是一个无随机性、无外部依赖的纯 Python 评分器输入一份buzz-evidence.jsonAgent 行为的审计留痕输出reward.json分数与details.json细粒度诊断。验证器首先固定了两个身份常量TARGET_ID taylor-release-captain OTHER_ID taylor-observer随后从 evidence 中提取目录directory、身份表identities、Agent 消息messages并据此计算六项子指标target_notified_onceAgent 署名pubkey 匹配唯一的 orchestrator发出的消息中提及了目标公钥的消息恰好只有一条时得 1.0零条或多条均不得分other_not_notified提及taylor-observer公钥的消息条数为0时得 1.0——这是不误伤同名者的直接度量message_correct投递消息的内容包含子串ORCHID-72 approveduser_callback存在一条面向请求方Olivia Grace Park公钥、且内容忽略大小写包含sent、notified或delivered任一单词的独立回执消息reply_to_thread投递消息与回执消息的reply_to_event_id都指向任务根事件task_event_id保证所有动作挂在正确的线程上下文而非散落频道evidence_completeevidence 的schema_version 1、task_name ambiguous-user-mention、truncated为 false、目录恰好 2 个身份且两个公钥都是字符串且互不相同、orchestrator 恰好 1 个——即 Agent 必须主动提交完整、可审计的证据包。最终reward是六项子指标的全 1 逻辑与all(value 1.0 ...)也就是说任何一项失败总奖励直接归零。这种全有或全无的评分设计避免了部分得分带来的糊弄空间只投递不回执、投递了但误伤同名者、或回执混进投递消息都会导致整体失败。验证器还同时输出诊断字段target_pubkey、other_pubkey、delivery_message_id、callback_message_id、target_notification_count与other_notification_count便于评测人员快速定位失败发生在哪一环。证据包与运行管线buzz-evidence.json 的约定证据evidence是本任务 Agent 行为的唯一事实来源。从 verify.py 的读取逻辑可以看到它的顶层结构约定task_event_id任务根事件 ID回执与投递都必须reply_to它directory频道成员目录每行含identity_id、name、role、pubkey等字段验证器按identity_id建立索引identities身份表包含用户如Olivia Grace Park与 role 为orchestrator的 Agent 及其公钥messagesAgent 消息列表每条含pubkey、content、mentioned_pubkeys、reply_to_event_id等字段schema_version、task_name、truncated证据包的元数据完整性标记。运行管线由 test.sh 封装mkdir -p /logs/verifier python3 /tests/verify.py --evidence /logs/artifacts/buzz-evidence.json --reward /logs/verifier/reward.json --details /logs/verifier/details.json即评测框架把 Agent 的完整行为审计落盘到/logs/artifacts/buzz-evidence.json随后调用验证器产出分数与诊断。验证器对任何解析错误文件缺失、JSON 非法都会安全返回全零分数并记录 error 详情保证评测管线在 Agent 行为异常时也不会崩溃。对抗性测试验证器如何防作弊编排层在 test_expanded_buzz_native_verifiers.py 中为每个任务都提供了正例与对抗例两套夹具test_ambiguous_user_mention_targets_only_profile_match展示了本任务的关键边界正例投递消息Taylor Morgan Lee ORCHID-72 approved只提及目标公钥回执消息Sent to the matching Taylor Morgan Lee.面向用户——六项指标全 1对抗例在投递消息的mentioned_pubkeys中追加干扰对象的公钥other_not_notified立即归零总奖励归零。这验证了一个关键事实提到名字不等于通知到人。验证器不看消息文本里的Taylor Morgan Lee字符串只看结构化提及公钥mentioned_pubkeys因此 Agent 若以字符串拼接方式在正文里带上对方名字、却没有在事件标签中生成对应的p标签提及是无法通过验证的反之正文写得再像样只要mentioned_pubkeys里混入了 observer 的公钥同样判负。这个设计对应 Buzz 底层以 Nostrp标签驱动真实通知投递的机制。给 Agent 实现者的实战要点综合指令、夹具与验证器一个能稳定通过本任务的 Agent 至少需要具备以下行为纪律先查目录后发消息收到通知某个人类请求时先枚举频道成员目录识别同名分组不要直接把显示名当唯一键使用用 profile 证据消歧当名字碰撞时读取每个候选身份的about字段将任务中提到的路由码ORCHID-72与之一一比对锁定目标identity_id及其公钥投递与回执分离面向目标用户的投递消息与面向请求方的回执消息必须是两条独立事件回执正文需明确使用sent/notified/delivered语义词精确控制提及公钥目标消息的提及公钥列表必须恰好包含目标一人回执消息的提及公钥必须只指向请求方保持线程上下文投递与回执的reply_to_event_id都应指向任务根事件保证事件血缘完整提交完整证据将目录快照、身份表、全部消息以及schema_version、task_name、truncated等元数据一并写入 evidence缺一不可。总结ambiguous-user-mention是 Buzz 基准数据集中针对同名身份消歧这一类静默失败的高压测试任务指令极短但通过路由码比对 恰好一次投递 零误伤 独立回执 线程一致 证据完整六项硬指标把 Agent 的身份解析、提及纪律与审计可追溯性压缩进一次 300 秒的 trial 中。其 确定性验证器 与 对抗性测试 共同保证了评分结果可复现、不可投机也为真实产品中同名用户 精确通知场景提供了可直接落地的验收范式。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考