让企业规则成为
Agent 的确定性大脑

制度文档 → 本体 → 确定性判决

Ontos 把企业制度文档整理为可执行的业务本体——每条规则逐条溯源制度条款；判定由确定性规则引擎完成，判定路径零 LLM、微秒级出结果，同一单据连判 N 次判决一致。每条判决都带 rule_id、字段级证据链与制度条款出处，经得起审计追问。

Agent 很强，但它不懂你的规则

通用办公 Agent 写文档、订日程、跑流程都很出色——可一到真正的业务判定 （这张发票能不能付？这条线索该不该跟？）就露怯：它不懂你的业务规则，也接不住规则的变化。 Gap 出在三处：

其一

规则写在业务语言里，执行要的是技术语言。人肉翻译一次，信息损耗一次、语义偏差一次——Agent 学到的从来不是制度原意。

其二

制度躺在文档和手册里（非结构化），引擎能执行的是结构化规则。中间没有桥，规则就无法被自动化引擎准确理解和执行。

其三

规则越攒越多：冲突、遗漏、冗余交织，改一条不知道牵动几条， 维护成本随规则数激增——最后没人敢动，也没人说得清。

海外实践给出的答案是 Ontology（本体）：把业务规则梳理成机器可执行、逐条可溯源的结构化知识，再交给确定性引擎。这正是 Ontos 在做的事——自动构建本体 → 与业务确认 → 驱动 Agent 执行，让 Agent 更懂业务、更 follow 公司规则。

壹

确定性规则引擎，判定路径零 LLM。同一单据连判 N 次判决一致，每条判决携带 rule_id、字段级证据链与制度条款出处，结论可复核、可追溯。

贰

三值语义：字段缺失 → 判不了 → 转人工并列出缺口。发票号缺失不会被"猜"成通过——不确定就明说，这正是与纯 LLM 判定的分界线。

叁

改规则必须通过 41 case 评测回归（pass_rate==1.0）才允许发布，发布门禁不可绕过；版本存档、可回滚。规则演进有闸门，不靠祈祷上线。

企业既有的制度、办法、细则——判定依据的唯一来源。

8 实体 / 24 规则 / 3 例外 / 7 参数，每条规则逐条溯源制度条款。

判定路径零 LLM，微秒级；三值逻辑，缺字段即转人工。

rule_id · 字段级证据链 · 制度条款出处，逐条可回查。

AI 只在边缘：LLM 只用于制度抽取（制度 → 本体初稿）与答案转写，从不参与判定本身。

Ontos 不替换你的 Agent，而是给它装上规则大脑。团队在用的这些 Agent 平台，都可以成为 Ontos 的入口：

一段安装 prompt 自建薄路由技能；真机双执行模式（本地 / 云电脑）全部验收通过。

/api/agent/judge 支持 ref / context 双形态入参，Bearer 认证，任何系统可直连。

stdio server，真 MCP 客户端握手 / 发现 / 调用 E2E 通过，标准协议对接 MCP 宿主。

接入靠三条标准通道，不为任何平台单独开发：一段安装 prompt（豆包已真机双模式验收）、 HTTP API、MCP 标准协议——能发请求或说 MCP 的 Agent 就能接。

当前场景示例：财务四流合一审核——合同流、发票流、资金流、货物流的一致性判定。

GET /api/health · GET /api/scenarios · POST /api/agent/judge (Bearer)

客户协作门户请使用顾问发您的专属链接；链接遗失请联系您的 Ontos 顾问。