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 Lee`	Agent 必须意识到同名歧义，不能凭名字直接投递	—（前置条件）
Find the one whose profile says`Routing code ORCHID-72`	Agent 必须读取双方 profile（about 字段），依据路由码定位目标公钥	`evidence_complete`（目录完整、公钥可区分）
send that person the message`ORCHID-72 approved`	目标用户必须被恰好通知一次，且消息内容精确包含`ORCHID-72 approved`	`target_notified_once`、`message_correct`
Do not notify the other Taylor Morgan Lee	同名者（observer）不得被通知，即不能出现在任何消息的提及公钥中	`other_not_notified`
Then 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.0：Agent 有 300 秒完成全部动作，超时即视为未完成；
verifier.timeout_sec = 30.0：评分器本身必须在 30 秒内产出结果，保证评测管线可并行、可调度；
[environment]：每个 trial 运行在公开网络、单核 1 GB 内存的隔离容器中，storage_mb = 1024限定临时存储上限。

从"workflow 层评估"这个定位可以看出，该任务评测的不是单条消息的对错，而是整条 Agent 行为链的纪律性：谁被提及、谁没被提及、回执是否独立、事件是否都挂在正确的线程（reply_to）下，全部进入评分。

环境布置：两份同名身份与两个路由码

任务环境由 Dockerfile（python:3.12-slim-bookworm基础镜像）构建，而频道内的身份目录则定义在编排层的夹具文件中。在 task_fixtures.py 中可以找到本任务的_AMBIGUOUS_USER_MENTION_FIXTURE，它定义了频道中的两名成员：

identity_id	显示名	role	about（profile）	路由码
`taylor-release-captain`	Taylor Morgan Lee	user	Release captain.Routing code ORCHID-72.	ORCHID-72（目标）
`taylor-observer`	Taylor Morgan Lee	user	Compliance observer.Routing code COBALT-19.	COBALT-19（干扰项）

两者同为频道成员（channel_member=True），显示名完全一致，唯一可区分的信息就是about字段中的路由码。请求方用户的显示名为Olivia Grace Park。这个夹具设计刻意制造了"名字相同、语义角色不同、可观测特征唯一"的最小消歧条件：Agent 只有读取双方 profile 才能定位ORCHID-72，任何依赖名字、顺序或运气的行为都会被对抗用例击穿。

确定性验证器：六项指标如何被计算

本任务的核心裁判是 verify.py，它是一个无随机性、无外部依赖的纯 Python 评分器，输入一份buzz-evidence.json（Agent 行为的审计留痕），输出reward.json（分数）与details.json（细粒度诊断）。

验证器首先固定了两个身份常量：

TARGET_ID = "taylor-release-captain" OTHER_ID = "taylor-observer"

随后从 evidence 中提取目录（directory）、身份表（identities）、Agent 消息（messages），并据此计算六项子指标：

target_notified_once：Agent 署名（pubkey 匹配唯一的 orchestrator）发出的消息中，提及了目标公钥的消息恰好只有一条时得 1.0，零条或多条均不得分；
other_not_notified：提及taylor-observer公钥的消息条数为0时得 1.0——这是"不误伤同名者"的直接度量；
message_correct：投递消息的内容包含子串ORCHID-72 approved；
user_callback：存在一条面向请求方Olivia Grace Park公钥、且内容（忽略大小写）包含sent、notified或delivered任一单词的独立回执消息；
reply_to_thread：投递消息与回执消息的reply_to_event_id都指向任务根事件（task_event_id），保证所有动作挂在正确的线程上下文而非散落频道；
evidence_complete：evidence 的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 及其公钥；
messages：Agent 消息列表，每条含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），仅供参考