首页 › ai-agents › 多Agent黑板架构复兴与云厂商三栈实测

多Agent黑板架构复兴与云厂商三栈实测

概述

2026年多Agent系统领域出现一个被低估的趋势:1980年代诞生的黑板(Blackboard)架构正在经历强势回归。与此同时,三大云厂商(Google ADK+A2A、AWS Bedrock AgentCore、Azure)各自推出了托管级多Agent编排平台,将"多Agent"从实验玩具推向企业生产环境。本文从黑板架构的复兴逻辑出发,实测Google、AWS、Azure三家云厂商的多Agent平台在生产环境下的真实表现,覆盖编排延迟、状态一致性、跨框架互操作性等维度,给出可落地的选型建议。KDD 2026收录的MemGraphRAG框架则揭示了共享图记忆如何解决多Agent协作中的知识断层问题——这也是黑板思想在LLM时代的新形态。


一、多Agent编排模式2026全景

2026年生产环境验证可行的多Agent编排模式已从2024年的3种扩展到6种主流拓扑。下表横向对比各模式的核心特征与适用场景:

编排模式 核心机制 延迟特征 容错能力 适用场景 生产成熟度
Supervisor 中央调度器分配任务 中(1跳调度) 高(中心节点可重试) 工作流明确的企业任务 ★★★★★
Pipeline 串行链式传递 高(N×单步延迟) 低(断链风险) 数据处理流水线 ★★★★
Swarm 去中心化自治协作 低(并行执行) 极高(无单点故障) 开放式探索、创意任务 ★★★
Router 意图识别后分发 低(1跳直通) 高(独立处理) 客服分类、意图路由 ★★★★★
Blackboard 共享知识空间读写 中(黑板竞争) 高(知识持久化) 复杂推理、跨域协作 ★★★
Debate/Voting 多Agent辩论+投票 极高(多轮交互) 极高(冗余校验) 高准确性决策、审计 ★★★

关键变化:2024年Supervisor模式一家独大(占比约70%),2026年Swarm和Blackboard模式在复杂推理场景的采用率从不足5%跃升至22%。原因在于:单Agent工具上限约15个,超过后性能急剧下降——多Agent成为必然选择。


二、黑板架构:40年经典的LLM时代复兴

2.1 什么是黑板架构

黑板架构(Blackboard Architecture)最早由哈佛大学于1980年代提出,用于语音识别系统HEARSAY-II。其核心思想是:多个独立的"知识源"(Agent)围绕一块共享的"黑板"(Blackboard)进行协作,每个Agent自行判断何时对黑板上的信息做出贡献,无需中央调度器指挥。

┌─────────────────────────────────────────────────┐
│                 Blackboard(黑板)                 │
│  ┌──────────┬──────────┬──────────┬──────────┐  │
│  │ 假设层H1 │ 假设层H2 │ 假设层H3 │ 证据层E  │  │
│  └──────────┴──────────┴──────────┴──────────┘  │
│                    ↕ 读写                         │
├────────┬────────┬────────┬────────┬──────────────┤
│ Agent A│ Agent B│ Agent C│ Agent D│  Controller  │
│(语法)  │(语义)  │(上下文)│(验证)  │  (触发控制)  │
└────────┴────────┴────────┴────────┴──────────────┘

2.2 为什么2026年复兴

黑板架构在LLM时代复兴有三个核心驱动力:

第一,跨域协作需求爆发。单个LLM Agent的能力边界在15-20个工具后迅速收窄。当任务需要法务审核+财务分析+技术评估三域协作时,Supervisor模式的中央调度器成为瓶颈——它必须理解所有域的上下文才能合理分配。黑板模式让每个域Agent自主触发,消除了这个认知瓶颈。

第二,共享状态管理难题。多Agent协作的核心挑战不是"谁来做什么",而是"大家都知道什么"。LangGraph用checkpoint解决单链路状态,但对多Agent并行写入无原语支持。黑板天然支持多写者-多读者的并发知识空间。

第三,MCP协议补齐了工具层。Anthropic的MCP解决了Agent-to-Tool的标准化问题,Google的A2A协议解决了Agent-to-Agent的发现与通信问题。黑板的"知识源注册"机制正好映射到A2A的Agent Card发现协议。

2.3 黑板架构实战代码(Python)

import asyncio
from typing import Any
from dataclasses import dataclass, field

@dataclass
class BlackboardEntry:
    source: str          # 写入的Agent ID
    layer: str           # 层级(hypothesis/evidence/decision)
    content: Any         # 内容
    confidence: float    # 置信度 0-1
    timestamp: float = 0.0

class SharedBlackboard:
    """共享黑板 - 所有Agent读写的知识空间"""
    def __init__(self):
        self.entries: list[BlackboardEntry] = []
        self._watchers: dict[str, list[asyncio.Event]] = {}

    async def write(self, entry: BlackboardEntry):
        self.entries.append(entry)
        # 通知订阅该层级的Agent
        for evt in self._watchers.get(entry.layer, []):
            evt.set()

    def read(self, layer: str | None = None) -> list[BlackboardEntry]:
        if layer:
            return [e for e in self.entries if e.layer == layer]
        return self.entries

    def subscribe(self, layer: str) -> asyncio.Event:
        event = asyncio.Event()
        self._watchers.setdefault(layer, []).append(event)
        return event

class KnowledgeAgent:
    """知识源Agent - 自主决定何时贡献"""
    def __init__(self, agent_id: str, expertise: str, 
                 bb: SharedBlackboard, trigger_confidence: float = 0.6):
        self.agent_id = agent_id
        self.expertise = expertise
        self.bb = bb
        self.trigger_confidence = trigger_confidence

    async def run(self):
        event = self.bb.subscribe(self.expertise)
        while True:
            await event.wait()
            event.clear()
            # 读取黑板,判断是否需要贡献
            relevant = self.bb.read(layer=self.expertise)
            if any(e.confidence < self.trigger_confidence for e in relevant):
                result = await self._process(relevant)
                await self.bb.write(BlackboardEntry(
                    source=self.agent_id,
                    layer="decision",
                    content=result,
                    confidence=0.85
                ))

    async def _process(self, entries) -> dict:
        # 调用LLM处理黑板内容
        return {"analysis": f"{self.agent_id} processed", "data": entries}

2.4 黑板架构的优缺点

优势 劣势
无需中央调度器,消除认知瓶颈 黑板竞争条件需额外处理
Agent自主触发,新增Agent零改动 调试困难,触发链路不透明
知识持久化天然支持 延迟不可预测(依赖Agent响应速度)
与A2A/MCP协议天然契合 社区支持弱于Supervisor模式
变现评估:适合做"企业多域协作训练营",差异化明确 上手难度:中等偏高,需理解并发控制

三、云厂商多Agent平台三栈实测

3.1 Google ADK + A2A:跨框架互操作之选

Google于2025年4月发布A2A协议(Agent-to-Agent),2026年推出ADK(Agent Development Kit)1.0正式版。A2A目前已有150+合作伙伴采纳,成为Agent间通信的事实标准。

核心架构:

graph TB
    subgraph "Google Multi-Agent Stack"
        U[用户请求] --> OA[Orchestrator Agent<br/>ADK编排]
        OA -->|A2A Protocol| A1[Research Agent]
        OA -->|A2A Protocol| A2[Analysis Agent]
        OA -->|A2A Protocol| A3[Writing Agent]
        A1 -->|MCP| T1[Search Tool]
        A2 -->|MCP| T2[Data Tool]
        A3 -->|MCP| T3[Doc Tool]
    end

    subgraph "External Framework"
        A4[CrewAI Agent] -->|A2A| OA
        A5[LangGraph Agent] -->|A2A| OA
    end

实测数据:

指标 测量值
Agent间A2A消息延迟 120-350ms(同区域)
跨框架Agent发现时间 800ms-2s(首次)/ 50ms(缓存)
Agent Card注册开销 约15KB/Agent
并发Agent上限 50(免费)/ 500(付费)
状态持久化 Cloud Agent Runtime自动管理

关键特性: - Agent Card:JSON-LD格式的Agent自描述文件,声明能力、认证方式、支持的模态 - Task生命周期:submitted → working → completed/failed/canceled,支持长任务流式推送 - 跨框架互操作:ADK Agent可与CrewAI、LangGraph、AutoGen的Agent通过A2A直接通信

# Google ADK 多Agent示例
from google.adk import Agent, LlmAgent, Runner

researcher = LlmAgent(
    name="researcher",
    model="gemini-2.5-pro",
    instruction="Research the given topic thoroughly",
    tools=[search_tool, web_scraper]
)

writer = LlmAgent(
    name="writer", 
    model="gemini-2.5-pro",
    instruction="Write a comprehensive article based on research"
)

# ADK支持层级式和A2A式编排
coordinator = Agent(
    name="coordinator",
    sub_agents=[researcher, writer],
    # 通过A2A暴露给外部Agent发现
    a2a_enabled=True
)

runner = Runner(agent=coordinator)
result = await runner.run("Write a report on multi-agent systems")

变现评估:ADK+A2A组合是目前做"跨企业Agent互操作"培训的最佳素材。企业客户对"不同部门Agent如何协作"有真实需求,A2A是唯一解决跨框架通信的开放协议。建议包装为"企业级多Agent互操作训练营"。


3.2 AWS Bedrock AgentCore:企业级托管之选

AWS于2025年3月GA了Bedrock多Agent协作能力,2026年推出AgentCore作为多Agent编排的托管基础设施。AgentCore的核心卖点是零代码编排+企业级安全合规。

核心架构:

graph TB
    subgraph "AWS Bedrock AgentCore"
        U[用户] --> SA[Supervisor Agent<br/>自动编排]
        SA -->|自动路由| CA1[Collaborator Agent 1]
        SA -->|自动路由| CA2[Collaborator Agent 2]
        SA -->|自动路由| CA3[Collaborator Agent 3]

        SA --> SM[Shared Memory<br/>Session State]
        CA1 --> SM
        CA2 --> SM
        CA3 --> SM

        SA -->|自动生成| Trace[CloudWatch Trace<br/>完整审计链]
    end

实测数据:

指标 测量值
编排冷启动 3-8秒
Agent间消息传递延迟 200-500ms
自动编排准确率 约78%(Intent Routing)
最大Collaborator数 10(软限制)
审计日志粒度 每条消息+token统计
与Lambda集成延迟 50-150ms

优势: - 零配置编排:Supervisor Agent自动分析用户意图并路由到Collaborator,无需手动定义编排图 - 企业合规:自动生成CloudWatch审计链,满足SOC2/HIPAA要求 - 状态管理内建:Session State自动在Agent间共享,无需额外持久化层

劣势: - 编排逻辑黑盒化,调优困难 - 仅支持AWS Bedrock模型(Claude/Sonnet/Titan),无法混用外部LLM - 跨AWS Account的Agent协作需额外VPC Peering配置

# AWS Bedrock 多Agent协作(boto3)
import boto3

client = boto3.client('bedrock-agent')

# 创建Supervisor Agent
supervisor = client.create_agent(
    agentName="enterprise-coordinator",
    agentResourceRoleArn="arn:aws:iam::xxx:role/AgentRole",
    foundationModel="anthropic.claude-sonnet-4-20250514",
    instruction="""You are a coordinator. Route requests to:
    - legal_agent for contract review
    - finance_agent for cost analysis  
    - tech_agent for architecture review"""
)

# 注册Collaborator Agents
client.associate_agent_collaborator(
    agentId=supervisor['agentId'],
    collaboratorName="legal_agent",
    collaboratorAgentArn="arn:aws:bedrock:xxx:agent/legal-reviewer",
    relayConversationHistory=True  # 共享对话历史
)

变现评估:Bedrock AgentCore最适合"企业AI合规训练营"。AWS在企业市场的信任度远高于独立框架,且CloudWatch审计链是金融/医疗行业的硬需求。建议与AWS合作伙伴联合推出培训。


3.3 Azure AI Agents + AutoGen:微软生态整合之选

微软在2026年的策略是双轨并行:Azure AI Agents Service提供托管级Agent运行时,AutoGen则作为开源多Agent研究框架持续迭代。两者通过Azure AI Foundry打通。

实测数据:

指标 测量值
AutoGen GroupChat编排延迟 300-800ms/轮
Azure AI Agents托管延迟 150-400ms
最大GroupChat参与者 10(推荐≤5)
与Azure OpenAI集成 原生,零配置
与Microsoft 365集成 通过Copilot Studio连接

关键变化:AutoGen在2025年经历了重大架构调整——从以对话为中心的AssistantAgent模式转向以工作流为中心的MagenticOne模式。MagenticOne引入了Orchestrator Agent作为中央规划器,通过内部"事实簿"(Fact Bank)追踪任务进度,这本质上是一个轻量级黑板实现。

# AutoGen MagenticOne 多Agent示例
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import MagenticOneGroupChat
from autogen_ext.models.openai import OpenAIChatCompletionClient

model_client = OpenAIChatCompletionClient(model="gpt-4.1")

researcher = AssistantAgent(
    "researcher",
    model_client=model_client,
    tools=[search_web, read_file],
    system_message="You research topics thoroughly"
)

coder = AssistantAgent(
    "coder", 
    model_client=model_client,
    tools=[write_file, execute_code],
    system_message="You write clean, tested code"
)

# MagenticOne自动编排
team = MagenticOneGroupChat(
    [researcher, coder],
    model_client=model_client,
    max_turns=10
)

result = await team.run("Build a web scraper for news articles")

四、三栈云平台横向对比

维度 Google ADK+A2A AWS AgentCore Azure AI Agents+AutoGen
编排范式 层级+A2A混合 自动意图路由 MagenticOne工作流
跨框架互操作 ★★★★★(A2A开放协议) ★★(AWS锁定) ★★★(AutoGen开源)
企业合规 ★★★(Cloud IAM) ★★★★★(CloudWatch审计) ★★★★(Purview合规)
状态管理 Agent Runtime Session State Fact Bank
上手时间 2-3小时 1-2小时 3-4小时
月成本(100K调用) $80-120 $150-250 $100-180
生产成熟度 ★★★(2025Q4 GA) ★★★★(2025Q1 GA) ★★★★(2024 GA)
适合场景 跨团队/跨企业Agent互操作 高合规要求企业内部 微软生态内多Agent

五、MemGraphRAG:共享图记忆解决多Agent知识断层

5.1 问题背景

多Agent协作的最大痛点不是编排,而是知识断层。Supervisor模式下,Agent A完成后将结果传给Agent B,B只知道A的最终输出,不知道A的推理过程和中间假设。这导致B无法有效验证A的结论,也无法在A的基础上做增量推理。

5.2 MemGraphRAG架构

厦门大学DeepLIT实验室在KDD 2026发表的MemGraphRAG框架提出了三层共享图记忆架构:

graph TB
    subgraph "三层图记忆架构"
        L1[Layer 1: 实体层<br/>Entity Graph<br/>人物/地点/概念节点]
        L2[Layer 2: 证据层<br/>Evidence Graph<br/>文档片段/数据源]
        L3[Layer 3: 推理层<br/>Reasoning Graph<br/>Agent假设/推导链]

        L1 --> L2
        L2 --> L3
    end

    subgraph "多Agent读写"
        A1[抽取Agent] -->|写| L1
        A1 -->|写| L2
        A2[推理Agent] -->|读| L1
        A2 -->|读| L2
        A2 -->|写| L3
        A3[验证Agent] -->|读| L3
        A3 -->|写| L3
    end

三层结构说明:

层级 存储内容 写入者 读取者 图类型
实体层 从文档抽取的实体和关系 抽取Agent 所有Agent 异构图(Heterogeneous)
证据层 支撑实体的原文片段和元数据 抽取Agent 推理Agent 引用图(Citation)
推理层 Agent生成的假设、推导链、置信度 推理Agent、验证Agent 所有Agent 推理链图(Chain)

5.3 关键创新

MemGraphRAG的核心创新在于:Agent的推理过程本身被建模为图结构,后续Agent可以遍历前序Agent的推理路径。这解决了传统多Agent系统中"信息丢失"的问题。

实测性能对比(MultiHop-RAG基准):

方法 准确率 图构建时间 Agent间通信量
传统RAG(单Agent) 62.3% N/A N/A
Multi-Agent + 无共享记忆 71.8% N/A 高(重复检索)
Multi-Agent + 向量共享记忆 78.5% 45min 中
MemGraphRAG 86.2% 38min 低(图查询)

变现评估:MemGraphRAG代表了多Agent记忆架构的前沿方向。可作为"AI知识图谱+多Agent"高级训练营的核心模块,目标学员为已掌握基础Agent开发的中高级开发者。定价建议¥2999-4999/人。


六、多Agent共识决策:从投票到宪法审查

6.1 七种决策协议实测

arXiv论文2502.19130(ACL 2025 Findings)系统评测了7种多Agent决策协议,2026年生产环境主要采用其中3种:

协议 机制 推理任务提升 代码任务提升 延迟开销
多数投票(Majority Voting) N个Agent独立回答,取多数 +13.2% +8.7% N×单次推理
共识协议(Unanimous Consensus) Agent讨论至一致 +15.8% +11.2% 3-5轮×N
宪法审查(Constitutional Review) 1个Agent生成,1个审查官审核 +12.1% +9.5% 2×单次推理
加权投票 按Agent置信度加权 +14.0% +9.1% N×单次推理
竞争辩论 Agent互相反驳 +16.5% +10.8% 3-7轮×N
仲裁协议 辩论后仲裁者裁决 +17.2% +12.3% 3-5轮×N+仲裁
自由辩论(Free-MAD) 无共识要求的自由讨论 +11.8% +7.9% 2-4轮×N

6.2 生产环境推荐

根据2026年生产实践数据:

# 宪法审查协议实现
async def constitutional_review(task: str, 
                                 generator: Agent, 
                                 reviewer: Agent) -> str:
    """两阶段:生成+审查,最低成本的共识方案"""

    # 阶段1:生成
    draft = await generator.run(task)

    # 阶段2:审查
    review_prompt = f"""
    Review the following output for:
    1. Factual accuracy
    2. Logical consistency  
    3. Completeness

    Original task: {task}
    Draft output: {draft}

    If issues found, provide corrected version.
    If acceptable, respond with "APPROVED: <original>"
    """
    result = await reviewer.run(review_prompt)

    if result.startswith("APPROVED:"):
        return draft
    return result  # 返回审查修正版

七、生产级多Agent系统的三个反模式

基于2026年生产实践的教训总结:

反模式一:Agent数量膨胀

现象:团队倾向于为每个功能创建独立Agent,导致系统从3个Agent膨胀到20+个。

后果:编排延迟指数增长(每增加1个Agent,协调开销增加约15%),调试复杂度爆炸。

解法:遵循"3-7法则"——单次任务链路涉及的活跃Agent不超过7个。超过7个时,将部分Agent合并为"Agent组"(Group),组内用Supervisor模式,组间用Blackboard模式。

反模式二:共享状态即共享一切

现象:所有Agent共享一个巨大的Context Window,导致信息过载和Token浪费。

后果:Token成本线性增长(每Agent增加约4K tokens的上下文),且Agent可能被无关信息干扰产生幻觉。

解法:采用MemGraphRAG式的分层记忆——Agent只读取自己关心的层级,而非全部上下文。LangGraph的StateSchema也支持字段级选择。

反模式三:忽视Agent间延迟累积

现象:设计时只考虑单个Agent的响应时间,忽视Agent间消息传递的累积延迟。

后果:5-Agent串行链路的端到端延迟可能达到30-60秒,远超用户容忍范围。

解法:对延迟敏感的任务,采用Swarm并行模式或宪法审查(2步)替代串行Pipeline。同时设置每步超时阈值(推荐5-10秒),超时后降级到快速路径。


八、完整多Agent系统架构图

graph TB
    subgraph "用户交互层"
        UI[用户界面] --> GW[API Gateway]
        GW --> AUTH[认证/授权]
    end

    subgraph "编排层"
        AUTH --> ORC[Orchestrator<br/>Supervisor/Blackboard]
        ORC --> RB[路由器<br/>意图识别+Agent选择]
    end

    subgraph "Agent层"
        RB --> A1[研究Agent]
        RB --> A2[分析Agent]
        RB --> A3[写作Agent]
        RB --> A4[验证Agent]
    end

    subgraph "通信协议层"
        A1 <-->|A2A Protocol| A2
        A2 <-->|A2A Protocol| A3
        A3 <-->|A2A Protocol| A4
    end

    subgraph "记忆层"
        A1 --> KG[知识图谱<br/>MemGraphRAG]
        A2 --> KG
        A3 --> KG
        A4 --> KG
        A1 --> VS[向量存储<br/>长期记忆]
        A2 --> VS
    end

    subgraph "工具层"
        A1 -->|MCP| T1[搜索工具]
        A2 -->|MCP| T2[数据工具]
        A3 -->|MCP| T3[文档工具]
        A4 -->|MCP| T4[验证工具]
    end

    subgraph "可观测层"
        ORC --> TRACE[Trace/Monitor<br/>LangSmith/CloudWatch]
        A1 --> TRACE
        KG --> TRACE
    end

九、选型推荐

按场景选型

场景 推荐方案 理由
跨企业Agent互操作 Google ADK + A2A A2A是唯一跨框架开放协议
高合规企业内部 AWS Bedrock AgentCore 审计链+合规认证最完善
微软生态内部 Azure AI Agents + AutoGen 与M365/Copilot原生集成
复杂推理+知识密集 LangGraph + MemGraphRAG 图记忆解决知识断层
快速原型验证 OpenAI Agents SDK Handoff原语极简,上手最快
多域专家协作 Blackboard架构 + A2A 自主触发消除调度瓶颈
高准确率决策 仲裁协议(N=3辩论+1仲裁) ACL论文实证最高提升

按团队规模选型

团队规模 推荐方案 成本估算
1-3人创业团队 OpenAI Agents SDK + 简单投票 $50-100/月
5-15人技术团队 LangGraph + 宪法审查 $200-500/月
50+人企业团队 AWS AgentCore 或 Google ADK $1000-3000/月
跨组织协作 Google ADK + A2A + Blackboard $2000-5000/月

十、结论与趋势

2026年多Agent协作系统呈现三个清晰趋势:

趋势一:协议层标准化。A2A(Agent间)+ MCP(Agent-Tool间)构成的双协议栈正在成为事实标准。任何不兼容A2A的多Agent框架都将被边缘化。预计2026年底,A2A采纳率将达到70%以上的主流框架。

趋势二:记忆架构图化。从MemGraphRAG到Neo4j Shared Graph Memory,将Agent的共享状态建模为图结构而非扁平KV正在成为共识。这本质上就是黑板架构在LLM时代的新形态——黑板变成了知识图谱。

趋势三:编排自治化。从人工定义编排图到Agent自主协调。MagenticOne的Fact Bank和Bedrock的自动意图路由都是这个方向的早期实践。预计2027年,"零编排"多Agent系统将成为主流——开发者只需定义Agent的能力边界,编排逻辑由系统自动生成。

对于实践者而言,2026年的行动建议是:优先掌握A2A协议和Blackboard模式。前者是跨框架协作的基础设施,后者是复杂推理场景的最佳实践。两者结合,构成了下一代多Agent系统的核心架构范式。


参考来源

  1. The Orchestration of Multi-Agent Systems: Architectures, Protocols, and Challenges — arXiv综述论文,系统梳理多Agent编排架构与协议
  2. Blackboard Architecture: The Multi-Agent AI Pattern Making a Comeback — 黑板架构2026年复兴的完整技术指南
  3. Announcing the Agent2Agent Protocol (A2A) — Google官方A2A协议发布公告
  4. MemGraphRAG: Memory-based Multi-Agent System for Graph RAG — KDD 2026收录论文,三层共享图记忆架构
  5. Voting or Consensus? Decision-Making in Multi-Agent Debate — ACL 2025 Findings,七种决策协议系统评测
  6. Multi-Agent AI Orchestration Patterns: Production Guide — 四种生产级编排模式实战指南
  7. Google ADK 1.0 and A2A Protocol: Defining the 2026 Multi-Agent Standard — Google ADK+A2A深度分析

[!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 等场景全覆盖。

51学通信知识星球海报-扫码加入