OpenAI与Atlassian扩大合作，将GPT-6家族模型接入Atlassian平台与Rovo智能体，旨在把分散于Jira、Confluence和开发流程的企业知识转化为可执行的工作建议与行动。合作覆盖模型接入、知识调用、开发者工作流与写回能力，同时提出权限控制、审计与治理等企业部署关键问题。
OpenAI与Atlassian于2026年10月6日宣布扩大合作，将GPT-6家族的前沿模型引入Atlassian平台和Rovo智能体，试图把分散在Jira、Confluence以及软件开发流程中的企业知识，转化为可以执行的工作建议和行动。
这项合作的核心，不只是让企业员工在聊天窗口里查询项目资料，而是把OpenAI的模型能力与Atlassian的Teamwork Graph连接起来。后者是Atlassian用来描述人员、项目、文档和决策之间关系的企业上下文层。两家公司希望，AI不再只回答“发生了什么”，而是能够进一步判断项目是否按计划推进、哪些任务受到阻碍，以及下一步应由谁采取什么行动。
OpenAI的合作公告称，新的协议将让OpenAI前沿模型为Atlassian平台和Rovo中的智能体提供支持。合作始于2023年，最新扩展则覆盖模型接入、企业知识调用、开发者工作流以及两家公司自身的产品使用。
从企业搜索走向可执行的工作流
Atlassian的Rovo原本就试图解决企业搜索和知识发现问题。企业的关键信息通常分散在项目工单、会议记录、产品文档、代码仓库和即时通信中，即使这些资料都存在，员工也往往需要手动拼接上下文，才能判断一个项目的真实状态。
在两家公司设想的场景中，一名产品经理可以询问Rovo某项产品发布是否准备就绪。系统随后从Teamwork Graph中关联Jira工单、Confluence页面和相关讨论，找出工程阻塞、遗漏的里程碑以及尚未解决的决策，并借助OpenAI模型生成发布准备度评估和后续建议。
这种做法与传统的企业聊天机器人有明显区别。传统问答系统通常围绕“从哪一页找到答案”展开，而Rovo与OpenAI试图处理的是“基于这些资料，组织现在应该做什么”。这也是企业AI从搜索、摘要逐渐转向代理式工作流的一个缩影。
Atlassian在自己的公告中也曾强调，Rovo可以把Jira和Confluence作为ChatGPT中的实时信息来源，帮助用户总结工作项、发现趋势，并直接创建Jira问题。其Rovo MCP Connector for ChatGPT支持通过Model Context Protocol连接第三方AI客户端，并提供写回能力，例如在ChatGPT中创建或批量更新Jira事项。
但“能够写回”也意味着系统不只是读取企业知识，而是可能改变企业系统中的状态。Atlassian表示，Rovo MCP Server使用OAuth认证，遵循既有权限控制，并提供审计日志和客户端允许列表，让管理员能够限制哪些外部客户端可以连接。这些机制将决定这类整合能否从演示功能进入生产环境。
GPT-6家族成为企业平台的模型层
OpenAI公告没有把这次合作限定在单一模型上，而是表示Atlassian将获得包括GPT-6 Astra和GPT-5.6系列在内的最新前沿模型访问权。不同模型可以根据任务的复杂程度、成本和响应速度承担不同角色。
这与OpenAI近期对模型产品的分层思路一致。AIFlux此前对OpenAI GPT-6开发指南的报道指出，OpenAI已经把模型选择从单纯比较基准成绩，扩展到衡量一次任务成功所需的综合成本，包括推理强度、上下文处理、工具调用、失败重试和人工审核。
对Atlassian而言，模型价值也不只在于生成更流畅的文字。Rovo需要理解项目之间的关系、人员的职责、文档的时间顺序以及企业权限，并把这些信息转换为可供团队采取行动的结果。模型越深入地参与工单创建、任务分派和项目跟踪，企业就越需要知道它使用了哪些信息、作出了哪些判断，以及哪些步骤仍然需要人类批准。
OpenAI还表示，Atlassian内部正在扩大对Codex和ChatGPT Enterprise的使用。目前有超过3,000名Atlassian开发者在终端、集成开发环境和代码审查流程中使用Codex。借助Teamwork Graph相关插件，Codex用户可以访问工作项、技术文档和开发上下文，从而帮助开发者编写、测试和发布软件。
这说明双方的关系并不是单向的“OpenAI向Atlassian提供模型”。Atlassian既是模型能力的企业客户，也是把企业工作数据连接到AI系统中的平台方。OpenAI可以在Atlassian内部使用Jira管理关键流程，Atlassian则可以把OpenAI模型嵌入自己的产品和开发体系，形成相互强化的合作关系。
ChatGPT和Codex开始进入企业系统的控制层
此次合作还包括Atlassian为ChatGPT和Codex提供的插件扩展。OpenAI称，相关插件可以让用户把Jira工作项、Confluence内容和人员信息直接带入ChatGPT或Codex的提示中，并在适当权限下访问项目、文档和开发上下文。
OpenAI已经提供Atlassian Rovo插件页面，其中列出的能力包括在ChatGPT中访问Jira、Confluence和Compass的上下文、查找事故相关文档、总结根因与缓解措施，以及把对话转换为带有验收标准和负责人的Jira任务。插件同时被标注为支持交互式操作和写入功能，具体可用范围取决于套餐和工作区管理员设置。
这类产品把ChatGPT从一个独立的对话入口，推向企业软件的控制层。用户不必在多个系统之间来回复制内容，AI可以直接读取项目资料、整理背景、提出下一步动作，并在授权后写回任务管理系统。
但系统之间的连接越深入，错误的影响也越具体。一个不准确的摘要可能只是造成误解；一个错误创建、关闭或重新分派的任务，则可能影响项目进度、客户响应和责任追踪。因此，权限边界、人工审批、审计记录以及可逆操作将成为企业采用这类工具时的关键条件。
Atlassian正在把“开放平台”作为竞争方向
Atlassian表示，双方正在探索更深层次的Jira整合，使企业更容易把工作分派给AI智能体、跟踪执行进度、记录决策并审核结果。公司还提到，将来可能把这些能力与DX平台结合，用于观察AI对开发速度、交付周期和开发者体验的影响。
这显示出Atlassian并不满足于在自己的产品中增加一个模型接口，而是试图把Rovo、Teamwork Graph、MCP连接器和开发工具组合成开放的企业AI平台。企业可以在Atlassian内部使用Rovo，也可以让ChatGPT、Codex和其他AI客户端通过连接器访问相关上下文。
这一方向的优势是减少信息孤岛，避免企业为了每一种AI工具都重新搭建一套数据接入系统。但它也会带来新的治理难题：不同AI客户端的权限如何保持一致，多个代理同时修改同一项工作时谁拥有最终控制权，模型生成的建议如何与企业流程和责任制度衔接，以及企业是否能够在发现异常后及时停止和回滚操作。
AIFlux此前在OpenAI DevDay 2026的报道中指出，OpenAI正在把模型、持续运行的智能体、开发环境和插件生态组合成更完整的工作系统。Atlassian合作将这条路线进一步带入企业项目管理和知识协作场景。
企业知识的价值取决于权限和责任
两家公司对这项合作的表述，重点放在“把知识转化为行动”。不过，企业知识并不是一个可以任意汇总的公共数据库。它通常包含不同部门的权限边界、尚未公开的产品计划、客户信息、技术缺陷以及管理层决策记录。
因此，Rovo和OpenAI模型能否真正创造价值，不只取决于模型是否足够强大，还取决于系统是否能够准确判断哪些信息可以被读取、哪些内容只能被特定人员访问，以及哪些行动必须在执行前获得批准。企业还需要能够追踪代理使用过的资料、生成过的判断和执行过的写回操作。
Atlassian已经公布OAuth、权限控制、审计日志和客户端允许列表等安全措施，但这些是产品设计和公司披露的能力，并不等于所有实际部署都已经完成独立安全验证。OpenAI和Atlassian也没有在公告中公布合作产品的详细定价、全面可用时间表、各模型在Rovo中的具体分工，或代理在不同企业工作流中的准确率和失败率。
对企业客户而言，下一阶段需要观察的将是更具体的问题：Rovo是否能在复杂项目中持续保持上下文一致，代理写回是否始终遵循权限，模型提出的阻塞和风险判断能否被人工复核，以及系统在错误操作后能否提供清晰的追踪和恢复路径。
OpenAI与Atlassian的合作，代表的并不只是又一次模型接入或插件发布。它反映出企业AI竞争正在从“谁能回答得更好”，转向“谁能在真实组织的知识、权限和工作流程中可靠地完成更多事情”。如果这一模式能够稳定运行，Jira和Confluence可能成为AI代理理解企业工作的关键上下文层；但要让企业真正放心把行动交给代理，模型能力之外的治理、审计和责任机制同样不可缺少。
来源：