Day 3 语义本体 MVP

这一天把自然语言问题统一切成 8 个核心字段。Day 3 不是追求大模型多聪明，而是先让结构稳定、可落日志、可被 Orchestrator、User Agent 和 Hermes 共用。

上游依赖

Day 1 的 SemanticParseLog / AgentRun，Day 2 的资产 API。

下游交接

Day 4 路由、Day 5 查询解释、Day 6 风险巡检都直接消费这 8 字段。

当天关键

名字统一、类型统一、日志统一、低置信度有澄清问题。

Three-Layer Mapping

三层文档映射

路线图

周计划要求建立用户问题的统一语义解析层，覆盖场景、意图、对象、时间、指标、约束、风险、权限 8 字段。

day_3_semantic_ontology_mvp.md

执行细则

执行层拆成 8 字段定义、字段枚举、Schema、解析服务、对象提取、时间范围、指标约束、风险权限、API、前端调试入口和评测集。

agent week plan/day_3

架构依据

主要受语义本体、财务标准模型和数据治理约束。应收、应付、报销的对象语义必须能回到最小业务表和标准对象。

02 14 06

Build Order

今天必须产出的东西

8 字段统一结构

scenario、intent、entities、time_range
metrics、constraints、risk_flags、permission
附带 confidence、clarification_required、run_id

规则解析优先版

先用关键词和规则解析打底。
报销 / 应收 / 应付 / 知识 / unknown 场景都能落到结构。
越权动作能识别为 approval_required 或 forbidden。

日志和调试入口

每次解析都要落 SemanticParseLog。
前端可直接输入一句话看 8 字段结果。
低置信度问题必须给澄清问题。

最小评测集

至少覆盖报销、应收、应付、知识、越权动作。
每条样例要写期望 scenario、intent 和权限级别。
当天目标是可评测，而不是追求完美准确率。

Acceptance Snapshot

验收快照

语义结构

8 字段在 Schema、服务层、日志里名字完全一致。

关键识别

“本周报销超标风险”“客户 A 本月应收”“供应商 B 明天要付多少钱”都能落到正确场景和意图。

权限结果

“帮我直接付款”不能被识别成可直接执行动作。

日志与前端

连续调用多次都能在日志中查到，并能通过调试入口观察结果。

Common Misses

这一天最容易漏掉的点

字段结构和日志结构各写一套名字，后面 Trace 很难串。
只做 scenario 和 intent，不做 permission，Day 4 会直接失去拦截依据。
只在服务里返回结果，不把解析过程落库或落日志，后续无法复盘误判样例。