人工智能LLM 网关API网关后端【免费下载链接】bifrostFastest enterprise AI gateway (50x faster than LiteLLM) with adaptive load balancer, cluster mode, guardrails, 1000 models support 100 µs overhead at 5k RPS.项目地址https://gitcode.com/gh_mirrors/bifrost31/bifrost点击查看免费下载导读Bifrost 的插件体系并非单一面板——一个插件可以通过实现多个接口在 HTTP 传输层、LLM 调用层、MCP 工具层以及 Trace 可观测层同时挂载钩子构建端到端的可观测性与统一治理能力。本文以仓库中的multi-interface示例插件为骨架源码见 examples/plugins/multi-interface/main.go完整讲解四大插件接口的实现方式、跨层上下文数据流、构建与配置方法以及底层 Hook 执行顺序帮助你从零写出一个一次请求全程追踪的全栈插件。一、插件接口全景一个插件能同时做什么Bifrost 的插件以 Go 原生共享库.so-buildmodeplugin或 WASM 形式加载插件通过实现预定义接口参与请求处理管线。接口定义集中在 core/schemas/plugin.go其中BasePlugin是所有插件的最小契约GetName() string返回系统级唯一标识插件注册与识别依赖它Cleanup() errorBifrost 关闭时回调用于释放资源文件句柄、连接池、定时器等。在BasePlugin之上multi-interface示例一次性实现了全部四个扩展接口接口定义位置插件角色示例中的能力HTTPTransportPlugincore/schemas/plugin.go 中的HTTPTransportPlugin在 HTTP 传输层拦截进出请求统计请求数、追加请求序号响应头、计算 HTTP 耗时、把 HTTP 元数据写入 ContextLLMPlugin同上LLMPlugin在 LLM 提供商调用前后介入读取 HTTP 层元数据、注入动态 system prompt、统计 LLM 耗时、记录请求/响应明细MCPPlugin同上MCPPlugin在 MCP 工具/资源调用前后介入读取 HTTP 层元数据、记录所有 MCP 调用、统计 MCP 耗时、实现 MCP 治理ObservabilityPlugin同上ObservabilityPlugin异步接收完整 Trace将 Trace 序列化为 JSON为接入 OTEL、Datadog、Jaeger 等后端预留出口从源码结构看multi-interface的定位就是插件开发者的最小全栈模板它不侧重某个单点功能而是演示同一份请求如何在四个层次间流转并被同一份状态请求计数、启动时间贯穿。仓库中还提供了单一接口的精简对照示例便于逐层理解hello-world、http-transport-only、llm-only、mcp-only。二、Context Flow跨层元数据如何流动示例插件最核心的设计是用BifrostContext在 Hook 之间传递元数据形成一条从 HTTP 入口到 LLM/MCP 再到 HTTP 出口的完整数据链HTTPTransportPreHookHTTP 层入口→ 把请求到达时间、请求路径写入 ContextPreLLMHook / PreMCPHook提供商调用前→ 从 Context 读回 HTTP 元数据写入各自的起始时间PostLLMHook / PostMCPHook提供商调用后→ 从 Context 读回起始时间计算耗时并回写HTTPTransportPostHookHTTP 层出口→ 把耗时与接口清单写入响应头Inject异步→ 收到完整 Trace整体导出。对应的源码实现位于 examples/plugins/multi-interface/main.go// HTTP 层记录请求到达时刻与路径 ctx.SetValue(schemas.BifrostContextKey(multi-http-request-time), time.Now()) ctx.SetValue(schemas.BifrostContextKey(multi-http-path), req.Path)// LLM 层读取 HTTP 路径记录 LLM 起始时刻 httpPath : ctx.Value(schemas.BifrostContextKey(multi-http-path)) ctx.SetValue(schemas.BifrostContextKey(multi-llm-start-time), time.Now())// HTTP 出口读取起始时间换算耗时写入响应头 if startTime, ok : ctx.Value(schemas.BifrostContextKey(multi-http-request-time)).(time.Time); ok { duration : time.Since(startTime) resp.Headers[fmt.Sprintf(%s-Duration-Ms, pluginConfig.CustomHeaderPrefix)] fmt.Sprintf(%d, duration.Milliseconds()) }BifrostContext的SetValue/Value方法在 core/schemas/context.go 中定义支持跨 Hook 阶段读写任意键值源码中还内置了如BifrostContextKeyResolvedAlias、BifrostContextKeyCacheMetadata等预定义键见 core/schemas/cachemetadata.go。注意读取时使用类型断言.(time.Time)因为 Context 值是以any存储的断言失败时插件应优雅降级而非 panic。三、构建生成插件共享库示例仓库自带 Makefile构建命令为make build执行后会在build/目录生成build/multi-interface.so。Makefile 中的核心步骤等价于go build -buildmodeplugin -o build/multi-interface.so main.go-buildmodeplugin是 Go 编译为动态插件的前提。需要留意的两点Go 版本一致性go.mod 声明了go 1.27.0并以replace指令将github.com/maximhq/bifrost/core指向本地../../../core。实际加载插件时宿主与插件的 Go 运行时版本不匹配会导致加载失败因此务必使用与 Bifrost 构建环境一致的 Go 工具链。平台限制-buildmodeplugin目前不支持 Windows 及部分交叉编译场景在目标 Linux 环境上编译后再部署是最稳妥的方式。清理产物使用make clean仅删除build/目录。四、配置接入 Bifrost 主配置构建出.so后把它注册进 Bifrost 的plugins配置段。以下为文档给出的完整配置{ plugins: [ { path: /path/to/multi-interface.so, name: multi-interface, display_name: Full-Stack Observability, enabled: true, type: auto, config: { enable_http_hooks: true, enable_llm_hooks: true, enable_mcp_hooks: true, enable_observability: true, enable_logging: true, track_requests: true, inject_uptime: true, custom_header_prefix: X-Multi-Plugin } } ] }两条命名规则值得特别注意name是系统标识符必须与插件GetName()的返回值一致本例为multi-interface用户不可修改display_name仅用于UI 展示用户可自由编辑。插件加载与启用状态由 core/schemas/plugin.go 中的PluginConfig结构驱动enabled、path、config、placement、order等字段其中placement可控制自定义插件相对内置插件的执行位置pre_builtin/post_builtin默认post_builtinorder控制同一分组内的先后次序。对于实现了ObservabilityPlugin的插件还可通过semaphore_size并发上限默认 10000与inject_timeout单次 Inject 超时默认 5s约束异步 Trace 注入的资源占用。配置选项明细插件在Init(config any)中解析config映射见 examples/plugins/multi-interface/main.go 的Init函数各开关含义如下OptionTypeDefaultDescriptionenable_http_hooksbooleantrueEnable HTTP transport layer hooksenable_llm_hooksbooleantrueEnable LLM request/response hooksenable_mcp_hooksbooleantrueEnable MCP request/response hooksenable_observabilitybooleantrueEnable observability/trace injectionenable_loggingbooleantrueEnable detailed loggingtrack_requestsbooleantrueTrack and count requestsinject_uptimebooleantrueInject server uptime in LLM system messagescustom_header_prefixstringX-Multi-PluginCustom prefix for HTTP response headersInit中的解析逻辑examples/plugins/multi-interface/main.go逐一从map[string]interface{}提取上述字段并回写到包级变量pluginConfig——这是插件默认值 配置覆盖的惯用模式先给结构体赋默认值再按配置逐项覆盖最后打印生效后的配置摘要。按场景裁剪的示例配置LLM-only 模式只挂 LLM 钩子最小化其余开销{ config: { enable_http_hooks: false, enable_llm_hooks: true, enable_mcp_hooks: false, enable_observability: false } }可观测性优先全钩子开启关闭冗长日志{ config: { enable_http_hooks: true, enable_llm_hooks: true, enable_mcp_hooks: true, enable_observability: true, enable_logging: false, track_requests: true } }最小开销保留钩子但关闭副作用{ config: { enable_logging: false, track_requests: false, inject_uptime: false } }自定义响应头前缀{ config: { custom_header_prefix: X-Custom-Plugin } }注意enable_http_hooks、enable_llm_hooks、enable_mcp_hooks等开关在插件源码中通过提前返回实现if !pluginConfig.EnableHTTPHooks { return nil, nil }关闭后对应 Hook 变为 no-op但函数签名与生命周期依然完整——这正是按需启用接口子集的推荐做法。五、Hook 执行顺序一次请求的完整生命周期multi-interface文档给出了两种典型请求的时序结合 core/schemas/plugin.go 中接口的文档注释可以更精确地理解典型 LLM 请求HTTPTransportPreHookHTTP 层入口鉴权之后、进入 Bifrost core 之前PreRequestHook每请求一次的路由决策阶段本示例未做路由直接返回 nilPreLLMHookLLM 提供商调用之前LLM Provider Call实际的上游模型调用PostLLMHookLLM 提供商返回之后HTTPTransportPostHookHTTP 层出口响应写回客户端前Inject响应已写出后的异步Trace 投递典型 MCP 请求HTTPTransportPreHookHTTP 层入口PreMCPHookMCP 服务器调用之前MCP Server Call实际工具/资源调用PostMCPHookMCP 服务器返回之后HTTPTransportPostHookHTTP 层出口Inject异步 Trace 投递接口文档中定义的执行细节每请求 vs 每尝试HTTPTransportPreHook、PreRequestHook、HTTPTransportPostHook每个顶层请求只执行一次而PreLLMHook/PostLLMHook在每次 fallback 尝试时都会执行主提供商调用 每次回退。如果需要对所有 fallback 可见的变更应放在PreRequestHook中。对称性保证管线保证每个执行过的PreLLMHook都会有对应的PostLLMHook以逆序回调插件作者应同时容忍 resp 与 err 为 nil 的情况PostLLMHook总会同时收到当前 response 与 error。Short-circuitPreLLMHook若返回LLMPluginShortCircuit可跳过提供商调用此时已执行过 Pre 钩子的插件仍会按逆序收到 Post 回调。流式响应HTTPTransportPostHook对流式响应不触发流式场景应实现HTTPTransportStreamChunkHook逐 chunk 逆序回调。错误语义插件错误不会被透传给调用方而是由 Bifrost 实例记录为警告PreRequestHook返回错误也不阻断请求仅记录日志。六、源码级拆解四个接口的实现要点下面逐接口梳理 examples/plugins/multi-interface/main.go 的实现细节方便你对照接口定义core/schemas/plugin.go理解每个签名。6.1 HTTPTransportPlugin请求计数与耗时头HTTPTransportPreHook(ctx, req)在请求进入 core 前执行关闭时直接返回(nil, nil)表示不拦截、继续开启track_requests时全局计数requestCount并向请求头写入prefix-Request-Number将请求时刻与路径写入 Context供后续 Hook 消费。HTTPTransportPostHook(ctx, req, resp)在响应出口执行从 Context 读回起始时间计算duration.Milliseconds()写入prefix-Duration-Ms响应头依据各开关组装当前启用的接口列表写入prefix-Interfaces响应头让下游系统一眼看出该请求经过了哪些插件层。这两个钩子接收的HTTPRequest/HTTPResponse是可序列化类型定义在 core/schemas/plugin.go含 Method、Path、Headers、Query、Body、PathParams 等字段并配套AcquireHTTPRequest/ReleaseHTTPRequest池化接口因此该接口同时兼容原生.so插件与 WASM 插件。另外接口还定义了HTTPTransportPreAuthHook鉴权中间件之前执行可为鉴权提供凭据——插件若无此需求返回(nil, nil)即可。6.2 LLMPlugin动态 system prompt 与耗时统计PreRequestHook(ctx, req)是路由决策阶段本示例不参与路由直接return nil。PreLLMHook(ctx, req)在每次提供商调用前执行读取 HTTP 层写入的multi-http-path关联出这次 LLM 调用来自哪个 HTTP 路径写入multi-llm-start-time当inject_uptime开启时构造一条 system 消息schemas.ChatMessage{Role: system, ...}内容包含请求序号与服务器运行时长并前置插入req.ChatRequest.Input切片头部——这是请求改写类插件的标准手法。PostLLMHook(ctx, resp, bifrostErr)在提供商返回后执行从 Context 读回起始时间计算 LLM 耗时写入multi-llm-duration供可观测层使用原样透传resp与bifrostErr。6.3 MCPPluginMCP 调用治理与计时PreMCPHook(ctx, req)在 MCP 工具/资源调用前执行写入multi-mcp-start-time与multi-mcp-type请求类型当req.ChatAssistantMessageToolCall.Function.Name存在时打印被调用的工具名演示治理即记录。PostMCPHook(ctx, resp, bifrostErr)在调用完成后计算并回写multi-mcp-duration。从 core/schemas/plugin.go 的接口定义可见MCP 层还提供可选的MCPConnectionPlugin扩展接口PreMCPConnectionHook/PostMCPConnectionHook仅处理 Connect 事件且实现该接口时通用 Pre/PostMCPHook 不会收到 Connect 请求只关心连接事件而不想实现通用钩子的插件可内嵌MCPPluginNoOpHooks获得免费的 no-op 实现。6.4 ObservabilityPlugin异步 Trace 投递Inject(ctx, trace)是唯一一个与请求主路径解耦的钩子异步触发响应写回客户端之后才调用不给客户端响应增加延迟接口注释明确说明若实现网络 I/O应将ctx传播给后端客户端以便inject_timeout超时后真正解除阻塞序列化导出示例用json.MarshalIndent(trace, , )将schemas.Trace输出为 JSON并注释出sendToDatadog(traceJSON)、sendToOTEL(trace)两个生产接入点生命周期约束Inject返回后调用方会立即把*Trace释放回sync.Pool插件禁止在返回后继续持有 Trace 指针需要异步转发的必须在返回前拷贝所需数据。Trace结构定义于 core/schemas/trace.go包含RequestID、TraceID继承自 W3C traceparent、RootSpan、Spans、Attributes、PluginLogs等字段并提供AddSpan、SetAttribute、SnapshotForExport等方法Trace层面的属性如x-bf-session-id、bifrost.dimensions不会作为 span 属性导出而是供 BigQuery、Datadog 等连接器直接读取。插件还可选择性实现OverheadSpanConsumer接收内部开销拆解 span与RawPayloadConsumer接收原始 provider 报文不实现则默认不接收。七、典型应用场景与扩展建议文档归纳了该插件的五类典型用途结合源码可以进一步落地为具体方案全栈可观测性Full-stack observabilitymulti-http-request-time→multi-llm-duration/multi-mcp-duration→Inject的 JSON Trace覆盖HTTP 进 → LLM/MCP 处理 → HTTP 出全链路接入真实后端时把Inject中的日志输出替换为 OTEL SDK / Datadog / Jaeger 客户端即可。统一治理Unified governance在 HTTP 层做鉴权/限流在 LLM 层改写请求或拦截输出在 MCP 层记录并约束工具调用同一份 Context 让各层策略共享决策信息。性能监控Performance monitoring三处耗时HTTP、LLM、MCP写入响应头可用于对外暴露延迟指标track_requests的计数在Cleanup时汇总打印processed N requests over uptime适合做进程级统计。审计留痕Audit trailsenable_logging开启时每个 Hook 阶段都会输出日志配合Inject的完整 Trace JSON 可重建任意请求的完整处理轨迹。自定义分析Custom analyticsHTTP 路径与 LLM/MCP 调用详情在同一 Context 中关联天然支持按路由统计模型调用成本/延迟类分析。作为模板使用时建议以本示例为骨架将Inject内的注释替换为真实后端适配器、为各钩子补充业务策略并根据需要实现OverheadSpanConsumer/RawPayloadConsumer等可选接口若只想实现单一接口可对照 http-transport-only、llm-only、mcp-only 三个精简示例缩减代码量。八、使用注意事项跨请求状态示例用包级变量requestCount、startTime跨请求计数与计时这在进程内是可行的但注意 Bifrost 插件以共享库形式在宿主进程内加载并发请求下需要自行保证计数操作的线程安全示例中的递增在真实高并发下建议改用原子操作。Context 生命周期元数据通过BifrostContext在单请求内流转各 Hook 阶段写入的键值仅对当前请求有效跨请求共享的数据应走包级状态而非 Context。Inject是异步的它发生在响应写出之后不能在Inject中依赖仍在进行的请求数据需要完整 Trace 时应在其内部完成格式化与转发且不得在返回后保留*Trace。流式响应HTTPTransportPostHook对流式场景不触发若插件需要逐 chunk 处理如修改增量内容、埋点统计应实现HTTPTransportStreamChunkHook。版本与工具链插件.so与宿主的 Go 版本、平台必须一致构建前确认 go.mod 中replace指向的core路径有效并始终在目标 Linux 环境上执行make build。赞分享人工智能LLM 网关API网关后端【免费下载链接】bifrostFastest enterprise AI gateway (50x faster than LiteLLM) with adaptive load balancer, cluster mode, guardrails, 1000 models support 100 µs overhead at 5k RPS.项目地址https://gitcode.com/gh_mirrors/bifrost31/bifrost点击查看免费下载相关推荐抖音批量下载工具指南三步跑通主页作品无水印采集抖音批量下载工具指南三步跑通主页作品无水印采集 想把一个抖音主页的作品全部存到本地、去掉水印、重跑时只取新发布的这正是 douyin downloader人工智能LLM 网关API网关后端一个内核四种入口agent-memory的SDK、HTTP、CLI、MCP多形态接入实战一个内核四种入口agent memory的SDK、HTTP、CLI、MCP多形态接入实战 openJiuwen 的 agent memory Jiuwen人工智能AI AgentAgent 记忆RAGMCP 服务Pinpoint 接入 Google HTTP Client 插件同步/异步调用链路追踪配置与原理详解Pinpoint 接入 Google HTTP Client 插件同步/异步调用链路追踪配置与原理详解 Pinpoint 是面向大规模分布式系统的 APMA后端可观测性APM链路追踪微服务上一篇突破桌面应用图标壁垒Nativefier全平台格式转换实战指南下一篇微信读书助手wereader打造你的专属数字书房管理方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Bifrost 多接口插件实战：一个插件同时接入 HTTP、LLM、MCP 与 Observability 全链路
人工智能LLM 网关API网关后端【免费下载链接】bifrostFastest enterprise AI gateway (50x faster than LiteLLM) with adaptive load balancer, cluster mode, guardrails, 1000 models support 100 µs overhead at 5k RPS.项目地址https://gitcode.com/gh_mirrors/bifrost31/bifrost点击查看免费下载导读Bifrost 的插件体系并非单一面板——一个插件可以通过实现多个接口在 HTTP 传输层、LLM 调用层、MCP 工具层以及 Trace 可观测层同时挂载钩子构建端到端的可观测性与统一治理能力。本文以仓库中的multi-interface示例插件为骨架源码见 examples/plugins/multi-interface/main.go完整讲解四大插件接口的实现方式、跨层上下文数据流、构建与配置方法以及底层 Hook 执行顺序帮助你从零写出一个一次请求全程追踪的全栈插件。一、插件接口全景一个插件能同时做什么Bifrost 的插件以 Go 原生共享库.so-buildmodeplugin或 WASM 形式加载插件通过实现预定义接口参与请求处理管线。接口定义集中在 core/schemas/plugin.go其中BasePlugin是所有插件的最小契约GetName() string返回系统级唯一标识插件注册与识别依赖它Cleanup() errorBifrost 关闭时回调用于释放资源文件句柄、连接池、定时器等。在BasePlugin之上multi-interface示例一次性实现了全部四个扩展接口接口定义位置插件角色示例中的能力HTTPTransportPlugincore/schemas/plugin.go 中的HTTPTransportPlugin在 HTTP 传输层拦截进出请求统计请求数、追加请求序号响应头、计算 HTTP 耗时、把 HTTP 元数据写入 ContextLLMPlugin同上LLMPlugin在 LLM 提供商调用前后介入读取 HTTP 层元数据、注入动态 system prompt、统计 LLM 耗时、记录请求/响应明细MCPPlugin同上MCPPlugin在 MCP 工具/资源调用前后介入读取 HTTP 层元数据、记录所有 MCP 调用、统计 MCP 耗时、实现 MCP 治理ObservabilityPlugin同上ObservabilityPlugin异步接收完整 Trace将 Trace 序列化为 JSON为接入 OTEL、Datadog、Jaeger 等后端预留出口从源码结构看multi-interface的定位就是插件开发者的最小全栈模板它不侧重某个单点功能而是演示同一份请求如何在四个层次间流转并被同一份状态请求计数、启动时间贯穿。仓库中还提供了单一接口的精简对照示例便于逐层理解hello-world、http-transport-only、llm-only、mcp-only。二、Context Flow跨层元数据如何流动示例插件最核心的设计是用BifrostContext在 Hook 之间传递元数据形成一条从 HTTP 入口到 LLM/MCP 再到 HTTP 出口的完整数据链HTTPTransportPreHookHTTP 层入口→ 把请求到达时间、请求路径写入 ContextPreLLMHook / PreMCPHook提供商调用前→ 从 Context 读回 HTTP 元数据写入各自的起始时间PostLLMHook / PostMCPHook提供商调用后→ 从 Context 读回起始时间计算耗时并回写HTTPTransportPostHookHTTP 层出口→ 把耗时与接口清单写入响应头Inject异步→ 收到完整 Trace整体导出。对应的源码实现位于 examples/plugins/multi-interface/main.go// HTTP 层记录请求到达时刻与路径 ctx.SetValue(schemas.BifrostContextKey(multi-http-request-time), time.Now()) ctx.SetValue(schemas.BifrostContextKey(multi-http-path), req.Path)// LLM 层读取 HTTP 路径记录 LLM 起始时刻 httpPath : ctx.Value(schemas.BifrostContextKey(multi-http-path)) ctx.SetValue(schemas.BifrostContextKey(multi-llm-start-time), time.Now())// HTTP 出口读取起始时间换算耗时写入响应头 if startTime, ok : ctx.Value(schemas.BifrostContextKey(multi-http-request-time)).(time.Time); ok { duration : time.Since(startTime) resp.Headers[fmt.Sprintf(%s-Duration-Ms, pluginConfig.CustomHeaderPrefix)] fmt.Sprintf(%d, duration.Milliseconds()) }BifrostContext的SetValue/Value方法在 core/schemas/context.go 中定义支持跨 Hook 阶段读写任意键值源码中还内置了如BifrostContextKeyResolvedAlias、BifrostContextKeyCacheMetadata等预定义键见 core/schemas/cachemetadata.go。注意读取时使用类型断言.(time.Time)因为 Context 值是以any存储的断言失败时插件应优雅降级而非 panic。三、构建生成插件共享库示例仓库自带 Makefile构建命令为make build执行后会在build/目录生成build/multi-interface.so。Makefile 中的核心步骤等价于go build -buildmodeplugin -o build/multi-interface.so main.go-buildmodeplugin是 Go 编译为动态插件的前提。需要留意的两点Go 版本一致性go.mod 声明了go 1.27.0并以replace指令将github.com/maximhq/bifrost/core指向本地../../../core。实际加载插件时宿主与插件的 Go 运行时版本不匹配会导致加载失败因此务必使用与 Bifrost 构建环境一致的 Go 工具链。平台限制-buildmodeplugin目前不支持 Windows 及部分交叉编译场景在目标 Linux 环境上编译后再部署是最稳妥的方式。清理产物使用make clean仅删除build/目录。四、配置接入 Bifrost 主配置构建出.so后把它注册进 Bifrost 的plugins配置段。以下为文档给出的完整配置{ plugins: [ { path: /path/to/multi-interface.so, name: multi-interface, display_name: Full-Stack Observability, enabled: true, type: auto, config: { enable_http_hooks: true, enable_llm_hooks: true, enable_mcp_hooks: true, enable_observability: true, enable_logging: true, track_requests: true, inject_uptime: true, custom_header_prefix: X-Multi-Plugin } } ] }两条命名规则值得特别注意name是系统标识符必须与插件GetName()的返回值一致本例为multi-interface用户不可修改display_name仅用于UI 展示用户可自由编辑。插件加载与启用状态由 core/schemas/plugin.go 中的PluginConfig结构驱动enabled、path、config、placement、order等字段其中placement可控制自定义插件相对内置插件的执行位置pre_builtin/post_builtin默认post_builtinorder控制同一分组内的先后次序。对于实现了ObservabilityPlugin的插件还可通过semaphore_size并发上限默认 10000与inject_timeout单次 Inject 超时默认 5s约束异步 Trace 注入的资源占用。配置选项明细插件在Init(config any)中解析config映射见 examples/plugins/multi-interface/main.go 的Init函数各开关含义如下OptionTypeDefaultDescriptionenable_http_hooksbooleantrueEnable HTTP transport layer hooksenable_llm_hooksbooleantrueEnable LLM request/response hooksenable_mcp_hooksbooleantrueEnable MCP request/response hooksenable_observabilitybooleantrueEnable observability/trace injectionenable_loggingbooleantrueEnable detailed loggingtrack_requestsbooleantrueTrack and count requestsinject_uptimebooleantrueInject server uptime in LLM system messagescustom_header_prefixstringX-Multi-PluginCustom prefix for HTTP response headersInit中的解析逻辑examples/plugins/multi-interface/main.go逐一从map[string]interface{}提取上述字段并回写到包级变量pluginConfig——这是插件默认值 配置覆盖的惯用模式先给结构体赋默认值再按配置逐项覆盖最后打印生效后的配置摘要。按场景裁剪的示例配置LLM-only 模式只挂 LLM 钩子最小化其余开销{ config: { enable_http_hooks: false, enable_llm_hooks: true, enable_mcp_hooks: false, enable_observability: false } }可观测性优先全钩子开启关闭冗长日志{ config: { enable_http_hooks: true, enable_llm_hooks: true, enable_mcp_hooks: true, enable_observability: true, enable_logging: false, track_requests: true } }最小开销保留钩子但关闭副作用{ config: { enable_logging: false, track_requests: false, inject_uptime: false } }自定义响应头前缀{ config: { custom_header_prefix: X-Custom-Plugin } }注意enable_http_hooks、enable_llm_hooks、enable_mcp_hooks等开关在插件源码中通过提前返回实现if !pluginConfig.EnableHTTPHooks { return nil, nil }关闭后对应 Hook 变为 no-op但函数签名与生命周期依然完整——这正是按需启用接口子集的推荐做法。五、Hook 执行顺序一次请求的完整生命周期multi-interface文档给出了两种典型请求的时序结合 core/schemas/plugin.go 中接口的文档注释可以更精确地理解典型 LLM 请求HTTPTransportPreHookHTTP 层入口鉴权之后、进入 Bifrost core 之前PreRequestHook每请求一次的路由决策阶段本示例未做路由直接返回 nilPreLLMHookLLM 提供商调用之前LLM Provider Call实际的上游模型调用PostLLMHookLLM 提供商返回之后HTTPTransportPostHookHTTP 层出口响应写回客户端前Inject响应已写出后的异步Trace 投递典型 MCP 请求HTTPTransportPreHookHTTP 层入口PreMCPHookMCP 服务器调用之前MCP Server Call实际工具/资源调用PostMCPHookMCP 服务器返回之后HTTPTransportPostHookHTTP 层出口Inject异步 Trace 投递接口文档中定义的执行细节每请求 vs 每尝试HTTPTransportPreHook、PreRequestHook、HTTPTransportPostHook每个顶层请求只执行一次而PreLLMHook/PostLLMHook在每次 fallback 尝试时都会执行主提供商调用 每次回退。如果需要对所有 fallback 可见的变更应放在PreRequestHook中。对称性保证管线保证每个执行过的PreLLMHook都会有对应的PostLLMHook以逆序回调插件作者应同时容忍 resp 与 err 为 nil 的情况PostLLMHook总会同时收到当前 response 与 error。Short-circuitPreLLMHook若返回LLMPluginShortCircuit可跳过提供商调用此时已执行过 Pre 钩子的插件仍会按逆序收到 Post 回调。流式响应HTTPTransportPostHook对流式响应不触发流式场景应实现HTTPTransportStreamChunkHook逐 chunk 逆序回调。错误语义插件错误不会被透传给调用方而是由 Bifrost 实例记录为警告PreRequestHook返回错误也不阻断请求仅记录日志。六、源码级拆解四个接口的实现要点下面逐接口梳理 examples/plugins/multi-interface/main.go 的实现细节方便你对照接口定义core/schemas/plugin.go理解每个签名。6.1 HTTPTransportPlugin请求计数与耗时头HTTPTransportPreHook(ctx, req)在请求进入 core 前执行关闭时直接返回(nil, nil)表示不拦截、继续开启track_requests时全局计数requestCount并向请求头写入prefix-Request-Number将请求时刻与路径写入 Context供后续 Hook 消费。HTTPTransportPostHook(ctx, req, resp)在响应出口执行从 Context 读回起始时间计算duration.Milliseconds()写入prefix-Duration-Ms响应头依据各开关组装当前启用的接口列表写入prefix-Interfaces响应头让下游系统一眼看出该请求经过了哪些插件层。这两个钩子接收的HTTPRequest/HTTPResponse是可序列化类型定义在 core/schemas/plugin.go含 Method、Path、Headers、Query、Body、PathParams 等字段并配套AcquireHTTPRequest/ReleaseHTTPRequest池化接口因此该接口同时兼容原生.so插件与 WASM 插件。另外接口还定义了HTTPTransportPreAuthHook鉴权中间件之前执行可为鉴权提供凭据——插件若无此需求返回(nil, nil)即可。6.2 LLMPlugin动态 system prompt 与耗时统计PreRequestHook(ctx, req)是路由决策阶段本示例不参与路由直接return nil。PreLLMHook(ctx, req)在每次提供商调用前执行读取 HTTP 层写入的multi-http-path关联出这次 LLM 调用来自哪个 HTTP 路径写入multi-llm-start-time当inject_uptime开启时构造一条 system 消息schemas.ChatMessage{Role: system, ...}内容包含请求序号与服务器运行时长并前置插入req.ChatRequest.Input切片头部——这是请求改写类插件的标准手法。PostLLMHook(ctx, resp, bifrostErr)在提供商返回后执行从 Context 读回起始时间计算 LLM 耗时写入multi-llm-duration供可观测层使用原样透传resp与bifrostErr。6.3 MCPPluginMCP 调用治理与计时PreMCPHook(ctx, req)在 MCP 工具/资源调用前执行写入multi-mcp-start-time与multi-mcp-type请求类型当req.ChatAssistantMessageToolCall.Function.Name存在时打印被调用的工具名演示治理即记录。PostMCPHook(ctx, resp, bifrostErr)在调用完成后计算并回写multi-mcp-duration。从 core/schemas/plugin.go 的接口定义可见MCP 层还提供可选的MCPConnectionPlugin扩展接口PreMCPConnectionHook/PostMCPConnectionHook仅处理 Connect 事件且实现该接口时通用 Pre/PostMCPHook 不会收到 Connect 请求只关心连接事件而不想实现通用钩子的插件可内嵌MCPPluginNoOpHooks获得免费的 no-op 实现。6.4 ObservabilityPlugin异步 Trace 投递Inject(ctx, trace)是唯一一个与请求主路径解耦的钩子异步触发响应写回客户端之后才调用不给客户端响应增加延迟接口注释明确说明若实现网络 I/O应将ctx传播给后端客户端以便inject_timeout超时后真正解除阻塞序列化导出示例用json.MarshalIndent(trace, , )将schemas.Trace输出为 JSON并注释出sendToDatadog(traceJSON)、sendToOTEL(trace)两个生产接入点生命周期约束Inject返回后调用方会立即把*Trace释放回sync.Pool插件禁止在返回后继续持有 Trace 指针需要异步转发的必须在返回前拷贝所需数据。Trace结构定义于 core/schemas/trace.go包含RequestID、TraceID继承自 W3C traceparent、RootSpan、Spans、Attributes、PluginLogs等字段并提供AddSpan、SetAttribute、SnapshotForExport等方法Trace层面的属性如x-bf-session-id、bifrost.dimensions不会作为 span 属性导出而是供 BigQuery、Datadog 等连接器直接读取。插件还可选择性实现OverheadSpanConsumer接收内部开销拆解 span与RawPayloadConsumer接收原始 provider 报文不实现则默认不接收。七、典型应用场景与扩展建议文档归纳了该插件的五类典型用途结合源码可以进一步落地为具体方案全栈可观测性Full-stack observabilitymulti-http-request-time→multi-llm-duration/multi-mcp-duration→Inject的 JSON Trace覆盖HTTP 进 → LLM/MCP 处理 → HTTP 出全链路接入真实后端时把Inject中的日志输出替换为 OTEL SDK / Datadog / Jaeger 客户端即可。统一治理Unified governance在 HTTP 层做鉴权/限流在 LLM 层改写请求或拦截输出在 MCP 层记录并约束工具调用同一份 Context 让各层策略共享决策信息。性能监控Performance monitoring三处耗时HTTP、LLM、MCP写入响应头可用于对外暴露延迟指标track_requests的计数在Cleanup时汇总打印processed N requests over uptime适合做进程级统计。审计留痕Audit trailsenable_logging开启时每个 Hook 阶段都会输出日志配合Inject的完整 Trace JSON 可重建任意请求的完整处理轨迹。自定义分析Custom analyticsHTTP 路径与 LLM/MCP 调用详情在同一 Context 中关联天然支持按路由统计模型调用成本/延迟类分析。作为模板使用时建议以本示例为骨架将Inject内的注释替换为真实后端适配器、为各钩子补充业务策略并根据需要实现OverheadSpanConsumer/RawPayloadConsumer等可选接口若只想实现单一接口可对照 http-transport-only、llm-only、mcp-only 三个精简示例缩减代码量。八、使用注意事项跨请求状态示例用包级变量requestCount、startTime跨请求计数与计时这在进程内是可行的但注意 Bifrost 插件以共享库形式在宿主进程内加载并发请求下需要自行保证计数操作的线程安全示例中的递增在真实高并发下建议改用原子操作。Context 生命周期元数据通过BifrostContext在单请求内流转各 Hook 阶段写入的键值仅对当前请求有效跨请求共享的数据应走包级状态而非 Context。Inject是异步的它发生在响应写出之后不能在Inject中依赖仍在进行的请求数据需要完整 Trace 时应在其内部完成格式化与转发且不得在返回后保留*Trace。流式响应HTTPTransportPostHook对流式场景不触发若插件需要逐 chunk 处理如修改增量内容、埋点统计应实现HTTPTransportStreamChunkHook。版本与工具链插件.so与宿主的 Go 版本、平台必须一致构建前确认 go.mod 中replace指向的core路径有效并始终在目标 Linux 环境上执行make build。赞分享人工智能LLM 网关API网关后端【免费下载链接】bifrostFastest enterprise AI gateway (50x faster than LiteLLM) with adaptive load balancer, cluster mode, guardrails, 1000 models support 100 µs overhead at 5k RPS.项目地址https://gitcode.com/gh_mirrors/bifrost31/bifrost点击查看免费下载相关推荐抖音批量下载工具指南三步跑通主页作品无水印采集抖音批量下载工具指南三步跑通主页作品无水印采集 想把一个抖音主页的作品全部存到本地、去掉水印、重跑时只取新发布的这正是 douyin downloader人工智能LLM 网关API网关后端一个内核四种入口agent-memory的SDK、HTTP、CLI、MCP多形态接入实战一个内核四种入口agent memory的SDK、HTTP、CLI、MCP多形态接入实战 openJiuwen 的 agent memory Jiuwen人工智能AI AgentAgent 记忆RAGMCP 服务Pinpoint 接入 Google HTTP Client 插件同步/异步调用链路追踪配置与原理详解Pinpoint 接入 Google HTTP Client 插件同步/异步调用链路追踪配置与原理详解 Pinpoint 是面向大规模分布式系统的 APMA后端可观测性APM链路追踪微服务上一篇突破桌面应用图标壁垒Nativefier全平台格式转换实战指南下一篇微信读书助手wereader打造你的专属数字书房管理方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考