Composio 接入 Snowflake 完整指南多租户 OAuth 配置、Basic 迁移与异步查询实战【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio本篇指南围绕 Composio 开源仓库中 Snowflake 官方支持知识文档展开系统讲解在 Composio 平台上接入 Snowflake 的核心要点多租户 SaaS OAuth 的 auth config 规划、Basic auth 到 OAuth2 的迁移路径、刷新令牌与周期性重连设计、账户详情发现、异步查询分区结果处理以及降低工具输出 Token 负载的实践。读完本文你将能基于 Composio 正确搭建 Snowflake 工具接入与认证体系并避开多租户连接、令牌过期与大数据量返回等典型坑点。Snowflake 集成在 Composio 中的整体形态Composio 以工具tool—工具包toolkit—认证配置auth config—连接connected account为基本单元组织第三方集成。Snowflake 作为数据仓库工具包其能力通过一组工具如执行 SQL、检查语句状态等暴露给 Agent而要让这些工具真正跑在客户的数据上必须先解决认证与账户定位问题。本指南的事实主体来自仓库中的 Snowflake 支持知识源文档并辅以 编译后的 KB 指南页、Snowflake FAQ 以及 Python SDK 的 auth config 示例 作为实现佐证。下面按认证、迁移、生命周期、元数据、查询与性能六个主题逐一展开。一、多租户 SaaS每个客户 Snowflake 账户使用独立的 auth config为什么不能共用一个 OAuth 应用Snowflake 的 OAuth 与用户所在的 Snowflake 账户、安全集成security integration强绑定。没有一个通用的 OAuth 应用能安全地覆盖所有账户的角色配置、重定向 URI 和安全策略这一点在仓库的 Snowflake FAQ 中有明确说明。因此在生产环境中每个 Snowflake 用户/客户应当提供其自己 Snowflake 账户内配置的安全集成所签发的 OAuth 客户端凭据。推荐架构一客户一 auth config对于 Snowflake 多租户 OAuth官方推荐的模式是在每个客户自己的 Snowflake 账户中通过CREATE SECURITY INTEGRATION创建 OAuth 安全集成获得该客户专属的 OAuth 凭据client id / client secret 等。在 Composio 中为每一个客户账户创建一个独立的 auth config使用该客户自己的 Snowflake OAuth 凭据。将创建 auth config 后返回的auth_config_id保存在你自己的业务系统中与客户记录关联。当需要为该客户连接用户时传入正确的auth_config_id。连接过程中Composio 会收集每个连接connection专属的 Account ID例如myorg-myaccount这种组织-账户格式并基于它构建 Snowflake 的授权authorization与令牌tokenURL。也就是说账户定位信息是在连接级收集的而 OAuth 应用凭据是在 auth config 级隔离的——两层各司其职共同保证多租户之间的数据与权限隔离。用 SDK 管理 auth config仓库中的 Python 示例 展示了完整的 auth config 生命周期操作Snowflake 场景下可直接套用from composio import Composio composio Composio() # 1. 为某个客户创建自定义 OAuth auth config以 OAuth2 为例 auth_config composio.auth_configs.create( toolkitsnowflake, options{ name: Customer A Snowflake OAuth, type: use_custom_auth, auth_scheme: OAUTH2, credentials: { client_id: 客户 A 的 client_id, client_secret: 客户 A 的 client_secret, oauth_redirect_uri: 客户 A 配置的重定向 URI, }, }, ) # 将 auth_config.id 保存到你的业务侧与客户 A 绑定 print(auth_config.id) # 2. 需要时按 auth config 校验必填字段 required_fields composio.toolkits.get_auth_config_creation_fields( toolkitSNOWFLAKE, auth_schemeOAUTH2, ) print(required_fields) # 3. 后续可按 id 获取、更新、启用/禁用、删除 auth_config_retrieved composio.auth_configs.get(auth_config.id) # composio.auth_configs.enable(auth_config.id) # composio.auth_configs.disable(auth_config.id) # composio.auth_configs.delete(auth_config.id)从源码结构看auth_configs.create同时支持use_composio_managed_auth平台托管认证与use_custom_auth自带凭据两种模式Snowflake 多租户场景应使用use_custom_auth并逐客户传入其自有凭据。composio.toolkits.get_auth_config_creation_fields可以在创建前确认当前认证方案要求哪些字段避免凭据缺项导致创建失败。二、Snowflake Basic auth 已弃用迁移到 OAuth2迁移背景Snowflake 的 Basic auth用户名/密码方式已被官方弃用并替换为 OAuth2。仍在使用的旧式 Basic auth auth config 或 connected account 不再属于长期可用的路径理由包括Basic auth 下可用的工具/动作可能与 OAuth2 下不一致认证机制本身不再演进长期维护风险高多租户场景下 Basic auth 也无法提供 OAuth2 的细粒度权限与令牌生命周期控制。迁移步骤迁移到 OAuth2 的完整路径创建 Snowflake OAuth 安全集成在客户的 Snowflake 账户中执行CREATE SECURITY INTEGRATION参考下文 SQL取得 OAuth 客户端凭据。创建 Composio auth config使用上述凭据按第一节的方式为每个客户创建 OAuth2 类型的 auth config。重新连接用户让用户基于新的 auth config 重新发起连接collect Account ID 并走 OAuth 授权流程。下线旧 Basic 配置确认新连接稳定后清理旧的 Basic auth config 与连接。FAQ 中给出的安全集成示例 SQL 如下CREATE SECURITY INTEGRATION oauth_custom_all_roles TYPE oauth ENABLED true OAUTH_CLIENT_TYPE CONFIDENTIAL OAUTH_REDIRECT_URI https://your-app.com/oauth/callback OAUTH_REFRESH_TOKEN_VALIDITY 7776000;OAUTH_CLIENT_TYPE CONFIDENTIAL表明使用需要 client secret 的机密型客户端OAUTH_REDIRECT_URI必须与你在 Composio auth config 中登记的oauth_redirect_uri保持一致否则授权回调会失败。FAQ 还提醒应确保 OAuth 应用与 Snowflake 的角色roles、数据库databases、模式schemas按集成需求正确配置这些权限边界决定了连接在 OAuth2 下实际可访问的数据范围。三、配置刷新令牌并为周期性重连做好产品设计让 Snowflake 签发刷新令牌即使完成了 OAuth2Snowflake 默认也不一定签发刷新令牌。要获得更长生命周期的连接需要在 Snowflake 安全集成上显式开启刷新令牌OAUTH_ISSUE_REFRESH_TOKENS TRUE要求 Snowflake 在授权流程中签发刷新令牌OAUTH_REFRESH_TOKEN_VALIDITY设置刷新令牌有效时长建议设为 Snowflake 允许的最大值例如7776000秒约 90 天。官方支持知识建议将该值设到 Snowflake 允许的上限上述 SQL 示例中的OAUTH_REFRESH_TOKEN_VALIDITY 7776000即对应约 90 天的窗口。预期内的重连即便把刷新令牌有效期拉到最大Snowflake 仍可能在刷新令牌有效期结束后要求用户重新连接。这不是配置错误而是平台令牌生命周期的固有约束。因此产品设计上应把周期性重连当作正常流程而非异常分支在连接即将过期前主动提示用户重新授权重连时复用同一 auth config 与 Account ID避免产生重复的账户记录对连接状态做监控及时标记失效连接如利用composio.connected_accounts相关接口轮询连接状态。四、发现 Snowflake 账户详情toolkit 元数据与连接字段在搭建连接流程时常常需要确认连接发起时到底要收集哪些字段以及已建立的连接存了哪些字段。官方推荐两条数据来源路径连接发起前——toolkit-by-slug 端点调用按 slug 获取 toolkit 的接口Python SDK 对应composio.toolkits.get(slug...)检查其接受的初始化字段accepted initiation fields。这一步可以确认 Snowflake 连接需要哪些输入例如 Account ID。连接建立后——按 ID 获取 connected account调用获取 connected account 的接口composio.connected_accounts.get(...)读取该连接实际存储的连接字段用于展示账户信息、排查账户归属等。需要注意provider服务商的字段 schema 大多是静态的但provider 有能力变更这些字段。因此在当前到底需要/接受哪些字段这一问题上toolkit 元数据端点比硬编码的 schema 更可靠应当把它作为必选/可选字段的唯一权威来源避免因 provider 侧字段调整导致连接发起失败或字段缺失。五、异步查询与分区结果用好 SNOWFLAKE_CHECK_STATEMENT_STATUS问题现象当一条 Snowflake 查询返回了部分结果时不要急着判定数据缺失——Snowflake 可能把结果集拆分成了多个分区partition而单次工具调用并不会总是返回全部分区。正确做法轮询语句状态针对 Snowflake 的异步查询官方给出的处理方式是发起查询后拿到语句句柄statement handle调用SNOWFLAKE_CHECK_STATEMENT_STATUS工具传入该句柄轮询该工具直到查询真正完成status 表明 finished再通过结果工具按句柄/游标取回完整结果逐个分区消费。典型的 Agent 循环伪代码如下handle snowflake_execute_query(sql...) loop: status SNOWFLAKE_CHECK_STATEMENT_STATUS(statement_handlehandle) if status.finished: results snowflake_fetch_result(statement_handlehandle) break sleep(interval)这套提交异步语句 → 轮询状态 → 拉取结果的流程与 Snowflake 平台自身对长查询/大结果集的异步执行模型一致。在设计 Agent 时务必让工具链具备轮询能力而不是一次调用假定结果完整并在拿到结果后检查分区标记逐分区合并数据。六、降低工具输出与 Token 负载processors 与描述覆盖Snowflake 查询结果可能非常庞大直接回传给 LLM 会带来两方面问题一是 Token 消耗爆炸二是模型面对超大/超宽结果难以聚焦。官方知识给出两类手段1. 使用 processors 做输出后处理对于返回数据过多、或需要调整 LLM 侧 schema/描述的工具可以在工具输出返回给模型之前通过 processor 对输出做后处理post-process。常见用途截断/采样只保留前 N 行结果或关键列聚合摘要把明细结果聚合成统计摘要再交给模型裁剪 schema收缩工具对模型暴露的参数与返回字段减小每次调用的上下文占用。这类处理逻辑以包装在工具执行与模型消费之间的形式存在具体实现与 SDK 版本相关可结合当前 SDK 的处理器接口按需注册。2. 覆盖工具描述在本地 Agent 场景不依赖远端服务下你还可以在拿到返回的工具对象后、把它传给模型之前直接修改其 description 字段。通过改写描述可以引导模型更精准地使用该工具例如注明该工具只返回部分分区需配合状态检查轮询使用从而减少误用和重复调用带来的额外 Token 开销。落地建议对高频、大结果的查询类工具优先配置输出截断 processor对需要模型理解分区语义的工具在描述中显式说明轮询与分区消费要求监控每次会话的工具输出体积把 processor 阈值当作性能参数持续调优。七、实践要点速查认证隔离一客户一 auth configauth_config_id与客户绑定连接时传入对应配置Account ID如myorg-myaccount在连接级收集用于构造授权与令牌 URL。弃用处理Basic auth 不再作为长期路径统一迁移到 OAuth2迁移顺序为建安全集成 → 建 auth config → 重连用户 → 清理旧配置。令牌生命周期开启OAUTH_ISSUE_REFRESH_TOKENS TRUEOAUTH_REFRESH_TOKEN_VALIDITY设到 7776000 秒上限并把周期性重连内置到产品流程。字段权威来源连接前查 toolkit 元数据端点连接后查 connected account 字段不要把 provider schema 当作一成不变的事实。异步查询结果不完整时检查分区用SNOWFLAKE_CHECK_STATEMENT_STATUS 语句句柄轮询直至完成。成本控制用 processor 后处理工具输出、覆盖工具描述在输出进入模型之前削减 Token 负载。以上内容均可在仓库中溯源验证核心结论见 Snowflake 支持知识源文档认证细节补充见 Snowflake FAQauth config 的 SDK 用法见 auth_configs.py 示例多租户路由与连接管理的类似实践可参考 toolkits-jira 指南 与 toolkits-quickbooks 指南。【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Composio 接入 Snowflake 完整指南：多租户 OAuth 配置、Basic 迁移与异步查询实战
Composio 接入 Snowflake 完整指南多租户 OAuth 配置、Basic 迁移与异步查询实战【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio本篇指南围绕 Composio 开源仓库中 Snowflake 官方支持知识文档展开系统讲解在 Composio 平台上接入 Snowflake 的核心要点多租户 SaaS OAuth 的 auth config 规划、Basic auth 到 OAuth2 的迁移路径、刷新令牌与周期性重连设计、账户详情发现、异步查询分区结果处理以及降低工具输出 Token 负载的实践。读完本文你将能基于 Composio 正确搭建 Snowflake 工具接入与认证体系并避开多租户连接、令牌过期与大数据量返回等典型坑点。Snowflake 集成在 Composio 中的整体形态Composio 以工具tool—工具包toolkit—认证配置auth config—连接connected account为基本单元组织第三方集成。Snowflake 作为数据仓库工具包其能力通过一组工具如执行 SQL、检查语句状态等暴露给 Agent而要让这些工具真正跑在客户的数据上必须先解决认证与账户定位问题。本指南的事实主体来自仓库中的 Snowflake 支持知识源文档并辅以 编译后的 KB 指南页、Snowflake FAQ 以及 Python SDK 的 auth config 示例 作为实现佐证。下面按认证、迁移、生命周期、元数据、查询与性能六个主题逐一展开。一、多租户 SaaS每个客户 Snowflake 账户使用独立的 auth config为什么不能共用一个 OAuth 应用Snowflake 的 OAuth 与用户所在的 Snowflake 账户、安全集成security integration强绑定。没有一个通用的 OAuth 应用能安全地覆盖所有账户的角色配置、重定向 URI 和安全策略这一点在仓库的 Snowflake FAQ 中有明确说明。因此在生产环境中每个 Snowflake 用户/客户应当提供其自己 Snowflake 账户内配置的安全集成所签发的 OAuth 客户端凭据。推荐架构一客户一 auth config对于 Snowflake 多租户 OAuth官方推荐的模式是在每个客户自己的 Snowflake 账户中通过CREATE SECURITY INTEGRATION创建 OAuth 安全集成获得该客户专属的 OAuth 凭据client id / client secret 等。在 Composio 中为每一个客户账户创建一个独立的 auth config使用该客户自己的 Snowflake OAuth 凭据。将创建 auth config 后返回的auth_config_id保存在你自己的业务系统中与客户记录关联。当需要为该客户连接用户时传入正确的auth_config_id。连接过程中Composio 会收集每个连接connection专属的 Account ID例如myorg-myaccount这种组织-账户格式并基于它构建 Snowflake 的授权authorization与令牌tokenURL。也就是说账户定位信息是在连接级收集的而 OAuth 应用凭据是在 auth config 级隔离的——两层各司其职共同保证多租户之间的数据与权限隔离。用 SDK 管理 auth config仓库中的 Python 示例 展示了完整的 auth config 生命周期操作Snowflake 场景下可直接套用from composio import Composio composio Composio() # 1. 为某个客户创建自定义 OAuth auth config以 OAuth2 为例 auth_config composio.auth_configs.create( toolkitsnowflake, options{ name: Customer A Snowflake OAuth, type: use_custom_auth, auth_scheme: OAUTH2, credentials: { client_id: 客户 A 的 client_id, client_secret: 客户 A 的 client_secret, oauth_redirect_uri: 客户 A 配置的重定向 URI, }, }, ) # 将 auth_config.id 保存到你的业务侧与客户 A 绑定 print(auth_config.id) # 2. 需要时按 auth config 校验必填字段 required_fields composio.toolkits.get_auth_config_creation_fields( toolkitSNOWFLAKE, auth_schemeOAUTH2, ) print(required_fields) # 3. 后续可按 id 获取、更新、启用/禁用、删除 auth_config_retrieved composio.auth_configs.get(auth_config.id) # composio.auth_configs.enable(auth_config.id) # composio.auth_configs.disable(auth_config.id) # composio.auth_configs.delete(auth_config.id)从源码结构看auth_configs.create同时支持use_composio_managed_auth平台托管认证与use_custom_auth自带凭据两种模式Snowflake 多租户场景应使用use_custom_auth并逐客户传入其自有凭据。composio.toolkits.get_auth_config_creation_fields可以在创建前确认当前认证方案要求哪些字段避免凭据缺项导致创建失败。二、Snowflake Basic auth 已弃用迁移到 OAuth2迁移背景Snowflake 的 Basic auth用户名/密码方式已被官方弃用并替换为 OAuth2。仍在使用的旧式 Basic auth auth config 或 connected account 不再属于长期可用的路径理由包括Basic auth 下可用的工具/动作可能与 OAuth2 下不一致认证机制本身不再演进长期维护风险高多租户场景下 Basic auth 也无法提供 OAuth2 的细粒度权限与令牌生命周期控制。迁移步骤迁移到 OAuth2 的完整路径创建 Snowflake OAuth 安全集成在客户的 Snowflake 账户中执行CREATE SECURITY INTEGRATION参考下文 SQL取得 OAuth 客户端凭据。创建 Composio auth config使用上述凭据按第一节的方式为每个客户创建 OAuth2 类型的 auth config。重新连接用户让用户基于新的 auth config 重新发起连接collect Account ID 并走 OAuth 授权流程。下线旧 Basic 配置确认新连接稳定后清理旧的 Basic auth config 与连接。FAQ 中给出的安全集成示例 SQL 如下CREATE SECURITY INTEGRATION oauth_custom_all_roles TYPE oauth ENABLED true OAUTH_CLIENT_TYPE CONFIDENTIAL OAUTH_REDIRECT_URI https://your-app.com/oauth/callback OAUTH_REFRESH_TOKEN_VALIDITY 7776000;OAUTH_CLIENT_TYPE CONFIDENTIAL表明使用需要 client secret 的机密型客户端OAUTH_REDIRECT_URI必须与你在 Composio auth config 中登记的oauth_redirect_uri保持一致否则授权回调会失败。FAQ 还提醒应确保 OAuth 应用与 Snowflake 的角色roles、数据库databases、模式schemas按集成需求正确配置这些权限边界决定了连接在 OAuth2 下实际可访问的数据范围。三、配置刷新令牌并为周期性重连做好产品设计让 Snowflake 签发刷新令牌即使完成了 OAuth2Snowflake 默认也不一定签发刷新令牌。要获得更长生命周期的连接需要在 Snowflake 安全集成上显式开启刷新令牌OAUTH_ISSUE_REFRESH_TOKENS TRUE要求 Snowflake 在授权流程中签发刷新令牌OAUTH_REFRESH_TOKEN_VALIDITY设置刷新令牌有效时长建议设为 Snowflake 允许的最大值例如7776000秒约 90 天。官方支持知识建议将该值设到 Snowflake 允许的上限上述 SQL 示例中的OAUTH_REFRESH_TOKEN_VALIDITY 7776000即对应约 90 天的窗口。预期内的重连即便把刷新令牌有效期拉到最大Snowflake 仍可能在刷新令牌有效期结束后要求用户重新连接。这不是配置错误而是平台令牌生命周期的固有约束。因此产品设计上应把周期性重连当作正常流程而非异常分支在连接即将过期前主动提示用户重新授权重连时复用同一 auth config 与 Account ID避免产生重复的账户记录对连接状态做监控及时标记失效连接如利用composio.connected_accounts相关接口轮询连接状态。四、发现 Snowflake 账户详情toolkit 元数据与连接字段在搭建连接流程时常常需要确认连接发起时到底要收集哪些字段以及已建立的连接存了哪些字段。官方推荐两条数据来源路径连接发起前——toolkit-by-slug 端点调用按 slug 获取 toolkit 的接口Python SDK 对应composio.toolkits.get(slug...)检查其接受的初始化字段accepted initiation fields。这一步可以确认 Snowflake 连接需要哪些输入例如 Account ID。连接建立后——按 ID 获取 connected account调用获取 connected account 的接口composio.connected_accounts.get(...)读取该连接实际存储的连接字段用于展示账户信息、排查账户归属等。需要注意provider服务商的字段 schema 大多是静态的但provider 有能力变更这些字段。因此在当前到底需要/接受哪些字段这一问题上toolkit 元数据端点比硬编码的 schema 更可靠应当把它作为必选/可选字段的唯一权威来源避免因 provider 侧字段调整导致连接发起失败或字段缺失。五、异步查询与分区结果用好 SNOWFLAKE_CHECK_STATEMENT_STATUS问题现象当一条 Snowflake 查询返回了部分结果时不要急着判定数据缺失——Snowflake 可能把结果集拆分成了多个分区partition而单次工具调用并不会总是返回全部分区。正确做法轮询语句状态针对 Snowflake 的异步查询官方给出的处理方式是发起查询后拿到语句句柄statement handle调用SNOWFLAKE_CHECK_STATEMENT_STATUS工具传入该句柄轮询该工具直到查询真正完成status 表明 finished再通过结果工具按句柄/游标取回完整结果逐个分区消费。典型的 Agent 循环伪代码如下handle snowflake_execute_query(sql...) loop: status SNOWFLAKE_CHECK_STATEMENT_STATUS(statement_handlehandle) if status.finished: results snowflake_fetch_result(statement_handlehandle) break sleep(interval)这套提交异步语句 → 轮询状态 → 拉取结果的流程与 Snowflake 平台自身对长查询/大结果集的异步执行模型一致。在设计 Agent 时务必让工具链具备轮询能力而不是一次调用假定结果完整并在拿到结果后检查分区标记逐分区合并数据。六、降低工具输出与 Token 负载processors 与描述覆盖Snowflake 查询结果可能非常庞大直接回传给 LLM 会带来两方面问题一是 Token 消耗爆炸二是模型面对超大/超宽结果难以聚焦。官方知识给出两类手段1. 使用 processors 做输出后处理对于返回数据过多、或需要调整 LLM 侧 schema/描述的工具可以在工具输出返回给模型之前通过 processor 对输出做后处理post-process。常见用途截断/采样只保留前 N 行结果或关键列聚合摘要把明细结果聚合成统计摘要再交给模型裁剪 schema收缩工具对模型暴露的参数与返回字段减小每次调用的上下文占用。这类处理逻辑以包装在工具执行与模型消费之间的形式存在具体实现与 SDK 版本相关可结合当前 SDK 的处理器接口按需注册。2. 覆盖工具描述在本地 Agent 场景不依赖远端服务下你还可以在拿到返回的工具对象后、把它传给模型之前直接修改其 description 字段。通过改写描述可以引导模型更精准地使用该工具例如注明该工具只返回部分分区需配合状态检查轮询使用从而减少误用和重复调用带来的额外 Token 开销。落地建议对高频、大结果的查询类工具优先配置输出截断 processor对需要模型理解分区语义的工具在描述中显式说明轮询与分区消费要求监控每次会话的工具输出体积把 processor 阈值当作性能参数持续调优。七、实践要点速查认证隔离一客户一 auth configauth_config_id与客户绑定连接时传入对应配置Account ID如myorg-myaccount在连接级收集用于构造授权与令牌 URL。弃用处理Basic auth 不再作为长期路径统一迁移到 OAuth2迁移顺序为建安全集成 → 建 auth config → 重连用户 → 清理旧配置。令牌生命周期开启OAUTH_ISSUE_REFRESH_TOKENS TRUEOAUTH_REFRESH_TOKEN_VALIDITY设到 7776000 秒上限并把周期性重连内置到产品流程。字段权威来源连接前查 toolkit 元数据端点连接后查 connected account 字段不要把 provider schema 当作一成不变的事实。异步查询结果不完整时检查分区用SNOWFLAKE_CHECK_STATEMENT_STATUS 语句句柄轮询直至完成。成本控制用 processor 后处理工具输出、覆盖工具描述在输出进入模型之前削减 Token 负载。以上内容均可在仓库中溯源验证核心结论见 Snowflake 支持知识源文档认证细节补充见 Snowflake FAQauth config 的 SDK 用法见 auth_configs.py 示例多租户路由与连接管理的类似实践可参考 toolkits-jira 指南 与 toolkits-quickbooks 指南。【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考