# Agent-Benchmark：已确认决策与待确认问题

更新日期：2026-10-02

阶段：SPEC/PLAN/TASK 与 T-001–T-011 已完成；含原生 dsh 接入、官方配对实验及 PawBench 一个可运行子集。工程验收与模型解题成绩分开，见 RESULTS。

用户选择机制研究优先（D-010），要求以 Codex 策略比较为目标先设计再开发（D-011），随后提供 DeepSeek 官方服务并要求完成后续内容（D-012）。本轮两组、预算、任务与外部子集已按可逆工程默认冻结。以下四组/五组及 Q 表保留为长期候选，不代表当前交付仍被这些访谈问题阻塞。

## 1. 项目目标

基于 DeepSeek Harness（下称 dsh），复用其 Agent 运行能力，横向比较不同机制对 Agent 性能的影响。例如固定模型、工具和任务，仅替换上下文管理机制，在 benchmark 上比较效果。

项目需要支持可解释、可复现的实验，而不只是给出不同 Agent 的总分排名。

## 2. 已确认决策

| ID | 决策 | 确认依据与边界 |
| --- | --- | --- |
| D-001 | 定位为 dsh 生态中的实验与评测扩展，结合通用开源项目的设计 | 用户选择“dsh + 通用开源项目调查”，希望加入 dsh 生态并补充社区能力。具体包结构、插件与独立运行器的边界尚待确认。 |
| D-002 | 设计前先调查已有项目与 dsh 插件，避免重复建设 | 用户明确要求先调研 GitHub 与 dsh 生态。当前调查仅为初步调查，不能据此认定社区没有同类项目。 |
| D-003 | 吸收 PawBench、Harness-Bench 等项目的优秀设计 | 用户明确要求；具体复用内容、接口、许可及代码来源需要进一步核实。 |
| D-004 | 在 README 末尾声明设计来源与致谢 | 用户明确要求；该要求不替代复用代码或数据时需要保留的许可证与版权声明。 |
| D-005 | 采用两层评测体系 | 用户选择 A：自建受控任务集为主，PawBench/Harness-Bench 为外部适配与对照。外部适配的具体深度尚待确认。 |
| D-006 | SWE-bench 暂不作为首个主基准 | 属于用户接受的两层方案；后续是否支持它仍待讨论。 |
| D-007 | 按 SDD 顺序完成文档 | 依次完成细节确认、SPEC 规范文档、PLAN 计划文档、TASK 原子任务文档。 |
| D-008 | 设计完成前不编写实现代码（历史阶段要求） | 用户此前要求先完成设计；已按顺序完成三份文档，本轮 D-011 授权进入实现。 |
| D-009 | 使用指定 GitHub 仓库保存项目 | 用户指定 `git@github.com:cuguanren/Agent-Benchmark.git`，并授权推送本次整理的项目。 |
| D-010 | 首版以机制研究为主要验收 | 用户在首版验收问题中选择 A：完成可复现的上下文策略对比，解释成功率、成本及失败差异。通用开发工具和外部基准复现不作为首版的主要验收目标；不因此取消已确认的两层评测方向。该选择不自动确认实验组数、CLI/UI 形态、外部适配深度或资源预算。 |
| D-011 | 将 Codex 策略比较文档作为初期功能验证目标，完成 spec/plan/task 后开始开发 | 用户当前明确指令。初期实现 local-summary 与 window-reset，旧四组/五组选择不阻塞这一阶段；不代表冻结正式质量实验的模型、预算或任务集。 |
| D-012 | 使用 DeepSeek V4.1-Flash 官方 API，完成 T-009–T-011 | 用户指定服务并提供凭据、明确要求完成后续内容。实际 model ID deepseek-flash 已验证；不落盘凭据。有限预算、36 任务和 PawBench 单子集是实现默认，协议在首次付费调用前冻结；不扩展为完整排行榜、独立组件归因或任意费用授权。 |
| D-013 | 补齐 dsh 本地发布候选，源码采用 MIT | 用户要求审查生态发布质量后继续后续任务，并明确选择 MIT。实现 bundle、生命周期、安装验证与发布文档；版本 0.2.0-rc.1，不等同已上传 npm/社区目录。 |

实现默认：Node.js/TypeScript、串行 JSON CLI、本地恢复工具；Cordis 4.0.4/dsh 0.1.0-rc.8 原生组合；官方模型 thinking disabled、temperature 0。36 受控任务开发/评测分离、96 主评测 trial、两组共享 2M token 限额；PawBench 1 原任务 × 2 组。具体参数见 SPEC/ONLINE_PROTOCOL，属于已授权范围内的工程决定，不冒充用户逐项确认。PawBench 原评分器可运行，实际模型两组预算终止；所有失败保留，不重跑挑成功。

本轮已落实 Q-002 的插件+CLI、Q-005 的原生版本/接口、Q-007 的统一预算含摘要、Q-008 的官方模型、Q-009/Q-011/Q-012 的任务与独立评分/配对、Q-010 的一个许可明确子集、Q-013 的 Windows 工具环境、Q-014 的串行/有限期限、Q-015–Q-017 的原始轨迹和哈希。D-013 已确定 Q-019 的 MIT 与本地候选交付；实际发布、四组/五组独立归因及更广模型/环境仍为后续范围。

## 3. 已接受方向中尚未冻结的细节

两层评测方案中的下列内容是讨论时的建议，尚未形成可执行规范：

- 自建主评测集建议为约 30–50 个离线、可重复、带确定性验证器的任务；最终数量、分类与验收标准未定。
- 建议覆盖长上下文、信息召回、跨轮状态、噪声干扰、工具结果压缩、错误恢复和任务完成性；各类别的定义与配比未定。
- 外部兼容层可能复用任务、验证器、执行接口或结果格式；尚未确定具体交付内容，不能将“结果格式兼容”等同于“能够运行原始基准”。

## 4. 当前正在确认的问题：首批上下文管理机制

历史讨论提出以下候选，尚未冻结为正式质量实验；当前初期功能验证采用 D-011 指定文档中的两种 Codex 风格策略，四组/五组讨论留待后续归因实验：

| 候选 | 建议行为 | 需要澄清 |
| --- | --- | --- |
| Full History | 保留完整对话与工具轨迹；达到上下文上限时停止 | 超限属于实验结果还是运行错误；输入预算如何统一。 |
| Budgeted Truncation | 在 token 预算内保留固定提示与近期轨迹，裁剪较早内容 | 裁剪单位、工具调用与结果配对、是否保留关键结果及其选择规则。 |
| Structured Summary + Retrieval | 结构化摘要加历史片段检索 | 同时引入摘要和检索，无法单独归因两个机制；是否拆成独立实验组。 |

历史选项为：A. 采用上述三种；B. 第三种改为语义检索；C. 增加第四种。该轮未获回答，不再作为当前访谈选项；2026-10-02 用户选择的 A 对应 D-010 的首版验收目标，不对应这组历史机制选项。

需要先解决的方法问题：如果目标是识别单个机制的效果，建议考虑 Full History、Truncation、Summary Only、Summary + Retrieval 的分组，或明确第三组只评估组合策略。该建议尚未确认。

当前 B-002 的候选为：A. 四组策略比较（Full History、Truncation、Summary Only、Summary + Retrieval），接受检索增益仅在摘要条件下解释；B. 增加 Retrieval Only，并以统一的近期尾部、保留规则及资源分配形成无摘要/无检索、仅摘要、仅检索、摘要加检索的四个对照条件，Full History 另作参考。B 的独立贡献及交互结论仍取决于匹配的实验契约，增加一个组本身不保证可归因。尚未收到本题答案。

用户随后要求先对比 Codex CLI 的 TokenBudget 与本地压缩。源码核对见 [Codex 上下文策略比较](CODEX_CONTEXT_STRATEGIES.md)：前者是换窗与 Agent 主动 notes/history 恢复的组合，不能直接等同为 Truncation 或 Retrieval Only；后者是摘要调用与用户文本保留的组合。当前已据 D-011 进入这两种组合策略的功能验证开发，未据此确认其他质量实验组。

## 5. 后续待确认问题

以下是原访谈形成的长期扩展清单；本轮已确定的部分以 D-012 和现行 SPEC 为准。初期及后续三份文档和任务已完成，其中工程默认不代表用户认可所有远期扩展。

| ID | 主题 | 待确认内容 |
| --- | --- | --- |
| Q-001 | 主要用户与使用场景 | 已确认首版以机制研究实验为主要验收（D-010）；主要用户、完整工作流与具体交付物仍需收敛。 |
| Q-002 | 产品形态 | 纯 dsh 插件，或 dsh 插件加独立 CLI；是否需要嵌入 dsh Web UI，MVP 是否包含工作台。 |
| Q-003 | MVP 机制范围 | 是否只实现上下文管理对比；工具组织、规划、反思、记忆、循环、子 Agent 等是否仅预留扩展接口。 |
| Q-004 | 首批机制定义 | 实验组数量、各组算法、触发阈值、可配置参数，以及摘要与检索的归因边界。 |
| Q-005 | dsh 集成方式 | 固定的版本或 commit、扩展点、生命周期、是否避免修改上游源码、支持的运行模式。 |
| Q-006 | 实验控制 | 固定模型、提示词、工具、任务环境与采样参数的方法；允许变化的字段及配置校验。 |
| Q-007 | 预算公平性 | 上下文窗口、累计 token、输出 token、工具调用、时长和金额限制；摘要与检索开销是否计入总预算。 |
| Q-008 | 模型与服务 | 首个模型与提供商、OpenAI-compatible 接口支持、模型版本记录及摘要模型的选择。 |
| Q-009 | 主评测任务 | 任务领域、数量、难度、上下文压力分档、生成方式、人工审查、开发集与评测集划分。 |
| Q-010 | 外部基准适配 | PawBench/Harness-Bench 的真实仓库、许可、任务与验证器可用性；MVP 优先适配哪一个及适配深度。 |
| Q-011 | 验证与评分 | 确定性验证器优先级；是否允许 LLM judge、如何校准；最终成功、过程质量与失败分类。 |
| Q-012 | 统计协议 | 每任务重复次数、配对实验、任务顺序、置信区间、显著性或效果量，以及结论的适用范围。 |
| Q-013 | 执行环境 | 本地与 Docker 支持、平台要求、环境快照、每次运行隔离、联网任务策略。 |
| Q-014 | 批量运行 | 并发、限流、超时、取消、重试、断点续跑；区分基础设施失败和 Agent 失败。 |
| Q-015 | 数据与轨迹 | 配置、模型请求、上下文变化、工具轨迹、产物与验证结果的 schema；脱敏与凭据过滤。 |
| Q-016 | 分析与导出 | 成功率、成本、时长、token、机制触发频率等指标；任务切片、配对差异与报告格式。 |
| Q-017 | 实验可复现性 | 版本锁定、任务与配置哈希、随机种子支持边界、缓存策略、结果清单与复现命令。 |
| Q-018 | 实施约束 | 人力、时间、API 费用预算、可用硬件及首版验收时间。 |
| Q-019 | 开源交付 | 项目名称、许可证、发布渠道、文档语言、示例实验、贡献规则与社区插件登记。 |
| Q-020 | SDD 文档验收 | SPEC/PLAN/TASK 文件位置、需求编号、追踪关系、每个原子任务的输入输出与完成判据。 |

## 6. 初步调研记录与证据边界

| 来源 | 当前观察 | 下一步核实 |
| --- | --- | --- |
| [DeepSeek Harness 官方介绍](https://www.deepseek.com/harness/en/) | 官方将模型、工具、会话、存储、循环、沙箱与 UI 等描述为插件能力，并强调轨迹记录。 | 阅读当前源码与开发文档，核实上下文替换接口、批量执行及计量能力。 |
| [DeepSeek Harness 源码](https://github.com/deepseek-ai/deepseek-harness) | 目标上游项目。 | 固定版本，检查许可证、内置机制与现有评测目录。 |
| [dsh.pub 社区目录](https://dsh.pub/en/) | 初步浏览看到了工具、UI、自动化等插件。 | 继续检索 GitHub 与插件源码；目录浏览不足以证明同类能力不存在。 |
| [PawBench](https://github.com/agentscope-ai/PawBench) | README 将其定位为 Model × Harness 联合评测，强调任务切片与诊断轨迹。 | 核实执行接口、任务和 grader、许可、是否适合单机制消融。 |
| [Harness-Bench 论文](https://arxiv.org/abs/2605.27922) | 论文描述固定环境、预算和评测协议下的 harness 配置比较。2026-10-02 已核实论文链接的 [Qihoo360/harness-bench](https://github.com/Qihoo360/harness-bench) 作者仓库，包含任务、oracle、runner 与适配器。 | 当前阅读快照未发现许可证文件；复用授权、任务依赖和原协议运行仍待确认，不能将公开代码视为已经可集成。 |
| [Agent Memory Benchmark](https://github.com/AlekseiMarchenko/agent-memory-benchmark) | 提供 memory provider 层面的检索、跨会话与冲突等测试。 | 可作为局部测试参考；其分数不能直接代表完整 Agent 的任务表现。 |

此前搜索结果出现的 `dsh-trajectory-ablation` 已于 2026-10-02 检查仓库说明，定位为单步上下文重建和删除消融；本轮还检查了 `dsh-eval` 的运行及配对源码，并阅读了 `dsh-bench` 的对照实验说明。社区已有与批量评测、配对比较、上下文消融重叠的项目，“社区缺少评测工具”不能作为已证实前提。具体来源、快照与复用边界见 [边界审查](BOUNDARY_REVIEW.md)。这轮检查尚未运行外部项目，也未穷尽竞品。

## 7. SDD 推进顺序

1. 继续 grill-me 访谈并记录各项决策，区分确认、建议和待查证事实。
2. 关键范围确定后撰写 SPEC：目标、非目标、行为契约、实验协议、数据契约与验收标准。
3. 基于 SPEC 撰写 PLAN：技术设计、上游集成、复用边界、阶段与验证方案。
4. 基于 SPEC 和 PLAN 撰写 TASK：有依赖关系、明确产物和完成判据的原子任务，追踪至需求编号。
5. 完成上述文档后，再根据用户后续指令进入实现。

本轮已依次完成 [SPEC](SPEC.md)、[PLAN](PLAN.md)、[TASK](TASK.md)，并完成 T-001–T-011 开发与验收。结果见 [RESULTS](RESULTS.md)；真实模型失败不等于隐藏或未执行任务。长期扩展须另定协议，不据此改写已冻结实验。