我一直在研究开发者如何把 AI 编程 Agent 引入现有工作流，而 Jira 是一个不错的切入点。很多工程团队早已用 Jira 管理 bug、功能需求、冲刺和待办事项。但问题是：Jira 里有张工单，并不意味着 AI 编程 Agent 就能自动接手它、完成代码改动、再把结果提交给你审阅。
与此同时，Atlassian 正通过 Rovo 为产品注入更多 AI 能力。这些功能确实有用，但对于想用自己的编程 Agent 的团队来说，可能并不想为了接入现有开发工作流，额外再去买一份 AI 使用额度。
所以我想探索一种更实用的方案：不花钱买额外的 Rovo 额度，直接让 Jira 配合你自己的 AI 编程 Agent 工作。
思路很简单：继续把 Jira 当作任务管理工具，将它连接到一个协调 Agent 执行的工具上，然后让 Claude Code 或 Codex 这类 Agent 用你已有的订阅或 API 账号去完成分配的任务。
Sharkly 就是实现这一方案的一种选择。它把 Jira 工单和 Agent 驱动的开发任务连接起来，让团队把工作分配给现有的编程 Agent，并提供一个统一的地方跟踪执行进度、审阅结果。
在这篇指南中，我会带你了解整个工作流的运作方式、如何搭建、能实现哪些功能，以及这里的“免费”究竟是什么意思。
为什么要在 Jira 中使用 AI Agent？
Jira 擅长组织工作。你可以创建 issue、指派责任人、排定 bug 优先级、规划冲刺、跟踪进度。
但管理任务和完成任务之间，始终隔着一道鸿沟。
假设 Jira 里有一条工单：
修复用户在注册表单中填写无效邮箱地址时出现的校验错误，并补充测试覆盖相关场景。
开发者通常会打开代码仓库，排查问题，修改代码，跑一遍测试，然后提交 pull request，最后再更新 Jira，让团队其他成员了解进展。
AI 编程 Agent 可以分担其中大量的实现工作：检查代码、提出修复方案、修改文件、运行测试，甚至创建 pull request。
难点在于，如何把这些步骤接入现有的 Jira 工作流。
如果缺少集成，就得有人手动把工单描述复制到 AI 工具里，手动提供仓库上下文，盯着运行过程，再把结果粘贴回 Jira。
偶尔用一用还行，但要是团队手头有几十个工单，这就太繁琐了。
把 Jira 接入 Agent 执行工作流，可以帮助团队：
- 从现有的工程工作中，直接把编码任务分配给 AI Agent。
- 保留工单描述和验收标准。
- 省去在 Jira 和编码工具之间来回手动复制的操作。
- 跟踪执行进度、阻塞项和结果。
- 在相互隔离的工作区中运行互不干扰的任务。
- 合并之前先审查 AI 生成的改动。
这样做的目的不是把开发者从流程中排除出去，而是减少从发现问题到产出可审查方案之间那些重复性的工作。
在 Jira 中使用 AI Agent 必须付费购买 Rovo 积分吗？
不一定，这取决于你使用哪些 AI 能力和集成。
Atlassian 的 Rovo 在其支持的各款产品中提供 AI 搜索、聊天、Agent 等能力。某些 AI 交互以及增强版 Teamwork Graph API 调用会按积分计量 Rovo 的使用量，包含的额度则取决于你的 Atlassian 套餐和适用的产品。详见 Atlassian 的 Rovo 定价与用量说明。
不过，Jira 并不要求每个外部编码 Agent 都通过 Rovo 来执行代码。
你也可以把 Jira 接到另一个工作流工具上，用自己已有订阅或 API 账户来运行编码 Agent。在这种方案下，编码 Agent 的模型用量由 Agent 提供方结算，不会自动计入 Rovo 的费用。
举个例子，Sharkly 提供了 Jira 集成，支持 Claude Code 和 Codex 等编码 Agent。其公布的定价显示，10 人以内的团队可以免费使用，而模型用量仍然走团队已有的编码套餐和 API 账户。具体套餐详情请查看 Sharkly 官网。
这里有一个关键区别：
所以当我说的“可以免费在 Jira 里用 AI Agent”时，指的是在符合条件的场景下，你可以沿用已有的 Agent 配置，再搭配免费的协调方案，从而省去基于 Rovo 的编码工作流这笔额外开支。
这并不意味着工作流中每个环节都免费。Jira 订阅、编码 Agent 套餐、API 消耗以及基础设施，仍可能产生费用。
开始之前需要准备什么
开始配置集成之前，请确保已具备以下条件：
- 拥有目标项目访问权限的 Jira 账号。
- Sharkly 账号。
- 已在某台电脑上配置好的编程 Agent，例如 Claude Code 或 Codex。
- 可以访问 Agent 将在其中工作的代码仓库。
- 连接 Jira 项目的权限；如有需要，可请 Jira 管理员协助。
无需把整个 Jira backlog 都迁移过来才能上手。先连接单个项目，用低风险任务试试这套工作流即可。
第一步：配置你的 AI 编程 Agent
直接用你已经在用的编程 Agent 即可，不必为了 Jira 集成专门换一个新模型。
比如你的开发机上可能已经装好了 Claude Code 或 Codex，只需确认它能访问目标仓库，且认证状态正常。
同时要验证 Agent 能完成所需的基本操作，例如：
- 阅读相关源码文件。
- 在指定工作区中修改代码。
- 运行项目测试。
- 报告错误或阻塞问题。
- 产出可供审查的代码变更。
这一步很关键：Sharkly 负责统筹协调，真正写代码的仍然是它所连接的编程 Agent。
如果你之前没配置过 Agent，可以先从官方文档入手：
- Claude Code
- OpenAI Codex
使用你有权限使用的服务商账号或 API 凭证即可。把 Jira 连到 Sharkly 并不需要更换新的模型服务商。
第二步：创建 Sharkly 工作区
接下来，打开 Sharkly 并创建你的工作区。
Sharkly 提供了一个共享环境，用于组织任务、分配 Agent、跟踪执行进度和审查结果。它的定位是配合现有开发工具使用，而非取代编程 Agent 本身。
工作区就绪后，连接一台可访问代码仓库的电脑，并确保其上运行着第一步中配置好的编程 Agent 运行时。
这里的计算机是指 Agent 实际运行所在的执行环境。根据你的配置，它可以是自己的开发机，也可以是其他受支持的计算机。
继续之前，请先确认该计算机可用，并且目标编码 Agent 的运行时已正确配置。
第 3 步：将 Jira 连接到 Sharkly
接下来连接你的 Jira 项目。
根据 Sharkly 的 Jira 集成文档，该连接支持 Jira Cloud、Jira Server 以及 Data Center。
对于 Jira Cloud，通常需要准备：
- Jira 主机地址，例如
your-company.atlassian.net。 - Jira 账户的邮箱地址。
- Atlassian API 令牌。
对于 Jira Server 或 Data Center，连接时需要提供 Jira 基础 URL、用户名，以及一种受支持的身份验证方式。
在 Sharkly 中打开集成设置，选择 Jira，然后点击连接 Jira 账户的选项。填入所需信息，并按提示完成验证。
请妥善保管 API 令牌。使用拥有目标项目访问权限的账户，并遵守所在组织的凭据管理规范。
连接账户并不会自动导入或同步所有 Jira 数据。你还需要自行选择项目和任务的对接方式。
第 4 步：将 Jira 项目关联到 Sharkly Space
连接 Jira 后，在 Jira 项目与 Sharkly Space 之间创建同步关联。
Space 是组织相应任务和 Agent 工作的场所。
设置过程中，你可以选择 Jira 项目、指定目标 Space、配置同步方式，并检查状态与用户的映射关系。
通常有两种做法：
方案 A：同步项目
如果你希望 Jira 与 Sharkly 在工作推进过程中始终保持联动，可以选择同步。根据配置的同步方向，已关联的问题和任务的受支持变更可以在两个系统之间流动。
方案 B：导入现有问题
如果想把 Jira 的历史问题复制到 Sharkly，比如测试工作流或规划迁移时，可以使用导入功能。
在设置过程中，你也可以导入已有工作并开启持续同步。
对于想继续使用 Jira 的团队，我建议先从单个项目加一条同步链路入手。这样团队无需迁移整个需求池，就能测试 Agent 的执行效果。
确认连接前，请先检查问题状态映射和用户映射。如果你的配置需要 webhook 权限，而你的 Jira 账号没有相应权限，可能需要 Jira 管理员来配置 webhook。
官方设置说明见这里：Sharkly Jira 集成。
第 5 步：为首个 Agent 任务选择一个 Jira 工单
项目连接完成后，选一个小而明确的问题。
我建议避免从"改进应用"这类模糊任务入手，也别选会影响生产环境安全、支付处理或关键基础设施的改动。
更好的选择是这样的：
- 为缺失的字段添加校验。
- 修复一个可复现的 UI 缺陷。
- 为现有函数添加单元测试。
- 更新一个独立组件。
- 排查某个测试失败的原因。
工单质量很关键。AI Agent 需要足够的信息，才能理解怎样才算成功。
例如，一份实用的工单可以这样写：
标题：为无效邮箱地址添加校验
描述：注册表单目前会接受格式错误的邮箱地址。请添加校验以拒绝无效格式，并显示清晰的错误提示。
验收标准：
- 拒绝无效的邮箱格式。
- 有效邮箱地址仍可正常使用。
- 错误提示易于理解。
- 测试覆盖有效和无效输入。
- 现有注册行为不发生意外变更。
验收标准写得越清晰，审查 Agent 的产出就越容易。
第 6 步：将工单分配给你的 AI Agent
Jira 项目连接后，关联的问题就会作为任务出现在 Sharkly 中。
接着你就可以把这个任务分配给已配置好的 Agent，就像把工作分给同事一样。
Agent 的配置决定了任务的执行方式，包括指令、运行时环境和可用资源。
举例来说，你可以把注册校验这类任务交给一个配置好使用 Claude Code 的 Agent。这个 Agent 可以查看相关代码仓库、实现改动、运行测试，并汇报完成了哪些工作。
同样的思路也适用于其他受支持的编码 Agent 运行时。
关键在于，Agent 拿到的是真实的任务上下文，而不是靠某人手动把工单内容复制到另一个对话里。
如果你是第一次运行，建议把范围控制得小一些，并确保 Agent 只能访问它所需的那部分资源。
第 7 步：让 Agent 在隔离环境中工作
任务分配完成、执行环境准备就绪后，Agent 就可以开始干活了。
Sharkly 为基于代码仓库的任务提供隔离工作区，包括基于 Git worktree 的执行方式。这能把并发的编码任务彼此隔开，避免它们直接覆盖对方的 working files。
当你以后想同时运行多个 Agent 时，这一点尤为重要。
想象一下你分配了三个互不相关的工单：
- Agent A 增加一条校验规则。
- Agent B 修复一个布局问题。
- Agent C 为另一个服务补充单元测试。
如果所有 Agent 都在同一个工作目录里改代码，改动之间就可能互相干扰。使用独立的 worktree 能把每个任务的改动隔离开，从而降低这种风险。
当然，隔离并不能解决所有集成问题。两个 Agent 的改动在合并分支时仍可能冲突，所以测试和审查依然必不可少。
执行过程中，你可以通过任务记录跟踪 Agent 的进展、查看相关输出，并发现阻塞点。
第 8 步：审查结果和 Pull Request
Agent 完成后，在接受改动之前先检查它的产出。
根据任务类型和配置的工作流，Agent 可能会汇报结果、说明改动了哪些文件、运行测试，或者创建 pull request。
如果你用 Sharkly 的 GitHub 集成，pull request 可以通过分支名、标题或描述中的任务 ID 关联到对应任务。
这样就能把编码结果追溯回最初发起的那条工作项。
在批准任何改动之前，我会检查以下几点：
- Agent 是否真正解决了 Jira 工单中的需求？
- 代码改动是否局限于预期范围？
- 相关测试是否运行并通过？
- 有没有意料之外的改动或依赖？
- 实现是否引入了安全、性能或兼容性方面的问题？
当改动至关重要时，不要轻信 Agent 声称“测试已通过”，而要亲自验证结果。
Pull request 仍应走团队正常的评审流程。Agent 可以产出初步实现方案，但代码能否合并发布，最终还是要由人来把关。
第 9 步：让 Jira 继续作为工作来源
这套工作流的一大好处是：团队不必放弃 Jira。
产品经理照常撰写需求，工程师照常划分 bug 优先级、规划迭代，QA 照常跟进问题的测试进度。AI Agent 可以协助实现选定的任务，团队对整个工作过程依然一目了然。
配置好同步链接后，受支持的变更可以在 Jira 和 Sharkly 之间流转，无需再为同一个任务维护两套完全独立的记录。
不过，团队仍有必要明确状态流转、pull request 评审和最终验收的处理方式。比如，除非你已显式配置相关的工作流，否则不应默认合并 pull request 就会自动关闭对应的 Jira 问题。
这样做的目标是把 Agent 的执行融入现有流程，而不是又多出一个彼此割裂的工作场所。
集成跑通之后，能自动化哪些事？
第一个任务成功后，你就可以逐步扩展这套工作流。
修复 bug
把可复现、验收标准清晰的 bug 分配给 Agent，让它们排查原因、实现修复并补充测试。
生成测试
让 Agent 为现有功能补充单元测试，或覆盖特定的边界情况。记得审查这些测试，确保它们真正验证了预期行为。
实现小型功能
对于范围明确的功能，Agent 可以阅读相关代码、完成改动，并提交 pull request 供人评审。
技术调研
Agent可以检查代码库、追踪故障、定位可能的原因，并整理出分析报告。即使你不打算让它改代码，这项能力也很有用。
并行处理工程任务
等团队习惯了隔离执行之后，就可以把相互独立的任务分派给不同的Agent。先从互不依赖的任务做起，再逐步提高并发程度。
并非所有任务都适合自动化。架构决策、需求不明确的改动、敏感变更以及生产发布，仍然需要人来深度参与。
到底能省多少时间？
最大的潜在收益未必来自模型成本的降低，而是省下了在各类工具之间来回切换、手动协调工作所耗费的时间。
设想一位开发者：他要把任务描述复制过来、打开编码会话、创建分支、盯着执行进度，每个任务完成后还要更新Jira——这些都在消耗时间。
打通之后的工作流可以减少其中不少重复步骤。
实际能省多少，取决于团队的任务量、Agent的可靠性、审查要求以及现有流程。不结合自身工作流去实测，就承诺固定的效率提升，只会误导人。
要评估这套方案是否值得，可以先跟踪以下几项指标：
- 从任务分配到产出可审查改动所需的时间。
- 每个任务需要多少手动准备工作。
- Agent任务中能产出可用结果的比例。
- 审查和修正Agent生成的改动所花的时间。
- 引入的缺陷数量或返工次数。
如果这些指标在质量不受影响的前提下持续改善，就说明这套集成发挥了作用。
这比直接用Rovo更好吗？
这取决于你想让Agent做什么。
Rovo在Atlassian生态内提供AI能力，包括搜索、对话和Agent功能。如果你希望AI直接对接Atlassian的关联知识和应用，它就是顺理成章的选择。
而如果你想用已有的工具（比如Claude Code或Codex）来处理代码仓库，单独搭建一套编码Agent工作流就更合适。
我是这样区分这两者的：
这些方法并不互斥。团队可以用 Rovo 处理部分 Atlassian 原生任务，同时用外部 coding agent 处理代码仓库相关的工作。
有一点需要留意：Atlassian 官方文档说明，通过外部工具（包括其 MCP server）发起的某些增强版 Teamwork Graph 调用会消耗 Rovo credits。如果你想避免额外的 Rovo 用量，请先确认你选定的工作流是否会调用这些消耗 credits 的服务。标准的 Jira 同步工作流和请求 Rovo 增强上下文的工作流，可不是一回事。
常见误区
给 Agent 分配模糊的任务单
需求模糊，实现往往也模糊。在派发任务之前，先写清楚验收标准，明确预期结果。
从高风险任务入手
先在小范围、可回滚的变更上测试集成效果，确认仓库访问、测试和评审流程都符合预期。
给 Agent 过高的权限
尽量使用独立的开发环境，避免暴露生产环境凭据或不必要的访问权限。
以为同步就意味着全自动
连接 Jira 并不会自动导入所有历史数据，也无法保证每个事件和状态流转都完全符合团队预期。请仔细检查同步设置并进行测试。
把生成的代码当作可上生产的代码
Agent 可能出错、误解需求，甚至引入回归问题。代码评审、测试和发布决策应始终由相关团队成员把关。
混淆免费协调与免费模型调用
免费的平台套餐未必涵盖 AI 模型的使用成本。请确认你的方案涉及哪些订阅、API key、基础设施和用量限制。
常见问题
能否在不购买 Rovo 额度的情况下，在 Jira 中使用 AI 编程 Agent？
可以。你可以接入外部编程 Agent 工作流来连接 Jira，完全不必调用 Rovo 那些消耗额度的 AI 功能。比如 Sharkly 可以把 Jira 任务对接到受支持的编程 Agent，这些 Agent 使用你已有的订阅或 API 账号。是否能避开 Rovo 额度，取决于你实际使用的集成和功能。
Sharkly 配合 Jira 使用免费吗？
Sharkly 公布的定价显示，10 人以内团队可以免费使用。模型的用量则由你为 Agent 配置的编程订阅方案或 API 账号承担。最新价格和条款请查看 Sharkly 官网。
必须把工单迁出 Jira 吗？
不必。你可以把 Jira 项目连接到 Sharkly Space 并配置同步。需要的话也可以导入历史 issue，但想先试用这套工作流的话，没必要迁移整个 backlog。
可以使用哪些 AI Agent？
Sharkly 支持多种编程 Agent 运行时，包括 Claude Code 和 Codex，以及其他受支持的环境。请确认你想用的运行时受支持，并且已在所连接的电脑上完成配置。
AI Agent 能根据 Jira 工单创建 pull request 吗？
只要运行时、仓库访问权限和工作流都配置妥当，Agent 就能实现任务并创建 pull request。借助 Sharkly 的 GitHub 集成，pull request 还能关联回对应任务。不过最终结果仍需人工审查。
多个 Agent 可以同时处理 Jira 工单吗？
可以，前提是配置得当。把相互独立的任务分给不同 Agent，并在隔离的工作区中运行，能减少相互干扰。但你也应考虑算力上限、Agent 用量、工单之间的依赖关系以及审查工作量。
结语
我认为，把 AI 引入软件开发最实用的方式之一，就是从团队现有的工作流入手。
如果你们团队已经在用 Jira 管理工作，那不一定非要换掉这套系统，也不必为了试用编程 Agent 再额外掏钱买一种 AI 计费模式。
只要把 Jira 连接到 Sharkly 这类工具，就能把选定的任务分派给现有的编程 Agent，让执行过程始终与原始任务挂钩，并在合并前审查产生的代码变更。
关键区别在于：Sharkly 负责协调工作，而编程 Agent 负责具体执行。模型调用仍然走你现有的订阅或 API 账号，结果的质量把关和最终验收也依然由你的团队负责。
我建议从一个小切口开始：选一个 Jira 项目、接入一个 Agent、挑一张低风险的工单。等工作流跑顺了，再根据团队的实际需要扩展到更多任务和 Agent。
这是一种务实的探索路径——在还没验证工作流能否创造价值之前，不必先在新的 AI 工具链上投入太多。
