D1Day 1 View
返回总览 周计划原文 合并文档原文
Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7
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

这一天最容易漏掉的点

Day 1 的判断标准很简单：不是“代码写了多少”，而是“后面 6 天会不会反复回头补地基”。