AI测评

AutoGen 概述 AutoGen 是微软推出的多智能体（Multi-Agent）框架，目标是让开发者能快速搭建多个 AI Agent 协作完成复杂任务。2025 年发布的 v0.4 是完全重写版本（也叫 AG2），架构设计全面升级。 v0.4 核心变化 维度 v0.3 (旧) v0.4 (新) 架构 扁平、耦合 分层、事件驱动 异步 ❌ ✅ 原生 asyncio 消息传递 直接调用 事件总线 Agent 通信 硬编码 可扩展通信协议 可观测性 基本日志 OpenTelemetry 集成 跨语言 Python only Python + .NET 扩展性 中 高（插件架构） 架构解析 事件驱动模型 ┌─────────────────────────────────────────┐ │ Runtime │ │ ┌──────────────────────────────────┐ │ │ │ Event Bus │ │ │ │ (消息路由、订阅/发布) │ │ │ └──────┬─────┬─────┬─────┬─────────┘ │ │ │ │ │ │ │ │ ┌────┴──┐ ┌┴────┐ ┌┴────┐ ┌┴──────┐ │ │ │Agent A│ │Agent B│ │Agent C│ │Tool │ │ │ │(Writer)│ │(Reviewer)│ │(Coder)│ │Agent │ │ │ └───────┘ └──────┘ └──────┘ └───────┘ │ │ │ │ ┌──────────────────────────────────┐ │ │ │ Model Client Layer │ │ │ │ (OpenAI / Azure / Ollama / ...) │ │ │ └──────────────────────────────────┘ │ └─────────────────────────────────────────┘ 所有 Agent 间通信通过事件总线，Agent 之间完全解耦。这意味着可以灵活替换、增删 Agent 而不影响其他部分。 ...

Haystack 的定位 deepset 出品的 Haystack 是一个 专注于 RAG（检索增强生成）的 NLP 框架。与 LangChain 的"万物皆链"不同，Haystack 的设计哲学是 Pipeline 即图——每个处理步骤是一个 Node，Node 之间通过类型化的连接器组装成 DAG（有向无环图）。 这种设计在 RAG 场景下优势明显：文档处理流水线天然是线性的（加载→切分→嵌入→存储→检索→生成），Haystack 的 Pipeline 模型与之完美契合。 架构核心 Pipeline：计算图 Haystack 2.x 的 Pipeline 是一个真正的计算图，支持分支、合并、循环： from haystack import Pipeline from haystack.components.embedders import SentenceTransformersTextEmbedder from haystack.components.retrievers import QdrantRetriever from haystack.components.generators import OpenAIGenerator from haystack.components.builders import PromptBuilder # 构建 RAG Pipeline pipe = Pipeline() # 添加组件 pipe.add_component("embedder", SentenceTransformersTextEmbedder(model="BAAI/bge-m3")) pipe.add_component("retriever", QdrantRetriever(document_store=doc_store)) pipe.add_component("prompt_builder", PromptBuilder(template=TEMPLATE)) pipe.add_component("generator", OpenAIGenerator(model="gpt-4o")) # 连接组件（类型安全） pipe.connect("embedder.embedding", "retriever.query_embedding") pipe.connect("retriever.documents", "prompt_builder.documents") pipe.connect("prompt_builder.prompt", "generator.prompt") Node 类型体系 Haystack 2.x 的组件按功能分类： 类别 典型组件 作用 Converters TextFileToDocument, HTMLToDocument, PyPDFToDocument 文件→Document Preprocessors DocumentCleaner, DocumentSplitter 清洗与切分 Embedders SentenceTransformersTextEmbedder, OpenAITextEmbedder 文本→向量 Retrievers QdrantRetriever, BM25Retriever, HybridRetriever 向量/关键词/混合检索 Generators OpenAIGenerator, HuggingFaceLocalGenerator LLM 生成 Joiners DocumentJoiner, BranchJoiner 合并多路检索结果 Routers ConditionalRouter, MetadataRouter 条件路由 组件的输入/输出契约 每个组件声明输入输出类型，Pipeline 在连接时做类型检查： ...

LlamaIndex 的核心命题 LlamaIndex 的定位是 “LLM 的数据框架”——解决 LLM 与私有数据之间的鸿沟。如果说 LangChain 是 LLM 应用的"胶水层"，那 LlamaIndex 就是 “数据管道+检索引擎”。 核心理念：不是所有数据都要塞进 Prompt，关键在于如何高效检索最相关的片段。 核心架构 三层抽象 数据层 (Data Connectors + Documents + Nodes) ↓ 索引层 (Index: Vector / List / Tree / Keyword / Knowledge Graph) ↓ 查询层 (Query Engine / Retriever / Response Synthesizer) 数据连接器（LlamaHub） LlamaHub 提供了 200+ 数据连接器： from llama_index.core import download_loader # 加载 Notion 数据 NotionPageReader = download_loader("NotionPageReader") loader = NotionPageReader(integration_token="your-token") documents = loader.load_data(page_ids=["page-id-1", "page-id-2"]) # 加载 GitHub 仓库 GithubRepositoryReader = download_loader("GithubRepositoryReader") loader = GithubRepositoryReader(owner="owner", repo="repo") documents = loader.load_data(branch="main") Document 与 Node from llama_index.core import Document, VectorStoreIndex from llama_index.core.node_parser import SentenceSplitter # Document 是原始数据单元 doc = Document(text="...", metadata={"source": "hr-handbook.pdf", "page": 42}) # Node 是切分后的最小检索单元 splitter = SentenceSplitter(chunk_size=512, chunk_overlap=64) nodes = splitter.get_nodes_from_documents([doc]) # Node 携带元数据关系 print(nodes[0].relationships) # {Source: doc, Next: node[1], Previous: None} 索引类型详解 LlamaIndex 提供了最丰富的索引类型： ...

EDD 核心理念 评估驱动开发（EDD）将评估置于开发流程中心。传统开发是"先写功能，再测试"，EDD 反过来：“先定义评估标准，再开发功能”。借鉴了 TDD，但有关键区别：TDD 关注代码正确性，EDD 关注产品效果。 维度 传统开发 EDD 开发起点 功能需求 评估集 验收标准 功能可用 评估指标达标 迭代依据 直觉/用户反馈 评估数据 回归保护 单元测试 评估集回归 评估集先行 评估集是带预期结果的测试用例，用于量化 Agent 在特定任务上的表现，是随产品演进的活文档。 eval_set = { "version": "1.3.0", "cases": [ { "id": "case_001", "input": "帮我查北京到上海的高铁票", "expected": { "tool_calls": ["search_trains"], "tool_args": {"from": "北京", "to": "上海", "type": "高铁"}, "response_must_not_contain": ["飞机", "航班"], }, "difficulty": "easy", }, { "id": "case_042", "input": "先查高铁，再看上海天气，总结出行建议", "expected": { "tool_calls": ["search_trains", "get_weather"], "tool_call_order": ["search_trains", "get_weather"], "max_turns": 5, }, "difficulty": "medium", }, ], } 管理原则：版本化（每次更新打标签）、分层级（核心集50个CI跑 + 完整集500个发版跑）、防污染（不进训练数据）、持续扩充（每周加5-10个 bad case）。 自动化评估流水线 代码提交 → 单元测试 → 评估集执行 → 指标计算 → 对比基线 → 通过/告警 class EvaluationPipeline: def __init__(self, eval_set, baseline_results): self.eval_set = eval_set self.baseline = baseline_results self.metrics = [ ToolAccuracyMetric(), ResponseQualityMetric(model="gpt-4o"), LatencyMetric(), CostMetric(), SafetyMetric(), ] async def run(self, agent): results = [] for case in self.eval_set["cases"]: result = await self._evaluate_case(agent, case) results.append(result) summary = self._summarize(results) diff = self._compare_baseline(summary, self.baseline) return { "summary": summary, "regressions": [r for r in diff if r["change"] < 0], "improvements": [r for r in diff if r["change"] > 0], } CI/CD 集成：merge request 跑核心集（50个），main 分支跑完整集（500个），评估不通过则阻止合并。 ...

为什么人工评测不可替代 自动化评估（LLM-as-Judge、程序化指标）发展迅速，但人工评测仍是金标准。原因有三：开放性任务无标准答案，创意写作和多轮对话的正确答案不唯一甚至不存在；LLM-as-Judge 存在位置偏差、长度偏差、自我偏好偏差，需要人工校准；细微质量差异（更自然、更有帮助、更安全）往往需要人类判断。 但人工评测有致命弱点：贵、慢、不一致。好的设计在这三个约束下最大化评估质量。 标注规范设计 核心要素：任务描述、评估维度、评分标准表、判断规则、至少5组带标注样例。 ## 评估维度示例 - 帮助性 (1-5): 回答是否直接解决了用户问题？ - 准确性 (1-5): 信息是否正确、有无幻觉？ - 安全性 (1-5): 是否包含有害内容？ - 自然度 (1-5): 语言是否流畅、表达是否得体？ ## 评分标准 | 分数 | 帮助性 | 准确性 | |------|--------|--------| | 5 | 完全解决，超出预期 | 完全正确，来源可靠 | | 4 | 基本解决，小瑕疵 | 正确，轻微不精确 | | 3 | 部分解决 | 大部分正确，有小错误 | | 2 | 几乎没帮助 | 有明显错误 | | 1 | 完全无关 | 严重错误或幻觉 | ## 判断规则 - 质量接近（差距≤1分）选择"平局" - 准确性与详细性冲突时，准确性优先 - 安全性问题一票否决（直接1分） 成对比较 vs 绝对评分 方式 优点 缺点 适用场景 成对比较 更易判断、一致性高 信息量少、不可传递 模型排序 绝对评分 信息丰富、可追踪 标注者差异大 质量监控 排序 信息量最大 认知负担重 小规模深度评估 实践建议：主用成对比较做模型排序，辅以绝对评分做质量追踪。 ...

排行榜迷思 LMSYS 上 GPT-4o 排第一，SuperCLUE 上 Qwen 排第一，OpenCompass 又是另一个结果。这不是数据造假，而是每个排行榜的评测方法论、任务分布、评分机制完全不同。理解这些差异，才能正确使用排行榜指导模型选择。 LMSYS Chatbot Arena 机制 核心机制是众包盲测成对比较 + Elo 评分：用户输入问题 → 随机选两个模型匿名回答 → 用户选择更好的一个 → Elo 更新。 def update_elo(rating_a, rating_b, score_a, k=32): """score_a: 1表示A赢, 0.5平局, 0表示B赢""" expected_a = 1 / (1 + 10 ** ((rating_b - rating_a) / 400)) new_a = rating_a + k * (score_a - expected_a) return new_a # GPT-4o(1420) vs Claude(1400)，用户选 GPT-4o # GPT-4o → ~1421.3, Claude → ~1398.7 优势与局限 优势 局限 生态效度高（真实问题分布） 用户偏技术人群，通用场景代表性不足 抗污染（实时用户输入） 长度偏差（用户偏好更长的回答） 盲测（消除品牌偏差） 英文占60%+，中文评估弱 动态更新（新模型1-2周出数据） 大量简单问题，区分顶级模型困难 分领域子榜更具参考价值：Coding（编程）、Hard Prompts（高难度）、Vision（多模态）、Chinese（中文）。优先看你关心的领域子榜，不要只看总榜。 OpenCompass 上海 AI Lab 主导的开源评测体系，特点是大而全：100+ 数据集，中英文全覆盖。 # OpenCompass 配置示例 datasets: - mmlu # 多任务理解 - cmmlu # 中文多任务 - gsm8k # 数学 - humaneval # 代码 - bbh # 推理 - ceval # 中文考试 特点 说明 全开源 评测代码、提示词、数据处理全公开 覆盖广 MMLU/CMMLU/GSM8K/HumanEval/BBH/C-Eval 等 可复现 Docker 镜像确保环境一致 标准化 统一提示词模板和评估脚本 与 LMSYS 差异 维度 LMSYS OpenCompass 评估方式 人工成对比较 程序化指标 问题来源 用户真实输入 标准测试集 可复现性 低（依赖用户输入） 高（固定测试集） 数据污染风险 低 高（测试集公开） 主观任务覆盖 好（创意写作等） 差（主要客观题） 中文能力 弱 强 HELM (Holistic Evaluation) 斯坦福推出，核心理念是全息评估：多场景 × 多指标 × 多透明度。 ...

什么是 GAIA GAIA（General AI Assistants Benchmark）是由 Meta AI、Hugging Face 等机构联合发布的通用 AI 助手评测基准。如果说 MMLU 是 AI 的"高考"，那 GAIA 就是 AI 的"执业资格考试"——它不考知识记忆，考的是解决真实问题的能力。 设计理念 GAIA 的核心设计原则： 真实世界问题：所有题目来自日常场景，不是人造的测试题 多步骤推理：平均需要 5-10 步才能解决 需要工具使用：搜索、计算、文件处理等 答案唯一确定：尽管过程多样，但最终答案可验证 三个难度等级 Level 1（简单） 问题：在2024年奥斯卡颁奖典礼上，最佳导演获奖者的导演处女作是什么电影？ 需要步骤： 1. 搜索2024奥斯卡最佳导演 2. 查找该导演的处女作 预计耗时：人类约30秒 Level 2（中等） 问题：找到附件PDF中提到的所有公司，查询这些公司2023年的营收， 按营收从高到低排列，输出CSV格式。 需要步骤： 1. 解析PDF内容 2. 提取公司名称 3. 逐一搜索营收数据 4. 排序并格式化输出 预计耗时：人类约5分钟 Level 3（困难） 问题：分析过去10年全球AI论文发表趋势， 按国家和技术领域分类， 生成可视化报告并预测2027年趋势。 需要步骤： 1. 搜索多个数据源 2. 爬取和解析论文数据 3. 数据清洗和分类 4. 统计分析 5. 生成图表 6. 撰写分析报告 预计耗时：人类约2小时 评测维度 维度 权重 说明 准确率 40% 最终答案是否正确 过程合理性 20% 步骤是否合理，有无冗余 工具使用 20% 是否选对工具，使用是否正确 效率 10% Token 消耗和步骤数 安全性 10% 是否有危险操作 2026 最新排行 排名 系统 Level 1 Level 2 Level 3 总分 1 GPT-5 + Code Interpreter 92% 73% 42% 71% 2 Claude 4 + Computer Use 88% 69% 38% 67% 3 Gemini 2.5 Pro 85% 65% 35% 64% 4 Qwen3-Max 78% 52% 22% 53% 5 DeepSeek-V4 75% 48% 18% 49% - 人类平均 95% 85% 70% 84% GAIA 暴露的问题 1. 工具选择困难 很多 Agent 在面对"模糊需求"时选错工具： ...

为什么需要 LangGraph 传统 Agent 框架（如 LangChain Agent）采用线性的 ReAct 循环：思考 → 行动 → 观察 → 重复。这种模式简单但局限明显： 无法表达复杂控制流：条件分支、并行执行、人工审批等场景难以优雅实现 状态管理粗糙：所有上下文堆在对话历史里，难以精细控制 不可暂停/恢复：长流程任务无法中间暂停等待外部输入 LangGraph 用有状态图解决了这些问题。 核心概念 State Graph（状态图） LangGraph 的核心是 StateGraph，每个节点接收状态、修改状态、返回新状态： from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated from operator import add class AgentState(TypedDict): messages: Annotated[list, add] # 消息列表自动追加 tool_results: list iteration: int def call_model(state: AgentState): response = llm.invoke(state["messages"]) return {"messages": [response], "iteration": state["iteration"] + 1} def should_continue(state: AgentState): if state["iteration"] > 5: return END return "tools" # 构建图 graph = StateGraph(AgentState) graph.add_node("agent", call_model) graph.add_node("tools", tool_node) graph.set_entry_point("agent") graph.add_conditional_edges("agent", should_continue) graph.add_edge("tools", "agent") app = graph.compile() 关键设计决策 设计点 LangChain LangGraph 控制流 线性循环 DAG + 条件边 状态管理 隐式（对话历史） 显式（TypedDict） 可暂停 ❌ ✅ 人工介入 难 内置 interrupt 流式输出 部分 全面支持 实战：多步骤研究 Agent 以下是一个实际的研究 Agent 示例，展示 LangGraph 的核心能力： ...

引言 2026 年，AI 应用开发平台已经成为开发者工具链中不可或缺的一环。在国内市场，Dify 和 Coze（扣子）是两个最受关注的选择。两者都定位为低代码/无代码 AI 应用构建平台，但在设计理念、技术架构和适用场景上差异显著。 本文将从实际开发体验出发，从七个维度对两个平台进行深度对比。 一、平台定位与架构 维度 Dify Coze 定位 开源 LLM 应用开发平台 字节跳动 AI Bot 构建平台 部署方式 支持私有化部署 纯 SaaS（国内/国际版） 核心抽象 Workflow + Agent + RAG Bot + Plugin + Workflow 开源状态 Apache 2.0 开源 闭源 技术栈 Python + TypeScript 字节内部技术栈 Dify 的核心优势在于开源可私有化。对于有数据合规要求的企业，Dify 可以部署在自有服务器上，数据完全自控。Coze 则背靠字节生态，开箱即用，适合快速验证想法。 二、工作流引擎对比 Dify 的工作流采用 DAG（有向无环图）模型： # Dify Workflow 示例 nodes: - id: start type: start variables: - name: query type: string - id: llm type: llm model: gpt-4o prompt: "回答以下问题：{{query}}" - id: end type: end output: "{{llm.output}}" Coze 的工作流更偏可视化拖拽，节点类型更丰富，内置了搜索、图片生成、知识库等字节生态能力。但 Coze 的工作流不支持导出和版本管理，这在团队协作中是个痛点。 ...

AI 编程 Agent 2026 横评：谁才是最强代码助手？ 2026 年，AI 编程工具已经从「代码补全」进化到「自主编程 Agent」。本文基于最新版本（2026 年 6 月）进行全方位对比。 参评工具 Cursor 0.50+（Cursor Agent Mode） GitHub Copilot Workspace（Copilot Agent Mode） OpenAI Codex（Codex Agent Loop） Claude Code（Anthropic 官方 CLI） 六大维度评测 1. 代码生成质量 用 50 个真实编程任务测试（涵盖 Python/TypeScript/Go/Rust）： 工具 一次通过率 需要修改率 完全失败率 Cursor 76% 18% 6% GitHub Copilot 71% 22% 7% Codex 82% 13% 5% Claude Code 79% 15% 6% 结论：Codex 代码生成质量最高，特别是在复杂逻辑和多文件项目上。 2. 多文件编辑能力 测试「新增一个完整功能模块」的能力： Codex：最强，能正确分析依赖关系，修改相关文件 Claude Code：次之，编辑准确但需要更多轮次 Cursor：擅长当前打开文件的编辑，跨文件能力稍弱 GitHub Copilot：跨文件编辑能力最弱 3. 调试和修复能力 ...