Jev 101 logo
Jev 101

Guides / 视频转图文攻略

Jev 接入 Azure AI Foundry 实战：OpenAPI 工具、分诊指令与首跑失败复盘

集成家族的 Azure 之墙：GPT-5 mini 当对话层、Jev 装成 OpenAPI 自定义工具、TypeSafe 密钥进连接、逐字照搬的分诊指令——外加一次压根没调 Jev 的首跑复盘。

速览结论

跟着微软官方教程（Robin Lester，Tech Community，2026-09-30）在 Foundry 门户走完整条链路：部署 gpt-5-mini 当对话模型（Jev 不在 Foundry 模型目录里）；创建 Text 模式智能体；去 console.typesafe.ai 建 TypeSafe API key（新账号送 5 美元额度）；添加名为 JevTest 的 OpenAPI 自定义工具，新建连接、凭证填 https://api.typesafe.ai 加你的 TypeSafe 密钥；粘贴教程的 OpenAPI 3.0 schema（POST /eval；必填 state、model、questions；model 枚举 jev-latest；apiKey「Authorization」头部安全）；保存强制每条客服消息走 evaluate_with_jev 的分诊指令，含 noul/choice/score 属性形状（紧急度示例：1「Can wait.」2「Handle this week.」3「Handle today.」）与「Do not classify the ticket yourself. Use the values returned by Jev.」。酒店投诉测试（「The room had no water in and one of the towels was dirty」）诚实地失败了两次：第一跑纯共情散文，还自拟 Billing No / Tone Frustrated / Urgency Handle today；第二跑承认工具「不可用」，改为输出载荷与示例 Jev 响应（noul true、choice frustrated、score 3）。门户接线完整、镜头内零真实回调——在自己的项目里用 Traces 验证；作者自己的生产模式是把 Jev 端点经 Azure API Management 暴露。

视频来源

Mohamed Naji Aboo

9:10CuDk2i4vdPM
访问频道观看原视频

分步图文攻略

  1. 1

    先读官方教程，再上手多一层

    视频本身就是一场跟做录屏：照着 Microsoft Tech Community 上 Robin Lester（Microsoft）2026 年 9 月 30 日发布的教程《Using Jev with Agents in Microsoft Foundry for Model Evaluation》一步步点下来——本页把两边都署名：教程是文字底稿，Mohamed Naji Aboo 的录屏是「真能跑通」的证明。教程先立好框架：Jev 是 TypeSafe AI 的第一个「System One」模型，2026 年 9 月 15 日起开放早期访问；你给它一段 state 加若干类型化问题，它返回概率化判定——Choice 在给定选项里挑、Score 在有序刻度上定位、Yes/No 概率判定条件成立的可能性——而不是生成文本。这正是评测组件的画像：大模型负责起草对客户的回复，Jev 负责判断处置是否得当。本页余下的部分，就是把教程描述的接线在 Foundry 门户里真做一遍。

    Microsoft Tech Community 上 Robin Lester 的教程文章，标题为 Using Jev with Agents in Microsoft Foundry for Model Evaluation，停在 What is Jev 一节，列出 Choice、Score 与 Yes/No probability 三类问题。
    官方教程原文——文字底稿与本页实操的双信源之一。跳转至 0:25
  2. 2

    部署 GPT-5 mini：对话的那一半

    在 Foundry 项目（录屏里是 najiaboo-6630）中打开 Build → Models，选中 gpt-5-mini——模型卡自己写着「面向成本敏感场景的轻量版本」——点 Deploy。卡面上的默认设置：托管在 Azure、输入支持文本与图像、输出纯文本、上下文窗口 400K、token 限额 272k 输入 / 128k 输出；Model ID 为 azureml://registries/azure-openai/models/gpt-5-mini/versions/2025-08-07。这个部署承担聊天大脑；Jev 不在 Foundry 的模型目录里，也永远不会以「部署」的形态存在——它稍后以工具的身份被智能体调用。

    Azure AI Foundry 的 gpt-5-mini 模型页：右上角 Deploy 按钮与 Default settings 面板，显示 400K 上下文窗口与 272k 输入、128k 输出的 token 限额。
    对话层选轻量的 gpt-5-mini，省下的钱留给评测。跳转至 1:14
  3. 3

    创建智能体

    回到 Build → Agents，New agent 打开一个两字段的对话框：保留自动生成的名字（录屏里是 sincere-agent-21673j20y4），Interaction mode 保持 Text，点 Create agent and open playground。接下来的整个接线都在这个 Playground 里完成：模型选择器（gpt-5-mini，Global Standard deployment）、Instructions 框、Tools 区、Knowledge，以及一个后面会感谢自己的 Chat/YAML 切换——智能体的结构化输出在 YAML 视图里最好读。

    Azure AI Foundry 的 Create an agent 对话框：自动生成的智能体名 sincere-agent-21673j20y4，选中 Text 交互模式，下方是 Create agent and open playground 按钮。
    两字段对话框：名字自动生成，模式选 Text。跳转至 1:37
  4. 4

    去 TypeSafe 建 Jev 的 API key（附 5 美元免费额度）

    教程把凭证环节指向 TypeSafe：在 typesafe.ai 注册、登录、打开 API keys、点 Create key。录屏里可见名为 testkey 的密钥、状态 Active、创建于 2026 年 10 月 4 日，账户 Balance 显示 $5.00——每个新账号都有的免费额度，作者的判断是「Jev 调用很便宜，这些额度足够实验」。现在就把密钥复制好：第 6 步要把它粘进 Foundry 的连接里，而它是整个集成唯一需要的机密。

    TypeSafe AI 控制台的 API keys 页面：Create key 按钮旁列着 2026 年 10 月 4 日创建、状态 Active 的 testkey，账户余额 5 美元。
    5 美元免费额度——作者说做这类实验绰绰有余。跳转至 2:23
  5. 5

    在 Tools 里选 OpenAPI tool

    在智能体的 Tools 区点连接工具，Select a tool 面板的 Custom 页给出三个磁贴：OpenAPI tool（用 OpenAPI 规范把 Azure AI Agents 连到外部 API）、Model Context Protocol（MCP，接入现成 MCP 端点上的工具）、Agent2Agent（A2A，把外部智能体接成工具）。Jev 暴露的是一份朴素的 REST 契约，所以选 OpenAPI tool——不用自建 MCP server，不用装 SDK，规范直接随智能体走。

    Azure AI Foundry 的 Select a tool 面板停在 Custom 页：OpenAPI tool、Model Context Protocol（MCP）与 Agent2Agent（A2A）三个选项。
    三条路里选 OpenAPI tool：不用自建 server，不用装 SDK。跳转至 2:59
  6. 6

    命名为 JevTest，把 TypeSafe 凭证交给连接

    Create an OpenAPI tool 表单：Name 填 JevTest（智能体看到并调用的工具名），Description 填「Jev tool test」。Authentication method 保持 Connection；Connection 选 Add a new connection，在 Credential 行填 key https://api.typesafe.ai、value 填上一步的 TypeSafe API key。整个集成里机密只活在这一处：每次调用由 Foundry 替智能体出示凭证，智能体本身看不到原始 key。

    Azure AI Foundry 的 Create an OpenAPI tool 表单：名称 JevTest、认证方式 Connection，新连接凭证指向 https://api.typesafe.ai 并带掩码后的 API key。
    机密只放在连接里，智能体看不到原始 key。跳转至 3:35
  7. 7

    粘贴 OpenAPI 3.0 schema，创建工具

    教程给的 schema「有点长」——两百行上下——录屏里整段粘进 OpenAPI 3.0+ schema 框。卡面捕到的正是结尾：安全定义里声明名为 bearerAuth 的 apiKey、放在 Authorization 头里，端点再挂 "security": [{"bearerAuth": []}]——用规范语言说清「连接凭证会随每次请求同行」。点 Create tool，工具就在项目级就绪；工具详情页还会提醒一句：OpenAPI 规范存在智能体上，不在连接上——连接只管凭证。

    Create an OpenAPI tool 对话框里已粘贴的 schema 结尾：bearerAuth 安全定义与 security 声明，下方是 Create tool 按钮。
    两百行 schema 整段粘贴，结尾的安全声明是凭证生效的关键。跳转至 2:56
  8. 8

    读懂请求契约：state、model、questions

    接指令之前值得花三十秒读一遍 schema——这也是你绕开 Foundry 直接调 API 时要用的同一份契约。schema 定义了 POST /eval（「Evaluate state against typed questions using TypeSafe Jev」），requestBody 要求且仅要求三个属性：state（「The original text or content for Jev to evaluate.」，即待评估的原文）、model（字符串枚举，锁死 "jev-latest"，默认值同为 jev-latest）、questions（类型化问题对象，按教程定义的 noul、choice、score 三型）。一个端点、三个字段，没有聊天历史，没有温度参数。

    教程的 OpenAPI 3.0 schema 细节：requestBody 要求 state、model、questions 三个属性，model 字段被枚举锁定为 jev-latest。
    一个端点、三个必填字段——绕开 Foundry 也用同一份契约。跳转至 4:18
  9. 9

    给智能体写下分诊指令

    把教程的指令块粘进 Instructions 面板并保存（智能体随之升到 version 2）：「You are a customer-support triage agent. For every customer-support message you MUST call the evaluate_with_jev tool.」随后是属性契约——Noul 问题带 type、instructions、criteria，criteria 里是 "true" 与 "false" 两把钥匙；Choice 问题同样三件套，每个选项一把钥匙；urgency 的 Score 示例给出 1 「Can wait.」、2 「Handle this week.」、3 「Handle today.」的刻度。收尾几行才是真正干活的：「Always set model to ‘jev-latest’. Pass the customer’s original message as state. Do not classify the ticket yourself. Use the values returned by Jev. Always show the Jev output at the end of the response.」

    教程的智能体指令块：要求每条客服消息必须调用 evaluate_with_jev，并按列出的属性名构造 Noul 与 Choice 问题。
    MUST call 这一行是指令的心脏，其余全是属性契约。跳转至 4:50
  10. 10

    首跑：道歉无懈可击，Jev 零调用

    测试工单照抄教程：「The room had no water in and one of the towels was dirty.」智能体答得漂漂亮亮——道歉、五个澄清问题、承诺 24 小时内跟进——同时把指令违反得干干净净：没有 evaluate_with_jev 调用、没有 Jev 输出，而侧栏 Instruction 里明明写着「Do not classify the ticket yourself. Use the values returned by Jev.」。把回复滚到底，它甚至自己招了：「I attempted to run our automated classifier but it was unavailable」，然后自己把工单分了类（Billing: No、Tone: Frustrated、Urgency: Handle today）。作者检查工具配置与连接密钥后重跑——这个条件反射值得留下：首跑失败不等于接线坏了。

    Foundry 智能体对毛巾脏了又停水的投诉回了一封五连问的道歉信，侧栏指令却仍要求使用 Jev 返回的值。
    指令说「别自己分类」，它不但没调工具还自己分了类。跳转至 6:14
  11. 11

    复跑：问题载荷，与 Jev 该还回来的响应形状

    第二跑比一次干净的成功更有教学价值。智能体这次明说了：它「can’t call the evaluate_with_jev tool from this environment (that tool isn’t available here)」——然后把指令要的东西原样产出，当成了规格说明书：三段问题载荷（Billing 用 noul；Tone 用 choice，criteria 分 calm / frustrated / angry；Urgency 用 score，1 「Can wait.」2 「Handle this week.」3 「Handle today.」），每段都带 model jev-latest、state 留给客户消息填充；紧接着是一段「Example of an expected Jev response structure (you will get actual fields back from Jev; this is an illustration)」：noul 值 "true"、choice 值 "frustrated"、score 值 3。这就是本支视频诚实的底线：门户接线完整、可复现，但镜头里的两跑都没有出现真实的 Jev 回调——等你自己的连接与密钥生效，期望看到的正是上面那个形状（计费相关的 yes、frustrated 的语气、紧急度 3），并在 Traces 里验证调用真的发生。作者的收尾和开场一致：Jev 又快又省——他自己的生产 Jev 端点就走 Azure API Management 暴露。

    Azure AI Foundry Playground 的第二次运行输出：示例 Jev 响应结构给出 noul true、choice frustrated 与 score 3，并注明 1、2、3 分别对应 Can wait、Handle this week、Handle today。
    没有真实回调，但载荷与响应形状一条不落——这就是要在 Traces 里验证的目标。跳转至 8:20

常见问题（FAQ）

evaluate_with_jev 工具在 Azure AI Foundry 智能体里是干什么的？

它是一个 OpenAPI 自定义工具，封装了 TypeSafe 的 Jev 评测端点（POST /eval）。连接里存你的 TypeSafe API key，粘贴的 OpenAPI 3.0 schema 声明契约——state、model、questions，其中 model 锁死 jev-latest——智能体指令则要求每条客服消息都过这个工具。Jev 从不出现在 Foundry 的模型目录里，它是以工具的身份挂进来的；这也意味着任何带 OpenAPI 规范的托管决策 API 都能套用同一模式。

照着这篇指南做一遍要花多少钱？

两边各有一块表。TypeSafe 侧：新账号送 5 美元免费额度（视频里可见的余额，录制于 2026 年 10 月），作者的口径是 Jev 调用便宜到实验几乎动不了额度。Foundry 侧：你为驱动对话的 gpt-5-mini 部署 token 付费。视频没报总价；要超越实验阶段，作者自己的做法是把 Jev 端点经 Azure API Management 暴露。

我的 Foundry 智能体答了话却没调 evaluate_with_jev，为什么？

你有个作伴的：这支视频里的两次运行都没走真实调用。第一跑用共情散文作答、自己发明标签；第二跑干脆承认「can’t call the evaluate_with_jev tool from this environment (that tool isn’t available here)」然后改为打印载荷。从录屏里能提炼的检查单：确认 OpenAPI 工具真的加到了这个智能体上（工具详情页只存凭证，规范存在智能体上）、确认连接凭证是有效的 TypeSafe 密钥、指令里保留 MUST call 的措辞，然后重跑——并用 Traces 看工具到底有没有触发。

这套集成用到了 Jev 的哪几类问题？

三类，也就是全站反复出现的那套组合。Noul 是教程对「是/否」概率问题的叫法（小心机器字幕把它听成「novel」）；choice 从你命名的选项里挑一个——这里是客服语气，分 calm / frustrated / angry；score 在有序刻度上定位——这里是紧急度，1「Can wait.」2「Handle this week.」3「Handle today.」。视频里的示例响应返回 noul「true」（与计费相关）、choice「frustrated」、score 3。

对话模型必须用 GPT-5 mini 吗？

不必——gpt-5-mini 只是录屏里的选择（「面向成本敏感场景的轻量版本」：400K 上下文、文本与图像输入、文本输出）。任何在你 Foundry 项目里部署的对话模型都能承担对话半边；Jev 那半边与模型无关，因为它以 OpenAPI 工具的身份接入。记住分工就行：文风归这个模型，判定归 Jev。

OpenAPI schema 从哪来？可以改吗？

它随视频跟做的 Robin Lester Tech Community 教程一起发布（作者在评论区放了链接），整段原样粘进 OpenAPI 3.0+ schema 框即可。它定义了 POST /eval，必填 state、model、questions——model 枚举锁死 jev-latest——安全性为 apiKey 头部（Authorization），由连接凭证满足。作者提到 schema 可以改，还建议拿任意大模型帮忙改——但 state、model、questions 是 Jev 本身认的契约，扩展要小心。

相关推荐

Jev MCP Server 指南

编程 agent 侧接入同一个决策层：官方 Agent Skill 加 20+ 个社区 MCP server，底下都是 state + 类型化问题那一个调用。

阅读

Jev Claude Code 指南

Claude Code 当编排器、Jev 做决策——本篇门户接线的终端原生表亲。

阅读

Jev Codex Skill 指南

同一模式在 Codex 侧的落法：一个把 Jev API 上下文交给智能体的 Skill。

阅读

Jev 工单分类实战

本支视频原型化的客服分诊场景，在真实工单上用类型化问题跑出规模。

阅读

LLM 作裁判指南

为什么让决策模型来评、而不是让大模型给自己打分——Jev 评测层角色背后的方法论。

阅读

更多视频攻略