前言

最近，我在尝试构建一个自动化工作流，目标是让 AI 能够直接在 GitHub 上帮我完成提 PR、更新 issue、添加评论等操作。过去，这类任务要么需要我手动操作，要么就得编写脚本调用 GitHub API，每次都得处理认证、权限、错误重试等繁琐的细节。

这时，我注意到了 Composio 这个项目。它宣称能让 AI 直接连接 GitHub、Slack、Jira、Gmail 等 150 多个工具，无需自行编写集成代码。这让我眼前一亮——或许它能帮我实现“AI 自动提 PR”这个想法。

如果你也想过用 AI 来操作第三方服务，但又担心权限配置太复杂，或者对赋予 AI 过多权限心存安全疑虑，那么这篇实践记录或许能帮你避开一些我踩过的坑。

我的需求场景

我有一个开源项目，经常需要去开展这些操作：

• 把 issue 内容作为依据自动创建对应的 PR
• 在 PR 当中自动添加测试结果的评论
• 依据代码变更自动更新文档
• 同时自动给 PR 打上标签

之前我是运用 GitHub Actions 加上自己编写的 Python 脚本来开展这项工作的，但每次都要去处理 GitHub API 的认证、错误重试以及速率限制这些问题，代码编写起来十分繁琐。

---

环境准备

• macOS 14.3
• Python 3.11
• 一个测试用的 GitHub 仓库（我专门建了个私有仓库来测试）
• OpenAI API key（Composio 需要调用 LLM）

---

安装 Composio

官方文档说用 pip 安装就行：

pip install composio-core composio-openai

装完之后验证一下：

composio --version

输出：

Composio version 0.3.8

看起来已经被装上了。

---

第一步：开展与 GitHub 的连接工作

Composio 需要先经过授权才可以去操作 GitHub。你可以运行：

composio add github

这个命令会打开浏览器，跳转到 GitHub OAuth 授权页面。

然后我看到了权限列表，直接愣住了：

• Read access to code
• Read and write access to actions, code, commit statuses, issues, pull requests, and workflows
• Read and write access to administration, members, and organization projects

这是要我给它完整的仓库读写权限，还包括 Actions、workflows、甚至组织管理权限。

我犹豫了一下，想着反正是测试仓库，就点了"Authorize"。

授权完成后，终端显示：

✓ Successfully connected GitHub account
Connection ID: conn_xxxxxxxxxxxxxx

---

写代码测试

官方文档给了个示例，我照着改了一下：

from composio_openai import ComposioToolSet, Action
from openai import OpenAI

# 初始化
toolset = ComposioToolSet()
client = OpenAI()

# 获取 GitHub 工具
tools = toolset.get_actions(actions=[Action.GITHUB_CREATE_PULL_REQUEST])

# 让 AI 创建一个 PR
response = client.chat.completions.create(
    model="gpt-4",
    tools=tools,
    messages=[
        {
            "role": "user",
            "content": "在我的仓库 test-repo 里创建一个 PR，标题是 'Add README'，从 feature 分支合并到 main 分支"
        }
    ]
)

# 执行 AI 返回的工具调用
result = toolset.handle_tool_calls(response)
print(result)

运行之后，报错了：

Error: Repository 'test-repo' not found or you don't have access

我去检查了一下，发现问题：Composio 不知道我的 GitHub 用户名，它不知道完整的仓库路径应该是 username/test-repo。

改了一下代码，把仓库路径写完整：

content = "在我的仓库 myusername/test-repo 里创建一个 PR，标题是 'Add README'，从 feature 分支合并到 main 分支，PR 描述写：这是一个测试 PR"

再跑一次，这次成功了。去 GitHub 上看，PR 真的创建出来了：

• 标题：Add README
• 源分支：feature
• 目标分支：main
• 描述：这是一个测试 PR

---

然后我发现了权限问题

测试成功后，我想看看 Composio 到底拿到了哪些权限。去 GitHub Settings → Applications → Authorized OAuth Apps，找到 Composio，点进去看详情。

权限列表：

• repo (Full control of private repositories)
• workflow (Update GitHub Action workflows)
• admin:org (Full control of orgs and teams)
• admin:repo_hook (Full control of repository hooks)

这个权限范围太大了。它不仅能读写代码，还能：

• 修改 GitHub Actions workflows
• 管理组织和团队
• 修改 repository hooks
• 删除仓库

我只是想让 AI 帮我提个 PR，结果给了它几乎所有权限。

---

试着限制权限

我去看 Composio 的文档，想找找能不能只授权部分权限。

文档里说，Composio 使用 GitHub OAuth App，权限是固定的，不能自定义。如果要限制权限，需要用 GitHub App 而不是 OAuth App。

但 Composio 目前只支持 OAuth App 方式，不支持 GitHub App。

我又去看了 GitHub 的 OAuth 权限文档，发现 repo 这个 scope 是全有或全无的，不能只授权 PR 相关的权限。

也就是说，要么给完整的仓库读写权限，要么什么都不给。

---

换个思路：用 Personal Access Token

我想到可以不用 OAuth，改用 Personal Access Token (PAT)。PAT 可以精细控制权限。

去 GitHub Settings → Developer settings → Personal access tokens → Fine-grained tokens，创建一个新 token：

• Repository access: 只选我的测试仓库
• Permissions:
  • Pull requests: Read and write
  • Contents: Read-only
  • Issues: Read and write

这样就只给了 PR 和 issue 的权限，没有给代码写入、workflows、组织管理这些权限。

然后在 Composio 里配置这个 token：

composio add github --api-key "ghp_xxxxxxxxxxxx"

结果报错：

Error: API key authentication is not supported for this integration. Please use OAuth.

看来 Composio 不支持用 PAT，只能用 OAuth。

---

实际测试几个场景

虽说权限方面的问题让我心里头多少有些犯嘀咕，但我还是接着去测试了好几个实际的应用场景。

场景 1：自动创建 PR

我们之前已经针对这段内容做过测试，它确实可以正常运行。AI 能够准确领会我的诉求，调用了对应的 API 接口，最终生成出完全符合要求的 PR 文件。

场景 2：在 PR 里添加评论

代码：

tools = toolset.get_actions(actions=[Action.GITHUB_CREATE_ISSUE_COMMENT])

response = client.chat.completions.create(
    model="gpt-4",
    tools=tools,
    messages=[
        {
            "role": "user",
            "content": "在 myusername/test-repo 的 PR #1 里添加评论：测试通过，可以合并"
        }
    ]
)

result = toolset.handle_tool_calls(response)

运行成功，评论添加上了。

场景 3：根据 issue 内容创建 PR

这项工作其实稍微复杂一些，得先让 AI 把这份 issue 的具体内容完整读取下来，之后再依据里面的细节信息，创建出与之相对应的 PR。

代码：

tools = toolset.get_actions(actions=[
    Action.GITHUB_GET_ISSUE,
    Action.GITHUB_CREATE_PULL_REQUEST
])

response = client.chat.completions.create(
    model="gpt-4",
    tools=tools,
    messages=[
        {
            "role": "user",
            "content": "读取 myusername/test-repo 的 issue #5，根据 issue 内容创建一个对应的 PR"
        }
    ]
)

result = toolset.handle_tool_calls(response)

在程序运行之后，AI 首先调用了 GITHUB_GET_ISSUE 来获取对应的 issue 内容，之后又调用了 GITHUB_CREATE_PULL_REQUEST 来创建 PR。

但我留意到一个情况：用 AI 生成的 PR 标题和描述，全都是直接从 issue 里复制过来的，没有做任何调整。要是 issue 的标题写得不够规范，那对应的 PR 标题自然也会跟着不规范。

我试着在 prompt 里加了更详细的要求：

content = "读取 myusername/test-repo 的 issue #5，根据 issue 内容创建一个 PR。PR 标题要简洁明了，描述要包含：1) 解决的问题 2) 实现方案 3) 测试情况"

这次由 AI 生成的 PR 质量确实好了不少，不光标题写得很规范，就连配套的描述也做得十分完整。

场景 4：批量操作

我想要试着测试一下，能不能让 AI 批量处理好多项 PR 任务，就比如说给全部还在等待审核的 PR 都添加上对应的标签。

代码：

tools = toolset.get_actions(actions=[
    Action.GITHUB_LIST_PULL_REQUESTS,
    Action.GITHUB_ADD_LABELS_TO_ISSUE
])

response = client.chat.completions.create(
    model="gpt-4",
    tools=tools,
    messages=[
        {
            "role": "user",
            "content": "列出 myusername/test-repo 所有状态为 open 的 PR，给每个 PR 添加 'needs-review' 标签"
        }
    ]
)

result = toolset.handle_tool_calls(response)

运行之后，AI 先是把所有处于开放状态的 PR 全都列了出来，算下来总共有三个，接着便逐个给它们添加上对应的标签。

但我留意到了一个情况：AI 采用的是串行的处理方式，也就是会一个接着一个地去添加标签。要是 PR 的数量比较多的话，整个处理过程就会变得很慢。

我查了一下 Composio 的文档，没有找到批量操作的 API。看来只能串行处理。

---

成本问题

测试了一天，我发现 Composio 的成本主要来自两部分：

1. OpenAI API 调用：每开展一次相关操作，都需要去调用 GPT-4，单次操作的成本大概处于 $0.01 到 $0.03 这个区间之内。
2. Composio 本身：它的免费版本，每个月可以支持 1000 次操作，要是超过了这个次数限制，那么每多一次操作就需要收取 $0.002 的费用。

要是只是偶尔拿来用一用的话，整体成本其实还在可以接受的范围当中。但如果是要开展高频的自动化操作，比方说每一个 PR 都自动去添加评论的话，那么所要投入的成本就会变得相当高。

我算了一下，要是每天要处理 100 个 PR 的话，每个 PR 其实需要完成三次操作，分别是读取、分析还有评论，这么算下来一个月的成本大概是这样的：

• OpenAI: 100 × 3 × 30 × $0.02 = $180
• Composio: (9000 - 1000) × $0.002 = $16
• 总计：$196/月

对于个人项目而言，这样的成本确实显得有些过高了。

---

安全风险

使用了几天之后，我心里头就开始越来越担心起相关的安全问题来了。

Composio 拿到的权限实在是太大了，从理论层面来讲，它可以做这些事情：

• 修改任何一段代码
• 删除对应的代码分支
• 修改 GitHub Actions 的工作流（这意味着还可以注入恶意代码）
• 修改代码仓库的相关设置
• 甚至直接把整个仓库都删掉

虽然 Composio 的官方人员表示他们并不会去存储或是滥用这些权限，但相关的风险其实还是存在的：

1. AI 误操作：要是给 AI 发出的提示语写得不够清楚明白，那么 AI 就有可能执行出错的操作
2. Composio 服务被攻击：如果 Composio 所依托的服务器遭到黑客入侵，那么攻击者就能够获取到所有用户对应的 GitHub 访问权限
3. 第三方依赖风险：Composio 依赖了数量不少的第三方库，要是其中某一个库存在安全漏洞，就有可能造成 token 的泄露

我在进行测试的时候就碰到过一次 AI 出现误操作的情况：当时我让它"关闭所有已经解决的 issue"，结果它直接把所有包含"solved"关键词的 issue 都给关闭了，其中甚至还包括一些还在进行讨论的 issue。

---

我的最终方案

测试完之后，我决定不在生产环境用 Composio。原因：

1. 权限太大：给 AI 完整的仓库写权限风险太高
2. 成本太高：高频使用的话，每月成本接近 $200
3. 误操作风险：AI 理解不准确时可能执行错误操作

我现在的方案是：

1. 简单操作：就是继续使用 GitHub Actions 加上自己编写的脚本就可以了
2. 复杂操作：可以使用 Composio，但有个前提，只能在测试仓库当中进行使用，绝对不能放到生产仓库里面
3. 权限控制：需要专门创建一个机器人账号，只给这个账号分配必要的权限，之后再用这个账号去完成 Composio 的授权工作

具体做法：

我们可以先创建一个名为 myproject-bot 的 GitHub 机器人账号，之后将这个账号添加到目标仓库的协作者列表中，仅赋予其 Write 权限，不开放 Admin 权限。接下来使用这个机器人账号完成 Composio 的授权操作，这样一来即便 Composio 遭遇攻击，攻击者也仅能对这一个仓库进行操作，无法访问到您的其他仓库。

---

总结

Composio 比较适合的场景大概有这些：

• 首先是那些想要快速把 AI 操作第三方服务的原型给验证出来的用户
• 然后是做个人项目或者测试项目的，这类项目对安全方面的要求并不是特别高
• 还有就是只是偶尔会使用，不需要高频度自动化操作，大概每月使用次数在 1000 次以内的情况
• 另外就是能接受给 AI 赋予比较大权限的场景
• 最后还有不想自己动手写集成代码，愿意为了使用的便利性去付费的用户

Composio 并不适合：

• 生产环境，尤其是涉及敏感数据或者关键业务的项目
• 有精细权限控制需求的场景
• 高频自动化的相关需求（这种情况下成本会比较高）
• 对安全性有着很高要求的企业项目
• 存在批量操作或者高性能相关需求的场景

我的建议是，要是你仅仅只是想要试着体验一下 AI 操作第三方服务的实际效果，那么可以使用 Composio
来快速验证你的想法。但如果是要在正式的生产环境当中使用的话，最好还是自己动手编写集成代码，或者是使用专门的机器人账号，同时遵循最小权限的相关原则。

等到 Composio 能够支持更细粒度的权限控制，比如说支持 GitHub App 或者 Fine-grained PAT 这类权限配置方式之后，再在生产环境当中进行使用，其实也并不算晚。