Composio 代理工具集成平台

要解决的问题

把 AI 代理真正接进现实业务系统，难点往往不在模型本身，而在外部应用那一层。Gmail、Slack、GitHub、Notion 各自一套身份体系和 API 形态，认证方式、权限粒度、限流策略都不一样。让开发者逐个对接，一个代理要写几十份胶水代码，token 刷新、scope 申请、错误重试这些脏活全得自己兜。更麻烦的是凭据泄漏风险：工具执行一旦跑在代理进程里，API key 和用户数据很容易混在一起。

核心能力与关键步骤

这个技能把这部分工作收敛到一套预构建工具包上。平台提供超过 1000 个工具，覆盖常用外部应用，接入时不用再手写每个服务的适配层。

• 托管身份验证：认证流程由平台侧维护，代理不需要自行处理登录态、token 过期与 scope 协商，凭据不必落进代理进程。
• 上下文管理：调用外部应用时，输入输出可以按会话组织和保留，避免每轮对话都重新拉取状态。
• 沙盒执行：工具实际运行在隔离环境中，副作用与外部请求有边界，代理侧拿到的是执行结果而非不受控的进程权限。
• SDK 抽象：提供 Python 与 TypeScript 两套 SDK，对齐主流代理框架的写法，工具调用在代码层表现为统一接口，框架迁移时不必重写集成逻辑。

典型路径是：在代理代码中引入 SDK，声明需要哪些外部应用的能力，运行时由平台解析工具、处理认证并转发到目标应用，沙盒内完成执行后把结果回注到代理上下文。

适用边界与注意点

这套方案的前提是网络可达与应用在工具清单覆盖范围内。未收录的私有系统仍需自建适配。托管认证意味着认证状态托管在平台侧，对合规要求严格的场景需要评估数据驻留与权限模型。沙盒执行引入额外一跳，高频低延迟调用要实测延迟开销。SDK 与代理框架的兼容程度以官方支持为准，深度定制的工具行为需要自行验证。