smolagents review

smolagents 评测:HuggingFace 的极简 Agent 框架

smolagents 的设计哲学:少即是多 HuggingFace 的 smolagents 用一句话概括:1000 行代码实现一个可用的 Agent 框架。在 LangChain 动辄数万行代码、依赖链深不见底的当下,smolagents 是一股清流。 设计原则 smolagents 的做法 极简核心 基类不超过 1000 行 最小依赖 仅依赖 huggingface_hub,其他都是可选的 Code Agent 优先 Agent 输出代码而非 JSON 工具调用 HF 生态原生 与 HuggingFace Hub/Inference 深度集成 学习门槛 10 分钟读完源码 Code Agent vs Tool Agent:范式之争 这是 smolagents 最重要的设计决策。理解它,就理解了 smolagents。 Tool Agent(LangChain/CrewAI 方式) Agent 输出 JSON 格式的工具调用: { "thought": "我需要搜索天气", "action": "search_weather", "action_input": {"city": "北京"} } LLM 需要严格遵循 JSON schema,任何格式错误都会导致解析失败。而且 JSON 无法表达复杂逻辑——如果你需要"对搜索结果排序后取前3个再分别查详情",只能拆成多轮调用。 Code Agent(smolagents 方式) Agent 直接输出 Python 代码: ...

2026-06-25 · 4 min · 646 words · AI 实战派
code llm eval

代码 LLM 评估:从 HumanEval 到 SWE-Bench Pro

引言 代码生成是 LLM 最成功的落地场景之一,但「能写代码」和「能解决工程问题」之间有巨大鸿沟。HumanEval 上的 90% 通过率并不意味着模型能胜任真实的软件工程工作。本文系统梳理 2026 年代码 LLM 评估从基础到工程级的完整体系。 一、基础代码生成评估 1.1 HumanEval HumanEval 由 OpenAI 在 2021 年发布,是代码 LLM 评估的元老级 Benchmark。包含 164 个 Python 编程任务,每个任务包含函数签名、docstring 和测试用例。 评估方式: 给定函数签名和 docstring,模型生成函数体,用测试用例验证正确性。 Pass@k 指标: Pass@k = 1 - C(n-c, k) / C(n, k) 其中 n 是总采样数,c 是通过测试的采样数,k 是允许的尝试次数。 2026 年头部模型 Pass@1: 模型 HumanEval Pass@1 GPT-5 96.2% Claude 4 Opus 95.8% Gemini 2.5 Ultra 94.1% DeepSeek-Coder V2.5 93.5% Llama 3.3 70B 88.7% 问题: HumanEval 已严重饱和,头部模型差距不到 8 个百分点,基本失去区分度。 ...

2026-06-25 · 4 min · 662 words · AI 实战派
multimodal eval 2026

多模态模型评估 2026:视觉/音频/视频全面评测

引言 2026 年的多模态模型已不再局限于「看图说话」。GPT-5、Gemini 2.5 Ultra、Claude 4 等模型能同时处理图像、音频、视频,并进行跨模态推理。但多模态评估远比纯文本复杂——视觉理解不只是图像分类,音频理解不只是语音识别,视频理解更涉及时序推理。本文系统梳理 2026 年多模态评估的方法论与 Benchmark 现状。 一、视觉理解评估 1.1 评估维度体系 视觉理解 ├── 基础感知 │ ├── 物体识别 (Object Recognition) │ ├── 属性识别 (Attribute Recognition) │ └── 场景分类 (Scene Classification) ├── 视觉推理 │ ├── 空间推理 (Spatial Reasoning) │ ├── 关系推理 (Relational Reasoning) │ └── 物理推理 (Physical Reasoning) ├── 文档理解 │ ├── OCR / 文字提取 │ ├── 图表理解 (Chart QA) │ └── 文档推理 (Document QA) ├── 细粒度理解 │ ├── 计数 (Counting) │ ├── 差异检测 (Difference Detection) │ └── 细节描述 (Detailed Description) └── 创意理解 ├── 梗图理解 (Meme Understanding) ├── 艺术作品分析 └── UI/UX 理解 1.2 主流视觉 Benchmark Benchmark 评测重点 样本数 头部得分 区分度 VQAv2 基础视觉问答 1.1M 92%+ ⚠️ 饱和 GQA 组合视觉推理 22M 88%+ ⚠️ 接近饱和 ChartQA 图表理解 30K 85-90% ✅ 良好 DocVQA 文档问答 50K 92-95% ⚠️ 接近饱和 MMMU 多领域视觉推理 11.5K 65-72% ✅ 良好 MMBench 多维度视觉评估 6K 80-85% ✅ 良好 MathVista 数学视觉推理 6K 55-70% ✅ 高 RealWorldQA 真实世界理解 7K 70-78% ✅ 高 1.3 关键 Benchmark 详解 MMMU (Massive Multi-discipline Multimodal Understanding) MMMU 覆盖 30 个学科(艺术、科学、商业、医学等),要求模型基于图像进行大学级别的推理。 ...

2026-06-25 · 4 min · 657 words · AI 实战派
dspyp review

DSPy 框架评测:声明式 LLM 编程

DSPy 是什么:Prompt 工程的范式转换 传统 Prompt 工程的核心痛点:Prompt 是手写的、脆弱的、不可优化的。你花数小时调出一个"看起来不错"的 Prompt,换个模型就失效了。DSPy 提出了一个激进的想法——不要手写 Prompt,让框架自动优化。 DSPy(Declarative Self-improving Language Programs)来自斯坦福 NLP 组,核心理念是将 LLM 编程从"写 Prompt"转变为"声明意图 + 自动优化"。 核心架构:三件套 Signature:声明输入输出 import dspy # 声明式定义:输入是什么,输出是什么 class QA(dspy.Signature): """回答问题,基于给定上下文""" context: str = dspy.InputField(desc="参考文档") question: str = dspy.InputField(desc="用户问题") answer: str = dspy.OutputField(desc="简洁准确的回答") class Summarizer(dspy.Signature): """生成长文本的摘要""" text: str = dspy.InputField(desc="原始文本") summary: str = dspy.OutputField(desc="200字以内的摘要") Signature 的关键在于:你只描述"做什么",不描述"怎么做"。框架会根据 Signature 自动生成 Prompt。 Module:组合 LLM 逻辑 # 类似 PyTorch 的模块化设计 class RAG(dspy.Module): def __init__(self): self.retrieve = dspy.Retrieve(k=3) self.generate = dspy.ChainOfThought(QA) def forward(self, question): context = self.retrieve(question).passages prediction = self.generate(context=context, question=question) return dspy.Prediction(answer=prediction.answer) # 使用 rag = RAG() result = rag(question="量子计算的基本原理是什么?") print(result.answer) DSPy 内置模块: 模块 功能 dspy.Predict 基础预测,直接调用 LLM dspy.ChainOfThought 链式思考,让模型先推理再回答 dspy.ReAct 推理+行动循环(工具调用) dspy.Retrieve 检索模块 dspy.MultiChainComparison 多路 CoT 对比 Teleprompter:自动 Prompt 优化 这是 DSPy 的杀手级能力。Teleprompter 会自动搜索最优 Prompt: ...

2026-06-24 · 3 min · 518 words · AI 实战派
instructor review

Instructor 框架评测:结构化输出的优雅方案

结构化输出的痛点 让 LLM 输出结构化数据是工程落地中最常见的需求:解析简历提取字段、分类用户意图、生成配置文件。传统做法是在 Prompt 里写"请输出 JSON",然后祈祷模型不要在 JSON 前面加一句"好的,这是你要的结果:"。Instructor 框架优雅地解决了这个问题。 Instructor 核心原理 Instructor 的设计哲学极其简洁:用 Python 类型注解定义结构,让 LLM 填充结构,自动验证和修复。 工作流程: 你定义一个 Pydantic 模型(即期望的输出结构) Instructor 将模型 Schema 注入 Prompt LLM 生成输出 Pydantic 验证输出 验证失败 → 自动将错误信息反馈给 LLM 重试 快速上手 安装与基础用法 pip install instructor import instructor from pydantic import BaseModel, Field from openai import OpenAI # 启用 Instructor client = instructor.from_openai(OpenAI()) # 定义输出结构 class UserInfo(BaseModel): name: str = Field(description="用户全名") age: int = Field(description="用户年龄", ge=0, le=150) email: str = Field(description="邮箱地址") role: str = Field(description="职位", default="unknown") # 调用——直接返回结构化对象 user = client.chat.completions.create( model="gpt-4o", response_model=UserInfo, messages=[{"role": "user", "content": "张三,28岁,邮箱 zhangsan@example.com,高级工程师"}], ) print(user.name) # "张三" print(user.age) # 28 print(user.email) # "zhangsan@example.com" print(user.role) # "高级工程师" print(type(user)) # <class 'UserInfo'> 注意:返回的不是字典,是经过验证的 Pydantic 对象。类型安全,IDE 补全全开。 ...

2026-06-24 · 3 min · 632 words · AI 实战派
guidance review

Microsoft Guidance 模板评测:控制 LLM 输出格式

Guidance 的设计理念 Prompt 工程的一个核心矛盾:你希望 LLM 严格遵循格式,但 LLM 本质上是在"续写文本",格式控制全靠提示词的"软约束"。Microsoft Guidance 提出了另一种思路——用模板语言硬约束 LLM 的输出结构。 Guidance 不是让 LLM “生成一个 JSON”,而是在 token 层面强制 LLM “先输出 {",再输出 key,再输出 ":",以此类推。这种约束式生成从根本上消除了格式错误。 核心语法 基础模板 from guidance import models, gen, system, user, assistant # 加载模型 lm = models.LlamaCpp("models/Llama-3-8B-Instruct-Q4_K_M.gguf", n_gpu_layers=35) # 使用角色标签 with system(): lm += "你是一个有帮助的助手。" with user(): lm += "解释量子纠缠。" with assistant(): lm += gen("response", max_tokens=200) print(lm["response"]) 变量插值 topic = "量子计算" difficulty = "初学者" lm = lm + f"请用{difficulty}能理解的方式解释{topic}。" + gen("answer", max_tokens=300) 条件逻辑 from guidance import guidance @guidance def answer_question(lm, question, use_cot=True): if use_cot: lm += "\n让我一步步思考。\n" lm += gen("reasoning", max_tokens=200) + "\n" lm += "因此,答案是:" lm += gen("answer", max_tokens=100) else: lm += "\n答案:" lm += gen("answer", max_tokens=100) return lm lm += answer_question("光合作用的原理是什么?", use_cot=True) 循环 @guidance def generate_questions(lm, topic, n=3): lm += f"关于{topic}的{n}个问题:\n" for i in range(n): lm += f"\n{i+1}. " lm += gen(f"question_{i}", max_tokens=50, stop=["\n", "?"]) lm += "?" return lm lm += generate_questions("机器学习", n=5) 结构化输出保证 JSON 保证输出 import guidance from guidance import json @guidance def extract_entity(lm, text): lm += f"从以下文本中提取实体信息:\n{text}\n" lm += json("entity", schema={ "type": "object", "properties": { "name": {"type": "string"}, "age": {"type": "integer"}, "occupation": {"type": "string"} }, "required": ["name", "age", "occupation"] }) return lm lm += extract_entity("李四今年30岁,是一名软件工程师") # 输出保证是合法 JSON,因为 Guidance 在 token 层面约束了结构 正则约束 from guidance import regex @guidance def generate_phone(lm): lm += "电话号码:" lm += regex(pattern=r"\d{3}-\d{3}-\d{4}") return lm # 输出格式保证为 XXX-XXX-XXXX 选择题约束 from guidance import select @guidance def classify(lm, text): lm += f"文本:{text}\n类别:" lm += select(options=["正面", "负面", "中性"], name="sentiment") return lm # LLM 只能输出这三个选项之一,不可能输出其他内容 与传统 Prompt 工程对比 格式可靠性 方法 JSON 成功率 格式控制方式 容错能力 手写 Prompt ~85% 软约束(提示词) 无 Function Calling ~95% API 约束 需手动 Guidance ~100% Token 级硬约束 内置 代码对比:生成结构化产品信息 传统 Prompt 方式: ...

2026-06-24 · 4 min · 656 words · AI 实战派
outlines review

Outlines 框架评测:保证 LLM 输出结构化

Outlines 的核心思想 Outlines 来自 dottxt 公司,与 Guidance 类似,采用约束式生成策略——在解码阶段限制 LLM 的 token 选择空间,从数学上保证输出符合指定格式。区别在于 Outlines 更聚焦于"结构"而非"模板",且在 CFG(上下文无关文法)支持上更加深入。 约束生成原理 Token 级约束的工作方式 传统生成:每个 step 从整个词表(~128k tokens)中采样 约束生成:每个 step 只从"符合当前格式要求"的 token 子集中采样 例如:已生成 '{"name": "张三", "age":' → 下一步只能是数字 token(如果 schema 要求 age 是整数) → 而非整个词表 CFG(上下文无关文法) Outlines 的核心技术创新是将 JSON Schema 编译为 CFG,然后在生成时用 CFG 约束 token 选择: JSON Schema: {"type": "object", "properties": {"name": {"type": "string"}}} → 编译为 CFG: value → object | string | number | ... object → "{" ws string ws ":" ws value ws "}" string → "\"" chars "\"" chars → char chars | ε ... → 生成时:根据当前 CFG 状态,确定合法的下一个 token 集合 快速上手 安装 pip install outlines 基础用法 import outlines model = outlines.models.transformers("meta-llama/Llama-3-8B-Instruct") # 直接定义输出类型 @outlines.generate.json(model) def extract_person(text: str) -> dict: """提取人物信息""" return { "name": str, "age": int, "occupation": str, } result = extract_person("王五,35岁,是一名医生") # result = {"name": "王五", "age": 35, "occupation": "医生"} # 100% 保证是合法 JSON 且类型正确 使用 Pydantic 模型 from pydantic import BaseModel, Field from typing import List class Education(BaseModel): school: str = Field(description="学校名称") degree: str = Field(description="学位") year: int = Field(description="毕业年份") class Person(BaseModel): name: str age: int occupation: str educations: List[Education] @outlines.generate.json(model, Person) def extract(text: str): """从文本中提取人物结构化信息""" person = extract("李四,28岁,工程师,毕业于清华大学计算机科学硕士,2022年毕业") print(person.name) # "李四" print(person.educations[0].school) # "清华大学" 正则约束 @outlines.generate.regex(model, r"\d{3}-\d{4}-\d{4}") def generate_phone(): """生成电话号码""" phone = generate_phone("请生成一个电话号码") # 100% 符合 XXX-XXXX-XXXX 格式 选择约束 @outlines.generate.choice(model, ["正面", "负面", "中性"]) def classify_sentiment(text: str): """情感分类""" result = classify_sentiment("这个产品太棒了!") # 只能是 "正面"、"负面" 或 "中性" 类型约束 # 整数约束 @outlines.generate.format(model, int) def generate_score(text: str): """生成评分""" # 布尔约束 @outlines.generate.format(model, bool) def is_spam(text: str): """判断是否垃圾信息""" CFG 高级用法 自定义文法 # 定义自定义语法 grammar = """ root: expr expr: term (("+" | "-") term)* term: factor (("*" | "/") factor)* factor: NUMBER | "(" expr ")" NUMBER: /[0-9]+/ """ @outlines.generate.cfg(model, grammar) def generate_expression(): """生成数学表达式""" expr = generate_expression("生成一个数学表达式") # 输出保证是合法的数学表达式 Lark 语法支持 from lark import Lark # 使用 Lark 语法定义更复杂的格式 sql_grammar = """ start: select_stmt select_stmt: "SELECT" column "FROM" table ("WHERE" condition)? column: NAME table: NAME condition: NAME OP VALUE OP: "=" | ">" | "<" | "!=" NAME: /[a-zA-Z_]+/ VALUE: /"[^"]*"/ | NUMBER NUMBER: /[0-9]+/ """ @outlines.generate.cfg(model, sql_grammar) def generate_sql(): """生成 SQL 查询语句""" sql = generate_sql("查询所有年龄大于30的用户") # 输出保证是语法正确的 SQL 多模型支持 import outlines # HuggingFace Transformers model = outlines.models.transformers("meta-llama/Llama-3-8B-Instruct") # llama.cpp (GGUF) model = outlines.models.llamacpp("models/Llama-3-8B-Instruct-Q4_K_M.gguf", n_gpu_layers=35) # vLLM (高吞吐) model = outlines.models.vllm("meta-llama/Llama-3-8B-Instruct") # mamba (SSM 架构) model = outlines.models.mamba("state-spaces/mamba-130m-hf") Outlines vs Function Calling vs Instructor vs Guidance 维度 Outlines Function Calling Instructor Guidance 格式保证 100%(CFG 约束) ~95%(API 约束) ~99%(重试) 100%(Token 约束) 模型要求 本地模型 API 模型 任意 本地模型优先 延迟开销 低(无重试) 中 中(可能重试) 低 Schema 支持 JSON Schema/Pydantic/正则/CFG JSON Schema Pydantic JSON Schema/正则/select 灵活性 高 中 高 很高 生产成熟度 高 高 高 中 可靠性对比 在 500 条信息抽取任务上的测试: ...

2026-06-24 · 4 min · 700 words · AI 实战派
multimodal eval guide

多模态评估指南:视觉语言模型怎么测?

VLM 评估维度 VLM 评估需同时考察视觉感知和语言推理两条链路。 ┌──────────┬──────────┬──────────┐ │ 感知层 │ 推理层 │ 生成层 │ 图像理解 │ 对象识别 │ 因果推理 │ 描述生成 │ 视频理解 │ 动作识别 │ 时序推理 │ 摘要生成 │ 3D 理解 │ 空间感知 │ 交互推理 │ 场景描述 │ └──────────┴──────────┴──────────┘ 感知层 能力 测试方法 对象识别 “图中有哪些物体” 属性识别 颜色、大小、材质 空间关系 物体间位置关系 细粒度识别 区分相似物体 OCR 识别图中文字 推理层 能力 示例 物理推理 “杯子从桌边掉落会怎样” 社会推理 “图中的人为什么生气” 多步推理 “根据路标该往哪走” 生成层 能力 示例 图像描述 无障碍 alt text 视觉问答 “图中时钟显示几点” 图文创作 看图写故事 核心基准 基准 规模 核心能力 特点 MMBench 2943题 20维度综合 中英双语,细粒度分类 MMMU 11.5K 学科知识+视觉 30学科,大学水平 SEED-Bench 19K 多模态理解 覆盖图像/视频/3D MME 2394 感知+认知 是/否问答 GQA 22M 场景图推理 结构化推理 MMBench 能力维度 ├── 粗粒度感知 (对象存在/计数/场景分类) ├── 细粒度感知 (属性/空间关系/OCR) ├── 推理 (物理/社会/逻辑) └── 关系 (图内/跨图) MME 评估 # Yes/No 问答,避免开放式生成的评分问题 def evaluate_mme(model, dataset): correct = 0 for item in dataset: for question, answer in item['questions']: pred = model.answer(item['image'], question) if normalize(pred) == answer.lower(): correct += 1 return correct / len(dataset) 视频理解评估 维度 基准 时序理解 MVBench, TempCompass 动作识别 Kinetics 视频问答 NExT-QA, EgoSchema 长视频理解 LongVideoBench 视频评估策略 def evaluate_video(model, video_path, questions): for q in questions: if q['type'] == 'temporal': frames = sample_frames(video_path, fps=2) # 密集采帧 elif q['type'] == 'action': frames = sample_keyframes(video_path, n=16) # 关键帧 else: frames = sample_uniform(video_path, n=8) # 均匀采样 answer = model.answer(frames, q['question']) 视频评估挑战 帧采样偏差:均匀采帧可能错过关键事件 时序长度:短视频和长视频需不同策略 计算成本:视频编码比图像贵 100x+ 3D 理解评估 基准 任务 数据形式 ScanQA 3D场景问答 点云+RGB-D 3D-LLM 3D场景对话 点云+语义标注 SpatialBench 空间关系推理 合成3D场景 评估陷阱 1. 数据泄露 def check_contamination(train_data, test_data): from imagehash import phash train_hashes = {phash(img) for img in train_data} leaked = sum(1 for img in test_data if phash(img) in train_hashes) return leaked / len(test_data) 2. 位置偏差 偏差 规避方法 位置A偏好 随机化选项顺序 末位偏好 选项排列组合测试 长度偏好 控制选项长度一致 3. 语言先验作弊 def test_vision_dependency(model, questions): with_image = [model.answer(q['image'], q['question']) for q in questions] without_image = [model.answer(None, q['question']) for q in questions] gap = accuracy(with_image) - accuracy(without_image) if gap < 0.1: print("警告:模型可能未有效利用视觉信息") 4. 指标陷阱 陷阱 解决方案 精确匹配过严 用语义相似度或LLM裁判 BLEU/ROUGE不适用 用 CIDEr 或 SPICE 多选准确率虚高 报告随机基线+normalized gain 实战建议 多基准组合:至少 3 个基准交叉评估 分维度报告:按感知/推理/生成分维度 做数据泄露检查:网络图片基准尤其注意 控制推理成本:视频和3D评估预算大 中英文分别评估:VLM 中英文能力差异可能很大 关注长尾能力:平均分高的模型可能特定维度很差 人工校验:抽 5-10% 人工复核确保指标可信 多模态评估仍在快速发展,保持对新方法和基准的关注,定期更新评估体系。 加入讨论 这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。 ...

2026-06-24 · 2 min · 334 words · AI 实战派
agent benchmark methodology

Agent 基准测试方法论:从设计到执行

Agent 基准测试与传统 LLM 评测的区别 传统 LLM 评测关注单轮输入输出质量——生成文本是否流畅、知识是否准确、推理是否正确。但 Agent 评测面临根本差异:Agent 需要在多轮交互中自主决策、调用工具、维护状态、处理错误。一次错误的工具调用可能让整个任务失败,即使后续推理完全正确。 Agent 基准测试必须考察:长程规划能力(复杂目标分解为可执行步骤)、工具使用准确性(参数构造与调用时机)、错误恢复能力(异常时调整策略)、状态管理(多轮交互的上下文一致性)。 设计原则 任务真实性:基准任务应反映真实世界需求,而非人造玩具问题 可复现性:同一 Agent 多次运行结果应稳定,随机性需控制和记录 评估客观性:优先程序化评估而非人工判断,可大规模运行 难度梯度:包含不同难度级别,避免天花板或地板效应 测试集构建 来源 优点 缺点 示例 真实工单 高生态效度 获取困难 SWE-bench 人工构造 可控性强 偏离真实分布 AgentBench 合成生成 规模可扩展 复杂度有限 ToolBench 混合方法 兼顾真实与可控 设计成本高 tau-bench 构建流程:原始任务池 → 去重过滤 → 难度标注 → 验证集构建 → 评估脚本开发 → 试测校准 → 正式发布 评估指标体系 metrics = { "success_rate": "任务完成率(最核心指标)", "step_efficiency": "实际步骤数 / 最优步骤数", "tool_accuracy": "正确工具调用数 / 总工具调用数", "cost_efficiency": "任务完成数 / 总 token 消耗", "error_recovery_rate": "成功恢复的错误数 / 总错误数", "hallucination_rate": "幻觉工具调用数 / 总工具调用数", } def composite_score(result): weights = {"success_rate": 0.5, "step_efficiency": 0.2, "tool_accuracy": 0.2, "cost_efficiency": 0.1} return sum(result[k] * w for k, w in weights.items()) 主流基准对比 AgentBench 覆盖 8 类任务环境:操作系统交互、数据库操作、知识图谱问答、卡片游戏、迷宫导航、网页浏览、家务模拟、购物对话。优势是覆盖面广,局限是部分任务生态效度参差不齐。 ...

2026-06-24 · 2 min · 266 words · AI 实战派
agent eval comparison

Agent 评估框架横向对比:谁在衡量 Agent 的能力?

为什么需要专门的 Agent 评估 传统 LLM 评估(MMLU、HumanEval、GSM8K)衡量的是单轮静态能力。Agent 评估面临截然不同的挑战: 多步推理:错误会沿步骤累积 环境交互:动作改变状态,状态影响后续决策 工具使用:API 调用正确性、参数填充准确性 长程任务:几十步后是否还记住初始目标 成本约束:Token 消耗与任务完成率的权衡 四大框架横向对比 总览 框架 开发方 评估维度 任务数 交互轮次 环境类型 开放性 AgentBench THUDM 多场景任务完成 8场景 10-30 模拟环境 部分开源 SWE-bench Princeton 软件工程 2,294 不限 Docker 容器 全开源 τ-bench Sierra 工具使用+策略遵循 165 ~30 模拟API 全开源 WebArena CMU Web 交互 812 ~15 真实网站 全开源 AgentBench:多场景覆盖 AgentBench 是清华推出的多场景 Agent 评估基准,覆盖 8 类环境: 场景 环境 核心能力 Operating System Linux 终端 命令行操作 Database SQL 数据库 数据查询操作 Knowledge Graph 知识图谱 多跳推理 Card Game 斗地主 策略规划 Lateral Thinking 水平思考谜题 创意推理 House Holding 模拟家居 具身智能 Web Shopping 电商网站 Web 交互 Web Browsing 网页浏览 信息检索 评估指标:任务成功率(Success Rate),各场景独立打分。 ...

2026-06-24 · 3 min · 503 words · AI 实战派
🔗 硅基 AGI 论坛 · silicon-agi.com | 📡 RSS 订阅
鲁ICP备2026018361号
📮 邮件订阅 每周 AI 深度长文与辩论精选,直达收件箱
订阅功能即将由邮件服务商(Brevo 免费版)正式启用 · 您的邮箱仅用于本站内容推送