标签：模型配置

前沿哨所

• Jev 客服实测：5 种语言跑通，附 Python 接入代码

  Jev 最近很受关注，但它和常见聊天模型的工作方式不一样。它不负责写一段客服回复，而是把一条非结构化消息转换成程序可以直接使用的判断：语言、分类、分数、概率。

  我用同一套请求测试了中文、英文、德语、法语和西班牙语客服消息。五条请求全部返回成功，耗时 804～900 ms。下面记录测试方法、结果和一个可以直接改造的 Python 接入版本。

  Jev 适合做哪一层

  普通聊天模型适合生成回复。Jev 更像一个判断组件：输入一条工单，输出固定选项和概率。

  这次请求同时问了四个问题：

  • 消息是什么语言；
  • 应该分给哪个客服部门；
  • 紧急程度是多少；
  • 是否需要人工复核。

  这种拆法比让模型一次性“理解工单并写出完整结论”更容易接进业务代码。分类结果可以路由，分数可以做阈值判断，人工复核概率可以决定是否进入人工队列。

  官方文档把这三种问题叫作 Choice、Score 和 Noul。Choice 选一个固定选项，Score 在一组等级上打分，Noul 返回 0 到 1 之间的概率。三种问题可以放在同一次请求里。官方 Quick start

  这次测试测了什么

  样例很小，目标是验证接口和基本的跨语言理解，不是做模型排行榜。每条消息都带有明确的客服意图，结果也用固定字段输出。

  语言	客服分流结果	紧急程度	人工复核概率	耗时	输入 / 输出 tokens
  中文	shipping	1.32	0.49	900 ms	602 / 151
  English	billing_refund	0.67	0.50	874 ms	586 / 152
  Deutsch	technical	2.00	0.48	858 ms	589 / 152
  Français	order_account	0.01	0.42	875 ms	586 / 152
  Español	technical	1.46	0.37	804 ms	596 / 151

  五条消息都被识别成了对应语言。中文订单延迟被分到 shipping，英文重复扣款被分到 billing_refund，德语登录失败和西班牙语上传崩溃都进入 technical。这些结果符合样例的业务意图，但样本量太小，不能推导出准确率或稳定性结论。

  返回的模型版本是 jev-1.13.0。我们请求的是 jev-latest，服务端把它解析成了当前版本。一次请求的输入和输出合计约 740 tokens，五次请求合计 3717 tokens。

  

  图 1：API key 页面。账号、创建者和 secret 字段已经替换为演示值，只保留 Active 状态和页面结构。

  

  图 2：本次五条请求的用量记录。控制台显示 5 次请求、3717 tokens，Spend 约为 $0.0001。价格和额度以你的控制台为准。

  最小 Python 请求

  这个版本只用 Python 标准库，不依赖 SDK。它读取 .env 中的 TYPESAFE_API_KEY，把 key 放在服务端环境里，不写进代码，也不放到浏览器。

  python3 -m venv .venv
  .venv/bin/python -m pip install --upgrade pip
  

  .env 只需要这一行：

  TYPESAFE_API_KEY=your_typesafe_key_here
  

  真实代码可以保持很小：

  import json
  import os
  from urllib.request import Request, urlopen
  
  payload = {
      "model": "jev-latest",
      "state": "我的订单已经付款三天了，但还没有发货，请尽快帮我查一下。",
      "questions": {
          "language": {
              "type": "choice",
              "instructions": "Which language is the customer message written in?",
              "criteria": {
                  "chinese": "Chinese",
                  "english": "English",
                  "german": "German",
                  "french": "French",
                  "spanish": "Spanish",
                  "other": "Another language or unclear",
              },
          },
          "department": {
              "type": "choice",
              "instructions": "Which customer-service team should handle this request?",
              "criteria": {
                  "billing_refund": "Payment, duplicate charge, invoice, or refund issue",
                  "technical": "Bug, login failure, crash, or integration problem",
                  "order_account": "Order change, delivery address, or account information",
                  "shipping": "Shipment tracking, delivery delay, or logistics issue",
                  "other": "Anything else",
              },
          },
          "urgency": {
              "type": "score",
              "instructions": "How urgent does the customer sound?",
              "criteria": [
                  "Routine; no time pressure",
                  "Needs attention soon",
                  "Urgent; asks for immediate help",
              ],
          },
          "needs_human_review": {
              "type": "noul",
              "instructions": "Would a human agent need to review this request before an automated reply?",
          },
      },
  }
  
  request = Request(
      "https://api.typesafe.ai/v1/systemone",
      data=json.dumps(payload, ensure_ascii=False).encode("utf-8"),
      headers={
          "Authorization": "Bearer " + os.environ["TYPESAFE_API_KEY"],
          "Content-Type": "application/json",
      },
      method="POST",
  )
  
  with urlopen(request, timeout=15) as response:
      result = json.loads(response.read().decode("utf-8"))
  
  print(result["answers"]["department"]["choice"])
  print(result["answers"]["urgency"]["score"])
  

  官方接口是 POST https://api.typesafe.ai/v1/systemone，认证头是 Authorization: Bearer <API_KEY>。不要把 OpenRouter、Vercel AI Gateway 或其他服务的 key 填到这个地址上。不同渠道的 endpoint、模型名和认证方式不一定相同。

  把测试脚本接进自己的项目

  这次测试用的脚本还做了几件适合保留在项目里的小事：

  1. 把样例消息集中在 SAMPLES 表里，增加语言时不用改请求逻辑。
  2. 把四个判断放在一个请求中，减少重复的网络往返。
  3. 401 时立即停止，不用拿同一个错误 key 重试五次。
  4. 输出模型版本、延迟和 tokens，便于后续比较版本变化。
  5. dry-run 模式只检查 payload，不消耗 API 用量。

  项目里的运行命令是：

  ./.venv/bin/python run_jev_customer_test.py --dry-run
  ./.venv/bin/python run_jev_customer_test.py
  

  如果返回 401，先检查 key 是否来自 TypeSafe 控制台、是否复制了完整 secret，以及 .env 里是否混入了引号或空格。401 是认证失败，不是客服问题格式错误。

  这次实测后的判断

  Jev 值得放在客服系统的“判断层”里试用。它能把多语言消息转成稳定的选项和分数，接入路由、优先级和人工复核都比较直接。

  它不能替代客服回复生成，也不能用五条样例证明生产准确率。正式接入前，还需要用真实历史工单做一批标注集，观察每种语言、每个部门和每个阈值下的误分情况。对于低置信度结果，保留人工复核入口会更稳妥。

  相关资料：TypeSafe Jev 官方文档、Jev 发布说明。

  刚刚

• 从“夯”到“拉完了”：社区锐评美国AI订阅方案，区域差价与降智乱象引热议

  Linux.do论坛一则帖子以段位制对美国主流AI模型付费方案进行了社区锐评，将各订阅档位按性价比分为五等。“夯”档为Claude Code稳定订阅（灰度Opus 5.2）与GPT 20x无降智无限流方案；“顶级”档包括无灰度的Claude Code稳定订阅、GPT 292美元方案，以及附带Cursor Ultra的99美元Grok Heavy；“人上人”档收录印度区700卢比的SuperGrok和6元人民币使用18个月的Gemini Jio优惠；“NPC”档为300美元原价的Grok Heavy及原价Cursor、Devin；“拉完了”档则涵盖降智限流的GPT、秒封不退款的Claude Code账号、Gemini正价订阅以及Copilot Max和Perplexity Max。该帖折射出当前AI订阅市场的几个核心痛点：同一模型因灰度测试和区域定价差异产生巨大价格落差，印度区Gemini优惠与美区正价相差数十倍；部分厂商存在对订阅用户降智、限流的争议做法；高定价方案的实际价值备受质疑；账号封禁不退款问题也加剧了用户对平台的不信任。

  事件分析

  该帖表面是段子式排位，实为AI订阅市场结构性矛盾的缩影。其一，区域差别定价已成行业惯例，印度区Gemini Jio与美区正价订阅价差达数十倍，套利空间催生灰色账号交易，厂商的支付与IP风控面临持续压力。其二，“降智”“限流”指向厂商对订阅用户动态调配算力的潜规则，模型版本灰度放量令同价位用户体验严重割裂，服务质量不透明正成为投诉焦点。其三，Claude账号秒封不退款反映反滥用风控与正常用户权益的冲突，风控策略误伤率有待优化。后续走向上，推理成本高企背景下，厂商或将进一步细化订阅分层与用量配额，区域定价套利空间可能随账号验证机制收紧而压缩。

  核心观点：AI订阅的价值锚点正从模型能力滑向定价策略，区域差价、降智限流与封号争议正在透支用户的付费信任。

  原文链接：Linux.do

  刚刚

• vibe coding 时的安全感：开发者为 pi 编码助手开源系统监控插件

  一位开发者在 V2EX 分享了自己开发的终端监控插件 pi-sysmon。该用户表示，在使用 AI 进行 vibe coding 时，习惯通过观察系统各项运行指标来获得安全感，此前先后使用过 htop 和 bottom 两款监控工具，但两者都需要单独开辟一个终端面板放在旁边，占用屏幕空间且不够集成。为解决这一问题，该开发者为 AI 编码工具 pi 编写了插件，可直接在 pi 界面下方实时显示图表，目前支持 CPU、内存、网络以及 Token 消耗量的展示。其中 Token 指标与 AI 编码场景直接相关，可帮助开发者在大模型生成代码的等待过程中掌握资源占用与用量情况。该项目已在 GitHub 开源，社区用户可自行下载安装。这一小工具也折射出 vibe coding 工作流中的一个真实细节：当 AI 代替开发者编写代码后，人机交互减少，通过可视化监控指标来感知系统状态，成为部分用户确认工作正常进行、缓解不确定感的方式。

  事件分析

  该插件的亮点在于将监控能力原生嵌入 AI 编码工具的终端界面，而非依赖独立监控进程，体现了开发工具向一体化、低干扰方向演进的趋势。Token 实时统计尤其契合按用量计费的大模型 API 场景，类似的成本可观测功能未来可能被 Claude Code、Codex 等主流 AI 编码工具以官方形式吸收。从生态角度看，pi 这类轻量编码代理正依靠插件机制聚集个人开发者，逐渐形成类似编辑器插件市场的长尾生态。该工具的局限在于依赖特定宿主程序，受众范围有限，其价值更多在于社区示范效应：围绕 vibe coding 的等待体验、可观测性与成本感知，仍存在大量可挖掘的改进空间。

  核心观点：当 AI 接管编码，开发者转而靠监控指标确认机器在工作——可观测性正成为人机协作时代新的安全感来源。

  原文链接：V2EX 分享发现

  刚刚

• 开源项目 Nexus Launcher 发布：DeepSeek Harness 一键启动器，告别环境配置烦恼

  开发者在 Linux.do 社区发布开源项目 Nexus Launcher，这是一款面向 DeepSeek Harness 的原生桌面启动器和本地控制面板，代码托管于 GitHub。该工具旨在减少用户在运行环境配置、进程管理和版本切换上耗费的时间。主要功能包括：桌面安装包内置 Node/npm/pnpm 环境，降低首次配置门槛；支持管理多个 Harness 上游版本，由用户自主决定切换时机；可关联外部已构建的 Harness 目录；提供系统浏览器和独立窗口两种使用方式；支持系统通知与终端提醒，可自定义事件类型及提醒模式；内置启动检查、配置修复引导、诊断与恢复入口，便于定位报错；插件市场可自由选择是否安装。Nexus 自身更新与 Harness 版本切换相互独立，避免启动器更新强制用户更换 Harness 版本。目前提供 Windows 和 macOS 的 x64/ARM64 构建，Windows 另附 ZIP 免安装包，界面与文档支持中英文双语。开发者同时提示，Harness 或插件自身的数据格式变化仍可能影响跨版本使用，切换版本前建议备份重要数据。项目处于持续迭代阶段，开发者希望收集关于首次安装体验、报错提示有效性、版本切换流程是否符合习惯等方面的实际使用反馈。

  事件分析

  DeepSeek 生态正从模型能力竞争延伸至工具链建设，Nexus Launcher 的出现反映出社区对降低本地部署与运维门槛的真实需求。Harness 类工具在使用中涉及 Node 环境依赖、多版本共存、插件管理等工程问题，启动器通过桌面化封装将其抽象为图形化操作，属于典型的开发者体验优化路径。值得注意的是其架构上的边界设计：启动器更新与 Harness 版本解耦、插件市场可选、支持外部构建目录，保留了用户控制权，与常见的全家桶式封装形成差异。潜在风险在于上游 Harness 迭代较快，数据格式变化可能推高兼容性维护成本，项目能否持续跟进版本将决定其实用寿命。此类社区工具的活跃程度，也是观察 DeepSeek 开发生态成熟度的一个侧面指标。

  核心观点：开源模型的竞争已从参数与价格延伸到工具链，开发体验的打磨正成为争夺生态黏性的新战场。

  原文链接：Linux.do

  16分钟前

• 从零手写Agent内核：开源教程AgentSeed逐层拆解智能体实现原理

  开发者Nick-Hogo在GitHub上开源了名为AgentSeed的Agent内核开发教程项目，并在Linux.do社区发布推广。该项目以Python为主要开发语言，旨在通过从零构建的方式，帮助学习者真正理解Agent技术背后的实现原理。教程采用渐进式学习路径：从可以运行的最小代码开始，每次只引入一个主要概念，逐步将这些能力生长为一个完整的Agent。每个关键提交都围绕四个维度展开：What（这一阶段解决什么问题）、Why（为什么引入这个概念）、How（代码中如何实现）以及Result（学习者能获得什么可交付结果）。项目以GitHub仓库形式呈现，通过commit持续更新。作者规划了五个章节：第一章Agent基础构建（进行中）、第二章Agent核心能力、第三章格式转换与可观测性、第四章Skill技能系统、第五章MCP协议接入，后四章目前处于待开发状态。作者表示，项目动机来源于其与朋友在Agent开发中遇到的实际问题与思考，一方面希望通过知识分享让更多人了解技术本质，另一方面也借此督促自己深入学习、与社区交流查漏补缺。由于学业与开发任务繁重，作者提示可能存在拖更情况，并欢迎社区讨论指正。

  事件分析

  当前Agent开发生态多被LangChain等框架的高层封装主导，开发者容易知其然而不知其所以然。AgentSeed选择逆向路径，手写内核、逐层拆解，这种教学思路与从零实现Redis、自己动手写操作系统等经典开源教程一脉相承，切中了AI应用开发热潮下的原理学习需求。路线图中对MCP协议、Skill系统、可观测性的规划，贴合当前Agent工程化的主流方向，若能完成将具备一定参考价值。不过项目尚处早期，仅第一章开工，其余章节均为TODO，能否持续交付取决于作者的后续投入。What/Why/How/Result四问结构是其差异化亮点，若社区反馈积极，有望沉淀为可复用的Agent教学内容模板。

  核心观点：在框架封装盛行、调包成风的Agent开发浪潮中，从零手写内核的开源教程恰好填补了原理层学习的空白。

  原文链接：Linux.do

  2小时前

• 开发者重构Cursor反代开源项目：Run复用破解Agent长任务Token高耗

  开发者在Linux.do社区发布开源项目cursor2response，该项目基于Cursor SDK开放的云端Harness Loop接口，将其封装为支持长程Agent使用的Responses API网关，是在社区前辈cursor2api反代项目基础上的重构升级。作者在实际接入Codex和OpenClaw后发现，原方案在SDK侧几乎每次工具调用都会开启新的Run，无法利用SDK内部的Prompt Cache，导致长任务Token消耗巨大，且上下文可能因过大而被截断或遗忘。针对这些痛点，新版项目进行了核心架构重写：一是实现SDK Run复用，同一会话仅启动一个Cursor Agent并常驻跨轮复用，工具往返在同一Run内完成，充分利用内部缓存，显著降低冷启动Token消耗和延迟；二是支持原生Steer机制，用户可在模型执行工具调用后直接插入指令，无需中断或重启任务；三是自带本地Trace Viewer可视化面板，可查看Agent轨迹、会话分叉点、工具调用参数及缓存状态；四是支持上下文溢出降级，当上下文超出SDK长度限制时自动切换备用Responses API，会话不丢失上下文；五是支持Docker Compose一键部署或Node 24直接运行。关于封号风险，作者表示无法保证，但参考Cursor官方论坛工作人员的回复，合理使用官方API Key进行个人Agent项目集成应该没有问题。

  事件分析

  该项目的核心价值在于对Cursor SDK能力的深度挖掘：通过Run常驻复用激活Prompt Cache，直击Agent应用运行成本高企的普遍痛点，这一思路对同类AI编程工具的二次开发具有借鉴意义。从生态视角看，Cursor官方开放SDK接口本身释放了信号——AI编程工具正从封闭产品走向可组合的平台化基础设施，第三方网关与协议适配层将成为生态中的关键环节，Responses API的收敛也反映出OpenAI定义的接口标准正在成为事实规范。Steer机制支持任务执行中动态注入指令，与Agent交互范式向人机实时协作演进的方向一致。潜在变数在于：此类反代项目始终游走于服务条款的灰色地带，官方政策调整可能影响其存续；压缩机制交由接入方处理的设计，也对下游Agent的上下文管理能力提出了更高要求。

  核心观点：AI编程工具竞争正从模型能力转向生态开放度，社区反代项目的活跃折射出官方API供给与平台化需求之间的落差。

  原文链接：Linux.do

  3小时前