DeepSeek-Reasonix 评测实战：读懂 eventlog 追加式事件日志包，从 README 到验证闭环

DeepSeek-Reasonix 评测实战：读懂 eventlog 追加式事件日志包，从 README 到验证闭环

【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix

本指南围绕 DeepSeek-Reasonix 仓库内benchmarks/e2e/tasks/integrate-eventlog任务中提供的eventlog本地 Python 包展开：先精读其 README 与源码，掌握 append-only 事件日志的设计语义，再沿着该任务的 prompt、种子数据与verify.sh评分脚本，完整还原"按文档集成本地包"的评测闭环。读完本文，你将理解这类api-integration评测任务的出题思路、评分约束，以及如何写出能一次性通过验证的rebuild.py。

eventlog 包是什么：一个带序列号的追加式事件日志

eventlog是一个极简的 Python 包，定位为append-only event log with sequence numbers（带序列号的追加式事件日志）。它的完整说明位于 eventlog/README.md，核心 API 只有三个成员：

from eventlog import Log log = Log("events.log") log.append(kind, name) # writes "<seq> <kind> <name>" with seq starting at 1 log.count() # entries appended through this Log instance

三个要点构成了这个包的契约：

1. 追加式（append-only）：日志文件只会在末尾追加新行，Log.append内部以"a"模式打开文件，不会覆盖、不会重排已有内容；
2. 序列号从 1 开始：每一行以<seq>开头，第一条记录的序列号是1，之后逐条递增；
3. 行格式固定："<seq> <kind> <name>"，三个字段以单个空格分隔，行尾带换行符。

从 README 到源码：确认实际写入行为

README 只给出了使用示例，而实际的写入细节在 eventlog/init.py 中实现。整个包的源码仅有十余行：

class Log: """See README.md; append writes "<seq> <kind> <name>" lines, seq from 1.""" def __init__(self, path): self.path = path self._seq = 0 def append(self, kind, name): self._seq += 1 with open(self.path, "a") as f: f.write(f"{self._seq} {kind} {name}\n") def count(self): return self._seq

对照源码可以确认几个关键行为：

• __init__(path)仅保存路径并把内部计数器_seq置 0，不会立即创建或清空文件；
• append(kind, name)先自增_seq再追加写行，因此第一条写入的序列号必然是1，与 README 声明一致；open(..., "a")的追加模式保证了不会破坏文件已有内容；
• count()返回self._seq，即通过当前 Log 实例调用append的次数，而非文件中的总行数——这是 README 中 "entries appended through this Log instance"（通过该实例追加的条目数）的精确含义。

由源码结构还可以推断两点使用边界（README 未直接说明）：其一，序列号完全由实例内存中的计数器驱动，如果多个Log实例（或多次进程运行）写同一个文件，后一个实例不会感知文件里已有的行数，序列号可能不与文件中实际行数对应；其二，追加写入没有加锁与并发保护，适合单写者顺序写入的场景。评测任务正是利用了"单进程、顺序追加"这个前提，让输出具有完全确定性。

实战场景：integrate-eventlog 评测任务全貌

这个 README 并非孤立文档，它是 DeepSeek-Reasonix 端到端评测套件（benchmarks/e2e/）中一个api-integration类任务的种子资料。任务定义见 task.toml：

prompt = "This directory contains an eventlog/ package with a README, plus raw.txt holding one `kind name` pair per line. Create rebuild.py so that `python3 rebuild.py` appends every raw.txt line, in order, to a Log at path events.log using the package. Do not write events.log by hand." class = "api-integration" max_steps = 20 timeout_sec = 300

任务结构由三个文件构成，这正是 benchmarks/README.md 描述的每个任务的标准形态：

种子数据 raw.txt

workdir/raw.txt 是待回放的原始事件，每行一个kind name对：

deploy harborlight rollback harborlight deploy mistgate audit quaywall

结合 prompt 的要求，"rebuild.py" 的名字已经暗示了语义：把 raw.txt 里的每一行按顺序追加进Log，相当于从原始记录重建一份带序列号的事件日志。

预期输出：把规则落到实处

将 raw.txt 的 4 行依次送入log.append(kind, name)，由于序列号从 1 递增，最终events.log应精确等于：

1 deploy harborlight 2 rollback harborlight 3 deploy mistgate 4 audit quaywall

这就是 README 中"<seq> <kind> <name>"格式与"seq starting at 1"的直接落地。

verify.sh：评分脚本如何验证集成质量

评分脚本 verify.sh 完整定义了"什么算通过"：

#!/usr/bin/env bash set -e export PYTHONPYCACHEPREFIX="$(mktemp -d)" rm -f events.log python3 rebuild.py diff events.log - <<'WANT' 1 deploy harborlight 2 rollback harborlight 3 deploy mistgate 4 audit quaywall WANT grep -q "eventlog" rebuild.py || { echo "rebuild.py must use the eventlog package" >&2; exit 1; }

它可以拆成四道关卡：

1. 环境净化：PYTHONPYCACHEPREFIX="$(mktemp -d)"把 Python 字节码缓存重定向到一次性临时目录。这是 benchmarks/README.md 中明确要求的 Python 评测脚本开头规范——macOS 系统 Python 按绝对路径集中缓存字节码，如果 agent 的修改保持了文件大小且在同一个 mtime 秒内，旧字节码可能被继续执行，traceback 却显示新源码，从而造成误判；
2. 干净起点：rm -f events.log确保评分时不存在手工预置的文件，杜绝"伪造日志"过关；
3. 精确比对：python3 rebuild.py后，用diff把events.log与期望的 4 行内容逐字节比对——序列号、空格、顺序、行尾都不能有偏差；
4. 强制使用包：grep -q "eventlog" rebuild.py检查脚本中出现了eventlog字样，确保 agent 是调用提供的包而非自行重造轮子。这与 prompt 中 "using the package"（以及do not write events.log by hand）互相呼应。

按照 benchmarks/README.md 中 "verify.sh contract" 一节的约定，verify.sh在 agent 运行结束后才被评测框架复制进临时工作目录，因此 agent 在运行过程中永远读不到答案；脚本以set -e运行，退出码 0 即通过。这套"种子数据 + 隐藏评分器 + 精确保留断言"的机制，保证了评分无法被提示词泄露。

参考实现：一份能一次通过的 rebuild.py

根据上述契约，一份合规的rebuild.py可以这样写（这是对任务的解法说明，仓库中并未提交该文件）：

from eventlog import Log log = Log("events.log") with open("raw.txt") as f: for line in f: line = line.strip() if not line: continue kind, name = line.split(" ", 1) log.append(kind, name)

逐条对照评分要求：

• from eventlog import Log满足grep -q "eventlog" rebuild.py的检查，且workdir/被整体复制进临时运行目录，同目录下的eventlog/包可直接导入；
• 按 raw.txt 的行序逐行append，与diff期望的1 deploy harborlight到4 audit quaywall精确一致；
• 全程没有手写events.log，文件内容完全由Log.append以追加模式产生；
• 脚本在python3 rebuild.py下可直接执行，不需要命令行参数。

在评测体系中的位置：api-integration 任务类

integrate-eventlog只是 DeepSeek-Reasonix 评测语料中api-integration类的一个样本。根据 benchmarks/README.md 的分类表，该类定位为"use a provided local package per its README"（按 README 使用给定的本地包），目标 4 个、已提交 4 个，与该任务同类的还有：

• integrate-backoff：按backoff包 README 中的next_delay生成绝对重试时间戳，且不得重新实现调度；
• integrate-kvstore：用kvstore包的事务 API 把legacy.json迁入store.json，且所有 put 必须在恰好一次commit 内完成（评分脚本会数store.json.commits的行数是否为 1）；
• integrate-ratelimiter：用ratelimit包的TokenBucket（capacity 3、refill_per_sec 1）过滤事件时间戳，且不得自行实现桶。

这类任务的共同设计意图是：评测 agent 是否真的读懂了给定包的 README 与 API 语义，而不是凭直觉重写一个行为相近的实现。因此每个任务的 prompt 都明确要求 "Use the package — do not reimplement"，评分脚本（如grep "eventlog"、统计 commit 次数）也会从产物层面验证这一点。

任务运行层面，评测框架通过cmd/e2ebench（见 cmd/e2ebench/main.go）调用reasonix run --auto --metrics <path> [--model NAME] [--max-steps N] [--profile delivery] [--ablate ARM] <prompt>，在任务workdir/的临时副本中执行，--auto标志允许无人值守地写入夹具文件。运行单个任务的命令为：

go run ./cmd/e2ebench -task integrate-eventlog

小结：从一份 README 到一条可验证的集成路径

eventlog的 README 虽然只有几行，却与源码、任务 prompt、种子数据、评分脚本共同构成了一条完整的闭环：README 定义 API 契约（序列号从 1 开始、追加式、行格式），源码给出可验证的实现细节，task.toml把"按文档集成"翻译成可执行的 prompt，raw.txt提供确定性的输入，而verify.sh用逐字节比对与包引用检查保证 agent 真正按文档行事。理解这条链路，也就理解了 DeepSeek-Reasonix 评测体系中api-integration类任务"以文档为契约、以源码为佐证、以脚本为裁决"的完整设计思想——这正是其 benchmarks/README.md 强调的"grader authoring rule"：每个任务必须在原始种子上失败、在参考解上通过。

【免费下载链接】DeepSeek-ReasonixDeepSeek-native AI coding agent for your terminal. Engineered around prefix-cache stability — leave it running.项目地址: https://gitcode.com/GitHub_Trending/de/DeepSeek-Reasonix