AI测评

CrewAI 的核心设计：角色扮演 + 任务驱动 CrewAI 的设计哲学是把多 Agent 协作抽象为人类团队的工作模式。你定义角色（Agent）、分配任务（Task）、设定流程（Process），框架负责编排执行。 from crewai import Agent, Task, Crew, Process # 定义角色 researcher = Agent( role="市场研究员", goal="收集目标市场的详细数据，包括规模、竞品、趋势", backstory="你是一位有10年经验的市场研究员，擅长数据分析和趋势预测", tools=[search_tool, web_scraper], llm="gpt-4o" ) writer = Agent( role="技术撰稿人", goal="将研究结果转化为清晰、有深度的分析报告", backstory="你曾是科技媒体主编，擅长把复杂技术概念转化为易懂文字", llm="gpt-4o" ) # 定义任务 research_task = Task( description="研究AI Agent框架市场，包括LangChain、CrewAI、AutoGen的市场份额、用户增长、社区活跃度", expected_output="包含数据图表的市场分析报告，至少2000字", agent=researcher ) write_task = Task( description="基于研究结果撰写深度分析文章", expected_output="结构完整的分析文章，含执行摘要、市场概况、竞品分析、趋势预测", expected_output_length="3000字以上", agent=writer, context=[research_task] # 依赖研究任务的输出 ) # 组建团队 crew = Crew( agents=[researcher, writer], tasks=[research_task, write_task], process=Process.sequential # 顺序执行 ) result = crew.kickoff() 这段代码的直觉性很强——你在描述一个团队的工作方式，而不是在写控制流代码。这是 CrewAI 最大的优势。 架构拆解 CrewAI 的架构有三个核心层： 层级 组件 职责 Agent 层 Agent、Role、Goal、Backstory 定义角色身份、目标、能力边界 Task 层 Task、Expected Output、Context 定义工作单元、输出标准、依赖关系 Crew 层 Crew、Process、Flow 编排执行流程、管理 Agent 间通信 Agent 的角色设计 CrewAI 的角色设计不仅是 prompt 工程，还影响工具选择和任务路由： ...

Haystack 1.x vs 2.0：推倒重来 Haystack 2.0 不是渐进式升级，是架构重写。deepset 团队总结了 1.x 的所有教训，推倒重建： 维度 Haystack 1.x Haystack 2.0 核心抽象 Node（黑盒） Component（白盒，类型安全） 连接方式 隐式管道连接 显式 connect() 方法 类型系统 无，靠字典传递 有，输入输出类型检查 路由 基于字段名自动路由 显式连接，可视化路由 扩展性 继承 BaseComponent 实现协议，组合优先 测试 困难（需整个 Pipeline） 组件可独立测试 序列化 有限 YAML 配置，完整序列化 1.x 最大的问题是黑盒太多。一个 FARMReader 封装了模型加载、预处理、预测、后处理，你想改其中一步就得继承重写。2.0 把这些全拆开，每个步骤是独立的 Component。 Pipeline 架构：显式连接 Haystack 2.0 的 Pipeline 是 Component 的有向无环图（DAG）： from haystack import Pipeline from haystack.components.converters import TextFileToDocument from haystack.components.preprocessors import DocumentSplitter from haystack.components.embedders import OpenAITextEmbedder, OpenAIDocumentEmbedder from haystack.components.writers import DocumentWriter from haystack.components.retrievers import VectorStoreRetriever from haystack.components.generators import OpenAIGenerator from haystack.components.builders import PromptBuilder from haystack.document_stores.in_memory import InMemoryDocumentStore # === 索引 Pipeline === indexing_pipeline = Pipeline() indexing_pipeline.add_component("converter", TextFileToDocument()) indexing_pipeline.add_component("splitter", DocumentSplitter(split_by="word", split_length=500)) indexing_pipeline.add_component("embedder", OpenAIDocumentEmbedder(model="text-embedding-3-small")) indexing_pipeline.add_component("writer", DocumentWriter(document_store=InMemoryDocumentStore())) # 显式连接 indexing_pipeline.connect("converter.documents", "splitter.documents") indexing_pipeline.connect("splitter.documents", "embedder.documents") indexing_pipeline.connect("embedder.documents", "writer.documents") # 运行索引 indexing_pipeline.run({"converter": {"sources": ["./data/*.txt"]}}) 注意 connect() 的参数格式："component_name.output_field" → "component_name.input_field"。类型必须匹配——如果 splitter 输出 documents，embedder 的输入也必须是 documents，否则 Pipeline 构建时就报错。 ...

LangChain 的痛点：为什么需要 LangGraph LangChain 最初设计目标是链式调用 LLM——prompt → model → output parser 串成一条链。这在简单的 Q&A 和 RAG 场景下足够用，但当你要构建真正的 Agent时，问题就来了： 痛点 具体表现 链是线性的 Agent 需要循环、条件分支、回退，Chain 只能直线走 状态管理粗糙 Memory 机制简陋，复杂状态需手动管理，多步推理容易丢上下文 没有检查点 长流程中途失败，无法从断点恢复，只能从头来 Human-in-the-loop 困难 链执行中无法暂停等待人类输入 AgentExecutor 黑盒 封装太重，调试困难，自定义控制流代价高 LangChain 的 AgentExecutor 本质上是一个 while 循环 + tool 调用，你无法精确控制每一步的行为。当你需要"如果工具返回 X 则走分支 A，否则走分支 B"这种逻辑时，AgentExecutor 就力不从心了。 LangGraph 的核心思路：把 Agent 当图来建模 LangGraph 的设计哲学很简单：Agent 的执行流程是一张有向图。 节点（Node）：每个节点是一个函数，接收状态，返回更新后的状态 边（Edge）：连接节点的有向边，可以是固定的或条件性的 状态（State）：一个共享的 TypedDict 或 dataclass，在节点间流转 from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated from langgraph.graph.message import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] tool_results: list def call_model(state: AgentState): response = llm.invoke(state["messages"]) return {"messages": [response]} def should_use_tool(state: AgentState) -> str: last_msg = state["messages"][-1] if last_msg.tool_calls: return "tools" return END # 构建图 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_use_tool) graph.add_edge("tools", "agent") # 工具执行完回到 agent app = graph.compile() 这段代码实现了一个标准的 ReAct Agent，但控制流完全透明。你能看到每一步在做什么，为什么走这个分支。 ...

LlamaIndex 的演进路线 LlamaIndex 起家于 RAG（检索增强生成），最初的定位是"连接你的数据与 LLM"。但随着 LLM 能力增强，单纯检索已经不够——用户需要 Agent 来动态决定何时检索、如何检索、检索后做什么。 版本阶段 核心能力 定位 0.9 之前 Index + Query Engine RAG 框架 0.10+ LlamaHub + Workflows 数据连接 + 工作流 当前 Data Agent + AgentWorkflow RAG + Agent 融合 0.10 是分水岭——LlamaIndex 重构了整个包结构，引入了 Workflow（事件驱动工作流）和 Data Agent，正式从 RAG 框架进化为 Agent 框架。 Data Agent：带检索能力的智能体 LlamaIndex 的 Data Agent = LLM + Tools + 检索能力： from llama_index.core.agent import FunctionAgent from llama_index.llms.openai import OpenAI from llama_index.core.tools import FunctionTool, QueryEngineTool llm = OpenAI(model="gpt-4o") # 工具1：网络搜索 def search_web(query: str) -> str: """搜索互联网获取最新信息""" from llama_index.tools.tavilyi import TavilyToolSpec return TavilyToolSpec().search(query) web_tool = FunctionTool.from_defaults(fn=search_web) # 工具2：RAG 查询（复用现有索引） from llama_index.core import VectorStoreIndex index = VectorStoreIndex.from_documents(documents) query_engine = index.as_query_engine(similarity_top_k=5) rag_tool = QueryEngineTool.from_defaults( query_engine=query_engine, name="knowledge_base", description="查询内部知识库，包含产品文档和技术规范" ) # 创建 Data Agent agent = FunctionAgent( tools=[web_tool, rag_tool], llm=llm, system_prompt="你是一个研究助手。先查内部知识库，找不到再搜网络。" ) response = await agent.run("我们的API限流策略是什么？和业界最佳实践比如何？") # Agent会: 1. 先用rag_tool查内部 2. 再用web_tool搜业界实践 3. 综合回答 这是 LlamaIndex 的差异化优势：RAG 不是外部组件，而是 Agent 的原生能力。在 LangChain 里你要手动把 Retriever 包装成 Tool，在 LlamaIndex 里这是内建的。 ...

引言 随着 LLM 部署规模扩大，安全评估不再是可选项。一个「能力强但不安全」的模型比一个「能力弱但安全」的模型危险得多。2026 年，安全评估已形成系统化的维度体系，涵盖毒性、偏见、越狱攻击、隐私泄露、对齐性等多个层面。本文提供完整的安全评估方法论。 一、安全评估维度全景 LLM 安全评估 ├── 毒性 (Toxicity) │ ├── 仇恨言论 │ ├── 侮辱/骚扰 │ ├── 暴力威胁 │ └── 自残引导 ├── 偏见 (Bias) │ ├── 性别偏见 │ ├── 种族偏见 │ ├── 年龄偏见 │ ├── 宗教偏见 │ └── 残障偏见 ├── 越狱攻击 (Jailbreak) │ ├── Prompt 注入 │ ├── 角色扮演绕过 │ ├── 编码/多语言绕过 │ └── 多轮诱导 ├── 隐私 (Privacy) │ ├── PII 泄露 │ ├── 训练数据提取 │ └── 成员推理 ├── 有害内容生成 │ ├── 武器/毒品制造 │ ├── 非法活动指导 │ └── 虚假信息生成 └── 对齐性 (Alignment) ├── 指令遵循 ├── 价值观一致性 └── 拒绝过度/不足 二、Toxicity 检测 2.1 评估方法 Red Teaming + 自动分类： ...

为什么仍需要人工评估 在 LLM-as-Judge 和自动化评测大行其道的 2026 年，人工评估仍然是不可替代的黄金标准。原因有三： 自动化评估的局限性：LLM-as-Judge 存在已知偏差（位置偏差、长度偏差、自我偏好），需要人工评估作为校准基准 主观维度的不可替代性：有用性、创意性、语气适配等维度，人类判断仍是 ground truth 对抗性场景的判断：Jailbreak 的危害程度、微妙偏见的存在与否，需要人类语义理解 一、评估者招募与培训 1.1 评估者画像 不同评估任务对评估者的要求差异极大： 评估类型 评估者要求 典型时薪 通用对话质量 母语者，本科以上 $15-25 专业领域（代码/医学/法律） 领域专家 $50-100+ 安全/偏见检测 培训过的审核员 $25-40 多语言评估 母语者 + 文化背景 $20-35 创意写作评估 写作背景/文学训练 $25-45 1.2 招募流程 筛选漏斗设计： 基础资质筛选：学历、语言能力证明 能力测试：让候选人对 20 个样本进行标注，与金标准对比 一致性测试：对同一样本标注两次（间隔 48 小时），计算自我一致性 培训与考核：通过者进入培训，培训后通过考核测试才能正式标注 关键指标： 候选人通过率通常在 30-50% 每位评估者需完成 2-4 小时的培训 培训后考核通过率约 70-80% 1.3 培训内容设计 培训不是「读标注指南」，而是系统化的能力建设： 模块一：任务理解——评估维度定义、评分标准详解 模块二：边界案例——最容易标错的案例及其正确标注 模块三：偏差认知——锚定效应、顺序偏差、中心化偏差 模块四：实操练习——30 个练习样本，含即时反馈 模块五：一致性校准——与团队其他成员的对齐练习 二、标注指南设计 2.1 评分量表设计 推荐：5 点 Likert 量表 + 结构化维度 ...

引言 模型能力决定了「能不能做」，推理性能决定了「能不能用」。一个 GPT-5 级别的模型如果每次回复需要 30 秒，在大多数实际场景中就不可用。2026 年，随着模型规模增长和上下文窗口扩展，推理性能优化已成为 LLM 工程的核心挑战。本文系统梳理推理性能的关键指标、测试方法论和主流模型对比。 一、关键指标定义 1.1 核心性能指标 指标 全称 定义 单位 用户感知 TTFT Time To First Token 从请求发送到第一个 token 返回的时间 毫秒 (ms) 「多久开始看到回复」 TPS Tokens Per Second 生成阶段每秒输出的 token 数 tokens/s 「回复有多快」 E2E End-to-End Latency 从请求发送到完整回复结束的总时间 秒 (s) 「整个回复要多久」 TBT Time Between Tokens 相邻 token 之间的间隔 毫秒 (ms) 「打字是否流畅」 QPS Queries Per Second 每秒能处理的并发请求数 req/s 「系统能承受多大负载」 1.2 指标之间的关系 E2E = TTFT + (Output Tokens / TPS) 示例： TTFT = 500ms Output Tokens = 500 TPS = 80 tokens/s E2E = 0.5 + (500/80) = 0.5 + 6.25 = 6.75 秒 1.3 哪个指标最重要？ 取决于应用场景： ...

引言 LLM-as-Judge 指使用大语言模型作为评估器来评判其他模型的输出质量。这一方法在 2024 年随 GPT-4 评审能力成熟而大规模采用，到 2026 年已成为行业标准实践。但「用 AI 评估 AI」并非无懈可击——偏差、成本、校准都是必须严肃对待的问题。 一、Judge 模型选择 1.1 Judge 模型能力要求 一个合格的 Judge 模型需要具备： 指令遵循能力：严格按照评估 rubric 打分，不自由发挥 长文本理解：能处理长回答和复杂 rubric 领域知识：对被评估内容有足够理解 评分稳定性：对相似输入给出一致的评分 抗偏见能力：不受回答长度、格式、风格等表面因素干扰 1.2 主流 Judge 模型对比（2026） Judge 模型 评分准确率 成本/1K 评估 延迟 推荐场景 GPT-5 88% $0.12 中 通用评估首选 Claude 4 Opus 87% $0.15 中 代码/推理评估 Gemini 2.5 Ultra 84% $0.08 低 大规模评估 GPT-4o 82% $0.05 中 预算有限 DeepSeek V3.5 79% $0.02 低 开源/低成本 Llama 3.3 70B 74% 自部署 低 数据隐私场景 准确率指与人类专家判断的一致率，基于 MT-Bench 和 Arena-Hard 基准。 ...

OpenClaw 的定位：个人 AI Agent 操作系统 OpenClaw 不是一个 Library，是一个运行时。你不需要在代码里 import 它——你启动它，它作为一个常驻服务运行，管理你的 AI Agent 的感知、决策和行动。 特征 OpenClaw LangChain/LangGraph CrewAI/AutoGen 形态 常驻服务（运行时） Python Library Python Library 使用方式 配置 + 自然语言 写代码 写代码 目标用户 非开发者 / 轻开发者 开发者 开发者 运行环境 本地机器 / 服务器 你的应用进程 你的应用进程 核心抽象 Skill + Memory + Channel Chain + Graph Agent + Crew 这个定位决定了 OpenClaw 的设计取舍——它更像一个"AI Agent OS"，而不是一个"Agent 开发框架"。 架构拆解 OpenClaw 的架构可以简化为五层： ┌─────────────────────────────────────────┐ │ Channel 层（渠道） │ │ WebChat / Discord / WhatsApp / API │ ├─────────────────────────────────────────┤ │ Agent 层（核心） │ │ LLM 推理 / 工具调用 / 决策循环 │ ├─────────────────────────────────────────┤ │ Skill 层（能力） │ │ 邮件 / 搜索 / 文档 / 浏览器 / 自定义 │ ├─────────────────────────────────────────┤ │ Memory 层（记忆） │ │ MEMORY.md / Daily Notes / LCM 压缩 │ ├─────────────────────────────────────────┤ │ Scheduler 层（调度） │ │ Heartbeat / Cron / Event 触发 │ └─────────────────────────────────────────┘ Skill 系统：插件化能力 OpenClaw 的 Skill 是一个 Markdown 文件（SKILL.md），包含指令和可能的脚本： ...

Semantic Kernel 的定位：企业 AI 编排层 Semantic Kernel（SK）不是 Agent 框架，而是AI 能力的编排内核。它的设计目标是在企业应用中嵌入 AI 能力，而不是构建独立的 Agent。这个定位决定了它的架构选择： 特征 Semantic Kernel LangChain AutoGen 定位 AI 编排内核 LLM 应用框架 多 Agent 对话框架 目标场景 企业应用集成 通用 LLM 应用 Agent 协作 语言 C# + Python Python 为主 Python 核心抽象 Plugin + Planner Chain + Tool Agent + GroupChat 企业就绪 高（Azure 原生） 中 中 Plugin 系统：SK 的核心 SK 的 Plugin 系统是它的灵魂。一个 Plugin 就是一组可被 AI 调用的函数： Python 版 from semantic_kernel.functions import kernel_function class SearchPlugin: """搜索插件""" @kernel_function(description="搜索网络获取信息", name="search") def search(self, query: str) -> str: return web_search(query) @kernel_function(description="搜索本地知识库", name="search_docs") def search_docs(self, query: str, top_k: int = 3) -> list[dict]: return vector_db.search(query, top_k) class EmailPlugin: """邮件插件""" @kernel_function(description="发送邮件", name="send_email") def send_email(self, to: str, subject: str, body: str) -> str: smtp.send(to, subject, body) return f"邮件已发送至 {to}" # 注册插件 kernel.add_plugin(SearchPlugin(), "Search") kernel.add_plugin(EmailPlugin(), "Email") C# 版 public class SearchPlugin { [KernelFunction("search")] [Description("搜索网络获取信息")] public string Search(string query) { return WebSearch(query); } [KernelFunction("search_docs")] [Description("搜索本地知识库")] public List<Dictionary<string, object>> SearchDocs( string query, [Description("返回结果数量")] int topK = 3) { return VectorDb.Search(query, topK); } } // 注册 kernel.Plugins.AddFromType<SearchPlugin>("Search"); kernel.Plugins.AddFromType<EmailPlugin>("Email"); Python 和 C# 的 API 高度对称——这是 SK 的一个重要优势。C# 团队和 Python 团队可以共享设计文档，代码迁移成本低。 ...