> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wangenhui.top/llms.txt
> Use this file to discover all available pages before exploring further.
# Benchmark、竞品对比与面试表达
> 用可复现的证据边界讨论评测、传统 Harness、Claude 和面试回答。
## 12. Benchmark：为什么“成绩好”不能直接证明 Harness 最强？
### 12.1 分数测的是一个组合
```text theme={null}
任务表现 = f(模型、Harness、工具、Prompt、预算、环境、任务集、随机性)
```
截图把 Terminal-Bench 的归属和多种评测压缩成口语化说法。本次查到的官方基准论文描述了终端环境任务及评测，但没有取得截图所指“Runta 的 Harness 测试”的可复现入口。因此，本文不转述其名次，也不沿用“某个人的测试”作为正式出处。[Terminal-Bench 2.0 论文](https://arxiv.org/abs/2601.11868)
本次打开旧 2.0 榜单链接时，页面跳转到了新版展示且未返回完整成绩表。因此，搜索摘要中的历史名次不能当作 2026-09-10 的当前榜单。想引用截图当日排名，应拿到当日快照、提交轨迹和配置。
### 12.2 最基本的 2×2 对照
| | 基础 Harness H0 | 新 Harness H1 |
| ----- | ------------- | ------------ |
| 模型 M0 | S00 | S01 |
| 模型 M1 | S10 | S11 |
```text theme={null}
M0 上的 Harness 增益 = S01 - S00
M1 上的 Harness 增益 = S11 - S10
交互项 = (S11 - S10) - (S01 - S00)
```
如果只看 `S11-S00`，无法知道提升来自模型、Harness，还是二者适配。交互项也只是该实验条件下的证据，不能推断所有任务都有同样增益。
进一步逐项消融：关闭 async，关闭 PTC，关闭 memory，替换压缩策略；固定其余条件，比较完成率、错误类型、延迟和成本。
### 12.3 必须控制哪些变量？
* 模型 ID/快照、reasoning effort、输入 Prompt、工具定义和权限。
* 仓库 commit、依赖环境、测试命令、CPU/内存与网络条件。
* 总时限、token/费用预算、最大工具次数和重试规则。
* 是否使用已有缓存和记忆；记忆是否来自独立训练/开发任务。
* 多次重复、失败归类、输出工件和可审计轨迹。
Memory 评测尤其要防止测试泄漏：不能先把测试任务的答案写入记忆，再把高分归因于更会学习。
### 12.4 不要混淆 pass\@1、pass\@k 与多次运行平均分
`pass@1` 关注单次尝试；`pass@k` 关注多次候选里是否至少一次成功。对 `n` 次样本中 `c` 次成功，常见估计形式为：
```text theme={null}
pass@k = 1 - C(n-c, k) / C(n, k) （满足相应采样条件）
```
重复运行 `k` 次不自动意味着榜单报告 `pass@k`；可能报告平均成功率。必须看该 benchmark 的评分定义。
### 12.5 实际项目应观察的指标
| 指标 | 计算/观察方式 | 防止误判 |
| ------------ | --------------- | --------------- |
| 任务成功率 | 独立验收器或人工复核 | 模型自评不能独自当真值 |
| 证据完整率 | 结论是否有对应工具/工件证据 | 有引用不代表引用支持结论 |
| Steering 保留率 | 后续方案是否符合新增约束 | 仅 ACK 不算成功 |
| 失败恢复率 | 断线、超时后能否继续 | 继续输出不代表恢复正确状态 |
| p50/p95 延迟 | 从接受到真实验收结束 | 首 token 快不等于任务快 |
| 每个成功任务成本 | 总成本 / 成功数量 | 不隐藏失败任务的成本 |
| 记忆准确性 | 范围正确、事实正确、来源可复核 | 命中率高可能只是乱召回 |
| 安全违规率 | 越权动作、跨任务泄漏 | 正确答案不能抵消不允许的副作用 |
### 12.6 用本教程的测试可以声称什么？
可声称：“我实现并验证了异步任务注册、调用去重、旧方案失效、取消、历史与工作集分离、来源可撤回的记忆视图。”
不可声称：“我复现了 Codex 的模型能力”“我的 Harness 在真实 coding benchmark 上领先”“两阶段记忆已证明长期有效”。这些需要真实模型、独立任务集和更长时间验证。
## 13. 与传统 Harness、Claude 的公平对比
### 13.1 这里的“传统”是基础串行循环，不是所有现有框架
成熟的自建 Harness、工作流引擎和其他 Agent 产品，同样可以实现并发、事件、持久化、权限与检索。这些机制并非所有都由 Codex 发明。真正差异在整合质量、默认体验、协议细节、模型适配与效果。
| 维度 | 本文基础串行 Harness | Codex/API 可核实方向 | 工程代价或适用边界 |
| ------------ | -------------- | ----------------------------------------- | -------------------- |
| 客户端 | 客户端内直接跑循环 | App Server 抽象富客户端接口 | 版本、连接、共享故障 |
| 任务状态 | 内存列表/当前函数栈 | Thread、Turn、Item 与事件 | 恢复要处理进行中的副作用 |
| 工具调度 | 调一次等一次 | 并发、cell yield/wait、API async | 依赖识别、输出归属、pending 管理 |
| 用户插话 | 等当前轮结束 | App turn steering / API response steering | 接受与生效区分、不会自动回滚 |
| 多步工具 | 模型逐次编排 | PTC / Code Mode | 程序沙盒、工具白名单、部分失败 |
| 长上下文 | 全量追加、简单截断 | 压缩、新窗口、历史恢复路径 | 来源/权限保留与召回质量 |
| 长期记忆 | 手写记忆文件或没有 | 后台提取与整合、读取能力 | 污染、冲突、额度与过期处理 |
| Computer Use | 自己接一个 click 工具 | 支持模型与执行环境闭环 | 状态观察、动作授权、终态验收 |
| 评估 | 看输出像不像正确 | 可对工具、任务与系统结果评估 | 不存在一个协议自动保证高分 |
### 13.2 Claude 并不等于“简单串行 Harness”
当前 Claude Agent SDK 文档包含工具执行、并行、权限、自动压缩、会话、hooks 等机制。Anthropic 还发布过长任务 Harness、交接工件与 Managed Agents 分层设计。因此，本教程不采纳“对方没有架构”这一结论。[Claude Agent loop](https://code.claude.com/docs/en/agent-sdk/agent-loop)、[长任务 Harness 文章](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
本文没有取得 Claude Code 全部当前内部源码，所以不判断它是否与 Codex 在每一个取消点、steering 协议或隔离边界上等价。**相似能力名称不证明同样实现；没有公开源码也不证明没有能力。**
### 13.3 Plan Mode 是不是落后？
Plan Mode 可以是一种工作阶段：先理解、澄清、设计，再执行。价值取决于任务，而不是发布时间。
```text theme={null}
简单拼写修复：强制写长计划可能只是开销。
跨服务迁移：先确认契约、依赖与回滚路径可以减少返工。
任务进行中出现新证据：计划应更新，不能把旧计划当不可变脚本。
```
好的设计是可编辑的计划状态与必要的审批点。Plan Mode 不是只能靠 Prompt，也不是一定要多 Agent；它可以由 UI 状态、权限策略和运行时契约共同实现。
### 13.4 哪些情况下不值得一开始就造复杂宿主？
如果只有一个受控工具、任务几秒内完成、不需要持久会话，一个清楚的函数调用循环可能足够。
只有在出现长工具等待、多客户端协作、恢复需求、历史超窗或安全隔离等真实痛点后，再逐步增加任务注册表、事件日志、窗口管理与持久化。复杂系统新增的故障模式可能比省下的 token 更昂贵。
## 14. 面试表达：怎么把这些内容讲得具体而可信？
### 14.1 90 秒回答模板
> 我理解 Codex 值得研究的地方，是把编码 Agent 从“模型加工具循环”做成可持续交互的执行系统。第一层是 App Server，用线程、轮次和条目等协议把客户端与执行宿主分开。第二层是调度，慢工具可以 pending，模型继续做无依赖的工作，并通过明确的调用 ID 回收结果。第三层是运行中调整，steering 区分更新已接受和已生效，而且不会撤销已完成副作用。第四层是上下文与记忆，把当前工作集、完整历史和长期经验分开管理。PTC 则让代码处理批量工具编排和确定性计算。它们的收益要靠成功率、延迟、成本与恢复能力验证，不能从品牌或一张榜单直接推断架构优劣。
### 14.2 5 分钟回答顺序
1. 用“修复失败测试”讲基础 loop，并指出工具等待和上下文增长问题。
2. 画出客户端、App Server、Runtime、模型、工具、状态库六块。
3. 举 CI 查询与 README 分析重叠的例子，解释 async 和依赖图。
4. 加一句用户中途说“只分析”，解释 revision 与副作用边界。
5. 对比 PTC 的程序聚合与逐次模型调用。
6. 区分历史、窗口、压缩和长期记忆。
7. 用自己跑过的测试收尾，明确真实模型和 benchmark 尚未测。
### 14.3 高频追问与回答要点
**Q1：Harness 和 Agent Framework 是什么关系？**
Framework 是构建工具；Harness 是具体承载策略与模型交互的运行系统。可以用框架写 Harness，也可以不依赖框架。关键看循环、状态、权限和结果验证在哪里。
**Q2：App Server 就是把 CLI 包成一个 HTTP 服务吗？**
仅包 HTTP 不能自动得到线程状态、双向审批、事件、恢复和工具生命周期。App Server 的价值是执行契约与状态语义，而不只是传输协议。
**Q3：为什么不每个任务启动一个进程？**
可以这样做，尤其强调隔离时。共享宿主主要换来复用和统一管理，但要承担隔离与共享故障成本；应测内存、启动延迟、故障影响范围。
**Q4：asyncio.gather 就等于 Astra 异步推理吗？**
不等于。gather 只说明应用并发运行协程；模型能否在结果未返回时继续，取决于模型与协议。教程本地 demo 只证明前者和 pending 管理。
**Q5：用户停止任务后为什么还有操作发生？**
可能只停止了生成流，没有取消工具或子进程；也可能动作已提交到远端。需要追踪取消传播、子进程组、远端任务句柄和提交时刻。
**Q6：如何保证工具 exactly once？**
单靠网络请求无法普遍保证。更常见是至少一次投递加幂等键、执行日志和结果缓存；外部服务也必须支持幂等或对账。本地字典去重只在当前进程生命周期内有效。
**Q7：为什么要有 expectedTurnId？**
防止客户端基于过期视图把新消息塞给错误轮次，是并发控制的一种防护，不是为了美化接口。
**Q8：steering 会改写正在生成的推理吗？**
可确认的是服务端接受更新并衔接后续响应，不应断言已采样 token 或内部推理状态被原地改写。已发出文本和已执行动作仍然存在。
**Q9：PTC 一定省 token 吗？**
不一定。数据很多且可压缩时收益明显；单次简单调用可能被程序生成、运行与错误处理开销抵消。需要按任务形态测。
**Q10：为什么不能用 Node vm 执行模型代码当沙盒？**
语言上下文隔离不等于安全执行环境。应明确 OS/进程/容器等隔离、资源预算与工具权限；本教程没有将 Node vm 声称为安全沙盒。
**Q11：MCP 会被 PTC 替代吗？**
通常不是同一层。MCP 连接服务，PTC 编排调用；程序里的一个工具调用完全可以经由 MCP 完成。
**Q12：为什么上下文换窗后还能继续？**
环境没有被重置；目标、笔记、持久历史和按需检索可以提供续接信息。但必须验证关键约束和工具配对，不能只是清空消息数组。
**Q13：压缩是不是无损？**
不是可以随便宣称的性质。API 的不透明压缩项是为继续任务而设计，不能当作可逆原文存档。需要原文时保留历史来源。
**Q14：窗口切换等于 sliding-window attention 吗？**
不是。前者是应用层上下文选择，后者是模型注意力范围设计；名字相似不代表实现相同。
**Q15：Memory 与 RAG 的关系？**
RAG 是检索后提供上下文的方式；Memory 是从经历形成可复用信息的机制。Memory 可以用 RAG 读取，但还需要写入、整合、冲突、失效和删除策略。
**Q16：怎么防止记忆跨项目污染？**
记忆键带 project/workspace scope；读取时先授权和过滤，再排序。不能先跨用户检索完再依赖模型“不要说出去”。
**Q17：dreaming 会让模型越用越聪明吗？**
外部记忆可能让以后少重复探索，但不是权重自动训练。有效性应测后续任务受益和错误继承，不能把文件更新等同于模型能力永久提升。
**Q18：模型说测试通过，你怎么判断？**
读取实际测试结果、退出码和对应代码版本，再核对覆盖的验收要求；生成摘要、命令完成和真实正确性是不同证据层级。
**Q19：Code Mode 怎样保留部分失败？**
只读聚合可以用 allSettled，结果标为 partial 并保留失败列表。写操作则需要幂等、事务或补偿，不能靠 Promise 聚合实现回滚。
**Q20：证明新 Harness 比旧的好，要做什么实验？**
固定模型、工具、任务与预算做配对实验，多次运行并报告置信区间，做功能消融；真实成功率是首要指标，同时报告成本、延迟和违规。
### 14.4 一个可以真实讲的项目经历
完成本文练习后，你可以说：
> 我做了一个 Python asyncio 的教学 Agent Runtime，把工具执行从同步调用拆成 pending job registry，使用 thread、turn、call ID 隔离结果，并给用户变更加了 revision 校验。实现了事件日志重放和 SQLite 的历史/记忆分层。我用测试验证了并发、取消、超时、调用去重、旧方案拒绝与来源撤回。还对接验证了本机 Codex App Server 的初始化协议。模型级 async、PTC 和 steering 的 API 接线代码已经准备，但还需要实际 API 端到端评测。
不要写成“负责开发 Codex 同款生产级底层架构”，也不要把本文 demo 的本地测试包装成复杂系统的性能证明。