夜雨聆风摘要
在大模型能力日益强大的今天，Agent在实际生产系统中却依然像“盲人摸象”——它能写代码、做推理，却不知道“这条告警属于谁”、“服务依赖什么”、“刚才谁修改了配置”。问题的根源不在于数据量不足，而在于缺少一个能描述“对象”与“关系”的语义层。
本文将深度介绍开源项目UnifiedModel，它通过一套“Set + Link + Field”的最小原语，为Agent构建了一个可执行、可查询、人与AI共读的“对象图”语义层。实验证明，添加UnifiedModel语义层后，4个旗舰模型的回答准确率均提升10-20个百分点，部分模型性能甚至超越了未使用该层的一线闭源模型。
关键词： UnifiedModel；语义层；Agent工程；对象图；AI可观测性；LLM应用
1. 引言：为什么Agent需要一个语义层？
今天的大模型已经非常聪明，能写代码、能做复杂推理。然而，当它们被放入真实的生产系统中时，立刻变成了“盲人摸象”。一个Agent能回答“宇宙的起源是什么”，却回答不了“payment-gateway服务现在的P99延迟为什么破了SLO”——因为它不知道告警属于哪个服务，不知道服务调用链，不知道刚才谁修改了配置。
为了弥补这个缺陷，业界尝试了各种方法：
| 更强的模型 | |
| 更多的上下文 | |
| 更多的检索 | |
| 更多的记忆 | |
| 接更多工具/多智能体 |
所有尝试都在加“能力”，却没有人补充那个最核心的东西——“结构”：对象，以及对象之间的关系。
Agent要想真正做事，脑子里必须有一个“世界模型”。任务越难，这个世界模型就必须越准确。数据只是现象，对象和关系，才是系统结构。
2. UnifiedModel：设计与实现
UnifiedModel的目标很明确：给Agent加一层语义层，把分散的原始数据组织成Agent能理解的“对象图”。
2.1 核心思想：本体论（Ontology）
语义层的根基是“本体论”——对一个领域里“有哪些类型的事物、它们之间如何关联”的明确规范。本体 = 类型 + 关系 + 属性 + 约束。
| 类型/概念 | Set | |
| 关系 | Link | |
| 属性 | Field | |
| 约束/公理 |
2.2 统一原语：Set + Link + Field
UnifiedModel用一套最小原语，将对象、数据、关系、语义建构成可执行、可查询、人与Agent共读的对象图。
Set（节点）：
EntitySet：对象/实体，有主键和生命周期 DataSet：观测数据集（MetricSet/LogSet/TraceSet等） RunbookSet：运维知识/Runbook/技能
Link（边）：
DataLink：实体/数据→数据集 EntitySetLink：实体→实体（calls/runs/contains等24类拓扑关系） StorageLink：数据集→存储（数据字段↔存储列）
Field（字段语义）：
类型：string/int/float/bool/time/json 取值与展示：unit、data_format、value_mapping 查询能力：analysable、filterable、orderable 约束与扩展：pattern、min/max、tags、properties
真实案例： 一个简单的“服务运行在主机上”关系，UnifiedModel会建模为：
EntitySet[Service]+EntitySet[Host]+EntitySetLink[runs_on]+ 各自的Field定义。一条调用链就是一张完整的对象图。
2.3 类（TBox）与个体（ABox）分离
UnifiedModel遵循知识图谱的经典架构：
- TBox（定义层）：
定义一次“类”的模板（Set/Link/Field），如 platform.service的14个字段。 - ABox（数据层）：
运行时持续写入“个体”实体，如 checkout-service、catalog-api等实例。
定义一次，N个个体持续写入，EntityStore自动通过keep_alive机制维护实体的上线与过期。
2.4 核心能力：统一查询（SPL）
UnifiedModel定义了一套SPL语法，覆盖定义、实体、拓扑、指标的查询：
# 查询实体→表
.entity with(domain='platform', name='platform.service')
| project display_name, status, owner
| limit 20
# 查询拓扑→图
.topo
| graph-call getNeighborNodes('full', 1, [platform.service])
屏蔽底层存储差异： Agent只需表达“查哪个对象、哪类数据”，UnifiedModel的Query Service会自动完成数据链路映射，为Elasticsearch、MySQL、ClickHouse等不同存储生成对应的查询方言。底层存储可变，对象语义与查询入口始终保持稳定。
2.5 AI友好设计
UnifiedModel为Agent设计了三大AI友好特性：
- 自描述与渐进式披露：
Agent不用预知Schema，直接问“你能做什么”，UnifiedModel运行时自己描述、被发现。模型增删方法，Agent自动看见。 - MCP标准协议：
通过MCP暴露给任意Agent，默认开启读工具（query_spl_execute、explain、examples），安全可控。 - 可加载Skills：
提供预置的Agent方法（读数、根因定位等），支持Claude Code、Cursor、Qoder、Codex等主流Agent运行时。 
3. 语义层效果实验：净增益10-20pp
为了验证语义层的实际效果，UnifiedModel团队设计了一个严格的对比实验。
实验设置：
- 任务：
Agent回答企业里的真实数据问题 - 对照组：
无语义层，面对分散的多张原始表，需要自己定位、拼接 - 实验组：
有语义层，看到整理好的“对象+关系”，按对象和关系直接查询 - 测试模型：
4个旗舰模型（Qwen3.7、GLM-5.2、DeepSeek、MiniMax） - 数据源：
DataAgentBench官方51题×5次评测
实验结果：
| +19.2pp | |||
| +10.2pp | |||
| +11.7pp | |||
| +20.0pp |
结论： 所有模型的准确率均提升10-20个百分点。尤其值得关注的是，添加UnifiedModel语义层后的GLM-5.2（50.2%），其表现甚至高于未使用该层的Claude-Opus和Gemini-3。
4. 实战场景演示
场景一：智能读数
Agent问： “payment-gateway现在怎么样？”
UnifiedModel的工作流程：
- 定位实体：
“那个服务”→ platform.service，ID63718b78… - 找数据集：
DataLink将实体关联到MetricSet/LogSet - 生成计划：
get_metrics自动生成PromQL，service_id已代入
Agent回答：
payment-gateway platform.service · 63718b78…
status: degraded
QPS: 4200 · 错误率: 14.8% · P99: 2150ms
SLA: platinum
场景二：根因定位（RCA）
Agent问： “payment-gateway为什么P99破SLO？”
三跳定位：
- 发现依赖链：
payment-gw ← checkout ← cfg-checkout-retry - 排除红鲱鱼：
12小时前的v3.2.1部署，仅日志格式变更 → 排除 - 量化根因：
retry_storm（重试5/2 × 大促3.5 = 35,000 QPS ≈ 8.75×容量）
5. 结论：语义层是Agent时代的基础设施
UnifiedModel的实践告诉我们一个核心道理：问题不在数据量，而在数据结构。
更强的模型、更多的上下文、更长的记忆、更多的工具——这些都只能解决“能力”问题，却无法补上那个最根本的“结构”问题。Agent需要的不只是更多数据，而是一个能描述“对象”和“关系”的语义层。
UnifiedModel的“Set + Link + Field”原语，用最小的概念集合构建了最大化的表达能力。它让Agent从“盲人摸象”变成了“心中有图”——先建模真实世界，再组织数据，这才是AI Agent时代真正的基础设施。
项目地址： https://github.com/alibaba/UnifiedModel
