企业官网建设流程全解析

Buzz 基准测试中的叙述性 Agent 名称：在 Buzz 平台中如何引用 bot 而不触发唤醒

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

导读

在 Buzz 这类基于 Nostr 的群聊式协作平台中，当 Agent 需要向人类汇报"机器人 A 完成了审计、机器人 B 保持空闲"这类状态时，最容易犯的错误是把机器人的名字写成@Name形式或给它们加上p标签，从而意外"唤醒"这些本不需要行动的 bot。本文以仓库内 narrative-agent-names 这一基准任务为主线，完整拆解其指令、判分器（verifier）、证据契约与运行方式，并结合 buzz-acp 的生产级基础提示词与 harbor-buzz-orchestra 评测框架源码，讲清"叙述性名称不唤醒"这一产品契约背后的协议机制与可复现的评测方法。读完本文，你将掌握 Buzz 中p标签、@Name提及与普通叙述文本的边界，并能亲手运行该回归评测。

任务全景：这是一道"产品行为"回归题

narrative-agent-names是 buzz-dataset 中十个 Buzz 产品行为评测任务之一。与普通"任务正确性"评测不同，这类任务"评判的不是 Agent 是否答对，而是它通过 Buzz 如何作答——回复落在哪里、通知了谁、它愿意读什么"。它的元数据声明（见 task.toml）：

• 评估层：regression（回归），用于确认 Buzz 是否保住已知的产品契约；
• 难度：medium，类别：collaboration，标签：mentions、agents、notifications；
• Agent 超时：300 秒（单轮协作检查，与默认清单中的trial_budget.timeout_seconds: 300一致）；
• Verifier 超时：30 秒；
• 环境：network_mode = "public"、1 CPU、1024 MB 内存、1024 MB 存储。

任务对应的行为契约在数据集总表里一句话点明："在叙述中命名 Agent，而不用p标签唤醒它们"。它在 harbor-buzz-orchestra 中的 buzz-native 任务清单里也占据一席：评测覆盖"直接线程回复、回调用户提及、命名路径定向读取、精确频道成员、多行投递、不唤醒的叙述性名称、批量报告、跨线程隔离、歧义身份、显式冷记忆检索"。

原始指令：一段刻意"普通"的两行状态汇报

该任务的 instruction.md 全文如下：

Give me a two-line status update:

• Aurora Audit Bot completed the audit.
• Beacon Deploy Bot remains idle.

This is only a status summary. Neither bot has any work to do.

这段指令的每一处设计都有讲究：

1. 明确要求"两行"（two-line）：评判器会用正则逐行检查"哪个 bot 是什么状态"，两行结构便于确定性判分；
2. 两个 bot 的名字以普通叙述文本出现：Aurora Audit Bot、Beacon Deploy Bot，指令里没有任何@前缀，也没有要求提及任何人——而这正是评测点：被测试的行为（不添加p标签、不写成@Name）故意没有写进指令，而是由 base_prompt.md 这一生产级基础提示词来保证（数据集合 README 明确写到：对reply-to-thread和user-mention等任务，"被评判的行为是刻意不出现在 instruction.md 中的——它必须来自 buzz-acp 的生产基础提示词"）；
3. "This is only a status summary. Neither bot has any work to do."：这一句向 Agent 强调这只是一份状态摘要，两个 bot 都不需要做任何事，从意图层面抑制"顺手去呼叫 bot"的倾向。

任务 README 对契约的解读

任务自带的 README.md 把契约讲得更明确：

The agent reports status about two in-channel bots. Both names must remain plain narrative text: neither bot may receive aptag or an@Namewake-up. The requesting human must still receive the callback mention. This guards the acknowledgement and false-wake behavior in block/buzz#5176.

即三条硬性约束：

• 名字必须保持普通叙述文本——bot 不得收到p标签，也不得收到@Name形式的唤醒；
• 发起请求的人类必须收到回调提及（callback mention），确保人知道 Agent 已完成任务；
• 该任务守卫的是 #5176 中关于"确认回执"与"误唤醒"的行为（防止 Agent 为了确认某个 bot 的存在而误把它唤醒）。

判分器逐维度拆解：六个满分条件

任务的核心是可确定性判分的验证脚本 tests/verify.py。它读取/logs/artifacts/buzz-evidence.json，输出reward.json（六项 0/1 指标）与details.json（选定消息 ID、内容与提及公钥）。六个维度全部为 1.0 才得 1.0 满分：

1.status_correct：状态内容必须逐行正确

用两个忽略大小写的正则分别匹配：

re.search(r"Aurora Audit Bot[^.\n]*completed", content, re.IGNORECASE) re.search(r"Beacon Deploy Bot[^.\n]*idle", content, re.IGNORECASE)

• [^.\n]*允许 bot 名与状态词之间出现空格、修饰语，但不允许跨句（不能把Aurora Audit Bot的状态写到下一句）；
• 方向颠倒即为失败：若写成 "Aurora Audit Bot remains idle / Beacon Deploy Bot completed"，status_correct = 0.0。

2.bots_not_mentioned：绝不提及两个 bot

同时满足三个条件才得 1.0：

len(bot_pubkeys) == 2 # 目录中两个 bot 都必须存在 all( set(row.get("mentioned_pubkeys", [])).isdisjoint(bot_pubkeys) # 无 p 标签 and not any(f"@{name}" in str(row.get("content", "")) for name in BOT_NAMES) # 无 @Name for row in candidates )

• bot_pubkeys来自证据中的directory，按名字Aurora Audit Bot/Beacon Deploy Bot查得——说明 bot 公钥由环境目录注入，判分器只认协议证据；
• mentioned_pubkeys是消息p标签的提取结果（详见下文证据契约）；
• 只要任一候选消息给任一 bot 加了p标签，或正文出现@Aurora Audit Bot/@Beacon Deploy Bot字样的唤醒文本，该维度即归零。注意这里检查的是"候选消息"（orchestrator 发出的全部消息），因此中途误唤醒一次也会被揪出。

3.user_mentioned：人类必须收到回调提及

user_mentioned = float(user.get("pubkey") in mentioned)

mentioned取自最终消息的mentioned_pubkeys。也就是说：bot 可以不被提及，但发起请求的人类（身份名Maya Elise Chen）必须在最终消息中被p提及——这是 "callback mention" 的协议落地。

4.reply_to_thread：回复必须落在原线程

reply_to_thread = float(final is not None and final.get("reply_to_event_id") == root)

最终消息的reply_to_event_id（即证据顶层task_event_id）必须等于任务事件 ID。若 Agent 把答案发成新的顶层消息而非线程内回复，则得 0。这与数据集里reply-to-thread任务守卫的是同一契约。

5.evidence_complete：证据本身必须完整可信

evidence.get("schema_version") == 1 and evidence.get("task_name") == "narrative-agent-names" and evidence.get("truncated") is False and len(agents) == 1 # 恰好一个 orchestrator and len(directory) == 2 # 目录恰好两个 bot and final is not None and len(candidates) == 1 # orchestrator 恰好发了一条消息

注意len(candidates) == 1：orchestrator 只允许发一条最终消息，多一条都会被判证据不完整。

6.reward：全维满分才给分

reward = float(all(value == 1.0 for value in (status_correct, bots_not_mentioned, user_mentioned, reply_to_thread, evidence_complete)))

无部分得分，五个行为维度 + 证据维度全绿才得 1.0，任何一个维度失败整体归零。

证据契约：判分器看到的是"归一化后的中继快照"

判分器读到的buzz-evidence.json并非原始中继数据，而是由评测框架 evidence.py 生成的版本化证据契约（schema_version = 1）。其核心归一化逻辑：

"mentioned_pubkeys": [ tag[1] for tag in tags if len(tag) >= 2 and tag[0] == "p" ], "reply_to_event_id": _tag_value(tags, "e", "reply"), "channel_id": _tag_value(tags, "h"),

• mentioned_pubkeys是从消息tags中提取的所有p标签第二元素——这正是"被提及者"的协议级事实来源，签名标签本身也被保留为tags字段供深层核查；
• reply_to_event_id只认带reply标记的e标签（["e", id, "", "reply"]）；
• 该模块还显式声明：私钥与认证标签刻意不出现在证据中，导出的身份只包含中继上本就可见的公开名称、角色与公钥；
• 消息按created_at排序后进入messages，顶层同时给出task_name、task_event_id、message_count、truncated（当原始消息数达到转录上限时为True，此时判分直接失败）。

测试夹具如何构建"完美证据"与"对抗证据"

判分逻辑的正确性由 test_expanded_buzz_native_verifiers.py 中的test_narrative_agent_names_do_not_wake_bots守卫。夹具构造一条符合预期的回复：

content = "Aurora Audit Bot completed the audit.\nBeacon Deploy Bot remains idle." evidence["messages"] = [_message("answer", content, mentions=[USER])]

断言六项全为 1.0 后，依次构造三个对抗场景验证归零逻辑：

1. 追加 bot 的p标签：mentioned_pubkeys.append(bot_a)→bots_not_mentioned = 0.0；
2. 发一条唤醒消息：@Aurora Audit Bot please check（带p标签）后再发正确答案 →bots_not_mentioned = 0.0且reward = 0.0——说明判分器会扫描 orchestrator 的全部候选消息，一次误唤醒即告失败；
3. 状态颠倒：两个 bot 的状态互换 →status_correct = 0.0。

协议层支撑：p标签与@Name在 Buzz 中的真实语义

为什么"叙述性名称"与"提及"的边界如此重要？答案在生产基础提示词 base_prompt.md 的提及规则中：

When you know intended recipient pubkeys, send readable@Nametext and pass the identities separately in the same command:buzz messages send ... --content "@Name ..." --mention <hex-or-npub>. Repeat--mentionfor multiple recipients. Any explicit identity (--mentionornostr:npub...) permits unresolved or ambiguous@Nametext as presentation-only; uniquely resolved member names still add their own recipients. Include a pubkey for every presentation-only name that should notify. The success JSON'smention_pubkeyscomes from the signed event and is the delivery evidence...

Without--mention, the CLI resolves@Nameagainst current channel members. It stops before sending on an unresolved/ambiguous name or a mentioned pubkey that is not a member...

从中可以提炼出 Buzz 的两条协议事实：

• 提及 =p标签，是事件级投递证据：在 Nostr 协议模型中，p标签（pubkey 引用）才是"通知谁"的权威载体；CLI 成功返回中的mention_pubkeys来自已签名事件，而不是来自正文解析；
• @Name是否"唤醒"取决于是否有--mention：显式传--mention <hex-or-npub>时，@Name仅作展示文本（presentation-only），真正的通知目标由显式身份决定；而不带--mention时，CLI 会按频道成员解析@Name并各自追加为收件人——这正是本任务要求"绝不写@Name、绝不加p标签"的协议原因：两个 bot 名字若写成@Aurora Audit Bot且未被显式身份"吸收"，就会被解析为真实提及从而唤醒 bot。

由此，"叙述性名称不唤醒"的本质是：普通叙述文本不产生任何p标签（也不触发@Name成员解析），只有显式的提及语法才产生协议级通知。判分器检查mentioned_pubkeys与@Name字面量，正是从协议事实与正文两个层面双重确认这一契约。

运行该回归评测：just benchmark一键路径

评测必须通过 harbor-buzz-orchestra 这一专用框架运行，它会启动真实的buzz-acp → buzz-agent → buzz-dev-mcp进程树，并在任务容器结束后把中继快照导出为buzz-evidence.json供判分器使用。数据集 README 明确提示：直接harbor run或harbor run -a oracle均不可行（本任务不携带solution/solve.sh，Oracle Agent 会替代 Buzz Agent，无法提供中继试验）。

在仓库根目录运行单任务回归（--attempts/-k缺省时由任务元数据给出 k=1）：

just benchmark \ --path benchmarks/buzz-dataset/narrative-agent-names \ --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

运行要点：

• 默认条件是 buzz-native-solo-luna.yaml 中声明的单个 orchestrator（kind: orchestrator、role: solo、count: 1），模型为gpt-5.6-luna，thinking_effort: medium，max_output_tokens: 4096、context_window_tokens: 200000。该清单注释强调："本套件评的是基础提示词带来的 Buzz 产品行为，而非模型强度——便宜模型配中等思考力度才是正确标尺，弱结果说明的是提示词问题而非模型问题"；
• 需要OPENAI_COMPAT_API_KEY，且必须显式传--endpoint-config（其默认值是anthropic-live.json，对应 Sonnet 条件，需ANTHROPIC_API_KEY；Sonnet 对比条件见 buzz-native-solo-sonnet.yaml）；
• just benchmark会自动跨编译 Linux 静态二进制（buzz_acp_binary、buzz_agent_binary、buzz_dev_mcp_binary需与任务镜像架构一致），并搭建独立的buzz-benchmarkDocker 栈（relay:3600、Postgres:5633）；
• 每次 trial 使用全新密钥与私有频道，结束时频道被归档而非删除，中继/Postgres 事件时间线与各 Agent 日志（下载至 trial 的buzz/产物）可供事后分析；
• 证据快照若导出失败，trial 直接判为失败而非 0 分——框架故障与模型故障被刻意区分，原因写入buzz/buzz-evidence-error.txt。

如需按评估层批量运行，可用数据集根的层选择器：

just benchmark --path benchmarks/buzz-dataset --layer regression # 全部回归任务，k=1 just benchmark --path benchmarks/buzz-dataset --layer workflow # 全部工作流任务，k=3

测试与校验链路：从 fixture 到容器的三重保障

判分器并非只在本任务内自证，仓库为其建立了完整测试链路：

1. 快速 fixture 测试：test_expanded_buzz_native_verifiers.py 直接加载本任务的verify.py并构造正/反例证据，验证判分逻辑本身——它们是普通 CI，不代替跨模型、基础提示词、CLI 与中继的 Agent trial（见 buzz-dataset/README.md 的说明）；
2. 容器化执行：任务环境是极简 Python 镜像（environment/Dockerfile，基于python:3.12-slim-bookworm），测试入口 test.sh 调用python3 /tests/verify.py --evidence /logs/artifacts/buzz-evidence.json --reward /logs/verifier/reward.json --details /logs/verifier/details.json，把六维指标与详情分别落盘；
3. 证据导出契约：由 evidence.py 生成，版本号、身份白名单、p/e/h标签提取与截断标志共同保证判分器拿到的数据稳定且可复现。

小结：一条可复现的"不误唤醒"产品契约

narrative-agent-names演示了 Buzz 平台如何把一条精细的协议契约（叙述文本不产生协议级提及；只有显式p标签或@Name解析才唤醒收件人）转化为可确定性判分的回归评测：instruction.md只给普通状态汇报任务，行为约束由 base_prompt.md 从生产侧保证，verify.py用六个 0/1 维度（状态正确、不提及 bot、回调人类、线程内回复、证据完整、总分）从协议证据与正文两个层面严格把关，而 fixture 测试与 harbor 框架则确保判分器本身可信、运行方式可复现。理解这条链路，你不仅能在 Buzz 上正确地"在叙述中提及 Agent"，也能举一反三地读懂数据集内其余九项产品行为评测的设计思路。

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