使用 Jira 开展智能体化工程
智能体化工程依托 Jira 运行。随着工程工作从编写代码转向管控人工智能支持人员，核心工作内容也随之改变。开发人员仅将约 16% 的时间用于编码；随着支持人员承担更多构建工作，真正棘手的工作都集中在周边事务：为支持人员提供上下文、编排支持人员、审查其输出内容，以及对支持人员开展治理。
这正是 Jira 一贯负责管理的工作，如今已拓展覆盖至支持人员。Jira 与 Teamwork Graph 是该类工作的记录系统，也是团队实现规模化时，将人工智能活动转化为实际生产力提升所必需的层级。
本指南介绍 Jira 如何支撑智能体化工程、它与您其他工具的适配关系以及上手方法。简而言之，Jira 可提供三项仅靠编码支持人员无法实现的能力：
为支持人员提供准确的上下文支撑，保障其执行行为精准
将常规工作委派至具备权限感知能力的自动化流程
在 Teamwork Graph 内留存可追责的记录
什么是智能体化工程？
智能体化工程是指通过指挥人工智能支持人员构建软件的实践：由支持人员规划并执行多步骤工作，而您设定目标、评判结果，无需亲自编写每一行代码。
这将改变您精力投入的方向：从编写代码转变为设计支持人员的运行系统。您指定所要构建的内容、为支持人员提供上下文、在其执行过程中加以引导，并判定输出内容是否达标。人工智能自动补全仅给出下一行代码建议，而单个支持人员就能够根据描述的结果一路生成拉取请求。智能体化工程则是更高一层：规模化编排多个支持人员、协调其工作内容，并管控最终交付成果。
这使得智能体化工程属于一项侧重协调与决策判断的工作，而不仅仅是编码工作。一旦支持人员承担编码或任务执行工作，其访问权限、操作以及输出内容都必须置于您团队现有可信管控体系之内。由此产生的各类问题首先属于工作管理层面问题，其次才是编码层面问题，这也是其需要依托 Jira 这类记录系统的原因。
Jira 是否专为智能体化工程打造？
Jira 专为原生人工智能软件开发打造，该实践用于对人工智能支持人员的各项工作进行规划、编排与规模化落地。当人们询问 Jira 是否“支持”智能体化工程时，其真正关切的问题是：Jira 能否作为这样一层平台，为支持人员工作提供上下文支撑，并对支持人员的工作开展协调、审查与治理。而这正是 Jira 所能实现的，单纯的编码支持人员却做不到这一点。
编码支持人员负责编写代码变更，但无法决定应当构建什么、判断成果是否达标，或是考量该项工作与其他正在推进事项之间的关联。以上这些都属于工作管理与团队决策范畴：运行在单人设备上的编码支持人员仅可为该人员服务，而由人员与支持人员组成的团队，则需要共享协作机制、可见性以及单一事实来源。Jira 承担这一层职能：保存计划、将工作分派给合适的支持人员、保障人员掌控最终交付内容，并留存完整操作记录作为持久上下文，用以指导后续工作。该过程随工作在 Jira 内流转发生，无需开发人员执行额外操作步骤。
相较于单独使用编码支持人员，Jira 额外提供了什么能力？
即便为编码支持人员提供一份真实规格说明，它依旧有可能偏离目标。它会遗忘过往决策、重复执行已完成的工作，并且受自身上下文窗口的限制。将计划存放于 markdown 文件并不能解决该问题，升级更优秀的支持人员同样于事无补。解决方案是搭建一套将规格说明与状态保管于支持人员内存之外的系统。该问题在团队环境中会愈发严重，因此智能体化工程本质上是记录系统的选型问题，而非编码工具的选型问题。下文所列能力，正是 Jira 作为这套记录系统所自带的功能。
连接器将您的工具链接入 Teamwork Graph。MCP 将该组织记忆推送至团队已在使用的各类人工智能。
一套涵盖人工于支持人员工作的统一记录系统。当支持人员开展工作时，它可读写 Teamwork Graph，更新任务相关的每一项决策与记录，避免上下文信息因本地会话结束而丢失。
治理继承您现有的企业管控措施。支持人员的访问权限沿用企业已经信赖的权限模型，因此这些管控机制将自动延伸至支持人员工作，无需搭建一套全新的治理体系。
任意智能体、任意模型，统一操作界面。您可将工作分配给 Claude、Cursor、Codex、GitHub Copilot 或是 Jira 原生编码支持人员，并在同一平台上完成编排。由于支持人员在您现有的工作流内运行，即便变更支持人员，工作流也不会改变。单一编码支持人员会将您锁定至某一供应商；而 Jira 则与支持人员无关。
从完整技术栈开展上下文工程，而并非只依靠工作单。Teamwork Graph 让支持人员可以依托 Jira、Confluence、代码，以及 Slack、Teams 这类实际开展工作讨论的工具中的工作项、决策与历史记录开展工作，因此支持人员能够按照任务的真实意图执行操作，而非仅凭一条空白提示词行动。这就使 Jira 成为围绕支持人员的上下文支撑层。
它为您提供管控支持人员工作的统一管控中枢。编码支持人员会在独立会话中运行，本身与计划以及团队其他工作相互隔离。Jira 补上了这一层能力，以决定支持人员承接哪些任务、为其提供恰当的上下文信息，并将每一次编码会话与其产出的工作关联起来，同时不会给开发人员增加额外操作步骤。记录系统负责留存已经发生过的事情，而管控中枢则是您在后台指挥、串联支持人员工作的手段。
Jira 在原生人工智能软件开发生命周期中的定位
Jira 在四个阶段为支持人员工作提供支撑：规划、编排、审查和规模化推广。您将工作规划为可供支持人员执行的工作项，编排支持人员完成任务，对其产出成果进行审查与测试，并依托管控和权限保障安全，在整个组织内规模化推广此类工作模式。下面介绍 Jira 在每一阶段承担的工作。
计划：如何让工作可供支持人员执行？
一键将计划与文档转化为建议工作项，随后按需审阅和调整，然后再接受。
规划就是将意图转化为可供支持人员执行的工作：一份包含清晰需求与验收标准的正式规格说明，外加支持人员开始工作前所需的全部上下文信息。
无论工作始于何处，都能将其记录。请求可能来自任何地方：Slack 讨论串、Confluence 页面、Loom 录制视频、会议。您可以提及 @Jira 或者使用 Rovo，就位将这些内容转化为工作项。这种需求承接能力的价值远不止省去重复录入文字；它能够把模糊的请求（哪怕最初只是一段对话）转换成一条工作项，并且借助 Teamwork Graph 附上相关上下文，标明该项任务如何适配团队的整体工作。
为支持人员提供清晰定义的规格说明，而不仅仅是一条提示词。在规格说明驱动的开发模式下，规格说明是核心输入：支持人员依据规格说明处理工作项，而不是依靠会话结束后就失效的一次性提示词。这份规格说明可与代码库、团队标准以及项目历史记录配合使用，因此支持人员能够获得所需上下文，以编写出符合团队标准的代码。Jira 规划器可以依托 Teamwork Graph、您的代码库以及 Confluence 历史记录生成一份规格说明初稿，随后您再细化打磨、补充验收标准，最终这份规格说明就成为支持人员的开发依据，同时也是成果审查时的评判标准。
为支持人员提供不断积累的上下文信息。上下文才是决定支持人员产出质量的真正制约因素。Jira 依托 Teamwork Graph，让支持人员能够基于各类工具中的目标、决策与历史记录开展工作，而不仅仅局限于工作单。它适用于任何 MCP 支持人员，并且上下文能够不断累积：经由该系统处理的工作越多，可供支持人员调取参考的信息就越丰富，最终产出效果也就越好。
编排：您如何为支持人员分配和指挥工作？
在统一位置为支持人员（包括原生 Jira 编码支持人员）分配工作。
将工作分配给最适合执行该项工作的支持人员，随后对支持人员的工作进行指挥与监督，而所有操作均可在团队日常跟进工作的平台上完成。
在统一位置向任意支持人员分配工作。您可以将工作项分配给 Claude、Cursor、Codex、GitHub Copilot 或是原生 Jira 编码支持人员，之后便可查看该支持人员在网页、IDE 以及终端会话中执行的操作与做出的决策，以便您及早发现执行偏差并予以纠正，且不会打断流程。
在您日常工作的环境中与支持人员协同开展工作。依托团队正在使用的各类操作界面完成编排：您可以在 Slack 中 @Jira，以创建工作项并启动缺陷修复闭环；将 Cursor、Claude Desktop 或任意 MCP 客户端接入 Jira 的上下文；或是授予支持人员 CLI/终端访问权限，使其能够基于上下文直接开展行动。
自动化处理常规工作。您可以通过自动化规则或工作流流转触发支持人员（也可将支持人员添加至面板列），使其在任务状态变更时自动承接工作，并将产出成果沿原有工作流回传。常规、重复性工作是启动支持人员自动化的最佳切入点。
支持人员活动保持可见，且与工作绑定。支持人员执行工作期间，它的活动以及所创建的拉取请求都会关联到对应的工作项，这样工作进度就可以在工作所在页面直接查看，而不会被埋没在其他独立工具中。您可以在统一界面查看每个支持人员承接了哪些任务、产出了什么成果，以及哪些内容待审查。
审查：如何验证支持人员的产出成果？
审查支持人员输出内容应包含人工介入环节。
支持人员的产出成果看似已经完成，实则仍有可能存在错误，因此输出必须经过人员审查、测试并签字确认之后，才可以交付。
测试与验证。支持人员的产出成果仍需通过常规检查。这些检查会在您的 CI 管道中执行，检查状态会展示在工作项上，因此审查环节可以阻止流转至已完成状态，直至完成工作验证。您可以将该流程的一部分自动化：由支持人员先对自己的产出成果执行检查，并不断迭代直至检查通过，之后再交由人工审查。
人工介入审查，内置于您的工作流中。需要人工主导的审查：产出成果会展示在工作项上，未经人员审批，无法流转至“已完成”状态。拉取请求及其审查状态会显示在工作项的开发面板中，审查工作便可直接在任务跟踪的位置完成。
合并并记录已交付的内容。审查通过后，变更完成合并，工作项流转至“已完成”状态。合并与部署操作在您已接入的工具中执行，而由 Jira 留存记录。
规模化：您如何长期、安全地在多个团队中运行支持人员？
统一 System of Work 有助于在组织内实现更成功的规模化拓展。
支持人员工作的规模化落地属于组织层面的转型。其难点并不在于单个开发人员运行更多的支持人员，而在于当支持人员工作逐步推广到各个团队时，能够稳定保障成果质量、建立信任以及保持过程透明可见。
委派常规工作。支持人员在后台处理重复发生、范围清晰明确的工作，就绪后拉取请求便呈现。您可通过统一的权限与安全配置始终掌握管控权。
迭代。智能体工程是闭环，而非单向流程：产出结果会反馈到下一份规格说明，工作重新进入生命周期。Jira 负责留存这些反馈信息，以便后续工作得以优化。
治理与审核。护栏存在于工作流中，而非仅仅写在政策文档中，所有操作都会在工作项上留下可审计记录，并且由 Jira 自身的权限机制进行把关。
衡量影响。借助周期时间、拉取请求吞吐量等交付数据，跟踪人工智能给团队交付模式带来的改变，从而让您能够衡量最终成果而非仅关注活动，并把资源投入到最有价值的地方。
Jira 如何与人工智能技术栈的其他组件协同？
Jira 并不会取代您的编码支持人员、IDE 或是所运行的模型。它是横跨其上的协调与记录层，无论由哪些工具负责开发工作，工作均保持可见、可管控。在规模化场景下，该层不可或缺；若缺少统一的记录系统，支持人员的工作就会分散割裂在各个工具之中，生产力也就无法完全落地。
主题 | Jira 负责实现（协调与记录层） | Jira 不负责实现（由您技术栈中的其他组件承担） |
规划 | 为支持人员规划、拆解工作并划分优先级（Jira 规划器） | 无需设定目标（人员决定任务内容与原因；Jira 将其转化为计划） |
上下文 | 依托工作项与 Teamwork Graph，为支持人员提供上下文 | 无需额外部署独立的上下文存储库或向量数据库（Teamwork Graph 即为托管式上下文层） |
编排 | 借助自动化、工作流流转与任务分配，将工作分发至适配的支持人员，并指挥、监督支持人员执行 | 不提供支持人员实际的运行环境（由支持人员自身平台提供；Jira 编码支持人员则运行于 Atlassian 沙盒） |
模型 | 保持模型无关性，可在统一位置指挥任意受支持的支持人员（模型由 Atlassian 的人工智能网关进行管理） | 不托管模型（Atlassian 的人工智能网关负责路由，可对接 Atlassian 托管模型、供应商模型或自带密钥模型） |
审查与质量管控 | 将产出成果送入审查与审批流程，生成可审核、受权限管控的操作轨迹 | 不保证产出成果无误，也不直接编写代码（人工负责审查与测试） |
团队协调 | 在统一共享系统中协调全团队工作，保证人员与支持人员基于同一事实来源开展工作，并且通过交付数据（周期时间、吞吐量）衡量影响 | 不执行具体编码工作（编码任务交由编码支持人员与 IDE 完成） |
依赖关系 | 梳理跨团队、跨服务的工作关联关系，让支持人员在交付前获知变更所带来的影响范围 | 不分析代码库的技术依赖关系（由 IDE 与构建工具完成） |
如何在 Jira 中开展智能体工程
查看支持人员执行的操作及其作出的决策。查看完整会话历史记录，尽早发现偏差，并按需进行纠正。
您无需一次性全面铺开，便可着手启动。最快速的首个落地成果，就是接入一个编码支持人员，为它分配一项小型任务，并且审查它所创建的拉取请求，所有操作都在单条工作项内完成。
选择一项常规且范围明确的任务。不稳定测试、依赖版本升级或是小型缺陷修复，都是最稳妥的入手方向。
将其记录为工作项。您可以把 Confluence 页面、Slack 讨论串或是一段简短提示词转换成工作项，并填写摘要与描述。
将其分配给支持人员。连接您的 Git 存储库，然后从“支持人员”面板将工作项分配给 Jira 编码支持人员。
审查拉取请求。支持人员会创建一条与该工作项关联的拉取请求，您便可在原先规划任务的位置完成审查。
实现自动化。完成首次运行后，找出您反复执行的任务，将其转化为自动化规则。重复性工作属于回报最高、风险最低的起步工作。
想要快速上手？只需完成一次配置，智能体工程模板便可搭建好可供支持人员运行的空间，预置好工作流、状态以及支持人员步骤，以便您可以直接基于一套可用的闭环流程开展工作，无需从零创建空白项目。如果您已经在某个空间稳定运行智能体工作流，付费版客户可将其保存为自定义模板，这样您的团队新建空间时，便可直接复用已经配置好的支持人员与工作流。
智能体工程常见问题解答
工程师在智能体工程中承担什么工作？
智能体工程师负责设定目标、背景信息以及护栏，以此引导人工智能支持人员完成多步骤任务，之后再对产出结果进行审查与审批。由 Jira 这类记录系统保障整个过程的协同推进与责任追溯。
提示词工程与智能体工程之间有什么区别？
提示词工程是编写单条指令，以此获得理想的模型回复；智能体工程则调度支持人员，让其针对完整任务规划、执行操作并且循环迭代。工作单元从一条提示词转变为一个目标。
相较于单独使用编码支持人员，Jira 额外提供了什么能力？
编码支持人员负责编写代码，而 Jira 作为统一的记录系统，承担任务定义、优先级划分、编排、审查以及治理工作。它能够协调任意支持人员，同时留存可审核追踪记录，并且每一条记录都与对应的工作项相互绑定。
人工智能支持人员如何从 Jira 获取上下文信息？
支持人员从工作项本身（需求与验收标准）以及 Teamwork Graph 中提取上下文信息，Teamwork Graph 将关联任务、文档和代码关联起来。这使得支持人员在执行任务之前就具备背景依据，而不仅仅依靠提示词开展工作。
如果由人工智能编写代码，您还需要 Jira 吗？
需要，甚至可以说更加离不开。随着支持人员更快、更多地产出代码，限制因素就转移到工作协调、审查与管控上来。Jira 作为管控中枢，让支持人员生成的内容可视、责任可追溯，并且和它所要完成的工作项绑定。