Prime Intellect 开源 General Agent 自演化合成智能体环境

General Agent：一个自我进化、合成式的智能体环境

训练有能力的智能体需要在整个后训练流程中接触多样化的任务和工具。然而，在开源社区中，能够接触数千种工具的智能体环境仍然稀缺。

今天，我们开源了 general-agent 环境的第一个版本（Environments Hub）——一个完全合成的环境，能够随时间推移让其任务语料库变得更加多样化和更具挑战性。它将合成任务创建形式化为两个智能体之间的双人博弈：

• Synthesizer —— 一个负责合成新任务的智能体；遵循明确定义的任务模式和合成流程，并采用多种机制来确保可解性、多样性和难度。
• Solver —— 一个负责求解任务实例的智能体。

合成器智能体按难度层级设计并演化出新颖的任务族。每个层级都通过让求解器对其运行来进行实证验证——只有通过率落在校准难度区间内的任务才会被接受。高难度层级会为下一波扩展提供种子，使语料库随时间推移逐步变得更难。

其成果是一个自我进化的任务语料库，目前包含 4,504 个任务，横跨 1,040 个领域，拥有超过 8,000 种独特工具，全部基于带状态数据库操作并配有语义验证。

任务剖析

每个任务都遵循清晰的语义结构：一个数据库、一组操作该数据库的工具、一条指令，以及一个黄金解决方案和与之匹配的验证函数，用于检查任务是否成功完成。

任务种子：数据库 + 工具 + 任务 + 验证

每个任务都定义一个 Pydantic 数据模型（DB），表示实体及其交互。例如，在 day_spa 任务族中，一个 Therapist 会在 Service 期间执行 Appointment。

智能体通过工具（Tools）与该数据库交互，这些工具是读取或操作数据库状态的简单 Python 函数。工具会强制执行领域逻辑（专业匹配、可用性检查、评分约束），并向智能体返回有关数据操作的结构化反馈。例如，智能体可以 list_services、list_therapists 和 book_appointment。

class Service(BaseModel):
    id: str
    name: str
    category: str  # massage, facial, body_treatment, nail_care
    duration_minutes: int
    price: float

class Therapist(BaseModel):
    id: str
    name: str
    specialties: list[str]  # service categories they can perform
    is_available: bool = True

class Appointment(BaseModel):
    id: str
    customer_name: str
    service_id: str
    therapist_id: str
    status: str = "booked"

class TaskDB(DB):
    services: list[Service] = []
    therapists: list[Therapist] = []
    appointments: list[Appointment] = []
    target_customer: str | None = None
    target_service: str | None = None

class TaskTools(Tools):
    db: TaskDB

    @tool
    def list_services(self) -> list[dict]:
        """Return all spa services with details."""
        return [s.model_dump() for s in self.db.services]

    @tool
    def list_therapists(self) -> list[dict]:
        """Return all therapists with their specialties."""
        return [t.model_dump() for t in self.db.therapists]

    @tool
    def book_appointment(self, appointment_id: str,
                         customer_name: str, service_id: str,
                         therapist_id: str) -> dict:
        """Book a spa appointment."""
        service = next(s for s in self.db.services if s.id == service_id)
        therapist = next(t for t in self.db.therapists if t.id == therapist_id)
        # check therapist availability and specialty match
        # mark therapist unavailable, append appointment
        ...

智能体接收一条自然语言指令，必须弄清楚如何使用这些工具来完成任务。对于种子任务 day_spa_t0，指令内容为

Hi, I'm Sarah and I'd like to book a Swedish Massage. Could you look up the services and therapists, then just go ahead and book me with any available therapist who does massage? Don't worry about asking me to pick, just pick one and book it.

为确保任务可解，合成器需要生成一个黄金解决方案和一个验证函数。验证函数应检查指令中列出的所有约束，并且合成器必须生成一个能通过其自身验证函数的黄金解决方案。对于这个简单的种子任务 day_spa_t0，verify 函数仅检查目标客户是否为目标服务预订了预约。

def verify(db: TaskDB) -> float:
    """Check that the target customer has a booked appointment
    for the target service."""
    if not db.target_customer or not db.target_service:
        return 0.0
    for a in db.appointments:
        if (a.customer_name == db.target_customer
        and a.service_id == db.target_service
        and a.status == "booked"):
            return 1.0
    return 0.0

合成器为此示例提供的黄金解决方案需要列出所有服务和治疗师，以找到一位可用的按摩治疗师，然后预订该预约。

[
  ["list_services", {}],
  ["list_therapists", {}],
  ["book_appointment", {"appointment_id": "A1", "customer_name": "Sarah", "service_id": "S1", "therapist_id": "T1"}]
]

对于任务的初始验证，我们只要求重放黄金解决方案后，数据库状态发生变化，使得验证从失败翻转为通过。它检查：

1. verify(initial_db) == 0.0 — 任务不应已被解决
2. verify(gold_db) == 1.0 — 重放黄金解决方案必须满足验证函数

该测试是一个简单的结构健全性检查：如果此检查失败，说明任务本身存在根本性缺陷。当合成器创建新的任务实例时，它可作为任务可解性的首个合理性检查。

任务演化：难度层级

遵循 DeepSeek-V3.2 的方法论（arxiv:2512.02556），我们发现将任务从简单逐步演化为困难，比一次性完成一个困难任务要容易得多。因此，合成器首先按照上述规范构建一个简单的种子任务，然后通过在每个步骤中扩展指令、数据库和工具来逐步提高其难度。

目前，每个任务族涵盖 5 个难度层级（t0 到 t4），其中较高层级通过应用以下一种或多种演化策略从较低层级发展而来。

我们确保每个任务族在其各层级中至少使用 5 种独特的演化策略。重要的是，每个层级都根据指定求解器模型的目标通过率区间进行经验性门控。这确保合成器为每个层级生成可解且足够困难的任务。

day_spa 任务族说明了这种演化：可用工具数量、数据库大小以及解决任务所需的黄金步骤数均单调增加，导致平均解决率与难度层级之间呈现清晰的负相关关系。由于我们使用 GPT-5-Mini 进行难度校准，其解决率恰好落在目标区间内。我们可以看到，难度阶梯可以推广到更强的模型，例如 GLM-5.1，尽管它并未被明确用于难度校准，但在更高难度层级中其解决率也更低。

为了了解模型实际在何处失败，我们分析了 GLM 的求解尝试，并发现了因任务难度增加而导致的常见失败模式。

day_spa_t2

该层级引入了三种新的演化策略（larger_db、cross_entity_coupling、stricter_thresholds），并将数据库从 26 个实体扩展到 97 个实体。指令现在要求在 195 美元预算内提供三项服务——敏感肌面部护理、轻柔按摩和修甲，且不得重复使用同一位理疗师或同一间房间。GLM-5.1 有 66% 的概率解决此任务。

我是 Olivia，我想犒劳自己享受一整天的水疗。我的皮肤很敏感，容易起反应，所以我需要专门针对敏感肌的面部护理——而不是那种通用的。我还想要一次轻柔的按摩，力度不要太重。另外我也想做个美甲。我的总预算是 200 美元。

在几乎所有失败的 rollout 中，模型都会选择中等力度的按摩，而不是轻力度的选项。模型所选的那种按摩以轻柔流畅的动作著称，因此模型错误地推断它符合“轻柔”的标准。模型系统性地用世界知识替代了数据库中的内容。

day_spa_t4

该层级应用了三种演化策略（ambiguity_resolution、cross_entity_coupling、noisy_instructions），将数据库扩展到 184 个实体。指令中充斥着拼写错误，并引入了怀孕约束。GLM-5.1 仅有 22% 的概率解决此任务。

嘿，我是 Mia，我几个月后就要生宝宝了，做护理得小心点。我的皮肤最近疯狂闹脾气，超级容易起反应，所以我需要专门针对敏感肌的面部护理——不是那些号称适合所有人的通用款，因为它们根本不适合。还想要一次按摩，但力度要轻，完全不要强烈的。另外我也想做个简单的美甲。总共只有 210 美元可花，而且我只信任评分 4.7 或更高的理疗师。直接找合适的并帮我预约就行，不用先问我。

出现了一项名为“Prenatal Massage”的服务——专为孕期客户设计，从情境上看完美契合。但它的力度字段是中等，而非轻柔。在大多数失败案例中，模型都会预约它。正确答案是 Couples Massage（87 美元，力度为轻柔）——一个不那么显而易见的选择，但却是符合约束的那一个。预算违规进一步导致失败的求解尝试多于成功的尝试。

任务合成

该环境围绕两类智能体构建，它们在一个反馈循环中协同工作，以生成和演化任务：

• Synthesizer——一个设计新任务族并通过难度层级演化它们的智能体。它被离线使用，在与求解器的双人博弈中生成任务语料库。
• Solver——一个尝试求解任务实例的智能体。它承担两个角色：在合成过程中作为门控模型（用于校准难度），以及在 RL 训练中作为优化目标。

这两个智能体都实现为 verifiers 环境，这使它们能够原生接入 Prime Intellect 生态系统。这实质上免费提供了用于大规模评估、训练和运行合成数据生成的基础设施。例如，为了生成初始任务语料库，我们并行运行了超过 1,000 个合成 GLM-5.1 智能体，持续多天，几乎无需监督。

Synthesizer

核心洞见在于，任务创建本身就是一个智能体任务。合成器是一个 LLM 智能体，运行在沙箱环境中，并可访问 general-agent CLI。它由一个结构化技能引导，该技能定义了任务格式、演化策略、门控标准和完整的合成协议。该技能确保整个语料库的一致性，同时赋予智能体在选择领域以及设计任务和约束时的创作自由。每次合成都遵循以下步骤：

1. 设计 —— 选择一个新颖的领域，设计数据库 schema，并定义工具 API。
2. 种子 —— 编写该领域中最简单的有用任务。编写验证函数并生成一个可通过的黄金解决方案。
3. 门控 —— 针对种子层级运行求解器，进行 20 次 rollout。如果解决率 ≥0.80，则接受该种子。否则，进行调整并重试。
4. 演化 —— 对于每个后续层级（t1→t4），添加演化策略、扩展数据库、编写新任务、验证它，并针对目标通过率区间进行门控（例如，对于 t3 目标解决率为 20-40%）。
5. 验证 —— 最终检查：该任务族在其各层级中必须使用 ≥5 种独特的演化策略。

这个循环确保语料库中的每个任务都是：

• 结构有效 —— 黄金解决方案可正确重放，验证函数一致
• 经验校准 —— 难度不是猜出来的，而是测量出来的
• 多样化 —— 每个任务族使用多种独立的演化策略

求解器

所有三种后端都使用相同的任务格式和评分——它们的区别在于智能体与工具交互的方式。

1. Local —— 在进程内直接以 Python 函数形式调用工具。用于快速迭代，并作为合成器沙箱内的通过率门控引擎。
2. OpenCode —— 在沙箱中运行 OpenCode 智能体。任务工具通过本地 MCP 服务器暴露。每个工具方法都成为智能体可以调用的原生 MCP 工具。
3. RLM —— 在沙箱中运行带有按工具技能的 RLM 智能体。每个 @tool 方法都被包装在一个 RLM 技能中，智能体通过 await <tool>.run(...) 从其 IPython 内核调用该技能。

例如，我们可以使用以下命令生成 5x3 次 rollout，以 gpt-5-mini 作为本地求解器来解决 day_spa 任务族。

# Local solver
prime eval run general-agent-solver-local -a '{"task": "day_spa"}' -m openai/gpt-5-mini

所有轨迹都会上传到 Prime Lab。下面，我们可以看到模型使用 2 次并行工具调用来检查可用的服务和治疗师，随后用一次工具调用来预约——这是解决该任务的最优策略。

任务语料库

合成循环使用 zai-org/GLM-5.1-FP8 作为合成器、openai/gpt-5-mini 作为求解器模型在 avg@20 下进行门控，在 1,040 个领域中产生了 4,504 个任务。每个任务族都是一个自包含的世界，拥有自己的数据库 schema、逻辑和验证标准。每个任务都已针对至少一个求解器模型进行了经验测量。此外，我们使用 zai-org/GLM-5.1-FP8 作为 RLM 框架中的求解器模型生成了 200K+ 条轨迹，以便从更强大的模型获得任务难度的稳健估计。

任务多样性

在全部 1,040 个家族中，该语料库定义了 8,159 个唯一工具和 2,222 个唯一实体类（如 Customer、Booking、AirspaceZone 等 Pydantic schema 类型）。78% 的工具和 66% 的实体类仅属于单个家族——其余则是跨领域复用的共享抽象（Order、Equipment、get_customer）。

全部 9 种演化策略在语料库中均有充分体现。cross_entity_coupling 和 conditional_rules 最为常见，而 ambiguity_resolution 最为罕见——它需要更精心设计任务，才能引入真正的消歧挑战。

难度校准

该语料库使用 GPT-5-mini 作为门控求解器进行校准。下表展示了各难度层级的语料库整体平均值——求解率、工具数量、黄金步骤数和数据库规模均随层级单调变化。

GPT-5-Mini 的求解率按设计落在目标区间内（它正是门控模型）。该难度阶梯可推广至 GLM-5.1，其求解率同样随层级升高而下降——不过由于它是更强的模型，下降斜率更平缓。

下面我们将各层级、各模型的平均求解率分解为分布图。对于 GPT-5-Mini（左图），分布干净地从右向左移动：在 t0 时几乎所有任务都被解决，到 t4 时质量集中在 0.3 以下。对于 GLM-5.1（右图），即使在 t4 时分布仍保持右偏（中位数 0.98），反映出该模型强得多。然而，左尾随每个层级不断增长——GLM 失败的任务比例单调增加，证实该难度阶梯可推广到其校准所用模型之外。

然而，该图揭示出在这个特定版本的数据集上，GLM-5.1 的提升潜力相对较低。要提升更强模型的工具调用性能，可能需要以当前最难的 t4 层级为种子进一步演化任务语料库，并以强大的开源模型作为门控。

早期训练结果

general-agent 环境的最终目标是提升模型的工具调用和智能体能力。为对该环境进行压力测试，我们进行了两项简单的 SFT 和 RL 实验，并针对既有基准进行评估，包括 BFCL（Berkeley Function Calling Leaderboard，测试在多样化真实世界工具 API 上的函数调用准确率），以及 MCP-Atlas 的一个子集（针对真实 MCP 服务器对多步工具编排进行基准测试）。

RL

首先，我们展示该环境可通过 RL 进行训练。我们在整个任务语料库上对 Qwen/Qwen3-30B-A3B-Instruct 进行了一次小型 RL 运行，排除了平凡的 t0 种子任务。

设置。我们训练 200 步，学习率恒定为 1e-6，每批次 32×16 次 rollout，序列长度为 32k token。

结果。 平均奖励在训练过程中从 30% 攀升至约 70%，其中前 100 步的增益最为陡峭。每次 rollout 的平均轮数从约 8 增加到约 24，表明模型学会了进行更多的工具调用，并在可靠地解决其训练任务方面有所提升。

SFT

最后，我们对 Nemotron-3-Nano-30B-A3B-Base-BF16 进行微调，以测试在合成工具调用轨迹上的训练能否迁移到留出基准上。

数据。 我们在整个任务语料库上使用 GLM-5.1 生成的 4,417 条带有工具调用和工具结果的原始多轮对话进行训练，未进行任何过滤。

设置。 我们在 16xH200 GPU 上训练了 200 步，学习率为 5e-5（线性衰减，50 步预热），批量大小为 8，上下文长度为 64k。（W&B 运行记录）

结果。 我们在 BFCL-v3 和 MCP-Atlas 上评估中间检查点。基础模型在两个基准上均从接近零开始。仅对 4.4k 条 general-agent 轨迹进行 SFT，就将 BFCL 从 18.9% 提升至 52.3%，将 MCP-Atlas 从 0.6% 提升至 12.1%——接近最终后训练模型（73.5% / 45.5%），而后者是在数量级更多的数据上训练的。

未来工作

这项工作可以看作是我们更广泛研究愿景的一步：通过自动化环境构建，闭环实现自我改进的智能体。我们相信该环境具备许多正确的要素，使我们能够执行这一研究愿景，并朝着它演进我们的工具和平台：

• 训练智能体，而非模型（在任何 harness 中训练任何任务）
• 组合多个智能体（多智能体回合，如 synthesizer-solver、solver-grader 等）

下面，我们列出了一些我们认为对实现这一愿景至关重要的具体后续步骤。

演进语料库难度

当前语料库是使用 GPT-5-Mini 作为门控求解器合成的。我们计划进一步扩展任务语料库，以最难层级为种子，并针对更强的门控模型生成更多任务——为挑战前沿模型的任务开辟空间。

领域泛化

general-agent 环境旨在创建一个具有最大多样性、完全合成工具的任务集。我们相信，当将任务生成建立在真实世界种子数据上时，非常相似的配方可以应用于许多其他领域（如终端使用或文档检索）的合成环境生成。

多智能体训练

对于此版本的环境，合成循环离线运行以创建固定的任务语料库，然后可用于求解器智能体的下游训练。然而，由于两个智能体都构建为验证器环境，包含两个智能体（合成器和求解器）的合成回合本身是可训练的。我们旨在未来实现这种多智能体训练，使我们能够在训练期间真正演进任务语料库。

抽象

我们最近合并了将成为 verifiers v1 的预览版——完全解耦任务（解决什么）和 harness（如何解决），并提供丰富的组合方式。general-agent 环境为测试这些新抽象提供了完美的试验场，因为它需要本地和沙箱执行，具有任务特定的自定义工具和多智能体子任务。

@article{primeintellect2026generalagent,
author = {Mika Senghaas},
title = {General Agent: A Self-Evolving, Synthetic Agent Environment},
journal = {Prime Intellect Blog},
year = {2026},
month = {May},
note = {https://www.primeintellect.ai/blog/general-agent}
}