Week 4 Day 30：最终检查与30天回顾 - 苏格拉底教学
30天前你用 go mod init 开始了一个空项目。今天你要让它变成一个值得放在简历上的作品，并且清楚地知道你学到了什么。
第一部分：问题驱动
🤔 问题1：如果面试官现在打开你的 GitHub repo，第一眼会看到什么？
引导问题：
- README 有没有截图或 demo GIF？（没有 → 面试官 30 秒后关掉）
- 代码有没有 TODO: 和 panic("not implemented")？（有 → 说明你没跑通）
- 有没有
.env 文件被提交上去了？（有 → 简历直接扣分）
- 测试覆盖了关键路径吗？（没有 → "这是个玩具项目"）
答案揭示：
GitHub repo 是你在面试官面前的无声简历。在面试官打开链接的前 60 秒，他会决定这个项目值不值得细看。
🤔 问题2：30天之后，你真正能讲清楚的是什么？
引导问题：
- 如果被问"你们 RAG 的 chunk size 怎么选的"，你能解释选择背后的权衡吗？
- 如果被问"ReAct 和普通 function calling 有什么区别"，你能回答吗？
- 如果被问"你的系统怎么保证 create_ticket 不重复"，你能从数据结构讲到代码吗？
答案揭示：
面试考的不是你知道多少概念，而是你能把"做过的事"讲清楚多深。一个讲透的模块比十个走马观花的更有价值。
第二部分：GitHub Repo 整理 Checklist
仓库结构检查
agent-runtime/
├── cmd/
│ └── api/
│ └── main.go ✅ 启动点清晰
├── internal/
│ ├── agent/ ✅ ReAct 主循环
│ ├── llm/ ✅ LLM Client 封装
│ ├── rag/ ✅ Chunker + Embedder + Retriever
│ ├── tools/ ✅ Tool 实现（search_kb, create_ticket 等）
│ ├── server/ ✅ HTTP handlers + SSE streaming
│ ├── middleware/ ✅ 日志、认证、Cost tracking
│ ├── cache/ ✅ Prompt cache + Response cache
│ ├── metrics/ ✅ CostTracker + LatencyTracker
│ └── security/ ✅ PII 检测 + Injection 检测
├── evals/ ✅ 评测脚本 + golden set
│ ├── golden_set.jsonl
│ └── run_eval.go
├── data/
│ └── docs/ ✅ 知识库文档（markdown）
├── Dockerfile ✅ 两阶段构建
├── docker-compose.yml ✅ 含 Qdrant + Redis + Postgres
├── .env.example ✅ 有示例，无真实 key
├── .gitignore ✅ 忽略 .env 和 binary
└── README.md ✅ 完整文档
12 点代码自查
在把仓库链接发给面试官之前，逐条检查：
正确性
安全
可读性
可操作性
第三部分：README 要素清单
完整 README 结构
# Agent Runtime — Customer Support Copilot
> 一句话描述：用 Go 构建的 AI Agent 系统，通过 RAG + ReAct 架构，
> 自动处理客服工单并支持人工审核工作流。
## 架构图
[在这里放一张架构图，可以用 ASCII art 或 Mermaid]
┌─────────────────────────────────────────────┐
│ 用户 / API │
└────────────────────┬────────────────────────┘
│
┌──────────▼──────────┐
│ Agent Service │
│ (ReAct Loop) │
└──┬───────┬───────┬──┘
│ │ │
RAG Service LLM Tool Hub
│ │
Qdrant Jira / Slack / Postgres
## 功能特性
- RAG 知识库检索（Qdrant Vector DB，Top-K cosine similarity）
- ReAct Agent 循环（最多 5 轮推理，支持并发 tool 调用）
- 人工审核工作流（高危操作走 Kafka → 人工确认）
- 成本追踪（每次 LLM 调用记录 token 用量和费用）
- 流式响应（SSE streaming，首字延迟 < 200ms）
- 防御性安全（PII 检测、Prompt Injection 过滤、幂等性）
## 快速启动
### 前置要求
- Go 1.22+
- Docker & Docker Compose
### 步骤
git clone https://github.com/yourname/agent-runtime
cd agent-runtime
cp .env.example .env
# 编辑 .env，填入 OPENAI_API_KEY 等
docker compose up -d # 启动 Qdrant + Redis + Postgres
go run ./cmd/api # 启动 Agent 服务
### 验证
# 健康检查
curl http://localhost:8080/health
# 发送一条客服消息（流式响应）
curl -N -X POST http://localhost:8080/chat/stream \
-H "Content-Type: application/json" \
-d '{"message": "如何重置我的 SSO 密码？", "user_id": "user_123"}'
## API 文档
### POST /chat
发送消息，获取 Agent 回答（非流式）
请求：
{
"message": "string",
"user_id": "string",
"session_id": "string（可选）"
}
响应：
{
"answer": "string",
"sources": ["string"],
"from_cache": false,
"latency_ms": 1234,
"model_used": "gpt-4o-mini"
}
### POST /chat/stream
流式响应版本，返回 SSE 事件流
SSE 事件格式：
data: {"type": "token", "content": "根据"}
data: {"type": "token", "content": "知识库..."}
data: {"type": "done", "done": true}
### GET /admin/metrics
返回成本和延迟摘要
## 评测结果
在 100 个 golden query 上的评测结果：
|------|----|
| 自动解决率 | 78% |
| Recall@5 | 0.91 |
| 平均响应时间 | 1.2s |
| P99 响应时间 | 3.1s |
| 月成本估算（1K DAU） | ~$38 |
## 技术选型说明
|------|------|------|
| Vector DB | Qdrant | 开源、Go SDK 成熟、支持 filtering |
| LLM | OpenAI GPT-4o / mini | 成本/效果权衡，支持 function calling |
| 缓存 | Redis | TTL 支持、SetNX 幂等键 |
| 消息队列 | Kafka | 审核工作流的持久化和回放 |
| ORM | 标准 database/sql | 避免 ORM 抽象层复杂性 |
第四部分：30天回顾
Week 1 核心学到什么
主题：Go 基础 + LLM Client 封装
- Go module 和项目结构（
cmd/ + internal/ 的设计哲学）
- HTTP middleware 链（
http.Handler 接口的函数式组合）
context.Context 的传播机制（超时、取消、跨函数传递 request_id）- 封装 LLM Client 的必要性：不能让 SDK 细节泄漏到业务逻辑层
interface 设计：LLMClient 接口让测试可以 mock，让实现可以替换
一句话核心洞察：
Go 的 context 不是可选的——它是整个请求链路的"总开关"，Agent 系统的每一层都必须正确传递和响应它。
Week 2 核心学到什么
主题：RAG 系统构建
- Chunking 策略：段落优先 + 大段再分割 + overlap 保留上下文
- Embedding 的本质：把文本映射到高维语义空间，使得相似语义有相似向量
- Vector DB 工作原理：HNSW 索引（近似最近邻，用图结构加速搜索）
- Metadata filtering：在向量相似度基础上加 WHERE 条件（部门、权限等）
- RAG 评测：Recall@K、MRR、Precision@K，以及如何建立 golden set
一句话核心洞察：
RAG 的精度瓶颈通常不在 embedding 模型，而在 chunking 策略和 metadata 设计。好的 chunk 让 LLM 有精准的上下文，差的 chunk 让它只能瞎猜。
Week 3 核心学到什么
主题：Agent 核心链路 + 可观测性
- ReAct 循环（Reasoning + Acting）：LLM 生成思考和行动，工具执行，结果反馈，循环
- Function Calling 协议：
tool_calls 结构，如何解析和执行，如何回传结果
- 人工审核工作流：并非所有 Agent 决策都该自动执行，高危操作走审批
- 结构化日志（slog）+ Trace ID：让每次请求的完整链路可以被回溯
- Metrics 设计：LLM 调用次数/延迟/token、tool 调用成功率、business metrics（自动解决率）
一句话核心洞察：
没有可观测性的 Agent 是黑盒，出了问题只能猜。结构化日志 + Trace ID 是 Agent 系统的基础设施，而不是事后补充。
Week 4 核心学到什么
主题：生产化 + 面试准备
- 成本建模：token × 单价 × 调用量 = 月账单。不知道成本就无法做优化决策
- 模型路由：简单 query 不需要最强模型，节省 40-80% 成本
- Failure Mode 思维：幻觉、超时、注入、PII 泄漏、重复创建——每一类都需要专门的防御
- Post-mortem 文化：事故不是坏事，没有 post-mortem 才是坏事
- Defense in Depth：任何单点防御都会失效，系统应在多层都有防护
一句话核心洞察：
"能跑通"和"生产可用"之间隔着：成本追踪、Failure Mode 防御、可观测性、测试覆盖、文档完整。这 30 天让你补上了这个差距。
第五部分：面试前最后准备
面试前一天 Checklist
技术确认：
内容准备：
心理准备：
面试中的实时策略
听到题目 → 先重复理解（不要立刻开始）
↓
澄清边界（规模、约束、特殊情况）
↓
口头说思路（先说方向，等面试官点头再写）
↓
写代码（从框架开始，再填细节）
↓
自己测试（举一个例子手动跑一遍）
↓
讨论 trade-off（主动说你的方案有什么限制）
第六部分：下一步学习建议
30天后的路径
如果面试还需要 2-4 周：
- 做 2 道 LeetCode Hard（优先：hard DP + 图）
- 深入研究一个你系统里你觉得最薄弱的模块
- 做一次完整的 chaos engineering 演练并记录结果
拿到 Offer 之后：
| 方向 |
推荐路径 |
| 深入 Go 并发 |
读 《Concurrency in Go》（Katherine Cox-Buday） |
| 分布式系统 |
读 《Designing Data-Intensive Applications》（Kleppmann） |
| LLM 系统 |
关注 LangChain Blog、Anthropic Research、OpenAI Cookbook |
| 可观测性 |
学习 OpenTelemetry，在项目里加 Jaeger tracing |
长期能力建设：
- 写 Post-mortem：每次遇到自己犯的 bug，认真写一份 5 Whys。这是 SRE 思维的基本训练
- 做 Benchmark：每引入一个新组件，先测它在你规模下的 P99 latency
- 读源码：你用了 Qdrant、chi、slog，选一个读它的 Go 实现
第七部分：自测清单
第八部分：作业
任务1：做 repo 最终扫描
# 检查是否有敏感内容
git log --all --oneline -- .env
git log --all --oneline -- "*.key"
# 检查所有 TODO
grep -rn "TODO\|FIXME\|HACK\|panic(" --include="*.go" .
# 检查 build
go build ./...
go test ./...
任务2：补全 README
任务3：写一份"30天心得"
不是给别人看的，是给自己的：
- 你在哪一天/哪个模块有了真正的理解突破？
- 哪个问题你现在还没有完全想清楚？
- 如果重来，你会改变哪一天的学习顺序？
任务4：发给一个朋友看 repo
让没有做过这个项目的朋友，跟着 README 启动服务。
- 他卡在哪里了？
- 哪里的文档不够清晰？
- 修复，然后再次发给他验证。
第九部分：常见面试问题（最终版）
Q: 你的项目和直接用 LangChain 有什么区别？
A: 三个核心区别：
（1）可控性：LangChain 隐藏了很多细节，出问题难以调试。我的实现每一层都是显式的，生产排查更直接；
（2）成本感知：LangChain 不内置成本追踪，我实现了 token × 单价的全链路计量；
（3）Go 生态：LangChain 主要是 Python，我的服务用 Go，并发性能更好，部署镜像更小（Go binary vs Python 镜像）。
Q: 30天能做出一个"生产级"系统吗？
A: 我不会说它是生产级，但它包含了生产环境需要考虑的核心问题：幂等性、可观测性、成本追踪、Failure Mode 防御、人工审核工作流。这些在大多数 demo 项目里是缺失的。
如果要真正上线，还需要：完整的 E2E 测试、压力测试、安全审计、以及更多领域知识（比如针对具体客服场景的数据）。这些我知道，也知道怎么做，只是 30 天内做了权衡。
Q: 你觉得 AI Agent 基础设施和传统微服务基础设施最大的不同是什么？
A: 核心不同在于不确定性的位置。
传统微服务：输入确定 → 逻辑确定 → 输出确定，问题通常是性能和可用性。
AI Agent：LLM 的输出本质上是概率性的，同样的输入可能给出不同输出。这带来了新的基础设施问题：
- 如何检测 LLM 给出了错误答案（而不只是崩溃）
- 如何在不确定输出中保证工具调用的安全边界
- 如何衡量系统"质量"（不只是 availability 和 latency，还有 accuracy）
这是我在这 30 天里最大的认知转变。
结语
30 天前，你开始了一个空项目。
今天你有：
- 一个完整的 Go Agent Runtime（RAG + ReAct + 人工审核）
- 对 LLM 成本、延迟、Failure Mode 的系统性认知
- 可以在面试中讲清楚的技术决策和权衡
- 一个可以展示给面试官的 GitHub repo
这不是终点，这是你真正开始理解 AI Infrastructure 的起点。
下一步，你会构建什么？