最近在AI圈子里，一个名为“F1×Rosé”的项目悄然走红，它并非什么新的偶像组合，而是一个将传统AI评测基准推向新高度的创新工具。如果你正在开发或评估一个大型语言模型（LLM），并且厌倦了那些要么过于简单、要么脱离真实场景的评测榜单，那么这个项目很可能就是你一直在寻找的答案。

传统的AI评测，无论是MMLU、GSM8K还是HumanEval，大多基于静态的、孤立的问答对。模型在这些测试上取得高分，并不意味着它在处理复杂的、多步骤的、需要动态信息整合的真实世界任务时同样出色。这就好比一个学生能在标准化考试中拿满分，却未必能完成一个需要调研、协作和创造性解决实际问题的毕业设计。

“F1×Rosé”的核心价值，正是试图弥合这一“考场”与“职场”之间的鸿沟。它不是一个单一的测试集，而是一个基于真实世界复杂任务的、可编程的、多智能体协作的评测框架。简单来说，它让AI模型不再只是“答题”，而是去“完成一个项目”。本文将深入解析F1×Rosé的设计理念、核心原理，并通过一个完整的实战示例，手把手带你搭建环境、运行评测，并理解其结果对于LLM能力评估的深刻意义。

1. F1×Rosé 要解决的根本问题：为什么传统评测不够用了？

在深入技术细节之前，我们必须先理解现有评测体系的局限性，这能让我们更清楚地看到F1×Rosé的革新之处。

传统评测的三大短板：

1. 静态与孤立：问题通常是封闭的，有标准答案。模型只需从内部知识中提取或进行单步推理。而真实用户需求是动态的、开放的，需要模型主动规划、搜索、验证。
2. 缺乏环境交互：模型像一个“闭卷考试”的考生，无法使用计算器、浏览器、API或文件系统等“外部工具”。现实中，一个强大的AI助手必须懂得利用工具来扩展自身能力边界。
3. 单一智能体假设：评测默认只有一个模型在工作。但复杂任务往往需要分工协作，例如，一个智能体负责规划，一个负责搜索，一个负责编写代码，另一个负责审核。这模仿了人类团队的工作模式。

F1×Rosé的提出者认为，下一代LLM的评测必须模拟软件工程师完成一个真实功能需求的全过程。这个过程是怎样的？接收一个模糊的需求（Issue），理解上下文，查阅文档（检索），设计解决方案（规划），编写代码（执行），运行测试（验证），并最终提交成果。这个过程天然是动态的、工具驱动的、多步骤的。

因此，F1×Rosé的核心理念是：将LLM置于一个接近真实软件开发的环境（通常是代码仓库）中，赋予其执行命令、读写文件、调用API的能力，然后要求它完成一个具体的、可验证的Github Issue。通过最终的任务完成度（如Issue是否被关闭、测试是否通过）来客观评价模型的能力。

这不仅仅是换个题目那么简单，它意味着评测范式从“知识问答”转向了“任务完成”，评估重点从“输出准确性”转向了“工程有效性”。

2. 核心概念与架构拆解

理解F1×Rosé，需要掌握几个关键概念，它们共同构成了这个评测框架的骨架。

2.1 核心组件

• 任务（Task）： 评测的基本单元，通常对应一个Github仓库中的一个具体Issue。例如，“为项目添加一个用户登录日志功能”或“修复某个单元测试失败的问题”。任务定义了起点（仓库状态）和成功标准（如Issue关闭、PR合并、测试通过）。
• 环境（Environment）： 一个隔离的、可重现的沙箱，通常是Docker容器。模型在其中运行，拥有对文件系统、shell命令、特定端口等的访问权限。环境保证了每次评测的起跑线一致，也隔离了模型操作可能带来的风险。
• 智能体（Agent）： 执行任务的LLM。它接收环境状态（如当前文件列表、Issue描述），经过思考，输出要执行的动作（Action）。智能体可以配置不同的底层模型（如GPT-4、Claude、DeepSeek）。
• 动作（Action）与工具（Tool）： 智能体与环境交互的方式。基础动作包括：
  • run_shell： 执行shell命令（如git clone,npm install,pytest）。
  • read_file： 读取文件内容。
  • write_file： 创建或修改文件。
  • browse_web： 模拟网页浏览（用于搜索文档）。
  • ask_human： 在遇到模糊点时向“人类”寻求澄清（在评测中通常有预设答案或超时跳过）。F1×Rosé定义了一套丰富的工具集，智能体可以像调用函数一样组合使用它们。
• 评测器（Evaluator）： 判断任务是否成功的模块。它可以是简单的规则（如“包含特定字符串的文件被创建”），也可以是复杂的程序化检查（如“运行项目的测试套件，全部通过”）。

2.2 工作流程

一个典型的F1×Rosé评测运行流程如下：

1. 初始化： 根据任务描述，准备一个干净的Docker环境，并将任务相关的代码仓库克隆到环境中。
2. 循环执行： a.观察： 将当前环境的状态（工作目录、文件树、之前动作的结果）格式化后，输入给智能体（LLM）。 b.思考： 智能体分析当前状态和任务目标，决定下一步要做什么。它可能会生成一个复杂的计划，但每次只输出一个具体的动作。 c.执行： 框架执行该动作（如在shell中运行命令），并捕获输出（stdout, stderr, return code）。 d.验证： 检查动作执行结果，更新环境状态。同时，评测器检查是否已满足任务成功的条件。
3. 终止： 当任务成功、失败（如超时、出现致命错误）或达到最大步骤限制时，循环结束，并输出最终评分和详细的执行轨迹（Trace）。

2.3 与相关概念的对比

为了更清晰定位，我们将其与类似项目对比：

简而言之，F1×Rosé在灵活性和对综合智能的评测深度上更胜一筹，它试图在一个框架内覆盖从简单文件操作到复杂软件开发的连续光谱。

3. 环境准备与快速开始

现在，让我们动手搭建一个可以运行F1×Rosé评测的环境。由于项目涉及在隔离环境中执行任意命令，Docker是必须的。

3.1 系统与软件要求

• 操作系统： Linux (Ubuntu 20.04+ 推荐) 或 macOS。Windows用户建议使用WSL2。
• Docker： 必须安装并运行。确保当前用户有执行docker命令的权限（通常在docker用户组中）。
• Python： 版本 3.9 或 3.10。推荐使用虚拟环境（venv或conda）。
• Git： 用于拉取代码和任务仓库。
• API密钥： 你需要一个支持的LLM API密钥，例如OpenAI的GPT-4。我们将以OpenAI为例。

3.2 安装F1×Rosé

项目通常以Python库的形式提供。我们通过pip安装其开源实现（这里以一个典型的开源项目f1-rose为例，实际项目名称可能不同，请以官方仓库为准）。

# 1. 创建并激活Python虚拟环境 python -m venv f1rose-env source f1rose-env/bin/activate # Linux/macOS # 对于Windows: f1rose-env\Scripts\activate # 2. 升级pip pip install --upgrade pip # 3. 安装f1-rose核心库及其基础依赖 # 注意：以下包名和版本为示例，请根据实际项目文档调整 pip install f1rose-core # 4. 安装额外的环境管理依赖（如果项目需要） pip install docker python-on-whales

3.3 配置LLM API密钥

框架需要知道如何调用你的LLM。创建一个配置文件或设置环境变量。

方式一：环境变量（推荐用于测试）

export OPENAI_API_KEY="sk-your-actual-openai-api-key-here" # 如果使用其他模型，如Anthropic Claude # export ANTHROPIC_API_KEY="your-claude-key"

方式二：配置文件创建一个config.yaml文件：

# config.yaml llm: provider: "openai" api_key: "sk-your-actual-openai-api-key-here" model: "gpt-4-turbo" # 指定使用的模型

3.4 验证安装

运行一个简单的检查命令，确保核心组件能正常工作。

python -c "import f1rose; print(f1rose.__version__)" # 假设有版本属性

如果导入成功，说明基础环境已就绪。

4. 运行你的第一个评测任务

我们从一个最简单的“Hello World”式任务开始，目标是让智能体在沙箱中创建一个文件并写入特定内容。这个任务不涉及外部仓库，适合验证整个流程。

4.1 创建任务定义文件

F1×Rosé的任务通常用一个YAML文件定义。我们创建task_hello.yaml：

# task_hello.yaml name: "hello_world_demo" description: "Create a file named greeting.txt with content 'Hello from F1×Rosé!'" success_criteria: - type: "file_exists_and_contains" path: "/workspace/greeting.txt" content: "Hello from F1×Rosé!" environment: image: "ubuntu:22.04" # 使用一个干净的基础镜像 workspace: "/workspace" # 可以在这里预装一些软件，如git, python setup_commands: - "apt-get update && apt-get install -y curl"

这个任务定义：

1. name/description: 任务标识和描述。
2. success_criteria: 成功标准。这里检查文件是否存在且内容完全匹配。
3. environment: 定义Docker环境。我们从ubuntu:22.04镜像启动，工作目录是/workspace，并在启动时运行setup_commands来安装curl（演示用）。

4.2 编写评测运行脚本

创建一个Python脚本run_eval.py来加载任务并运行智能体：

# run_eval.py import asyncio import os from f1rose import Task, Environment, Agent, OpenAIAgent # 假设的导入路径 from f1rose.llm import OpenAILLM async def main(): # 1. 加载任务定义 task = Task.from_yaml("task_hello.yaml") # 2. 初始化LLM（使用环境变量中的API_KEY） llm = OpenAILLM(model="gpt-4-turbo") # 3. 创建智能体，将LLM赋予它 agent = OpenAIAgent(llm=llm, name="demo_agent") # 4. 创建环境 env = Environment.from_task(task) print(f"开始任务: {task.name}") print(f"任务描述: {task.description}") # 5. 运行智能体直到任务完成或失败 try: await env.run(agent, max_steps=20) # 最多执行20步 except Exception as e: print(f"任务执行异常: {e}") # 6. 获取并打印结果 result = env.get_result() print(f"\n任务状态: {result.status}") # 应为 SUCCESS, FAILURE, TIMEOUT print(f"使用步数: {result.steps_used}") print(f"最终输出: {result.final_output}") # 7. 清理环境（可选） await env.close() if __name__ == "__main__": asyncio.run(main())

4.3 执行并观察

在终端运行脚本：

python run_eval.py

你将看到类似以下的输出（具体步骤可能因模型随机性而异）：

开始任务: hello_world_demo 任务描述: Create a file named greeting.txt with content 'Hello from F1×Rosé!' [STEP 1] 智能体思考: 我需要创建一个文件。首先，我看看当前目录。 动作: run_shell `pwd` 结果: /workspace [STEP 2] 智能体思考: 我在正确的工作目录。现在创建文件。 动作: run_shell `echo 'Hello from F1×Rosé!' > greeting.txt` 结果: (命令成功，无输出) [STEP 3] 智能体思考: 验证文件是否创建成功。 动作: run_shell `cat greeting.txt` 结果: Hello from F1×Rosé! [STEP 4] 评测器检查成功标准... 通过！ 任务状态: SUCCESS 使用步数: 3 最终输出: 成功创建文件 greeting.txt。

恭喜！你刚刚完成了一次完整的F1×Rosé评测。智能体自主理解了任务，规划了步骤（检查目录 -> 创建文件 -> 验证），并成功使用了shell工具。

5. 实战：评测LLM修复开源Bug的能力

现在我们来挑战一个更真实的任务：让智能体修复一个开源Python项目中的简单Bug。我们以一个虚构的仓库为例，假设其中有一个计算器程序，但乘法函数有误。

5.1 准备任务仓库

首先，我们创建一个有Bug的本地仓库来模拟真实场景。

# 创建一个临时目录作为我们的“开源项目” mkdir -p /tmp/calculator_repo cd /tmp/calculator_repo git init # 创建有Bug的Python文件 cat > calculator.py << 'EOF' def add(a, b): return a + b def subtract(a, b): return a - b def multiply(a, b): # Bug: 这里错误地使用了加法 return a + b def divide(a, b): if b == 0: raise ValueError("Cannot divide by zero") return a / b if __name__ == "__main__": # 简单的测试 print(f"2 + 3 = {add(2, 3)}") print(f"5 - 1 = {subtract(5, 1)}") print(f"4 * 3 = {multiply(4, 3)}") # 这里会输出错误结果 7 print(f"10 / 2 = {divide(10, 2)}") EOF # 创建一个单元测试文件（可选，但更真实） cat > test_calculator.py << 'EOF' import unittest from calculator import multiply class TestCalculator(unittest.TestCase): def test_multiply(self): self.assertEqual(multiply(4, 3), 12) self.assertEqual(multiply(0, 5), 0) self.assertEqual(multiply(-2, 3), -6) if __name__ == '__main__': unittest.main() EOF # 提交代码 git add . git commit -m "Initial commit with buggy multiply function"

5.2 创建复杂的任务定义

现在，我们定义一个任务：智能体需要克隆这个仓库，发现Bug，并修复它。我们通过单元测试来验证修复是否成功。

# task_fix_bug.yaml name: "fix_calculator_bug" description: | The `multiply` function in `calculator.py` has a bug where it performs addition instead of multiplication. Clone the repository, identify the bug, fix the `multiply` function, and ensure the existing unit tests pass. The repository URL is a local path: /tmp/calculator_repo. success_criteria: - type: "command_succeeds" command: "cd /workspace/repo && python -m pytest test_calculator.py -v" # 期望测试全部通过 environment: image: "python:3.9-slim" workspace: "/workspace" setup_commands: - "pip install pytest" # 确保测试框架存在 # 将本地仓库挂载到环境中（在真实评测中，这里会是git clone一个远程仓库） assets: - source: "/tmp/calculator_repo" target: "/workspace/repo" max_steps: 30 # 给予更多步骤进行代码分析和修改

5.3 创建支持代码查看与编辑的智能体

基础智能体只能运行命令。为了更高效地处理代码任务，我们需要赋予它read_file和write_file工具。修改我们的运行脚本：

# run_fix_bug.py import asyncio from f1rose import Task, Environment from f1rose.agents import OpenAIAgent from f1rose.llm import OpenAILLM from f1rose.tools import ShellTool, FileReadTool, FileWriteTool # 导入文件工具 async def main(): task = Task.from_yaml("task_fix_bug.yaml") llm = OpenAILLM(model="gpt-4-turbo") # 创建工具集 tools = [ ShellTool(), FileReadTool(), FileWriteTool() ] # 将工具集赋予智能体 agent = OpenAIAgent(llm=llm, tools=tools, name="code_fixer_agent") env = Environment.from_task(task) print(f"开始复杂任务: {task.name}") result = await env.run(agent, max_steps=task.max_steps) print(f"\n=== 任务结束 ===") print(f"状态: {result.status}") print(f"步数: {result.steps_used}") if result.status == "SUCCESS": print("✅ Bug修复成功！单元测试已通过。") else: print("❌ 任务失败。") print(f"最后错误: {result.error}") # 输出执行轨迹以供分析 print(f"\n=== 关键执行步骤 ===") for i, step in enumerate(result.trajectory[-5:]): # 看最后5步 print(f"[Step {step.step_id}] {step.thought[:100]}...") print(f" 动作: {step.action}") print(f" 结果: {step.observation[:200]}...\n") await env.close() if __name__ == "__main__": asyncio.run(main())

5.4 运行并分析结果

执行脚本：

python run_fix_bug.py

一个成功的执行轨迹可能如下：

开始复杂任务: fix_calculator_bug [STEP 1] 智能体思考: 首先，探索工作空间，找到仓库。 动作: run_shell `ls -la /workspace` 结果: 显示 repo 目录。 [STEP 2] 智能体思考: 进入仓库目录，查看文件。 动作: run_shell `cd /workspace/repo && ls` 结果: calculator.py test_calculator.py [STEP 3] 智能体思考: 阅读问题描述和代码。先看主文件。 动作: read_file `/workspace/repo/calculator.py` 结果: (显示 calculator.py 的完整内容) [STEP 4] 智能体思考: 发现 multiply 函数逻辑错误。查看测试文件以理解预期行为。 动作: read_file `/workspace/repo/test_calculator.py` 结果: (显示测试用例，明确说明 multiply(4,3) 应返回12) [STEP 5] 智能体思考: 运行现有测试，确认失败。 动作: run_shell `cd /workspace/repo && python -m pytest test_calculator.py -v` 结果: 显示测试失败，AssertionError: 7 != 12 [STEP 6] 智能体思考: 现在修复 multiply 函数。将加法改为乘法。 动作: write_file `/workspace/repo/calculator.py` 内容: (将 `return a + b` 修改为 `return a * b`，其他部分不变) [STEP 7] 智能体思考: 再次运行测试，验证修复。 动作: run_shell `cd /workspace/repo && python -m pytest test_calculator.py -v` 结果: 显示3个测试用例全部通过。 [STEP 8] 评测器检查成功标准（运行测试的命令）... 通过！ === 任务结束 === 状态: SUCCESS 步数: 7 ✅ Bug修复成功！单元测试已通过。

这个例子展示了F1×Rosé评测的核心魅力：智能体像一名真正的开发者一样，主动探索环境、阅读代码、理解问题、运行测试、定位Bug、实施修复并最终验证。整个过程是动态的、基于反馈的，而非一次性生成答案。

6. 结果解读与模型能力评估

运行完评测后，我们得到的不仅仅是一个“成功/失败”的标签。F1×Rosé会生成详细的执行轨迹（Trace），这是评估模型能力的金矿。

6.1 关键评估维度

1. 任务成功率（Success Rate）： 最直接的指标，在多个任务上计算成功比例。
2. 平均步数（Average Steps）： 衡量效率。步数越少，通常说明模型的规划能力越强、越精准。但需注意，有些复杂任务本身就需要更多步骤。
3. 工具使用模式（Tool Usage Pattern）：
   • 探索效率： 是否盲目运行ls、cat多次？还是能快速定位关键文件？
   • 规划合理性： 步骤顺序是否符合逻辑？例如，是先读代码再运行测试，还是反过来？
   • 纠错能力： 当动作失败（如命令错误）时，模型是否能理解错误信息并调整策略？
4. 代码修改质量： 对于编码任务，修复是否精准？是否引入了不必要的改动或新的Bug？
5. 人类求助频率： 如果配置了ask_human工具，模型在何时、因何问题求助，反映了其对不确定性的认知和边界判断能力。

6.2 如何分析轨迹日志

轨迹日志是JSON格式的详细记录。你可以从中提取洞察：

• 死胡同与回溯： 观察模型是否陷入无效循环（如反复修改同一行代码但测试仍失败），这反映了其推理和调试能力的局限性。
• 对错误信息的理解： 当pip install失败或测试报错时，模型是否能从stderr中提取关键信息并采取正确行动？
• 长期规划能力： 模型是否在一开始就有一个大致计划，还是走一步看一步？查看其早期的“思考”内容可以判断。

7. 常见问题、错误与排查指南

在运行F1×Rosé评测时，你可能会遇到一些典型问题。下表列出了常见问题及其解决方法：

8. 最佳实践与高级应用建议

当你熟悉基础操作后，以下实践能帮助你更专业地使用F1×Rosé进行评测和研究。

8.1 任务设计原则

• 明确性： 任务描述必须清晰、无歧义。好的描述应像一份合格的开发工单。
• 可验证性： 成功标准必须是客观、可自动判定的。优先使用“运行测试通过”、“生成特定文件”等标准，避免模糊的“代码质量高”。
• 渐进性： 从简单任务（如文件操作）开始，逐步增加复杂度（如修复Bug、添加功能、集成API）。
• 多样性： 设计涵盖不同领域的任务，如前端（修改CSS）、后端（修复API）、数据（处理CSV）、系统（配置服务）等，以全面评估模型。

8.2 智能体与提示工程

• 系统提示词（System Prompt）： 这是智能体的“角色设定”和“行为准则”。一个好的提示词应包含：
  • 角色定义（“你是一个资深软件工程师”）。
  • 目标说明（“你的目标是通过执行命令和编辑文件来完成给定任务”）。
  • 行动规范（“每次只做一个明确的动作”，“在修改关键文件前先备份”）。
  • 工具使用说明（“你可以使用run_shell, read_file, write_file等工具”）。
• 思维链（Chain-of-Thought）鼓励： 在提示词中要求模型“逐步思考”，并在动作前输出思考过程。这不仅能提升表现，也使轨迹日志更易分析。
• 多智能体协作： F1×Rosé框架支持部署多个智能体，让它们通过共享环境或消息队列进行协作。你可以设计“架构师”、“开发”、“测试”等角色，评测其协作效率。

8.3 工程化与大规模评测

• 任务套件（Benchmark Suite）： 不要只运行单个任务。创建一组具有代表性的任务（如10-100个），并计算整体成功率、平均步数等统计指标。
• 并行运行： 使用异步IO或任务队列并行运行多个评测任务，以节省时间。注意管理好API的速率限制。
• 结果分析与可视化： 将每次运行的轨迹和结果保存到数据库（如SQLite）或文件中。然后进行分析，生成模型在不同任务类型上的能力雷达图、工具使用热力图等。
• 版本控制： 对任务定义、智能体提示词和评测脚本进行Git版本控制，确保实验的可复现性。

8.4 安全与成本控制

• 沙箱隔离：永远不要在非Docker环境或生产环境中运行未经信任的模型和任务。F1×Rosé的Docker沙箱是安全底线。
• 资源限制： 为Docker容器设置CPU、内存和运行时间限制，防止恶意或错误任务耗尽资源。
• API成本监控： 使用LLM API是主要成本。在运行大规模评测前，用小任务估算单次调用的平均token消耗，并设置预算警报。
• 敏感信息： 任务中避免包含真实的API密钥、密码或敏感代码。使用环境变量或占位符。

F1×Rosé代表了一种更接近本质的AI能力评估方向——在动态、交互、工具丰富的环境中解决实际问题。它不再问模型“你知道什么”，而是问“你能做什么”。对于LLM开发者，它是检验模型工程实用性的试金石；对于研究者，它是探索智能体规划、工具使用和长期推理的绝佳实验平台；对于普通开发者，它提供了一个直观的视角，去理解当前AI助手的实际能力边界在哪里。

要真正掌握它，最好的方法就是亲手运行它。从本文的“Hello World”示例开始，尝试设计一个属于自己的小任务，比如“让智能体配置一个Nginx服务器”或“从API获取数据并生成图表”。在观察智能体挣扎、思考、最终成功或失败的过程中，你会对AI的现状与未来产生比阅读任何榜单都更深刻的认识。