子代理协作模式

分析 src/services/ 目录下所有服务的公共接口
找出所有引用了 UserService 的文件
理解认证中间件的工作流程

设计一个缓存层的架构方案
评估从 REST 迁移到 GraphQL 的可行性
制定数据库分表策略

在后台运行完整的测试套件
生成 API 文档
执行代码格式化

我刚接手这个项目，请帮我全面了解它的架构：
1. 用子代理分析后端的目录结构和核心模块
2. 用子代理分析前端的组件树和状态管理
3. 用子代理分析数据库 schema 和实体关系
然后综合三方面的信息，给我一份项目架构概览。

我需要为项目选择一个消息队列。请分别调研以下方案：
1. Redis Streams — 查看我们现有的 Redis 配置是否支持
2. RabbitMQ — 评估引入新依赖的成本
3. 直接用 PostgreSQL 的 LISTEN/NOTIFY
对每个方案，分析优缺点和与我们项目的兼容性。

请在后台运行项目的完整测试套件，我继续做其他事情。
测试跑完后告诉我结果。

请用子代理尝试以下操作：
1. 切换到一个临时分支
2. 尝试升级 React 到 19.x
3. 运行构建，看有多少兼容性错误
4. 把错误列表发给我
不要在主分支上操作。

这是我第一天接手这个项目，请帮我快速建立对项目的理解。
用子代理来并行分析以下方面：

1. 项目结构和入口点 — 扫描目录结构，找到 main 入口、路由定义、配置文件
2. 数据模型 — 分析所有 model 文件，画出实体关系
3. 业务逻辑 — 分析 services 目录，理解核心业务流程
4. 外部依赖 — 分析 requirements.txt 和实际的 import，找出关键依赖

最后请综合所有信息，给我一份不超过 500 字的项目概览。

正在启动 4 个子代理进行并行分析...

[子代理 1] 分析项目结构...

  - 扫描了 52 个 Python 文件
  - 找到入口点：main.py → FastAPI app
  - 路由定义在 routers/ 目录（8 个路由模块）
  - 配置：config.py + .env

[子代理 2] 分析数据模型...

  - 找到 12 个 SQLAlchemy 模型
  - 核心实体：User, Organization, Project, Task, Comment
  - 关键关系：User ← many-to-many → Organization, Project → has-many → Task

[子代理 3] 分析业务逻辑...

  - 9 个 service 文件
  - 核心流程：用户管理、项目管理、任务分配、通知系统
  - 异步任务处理使用 Celery

[子代理 4] 分析外部依赖...

  - 32 个直接依赖
  - 关键依赖：FastAPI, SQLAlchemy, Celery, Redis, Alembic
  - 发现 2 个未使用的依赖（requests, beautifulsoup4）

我需要给项目添加实时通知功能。请帮我并行评估以下三种方案：

方案 A：WebSocket（使用 FastAPI 内置的 WebSocket 支持）
方案 B：Server-Sent Events（SSE）
方案 C：轮询（Polling）

对每种方案，请分析：
1. 与我们现有架构的兼容性（检查现有代码）
2. 实现复杂度（大约需要改多少文件）
3. 性能和可扩展性
4. 客户端兼容性

然后给我一个对比表格和你的推荐。

三个子代理已完成分析。综合对比如下：

| 评估维度 | WebSocket | SSE | 轮询 |
|----------|-----------|-----|------|
| 架构兼容性 | 需要新增 WebSocket 路由 | 可复用现有 HTTP 路由 | 完全兼容 |
| 实现复杂度 | 高（约 8 个文件） | 中（约 4 个文件） | 低（约 2 个文件） |
| 实时性 | 最好（全双工） | 好（服务端推送） | 一般（取决于轮询间隔） |
| 可扩展性 | 需要 WebSocket 负载均衡 | 可用 CDN | 最简单 |
| Celery 集成 | 需要额外的消息桥接 | 可直接消费 Celery 事件 | 轮询数据库即可 |

**推荐**：考虑到你们已经使用 Celery + Redis，SSE 是最佳选择。
它可以直接订阅 Redis 频道获取 Celery 事件，实现复杂度适中，
而且不需要额外的基础设施。

请在后台运行 pytest，跑完整个测试套件。我继续改代码，跑完了告诉我。

后台测试已完成。结果：

- 总计：247 个测试
- 通过：241 个
- 失败：4 个
- 跳过：2 个

失败的测试：
1. test_order_service.py::test_calculate_total_with_discount
   AssertionError: 99.99 != 100.0
2. test_user_service.py::test_create_user_duplicate_email
   IntegrityError: 测试数据库未正确清理
3. ...

需要我帮你分析这些失败的测试吗？

## 子代理使用规范

### 何时使用子代理

- 分析超过 10 个文件的任务，应使用子代理
- 需要对比多个方案时，为每个方案启动独立子代理
- 运行测试应在后台子代理中执行

### 子代理任务描述模板
启动子代理时，任务描述应包含：
1. 明确的目标（做什么）
2. 范围限制（不做什么）
3. 输出格式（返回什么样的结果）

### 子代理结果处理
子代理的结果必须包含：

- 分析摘要（不超过 200 字）
- 关键发现列表
- 相关文件路径
- 潜在风险或问题

请用子代理分析（只读）src/models/ 目录下所有模型的关系。

请在后台帮我做两件事：
1. 运行完整的 lint 检查
2. 检查所有依赖是否有已知的安全漏洞
我继续改代码，完成后告诉我结果。

用子代理检查一下刚才说的那个问题。

用子代理检查 src/services/payment_service.py 中的
process_refund() 方法是否正确处理了并发退款请求。
需要关注数据库事务隔离级别和乐观锁的使用。

请并行执行以下任务：
1. [子代理 A] 分析前端代码中所有的 API 调用点
2. [子代理 B] 分析后端的 API 端点和参数定义
3. [子代理 C] 检查 API 文档是否与实际接口一致

三个任务完成后，汇总出 API 不一致的地方。

子代理告诉我 payment_service.py 第 127 行有问题，
请帮我看看这个文件的 120-140 行。

请用子代理做个实验：
1. 创建一个临时目录 /tmp/experiment
2. 把 src/models/user.py 复制进去
3. 尝试用 dataclasses 替代 SQLAlchemy 的声明式模型
4. 看看会有什么问题

不要动项目的任何文件。

（Plan 模式下）
请用子代理帮我调研以下问题，然后基于调研结果制定迁移计划：
1. 当前所有 REST API 的端点列表和调用频率
2. 哪些端点已经有 GraphQL 的等价实现
3. 客户端代码中对 REST API 的依赖程度

请用子代理连接数据库，分析以下内容：
1. 各表的数据量
2. 慢查询 Top 10
3. 缺失的索引
用数据库 MCP 工具来执行查询。

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "curl -X POST https://hooks.slack.com/... -d '{\"text\": \"$MESSAGE\"}'"
          }
        ]
      }
    ]
  }
}