> ## Documentation Index
> Fetch the complete documentation index at: https://docs.xpertai.cn/llms.txt
> Use this file to discover all available pages before exploring further.

# UOSE 理论

> UOSE 如何从本体论演化为统一对象语义执行模型。

UOSE 理论把本体论的“实体、关系、属性、约束”进一步扩展为“对象、语义、动作、策略、证据”的执行闭环。它面向的是企业智能体场景：Agent 既要理解业务对象，也要安全地调用真实系统。

## 五个基本要素

UOSE 的最小理论集合包括五类对象：

* Entity：可被识别和引用的业务对象或技术对象。
* Relation：实体之间的结构关系和语义关系。
* Attribute：实体或关系上的结构化描述。
* Affordance：对象理论上支持的动作能力。
* Policy：动作在当前租户、组织、资源和目标上的治理规则。

Affordance 是从本体论走向执行的关键。它表达“这个对象可以被如何使用”。例如，语义指标可以查询趋势，数据库表可以预览行，SAP Entity Set 可以读取集合或更新实体。

## 从对象到动作

UOSE 不允许 Agent 直接从自然语言跳到后端 API。它要求动作经过对象语义空间：

```text theme={null}
用户意图 -> 对象定位 -> 邻域上下文 -> 动作发现 -> 模拟校验 -> 真实执行
```

这条链路把不确定性分层处理：

* 对象定位解决“用户说的是哪个对象”。
* 邻域上下文解决“这个对象关联哪些模型、字段、关系和约束”。
* 动作发现解决“这个对象当前可做哪些事”。
* 模拟校验解决“这个动作是否满足参数、策略和运行条件”。
* 真实执行解决“把通过校验的动作发送给适配器并记录结果”。

## 渐进式上下文披露

UOSE 理论强调最小必要上下文。Agent 不应一次性读取所有资源细节，而应按任务阶段逐层获取：

* L0：可用资源和资源类型。
* L1：意图相关的实体候选。
* L2：目标实体的一跳邻域、schema 和约束。
* L3：动作输入契约、风险、审批和 readiness。
* L4：执行结果、审计证据和复盘信息。

这种渐进式披露降低上下文成本，也减少 Agent 误用过量信息的风险。

## Fail-closed 执行原则

UOSE 的执行默认遵循 fail-closed 原则：当系统无法确认动作契约、目标对象、参数合法性或策略结果时，执行应被拒绝或转入审批，而不是让 Agent 自行猜测。

典型拒绝原因包括：

* 找不到唯一实体。
* 目标实体类型不支持动作。
* action discovery mode 不允许自动执行。
* 缺少 `analysis_contract` 或 query endpoint。
* 参数不符合 action input schema。
* 策略绑定返回 deny。
* 高风险动作需要审批但未提供已批准的审批单。

## 语义和执行分离

UOSE 把语义层和事实执行层分开：

* 语义层负责发现对象、关系、schema、约束和上下文。
* 执行层负责调用外部资源、查询事实数据或触发写操作。

例如，RDF 层可以回答某个指标属于哪个 Cube，但真实指标值仍由 `semantic_model` adapter 回源查询；本体层可以描述 SAP Entity Set 的字段，但真实读取仍由 SAP OData adapter 调用源服务。

这种分离让 UOSE 既能保持语义统一，又能尊重每个源系统的事实边界和权限边界。