会议时间：2026-05-28
原始记录：项目多方面情况讨论.txt
说明：原文为语音转写，部分术语存在转写不稳定情况。本文将 renewmake / renumake / renew Mac / RenewMint 等统一按 RenewMake 理解；countryadd / contractyard / controller yard 等统一按当前新项目或 agent 运行平台理解；cloud / closed code 等按上下文整理为 Claude / Claude Code / Claude Agent SDK 相关内容。

1. 会议核心结论

本次会议主要围绕新项目近期各条任务线的进展、MCP Apps / MCP UI 的沙箱能力、找客户 Agent、产品推荐、邮件 MCP Server、RenewMake CLI 对接，以及后续 RenewMake 与新项目之间的架构关系展开。

整体结论如下：

• 当前优先目标仍然是先把几个核心业务场景在新项目中跑通，包括找客户、产品推荐、邮件草稿/发送、CRM 写入等。
• MCP Apps / MCP UI 相关能力需要重点解决沙箱内打开链接、下载文件、组件与 host 双向通信等问题。
• 找客户 Agent 已基本能运行，能够导入脚本、输入 key 和 URL，并把结果加载到 CRM，但下载能力和部分 UI 体验还可以后置优化。
• 产品推荐已经支持编辑和导出，编辑后会保存到 RenewMake 数据库，并且版本会递增。
• 邮件 MCP Server 当前重点不是追求所有旧功能完全一致，而是先保证创建、编辑、上下文更新、发送等主流程可用。
• rewrite / write with AI 这类按钮可以先降级为快捷发起一条用户消息，由下方对话里的 agent 继续处理，而不是在组件内部单独实现复杂 AI 编辑逻辑。
• 后续 RenewMake 中所有 AI / agent 相关逻辑倾向于逐步改为调用新项目提供的 SDK / API，由新项目负责 agent 创建、session 运行、MCP Server、工具和运行环境。
• 当前阶段仍允许通过导入脚本或固定环境变量方式快速验证，等新项目能力稳定后，再清理临时脚本和重复逻辑。

2. 各任务线当前进展

2.1 新项目沙箱权限与下载能力

小关反馈：新项目中有一块需要开权限，目前沙箱组件内无法打开新链接，也无法下载文件。已经测试了几种下载方式，都会被拦截。

会议讨论认为，这个问题和 MCP Apps / MCP UI 的 host 与 iframe / sandbox 交互有关。ChatGPT 或类似 MCP Apps host 本质上会作为一个外层主机，向内部 MCP UI 组件暴露一组能力接口，例如打开链接、全屏、消息通信等。

需要重点研究：

• MCP UI / Apps SDK 是否已经提供下载接口。
• 是否可以通过 onOpenLink 之类的接口，把下载链接传到外层 host，再由外层打开新窗口或触发浏览器下载。
• 如果 MCP UI 规范没有下载能力，是否需要项目自己扩展 host 接口。
• 如果不能直接下载，是否先采用打开链接、右键下载或跳转外部页面的方式临时解决。

会议倾向是：短期可以先不死磕下载，优先跑通主流程；下载能力后面再处理。最好使用链接形式走浏览器默认下载目录。如果改成 JS 下载，则需要处理下载进度、大文件、失败状态等，复杂度更高。

2.2 找客户 Agent

找客户 Agent 当前已能正常运行：

• 可以导入脚本。
• 运行时需要输入 key 和 URL。
• 找客户结果会以表格形式生成。
• 结果可以加载到 CRM 中。
• 相关输出和之前系统提示词生成的效果差不多，会包含客户和对应信息。

会议确认：

• 找客户 Agent 写入 CRM 时仍涉及 MCP token。
• 当前 token / URL 可以在导入脚本后作为参数填写。
• 本地开发阶段可以让 AI 或开发者直接设置 key 和 URL。
• 也可以先走测试环境，用测试账号配置 MCP key 和 URL。
• 目前这种配置方式可以先保留。

需要注意的是：找客户 Agent 后续还需要把组织上下文和用户上下文注入进去，否则 agent 只知道通用规则，不知道当前公司的业务背景、组织规则、用户偏好等。

2.3 产品推荐

产品推荐当前状态：

• 可以编辑。
• 可以导出。
• 导出能力目前临时放了一个“打开链接”按钮。
• 右键链接实际上也可以下载。
• 编辑后会直接保存到 RenewMake 数据库。
• 每次编辑保存后版本号会递增。

会议结论是：产品推荐的下载能力可以先放一放，主线是先保证功能可用、UI 可用，并且能和 RenewMake 数据库正确同步。

后续 RenewMake 对接时，产品推荐会是比较明确的 MCP Apps 场景之一，需要和新项目中的 agent 运行、数据库保存、版本递增机制继续打通。

3. MCP Apps / MCP UI 通信机制

3.1 当前需要理解的层次

会议中把整体结构拆成几层：

1. ChatGPT / 外层应用

   • 可以理解为 MCP Apps host。
   • 负责承载前端聊天界面。
   • 负责给内部 MCP UI 组件提供部分能力接口。

2. MCP UI / MCP Apps 组件

   • 在沙箱中渲染。
   • 和外层 host 之间通过约定接口通信。
   • 可用于展示编辑器、产品推荐、邮件草稿等交互式 UI。

3. MCP Server

   • 提供实际工具能力。
   • 返回资源、组件或数据。
   • 与 agent runtime 交互。

当前项目中不一定直接使用 MCP UI client 的高层组件，而可能是使用了更底层的协议和渲染能力。会议中提到，之前 AI 分析认为当前不必立刻切换到 MCP UI client 组件，因为现有底层实现已经能满足一些需求，而且项目里还涉及代理等自定义逻辑。

3.2 需要重点研究的接口

会议中特别提到可以让 AI 分析 MCP UI client / Apps render 相关代码，看看是否已有：

• onOpenLink：用于打开链接，可用于下载链接外抛。
• onMessage：用于组件和 host 之间传消息。
• 发送用户消息的方法：组件中某个按钮触发后，向聊天框发送一条用户消息。
• update model context：组件内部状态变化后，将隐藏上下文同步给模型。

会议倾向：

• 普通场景不需要自己做大量定制化 message 传输。
• 优先使用 MCP Apps / OpenAI Apps SDK 已有约定。
• 对于下载、打开链接、全屏、快捷发送用户消息等能力，应优先走 host 暴露的标准接口。

4. 组织上下文和用户上下文注入

4.1 为什么要注入上下文

找客户、产品推荐、邮件撰写等 agent 不能只依赖通用系统提示词。后续接入 RenewMake 后，还需要知道：

• 当前组织信息。
• 当前组织的业务背景。
• 当前组织规则。
• 当前用户上下文。
• 用户偏好设置。
• RenewMake 中配置的自定义 AI 或组织级设置。

这些内容不适合都写进 agent 的静态系统提示词，因为 agent 是预先创建好的，系统提示词应尽量保持通用。

4.2 建议的注入方式

会议参考 Claude / Claude Code 的真实请求结构，提到 Claude 会把一些隐藏用户消息拼到上下文里，并用类似 system-reminder 的标签包起来。

建议后续采用类似方式：

• agent 创建时只保留通用系统提示词。
• 创建 session 或第一次发起请求时，先构建一条隐藏的 user message。
• 这条隐藏消息中包含组织上下文和用户上下文。
• 后面再接真正的用户输入，例如“帮我找客户”。

这样做的好处：

• 静态 agent 配置更稳定。
• 用户和组织上下文可以按 session 动态注入。
• 对模型缓存更友好。
• 可以区分用户真正说的话和系统/业务侧注入的信息。

短期会议结论是：这块可以先不立刻实现，但后续 RenewMake 对接时需要补上。

5. 邮件 MCP Server 与草稿编辑

5.1 当前进展

初晨反馈：邮件相关 MCP Server 中，部分内容已经可以写出来，但 AI rewrite、预览等旧项目组件还没有完全完善。

会议讨论后认为：这些复杂能力可以先不要完全复刻，关键是先保证主要链路能正常使用。

邮件相关主流程包括：

• 创建邮件草稿。
• 展示邮件草稿 UI。
• 用户可以编辑草稿。
• 编辑后通过 update model context 同步上下文。
• agent 知道用户已经修改过草稿。
• 用户可以发送邮件。
• 发送后 UI 和上下文状态正确更新。

5.2 Rewrite / AI 重写按钮的处理方式

会议建议：rewrite 不需要在邮件编辑器内部重新实现一套 AI 修改流程。

更合适的短期做法是：

• 在邮件 UI 里保留 rewrite 按钮。
• 用户点击后，组件通过 MCP Apps 通信接口向聊天区发送一条用户消息。
• 这条消息表达用户希望重写或优化当前草稿。
• 下方 agent 根据当前草稿上下文继续处理。

这样 rewrite 按钮本质上是一个快捷操作，而不是一个独立的内部 AI 编辑器。

5.3 附件显示样式

附件区域需要做样式优化：

• 直接显示文件名。
• 文件名过长时需要截断。
• 附件展示不应占用过多空间。
• UI 要更接近正常邮件客户端的附件展示方式。

5.4 创建邮件后的模型回复

当前创建邮件草稿后，模型可能会在下方重复输出很多邮件详情。会议认为这不合理，因为邮件详情已经通过 UI 展示。

建议修改创建邮件草稿工具的描述，让模型知道：

• 邮件草稿会通过 UI 展示。
• 工具调用后不需要在文本回复中重复完整邮件内容。
• 最多用一句话总结即可。
• 不要输出冗长详情。

这个约束优先放在创建邮件草稿的 tool description 中。

5.5 get draft / update context 的重复展示问题

当前存在一个问题：agent 修改或发送邮件时，可能会调用 get draft，而 get draft 又渲染出一个草稿 UI，导致消息中出现重复组件。

会议讨论认为：

• get draft 是为了让模型确认最新草稿内容，类似写代码时修改文件后再读一次文件。
• 但在邮件场景中，很多时候可以依靠 update model context 获取最新状态。
• 即使保留 get draft，它也不一定要渲染 UI。
• 用户查询邮件和模型内部读取草稿应该区分开。

建议调整：

• get draft 默认不渲染编辑器 UI。
• 去掉或弱化“每次修改后都必须 get draft”的约束。
• 改成只有确实需要确认草稿内容时才读取。
• 用户编辑草稿后，通过隐藏消息告诉模型“用户已编辑草稿”以及必要的草稿内容。
• 隐藏消息可以考虑使用标签化格式，和普通用户消息区分开。

5.6 update model context 的消息形态

会议中提到，update model context 产生的结构化消息可能有两种处理方式：

• 直接构建成一条 message。
• 或者先生成纯文本，再由 host 拼接成隐藏 user message。

无论哪种方式，最终都应该进入模型上下文，并且应该：

• 使用 user role 或等价形式。
• 对用户隐藏。
• 通过标签和普通对话内容区分。
• 能表达用户在 UI 中做过什么修改。
• 必要时包含修改后的关键内容。

具体要看当前代码里 update model context 如何被拼进上下文，再决定用结构化 message 还是纯文本拼接。

5.7 发送邮件后的重复调用和错误

会议中看到旧截图里发送邮件时似乎调用了多次工具，甚至出现 error。初晨说明这可能是较早版本的问题，最新版本可能已经没有。

会议判断：

• 旧问题可能是工具调用失败后，模型重复尝试调用导致。
• 需要在最新代码中重新验证。
• 如果仍有多次调用，需要看调试 timeline 中的工具调用记录，判断是模型重复调用还是 UI 渲染重复。

6. 邮件技能、附件和内嵌图片

6.1 邮件 skill 的定位

会议区分了两类 skill：

1. 工具使用型 skill

   • 告诉 AI 如何使用某个 CLI 或工具。
   • 例如 RenewMake CLI 怎么搜索客户、怎么组合参数、怎么调用脚本。

2. 知识型 / 写作型 skill

   • 告诉 AI 如何写好一封邮件。
   • 例如开发信写作原则、销售邮件结构、语气、内容组织。

邮件场景里，skill 不应包含脚本，也不应承担 MCP Server 使用说明。邮件 MCP Server 的使用方式应由 MCP Server / tool description 约束。邮件 skill 可以只负责“如何写好邮件”。

会议甚至认为：邮件这块短期可以先不加 skill，等主流程跑通后再根据需要补充写作知识。

6.2 内嵌图片与附件判断

会议讨论了图片应该放在邮件正文中还是作为附件的问题。

结论倾向：

• agent 需要具备判断能力。
• 图片类文件如果适合作为产品展示、效果图、封面图，通常应放入正文合适位置。
• 如果图片只是普通资料或用户明确要求作为附件，则作为附件。
• PDF、文档等其他格式通常作为附件。
• 邮件正文中提到附件时，可以自然写出“产品图片及详细 PDF 请见附件”之类表述。

需要通过提示词或邮件写作 skill 约束 AI：

• 根据用户意图、文件类型和邮件内容判断内嵌还是附件。
• 不确定时可以询问用户。
• 不要机械地把所有图片都作为附件，也不要把所有图片都塞进正文。

6.3 已发送邮件不可编辑

旧功能中可能存在已发送邮件仍显示可编辑入口的问题。会议明确：已发送邮件不应再允许编辑。

需要检查：

• 已发送状态下收件人、发件人、正文等是否还能点编辑。
• 已发送邮件组件是否还展示编辑按钮。
• 发送后的 UI 状态是否切换正确。

6.4 编辑器高度、滚动和全屏

当前邮件编辑器可能存在内容显示不全、滚动异常的问题。

会议建议：

• 邮件编辑器内容区域应有固定高度。
• 内容超出时可以滚动。
• 交互体验要接近普通邮件客户端。
• 可以提供全屏处理能力。
• 目标不是完全复刻旧版本，而是保证用户能正常编辑、查看和发送。

7. RenewMake CLI、认证和新项目对接

7.1 当前 CLI 对接问题

初晨提到：当前构建时依赖 RenewMake 自己把命令打包，再发到新项目中。

会议认为后续不应该长期依赖这种方式。RenewMake CLI 属于 RenewMake 项目，可以在 RenewMake 内部提供安装链接或安装方式，让 agent 根据文档安装和使用。

CLI 认证是主要问题之一：

• CLI 执行时需要 token。
• token 可以来自环境变量。
• 也可以来自某个系统设置。
• 还可以通过一个专门的 RenewMake MCP 提供认证信息。
• 未来如果新项目 SDK 支持创建 session 时设置执行环境变量，可以在 session 启动时把 token 注入进去。

7.2 短期认证方案

会议认为，当前阶段重点是先跑通验证，不必一开始就做最规范的认证体系。

短期可以：

• 在 skill 或脚本中固定测试配置。
• 通过环境变量传 token。
• 使用测试账号。
• 让导入脚本传 key 和 URL。

等 SDK / session / environment 能力更规范后，再改成创建 session 时设置环境变量或通过凭证体系注入。

7.3 长期架构方向

会议明确了一个更长期的方向：后续 RenewMake 中所有跟 AI 有关的逻辑，都尽量通过新项目的 SDK / API 调用。

长期形态大致是：

• RenewMake 自己不再管理 agent 运行细节。
• RenewMake 中的自定义 AI、组织设置、用户设置等，通过 SDK 同步或创建到新项目。
• 新项目提供 create agent、list agent、new session、run session 等能力。
• agent 的运行、MCP Server、工具调用、上下文、运行环境都交给新项目。
• RenewMake 只作为业务系统和前端入口存在。

这也是为什么当前要让大家在新项目中直接跑 RenewMake 场景：开发过程中可以暴露新项目 SDK、MCP、UI、上下文等基础能力的问题，并及时调整。

等新项目验证完整后，RenewMake 中原来维护 agent、导入脚本等临时逻辑都可以逐步删除。

8. 脚本拆分和本地开发规范

会议中提到，部分导入脚本或测试脚本不应和 local runner 启动逻辑混在一起。

要求：

• 把导入脚本作为单独脚本处理。
• 不要写进 local runner start 或本地 runner 启动流程。
• 参考小关的脚本组织方式，将业务导入、测试账号绑定、local runner 启动拆开。
• 本地开发需要跑脚本时手动执行即可。
• 后续这些脚本很可能一次性删除，因为正式流程应由 RenewMake 调 SDK 创建 agent，而不是靠导入脚本。

会议还讨论了是否将脚本中的配置指向测试环境，例如 .com 或测试 API。结论是可以根据开发便利性处理，但核心是不要让临时脚本污染正常启动流程。

9. 合并与发布相关讨论

会议末尾讨论了几个分支或改动是否可以合并：

• RenewMake 相关改动可以先合并。
• 找客户相关改动可以合并。
• 产品推荐相关改动可以合并。
• 特定搜索相关改动可以合并。
• 邮件 draft / get / update context 相关问题还需要继续调整。
• 导入脚本需要拆成单独脚本后再整理。

会议也提到：RenewMake research 命令之前可能被错误地对外提到，已有客户在使用，因此合并时要注意不要影响正式环境。判断上认为 CLI agent 应该会根据 router / 参数自己做调整，影响不大，但仍需谨慎验证。

10. 具体待办事项

事项	负责人/涉及人	优先级	说明
研究 MCP UI / Apps 是否提供下载或打开链接接口	小关	高	重点看 onOpenLink、host 通信、沙箱下载限制
找客户 Agent 主流程继续验证	小关	高	确认导入脚本、key / URL、CRM 写入、结果表格都稳定
产品推荐 UI 和导出体验优化	小关	中	下载可后置，先保证编辑、保存、版本递增可用
后续补充组织上下文和用户上下文注入	待定	中	第一次请求前拼隐藏 user message
邮件附件区域样式优化	初晨	中	显示文件名、长文件名截断
创建邮件草稿 tool description 调整	初晨	高	避免模型在文本回复中重复完整邮件详情
get draft 不再默认渲染 UI	初晨	高	减少重复草稿组件
修改“每次编辑后必须 get draft”的约束	初晨	中	改为必要时读取，优先依赖 update model context
梳理 update model context 如何进入上下文	初晨	高	决定用结构化 message 还是纯文本隐藏消息
检查发送邮件重复工具调用问题	初晨	中	结合最新 timeline 验证是否仍存在
已发送邮件禁用编辑能力	初晨	中	已发送状态不应再显示编辑入口
邮件编辑器滚动和全屏体验调整	初晨	中	固定高度、内容滚动、必要时全屏
邮件内嵌图片 / 附件判断提示词补充	初晨	中	图片根据语义判断放正文或附件，其他文件多作为附件
RenewMake CLI 认证方式调研	初晨 / 相关开发	中	环境变量、MCP 获取 token、session 注入 env 等
导入脚本从 local runner 启动流程中拆出	初晨	高	作为独立脚本，避免污染本地 runner 启动
可合并分支先合并一次	相关开发	中	找客户、产品推荐、搜索等可先合，draft 问题继续改

11. 待确认问题

后续仍需要确认的问题包括：

• MCP Apps / MCP UI 是否有标准下载接口，还是只能通过 open link 间接处理。
• 当前项目是否要继续使用底层 MCP 协议实现，还是未来切换到 MCP UI client / Apps render 高层组件。
• update model context 在当前代码中最终如何进入模型上下文。
• 隐藏消息采用什么标签格式，是否统一参考 Claude Code 的 system-reminder 思路。
• 邮件 get draft 在哪些场景需要返回 UI，哪些场景只返回数据。
• RenewMake CLI 的 token 最终由环境变量、MCP Server、系统设置还是 SDK session env 注入。
• 新项目 SDK 什么时候暴露创建 session 时设置执行环境变量的能力。
• RenewMake 未来是完全通过 SDK / API 调新项目，还是部分核心代码迁回 RenewMake。

12. 总结

这次会议的重点不是新增一个孤立功能，而是在通过找客户、产品推荐、邮件等真实业务场景，验证新项目作为 agent 运行平台是否能够承接 RenewMake 的核心 AI 能力。

短期开发策略是务实推进：下载、rewrite、预览、认证等复杂能力可以先采用临时方案或降级方案，优先确保主流程跑通，并把 UI 状态、模型上下文、工具调用和业务数据库之间的关系理顺。

长期方向则比较清晰：RenewMake 逐渐减少自身对 agent runtime 的维护，把 agent 创建、session 运行、MCP Server、工具、上下文和执行环境交给新项目，通过 SDK / API 统一调用。当前阶段的各类导入脚本和固定配置，本质上都是验证期工具，后续会被更规范的 SDK 和凭证/环境注入机制替代。