最近技术社区流传一个视频标题OpenAI just proved AI has no idea what its doing。第一次看到这句话我以为是又一轮“AI 无用论”的争吵。但把这件事放到 Agent 工程化语境里它说的其实是另外一件事模型在规整的 Demo 里表现得像什么都懂一旦进入真实工程任务经常表现出“不知道自己在做什么”的失控感。OpenAI 开源 Codex Harness 之后这个话题又被重新翻出来因为评测代码生成 Agent 终于有了一套可复现的框架而不是靠几个截图和演示视频下结论。如果你是做 AI 应用开发、模型评测、提示词工程或者正在把 ChatGPT 这类大模型接进自己的发布流程这篇内容可以收藏。我不打算替官方仓库写使用文档而是从工程角度拆解为什么 AI 需要一场“期末考试”怎么用一个可复现的沙箱去测 Agent 的代码能力怎么通过接口做批量任务以及最容易踩的坑是什么。本文会覆盖五件事第一Codex Harness 这类评测框架解决什么问题第二搭建一个最小可运行的评测环境需要什么硬件和软件第三用一组代码任务做功能验证第四通过 OpenAI 兼容接口批量跑任务第五常见问题排查和工程化建议。最后会给出一个结论AI 到底有没有“知道自己在做什么”不取决于模型宣传而取决于你有没有一套能骗过自己直觉的评估流程。1. 核心能力速览先给出一张速览表。这里的描述是根据公开仓库和社区讨论整理不属于官方承诺具体参数以你拉取代码时的仓库 README 和文档为准。能力项说明项目类型代码生成 Agent 评测与执行环境主要功能在隔离环境中运行代码任务验证生成结果是否满足测试要求核心目标把“模型能写代码”变成“模型能完成闭环任务”支持语言以 Python 为主扩展语言取决于你构建的执行环境推荐硬件只跑评测框架CPU、内存、Docker 即可模型推理另算GPU 需求使用 API 时不需要 GPU使用本地模型时按模型大小决定显存启动方式命令行脚本、Docker 容器、Python 接口是否支持 API模型侧通常可以接 OpenAI 兼容接口是否支持批量任务支持任务文件可按行定义批量运行适合人群AI 应用开发者、模型评测工程师、提示词工程师、技术负责人这类评测框架的核心不是“生成代码”而是“执行代码并给出判定”。它把任务定义、代码运行、结果检查串联起来让你可以快速判断某个模型在某个任务集上到底能通过多少测试。由于它只负责运行环境所以对显卡没有那么强依赖真正吃算力的是模型推理过程。如果你的目的是验证 OpenAI API 返回的代码是否靠谱本机只需要 Docker 和 Python不需要部署大模型。2. 适用场景与使用边界这套评测思路适合三类场景。第一类是模型准入测试你准备换一个模型或换一个版本想先看看它的代码生成能力有没有倒退。第二类是 Prompt 回归测试你改了系统提示词担心影响原有任务可以直接跑一遍历史任务集对比通过率。第三类是 Agent 能力验证你需要确认模型在“读取任务、生成代码、根据报错修复”这个闭环里是否稳定而不是只测单次补全。不适合的场景也要说清楚。它很难替代业务系统的端到端验收因为真实工程上下文远比赛题复杂评测任务通常是孤立的函数级问题不能代表多文件、多服务、老代码库里的实际情况。同时这类评测只能证明模型在当前任务集上的表现并不等于模型的通用能力。任务集设计得越窄结论的泛化性越差。还需要明确使用边界。代码评测一定会执行生成的代码而生成代码可能有任意行为所以必须在 Docker 等隔离环境中运行不要直接在宿主机上执行。不要用公司私有代码、商业机密数据提交到外部评测服务或公开模型接口除非你确认数据不会被留存。涉及开源代码生成时也要检查是否触犯许可证和版权问题生成结果不能默认合入生产。3. 环境准备与前置条件如果只是想先跑通评测流程最低配置其实不高一台能装 Docker 的 Linux/macOS/Windows 机器即可内存建议 8G 以上磁盘至少留 20G。Windows 推荐用 WSL2 和 Docker Desktop避免路径和权限问题。Python 版本建议 3.10 以上git 是必装的。如果计划用本地模型做推理再准备 NVIDIA GPU12G 显存左右比较稳妥但具体占用要以模型和推理参数为准不要盲信网上任何一张显存截图。开始之前先做一轮环境检查。在终端执行docker --version python3 --version git --version三个命令都能正常输出版本号说明基础环境可用。如果 docker 命令不存在需要先安装 Docker如果 python3 版本过低建议用 pyenv 或 conda 管理版本。接下来确认 Docker 守护进程已经启动docker ps这条命令会列出当前容器列表。如果卡住或报错先解决 Docker 运行问题再继续后面的操作否则评测沙箱起不来所有任务都会失败。配置模型接口时建议把 API Key 放到环境变量里不要写死在代码中。Linux/macOS 可以这样设置export AI_API_URLhttps://api.example.com/v1/chat/completions export AI_API_KEYyour-api-keyWindows PowerShell 对应写法是$env:AI_API_URLhttps://api.example.com/v1/chat/completions $env:AI_API_KEYyour-api-key这里的 URL 和 Key 只是示例替换成你自己的模型服务地址即可。如果使用的是 OpenAI 官方接口同样遵循这个通用模式。接口地址、模型名、鉴权方式会因为服务商不同而变化建议先确认官方文档。4. 本地评测流程与启动方式下面给出一套通用评测流程。以真实仓库为准所有仓库名、路径、脚本名都需要替换。第一步拉取评测框架代码。假设评测仓库地址是 GitHub 上的某个公开仓库先克隆到本地git clone https://github.com/{org}/{repo}.git cd {repo} pip install -r requirements.txt第二步准备任务文件。评测任务通常用 JSONL 描述每行一个独立任务。下面是一个常见示例格式不代表具体评测框架的字段但可以帮你理解任务结构{task_id: task_001, instruction: Write a Python function to compute Fibonacci numbers., test: assert fib(10) 55}字段里至少要包含任务 ID、给模型的指令、以及用来验证结果的测试代码。更完整的任务集还会包含参考代码、环境依赖信息、超时时间等。第三步构建隔离执行环境。代码生成结果必须放在沙箱里运行最方便的办法是写一个 Dockerfile。下面是一个最小示例FROM python:3.11-slim WORKDIR /workspace RUN apt-get update apt-get install -y --no-install-recommends gcc g rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt ENV PYTHONDONTWRITEBYTECODE1这个镜像只安装了编译基础工具和 Python 依赖适合跑大多数纯 Python 评测任务。如果你的任务需要 Node、Java、Go 等环境在镜像里额外安装对应运行时即可。第四步运行评测。不同评测框架的启动命令不一样但思路类似都是指定任务文件、指定模型接口、指定输出目录。通用模板如下python run_eval.py \ --input tasks.jsonl \ --output results.jsonl \ --api-url $AI_API_URL \ --api-key $AI_API_KEY \ --model your-model-name \ --max-workers 4--max-workers控制并发数第一次建议设为 1先确认流程通畅再逐步提高。启动后日志会打印当前任务进度正常能看到“任务开始”“模型返回”“代码执行”“测试通过/失败”这类信息。如果服务启动失败优先检查三件事环境变量是否配置、任务文件 JSON 格式是否合法、Docker 是否可用。5. 功能测试与效果验证5.1 单任务代码生成测试第一次测试不要跑批量任务。挑一个最简单的函数级任务手动确认整个链路是否正常。输入示例{task_id: task_001, instruction: Write a Python function add(a, b) that returns a b., test: assert add(2, 3) 5}操作流程是运行评测脚本加载这一条任务模型调用接口返回一段代码评测框架把代码写入工作目录然后执行测试代码。判断成功的标准是测试最终返回通过并且日志里能看到task_001: PASS或等价输出。如果失败检查模型返回的代码是否是完整函数是否缺少 import是否有额外输出混入代码。这一步最重要。单任务跑通说明接口鉴权、任务格式、沙箱执行、结果判定四个环节都是通的。任何一个环节卡住都不要急着扩大任务量先把链路修好。5.2 多轮修复测试很多评测框架支持“生成代码→执行测试→失败信息反馈给模型→模型修复→再次执行”的多轮闭环。这个能力比单次生成更接近真实工程场景也是判断 Agent 是否“知道自己在做什么”的关键指标。以 5.1 的任务为例故意在测试里增加一个边界条件比如{task_id: task_002, instruction: Write a function fib(n) that returns the n-th Fibonacci number., test: assert fib(0) 0 and fib(1) 1 and fib(10) 55}如果第一轮生成的代码没处理 n0 的情况测试会失败。评测框架会把失败信息传回模型模型需要根据错误信息修改代码。判断成功的标准不是第一轮就通过而是在允许的轮数内最终通过。你需要重点观察模型在看到报错后是真正修正了逻辑还是反复输出同样的错误代码。后者是“AI 不知道自己在做什么”的典型表现。5.3 批量任务测试批量任务的价值在于把单点表现变成统计结论。准备一个包含几十条任务的 JSONL 文件每条任务难度可以分级。第一次批量任务建议控制在 10 条以内每条任务独立记录结果避免一个任务卡死影响全部。运行方式仍然复用 4.1 的评测脚本把输入文件换成批量任务文件。预期输出是一份结果文件里面包含每个任务的状态、生成代码、测试输出和耗时。批量任务跑完后统计通过率和平均耗时这就是当前模型在这份任务集上的基线数据。这里要留意一个坑并发数太高会导致模型接口被限流或返错任务看起来是“失败”实际上只是超时。更稳妥的做法是先跑 1 个并发记录基线耗时再逐步增加并发数对比失败率变化。5.4 结果判定与环境隔离结果判定逻辑本身也必须正确。不要只看模型是否输出了“我认为代码正确”而要看隐藏测试是否通过。测试环境要保持干净不能出现上一条任务留下的缓存文件、临时目录、环境变量污染。这也是为什么推荐用 Docker 容器做执行环境而不是直接在宿主机执行。对于复杂任务还可以把判定拆成多级指标。第一级是是否能运行、不报语法错误第二级是是否能通过基本测试第三级是是否能通过隐藏测试和边界测试第四级是代码风格、复杂度、可维护性。前两级适合自动化判定后两级需要人工或更严格的静态检查工具完成。5.5 稳定性观察同一批任务连续跑两次结果可能不一样因为模型推理有随机性评测框架也可能受网络波动影响。稳定性观察方法是固定同一份任务集、同一个模型、同样的并发参数连续跑三遍对比通过率的波动范围。如果三遍结果差异很大说明当前模型或评测流程不稳定不能作为正式基准数据。评测日志要包含完整上下文。每个任务至少记录模型返回的原始内容、写入的文件内容、测试执行输出、最终判定、耗时、重试次数。这样出问题时可以回溯是模型问题、网络问题还是测试代码问题。6. 接口 API 与批量任务6.1 OpenAI 兼容接口调用示例如果你不打算用完整的评测框架只想自己写脚本把模型接口和测试逻辑串起来可以直接调用 OpenAI 兼容接口。下面是一个最小可用的 Python 示例import requests import os API_URL os.getenv(AI_API_URL, https://api.example.com/v1/chat/completions) API_KEY os.getenv(AI_API_KEY, ) payload { model: your-model-name, messages: [ {role: system, content: You are a coding assistant.}, {role: user, content: Write a Python function to compute Fibonacci numbers.} ], temperature: 0.2, max_tokens: 1024 } headers {Authorization: fBearer {API_KEY}} response requests.post(API_URL, jsonpayload, headersheaders, timeout120) print(response.status_code) print(response.json()[choices][0][message][content])这里把 API_URL 设置为环境变量方便切换真实服务地址。需要注意不同兼容服务可能使用不同的路径前缀有些是/v1/chat/completions有些是/v1/responses请以实际服务商文档为准。6.2 批量任务脚本结构批量任务不只是用 for 循环把所有任务跑一遍还要考虑并发、失败重试和结果落盘。下面是一个通用批量脚本它从一个 JSONL 文件读取任务用线程池控制并发每个任务调用一次模型接口把结果写入另一个 JSONL 文件import json import requests from concurrent.futures import ThreadPoolExecutor, as_completed INPUT_FILE tasks.jsonl OUTPUT_FILE results.jsonl API_URL https://api.example.com/v1/chat/completions API_KEY your-api-key MAX_WORKERS 4 def run_task(task): payload { model: your-model-name, messages: [{role: user, content: task[instruction]}], temperature: 0.2, max_tokens: 1024, } headers {Authorization: fBearer {API_KEY}} try: response requests.post(API_URL, jsonpayload, headersheaders, timeout180) response.raise_for_status() content response.json()[choices][0][message][content] return {task_id: task[task_id], ok: True, result: content} except Exception as exc: return {task_id: task[task_id], ok: False, error: str(exc)} with open(INPUT_FILE, r, encodingutf-8) as f: tasks [json.loads(line) for line in f if line.strip()] results [] with ThreadPoolExecutor(max_workersMAX_WORKERS) as executor: futures [executor.submit(run_task, task) for task in tasks] for future in as_completed(futures): results.append(future.result()) with open(OUTPUT_FILE, w, encodingutf-8) as f: for result in results: f.write(json.dumps(result, ensure_asciiFalse) \n) print(fdone, total{len(results)})这个脚本的重点是失败不会中断整体流程。单个任务报错会被捕获并写入错误信息方便后面集中分析。真实的评测脚本还应该在请求失败时做指数退避重试避免瞬时网络抖动导致大量失败。6.3 结果落盘与二次判定模型接口返回的只是一段代码还需要二次判定。可以写一个独立的验证脚本从结果文件里读取生成代码写入临时文件然后用 pytest 或其他测试工具执行import subprocess import sys import json def verify_one(task_id, code, test_code): with open(solution.py, w, encodingutf-8) as f: f.write(code) with open(test_solution.py, w, encodingutf-8) as f: f.write(test_code) result subprocess.run( [sys.executable, -m, pytest, test_solution.py, -q], capture_outputTrue, textTrue, timeout30 ) return result.returncode 0, result.stdout result.stderr with open(results.jsonl, r, encodingutf-8) as f: lines [json.loads(line) for line in f if line.strip()] for item in lines: ok, log verify_one(item[task_id], item[result], item[test]) print(item[task_id], ok)在实际评测框架里二次判定往往直接集成到评测循环中不需要单独拆出来写。如果你是从零开始搭自动化评测系统这个拆法逻辑更清晰第一步拿到模型输出第二步把输出代码执行并判定两步分开跑便于排查问题。7. 资源占用与性能观察评测框架本身的资源消耗通常不高主要吃 CPU、内存和临时磁盘。Docker 容器里的代码编译和执行会占用少量 CPU任务集大或单任务运行时间长时内存会明显上涨。观察资源占用最直接的方式是docker stats这个命令会实时显示每个容器的 CPU、内存、网络和磁盘占用。如果某个容器内存持续飙升很可能是模型生成的代码有死循环或一次性加载了超大数据。此时除了加内存还要在评测配置里设置单任务超时时间。模型推理部分是资源消耗的大头。使用外部 API 时本机只承担网络请求不占 GPU。使用本地模型时推理由 GPU 完成可以用nvidia-smi观察显存占用watch -n 1 nvidia-smi通过率、耗时、显存占用这些指标会随着模型大小、并发数、输入输出 token 长度明显变化。建议每次评测都固定一组参数模型名、温度、max_tokens、并发数、超时时间。参数变了结果就不能直接横向比较。降低资源占用的通用手段包括降低并发数、减小 max_tokens、缩短任务输入、为容器设置内存限额。如果不做资源限制一个失控的任务可能会拖垮整台机器。Docker 启动容器时可以加参数docker run --memory4g --cpus2 --networknone your-eval-image--networknone表示禁用网络访问适合不需要联网的任务也避免生成代码在评测环境里访问外部资源。是否需要禁用网络取决于你的任务集设计不能一概而论。8. 常见问题与排查方法在搭建和运行评测流程时下面这些问题最容易遇到。问题现象可能原因排查方式解决方案接口调用一直失败API URL 或 Key 配置错误打印请求参数和响应状态码对照服务商文档修正 URL 和鉴权头Docker 镜像构建慢基础镜像过大或网络不稳定查看构建日志卡在哪一步换用更小的基础镜像固定版本号配置镜像加速容器启动后立刻退出任务缺少入口文件或权限不足查看容器日志检查任务工作目录和文件权限生成的代码无法执行模型输出了 Markdown 代码块或额外文字查看原始返回内容在写入文件前剥离代码块标记单任务被判定失败但人工看是对的测试代码条件过严或输出格式不符合预期打印测试输出和生成文件内容完善测试代码允许合理的输出差异批量任务大量超时并发数过高或接口限流查看错误信息中的超时状态降低并发数增加超时时间加入重试机制本地模型显存不足模型参数规模超过 GPU 显存用 nvidia-smi 查看实际占用换更小模型使用量化版本减小最大 token结果文件找不到输出路径配置错误或脚本中断检查运行时日志和当前工作目录使用绝对路径程序退出前 flush 结果排查问题有个基本原则先复现单条再分析批量。批量任务失败率异常时先挑出第一条失败任务单独运行把模型请求、代码生成、测试执行三个步骤拆开看。很多时候问题不是模型能力而是评测环境本身不够干净。还有一类问题是评测脚本常驻进程没有正常退出导致端口冲突或文件句柄占用。销毁容器和清理临时目录可以在评测脚本结束时统一处理。如果卡住可以用CtrlC中断主进程然后检查残留的 Python 和 Docker 容器。9. 最佳实践与使用建议第一第一次评测只用一个小任务集。目标不是“评测出最好模型”而是先确认整个链路可以稳定复用。建议准备 5 到 10 个任务覆盖正确性、边界条件、依赖安装三种情况。跑通之后再逐步扩大到 100 条、500 条。第二任务集要版本化。任务文件、评测脚本、依赖版本都要纳入 git 管理。否则过一段时间你改了几行测试代码旧的结果就失去了对比价值。每次跑批量评测时记录任务文件 hash 或版本号确保结果可追溯。第三代码执行必须隔离。无论评测代码是否可信都要在 Docker 容器中运行。不要为了省事直接在宿主机执行。容器要限制内存、CPU 和网络具体限制值根据任务需求调整。第四批量任务要有重试机制。模型接口偶发超时是正常的不要一失败就判定任务结果异常。对瞬时失败做 2 到 3 次重试并记录重试次数。重试仍失败的再标记为失败这样能避免统计结果被网络抖动污染。第五数据隐私和版权合规要前置。评测数据不要包含个人隐私、密码、内部业务信息。使用第三方模型接口前确认服务商是否会用你的数据做训练。生成代码用于生产环境前仍需要人工审查并确认代码没有复制受版权保护的内容。第六建立“基线”概念。每次评测都选一个固定模型作为基准先跑一遍得到基线通过率。后续换模型、换 Prompt、换任务集时都拿新结果和基线对比。没有基线的评测只能得出“好像能跑”得不出“是否变好”的结论。10. 总结与下一步回到开头那个标题OpenAI just proved AI has no idea what its doing。这句话的真正价值是逼着我们去回答一个更工程化的问题你如何判断一个 AI Agent 到底有没有在正确地做任务答案不是看演示视频也不是听厂商宣传而是设计一套可复现的评测流程把任务、代码执行、结果判定全部串起来。Codex Harness 这类开源评测框架的意义恰恰是把这套流程标准化让模型能力可以被量化、被对比、被回归。如果你是第一次尝试建议最先验证的不是复杂任务而是一个最简单的函数生成任务比如让模型生成一个add(a, b)函数。跑通单任务后再跑批量任务。最容易踩的坑有两个一是任务环境不干净导致测试通过与否和模型能力无关二是接口并发设置过高让统计结果被限流噪声污染。这两点都可以通过固定并发数、清理容器环境、增加日志来解决。下一步的扩展方向有三条。第一把评测流程接入 CI每次修改 Prompt 或换模型时自动跑回归测试。第二把任务集从纯函数级扩展到文件级、项目级验证 Agent 的多文件编辑能力。第三接入本地模型把 API 调用替换为本地推理服务在离线环境里做更频繁的迭代评测。先把一个任务跑通再把十个任务跑顺最后再把一百个任务跑稳。这套路径对任何想认真评估 AI 编程能力的团队都适用。希望这篇内容能帮你少走一些弯路。
Codex Harness：用可复现评测框架检验AI编程Agent的真实能力
最近技术社区流传一个视频标题OpenAI just proved AI has no idea what its doing。第一次看到这句话我以为是又一轮“AI 无用论”的争吵。但把这件事放到 Agent 工程化语境里它说的其实是另外一件事模型在规整的 Demo 里表现得像什么都懂一旦进入真实工程任务经常表现出“不知道自己在做什么”的失控感。OpenAI 开源 Codex Harness 之后这个话题又被重新翻出来因为评测代码生成 Agent 终于有了一套可复现的框架而不是靠几个截图和演示视频下结论。如果你是做 AI 应用开发、模型评测、提示词工程或者正在把 ChatGPT 这类大模型接进自己的发布流程这篇内容可以收藏。我不打算替官方仓库写使用文档而是从工程角度拆解为什么 AI 需要一场“期末考试”怎么用一个可复现的沙箱去测 Agent 的代码能力怎么通过接口做批量任务以及最容易踩的坑是什么。本文会覆盖五件事第一Codex Harness 这类评测框架解决什么问题第二搭建一个最小可运行的评测环境需要什么硬件和软件第三用一组代码任务做功能验证第四通过 OpenAI 兼容接口批量跑任务第五常见问题排查和工程化建议。最后会给出一个结论AI 到底有没有“知道自己在做什么”不取决于模型宣传而取决于你有没有一套能骗过自己直觉的评估流程。1. 核心能力速览先给出一张速览表。这里的描述是根据公开仓库和社区讨论整理不属于官方承诺具体参数以你拉取代码时的仓库 README 和文档为准。能力项说明项目类型代码生成 Agent 评测与执行环境主要功能在隔离环境中运行代码任务验证生成结果是否满足测试要求核心目标把“模型能写代码”变成“模型能完成闭环任务”支持语言以 Python 为主扩展语言取决于你构建的执行环境推荐硬件只跑评测框架CPU、内存、Docker 即可模型推理另算GPU 需求使用 API 时不需要 GPU使用本地模型时按模型大小决定显存启动方式命令行脚本、Docker 容器、Python 接口是否支持 API模型侧通常可以接 OpenAI 兼容接口是否支持批量任务支持任务文件可按行定义批量运行适合人群AI 应用开发者、模型评测工程师、提示词工程师、技术负责人这类评测框架的核心不是“生成代码”而是“执行代码并给出判定”。它把任务定义、代码运行、结果检查串联起来让你可以快速判断某个模型在某个任务集上到底能通过多少测试。由于它只负责运行环境所以对显卡没有那么强依赖真正吃算力的是模型推理过程。如果你的目的是验证 OpenAI API 返回的代码是否靠谱本机只需要 Docker 和 Python不需要部署大模型。2. 适用场景与使用边界这套评测思路适合三类场景。第一类是模型准入测试你准备换一个模型或换一个版本想先看看它的代码生成能力有没有倒退。第二类是 Prompt 回归测试你改了系统提示词担心影响原有任务可以直接跑一遍历史任务集对比通过率。第三类是 Agent 能力验证你需要确认模型在“读取任务、生成代码、根据报错修复”这个闭环里是否稳定而不是只测单次补全。不适合的场景也要说清楚。它很难替代业务系统的端到端验收因为真实工程上下文远比赛题复杂评测任务通常是孤立的函数级问题不能代表多文件、多服务、老代码库里的实际情况。同时这类评测只能证明模型在当前任务集上的表现并不等于模型的通用能力。任务集设计得越窄结论的泛化性越差。还需要明确使用边界。代码评测一定会执行生成的代码而生成代码可能有任意行为所以必须在 Docker 等隔离环境中运行不要直接在宿主机上执行。不要用公司私有代码、商业机密数据提交到外部评测服务或公开模型接口除非你确认数据不会被留存。涉及开源代码生成时也要检查是否触犯许可证和版权问题生成结果不能默认合入生产。3. 环境准备与前置条件如果只是想先跑通评测流程最低配置其实不高一台能装 Docker 的 Linux/macOS/Windows 机器即可内存建议 8G 以上磁盘至少留 20G。Windows 推荐用 WSL2 和 Docker Desktop避免路径和权限问题。Python 版本建议 3.10 以上git 是必装的。如果计划用本地模型做推理再准备 NVIDIA GPU12G 显存左右比较稳妥但具体占用要以模型和推理参数为准不要盲信网上任何一张显存截图。开始之前先做一轮环境检查。在终端执行docker --version python3 --version git --version三个命令都能正常输出版本号说明基础环境可用。如果 docker 命令不存在需要先安装 Docker如果 python3 版本过低建议用 pyenv 或 conda 管理版本。接下来确认 Docker 守护进程已经启动docker ps这条命令会列出当前容器列表。如果卡住或报错先解决 Docker 运行问题再继续后面的操作否则评测沙箱起不来所有任务都会失败。配置模型接口时建议把 API Key 放到环境变量里不要写死在代码中。Linux/macOS 可以这样设置export AI_API_URLhttps://api.example.com/v1/chat/completions export AI_API_KEYyour-api-keyWindows PowerShell 对应写法是$env:AI_API_URLhttps://api.example.com/v1/chat/completions $env:AI_API_KEYyour-api-key这里的 URL 和 Key 只是示例替换成你自己的模型服务地址即可。如果使用的是 OpenAI 官方接口同样遵循这个通用模式。接口地址、模型名、鉴权方式会因为服务商不同而变化建议先确认官方文档。4. 本地评测流程与启动方式下面给出一套通用评测流程。以真实仓库为准所有仓库名、路径、脚本名都需要替换。第一步拉取评测框架代码。假设评测仓库地址是 GitHub 上的某个公开仓库先克隆到本地git clone https://github.com/{org}/{repo}.git cd {repo} pip install -r requirements.txt第二步准备任务文件。评测任务通常用 JSONL 描述每行一个独立任务。下面是一个常见示例格式不代表具体评测框架的字段但可以帮你理解任务结构{task_id: task_001, instruction: Write a Python function to compute Fibonacci numbers., test: assert fib(10) 55}字段里至少要包含任务 ID、给模型的指令、以及用来验证结果的测试代码。更完整的任务集还会包含参考代码、环境依赖信息、超时时间等。第三步构建隔离执行环境。代码生成结果必须放在沙箱里运行最方便的办法是写一个 Dockerfile。下面是一个最小示例FROM python:3.11-slim WORKDIR /workspace RUN apt-get update apt-get install -y --no-install-recommends gcc g rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt ENV PYTHONDONTWRITEBYTECODE1这个镜像只安装了编译基础工具和 Python 依赖适合跑大多数纯 Python 评测任务。如果你的任务需要 Node、Java、Go 等环境在镜像里额外安装对应运行时即可。第四步运行评测。不同评测框架的启动命令不一样但思路类似都是指定任务文件、指定模型接口、指定输出目录。通用模板如下python run_eval.py \ --input tasks.jsonl \ --output results.jsonl \ --api-url $AI_API_URL \ --api-key $AI_API_KEY \ --model your-model-name \ --max-workers 4--max-workers控制并发数第一次建议设为 1先确认流程通畅再逐步提高。启动后日志会打印当前任务进度正常能看到“任务开始”“模型返回”“代码执行”“测试通过/失败”这类信息。如果服务启动失败优先检查三件事环境变量是否配置、任务文件 JSON 格式是否合法、Docker 是否可用。5. 功能测试与效果验证5.1 单任务代码生成测试第一次测试不要跑批量任务。挑一个最简单的函数级任务手动确认整个链路是否正常。输入示例{task_id: task_001, instruction: Write a Python function add(a, b) that returns a b., test: assert add(2, 3) 5}操作流程是运行评测脚本加载这一条任务模型调用接口返回一段代码评测框架把代码写入工作目录然后执行测试代码。判断成功的标准是测试最终返回通过并且日志里能看到task_001: PASS或等价输出。如果失败检查模型返回的代码是否是完整函数是否缺少 import是否有额外输出混入代码。这一步最重要。单任务跑通说明接口鉴权、任务格式、沙箱执行、结果判定四个环节都是通的。任何一个环节卡住都不要急着扩大任务量先把链路修好。5.2 多轮修复测试很多评测框架支持“生成代码→执行测试→失败信息反馈给模型→模型修复→再次执行”的多轮闭环。这个能力比单次生成更接近真实工程场景也是判断 Agent 是否“知道自己在做什么”的关键指标。以 5.1 的任务为例故意在测试里增加一个边界条件比如{task_id: task_002, instruction: Write a function fib(n) that returns the n-th Fibonacci number., test: assert fib(0) 0 and fib(1) 1 and fib(10) 55}如果第一轮生成的代码没处理 n0 的情况测试会失败。评测框架会把失败信息传回模型模型需要根据错误信息修改代码。判断成功的标准不是第一轮就通过而是在允许的轮数内最终通过。你需要重点观察模型在看到报错后是真正修正了逻辑还是反复输出同样的错误代码。后者是“AI 不知道自己在做什么”的典型表现。5.3 批量任务测试批量任务的价值在于把单点表现变成统计结论。准备一个包含几十条任务的 JSONL 文件每条任务难度可以分级。第一次批量任务建议控制在 10 条以内每条任务独立记录结果避免一个任务卡死影响全部。运行方式仍然复用 4.1 的评测脚本把输入文件换成批量任务文件。预期输出是一份结果文件里面包含每个任务的状态、生成代码、测试输出和耗时。批量任务跑完后统计通过率和平均耗时这就是当前模型在这份任务集上的基线数据。这里要留意一个坑并发数太高会导致模型接口被限流或返错任务看起来是“失败”实际上只是超时。更稳妥的做法是先跑 1 个并发记录基线耗时再逐步增加并发数对比失败率变化。5.4 结果判定与环境隔离结果判定逻辑本身也必须正确。不要只看模型是否输出了“我认为代码正确”而要看隐藏测试是否通过。测试环境要保持干净不能出现上一条任务留下的缓存文件、临时目录、环境变量污染。这也是为什么推荐用 Docker 容器做执行环境而不是直接在宿主机执行。对于复杂任务还可以把判定拆成多级指标。第一级是是否能运行、不报语法错误第二级是是否能通过基本测试第三级是是否能通过隐藏测试和边界测试第四级是代码风格、复杂度、可维护性。前两级适合自动化判定后两级需要人工或更严格的静态检查工具完成。5.5 稳定性观察同一批任务连续跑两次结果可能不一样因为模型推理有随机性评测框架也可能受网络波动影响。稳定性观察方法是固定同一份任务集、同一个模型、同样的并发参数连续跑三遍对比通过率的波动范围。如果三遍结果差异很大说明当前模型或评测流程不稳定不能作为正式基准数据。评测日志要包含完整上下文。每个任务至少记录模型返回的原始内容、写入的文件内容、测试执行输出、最终判定、耗时、重试次数。这样出问题时可以回溯是模型问题、网络问题还是测试代码问题。6. 接口 API 与批量任务6.1 OpenAI 兼容接口调用示例如果你不打算用完整的评测框架只想自己写脚本把模型接口和测试逻辑串起来可以直接调用 OpenAI 兼容接口。下面是一个最小可用的 Python 示例import requests import os API_URL os.getenv(AI_API_URL, https://api.example.com/v1/chat/completions) API_KEY os.getenv(AI_API_KEY, ) payload { model: your-model-name, messages: [ {role: system, content: You are a coding assistant.}, {role: user, content: Write a Python function to compute Fibonacci numbers.} ], temperature: 0.2, max_tokens: 1024 } headers {Authorization: fBearer {API_KEY}} response requests.post(API_URL, jsonpayload, headersheaders, timeout120) print(response.status_code) print(response.json()[choices][0][message][content])这里把 API_URL 设置为环境变量方便切换真实服务地址。需要注意不同兼容服务可能使用不同的路径前缀有些是/v1/chat/completions有些是/v1/responses请以实际服务商文档为准。6.2 批量任务脚本结构批量任务不只是用 for 循环把所有任务跑一遍还要考虑并发、失败重试和结果落盘。下面是一个通用批量脚本它从一个 JSONL 文件读取任务用线程池控制并发每个任务调用一次模型接口把结果写入另一个 JSONL 文件import json import requests from concurrent.futures import ThreadPoolExecutor, as_completed INPUT_FILE tasks.jsonl OUTPUT_FILE results.jsonl API_URL https://api.example.com/v1/chat/completions API_KEY your-api-key MAX_WORKERS 4 def run_task(task): payload { model: your-model-name, messages: [{role: user, content: task[instruction]}], temperature: 0.2, max_tokens: 1024, } headers {Authorization: fBearer {API_KEY}} try: response requests.post(API_URL, jsonpayload, headersheaders, timeout180) response.raise_for_status() content response.json()[choices][0][message][content] return {task_id: task[task_id], ok: True, result: content} except Exception as exc: return {task_id: task[task_id], ok: False, error: str(exc)} with open(INPUT_FILE, r, encodingutf-8) as f: tasks [json.loads(line) for line in f if line.strip()] results [] with ThreadPoolExecutor(max_workersMAX_WORKERS) as executor: futures [executor.submit(run_task, task) for task in tasks] for future in as_completed(futures): results.append(future.result()) with open(OUTPUT_FILE, w, encodingutf-8) as f: for result in results: f.write(json.dumps(result, ensure_asciiFalse) \n) print(fdone, total{len(results)})这个脚本的重点是失败不会中断整体流程。单个任务报错会被捕获并写入错误信息方便后面集中分析。真实的评测脚本还应该在请求失败时做指数退避重试避免瞬时网络抖动导致大量失败。6.3 结果落盘与二次判定模型接口返回的只是一段代码还需要二次判定。可以写一个独立的验证脚本从结果文件里读取生成代码写入临时文件然后用 pytest 或其他测试工具执行import subprocess import sys import json def verify_one(task_id, code, test_code): with open(solution.py, w, encodingutf-8) as f: f.write(code) with open(test_solution.py, w, encodingutf-8) as f: f.write(test_code) result subprocess.run( [sys.executable, -m, pytest, test_solution.py, -q], capture_outputTrue, textTrue, timeout30 ) return result.returncode 0, result.stdout result.stderr with open(results.jsonl, r, encodingutf-8) as f: lines [json.loads(line) for line in f if line.strip()] for item in lines: ok, log verify_one(item[task_id], item[result], item[test]) print(item[task_id], ok)在实际评测框架里二次判定往往直接集成到评测循环中不需要单独拆出来写。如果你是从零开始搭自动化评测系统这个拆法逻辑更清晰第一步拿到模型输出第二步把输出代码执行并判定两步分开跑便于排查问题。7. 资源占用与性能观察评测框架本身的资源消耗通常不高主要吃 CPU、内存和临时磁盘。Docker 容器里的代码编译和执行会占用少量 CPU任务集大或单任务运行时间长时内存会明显上涨。观察资源占用最直接的方式是docker stats这个命令会实时显示每个容器的 CPU、内存、网络和磁盘占用。如果某个容器内存持续飙升很可能是模型生成的代码有死循环或一次性加载了超大数据。此时除了加内存还要在评测配置里设置单任务超时时间。模型推理部分是资源消耗的大头。使用外部 API 时本机只承担网络请求不占 GPU。使用本地模型时推理由 GPU 完成可以用nvidia-smi观察显存占用watch -n 1 nvidia-smi通过率、耗时、显存占用这些指标会随着模型大小、并发数、输入输出 token 长度明显变化。建议每次评测都固定一组参数模型名、温度、max_tokens、并发数、超时时间。参数变了结果就不能直接横向比较。降低资源占用的通用手段包括降低并发数、减小 max_tokens、缩短任务输入、为容器设置内存限额。如果不做资源限制一个失控的任务可能会拖垮整台机器。Docker 启动容器时可以加参数docker run --memory4g --cpus2 --networknone your-eval-image--networknone表示禁用网络访问适合不需要联网的任务也避免生成代码在评测环境里访问外部资源。是否需要禁用网络取决于你的任务集设计不能一概而论。8. 常见问题与排查方法在搭建和运行评测流程时下面这些问题最容易遇到。问题现象可能原因排查方式解决方案接口调用一直失败API URL 或 Key 配置错误打印请求参数和响应状态码对照服务商文档修正 URL 和鉴权头Docker 镜像构建慢基础镜像过大或网络不稳定查看构建日志卡在哪一步换用更小的基础镜像固定版本号配置镜像加速容器启动后立刻退出任务缺少入口文件或权限不足查看容器日志检查任务工作目录和文件权限生成的代码无法执行模型输出了 Markdown 代码块或额外文字查看原始返回内容在写入文件前剥离代码块标记单任务被判定失败但人工看是对的测试代码条件过严或输出格式不符合预期打印测试输出和生成文件内容完善测试代码允许合理的输出差异批量任务大量超时并发数过高或接口限流查看错误信息中的超时状态降低并发数增加超时时间加入重试机制本地模型显存不足模型参数规模超过 GPU 显存用 nvidia-smi 查看实际占用换更小模型使用量化版本减小最大 token结果文件找不到输出路径配置错误或脚本中断检查运行时日志和当前工作目录使用绝对路径程序退出前 flush 结果排查问题有个基本原则先复现单条再分析批量。批量任务失败率异常时先挑出第一条失败任务单独运行把模型请求、代码生成、测试执行三个步骤拆开看。很多时候问题不是模型能力而是评测环境本身不够干净。还有一类问题是评测脚本常驻进程没有正常退出导致端口冲突或文件句柄占用。销毁容器和清理临时目录可以在评测脚本结束时统一处理。如果卡住可以用CtrlC中断主进程然后检查残留的 Python 和 Docker 容器。9. 最佳实践与使用建议第一第一次评测只用一个小任务集。目标不是“评测出最好模型”而是先确认整个链路可以稳定复用。建议准备 5 到 10 个任务覆盖正确性、边界条件、依赖安装三种情况。跑通之后再逐步扩大到 100 条、500 条。第二任务集要版本化。任务文件、评测脚本、依赖版本都要纳入 git 管理。否则过一段时间你改了几行测试代码旧的结果就失去了对比价值。每次跑批量评测时记录任务文件 hash 或版本号确保结果可追溯。第三代码执行必须隔离。无论评测代码是否可信都要在 Docker 容器中运行。不要为了省事直接在宿主机执行。容器要限制内存、CPU 和网络具体限制值根据任务需求调整。第四批量任务要有重试机制。模型接口偶发超时是正常的不要一失败就判定任务结果异常。对瞬时失败做 2 到 3 次重试并记录重试次数。重试仍失败的再标记为失败这样能避免统计结果被网络抖动污染。第五数据隐私和版权合规要前置。评测数据不要包含个人隐私、密码、内部业务信息。使用第三方模型接口前确认服务商是否会用你的数据做训练。生成代码用于生产环境前仍需要人工审查并确认代码没有复制受版权保护的内容。第六建立“基线”概念。每次评测都选一个固定模型作为基准先跑一遍得到基线通过率。后续换模型、换 Prompt、换任务集时都拿新结果和基线对比。没有基线的评测只能得出“好像能跑”得不出“是否变好”的结论。10. 总结与下一步回到开头那个标题OpenAI just proved AI has no idea what its doing。这句话的真正价值是逼着我们去回答一个更工程化的问题你如何判断一个 AI Agent 到底有没有在正确地做任务答案不是看演示视频也不是听厂商宣传而是设计一套可复现的评测流程把任务、代码执行、结果判定全部串起来。Codex Harness 这类开源评测框架的意义恰恰是把这套流程标准化让模型能力可以被量化、被对比、被回归。如果你是第一次尝试建议最先验证的不是复杂任务而是一个最简单的函数生成任务比如让模型生成一个add(a, b)函数。跑通单任务后再跑批量任务。最容易踩的坑有两个一是任务环境不干净导致测试通过与否和模型能力无关二是接口并发设置过高让统计结果被限流噪声污染。这两点都可以通过固定并发数、清理容器环境、增加日志来解决。下一步的扩展方向有三条。第一把评测流程接入 CI每次修改 Prompt 或换模型时自动跑回归测试。第二把任务集从纯函数级扩展到文件级、项目级验证 Agent 的多文件编辑能力。第三接入本地模型把 API 调用替换为本地推理服务在离线环境里做更频繁的迭代评测。先把一个任务跑通再把十个任务跑顺最后再把一百个任务跑稳。这套路径对任何想认真评估 AI 编程能力的团队都适用。希望这篇内容能帮你少走一些弯路。
