refactor(harness): remove legacy agent architecture

2026-07-22 18:02:01 +08:00
parent bc36248cd8
commit 8ee7cc0b70
148 changed files with 3091 additions and 13889 deletions
@@ -0,0 +1,152 @@
+# 面试演示讲解稿
+
+这是一份短时间 Agent 工程面试用讲解稿，不是完整系统文档。
+
+## 1. 30 秒摘要
+
+```text
+这是一个企业故障诊断 Agent MVP。
+它接收支付超时问题，规划排查步骤，调用证据工具，
+用 Verifier 检查答案，把完整 Trace 持久化，并支持用户反馈。
+```
+
+关键主张不是“模型回答了一次”，而是：
+
+```text
+系统能展示用了什么证据、答案如何被检查、如何用 sessionId + runId 精确回放这次诊断。
+```
+
+## 2. Demo 流程
+
+1. 用 `mvp-demo` profile 启动服务。
+2. 运行固定的支付超时请求。
+3. 打开 `mvp/demo/output/chat-response.json`。
+4. 打开 `mvp/demo/output/trace-response.json`。
+5. 指出证据工具和 verifier evaluation。
+6. 提交 feedback，并展示它挂在当前 run 上。
+7. 打开 `evidence-pipeline-scenarios.md`，说明 PASS / LOW_CONFID / REJECT / no-evidence 的固定回归矩阵。
+
+## 3. 命令
+
+启动服务：
+
+```powershell
+mvn spring-boot:run "-Dspring-boot.run.profiles=mvp-demo"
+```
+
+另开终端运行 Demo：
+
+```powershell
+powershell -ExecutionPolicy Bypass -File mvp/demo/scripts/run-payment-timeout-demo.ps1
+```
+
+可选自定义 session：
+
+```powershell
+powershell -ExecutionPolicy Bypass -File mvp/demo/scripts/run-payment-timeout-demo.ps1 -SessionId "mvp-demo-payment-timeout-002"
+```
+
+## 4. 展示什么
+
+### 4.1 用户侧答案
+
+文件：
+
+```text
+mvp/demo/output/chat-response.json
+```
+
+话术：
+
+```text
+这是用户看到的答案。这里的 sessionId 是稳定的，同时响应里会返回 runId，所以我后面可以精确追踪这一次回答是怎么来的。
+```
+
+### 4.2 证据 Trace
+
+文件：
+
+```text
+mvp/demo/output/trace-response.json
+```
+
+话术：
+
+```text
+这才是 Agent 工程最重要的部分。
+我可以检查 Agent 调用了哪些工具、每个工具拿到什么入参、是否成功、返回了什么证据预览。
+```
+
+重点字段：
+
+- `data.toolInvocations[*].toolName`
+- `data.toolInvocations[*].inputParams`
+- `data.toolInvocations[*].outputPreview`
+- `data.toolInvocations[*].success`
+
+### 4.3 Verifier / 自评估
+
+重点字段：
+
+- `data.session.selfEvaluation`
+- `data.summary.hasVerifierEvaluation`
+
+话术：
+
+```text
+最终答案不是 Executor 原始输出直接返回。
+系统会基于持久化的工具 trace 做 Verifier 或规则自评估。
+这样系统可以区分 PASS、LOW_CONFID、REJECT，而不是假装每个答案都同样可信。
+```
+
+### 4.4 反馈闭环
+
+文件：
+
+```text
+mvp/demo/output/feedback-response.json
+```
+
+必要时重新查询 Trace。
+
+话术：
+
+```text
+feedback 会挂在当前 diagnosis run 上。
+这让后续挖掘 useful case 或 not_useful bad case 成为可能。
+```
+
+### 4.5 回归故事
+
+如果被问到稳定性，可以补充：
+
+```text
+我把运行时 Demo 和离线 eval 分开。
+Demo 证明真实链路能跑通，offline eval baseline 证明固定 case 可以回归。
+这两者分开是有意的：Demo 面向人类审阅，eval 面向自动化信号。
+```
+
+如果被问到怎么防止证据归因幻觉，可以补充：
+
+```text
+Executor 的 claim 必须绑定 source_invocation_id、raw_path 和 evidence_excerpt。
+Gatekeeper 用代码核验这些引用，并把 rule_set_version 写进 trace。
+Verifier 只判断已核验证据能否推出 claim，Composer 只表达允许输出的内容。
+```
+
+## 5. 强面试表达
+
+```text
+我关注的是 Agent 工程表面：
+traceability、evidence persistence、verifier gating、feedback 和 regression checks。
+模型答案只是系统的一部分。
+更重要的是答案产出后，能否被审计、验证和持续改进。
+```
+
+## 6. 主动说明限制
+
+```text
+这个 MVP 仍依赖 MySQL、Redis、Milvus 和模型凭证。
+mvp-demo profile mock 了日志和指标，但不是完整生产运行环境。
+密钥清理、默认隔离测试和生产可靠性是后续 hardening 工作。
+```