D5 Day 5 View
返回总览 周计划原文 合并文档原文
User Agent

# 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

## 推荐开发顺序

Step 1先定 `UserAgentRequest` / `UserAgentResponse` 协议。
Step 2优先实现报销、应收、应付查询处理器。
Step 3补规则解释和风险解释，让回答有依据而不是只给一句话。
Step 4补草稿生成与知识读取骨架。
Step 5最后接前端问答入口、加载态、错误态和确认提示。
Must Deliver

## 今天必须产出的东西

### 三类财务查询

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

### 解释能力

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

### 草稿而非执行

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

### 用户入口

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

Acceptance Snapshot

## 验收快照

问答闭环
用户在页面上能完成一次自然语言提问、拿到回答、看到引用和 run_id。
三类场景
至少报销、应收、应付三类财务问题都有结构化回答。
引用能力
“为什么这笔报销有风险”这类问题能引用规则，而不是只给模糊判断。
安全边界
“直接付款”“直接审批”类提示不会自动执行，只能变成建议或草稿。
Common Misses

## 这一天最容易漏掉的点

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