本项目是中间件课程大作业，实现了一个面向课程作业自动化的多 Agent 编排平台。系统接收作业要求和工作区，依次完成需求分析、历史风格提炼、任务规划、资料整理、解答或代码生成、报告撰写、质量审核、自动修订，并在最终归档前等待人工确认。
项目的重点不是“用 AI 写一次作业”，而是把 Agent、模型、工具、文件和人工决策之间的协调能力做成可复用的中间层。
系统位于上层作业场景与下层模型、文件、工具和外部服务之间：
用户 / 课程作业 / Dashboard
|
统一 REST API
|
多 Agent 作业编排中间件
- Workflow Engine
- State Machine
- ReAct Runner
- Tool Registry
- Approval Gateway
- Context & Artifact Protocol
|
Kimi / 文件系统 / 文档导出 / KV / 注册中心 / 后续课程平台适配器
它符合中间件的主要特征：
- 处于中间层：向上接收不同课程、不同来源的作业，向下屏蔽模型、工具、存储和文件格式差异。
- 提供通用抽象：对外提供统一任务提交、状态查询、人工审批和工件访问接口，而不是只完成某一道题。
- 负责协调而非业务终态：核心职责是节点调度、上下文传递、失败处理、暂停恢复、质量回路和产物管理。
- 支持替换与扩展：LLM Provider、Agent 工具、作业来源、存储服务和提交适配器都可以替换，而上层调用方式保持稳定。
- 可被多个应用复用：同一运行时可以服务于编程作业、实验报告、调研报告和课程设计。
因此，本项目首先是一个“面向作业自动化场景的领域中间件”。Dashboard 只是它的控制台，上层作业完成流程只是它服务的应用场景。
flowchart TB
U["用户 / 课程作业"] --> D["React Dashboard"]
D --> API["统一 REST API"]
subgraph MW["多 Agent 作业编排中间件"]
API --> E["Workflow Engine"]
E --> SM["State Machine"]
E --> R["ReAct Runner"]
R --> TR["Tool Registry"]
E --> AG["Approval Gateway"]
E <--> C["Context & Artifact Protocol"]
end
TR --> LLM["Kimi / OpenAI-compatible LLM"]
TR --> FS["Workspace File System"]
TR --> DOC["Markdown / DOCX Export"]
TR -. optional .-> REG["Lab5 Registry"]
REG -. discover .-> KV["Lab4 TCP KV"]
AG --> H["人工确认"]
需要区分“项目本身实现的中间件机制”和“项目依赖的其他中间件”。
| 技术 | 使用状态 | 在系统中的作用 | 分类 |
|---|---|---|---|
| 自研工作流引擎与状态机 | 主流程必需 | 编排 Agent、推进节点、暂停与恢复 | 项目自身的中间件核心 |
| Tool Registry / Adapter | 主流程必需 | 统一模型、文件、报告和工具调用协议 | 项目自身的中间件核心 |
| Approval Gateway | 主流程必需 | 在关键操作前形成人机协同边界 | 项目自身的中间件核心 |
| Lab4 TCP KV | 可选接入 | 演示远程状态或键值能力复用 | 项目使用的存储中间件 |
| Lab5 注册中心与服务发现 | 可选接入 | 动态发现 kv-store 服务地址 |
项目使用的服务治理中间件 |
| HTTP/REST + CORS | 已使用 | Dashboard 与后端之间的通信协议 | 通信机制，不单独宣称为中间件产品 |
| Kimi K2.5 / OpenAI-compatible API | 已使用 | 为各 Agent 提供推理和内容生成能力 | 外部模型服务，不是本项目的中间件依据 |
| ReactFlow | 已使用 | 展示工作流 DAG 和节点状态 | 前端可视化库，不是中间件 |
| 本地文件系统与 OOXML | 已使用 | 保存工件、导出 Markdown/DOCX | 基础设施与文档组件，不是中间件 |
当前主流程不强依赖 Redis、消息队列、gRPC 或第三方工作流框架。这样可以更直接地展示中间件原理是如何由项目自身实现的。TCP KV 和注册中心作为课程实验能力被保留为可选集成，不会在未启动时阻塞作业流程。
默认工作流共有 11 个节点：
Ingest
-> Requirement Analyst
-> Style Profiler
-> Planner
-> Researcher
-> Executor
-> Report Writer
-> Quality Reviewer
-> Reviser
-> Human Approval
-> Archivist
flowchart LR
I["获取要求"] --> A["需求分析"]
A --> S["风格提炼"]
S --> P["任务规划"]
P --> R["资料调研"]
R --> E["解答 / 实现"]
E --> W["报告撰写"]
W --> Q["质量审核"]
Q --> V["自动修订"]
V --> H{"人工确认"}
H -->|approve| AR["归档记忆"]
H -->|reject| F["流程失败"]
主要角色和产物：
| Agent | 职责 | 主要产物 |
|---|---|---|
| Requirement Analyst | 提取交付物、约束和验收标准 | analysis.json |
| Style Profiler | 从历史作业提炼标题结构和段落习惯 | style-profile.json |
| Planner | 把要求拆解为可执行步骤 | plan.json |
| Researcher | 整理可信背景、待验证假设和资料类型 | research.md |
| Executor | 形成解答、实验方案或代码文件 | solution.md、generated/* |
| Report Writer | 汇总真实上游产物并导出报告 | report.md、report.docx |
| Quality Reviewer | 检查遗漏、虚构、证据和格式问题 | review.json |
| Reviser | 根据审核意见修订报告 | 更新后的报告 |
| Archivist | 归档结果并更新风格画像 | archive.json |
每条 Agent 记录都会标注执行模式：
llm：真实模型调用成功。fallback：模型不可用或响应不合规，使用确定性模板。deterministic：本来就是本地确定性操作，例如风格扫描和归档。
执行 Agent 生成源文件时，只允许写入当前 workflow 的 generated/ 目录，并拒绝绝对路径和 .. 越界路径。涉及外部课程平台提交或任意命令执行的操作仍保留在人工确认边界之外。
final-project/
backend/ Go 中间件运行时、HTTP API、Agent 工具与测试
dashboard/ React + ReactFlow 控制台
scripts/ Windows 启动脚本
deliverables/ 课程报告、DOCX 和演示材料生成脚本
outputs/ 生成的报告与演示文件（不提交到 Git）
推荐在项目根目录执行：
powershell -ExecutionPolicy Bypass -File .\scripts\start-backend.ps1如果 19300 已被占用：
powershell -ExecutionPolicy Bypass -File .\scripts\start-backend.ps1 -Port 19430启动 Dashboard：
cd dashboard
npm install
npm run devLLM 配置保存在 backend/configs/llm.local.json，该文件包含密钥并已被 Git 忽略。也可以在 Dashboard 中保存 Provider、Base URL、Model 和 API Key。
cd backend
go test ./...
cd ..\dashboard
npm run test -- --run
npm run build项目已经使用 Kimi K2.5 做过真实链路验证：需求分析与执行 Agent 均以 llm 模式完成，生成 Go 源码、单元测试和 go.mod，并对生成代码执行 go test ./... 通过。
- 工作流实例主要保存在内存中，重启恢复尚未实现。
- 状态更新通过轮询获取，尚未升级为 WebSocket 或事件总线。
- 外部网页信息获取目前主要依赖模型知识，尚未接入可追溯搜索适配器。
- 教务系统提交需要专用适配器、登录态和人工确认，当前不做无条件自动提交。
- TCP KV 和注册中心为可选能力，默认主流程使用工作区文件保存工件。
更多设计说明见 ARCHITECTURE.md，后端接口见 backend/README.md，课程报告源稿见 deliverables/course-report.md。