会议时间：2025年5月16日 参与人员：说话人A（主导，负责整体架构与分工）、小关（前端/Email Agent 开发）、朱晨（API/数据接口开发）

一、核心议题

1. Email Agent 整体能力规划

• 背景：接下来会有很多 AI 功能以 agent 形式存在，部分还要对接到主系统中。本次重点是 Email Agent。
• 目标功能：
  • 可以处理邮箱：搜索某封邮件、查看今天有哪些邮件。
  • 可以基于邮件做内容总结、信息汇总。
  • 可以发送邮件。
• 由小关负责该 Email Agent 的实现，朱晨同步关注后续也会接入类似 agent。

2. 邮箱配置与凭据管理

• 在系统的”设置”页面里，用户可设置自己的邮箱信息，例如企业邮箱。
• 需要先看邮箱客户端设置：包括接收服务器（IMAP）+ 端口号、发送服务器（SMTP）+ 端口号。
• Email 地址 / username 用企业邮箱即可。
• 密码注意：不能用邮箱本身的登录密码，必须使用客户端专用密码（每次需在邮箱后台生成新的），生成后复制粘贴到设置中。两个密码（IMAP/SMTP）填一致。
• 保存后写入数据库表 Email account。

3. 推荐 Agent 与 UI 优化

• 本次会议同时提到说话人A 会接着把”推荐 Agent”再优化，把 UI 界面调整为左右两侧的布局，方便侧边展示。

4. 朱晨负责的 URL/特殊接口处理

• 主要针对亚马逊和领英两个特殊网址，需要对其接口做特殊处理。
• 评估两种实现路径：通用 API 模式 vs 单独实现。

二、技术决策与方案细节

Email Agent 架构

• 基于 ReAct Agent 模式构建：使用 LangGraph 框架，给 AI 模型一个工具集合，由模型自行决定调用哪些工具。
• 系统提示词里可以约定流程顺序：先确认客户信息 → 创建推荐 → 自我检查推荐等。提示词不是强约束，但模型大概率会按流程执行。
• 简单场景（如打招呼）AI 不会调工具；复杂场景下 AI 自行选择调用工具，并汇总工具结果再回复。
• 早期开发优先使用 ReAct Agent；只有当流程复杂、需要明确节点/分支/循环时才自定义工作流。

Email 工具集合（在 tools 目录下）

• 列出邮件（list email）：实际不需要，因为约定每个用户只配一个 Email account，可注释掉。
• 发送邮件、搜索邮件、读取邮件、移动邮件（不同文件夹间）、标记已读/未读。
• 删除邮件：直接禁用，避免误操作。
• 获取邮箱文件夹、创建文件夹、删除文件夹。
• 同步邮件：默认抓取过去 7 天。
• 工具代码大部分由 AI 生成，开发时尽量交给 AI 处理。

IMAP 搜索注意点

• AI 在构建 IMAP 搜索条件时，可能会出现条件构造错误（如组合 AND/与 条件时的语法）。
• 需要让 AI 理解 IMAP 的搜索语义（主题与正文分开搜索；起止时间两个时间节点）。
• 如调试中出现搜索条件错误，需要调整提示词。

数据库与密码加密

• 数据库中存的不是邮箱真实密码，是加密后的（类似加盐）。
• 如果使用线上测试数据库，必须保证两端加密配置一致，否则解出的密码不一致导致连接失败。
• 数据库本地操作命令：
  • package.json 中 db studio 启动本地数据库管理界面；
  • 修改数据库结构后用 db push 同步。

LangGraph 数据保存机制

• 开发模式与部署模式的内部黑盒差异较大，数据库结构不同。
• 开发模式下，部分对话不会真正保存到数据库，而是保存在 langref API 文件夹中。
• 在 graph 内部调用另一个 graph 的场景，会把那部分数据保存到数据库。
• 因此开发期间看到数据库结果不一致是正常的，部署时会解决。

朱晨负责的 URL 处理方案

• 亚马逊、领英两个接口需特殊处理。
• 如果两者调用方式一致（如有统一配置文件、统一的 API 网址匹配规则），则写一个通用 API：URL 命中列表中任意一个就走该流程。
• 如果不能通用，则针对亚马逊、领英分别写单独的逻辑，内部做匹配。
• 处理完后及时提交，并开始着手 agent 相关逻辑。

三、UI/交互细节

设置页面

• 增加邮箱配置入口：接收服务器、端口；发送服务器、端口；邮箱地址 / username；客户端专用密码（IMAP 与 SMTP 一致）。
• 保存后写入 Email account 表。
• 报错形式：使用 toast/post 提示，可带”前往设置”按钮，引导用户跳转到 setting 页面。

Email Agent 输出格式

• 在系统提示词中要求 AI 用 Markdown 格式输出，便于前端渲染信息表格、清单等。

助手选择按钮

• 当前数据太多，将助手相关入口聚合为一个按钮 + 下拉框形式，点击后选择助手。
• 说话人A 会另外发一张参考图给小关。

四、后续行动与分工

角色	任务
小关	实现 Email Agent；用自己企业邮箱配置 IMAP/SMTP 测试；先连线上测试数据库，可读取说话人A 的邮件验证
小关	在 action.ts 中获取 Email account context，校验只能有一个账户，否则报错并引导设置
小关	调试 IMAP 搜索条件构建问题，必要时调整提示词
小关	跑通测试文档中覆盖的几种场景（阅读邮件、回复邮件、今日待处理事项汇总等）
小关	把助手入口聚合为按钮+下拉框（等说话人A 发参考图）
朱晨	处理亚马逊与领英的 URL/接口特殊逻辑；可通用则写通用方案，否则分开写；完成后及时提交
朱晨	处理完 URL 后开始处理 agent 相关逻辑
说话人A	优化推荐 Agent，将 UI 调整为左右两侧布局并集成到侧边

五、其他要点

• 测试文档由 AI 自动生成，无需严格按照执行，只需把流程跑一遍。
• 重点测试场景：“今天要处理哪些事情”——期望 AI 调用读取过去 7 天邮件的工具，并按优先级汇总。后续可做成定时任务/场景触发任务，每天早上主动推送。
• email_account_id 在 LangGraph 的 configure 中可读到，配合用户 ID 获取上下文。
• list email account 工具实际无用，可从工具列表中注释掉。
• 朱晨提到 URL 读取功能仍在测试，部分网站存在问题；目标是任意一个网站能读一次，亚马逊页面要能拿到商家部分信息。
• 强调”先用 AI 生成，再人工调优”的开发节奏，尤其是工具实现部分。
• 后续 Email Agent 可演化为按场景触发的定时任务，主动推送每日待办列表。