12. Benchmark：为什么“成绩好”不能直接证明 Harness 最强？
12.1 分数测的是一个组合
12.2 最基本的 2×2 对照
S11-S00，无法知道提升来自模型、Harness，还是二者适配。交互项也只是该实验条件下的证据，不能推断所有任务都有同样增益。
进一步逐项消融：关闭 async，关闭 PTC，关闭 memory，替换压缩策略；固定其余条件，比较完成率、错误类型、延迟和成本。
12.3 必须控制哪些变量？
- 模型 ID/快照、reasoning effort、输入 Prompt、工具定义和权限。
- 仓库 commit、依赖环境、测试命令、CPU/内存与网络条件。
- 总时限、token/费用预算、最大工具次数和重试规则。
- 是否使用已有缓存和记忆；记忆是否来自独立训练/开发任务。
- 多次重复、失败归类、输出工件和可审计轨迹。
12.4 不要混淆 pass@1、pass@k 与多次运行平均分
pass@1 关注单次尝试；pass@k 关注多次候选里是否至少一次成功。对 n 次样本中 c 次成功，常见估计形式为：
k 次不自动意味着榜单报告 pass@k；可能报告平均成功率。必须看该 benchmark 的评分定义。
12.5 实际项目应观察的指标
12.6 用本教程的测试可以声称什么？
可声称：“我实现并验证了异步任务注册、调用去重、旧方案失效、取消、历史与工作集分离、来源可撤回的记忆视图。” 不可声称：“我复现了 Codex 的模型能力”“我的 Harness 在真实 coding benchmark 上领先”“两阶段记忆已证明长期有效”。这些需要真实模型、独立任务集和更长时间验证。13. 与传统 Harness、Claude 的公平对比
13.1 这里的“传统”是基础串行循环，不是所有现有框架
成熟的自建 Harness、工作流引擎和其他 Agent 产品，同样可以实现并发、事件、持久化、权限与检索。这些机制并非所有都由 Codex 发明。真正差异在整合质量、默认体验、协议细节、模型适配与效果。13.2 Claude 并不等于“简单串行 Harness”
当前 Claude Agent SDK 文档包含工具执行、并行、权限、自动压缩、会话、hooks 等机制。Anthropic 还发布过长任务 Harness、交接工件与 Managed Agents 分层设计。因此，本教程不采纳“对方没有架构”这一结论。Claude Agent loop、长任务 Harness 文章 本文没有取得 Claude Code 全部当前内部源码，所以不判断它是否与 Codex 在每一个取消点、steering 协议或隔离边界上等价。相似能力名称不证明同样实现；没有公开源码也不证明没有能力。13.3 Plan Mode 是不是落后？
Plan Mode 可以是一种工作阶段：先理解、澄清、设计，再执行。价值取决于任务，而不是发布时间。13.4 哪些情况下不值得一开始就造复杂宿主？
如果只有一个受控工具、任务几秒内完成、不需要持久会话，一个清楚的函数调用循环可能足够。 只有在出现长工具等待、多客户端协作、恢复需求、历史超窗或安全隔离等真实痛点后，再逐步增加任务注册表、事件日志、窗口管理与持久化。复杂系统新增的故障模式可能比省下的 token 更昂贵。14. 面试表达：怎么把这些内容讲得具体而可信？
14.1 90 秒回答模板
我理解 Codex 值得研究的地方，是把编码 Agent 从“模型加工具循环”做成可持续交互的执行系统。第一层是 App Server，用线程、轮次和条目等协议把客户端与执行宿主分开。第二层是调度，慢工具可以 pending，模型继续做无依赖的工作，并通过明确的调用 ID 回收结果。第三层是运行中调整，steering 区分更新已接受和已生效，而且不会撤销已完成副作用。第四层是上下文与记忆，把当前工作集、完整历史和长期经验分开管理。PTC 则让代码处理批量工具编排和确定性计算。它们的收益要靠成功率、延迟、成本与恢复能力验证，不能从品牌或一张榜单直接推断架构优劣。
14.2 5 分钟回答顺序
- 用“修复失败测试”讲基础 loop，并指出工具等待和上下文增长问题。
- 画出客户端、App Server、Runtime、模型、工具、状态库六块。
- 举 CI 查询与 README 分析重叠的例子，解释 async 和依赖图。
- 加一句用户中途说“只分析”，解释 revision 与副作用边界。
- 对比 PTC 的程序聚合与逐次模型调用。
- 区分历史、窗口、压缩和长期记忆。
- 用自己跑过的测试收尾，明确真实模型和 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 的本地测试包装成复杂系统的性能证明。