作者DKX,ZP,PZL from DeepLink Group Shanghai AI Lab在AI大模型时代算力成为新的石油。然而如何科学、高效地评测AI芯片与软件栈的性能却成为困扰行业的难题。传统评测方式面临诸多痛点脚本编写繁琐、环境配置复杂、跨芯片适配困难、失败排查耗时。一个完整的评测任务往往需要工程师投入数天甚至数周时间。为解决上述行业痛点问题我们推出多智能体协作的自动化评测方案构建五大专职智能体及多智能体协作机制实现AI软硬件评测的全流程自动化能够显著提升评测效率。此外我们在近日开源了 AI 全环节软硬件验证技能库DeepEval-Skills作为验证平台的核心工具之一DeepEval-Skills已适配多款国内外主流AI芯片覆盖 NLP、CV、多模态、科学计算、语音等10余个评测子场景兼容主流智能体工具支持开发者开箱即用有效降低AI芯片、大模型软硬件评测门槛。本文将介绍我们如何通过多智能体协同实现 AI 软硬件评测的全流程自动化详细讲解系统架构与设计要点并在最后附上了开源评测技能库DeepEval-Skills的部署使用方式。DeepEval-Skills Githubhttps://github.com/DeepLink-org/DeepEval-SkillsDeepEval-Skills Atomgithttps://atomgit.com/DeepLink/DeepEval-Skills一、行业痛点AI评测的三座大山传统AI评测存在人工成本高昂、技术门槛高、跨芯片适配难等痛点问题具体表现为1.人工成本高昂一个典型的AI训练评测任务涉及配置收集理解评测需求确定模型、数据集、硬件配置、环境搭建安装Docker、配置依赖、挂载存储、脚本编写编写训练/推理脚本、数据预处理代码、执行监控启动任务、监控进度、采集日志、结果分析提取性能指标、生成评测报告等环节。每个环节都需要人工介入一名有经验的工程师完成一个完整评测任务平均需要2-5天。2.技术门槛高AI评测需跨越多个技术领域涵盖深度学习框架、并行训练、性能优化等。工程师需掌握PyTorch、TensorFlow、Megatron-LM、NeMo等框架理解数据并行、模型并行、流水线并行及ZeRO优化等并行训练策略熟悉混合精度、梯度累积、通信优化等性能调优方法同时需应对NVIDIA GPU、华为昇腾、海光DCU等不同硬件平台的软件栈差异。这些技术栈要求工程师具备跨领域综合能力培养周期长且人才稀缺。3.跨芯片适配难不同AI芯片的软件生态差异巨大一次评测任务要适配多种芯片工作量成倍增加。二、解决方案多智能体协作的自动化评测解放工程师生产力系统架构面向 AI 软硬件评测DeepLink团队推出多智能体协作系统(DeepEval-Agent)。系统采用三层架构UI 层提供统一入口Web UI / CLI / REST APIAgent 层负责智能决策与执行共享服务层LLM Service / Data Service / Cluster Layer提供基础能力。Agent 层采用多智能体协作架构将评测全流程分解为 5 个专职 AgentMain Agent作为入口与编排器Plan Agent、Scheduler Agent、Executor Agent、Report Agent 构成规划→调度→执行→分析四阶段流水线在无人介入的情况下完成从自然语言需求到评测报告的全流程闭环。各 Agent 输入输出规范Agent输入输出Main Agent自然语言 / 配置文件 / 评测方案StructuredRequest 用户意图的结构化表达评测意图、目标GPU、场景、任务类型、评测参数Plan AgentStructuredRequest SkillStore评测skills ResultStore历史评测结果TaskDAG 可执行的任务有向无环图每节点TaskNode自包含完整 Skill 配置Scheduler AgentTaskDAG ClusterRegistry集群注册信息SchedulerResult 完整评测全部结果的汇总DAG 标识TaskResult映射Executor AgentTaskNode Sandbox 实例运行沙箱TaskResult评测指标 硬件数据 重试历史Report AgentSchedulerResult BaselineStore性能基线库评测报告 ResultStore 写入 基线更新建议Agent 详解Main Agent负责三件事意图识别、安全校验、流程编排。意图识别将用户输入自然语言 / JSON 配置文件 / 评测方案文档通过约束生成做结构化解析产出统一的 StructuredRequest包含以下类别的字段评测意图intent——benchmark / comparison / rerun决定下游是否标记对比组目标芯片列表gpus——如 nvidia-h200、huawei-910c用于笛卡尔积展开 TaskDAG评测场景列表scenarios——如 language、vision_multimodal对应 Skill 检索的场景维度任务类型列表tasks——如 training、inference对应 Skill 检索的任务维度附加参数parameters——卡数、batch_size、模型规格等作为下游 TaskNode 的初始执行参数对比标志comparison——true 时按(scenario, task)分组标记对比组输入来源source——natural_language / config / plan下游 Agent 不感知具体路径原始输入raw_input——保留用户原文用于安全审计与问题排查输入安全层校验采用提示词注入检测规则 LLM 双重策略、资源配额检查。流程编排采用顺序编排逻辑将复杂性放在各子Agent内部不在编排层提高系统稳定性。输出为结构化指标字典供下游 Agent 直接消费json*节选* { intent: comparison, gpus: [nvidia-h200, huawei-910c], scenarios: [language], tasks: [training], parameters: { card_count: 8, model: gpt3-13b, batch_size: 4 }, comparison: true, source: natural_language, raw_input: 对比 H200 和 910C 在 GPT-3 13B 训练中的吞吐量... }Plan Agent对评测进行规划确定怎么做将StructuredRequest的评测请求转化为TaskDAG——一个自包含、可直接派发的任务有向无环图。Plan Agent 的核心机制有Skill渐进式加载、历史经验检索、TaskDAG 生成。SkillConfig包含镜像地址、命令模板、环境变量、卷挂载、资源需求、指标定义、安全等级等十余个字段平台沉淀的Skill数量随接入的芯片、场景、任务持续增长一次性全注入会稀释 token 预算和模型注意力。Plan Agent 采用渐进式加载元数据层始终加载——仅加载 {skill_id, gpu, scenario, task} 索引项配置层按需加载在 TaskDAG 展开过程中按 {gpu, scenario, task} 三元组从 SkillStore 精确取出对应的 SkillConfig 完整体注入对应的 TaskNode。历史经验检索是历史经验复用的关键Plan Agent 在生成 TaskNode 之前会检索 ResultStore把已有评测沉淀的成功参数和失败修复方案直接复用。检索分三级降级Skill-Indexed 精确检索精确匹配 {gpu, scenario, task} 三元组命中则直接套用上次的成功参数**语义混合检索**同 GPU 同场景跨任务结构化过滤后按key_findings向量相似度回退**跨芯片类比检索**同场景跨 GPU仅作初值上下界估计检索命中时还会跳过已知的在该参数空间已经验证过的失败路径后续的重试不会再退化到这一档。TaskDAG生成是Plan Agent的核心输出环节。按笛卡尔积gpu × scenario × task将StructuredRequest展开成TaskNode在展开之前先做静态预检Skill 存在 / 镜像安全等级通过 / 镜像仓库可达 / 数据集可访问任一失败立即终止。生成完成后做四项校验无环、依赖完整、单节点资源可行、对比组一致这样保证Executor收到的 TaskNode 自包含不依赖任何外部查询即可执行。完整的伪代码如下输入: StructuredRequest 输出: TaskDAG step 1. 初始化空节点列表 nodes [] step 2. 遍历笛卡尔积生成节点 for gpus 中的每个 gpu: for scenarios 中的每个 scenario: for tasks 中的每个 task: - config SkillStore.query(gpu, scenario, task) - history ResultStore.retrieve(gpu, scenario, task) // 可选 - parameters optimize(config, history) // 可选 - node TaskNode(gpu, scenario, task, parameters) - nodes.add(node) step 3. 设置依赖关系: for nodes 中的每个 node: if node 属于评测方案输入且用户声明了 depends_on: node.dependencies 用户声明的依赖列表 else: node.dependencies [] step 4. 标记对比组: if comparison true: 按 (scenario, task_type) 分组 同一组内的不同 gpu 节点标记为同一对比组 step 5. DAG 校验: - 无环检测: 检查 dependencies 是否构成有向无环图 - 完整性检查: 所有依赖的节点都存在 - 单节点资源可行性: 每个节点的资源需求是否满足 - 对比组一致性: 同一对比组内节点参数结构一致 step 6. 输出 TaskDAGScheduler Agent对整个任务进行实际集群和GPU卡的调度将各个子任务TaskNode派发到对应的集群后端管理 Executor 生命周期等待所有任务完成后汇聚结果。提供两个核心的功能硬件层抽象屏蔽集群异构性以及DAG 拓扑调度管理依赖与并发。异构GPU评测面对硬件层面两个正交的差异维度集群后端和芯片类型。系统用两个独立抽象分别屏蔽集群后端使用SandboxInterface抽象芯片类型使用DeviceAdapter抽象。SandboxInterface 把六个执行操作收敛到统一接口由 Scheduler 在动态预检后创建并传给 ExecutorExecutor 拿到 Sandbox 后只调统一接口不感知底层。class SandboxInterface(ABC): async def create(self, config: SandboxConfig) - str: ... async def execute(self, command: str, timeout: int) - ExecResult: ... async def upload_file(self, local: str, remote: str) - bool: ... async def download_file(self, remote: str, local: str) - bool: ... async def check_status(self) - SandboxStatus: ... async def destroy(self): ...DeviceAdapter 由 Executor 按芯片型号实例化封装该芯片的设备映射、状态查询、监控指标采集新增一款国产芯片只需实现一个 DeviceAdapter 子类Executor 核心链路不感知芯片差异。class DeviceAdapter(ABC): def get_mapping(self, device_ids: List[str]) - DeviceMapping: ... async def check_status(self, sandbox: SandboxInterface) - DeviceStatus: ... def get_monitor_command(self) - str: ... def parse_metrics(self, output: str) - List[HardwareMetrics]: ...解耦的硬件层抽象把 M 种集群 × N 种芯片的适配工作量从 N×M 降至 NM新增一款芯片或集群只实现一个子类所有 Agent 透明继承新能力各Agent始终在抽象层操作不必跟着底层重写设计。更重要的是两层抽象不仅屏蔽差异还把硬件运行状态结构化输出把解析逻辑下沉到 Adapter 内部Agent不必再直接解析原始日志而是在结构化字段上做决策DeviceStatus / HardwareMetrics等不必读懂硬件命令的输出格式。硬件信息从运行时副产品变成 Agent 的一等公民输入可以被Agent直接理解。Scheduler Agent按TaskDAG依赖使用Kahn 算法进行拓扑分层。同层任务无依赖可并行派发跨层顺序执行。并行度采用两层控制逻辑应用层引入max_concurrency 限制 Scheduler 同时在运行的TaskNode 的总数。这一层防止 Scheduler 自身被压垮——每个 in-flight task 占用事件循环 slot、网络连接、async 上下文不设上限会导致 LLM 调用超限、连接池耗尽。集群层即使应用层放行了集群层也可能让任务排队Slurm / K8s 由集群自身的调度器负责 GPU 分配和等待队列Docker 本地无外部调度器由 Scheduler 自己用 GPU 信号量管理。Executor AgentExecutor 是评测系统中不确定性最集中的 Agent所有结果不可预期的决策镜像能不能拉下来、容器能不能起、benchmark 会不会 OOM、参数对不对最终都汇集到这里。它的设计核心是把这种不确定性结构化、可控化用确定性流程框架打底在可能失控的环节引入 LLM 推理并用规则约束 LLM 不会脱缰。双模协同执行模式 推理模式Executor 是 DeepEval-Agent双模协同思想的具体落点。运行时由两种模式协同驱动-执行模式——确定性的结构化流程硬件检测、命令执行、指标采集、资源回收。全部走代码路径不调 LLM。-推理模式——非确定性的语义判断脚本生成、错误诊断、参数修正。由 LLM 结合结构化上下文完成。评测场景中大量决策缺乏可编程的规则——如何根据芯片型号生成正确的启动命令、如何解释一段模糊的错误日志、如何在 OOM 与吞吐量之间寻找最优参数组合。逐一写处理逻辑边际成本无法承受。Executor 的解法是执行模式提供充足的结构化上下文DeviceStatus、Skill 中的 task_command_hints、AttemptRecord 历史交给推理模式做语义级判断——脚本生成不再依赖模板穷举错误诊断不再依赖 if-else 规则。两种模式相互促进执行模式积累的 AttemptRecord 让推理越来越准推理模式的成功修复方案沉淀回 ResultStore让下次评测直接复用——形成正向飞轮避开硬编码脚本的僵化和纯 LLM 方案的不可控两个极端。引入七步执行流程在确定性框架里隔离不确定性七步流程的设计原则是把不确定性收敛到 Step 4 一个环节。其余六步全是确定性代码路径能用模板 / 正则 / 标准命令完成的事情绝不调 LLM这是控制 token 成本与可重复性的根本Step模式关键技术点1 创建环境执行模式命令模板渲染 DeviceAdapter 注入设备映射失败转 Evaluator 推理模式2 设备检查执行模式DeviceAdapter.check_status → 结构化 DeviceStatus硬件不可恢复立即终止3 准备脚本模板优先 → LLM 兜底task_command充分时纯渲染只有 hints 时才走 LLM脚本必经安全校验shebang / 危险命令拦截 / 输出路径约定4 执行 benchmark执行 ↔ 推理唯一重试入口失败 → Evaluator → adjustments → 回 Step 4AttemptRecord 实时沉淀5 指标采集执行模式MetricDef 正则提取应用级指标DeviceAdapter.parse_metrics 解析硬件级指标warmup_steps 排除前 N 步噪声6 结果初步验证执行模式完整性 / 合理性 / 稳定性三检产生 warning 不阻断7 资源清理执行模式finally 语义无论成功 / 失败都sandbox.destroy()Report Agent末端职责结果验证、横向对比、基线管理、报告生成。结果可信度三维验证维度触发条件处理基线对比偏差 5%–20%warning基线对比偏差 20%anomaly 标注统计异常历史 ≥3 次时偏离均值 3σ标注统计异常跨任务一致性对比组内一成功一失败 / 同指标差 1 个数量级显著标注**横向对比**基于 comparison_groups 进行多维分析绝对性能吞吐量、延迟、资源效率性能/显存、性能/功耗、稳定性变异系数、长时衰减率**基线管理半自动**首次评测自动建立基线连续 3 次稳定偏离当前基线时Report Agent 提出建议更新基线由用户决定是否采纳Human-In-Loop因为基线更新有业务含义自动更新可能掩盖问题。**报告生成**按照模板对结构化指标进行渲染。设计要点多维可扩展的评测专用引擎DeepEval-Agent t 的核心是一套专为评测场景设计、具备多维扩展能力的协作引擎。评测流程的关键基础设施是引擎的原生能力而非在通用智能体上通过提示词和外部配置拼装出来的。引擎的扩展性体现在四个维度芯片扩展新增芯片只需添加对应适配核心链路零改动芯片差异与集群差异是正交的两个维度。系统通过DeviceAdapter抽象基类封装每款芯片的特定知识。DeviceMapping统一描述设备后端的挂载方式。check_status封装芯片特定的状态查询命令返回标准化的DeviceStatus设备数量、驱动版本、显存总量/可用量、健康状态。get_monitor_command和parse_metrics负责硬件级指标采集功耗、温度、显存时间线、计算利用率采样在独立后台进程中进行对 benchmark 主进程的性能影响可忽略。集群扩展新增集群类型只需对接统一执行接口不同配置各自独立集群后端的差异通过SandboxInterface抽象基类封装。六个抽象接口覆盖一个执行环境的完整生命周期create—— 创建执行环境返回环境标识具体形态由集群类型决定execute—— 在已创建的环境中执行命令并捕获 stdout / stderr / exit_codeupload_file/download_file—— 文件双向传输脚本、数据集、结果文件check_status—— 探测环境运行状态运行中 / 已退出 / 故障destroy—— 释放执行环境资源Scheduler Agent 通过工厂方法create_sandbox(cluster_type)获取对应实例上层的 Executor 只调用接口方法不感知底层是哪种集群。场景扩展新场景或新任务通过 Skill 文件接入芯片方按标准格式发布即可即插即用评测场景的差异体现在镜像、启动命令、资源需求和指标定义上。系统将这些差异封装为SkillConfig数据结构可进行灵活扩展。dataclass class SkillConfig: skill_id: str # {gpu}_{scenario}_{task} image_name: str # Docker 镜像地址 start_command: str # 容器启动命令模板 task_command: str # 评测执行命令模板 environment: Dict[str, str] # 环境变量 volumes: List[str] # 卷挂载列表 start_command_hints: str # LLM 引导提示 task_command_hints: str # LLM 引导提示 requirements: Requirements # 资源需求min_gpu_count, exclusive_gpu, requires_rdma metrics_definition: List[MetricDef] # 指标定义{name, unit, extract_pattern} estimated_duration: int # 预估执行时长 image_security_level: str # 镜像安全等级输入扩展支持自然语言、配置文件、评测方案多种接入方式三种输入形式自然语言、JSON 配置文件、评测方案文档最终都归一化为StructuredRequest自然语言路径通过 LLM 约束生成完成解析提示词中注入 SkillStore 中的可用芯片/场景/任务列表LLM 在有限选项中匹配缺失字段触发澄清对话。配置文件和评测方案路径直接做 Schema 校验和反序列化。下游所有 AgentPlan → Scheduler → Report只与StructuredRequest交互新增输入形式只需增加一个解析器。这四个维度的扩展能力共同构成了一套完整的评测基础设施——芯片方、集群方、场景方、评测方各自独立接入引擎本身不需要为任何接入方做定制改造。这才是评测引擎的结构性优势。Reflexion经验闭环DeepEval-Agent 把每次评测的失败诊断与成功修复方案沉淀回 ResultStore下次评测时由 Plan Agent 直接复用。这不是AI 会学习的概念口号而是通过数据结构落到工程实现闭环的写入侧由 Executor 与 Report Agent 共同完成Executor 把每次尝试的命令、参数、错误、修复方案沉淀为 AttemptRecord 写入 local_memoryReport Agent 在评测结束时从 local_memory 中提炼成功参数和失败修复模式写入 ResultStore 的 key_findings 字段按 {gpu, scenario, task} 三元组建立关系索引并对自然语言摘要建立向量索引。闭环的读取侧由 Plan Agent 完成按三级降级Skill-Indexed 精确检索 → 语义混合检索 → 跨芯片类比检索取经验把命中的成功参数与失败避免清单带入新一轮 TaskDAG 的初始配置。正向飞轮的工程意义在于每次成功修复都让系统下一次更聪明一点而不是埋在工程师笔记里——把经验从隐性知识转成结构化资产。多层防线保障评测公正可信多芯片横向对比的核心前提是评测公正可信。运行环境与执行过程都不能影响评测结果的公允性。DeepEval-Agent的安全设计遵循两条原则纵深防御和全链路审计。纵深防御四个层次按 Agent 责任分工每层独立拦截一类威胁输入安全层Main Agent提示词注入检测规则匹配 LLM 辅助判断双重策略、资源配额检查GPU 卡数、并发任务、预估时长合理性在评测逻辑执行前就拦截非法或恶意输入。规划安全层Plan Agent镜像白名单校验、镜像安全等级unscanned / passed / warning / rejected、Skill 配置合法性验证。镜像未通过审计则不进入执行链。镜像安全等级在 SkillStore 中持久化定期复检与等级重评执行安全层Executor Agent双重隔离——Docker 命令安全校验拦截--privileged、--cap-add、shell 注入 沙箱物理隔离容器网络受限、文件系统只读、进程权限最小化。即使评测镜像本身存在问题也无法影响宿主机或其他任务。防作弊安全层持续运行评测结果的公信力来自可证伪性。该层目前处于技术规划阶段技术思路主要围绕四个方向展开输入随机化让 benchmark 不可被作弊代码稳定识别跨框架交叉验证让单一实现的伪造无法跨多个框架保持一致运行时行为监控限制容器内对系统接口的异常写入镜像供应链审计比对厂商声明的版本与实际安装。具体策略与实施细节随场景持续打磨。全链路审计贯穿所有层。每个 Agent 的每一步操作命令、参数、错误、修正动作都被结构化日志记录链路追踪以task_id串联从 Main 到 Report 的完整路径整个评测过程可中断、可恢复、可回溯。任何一步的异常都被审计日志捕获用户可随时查看完整执行链——这同时是评测结果可独立审查的基础。目前该方向处于研究阶段团队已开始相关布局。与传统方案对比DeepEval-Agent将 LLM 驱动的智能体引入评测流程具备感知、推理、决策和工具调用能力。DeepEval-Agent 能自动处理多模态输入、动态生成与修复脚本实现跨芯片环境的自我诊断、泛化适配闭环降低人工迁移成本。当然DeepEval-Agent的主要短板仍然是LLM幻觉带来的可重复性风险和额外的推理成本。但通过多次验证锁定结果、缓存复用减少调用、轻量模型路由控制开销将这些短板控制在工程可接受范围内在保持灵活性的同时逼近脚本级的效率与确定性。维度自动化脚本评测DeepEval-Agent跨芯片适配多芯片多场景多任务意味着指数级适配脚本每个新组合都需人工编写和验证Skill 机制统一抽象新芯片接入等同于新增配置不改核心逻辑错误处理对非预期输出和环境差异高度敏感脚本失效需大量人力排查修复无法自愈Executor agent基于LLM 驱动进行自动诊断根因并智能生成修正策略输入灵活性仅支持预定义的配置格式和参数组合同时支持自然语言、配置文件、评测方案三种输入方式自动解析意图并补全缺失信息确定性同版本脚本输出恒定可重复性强通过多次验证锁定结果、缓存复用减少调用将不确定性控制在工程可接受范围执行效率几乎无额外推理开销模板优先、LLM 兜底策略降低调用频次轻量模型路由控制成本离线批处理降低时延三、DeepEval-Skills开源评测技能库DeepEval-Skills是面向AI软硬件评测的开源技能库遵循Agent Skills标准兼容Claude Code等多款主流智能体。技能库提供两种便捷部署使用方式面向不同开发场景主流Agent框架集成Skills将Skills安装到主流Agent框架Claude Code、Codex、OpenClaw、Hermes Agent等输入自然语言即可发起评测任务。详细可参考Quick Starthttps://github.com/DeepLink-org/DeepEval-Skills/blob/main/README.md示例Hermes Agent集成技能库后输入自然语言即可评测算子DeepEval即将发布 开箱即用DeepEval-Agent已内置本仓库的全部 Skills并针对评测场景进行了深度定制通过硬件抽象层直接获取芯片和集群的底层信息在诊断修复和资源调度时跳过 LLM 推理链同时内置错误自愈经验和安全合规策略这些能力不依赖 LLM 推理比使用提示词、外部配置或工具调用的方式更稳定高效可以降低评测时延和成本。目前除了主流开源社区Github外DeepLink已同步入驻 AtomGit 社区构建多维开源社区矩阵。已支持评测场景快速开始使用skills CLI 安装*# 克隆本仓库到本地* git clone https://github.com/DeepLink-org/DeepEval-Skills.git *# 查看本仓库中可用的 skills* npx skills add ./DeepEval-Skills/skills --list *# 批量安装 skill 到当前项目* npx skills add ./DeepEval-Skills/skills/NVIDIA -s * # 安装指定 skill 到当前项目 npx skills add ./DeepEval-Skills/skills/NVIDIA/nlp/nvidia-nlp-inference # 仅安装到指定智能体 npx skills add ./DeepEval-Skills/skills/NVIDIA -s * --agent claude-code *# 在Claude Code中使用* 我要评测NVIDIA上GEMM算子的性能 [Skill自动加载] nvidia-nlp-operator [开始自动化评测流程]四、应用场景AI 芯片厂商加速性能验证与市场交付支持新芯片发布前的自动化对比评测如 NVIDIA vs 国产芯片并可无缝集成至 CI/CD 流程中。在保障评测公允性的同时能减少评测工程师 70% 以上的工作量。AI 创业公司与企业用户优化模型选型与部署成本在海量硬件与模型组合中快速找出最优的性价比方案同时支持自动化性能回归测试大幅降低模型在异构算力上的部署与迁移门槛。五、开源与共建开源内容DeepEval-Skills评测技能库已开源GitHub:https://github.com/DeepLink-org/DeepEval-SkillsAtomgithttps://atomgit.com/DeepLink/DeepEval-SkillsDeepLink 官网https://deeplink.org.cn共建邀请欢迎社区贡献新的评测技能贡献新的芯片支持贡献新的评测场景改进现有Skill的性能和准确性六、未来展望DeepEval-Skills 评测技能库的开源是DeepLink 在 AI 全环节软硬件验证方向的关键进展。未来我们将持续扩充技能库覆盖范围新增强化学习、推荐系统等评测场景拓展更多国产 AI 芯片适配持续优化智能体推理性能打通与 AI 全环节软硬件验证平台、司南体系的对接分阶段上线云端评测服务提供低门槛的在线评测入口。长期而言DeepLink 将联合产业链伙伴共建统一、开放的 AI 软硬件评测标准与基准数据库推动行业评测流程自动化、评测指标规范化。未来平台一方面服务于芯片厂商与 AI 企业的性能验证与模型选型需求另一方面也将成为国产异构算力生态标准化的重要基础设施助力整个 AI 产业降本增效、健康发展。结语在AI大模型时代评测工作不应成为瓶颈。DeepEval-Agent通过多智能体协作实现了AI软硬件评测的全流程自动化让工程师从繁琐的脚本编写中解放出来专注于更有价值的工作。我们开源DeepEval-Skills希望与社区共建AI评测的开放生态。欢迎在我们的GitHub与AtomGit社区贡献您的评测技能一起推动AI基础设施的进步。联系方式GitHub Issues: 欢迎提交问题和建议邮箱deeplinkpjlab.org.cn