Day 5 User Agent MVP

这一天开始让“用户真的能问问题”。但 User Agent 只负责查询、解释、规则引用和草稿生成，绝不绕过权限做审批、付款、上线这类高风险动作。

上游依赖

Day 4 Orchestrator、Day 3 语义结构、Day 1 业务数据与日志模型、Day 2 规则资产。

下游交接

Day 7 要拿它做问答演示、规则解释演示和草稿生成演示。

当天关键

回答可读、引用可追溯、草稿可确认、高风险不自动执行。

Three-Layer Mapping

三层文档映射

路线图

周计划要求做用户自然语言入口、报销 / 应收 / 应付查询解释、规则引用解释、建议草稿和前端入口。

day_5_user_agent_mvp.md

执行细则

执行层拆成输入输出、查询处理、规则解释、风险解释、草稿生成、知识库读取骨架、对话入口、安全边界和测试。

agent week plan/day_5

架构依据

主要受 Agent 职责划分、运行时流程、知识架构和规则形成生命周期约束。所有高风险动作只能停留在建议或草稿层。

03 04 12 13

Build Order

今天必须产出的东西

三类财务查询

报销查询可读，能查金额、状态或进度。
应收查询可读，能查客户未收金额或账龄。
应付查询可读，能查供应商待付款或付款状态。

解释能力

规则解释能引用 active 规则、版本号和更新时间。
风险解释能说明风险类型、原因和建议动作。
知识库不可用时要优雅降级。

草稿而非执行

可生成报销处理意见草稿、应收催收建议草稿、应付付款建议草稿。
草稿必须写明“待人工确认”。
草稿行为写入审计日志和 AgentRun 结果。

用户入口

前端输入框走 Orchestrator，不绕行。
显示回答、引用、建议动作、确认提示和 run_id。
有加载态和错误态。

Acceptance Snapshot

验收快照

问答闭环

用户在页面上能完成一次自然语言提问、拿到回答、看到引用和 run_id。

三类场景

至少报销、应收、应付三类财务问题都有结构化回答。

引用能力

“为什么这笔报销有风险”这类问题能引用规则，而不是只给模糊判断。

安全边界

“直接付款”“直接审批”类提示不会自动执行，只能变成建议或草稿。

Common Misses

这一天最容易漏掉的点

只返回原始查询数据，不把结果翻译成用户可读回答。
只做草稿内容，不做 requires_confirmation 和审计日志。
绕过 Orchestrator 直接从前端打 User Agent，导致 Day 4 的统一链路失效。