D1 Day 1 View
返回总览 周计划原文 合并文档原文
Foundation Completed

# Day 1 基础模型与工程骨架

这一天的任务不是做炫目的业务能力，而是把后面 6 天要反复依赖的模型、版本、审核、run trace、审计日志和最小业务数据源一次定稳。Day 1 做虚了，Day 4 到 Day 6 会全部返工。

当前状态
已完成（2026-05-11），可直接进入 Day 2 联调。
上游依赖
无，Day 1 是全周底座。
下游交接
Day 2 资产 API，Day 3 解析日志，Day 4 run trace，Day 5/6 业务数据查询。
当天关键
先确定统一模型，再接 API 骨架和种子数据。
Three-Layer Mapping

## 三层文档映射

### 路线图

周计划里定义这一天要完成“工程地基”，强调只做稳定模型、API 骨架、种子数据、基础审计和可运行验证。

day_1_foundation_models.md

### 执行细则

执行层把 Day 1 拆成命名边界、最小财务业务数据模型、Agent 资产模型、版本、审核、Run、ToolCall、SemanticParseLog、AuditLog、Schema、API、服务层。

agent week plan/day_1

### 架构依据

主要受总体架构、语义本体、数据契约、能力注册、权限确认、可观测性和财务标准模型约束。

01 02 06 07 08 09 14
Build Order

## 推荐开发顺序

Step 1先确认后端目录、ORM、迁移方式、测试目录和不该碰的文件。
Step 2统一命名：资产类型、状态、审核状态、Agent、权限级别。
Step 3补最小财务业务数据模型：`expense_claims`、`accounts_receivable`、`accounts_payable`。
Step 4完成 AgentAsset、Version、Review、Run、ToolCall、ParseLog、AuditLog。
Step 5把 Schema、API 骨架、服务层、种子数据接起来。
Must Deliver

## 今天必须产出的东西

### 平台底座表

- `AgentAsset`、`AgentAssetVersion`、`AgentAssetReview`
- `AgentRun`、`AgentToolCall`、`SemanticParseLog`
- `AuditLog`

### 最小业务数据来源

- 报销至少有时间、地点、理由、金额、员工、部门、状态。
- 应收至少有客户、金额、未收金额、到期日、账龄、状态。
- 应付至少有供应商、金额、未付金额、到期日、账龄、状态。

### API 骨架

- 资产列表 / 详情 / 版本 / 审核 / 上线。
- 运行日志与审计日志查询。
- 返回真实数据库结果，不用前端硬编码收尾。

### 统一服务边界

- 上线拦截逻辑在服务层，不堆到路由。
- 所有写操作要留审计接口。
- 任何 Agent 执行记录都必须生成 `run_id`。

Acceptance Snapshot

## 验收快照

资产模型
已落地 3 条规则、2 条技能、2 条 MCP、3 条任务，并可通过资产接口返回。
版本与审核
三条规则都具备版本历史；同一资产版本号不可重复，未审核规则不能上线。
运行与错误
`GET /api/v1/agent-runs` 可返回 3 条运行日志，任意新建 Run 自动生成 `run_id`。
最小业务表
报销、应收、应付种子数据已就位，后续查询和风险巡检都有明确数据来源。
Common Misses

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

- 只建 Agent 表，不建最小财务业务表，导致 User Agent 和 Hermes 后面无数据可查。
- 把审核拦截塞在 API 路由里，后面很难复用到 Orchestrator 和别的入口。
- 没有统一 `run_id` 和审计接口，Day 4 到 Day 7 的 Trace 会断链。