先说结论：这场面试我大概率是凉了，但凉得很爽。

阿里一面，聊到一半面试官说他们团队正在做 Agent 项目。我脑子一热，直接反问了一句：

“那你们这个 Agent 项目，LangChain、Multi-Agent、A2A 这几块具体是怎么做的？框架选型、编排方式、协议对接，能展开说说吗？”

然后我就看着面试官开始擦汗。

事后复盘，我承认这句话有点“攻击性”，但它确实戳中了一个很现实的问题：现在太多团队嘴上说在做 Agent，实际上只是套了个 LangChain 的壳，跑了个 ReAct 循环。

这篇文章不吹面试战绩，只把这三个词讲清楚：LangChain、Multi-Agent、A2A，各自解决什么问题，真实项目里怎么组合，以及面试时被问到该怎么答。

一、先厘清三个词不在一个维度上

很多人把这三个词并列着说，其实它们压根不是同一层的东西：

概念	本质	解决的问题
LangChain	开发框架 / 工具库	怎么快速把 LLM、工具、记忆、检索串起来
Multi-Agent	架构模式	单个 Agent 能力不够时，怎么拆成多个角色协作
A2A	通信协议	不同厂商、不同进程的 Agent 之间怎么互相调用

一句话概括：LangChain 是“怎么写”，Multi-Agent 是“怎么分工”，A2A 是“怎么对话”。

面试时如果能把这三层拆开讲，基本就能和“只会调 API”的候选人拉开差距。

二、LangChain：它到底帮你省了什么

LangChain 最容易被误解成“一个封装了 OpenAI SDK 的库”。如果只用到 ChatOpenAI 加一个 invoke，那确实没必要用它。

它真正有价值的是三件事：

1. 抽象层统一

模型、Embedding、向量库、工具、回调，全部有统一接口。今天用通义，明天换 GPT，后天换本地 Qwen，业务代码基本不用动。

2. 编排能力

LCEL（LangChain Expression Language）用管道符把链路串起来，天然支持流式、批处理、异步和重试：

from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser
from langchain_openai import ChatOpenAI

prompt = ChatPromptTemplate.from_messages([
    ("system", "你是一个严谨的技术助手，回答要给出依据。"),
    ("human", "{question}"),
])

chain = prompt | ChatOpenAI(model="gpt-4o-mini") | StrOutputParser()

print(chain.invoke({"question": "什么是 A2A 协议？"}))

3. 生态与可观测性

LangSmith 的链路追踪在排查“Agent 为什么跑偏”时非常实用，每一步的输入输出、token 消耗、耗时都能看到。

但要说清楚它的边界：LangChain 不负责帮你设计 Agent 的决策逻辑，也不保证效果。它只是脚手架，楼盖得好不好还是看设计。

三、Multi-Agent：什么时候才真的需要

这是面试里最容易翻车的点。很多人一上来就说“我们用了 Multi-Agent”，追问一句“为什么不用单 Agent”就答不上来了。

我的判断标准很简单：当单个 Agent 的工具数量超过 10 个、或者不同任务需要完全不同的系统提示词和知识库时，才考虑拆分。

常见的几种协作模式

• Supervisor 模式：一个调度 Agent 负责分派任务，子 Agent 各管一摊。最常用，也最好调试。
• Pipeline 模式：像流水线一样串行，比如“检索 → 分析 → 撰写 → 审核”。
• Debate / 辩论模式：多个 Agent 给出不同答案再投票，适合高准确性场景，但成本翻倍。
• Hierarchical 模式：多层调度，适合超复杂任务，但工程复杂度陡增。

一个最小可运行的 Supervisor 示例

from typing import Literal
from langchain_core.tools import tool
from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.prebuilt import create_react_agent

@tool
def search_docs(query: str) -> str:
    """检索内部文档"""
    return f"关于 {query} 的检索结果：……"

@tool
def run_sql(sql: str) -> str:
    """执行只读 SQL"""
    return f"SQL 执行结果：……"

doc_agent = create_react_agent(model, tools=[search_docs])
sql_agent = create_react_agent(model, tools=[run_sql])

def supervisor(state: MessagesState) -> Literal["doc", "sql", "finish"]:
    # 这里用一次 LLM 调用做路由决策
    decision = router_llm.invoke(state["messages"])
    return decision.route

builder = StateGraph(MessagesState)
builder.add_node("supervisor", supervisor)
builder.add_node("doc", doc_agent)
builder.add_node("sql", sql_agent)
builder.add_edge(START, "supervisor")
builder.add_conditional_edges("supervisor", lambda s: s["route"], {
    "doc": "doc",
    "sql": "sql",
    "finish": END,
})
graph = builder.compile()

注意这里用的是 LangGraph 而不是 LangChain 的 AgentExecutor。原因很直接：AgentExecutor 是黑盒循环，LangGraph 是显式状态机，出问题能定位到具体节点。

面试时如果被问“Multi-Agent 怎么保证不失控”，可以答：显式状态图 + 最大轮次限制 + 每个子 Agent 独立超时 + 全链路 trace。

四、A2A：跨系统协作的那一层

A2A（Agent2Agent）解决的是另一个问题：你的 Agent 和别人的 Agent 怎么通信。

前面说的 Multi-Agent，通常是在同一个进程、同一个框架里，共享内存和状态。但真实企业场景里，客服 Agent 是 A 团队做的，订单 Agent 是 B 团队做的，甚至来自不同厂商，这时候就需要协议。

A2A 的核心要素

• Agent Card：每个 Agent 对外声明自己的能力、输入输出格式、鉴权方式，类似服务发现。
• Task：一次协作请求被抽象成任务，有明确的生命周期状态（提交、处理中、需要补充输入、完成、失败）。
• 消息与产物：任务过程中通过消息交互，最终产出 Artifact。
• 流式与异步：长任务支持 SSE 推送进度，避免同步阻塞。

和 MCP 的区别（高频追问）

维度	MCP	A2A
连接对象	Agent 与工具/数据源	Agent 与 Agent
类比	USB 接口	HTTP 服务调用
关注点	能力暴露与调用	任务协商与协作

简单记：MCP 让 Agent 会用工具，A2A 让 Agent 会找同事。

五、三者怎么组合成一个真实项目

如果让我设计一个企业级 Agent 平台，分层大概是这样：

flowchart TD
    U[用户请求] --> G[网关 / 鉴权]
    G --> S[Supervisor Agent]
    S --> A1[检索 Agent]
    S --> A2[数据分析 Agent]
    S --> A3[外部厂商 Agent]
    A1 --> M1[MCP: 知识库]
    A2 --> M2[MCP: 数据库]
    A3 -.A2A 协议.-> E[外部 Agent 服务]
    S --> R[结果聚合与审核]
    R --> U

对应到技术选型：

1. 框架层：LangGraph 做编排，LangChain 提供模型和工具抽象。
2. 协作层：Supervisor 模式拆分内部子 Agent，控制上下文长度和职责边界。
3. 协议层：内部工具走 MCP，跨团队/跨厂商走 A2A。
4. 观测层：全链路 trace，记录每次路由决策和工具调用。

六、面试被问到，我会这样答

复盘一下，如果重来一次，我不会用反问的方式，而是这样结构化地讲：

“我们项目里这三层是分开的。框架层用 LangGraph 做显式状态编排，因为 AgentExecutor 的黑盒循环不好调试；架构层用 Supervisor 模式，主 Agent 只做路由，子 Agent 各自绑定专属工具和提示词，避免工具过多导致选择困难；协议层内部工具用 MCP 统一接入，跨团队协作走 A2A，通过 Agent Card 做能力发现。效果上，路由准确率从 78% 提到 92%，平均链路耗时下降 30%。”

有分层、有选型理由、有数据，比反问有用得多。

七、写在最后

Agent 这个方向现在确实有点“概念先行”。LangChain 被吐槽封装过重，Multi-Agent 经常被做成“多个 Agent 互相甩锅”，A2A 也还在早期。

但把这三个词拆开看，它们各自要解决的问题是真实的：降低集成成本、控制复杂度、打通系统边界。

面试时真正加分的，不是知道这些名词，而是能说清楚“什么场景下不该用它”。

至于我那次反问——面试官擦汗的样子，我到现在还记得。