feat: archive mvp demo trace acceptance
This commit is contained in:
@@ -0,0 +1,39 @@
|
||||
# MVP Demo Profile 与 Trace 查询接口
|
||||
|
||||
## 背景
|
||||
|
||||
MVP 已经能跑多 Agent 诊断、工具调用、Verifier 和反馈,但对外展示时仍然缺少一个稳定的复盘入口。面试官或评审如果想确认一次 Agent 回答是否可信,不能只看最终答案,还需要看到用户原始问题、Agent 步骤顺序、工具调用证据、Verifier / self-evaluation、最终答案和用户反馈。
|
||||
|
||||
## 决策
|
||||
|
||||
新增 `mvp-demo` profile 和 trace 查询接口:
|
||||
|
||||
```text
|
||||
GET /api/diagnosis/{sessionId}/trace
|
||||
```
|
||||
|
||||
接口聚合:
|
||||
|
||||
- `diagnosis_session`
|
||||
- `agent_step`
|
||||
- `tool_invocation`
|
||||
- `self_evaluation`
|
||||
- `feedback`
|
||||
|
||||
同时在 `mvp/demo` 下沉淀端到端验收 case,把启动、提问、查 trace、提交 feedback 串成一条可演示路径。
|
||||
|
||||
## 取舍
|
||||
|
||||
`mvp-demo` profile 不是完整离线 mock 环境,仍然复用当前真实 DB / Redis / Milvus / LLM 配置,只显式打开日志和指标 mock。原因是当前阶段目标是展示企业级 Agent 工程闭环,不是隐藏真实集成复杂度。
|
||||
|
||||
这让 MVP 的讲述从“我实现了一个聊天接口”升级为:
|
||||
|
||||
```text
|
||||
我实现了一条可执行、可观测、可验收、可复盘的 Agent 诊断链路。
|
||||
```
|
||||
|
||||
## 面试表达
|
||||
|
||||
- 我没有把 trace 塞进 chat 返回值,而是做成独立只读观测接口,保持执行链路和观测链路解耦。
|
||||
- Trace API 复用已经沉淀的 `diagnosis_session`、`agent_step`、`tool_invocation` 三张表,没有引入新的 schema 风险。
|
||||
- Demo profile 只做最小 overlay,让日志和指标工具可重复,保留真实基础设施集成,方便说明 MVP 与生产化之间的差距。
|
||||
Reference in New Issue
Block a user