【AI大模型】MCP 模型上下文协议：客户端-服务器架构、JSON-RPC 消息与能力协商、工具发现与调用链路、与函数调用的分工

say_fall2026-11-09 12:48

【AI大模型】MCP 模型上下文协议：客户端-服务器架构、JSON-RPC 消息与能力协商、工具发现与调用链路、与函数调用的分工


🌈 say-fall：个人主页 🚀 专栏：《手把手教你学会C++》 | 《系统深入Linux操作系统》 | 《数据结构与算法》 | 《小游戏与项目》 💪 格言：做好你自己，才能吸引更多人，与他们共赢，这才是最好的成长方式。

前言

我们把大模型怎么调、函数调用怎么写说得差不多了，接下来更躲不开的是模型外面那一堆数据和服务。这一篇就以MCP为例，把 AI 应用连接外部世界的原理从头捋一遍。

刚把函数调用弄明白，面对真实项目可能会有这些疑问：同一个查数据库的工具，换个 AI 客户端为什么就得重写一遍？模型明明只吐出一段 JSON，外部系统是怎么真的被改动的？

现象 你可能以为的原因 真正发生的事情
AI 助手能读到本地文件 模型自己有文件系统权限 有一个独立的服务器进程代它读，结果按约定格式回传
换个客户端还能用同一个工具 新客户端做了兼容适配 工具描述由服务器提供，客户端在运行时动态发现
工具列表会自己变多 应用升级时把工具写死进代码了 服务器发一条变更通知，客户端重新拉取清单
模型能改外部系统里的数据 模型直接调了外部 API 模型只产出调用意图，真正执行的是 MCP 服务器

问题来了： 客户端和服务器之间传的到底是什么样的消息？工具清单是怎么被发现的？一次调用从模型吐参数到外部系统返回结果，中间经过了谁？MCP 和函数调用，究竟谁管哪一段？

答案就是------统一的消息格式 + 固定的交互流程！MCP 把「AI 应用怎么用外部工具」拆成客户端和服务器两侧，两边靠 JSON-RPC 2.0 对话，工具的描述、发现、调用、回传全走同一份约定。而所谓工具调用，说到底还是一次客户端与服务器之间的请求和响应，只是中间多了一个会吐 JSON 的模型。

通过本文，你将掌握：

技能 应用场景
Host / Client / Server 三层角色 看懂一个 AI 应用是怎么同时接上多个外部服务的
数据层与传输层的分工 理解为什么换传输不用改业务逻辑
JSON-RPC 2.0 的三种消息 读懂真实报文，分清协议错误和工具执行错误
stdio 与 Streamable HTTP 选对本地和远端两种接法，避开 stdout 被日志污染的坑
生命周期与 capabilities 能力协商 明白「能做什么」是怎么在协议层被限制住的
Tools、Resources、Prompts 三类原语 区分让模型做的事、给模型看的数据、可复用的提示模板
一次工具调用的完整链路 把模型吐参数、客户端转发、服务器执行、结果回填串成一条线
MCP 与函数调用的分层关系 知道两者各自管哪一段，不再当成二选一

前置知识： 大模型 API 的基本调用、函数调用（工具使用）的概念、JSON 与 HTTP 常识、进程间通信的基本概念。

文章目录

正文：

一、MCP 是什么：先把「协议」两个字说清楚

MCP 全称 Model Context Protocol，模型上下文协议，是 Anthropic 在 2024 年末开放出来的一套标准。它要解决的问题很具体：AI 应用想接外部的数据、工具和服务，以前每接一个都得专门写一遍集成代码。

拿 USB-C 打比方是合适的，但得说清像在哪儿。USB-C 统一的是接口的形状、引脚和电气信号，插得上、供得了电、传得了数据；MCP 统一的是消息的语义和交互的流程：工具怎么描述自己、客户端怎么发现、调用怎么发、结果怎么回。一个管硬件怎么连，一个管软件怎么说话。

在没有这套约定之前，集成成本是一个乘法。假设有 M 个 AI 客户端、N 个外部系统，每个客户端各自去适配每个系统，就要写 M×N 份适配代码。有了统一协议之后，客户端实现一次协议，每个系统实现一次服务器，工作量变成 M+N。

对比 没有统一协议 有 MCP
集成代码量 M 个客户端 × N 个系统 M 个客户端 + N 个服务器
工具描述放在哪 写死在每个应用的请求代码里 由 MCP 服务器自己提供
换一个 AI 客户端 重新写一遍适配 配置里加一个服务器
新增一个工具 所有客户端跟着升级 服务器自己加，客户端运行时发现

这里要划一条线： MCP 只管上下文怎么在 AI 应用和外部能力之间交换，它不规定 AI 应用该选哪个模型、怎么组织提示词、拿到上下文之后怎么用。这些仍然归应用自己管。

二、整体架构：Host、Client、Server 各管什么

MCP 是客户端-服务器架构，但参与方有三个，别把 Host 和 Client 混成一个。

  • Host（宿主）：用户直接面对的那个 AI 应用，Claude Desktop、Cursor、VS Code 里的编码助手都算。它负责跟大模型对话、管权限、决定什么时候用哪个外部能力。
  • Client（客户端）：Host 内部的一个组件，一个 Client 专门对接一个 Server，维持一条独立连接，负责收发消息、处理错误、管会话。
  • Server（服务器）：一个独立的进程或服务，把文件、数据库、API、工作流包装成 MCP 规定的样子暴露出去。

Host 连几个 Server，就创建几个 Client，彼此是 1:1 的专用连接。这么设计是有原因的：每个 Server 的能力、鉴权、生命周期都不一样，绑在一条连接上会互相干扰。

text 复制代码 
用户 <--> Host（AI 应用，里面跑着大模型）
              |
              +-- Client A <-- 专用连接 --> Server A（本地文件系统，stdio）
              |
              +-- Client B <-- 专用连接 --> Server B（数据库，stdio）
              |
              +-- Client C <-- 专用连接 --> Server C（远端服务，HTTP）

协议自己还分了两层：

层 管什么 具体内容
数据层 消息「是什么意思」 JSON-RPC 2.0 消息格式、生命周期、能力协商、tools / resources / prompts 等原语
传输层 消息「怎么送到」 建连、分帧、鉴权、取消与断连

分层的好处是换传输不用改协议：同一份 JSON-RPC 报文，跑在本地进程的标准输入输出上，和跑在远端的 HTTP 上，内容完全一样。

三、协议的地基：JSON-RPC 2.0 与两种传输

三种消息

MCP 选了 JSON-RPC 2.0 作为消息格式，全部 UTF-8 编码。消息只有三种，把「请求-响应」和「单向通知」分得很干净。下面报文里的 // 是讲解用的注释，真实报文里不带。

请求：

json 复制代码 
// 客户端 -> 服务器，带 id，等一个对应的响应
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

响应：

json 复制代码 
// 服务器 -> 客户端，id 必须和请求一致，result 与 error 二选一
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": []
  }
}

通知：

json 复制代码 
// 单向消息，没有 id，收的一方不回包
{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

几个容易踩的点：

① 请求 id 不能是 null，同一个会话里也不能重复用还没收到响应的 id，靠它对上响应。

② 响应里 result 和 error 只能出现一个，错误码是整数，常见的 -32601 是方法不存在，-32602 是参数不对或者能力没声明。

③ 工具本身执行失败（比如查不到数据）不算协议错误，要在工具结果里用 isError: true 把错误文本带回去，让模型看得见、能自己决定下一步。

第 ③ 条值得多说一句：协议的错是「这句话没听懂」，工具的错是「事没办成」。把两者分开，模型才能对后者做出重试或者换参数的反应。

两种传输

传输 用在哪 怎么传 鉴权
stdio 本地，Server 是 Host 拉起的子进程 换行分隔的 JSON-RPC 走 stdin / stdout 靠进程隔离，凭据从环境变量拿
Streamable HTTP 远端，一个 Server 服务多个 Client 客户端 POST 到单个 MCP 端点，回 JSON 或按需开 SSE 流 Bearer Token、API Key，推荐 OAuth

stdio 是最容易理解也最容易写错的一种。Server 的 stdout 只能输出 JSON-RPC 报文，日志必须写到 stderr。在 Node 里顺手一个 console.log、Python 里一个 print()，都会混进 stdout 把报文流冲坏，客户端解析直接失败。这个坑几乎每个第一次写本地 Server 的人都会踩。

Streamable HTTP 是 2025 年那次修订引进来替代旧的 HTTP + SSE 的：客户端只用 POST 发消息，服务器可以直接回一个 JSON，也可以在需要推进度、流式结果时开一条 SSE。会话靠 Mcp-Session-Id 一类的头部标识，断连和取消都有对应约定。远程服务要走标准 HTTP 鉴权，规范里明确建议用 OAuth，而不是把上游凭据原样透传给服务器。

传输层对上层是透明的。写 Server 的人实现一遍 tools/list 的逻辑，本地跑 stdio 还是远端跑 HTTP，业务逻辑不用改一行。

四、一次连接怎么建立：生命周期与能力协商

MCP 是一条有状态的对话，正式干活之前得先对齐两件事：用哪个版本的协议、双方各自支持什么能力。

早期（也是目前实现里最常见）的做法是握手：

json 复制代码 
// 1. 客户端发起 initialize，声明版本、自己有的能力、自己是谁
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": { "sampling": {}, "roots": {} },
    "clientInfo": { "name": "my-client", "version": "1.0.0" }
  }
}
json 复制代码 
// 2. 服务器回应，带回自己支持的能力
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools":     { "listChanged": true },
      "resources": { "subscribe": true },
      "prompts":   {}
    },
    "serverInfo": { "name": "my-server", "version": "1.0.0" }
  }
}
json 复制代码 
// 3. 客户端发一条通知，表示「我准备好了」，这条不需要回应
{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

之后进入运行阶段，最后关掉传输。stdio 是结束子进程，HTTP 是删掉会话。

能力协商不是走个过场。capabilities 里没声明的东西，对方就不能用：服务器没声明 resources，客户端发 resources/read 就该收到方法不存在；客户端没声明 sampling，服务器反过来请求模型补全，会拿到 -32602。这就是最小权限在协议层的落地方式，能做什么明明白白写在握手里。

谁声明 能力 含义
服务器 tools 有可调用的工具，listChanged 表示列表变化时会发通知
服务器 resources 有可读的数据，subscribe 表示支持变更订阅
服务器 prompts 有可复用的提示模板
服务器 logging 会往客户端推日志
客户端 sampling 服务器可以借宿主的模型做一次补全
客户端 elicitation 服务器可以向用户追问补充信息
客户端 roots 客户端会告诉服务器可操作的文件系统边界

版本提示： 协议还在演进。2026 年的新版规范把「版本 + 客户端能力 + 客户端信息」从一次性握手挪到了每个请求的 _meta 字段里（形如 io.modelcontextprotocol/protocolVersion），服务器不再依赖先前的连接状态来判断对面会什么；服务器反向要模型补全、要用户输入这类动作，也被整理成多轮往返请求。分层的思路、JSON-RPC 消息格式、能力必须显式声明的规则都没变，只是握手从「建连时谈一次」变成「每条请求自带」。读老资料时看到 initialize，别以为是写错了。

五、服务端三类原语：工具、资源、提示

「原语」这个词听着唬人，其实就是协议预先定义好的几类能力，双方照着同一套方法名交互。服务器对外主要提供三类。

Tools：模型能调用的函数

工具是唯一一类由模型决定要不要调的能力，也是最容易和函数调用搞混的地方。服务器先用 tools/list 把清单交出来，每个工具带三样东西：名字、给模型看的描述、用 JSON Schema 写好的入参约束。

json 复制代码 
// tools/list 的响应片段
{
  "tools": [
    {
      "name": "query_weather",
      "description": "查询指定城市指定日期的天气，返回温度、天气状况和风力",
      "inputSchema": {
        "type": "object",
        "properties": {
          "city": { "type": "string", "description": "城市名，如 北京" },
          "date": { "type": "string", "description": "YYYY-MM-DD" }
        },
        "required": ["city", "date"]
      }
    }
  ]
}
json 复制代码 
// 客户端发起 tools/call
{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "query_weather",
    "arguments": { "city": "北京", "date": "2026-11-14" }
  }
}
json 复制代码 
// 服务器回传结果，content 是内容块数组，文本、图片都能装
{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "content": [ { "type": "text", "text": "北京 11-14：晴，3~12℃，西北风 3 级" } ],
    "isError": false
  }
}

描述和 inputSchema 是给模型看的，不是给人看的文档。写得含糊，模型就会选错工具或者编出参数；写得清楚，模型不用改一行代码就能用好新工具。工具列表变了，服务器发一条 notifications/tools/list_changed，客户端重新拉一次即可，不用重启应用。

Resources：能被读进上下文的数据

资源是只读的数据，用 URI 标识，比如 file:///project/README.md、db://orders/schema。方法主要就两个：resources/list 列清单，resources/read 按 URI 读内容；支持订阅的服务器还能在内容变化时推更新通知。

和 Tools 的区别要分清：

对比 Tools Resources
谁决定使用 模型在对话中自己判断 应用或用户主动挑，塞进上下文
有没有副作用 可以有，写文件、发消息都算 只读
典型内容 查询、创建、执行、控制 文件、表结构、日志、文档
对应方法 tools/list、tools/call resources/list、resources/read

把「给模型看的数据」和「让模型做的事」分开，权限就好管了：读某个文件可以默认放行，删某个文件必须弹窗让用户确认。

Prompts：可复用的提示模板

提示模板是服务器预先写好的一段交互骨架，客户端用 prompts/list 看有哪些、prompts/get 按参数取出来，常见形态就是应用里的斜杠命令。比如一个代码审查服务器提供 /review，用户填个文件路径，客户端取回拼装好的提示词再发给模型。它省的是「每个客户端都要重写一遍同样提示词」的功夫。

反过来借能力：Sampling、Roots、Elicitation

协议不是单向的。服务器干活干到一半，也可以向客户端要东西：

① sampling：服务器想让宿主的模型帮忙做一次补全（比如给抓下来的文本做个摘要），不必自己配 API Key，也不必自己选模型。客户端拿回请求后由用户把关，再把结果交回服务器。

② elicitation：参数不够时向用户追问一句，比如「要删的是这三个文件里的哪几个」。

③ roots：客户端告诉服务器「你只能碰这几个目录」，服务器据此收窄自己的操作范围。

这三条的共同点：最后拍板的都是宿主和用户，不是服务器。协议把人留在回路里，是有意留的。

六、一次工具调用的完整链路

用户问一句、模型答一句，中间其实跨了好几层。把每一步对应的方法和数据形态补上，链路是这样的。用户问「帮我查一下北京周六的天气」：

text 复制代码 
[1] 用户提问
     ↓
[2] Host 把问题 + 已发现的工具清单一起交给模型
     （工具清单来自各 Server 的 tools/list，被转成模型 API 的 tools 参数）
     ↓
[3] 模型输出一次工具调用意图：name=query_weather, arguments={city:"北京",date:"..."}
     ↓
[4] Host 找到对应的 Client，由它组装 tools/call 请求
     ↓
[5] Client --JSON-RPC--> Server（stdio 或 HTTP）
     ↓
[6] Server 校验参数、调用背后的真实 API、把结果包装成 content 回传
     ↓
[7] Client 把结果作为一条工具消息回填进对话上下文
     ↓
[8] 模型接着生成最终回答

几个关键点：

  • 服务器从不和大模型直接说话。 它眼里只有客户端发来的 JSON-RPC 请求。模型看到的是 Host 转换过的工具描述，不是服务器进程。
  • 决策权在模型，执行权在服务器。 模型只负责说「我想调这个名字、这些参数」，参数对不对由服务器校验，动作由服务器执行。
  • 第 7 步是上下文真正变多的地方。 工具结果不替换用户问题，而是作为新消息追加进对话，模型基于「问题 + 工具结果」再回答一次。这也是为什么协议叫「模型上下文协议」，它扩的是上下文，不是模型的权重。

再拿旅行规划套一遍就直白了。用户说「帮我规划一个北京周末两日游」：

① 客户端连上天气、景点、地图三个 Server，各自 tools/list 拿到清单。

② 模型判断先要天气，Host 发 tools/call 给天气 Server，拿到结果回填。

③ 模型继续要景点推荐，再要路线计算，每一轮都是「意图 → tools/call → 回填 → 再生成」。

④ 三次结果都进上下文之后，模型一次写出带天气、景点、交通和餐饮的完整行程。

用户只看见一段回答，背后是三轮请求-响应和一份不断变长的上下文。这个过程对用户是透明的，协调多个外部服务的活全在协议这一层。

七、MCP 与函数调用：不是二选一，是两层

一个常见疑问是：MCP 和 OpenAI 的函数调用、Anthropic 的工具使用有什么区别。它们不在同一个技术层次上，谈不上竞争。

维度 函数调用 / 工具使用 MCP 模型上下文协议
本质 模型 API 的一项功能，是「动词」 一套集成协议，是「管道」
关心的事 模型怎么表达「我要调工具」 工具怎么被描述、发现、连接和执行
工具定义 每次 API 请求里由应用代码写死 由独立的 MCP 服务器提供，可复用
工具发现 应用硬编码，加工具要重新部署 客户端运行时动态发现
执行位置 在你的应用代码里 在 MCP 服务器进程里
复用范围 服务于当前这一个应用 同一个 Server 能被多种 AI 客户端接
典型场景 单应用，工具和业务逻辑紧耦合 把工具做成能被多家客户端用的服务

把两者拼起来看最清楚。Host 里干的事拆开是四步：拉工具清单、连问题一起交给模型、把调用意图转成 MCP 请求、结果回填后再生成一次。大致是这么一段逻辑：

python 复制代码 
tools = []
for client in clients:
    tools += client.request("tools/list")["tools"]      # 拉工具清单

resp = llm.chat(messages=messages, tools=tools)         # 连问题带工具一起交给模型

if resp.tool_call:
    result = find_client(resp.tool_call.name).request(  # 意图转成 MCP 请求
        "tools/call",
        {"name": resp.tool_call.name, "arguments": resp.tool_call.arguments}
    )
    messages.append(tool_result_message(result))        # 结果回填上下文
    answer = llm.chat(messages=messages, tools=tools)   # 再生成最终回答

第 2、3 步用的是函数调用，第 1、3、4 步里和 Server 打交道用的是 MCP。函数调用负责「在具体这轮对话里怎么把意图说出来」，MCP 负责「这些工具从哪来、谁去执行、结果按什么格式回来」。少了前者，模型没法表达调用；少了后者，每个应用都得自己把工具实现一遍。

说白了： 函数调用是模型侧的表达能力，MCP 是工具侧的分发与连接约定，一次回答里两者常常同时在场。

八、为什么需要它：三个痛点

回到工程上，MCP 对准的是三件很具体的事。

开发效率低。 以前让 AI 接一个 Notion 或 GitHub，针对每个 AI 平台都要写一套集成代码，认证、数据格式、错误重试各写各的。标准化之后，接一个新系统等于写一个 Server 或者配一个现成的 Server，工作量从「每个客户端一遍」变成「一次」。

能力孤岛。 每个 AI 应用都维护自己的工具列表，Claude 里能用的工具，换个客户端就用不上。Server 把工具统一暴露出来之后，工具不再属于某个应用，一次构建，处处可用。

体验割裂。 用户在不同 AI 应用之间切换，能访问的外部服务、要重新授权的方式都不一样。协议统一之后，日历、数据库、设计工具在各个兼容客户端里是一套接法。

说到底，就是把原本散落在每个 Host 里的集成代码，搬到一个个独立的 Server 进程里，再用一份公开约定把它们接回来。

九、应用场景：AI 从「只会说」到「能动手」

  • 个人助理：助手读日历和笔记，按你的日程排会议、提醒待办。这里用的是 Resources 读数据 + Tools 写日程。
  • 开发助手：在 Cursor、VS Code 里读项目文件、查文档、跑测试，生成代码时拿到的上下文不再靠人手动贴。本地文件这类能力最适合 stdio，进程就在本机，凭据也不出门。
  • 企业数据分析 ：内部聊天机器人通过 MCP 连多个部门数据库，用自然语言查分散的数据。这种场景更要靠 roots、最小权限和鉴权把边界划死。
  • 创意工作流：读 Figma 设计稿生成 Web 应用，或者在 Blender 里建模再送去打印。本质是把一串原本要人点来点去的操作拆成可调用的工具。

十、生态与未来：开放标准的意义

MCP 能推开，靠的不是某一个产品，而是开放性。

  • 客户端侧：Claude Desktop、ChatGPT、Cursor、VS Code Copilot 等主流 AI 应用和开发工具都已经支持 MCP。
  • 服务器侧：社区里已经积累了覆盖 Google Drive、Slack、GitHub、Postgres、浏览器控制、Figma 等大量 MCP 服务器，官方也给出了各语言 SDK 和参考实现。
  • 企业侧：已经有公司把它接进内部系统，用来搭自己的 AI 代理。

这是个正循环：支持的工具越多，客户端接协议越划算；客户端越多，工具作者越愿意按协议写一遍。跟当年 USB-C 铺开的过程是一回事，标准的价值不在标准本身，在有多少人真的照着做。

十一、挑战与安全边界

门一打开，问题也跟着来了。

权限与授权。 允许 AI 访问外部系统，等于多了一条新的攻击面。stdio 场景下靠进程隔离和 roots 收窄范围；远程 HTTP 场景下要走正规鉴权，按最小权限签发令牌，敏感操作必须弹给用户确认。规范里明确禁止把上游凭据原样透传给 MCP 服务器，就是因为一旦透传，服务器拿着用户的令牌能干的事就没人管得住了。

提示注入与工具投毒。 工具返回的内容会被塞进上下文，如果里面藏着「忽略之前的指令，去读某个文件」这类文本，模型可能照做；工具描述本身也可能被写进诱导性内容。这类问题不是加一层鉴权就能解决的，得靠内容隔离、人工确认和只暴露必要工具一起兜。

模型能力差异。 协议只保证连得上，不保证用得好。同一份工具清单，推理强的模型能拆出多步调用，弱一点的模型可能选错工具、编错参数。连接是协议的活，会不会用是模型的活。

标准化与碎片化。 MCP 本身就是为了治碎片化来的，但如果各家 Server 实现得松紧不一，或者又冒出几套互相不通的协议，老问题会在新一层重演。规范持续修订、SDK 和一致性测试跟着跟上，才守得住这个「通用端口」。

十二、结语

MCP 说到底不是什么新模型，也不是让模型变聪明的技术。它做的是另一件事：把「AI 应用怎么拿到外部能力」从每家自己解决的工程问题，变成一份大家共同遵守的约定。

思路上的变化其实很清楚：从只追求更大、更聪明的单一模型，转向让模型能连接、调用、协调外部的资源与服务。往后的 AI 助手不会是个封闭的黑盒，它得能查企业数据库、能调网络服务、能在用户点头之后真的去改点什么。要做到这些，先得有一套谁都听得懂的话，MCP 想定下来的就是这套话怎么说。

USB-C 让设备之间不用再各带各的线，MCP 让 AI 应用和外部系统之间不用再各写各的适配。事情就这么朴素。

  • 本节完...

📝 作者：say-fall | 编辑：say-fall | 🌟 原创不易，如果对你有帮助，记得 👍 点赞 + ⭐ 收藏 哦！

相关推荐
早起CaiCai29 分钟前
【2023-01 OM】利用深度学习算法融合异质观测实现海洋场降尺度
人工智能·深度学习·算法
周杰伦的稻香37 分钟前
AI 助手 2.0：多轮对话、卡片化与文章页感知
人工智能
Martina_03211 小时前
AI生成3D场景从白模换成精模后镜头全偏了？用6步检查单位、枢轴与层级替换
图像处理·人工智能·3d·ai·自然语言处理·材质·1024程序员节
狒狒AI1 小时前
手绘白板动画的生产线拆解：AI 出图、笔迹对齐、镜头渲染七道工序（附 21 个开源脚本）
人工智能·aigc
用户2763965765101 小时前
上手 GitHub 官方 Spec Kit：AI 编码别再裸奔，先写 spec 再出码，SDD规约开发
人工智能
Lucas_coding1 小时前
【Agent】Agent 知识地图：核心概念、工程方法与产品生态
人工智能
方方洛1 小时前
ray教程-28-附录G-CICD与Slurm与云上调度
人工智能·分布式·机器学习
Decay__1 小时前
14_MySQL 高可用与容灾架构 —— MGR / InnoDB Cluster / Keepalived+VIP / 双主 / 读写分离 / 两地三中心
运维·数据库·sql·mysql·架构
猿人谷1 小时前
Surrogate Model：让进化算法学会“预测”，为什么它正在成为智能优化的重要技术？
后端·算法·架构
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03历年考研数学一、数学二、数学三真题试卷及答案PDF04几个好用的ip纯净度检测网站05GitHub 镜像站点06苹果iPA游戏软件资源下载网站07微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新08蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接09昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战10Dify：一站式AI应用开发平台全解析与Windows部署指南