给 Agent 加一个“判断器”：聊聊 Laya、Jev，以及怎么部署和选择

做 Agent，有时候最别扭的模型调用，恰恰是那些输出特别短的调用。

假设你在做一个工单助手。用户发来一句话：

升级之后，整个部门都登录不了了，今天的工作全卡住了。

你暂时不需要模型写排障报告，只想知道三件事：这算故障还是咨询？有多紧急？要不要交给人工？

于是，又写了一段提示词：请判断、只返回 JSON、不要解释、字段必须……

结构化输出已经能解决不少格式问题。但做完之后还是会有点不甘心：我只需要几个判断，能不能把这件事做得更直接一点？

Laya 和 Jev 关注的，就是这类需求。它们让模型读材料、回答范围明确的问题，再把结果交给程序继续处理。

这篇文章把几个容易混在一起的问题拆开聊：Laya 到底做什么，它与 Jev 差在哪，是否需要自己部署，以及真的准备接入时该怎么选。

本文资料核对于 2026-09-23。部署示例以 Laya 0.3.7 为准；Jev 的版本信息参考当日官方文档。代码与命令按公开接口、发布源码核对，本文未实际下载权重、运行推理或复现性能。

1. Laya 能做什么？先把问题问小一点

Laya 是 Convai Innovations 公开的非自回归决策模型项目，提供代码、权重和 Python SDK，采用 Apache 2.0 许可证。这里讨论的 Laya，是这个 AI 项目。项目仓库

它的调用方式可以拆成两份输入：

• state：这次判断要看的材料。 比如工单内容、用户请求、几条相关日志。
• questions：你希望判断什么。 问题怎么问、有哪些候选项、每个等级代表什么，都由应用定义。

输出主要有三类：

类型	用工单举个例子	拿到什么
choice	这是故障、咨询，还是功能建议？	被选中的标签、各选项概率、置信度
score	按“不紧急、影响使用、业务阻断”评估紧急程度	等级的概率分布，以及按等级索引计算的期望分数
noul	材料是否表明多人受到影响？	该判断成立的概率，范围为 0～1

score 容易被误会。它不是让模型随便编一个百分制分数。假设你定义三个等级，索引分别是 0、1、2，模型给出的概率分别是 0.1、0.3、0.6，那么期望分数就是 1.5。这组数字只是解释计算方式，并非本文实测输出。Laya 结果构造源码

图 1：模型负责判断，应用代码负责使用判断结果。图中的字段说明为概念示意。

比如，choice 选中了“故障”，你的代码就把工单送到故障队列。是否升级、分给谁、是否需要人工确认，仍然是业务逻辑。

也别把“不会生成候选项以外的标签”理解成“不会判断错”。把一条故障工单分进咨询队列，返回格式可以完全正确，业务结果照样不对。

这种分工有一个很实在的好处：出了问题比较好查。是分类错了，还是升级规则不合理？至少不用对着一大段提示词猜。

当然，问题要问得足够具体。“请综合判断这个客户值不值得挽留”就很宽；“是否明确提出退订”“是否重复报障”“当前问题是否阻断使用”，更适合拆开判断，再由代码组合。

2. 它为什么能快？里面发生了什么

生成式模型通常逐个生成 token。Laya 的推理路径是把问题、选项和材料编码，然后对候选项计算分数，转换成概率，再按问题类型构造返回值。它不需要先写出一段回答，再从回答里抽取标签。

从实现看，它采用双向 Transformer 编码器和决策头；每个选项在输入里有对应标记，决策头读取这些位置进行打分。问题里的选项可以在调用时定义，但“能换选项”并不保证换到任何领域都能判断准确。模型结构与输入构造源码

目前公开的几个 checkpoint，可以先这样理解：

checkpoint	编码器 / 总参数量	默认输入长度	适合先从哪里试
英文版	ModernBERT-large / 约 421M	512 tokens	英文判断任务
多语言版	mmBERT-base / 约 322M	1,024 tokens	中文等多语言任务
typed-decisions	ModernBERT-large / 约 421M	1,024 tokens	与其专项微调任务接近的工作流

这些长度来自项目公开配置说明，不等于所有内容都能留给 state：问题和选项也要占空间。多语言版的默认问题预算是 256 tokens，材料预算可粗略按剩余约 768 tokens 理解，实际还受输入格式和特殊 token 影响。模型卡

同一次 predict 中的多个问题会被组成一个批次进行前向计算。这里也别想得过于神奇：问题多了，计算和内存开销仍会增加；“一次前向”不是“问多少问题都一样快”。

项目还使用 RLCD 训练方法，希望模型输出的概率能反映不确定性。这个方向很有意义，但训练目标与实际校准效果是两件事，后面会专门说它的限制。

3. 上下文从哪来？怎么接到 LLM 前面？

第一次看这种接口，很容易有个疑问：我在聊天窗口里已经说了很多，Laya 是不是天然知道？

需要由你的应用把这些材料放进 state。对话记录在数据库里，就由应用读取；日志在日志平台，就由已有检索流程拿到；用户上传了文件，就先提取出这次判断需要的文本。调用本身只处理传入的内容。

例如，要判断一个请求应该交给轻量模型还是更强的模型，我会先给它“用户原话 + 几条影响路由的事实”。为了分流，通常没必要先塞进去整套代码和几万行日志。

更不必为了每次路由，先专门调用另一个大模型总结上下文。已有的会话摘要、业务字段、最近几条相关消息，常常就能作为起点。是否需要额外摘要，要看材料长度和实际效果。

图 2：一种 LLM 路由接法。图中收集材料、映射模型和发起请求的动作，都需要应用代码实现。

这里有两份上下文需要区分：给 Laya 的材料用于判断路线；给后续 LLM 的材料用于真正回答问题。 后者可能需要更详细的日志、代码和历史消息。路由标签本身不能代替这些内容。

也不是所有判断后面都要接 LLM。假如你的目标就是给工单分类，拿到分类结果后，进入对应队列就可以结束这一轮。

还有一个名字很容易撞车：SDK 自带的 Router，主要在 Laya 的英文、多语言等 checkpoint 之间选择；图里的 small_llm / strong_llm 是我们自己定义的业务选项。它们是不同层次的路由。0.3.7 中，专项 typed-decisions 的自动任务识别需要显式启用，或直接指定对应模型。Router 发布源码

4. Laya 和 Jev，是不是同一个东西？

它们面向相近的问题，但来自不同项目。Laya 不是 Jev 的公开权重。

Jev 是 TypeSafe 的 System One 模型。官方也采用 state + questions 的方式，提供 Choice、Score、Noul，让应用拿到可以参与分支、排序和路由的结构化结果。Jev 官方介绍

如果只看使用思路，两者确实很像。真正影响落地的差别，要往下面看。

图 3：部署职责对照。Laya 0.3.7 已提供 Jev 风格的 HTTP 兼容层，详见下文；接口形状相近不代表预测效果相同。

比较项	Laya	Jev
模型从哪里来	公开权重，自己下载和运行	通过 TypeSafe 托管 API 使用
谁维护推理环境	自己或自己的平台团队	托管服务方；应用仍需处理网络、限流和失败
能否改权重	可依据项目材料开展微调	官方说明不按客户数据进行专属微调或 LoRA，主要通过输入和问题定义适配
中文怎么处理	明确选多语言版，再用自己的中文样本验证	官方说明英文表现最好，其他语言也应自行测试
上下文空间	当前常用配置为 512 / 1,024 tokens	Jev 1.13 文档为每请求 64k；state + 最长问题 另有 32k 限制
大量候选项	受选项预算影响，可能要分层或先筛候选	官方 Choice API 允许最多 255 个选项；数量上限不是效果保证
成本构成	机器、服务维护、评测，以及可能的训练	API 费用、接入维护和请求失败处理

表中的 Jev 模型、语言、上下文和定制方式依据官方模型文档，选项上限依据API 文档。Laya 的配置与限制依据项目说明。这些是接入条件对比，不是效果排名。

Jev 在 2026-09-15 宣布开放 early access。本文核对的公开资料提供托管 API、控制台和 SDK，未找到公开权重下载或自行部署说明；企业合作是否有其他交付方式，需要另行确认。TypeSafe 发布说明

0.3.7 有个值得单独说的变化：HTTP 兼容层

Laya 0.3.7 提供了 POST /v1/systemone，接受 state、questions、model 等字段，并返回 Jev 风格的结果结构。已有的部分客户端，可以围绕这个兼容层尝试接入 Laya。0.3.7 服务源码

但我不会把它写成“改个地址，迁移就结束了”。这个服务实现的是判断端点和健康检查，并没有覆盖 TypeSafe 的全部服务能力。换模型后，概率分布、置信度、输入限制、错误行为和业务效果都要重新验证。

尤其是已经写进业务代码的阈值，不应该原样照搬。字段名字一样，不代表在两套模型上使用同一个阈值，会得到同样的误判率。

5. 用 Laya，一定要在自己电脑上部署吗？

不一定要装在自己的电脑上。但要做真实推理，总得有一台机器加载模型。

如果只是了解接口，可以先看项目链接的在线 Demo，其可用性取决于 Space 当时的状态，示例也不宜放入真实敏感业务数据。

真正接入应用，常见的是下面两种方式：

1. 直接放进 Python 进程。 程序启动时加载模型，后续反复调用 predict。自己的电脑、开发机、云主机都可以承担这个角色，不必先搭一个 HTTP 服务。
2. 部署成一个独立服务。 在自有服务器上运行 Laya，让 Java、Go、Node.js 等应用通过 HTTP 调用。这样业务服务不必各自装一份 PyTorch 和权重。

如果用 Jev 官方 API，你通常只需要接入客户端和凭据，不需要在本机下载 Jev 模型。代价是请求要经过托管服务，网络条件和服务限制也进入了调用链。Jev 快速开始

如果你是为了控制数据流向而自部署，还要看看后半段：Laya 在本地判断之后，假如应用继续把原始材料发送给云端 LLM，那些材料仍会离开本地环境。部署位置要按整条调用链来检查。

图 4：自部署描述的是模型由谁运行、运行在哪里，不等于必须在个人电脑上长期跑。

对第一次尝试的人，我会从进程内调用开始。先看看模型能不能把自己的十几条样本分明白，再考虑服务化。

6. 最小本地部署：一个 Python 文件就够了

下面以 macOS / Linux 的终端操作为例。Laya 0.3.7 要求 Python 3.10 及以上，并依赖 PyTorch、Transformers 等库。发布版本与依赖声明

第一步：建一个独立环境

# 为这次示例准备目录。
mkdir -p laya-demo
# 进入示例目录。
cd laya-demo
# 创建虚拟环境，隔离依赖。
python3 -m venv .venv
# 在当前终端启用环境。
source .venv/bin/activate
# 固定本文核对的 Laya 版本。
python -m pip install "laya==0.3.7"

这里固定了 Laya 版本，传递依赖仍由 pip 解析。正式交付时，还应保存验证通过的依赖锁定结果与权重版本。不要把“今天能安装”理解成“未来任何依赖组合都一样”。PyPI 0.3.7

第二步：把下面内容保存为 demo.py

示例只做一件事：判断当前请求适合交给哪一类 LLM，并展示后续应该发送的材料。

"""最小示例：Laya 判断路由，再展示下游 LLM 的输入；不调用下游 API。"""

import json

import laya

# 应用提供原始请求及与本次判断相关的少量上下文。
state = {
    # 保留用户的问题，后续也要传给被选中的 LLM。
    "request": "帮我分析这次登录故障",
    # 此处是内置演示数据，实际接入时由应用从已有材料中提取。
    "context": "升级后多人无法登录，网关和用户服务都出现超时日志。",
}

# 定义一个名为 route 的问题，供应用读取对应的判断结果。
questions = {
    "route": {
        # choice 要求从下面列出的候选路由中选择。
        "type": "choice",
        # 只判断所需模型类型，不要求 Laya 在这里分析故障根因。
        "instructions": "选择适合处理当前请求的模型类型。",
        # 两个标签只是本应用的分组名称，不是模型供应商的模型 ID。
        "criteria": {
            # 范围明确的改写、翻译等任务分给轻量模型。
            "small_llm": "简单改写、翻译、常规问答",
            # 需要综合多条证据的任务分给更强的模型。
            "strong_llm": "复杂推理、跨服务故障分析",
        },
    }
}

# 中文输入使用多语言权重；先用 CPU 验证流程，首次运行会下载模型。
agent = laya.load("convaiinnovations/laya", subfolder="multilingual", device="cpu")

# 显示实际推理设备，便于核对 CPU、CUDA 或 MPS 是否生效。
print("实际推理设备：", agent.device)

# 将事实和问题分别交给 Laya，实际选择由模型计算得出。
result = agent.predict(state, questions)

# 使用自己定义的问题名称取出选项、概率等结果，不预设模型一定选哪项。
decision = result["answers"]["route"]

# 将原始请求与上下文保留为下游消息，不用路由标签替代原始材料。
messages = [
    {
        # 原始输入作为用户内容传递，不提升为系统指令。
        "role": "user",
        # 小例子复用完整 state；实际项目可以在这里补充详细日志或代码。
        "content": json.dumps(state, ensure_ascii=False),
    }
]

# 打印模型的真实返回值；这一步不代表路由效果已经经过业务评测。
print("Laya 的路由结果：")
print(json.dumps(decision, ensure_ascii=False, indent=2))

# 展示应用将选择的模型组，接入时再映射成供应商提供的真实模型 ID。
print("下游 LLM 分组：", decision["choice"])

# 仅展示待发送的消息，便于观察上下文传递，不发起下游 API 请求。
print("准备传给 LLM 的消息（仅展示）：")
print(json.dumps(messages, ensure_ascii=False, indent=2))

第三步：运行，并区分加载与推理

# 在已激活虚拟环境的终端运行示例。
python demo.py

第一次执行 laya.load 会访问 Hugging Face 下载相应文件，然后把模型加载到内存。模型卡标注多语言权重约 647 MB，但权重文件大小不能当成运行内存需求：还需要模型运行时、临时张量等空间。权重与加载说明

本文没有运行这次推理，所以不贴一组看上去很漂亮的“实际返回”。运行后应查看脚本打印的设备、模型选择和概率；它也可能选错，需要由你的样本验证。

这个文件中的材料是演示数据。它没有自动读取聊天历史，也没有真的调用下游 LLM。接入时，还要把 small_llm / strong_llm 映射到实际模型 ID，再把 messages 交给对应客户端。

电脑没有 NVIDIA 显卡，还能试吗？

可以先用上面明确指定的 CPU 路径。当前 SDK 也处理 CUDA 与 Apple MPS 设备；具备相应硬件和 PyTorch 支持时，可以把 device="cpu" 改为 "cuda" 或 "mps"。某些情况下会回退到 CPU，要检查实际设备，不能只看传入参数。设备选择与回退源码

如果使用 CUDA，请根据操作系统、显卡与驱动选择匹配的 PyTorch 安装方案。这里只给出 CPU 入门路径，不承诺任意 Mac、显卡或依赖组合都已验证。

长时间运行的应用应该在启动时加载一次，复用这个对象。把 laya.load 写进每次请求里，测出来的很可能主要是加载耗时。

7. 想给 Java 或其他应用调用：启动官方 HTTP 服务

如果业务服务是 Java，通常可以把 Laya 放在独立的 Python 进程里，业务侧调用 HTTP。0.3.7 已有服务入口，可以先用它验证接入，无需为了一个示例手写服务框架。

安装服务依赖

继续使用前面那个虚拟环境：

# 安装同一版本的服务端可选依赖。
python -m pip install "laya[serve]==0.3.7"

这个 extra 提供 FastAPI、Uvicorn，命令入口是 laya-serve。安装入口定义

先只在本机监听

下面几段命令在同一个已激活虚拟环境的终端中依次执行。服务放到后台，后续请求沿用当前终端的临时密钥。

# 为本次本地演示生成临时密钥，不把固定密钥写进文件。
export LAYA_API_KEY="$(python -c 'import secrets; print(secrets.token_urlsafe(32))')"
# 只绑定本机，启动时预加载多语言模型，并明确用 CPU 验证流程。
LAYA_HOST=127.0.0.1 \
LAYA_PORT=8000 \
LAYA_DEVICE=cpu \
LAYA_PRELOAD=1 \
LAYA_MODELS=multilingual \
laya-serve &
# 保存这个演示进程的 ID，便于结束时关闭。
LAYA_DEMO_PID=$!

等待终端出现服务启动完成的信息，再检查健康状态。首次需要下载、加载模型时，不要用这段等待时间去对照 GPU 的推理耗时。

# 健康检查确认服务状态与已加载的 checkpoint。
curl --fail --silent --show-error \
  --connect-timeout 5 --max-time 10 \
  http://127.0.0.1:8000/health

注意，LAYA_MODELS 表示预加载哪些模型，并不是禁止其他模型被请求的白名单。下面的请求还会显式指定 multilingual，让演示路径保持明确。

发出一个真实的判断请求

执行下面命令会触发你本机服务的模型推理；这里展示的是读者运行步骤，本文未执行。

# 在同一终端中携带临时密钥，提交固定的演示数据。
curl --fail --silent --show-error \
  --connect-timeout 5 --max-time 60 \
  http://127.0.0.1:8000/v1/systemone \
  -H "Authorization: Bearer ${LAYA_API_KEY}" \
  -H 'Content-Type: application/json' \
  --data-binary @- <<'JSON'
{
  "model": "multilingual",
  "state": {
    "request": "帮我分析这次登录故障",
    "context": "升级后多人无法登录，网关和用户服务都出现超时日志。"
  },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "选择适合处理当前请求的模型类型。",
      "criteria": {
        "small_llm": "简单改写、翻译、常规问答",
        "strong_llm": "复杂推理、跨服务故障分析"
      }
    }
  }
}
JSON

关注返回结果中的 answers.route.choice。到这里，HTTP 服务做的仍然是判断；如果你要自动调用后面的 LLM，还是由业务应用读取结果并发起下一次请求。

试完关闭本次后台进程：

# 关闭当前终端刚启动的演示服务。
kill "$LAYA_DEMO_PID"
# 清除本次演示的临时变量。
unset LAYA_API_KEY LAYA_DEMO_PID

上述环境变量、路径和鉴权方式均按 0.3.7 发布源码 核对。服务默认监听所有网卡，Bearer 校验也需要配置才启用，因此示例明确限制为本机并设置密钥。/health 本身不要求这个密钥，不应把它当成受保护的业务接口。

放到服务器上，还差哪些事？

本地能够返回结果，是接入的第一步。要给团队服务，我还会补上这些工作：

• 保留现有的认证与网络边界。 优先让反向代理或网关接入；跨机器传输配置 TLS，限制可调用方、请求体大小和请求频率。
• 控制资源和并发。 问题数量、选项数量、队列长度和超时都要有上限；增加进程数前先测内存，每个进程可能持有自己的模型副本。
• 限定能调用的模型。 在网关或服务封装层校验 model 白名单，对缺失值和未知值按服务端规则拒绝或固定映射。LAYA_MODELS 只控制预加载，不能阻止请求触发其他模型；禁止请求阶段下载或加载未批准的 checkpoint。
• 把版本和启动过程固定下来。 留存 SDK、依赖和权重版本；预加载并预热后再接流量，记录真正使用的设备。
• 定义失败时怎么办。 加载失败、超时、模型判断质量不足，各走什么后备路径，写在应用里；监控延迟、错误和资源，不记录完整敏感输入。

源码中的 HTTP 层比较轻量，这些生产能力不能仅凭“有一个服务命令”就假定已经具备。网络隔离环境还需提前准备完整模型文件及依赖，并验证离线启动。

8. 速度、效果和成本，别只看最漂亮的一个数

先看 Laya 作者在 T4 上公布的耗时。这里只画 Laya 的两个 checkpoint，不把来源不同的 Jev 数字混成同条件比赛。

图 5：作者测试，本文未独立复现。单位为毫秒，纵轴从 0 开始；十个问题的柱子表示整批耗时。

英文版单问题约 39.5 ms，多语言版约 32.8 ms；一次处理十个问题时，分别约 158.6 ms 和 72.3 ms。后者平均每题约 7.2 ms，但调用者仍然需要等待整批返回。性能报告

这些数值得关注，但不能直接写进自己服务的 SLA。硬件、输入长度、并发、加载状态，以及是否经过 HTTP，都会改变最终体验。测试自己的业务时，我会把首次加载和预热后的请求分开测，并同时看 p50、p95 和失败率。

效果更需要谨慎。作者披露，typed-decisions 上较好的结果来自专项微调；基础 checkpoint 在同一任务上明显弱得多。因此“它能接收任意问题格式”和“它能解决任意业务问题”，中间还隔着评测与训练。

概率也不能照单全收。Laya 在一些公开评测中过度自信，作者新增的路由任务记录又出现了偏保守的情况。方向可能随任务变化，用自己的留出集检查才有意义。校准与限制说明

再补一个容易看漏的细节：Laya 的 choice、score 中，confidence 是根据概率分布的归一化熵计算的集中程度。它不是最高选项概率的另一个名字，更不能直接当作“这次有多少概率一定做对”。confidence 实现 Jev 官方同样区分概率分布与由分布计算的置信度，并要求按领域验证阈值。Jev 置信度说明

Jev 也有公开短板。官方列出的 Jev 1.13 问题包括数字精确性、复杂间接推理、无关上下文干扰和对抗内容。算金额、比较日期、做权限判断，这些已有明确算法或规则的部分，应该继续留在代码里。Jev 已知限制

成本则要把两本账放在一起算。核对时，Jev 模型页列出的输入价格是 每百万 tokens 0.042 美元，输出不收费；后续以官方页面为准。Jev 价格与模型信息

Laya 没有因此变成“零成本”。即使使用开源权重，机器空闲时也可能在计费，模型和依赖需要维护，业务样本需要评测。一个实用的比较方法是：

托管方案：API 费用 + 接入维护 + 网络与失败处理成本。
自部署方案：机器费用 + 服务维护 + 评测及可能的微调成本。

如果每个月只做少量判断，省下来的调用费未必抵得上一轮部署维护。反过来，如果流量稳定、内部已有推理基础设施，自己运行的账又可能很好算。没有实际调用量和资源利用率，先别急着宣布哪边更便宜。

9. 最后怎么选？我会先问这几个问题

如果是我的项目，我不会从“哪个名字更新”“哪个榜单更高”开始选。我会先看这项判断到底需要什么。

第一，是否真的需要一个模型？

如果判断条件是“订单金额超过某个值”，直接写代码。如果需要写文章、解释故障根因、做多步分析，继续用擅长生成与推理的模型。Laya、Jev 更值得尝试的，是那些规则很难穷举、又能清楚定义答案范围的语义判断。

第二，我最想省掉什么？

希望尽快把一个工作流接起来，不想自己维护权重和推理服务，也能接受托管 API 的数据路径与服务条件，那么可以先评估 Jev。先拿到访问权限，用自己的任务测效果，再决定是否接入。

如果推理位置、权重控制、内网运行或业务微调是硬需求，并且团队能承担服务维护，那么 Laya 更值得先做小规模验证。中文业务明确选多语言 checkpoint，不要看到“开源可部署”就默认中文效果已经过关。

第三，这个任务有多少候选项、多少上下文？

两个路由选项与七十多个工单分类，难度和输入预算都不一样。几百字材料与长对话，也不是一回事。Jev 的公开上下文与选项上限更宽；Laya 可以考虑精简材料、分层分类或先筛候选，但这些都是要额外验证的工程选择。

图 6：选型路线是本文的工程建议；通过接入条件筛选后，仍需要业务评测。

真正准备试点时，我会选一个边界最清楚的环节，例如“工单分到哪个队列”，准备有人工标签的数据：一部分用来校准、选阈值，另一部分留作独立测试，不参与训练或调参。同时看四件事：

1. 错在哪。 总体准确率之外，关键类别的漏判和误判是否能接受。
2. 要等多久。 在预期输入长度与并发下，p95 和失败率是多少。
3. 能自动处理多少。 在校准集选定阈值，再用独立测试集检查自动处理覆盖率与错误率。
4. 省下了什么。 把请求费用、机器费用和维护时间一起算，再看是否值得长期保留。

对我来说，Laya 最有吸引力的地方，是可以拿到模型，在自己的环境里围绕具体判断任务继续打磨；Jev 的吸引力，则是把维护推理服务的工作交给托管方，让自己更快开始验证业务流程。

先选一个小环节跑明白就好。能稳定地把工单送对队列，比一次给 Agent 加上十个“智能判断节点”，更容易看出实际价值。

---

本文是技术介绍与部署步骤整理，未实际安装 Laya、下载模型或运行推理，也未调用 Jev API。配套 demo.py 与文中代码一致；现有性能图引用作者数据。部署命令核对到 Laya 0.3.7 发布提交 010bacef009c855ccba814b51f7c8e1d38ab5e3f，后续版本请重新检查接口与默认值。