超越MCP：用TWG CLI把AI编程代理接入Jira与Bitbucket

A CLI-first way to give your coding agent the ticket, the PR, and the review comments. Why it usually costs fewer tokens than an MCP server, and what broke when I set it up on a corporate Windows laptop.

AI 编程代理写代码这件事已经做得不错了，但它们大多仍然对为什么写这段代码一无所知。验收标准在 Jira，设计笔记在 Confluence，评审意见在 Bitbucket 的 PR 里。于是开发者成了工具与代理之间的人肉复制粘贴层。

这篇文章讲的是 Atlassian 的 Teamwork Graph CLI（TWG CLI）如何补上这一环：为什么它的 CLI 优先设计比典型 MCP 服务器更适合编程代理，以及它在一台受管控的企业 Windows 笔记本上安装时踩到的坑。

Beyond MCP: Wiring Your AI Coding Agent to Jira and Bitbucket with Atlassian's TWG CLI

TWG CLI 到底是什么

TWG CLI 是一个命令行工具，让 AI 编程代理访问你的 Atlassian 工作上下文。Atlassian 的说法是它为代理而生，而不是把旧工具改造给代理用。

它构建在 Teamwork Graph 之上——Atlassian 用来描述人、内容、活动及其相互关系的一张图。这张图是权限感知的，代理只能看到你本来就有权限看到的东西。

覆盖面相当广：

Jira： 工作项、看板、冲刺、过滤器、状态流转、关联关系
Confluence： 页面、空间、数据库、白板、搜索
Bitbucket： 仓库、PR、分支、提交、流水线
其他： Jira Service Management、Assets、Loom、Trello、Rovo Search、Goals

它能配合 Claude Code、Codex、Gemini CLI、Cursor 等任何能执行 shell 命令的代理使用。你不需要学它的语法——你只提结果，比如「我有哪些未关闭的 Jira issue？」，具体命令由代理自己选。

目前 TWG CLI 处于 Atlassian 的 Early Access Program 阶段，免费使用，官方注明部分功能日后可能转为付费。

为什么不用 MCP？先说上下文税

MCP 是一个开放协议，让代理通过标准接口发现并调用外部工具。Atlassian 自己也有一款：Rovo MCP Server，面向 Jira、Confluence、Jira Service Management、Bitbucket 和 Compass 的云端托管端点，用 OAuth 2.1 和你的现有权限做安全控制。

它是个好产品。问题在于哪种形态更贴合编程代理。

MCP 对编程代理最大的成本是上下文。典型 MCP 客户端会在代理干任何活之前，就把每个工具的名称、描述和输入 schema 全部加载进模型的上下文窗口。服务越大，这笔开销越贵。被广泛引用的一个例子是：某 GitHub MCP 服务器在第一个任务之前就加载了约 55,000 token 的工具定义。Tyk 汇总的基准测试显示，MCP 的 token 消耗是等价 CLI 调用的 4 到 32 倍。

CLI 走的是另一条路。代理启动时几乎什么都不加载。需要某个命令时，跑一次该命令的 --help，读几百个 token。TWG 正是吃透了这一点：每条命令遵循同样的模式，并且每一层都暴露帮助信息，代理可以边走边发现功能。

公平地说，MCP 客户端也在变聪明。Claude Code 加入了工具搜索，不再一次性加载全部 schema。差距在收窄，但对一个本来就住在终端里的编程代理来说，CLI 仍然是更自然的形态。

MCP（Model Context Protocol，模型上下文协议） 是 Anthropic 于 2024 年底开源的一项标准，允许 AI 应用以统一接口发现并调用外部工具和数据源。它的价值在于把分散的集成抽象成协议：一个 MCP Server 声明自己提供哪些工具（名称、描述、JSON Schema 格式的输入参数），任何兼容 MCP 的客户端都能挂载使用，无需为每个模型或 IDE 单独适配。理论上这降低了集成成本，但也带来一个被低估的副作用——工具定义必须进入模型上下文才能被调用，而模型上下文窗口是稀缺资源。服务越庞大，这份“清单”越昂贵，这正是本文所说的上下文税。

TWG CLI 与 Rovo MCP Server 对比

两者都尊重你的 Atlassian 权限。区别主要在运行位置和如何加载进代理。

维度	TWG CLI	Rovo MCP Server
运行位置	本机，本地二进制	Atlassian 云端，远程端点
上下文成本	按需读取帮助，逐命令	工具 schema 预先加载，除非客户端支持工具搜索
登录方式	浏览器 OAuth，PR 功能另需 Bitbucket API token	OAuth 2.1；Bitbucket 和 JSM 工具需要 API token 认证
覆盖产品	Jira、Confluence、Bitbucket、JSM、Assets、Loom、Trello、Rovo、Goals	Jira、Confluence、JSM、Bitbucket、Compass
可组合性	输出可管道传给脚本和其他 shell 命令	调用走 MCP 客户端
最佳场景	终端或 IDE 里的编程代理	没有 shell 的浏览器和聊天客户端
状态	Early Access，暂时免费	Jira、Confluence、Compass 已正式可用

token 消耗：加上 TWG 之后变了什么

加入 TWG 几乎不改变代理的启动上下文，而 MCP 服务器会把整份工具清单塞进每一个会话。具体差距取决于服务器和客户端，所以下面这些公开数字只能当参考，最终要测自己的环境。

公开测量数据说明了什么

配置	首个任务前加载的 token	典型任务 token	来源
GitHub MCP 服务器（43 个工具）	约 55,000	schema 全程驻留	Manveer Chawla
含 20 个工具的 MCP 服务器	3,000–10,000	schema 全程驻留	MindStudio
等价 CLI（`gh issue create`）	接近零	约 200 token 帮助信息，总计不到 500	Manveer Chawla

Scalekit 的基准测试也发现，在等价任务上 MCP 的 token 用量是 CLI 的 4 到 32 倍。这些数字不是 Atlassian 专属的，但它揭示了规律。

TWG 处在什么位置

TWG 以 skills + CLI 的形式进入 Claude Code。一个 skill 在会话开始时只加载它短短的名字和描述；完整指令要等代理决定使用时才加载。之后代理只为即将执行的命令读取 TWG 的命令帮助。

所以固定成本只是几条很短的 skill 描述，其余按任务付费，花多少取决于任务需要多少。换句话说，TWG 工作流通常比同样的 MCP 工作流省 token。省下来的是开销：MCP 服务器在整个会话期间把所有工具定义留在上下文里，用不用都在；TWG 只加载当前这一步需要的。

两个前提条件

内容本身的花费两边一样。 一份长长的 Jira 描述或一大段 PR diff，无论走 MCP 还是 TWG，token 都差不多。如果任务主要是读大 ticket 或大 diff，差距会缩小。

差距在收窄。 MCP 客户端正在加入工具搜索，只在需要时加载工具定义。Claude Code 已经这么做了，这消除了 MCP 很大一部分前置开销。

skills 是 Anthropic 在 Claude Code 中引入的一种渐进式加载机制。 一个 skill 通常是一个 Markdown 文件加若干辅助资源，开头有一段简短的 name 和 description 元数据。会话启动时，Claude 只把这些简短的元数据载入上下文；只有当模型判断当前任务确实需要某个 skill 时，才会读取它的完整指令正文。这与 MCP 一次性列全部工具 schema 的做法截然相反，把“是否加载”的决策推迟到真正需要的那一刻。TWG 正是利用这一点，让几乎所有上下文开销都发生在实际调用命令的当下，而不是会话开始时。

自己动手量一遍

在三个全新会话里跑同一个 prompt 并记录数字。在 Claude Code 里，/context 会显示上下文窗口的构成，包括工具定义。

开启一个没有任何 Atlassian 集成的会话，运行 /context。这是基线。
加上 Rovo MCP Server，开新会话再跑一次 /context；然后问「拉取 PROJ-1234 并总结它的验收标准」，再跑一次 /context。
移除 MCP 服务器，启用 TWG，在新会话里重复第二步。

配置	启动时工具与 skill 定义（token）	拉取并总结任务后总计（token）
基线，无集成	[你的数字]	[你的数字]
含 Rovo MCP Server	[你的数字]	[你的数字]
含 TWG CLI	[你的数字]	[你的数字]

自己的数字比任何基准测试都有说服力。如果你的客户端支持 MCP 工具搜索，也一并记下来，因为它会让差距变小。

五个每天都在用的工作流

TWG 接好之后，你不再在两个工具之间搬文字，而是直接要结果。以下是实践中最有用的五个场景。

接手一个 ticket。 「接手 PROJ-1234。」代理读取故事和验收标准，创建分支，提出方案。你从真实需求出发，而不是凭记忆。
一步开 PR。 「把 PROJ-1234 提交、推送并开 PR。」代理根据 ticket 和 diff 自动写 PR 描述，描述与工作项保持一致并互相关联。
不用打开浏览器就处理评审反馈。 「处理我 PR 上的评论。」代理拉取评审意见，做出修复，并起草回复供你检查。
对照 ticket 做评审，而不只看代码。 「评审 PR #193。」代理把 diff 对照验收标准检查，这能抓住纯风格评审会漏掉的「代码干净但功能不对」问题。
早上看一眼全局。 「我今天要做什么？」代理把冲刺里的 ticket 和等你评审的 PR 汇总起来，是站会不错的起点。

共同点是：代理和你的团队用的是同一个事实来源。这比速度更重要——从 ticket 生成的 PR 描述，比下午六点凭记忆敲出来的更准确。

安装过程与企业网络上的坑

官方安装大约十分钟。在一台企业 Windows 笔记本上，我花了更久。下面是我实际走通的路径，以及你可能遇到的问题。

1. 安装二进制

Windows 上 Atlassian 的安装器是一个 PowerShell 脚本：

curl.exe -fsSL https://teamwork-graph.atlassian.com/cli/install.ps1 -o "$env:TEMP\twg-install.ps1"
powershell -ExecutionPolicy Bypass -File "$env:TEMP\twg-install.ps1" -Yes -SkipLogin -Plugin claude-code

请自己动手跑。 处于自动模式的代理通常会拒绝下载并执行远程脚本——它们拒得对。

2. 打开一个新终端

安装器会把 TWG 加进用户 PATH，但当前窗口看不到。用 twg --version 验证。

3. 连接账号与代理

twg setup
twg skills install --agent claude
twg upkeep enable

twg setup 会拉起浏览器登录并询问你的 Atlassian 站点。当它提出要 Bitbucket API token 时请同意，否则 PR 相关功能无法工作。token 只粘贴到 TWG 的掩码输入提示里，绝不要贴进聊天窗口。第二条命令把 TWG 的 skills 放到 Claude Code 会查找的位置。第三条负责在后台保持登录状态刷新。

4. 验证

开一个新的代理会话，让它运行 twg doctor 并拉取一个你熟悉的 ticket。所有检查都应通过。

我踩到的坑

安装器在下载二进制时卡住。 企业级 HTTPS 检查会拖慢甚至阻塞大文件下载。直接用 curl.exe 把二进制下载到 %LOCALAPPDATA%\Programs\twg\bin\twg.exe，把该目录加进用户 PATH，然后从第 2 步继续。这会跳过安装器的插件步骤，所以别漏掉 twg skills install。
Node 脚本报 unable to get local issuer certificate。 同一个 HTTPS 检查搞坏了调用 Atlassian API 的 Node 工具。较新的 Node 版本可以用 --use-system-ca 信任 Windows 证书存储；旧版本需要把受信任根证书导出为 PEM 文件，再把 NODE_EXTRA_CA_CERTS 指向它。千万不要设置 NODE_TLS_REJECT_UNAUTHORIZED=0，那等于完全关闭证书校验。

护栏：代理以你的身份行动

代理发布的一切都挂你的名字：PR、评论、ticket 状态变更。请认真对待这件事。

每一次写入都要批准。 让代理自由读取，但每个 PR、每条评论和每次状态变更都要在发出前确认。
对产出负责。 生成的 PR 描述或评审回复都只是草稿。像自己写的一样去读它，因为署名就是你。
别把密钥放进聊天和仓库。 token 属于掩码提示、操作系统凭据存储或 git 忽略的 .env 文件。加进去之前先用 git check-ignore .env 检查。
搞清楚当前是哪个账号。 一台机器上同时有个人和公司 AI 账号时，处理公司代码前先确认当前激活的是哪个，并遵守雇主对个人工具的政策。
最小权限原则依然适用。 TWG 和 Rovo MCP Server 都继承你的 Atlassian 权限，从不多给。所以权限过大的用户，意味着权限过大的代理。

什么情况下 MCP 仍是更好的选择

CLI 优先并不是万能解。以下情况请选 Rovo MCP Server：

你的客户端没有 shell。 基于浏览器的代理和聊天应用跑不了本地二进制。Atlassian 自己的插件页面就建议在浏览器里用 Claude Code 的人改装 Rovo MCP 插件。
非开发者也需要访问。 产品经理和支持人员不需要安装任何东西就能连上托管 MCP 服务器。
管理员想要集中管控。 Atlassian 管理员可以控制哪些外部 AI 工具和域名能连到 Rovo MCP Server。

很多团队会两者并用：开发者在终端里用 TWG CLI，其他人用 Rovo MCP。

核心要点

编程代理的水平取决于它拿到的上下文。把代理连到你的 ticket 和 PR，比写一个更好的 prompt 更重要。
对住在终端里的代理而言，像 TWG 这样的 CLI 通过按需读取帮助信息，而不是预加载所有工具 schema，让上下文窗口保持精简。
MCP 在浏览器客户端、非开发者和集中管控访问上仍有优势，所以多数团队会两者都用。
在企业机器上要预期网络和证书摩擦。用系统证书存储来修，而不是关掉 TLS 校验。
代理以你的身份发言。每次写入都要批准，并把它的产出当作你自己的草稿。

资料来源

What is Teamwork Graph CLI?（Atlassian Support）
Teamwork Graph CLI（Atlassian Developer）
TWG CLI（Atlassian Developer）
atlassian/twg-cli（GitHub）
Atlassian Teamwork Graph CLI plugin（Claude plugins）
About the Atlassian Rovo MCP Server（Atlassian Developer）
atlassian/atlassian-mcp-server（GitHub）
MCP vs CLI for AI agents: enterprise comparison guide（Tyk）
MCP vs. CLI for AI agents: when to use each（Manveer Chawla）
MCP vs CLI for AI agents: token costs（MindStudio）
CLI vs MCP: what AI agents actually use now（VideoGen）

背景补充

企业网络普遍部署中间人（MITM）HTTPS 检查：代理服务器用自己的证书替换服务器证书，以便解密和审计流量。操作系统会信任这个代理根证书，但许多运行时（尤其是 Node.js）自带一份独立的 CA 信任列表，不读取 Windows 证书存储，于是报出 unable to get local issuer certificate。正确的修法是让 Node 信任系统证书：较新版本可用 --use-system-ca 参数，旧版本则需把代理根证书导出为 PEM 并设置 NODE_EXTRA_CA_CERTS 环境变量指向它。设置 NODE_TLS_REJECT_UNAUTHORIZED=0 虽然能立刻绕过错误，但会彻底关闭证书校验，使所有 HTTPS 流量暴露在中间人攻击之下，绝不可取。