A implantação self-hosted lidera o lançamento deste mês

A partir de 24 de setembro de 2026, o IBM Bob está disponível para implantação self-hosted. O backend do Bob é executado em clusters Red Hat OpenShift geridos pela própria organização, nas suas instalações ou na sua própria conta cloud. O modelo é um modelo frontier a partir de um serviço cloud de modelos que a organização já utiliza, ou um modelo open-weight nos seus próprios GPUs. Os developers continuam a usar o mesmo Bob IDE e Bob Shell que já conhecem. O lançamento deste mês também adiciona processos em segundo plano, um cliente MCP atualizado e novos controlos para administradores.

O serviço cloud do Bob continua a ser a opção certa para a maioria das equipas de engenharia: sem infraestrutura para gerir, atualizações que chegam automaticamente, e o backend é operado pelas pessoas que o construíram. Para muitas grandes organizações de engenharia esse padrão não está disponível, porque o código fonte não pode sair da infraestrutura que controlam. Segundo regras de residência de dados, o Bob pode usar um modelo frontier através da conta cloud da própria organização. Numa rede air-gapped, o Bob usa um modelo open-weight nos GPUs da própria organização.

Implantação self-hosted

O que inclui uma implantação self-hosted

A implantação self-hosted empacota o backend do Bob para Red Hat OpenShift. Inclui identidade, o gateway de inferência, registo de auditoria e medição de utilização, todos geridos por um operador que trata da instalação, atualizações e operações de dia 2. O Bob é executado como uma carga de trabalho com namespace ordinária, podendo partilhar um cluster existente com outras aplicações.

Os developers continuam a trabalhar no Bob IDE e no Bob Shell como antes. O endpoint self-hosted é normalmente distribuído através de políticas de grupo, pelo que os clientes se ligam ao cluster interno sem qualquer configuração do lado do developer. O agente que lhe está subjacente é o mesmo que corre contra o serviço cloud.

Os pacotes premium também funcionam numa implantação self-hosted: IBM Bob Premium Package for Java Modernization, IBM Bob Premium Package for IBM i e IBM Bob Premium Package for Z (PP4Z). Um administrador do Bob atribui-os a utilizadores na mesma Admin UI do serviço cloud. O PP4Z traz os seus próprios componentes de backend, incluindo o Z Understand, e o administrador do cluster decide no momento da instalação se os implanta.

Duas formas de ligar um modelo

O Bob self-hosted liga-se a um modelo de uma de duas formas.

Modelos frontier através da conta cloud da organização. O Bob pode usar modelos frontier através do AWS Bedrock, Azure OpenAI, Google Vertex AI ou qualquer outro serviço de modelos compatível com OpenAI. O backend do Bob, identidade, registos de auditoria e medição permanecem no cluster. Os pedidos ao modelo, incluindo o contexto de código que transportam, vão para a conta cloud da própria organização ao abrigo dos acordos que já tem. Esta opção é adequada para organizações que já têm acesso aprovado a um serviço cloud de modelos, mas precisam de tudo o resto sob o seu próprio controlo.

Totalmente self-hosted. Para redes sem ligação de saída, o modelo corre nos GPUs da própria organização. Dois modelos open-weight são suportados nesta opção: NVIDIA Nemotron 3 Ultra e Poolside Laguna S 2.1. O agente do Bob foi ajustado e avaliado em relação a cada um deles. O dimensionamento de hardware segue as orientações de cada fornecedor, uma vez que depende da quantização, do comprimento do contexto e do número de developers atendidos em simultâneo. Um pequeno modelo de guarda-redes filtra inputs e outputs nesta opção, e o Bob IDE e o Bob Shell detetam-no automaticamente assim que estiver configurado.

Uma instalação em duas etapas

A instalação é gerida pelo bobctl, a CLI de instalação do Bob para implantações self-hosted, e é feita em duas etapas. A primeira cria os elementos ao nível do cluster: definições de recursos, permissões e o operador. Requer direitos de cluster-admin e, na maioria das empresas, passa pela revisão de mudanças da equipa de plataforma. A segunda etapa instala o próprio Bob num namespace e necessita apenas de acesso ao nível do namespace.

A separação significa que a equipa de plataforma revê e aprova o footprint ao nível do cluster uma vez. Depois disso, a equipa que gere o Bob pode instalar, atualizar e reconfigurar sem ter direitos de cluster-admin nem abrir um ticket para cada mudança.

Clusters totalmente air-gapped são um caminho de instalação suportado. O bobctl espelha as imagens do Bob para um registo privado, incluindo o caso em que as imagens são descarregadas numa máquina com ligação, transportadas além da barreira e enviadas do lado isolado.

Uma instalação de nó único do OpenShift é suficiente para uma prova de conceito. O dimensionamento de produção e os pré-requisitos estão cobertos na documentação de instalação.

Identidade através do diretório corporativo

Uma implantação self-hosted inclui o seu próprio serviço de identidade, baseado em Keycloak, que pode ser ligado ao LDAP ou Active Directory da organização. Uma vez ligado, os developers entram com as suas credenciais corporativas e o acesso segue o diretório: as pessoas adicionadas ao mesmo são provisionadas no Bob, e as pessoas removidas perdem o acesso automaticamente. Instalações menores e provas de conceito podem gerir utilizadores diretamente no serviço de identidade.

Como obter o Bob self-hosted

A implantação self-hosted é liderada pelas vendas. Para ver uma demonstração ou iniciar uma prova de conceito, contacta um representante IBM ou Business Partner, ou usa Contactar Vendas em bob.ibm.com. A equipa de conta configura o direito para a organização, incluindo quaisquer pacotes premium.

Começa com uma prova de conceito de nó único do OpenShift apontada para um endpoint de modelo que a organização já executa, e liga o Bob IDE de uma equipa a esse endpoint. A documentação de implantação self-hosted cobre o caminho daí até à produção, incluindo a instalação air-gapped, backup e restauro.

Mais neste lançamento mensal

Cliente MCP atualizado para v2

O cliente MCP suporta agora a especificação MCP 2026-07-28, incluindo o transporte Streamable HTTP sem estado, mantendo a compatibilidade com MCP 2025 Streamable HTTP e servidores stdio. O tratamento do protocolo OAuth passa para o cliente.

Mudança incompatível: O suporte ao transporte HTTP+SSE foi removido, e o Bob rejeita configurações HTTP+SSE no arranque. Os servidores MCP ainda a usar HTTP+SSE têm de ser atualizados para Streamable HTTP antes de atualizar o Bob.

Para administradores

Política de grupo RequiredExtensions. A política de grupo que distribui o endpoint self-hosted pode agora também instalar extensões do VS Code. Os administradores listam os IDs das extensões na nova política RequiredExtensions, e o Bob instala-as a partir do marketplace no arranque, sem qualquer ação necessária por parte do developer. A política usa os mesmos templates ADMX/ADML, gestão de dispositivos móveis e mecanismos de ficheiros de política que já governam as próprias definições do Bob.

Diretórios de plugins. Skills, modes, ficheiros de regras e configuração MCP podem agora ser colocados em .bob/plugins/<plugin-name>/ ao nível do workspace, ou ~/.bob/plugins/<plugin-name>/ globalmente, e o Bob deteta-os no arranque. Uma equipa pode incluir um mode personalizado, as regras que referencia, as skills que invoca e uma configuração MCP juntos como um único diretório de plugin. O layout de nível raiz existente continua a funcionar.

Para developers

Processos em segundo plano. Builds, watchers, servidores de desenvolvimento e outros comandos de longa duração agora arrancam em segundo plano em vez de bloquear a conversa. Um indicador na vista de chat mostra o que está a correr; clica nele para inspecionar o output ou parar o processo.

Obter páginas web (experimental). O Bob pode obter uma página de documentação, uma referência de API ou outro URL conhecido e lê-la como Markdown ou texto simples. Ativa primeiro web_fetch em Definições → Chat.

Hooks de ciclo de vida de compactação. O PreCompact corre antes da compactação de contexto e pode bloqueá-la; o PostCompact corre após a sua conclusão. /compress na entrada de chat aciona a compactação manualmente.

Largura de chat configurável. Definições → Chat → Aparência oferece Predefinida, Larga e Largura completa, e a escolha persiste entre sessões.

Também neste lançamento

Os eventos de hook podem ser enviados para endpoints HTTPS. Os handlers de hook HTTP são agora configuráveis na UI de Definições do Bob.
O watsonx Governance está agora disponível no Bob Marketplace.
As perguntas de seguimento aparecem agora uma de cada vez em vez de em lote.
Os nomes dos servidores MCP são preservados nos IDs das ferramentas, facilitando o rastreio do servidor de onde veio uma determinada chamada de ferramenta.
O file watching e a descoberta de skills funcionam agora em workspaces Remote SSH.
Nomes de diretórios de skills inválidos apresentam um aviso no arranque.

Experimenta o lançamento mais recente

Antes de atualizar, move qualquer servidor MCP ainda em HTTP+SSE para Streamable HTTP. Em seguida, arranca um servidor de desenvolvimento numa sessão e continua a trabalhar enquanto ele corre em segundo plano.

Para partilhar uma configuração de equipa, coloca um mode personalizado, as regras que referencia e as skills que invoca em .bob/plugins/<plugin-name>/ e faz commit do diretório para o repositório. O Bob deteta o plugin no arranque para todos os que abrem o workspace. Com web_fetch ativo, aponta o Bob para a referência de API de uma biblioteca antes de lhe pedir que escreva código contra essa biblioteca.