Atlassian AI 战略：从编码工具到全生命周期编排
Atlassian 的 Andy Wong、Shane Wolf 和 Andrei Bocan 在 AI Engineers World Fair 工作坊中，深入探讨了 Agentic Systems（智能体系统）如何彻底改变软件开发生命周期（SDLC）。Andy Wong 指出，随着 AI 编码工具的普及，单纯的生产力提升边际效应正在递减。因此，Atlassian 的战略重心转向了代码编写之外的环节，即“everything left and right of code”（代码左侧与右侧的所有事务）。> “As time kind of goes on, you can kind of see that as we have more AI coding tools... productivity gains from those tools are kind of tapering.” 这意味着未来的机会在于规划、编排、代码审查流程以及运维操作等更广泛的领域。为此，Atlassian 在过去一年半中开发了包括 Teamwork Graph、AI Planner、AutoDev、Reviewer 以及核心的 AI Context Machine 在内的多种智能体工具，旨在构建一个更 holistic（整体化）的开发环境。
Jira Coding Agent：深度企业上下文与多智能体协作
本次演示的核心是 Jira Coding Agent，这是一个原生嵌入 Atlassian 生态系统的编码智能体。它具备深度的企业上下文理解能力，能够读取 Jira Ticket、Confluence 文档、邮件以及 Slack 消息，从而规划并实施特定的 Jira 任务。> “It is a deep enterprise context agent that has a deep understanding of everything within the Atlassian ecosystem.” 该智能体不仅能在 Jira Cloud 环境中直接交互和编辑 Pull Request，还支持灵活的代理分配机制。如果用户偏好其他工具如 Claude、Cursor 或 CodeEx，也可以将 Jira Agent 的任务指派给这些外部智能体执行。此外，Atlassian 还提供了 SDLC 自动化功能，当满足特定条件时，系统可自动生成代码。这种设计允许团队在保持工作流连贯性的同时，选择最适合自身需求的智能体组合进行协作。
AI Reviewer：降低噪音与提升审查质量的数据实证
在代码右侧的自动化环节，Atlassian 推出了 AI Reviewer，旨在超越传统的代码检查。它不仅审查代码本身，还检索 Jira、Confluence、SCM 以及 Slack 中的上下文信息，以提供全面的审查意见。针对代码审查中常见的“噪音”问题——即过多低价值或过度挑剔的评论，Atlassian 训练并过滤了特定模型来剔除这些无用信息。> “We are trying to reduce the amount of noise that comes from the code review process as a whole.” 这一举措显著提升了审查质量。根据内部数据，经过模型过滤后的评论解决了约 40% 的问题，这一数字非常接近人类基准的 45%。Atlassian 还通过仪表盘实时监控工具价值，展示智能体运行的审查数量和代码覆盖率，帮助管理者量化 AI 在 DevOps 空间中的实际贡献。
标准化与自动化：跨平台实施统一工程标准
除了智能体协作，Atlassian 还致力于解决团队在代码仓库中实施统一标准的痛点。通过 Standards 功能，管理者可以更轻松地在所有 Pull Request 中强制执行特定的工程规范。这一功能具有高度的兼容性，支持 GitHub、GitLab 和 Bitbucket Cloud 等所有主要 SCM 平台。> “Every team, every organization kind of has their own standards... we are trying to make it a lot easier for managers, software engineers to implement those standards.” 结合 AI AutoDev（自动开发）功能，系统能够遍历 Jira Board，自动化处理从需求到代码生成的流程。这些工具共同构成了一个闭环，不仅提升了编码效率，更通过自动化审查和标准化实施，确保了软件交付的质量与一致性。
AutoDev：Jira 生态内的自动化开发工作流
AutoDev 的核心能力在于能够识别哪些工单可以自主运行，并在 Jira 生态系统内部完成从应用标准规范到创建待审查 Pull Request (PR) 的全过程。这一流程完全可由用户配置，包括设定每月使用的最大积分上限、每个用户运行的自动开发工单数量限制等。此外，管理员可以指定在特定仓库或组织内所有仓库中运行 AutoDev。
为了提供透明度，系统内置了仪表盘以展示 AutoDev 的运行状态、待审查的 PR 数量以及故事审查需求。工程师和团队可以通过丰富的元数据全面了解 AutoDev 的整体表现。同时，AutoDev 已与 Slack 集成，一旦在仓库中启用，它将根据可用性和投入产出比 (ROI) 洞察开始处理特定工作项。Atlassian 致力于尽可能多地衡量 AutoDev 带来的整体 ROI，以量化其价值。
"All of that is triggerable within the Jira ecosystem itself."
AI Incident Response (AISR)：智能故障诊断与根因分析
针对凌晨 2-3 点发生的棘手事故，AI Incident Response (AISR) 旨在从 Jira、Confluence 等历史数据中抓取上下文，进行根因分析并提供修复建议。该系统同样集成于 Slack 之中，用户可获得事故影响的快速摘要（如是否影响外部客户）以及详细的缓解步骤。
AISR 不仅提供根因分析，还会给出多种可能的修复理论。通过整合上下文信息，AISR 帮助团队在事故再次发生时快速定位问题并执行缓解措施。这体现了 Atlassian 对“上下文”重要性的强调，即通过聚合分散的信息来增强智能体的决策能力。
"AISR aims to do is try to grab all that context again... and provide suggestions of how to remediate the specific incidents."
AI Context Engine：构建标准化的上下文引擎
Atlassian 正在构建的“AI Context Agent”旨在解决大型单体仓库中上下文分散的问题。该引擎通过语义代码搜索，将 Jira、Confluence 以及第三方工具（如 Notion、Slack）中的数据连接起来，形成标准化的上下文供智能体使用。这一年的核心战略是尽可能抓取所有上下文，为未来的智能体构建强大的引擎。
在架构上，Atlassian 内部使用图数据库连接客户产品中的数据（如 Jira 工单与 Confluence 规范文档的关联），并支持显式或隐式的连接推断。所有工具正朝着插件化方向发展，工程师可将其轻松添加到浏览器、IDE 或 CLI 中开箱即用。这种设计旨在降低使用门槛，提升开发效率。
"We're trying to grab all the context as possible and try to create a really powerful engine for us to power our agents in the future."
现场 Workshop：Jira Coding Agent 体验与技术支持
演讲最后介绍了现场的互动环节，参与者将获得一个特定的账号号码用于登录 Jira Coding Agent 进行体验。由于现场 Wi-Fi 出现波动，技术人员正在协助解决网络连接问题。演讲者利用等待时间开放问答环节，讨论产品路线图、可用功能及工作流偏好。
在回答关于 Context Engine 的提问时，演讲者进一步解释了其底层逻辑：通过图数据库连接 Atlassian 产品数据（Confluence, Jira, Bitbucket），并整合第三方工具，形成上下文网络。这种连接既可以通过产品使用中的推断实现，也可以通过显式链接（如工单关联文档）建立。最终目标是利用语义搜索技术，为各类智能体提供统一且丰富的上下文支持。
"We have a number of graph databases inside of Atlassian that connect to all the data... wrapped into this whole tapestry of context."
动态上下文获取与单体仓库的权衡
在构建 AI 编码代理时，从其他团队或组织内部的其他项目中拉取上下文至关重要。例如，当某位开发者（如 Shane）专注于 Wi-Fi 连接性工作时，系统需要自动整合与其相关的平台文档和其他影响该模块的组织级举措。Atlassian 通过引入 Code Context Engine（代码上下文引擎），将这些分散的信息实时注入到当前的代理编码会话中。这种做法解决了传统单体仓库（Monorepo）策略的痛点：虽然单体仓库能让代理随时访问所有代码，但往往伴随着沉重的技术债务和缓慢的开发速度。过去团队倾向于建立单体仓库以确保上下文可用，但这导致大量时间被消耗在构建配套工具上。通过代码上下文引擎，团队可以保持产品仓库的独立性，只需在 Hawk 平台接入该引擎即可实现极速的代码级访问。
这种架构的核心优势在于代码即真理。相比于 Confluence 文档仅是对某一时刻的静态快照，代码反映了最新的逻辑状态。通过高吞吐量的搜索语义访问最新代码，避免了因信息过时导致的错误。这种动态拉取上下文的方式不仅提升了效率，还消除了维护单体仓库所需的复杂工具链负担。
"Historically we've seen a lot of teams try to do like opt for monor repos in order to have all their agents like have the context available at all times that has some shortcomings... You spend a lot of time building tooling to build the thing."
冲突解决与人类在环的权威性验证
关于如何解析代理生成的代码冲突，Atlassian 的观点是：目前尚无全自动的完美解决方案，核心在于“人类在环”（Human-in-the-loop）的验证机制。随着 AI 代理从多种来源推导知识，最终需要人类确认哪些信息是真实的、适用于特定案例的。如果将上下文缓存（Snapshot），则面临数据过时的风险；而实时生成上下文虽然保证了信息的最新性，但引入了复杂性。因此，Atlassian 采取的策略是赋予人类更高的权威性：由人来判断哪些内容具有更高可信度，特别是对于 Jira 工作项等复杂场景。
自动化虽然能处理部分逻辑，但存在风险：如果自动生成的内容被误认为是权威真理，可能会导致错误的决策。因此，他们更倾向于让人类介入验证过程，确保代理生成的代码符合业务逻辑和真实需求。这种模式虽然增加了人工干预的成本，但有效避免了自动化带来的“虚假权威”陷阱。在 AGI 到来之前，人类的判断力仍然是解决上下文冲突和验证正确性的关键。
"At the end of the day, you need a human to tell like yes, this is actually true... You can end up in that same situation [where automated things become authoritative]."
Jury Coding Agent 的验证与测试环境搭建
在讨论需求验证时，Atlassian 介绍了 Jury Coding Agent 的工作流程：每个 Jira 工作项都包含明确的验收标准（Acceptance Criteria）清单。当代理生成代码时，它会在一个完整的沙箱环境（Full Sandbox）中运行。该沙箱允许代理安装依赖、执行代码并直接操作特定仓库，从而自动验证生成的代码是否满足预设的验收标准。这种沙箱机制确保了代理可以在隔离且可控的环境中完成自我验证，提高了代码交付的质量。
为了让观众亲身体验这一过程，Atlassian 提供了测试环境。参与者需使用分配的账号登录 Alaskan University（可能是内部测试域名或笔误，原文如此），并通过 Confluence 页面访问 Jury Workspace。Atlassian 还提供了一个名为 “Atlassian Swag” 的 Bitbucket starter repository，供用户直接在 Jira 生态系统中与代理互动。尽管现场遇到了 Wi-Fi 连接问题，但 Atlassian 强调通过优化流量和解决网络瓶颈是确保 AI 代理流畅运行的基础。
"The way that the jury coding agent runs is like it has a full sandbox. It can install things, it can run things... So as long as you have the acceptance criteria... it'll go in and like verify those specific things."
Atlassian 沙箱环境与 API 密钥管理机制
Atlassian 提供的开发环境是一个基于容器的专有沙箱（Sandbox），目前用户尚无法自行引入外部容器，但该平台已启用 Docker 支持，允许开发者运行所需的各类工具。在计费与模型接入方面，系统采用按量付费（Pay-as-you-go）模式。开发者可以使用自己的 API 密钥连接 Anthropic、OpenAI 等模型，也可以利用 Atlassian 提供的信用额度（Credits）进行消耗。这种机制允许每个智能体灵活指向不同的后端服务，无需强制绑定特定模型。
"Uh right now you can use uh so the billing is through Atlassian credits currently... Uses an API key so it uses your own API keys."
关于模型支持范围，Juror Coding Agent 目前明确兼容所有 Anthropic 和 OpenAI 的模型。对于 Google Gemini 等其他模型的支持情况，演讲者表示记忆模糊但倾向于认为云服务和 OpenAI 兼容是主要保障。这种架构设计旨在提供高度的灵活性，让团队根据任务需求选择最合适的模型组合。
信用额度报告与 ROI 监控现状
在企业管理视角下，AI 信用的使用追踪目前仅细化到具体产品体验层面。例如，系统可以记录特定用户在使用 Jira 的 Juror Coding Agent 这一具体功能时的信用消耗，但尚不支持基于测试用例或更细粒度任务的报告。演讲者指出，随着更多人使用代理式编码（Agentic Coding），确保投资回报率（ROI）变得至关重要。管理层需要监控是否存在异常情况，例如某项任务消耗了数十亿 Token 却未产生预期价值，从而防止资源浪费或边缘化进程失控。
"as we have like more and more people using uh agentic coding you want to make sure that like the ROI is there... spend like I don't know uh 1 billion tokens on a thing then you want to ensure that is something that you actually want to have done"
目前，团队正在开发更精细的报告功能，以解决多体验场景下的信用分摊问题。未来的目标是将报告粒度从“产品级”进一步下钻，以便更准确地评估每个开发任务的实际效能与成本效益。
模型路由策略：手动选择 vs. 智能调度
关于模型路由（Model Routing），当前的 Juror Coding Agent 允许用户在顶层手动选择要使用的模型。此外，通过定义“技能”（Skills），开发者可以为特定任务指定特定的子代理或模型配置。然而，目前系统尚未实现智能路由（Smart Routing）功能。演讲者明确表示，自动根据任务复杂度或历史成功率动态选择最优模型的功能仍在开发中。
"Uh we currently don't have anything out uh that would do be doing like doing smart routing. That is something that we're working on... to help you essentially figure out oh this specific task this is a high cool level. We've seen success with it"
未来的 AutoDev 计划将引入智能路由机制，通过分析任务指标和历史成功数据，自动推荐或强制执行特定的模型策略。这种演进旨在从“人工配置”转向基于数据的自动化决策，从而优化开发效率并降低试错成本。目前的工作流仍依赖于开发者对技能与模型映射关系的预设。
演示环境访问与安全注意事项
为了便于参会者在 Wi-Fi 恢复后继续体验，Atlassian 将保持演示站点开放至 AI AIS Fair 结束。访问地址为 1-ish-devo.atlassian.net，登录凭证使用参会者的学生编号作为用户名。演讲者特别强调了数据安全与隐私保护。由于演示环境的安全级别较高，但并非生产级隔离，开发者被强烈建议不要输入任何敏感信息。具体而言，严禁在演示环境中提交类似 GitHub Gist 或 Bitbucket Snippet 中可能包含的代码片段、密钥或个人数据。
"keep that in mind as you're kind of adding stuff to and messing around with all these things... don't put in anything that you wouldn't be comfortable putting on a GitHub gist somewhere"
这一警告旨在防止数据泄露风险。参会者在探索不同工具和功能时，应仅使用虚构或脱敏的数据进行测试，确保在享受技术演示的同时遵守基本的安全规范。
清理过时上下文与权威性的平衡
在大型组织长期使用 Atlassian 等工具积累大量数据后，如何清理“陈旧上下文”（stale context）成为关键问题。如果保留十年前的文档，AI 代理在检索答案时可能会优先抓取这些过时信息，导致回答不准确。Atlassian 的经验表明，系统倾向于偏好较新的结果，这在一定程度上缓解了陈旧数据的影响。然而，如果某份十年前的文档依然是“尖刀”（tip of the spear），即当前最权威、最常用的指南，系统需要一种机制来识别其权威性。
为此，Atlassian 引入了“验证徽章”（verified badge）功能。这一机制旨在内部标记那些仍然代表最新、最佳实践的文档。通过这种方式，系统可以在检索过程中给予这些经过验证的上下文更高的权重。正如演讲者所述：
"that's basically the thing that we use internally to say like yes cool this is like still the latest and greatest and that this context should be favored"
这种设计确保了 AI 在提供答案时，既能利用最新的信息流，又能尊重那些经过时间考验的核心权威知识。
大型组织的组织级重构与 Agent 角色定位
在大型企业环境中，存在大量相似的服务实例（如从某一版本 Rails 迁移至另一版本），这种组织级导航 (Organizational Steering) 场景是 AI Agent 发挥巨大价值的领域。以拥有 10,000 个服务的组织为例，由于学习曲线、记忆机制和工作流高度相似，工程师无需深度介入每一个具体任务。理想的模式是：Agent 自主完成代码生成和 PR（拉取请求）的创建，而人类仅负责协调工作。这种分工旨在减少工程师在重复性迁移工作中的精力消耗，将 Agent 视为推动大规模技术演进的关键机会。通过集中化处理这些相似任务，组织能够显著降低人力成本并加速标准化进程。
自主工作流的可见性、成本控制与需求规范
当 AutoDev 等工具在团队背后自主工作时，透明性与干预机制至关重要。工程师必须能够实时知晓 Agent 的行为，并在其分配错误或偏离目标时进行干预。Jira Board 作为团队日常关注的核心界面，是展示这些自主工作进度的主要载体。同时，必须设置在制品限制 (WIP Limits) 以防止团队被大量 PRs 淹没，导致注意力分散。此外，成本控制已成为当前企业关注的重点（Table Stakes），管理者需要为 Agent 设定明确的预算上限，例如每个工单 (per ticket) 或每周 (per week) 的支出限额，以防止资源浪费。对于积压需求中描述模糊（如仅有一行摘要）的任务，系统无法直接执行，必须引入人在回路 (Human in the Loop) 机制。人类需介入澄清目标并完善需求规格，只有当规范达到足够高的详细程度 (large good level of specification) 时，Agent 才能开始实质性工作。
解决审查瓶颈与 AI Planner 的可行性分析
在自主开发流程中，代码审查 (Reviewing) 往往是导致工作停滞的瓶颈。为了解决这一问题，Atlassian 正在构建系统以在适当时机主动联系相关人员（初期主要通过 Slack），请求快速评估是否合并或废弃。与此同时，Atlassian 推出了 AI Planner，主要面向项目经理和技术负责人，用于评估现有代码库中实现新功能的可行性。AI Planner 通过上下文引擎分析仓库现状，判断想法是否可行；若可行，它将提供具体的实施分解 (breakdown) 和多种执行路径。这一工具帮助管理者在投入开发前确认技术可行性，避免盲目启动项目。
上下文引擎与 Code Chat 的技术架构
Atlassian 内部拥有 15,000 个代码仓库，面对“某功能在哪里实现”或“哪些服务依赖此组件”等复杂查询时，传统的搜索方式效率低下。上下文引擎 (Context Engine) 的核心在于缩小检索和搜索空间，精准定位答案最可能存在的代码区域，并深入挖掘以回答问题。此外，该系统还整合了团队协作图中的信息。鉴于历史文档往往过时或不准确，仅依赖文档搜索会导致错误结果；因此，上下文引擎结合代码实际状态与协作关系图，提供了比单纯文档搜索更可靠、更具时效性的技术洞察。
Context Engine：利用历史决策上下文赋能 AI 规划
Context Engine（上下文引擎）的核心理念在于保留代码在特定时间点的决策历史。虽然这些历史信息随时间推移可能不再直接适用，但它们对于理解“为什么当时这样决定”至关重要。通过利用现有的代码库以及过去决策的历史背景，团队可以在未来的实施路径或规划中获得有价值的指导。Context Engine 本质上是一种代理式搜索（agentic search），它帮助开发者避免重蹈过去的覆辙。
"Historical information about why decisions were made are something that's often left out of agent generated code, but it's really important historical context for like not remaking mistakes of the past."
目前，AI Planner（AI 规划器）大量利用这一能力来构建新功能。当尝试确定如何构建某项功能时，AI 可以查阅相关项目文档及上下文。TeamGraph CLI 是暴露这些能力的主要接口，它拥有访问所有代码上下文技能的权限。虽然 AI Reviewer 目前较少使用此引擎，但团队正在实验将其整合进去。
Robo Chat 与代码上下文的深度融合
在用户交互层面，Context Engine 的能力已集成到 Robo Chat 中。Robo Chat 于几个月前宣布进入早期访问阶段，目前已有少数客户在使用。如果启用了代码上下文启用（code context enabled）功能，Robo Chat 在回答与代码相关的问题时，不再仅仅依赖 Confluence 搜索或 GitHub/Bitbucket API，而是基于“今天的真相”和“历史决策”提供更连贯、更有效的回答。
这种机制使得 AI 能够理解代码背后的逻辑脉络，而不仅仅是语法结构。对于希望提升开发效率的团队而言，这种基于深度上下文的问答能力显著优于传统的关键词搜索。通过 TeamGraph CLI 暴露核心原语，未来更多功能可能会直接集成到该接口中，进一步简化开发者与 AI 代理的交互流程。
Jira Agent (JCA)：从史诗到多波次代理执行的自动化工作流
针对如何将大型 Epic（史诗）分解并执行的问题，演讲者展示了 Jira Agent (JCA) 的强大自动化能力。用户可以将一个 Epic 输入给 JCA，JCA 能够将其分解为更小的 Issue（问题）或任务。随后，通过配置自动化规则（Automation Rules），可以在 Epic 被分解后自动重启 JCA 实例，从而自主开发每个小片段。
"You can take an epic... JCA will break this down into smaller issues for me... you can have automations kind of restart a JCA instance and it is able to autonomously develop each."
这种工作流支持多波次执行（Waves of Agents）。例如，先进行基础工作的 V0 版本开发，再逐步推进到 V1、V2。演讲者指出，没有任何限制阻止这种递归分解和持续执行。虽然 Robo 可能不直接处理此类复杂编排，但结合 Jira Automation 和 AutoDev，可以实现从高层需求到底层代码实现的端到端自主开发流程。这种灵活性允许团队将大型项目拆解为多个阶段，并由 AI 代理分批次完成。
Jira Agent 会话隔离与本地开发环境的同步机制
关于代码变更的实时性，演讲者澄清了 Jira Agent 会话与本地 IDE（如 VS Code）之间的隔离关系。JCA 的代理会话是高度隔离的。如果在 Jira Agent 会话内部或云端 VS Code 实例中进行代码更改，这些变更会实时反映在云环境中。然而，如果在本地 IDE（如桌面版 VS Code）中进行更改，这被视为一个独立的实例，不会自动同步到 Jira Agent 的云端会话中。
对于希望将代理部署在本地环境（On-prem）的用户，开发环境是基于 Docker 构建的。这意味着用户需要利用 Dockerfile 来配置本地代理运行环境，而不是直接同步本地的代码修改。这种设计确保了 AI 代理在受控环境中执行任务的一致性，但也要求开发者明确区分本地手动修改与云端 AI 生成的代码流。
AI 审查器新功能与技能支持扩展
在本次研讨会的最后阶段，演讲者回应了关于最新技术进展的提问。他们透露，Atlassian 团队近期在 AI 审查器（AI Reviewer）的功能拓展上取得了重要突破，特别是针对“技能”（Skills）的支持刚刚启动不久。这一更新标志着 AI 工具在理解特定上下文和专业化任务处理能力的进一步提升。AI Reviewer 近期发布了“Leads”功能，该功能的推出时间非常紧凑，据演讲者描述是在不到一个月前发布的。这一快速迭代展示了团队在响应社区需求和提升产品实用性方面的敏捷性。新功能的上线旨在增强 AI 对代码审查中特定角色或流程的理解，从而提供更精准的辅助建议。
研讨会总结与致谢环节
随着技术问答环节的结束，会议进入了正式的收尾阶段。演讲者对现场观众的热情参与表示了诚挚的感谢。本次工作坊的成功举办离不开所有参会者的投入，同时也特别提到了技术团队在解决现场 Wi-Fi 问题上的辛勤付出。演讲者明确表示：“Thanks a bunch for the uh the tech staff for getting all of our Wi-Fi issues sorted out.” 这种对幕后支持团队的公开致谢，体现了会议组织方对技术基础设施稳定性的重视。与会者被祝愿在会议期间剩余的时间里度过愉快的一周，整个活动在积极友好的氛围中落下帷幕。
未来互动与社区连接
尽管本次研讨会的主要议程已经结束，但演讲者强调了持续互动的可能性。他们表示团队将继续在场边待命，以回答任何后续可能出现的疑问。这种开放式的沟通机制确保了参会者即使离开主会场也能获得必要的技术支持。“We'll be around if there's any other questions.” 这句话不仅是对当前问题的回应，更是对未来合作与反馈渠道的确认。Atlassian 团队希望通过这种方式保持与开发社区的紧密联系，以便更好地优化产品并解决用户在实际使用中遇到的挑战。
结论
Atlassian AI战略核心在于从单一编码工具转向全生命周期编排，通过Jira Coding Agent、AI Reviewer及Context Engine构建闭环。实证数据显示，经过滤的评论解决率（40%）接近人类基准（45%），显著降低审查噪音。Context Engine通过语义搜索解决单体仓库痛点，实现动态上下文获取。
然而，全自动冲突解决尚不成熟，依赖“人在环”验证以确保准确性。当前模型路由需手动配置，智能调度未上线；信用报告粒度仅至产品级。适用条件包括：需明确验收标准、设置WIP限制及成本上限，并严禁在演示环境输入敏感数据。