拓冰网站定制 
简介顺丰科技Agentic AI企业应用平台的完整分享PPT面向企业AI平台架构师、大模型应用开发者及智能化转型决策者展示从智能体生态建设到模型服务治理的落地思路。资源共1个pptx文件压缩包仅5.41MB轻量便于快速浏览已有258人学习。内容围绕顺丰AI平台整体架构的“功能层算力云原生应用层”设计重点介绍EGPU池化、混合云推理优化、LLMOps观测平台Langfuse、模型广场及统一AI网关等关键模块。预览可见Agent生态发展时间线2024年Dify内部上线至DeepSeek/Qwen快速私有化部署、模型工具选型并针对NL2SQL、客服意图识别、语音生成等场景给出实践示例。看完可理解企业级AI平台如何通过资源调度、安全鉴权、统一协议与效果测评支撑1000智能体与千万级对话量帮助团队少走弯路。1. Agentic AI 企业级落地的三块基石模型入口、效果测评与链路观测Agentic AI 真正难的从来不是写出一个 Agent 原型而是把模型入口、效果测评、链路观测这三层基础设施打牢。顺丰科技 AI 平台组的这份内部材料讲的就是这三层怎么在企业里真实落地模型广场加一层 AI 网关做统一鉴权、协议转换和图片 Base64 化测评平台把模型选型从拍脑袋变成数据集加评分指标的客观打分LLMOps 观测平台用 LangFuse 把 Agent 链路每一跳都变成可追溯的数据。这套体系已经支撑了 1000 活跃智能体日消耗 Token 20 亿在客服意图识别、NL2SQL、运维监控等场景跑了一年多。如果你正在搭企业级 Agent 中台被“模型很多不知道怎么管、Prompt 调一次好一次坏、线上答错了不知道卡在哪一步”缠住这份 PPT 给出的是一条被真实业务压过的路径。2. 模型广场与 AI 网关协议转换、图片 Base64 化与统一鉴权怎么落地企业里接大模型从来不是接一个而是接一群私部署的 DeepSeek、Qwen商业的火山 Doubao、阿里 Qwen再加上语音识别、语音生成、向量化、Rerank 这些配套模型直接面对模型供应商时协议、鉴权、限流、审计全是窟窿。顺丰的做法是在模型广场前面加一层自研 AI 网关把私有部署和商业模型全部收口成一个 OpenAI 协议入口Agent 开发者不再关心底层是哪家供应商。2.1 为什么模型入口要先做收敛四个现实约束第一个约束是协议不统一。开发者有的用 OpenAI 协议有的用 Anthropic 协议还有的直接调各家原生 SDK平台没法统一记录调用量和调用成本。第二个约束是供应商太多Agent 开发者希望有丰富的模型种类快速试错但权限必须收敛还要兼顾个人提效需求。第三个约束是环境多研发、测试、生产各有一套私部署模型成本高多环境资源复用做不好光 GPU 采购就压不住。第四个约束是安全合规模型接入要有管控内容安全的模型才能引入内部使用从研发、集成到上线各阶段都要有流程申请和调用审核。这四个约束叠在一起结论只有一个Agent 开发者不应该直接对接模型供应商平台需要提供统一入口把鉴权、限流、负载均衡、协议转换这些脏活全部吃掉。这也是顺丰 AI 平台把“模型广场”放在架构最底层的原因——它既是模型目录也是访问控制边界。2.2 网关六项核心能力拆解鉴权、协议转换与图片 Base64 化AI 网关的六项能力每一项都对应一个具体的线上问题。能力解决什么关键设计 / 参数统一鉴权兼容 OpenAI 协议企业内统一 API 授权平台申请 API 授权按消费者配置限流按单位时间控制配额负载均衡后端 GPU 负载不均单实例被打满依据 KVCache 用量、排队请求数调度到最低负载实例协议转换Anthropic 等协议与 OpenAI 协议不互通统一为 OpenAI 协议保留原有协议接口APIKey 管理商业模型 Key 散落在各业务手上Key 与 Endpoint 独立模块管理多 Key 配置负载均衡内容审核请求和响应内容安全对 AI 请求与响应双向审核按模型配置调用审核策略图片转换内网图片 URL 无法被商业模型直接访问独立模块拉取图片并转 Base64 后再请求外部模型前两项是网关的常规操作后四项是顺丰做出来的企业内差异化。举两个例子说明。协议转换的价值在于降低试错成本。内部开发人员已经习惯了 OpenAI 的 SDK 和参数风格平台把 Anthropic 的接口翻译成 OpenAI 格式后业务代码一行不用改就能切换模型供应商。保留原协议接口是为了兼容已经在用的老系统避免强制迁移。图片转换是最容易被低估的一个能力。商业多模态模型要求传图片但内网文件服务有独立鉴权外部模型根本拉不到 URL。常见做法是在网关里做一个独立模块先按内网鉴权规则拉取图片转成 Base64 再拼进请求体。示意图如下import base64 import requests def fetch_and_encode(image_url: str, max_bytes: int 5 * 1024 * 1024) - str: # 内网文件服务有独立鉴权必须由网关侧拉取不能让外部模型直连 resp requests.get(image_url, timeout5) resp.raise_for_status() data resp.content if len(data) max_bytes: # 超过阈值先压缩或直接拒绝避免请求体过大触发商业模型 413 raise ValueError(fimage too large: {len(data)} bytes) return base64.b64encode(data).decode(utf-8)这段逻辑里有三个点容易踩超时必须要短内网文件服务慢会拖垮整个推理请求大小限制必须前置Base64 会让体积膨胀约 33%5MB 的图转完接近 7MB异常必须显式抛出让上层业务感知到是图片环节挂了而不是模型返回了莫名错误。提示图片转换独立成模块而不是写进网关主链路是为了故障隔离。图片服务抖动时只影响多模态请求不影响纯文本对话。2.3 成本与性能指标EGPU 池化、TTFT/TPOT 怎么定义模型入口收敛之后第二个问题是资源成本。顺丰的自研方向是 EGPU 池化技术搭配混合云推理优化和资源调度优化最大化 GPU 利用率。这套东西解决的是私部署模型的老大难GPU 资源碎片化、开发环境和生产环境各囤一批卡、高峰和低谷利用率天差地别。池化之后多环境可以复用同一批推理资源KVCache 用量和排队请求数成为调度依据把请求打到真正空闲的实例上。网关侧要盯的指标PPT 里列得很明确QPS、请求成功率、Token 消耗、RT含端到端响应时长、TTFT、TPOT、限流统计。其中 TTFT 和 TPOT 是判断“模型响应慢”到底慢在哪的关键指标含义典型用途TTFT从请求发出到收到首个 Token 的时延客服、对话场景的第一观感核心业务 SLO 必备TPOT平均生成一个 Token 的耗时判断模型推理吞吐定位是首字慢还是生成慢端到端 RT整个请求从发出到完成的耗时用户体感兜底指标告警首选我一般会用 TTFT 和 TPOT 一起看问题TTFT 高说明卡在排队或 Prefill 阶段TPOT 高说明模型生成能力或者显存带宽成了瓶颈。只看端到端 RT 的话这两个问题会被混在一起没法定位。模型入口收口之后下一个问题就是这么多模型到底哪个适合我的业务——这就要轮到测评平台说了算。3. Agent 效果测评在线/离线两条线、裁判员模型与性能 SLO 怎么定模型入口统一了紧接着的问题更头疼同一个业务需求DeepSeek、Qwen、Doubao 都能跑选哪个线上效果不好是模型不行还是 Prompt 不行PPT 里那句“调调 Prompt这个 Case OK 了其他 Case 效果又差了”就是纯靠试错的真实写照——没有客观评价体系调 Prompt 就是在碰运气。测评平台的价值是给这个黑匣子装上仪表盘。3.1 为什么测评要先于模型选型从调 Prompt 玄学说起Agent 落地初期模型选型基本靠两个手段看榜单、靠感觉。但企业场景里模型性能参差不齐同一套业务数据在不同模型上的表现可能差出两三个身位线上用户体验千差万别。顺丰测评平台的核心设计是让“选型”和“优化”都变成可留痕的评测任务每次测评固定大模型版本、数据集和评分指标输出测评报告效果对比和迭代跟踪才有依据。评测平台的组成PPT 里拆成了三块数据集市场、工具选择、测评报告。数据集负责提供“考卷”包含开源数据集和围绕业务能力指标构建的领域测试集工具选择负责封装标准测评产品支持灵活扩展覆盖模型广场、模型服务、智能体应用等多种调用来源测评报告负责输出可对比、可追溯的评估结论包括性能报告、基线效果报告、多模型 PK 报告、多 Prompt 效果评估报告。3.2 数据集、测试集与 Prompt 管理三个来源与版本留痕测评要让人信服先要解决“拿什么考”的问题。数据集来源有三个开源数据集用于冷启动覆盖通用能力业务数据集围绕业务能力指标构建比如客服意图识别的兜底率、NL2SQL 的字段正确性自定义数据集沉淀线上真实 Case配上业务方确认过的标准答案。三类数据集各有分工比例取决于业务阶段——冷启动期开源数据占比高业务稳定后自定义数据才是主力。构建一个可用的领域测试集我一般会走这几步从线上日志里挑高频和高价值场景按业务能力维度打标比如“多轮追问”“模糊指代”“复杂条件查询”。每个 Case 配标准答案务必找业务方确认口径不要算法同学自己拍板。用开源数据集覆盖通用能力冷启动业务数据集覆盖特殊场景。每次评估固定数据集版本和 Prompt 版本避免“换题考试”导致测评结果不可比。Prompt 管理在这套体系里容易被忽略但它直接决定测评结论的可靠性。同一个模型Prompt 版本不同效果能差出一大截。测评平台把 Prompt 纳入管理支持版本控制和变更留痕配合数据集版本一起锁定任何一次“改了 Prompt 效果变好了”的结论才能被验证。3.3 性能评测与效果评测两套流程与裁判员模型打分建模评测任务的流程很标准选测评集 → 创建测评任务 → 选择测评指标 → 查看测评结果。每一步的产物要固定下来否则后期没法追溯。步骤做什么产物选择测评集从数据集市场选内置或自定义数据集固定的测试集版本创建测评任务绑定模型服务或 Agent 应用配置评测方式可留痕的评估任务选择测评指标性能类选 TTFT/TPOT效果类选自动规则或裁判员模型指标定义查看测评结果生成报告支持多模型 PK 与日志追溯可追溯的测评报告效果评测分成在线、离线两条线。在线评测流程是数据集 推理模型/应用配置 → 在线生成推理结果 → 裁判员模型或自动规则打分。离线评测流程是数据集 线下提前跑好的模型推理结果 → 裁判员模型或自动规则打分。离线评测适合大批量跑批、模型服务还没上线的场景省 Token 也省时间在线评测适合模型已经接入服务、想实时看效果的场景。打分方式有三类自动规则打分适合有标准答案的结构化任务比如 NL2SQL 直接比对 SQL 执行结果裁判员模型评估适合开放性任务对比评估PK让多个模型跑同一批题直接比胜率。裁判员模型是目前企业里用得最多的给一个我们内部在用的打分模板你是一个公正的 Agent 效果评测员。 下面是用户问题、标准答案与候选回答。 请从正确性、完整性、相关性三个维度打分每个维度 1~5 分。 只输出 JSON不要输出任何解释。 {correctness: 4, completeness: 5, relevance: 3, comment: 简要扣分理由}这个模板里三个维度、分值范围、输出字段都是评分锚点缺了它们裁判员很容易给出“凭感觉”的分数。还有两个细节裁判员模型本身的 temperature 要固定为 0否则同一 Case 两次打分能差出好几分关键业务的测评建议抽 20%~30% 的 Case 做人工复核只信机器打分早晚翻车。提示性能评测是另一条独立流程——数据集只含提问字段配置好推理模型或应用后按生成 Token 的情况计算性能指标。它的用途是业务模型上线性能评估、模型优化评估、多模型横向对比最终形成企业内部的大模型 SLO。模型行不行有数了线上效果有没有达标还得靠另一套东西兜底——可观测。4. LLMOps 可观测LangFuse 选型、Trace 接入与 AIOps 多 Agent 监控测评解决的是“选谁”可观测解决的是“上线后到底发生了什么”。Agent 应用一上线链路就变成了一团乱麻前端 UI、认证、会话管理、对话服务、路由、流程编排、大模型服务、外部工具、MCP 服务、向量数据库每一层都可能拖慢或者出错。PPT 里有一个很实在的判断不同应用技术栈多样、技术框架多样、大模型调用上下文长、工具质量参差不齐没有 Trace 时排障就是猜谜。4.1 LLM 应用为什么必须走 Trace从排障黑匣子到白盒化LLM 应用的可观测需求和传统微服务不一样它要多回答四类问题。第一如何低成本高质量地采集数据应用技术栈五花八门采集成本高了没人愿意接。第二如何监控端到端全链路性能性能下降或报错时能及时告警而不是等用户投诉。第三如何标准化记录输入输出、Token 消耗、关键执行动作和结果状态并可视化分析。第四应用编排框架把底层细节屏蔽了Agent 逻辑复杂、工具质量参差不齐平台必须提供白盒化能力做根因定位。这四件事落到数据上就是一件事把每一次 Agent 运行的完整上下文记录下来包括外部 API 调用、Prompt、上下文、工具参数、结果状态。记录下来的数据再反哺测评和优化就形成了 PPT 里说的数据飞轮——线上实际效果表现数据辅助分析、评估、持续优化迭代 LLM 应用越跑越准。4.2 LangFuse 还是 Opik选型对比、接入边界与采样顺丰内部对 LangFuse 和 Opik 做过一轮完整对比结论直接放表格里。维度LangFuseOpik协议MITApache 2.0追踪与日志完整上下文、外部 API 调用、实时指标、OTEL、DAG 图、数据脱敏、采样嵌套调用追踪、实时指标、OTEL、DAG 图评估与测试手动管理数据集从上下文批量添加预构建和自定义评估指标支持 LLM 单元测试和 PytestPrompt 管理UI 驱动支持版本控制和测试提示库支持代码同步和版本控制集成能力LangChain、LlamaIndex、Dify支持 44 个开源框架OpenAI、LangChain 等支持 33 个开源框架易用性门槛低UI 驱动适合非技术团队门槛中等特性多需要更多编码选型结论很直接LangFuse 胜在易用性和开箱即用尤其是直接支持 Dify内部平台接进来几乎不用写适配层Opik 可玩性强、评估体系更丰富但需要专门的开发人手去维护。顺丰内部选了 LangFuse 并纳入平台理由是“使用门槛低 直接支持 Dify 支持 OTEL 协议可以和企业内部可观测实践对齐”。接入方式常见做法是通过 SDK 埋点每个用户请求建一条 TraceAgent 内部每一跳挂一个 Span。示意代码如下from langfuse import Langfuse langfuse Langfuse( public_keyos.environ[LANGFUSE_PK], secret_keyos.environ[LANGFUSE_SK], hostos.environ[LANGFUSE_HOST], ) def handle_agent_request(request): trace langfuse.trace( nameagent-run, session_idrequest[session_id], ) try: result run_agent(request) trace.update( outputresult, metadata{tokens: count_tokens(request, result)}, ) return result except Exception as exc: trace.update(statuserror, metadata{error: str(exc)}) raise这段代码有两个关键点Trace 要按“一次用户请求”建而不是按“一次模型调用”建否则多分支流程会碎成一片异常分支必须把错误信息写进 Trace 状态线上很多链路断了就是没记 error排障时又抓瞎。生产环境建议分层采样核心业务全量采集普通业务按 5%~10% 采样调试场景 1% 就够全量上报迟早把存储打爆。提示Trace 数据里经常带用户输入、业务上下文等敏感字段上报前必须做脱敏。LangFuse 支持上报数据脱敏和采样这两项要当成选型必备项不是可选项。4.3 AIOps 多 Agent 场景几十个分支怎么盯PPT 里给了一个内部 AIOps 多 Agent 系统的例子链路复杂到几十个分支。这类系统的维护难点主要有六个流程复杂分支多到改一个节点要理半天大模型调用场景多需要记录对应的输入输出工具调用场景多每次调用工具的具体参数都要记录Prompt 多没有统一管理工具根本理不清性能优化难没有全局视图找不到可优化点全链路跟踪困难下游出问题没法快速定位到 Agent 流程里的具体节点。这些难点对应的监控对象可以收敛成一张表监控对象关键指标用途API 接口端到端 RT、成功率用户体感兜底第一时间告警Agent 节点单节点执行时长、重试次数定位到底哪个分支拖慢了整体大模型调用输入/输出 Token、TTFT、TPOT成本和性能归因工具调用参数、返回状态、耗时定位下游工具故障Prompt版本、变更时间效果回归对照除传统的 API 接口端到端性能之外多 Agent 系统还要额外盯住各 Agent 自身的性能、任务执行情况、Token 开销和大模型输入输出。配合 OTEL 协议Agent 的 Trace 与企业内部可观测平台打通传统的日志和指标也能收进同一平台运维从“Agent 流程黑盒”变成“每一跳都有据可查”。这也呼应了 PPT 那句不仅监控接口还监控 Agent 系统的 Token 开销为后续优化做准备。工具链的每一块都有坑下面把五类典型的翻车记录摆出来。5. 避坑与常见问题网关、测评与可观测层的五个典型踩坑这五个坑是我们在内部平台从上线到稳定过程中反复踩过的写出来当后悔药。前三个在模型服务与网关层后两个在测评与可观测层各有各的隐蔽性。5.1 模型服务与网关限流挤兑、图片超限与流式转换坑一商业模型 APIKey 共用导致限流互相挤兑现象A 业务跑大批量离线任务把共享的商业模型配额占满B 业务线上实时请求全部被限流成功率肉眼可见地往下掉。原因平台为省事让多个业务共用同一组商业模型的 APIKey 和 Endpoint。网关限流是 Endpoint 维度的一个业务打满全员陪葬。解决APIKey 按消费者维度拆分每个应用申请独立的子 Key限流策略分成“总配额 单消费者配额”两级核心业务单独分配一组 Endpoint做故障隔离。健康检查也要区分实例层和应用层实例活着不代表 Endpoint 还能继续扛量。坑二内网图片转 Base64 后请求体超限现象内网图片转成 Base64 调用商业多模态模型请求直接被拒绝报 413 或超时。原因内网图片普遍偏大转 Base64 后体积再膨胀约 33%再加上 Prompt 和上下文很容易超过商业模型接口的请求体上限。解决网关拉取图片时前置校验大小超过阈值压缩或直接拒绝转换模块独立部署设独立超时和重试对超大图片给业务方降级策略比如取缩略图或抽取关键帧。这个坑在选型时容易被忽略等上线被 413 打脸就晚了。坑三流式场景协议转换把 SSE 改坏了现象统一网关后前端打字机效果时断时续甚至直接解析失败。原因协议转换逻辑大多基于非流式接口实现流式场景下 SSE chunk 的格式、字段位置、结束标记处理不一致转换层把流给截断了。解决流式请求走协议级透传只有非流式请求做 Anthropic 到 OpenAI 的字段翻译上线前用 SSE 压测脚本覆盖断连、半包、多 chunk 场景。协议转换的测试用例里必须包含流式这是最容易漏的一类。5.2 测评与可观测裁判员波动与 Trace 数据膨胀坑四裁判员模型打分不稳定同一 Case 两次评分差太多现象同一份测试集跑两次测评分数波动明显无法判断这次改动到底有没有效。原因裁判员模型本身继承了 LLM 的随机性评分 Prompt 没有定义分值锚点打 3 分还是 4 分全凭感觉生成参数没固定temperature 默认值下同一输入可能产出不同分数。解决temperature 固定为 0评分 Prompt 明确每个分值的含义附 1~2 个参考样例同一 Case 多次评分取均值关键业务 20%~30% 的 Case 人工复核。裁判员模型的输出格式也要硬约束成 JSON方便自动化解析和留痕。坑五Trace 全量上报存储和查询先撑不住现象LangFuse 集群存储涨得飞快链路查询越来越慢本来为了排障结果排障工具先卡死了。原因全量记录输入输出带长上下文的对话单条 Trace 就有几十 KB生产环境跑几天就是几十 GB。存储膨胀之后查询和索引也跟着退化。解决分层采样核心业务全量采集普通业务按 5%~10% 采样敏感字段脱敏后再上报Prompt 内容默认截断需要排查时再按 request_id 从日志侧补查设定日志保留周期超期归档或清理。可观测数据不是越多越好能支撑定位和告警的量就是最优解。6. 把 Agent 工具链串起来Dify 模型供应商解耦与 MCP 市场的落地技巧前面几章讲的都是平台底座最后一公里其实只有两件事一是让模型供应商从 Dify 社区代码里解耦出来二是让内部工具都包成 MCP 插件。6.1 模型供应商外置与 MCP 插件化一次封装两端复用Dify 社区版的问题是模型供应商内置在代码里每接一个新模型都要改插件包、发版、等部署。顺丰的做法是把模型提供商接口从 Dify 社区代码里解耦出来开发了符合内部合规要求的模型供应商模块每个 App 可以在界面上直接配置模型新模型从申请到上线可以做到天级不用等 Dify 本体发版。这是基于 Dify 二次开发里最值回票价的一个改动。Dify 的性能也要单独调。核心流程的 chat-message、completion-message 对话补全、datasets 知识库管理分别做逻辑优化数据库层也做了增强核心接口性能能提升数倍。这里的常见做法是先压测定位慢查询再针对补全接口的 N1 查询做批量化改造知识库命中的结果加缓存。MCP 市场是另一个值得抄作业的设计。平台把代码、日常办公工具、顺丰物流业务工具、客服业务工具等数十种内部能力包成 MCP 插件既提供给 Agent 平台用也提供给 MCP 客户端用。收益是一次封装两端复用Agent 应用不再需要重复造工具轮子外部生态也能通过标准协议接进来。从那以后我形成一个习惯任何内部能力要接入平台先问一句“能不能包成 MCP 插件”能包就先包——工具侧的开放程度直接决定了 Agent 应用能长多快。模型入口收敛、效果可测评、链路可观测、工具可插拔这四件事是所有 Agent 平台从 demo 走向生产的必经之路。希望帮到你。本文还有配套的精品资源点击获取 Agentic AI企业级落地的三块基石：模型入口、效果测评与链路观测
简介顺丰科技Agentic AI企业应用平台的完整分享PPT面向企业AI平台架构师、大模型应用开发者及智能化转型决策者展示从智能体生态建设到模型服务治理的落地思路。资源共1个pptx文件压缩包仅5.41MB轻量便于快速浏览已有258人学习。内容围绕顺丰AI平台整体架构的“功能层算力云原生应用层”设计重点介绍EGPU池化、混合云推理优化、LLMOps观测平台Langfuse、模型广场及统一AI网关等关键模块。预览可见Agent生态发展时间线2024年Dify内部上线至DeepSeek/Qwen快速私有化部署、模型工具选型并针对NL2SQL、客服意图识别、语音生成等场景给出实践示例。看完可理解企业级AI平台如何通过资源调度、安全鉴权、统一协议与效果测评支撑1000智能体与千万级对话量帮助团队少走弯路。1. Agentic AI 企业级落地的三块基石模型入口、效果测评与链路观测Agentic AI 真正难的从来不是写出一个 Agent 原型而是把模型入口、效果测评、链路观测这三层基础设施打牢。顺丰科技 AI 平台组的这份内部材料讲的就是这三层怎么在企业里真实落地模型广场加一层 AI 网关做统一鉴权、协议转换和图片 Base64 化测评平台把模型选型从拍脑袋变成数据集加评分指标的客观打分LLMOps 观测平台用 LangFuse 把 Agent 链路每一跳都变成可追溯的数据。这套体系已经支撑了 1000 活跃智能体日消耗 Token 20 亿在客服意图识别、NL2SQL、运维监控等场景跑了一年多。如果你正在搭企业级 Agent 中台被“模型很多不知道怎么管、Prompt 调一次好一次坏、线上答错了不知道卡在哪一步”缠住这份 PPT 给出的是一条被真实业务压过的路径。2. 模型广场与 AI 网关协议转换、图片 Base64 化与统一鉴权怎么落地企业里接大模型从来不是接一个而是接一群私部署的 DeepSeek、Qwen商业的火山 Doubao、阿里 Qwen再加上语音识别、语音生成、向量化、Rerank 这些配套模型直接面对模型供应商时协议、鉴权、限流、审计全是窟窿。顺丰的做法是在模型广场前面加一层自研 AI 网关把私有部署和商业模型全部收口成一个 OpenAI 协议入口Agent 开发者不再关心底层是哪家供应商。2.1 为什么模型入口要先做收敛四个现实约束第一个约束是协议不统一。开发者有的用 OpenAI 协议有的用 Anthropic 协议还有的直接调各家原生 SDK平台没法统一记录调用量和调用成本。第二个约束是供应商太多Agent 开发者希望有丰富的模型种类快速试错但权限必须收敛还要兼顾个人提效需求。第三个约束是环境多研发、测试、生产各有一套私部署模型成本高多环境资源复用做不好光 GPU 采购就压不住。第四个约束是安全合规模型接入要有管控内容安全的模型才能引入内部使用从研发、集成到上线各阶段都要有流程申请和调用审核。这四个约束叠在一起结论只有一个Agent 开发者不应该直接对接模型供应商平台需要提供统一入口把鉴权、限流、负载均衡、协议转换这些脏活全部吃掉。这也是顺丰 AI 平台把“模型广场”放在架构最底层的原因——它既是模型目录也是访问控制边界。2.2 网关六项核心能力拆解鉴权、协议转换与图片 Base64 化AI 网关的六项能力每一项都对应一个具体的线上问题。能力解决什么关键设计 / 参数统一鉴权兼容 OpenAI 协议企业内统一 API 授权平台申请 API 授权按消费者配置限流按单位时间控制配额负载均衡后端 GPU 负载不均单实例被打满依据 KVCache 用量、排队请求数调度到最低负载实例协议转换Anthropic 等协议与 OpenAI 协议不互通统一为 OpenAI 协议保留原有协议接口APIKey 管理商业模型 Key 散落在各业务手上Key 与 Endpoint 独立模块管理多 Key 配置负载均衡内容审核请求和响应内容安全对 AI 请求与响应双向审核按模型配置调用审核策略图片转换内网图片 URL 无法被商业模型直接访问独立模块拉取图片并转 Base64 后再请求外部模型前两项是网关的常规操作后四项是顺丰做出来的企业内差异化。举两个例子说明。协议转换的价值在于降低试错成本。内部开发人员已经习惯了 OpenAI 的 SDK 和参数风格平台把 Anthropic 的接口翻译成 OpenAI 格式后业务代码一行不用改就能切换模型供应商。保留原协议接口是为了兼容已经在用的老系统避免强制迁移。图片转换是最容易被低估的一个能力。商业多模态模型要求传图片但内网文件服务有独立鉴权外部模型根本拉不到 URL。常见做法是在网关里做一个独立模块先按内网鉴权规则拉取图片转成 Base64 再拼进请求体。示意图如下import base64 import requests def fetch_and_encode(image_url: str, max_bytes: int 5 * 1024 * 1024) - str: # 内网文件服务有独立鉴权必须由网关侧拉取不能让外部模型直连 resp requests.get(image_url, timeout5) resp.raise_for_status() data resp.content if len(data) max_bytes: # 超过阈值先压缩或直接拒绝避免请求体过大触发商业模型 413 raise ValueError(fimage too large: {len(data)} bytes) return base64.b64encode(data).decode(utf-8)这段逻辑里有三个点容易踩超时必须要短内网文件服务慢会拖垮整个推理请求大小限制必须前置Base64 会让体积膨胀约 33%5MB 的图转完接近 7MB异常必须显式抛出让上层业务感知到是图片环节挂了而不是模型返回了莫名错误。提示图片转换独立成模块而不是写进网关主链路是为了故障隔离。图片服务抖动时只影响多模态请求不影响纯文本对话。2.3 成本与性能指标EGPU 池化、TTFT/TPOT 怎么定义模型入口收敛之后第二个问题是资源成本。顺丰的自研方向是 EGPU 池化技术搭配混合云推理优化和资源调度优化最大化 GPU 利用率。这套东西解决的是私部署模型的老大难GPU 资源碎片化、开发环境和生产环境各囤一批卡、高峰和低谷利用率天差地别。池化之后多环境可以复用同一批推理资源KVCache 用量和排队请求数成为调度依据把请求打到真正空闲的实例上。网关侧要盯的指标PPT 里列得很明确QPS、请求成功率、Token 消耗、RT含端到端响应时长、TTFT、TPOT、限流统计。其中 TTFT 和 TPOT 是判断“模型响应慢”到底慢在哪的关键指标含义典型用途TTFT从请求发出到收到首个 Token 的时延客服、对话场景的第一观感核心业务 SLO 必备TPOT平均生成一个 Token 的耗时判断模型推理吞吐定位是首字慢还是生成慢端到端 RT整个请求从发出到完成的耗时用户体感兜底指标告警首选我一般会用 TTFT 和 TPOT 一起看问题TTFT 高说明卡在排队或 Prefill 阶段TPOT 高说明模型生成能力或者显存带宽成了瓶颈。只看端到端 RT 的话这两个问题会被混在一起没法定位。模型入口收口之后下一个问题就是这么多模型到底哪个适合我的业务——这就要轮到测评平台说了算。3. Agent 效果测评在线/离线两条线、裁判员模型与性能 SLO 怎么定模型入口统一了紧接着的问题更头疼同一个业务需求DeepSeek、Qwen、Doubao 都能跑选哪个线上效果不好是模型不行还是 Prompt 不行PPT 里那句“调调 Prompt这个 Case OK 了其他 Case 效果又差了”就是纯靠试错的真实写照——没有客观评价体系调 Prompt 就是在碰运气。测评平台的价值是给这个黑匣子装上仪表盘。3.1 为什么测评要先于模型选型从调 Prompt 玄学说起Agent 落地初期模型选型基本靠两个手段看榜单、靠感觉。但企业场景里模型性能参差不齐同一套业务数据在不同模型上的表现可能差出两三个身位线上用户体验千差万别。顺丰测评平台的核心设计是让“选型”和“优化”都变成可留痕的评测任务每次测评固定大模型版本、数据集和评分指标输出测评报告效果对比和迭代跟踪才有依据。评测平台的组成PPT 里拆成了三块数据集市场、工具选择、测评报告。数据集负责提供“考卷”包含开源数据集和围绕业务能力指标构建的领域测试集工具选择负责封装标准测评产品支持灵活扩展覆盖模型广场、模型服务、智能体应用等多种调用来源测评报告负责输出可对比、可追溯的评估结论包括性能报告、基线效果报告、多模型 PK 报告、多 Prompt 效果评估报告。3.2 数据集、测试集与 Prompt 管理三个来源与版本留痕测评要让人信服先要解决“拿什么考”的问题。数据集来源有三个开源数据集用于冷启动覆盖通用能力业务数据集围绕业务能力指标构建比如客服意图识别的兜底率、NL2SQL 的字段正确性自定义数据集沉淀线上真实 Case配上业务方确认过的标准答案。三类数据集各有分工比例取决于业务阶段——冷启动期开源数据占比高业务稳定后自定义数据才是主力。构建一个可用的领域测试集我一般会走这几步从线上日志里挑高频和高价值场景按业务能力维度打标比如“多轮追问”“模糊指代”“复杂条件查询”。每个 Case 配标准答案务必找业务方确认口径不要算法同学自己拍板。用开源数据集覆盖通用能力冷启动业务数据集覆盖特殊场景。每次评估固定数据集版本和 Prompt 版本避免“换题考试”导致测评结果不可比。Prompt 管理在这套体系里容易被忽略但它直接决定测评结论的可靠性。同一个模型Prompt 版本不同效果能差出一大截。测评平台把 Prompt 纳入管理支持版本控制和变更留痕配合数据集版本一起锁定任何一次“改了 Prompt 效果变好了”的结论才能被验证。3.3 性能评测与效果评测两套流程与裁判员模型打分建模评测任务的流程很标准选测评集 → 创建测评任务 → 选择测评指标 → 查看测评结果。每一步的产物要固定下来否则后期没法追溯。步骤做什么产物选择测评集从数据集市场选内置或自定义数据集固定的测试集版本创建测评任务绑定模型服务或 Agent 应用配置评测方式可留痕的评估任务选择测评指标性能类选 TTFT/TPOT效果类选自动规则或裁判员模型指标定义查看测评结果生成报告支持多模型 PK 与日志追溯可追溯的测评报告效果评测分成在线、离线两条线。在线评测流程是数据集 推理模型/应用配置 → 在线生成推理结果 → 裁判员模型或自动规则打分。离线评测流程是数据集 线下提前跑好的模型推理结果 → 裁判员模型或自动规则打分。离线评测适合大批量跑批、模型服务还没上线的场景省 Token 也省时间在线评测适合模型已经接入服务、想实时看效果的场景。打分方式有三类自动规则打分适合有标准答案的结构化任务比如 NL2SQL 直接比对 SQL 执行结果裁判员模型评估适合开放性任务对比评估PK让多个模型跑同一批题直接比胜率。裁判员模型是目前企业里用得最多的给一个我们内部在用的打分模板你是一个公正的 Agent 效果评测员。 下面是用户问题、标准答案与候选回答。 请从正确性、完整性、相关性三个维度打分每个维度 1~5 分。 只输出 JSON不要输出任何解释。 {correctness: 4, completeness: 5, relevance: 3, comment: 简要扣分理由}这个模板里三个维度、分值范围、输出字段都是评分锚点缺了它们裁判员很容易给出“凭感觉”的分数。还有两个细节裁判员模型本身的 temperature 要固定为 0否则同一 Case 两次打分能差出好几分关键业务的测评建议抽 20%~30% 的 Case 做人工复核只信机器打分早晚翻车。提示性能评测是另一条独立流程——数据集只含提问字段配置好推理模型或应用后按生成 Token 的情况计算性能指标。它的用途是业务模型上线性能评估、模型优化评估、多模型横向对比最终形成企业内部的大模型 SLO。模型行不行有数了线上效果有没有达标还得靠另一套东西兜底——可观测。4. LLMOps 可观测LangFuse 选型、Trace 接入与 AIOps 多 Agent 监控测评解决的是“选谁”可观测解决的是“上线后到底发生了什么”。Agent 应用一上线链路就变成了一团乱麻前端 UI、认证、会话管理、对话服务、路由、流程编排、大模型服务、外部工具、MCP 服务、向量数据库每一层都可能拖慢或者出错。PPT 里有一个很实在的判断不同应用技术栈多样、技术框架多样、大模型调用上下文长、工具质量参差不齐没有 Trace 时排障就是猜谜。4.1 LLM 应用为什么必须走 Trace从排障黑匣子到白盒化LLM 应用的可观测需求和传统微服务不一样它要多回答四类问题。第一如何低成本高质量地采集数据应用技术栈五花八门采集成本高了没人愿意接。第二如何监控端到端全链路性能性能下降或报错时能及时告警而不是等用户投诉。第三如何标准化记录输入输出、Token 消耗、关键执行动作和结果状态并可视化分析。第四应用编排框架把底层细节屏蔽了Agent 逻辑复杂、工具质量参差不齐平台必须提供白盒化能力做根因定位。这四件事落到数据上就是一件事把每一次 Agent 运行的完整上下文记录下来包括外部 API 调用、Prompt、上下文、工具参数、结果状态。记录下来的数据再反哺测评和优化就形成了 PPT 里说的数据飞轮——线上实际效果表现数据辅助分析、评估、持续优化迭代 LLM 应用越跑越准。4.2 LangFuse 还是 Opik选型对比、接入边界与采样顺丰内部对 LangFuse 和 Opik 做过一轮完整对比结论直接放表格里。维度LangFuseOpik协议MITApache 2.0追踪与日志完整上下文、外部 API 调用、实时指标、OTEL、DAG 图、数据脱敏、采样嵌套调用追踪、实时指标、OTEL、DAG 图评估与测试手动管理数据集从上下文批量添加预构建和自定义评估指标支持 LLM 单元测试和 PytestPrompt 管理UI 驱动支持版本控制和测试提示库支持代码同步和版本控制集成能力LangChain、LlamaIndex、Dify支持 44 个开源框架OpenAI、LangChain 等支持 33 个开源框架易用性门槛低UI 驱动适合非技术团队门槛中等特性多需要更多编码选型结论很直接LangFuse 胜在易用性和开箱即用尤其是直接支持 Dify内部平台接进来几乎不用写适配层Opik 可玩性强、评估体系更丰富但需要专门的开发人手去维护。顺丰内部选了 LangFuse 并纳入平台理由是“使用门槛低 直接支持 Dify 支持 OTEL 协议可以和企业内部可观测实践对齐”。接入方式常见做法是通过 SDK 埋点每个用户请求建一条 TraceAgent 内部每一跳挂一个 Span。示意代码如下from langfuse import Langfuse langfuse Langfuse( public_keyos.environ[LANGFUSE_PK], secret_keyos.environ[LANGFUSE_SK], hostos.environ[LANGFUSE_HOST], ) def handle_agent_request(request): trace langfuse.trace( nameagent-run, session_idrequest[session_id], ) try: result run_agent(request) trace.update( outputresult, metadata{tokens: count_tokens(request, result)}, ) return result except Exception as exc: trace.update(statuserror, metadata{error: str(exc)}) raise这段代码有两个关键点Trace 要按“一次用户请求”建而不是按“一次模型调用”建否则多分支流程会碎成一片异常分支必须把错误信息写进 Trace 状态线上很多链路断了就是没记 error排障时又抓瞎。生产环境建议分层采样核心业务全量采集普通业务按 5%~10% 采样调试场景 1% 就够全量上报迟早把存储打爆。提示Trace 数据里经常带用户输入、业务上下文等敏感字段上报前必须做脱敏。LangFuse 支持上报数据脱敏和采样这两项要当成选型必备项不是可选项。4.3 AIOps 多 Agent 场景几十个分支怎么盯PPT 里给了一个内部 AIOps 多 Agent 系统的例子链路复杂到几十个分支。这类系统的维护难点主要有六个流程复杂分支多到改一个节点要理半天大模型调用场景多需要记录对应的输入输出工具调用场景多每次调用工具的具体参数都要记录Prompt 多没有统一管理工具根本理不清性能优化难没有全局视图找不到可优化点全链路跟踪困难下游出问题没法快速定位到 Agent 流程里的具体节点。这些难点对应的监控对象可以收敛成一张表监控对象关键指标用途API 接口端到端 RT、成功率用户体感兜底第一时间告警Agent 节点单节点执行时长、重试次数定位到底哪个分支拖慢了整体大模型调用输入/输出 Token、TTFT、TPOT成本和性能归因工具调用参数、返回状态、耗时定位下游工具故障Prompt版本、变更时间效果回归对照除传统的 API 接口端到端性能之外多 Agent 系统还要额外盯住各 Agent 自身的性能、任务执行情况、Token 开销和大模型输入输出。配合 OTEL 协议Agent 的 Trace 与企业内部可观测平台打通传统的日志和指标也能收进同一平台运维从“Agent 流程黑盒”变成“每一跳都有据可查”。这也呼应了 PPT 那句不仅监控接口还监控 Agent 系统的 Token 开销为后续优化做准备。工具链的每一块都有坑下面把五类典型的翻车记录摆出来。5. 避坑与常见问题网关、测评与可观测层的五个典型踩坑这五个坑是我们在内部平台从上线到稳定过程中反复踩过的写出来当后悔药。前三个在模型服务与网关层后两个在测评与可观测层各有各的隐蔽性。5.1 模型服务与网关限流挤兑、图片超限与流式转换坑一商业模型 APIKey 共用导致限流互相挤兑现象A 业务跑大批量离线任务把共享的商业模型配额占满B 业务线上实时请求全部被限流成功率肉眼可见地往下掉。原因平台为省事让多个业务共用同一组商业模型的 APIKey 和 Endpoint。网关限流是 Endpoint 维度的一个业务打满全员陪葬。解决APIKey 按消费者维度拆分每个应用申请独立的子 Key限流策略分成“总配额 单消费者配额”两级核心业务单独分配一组 Endpoint做故障隔离。健康检查也要区分实例层和应用层实例活着不代表 Endpoint 还能继续扛量。坑二内网图片转 Base64 后请求体超限现象内网图片转成 Base64 调用商业多模态模型请求直接被拒绝报 413 或超时。原因内网图片普遍偏大转 Base64 后体积再膨胀约 33%再加上 Prompt 和上下文很容易超过商业模型接口的请求体上限。解决网关拉取图片时前置校验大小超过阈值压缩或直接拒绝转换模块独立部署设独立超时和重试对超大图片给业务方降级策略比如取缩略图或抽取关键帧。这个坑在选型时容易被忽略等上线被 413 打脸就晚了。坑三流式场景协议转换把 SSE 改坏了现象统一网关后前端打字机效果时断时续甚至直接解析失败。原因协议转换逻辑大多基于非流式接口实现流式场景下 SSE chunk 的格式、字段位置、结束标记处理不一致转换层把流给截断了。解决流式请求走协议级透传只有非流式请求做 Anthropic 到 OpenAI 的字段翻译上线前用 SSE 压测脚本覆盖断连、半包、多 chunk 场景。协议转换的测试用例里必须包含流式这是最容易漏的一类。5.2 测评与可观测裁判员波动与 Trace 数据膨胀坑四裁判员模型打分不稳定同一 Case 两次评分差太多现象同一份测试集跑两次测评分数波动明显无法判断这次改动到底有没有效。原因裁判员模型本身继承了 LLM 的随机性评分 Prompt 没有定义分值锚点打 3 分还是 4 分全凭感觉生成参数没固定temperature 默认值下同一输入可能产出不同分数。解决temperature 固定为 0评分 Prompt 明确每个分值的含义附 1~2 个参考样例同一 Case 多次评分取均值关键业务 20%~30% 的 Case 人工复核。裁判员模型的输出格式也要硬约束成 JSON方便自动化解析和留痕。坑五Trace 全量上报存储和查询先撑不住现象LangFuse 集群存储涨得飞快链路查询越来越慢本来为了排障结果排障工具先卡死了。原因全量记录输入输出带长上下文的对话单条 Trace 就有几十 KB生产环境跑几天就是几十 GB。存储膨胀之后查询和索引也跟着退化。解决分层采样核心业务全量采集普通业务按 5%~10% 采样敏感字段脱敏后再上报Prompt 内容默认截断需要排查时再按 request_id 从日志侧补查设定日志保留周期超期归档或清理。可观测数据不是越多越好能支撑定位和告警的量就是最优解。6. 把 Agent 工具链串起来Dify 模型供应商解耦与 MCP 市场的落地技巧前面几章讲的都是平台底座最后一公里其实只有两件事一是让模型供应商从 Dify 社区代码里解耦出来二是让内部工具都包成 MCP 插件。6.1 模型供应商外置与 MCP 插件化一次封装两端复用Dify 社区版的问题是模型供应商内置在代码里每接一个新模型都要改插件包、发版、等部署。顺丰的做法是把模型提供商接口从 Dify 社区代码里解耦出来开发了符合内部合规要求的模型供应商模块每个 App 可以在界面上直接配置模型新模型从申请到上线可以做到天级不用等 Dify 本体发版。这是基于 Dify 二次开发里最值回票价的一个改动。Dify 的性能也要单独调。核心流程的 chat-message、completion-message 对话补全、datasets 知识库管理分别做逻辑优化数据库层也做了增强核心接口性能能提升数倍。这里的常见做法是先压测定位慢查询再针对补全接口的 N1 查询做批量化改造知识库命中的结果加缓存。MCP 市场是另一个值得抄作业的设计。平台把代码、日常办公工具、顺丰物流业务工具、客服业务工具等数十种内部能力包成 MCP 插件既提供给 Agent 平台用也提供给 MCP 客户端用。收益是一次封装两端复用Agent 应用不再需要重复造工具轮子外部生态也能通过标准协议接进来。从那以后我形成一个习惯任何内部能力要接入平台先问一句“能不能包成 MCP 插件”能包就先包——工具侧的开放程度直接决定了 Agent 应用能长多快。模型入口收敛、效果可测评、链路可观测、工具可插拔这四件事是所有 Agent 平台从 demo 走向生产的必经之路。希望帮到你。本文还有配套的精品资源点击获取