feat(storage): 为工具和成果定义一等附件引用

区域

MCP 磁共振

问题或动机

讨论#4806询问聊天上传是否可以作为上传的原始文件交给MCP/Custom工具.

这影响到制作人的工作流程、文档/图像转换、MCP工具、定制工具、归还的文物和储存卫生。 如今,基于文件的工具工作流程更难解释上传是否被作为内置有效载荷或本地路径而不是一等附件引用.

当用户要求时,工具应该能够与上传的原始字节配合,但是它们不应该随意接收任意的主机文件系统路径或大型内线基数64的有效载荷.

建议的解决办法

定义奥德修斯的一等附属/工艺合同。

第一版的目标应当是:

• 原上传字节保存一次;
• 每上传一个稳定的附件ID;
• 元数据与附件一起存储:原始文件名、MIME类型、大小、校验和、拥有信件/会话和创建时间;
• 代理/工具层接收附件参考,而不是内置基数64有效载荷;
• 工具/MCP服务器可请求受控读取特定附件ID;
• 将生成的文件作为带有ID、元数据、MIME类型和预览/下载处理的文物送回;
• 保留和删除行为记录在案。

建议的首个执行部分:

1. 界定附件元数据/参考形状;
2. 确保能够用稳定的ID来查询电流上传信息;
3. 向工具显示只读附件查询路径;
4. 增加一个小的证明案例,读取上传的文件并返回衍生文物;
5. 记录寿命周期和许可界限。

考虑的替代品

将原始本地文件系统路径直接传递到工具上会比较简单,但它与主机/容器路径布局的工具对齐,并有可能暴露出比预期更广泛的文件系统访问.

将大型基数64的有效载荷装入信息/工具呼叫中也是不可取的,因为它增加了DB大小、即时/工具的有效载荷大小以及搜索索引风险。

· 前文/相关问题

相关讨论:#4806,#4762.

这也与存储卫生有关,因为一等附件的引用将有助于避免重复上传到“聊天信息”中的字节。 内容`。

你愿意执行吗?

部分——我可以帮忙,但需要指导