ClawEnvKit: Automatic Environment Generation for Claw-Like Agents

Paper: arXiv:2604.18543 Code: xirui-li/ClawEnvKit Code reference: main @ e7003442 (2026-05-07)

1. Motivation (研究动机)

现有 claw-like agents（如 OpenClaw、NanoClaw、IronClaw、Claude Code/MCP 类 harness）已经能在文件系统、API、web 服务等数字环境里执行多步任务，但“环境”本身仍主要靠人工构造：研究者要写 task prompt、准备 mock 数据、实现 grader、维护 sandbox，再逐个验证任务是否可解。这会带来三个瓶颈。

第一，训练数据和评测任务都被人工或真实用户流量卡住。OpenClaw-RL、MetaClaw 这类工作可以从真实用户轨迹里学习，但覆盖面取决于用户刚好做过什么；Claw-Eval、SkillsBench 等 benchmark 虽然更可控，但每个任务都需要人写题、写 rubric/判分逻辑，发布后任务分布也会固定，难以跟上 agent 能力迭代。

第二，传统 RL 环境形式不适合现代 agent。经典 MDP 假设可枚举的状态空间 $S$ ，但 agent 读邮件、查知识库、调用 API、处理文件时，状态由自然语言上下文、工具输出、历史轨迹共同决定，从 agent 视角几乎无限；从实现者视角，状态又只是少量 mock service 的内存数据库和 fixture。论文的关键观察是：不要让 LLM 生成完整状态转移系统，而是只生成“任务要做什么、能用什么、如何评分”。

第三，评测必须同时支持多种 harness，而不是只评测某个固定 agent loop。不同 claw-like agent 接入工具的方式不同：native plugin、MCP server、或把 SKILL.md + curl 写进 prompt。若 benchmark 只能跑一种接入方式，就无法判断性能差异来自 backbone model、agent harness 工程，还是任务本身。ClawEnvKit 试图把环境生成、执行、评分三件事解耦，从而让同一批环境可以横向比较多种 model 与 harness。

Figure 1 解读：这张总览图强调 ClawEnvKit 的三类价值：质量上接近或超过人工 benchmark，规模上可以从自然语言需求自动扩展，适配性上可以按需生成用户自己的环境；右侧则说明它不是只为某个单一 agent 写的评测，而是面向多 model family 与多 claw-based harness 的基础框架。

2. Idea (核心思想)

核心思想是把 agent 环境形式化为一个可由 LLM 可靠生成、可由程序可靠验证的三元组 $E = (P, M, C)$ ： $P$ 是自然语言任务规格， $M = (T, O)$ 是工具接口与服务端 audit log， $C$ 是一组带权重的评分组件。LLM 负责把自然语言需求翻译成任务、工具、fixture 和 scoring config；确定性 validator / GradingEngine 负责把不可控的生成结果筛掉，并用 audit log 给 agent 轨迹打分。

更具体地说，论文不是把“环境生成”理解成写一段 benchmark prompt，而是把环境拆成四个可组合的工程对象：mock service library、task YAML、fixture data、grading checks。只要这四个对象的接口稳定，新的自然语言需求就可以被实例化为新的任务分布；同一任务又能被不同 harness 以 native plugin、MCP、或 SKILL.md + curl 三种方式执行。这样，研究者可以把“agent 失败”继续分解成：任务生成质量问题、tool interface 问题、harness 工程问题、backbone model 问题或 grading 问题。

与 Claw-Eval / SkillsBench 的根本区别不是“再做一个 benchmark”，而是把 benchmark 构造过程本身自动化：Claw-Eval 给出的是固定的 104 个人工任务，ClawEnvKit 给出的是一个可以按目标分布反复实例化环境的 pipeline，并由此生成 Auto-ClawEval（1,040 个环境）和 Auto-ClawEval-Mini（104 个环境）。因此它的贡献更接近 base framework：未来某个团队想测试自己的 CRM、ticketing、calendar workflow，不必先人工写完整评测集，而可以先用自然语言给出任务分布，再让 ClawEnvKit 生成可执行环境并由 validator 过滤。

它也不同于只做 synthetic task generation 的方法：ClawEnvKit 不是只写 prompt，而是同时生成交互接口、mock service / fixture、scoring components、安全规则、sandbox 执行、agent-native harness 配置和结果收集；因此生成结果可以直接跑 evaluation 或 RL training，而不只是离线题目文本。

这个设计成立的关键直觉是：现代 agent 环境从 agent 视角很开放，但从评测者视角可以被“证据化”。只要每次工具调用都有服务端 audit log，grader 就不必相信 agent 自称完成了任务；只要 scoring config 明确列出哪些 action、字段、文件、输出关键词或 LLM-judge rubric 重要，评测就可以变成有限证据检查。ClawEnvKit 的自动化边界也正是在这里：它擅长生成可被有限证据验证的 API/file/mock-service 任务，但对真实外部状态、长周期人类审批、GUI/voice 交互等更开放任务仍然需要扩展。

3. Method (方法)

3.1 环境形式化：从无限状态转为声明式三元组

论文定义一个环境为： $E = (P, M, C)$ 其中 $P \in L$ 是自然语言任务规格； $M = (T, O)$ 是交互接口， $T$ 为可调用工具集合， $O$ 为服务端记录的 audit log； $C = {(c_{i}, w_{i})}$ 是 evaluation functional，每个 $c_{i} : Σ \times O \to [0, 1]$ 根据 agent 轨迹 $σ$ 和 audit log 判定某个性质，且 $\sum_{i} w_{i} = 1$ 。

基础环境分数为： $R (σ, E) = \sum_{i} w_{i} \cdot c_{i} (σ, O)$ 直觉上， $P$ 告诉 agent “要做什么”， $M$ 限定 agent “能做什么并留下什么证据”， $C$ 则说明“什么证据算成功”。这比让 LLM 直接写完整状态机更稳，因为验证逻辑只需要检查工具调用、输出文本、文件状态和有限 mock DB，而不需要建模所有可能自然语言状态。

Figure 2 解读：上半部分是 Environment Generation：从自然语言 specification 生成 $N$ 个环境，每个环境都包含 $P$ 、 $M$ 、 $C$ 。下半部分是执行闭环：sandbox 初始化、harness 准备、agent 执行、结果收集。右上角的 Performance Grading 将轨迹拆成 Safety、Completion、Robustness 三个维度，而不是只看一个 binary pass/fail。

3.2 Environment Generation：Parser → Generator → Validator

ClawEnvKit 的 generation 模块由三个 agent-like 组件组成，但最终产物必须落到可执行的 YAML / service / fixture / scoring config。

Parser：自然语言需求到 intent atoms

Parser 用一次 LLM 调用把用户请求解析成结构化 specification：需要哪些 service、难度、缺失服务、以及 intent atoms。atom 分为三类：action（必须执行的动作，如 create_event）、object（任务必须涉及的对象，如 attendees）、constraint（必须满足的约束，如不能删除已有事件）。这些 atoms 是后续 coverage validation 的锚点：如果用户说“发邮件并安排会议”，最终 task 里必须有对应工具、fixture 或 rubric 覆盖这两个要求。

Generator：生成 task、service 和 fixture

Generator 有三个子流程。Task generation 根据 service list、difficulty、domain、focus action 和已生成任务列表，让 LLM 生成 task.yaml，包含 task_id、prompt、tools、fixtures、scoring_components、safety_checks。Service generation 处理 mock service 库里不存在的新服务：设计 POST-only endpoint、FastAPI server、in-memory storage、audit logging，并在用户确认后注册进 library。Fixture generation 负责生成数据库、文档、OCR 图片、终端任务文件等，使 agent 在容器中看到的数据与 $P$ 精确对应。

Validator：格式、覆盖、可解性三重过滤

Validator 接受或拒绝生成环境，主要回答三类问题：

Format Check：字段是否完整、scoring 权重是否约等于 1、是否至少有一个 safety check、scoring 与 safety 是否自相矛盾。
Coverage Check：Parser 的每个 intent atom 是否在 task 中有对应证据。action 必须出现在 tools[].name 并被 scoring 或 llm_judge rubric 覆盖；object 必须出现在 fixture、prompt 或 rubric；constraint 必须由 safety 或 scoring/rubric 强制。
Feasibility Check：任务是否真的可解，例如不能要求 agent 获取不存在的“明天邮件”，也不能让 scoring 依赖 agent 无法访问的信息。

如果任何检查失败，系统最多重试 3 次生成；如果新 service 被生成，Validator 还会启动 server、访问 endpoint、确认 health check 通过后才注册。

Figure 3 解读：该图展开了生成端的关键结构：Parser 先把自然语言需求拆成 service、difficulty、intent atoms；Generator 再补全 task prompt、tools、fixtures、scoring components 和 safety checks；Validator 最后用 structural validation、coverage validation、feasibility validation 把不完整或不可解的环境退回重生。它的重点不是“LLM 一次性写对”，而是“LLM 生成 + 程序化约束 + 重试”形成可控 pipeline。

3.3 Execution：同一环境适配三层 harness

执行阶段把已验证的 $E = (P, M, C)$ 放进隔离容器中运行。每个任务容器使用 --network none，task.yaml 以只读方式挂载到 /opt/clawenvkit/task.yaml，fixture 文件挂载到 /workspace/，mock services 通过 uvicorn 在本地启动，health check 确认服务可用后再启动 agent。

ClawEnvKit 通过三层接入方式支持不同 claw-like agents：

Tier 1 Native Plugin：如 OpenClaw，通过 clawenvkit-eval plugin 注册原生工具。
Tier 2 MCP：如 Claude Code、NanoClaw、PicoClaw、ZeroClaw 等，启动 stdio MCP server 并写入对应 agent config。
Tier 3 SKILL.md + curl：如 CoPaw、NemoClaw、Hermes，把每个 endpoint 的 curl 示例写入 SKILL.md 并追加到任务 prompt。

所有工具调用最终都进入同一组 mock services，因此不同 harness 的差异主要来自 tool integration、prompting、agent loop 与错误恢复，而不是后端服务差异。

3.4 Performance Grading：Safety × Completion × Robustness

实验沿用 Claw-Eval 风格的 reward： $R (σ, E) = safety (σ) \times (0.8 \cdot completion (σ, C) + 0.2 \cdot robustness (σ, M))$ 其中： $completion (σ, C) = \sum_{i} w_{i} \cdot c_{i} (σ, O)$ $safety (σ) \in {0, 1}$ 是硬门控，一旦调用 forbidden tool 或输出 forbidden keyword，就把总分归零； $robustness$ 是注入错误后成功恢复的比例，论文 appendix 写作 $recovered / total_errors$ 。

GradingEngine 支持 15 类 scoring check：6 类 audit-based（如 audit_action_exists、audit_sequence），4 类 output-based（如 keywords_present、pattern_match），4 类 file-based（如 file_exists、pytest_pass），以及 llm_judge。llm_judge 使用 Claude Haiku，根据 rubric、agent final output、audit summary 给 $0.0, 0.3, 0.5, 0.7, 0.9, 1.0$ 六档分数；其总权重被限制在 API tasks 的 55% / file tasks 的 65%，保证多数评分仍由确定性检查承担。

Pass $^{3}$ 聚合要求同一任务的 3 次独立运行都达到默认阈值 0.5 才算 pass，并报告 mean score、min score 和三个维度的平均值。这抑制了 error injection 随机性导致的“单次幸运通过”。

3.5 Released code 对应的实现流程

Code reference: main @ e7003442 (2026-05-07) — pseudocode and mapping based on this commit

生成 pipeline 伪代码

from pathlib import Path
 
class ClawEnvKitPipeline:
    def generate_environment(self, request: str, output_dir: Path, api_key: str):
        parser = Parser()
        generator = Generator()
        validator = Validator()
 
        spec = parser.parse_intent(
            request=request,
            api_key=api_key,
            model="claude-haiku-4-5",
        )
 
        services = generator.resolve_services(
            services=spec.get("services"),
            category=spec.get("category", ""),
        )
 
        for attempt in range(3):
            prompt = generator.generate_task_prompt(
                services=services,
                difficulty=spec.get("difficulty", "medium"),
                existing_tasks=list_recent_task_names(output_dir, limit=10),
                focus_action=choose_next_action_for_diversity(services),
            )
            llm_response = call_generation_model(prompt)
            task_config = generator.ingest_task_config(
                llm_response=llm_response,
                services=services,
                atoms=spec.get("atoms", []),
                check_feasibility=True,
            )
 
            issues = validator.validate_task_config(task_config, services=services)
            issues += validator.verify_coverage(task_config, spec.get("atoms", []))
            issues += validator.verify_feasibility(task_config)
            if not issues:
                fixtures = generator.generate_fixtures(
                    category=task_config.get("category", ""),
                    topic=task_config.get("task_name", ""),
                    output_dir=output_dir / task_config["task_id"],
                )
                return task_config, fixtures
 
        raise RuntimeError("failed to generate a valid task after 3 attempts")

新 service 生成伪代码

def generate_missing_service(request: str, validator: Validator) -> Path:
    generator = Generator()
 
    for attempt in range(3):
        spec = generator.plan_service(request, max_retries=3)
        spec_issues = validator.validate_spec(spec)
        if spec_issues:
            request = request + "\nFix these service spec issues: " + repr(spec_issues)
            continue
 
        service_dir = generator.generate_service(spec, verify=True)
        server_issues = validator.validate_server(service_dir, spec, timeout=5)
        if not server_issues:
            generator.register_service(spec)
            return service_dir
 
    raise RuntimeError("service generation failed validation")

GradingEngine 伪代码

def grade(task_config: dict, audit_data: dict, agent_output: str, container_id: str | None):
    safety_violations = check_safety(task_config.get("safety_checks", []), audit_data, agent_output)
    safety = 0.0 if safety_violations else 1.0
 
    component_results = []
    for comp in task_config.get("scoring_components", []):
        check = comp["check"]
        score = run_check(check["type"], check, audit_data, agent_output, container_id)
        component_results.append({"score": score, "weight": comp.get("weight", 1.0)})
 
    total_weight = sum(x["weight"] for x in component_results)
    completion = 0.0 if total_weight == 0 else sum(
        x["score"] * x["weight"] for x in component_results
    ) / total_weight
 
    robustness = calculate_robustness_from_audit(audit_data)
    final_score = safety * (0.80 * completion + 0.20 * robustness)
    return final_score, completion, robustness, safety

Benchmark 执行伪代码

def evaluate_dataset(dataset_dir: Path, models: list[str], harness: str, workers: int = 1):
    results = {}
    for model in models:
        task_paths = sorted(dataset_dir.rglob("*.yaml"))
        model_results = parallel_map(
            lambda task_path: run_task_in_docker_harness(
                task_path=task_path,
                model=model,
                harness=harness,
                timeout_s=300,
                temperature=0,
                max_tool_rounds=20,
            ),
            task_paths,
            workers=workers,
        )
        results[model] = summarize_scores(model_results)
    return results

Paper Concept	Source File	Key Class / Function
Parser / intent atoms	`clawenvkit/generate/pipeline.py`, `clawenvkit/generate/intent_parser.py`	`Parser.parse_intent`, `parse_intent`
Task YAML generation	`clawenvkit/generate/task_generator.py`, `prompts/task_config_generation.md`	`generate_task_config_prompt`, `ingest_task_config`
Mock service generation	`clawenvkit/generate/service_generator.py`, `prompts/service_generation.md`	`plan_service`, `generate_service`, `validate_server`, `register_service`
Fixture generation	`clawenvkit/generate/fixture_generators.py`	`generate_fixtures`, `_generate_terminal_fixtures`, `_generate_test_image`
Validator / coverage	`clawenvkit/generate/task_generator.py`, `clawenvkit/compatibility/checker.py`	`validate_task_config`, `verify_coverage`, `verify_feasibility`, `run_checks`
GradingEngine	`clawenvkit/evaluate/engine.py`	`GradingEngine.grade`, `grade_pass3`, `_run_check`, `_check_safety`, `_calculate_robustness`
Dataset generation	`scripts/generate_dataset.py`	`build_plan`, `generate_api_tasks`, `generate_file_tasks`, CLI `--multiplier`, `--workers`
Harness evaluation	`scripts/evaluate.py`, `scripts/agent_loop_eval.py`	`Evaluator.run_model`, `AgentLoopEvaluator.run_one_task`, CLI `--timeout`, `--error-rate`
Tool integration	`mcp_server/mcp_server.py`, `extensions/clawenvkit-eval/index.ts`, `docker/*`	MCP server, OpenClaw plugin, harness Docker images

论文公式与 released code 实现差异：论文/appendix 描述 robustness 在“next five audit log entries”内找到同 action 的成功重试即算 recovered；clawenvkit/evaluate/engine.py 的循环是 range(i + 1, min(i + 5, len(entries)))，Python stop exclusive，因此最多检查后续 4 条记录。另一个需要注意的版本差异是：摘要和正文多处报告 Auto-ClawEval 使用 15 个 mock services，而 released code 的 SERVICE_DEFINITIONS 与 mock_services/ 当前包含 20 个 service（gmail, calendar, todo, contacts, helpdesk, notes, crm, inventory, scheduler, finance, rss, kb, config, ocr, caption, documents, web, web_real, web_real_injection, spotify）；笔记中的实验数字以论文表格为准，工程映射以 main@e7003442 为准。

4. Experimental Setup (实验设置)

4.1 数据集与规模

Dataset / Environment set	Scale	Purpose
Claw-Eval	104 human-written tasks	人工 benchmark，对照生成任务质量
Auto-ClawEval-Mini	104 generated environments，1 per Claw-Eval ID	与 Claw-Eval count-matched 对比，并作为低成本 proxy
Auto-ClawEval	1,040 generated environments，10 per Claw-Eval ID	大规模 cross-harness / cross-model 评测

论文报告 Auto-ClawEval 覆盖 24 semantic categories；正文称 15 mock services，appendix 与 released code 体现 20-service library。任务组成方面，appendix 给出近似比例：API-based 77%，file-dependent 23%；更细地说，single-service API tasks 约 370，cross-service API tasks 约 400，file-dependent tasks 约 270（terminal、OCR、document QA）。

4.2 Baselines / 对比对象

Benchmark-level 对比包括 ClawArena（64 tasks, human, binary grading）、ClawsBench（human, rubric）、SkillsBench（84 tasks, human, binary）、Claw-Eval（104 tasks, human, rubric）。Auto-ClawEval 是表 1 中唯一同时具备 auto-generated tasks、rubric grading、generalizability、safety eval、robustness eval 与 harness support 的环境集合。

Model-level 对比使用 4 个 family / 8 个模型：Claude Opus 4.6、Claude Sonnet 4.6、GPT-5.4、GPT-5-nano、GLM 5 Turbo、GLM 5、MiniMax M2.7、MiniMax M2.5。Harness-level 对比固定 backbone 为 Claude Haiku 4.5，评测 OpenClaw、Claude Code、NanoClaw、ZeroClaw、PicoClaw、CoPaw、NemoClaw、Hermes，以及 pseudo harness ReAct Agent Loop。

4.3 Metrics

Validity：结构校验是否通过；Auto-ClawEval-Mini 和 Claw-Eval 都为 100%。
Coherence：任务规格、工具接口、评分逻辑的一致性，LLM judge / structural format 共同衡量。
Clarity：任务 prompt 是否清晰可执行，表格中为 1—5 风格分数。
Safety / Completion / Robustness / Mean score：Safety 是硬门控，Completion 是 scoring components 加权平均，Robustness 是注入错误后的恢复比例，Mean score 是 $0.8$ completion + $0.2$ robustness 再乘 safety。
Efficiency：平均 tool calls、API cost 与 score 的关系，用于判断“工具接入多/贵”是否必然带来高分。

4.4 生成与评测配置

论文生成 Auto-ClawEval 时使用 claude-sonnet-4.6，报告 1,040 个环境约 $80 API cost；质量对比表显示 full Auto-ClawEval 生成耗时 18 h，Auto-ClawEval-Mini 1.8 h，而人工 Claw-Eval 估计 208 h。Released code 中 scripts/generate_dataset.py 的默认输出为 Auto-ClawEval-mini，--multiplier 默认 1，--workers 默认 1；要得到 full benchmark 的 10-per-ID 规模，需要对 base plan 做 multiplier expansion。

评测配置来自 appendix 与 released code：所有模型经 OpenRouter 的 OpenAI-compatible function-calling 接口调用，temperature 0，单次调用最多 4096 tokens，每个任务最多 20 tool-calling rounds。scripts/evaluate.py 默认 --timeout 300 秒、--workers 1；scripts/agent_loop_eval.py 默认 --error-rate 0.25。Mock service 的 25% POST requests 会注入错误，分布为 35% HTTP 429、35% HTTP 500、30% HTTP 200 with 2—4s delay。实验在单台 Apple M-series Mac + Docker Desktop 上运行，不需要 GPU。

5. Experimental Results (实验结果)

5.1 生成任务质量：接近或超过人工任务

Dimension	Claw-Eval	Auto-ClawEval	Auto-ClawEval-Mini
# Environments	104	1,040	104
# Services	19	15	15
# Categories	24	24	24
Validity	100%	100%	100%
Coherence	0.51	0.59	0.59
Clarity	3.38	3.54	3.52
Time	208 h	18 h	1.8 h

Auto-ClawEval-Mini 在任务数量上与 Claw-Eval 相同，但 coherence 从 0.51 提升到 0.59，clarity 从 3.38 提升到 3.52；full Auto-ClawEval clarity 为 3.54。论文解释 coherence 差距来自结构化 task format：显式 tool list 和 scoring components 让 $P \leftrightarrow M \leftrightarrow C$ 更容易被 judge 检查，而人工 Claw-Eval 的 rubric 藏在 task-specific grader 代码里。

5.2 Model scaling：Completion 是主要短板

Family	Model	Auto-ClawEval Safety	Completion	Robustness	Mean	Mini Mean
Claude	Opus 4.6	87.3	49.7	100.0	52.4	52.1
Claude	Sonnet 4.6	90.3	50.0	100.0	53.7	54.2
GPT	GPT-5.4	91.0	56.7	100.0	58.8	56.5
GPT	GPT-5-nano	93.3	48.9	100.0	54.9	55.7
GLM	GLM 5 Turbo	89.0	46.2	100.0	49.8	50.3
GLM	GLM 5	90.2	45.3	100.0	50.1	51.3
MiniMax	MiniMax M2.7	90.5	43.8	100.0	49.4	44.9
MiniMax	MiniMax M2.5	93.0	35.5	100.0	43.6	51.4

GPT-5.4 在 full Auto-ClawEval 上最高，Mean 为 58.8；MiniMax M2.5 full Mean 最低，为 43.6。更重要的是，Safety 与 Robustness 基本接近满分，而 Completion 从 35.5 到 56.7 大幅变化，说明当前 frontier agents 主要不是“危险”或“不会 retry”，而是没有完成复杂多步任务。

5.3 Harness engineering：最高带来 15.7 个点提升

Harness	Tier	Auto-ClawEval Safety	Completion	Robustness	Mean score	Mini Mean
OpenClaw	1	93.8	61.3	100.0	64.2	64.2
Claude Code	2	94.7	64.1	100.0	67.0	66.5
NanoClaw	2	94.6	60.1	100.0	63.7	67.8
ZeroClaw	2	94.6	51.4	100.0	57.1	54.9
PicoClaw	2	91.2	48.3	100.0	53.2	50.0
CoPaw	3	89.7	61.5	100.0	60.8	59.3
NemoClaw	3	87.5	74.2	100.0	69.0	67.9
Hermes	3	87.6	71.1	100.0	66.9	66.5
ReAct Agent Loop	-	95.4	38.3	100.0	53.3	51.7

所有 structured harness 都超过 ReAct Agent Loop 的 53.3。NemoClaw 达到 69.0，比 ReAct 高 15.7 点；Hermes 66.9、Claude Code 67.0 也明显领先。一个反直觉结果是 tier 并不严格决定性能：Tier 3 的 NemoClaw / Hermes 超过若干 Tier 2 MCP harness，说明 prompt/tool-use policy 与 task interaction pattern 可能比“原生工具接入等级”更关键。

Figure 6 解读：violin plot 显示 ReAct Agent Loop 的分数主要堆在 0.4—0.6，structured harness 的分布整体右移并在 1.0 附近形成更尖的峰。这意味着 harness engineering 不只是平均分略升，而是增加了“完全解决任务”的比例。

5.4 Full benchmark 与 Mini proxy 一致

论文报告 Auto-ClawEval 与 Auto-ClawEval-Mini 在所有 model / harness 上差异都小于 2%，说明 104-task Mini 可以作为低成本 proxy。这个结论支持自动生成环境的一个核心卖点：同一个 generation pipeline 可以在小规模上做快速迭代，在大规模上做最终评测，而不明显改变排名或难度分布。

5.5 类别难度、工具调用与成本效率

Figure 4 解读：heatmap 展示 8 个 harness 在 34 个 service combinations（C01—C34）上的平均分。C16 在所有 harness 上都难（约 10—71%），C21 和 C32 则稳定高于 85%。这说明 aggregate score 接近的 harness 仍可能有完全不同的错误模式，因此 Auto-ClawEval 可用于定位 agent 在特定任务类别上的薄弱点。

Figure 5a–5b 解读：左图把 harness 平均分与每任务平均 tool calls 对齐，说明更多 tool calls 或更深接入层级并不必然带来更高分，Pareto frontier 上混合了不同 tier 的 harness；右图把 model 成本与表现放在一起，论文指出 GPT-5.4 最强，而 GPT-5-nano 更偏经济选择。

5.6 Live evaluation：从静态 benchmark 到按需生成

Figure 7 解读：live testbed 展示用户只需描述一个工作流，ClawEnvKit 就能提出 endpoint、交互式补齐缺失 service，并生成可执行 task environment。这把评测从“论文作者发布固定任务集”变成“用户按自己的长尾需求生成验证环境”，也让正在开发中的服务可以提前纳入 agent evaluation。

5.7 False negative 与局限

论文对 high-effort low-score cases 做了人工检查：定义为 $\geq 10$ 次 tool calls 但 final score $< 0.4$ 的轨迹，共 52 例。根因分布为：wrong parameter name 导致 HTTP 422：43 例（82.7%）；error injection 429 后没有 retry：5 例（9.9%）；其他执行错误：4 例（7.4%）；真正被 grader 错罚的 alternative solution：0 例（0%）。作者据此认为 declarative scoring 没有系统性惩罚有效替代解。

局限也很明确：第一，mock services 仍然比真实 API 简单，缺少真实 OAuth、subscription-specific rate limit、schema drift、真实外部状态等复杂性；第二，24 类任务仍不足以覆盖 voice interfaces、GUI automation、multi-agent delegation、法律/医疗/金融等专业工作流；第三，当前任务被设计在 20 tool-calling rounds 内完成，不适合跨小时/天、有 human-in-the-loop checkpoint、持久状态的 long-horizon workflows。

Paper Notes

探索

ClawEnvKit: Automatic Environment Generation for Claw-Like Agents

ClawEnvKit: Automatic Environment Generation for Claw-Like Agents

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 环境形式化：从无限状态转为声明式三元组

3.2 Environment Generation：Parser → Generator → Validator

Parser：自然语言需求到 intent atoms

Generator：生成 task、service 和 fixture

Validator：格式、覆盖、可解性三重过滤

3.3 Execution：同一环境适配三层 harness

3.4 Performance Grading：Safety × Completion × Robustness

3.5 Released code 对应的实现流程

生成 pipeline 伪代码

新 service 生成伪代码

GradingEngine 伪代码

Benchmark 执行伪代码

4. Experimental Setup (实验设置)

4.1 数据集与规模

4.2 Baselines / 对比对象

4.3 Metrics

4.4 生成与评测配置

5. Experimental Results (实验结果)

5.1 生成任务质量：接近或超过人工任务

5.2 Model scaling：Completion 是主要短板

5.3 Harness engineering：最高带来 15.7 个点提升

5.4 Full benchmark 与 Mini proxy 一致

5.5 类别难度、工具调用与成本效率

5.6 Live evaluation：从静态 benchmark 到按需生成

5.7 False negative 与局限

目录