feat: 重构 AuditView 支持规则/技能分类,新增 Agent 开发文档
This commit is contained in:
105
document/development/agent week plan/00_README.md
Normal file
105
document/development/agent week plan/00_README.md
Normal file
@@ -0,0 +1,105 @@
|
||||
# Agent Week Plan 一周开发计划
|
||||
|
||||
本目录是在 `document/development/agent plan` 架构文档基础上拆出的 7 天生产标准开发计划。
|
||||
|
||||
这版文档不是概念说明,而是给 Codex 或开发人员逐项执行的 TODO 手册。执行时必须按顺序推进,每完成一项就在对应文档中标记。
|
||||
|
||||
## 执行标记规则
|
||||
|
||||
未完成:
|
||||
|
||||
```md
|
||||
- [ ] 建立 AgentAsset 数据模型
|
||||
```
|
||||
|
||||
完成后:
|
||||
|
||||
```md
|
||||
- [x] ~~建立 AgentAsset 数据模型~~
|
||||
```
|
||||
|
||||
执行要求:
|
||||
|
||||
- [ ] 每次只处理一个最小 TODO。
|
||||
- [ ] 完成后先自测,再改成 `[x]`。
|
||||
- [ ] 改成 `[x]` 时,同时用 `~~` 画线。
|
||||
- [ ] 不能因为代码写完就标完成,必须满足该 TODO 的验收证据。
|
||||
- [ ] 遇到阻塞时,在当天文档的“阻塞记录”下新增一条说明。
|
||||
- [ ] 每天收尾时更新当天文档的“日终交接”。
|
||||
|
||||
## 文档顺序
|
||||
|
||||
先看总控清单,再进入每天的执行文档:
|
||||
|
||||
1. [MASTER_TODO.md](./MASTER_TODO.md)
|
||||
2. [day_1_foundation_models.md](./day_1_foundation_models.md)
|
||||
3. [day_2_rule_center_integration.md](./day_2_rule_center_integration.md)
|
||||
4. [day_3_semantic_ontology_mvp.md](./day_3_semantic_ontology_mvp.md)
|
||||
5. [day_4_orchestrator_runtime.md](./day_4_orchestrator_runtime.md)
|
||||
6. [day_5_user_agent_mvp.md](./day_5_user_agent_mvp.md)
|
||||
7. [day_6_hermes_mvp.md](./day_6_hermes_mvp.md)
|
||||
8. [day_7_hardening_demo_acceptance.md](./day_7_hardening_demo_acceptance.md)
|
||||
|
||||
## 一周总目标
|
||||
|
||||
- [ ] 建立规则、技能、MCP、任务的统一资产模型。
|
||||
- [ ] 建立规则 Markdown 内容、版本、审核、上线状态的闭环。
|
||||
- [ ] 建立语义本体 8 字段解析接口。
|
||||
- [ ] 建立 Orchestrator 路由和 Agent Run Trace。
|
||||
- [ ] 建立 User Agent 的查询、解释、流程辅助 MVP。
|
||||
- [ ] 建立 Hermes 的定时风险巡检和日报 MVP。
|
||||
- [ ] 建立基础权限分级、人工确认、审计日志。
|
||||
- [ ] 建立最小评测集、手动验收脚本和演示流程。
|
||||
|
||||
## 一周暂不做
|
||||
|
||||
- [ ] 不做完整 OCR 生产识别引擎,只预留标准接口和 Mock 结果。
|
||||
- [ ] 不做完整发票验真 MCP 深度接入,只做能力注册和 Mock 调用。
|
||||
- [ ] 不做完整 LLM Wiki 向量检索,只做知识条目写入和读取骨架。
|
||||
- [ ] 不做所有财务域数据全量打通,只覆盖报销、应收、应付的最小字段。
|
||||
- [ ] 不做规则自动上线,规则只能生成草稿,必须人工审核。
|
||||
- [ ] 不做完整 CI/CD,只做本地构建、核心测试和验收脚本。
|
||||
|
||||
## 生产底线
|
||||
|
||||
以下底线不得被 MVP 名义绕过:
|
||||
|
||||
- [ ] 所有写操作必须记录审计日志。
|
||||
- [ ] 所有 Agent 执行必须生成 `run_id`。
|
||||
- [ ] 所有规则必须有版本。
|
||||
- [ ] 未审核规则不能上线。
|
||||
- [ ] 高风险动作只能生成草稿或建议,不能自动提交。
|
||||
- [ ] 外部服务失败必须有降级结果。
|
||||
- [ ] 语义解析结果必须落库或落日志,便于回放。
|
||||
- [ ] 前端不能只写静态 UI,必须至少对接 Mock 或真实 API。
|
||||
|
||||
## 每日固定流程
|
||||
|
||||
上午:
|
||||
|
||||
- [ ] 读取当天文档。
|
||||
- [ ] 检查前一天遗留阻塞。
|
||||
- [ ] 确认数据库模型、API、服务边界。
|
||||
- [ ] 完成后端主路径。
|
||||
|
||||
下午:
|
||||
|
||||
- [ ] 完成前端联调。
|
||||
- [ ] 接入 Agent 或 Orchestrator 流程。
|
||||
- [ ] 完成权限、审计、错误态。
|
||||
|
||||
傍晚:
|
||||
|
||||
- [ ] 运行测试和构建。
|
||||
- [ ] 按当天验收清单逐项验收。
|
||||
- [ ] 更新 TODO 完成状态。
|
||||
- [ ] 填写日终交接。
|
||||
|
||||
## Codex 执行约束
|
||||
|
||||
- [ ] 修改代码前先读相关文件,不凭空创建重复模块。
|
||||
- [ ] 优先复用现有 FastAPI、SQLAlchemy、Vue、PrimeVue 写法。
|
||||
- [ ] API 命名必须稳定,不能一天一个风格。
|
||||
- [ ] 数据模型新增字段必须写清楚用途。
|
||||
- [ ] 前端状态、空态、错误态、加载态都要覆盖。
|
||||
- [ ] 每天结束必须能给出可运行证据。
|
||||
119
document/development/agent week plan/MASTER_TODO.md
Normal file
119
document/development/agent week plan/MASTER_TODO.md
Normal file
@@ -0,0 +1,119 @@
|
||||
# Agent Week Plan 总控 TODO
|
||||
|
||||
本文件用于控制 7 天开发顺序。每个大项完成后,再进入对应天的详细文档。
|
||||
|
||||
完成标记规则:
|
||||
|
||||
```md
|
||||
- [x] ~~已完成的任务~~
|
||||
```
|
||||
|
||||
## Day 1:基础模型与工程骨架
|
||||
|
||||
- [ ] 阅读 `document/development/agent plan/01_overall_architecture.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/02_semantic_ontology.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/06_data_contracts_and_governance.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/07_capability_registry.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/08_permission_confirmation.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/09_observability_and_trace.md`。
|
||||
- [ ] 完成统一资产模型 `AgentAsset`。
|
||||
- [ ] 完成资产版本模型 `AgentAssetVersion`。
|
||||
- [ ] 完成资产审核模型 `AgentAssetReview`。
|
||||
- [ ] 完成 Agent 运行日志模型 `AgentRun`。
|
||||
- [ ] 完成工具调用日志模型 `AgentToolCall`。
|
||||
- [ ] 完成语义解析日志模型 `SemanticParseLog`。
|
||||
- [ ] 完成审计日志模型 `AuditLog`。
|
||||
- [ ] 完成基础 API 路由骨架。
|
||||
- [ ] 完成种子数据。
|
||||
- [ ] 完成 Day 1 验收。
|
||||
|
||||
## Day 2:任务规则中心联调
|
||||
|
||||
- [ ] 阅读 `document/development/agent plan/13_rule_formation_lifecycle.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/07_capability_registry.md`。
|
||||
- [ ] 对接规则、技能、MCP、任务资产列表 API。
|
||||
- [ ] 对接资产详情 API。
|
||||
- [ ] 对接规则 Markdown 读取和保存 API。
|
||||
- [ ] 对接版本列表和版本切换 API。
|
||||
- [ ] 对接审核者信息和审核状态。
|
||||
- [ ] 对接规则上线前审核拦截。
|
||||
- [ ] 完成前端筛选、搜索、详情、弹窗状态。
|
||||
- [ ] 完成 Day 2 验收。
|
||||
|
||||
## Day 3:语义本体 MVP
|
||||
|
||||
- [ ] 阅读 `document/development/agent plan/02_semantic_ontology.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/14_financial_document_canonical_model.md`。
|
||||
- [ ] 定义 8 个核心字段的数据结构。
|
||||
- [ ] 实现语义解析服务。
|
||||
- [ ] 实现语义解析 API。
|
||||
- [ ] 实现解析日志保存。
|
||||
- [ ] 实现场景、意图、对象、时间、指标、约束、风险、权限字段。
|
||||
- [ ] 接入 User Agent 查询入口。
|
||||
- [ ] 完成最小评测集。
|
||||
- [ ] 完成 Day 3 验收。
|
||||
|
||||
## Day 4:Orchestrator 运行时
|
||||
|
||||
- [ ] 阅读 `document/development/agent plan/04_orchestrator_and_runtime_flow.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/08_permission_confirmation.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/09_observability_and_trace.md`。
|
||||
- [ ] 实现 Orchestrator 入口服务。
|
||||
- [ ] 实现语义本体到 Agent 路由。
|
||||
- [ ] 实现权限级别判断。
|
||||
- [ ] 实现工具调用封装。
|
||||
- [ ] 实现运行 Trace。
|
||||
- [ ] 实现降级和错误返回。
|
||||
- [ ] 完成 Day 4 验收。
|
||||
|
||||
## Day 5:User Agent MVP
|
||||
|
||||
- [ ] 阅读 `document/development/agent plan/03_agent_responsibilities.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/12_llm_wiki_knowledge_architecture.md`。
|
||||
- [ ] 实现用户自然语言入口。
|
||||
- [ ] 实现报销查询解释流程。
|
||||
- [ ] 实现应收账款查询解释流程。
|
||||
- [ ] 实现应付账款查询解释流程。
|
||||
- [ ] 实现规则引用解释。
|
||||
- [ ] 实现建议草稿输出。
|
||||
- [ ] 完成前端对话或操作入口。
|
||||
- [ ] 完成 Day 5 验收。
|
||||
|
||||
## Day 6:Hermes MVP
|
||||
|
||||
- [ ] 阅读 `document/development/agent plan/03_agent_responsibilities.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/11_ocr_invoice_architecture.md`。
|
||||
- [ ] 阅读 `document/development/agent plan/15_feedback_learning_loop.md`。
|
||||
- [ ] 实现任务资产调度入口。
|
||||
- [ ] 实现每日风险巡检任务。
|
||||
- [ ] 实现每日报销/报账/账款统计任务。
|
||||
- [ ] 实现知识库维护任务。
|
||||
- [ ] 实现 OCR Mock 接入点。
|
||||
- [ ] 实现 Hermes 运行结果面板或 API。
|
||||
- [ ] 完成 Day 6 验收。
|
||||
|
||||
## Day 7:加固、演示和验收
|
||||
|
||||
- [ ] 回归 Day 1 到 Day 6 所有核心路径。
|
||||
- [ ] 补齐权限拦截。
|
||||
- [ ] 补齐审计日志。
|
||||
- [ ] 补齐错误态和空态。
|
||||
- [ ] 补齐评测用例。
|
||||
- [ ] 补齐演示数据。
|
||||
- [ ] 完成构建。
|
||||
- [ ] 完成一周交付说明。
|
||||
- [ ] 完成 Day 7 验收。
|
||||
|
||||
## 一周最终验收
|
||||
|
||||
- [ ] 能从任务规则中心看到规则、技能、MCP、任务。
|
||||
- [ ] 能打开规则详情,编辑 Markdown,查看版本,切换版本。
|
||||
- [ ] 未审核规则不能上线。
|
||||
- [ ] 能输入一句自然语言问题并得到语义本体 8 字段结果。
|
||||
- [ ] 能由 Orchestrator 路由到 User Agent。
|
||||
- [ ] 能由 Hermes 执行一次模拟定时任务。
|
||||
- [ ] 能查看 Agent Run Trace。
|
||||
- [ ] 能查看工具调用日志。
|
||||
- [ ] 能查看审计日志。
|
||||
- [ ] 能运行核心测试。
|
||||
- [ ] 能完成演示脚本。
|
||||
316
document/development/agent week plan/day_1_foundation_models.md
Normal file
316
document/development/agent week plan/day_1_foundation_models.md
Normal file
@@ -0,0 +1,316 @@
|
||||
# Day 1:基础模型与工程骨架 TODO
|
||||
|
||||
目标:建立后续 6 天开发所需的后端地基。Day 1 不做复杂业务逻辑,只做稳定模型、API 骨架、种子数据、基础审计和可运行验证。
|
||||
|
||||
参考文档:
|
||||
|
||||
- `document/development/agent plan/01_overall_architecture.md`
|
||||
- `document/development/agent plan/02_semantic_ontology.md`
|
||||
- `document/development/agent plan/06_data_contracts_and_governance.md`
|
||||
- `document/development/agent plan/07_capability_registry.md`
|
||||
- `document/development/agent plan/08_permission_confirmation.md`
|
||||
- `document/development/agent plan/09_observability_and_trace.md`
|
||||
|
||||
## 0. 开始前检查
|
||||
|
||||
- [ ] 确认当前分支和工作区状态。
|
||||
- [ ] 确认后端目录位置,例如 `/app/server`。
|
||||
- [ ] 确认前端目录位置,例如 `/app/web`。
|
||||
- [ ] 确认后端使用的框架、ORM、迁移方式。
|
||||
- [ ] 找到现有数据库模型目录。
|
||||
- [ ] 找到现有 API 路由目录。
|
||||
- [ ] 找到现有启动入口。
|
||||
- [ ] 找到现有测试目录。
|
||||
- [ ] 找到现有种子数据或初始化脚本。
|
||||
- [ ] 记录不应修改的无关文件。
|
||||
|
||||
## 1. 统一命名和边界
|
||||
|
||||
- [ ] 确认统一模块名使用 `agent_assets`。
|
||||
- [ ] 确认资产类型枚举为 `rule`、`skill`、`mcp`、`task`。
|
||||
- [ ] 确认资产状态枚举为 `draft`、`review`、`active`、`disabled`。
|
||||
- [ ] 确认审核状态枚举为 `pending`、`approved`、`rejected`。
|
||||
- [ ] 确认 Agent 枚举为 `orchestrator`、`user_agent`、`hermes`。
|
||||
- [ ] 确认运行来源枚举为 `user_message`、`schedule`、`system_event`。
|
||||
- [ ] 确认权限级别枚举为 `read`、`draft_write`、`approval_required`、`forbidden`。
|
||||
- [ ] 确认所有主键、外键、时间字段命名符合现有代码风格。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 枚举命名在模型、Schema、服务层保持一致。
|
||||
- [ ] 没有同时出现 `schedule` 和 `task` 两套用户可见命名。
|
||||
|
||||
## 2. 建立 AgentAsset 模型
|
||||
|
||||
- [ ] 新增或扩展模型文件,定义 `AgentAsset`。
|
||||
- [ ] 增加字段 `id`。
|
||||
- [ ] 增加字段 `asset_type`,取值 `rule | skill | mcp | task`。
|
||||
- [ ] 增加字段 `code`,作为业务编码。
|
||||
- [ ] 增加字段 `name`。
|
||||
- [ ] 增加字段 `description`。
|
||||
- [ ] 增加字段 `domain`,例如 `expense | ar | ap | knowledge | system`。
|
||||
- [ ] 增加字段 `scenario_json`,保存适用场景。
|
||||
- [ ] 增加字段 `owner`。
|
||||
- [ ] 增加字段 `reviewer`。
|
||||
- [ ] 增加字段 `status`。
|
||||
- [ ] 增加字段 `current_version`。
|
||||
- [ ] 增加字段 `config_json`。
|
||||
- [ ] 增加字段 `created_at`。
|
||||
- [ ] 增加字段 `updated_at`。
|
||||
- [ ] 给 `code` 增加唯一约束。
|
||||
- [ ] 给 `asset_type` 增加索引。
|
||||
- [ ] 给 `status` 增加索引。
|
||||
- [ ] 给 `domain` 增加索引。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 能创建一条规则资产。
|
||||
- [ ] 能创建一条技能资产。
|
||||
- [ ] 能创建一条 MCP 资产。
|
||||
- [ ] 能创建一条任务资产。
|
||||
|
||||
## 3. 建立 AgentAssetVersion 模型
|
||||
|
||||
- [ ] 定义 `AgentAssetVersion`。
|
||||
- [ ] 增加字段 `id`。
|
||||
- [ ] 增加字段 `asset_id`。
|
||||
- [ ] 增加字段 `version`,例如 `v1.0.0`。
|
||||
- [ ] 增加字段 `content`。
|
||||
- [ ] 增加字段 `content_type`,取值 `markdown | json`。
|
||||
- [ ] 增加字段 `change_note`。
|
||||
- [ ] 增加字段 `created_by`。
|
||||
- [ ] 增加字段 `created_at`。
|
||||
- [ ] 增加 `asset_id + version` 唯一约束。
|
||||
- [ ] 建立 `AgentAsset` 到 `AgentAssetVersion` 的关系。
|
||||
- [ ] 约定规则资产的 `content` 保存 Markdown。
|
||||
- [ ] 约定技能、MCP、任务资产的 `content` 保存 JSON 快照。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 同一个资产不能重复创建同一个版本号。
|
||||
- [ ] 资产详情能拿到最近 5 个版本。
|
||||
|
||||
## 4. 建立 AgentAssetReview 模型
|
||||
|
||||
- [ ] 定义 `AgentAssetReview`。
|
||||
- [ ] 增加字段 `id`。
|
||||
- [ ] 增加字段 `asset_id`。
|
||||
- [ ] 增加字段 `version`。
|
||||
- [ ] 增加字段 `reviewer`。
|
||||
- [ ] 增加字段 `review_status`。
|
||||
- [ ] 增加字段 `review_note`。
|
||||
- [ ] 增加字段 `reviewed_at`。
|
||||
- [ ] 增加字段 `created_at`。
|
||||
- [ ] 建立资产、版本、审核之间的查询关系。
|
||||
- [ ] 增加服务层校验:没有 `approved` 审核时不能把规则置为 `active`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] `pending` 规则上线会被拒绝。
|
||||
- [ ] `rejected` 规则上线会被拒绝。
|
||||
- [ ] `approved` 规则可以上线。
|
||||
|
||||
## 5. 建立 AgentRun 模型
|
||||
|
||||
- [ ] 定义 `AgentRun`。
|
||||
- [ ] 增加字段 `id`。
|
||||
- [ ] 增加字段 `run_id`。
|
||||
- [ ] 增加字段 `agent`。
|
||||
- [ ] 增加字段 `source`。
|
||||
- [ ] 增加字段 `user_id`。
|
||||
- [ ] 增加字段 `task_id`。
|
||||
- [ ] 增加字段 `ontology_json`。
|
||||
- [ ] 增加字段 `route_json`。
|
||||
- [ ] 增加字段 `permission_level`。
|
||||
- [ ] 增加字段 `status`,取值 `running | succeeded | failed | blocked`。
|
||||
- [ ] 增加字段 `result_summary`。
|
||||
- [ ] 增加字段 `error_message`。
|
||||
- [ ] 增加字段 `started_at`。
|
||||
- [ ] 增加字段 `finished_at`。
|
||||
- [ ] 给 `run_id` 增加唯一约束。
|
||||
- [ ] 给 `agent`、`status`、`started_at` 增加索引。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 创建任意 Agent 执行记录时必须生成 `run_id`。
|
||||
- [ ] 失败执行能保存错误信息。
|
||||
|
||||
## 6. 建立 AgentToolCall 模型
|
||||
|
||||
- [ ] 定义 `AgentToolCall`。
|
||||
- [ ] 增加字段 `id`。
|
||||
- [ ] 增加字段 `run_id`。
|
||||
- [ ] 增加字段 `tool_type`,例如 `mcp | database | llm | ocr | rule_engine`。
|
||||
- [ ] 增加字段 `tool_name`。
|
||||
- [ ] 增加字段 `request_json`。
|
||||
- [ ] 增加字段 `response_json`。
|
||||
- [ ] 增加字段 `status`。
|
||||
- [ ] 增加字段 `duration_ms`。
|
||||
- [ ] 增加字段 `error_message`。
|
||||
- [ ] 增加字段 `created_at`。
|
||||
- [ ] 建立 `AgentRun` 到 `AgentToolCall` 的关系。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 一个 `run_id` 下可以记录多个工具调用。
|
||||
- [ ] 工具调用失败时不影响主运行日志保存。
|
||||
|
||||
## 7. 建立 SemanticParseLog 模型
|
||||
|
||||
- [ ] 定义 `SemanticParseLog`。
|
||||
- [ ] 增加字段 `id`。
|
||||
- [ ] 增加字段 `run_id`。
|
||||
- [ ] 增加字段 `user_id`。
|
||||
- [ ] 增加字段 `raw_query`。
|
||||
- [ ] 增加字段 `scenario`。
|
||||
- [ ] 增加字段 `intent`。
|
||||
- [ ] 增加字段 `entities_json`。
|
||||
- [ ] 增加字段 `time_range_json`。
|
||||
- [ ] 增加字段 `metrics_json`。
|
||||
- [ ] 增加字段 `constraints_json`。
|
||||
- [ ] 增加字段 `risk_flags_json`。
|
||||
- [ ] 增加字段 `permission_json`。
|
||||
- [ ] 增加字段 `confidence`。
|
||||
- [ ] 增加字段 `created_at`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 能保存一条完整 8 字段语义解析日志。
|
||||
- [ ] 能按 `run_id` 查询语义解析结果。
|
||||
|
||||
## 8. 建立 AuditLog 模型
|
||||
|
||||
- [ ] 定义 `AuditLog`。
|
||||
- [ ] 增加字段 `id`。
|
||||
- [ ] 增加字段 `actor`。
|
||||
- [ ] 增加字段 `action`。
|
||||
- [ ] 增加字段 `resource_type`。
|
||||
- [ ] 增加字段 `resource_id`。
|
||||
- [ ] 增加字段 `before_json`。
|
||||
- [ ] 增加字段 `after_json`。
|
||||
- [ ] 增加字段 `request_id`。
|
||||
- [ ] 增加字段 `created_at`。
|
||||
- [ ] 为规则保存、审核、上线、任务执行创建审计记录接口。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 保存规则 Markdown 时有审计日志。
|
||||
- [ ] 审核规则时有审计日志。
|
||||
- [ ] 修改任务状态时有审计日志。
|
||||
|
||||
## 9. 建立 Schema / DTO
|
||||
|
||||
- [ ] 定义 `AgentAssetCreate`。
|
||||
- [ ] 定义 `AgentAssetUpdate`。
|
||||
- [ ] 定义 `AgentAssetRead`。
|
||||
- [ ] 定义 `AgentAssetListItem`。
|
||||
- [ ] 定义 `AgentAssetVersionRead`。
|
||||
- [ ] 定义 `AgentAssetReviewRead`。
|
||||
- [ ] 定义 `RuleMarkdownUpdate`。
|
||||
- [ ] 定义 `AgentRunRead`。
|
||||
- [ ] 定义 `AgentToolCallRead`。
|
||||
- [ ] 定义 `SemanticParseRead`。
|
||||
- [ ] 所有 JSON 字段在 DTO 中保持结构化,不返回字符串化 JSON。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] OpenAPI 文档能展示新增 Schema。
|
||||
- [ ] 列表 DTO 不返回大块 Markdown 内容。
|
||||
- [ ] 详情 DTO 返回当前版本内容。
|
||||
|
||||
## 10. 建立 API 骨架
|
||||
|
||||
- [ ] 新增 `GET /api/agent-assets`。
|
||||
- [ ] 新增 `GET /api/agent-assets/{asset_id}`。
|
||||
- [ ] 新增 `POST /api/agent-assets`。
|
||||
- [ ] 新增 `PATCH /api/agent-assets/{asset_id}`。
|
||||
- [ ] 新增 `GET /api/agent-assets/{asset_id}/versions`。
|
||||
- [ ] 新增 `POST /api/agent-assets/{asset_id}/versions`。
|
||||
- [ ] 新增 `POST /api/agent-assets/{asset_id}/reviews`。
|
||||
- [ ] 新增 `POST /api/agent-assets/{asset_id}/activate`。
|
||||
- [ ] 新增 `GET /api/agent-runs`。
|
||||
- [ ] 新增 `GET /api/agent-runs/{run_id}`。
|
||||
- [ ] 新增 `GET /api/audit-logs`。
|
||||
- [ ] 所有接口先返回真实数据库结果,不使用前端硬编码数据作为最终结果。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 能调用资产列表接口。
|
||||
- [ ] 能调用资产详情接口。
|
||||
- [ ] 能调用版本接口。
|
||||
- [ ] 能调用运行日志接口。
|
||||
|
||||
## 11. 建立服务层
|
||||
|
||||
- [ ] 新增资产查询服务。
|
||||
- [ ] 新增资产保存服务。
|
||||
- [ ] 新增版本创建服务。
|
||||
- [ ] 新增审核服务。
|
||||
- [ ] 新增上线校验服务。
|
||||
- [ ] 新增 Agent Run 创建服务。
|
||||
- [ ] 新增 Tool Call 记录服务。
|
||||
- [ ] 新增审计日志服务。
|
||||
- [ ] 所有服务函数返回明确错误,不直接把数据库异常暴露给前端。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] API 路由中不堆业务判断。
|
||||
- [ ] 上线校验逻辑在服务层。
|
||||
- [ ] 审计日志通过统一服务写入。
|
||||
|
||||
## 12. 建立种子数据
|
||||
|
||||
- [ ] 创建至少 3 条规则资产。
|
||||
- [ ] 每条规则资产至少有 2 个版本。
|
||||
- [ ] 至少 1 条规则为 `active`。
|
||||
- [ ] 至少 1 条规则为 `review`。
|
||||
- [ ] 至少 1 条规则为 `draft`。
|
||||
- [ ] 创建至少 2 条技能资产。
|
||||
- [ ] 创建至少 2 条 MCP 资产。
|
||||
- [ ] 创建至少 3 条任务资产。
|
||||
- [ ] 为 active 规则创建 approved 审核记录。
|
||||
- [ ] 为 review 规则创建 pending 审核记录。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 资产列表按类型筛选时四类都有数据。
|
||||
- [ ] 规则详情能看到版本和审核者。
|
||||
|
||||
## 13. 最小测试
|
||||
|
||||
- [ ] 编写资产模型创建测试。
|
||||
- [ ] 编写版本唯一约束测试。
|
||||
- [ ] 编写未审核不能上线测试。
|
||||
- [ ] 编写资产列表接口测试。
|
||||
- [ ] 编写资产详情接口测试。
|
||||
- [ ] 编写 AgentRun 创建测试。
|
||||
- [ ] 编写 AuditLog 写入测试。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 后端核心测试通过。
|
||||
- [ ] 测试失败时能定位到具体服务。
|
||||
|
||||
## 14. Day 1 验收
|
||||
|
||||
- [ ] 数据库能创建所有新增表或等价结构。
|
||||
- [ ] API 服务能启动。
|
||||
- [ ] OpenAPI 能看到新增接口。
|
||||
- [ ] 资产列表接口返回规则、技能、MCP、任务。
|
||||
- [ ] 规则资产有 Markdown 当前版本。
|
||||
- [ ] 规则资产有最近版本列表。
|
||||
- [ ] 未审核规则不能上线。
|
||||
- [ ] AgentRun 能保存一条运行记录。
|
||||
- [ ] AuditLog 能保存一条写操作记录。
|
||||
- [ ] 所有完成项已用 `[x] ~~...~~` 标记。
|
||||
|
||||
## 阻塞记录
|
||||
|
||||
- [ ] 暂无。
|
||||
|
||||
## 日终交接
|
||||
|
||||
- [ ] 写明已完成模型。
|
||||
- [ ] 写明已完成 API。
|
||||
- [ ] 写明未完成问题。
|
||||
- [ ] 写明 Day 2 前端联调需要使用的接口地址。
|
||||
@@ -0,0 +1,220 @@
|
||||
# Day 2:任务规则中心联调 TODO
|
||||
|
||||
目标:把任务规则中心从静态 UI 改成可对接后端的生产形态,覆盖规则、技能、MCP、任务四类资产。重点是规则 Markdown 编辑、版本切换、审核者信息、上线约束。
|
||||
|
||||
参考文档:
|
||||
|
||||
- `document/development/agent plan/07_capability_registry.md`
|
||||
- `document/development/agent plan/13_rule_formation_lifecycle.md`
|
||||
- `document/development/agent plan/06_data_contracts_and_governance.md`
|
||||
|
||||
## 0. 开始前检查
|
||||
|
||||
- [ ] 确认 Day 1 API 已可访问。
|
||||
- [ ] 确认前端任务规则中心文件位置。
|
||||
- [ ] 确认现有路由名称和导航名称。
|
||||
- [ ] 确认现有 UI 风格,不重新做大改版。
|
||||
- [ ] 确认当前页面已有页签:规则、技能、MCP、任务。
|
||||
- [ ] 确认详情页隐藏顶部 title bar 的逻辑仍然有效。
|
||||
- [ ] 确认返回列表栏高度没有被重新拉高。
|
||||
|
||||
## 1. API Client
|
||||
|
||||
- [ ] 新增或扩展资产列表请求函数。
|
||||
- [ ] 新增资产详情请求函数。
|
||||
- [ ] 新增版本列表请求函数。
|
||||
- [ ] 新增规则 Markdown 保存请求函数。
|
||||
- [ ] 新增审核请求函数。
|
||||
- [ ] 新增上线请求函数。
|
||||
- [ ] 新增运行日志请求函数。
|
||||
- [ ] 给所有请求增加加载态。
|
||||
- [ ] 给所有请求增加错误态。
|
||||
- [ ] 给所有写请求增加成功提示。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 前端不再只依赖本地硬编码资产数据。
|
||||
- [ ] 后端不可用时页面有明确错误提示。
|
||||
|
||||
## 2. 列表页数据接入
|
||||
|
||||
- [ ] 规则页签请求 `asset_type=rule`。
|
||||
- [ ] 技能页签请求 `asset_type=skill`。
|
||||
- [ ] MCP 页签请求 `asset_type=mcp`。
|
||||
- [ ] 任务页签请求 `asset_type=task`。
|
||||
- [ ] 搜索框传递关键词或本地过滤。
|
||||
- [ ] 类型下拉和搜索框可以同时生效。
|
||||
- [ ] 状态筛选可以过滤 `draft | review | active | disabled`。
|
||||
- [ ] 列表卡片展示名称。
|
||||
- [ ] 列表卡片展示摘要。
|
||||
- [ ] 列表卡片展示状态。
|
||||
- [ ] 列表卡片展示负责人。
|
||||
- [ ] 列表卡片展示最近更新时间。
|
||||
- [ ] 空数据时展示空态。
|
||||
- [ ] 加载中时展示骨架或加载状态。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 四个页签都能切换。
|
||||
- [ ] 四个页签都有数据或空态。
|
||||
- [ ] 搜索和筛选不会互相覆盖。
|
||||
|
||||
## 3. 规则详情页主信息
|
||||
|
||||
- [ ] 打开规则资产时请求详情 API。
|
||||
- [ ] Hero title 展示规则名称。
|
||||
- [ ] Hero title 下方展示审核者。
|
||||
- [ ] Hero title 下方展示审核状态。
|
||||
- [ ] Hero title 下方展示上线条件。
|
||||
- [ ] Hero title 高度保持紧凑。
|
||||
- [ ] 详情页不显示外层顶部 title bar。
|
||||
- [ ] 返回列表栏高度保持原有紧凑高度。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 用户能一眼看到该规则是否已审核。
|
||||
- [ ] 用户不会看到两层 title。
|
||||
|
||||
## 4. Markdown 编辑器
|
||||
|
||||
- [ ] 从当前版本读取 Markdown 内容。
|
||||
- [ ] Markdown 编辑框高度和右侧版本卡片底部对齐。
|
||||
- [ ] Markdown 编辑框支持长内容滚动。
|
||||
- [ ] Markdown 编辑框保存时调用 API。
|
||||
- [ ] 保存后创建新版本或更新草稿版本,按后端约定执行。
|
||||
- [ ] 保存成功后刷新版本列表。
|
||||
- [ ] 保存失败时保留用户输入。
|
||||
- [ ] 编辑器禁用态覆盖 `active` 且无编辑权限的情况。
|
||||
- [ ] 编辑器底部展示最后保存时间。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 编辑 Markdown 后刷新页面内容仍存在。
|
||||
- [ ] 保存失败不会丢内容。
|
||||
- [ ] 左右卡片底部视觉对齐。
|
||||
|
||||
## 5. 版本卡片
|
||||
|
||||
- [ ] 右侧只保留版本信息卡片。
|
||||
- [ ] 版本卡片宽度足够展示版本号、日期、状态。
|
||||
- [ ] 展示最近 5 个版本。
|
||||
- [ ] 当前版本有明显但不突兀的标识。
|
||||
- [ ] 当前版本标识居中显示。
|
||||
- [ ] 选中状态只变色,不改变内容对齐。
|
||||
- [ ] 日期列和其他版本日期对齐。
|
||||
- [ ] 点击非当前版本时弹出确认弹窗。
|
||||
- [ ] 弹窗展示目标版本号。
|
||||
- [ ] 弹窗展示切换风险提示。
|
||||
- [ ] 确认后切换当前展示内容。
|
||||
- [ ] 取消后不改变当前版本。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 版本切换不会造成列表文字位移。
|
||||
- [ ] 当前版本背景能完全覆盖内容区域。
|
||||
- [ ] 版本卡片不贴右侧边界。
|
||||
|
||||
## 6. 审核与上线
|
||||
|
||||
- [ ] 详情中展示审核者姓名。
|
||||
- [ ] 详情中展示审核时间。
|
||||
- [ ] 详情中展示审核意见。
|
||||
- [ ] 未审核规则显示不能上线原因。
|
||||
- [ ] 点击上线时调用后端上线接口。
|
||||
- [ ] 后端拒绝时展示拒绝原因。
|
||||
- [ ] 审核通过后上线按钮可用。
|
||||
- [ ] 审核动作写入审计日志。
|
||||
- [ ] 上线动作写入审计日志。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] pending 规则无法上线。
|
||||
- [ ] approved 规则可以上线。
|
||||
- [ ] rejected 规则无法上线。
|
||||
|
||||
## 7. 技能详情
|
||||
|
||||
- [ ] 技能页签列表展示能力名称。
|
||||
- [ ] 技能详情展示能力说明。
|
||||
- [ ] 技能详情展示输入参数。
|
||||
- [ ] 技能详情展示输出参数。
|
||||
- [ ] 技能详情展示依赖能力。
|
||||
- [ ] 技能详情展示适用场景。
|
||||
- [ ] 技能详情展示负责人。
|
||||
- [ ] 技能详情展示版本。
|
||||
- [ ] 技能详情不使用规则 Markdown 编辑器。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 技能和规则详情不会混用 UI。
|
||||
|
||||
## 8. MCP 详情
|
||||
|
||||
- [ ] MCP 页签列表展示外部服务名称。
|
||||
- [ ] MCP 详情展示服务类型。
|
||||
- [ ] MCP 详情展示调用地址或能力名。
|
||||
- [ ] MCP 详情展示鉴权方式。
|
||||
- [ ] MCP 详情展示超时配置。
|
||||
- [ ] MCP 详情展示降级策略。
|
||||
- [ ] MCP 详情展示最近调用状态。
|
||||
- [ ] MCP 详情展示负责人。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] MCP 被定义为外部服务,而不是技能规则。
|
||||
|
||||
## 9. 任务详情
|
||||
|
||||
- [ ] 任务页签展示定时任务名称。
|
||||
- [ ] 任务详情展示 cron 或调度周期。
|
||||
- [ ] 任务详情展示执行 Agent,默认 Hermes。
|
||||
- [ ] 任务详情展示任务目标。
|
||||
- [ ] 任务详情展示风险等级。
|
||||
- [ ] 任务详情展示最近执行时间。
|
||||
- [ ] 任务详情展示最近执行结果。
|
||||
- [ ] 任务详情展示启停状态。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 定时任务用户可见名称为“任务”。
|
||||
- [ ] 技术字段可保留 `schedule`,但 UI 不显示“定时任务”。
|
||||
|
||||
## 10. 前端质量
|
||||
|
||||
- [ ] 页面在 1366 宽度下无横向滚动。
|
||||
- [ ] 页面在 1920 宽度下右侧卡片不过宽。
|
||||
- [ ] 页面在窄屏下详情区域可滚动。
|
||||
- [ ] 所有按钮有禁用态。
|
||||
- [ ] 所有弹窗有取消按钮。
|
||||
- [ ] 所有表单错误有提示。
|
||||
- [ ] 所有日期格式统一。
|
||||
- [ ] 状态颜色和现有系统一致。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] `npm run build` 通过。
|
||||
- [ ] 任务规则中心手动走查通过。
|
||||
|
||||
## 11. Day 2 验收
|
||||
|
||||
- [ ] 规则、技能、MCP、任务四个页签可用。
|
||||
- [ ] 搜索框和筛选下拉可用。
|
||||
- [ ] 规则详情展示 Markdown。
|
||||
- [ ] 规则 Markdown 可保存。
|
||||
- [ ] 右侧只保留版本信息。
|
||||
- [ ] 版本可切换且有弹窗确认。
|
||||
- [ ] 审核者信息在标题下方。
|
||||
- [ ] 未审核规则不能上线。
|
||||
- [ ] 前端构建通过。
|
||||
- [ ] 所有完成项已用 `[x] ~~...~~` 标记。
|
||||
|
||||
## 阻塞记录
|
||||
|
||||
- [ ] 暂无。
|
||||
|
||||
## 日终交接
|
||||
|
||||
- [ ] 写明已接入的 API。
|
||||
- [ ] 写明仍然使用 Mock 的字段。
|
||||
- [ ] 写明 UI 未完成项。
|
||||
- [ ] 写明 Day 3 语义本体需要复用的资产数据。
|
||||
@@ -0,0 +1,236 @@
|
||||
# Day 3:语义本体 MVP TODO
|
||||
|
||||
目标:建立用户问题的语义解析层,输出稳定的 8 个核心字段,让 User Agent、Hermes 和 Orchestrator 都能使用同一套语义结构。
|
||||
|
||||
参考文档:
|
||||
|
||||
- `document/development/agent plan/02_semantic_ontology.md`
|
||||
- `document/development/agent plan/14_financial_document_canonical_model.md`
|
||||
- `document/development/agent plan/06_data_contracts_and_governance.md`
|
||||
|
||||
## 0. 开始前检查
|
||||
|
||||
- [ ] 确认 Day 1 的 `SemanticParseLog` 可用。
|
||||
- [ ] 确认 Day 1 的 `AgentRun` 可用。
|
||||
- [ ] 确认 Day 2 的资产 API 可用。
|
||||
- [ ] 找到后端服务层目录。
|
||||
- [ ] 找到现有 LLM 调用或 Mock 调用方式。
|
||||
- [ ] 确认当前是否允许真实调用 LLM。
|
||||
- [ ] 如果不能调用真实 LLM,准备规则解析加 Mock 解析。
|
||||
|
||||
## 1. 定义 8 个核心字段
|
||||
|
||||
- [ ] 定义字段 `scenario`,表示业务场景。
|
||||
- [ ] 定义字段 `intent`,表示用户意图。
|
||||
- [ ] 定义字段 `entities`,表示业务对象。
|
||||
- [ ] 定义字段 `time_range`,表示时间范围。
|
||||
- [ ] 定义字段 `metrics`,表示指标或金额口径。
|
||||
- [ ] 定义字段 `constraints`,表示过滤条件。
|
||||
- [ ] 定义字段 `risk_flags`,表示风险信号。
|
||||
- [ ] 定义字段 `permission`,表示动作权限。
|
||||
- [ ] 为每个字段写清楚类型。
|
||||
- [ ] 为每个字段写清楚是否必填。
|
||||
- [ ] 为每个字段写清楚默认值。
|
||||
- [ ] 为每个字段写清楚示例。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 8 个字段在 Schema、服务层、日志中名字一致。
|
||||
|
||||
## 2. 设计字段枚举
|
||||
|
||||
- [ ] `scenario` 支持 `expense`。
|
||||
- [ ] `scenario` 支持 `accounts_receivable`。
|
||||
- [ ] `scenario` 支持 `accounts_payable`。
|
||||
- [ ] `scenario` 支持 `knowledge`。
|
||||
- [ ] `scenario` 支持 `unknown`。
|
||||
- [ ] `intent` 支持 `query`。
|
||||
- [ ] `intent` 支持 `explain`。
|
||||
- [ ] `intent` 支持 `compare`。
|
||||
- [ ] `intent` 支持 `risk_check`。
|
||||
- [ ] `intent` 支持 `draft`。
|
||||
- [ ] `intent` 支持 `operate`。
|
||||
- [ ] `permission.level` 支持 `read`。
|
||||
- [ ] `permission.level` 支持 `draft_write`。
|
||||
- [ ] `permission.level` 支持 `approval_required`。
|
||||
- [ ] `permission.level` 支持 `forbidden`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 未识别的问题不会抛异常,返回 `unknown`。
|
||||
|
||||
## 3. 建立 Schema
|
||||
|
||||
- [ ] 定义 `OntologyParseRequest`。
|
||||
- [ ] `OntologyParseRequest` 包含 `query`。
|
||||
- [ ] `OntologyParseRequest` 包含 `user_id`。
|
||||
- [ ] `OntologyParseRequest` 包含 `context_json`。
|
||||
- [ ] 定义 `OntologyParseResult`。
|
||||
- [ ] `OntologyParseResult` 包含 8 个核心字段。
|
||||
- [ ] `OntologyParseResult` 包含 `confidence`。
|
||||
- [ ] `OntologyParseResult` 包含 `clarification_required`。
|
||||
- [ ] `OntologyParseResult` 包含 `clarification_question`。
|
||||
- [ ] `OntologyParseResult` 包含 `run_id`。
|
||||
- [ ] 定义字段级错误结构。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] OpenAPI 中可以看到语义解析请求和响应。
|
||||
|
||||
## 4. 实现解析服务
|
||||
|
||||
- [ ] 新增 `SemanticOntologyService` 或同等服务。
|
||||
- [ ] 实现 `parse(query, user_context)` 主函数。
|
||||
- [ ] 先做关键词规则解析。
|
||||
- [ ] 报销关键词映射到 `expense`。
|
||||
- [ ] 应收、回款、客户欠款映射到 `accounts_receivable`。
|
||||
- [ ] 应付、供应商、付款映射到 `accounts_payable`。
|
||||
- [ ] 风险、异常、重复、超标映射到 `risk_check`。
|
||||
- [ ] 为什么、依据、规则映射到 `explain`。
|
||||
- [ ] 统计、汇总、多少映射到 `query`。
|
||||
- [ ] 生成、创建、发起映射到 `draft` 或 `operate`。
|
||||
- [ ] 无法识别时返回低置信度和澄清问题。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] “查一下本周报销超标风险”能识别为 expense + risk_check。
|
||||
- [ ] “客户 A 这个月还有多少应收”能识别为 accounts_receivable + query。
|
||||
- [ ] “供应商 B 明天要付多少钱”能识别为 accounts_payable + query。
|
||||
|
||||
## 5. 解析业务对象
|
||||
|
||||
- [ ] 从问题中提取员工姓名。
|
||||
- [ ] 从问题中提取部门。
|
||||
- [ ] 从问题中提取客户。
|
||||
- [ ] 从问题中提取供应商。
|
||||
- [ ] 从问题中提取项目。
|
||||
- [ ] 从问题中提取单据号。
|
||||
- [ ] 从问题中提取金额。
|
||||
- [ ] 从问题中提取费用类型。
|
||||
- [ ] 无法提取时返回空数组,不返回 null。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] “张三 4 月差旅报销”能提取员工、月份、费用类型。
|
||||
|
||||
## 6. 解析时间范围
|
||||
|
||||
- [ ] 支持今天。
|
||||
- [ ] 支持昨天。
|
||||
- [ ] 支持本周。
|
||||
- [ ] 支持上周。
|
||||
- [ ] 支持本月。
|
||||
- [ ] 支持上月。
|
||||
- [ ] 支持本季度。
|
||||
- [ ] 支持今年。
|
||||
- [ ] 支持明确日期。
|
||||
- [ ] 支持日期区间。
|
||||
- [ ] 解析结果包含 `start_date` 和 `end_date`。
|
||||
- [ ] 日期使用 ISO 格式。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] “本周”能解析为当前周起止日期。
|
||||
- [ ] “2026 年 4 月”能解析为 `2026-04-01` 到 `2026-04-30`。
|
||||
|
||||
## 7. 解析指标与约束
|
||||
|
||||
- [ ] 识别金额指标。
|
||||
- [ ] 识别数量指标。
|
||||
- [ ] 识别超标指标。
|
||||
- [ ] 识别逾期指标。
|
||||
- [ ] 识别重复报销指标。
|
||||
- [ ] 识别部门过滤条件。
|
||||
- [ ] 识别状态过滤条件。
|
||||
- [ ] 识别金额阈值过滤条件。
|
||||
- [ ] 识别排序要求。
|
||||
- [ ] 识别 Top N 要求。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] “列出金额最高的 10 笔报销”能识别排序和 Top 10。
|
||||
|
||||
## 8. 解析风险与权限
|
||||
|
||||
- [ ] 重复报销映射到 `duplicate_expense`。
|
||||
- [ ] 发票异常映射到 `invoice_anomaly`。
|
||||
- [ ] 金额超标映射到 `amount_over_limit`。
|
||||
- [ ] 逾期应收映射到 `ar_overdue`。
|
||||
- [ ] 逾期应付映射到 `ap_overdue`。
|
||||
- [ ] 查询类问题权限为 `read`。
|
||||
- [ ] 生成草稿权限为 `draft_write`。
|
||||
- [ ] 审批、上线、付款类动作权限为 `approval_required`。
|
||||
- [ ] 越权动作权限为 `forbidden`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] “帮我直接付款”不能被标为可直接执行。
|
||||
|
||||
## 9. API 接口
|
||||
|
||||
- [ ] 新增 `POST /api/ontology/parse`。
|
||||
- [ ] 请求参数包含用户问题。
|
||||
- [ ] 请求参数包含用户上下文。
|
||||
- [ ] 响应包含 8 个字段。
|
||||
- [ ] 响应包含 `run_id`。
|
||||
- [ ] 响应包含置信度。
|
||||
- [ ] 响应包含澄清问题。
|
||||
- [ ] 每次调用写入 `SemanticParseLog`。
|
||||
- [ ] 每次调用写入 `AgentRun` 或关联已有 `AgentRun`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 连续调用 5 次都能在日志中查到。
|
||||
|
||||
## 10. 前端调试入口
|
||||
|
||||
- [ ] 在合适页面增加语义解析调试入口。
|
||||
- [ ] 输入框支持自然语言问题。
|
||||
- [ ] 点击解析后调用 API。
|
||||
- [ ] 展示 8 个字段。
|
||||
- [ ] 展示 JSON 原始结果。
|
||||
- [ ] 展示置信度。
|
||||
- [ ] 展示澄清问题。
|
||||
- [ ] 展示 `run_id`。
|
||||
- [ ] 错误时展示错误信息。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 产品和开发可以直接在页面验证解析结果。
|
||||
|
||||
## 11. 评测集
|
||||
|
||||
- [ ] 创建至少 5 条报销问题。
|
||||
- [ ] 创建至少 5 条应收问题。
|
||||
- [ ] 创建至少 5 条应付问题。
|
||||
- [ ] 创建至少 3 条知识库问题。
|
||||
- [ ] 创建至少 3 条越权操作问题。
|
||||
- [ ] 为每条问题写期望 `scenario`。
|
||||
- [ ] 为每条问题写期望 `intent`。
|
||||
- [ ] 为每条问题写期望权限级别。
|
||||
- [ ] 编写评测脚本或测试。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 核心场景识别准确率达到当天设定阈值,例如 80%。
|
||||
|
||||
## 12. Day 3 验收
|
||||
|
||||
- [ ] 语义解析 API 可用。
|
||||
- [ ] 8 个核心字段完整返回。
|
||||
- [ ] 解析日志可查询。
|
||||
- [ ] 低置信度问题有澄清问题。
|
||||
- [ ] 越权动作不会被标为可执行。
|
||||
- [ ] 前端调试入口可用。
|
||||
- [ ] 评测集可运行。
|
||||
- [ ] 所有完成项已用 `[x] ~~...~~` 标记。
|
||||
|
||||
## 阻塞记录
|
||||
|
||||
- [ ] 暂无。
|
||||
|
||||
## 日终交接
|
||||
|
||||
- [ ] 写明已支持的关键词。
|
||||
- [ ] 写明识别不准的样例。
|
||||
- [ ] 写明 Day 4 Orchestrator 可以直接复用的响应结构。
|
||||
@@ -0,0 +1,183 @@
|
||||
# Day 4:Orchestrator 运行时 TODO
|
||||
|
||||
目标:建立统一调度层,让用户请求和系统任务都先进入 Orchestrator,再根据语义本体、权限、能力注册路由到 User Agent、Hermes、MCP 或规则引擎。
|
||||
|
||||
参考文档:
|
||||
|
||||
- `document/development/agent plan/04_orchestrator_and_runtime_flow.md`
|
||||
- `document/development/agent plan/07_capability_registry.md`
|
||||
- `document/development/agent plan/08_permission_confirmation.md`
|
||||
- `document/development/agent plan/09_observability_and_trace.md`
|
||||
|
||||
## 0. 开始前检查
|
||||
|
||||
- [ ] 确认 Day 3 `POST /api/ontology/parse` 可用。
|
||||
- [ ] 确认 `AgentRun` 可创建。
|
||||
- [ ] 确认 `AgentToolCall` 可创建。
|
||||
- [ ] 确认资产列表能查询技能、MCP、任务。
|
||||
- [ ] 确认权限级别枚举已稳定。
|
||||
- [ ] 找到后端服务层适合放 Orchestrator 的位置。
|
||||
|
||||
## 1. Orchestrator 输入输出
|
||||
|
||||
- [ ] 定义 `OrchestratorRequest`。
|
||||
- [ ] 请求包含 `source`。
|
||||
- [ ] 请求包含 `user_id`。
|
||||
- [ ] 请求包含 `message`。
|
||||
- [ ] 请求包含 `task_id`。
|
||||
- [ ] 请求包含 `context_json`。
|
||||
- [ ] 定义 `OrchestratorResponse`。
|
||||
- [ ] 响应包含 `run_id`。
|
||||
- [ ] 响应包含 `selected_agent`。
|
||||
- [ ] 响应包含 `route_reason`。
|
||||
- [ ] 响应包含 `permission_level`。
|
||||
- [ ] 响应包含 `status`。
|
||||
- [ ] 响应包含 `result`。
|
||||
- [ ] 响应包含 `requires_confirmation`。
|
||||
- [ ] 响应包含 `trace_summary`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] Orchestrator 响应能直接被前端展示。
|
||||
|
||||
## 2. 建立 Orchestrator 服务
|
||||
|
||||
- [ ] 新增 `OrchestratorService`。
|
||||
- [ ] 实现 `run(request)` 主入口。
|
||||
- [ ] 主入口第一步创建 `AgentRun`。
|
||||
- [ ] 主入口第二步调用语义解析。
|
||||
- [ ] 主入口第三步执行权限判断。
|
||||
- [ ] 主入口第四步选择 Agent。
|
||||
- [ ] 主入口第五步调用目标 Agent 或返回阻断结果。
|
||||
- [ ] 主入口第六步更新 `AgentRun` 状态。
|
||||
- [ ] 所有异常都写入 `AgentRun.error_message`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 正常请求状态为 `succeeded`。
|
||||
- [ ] 被权限拦截请求状态为 `blocked`。
|
||||
- [ ] 异常请求状态为 `failed`。
|
||||
|
||||
## 3. 路由规则
|
||||
|
||||
- [ ] `source=user_message` 默认路由到 User Agent。
|
||||
- [ ] `source=schedule` 默认路由到 Hermes。
|
||||
- [ ] `intent=risk_check` 且来源为 schedule 时路由到 Hermes。
|
||||
- [ ] `intent=query` 且来源为 user_message 时路由到 User Agent。
|
||||
- [ ] `intent=explain` 路由到 User Agent。
|
||||
- [ ] `intent=draft` 路由到 User Agent,但只允许生成草稿。
|
||||
- [ ] `permission.level=approval_required` 时设置 `requires_confirmation=true`。
|
||||
- [ ] `permission.level=forbidden` 时不调用下游 Agent。
|
||||
- [ ] 无法识别时返回澄清问题。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 同一句风险检查,在用户入口和任务入口有不同路由结果。
|
||||
|
||||
## 4. 权限判断
|
||||
|
||||
- [ ] 新增权限判断服务或函数。
|
||||
- [ ] 查询类请求返回 `read`。
|
||||
- [ ] 草稿类请求返回 `draft_write`。
|
||||
- [ ] 审批、上线、付款类请求返回 `approval_required`。
|
||||
- [ ] 用户无权限时返回 `forbidden`。
|
||||
- [ ] 高风险动作不允许自动执行。
|
||||
- [ ] 需要确认的动作返回确认提示。
|
||||
- [ ] 权限判断结果写入 `AgentRun.permission_level`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] “直接上线规则”不会被自动执行。
|
||||
- [ ] “直接付款”不会被自动执行。
|
||||
|
||||
## 5. 能力注册查询
|
||||
|
||||
- [ ] 从 `AgentAsset` 查询 active 技能。
|
||||
- [ ] 从 `AgentAsset` 查询 active MCP。
|
||||
- [ ] 从 `AgentAsset` 查询 active 任务。
|
||||
- [ ] 过滤 disabled 能力。
|
||||
- [ ] 过滤未审核 active 条件不满足的规则。
|
||||
- [ ] 为每次能力选择记录 `route_json`。
|
||||
- [ ] 找不到能力时返回降级说明。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 禁用 MCP 不会被 Orchestrator 调用。
|
||||
|
||||
## 6. 工具调用封装
|
||||
|
||||
- [ ] 定义统一工具调用接口。
|
||||
- [ ] 工具请求前写入 `AgentToolCall` running 或准备记录。
|
||||
- [ ] 工具成功后写入响应和耗时。
|
||||
- [ ] 工具失败后写入错误。
|
||||
- [ ] 外部 MCP 调用失败时返回降级结果。
|
||||
- [ ] 数据库查询失败时返回明确错误。
|
||||
- [ ] LLM 调用失败时返回可读提示。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 每次 Orchestrator 运行至少可以看到 0 到多条工具调用记录。
|
||||
|
||||
## 7. API 接口
|
||||
|
||||
- [ ] 新增 `POST /api/orchestrator/run`。
|
||||
- [ ] 请求支持用户消息。
|
||||
- [ ] 请求支持任务触发。
|
||||
- [ ] 响应返回 `run_id`。
|
||||
- [ ] 响应返回路由结果。
|
||||
- [ ] 响应返回权限结果。
|
||||
- [ ] 新增 `GET /api/orchestrator/runs/{run_id}/trace` 或复用 AgentRun 详情接口。
|
||||
- [ ] Trace 接口返回语义解析、路由、工具调用、最终结果。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 前端或 curl 可以完整看到一次运行链路。
|
||||
|
||||
## 8. 前端最小 Trace 查看
|
||||
|
||||
- [ ] 在合适位置展示最近运行记录。
|
||||
- [ ] 点击运行记录能查看 `run_id`。
|
||||
- [ ] 展示 selected_agent。
|
||||
- [ ] 展示 route_reason。
|
||||
- [ ] 展示 permission_level。
|
||||
- [ ] 展示工具调用列表。
|
||||
- [ ] 展示错误信息。
|
||||
- [ ] 展示耗时。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 开发调试时不需要直接查数据库才能理解路由结果。
|
||||
|
||||
## 9. 测试
|
||||
|
||||
- [ ] 测试用户查询路由到 User Agent。
|
||||
- [ ] 测试定时任务路由到 Hermes。
|
||||
- [ ] 测试 forbidden 不调用下游 Agent。
|
||||
- [ ] 测试 approval_required 返回确认。
|
||||
- [ ] 测试工具失败写入 ToolCall。
|
||||
- [ ] 测试 Orchestrator 异常写入 AgentRun。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] Orchestrator 核心测试通过。
|
||||
|
||||
## 10. Day 4 验收
|
||||
|
||||
- [ ] Orchestrator API 可用。
|
||||
- [ ] 用户请求能路由到 User Agent 占位实现。
|
||||
- [ ] 定时任务能路由到 Hermes 占位实现。
|
||||
- [ ] 权限阻断有效。
|
||||
- [ ] 运行 Trace 可查询。
|
||||
- [ ] 工具调用日志可查询。
|
||||
- [ ] 降级结果可读。
|
||||
- [ ] 所有完成项已用 `[x] ~~...~~` 标记。
|
||||
|
||||
## 阻塞记录
|
||||
|
||||
- [ ] 暂无。
|
||||
|
||||
## 日终交接
|
||||
|
||||
- [ ] 写明路由规则现状。
|
||||
- [ ] 写明权限判断现状。
|
||||
- [ ] 写明 Day 5 User Agent 需要实现的接口契约。
|
||||
183
document/development/agent week plan/day_5_user_agent_mvp.md
Normal file
183
document/development/agent week plan/day_5_user_agent_mvp.md
Normal file
@@ -0,0 +1,183 @@
|
||||
# Day 5:User Agent MVP TODO
|
||||
|
||||
目标:实现面向用户的自建 Agent。它负责用户提问、流程辅助、规则解释、查询结果解释和草稿生成,不做自动审批、自动付款、自动上线等高风险动作。
|
||||
|
||||
参考文档:
|
||||
|
||||
- `document/development/agent plan/03_agent_responsibilities.md`
|
||||
- `document/development/agent plan/04_orchestrator_and_runtime_flow.md`
|
||||
- `document/development/agent plan/12_llm_wiki_knowledge_architecture.md`
|
||||
- `document/development/agent plan/13_rule_formation_lifecycle.md`
|
||||
|
||||
## 0. 开始前检查
|
||||
|
||||
- [ ] 确认 Orchestrator 能把用户请求路由到 User Agent。
|
||||
- [ ] 确认语义本体 8 字段可用。
|
||||
- [ ] 确认规则资产可查询。
|
||||
- [ ] 确认 AgentRun 和 ToolCall 可记录。
|
||||
- [ ] 确认是否有现成对话 UI。
|
||||
- [ ] 确认财务业务数据是否真实可查。
|
||||
- [ ] 如果业务数据不可查,准备最小 Mock 数据服务。
|
||||
|
||||
## 1. User Agent 输入输出
|
||||
|
||||
- [ ] 定义 `UserAgentRequest`。
|
||||
- [ ] 请求包含 `run_id`。
|
||||
- [ ] 请求包含 `user_id`。
|
||||
- [ ] 请求包含 `message`。
|
||||
- [ ] 请求包含 `ontology`。
|
||||
- [ ] 请求包含 `context_json`。
|
||||
- [ ] 定义 `UserAgentResponse`。
|
||||
- [ ] 响应包含 `answer`。
|
||||
- [ ] 响应包含 `citations`。
|
||||
- [ ] 响应包含 `suggested_actions`。
|
||||
- [ ] 响应包含 `draft_payload`。
|
||||
- [ ] 响应包含 `risk_flags`。
|
||||
- [ ] 响应包含 `requires_confirmation`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] User Agent 响应结构能被 Orchestrator 直接包装返回。
|
||||
|
||||
## 2. 查询处理
|
||||
|
||||
- [ ] 实现报销查询处理器。
|
||||
- [ ] 实现应收查询处理器。
|
||||
- [ ] 实现应付查询处理器。
|
||||
- [ ] 查询前检查权限级别。
|
||||
- [ ] 查询时记录 ToolCall。
|
||||
- [ ] 查询失败时返回可读错误。
|
||||
- [ ] 查询为空时返回空态解释。
|
||||
- [ ] 查询结果限制返回条数,避免一次返回过大。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] “查本周报销金额”有可读回答。
|
||||
- [ ] “客户 A 本月应收多少”有可读回答。
|
||||
- [ ] “供应商 B 待付款多少”有可读回答。
|
||||
|
||||
## 3. 规则解释
|
||||
|
||||
- [ ] 根据语义场景查询相关规则资产。
|
||||
- [ ] 只引用 active 规则。
|
||||
- [ ] 读取规则当前版本 Markdown。
|
||||
- [ ] 从 Markdown 中提取规则摘要。
|
||||
- [ ] 回答中说明使用了哪些规则。
|
||||
- [ ] 回答中包含规则版本号。
|
||||
- [ ] 回答中包含规则更新时间。
|
||||
- [ ] 没有相关规则时说明缺失。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] “为什么这笔报销有风险”能引用规则。
|
||||
|
||||
## 4. 风险解释
|
||||
|
||||
- [ ] 识别重复报销风险。
|
||||
- [ ] 识别金额超标风险。
|
||||
- [ ] 识别发票异常风险。
|
||||
- [ ] 识别逾期应收风险。
|
||||
- [ ] 识别逾期应付风险。
|
||||
- [ ] 风险回答包含风险类型。
|
||||
- [ ] 风险回答包含触发原因。
|
||||
- [ ] 风险回答包含建议处理动作。
|
||||
- [ ] 高风险建议不能变成自动执行。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 风险解释结果不是单纯“有风险”,而是有依据。
|
||||
|
||||
## 5. 草稿生成
|
||||
|
||||
- [ ] 支持生成报销处理意见草稿。
|
||||
- [ ] 支持生成应收催收建议草稿。
|
||||
- [ ] 支持生成应付付款建议草稿。
|
||||
- [ ] 草稿中标明“待人工确认”。
|
||||
- [ ] 草稿不直接提交业务系统。
|
||||
- [ ] 草稿生成写入审计日志。
|
||||
- [ ] 草稿生成写入 AgentRun 结果。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] “帮我生成处理意见”只返回草稿,不执行审批。
|
||||
|
||||
## 6. 知识库读取骨架
|
||||
|
||||
- [ ] 建立知识条目查询接口或服务。
|
||||
- [ ] 支持按关键词查询知识条目。
|
||||
- [ ] 支持按业务场景查询知识条目。
|
||||
- [ ] User Agent 回答可以引用知识条目。
|
||||
- [ ] 引用中包含知识标题。
|
||||
- [ ] 引用中包含更新时间。
|
||||
- [ ] 知识库不可用时返回降级说明。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 知识库失败不会导致整个回答失败。
|
||||
|
||||
## 7. 对话或操作入口
|
||||
|
||||
- [ ] 前端增加用户问题输入框。
|
||||
- [ ] 输入框支持回车或按钮提交。
|
||||
- [ ] 提交时调用 Orchestrator,而不是绕过 Orchestrator。
|
||||
- [ ] 展示 Agent 回答。
|
||||
- [ ] 展示引用规则或知识。
|
||||
- [ ] 展示建议动作。
|
||||
- [ ] 展示需要人工确认的提示。
|
||||
- [ ] 展示 `run_id`。
|
||||
- [ ] 展示加载态。
|
||||
- [ ] 展示错误态。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 用户可在页面完成一次问答闭环。
|
||||
|
||||
## 8. 安全边界
|
||||
|
||||
- [ ] User Agent 不直接修改规则状态。
|
||||
- [ ] User Agent 不直接上线规则。
|
||||
- [ ] User Agent 不直接审批报销。
|
||||
- [ ] User Agent 不直接付款。
|
||||
- [ ] User Agent 不直接删除知识。
|
||||
- [ ] 所有高风险动作只返回建议或草稿。
|
||||
- [ ] 所有草稿动作标记 `requires_confirmation=true`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 提示词要求“直接付款”时仍被阻断。
|
||||
|
||||
## 9. 测试
|
||||
|
||||
- [ ] 测试报销查询。
|
||||
- [ ] 测试应收查询。
|
||||
- [ ] 测试应付查询。
|
||||
- [ ] 测试规则解释。
|
||||
- [ ] 测试风险解释。
|
||||
- [ ] 测试草稿生成。
|
||||
- [ ] 测试越权动作阻断。
|
||||
- [ ] 测试知识库降级。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] User Agent 核心测试通过。
|
||||
|
||||
## 10. Day 5 验收
|
||||
|
||||
- [ ] User Agent 服务可被 Orchestrator 调用。
|
||||
- [ ] 用户入口可提交自然语言问题。
|
||||
- [ ] 至少 3 个财务场景有回答。
|
||||
- [ ] 回答能引用规则或知识。
|
||||
- [ ] 高风险动作不会自动执行。
|
||||
- [ ] AgentRun Trace 能看到 User Agent 步骤。
|
||||
- [ ] 前端构建通过。
|
||||
- [ ] 所有完成项已用 `[x] ~~...~~` 标记。
|
||||
|
||||
## 阻塞记录
|
||||
|
||||
- [ ] 暂无。
|
||||
|
||||
## 日终交接
|
||||
|
||||
- [ ] 写明已支持的问题类型。
|
||||
- [ ] 写明仍使用 Mock 的数据。
|
||||
- [ ] 写明 Day 6 Hermes 可以复用的规则、风险、知识接口。
|
||||
191
document/development/agent week plan/day_6_hermes_mvp.md
Normal file
191
document/development/agent week plan/day_6_hermes_mvp.md
Normal file
@@ -0,0 +1,191 @@
|
||||
# Day 6:Hermes MVP TODO
|
||||
|
||||
目标:实现 Hermes 数字员工的最小闭环。Hermes 不面向用户即时对话,而是负责定时巡检、统计、风险预警、知识维护和规则草稿形成。
|
||||
|
||||
参考文档:
|
||||
|
||||
- `document/development/agent plan/03_agent_responsibilities.md`
|
||||
- `document/development/agent plan/11_ocr_invoice_architecture.md`
|
||||
- `document/development/agent plan/12_llm_wiki_knowledge_architecture.md`
|
||||
- `document/development/agent plan/15_feedback_learning_loop.md`
|
||||
|
||||
## 0. 开始前检查
|
||||
|
||||
- [ ] 确认任务资产 `asset_type=task` 可查询。
|
||||
- [ ] 确认 Orchestrator 能处理 `source=schedule`。
|
||||
- [ ] 确认 Hermes 占位服务可被调用。
|
||||
- [ ] 确认 AgentRun 和 ToolCall 可记录。
|
||||
- [ ] 确认是否已有后台任务框架。
|
||||
- [ ] 如果没有后台任务框架,先用手动触发 API 模拟定时执行。
|
||||
|
||||
## 1. Hermes 输入输出
|
||||
|
||||
- [ ] 定义 `HermesTaskRequest`。
|
||||
- [ ] 请求包含 `run_id`。
|
||||
- [ ] 请求包含 `task_asset_id`。
|
||||
- [ ] 请求包含 `task_type`。
|
||||
- [ ] 请求包含 `schedule_time`。
|
||||
- [ ] 请求包含 `context_json`。
|
||||
- [ ] 定义 `HermesTaskResult`。
|
||||
- [ ] 响应包含 `summary`。
|
||||
- [ ] 响应包含 `risk_items`。
|
||||
- [ ] 响应包含 `statistics`。
|
||||
- [ ] 响应包含 `knowledge_updates`。
|
||||
- [ ] 响应包含 `draft_rules`。
|
||||
- [ ] 响应包含 `next_actions`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] Hermes 响应能被任务详情或运行日志展示。
|
||||
|
||||
## 2. 任务调度入口
|
||||
|
||||
- [ ] 新增手动触发任务 API。
|
||||
- [ ] API 参数支持任务资产 ID。
|
||||
- [ ] API 调用 Orchestrator,source 为 `schedule`。
|
||||
- [ ] Orchestrator 路由到 Hermes。
|
||||
- [ ] Hermes 执行结果写入 AgentRun。
|
||||
- [ ] 任务执行失败时写入错误。
|
||||
- [ ] 任务执行结束后更新任务最近执行时间。
|
||||
- [ ] 任务执行结束后更新任务最近执行状态。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 可以手动触发一次 Hermes 任务并看到运行结果。
|
||||
|
||||
## 3. 每日风险巡检
|
||||
|
||||
- [ ] 实现重复报销巡检。
|
||||
- [ ] 实现金额超标巡检。
|
||||
- [ ] 实现发票异常巡检占位。
|
||||
- [ ] 实现应收逾期巡检。
|
||||
- [ ] 实现应付异常付款巡检。
|
||||
- [ ] 每个风险项包含风险类型。
|
||||
- [ ] 每个风险项包含业务对象。
|
||||
- [ ] 每个风险项包含触发规则。
|
||||
- [ ] 每个风险项包含建议动作。
|
||||
- [ ] 每个风险项包含风险等级。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 风险巡检结果可以被用户理解和追溯。
|
||||
|
||||
## 4. 每日统计
|
||||
|
||||
- [ ] 统计当日报销单数量。
|
||||
- [ ] 统计当日报销金额。
|
||||
- [ ] 统计当日报账数量。
|
||||
- [ ] 统计当日报账金额。
|
||||
- [ ] 统计应收新增金额。
|
||||
- [ ] 统计应收逾期金额。
|
||||
- [ ] 统计应付待付金额。
|
||||
- [ ] 统计应付逾期金额。
|
||||
- [ ] 输出日报摘要。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] Hermes 能生成一份每日财务摘要。
|
||||
|
||||
## 5. OCR 接入点
|
||||
|
||||
- [ ] 建立 OCR 识别服务接口。
|
||||
- [ ] 定义发票识别输入结构。
|
||||
- [ ] 定义发票识别输出结构。
|
||||
- [ ] 输出结构包含发票号。
|
||||
- [ ] 输出结构包含开票日期。
|
||||
- [ ] 输出结构包含金额。
|
||||
- [ ] 输出结构包含税额。
|
||||
- [ ] 输出结构包含销售方。
|
||||
- [ ] 输出结构包含购买方。
|
||||
- [ ] 输出结构包含置信度。
|
||||
- [ ] 当前阶段允许使用 Mock 结果。
|
||||
- [ ] OCR 调用写入 ToolCall。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] Hermes 风险巡检中可以调用 OCR Mock。
|
||||
|
||||
## 6. 知识库维护
|
||||
|
||||
- [ ] 建立知识条目写入服务。
|
||||
- [ ] Hermes 可以生成知识候选条目。
|
||||
- [ ] 候选条目包含标题。
|
||||
- [ ] 候选条目包含正文。
|
||||
- [ ] 候选条目包含来源。
|
||||
- [ ] 候选条目包含适用场景。
|
||||
- [ ] 候选条目默认状态为 `draft`。
|
||||
- [ ] 知识条目不能自动发布。
|
||||
- [ ] 知识条目写入审计日志。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] Hermes 可以生成待审核知识条目。
|
||||
|
||||
## 7. 规则草稿形成
|
||||
|
||||
- [ ] Hermes 可以根据风险巡检结果生成规则草稿。
|
||||
- [ ] 规则草稿保存为 `asset_type=rule`。
|
||||
- [ ] 规则草稿状态为 `draft`。
|
||||
- [ ] 规则草稿包含 Markdown 内容。
|
||||
- [ ] 规则草稿包含生成原因。
|
||||
- [ ] 规则草稿包含关联风险样例。
|
||||
- [ ] 规则草稿不能自动上线。
|
||||
- [ ] 规则草稿需要审核人。
|
||||
- [ ] 规则草稿写入审计日志。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] Hermes 生成的新规则出现在规则列表中,但不是 active。
|
||||
|
||||
## 8. Hermes 页面或日志展示
|
||||
|
||||
- [ ] 任务详情能看到最近执行结果。
|
||||
- [ ] 任务详情能手动触发执行。
|
||||
- [ ] 任务详情能看到风险项数量。
|
||||
- [ ] 任务详情能看到日报摘要。
|
||||
- [ ] 任务详情能看到知识候选数量。
|
||||
- [ ] 任务详情能看到规则草稿数量。
|
||||
- [ ] 运行 Trace 能看到 Hermes 步骤。
|
||||
- [ ] 错误时展示错误原因。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 不查数据库也能判断 Hermes 是否执行成功。
|
||||
|
||||
## 9. 测试
|
||||
|
||||
- [ ] 测试手动触发任务。
|
||||
- [ ] 测试 Orchestrator 路由到 Hermes。
|
||||
- [ ] 测试风险巡检输出。
|
||||
- [ ] 测试日报统计输出。
|
||||
- [ ] 测试 OCR Mock 调用。
|
||||
- [ ] 测试知识候选写入。
|
||||
- [ ] 测试规则草稿生成。
|
||||
- [ ] 测试 Hermes 异常写入 AgentRun。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] Hermes 核心测试通过。
|
||||
|
||||
## 10. Day 6 验收
|
||||
|
||||
- [ ] Hermes 可被 Orchestrator 调用。
|
||||
- [ ] 至少一个任务可以手动触发。
|
||||
- [ ] 风险巡检有结构化结果。
|
||||
- [ ] 每日统计有结构化结果。
|
||||
- [ ] OCR Mock 接入点可用。
|
||||
- [ ] 知识候选可生成。
|
||||
- [ ] 规则草稿可生成且不能自动上线。
|
||||
- [ ] 任务详情或运行日志能展示结果。
|
||||
- [ ] 所有完成项已用 `[x] ~~...~~` 标记。
|
||||
|
||||
## 阻塞记录
|
||||
|
||||
- [ ] 暂无。
|
||||
|
||||
## 日终交接
|
||||
|
||||
- [ ] 写明 Hermes 已支持任务类型。
|
||||
- [ ] 写明 OCR 当前是真实还是 Mock。
|
||||
- [ ] 写明生成的知识和规则草稿状态。
|
||||
- [ ] 写明 Day 7 需要重点回归的路径。
|
||||
@@ -0,0 +1,223 @@
|
||||
# Day 7:加固、演示和验收 TODO
|
||||
|
||||
目标:把前 6 天做出的功能整理成可演示、可验收、可继续迭代的基础平台。Day 7 不再大规模扩功能,重点是修缺口、补测试、补日志、补文档、完成演示链路。
|
||||
|
||||
参考文档:
|
||||
|
||||
- `document/development/agent plan/00_README.md`
|
||||
- `document/development/agent plan/05_development_roadmap.md`
|
||||
- `document/development/agent plan/09_observability_and_trace.md`
|
||||
- `document/development/agent plan/10_evaluation_and_testset.md`
|
||||
|
||||
## 0. 开始前检查
|
||||
|
||||
- [ ] 汇总 Day 1 未完成项。
|
||||
- [ ] 汇总 Day 2 未完成项。
|
||||
- [ ] 汇总 Day 3 未完成项。
|
||||
- [ ] 汇总 Day 4 未完成项。
|
||||
- [ ] 汇总 Day 5 未完成项。
|
||||
- [ ] 汇总 Day 6 未完成项。
|
||||
- [ ] 标记必须今天修复的问题。
|
||||
- [ ] 标记可以进入下一阶段的问题。
|
||||
- [ ] 冻结新增需求,只处理验收相关问题。
|
||||
|
||||
## 1. 核心链路回归
|
||||
|
||||
- [ ] 回归资产列表接口。
|
||||
- [ ] 回归规则详情接口。
|
||||
- [ ] 回归 Markdown 保存。
|
||||
- [ ] 回归版本列表。
|
||||
- [ ] 回归版本切换。
|
||||
- [ ] 回归审核接口。
|
||||
- [ ] 回归上线拦截。
|
||||
- [ ] 回归语义解析接口。
|
||||
- [ ] 回归 Orchestrator 路由。
|
||||
- [ ] 回归 User Agent 问答。
|
||||
- [ ] 回归 Hermes 任务执行。
|
||||
- [ ] 回归 AgentRun Trace。
|
||||
- [ ] 回归 ToolCall 日志。
|
||||
- [ ] 回归 AuditLog 日志。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 从前端能完成至少一条端到端演示路径。
|
||||
|
||||
## 2. 权限和风险边界
|
||||
|
||||
- [ ] 未审核规则不能上线。
|
||||
- [ ] rejected 规则不能上线。
|
||||
- [ ] disabled 能力不能被调用。
|
||||
- [ ] 用户请求付款必须拦截。
|
||||
- [ ] 用户请求审批必须需要确认。
|
||||
- [ ] Hermes 生成规则只能是 draft。
|
||||
- [ ] Hermes 生成知识只能是 draft。
|
||||
- [ ] User Agent 生成处理意见只能是草稿。
|
||||
- [ ] 所有高风险动作响应中包含 `requires_confirmation`。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 不存在 MVP 期间绕过人工审核的路径。
|
||||
|
||||
## 3. 审计和 Trace 补齐
|
||||
|
||||
- [ ] 规则保存写 AuditLog。
|
||||
- [ ] 规则审核写 AuditLog。
|
||||
- [ ] 规则上线写 AuditLog。
|
||||
- [ ] Hermes 生成规则草稿写 AuditLog。
|
||||
- [ ] Hermes 生成知识候选写 AuditLog。
|
||||
- [ ] User Agent 草稿生成写 AuditLog。
|
||||
- [ ] Orchestrator 每次运行有 AgentRun。
|
||||
- [ ] 每次工具调用有 ToolCall。
|
||||
- [ ] Trace 页面或接口能串起 run_id。
|
||||
- [ ] 错误 Trace 包含 error_message。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 任意一条演示链路都能追溯到 run_id。
|
||||
|
||||
## 4. 前端体验修补
|
||||
|
||||
- [ ] 任务规则中心列表无明显错位。
|
||||
- [ ] 详情页无双 title。
|
||||
- [ ] Hero title 高度紧凑。
|
||||
- [ ] 返回列表栏高度正常。
|
||||
- [ ] Markdown 编辑器和版本卡片底部对齐。
|
||||
- [ ] 版本卡片不贴右侧。
|
||||
- [ ] 当前版本标识不突兀。
|
||||
- [ ] 日期列对齐。
|
||||
- [ ] 弹窗文案清楚。
|
||||
- [ ] 加载态可见。
|
||||
- [ ] 错误态可见。
|
||||
- [ ] 空态可见。
|
||||
- [ ] 按钮禁用态可见。
|
||||
- [ ] 窄屏不出现内容重叠。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 任务规则中心可以给业务用户演示,不需要解释 UI 异常。
|
||||
|
||||
## 5. 测试补齐
|
||||
|
||||
- [ ] 运行后端现有测试。
|
||||
- [ ] 运行新增模型测试。
|
||||
- [ ] 运行新增 API 测试。
|
||||
- [ ] 运行语义解析测试。
|
||||
- [ ] 运行 Orchestrator 测试。
|
||||
- [ ] 运行 User Agent 测试。
|
||||
- [ ] 运行 Hermes 测试。
|
||||
- [ ] 运行前端构建。
|
||||
- [ ] 如果有前端测试,运行前端测试。
|
||||
- [ ] 记录未能运行的测试和原因。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 测试结果写入本文件“测试记录”。
|
||||
|
||||
## 6. 评测集
|
||||
|
||||
- [ ] 准备 5 条报销问题。
|
||||
- [ ] 准备 5 条应收问题。
|
||||
- [ ] 准备 5 条应付问题。
|
||||
- [ ] 准备 3 条规则解释问题。
|
||||
- [ ] 准备 3 条越权动作问题。
|
||||
- [ ] 执行语义解析评测。
|
||||
- [ ] 执行 User Agent 回答评测。
|
||||
- [ ] 执行权限拦截评测。
|
||||
- [ ] 记录失败样例。
|
||||
- [ ] 为失败样例写下一阶段优化建议。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 可以说明 MVP 当前能力边界和准确率风险。
|
||||
|
||||
## 7. 演示数据
|
||||
|
||||
- [ ] 准备 active 规则。
|
||||
- [ ] 准备 pending 规则。
|
||||
- [ ] 准备 rejected 规则。
|
||||
- [ ] 准备至少一条报销数据。
|
||||
- [ ] 准备至少一条应收数据。
|
||||
- [ ] 准备至少一条应付数据。
|
||||
- [ ] 准备至少一个 Hermes 任务。
|
||||
- [ ] 准备至少一个 MCP Mock。
|
||||
- [ ] 准备至少一个知识条目。
|
||||
- [ ] 准备至少一个风险样例。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 演示不会因为没有数据而中断。
|
||||
|
||||
## 8. 演示脚本
|
||||
|
||||
- [ ] 编写演示步骤 1:打开任务规则中心。
|
||||
- [ ] 编写演示步骤 2:查看规则详情。
|
||||
- [ ] 编写演示步骤 3:编辑 Markdown 并保存。
|
||||
- [ ] 编写演示步骤 4:切换版本。
|
||||
- [ ] 编写演示步骤 5:尝试上线未审核规则并被拦截。
|
||||
- [ ] 编写演示步骤 6:输入用户问题。
|
||||
- [ ] 编写演示步骤 7:查看语义本体结果。
|
||||
- [ ] 编写演示步骤 8:查看 User Agent 回答。
|
||||
- [ ] 编写演示步骤 9:手动触发 Hermes 任务。
|
||||
- [ ] 编写演示步骤 10:查看 AgentRun Trace。
|
||||
- [ ] 编写演示步骤 11:查看审计日志。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 新开发者按脚本可以复现演示。
|
||||
|
||||
## 9. 文档收尾
|
||||
|
||||
- [ ] 更新一周计划完成情况。
|
||||
- [ ] 更新剩余风险。
|
||||
- [ ] 更新下一阶段开发建议。
|
||||
- [ ] 更新接口清单。
|
||||
- [ ] 更新数据模型清单。
|
||||
- [ ] 更新前端页面清单。
|
||||
- [ ] 更新评测结果。
|
||||
- [ ] 更新演示脚本。
|
||||
- [ ] 更新部署或启动说明。
|
||||
|
||||
验收证据:
|
||||
|
||||
- [ ] 文档能指导下一周继续开发。
|
||||
|
||||
## 10. 最终验收清单
|
||||
|
||||
- [ ] 任务规则中心可查看规则、技能、MCP、任务。
|
||||
- [ ] 规则详情可编辑 Markdown。
|
||||
- [ ] 规则详情可查看最近 5 个版本。
|
||||
- [ ] 版本切换有确认弹窗。
|
||||
- [ ] 审核者信息可见。
|
||||
- [ ] 未审核规则不能上线。
|
||||
- [ ] 语义本体 8 字段可返回。
|
||||
- [ ] Orchestrator 能路由用户请求。
|
||||
- [ ] Orchestrator 能路由定时任务。
|
||||
- [ ] User Agent 能回答至少 3 类财务问题。
|
||||
- [ ] Hermes 能执行至少 1 个任务。
|
||||
- [ ] OCR Mock 接入点可用。
|
||||
- [ ] 知识候选可生成。
|
||||
- [ ] 规则草稿可生成。
|
||||
- [ ] AgentRun Trace 可查。
|
||||
- [ ] AuditLog 可查。
|
||||
- [ ] 前端构建通过。
|
||||
- [ ] 后端核心测试通过。
|
||||
- [ ] 演示脚本可执行。
|
||||
- [ ] 所有完成项已用 `[x] ~~...~~` 标记。
|
||||
|
||||
## 测试记录
|
||||
|
||||
- [ ] 后端测试:未运行。
|
||||
- [ ] 前端构建:未运行。
|
||||
- [ ] 语义评测:未运行。
|
||||
- [ ] 手动验收:未运行。
|
||||
|
||||
## 阻塞记录
|
||||
|
||||
- [ ] 暂无。
|
||||
|
||||
## 日终交接
|
||||
|
||||
- [ ] 写明本周最终完成内容。
|
||||
- [ ] 写明未完成内容。
|
||||
- [ ] 写明生产化前必须补齐内容。
|
||||
- [ ] 写明下一周建议优先级。
|
||||
Reference in New Issue
Block a user