Buzz 冷记忆检索基准任务剖析从buzz mem set播种到精确数字验证器【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz导读memory-retrieval是 Buzz 开源仓库benchmarks/buzz-dataset中一组「Buzz 原生buzz-native」回归基准任务之一它检验的核心能力是当问题的答案只存在于 agent 自己的冷记忆cold memory中、而频道对话历史完全不包含该信息时agent 能否通过检索记忆工具拿到唯一正确的精确值。本文以该任务的 README 为骨架结合仓库中的任务声明、harness 播种逻辑、验证器源码与测试用例完整讲解任务设计、播种机制、评分规则与运行方式帮助读者理解 Buzz 如何把「记忆检索」这一产品行为变成可自动判分的回归测试。任务一句话定义按 task.toml 的声明任务的规范名是buzz-native/memory-retrieval描述为 Answer a question using a harness-seeded cold-memory rule.即仅凭 harness 预先播种的冷记忆规则来回答问题。任务的元数据进一步明确了它在评测体系中的位置字段值含义metadata.evaluation_layerregression回归层检验 Buzz 是否守住了某个已知产品契约metadata.difficultyhard难度标定metadata.categorycollaboration协作类场景keywordsbuzz-native / agents / memory / retrieval检索主题标签agent.timeout_sec300.0agent 求解时限 5 分钟verifier.timeout_sec30.0验证器执行时限 30 秒environment.network_modepublic允许公网访问agent 需要连接远端模型端点environment.cpus / memory_mb / storage_mb1 / 1024 / 1024容器配额1 核、1 GiB 内存、1 GiB 存储与buzz-dataset中其他任务一致回归层默认只跑 1 次试验k1用于定向 PR、nightly 或预发布检查评估层信息见 benchmarks/buzz-dataset/README.md 的「Evaluation layers」小节。任务运行环境任务容器由 environment/Dockerfile 定义极其精简FROM python:3.12-slim-bookworm WORKDIR /app容器内部只预置 Python 3.12 运行时并不预装答案、不预置任何记忆。agent 实际运行的buzz-acp→buzz-agent→buzz-dev-mcp技术栈由 harbor-buzz-orchestra harness 在试验启动时注入这一点是理解整个任务的前提记忆不是任务环境的「文件」而是通过 Buzz 自身的 engram记忆协议写入的。冷记忆播种机制harness 如何「喂」记忆任务 README 开门见山地说明了播种方式Before the agent starts, the harness runsbuzz mem setwith the agents own Buzz credentials to seed five similar cold memories.也就是说在 agent 启动之前harness 使用 agent 自己的 Buzz 凭据执行buzz mem set命令写入五条高度相似的「冷记忆」。所谓冷记忆cold memory指的是写入后不主动暴露、需要 agent 主动检索才能发现的记忆——它的存在和内容都不会出现在任何频道消息里。五条记忆的精确内容播种数据的声明位于 harness 的 task_fixtures.py 中_MEMORY_RETRIEVAL_FIXTURE共 5 条全部以MemorySeed(slug, value)结构写入slug内容value角色total-customers-per-monthWe average 361,250 customers per month.干扰月度均值 361,250customer-value-metricLast month we had 351,340 customers with a $2400 revenue per customer干扰上月客户数 351,340、每客户收入 2,400customers-metrics-spring-24In March, we had 325,401 total customers. In April, we had 3,710 active customers named John.干扰三月总数 325,401、四月名为 John 的活跃客户 3,710new-customers-april-2024There are 21,604 new customers in April 2024.干扰四月新增客户 21,604total-customers-metricIn April 2024, we had 352,345 total customers.正确记忆352,345注意最后一条的措辞——它虽然也叫total-customers-*开头但唯一完整回答「2024 年 4 月总客户数」的记忆只有total-customers-metric而另外四条记忆分别混淆了「均值」「上月」「三月」「新增」等维度。agent 必须逐个检索、逐条甄别不能「一揽子倾倒」全部记忆。MemorySeed数据类的定义在同一文件头部dataclass(frozenTrue, slotsTrue) class MemorySeed: A cold-memory value seeded under the orchestrators identity. slug: str value: str其 docstring 强调播种目标身份是orchestrator协调者agent这与验证器只认 orchestrator 发布答案的规则一一对应。_seed_memories的执行细节播种动作由 container_runtime.py 的_seed_memories方法完成核心调用链为buzz mem set seed.slug - 值通过 stdin 传入 环境变量 BUZZ_RELAY_URL → 本次试验的 relay WebSocket 地址 BUZZ_PRIVATE_KEY → agent 的 nsec 私钥 BUZZ_AUTH_TAG → NIP-OA 认证标签携带 owner pubkey关键点-表示从 stdin 读取值seed.value.encode()作为子进程 stdin 写入避免命令行泄露记忆内容。使用 agent 自己的凭据BUZZ_PRIVATE_KEY是 orchestrator 的 nsec因此写出的记忆归属该 agentagent 启动后能以自身身份读取。失败即熔断若任一 seed 写入返回非零码harness 抛出RuntimeLaunchError试验直接失败不会带着残缺记忆继续跑。buzz mem set的 CLI 实现buzz mem是 buzz-cli 提供的「agent 侧 engram 管理」命令族实现于 NIP-AE 协议子命令作用buzz mem ls列出未被 tombstone 的记忆buzz mem get slug输出某个记忆的明文值buzz mem hash slug输出sha256(value)十六进制buzz mem set slug value\|-写入记忆-从 stdin 读buzz mem patch slug对当前值应用 unified diffbuzz mem rm slug发布 tombstone 删除记忆cmd_set的实现细节mem.rs 中cmd_set值得关注slug 规范化normalize_slug校验并规范化 slug非法 slug 直接返回用法错误stdin 长度上界stdin 读取被限制在NIP44_PLAINTEXT_MAX 1字节超出 NIP-44 明文上限即报错防止上游产生失控数据导致 OOM空值保护stdin 读到空串时默认拒绝写入除非显式传--allow-empty用于拦截「上游管道失败 → 悄悄写空值毁掉 slug」的常见事故模式单调时间戳monotonic_created_at(now_secs(), prior_created_at)保证新事件时间戳严格大于旧 head配合 relay 的 NIP-33 LWW 判定submit_engram会把 relay 回复中duplicate:前缀视为冲突确保写入被权威接受。禁用自动记忆注入memory-retrieval 任务还有一个特殊环境约束harness 会设置BUZZ_ACP_NO_MEMORYtrue这一行为由 test_container_runtime.py 的test_memory_task_disables_auto_memory_injection测试锁定——该测试断言memory-retrieval任务的 agent 环境里BUZZ_ACP_NO_MEMORY true且频道列表固定为单个 channel。这背后的设计意图是关闭 buzz-acp 的自动记忆注入强制 agent 走显式的buzz mem ls/get检索路径从而让「主动检索工具」成为得分的唯一通道。如果允许自动注入agent 可能在系统提示中直接「看到」记忆任务就测不到检索能力了。提问环节答案绝不外泄播种完成后harness 把 instruction.md 交付给 agent全文只有一句话How many total customers did we have in April 2024?这句话刻意做到了三点不含答案352,345不在其中不暴露记忆 slug提问没有暗示应该查total-customers-metric还是其他total-customers-*记忆不携带任何数字线索除了问题本身没有任何可让 agent 少检索一条记忆的提示。同时harness 不会向频道注入任何包含答案的消息因此 agent 的对话历史里搜不到正确答案——「从聊天记录里抄答案」的捷径被彻底封死。测试 test_expanded_buzz_native_verifiers.py 的test_memory_retrieval_answer_exists_only_in_harness_seed专门做了交叉验证断言352,345只出现在total-customers-metric一条 seed 中、不出现在instruction.md并且验证器的DISTRACTOR_NUMBERS恰好等于从四条干扰 seed 中解析出的全部数字集合。这意味着任何「正确」数字只可能来自那条唯一的正确记忆。验证器只看可观察答案不检查工具调用任务 README 特别强调The verifier does not inspect tool calls: seeding is deterministic harness setup, and retrieval is graded only through the observable answer.即验证器不关心 agent 调用了什么工具、调了几次——播种是确定性的 harness 准备动作检索行为只通过最终答案来判分。判分入口在 tests/test.sh#!/bin/sh set -eu mkdir -p /logs/verifier python3 /tests/verify.py --evidence /logs/artifacts/buzz-evidence.json --reward /logs/verifier/reward.json --details /logs/verifier/details.json它读取 harness 导出的 relay 快照buzz-evidence.json写出机器可读的reward.json与人类可读的details.json。评分公式核心函数score_evidenceverify.py输出四个指标并组合成总分reward answer_correct × structural_score structural_score threaded_reply × evidence_complete指标判定条件answer_correct答案中出现352,345且除年份2024外没有出现任何其他数字threaded_reply存在一条 orchestrator 发布、位于问题频道、reply_to_event_id指向问题事件的消息evidence_complete证据schema_version 1、task_name memory-retrieval、未截断、恰好 1 个 orchestrator 身份、问题事件 ID 与频道 ID 均为字符串reward上述三项的乘积三者任一为 0 则总分为 0数字提取与格式宽容verify.py用正则(?![A-Za-z0-9_])-?\d[\d,]*(?:\.\d)?从答案文本中提取所有数字再去掉千位分隔符后转成浮点比较。因此接受等价的逗号无关格式352,345与352345得分完全一样不接受任何近似About 352 thousand、Approximately 352.3 thousand、352,000、甚至352,344/352,346都会判answer_correct 0不接受掺杂干扰数字即使答案同时给出352,345和任何DISTRACTOR_NUMBERS集合内的数字361_250、351_340、2_400、325_401、3_710、21_604也会因noise_numbers非空而判零分唯一的白名单例外2024问题中明确要求的年份可以出现。DISTRACTOR_NUMBERS的定义带注释说明设计动机「说出任何干扰数字意味着答案取自错误的记忆或倾倒多条记忆无法证明选对了正确值」。结构化惩罚线程化回复是硬门槛即使数字正确如果回答不是线程化回复reply_to_event_id未指向问题事件threaded_reply 0总分同样为 0。这条规则与 buzz-dataset 的reply-to-thread任务共享同一产品契约——Buzz 要求 agent 在提问者的线程内回答而不是另起一条顶层消息。测试套件评分逻辑被逐条锁定仓库用 pytest 把验证器的每个判定分支都固化成回归测试见 test_expanded_buzz_native_verifiers.pytest_memory_retrieval_requires_correct_threaded_answer三种合法格式352,345、带句子的完整回答、无逗号的352345全部得满分十一种错误答案六条干扰数字 352,344、352,346、352,000、About 352 thousand、Approximately 352.3 thousand全部零分正确答案 任一干扰数字的组合 →mentions_distractorTrue零分正确答案 非干扰噪声如352,000、999,999→noise_numbers非空零分数字正确但reply_to_event_id指向错误问题 →threaded_reply与reward双零。harness 侧播种行为也有专门测试test_container_runtime.py 的test_memory_seed_uses_agent_credentials_and_stdin断言对每条 seed 都以(mem, set, seed.slug, -)调用 CLI、传入 agent 的BUZZ_PRIVATE_KEY、stdin 写入的正是seed.value的字节串。如何运行本任务memory-retrieval属于 buzz-native 任务必须借助 harbor-buzz-orchestra harness 运行普通harbor run无法工作且没有solution/solve.sh不能跑 Oracle agent。仓库根目录下的标准入口是just benchmark以同目录下的reply-to-thread为例的命令格式为替换 path 为本任务目录即可just benchmark \ --path benchmarks/buzz-dataset/reply-to-thread \ --manifest benchmarks/harbor-buzz-orchestra/manifests/buzz-native-solo-luna.yaml \ --endpoint-config benchmarks/harbor-buzz-orchestra/testbed/endpoints/openai-live.json \ --n-concurrent 1manifest 声明 agent 阵容单 orchestrator 的 solo 配置endpoint-config 声明 LLM 端点harness 负责播种记忆 → 投递instruction.md→ 启动 agent 容器 → 导出 relay 证据 → 调用验证器写回奖励与明细。设计要点总结从本任务可以提炼出 Buzz 对「可判分的产品行为测试」的几条设计原则答案只存在于冷记忆把正确答案放入 agent 私有记忆频道历史与提示文本均不含答案杜绝「抄对话」的旁路得分路径干扰记忆与正确答案同构四条干扰记忆在主题、措辞、数值量级上与正确答案高度相似只有精确检索并比对才能选出唯一正确值精确匹配、拒绝近似352,345与352345等价但任何四舍五入、口头近似、或附带其他数字的答案都不得分把「找到正确记忆」与「复述一个大概值」严格区分开不检查工具调用只看可观察输出评分聚焦 agent 在 Buzz 中最终呈现的线程化回答既保持判分确定性与可审计性又避免把内部实现细节耦合进评测强制显式检索通过BUZZ_ACP_NO_MEMORYtrue关闭自动记忆注入确保只有「主动调用buzz mem ls/get检索」这一路径能获得记忆内容验证器与 harness 双侧测试锁定验证器的每个判定分支、harness 的每次播种调用都有 pytest 用例保护防止评分逻辑随代码演进悄悄漂移。这套设计让「记忆检索」这样一个抽象的产品能力落成了一个确定性、可复现、可自动判分的回归测试——这也是 buzz-dataset 中全部任务的共同方法论表面是普通问题实际考的是 agent 在 Buzz 里的行为契约。【免费下载链接】buzzA hive mind communication platform项目地址: https://gitcode.com/GitHub_Trending/buzz14/buzz创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考