Atlassian拆解企业级AI代码智能体：全流程自动化实战

在AI Engineers World's Fair的一场 workshop 上，Atlassian 的 Andy Wong、Shane Wolfe 和 Andrew Bocan 系统展示了他们过去一年半在企业级 AI 代码智能体上的布局。核心判断很明确：随着 AI 编程工具增多，单点工具带来的生产力增益正在放缓，真正的机会在于代码“左右两侧”——规划、编排、审查与运维。

为什么焦点从“写代码”转向“代码之外”

Andy Wong 在开场就抛出了一个观察：AI 编程工具越来越多，但每个工具带来的边际生产力提升正在收窄。Atlassian 因此把赌注押在软件开发生命周期中那些“不那么显眼”的环节——规划、编排、代码审查和运维。

围绕这个判断，Atlassian 构建了一套产品矩阵：Teamwork Graph、AI Planner、AI AutoDev、AI Reviewer、AI SRE，以及位于所有这些工具中心的 AI Context Engine（上下文引擎）。其逻辑是，企业研发的瓶颈往往不在敲代码本身，而在于上下文散落在 Jira 工单、Confluence 文档、Slack 消息和代码仓库之间。

据现场演示，这套体系已经以 Jira Coding Agent（JCA）为入口落地，且 JCA 已经正式对外可用。

Jira Coding Agent：把工单变成可审查的 PR

Jira Coding Agent 是 Atlassian 原生编码智能体，最大特点是“深度企业上下文”。它会读取 Jira 工单、Confluence 文档，也会检索邮件和 Slack 消息，以收集完成一个工单所需的背景信息。开发者可以直接在 Jira 生态内与 Pull Request 交互，也可以把任务指派给自己偏好的第三方智能体，比如 Claude、Cursor、Codex。

在验证环节，JCA 依赖工单中的验收标准清单。智能体在拥有完整沙盒的环境下运行——沙盒基于容器、支持 Docker，可以安装依赖、运行项目，甚至在浏览器中执行验证步骤。只要仓库中写清楚了“如何运行”，它就能自行完成验收检查。

模型选择上，JCA 目前支持 Anthropic 和 OpenAI 系列模型，采用基于 credits 的计费方式，也支持用户自带 API Key。现场被问及是否做智能模型路由时，团队坦言目前还没有，但 AutoDev 正在朝这个方向推进，希望帮助团队判断某个任务是否属于“Haiku 级别”并给出指标依据。

Pull Request（PR） 是代码协作平台（如 GitHub、GitLab、Bitbucket）中的核心机制，指开发者将一组代码变更提交到仓库时发起的合并请求。在 PR 流程中，团队成员可以逐行审查变更、留下评论、要求修改，并通过 CI 流水线自动运行测试与检查，最终由有权限的人批准并合并。对于 AI 编码智能体而言，PR 是一个天然的“人机交接面”：智能体在沙盒中完成代码修改后以 PR 形式提交，人类只需审查 diff 和验收标准是否满足，而无需关心智能体内部的执行过程。PR 还把审查意见、状态检查和合并记录沉淀为可追溯的元数据，成为衡量智能体产出质量与 ROI 的重要数据来源。

AI Reviewer：用自训练模型过滤低价值评论

代码审查是 Atlassian 投入较重的环节。AI Reviewer 的目标不只是找 bug，而是结合 Jira、Confluence、SCM 和 Slack 的上下文，对 PR 是否满足需求做整体判断。

一个值得注意的细节是，团队发现很多代码审查工具过于“吹毛求疵”，会产生大量低价值评论。Atlassian 选择自训练模型来过滤这些噪音，现场给出的数据是：评论解决率达到约 40%，接近人类基线 45%。这个数字说明 AI 审查正在逼近可用的临界点，但距离完全替代人工仍有距离。

配套的还有集中管理的 Standards（标准）功能。团队可以在 Rovo Dev 中创建标准、编写规则，并指定应用到哪些仓库（支持手动选择或按模式匹配），覆盖 GitHub、GitLab、Bitbucket Cloud 等 SCM 平台。现场演示了“设计令牌强制”标准的创建流程：填写名称、描述、规则，选择目标仓库，之后编码智能体在 PR 流程中自动检查是否符合标准。

自训练模型（self-trained model） 在此语境下指 Atlassian 基于自身代码审查数据（历史 PR 评论、解决状态、人类反馈等）微调或专门训练的模型，而非直接调用通用大模型。通用模型往往倾向于“面面俱到”，对命名风格、注释格式等细枝末节也给出评论，导致噪音过多、开发者产生审查疲劳。自训练模型可以学习企业内部的审查偏好和“什么算有价值的评论”，从而在生成阶段或后处理阶段过滤低价值意见。其代价是需要持续的数据标注与模型维护，收益则是更高的评论解决率与更低的误报率——文中约 40% 的解决率正说明这种针对性训练已带来接近人类基线的效果。

AutoDev：从 backlog 自主领任务，但要控制“工作洪流”

AutoDev 是 Atlassian 在 AI SDLC 编排上的尝试。它的初始版本会扫描 Jira backlog，挑出智能体有把握自主完成的工作项，直接生成 PR 交给团队审查。

负责 AutoDev 的 Andrew Bocan 特别强调了几个现实约束。第一是需求完整性：backlog 里大量工单只有一行摘要，智能体无法判断目标，这时会拉入人类补充规格。第二是审查瓶颈——“审查这一步是事情死掉的地方”，因此 AutoDev 通过 Slack 在合适时机提醒相关人。第三是工作流控制，团队可以配置每人每周分配多少个 PR、每月最多使用多少 credits、限定哪些仓库启用。

Andrew 还提到一个容易被忽略的点：没人愿意一天审查 50 个 PR。因此 AutoDev 的设计哲学是渐进式推进，而不是一次性把大量变更砸给团队。对于大规模组织迁移（比如 Rails 版本升级、上万服务的相似改造），这种“智能体干活、人类做协调”的模式被认为是主要机会。

AI Context Engine：让产品仓库“像 monorepo 一样”

整场分享中，“上下文”是出现频率最高的词。Atlassian 内部有约 15000 个仓库，回答“这个改动应该在哪里实现”“哪些服务在用这个服务”这类问题极其困难。

Context Engine 的思路是缩小检索空间，先定位答案最可能所在的代码范围，再深入挖掘，同时叠加 Teamwork Graph 中的文档信息。Shane Wolfe 指出，文档往往过时，但它记录了“当时为什么这样决策”，这对避免重犯历史错误很有价值。代码是当下的真相，文档是历史的决策背景，两者结合才能支撑更好的实现路径规划。

一个有意思的判断是，团队认为过去很多组织为了给智能体提供上下文而选择 monorepo，但这会带来 monorepo 的债务和大量工具建设成本。Context Engine 的目标是让普通产品仓库“感觉像 monorepo”——通过按需、高速的代码级检索实现。

对于上下文冲突和权威性问题，Atlassian 的策略是不做快照缓存，避免信息过时，同时把“权威性”交给人类在环确认。Confluence 中的“已验证”徽章就是一个例子，用来标记仍然有效的文档，使其在检索中被优先对待。

Monorepo（单一仓库） 指将多个项目、服务或包放在同一个代码仓库中管理，Google、Meta 等公司是典型代表。其优势在于跨项目依赖、搜索和重构极为方便，智能体可以一次性看到全部代码上下文；劣势是仓库体积庞大、构建与权限管理复杂，需要投入大量自研工具（如增量构建、代码索引、稀疏检出）来维持效率。许多组织为了给 AI 智能体提供完整上下文而考虑迁移到 monorepo，却低估了随之而来的工具债务。Atlassian 的 Context Engine 试图用“按需、高速的代码级检索”模拟 monorepo 的检索体验：智能体先缩小候选范围，再深入具体文件，从而在不改变仓库结构的前提下获得足够的上下文。

AI Planner 与 AI SRE：覆盖规划与运维两端

AI Planner 面向的是可行性评估和任务拆解。开发者或管理者提供想法后，Planner 会借助 Context Engine 判断在当前仓库中是否可行，并给出实现计划和多种执行路径。

AI SRE 则瞄准凌晨两三点的故障诊断场景。它从历史事件中提取上下文，做根因分析，给出可能的修复建议，并集成 Slack 提供快速摘要——包括是否影响多个外部客户，还是只影响小部分用户。

现场还演示了一个组合玩法：用 JCA 把一个 epic 拆成更小的 Jira 任务，再通过自动化规则触发 JCA 会话，让智能体自主开发每个子任务。团队表示，这种模式可以继续外推——把故事拆成多个 epic（基础版、V0、V1、V2），再逐层细化，技术上没有阻碍。

SRE（Site Reliability Engineering，站点可靠性工程） 是起源于 Google 的运维方法论，强调用软件工程手段保障系统可靠性，核心实践包括服务水平目标（SLO）、错误预算、故障复盘（postmortem）和自动化应急响应。AI SRE 指的是将大模型与智能体引入这一流程：在故障发生时快速汇总告警、日志、历史事件和变更记录，辅助定位根因并给出修复建议；在日常则从历史事件中提取模式，帮助团队预防重复故障。文中凌晨两三点的故障诊断场景正是 SRE 的典型痛点——信息分散、时间压力大，而智能体可以同时检索多个系统并在 Slack 中给出“是否影响外部客户”这类关键判断，缩短平均恢复时间（MTTR）。

对企业落地的几点启示

这场分享的价值不在于罗列功能，而在于暴露了企业级智能体落地的真实约束。成本控制（credits 上限、按工单/按周预算）已经成为“基本盘”；工作流控制（每人每周 PR 数量上限）是防止智能体制造审查洪流的必要设计；人类在环不是妥协，而是处理需求模糊性和上下文权威性的机制。

另一个值得关注的信号是 ROI 度量。Atlassian 为各工具构建了仪表盘，追踪审查次数、智能体运行量、AutoDev 生成的 PR 数量等元数据。当智能体可能“在某个角落烧掉十亿 token”时，可观测性就不再是锦上添花。

至于现场反复出现的 Wi-Fi 故障，反倒成了一个意外的注脚：在通往 AGI 的路上，先要解决的是网络连接。