省流总结：

LLM之所以能“知道”应调用哪个MCP服务及其参数，并不是源自模型本身具备实时解析接口的能力，而是依赖于智能体框架在运行时自动收集、整理所有可用服务的描述和参数定义（schema）。

这些结构化信息通过特定的Prompt或函数调用协议作为上下文注入LLM。LLM基于用户输入和这些服务信息推理出是否需要发起服务调用，并以标准化格式（如JSON）输出调用指令和参数。

框架再解析LLM输出并完成实际调用，并将结果返回给大模型进行后续处理。

面试中问到 TCP 相关知识时一般会问到三次握手和四次挥手，内容大家一定回答过很多次并熟记于心了。传统的 TCP 建立连接时需要三次握手，并且握手时只发送简单的 SYN 和 ACK 报文（部分优化的网络协议栈可以在第三次握手时直接发送数据）。

从网络带宽的资源利用的角度来看，传输层的 TCP 头部 + 网络层的 IP 头部，最少有 40 个字节，为了发送几个字节的报文数据包，而额外组装了 40 个字节的头部，着实有点浪费资源。

从应用优化的角度来看，因为要等到 TCP 经过三次握手建立连接之后才能发送应用层数据，所以会造成应用程序首次发送数据时存在一定的延迟，尤其是短连接、移动设备等场景中，这种副作用会加剧。

为解决上述问题，TCP Fast Open 应运而生。