40 lines
1.6 KiB
Markdown
40 lines
1.6 KiB
Markdown
# 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 与生产化之间的差距。
|