会议时间：2026 年 1 月 20 日 参与人员：说话人 A（主持，负责整体功能规划与任务分派）、说话人 B（开发）、小关（前端 / 邮件相关）、朱晨（PDF / 后端相关）

一、核心议题

1. 客户开发 / 客户背调入口的输入框与模板化设计

• 在客户开发、客户背调等入口点击之后，需要弹出一个输入框，让用户输入客户名称或网址。
• 这一交互背后实际上是一种”模板”形式：用户输入 → 触发对应模板。
• 当前优先级最高，分配给小关：先验证使用原生输入框是否能实现该功能，再考虑后续点击之后如何展开后续逻辑。
• 模板内容可以先让 AI（Codex / Claude 等）自动生成一份，先有一个可用版本，再迭代优化。

2. 发送邮件工具与”创建草稿”画布的处理

• 之前的”发送邮件”工具被删除，改成了”创建草稿”，但创建草稿在新框架（画布）里的发布流程不通，目前需要重新做发送邮件的工具。
• 决策：把”发送邮件”这个技能 block 掉，不再作为独立技能，而是作为 agent 内部的一个工具（创建草稿的工具）。
• 在 agent 调用工具后，前端按工具调用的方式去渲染 UI，而不是为每种实现单独写组件。
• 创建邮件后需要让前端渲染成可点击的项，点击后把内容显示到”写邮件的弹窗”里，不直接发送，由用户确认。
• 强调通用性：后续会接入 Claude Code、Claude Agent SDK 等多种实现，不能为每种实现单独定制 UI。

3. 拖拽与邮件信息读取问题

• 目前邮件部分的拖拽存在卡顿问题，需要排查。
• 邮件回复时，AI 没有读到当前邮件 / 线程的信息，需要把当前邮件 ID 注入进去（通过邮件 ID 注入的方式）。

4. PDF 压缩

• 目前生成推荐 PDF 时没有压缩，原来的压缩代码被误删。
• 朱晨负责：在历史”生成推荐”代码中找到压缩代码，放到技能脚本里。
• 压缩相关的依赖装到 doc 文件（依赖目录）里。

5. 图片相关工具（分析图片 / 生成与编辑图片）

• 新增”分析图片”工具：
  • 用户上传的图片会放入 workspace 文件中，不作为对话上下文消息直接发送。
  • 工具对指定路径的图片文件进行分析。
  • 默认使用 GPT 模型（更稳定），通过 AI Gateway provider 调用，使用环境变量里已配置的 AI Gateway key。
  • 默认行为是描述图片；可增加参数控制描述的针对性，例如开发页面的代码场景下重点描述 UI 效果与布局。
  • 提示语中需要根据上下文设置不同的描述侧重点，但即便有针对性也应包含基础描述。
• 新增”生成 / 编辑图片”工具：
  • 使用 Gemini 3 image 模型，也通过 Gateway provider 调用。
  • 注意：Gemini 在生成图片时走的仍是 generateText 接口，需要按生成文本的方式获取结果。
  • 返回的结果如果是 URL，则直接在会话里使用；如果不是 URL，则下载下来写入 workspace。
  • 是否直接写入文件或先作为上下文存在，按实际开发情况选择。
• 这两个工具是为后续”产品设计技能”（产品编辑与变种设计）做准备，先实现这两个基础工具，再考虑产品设计技能。

6. 邮件回复 UI 改成弹窗形式

• 当前点击回复后是在下方展开，调整为类似弹窗形式。
• 回复区域的几个操作按钮调整到弹窗上部（暂定位置）。
• 这部分分配给小关。

7. 历史邮件脉络分析按钮

• 保留原有”解析此邮件并拟定回复”按钮（点击后向 email agent 发送提示语）。
• 新增按钮：“历史脉络分析”——当一个邮件有非常长的历史记录时，让 AI 梳理整个沟通的历史脉络。
• 标题区的”回复 / 全部回复”等文字按钮全部改成 icon，可参考其他邮件客户端的 icon 风格。

8. Docker 中命令行交互模式问题（bug）

• 当前在 Docker 里运行时，命令行无法进入交互模式，与本地开发不同，会影响后续在命令行中启动的服务。
• 由说话人 A 在排查处理。

9. 工具搜索方案验证（Tool Search）

• 当前已有 15 个工具，加入邮件、待办、网盘、系统设置等工具后总数预计达到 30 个左右。
• 工具数量过多会导致一开始就消耗约 2 万 tokens，需要”压缩上下文”的方案：
  • 通过一个小模型在每次发送消息时，先判断需要加载哪些工具。
  • 参考 Claude Code 最近发布的 tool search tool 方案（主要针对 MCP）。
  • 我们的方案可以扩展到所有工具，或对工具分类：基础工具不进搜索方案，其他工具走搜索方案。
• MCP 设置先对用户隐藏，是否把所有工具作为 MCP 集成仍在评估。

二、技术决策与方案细节

• 发送邮件改为 agent 工具（不是独立技能），前端按 SDK 的 UI message 默认机制根据工具调用渲染。
• 图片分析工具默认使用 GPT 模型走 AI Gateway provider；生成 / 编辑图片使用 Gemini 3 image 走 AI Gateway provider。
• Email Agent 与默认 Agent 的对话组件复用：Email agent 那部分代码重写较多，需要小关考虑能否继续复用同一个对话组件。
• 系统设置工具（一个工具承载两类事项）：
  • 邮箱账户设置（普通用户配置邮箱较复杂，后续会有”辅助配置邮箱”的技能）。
  • 自定义 AI / 个性化设置。
  • 后续系统中其他设置都会被统一加载到这个 agent 里操作。

三、UI / 交互细节

• 客户开发 / 客户背调入口：点击后弹出输入框，输入客户名称或网址，背后驱动模板。
• 邮件回复：从下方展开改为弹窗形式，操作按钮放在弹窗上部。
• 邮件标题区：“回复 / 全部回复”等文字按钮改为 icon。
• 新增”历史脉络分析”按钮（点击后等同于在 email agent 弹窗发送一条提示语）。
• 邮件信息注入：通过邮件 ID 把当前邮件 / 线程信息注入到 AI 上下文。
• 工具调用渲染：前端针对特定工具调用配置专属渲染 UI（基于 SDK 默认 UI message 机制）。

四、后续行动与分工

负责人	任务
小关	客户开发 / 背调输入框 + 模板（最高优先级）；发送邮件工具调用的前端渲染组件；邮件回复改为弹窗形式 + icon 化；考虑 Email agent 与默认 agent 对话组件复用；系统设置工具（邮箱账户 + 自定义 AI）
朱晨	PDF 压缩代码恢复并放入技能脚本；压缩依赖装入 doc；图片相关工具的实现（分析图片、生成 / 编辑图片）
说话人 A	Docker 命令行交互模式 bug 修复；工具搜索方案的整体设计与验证；MCP 集成方式的最终决策
说话人 B	重新实现发送邮件工具（作为 agent 工具）

• 周四或周五发布一个版本，不要求全部完成，按优先级做到能做的程度即可。

五、其他要点

• 后续 agent 方向：所有内置工具（邮件、待办、网盘、系统设置）默认接入到普通 agent 中，普通 agent 即可调用 Email 工具，而不需要嵌入上下文处理。
• 邮箱账户配置后续可能有专门的”配置辅助技能”协助用户完成。
• 工具数量增长后必须有上下文压缩机制（通过小模型路由 + 工具搜索）。
• HTML 链接相关问题待说话人 A 进一步确认。
• 整体优先级以会上排序为准，不必全部做完，本周末发版。