Composio TypeScript Provider 开发工作流从脚手架创建到框架适配器落地【免费下载链接】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 仓库中 .agents/skills/typescript-providers/references/provider-workflow.md 为核心脉络系统讲解 TypeScript Provider框架适配器的完整开发工作流如何创建或定位 Provider 包、遵循哪些实现规则、如何完成类型检查与测试验证。读完本文你将掌握在 Composio 中为 OpenAI、Anthropic、LangChain 等 AI 框架开发原生工具适配器的标准化流程并能对照仓库源码理解 Provider 的底层运行机制。什么是 Composio TypeScript ProviderComposio 通过 Provider 机制将平台上的 1000 工具适配到各个 AI 框架的原生工具格式。在 ts/packages/providers/README.md 中可以看到每个包负责将一个 Agent 框架的调用约定转换为 Composio 工具包名适配框架composio/openaiOpenAI Chat Completions 与 Responses APIcomposio/openai-agentsOpenAI Agents SDKcomposio/anthropicAnthropic Messages APIcomposio/claude-agent-sdkClaude Agent SDKcomposio/vercelVercel AI SDKcomposio/googleGoogle GenAIcomposio/langchainLangChain 与 LangGraphcomposio/llamaindexLlamaIndexcomposio/mastraMastracomposio/cloudflareCloudflare Workers AI使用方式非常统一将 Provider 实例传入new Composio({ provider })之后session.tools()返回的工具就能被对应框架直接调用。例如 Anthropic Provider 的典型用法见 ts/packages/providers/anthropic/README.mdimport Anthropic from anthropic-ai/sdk; import { Composio } from composio/core; import { AnthropicProvider } from composio/anthropic; const composio new Composio({ provider: new AnthropicProvider(), }); const client new Anthropic(); const session await composio.create(user_123); const tools await session.tools(); let response await client.messages.create({ model: claude-opus-4-6, max_tokens: 4096, tools, messages: [{ role: user, content: Send an email to johnexample.com... }], }); // Agentic loop: 持续执行工具调用直到模型返回文本 while (response.stop_reason tool_use) { const toolResults await composio.provider.handleToolCalls(session, response); messages.push({ role: assistant, content: response.content }); messages.push(...toolResults); response await client.messages.create({ model: claude-opus-4-6, max_tokens: 4096, tools, messages }); }Provider 的工作流程provider-workflow.md正是围绕创建/定位 → 实现 → 验证这一开发闭环展开的本文后续各节将逐一深入。第一步创建或定位 Provider 包使用脚手架命令创建新 Provider在仓库根目录执行pnpm create:provider provider-name [--agentic]该命令在 package.json 中定义为bash ts/scripts/create-provider.sh。阅读 ts/scripts/create-provider.sh 可知它会自动完成以下工作在ts/packages/providers/provider-name/下创建目录结构生成package.json包名为composio/provider-name内置build: tsdown与test: vitest run脚本peerDependencies 声明composio/core生成tsconfig.jsonextends 仓库根目录 tsconfig.base.json启用strict、declaration等生成tsdown.config.ts复用 tsdown.config.base.ts 基础配置生成src/index.ts骨架非 agentic 模式导出extends BaseNonAgenticProvider的ProviderNameProvideragentic 模式则导出extends BaseAgenticProvider的版本并预置wrapTool/wrapTools待实现方法生成 README.md 模板。Provider 包的存放位置所有 TypeScript Provider 统一位于ts/packages/providers/目录当前已有 openai、openai-agents、anthropic、claude-agent-sdk、vercel、google、langchain、llamaindex、mastra、cloudflare 十个包。每个包均包含src/实现、test/vitest 测试、README.md安装命令与可运行 quickstart、tsdown.config.ts构建配置新增包请保持这一目录约定。若只是修改已有框架的适配直接定位到对应包即可无需重新脚手架。第二步理解 Provider 的两种基类在动手实现前需要先明确 Provider 属于哪一类别。从 ts/packages/core/src/provider/BaseProvider.ts 的源码可以看到Provider 全部继承自内部基类BaseProviderTMcpResponse并由两个公开抽象子类分化出两种模式非 Agentic ProviderBaseNonAgenticProvider_isAgentic false只负责把工具 Schema 转换成原始模型 API 的格式如 OpenAI、Anthropic、Cloudflare抽象方法签名为wrapTool(tool: Tool): TTool与wrapTools(tools: Tool[]): TToolCollection不携带执行函数工具循环tool loop由开发者自己的代码驱动调用 Provider 提供的executeToolCall/handleToolCalls等辅助方法完成执行。Agentic ProviderBaseAgenticProvider_isAgentic true将工具包装为自带执行函数的形式如 LangChain 的DynamicStructuredTool、LlamaIndex、Mastra、Vercel、OpenAI Agents抽象方法签名为wrapTool(tool: Tool, executeTool: ExecuteToolFn): TTool与wrapTools(tools: Tool[], executeTool: ExecuteToolFn): TToolCollection——执行函数由核心 SDK 注入工具循环由框架自行驱动。BaseProvider还暴露了公共方法executeTool(toolSlug, body, modifiers)它映射到Tools类的execute方法供 Provider 实现执行辅助函数若未注入全局执行函数会抛出ComposioGlobalExecuteToolFnNotSetError。另外executeToolForTarget负责区分两种执行目标传入userId字符串时走直连工具 API传入 Tool Router 会话对象时则调用target.execute(toolSlug, arguments_)并拒绝在会话绑定模式下混用直连执行选项assertToolCallExecutionOptions会抛出TypeError。因此创建 Provider 时选择--agentic与否直接决定了生成的骨架类与需要实现的接口签名。第三步遵循实现规则provider-workflow.md明确了五条实现规则结合仓库源码可以进一步理解每条规则背后的约束1. 保持框架原生工具格式适配器的价值在于原生化。以 ts/packages/providers/langchain/README.md 为例每个工具都被包装成标准的DynamicStructuredTool因此可以直接用于 LangChain 的 chains、LCEL 管线或任何 chat model 的bindToolsLangGraph 在 TypeScript 侧也由同一包提供服务。不要把工具改造成 Composio 私有格式否则框架无法识别。2. Provider 特有代码留在 Provider 包内Provider 专属逻辑应封闭在ts/packages/providers/name/中。核心包composio/core只保留通用抽象与执行注入机制这也解释了为什么 ts/packages/providers/openai/src/index.ts 中的OpenAIProvider直接由composio/core导出它是核心内置的便捷导出而 Responses Provider 则放在包内单独实现。3. 避免把 Provider 专属依赖泄漏进核心在 ts/packages/providers/AGENTS.md 中有更细化的补充Provider 的依赖只应出现在自身包的package.json中不得反向引入composio/core。脚手架生成的package.json也印证了这一点——它只声明composio/core为 peerDependency。4. Schema 规范化要求AGENTS.md补充了一条关键实现细节凡接收原始Tool的 Provider在输出厂商 JSON Schema 之前必须调用composio/core的deduplicateJsonSchemaRequiredArrays去重required数组若工具已通过ToolSchema规范化且未再做变换则无需重复调用。5. 同步更新文档与示例当 Provider 的设置方式或公共用法变化时需要同步更新对应包的 README 与 examples。每个 Provider 包 README 都承诺有安装命令和可运行的 quickstart这是保持仓库示例可运行的一部分。6. 有 Python 对应物时使用 cross-sdk-parity对存在 Python 对应实现的 Provider应遵循cross-sdk-parity技能见 .agents/skills/cross-sdk-parity/SKILL.md保持 TypeScript 与 Python 两侧 SDK 的行为、生成客户端用法、公共 API 命名与文档示例对齐。作为对照Python 侧 Provider 的开发流程记录在 .agents/skills/python-providers/references/provider-workflow.md使用make create-provider nameprovider-name两者共享保留框架原生约定、同步文档、跨 SDK 对齐的原则。第四步验证与构建provider-workflow.md给出的验证命令如下pnpm --filter composio/provider typecheck pnpm --filter composio/provider test pnpm build:packagestypecheck对目标 Provider 包做严格类型检查tsconfig.json中开启了strict: true确保与composio/core的类型契约一致test运行该包的 vitest 测试脚手架生成的package.json中test脚本为vitest runbuild:packages仓库级全量构建。在 package.json 中定义为turbo build --filter./ts/packages/**会用 tsdown 构建所有 TS 包产物用于确认新增 Provider 与现有包的构建互不破坏。对于快速迭代也可以像 Python 侧工作流那样针对单个包做窄范围验证避免每次全量构建。第五步编写测试provider-workflow.md要求针对以下四类场景补充测试Wrapping包装验证wrapTool/wrapTools输出的工具格式是否符合框架规范Tool-call 处理执行处理验证executeToolCall、handleToolCalls等辅助方法能否正确处理框架回传的工具调用块Schema 转换验证工具参数 Schema 在转换后仍保持正确的类型、必填项与描述信息框架版本兼容性覆盖所适配框架的不同版本行为。以 ts/packages/providers/openai/test/openai.test.ts 为参考测试采用 vitest 的vi.mock对 OpenAI 模块打桩并通过provider._setExecuteToolFn(mockExecuteToolFn)注入模拟执行函数再验证 Provider 的包装与执行逻辑。Anthropic 包ts/packages/providers/anthropic/src/index.ts中的executeToolCall与handleToolCalls则是执行处理测试的典型对象——前者执行单个tool_use块并返回 JSON 字符串后者批量执行并返回可直接追加到消息列表的MessageParam[]数组。建议将测试放在ts/packages/providers/name/test/下与官方包保持一致的组织方式便于被pnpm --filter过滤执行。小结Composio TypeScript Provider 的开发工作流可以归纳为一条清晰的闭环在ts/packages/providers/下用pnpm create:provider脚手架生成包 → 依据 agentic / non-agentic 基类实现wrapTool/wrapTools必要时实现executeToolCall→ 遵守原生格式、依赖隔离、Schema 规范化、文档同步、跨 SDK 对齐等实现规则 → 通过typecheck、test、build:packages三重验证 → 按 wrapping、执行处理、Schema 转换、版本兼容四类场景补齐测试。遵循这一工作流既能保证新增框架适配器与核心 SDK 的类型契约一致也能让工具在目标 Agent 框架中以最原生的形态被调用这正是 Composio 多框架支持能力得以持续扩展的基础。【免费下载链接】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 TypeScript Provider 开发工作流：从脚手架创建到框架适配器落地
Composio TypeScript Provider 开发工作流从脚手架创建到框架适配器落地【免费下载链接】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 仓库中 .agents/skills/typescript-providers/references/provider-workflow.md 为核心脉络系统讲解 TypeScript Provider框架适配器的完整开发工作流如何创建或定位 Provider 包、遵循哪些实现规则、如何完成类型检查与测试验证。读完本文你将掌握在 Composio 中为 OpenAI、Anthropic、LangChain 等 AI 框架开发原生工具适配器的标准化流程并能对照仓库源码理解 Provider 的底层运行机制。什么是 Composio TypeScript ProviderComposio 通过 Provider 机制将平台上的 1000 工具适配到各个 AI 框架的原生工具格式。在 ts/packages/providers/README.md 中可以看到每个包负责将一个 Agent 框架的调用约定转换为 Composio 工具包名适配框架composio/openaiOpenAI Chat Completions 与 Responses APIcomposio/openai-agentsOpenAI Agents SDKcomposio/anthropicAnthropic Messages APIcomposio/claude-agent-sdkClaude Agent SDKcomposio/vercelVercel AI SDKcomposio/googleGoogle GenAIcomposio/langchainLangChain 与 LangGraphcomposio/llamaindexLlamaIndexcomposio/mastraMastracomposio/cloudflareCloudflare Workers AI使用方式非常统一将 Provider 实例传入new Composio({ provider })之后session.tools()返回的工具就能被对应框架直接调用。例如 Anthropic Provider 的典型用法见 ts/packages/providers/anthropic/README.mdimport Anthropic from anthropic-ai/sdk; import { Composio } from composio/core; import { AnthropicProvider } from composio/anthropic; const composio new Composio({ provider: new AnthropicProvider(), }); const client new Anthropic(); const session await composio.create(user_123); const tools await session.tools(); let response await client.messages.create({ model: claude-opus-4-6, max_tokens: 4096, tools, messages: [{ role: user, content: Send an email to johnexample.com... }], }); // Agentic loop: 持续执行工具调用直到模型返回文本 while (response.stop_reason tool_use) { const toolResults await composio.provider.handleToolCalls(session, response); messages.push({ role: assistant, content: response.content }); messages.push(...toolResults); response await client.messages.create({ model: claude-opus-4-6, max_tokens: 4096, tools, messages }); }Provider 的工作流程provider-workflow.md正是围绕创建/定位 → 实现 → 验证这一开发闭环展开的本文后续各节将逐一深入。第一步创建或定位 Provider 包使用脚手架命令创建新 Provider在仓库根目录执行pnpm create:provider provider-name [--agentic]该命令在 package.json 中定义为bash ts/scripts/create-provider.sh。阅读 ts/scripts/create-provider.sh 可知它会自动完成以下工作在ts/packages/providers/provider-name/下创建目录结构生成package.json包名为composio/provider-name内置build: tsdown与test: vitest run脚本peerDependencies 声明composio/core生成tsconfig.jsonextends 仓库根目录 tsconfig.base.json启用strict、declaration等生成tsdown.config.ts复用 tsdown.config.base.ts 基础配置生成src/index.ts骨架非 agentic 模式导出extends BaseNonAgenticProvider的ProviderNameProvideragentic 模式则导出extends BaseAgenticProvider的版本并预置wrapTool/wrapTools待实现方法生成 README.md 模板。Provider 包的存放位置所有 TypeScript Provider 统一位于ts/packages/providers/目录当前已有 openai、openai-agents、anthropic、claude-agent-sdk、vercel、google、langchain、llamaindex、mastra、cloudflare 十个包。每个包均包含src/实现、test/vitest 测试、README.md安装命令与可运行 quickstart、tsdown.config.ts构建配置新增包请保持这一目录约定。若只是修改已有框架的适配直接定位到对应包即可无需重新脚手架。第二步理解 Provider 的两种基类在动手实现前需要先明确 Provider 属于哪一类别。从 ts/packages/core/src/provider/BaseProvider.ts 的源码可以看到Provider 全部继承自内部基类BaseProviderTMcpResponse并由两个公开抽象子类分化出两种模式非 Agentic ProviderBaseNonAgenticProvider_isAgentic false只负责把工具 Schema 转换成原始模型 API 的格式如 OpenAI、Anthropic、Cloudflare抽象方法签名为wrapTool(tool: Tool): TTool与wrapTools(tools: Tool[]): TToolCollection不携带执行函数工具循环tool loop由开发者自己的代码驱动调用 Provider 提供的executeToolCall/handleToolCalls等辅助方法完成执行。Agentic ProviderBaseAgenticProvider_isAgentic true将工具包装为自带执行函数的形式如 LangChain 的DynamicStructuredTool、LlamaIndex、Mastra、Vercel、OpenAI Agents抽象方法签名为wrapTool(tool: Tool, executeTool: ExecuteToolFn): TTool与wrapTools(tools: Tool[], executeTool: ExecuteToolFn): TToolCollection——执行函数由核心 SDK 注入工具循环由框架自行驱动。BaseProvider还暴露了公共方法executeTool(toolSlug, body, modifiers)它映射到Tools类的execute方法供 Provider 实现执行辅助函数若未注入全局执行函数会抛出ComposioGlobalExecuteToolFnNotSetError。另外executeToolForTarget负责区分两种执行目标传入userId字符串时走直连工具 API传入 Tool Router 会话对象时则调用target.execute(toolSlug, arguments_)并拒绝在会话绑定模式下混用直连执行选项assertToolCallExecutionOptions会抛出TypeError。因此创建 Provider 时选择--agentic与否直接决定了生成的骨架类与需要实现的接口签名。第三步遵循实现规则provider-workflow.md明确了五条实现规则结合仓库源码可以进一步理解每条规则背后的约束1. 保持框架原生工具格式适配器的价值在于原生化。以 ts/packages/providers/langchain/README.md 为例每个工具都被包装成标准的DynamicStructuredTool因此可以直接用于 LangChain 的 chains、LCEL 管线或任何 chat model 的bindToolsLangGraph 在 TypeScript 侧也由同一包提供服务。不要把工具改造成 Composio 私有格式否则框架无法识别。2. Provider 特有代码留在 Provider 包内Provider 专属逻辑应封闭在ts/packages/providers/name/中。核心包composio/core只保留通用抽象与执行注入机制这也解释了为什么 ts/packages/providers/openai/src/index.ts 中的OpenAIProvider直接由composio/core导出它是核心内置的便捷导出而 Responses Provider 则放在包内单独实现。3. 避免把 Provider 专属依赖泄漏进核心在 ts/packages/providers/AGENTS.md 中有更细化的补充Provider 的依赖只应出现在自身包的package.json中不得反向引入composio/core。脚手架生成的package.json也印证了这一点——它只声明composio/core为 peerDependency。4. Schema 规范化要求AGENTS.md补充了一条关键实现细节凡接收原始Tool的 Provider在输出厂商 JSON Schema 之前必须调用composio/core的deduplicateJsonSchemaRequiredArrays去重required数组若工具已通过ToolSchema规范化且未再做变换则无需重复调用。5. 同步更新文档与示例当 Provider 的设置方式或公共用法变化时需要同步更新对应包的 README 与 examples。每个 Provider 包 README 都承诺有安装命令和可运行的 quickstart这是保持仓库示例可运行的一部分。6. 有 Python 对应物时使用 cross-sdk-parity对存在 Python 对应实现的 Provider应遵循cross-sdk-parity技能见 .agents/skills/cross-sdk-parity/SKILL.md保持 TypeScript 与 Python 两侧 SDK 的行为、生成客户端用法、公共 API 命名与文档示例对齐。作为对照Python 侧 Provider 的开发流程记录在 .agents/skills/python-providers/references/provider-workflow.md使用make create-provider nameprovider-name两者共享保留框架原生约定、同步文档、跨 SDK 对齐的原则。第四步验证与构建provider-workflow.md给出的验证命令如下pnpm --filter composio/provider typecheck pnpm --filter composio/provider test pnpm build:packagestypecheck对目标 Provider 包做严格类型检查tsconfig.json中开启了strict: true确保与composio/core的类型契约一致test运行该包的 vitest 测试脚手架生成的package.json中test脚本为vitest runbuild:packages仓库级全量构建。在 package.json 中定义为turbo build --filter./ts/packages/**会用 tsdown 构建所有 TS 包产物用于确认新增 Provider 与现有包的构建互不破坏。对于快速迭代也可以像 Python 侧工作流那样针对单个包做窄范围验证避免每次全量构建。第五步编写测试provider-workflow.md要求针对以下四类场景补充测试Wrapping包装验证wrapTool/wrapTools输出的工具格式是否符合框架规范Tool-call 处理执行处理验证executeToolCall、handleToolCalls等辅助方法能否正确处理框架回传的工具调用块Schema 转换验证工具参数 Schema 在转换后仍保持正确的类型、必填项与描述信息框架版本兼容性覆盖所适配框架的不同版本行为。以 ts/packages/providers/openai/test/openai.test.ts 为参考测试采用 vitest 的vi.mock对 OpenAI 模块打桩并通过provider._setExecuteToolFn(mockExecuteToolFn)注入模拟执行函数再验证 Provider 的包装与执行逻辑。Anthropic 包ts/packages/providers/anthropic/src/index.ts中的executeToolCall与handleToolCalls则是执行处理测试的典型对象——前者执行单个tool_use块并返回 JSON 字符串后者批量执行并返回可直接追加到消息列表的MessageParam[]数组。建议将测试放在ts/packages/providers/name/test/下与官方包保持一致的组织方式便于被pnpm --filter过滤执行。小结Composio TypeScript Provider 的开发工作流可以归纳为一条清晰的闭环在ts/packages/providers/下用pnpm create:provider脚手架生成包 → 依据 agentic / non-agentic 基类实现wrapTool/wrapTools必要时实现executeToolCall→ 遵守原生格式、依赖隔离、Schema 规范化、文档同步、跨 SDK 对齐等实现规则 → 通过typecheck、test、build:packages三重验证 → 按 wrapping、执行处理、Schema 转换、版本兼容四类场景补齐测试。遵循这一工作流既能保证新增框架适配器与核心 SDK 的类型契约一致也能让工具在目标 Agent 框架中以最原生的形态被调用这正是 Composio 多框架支持能力得以持续扩展的基础。【免费下载链接】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），仅供参考