一、项目定位：解决什么业务痛点？

在很多传统企业中，售后支持通常面临以下困境：

1. 知识孤岛：产品手册、FAQ、故障排查文档分散在各个角落，客服查找效率低。

2. 重复劳动：大量标准化问题（如退货流程、保修政策）消耗了客服 80% 的精力。

3. 系统割裂：工单系统与知识库系统往往没有联动，导致回复不标准。

KnowFlow Agent​ 旨在解决这些问题，它不仅仅是一个聊天机器人，而是一个企业知识库与智能工单处理平台。

核心功能规划

• 知识库管理：支持 PDF/Word/Markdown 等多格式文档的上传与解析。

• RAG 增强问答：基于检索增强生成技术，确保回答有据可依，减少大模型幻觉。

• 引用溯源：回答结果附带原文出处，方便客服复核。

• 智能工单：自动提取会话内容生成工单摘要，并进行分类与回复建议。

• Agent 工具调用：支持 AI 主动查询订单状态、发起退款等操作。

---

二、技术架构设计：为什么选择多服务拆分？

在设计之初，我面临一个关键决策：是把 AI 能力耦合在 Spring Boot 业务中，还是拆分为独立服务？

考虑到生产环境中，业务系统的稳定性与AI 模型的迭代速度往往是不同步的，且 Python 生态在 AI 领域具有天然优势。因此，我选择了 Spring Boot + FastAPI 的多服务架构。

架构全景图

┌─────────────┐
│  Vue 3 UI   │
└──────┬──────┘
       │ REST API
┌──────▼──────────┐
│  Spring Boot    │  ← 业务权威来源
│  (Backend)      │
│  - 用户/权限    │
│  - 工单/知识库  │
│  - MySQL/Redis  │
└──────┬──────────┘
       │ RPC / HTTP
┌──────▼──────────┐
│  FastAPI        │  ← AI 能力中心
│  (AI Service)   │
│  - LLM/RAG      │
│  - Embedding    │
│  - Agent Tools  │
└──────┬──────────┘
       │ Vector DB
┌──────▼──────────┐
│  向量数据库     │
└─────────────────┘

职责边界划分

服务	技术栈	核心职责
Backend Spring​	Java / Spring Boot	负责重业务：用户鉴权、工单流转、数据持久化、事务管理。
AI Service​	Python / FastAPI	负责重算力：文档解析、向量化、Prompt 编排、模型调用。

拆分带来的好处：

1. 技术栈解耦：后端同学用 Java 写业务，算法同学用 Python 调模型，互不干扰。

2. 独立演进：后续更换 Embedding 模型或升级 LangChain 版本，不会影响核心交易链路。

3. 资源隔离：AI 服务通常需要更高配置的 GPU/CPU 资源，可以独立部署和扩缩容。

---

三、Day 1：工程治理与项目骨架

实习经历让我意识到，项目的第一印象往往决定了它的生命周期。因此，Day 1 我没有写一行业务代码，而是专注于工程治理（Engineering Governance）。

1. 目录结构设计

一个清晰的目录结构是团队协作的基础。我采用了多模块扁平化结构：

knowflow-agent/
├── backend-spring/   # Spring Boot 业务后端
├── ai-service/       # FastAPI AI 服务
├── frontend-vue/     # Vue 3 前端 (占位)
├── deploy/           # Docker Compose 部署配置
├── docs/             # 核心设计文档
├── examples/         # 示例数据与请求
├── .env.example      # 环境变量模板
├── .gitignore
└── README.md

2. 文档先行（Documentation First）

很多项目死在没有文档。为了让这个项目“可阅读、可展示、可复盘”，我在 docs/目录下建立了四个核心文档：

• ROADMAP.md：项目里程碑与长期规划，明确每个阶段的交付物。

• ARCHITECTURE.md：详细阐述上述架构图的选型理由与技术栈。

• API.md：REST API 接口契约定义，前后端并行开发的依据。

• DEVLOG.md：开发日志，记录每日的技术决策与问题解决过程。

3. 开源标准配置

为了符合企业级开源标准，我完成了以下配置：

• .gitignore：严格区分源码与环境配置，避免密钥泄露。

• .env.example：提供配置模板，降低他人上手成本。

• License：明确开源协议。

---

四、技术决策复盘

回顾 Day 1 的工作，最核心的决策在于克制。

在实习中我见过太多项目因为早期过度设计而导致后期难以维护。KnowFlow Agent 目前只做了两件事：

1. 定边界：通过架构图明确了 AI 与业务的界限。

2. 立规矩：通过目录和文档确立了开发规范。

这种“慢启动”的策略，实际上是为了后续的高速迭代铺路。

---

五、下一步计划

Day 2 将正式启动 Backend-Spring​ 的开发，重点构建基础设施层：

1. 搭建 Spring Boot 基础脚手架。

2. 设计统一的 Response 响应结构​ 与 Global Exception Handler。

3. 封装 Result 返回对象，规范 API 输出。

---

总结

从 0 到 1 的过程，往往比写业务代码更能体现一个工程师的工程素养。

KnowFlow Agent 的 Day 1 虽然没有实现任何 AI 能力，但它确立了一个健康项目的基因：清晰的架构、严格的边界以及良好的文档习惯。

后续我会持续更新这个系列，记录从单体应用到智能 Agent 的完整落地过程。如果你对这个项目感兴趣，欢迎在 GitHub 上 Star 或提 Issue 交流。