从追踪到委派：Jira 的未来，是成为软件团队的“AI 调度层”

概要：我想看看，如果将 AI Agent 的能力映射到软件团队的各个职能中，会擦出怎样的火花。于是，我在 Jira 中构建了一支由专业化 Agent 组成的团队，将每个 Agent 分配给软件开发生命周期（SDLC）的一个阶段，并用它们为我的 Forge 应用开发了一个新功能。事实证明，这是我尝试过的最顺畅的开发工作流之一。

Jira 正在成为软件团队的“委派层”

长期以来，Jira 一直是您用来追踪工作的地方——更新状态、关闭工单。

而现在，随着 Agent 可以被指派到工作项中，情况发生了重大转变。Jira 依然是历史记录的档案库，但它现在多了一个新身份：一个让工作在人类与 Agent 之间流转的协作场所。

这种转变引发了我的思考：如果我彻底顺应这种趋势并进行一次实验会怎么样？如果 SDLC 的每个阶段都有专属的专业 Agent，并且看板本身负责在它们之间进行路由调度，结果会怎样？

我挑选了一个真实的功能，在 Jira 看板的每个阶段映射了一个专属 Agent，并让它们协同处理工作。实际情况如下。

项目：Launchpad

为了对这个工作流进行压力测试，我没有去搞另一个演示应用，而是选择了我正在开发的项目。

我一直在开发一款名为 Launchpad 的 Forge 应用。其核心理念是：在将想法付诸团队实际开发之前，我可以先与 AI Agent 一起梳理和打磨这个想法。

在这次实验中，我希望添加一个由 Teamwork Graph 驱动的上下文发现层。

目标很简单：在开始实现某个功能之前，我希望 Launchpad 能够自动浮现与之相关的组织上下文——相关的 Jira 工单、相关的 Confluence 页面、实现模式、已知阻碍，以及可能已经掌握该问题背景的人员。

这感觉是压力测试“可指派 Agent”的完美场景。它不只是一个单一的编码任务；它自然地拆分为研究、规划、实现和审阅，让每个 Agent 在工作流中都能扮演有意义的角色。

设计工作流

我的第一直觉是开始构建 Agent，但我很快意识到我的思路反了。我问自己：“如果这个功能是由一个小型软件团队构建的，那么自然的分工阶段边界会是什么样的？”这引导我划分出了四个阶段：研究→规划→实现→审阅。我更新了 Jira 看板以匹配该工作流，每一列代表 SDLC 的一个阶段，而不仅仅是另一个状态。

这个微小的转变改变了一切。看板不再只是一个追踪工作的地方，而变成了一个委派工作的地方。当工作项停留在某一列中时，该阶段就负责这项工作。

将 Agent 映射到看板列

定义好工作流后，我在 Studio 中创建了四个专职 Agent，并将其中的一个映射到 Jira 看板的各个阶段。这是我最期待尝试的部分。

我无需在每次需要帮助时手动调用 Agent，只需将工作项拖入新的列，就能自动将该阶段的工作流委派给分配给该列的 Agent。

在审查了输出结果后，我将其保存为 Jira 工单的评论，然后再推动工作向前发展。这些评论成为了 Agent 之间的共享上下文，为每个阶段提供了所需的信息，同时保留了沿途每个决策的记录。

从那时起，模式就很简单了：

• 看板决定所有权。

• Jira 工单保留上下文。

• 我来决定工作何时可以推进。

就在那时，这个工作流给我的感觉不再像是在使用 AI 工具。

它更像是在协调一支映射了软件团队角色的 Agent 团队。

创建第一个工作项

有了工作流和 Agent 团队，是时候给它们派活了。

我没有打开 Jira 手动创建工单，而是直接在开发环境中使用了 Rovo MCP，用一句话描述了该功能：“为 Launchpad 提供一个由 Teamwork Graph 驱动的上下文发现层，用于在实施开始前浮现相关的 Jira 工单、Confluence 页面和利益相关者。” Rovo MCP 将其转化为带有标题、描述和足够脚手架的 Jira 工作项，以此作为起点（我在[之前的文章]中更详细地介绍了该工作流）。

在构建此工作流时，我注意到的一件事是，它让我对如何描述工作有了更高的意向性和清晰度。

当其他工程师接手工单时，如果有什么不清楚的地方，他们可以提出后续问题。而 Agent 则更依赖于您预先提供的意图。这并不意味着我需要在工作流开始前写出一份完整的设计文档或定义每一个实现细节。这正是“研究”和“规划”阶段的作用。

但这确实意味着要为工作流提供一个清晰的起点：我想构建什么、它属于哪里、以及我试图达成什么目标。

在此之后，工作流的其余部分就可以各司其职了。

我将工单移至“研究”列，几秒钟后，研究 Agent 就接手并开始工作了。

推动工作在工作流中流转

自此，工作流变得出奇地简单。随着工单从一列移到下一列，每个 Agent 都会接手、完成其所在阶段的工作，并将发现结果留在工单上。我进行审查，将响应保存为评论，并推动工作向前推进。

有趣的是，它不仅能跑通，而且产出质量极高。

当工单进入“研究”列时，研究 Agent 开始着手处理该功能周围的组织上下文。我不用自己花时间翻找 Jira 和 Confluence，它就自动浮现了相关工作、实现指南、阻碍，以及在我编写第一行代码之前所需了解的背景信息。

整个“收集上下文”的阶段，在我喝杯咖啡的工夫就完成了。我审查了输出结果，将其作为评论保存到工单中，并将工单移至“规划”。

规划 Agent 从研究 Agent 停下的地方接棒，将这些上下文转化为具体的实施方案。我不再是给我的编码 Agent 一个模糊的功能请求，而是交出了一份经过研究、审查和结构化的计划。

自此，工作流遵循了相同的模式。实现 Agent 根据批准的计划进行开发，而 QA Agent 负责审查结果——我则负责在将工作移至下一个阶段之前批准每一次流转。

到最后，感觉不再像是在一堆 AI 工具之间反复横跳。

更像是在协调一个小型软件团队。

一旦工作流就绪，在软件开发生命周期中推动工作就变得像将 Jira 工单从一列拖到另一列一样简单。

改变了什么？

最让我感触深刻的并不是 Agent 速度有多快，而是模糊性大大减少了。

以往，我们带着一个粗糙的想法开始实施，然后在过程中边走边摸索；而现在，工作在每个阶段都变得更加精细。当它到达实现阶段时，编码 Agent 已经具备了所需的调研、上下文和实现方案。

这也改变了我的角色。

我不再需要到处追着找上下文，也不用琢磨下一步该做什么，而是转为审查决策、批准流转，并保持工作持续推进。

对我而言，这正是可指派 Agent 最有趣的地方。

它们并没有取代软件团队，而是为团队提供了一种结构化的方式来推动工作流转，同时让人们能够专注于人类的判断力，而不是收集信息。

亲自尝试一下

如果您一直在开发工作流中尝试 AI，请不要妄想在第一天就建起整支团队。

从一列开始。

挑选出最消耗您时间和上下文的工作流阶段。对于大多数开发者来说，就是编写代码之前的阶段——研究、规划或发现阶段——因为那里充满模糊性，也是跨阶段丢失上下文的重灾区。

然后只需做四件事：

1. 在 Jira 看板中添加代表该阶段的一列。

2. 在 Rovo Studio 中构建一个紧密围绕该阶段的专业 Agent。不要构建通用的助手，而是构建一个能把一件事做好的 Agent。

3. 将 Agent 分配给该列，这样它就会自动接手您移入其中的任何工作项。

4. 用一个真实工单跑通它。审查输出结果。不断迭代 Agent 的指令，直到您放心地将下一个阶段交托给它。

就是这样。一列，一个 Agent，一张工单。

一旦这个阶段运行稳定，再添加下一列。然后是再下一列。不久之后，您就会拥有一套这样的工作流：看板负责协调，Agent 负责专业工作，而您则在做您真正应该做的事情——审查、决策，并推动工作向前迈进。

重点不是去拼凑一支 Agent 团队，而是逐步改变工作在工作流中流转的方式。

这种模式不仅限于某个开发者或某个项目。任何基于 Atlassian 构建产品的团队——无论是内部团队还是 Marketplace 开发者——都可以组合使用这些基础组件：Jira 负责协调，Rovo Studio 负责 Agent，Forge 负责应用界面。您今天为自己的瓶颈构建的工作流，明天可能就会成为队友运行的工作流，或者成为合作伙伴在下个季度向成千上万客户交付的模式。