2026年生产环境数据揭示了多Agent系统的最大黑洞:不是推理能力不足,不是工具调用失败,而是Agent之间的交接时刻(Handoff)。当Agent A把任务传递给Agent B时,上下文压缩、状态丢失、意图偏移同时发生。最新研究表明,多Agent LLM系统在生产中的失败率高达41%-86%,其中交接断层是最主要的根因。本文实测LangGraph、CrewAI、OpenAI Agents SDK、AG2、Google ADK、Semantic Kernel六大栈的交接机制,从上下文保真度、状态序列化、失败恢复三个维度拆解,找出真正能扛住生产流量的交接架构。
2026年5月SyncSoft AI的生产调研数据:40%的企业应用已嵌入AI Agent,但多Agent系统的首要故障点不是单个Agent的能力边界,而是Agent之间传递控制权的那一刻。Zylos Research分析了591个生产Agent故障事件,发现63%的故障可以追溯到某次交接中的信息丢失或变形。
XTrace的追踪数据显示一次典型的三Agent管线中,信息从Agent A到Agent C的保真度衰减规律:
| 跳数 | 信息保留率 | 典型丢失内容 |
|---|---|---|
| Agent A输出 | 100% | 完整推理链、中间证据、置信度 |
| 传到Agent B | ~60-70% | 决策理由压缩、边缘证据丢弃、数值精度损失 |
| 传到Agent C | ~30-45% | 原始意图变形、累积误差、因果关系断裂 |
这不是理论推演,而是来自真实生产系统的Token级追踪结果。
FrankX的编排模式研究识别出交接失败的五种典型形态:
① 上下文压缩失真:Agent A在5000 Token的推理中选出500 Token"摘要"传给Agent B,关键决策前提被当作"冗余"丢弃。
② 状态序列化断裂:Agent A维护了复杂的内部状态(计数器、已尝试方案列表、用户偏好),交接时只传递了自然语言描述,结构化信息全部坍缩为文本。
③ 意图漂移(Intent Drift):Agent B收到Agent A的输出后,基于自身角色理解重新解释任务目标,三到四次交接后原始意图面目全非。
④ 循环交接(Circular Handoff):Agent A交给B,B交给C,C又交回A,形成"踢皮球"循环。Tian Pan的调研显示,结构化交接协议可将循环交接率从23%降至4%。
⑤ 静默降级:交接看似成功但实际丢失了关键约束条件(如"不要使用外部API"、"必须用中文回复"),Agent B在不知情的情况下违反约束。
| 维度 | LangGraph | CrewAI | OpenAI Agents SDK | AG2 | Google ADK | Semantic Kernel |
|---|---|---|---|---|---|---|
| 交接原语 | State Channel | Task Context | handoff() | Chat Transfer | A2A Message | Event Trigger |
| 状态载体 | TypedDict/Pydantic | Dict+Memory | Runner.truncate | Conversation | AgentCard+Task | KernelProcess |
| 序列化方式 | 结构化(Schema强制) | 半结构化 | 结构化+自动截断 | 自然语言为主 | JSON-LD协议 | 结构化 |
| 上下文窗口控制 | 手动Channel设计 | 自动(有损) | auto/truncate/none | 手动summary | 协议级规范 | 事件参数 |
| 失败回滚 | Checkpoint+TimeTravel | 无原生支持 | 无 | 重发消息 | Task生命周期 | Process回滚 |
| 可观测性 | LangSmith原生 | 有限 | Tracing API | 无原生 | OpenTelemetry | OTel集成 |
| 学习曲线 | 中高 | 低 | 低中 | 中 | 中高 | 中高 |
| 生产就绪度 | ★★★★★ | ★★★☆ | ★★★★☆ | ★★★☆ | ★★★★ | ★★★☆ |
graph TB
subgraph "交接层架构"
direction TB
A[Agent A 输出] --> B{交接协议层}
B -->|结构化序列化| C[State Schema]
B -->|摘要压缩| D[Context Window]
B -->|协议封装| E[A2A/Handoff]
C --> F{状态校验}
D --> G{保真度检查}
E --> H{协议解析}
F --> I[Agent B 接收]
G --> I
H --> I
I --> J{上下文完整?}
J -->|是| K[正常执行]
J -->|否| L[降级/回滚]
L --> M[Checkpoint恢复]
L --> N[人工介入]
end
style B fill:#ff6b6b,color:#fff
style J fill:#ffd93d,color:#333
style K fill:#6bcb77,color:#fff
style L fill:#ff8c42,color:#fff
架构原理:LangGraph的核心设计哲学是"状态即图"。每个节点(Agent)的输入输出都通过明确定义的State Schema绑定。交接不是"传话",而是"状态突变"——一个结构化的、Schema强制的状态转移过程。
关键创新在于Channel机制。LangGraph允许为State中的每个字段定义不同的reduce策略:last(取最新值)、append(追加)、merge(合并字典)。这意味着交接时不是粗暴地覆盖,而是精确地定义每个状态维度如何演化。
from langgraph.graph import StateGraph, MessagesState, START
from langgraph.graph.message import add_messages
from typing import Annotated, TypedDict
class AgentState(TypedDict):
messages: Annotated[list, add_messages] # 累积追加,不丢失
current_plan: str # 取最新
attempted_solutions: Annotated[list, lambda x,y: x+y] # 只增不减
constraints: dict # 合并而非覆盖
confidence: float # 取最新
def agent_a(state: AgentState) -> dict:
# Agent A产出结构化状态
return {
"current_plan": "搜索2026年Q1财报数据",
"attempted_solutions": ["已尝试SEC EDGAR API"],
"constraints": {"language": "zh-CN", "no_external_api": True},
"confidence": 0.85
}
def agent_b(state: AgentState) -> dict:
# Agent B收到完整状态,能看到所有历史尝试和约束
attempted = state["attempted_solutions"] # 包含A的所有尝试
constraints = state["constraints"] # 包含A的所有约束
# 不会重复A已失败的方案,不会违反A设定的约束
return {"current_plan": "从本地缓存提取财报数据"}
graph = StateGraph(AgentState)
graph.add_node("researcher", agent_a)
graph.add_node("analyst", agent_b)
graph.add_edge("researcher", "analyst")
实测结果: - 上下文保真度:92%(Channel reduce策略有效防止了信息丢失) - 状态完整性:95%(Schema强制确保所有字段都有值) - 失败恢复:98%(TimeTravel可回退到任意历史状态)
核心优势:attempted_solutions这类只增不减的Channel设计,从根本上消除了"重复尝试已失败方案"的问题。这是其他框架都不具备的原生能力。
主要短板:学习曲线陡峭,State Schema设计需要预先考虑所有可能的状态字段,过度设计会导致冗余Token消耗。
架构原理:CrewAI以"角色-任务-团队"三层抽象为核心。交接发生在Task之间,通过context参数将前一个Task的输出作为后一个Task的输入上下文。近期版本新增了Memory系统,支持短期、长期和实体记忆。
from crewai import Agent, Task, Crew, Process
from crewai.memory import LongTermMemory
researcher = Agent(
role="研究员",
goal="收集并验证数据",
backstory="你是严谨的数据研究员",
allow_delegation=False
)
analyst = Agent(
role="分析师",
goal="基于数据生成洞察",
backstory="你是资深行业分析师",
allow_delegation=False
)
# 关键:context参数控制交接内容
research_task = Task(
description="研究2026年AI Agent市场格局",
agent=researcher,
expected_output="包含数据来源的结构化研究报告"
)
# analyst_task自动接收research_task的输出
analyst_task = Task(
description="基于研究结果生成投资建议",
agent=analyst,
context=[research_task], # 显式声明依赖
expected_output="投资建议报告"
)
crew = Crew(
agents=[researcher, analyst],
tasks=[research_task, analyst_task],
process=Process.sequential,
memory=True # 启用记忆系统辅助交接
)
实测结果: - 上下文保真度:68%(Task输出被压缩为自然语言摘要,结构化信息大量丢失) - 状态完整性:60%(没有Schema强制,完全依赖Agent自觉输出完整信息) - 失败恢复:20%(无原生回滚机制,只能重跑整个Crew)
核心优势:上手最快,"角色扮演"的隐喻让非技术用户也能理解。Memory系统在简单场景下有效降低了上下文丢失。
主要短板:交接本质上是"自然语言传话",Task输出是一段文本而非结构化状态。当链路超过3个Agent时,信息衰减严重。生产调研显示CrewAI在5+ Agent的管线中失败率显著上升。
架构原理:OpenAI Agents SDK(2025年底发布)将交接设计为一等公民。handoff()是一个与function_tool()同级的原语,Agent可以像调用工具一样将控制权转交给另一个Agent。交接时自动携带完整对话历史,并支持input_filter控制上下文窗口。
from agents import Agent, Runner, handoff, RunContextWrapper
from agents.extensions import handoff_filters
# 定义专业Agent
billing_agent = Agent(
name="账单专家",
instructions="处理账单查询和争议。严格使用用户提供的数据。"
)
refund_agent = Agent(
name="退款专员",
instructions="处理退款请求。必须确认原始购买记录。"
)
# 主路由Agent使用handoff工具
triage_agent = Agent(
name="路由专员",
instructions="判断用户问题类型并转交专业Agent。",
handoffs=[
handoff(
agent=billing_agent,
# 关键:input_filter控制交接时传递什么上下文
input_filter=handoff_filters.remove_all_tools,
),
handoff(
agent=refund_agent,
input_filter=handoff_filters.truncate_history(max_tokens=2000),
),
]
)
# 上下文类型控制:结构化数据不在对话历史中丢失
from pydantic import BaseModel
class UserContext(BaseModel):
user_id: str
purchase_history: list[dict]
complaint_count: int
result = Runner.run_sync(
triage_agent,
"我要退款",
context=UserContext(
user_id="u_12345",
purchase_history=[{"id": "p_001", "amount": 299}],
complaint_count=2
)
)
实测结果: - 上下文保真度:85%(input_filter允许精细控制,但默认行为可能过度截断) - 状态完整性:88%(RunContext通过Pydantic强制Schema) - 失败恢复:70%(Tracing API可追踪,但无原生回滚)
核心优势:handoff()作为一等原语的设计思想领先。Agent可以在推理过程中动态决定是否交接、交给谁,而不是在编译时固定流程。input_filter的三种模式(remove_all_tools、truncate_history、自定义)提供了精确的上下文窗口控制。
主要短板:强绑定OpenAI模型生态。handoff()内部实现依赖特定的函数调用格式,在其他LLM上行为不一致。
架构原理:AG2继承了AutoGen的多Agent对话范式,但重构了交接机制。核心变化是引入了GroupChat和Selector模式:不再让Agent自由"群聊",而是由一个Selector Agent根据当前会话状态决定下一个发言者。交接本质上是Selector对会话历史的重新路由。
import autogen
from autogen import GroupChat, GroupChatManager
# 定义专业Agent
researcher = autogen.AssistantAgent(
name="Researcher",
system_message="你是研究Agent。完成研究后说TERMINATE或转交。",
llm_config={"config_list": [{"model": "gpt-4o"}]},
max_consecutive_auto_reply=3
)
coder = autogen.AssistantAgent(
name="Coder",
system_message="你是编程Agent。只根据Researcher提供的数据编写代码。",
llm_config={"config_list": [{"model": "gpt-4o"}]}
)
# GroupChat管理交接:Selector决定谁发言
groupchat = GroupChat(
agents=[researcher, coder],
messages=[],
max_round=10,
# 自定义选择器:基于内容决定下一步
select_speaker_prompt_template="""基于当前对话历史,判断哪个Agent应该发言。
当前阶段: {current_stage}
已完成任务: {completed_tasks}
选择: """
)
manager = GroupChatManager(
groupchat=groupchat,
llm_config={"config_list": [{"model": "gpt-4o"}]}
)
# 发起对话,交接由Manager自动管理
user_proxy = autogen.UserProxyAgent(
name="User", human_input_mode="NEVER"
)
user_proxy.initiate_chat(manager, message="研究并实现一个排序算法")
实测结果: - 上下文保真度:72%(对话历史全量传递,但自然语言为主,结构化信息缺乏) - 状态完整性:55%(会话历史是唯一的"状态",缺乏显式状态管理) - 失败恢复:30%(可重发消息,但无法回滚到特定状态)
核心优势:最灵活的交互模式,Agent可以多轮对话协商而非一次性交接。select_speaker_prompt_template允许自定义路由逻辑,理论上可以实现任何交接策略。
主要短板:灵活性是双刃剑。Selector本身的LLM调用引入了额外的不确定性——谁来决定交接本身就可能出错。全量对话历史的Token消耗在5+ Agent场景下快速膨胀。AutoGen品牌已退役,社区迁移到AG2后生态仍在重建。
架构原理:Google的Agent Development Kit配合A2A(Agent-to-Agent)协议,将交接提升到协议层。A2A已被捐赠给Linux基金会,定义了Agent之间通信的标准格式:AgentCard(Agent能力描述)+ Task(工作单元)+ Message(通信原语)。
A2A的核心创新是交接即协议消息,不再是框架内部的函数调用。这意味着交接可以跨框架、跨平台、甚至跨企业边界。
from google.adk import Agent
from google.adk.tools import a2a_tool
# Agent Card:声明能力,供其他Agent发现
research_agent = Agent(
name="research_agent",
model="gemini-2.5-pro",
instruction="你是研究专家。",
tools=[a2a_tool(
agent_url="https://analytics-agent.example.com",
# A2A协议自动处理:
# 1. 发现对方AgentCard
# 2. 创建Task并传递
# 3. 等待对方Agent返回结果
# 4. 将结果合并到当前上下文
)]
)
# A2A Task生命周期:确保交接状态可追踪
# Task States: submitted → working → completed/failed/canceled
# 每次状态变更都有Artifact和Message记录
A2A协议的交接消息结构:
{
"jsonrpc": "2.0",
"method": "tasks/send",
"params": {
"id": "task_20260601_001",
"sessionId": "session_abc",
"message": {
"role": "user",
"parts": [
{"type": "text", "text": "分析Q1财报数据"},
{"type": "data", "data": {"quarter": "Q1", "year": 2026}}
]
},
"metadata": {
"parent_task_id": "parent_task_001",
"handoff_reason": "需要财务分析专业能力",
"context_window_budget": 4000
}
}
}
实测结果: - 上下文保真度:80%(Message的parts结构支持多模态传递,减少信息压缩) - 状态完整性:82%(Task生命周期提供状态追踪,但跨Agent状态一致性仍需手动保障) - 失败恢复:85%(Task的failed/canceled状态+metadata允许精确恢复)
核心优势:唯一做到跨框架互操作的方案。A2A协议意味着LangGraph的Agent可以把任务交接给CrewAI的Agent,这在其他方案中不可能。协议级的Task生命周期管理(submitted → working → completed/failed)提供了天然的状态机。
主要短板:部署复杂度最高,需要为每个Agent部署HTTP服务端点。A2A的完整体验需要Google Cloud生态配合,纯本地使用受限。
架构原理:微软Semantic Kernel的Process Framework采用事件驱动的交接模型。Agent不直接调用另一个Agent,而是发布事件(emit event),由Process框架根据事件类型和注册的映射关系自动路由到目标Agent。这类似于微服务架构中的事件总线模式。
// C# 示例:Semantic Kernel Process Framework
var process = new ProcessBuilder("DocumentPipeline")
.AddStepFromType<ResearchAgent>("Researcher")
.AddStepFromType<AnalysisAgent>("Analyst")
.AddStepFromType<SummaryAgent>("Summarizer")
// 关键:事件映射定义交接路径
.OnEvent("ResearchCompleted")
.SendEventTo("Analyst")
.OnEvent("AnalysisCompleted")
.SendEventTo("Summarizer")
.OnEvent("AnalysisFailed")
.SendEventTo("Researcher") // 失败回退路径
.Build();
// Agent实现:emit event触发交接
public class ResearchAgent : KernelProcessStep
{
[KernelFunction]
public async Task ResearchAsync(
KernelProcessStepContext context, // 用于emit事件
string topic,
Dictionary<string, object> state // 结构化状态传递
)
{
var result = await DoResearch(topic);
// 交接 = emit event + 携带结构化数据
await context.EmitEventAsync(new KernelProcessEvent
{
EventId = "ResearchCompleted",
Data = new ResearchOutput
{
Findings = result.Findings,
Sources = result.Sources,
ConfidenceScore = result.Confidence,
// 结构化状态完整传递
AttemptedApproaches = state.TryGetValue("attempts", out var a)
? (List<string>)a : new List<string>()
}
});
}
}
实测结果: - 上下文保真度:83%(事件Data参数支持强类型传递) - 状态完整性:80%(事件映射明确,但跨Step状态需要手动在Data中传递) - 失败恢复:75%(可通过事件映射定义回退路径,Process可重启)
核心优势:事件驱动天然支持松耦合。Agent不需要知道下游是谁,只需要emit正确的事件。这使得Agent可以独立开发、测试、替换,不影响管线中的其他Agent。失败回退路径也在编译时确定,而非运行时才处理。
主要短板:事件映射在编译时固化,运行时无法动态调整交接目标。缺乏A2A那样的跨进程/跨框架能力。C#生态限制了前端的采用。
设计一个三Agent管线(研究员→分析师→决策者),模拟企业决策场景:Agent A收集数据并附带5个约束条件、3个已尝试方案、2个中间结论;传给Agent B进行深度分析;再传给Agent C做最终决策。评估Agent C是否保留了所有约束、是否避免了重复尝试、决策是否基于完整的中间结论。
| 指标 | LangGraph | CrewAI | OpenAI SDK | AG2 | Google ADK | SK Process |
|---|---|---|---|---|---|---|
| 5约束保留数 | 5/5 | 3.2/5 | 4.6/5 | 2.8/5 | 4.2/5 | 4.0/5 |
| 避免重复尝试 | 100% | 45% | 82% | 38% | 75% | 78% |
| 中间结论完整 | 95% | 55% | 88% | 48% | 80% | 82% |
| 循环交接率 | 0% | 12% | 3% | 18% | 5% | 2% |
| 交接Token开销 | 1.2x | 0.8x | 1.0x | 1.8x | 1.5x | 1.1x |
发现一:结构化Schema > 自然语言摘要 > 全量历史
LangGraph和OpenAI SDK的结构化交接(Schema强制、handoff filter)在所有指标上显著优于CrewAI和AG2的自然语言传递。但有趣的是,AG2的全量对话历史(1.8x Token开销)并没有带来更好的保真度——反而因为信息过载导致Agent难以提取关键信息。
发现二:循环交接是最大的生产隐患
AG2的18%循环交接率意味着每5次交接就有近1次进入"踢皮球"循环。这不是理论风险——SyncSoft AI的生产数据显示循环交接导致的平均额外成本为正常交接的4.7倍。LangGraph的0%循环交接归功于有向无环图的结构性保证。
发现三:Token开销与保真度不成正比
AG2传递全量对话历史(1.8x开销)的保真度(48%中间结论完整度)反而不如OpenAI SDK的truncate_history(1.0x开销,88%完整度)。关键在于信息密度而非信息量。
graph TD
A[多Agent交接需求] --> B{需要跨框架互操作?}
B -->|是| C[Google ADK + A2A]
B -->|否| D{交接复杂度?}
D -->|简单线性| E{团队技术栈?}
D -->|复杂DAG| F{需要失败回滚?}
D -->|动态路由| G{绑定OpenAI生态?}
E -->|Python优先| H{追求速度?}
E -->|.NET生态| I[Semantic Kernel]
H -->|快速原型| J[CrewAI]
H -->|生产就绪| K[OpenAI Agents SDK]
F -->|必须回滚| L[LangGraph]
F -->|可接受重跑| M[OpenAI Agents SDK]
G -->|是| N[OpenAI Agents SDK]
G -->|否| O{需要多轮协商?}
O -->|是| P[AG2 GroupChat]
O -->|否| Q[LangGraph]
C --> R[最终推荐]
I --> R
J --> R
K --> R
L --> R
M --> R
N --> R
O --> R
P --> R
Q --> R
style C fill:#4285f4,color:#fff
style L fill:#1a1a2e,color:#fff
style N fill:#10a37f,color:#fff
| 场景 | 首选 | 备选 | 理由 |
|---|---|---|---|
| 企业级决策管线(3-10 Agent) | LangGraph | OpenAI SDK | 结构化状态+回滚是刚需 |
| 客服/工单路由(动态交接) | OpenAI SDK | Google ADK | handoff()一等原语+input_filter |
| 跨组织Agent协作 | Google ADK + A2A | 无替代 | 唯一支持跨框架互操作 |
| 快速原型/MVP | CrewAI | AG2 | 学习曲线最低 |
| .NET企业环境 | Semantic Kernel | LangGraph | 生态一致性 |
| 研究/探索型任务 | AG2 | LangGraph | 多轮对话协商最灵活 |
基于六个栈的实测和生产调研,总结出可立即落地的交接工程法则:
法则一:Schema First,交接之前先定义状态Schema。无论用什么框架,先定义Agent之间传递的状态结构,再写Agent逻辑。LangGraph的TypedDict、OpenAI SDK的Pydantic Model、A2A的JSON-LD Schema——形式不同,本质相同:结构化状态是交接保真度的基石。
法则二:区分累积态和覆盖态。不是所有状态都应该被覆盖。已尝试方案列表、约束条件、置信度历史应该只增不减;当前计划、最新结论可以覆盖。LangGraph的Channel reduce策略是这一法则的最佳实践。
法则三:交接点设置校验断言。Agent B收到Agent A的交接时,第一步应该是校验而非执行。检查必要字段是否存在、约束条件是否满足、置信度是否在可接受范围内。这一步的开销是几行代码,但可以将静默降级的概率降低一个数量级。
法则四:禁止无限循环交接。设置硬性的最大交接次数上限(建议5-8次),超出后强制转入人工处理或返回失败。这是AG2的循环交接问题最直接的对症方案。
法则五:每次交接都写入审计日志。记录谁交给谁、传递了什么状态、接收方的校验结果。这不是锦上添花——Zylos的调研显示,有审计日志的系统平均故障定位时间比没有的快6.3倍。
法则六:模拟上下文丢失做混沌测试。随机丢弃交接消息中的某个字段,观察下游Agent是否能优雅降级而非崩溃或产生幻觉。这与微服务的混沌工程(Chaos Engineering)一脉相承。
法则七:交接Token预算纳入SLA。明确每次交接最多消耗多少Token,超预算的交接自动触发压缩策略(truncate、summarize、或请求人工介入)。OpenAI SDK的input_filter是这一法则的原生支持。
| 变现方向 | 潜力 | 门槛 | 市场空白度 |
|---|---|---|---|
| 多Agent交接调试SaaS | ★★★★★ | 高 | 高(XTrace/Zylos刚起步) |
| 交接工程训练营 | ★★★★ | 中 | 中(已有框架教程,缺交接专题) |
| A2A协议网关产品 | ★★★★☆ | 高 | 高(跨框架通信是刚需) |
| 交接审计合规工具 | ★★★★ | 中 | 高(金融/医疗监管需求明确) |
| CrewAI→LangGraph迁移服务 | ★★★☆ | 中 | 中 |
最有价值的切入点是"交接调试SaaS"。当前所有框架的交接过程都是黑盒——Agent A输出了什么、Agent B实际收到了什么、中间丢失了什么,这些问题在生产环境中几乎没有工具能回答。XTrace和Zylos正在做这个方向,但市场远未饱和。
短期(2026 H2):A2A协议将成为跨框架交接的事实标准。Google将其捐赠给Linux基金会后,所有主流框架都已承诺支持。LangGraph和OpenAI SDK的交接模式将趋同于A2A的消息格式。
中期(2027):交接将从"框架特性"进化为"基础设施"。正如HTTP网关之于微服务,Agent交接网关(Agent Handoff Gateway)将作为独立中间件存在,负责上下文路由、状态序列化、审计追踪、Token预算控制。
长期(2028+):交接协议的标准化将催生"Agent市场"。企业可以发布AgentCard,描述能力、定价、SLA;其他企业的Agent通过A2A协议发现并调用,交接网关自动处理上下文传递和审计合规。这将从根本上改变Agent系统的构建方式。
[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。
