框架测评

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 提供了最丰富的索引类型： ...

为什么需要 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. 调试和修复能力 ...