一、项目定位解决什么业务痛点在很多传统企业中售后支持通常面临以下困境知识孤岛产品手册、FAQ、故障排查文档分散在各个角落客服查找效率低。重复劳动大量标准化问题如退货流程、保修政策消耗了客服 80% 的精力。系统割裂工单系统与知识库系统往往没有联动导致回复不标准。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 编排、模型调用。拆分带来的好处技术栈解耦后端同学用 Java 写业务算法同学用 Python 调模型互不干扰。独立演进后续更换 Embedding 模型或升级 LangChain 版本不会影响核心交易链路。资源隔离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.md2. 文档先行Documentation First很多项目死在没有文档。为了让这个项目“可阅读、可展示、可复盘”我在docs/目录下建立了四个核心文档ROADMAP.md项目里程碑与长期规划明确每个阶段的交付物。ARCHITECTURE.md详细阐述上述架构图的选型理由与技术栈。API.mdREST API 接口契约定义前后端并行开发的依据。DEVLOG.md开发日志记录每日的技术决策与问题解决过程。3. 开源标准配置为了符合企业级开源标准我完成了以下配置.gitignore严格区分源码与环境配置避免密钥泄露。.env.example提供配置模板降低他人上手成本。License明确开源协议。四、技术决策复盘回顾 Day 1 的工作最核心的决策在于克制。在实习中我见过太多项目因为早期过度设计而导致后期难以维护。KnowFlow Agent 目前只做了两件事定边界通过架构图明确了 AI 与业务的界限。立规矩通过目录和文档确立了开发规范。这种“慢启动”的策略实际上是为了后续的高速迭代铺路。五、下一步计划Day 2 将正式启动Backend-Spring​ 的开发重点构建基础设施层搭建 Spring Boot 基础脚手架。设计统一的Response 响应结构​ 与Global Exception Handler。封装 Result 返回对象规范 API 输出。总结从 0 到 1 的过程往往比写业务代码更能体现一个工程师的工程素养。KnowFlow Agent 的 Day 1 虽然没有实现任何 AI 能力但它确立了一个健康项目的基因清晰的架构、严格的边界以及良好的文档习惯。后续我会持续更新这个系列记录从单体应用到智能 Agent 的完整落地过程。如果你对这个项目感兴趣欢迎在 GitHub 上 Star 或提 Issue 交流。