AI Agent 软件工程关键技术综述

LangChain v.s. LangGraph

LangChain 和 LangGraph 出自于同一个团队，都被设计用于与 LLM 集成并协同工作，两者常被混淆。但顾名思义，两者有着显著的区别：

• LangChain（链条）：静态顺序工作流，每个步骤都遵循预先定义的顺序。
• LangGraph（有向图）：动态分支工作流，允许在每一步进行决策并选择分支。

显然，LangChain 和 LangGraph 有着不同的应用场景，LangChain 专注于提供组件和 LCEL（LangChain Expression Language）链式编程语法，适合简单的一次性任务；LangGraph 则是构建有状态 Agent 系统的理想选择。两者并不互斥，可以协同工作。例如：在 LangGraph 中的一个 Node 可以使用LangChain 来定义一系列步骤。

所以，在学习 LangGraph 前，建议先学习 LangChain 的基础知识。虽然使用 LangGraph 创建智能体或许不需要完全掌握 LangChain，但扎实掌握其基础知识肯定会有所帮助。

特性对比：应用场景对比：

LangChain

LangChain 是一个开发 LLM AI 应用程序的基础框架，封装并提供了各种常用的接口和工具，可以方便开发者快速调用并实现业务功能，加快开发速度。 官方手册：https://python.langchain.com/docs/introduction/

1. 调用 LLM 的统一接口
2. 搜索、文档处理、向量数据库处理等工具
3. 链式调用（Chains）语法
4. 记忆管理
5. 提示词模版
6. 等

LangChain 的 LCEL 语法示例：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(linefrom langchain.chat_models import ChatOpenAIfrom langchain.prompts import ChatPromptTemplate

model = ChatOpenAI()prompt = ChatPromptTemplate.from_template("请回答以下问题：{question}")
# LCEL 链式编排chain = prompt | model# 运行链result = chain.invoke({"question": "什么是人工智能？"})

LangGraph

LangGraph 基于 LangChain 之上，是一个基更高级的 AI Agent 编排框架，可以处理复杂的 Workflow 编排和 Multi-Agent 编排。 官方手册：https://langchain-ai.github.io/langgraph/

1. 图结构架构：支持条件分支、循环、并行、回溯等复杂的控制流。
2. 状态管理：基于状态（State）的工作流处理，拥有强大的状态管理模块，确保上下文连续性。
3. 检查点（Checkpoints）管理：支持人工介入二次检查
4. 等

顾名思义，Lang（语言）+ Graph（图）= 用图结构组织 LLM AI 的思考流程。如下图所示。

值得注意的是 LangGraph 中的 State 机制。常规的 LLM 模型 API 调用不能维持多步骤的连续推理过程，每次对话都是独立的，不能记住之前的处理结果，也不能基于中间结果动态调整后续步骤。LangGraph State 正是为了解决这个问题，它将复杂任务分解成多个步骤，并记住每个步骤的结果。后续步骤可以访问前面步骤的结果和数据，并根据结果判断调整执行路径，最终完成整个任务链条。

LangGraph 的图结构编程示例：

ounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(lineounter(linefrom langgraph.graph import StateGraphfrom typing import TypedDict
class State(TypedDict):    messages: list    current_step: str
def node_a(state: State) -> State:    return {"messages": state["messages"] + ["处理A"], "current_step": "A"}
def node_b(state: State) -> State:    return {"messages": state["messages"] + ["处理B"], "current_step": "B"}
# 创建图结构graph = StateGraph(State)graph.add_node("node_a", node_a)     # nodegraph.add_node("node_b", node_b)     # nodegraph.add_edge("node_a", "node_b")   # edge

执行模式对比：

LangSmith

LangSmith 是一个针对 Agent 和 LLM Call 之间的可视化监控、追踪、调试、测试和评估平台：

• Debugging：实时诊断 LLM 交互中的逻辑错误。高亮异常节点（如工具调用超时、JSON 解析失败），关联错误与代码位置（如提示词第 15 行格式错误）。
• Tracing：记录跨组件的完整调用链，例如：串联 LangGraph 节点调用、数据库查询、API 请求等。
• Monitoring：生产环境实时指标观测与告警，包括：请求量、延迟、错误率、Token 消耗分布、工具调用成功率等。
• Test & Evaluation：自动化测试，支持对不同的 Prompt、LLM 执行 A/B 测试并生成质量评估。
• Prompt & Optimisation：追踪每次 Prompt 的修改对结果输出的影响。 官方地址：https://www.langchain.com/langsmith

Agent-chat UI

Agent-chat UI 是 LangChain Ecosystem 中的一部分，帮助开发者快速搭建一个基于 AI Agent 的 Chat WebUI。 项目地址：https://github.com/langchain-ai/agent-chat-ui

RAG（Retrieval Augmented Generation，检索增强生成）最初用于解决 LLM 数据过时、幻觉和偏见问题，现今也常被用于注入私域知识。是 Agent 和 LLM 交互环节中的一个重要组成部分。

• 数据过时：LLM 的知识边界受限于过时的预训练数据。此外，LLM 版本迭代往往也是滞后的。
• 幻觉：当 LLM 遇到知识盲区时，会启动一种联想补全机制基于局部信息拼接出看似合理、实则虚构的内容，并自信的认为这是真实的。
• 私域知识：LLM 预训练数据来自于公域数据，并不包含企业内部的私域数据，所以也无法理解企业内部的私域知识。

RAG 是缓解或解决上述问题的良药，核心是 “动态知识注入机制”，提供了一个外部知识存储，在不修改 LLM 参数的前提下，通过 “外挂” 的形式为 LLM 补充 “实时、准确、私域” 的知识，拓宽了 LLM 的知识边界。

• 解决数据过时：RAG 外部知识存储具有实时性，输入 User Query 前会主动检索实时数据，再将其组合到上下文输入给 LLM。
• 缓解幻觉：RAG 外部知识存储具有准确性，LLM 返回结果之前会自动检索准确数据进行对比，降低 LLM 捏造虚假内容的概率。但实际上 RAG 无法完全杜绝幻觉问题。
• 解决私域知识：RAG 外部知识存储具有私域知识，输入 User Query 前会将私域知识输入给 LLM。

如下图所示，RAG 的核心流程有检索阶段、增强阶段和生成阶段。

Agentic AI 解决了 LLM 无法操作外部环境的问题，RAG 解决了 LLM 知识边界固化的问题，使得 LLM 应用的潜力得到了极大的扩展。而 Anthropic 于 2024 年 11 月推出的 MCP（Model Context Protocol，模型上下文协议）则是为了解决 LLM 上下文的局限性问题，包括：

• 长上下文传输瓶颈：传统 JSON 格式输入 10K token 的上下文到 LLM 需 500ms+，而 MCP 压缩后仅需 20ms。
• 动态更新低效：局部更新（如新增对话）需重传全量上下文到 LLM，而 MCP 支持增量更新。
• 多模型协同障碍：MCP C/S 是与 LLM 解耦的，LLM-A 的输出作为 LLM-B 的输入需序列化转换，因为 MCP 提供了标准化上下文协议容器字段。例如：创建一个与 GitHub 交互的 MCP Server 时，任何支持 MCP 的 LLM 应用程序都可以使用它。
• 标准化扩展性差：在软件工程层面标准化 Agentic AI 和 RAG 的实现方式，使得 LLM 应用系统能够在一个标准化的协议之上进行构建，继而实现 LLM 应用的可扩展性、稳定性和深度上下文感知。

MCP 最大的特点是能够让 LLM 统一调用各种外部工具或数据源，不再需要为每一个工具单独写适配代码。带来了以下好处：

1. 标准化交互：确保 Agentic AI 能够轻松集成和扩展其功能，纳入新工具、API 或服务。
2. 降低开发复杂性：通过抽象化交互逻辑，减少代理开发的复杂性，使开发者能够专注于增强核心代理功能。
3. 促进集体智能：通过标准化通信渠道共享见解和协调行动，使分布式 Agentic AI 系统能够实现单一架构无法实现的结果。

MCP 结构

• MCP Host：LLM 应用及其运行环境，例如：ChatBot、AI IDE、AI Agent 等。
• MCP Client：运行在 LLM 应用内的、和 MCP Server 一一对应的、向 MCP Server 发出请求的 Client 模块。
• MCP Server：作为 MCP Client 和 Real Service 之间的桥梁，左边接受 MCP Client 的请求，右边将请求翻译并转发到后端的 Real Service，例如：API、DB、File、SSE、Internet 等等。
• Local Resources：运行在 MCP Host 本地的工具或数据。
• Remote Resources：云端或在线可访问的远程服务。

MCP 的 Transport Layer 采用了 JSON-RPC 结构化通信协议，支持多种消息类型：

• Stdio（标准输入输出）
• HTTP over SSE（服务器推送事件流）
• 自定义实现

MCP 运行流程

MCP 应用示例

1. 使用 LLM 应用总结代码库中最近的 5 次提交。MCP Host with Client 首先调用 MCP Server，询问有哪些可用的 Tools List。

2. 然后 MCP Host 将这些 Tools 输入到 LLM。LLM 接收到这些信息后，会选择使用某个工具。然后 MCP Host 再向 MCP Server 发送具体某个工具的使用请求，并收到工具执行结果。

3. 最后，MCP Host 将工具执行结果输入到 LLM。LLM 返回最终的响应结果给用户。

A2A（Agent2Agent Protocol）由 Google 在 2025 年 4 月提出，专注于 AI Agent 之间能够进行通信、协作和任务委托，并以结构化格式返回结果。支持异步工作流和多模态交互。通过 A2A 协议，Agents 之间可以了解彼此的技能，并完成任务的委托。

• MCP 赋予智能体 “操作世界” 的能力。
• A2A 赋予智能体 “协作彼此” 的能力。

A2A 结构

A2A 协议：基于 HTTP/S JSON-RPC 2.0 传输协议，符合 Web 原生的安全协议设计。

A2A Client：作为 Client 角色的 Agent，通过其他 A2A Server 的 Agent Cart 进行发现，并通过委托 Task 让其他 A2A Server 帮助自己完成可完成的任务。它向 A2A Server 的 URL 发送请求，如：tasks/send。

A2A Server：一个实现了 A2A 协议的 HTTP Endpoint，通过 Agent Card 对外进行发布，用于接收请求并管理任务执行。

Agent Card：是 A2S Server 的名片，JSON 格式，用于介绍 Agent 的名称、版本、能力描述、访问 Endpoint URL、支持的消息类型、身份认证方式、运行时 Metadata、供应商等信息。

Task：是 A2A Client 委托 A2A Server 执行的一个任务对象。Client 通过发送 Message（如 tasks/send 或 tasks/sendSubscribe）委托一个 Task。拥有唯一 ID 和 Stateful 状态机（如 submitted、working、input-required、completed、failed、canceled）。

Message：是 A2A 协议的消息体，A2A Client（role: "user"）与 A2A Server（role: "agent"）之间交互信息单元，由多个 Part 组成。A2A 协议建立时，Client 和 Server 之间会协商消息格式、内容粒度和可视化等机制。

Part（消息体部分）：多个 Parts 组成一个 Message，可细分为 TextPart、FilePart、DataPart（结构化 JSON）等富媒体信息交换类型。

Push Notifications：A2A Server 执行 Task 的过程中会主动向 A2A Client 提供的 webhook URL 推送通知，该 URL 可通过 tasks/pushNotification/set 进行配置。

Artifact：中间产物流式处理。对于长时间运行的 Task，A2A Server 在过程中生产的持久化产物，A2A Client 从 Artifact 获取任务更新数据。例如：生成的文件或结构化数据。

Streaming：实时反馈流式处理。对于支持流式传输的 A2A Server，A2A Client 可使用 tasks/sendSubscribe 进行调用，然后接收到包含 TaskStatusUpdateEvent 或 TaskArtifactUpdateEvent 的 Server-Sent Events（SSE），以获取实时进度。

A2A 工作流程

A2A 的典型应用场景是 Multi-Agent 软件架构，以及对来自不同团队或供应商的 Agents 进行安全互操作，形成跨平台的智能体生态系统。

1. 发现对方：Client 从 Server 的 well‑known URL（例如 https://DOMAIN/.well-known/agent.json）获取 Agent Card。
2. 任务委托：Client 发送包含 Client Infos 和 Task ID 的 tasks/send 或 tasks/sendSubscribe 请求。
3. 任务处理：

• 非流式处理：Server 同步处理任务，并在 HTTP Resp 中返回最终的 Task 对象。
• 流式处理：Server 在任务过程中，通过 SSE 发送状态更新或 Artifact 更新事件。

• 交互（可选）：如果 Task 进入 input-required 状态，Client 可使用相同的 Task ID，通过 tasks/send 或 tasks/sendSubscribe 发送后续消息以提供所需输入。
• 完成：Task 最终达到终止状态之一，包括：completed、failed 或 canceled。
分层记忆系统

目前关于 AI 记忆系统的研究尚未形成统一清晰的框架，特别是缺乏对记忆机制底层原子操作的系统化理解。以下通用架构图基于现有 AI Agent 记忆系统的主流设计模式，综合参考了 MemoryOS、Mem0、LangChain Memory 等系统的架构特点，以及相关学术研究中的理论框架。

• 多策略检索：结合语义检索、关键词匹配和图关系查询，从三层记忆中检索相关信息。
• 短期记忆：存储会话缓存、对话历史和临时状态，支持快速访问和上下文连续性。
• 中期记忆：维护向量索引、语义搜索和时序索引，实现高效的语义检索和时间序列分析。
• 长期记忆：管理知识图谱、实体关系和规则库，建立持久化的知识体系和推理规则。
• 智能记忆更新：通过增量更新、智能摘要、去重合并和分层存储，动态更新三层记忆。



Context Engineering

Context Engineering 是 Prompt Engineering 和 In-context Learning 的演进方向。

• Prompt Engineering（提示工程）：通过设计过的、结构化的 Prompt 让 LLM 准确理解用户意图，并生成期望的输出。
• In-Context Learning（上下文学习）：通过在 Prompt 中注入设计过的 Context 供 LLM 学习，而无需更新 LLM 的权重（不进行微调），最终让 LLM 能够生成期望的输出。
• 零样本学习（Zero-shot Learning）：默认的，不提供任务示例，仅靠指令和 LLM 预训练知识进行推理。
• 少样本学习（Few-shot Learning）：在 Prompt 中提供少量（e.g. 2~5 个）任务示例，引导 LLM 进行模仿，继而输出与示例相似的结果。

可见，Prompt Engineering 是应用 In-context Learning 的前提，两者有共同的目标，并且具有都是针对某个问题的、静态的、一次性的等共同特性，所以在 Chat 场景中表现良好。但在追求自主智能的 Agent 场景中，有着以下不足：

1. 复杂度高：Agent 场景涉及数十上百个步骤，需要编写大量的静态 Prompt 费时费力。
2. 适用性差：在长对话或多步骤任务中，目标和环境会不断演变。静态 Prompt 并不一定适用。
3. 持续性差：长期运行会产生海量历史信息，无法全部放入有限上下文窗口。

简而言之，PE 和 ICL 本质上是 “静态” 的，它们无法适应长期运行（Long Run）的自主任务（Autonomous）中不断变化的环境和状态。Context Engineering 在 PE 和 ICL 的基础之上，提出了一种 “动态地” 为长对话/多步骤任务提供完整背景信息的思路。即：根据对话/任务的当前状态和变化，动态地构建最相关的、最有效的 Context Window（上下文窗口）。



实现 Context Engineering 的关键技术：

1. RAG（检索增强生成）：检索到的信息动态注入上下文，为模型提供最新、准确、具体的背景知识，解决模型知识陈旧和幻觉问题。
2. 工具调用（Tool Calling / Function Calling）：将工具调用的输入请求和返回结果动态地整合进上下文，极大地扩展了模型的能力边界，使其能处理实时数据、执行具体操作。
3. 智能体记忆系统（Agent Memory）：根据当前任务需求，从记忆库中动态检索并注入最相关的历史片段，维持智能体的连贯性和个性化。

例如，智能客服系统不仅能记住你 “昨天咨询过退货政策”，还能结合 “你是 VIP 用户”、“购买商品未满 7 天” 等信息，直接给出 “退货免运费” 的解决方案，无需重复解释。上下文工程需要处理动态变化的信息网络，包含三个层级：

1. 即时信息：当前用户的输入内容，如 “我想退这个商品”。
2. 历史信息：用户过去的交互记录，如 “3 天前购买，未拆封”。
3. 外部信息：与场景相关的系统数据，如 “该商品支持 7 天无理由退货”、“用户是 VIP，免退货费”。

这些信息并非静态存储，而是需要通过 RAG、Tools、Memory 来获取并形成动态上下文信息。



Context Engineering 的终极目标不仅是构建数据上下文，甚至能实现指令上下文的动态优化，推动智能体向自适应性（Self-adaptive）和自我改进（Self-improvement）演进：

• 动态 Prompt 内容或策略调整：基于任务进展、用户反馈或观察，智能地调整后续步骤的 Prompt 内容或策略。例如：
• 内容：发现模型输出冗长时，自动在后续 Prompt 中加入 “请简洁回答” 的要求。
• 策略：在解决复杂推理问题时，根据中间步骤的成败动态切换不同的策略，如 CoT 切换到 ToT。
• 自我改进的实现：
• PromptWizard 等框架：让 LLM 基于自身输出结果进行 “自我批评”，生成改进建议，并迭代优化提示。实现 Prompt 的自动优化。
• Promptbreeder 等技术：采用进化算法，让 Prompt 在代际更替中不断优化（“自我参照”），在数学推理等任务上显著超越静态提示方法。
• 记忆驱动的优化：分析长期记忆中的成功/失败案例，自动总结出更有效的提示模板或行动策略。



知识图谱

虽然长上下文窗口、向量数据库、RAG 等技术可以提供基于语义的检索能找到语义相似的内容，在某些领域足以作为 Agent 记忆模块优选。但由于检索到的这些知识不具有关联关系特征，所以在对实体关系紧密的复杂推理场景中，就存在着精准性、推理性和可解释性上存在不足。例如：法律合同场景，对人物、时间、地点、观点、案件情景具有密切的关系。

对此，知识图谱可以通过建模实体及其关系，继而提供精准、可解释、覆盖全面的上下文工程，使得 LLM 拥有更接近人类认知模式：

1. 作者与情境：明确 “谁说了什么，何时何地”。
2. 动态结构：可随新信息快速更新关系网络。
3. 可解释性与覆盖面：推理路径透明且可持续优化。

更具体的。我们常结合 RAG 来实现一个长记忆系统，但也有认为 RAG 记忆系统存在缺陷的观点，例如：

1. 传统 RAG 系统本质上是一个文档馆，它假设知识是固定不变的，这在处理动态业务场景时就显得力不从心了。
2. 当新信息与旧信息发生冲突时，RAG 系统无法智能地判断哪个更可信，往往会把矛盾的信息一股脑儿返回给用户。
3. RAG 缺乏时间维度的理解让系统无法区分用户去年的偏好和用户现在的需求，导致推荐结果偏离实际情况。

Zep 是一个具有时间特性的知识图谱软件。Graphiti 是 Zep 记忆层背后的技术，它是一个开源的库，能够构建动态的、具有时间意识的知识图谱，用以表示实体之间复杂且不断变化的关系。它采用了一个巧妙的三层知识图谱架构来解决传统 RAG 的痛点，如下图所示：

1. Episode 子图：完整地存储原始对话、文本或 JSON 数据，不丢失任何信息。
2. Semantic Entity 子图：从原始数据中提取实体和关系。利用实体解析技术，将新旧信息有机地整合在一起。
3. Community 子图：通过标签传播算法对相关实体进行聚类。形成高层次的概念理解。

这种架构设计使得 Zep 系统既能保留细节信息，又能进行抽象推理。