MCP 项目相关讨论会议纪要

会议时间：2026-05-20
来源文件：MCP项目相关讨论.txt

一、会议核心结论

本次讨论的主线是：后续项目要逐步从当前偏 function call 的工具调用方式，迁移到以 MCP 为主的工具注册和运行方式。所有能通过 MCP 接入的工具都尽量改为 MCP 接入，这样未来替换 agent runtime、扩展工具、接入 MCP Apps UI 时会更简单，也能降低后续重构成本。

当前会维持两条线并行：

一条是更纯粹的 agent 运行平台项目。
另一条是当前 running Mac 项目，让它内部自己跑一套运行平台。

短期内不直接替换现有体系，而是先通过具体用例把整体流程跑通。会议中明确提到，Email 是优先集成的单独例子，用它来验证 MCP Apps、上下文同步、工具调用、UI 展示等链路。

二、总体方向：从 Function Call 迁移到 MCP

1. 为什么要迁移

当前很多工具是通过 function call 直接调用，例如发邮件等能力。这种方式在后续重构、替换 agent runtime、统一工具协议时容易遇到较多问题。

后续希望将工具尽可能改成 MCP Server / MCP Apps 的形式注册和调用。这样一来：

agent runtime 替换会更轻；
工具注册、展示、调用方式更统一；
交互式 UI 可以通过 MCP Apps 协议承载；
上下文同步可以使用 MCP Apps 已有协议，而不是每个功能重新设计；
多个客户端或支持 MCP Apps 的第三方环境也能复用同一套服务。

2. 命名和技术栈调整

会议中提到，原先一些地方可能叫 mcpui 或 MCP Server，后续更准确的表述应倾向于：

MCP Apps：面向带 UI 的 MCP 应用形态；
MCP use：用于构建 MCP Apps 的库；
MCPX：项目里涉及 MCP Apps 展示层或相关组件返回代码的部分。

已有 MCP Server 线下基本能跑，但功能完整度不足，需要逐步补齐体验和稳定性。

三、交互式 UI 相关要求

1. 数据分析场景优先使用交互式 UI

凡是涉及数据分析的场景，应在提示词或系统约束中明确：优先让 DA 主动调用交互式 UI 工具，而不是只输出纯文本结果。

交互式 UI 应支持：

在对话中内嵌组件；
组件内置按钮；
用户点击按钮后，可以通过 MCP Apps 协议发送一条用户消息；
组件状态变更后，可以通过隐藏消息或 update model context 同步给后续对话；
输出过程支持渐进式展示。

2. 渐进式输出

会议中明确提到，交互式 UI 的输出不应等完整代码或完整内容生成完才展示。理想状态是：

AI 生成过程中可以边输出边展示；
CSS 等基础结构应优先生成，保证半成品也能正常拼接和渲染；
即使输出到一半，也应该能形成一个可展示的文本或组件框架；
当前这块以前支持过，后续可能因为改动被破坏，需要恢复或验证。

3. 样式问题

当前交互式 UI 的样式被认为“不够高级”“有点丑”，需要进一步调优。参考项目据说逆向了 Claude 的交互风格，因此理论上能做到更接近 Claude 的简洁风格。

需要排查：

是否缺少某些变量导致样式异常；
参考项目里的指导文件或样式约束是否没有正确加载；
当前生成结果为什么没有达到预期质感；
是否有可复用的 Claude 风格交互 UI 实现。

负责人倾向：小关 / 小光优先排查和调整。

四、功能验收清单和任务点

1. Pet / PDF / Excel / 文档类能力

会议中提到默认 agent 里需要先加载一些功能。对于 Pet、PDF、Excel 等能力：

Pet 相关能力可能已有 skill 可以复用，并且可以直接编辑；
PDF 和 Excel 需要进一步评估采用什么方式更合适；
可以考虑找已有 skill 放到对应能力目录下；
需要保证 agent 默认能使用这些能力，而不是用户每次手动配置。

负责人倾向：朱晨评估 PDF、Excel 等能力接入方式。

2. 搜索工具单独计费

搜索工具，例如 EXA，不再简单计入 token 消耗，而是希望做成单独计费。

会议中给出的计费思路：

以搜索供应商原价乘以 2 作为成本基准；
当前积分换算为 1 美金 = 200 积分；
需要据此计算每次搜索大概要消耗多少积分；
搜索成本应独立展示或独立扣费，不再混入 token 计费。

负责人倾向：朱晨计算并设计搜索工具单独计费方案。

3. 全部 Agent 启用记忆功能

当前记忆功能可能只在部分 agent 或默认 agent 中启用。会议要求先沿用现有记忆功能实现，把它扩展到所有 agent。

负责人倾向：小关处理。

五、独立站 Skill

会议讨论了一个“独立站 skill”方向：用户选择某个 agent 后，agent 主动引导用户提供建站所需信息，并最终生成一个独立网站。

1. 用户输入信息

agent 应提醒用户提供：

公司信息；
产品信息；
图片素材；
其他建站所需资料。

初始阶段可以要求较少信息，图片等素材可后续补充，不必一开始就阻塞建站流程。

2. 技术实现

独立站生成应使用最新的 Vite + React，原因是启动和生成速度较快，适合自动生成站点。

需要研究是否已有 website skill 可以复用。

负责人倾向：朱晨研究已有 website / landing page / site builder 类 skill。

3. 发布能力

短期重点是先把站点生成出来，发布能力可以先预留入口。

未来可能支持的发布方式包括：

部署到 Cloudflare；
部署到某个容器环境；
部署到类似 E2B 的沙箱；
将站点放到对象存储；
通过反向代理访问对象存储中的站点；
用户需要自定义域名时，引导配置 CNAME。

当前结论是：先不急着完整实现发布链路，但发布时可以提醒用户选择发布目标，并在架构上保留扩展口。

六、MCP Apps 与 Email 用例

Email 是本轮 MCP Apps 改造的优先验证用例，目标是先把整体流程跑通。

1. Email MCP App 的基本目标

Email 相关 UI 不再只是前端项目里的固定组件，而是由 MCP Server / MCPX 返回组件代码，前端负责承载和展示。

短期目标：

让 Email MCP App 能正常显示；
能正常编辑邮件；
能正常发送；
能把必要上下文同步回对话；
体验尽量接近现有单独渲染版本。

某些复杂能力可先不做，例如 Email 里的 write with AI / 重写邮件交互，可以先降级为：点击对应按钮后，在对话中发送一条用户消息，由 agent 继续处理。

2. 草稿和上下文同步

Email 编辑器中每封草稿应有草稿 ID。用户在 UI 中修改内容后：

草稿 ID 保存在 MCP Server 侧；
修改后的具体内容也需要能被 MCP Server 或上下文机制感知；
当用户点击发送等操作后，会产生隐藏信息；
隐藏信息用于更新后续对话上下文；
关键词是 update model context。

update model context 的作用是让后续 AI 对话知道用户在组件里做过什么修改，而不是只看到原始对话文本。

会议中也提到，当前演示里这里可能还有 bug，后续实现时需要结合代码库进一步排查。

3. Email 附件和内嵌图片

Email MCP Server 需要支持文件。会议中倾向采用 URL 方式传递文件：

对 MCP 本身来说，文件就是 URL；
URL 必须公网可访问；
可以在沙箱中提供一个 API，让 MCP Server 能访问文件；
MCP Server 负责把文件 URL 转成邮件附件格式；
文件转附件的逻辑应在 MCP Server 内部完成。

内嵌图片方案还需要进一步设计，可能方向包括：

使用 HTML 的 img 标签；
作为附件或特殊资源处理；
通过 JS 或邮件 HTML 模板进行引用。

具体实现方式由后续开发时根据 Email MCP Server 能力决定。核心原则是：MCP Server 应尽量通用，不要过度绑定当前项目。

负责人倾向：朱晨在实现 Email 附件 / 内嵌图片时确认方案。

七、产品推荐 MCP App

产品推荐编辑器是另一个需要完善的 MCP Apps 场景。

1. 当前问题

已有产品推荐编辑器曾经跑通过，但样式和交互存在问题：

组件能看到部分内容；
大部分区域可能是空白；
可能存在滚动问题；
当前缺少清晰的编辑入口；
不符合“在对话上下文中直接修改推荐方案”的目标体验。

2. 期望体验

产品推荐编辑器应像邮件弹窗一样：

在对话里展示一个组件；
点击组件后可以进入编辑；
用户可以直接修改推荐方案；
修改完成后，对话上下文知道推荐方案已经被修改；
后续 AI 可以基于修改后的推荐方案继续工作。

3. 上下文同步方式

产品推荐编辑后，应通过 update model context 标记：

哪个推荐方案 ID 被修改；
修改已完成；
后续 AI 需要时可以调用 MCP 工具重新获取推荐方案数据。

这样 AI 不需要在当前对话文本中保留完整推荐方案内容，也能知道状态发生了变化。

八、CRM 工具接入

CRM 部分基本不涉及复杂 UI，主要是工具调用。

重点要求：

让 AI 站在用户视角执行任务；
理解用户希望对 CRM 数据做哪些调整；
用 MCP 工具完成对应操作；
提示词中不要继续要求 AI 使用旧 function call 工具；
如果旧工具被删除或找不到，AI 层面要有兼容逻辑，避免直接报错。

测试时需要让 AI 做真实任务，而不是只检查工具是否能调用。

九、Chat UI / Codex 风格对齐

后续会对当前 Chat UI 进行较大调整，目标是向 Codex 风格靠拢。

1. 输出过程展示

新的输出形态大致为：

运行中显示过程进度；
输出完成后将过程折叠；
最终只展示较简洁的总结；
文件消息只显示最后一条；
工具调用信息展示需要简化。

负责人倾向：

小关负责交互式 UI 和 Chat UI 改造；
朱晨后续关注工具调用信息展示简化。

2. 需要关注的兼容问题

UI 对齐过程中要特别关注：

文本链接渲染；
点击某个文件后，是否还能打开右侧窗口；
滚动到底部等行为；
原有大量 ref 控制逻辑是否可以清理；
是否能尽量使用参考项目 / 底层库已有实现；
输入框、选择 agent、输入内容等区域尽量沿用原项目现有实现。

3. Artifact 展示策略

如果 UI 改造涉及原有 Artifact 展示，可以考虑退化为占位符或末尾卡片形式：

类似 ARTIFACT-某个文件 的占位符；
或者按 Codex 风格，只在最后展示卡片；
中途不强制展示完整卡片；
因为后续接入 CRM 后，模型输出内容会更少，用户主要看最终汇总即可。

会议中提到，以前要求中间展示较多内容，是因为商机转化场景里一次性输出很多过程信息；后续可以适当简化。

4. 开发顺序

小关在进行大规模 UI 对齐前，需要先把之前的版本部署一次。原因是 UI 改造可能影响较大，后续短期内可能不太容易稳定部署，需要更多测试。

任务排序需要按优先级重新整理，并尽量避免代码冲突。MCP Apps 相关任务要等待交互式 UI / Chat UI 的关键改造先稳定一部分。

十、MCP Apps 实现参考

会议中提到后续会提供参考项目代码。参考项目中可能包含：

更纯粹的 agent 运行平台实现；
MCP Apps 展示层；
MCPX 相关实现；
滚动到底部等 UI 行为；
与 Codex 风格类似的输出形态；
MCP Apps 场景示例。

如果当前默认实现有问题，可以参考该项目中的 MCP Apps 实现。但是否直接迁移参考项目中的 MCPX，需要根据实际改造进度判断：

小关做 UI 转换时可能会顺带迁移 MCPX；
如果没有迁移，朱晨做 Email 用例时可能需要迁移；
参考项目里也有另一套 MCP Apps 实现，但可能需要通过 API 调节，短期可以先不考虑。

十一、测试环境和数据

会议中提醒，需要关注测试环境数据质量。

历史数据中应该存在：

某些公司下多个联系人；
多个协作成员；
对应销售；
协作人信息；
从邮箱中提取出来的联系人数据。

需要检查现有测试环境数据是否还完整，必要时重新导入。尤其 CRM、Email、产品推荐等场景都依赖更真实的数据，不能只用过于简单的单条数据测试。

负责人倾向：朱晨检查测试环境数据。

十二、提示词和工具兼容

MCP 工具迁移后，提示词也必须同步调整。

需要避免：

提示词仍要求 AI 使用旧 function call 工具；
工具已删除但提示词仍引用；
MCP Apps 场景没有明确要求 AI 使用新的 MCP 工具；
旧工具找不到时直接报错。

需要做到：

新提示词明确引导 AI 使用 MCP 工具；
涉及数据分析时倾向调用交互式 UI；
涉及 Email、CRM、产品推荐时使用对应 MCP 能力；
对旧工具缺失有兼容策略。

十三、成本和资源使用

会议中提到团队当前 token 消耗偏少，应更多使用 AI 来完成真实测试和开发辅助。

提到的参考数字：

团队近 30 天大约消耗 400 美金；
主讲人自己在另一条项目线上近 30 天大约消耗 4000 多美金；
建议大家在开发和测试时更充分使用 AI，尤其让 AI 多做真实任务测试。

这里的重点不是鼓励无意义消耗，而是希望团队不要因为节省 token 而减少必要的自动化验证、代码理解和端到端测试。

十四、明确任务清单

优先级	事项	负责人/关注人	说明
高	调整交互式 UI 样式和变量问题	小关 / 小光	参考 Claude / Codex 风格，修复当前“不够高级”的展示问题
高	数据分析场景优先使用交互式 UI	小关 / 小光	在提示词中加强约束，让 DA 主动调用工具
高	恢复或验证渐进式输出	小关 / 金芳	输出过程中应边生成边展示，金芳验证是否影响其他正常功能
高	Email MCP App 用例跑通	朱晨	优先验证 MCP Apps 全链路，包括编辑、发送、上下文同步
高	Chat UI 向 Codex 风格对齐	小关	运行中显示进度，完成后折叠，只显示简洁结果
高	UI 改造前先部署当前版本	小关	避免后续大改后短期无法稳定部署
中	产品推荐编辑器 MCP App 完善	待定 / 朱晨关注	修复空白、滚动、编辑入口和上下文同步
中	CRM 工具 MCP 化	待定	主要是工具调用，不涉及复杂 UI
中	全部 agent 启用记忆功能	小关	沿用现有记忆实现，扩展到所有 agent
中	搜索工具单独计费	朱晨	EXA 等搜索工具按原价 x2，并按 1 美金 = 200 积分换算
中	Email 支持附件和内嵌图片	朱晨	文件以公网 URL 传入，MCP Server 转附件；内嵌图片方案待定
中	独立站 skill 调研	朱晨	使用最新 Vite + React，研究已有 website skill
中	发布能力预留	朱晨 / 后续任务	先预留发布目标选择，未来支持 Cloudflare、对象存储、反代、CNAME 等
中	工具调用信息展示简化	朱晨	后续结合 Chat UI 改造一起处理
中	测试环境数据检查和重导	朱晨	确认联系人、协作成员、销售等数据完整
低	历史技能输出中的异常内容	待定	会议提到偶尔仍会出现，后续遇到再处理

十五、开放问题和待确认事项

VIPENLR 相关内容在转写中不清晰，需要结合原始上下文或任务系统确认具体含义。
Pet / PDF / Excel 能力具体复用哪些 skill，还需要进一步调研。
Email 内嵌图片最终采用 HTML 引用、附件引用还是其他方案，需要开发时结合邮件服务能力确认。
参考项目中的 MCPX / MCP Apps 展示层是否直接迁移，需要等小关 UI 改造和朱晨 Email 用例推进后判断。
产品推荐编辑器当前空白问题是滚动、布局还是数据加载导致，需要实际调试确认。
搜索工具单独计费需要明确不同供应商、不同搜索类型的成本和积分换算表。
发布能力短期是否只做提示和入口，还是要实现某个默认发布目标，需要后续产品决策。

十六、会议最后强调

主讲人最后再次强调：后续整体方向是以 MCP 为主，把所有工具尽可能通过 MCP 注册进去。这样在 agent runtime 更换、工具扩展、UI 协议统一时都会更容易。

同时，因为后续会开始推广，组织数量会持续增长，所以当前阶段要尽可能把已经做出来的功能做稳定。开发过程中不能只把任务抛给 AI，也要理解 AI 的具体执行方式、工具调用方式和上下文更新机制；但同时也要更多使用 AI 做真实测试和开发辅助，保证改动经过足够验证。