Mensagens do sistema e mudanças de ferramentas no meio da conversa

As instruções do sistema normalmente ficam no campo system de nível superior, antes de todas as mensagens da conversa. Essa posição é ótima para o cache de prompt: o prompt do sistema faz parte do prefixo estável, então os turnos subsequentes acertam o cache. É uma posição ruim para instruções que você só descobre que precisa no meio de uma sessão, porque editar o campo system de nível superior altera o próprio início do prompt e invalida o cache de tudo o que vem depois.

As mensagens do sistema no meio da conversa fecham essa lacuna. Você anexa uma mensagem {"role": "system"} no ponto da conversa em que a nova instrução se torna relevante, em vez de editar o campo system de nível superior. O prefixo em cache permanece o mesmo, então a próxima requisição ainda o lê do cache, e a nova instrução ainda é aplicada como uma instrução do sistema em vez de como texto comum do usuário.

Esta página cobre dois recursos: mensagens do sistema no meio da conversa, que estão disponíveis de forma geral, e mudanças de ferramentas no meio da conversa, um beta introduzido com o Claude Opus 5 que aplica a mesma abordagem ao array tools.



Mudanças de ferramentas no meio da conversa

O array tools fica ainda mais no início do prefixo da requisição com hash do que o campo system de nível superior, então editá-lo invalida o cache de prompt da conversa inteira. As mudanças de ferramentas no meio da conversa, um beta introduzido com o Claude Opus 5, são a contraparte para ferramentas das mensagens do sistema no meio da conversa. Em vez de fixar a lista de ferramentas pela duração da conversa, você altera quais ferramentas são oferecidas ao modelo entre turnos: declare o conjunto completo de ferramentas em tools antecipadamente e, em seguida, use blocos tool_addition e tool_removal para oferecer uma ferramenta ao modelo, ou retirá-la, a partir de um ponto específico da conversa em diante. O array tools em si nunca muda, então o prefixo em cache permanece intacto.

tool_addition e tool_removal são blocos de conteúdo no array content de uma mensagem role: "system", e podem ser misturados com blocos text na mesma mensagem. A mensagem segue as mesmas regras de posicionamento de qualquer mensagem do sistema no meio da conversa (consulte Limitações), e a mudança se aplica daquele ponto da conversa em diante. O campo tool de cada bloco referencia uma ferramenta em vez de definir uma: {"type": "tool_reference", "name": "..."} nomeia uma ferramenta declarada no array tools da requisição, e ferramentas do conector MCP podem ser referenciadas individualmente com mcp_tool_reference (server_name e name) ou como um conjunto completo de ferramentas com mcp_toolset_reference (server_name). Referenciar um nome que não está declarado em tools retorna um erro 400.

Toda ferramenta declarada em tools é oferecida ao modelo desde o início da conversa, a menos que seja declarada com defer_loading: true, o que a mantém retida até que um bloco tool_addition a exponha. tool_addition também oferece novamente uma ferramenta que um tool_removal anterior retirou.

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    betas=["mid-conversation-tool-changes-2026-07-01"],
    # O conjunto completo de ferramentas é declarado desde o início e nunca muda, então o
    # prefixo em cache permanece intacto.
    tools=[
        {
            "name": "get_weather",
            "description": "Get the current weather for a location.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "location": {"type": "string", "description": "City name"},
                },
                "required": ["location"],
            },
        },
    ],
    messages=[
        {
            "role": "user",
            "content": "Say OK.",
        },
        # Retira get_weather deste ponto em diante. O bloco referencia
        # a ferramenta pelo nome em vez de editar `tools`, então os turnos anteriores permanecem
        # idênticos byte a byte e o cache continua sendo aproveitado.
        {
            "role": "system",
            "content": [
                {
                    "type": "tool_removal",
                    "tool": {"type": "tool_reference", "name": "get_weather"},
                },
            ],
        },
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

As mudanças de ferramentas no meio da conversa estão em beta. Para usá-las, inclua o cabeçalho beta mid-conversation-tool-changes-2026-07-01 em suas requisições. Elas estão disponíveis no Claude Fable 5, Claude Mythos 5, Claude Opus 4.8 e Claude Opus 5, na API do Claude, no Amazon Bedrock e no Google Cloud.



Quando usar uma mensagem do sistema no meio da conversa

O cache de prompt faz o hash do prefixo da requisição em ordem: tools, depois system, depois messages. Um acerto de cache exige que o prefixo corresponda exatamente a uma requisição recente, byte a byte, até o ponto de interrupção do cache.

Essa ordenação significa que o campo system de nível superior fica bem perto do início do prefixo com hash. Qualquer alteração nele, mesmo anexar uma frase, produz um hash diferente, e a requisição erra o cache para o prompt do sistema e para todas as mensagens em cache depois dele.

As mensagens do sistema no meio da conversa permitem que você adicione a instrução no final do histórico de mensagens em vez disso. Tudo antes da nova instrução permanece inalterado, então a entrada de cache existente ainda corresponde, e apenas a nova mensagem é processada como entrada nova.

Algumas situações em que isso importa:

• Mudanças de política ou persona no meio da sessão. Uma sessão agêntica longa precisa de uma nova restrição ("a partir de agora, escreva todo SQL como consultas parametrizadas") depois de dezenas de turnos em cache. Adicioná-la ao campo system de nível superior reprocessaria todo o histórico.
• Contexto por turno que precisa ser autoritativo. Você quer injetar uma nota de atualidade, um prazo de sessão ou uma mudança de disponibilidade de ferramentas com peso de nível de sistema, e isso muda com frequência demais para ficar no prefixo em cache.
• Mudanças de estado que sua aplicação observa. Sua aplicação percebe algo que Claude deve tratar como um fato de nível de operador: arquivos mudaram no disco, o usuário alternou uma configuração de aprovação automática, as ferramentas disponíveis mudaram ou o orçamento de tokens restante caiu abaixo de um limite.
• Entrada do usuário que não deve interromper um loop agêntico. Um usuário digita uma continuação enquanto Claude ainda está executando ferramentas para a requisição anterior. Retransmiti-la como uma mensagem do sistema após o próximo resultado de ferramenta permite que Claude incorpore a nova entrada ao trabalho que já está fazendo, em vez de tratá-la como uma nova requisição para a qual mudar. Consulte Posicionamento após resultados de ferramentas abaixo.
• Trocas de modo que concedem permissões permanentes. Um modo de nível de sessão pode usar uma mensagem do sistema no meio da conversa para conceder consentimento permanente a uma capacidade cara, como iniciar automaticamente fluxos de trabalho multiagente, com um lembrete curto a cada vários turnos e um aviso de saída quando o modo é desativado. Para um exemplo prático, consulte Construa um modo de orquestração.

Em todos esses casos você poderia colocar a instrução em uma mensagem user comum, e Claude de fato segue instruções que chegam em turnos de usuário. A diferença é a prioridade: uma mensagem user é tratada como vinda do usuário final, enquanto uma mensagem system é tratada como vinda de você, o operador da aplicação. Quando as duas entram em conflito, as instruções do sistema têm precedência, então use o papel system para fatos e restrições de nível de operador que devem valer mesmo que o usuário final peça algo diferente. Uma mensagem do sistema no meio da conversa mantém essa prioridade de nível de operador sem pagar o custo de erro de cache de editar o campo system de nível superior.



Como funciona

Adicione uma mensagem com "role": "system" ao array messages. Use uma string simples ou blocos de conteúdo para content, da mesma forma que um turno user ou assistant. A instrução se aplica daquele ponto da conversa em diante. Quando as instruções entram em conflito, mensagens do sistema posteriores têm precedência sobre as anteriores, e mensagens do sistema no meio da conversa têm precedência sobre o campo system de nível superior para os turnos que as seguem.

Você ainda pode definir o campo system de nível superior para instruções que devem se aplicar à conversa inteira. Reserve as mensagens do sistema no meio da conversa para instruções que só se tornam relevantes mais tarde, ou que você quer adicionar sem invalidar o prefixo em cache.

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    # Cache de prompt automático: cada requisição armazena em cache a conversa até o momento,
    # e a próxima requisição lê o prefixo inalterado do cache.
    cache_control={"type": "ephemeral"},
    system="You are a code review assistant. Be concise.",
    messages=[
        {
            "role": "user",
            "content": "Review process() in utils.py for performance issues.",
        },
        {
            "role": "assistant",
            "content": "The list comprehension is fine for small inputs. For large inputs, consider a generator to avoid materializing the full list.",
        },
        {
            "role": "user",
            "content": "Now review the calling code that invokes process().",
        },
        # O revisor percebe no meio da sessão que todas as sugestões também
        # devem passar pela política de tipagem estrita da equipe. Acrescentar a
        # instrução aqui mantém os turnos anteriores idênticos byte a byte, então o
        # prefixo armazenado em cache pela requisição anterior ainda é lido do cache.
        {
            "role": "system",
            "content": "From now on, every suggestion must include explicit type annotations.",
        },
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

Este exemplo habilita o cache automático com o campo cache_control de nível superior. O cache de prompt é opcional: se uma requisição não tem campo cache_control (automático ou um ponto de interrupção explícito), nada é armazenado em cache e cada requisição paga o preço normal de tokens de entrada pela conversa completa. Com o cache habilitado, anexar a mensagem do sistema deixa os turnos já em cache inalterados, então a requisição que carrega a nova instrução ainda os lê do cache em vez de processá-los novamente. O cache também exige que a conversa atenda ao comprimento mínimo de prompt armazenável em cache; um exemplo tão curto quanto este fica abaixo dele, então cache_creation_input_tokens e cache_read_input_tokens permanecem em 0 até que a conversa cresça.

Uma mensagem do sistema no meio da conversa deve seguir imediatamente um turno user (ou um turno assistant terminando em um resultado de ferramenta de servidor), e deve ser a última entrada em messages ou ser imediatamente seguida por um turno assistant. Uma mensagem user que carrega blocos tool_result conta: em um loop agêntico você pode colocar a mensagem do sistema logo após os resultados das ferramentas, antes do próximo turno de Claude. Qualquer outra posição, incluindo entre um bloco tool_use de assistant e o tool_result que o responde, retorna um erro 400.



Posicionamento após resultados de ferramentas

Em um loop agêntico, a mensagem do sistema vai depois da mensagem user que entrega os resultados das ferramentas. É também aqui que sua aplicação pode retransmitir a entrada que o usuário digitou enquanto Claude estava trabalhando, para que o novo contexto seja absorvido sem reiniciar o turno:

[
  { "role": "user", "content": "Run the test suite and fix any failures." },
  {
    "role": "assistant",
    "content": [{ "type": "tool_use", "id": "toolu_01", "name": "run_tests", "input": {} }]
  },
  {
    "role": "user",
    "content": [
      { "type": "tool_result", "tool_use_id": "toolu_01", "content": "12 passed, 0 failed" }
    ]
  },
  {
    "role": "system",
    "content": "The user sent the following message while you were working: also update the changelog before you finish."
  }
]

Formule o conteúdo do sistema como contexto em vez de como um comando que sobrepõe o usuário. Declare o fato ("nova entrada chegou do usuário: X", "o orçamento de tokens restante agora é Y") e deixe Claude agir sobre ele. Claude é treinado para resistir a instruções que parecem trabalhar contra o usuário, e essa proteção ainda se aplica ao papel de sistema, então uma linguagem como "ignore o que o usuário disse" é menos eficaz do que declarar o que mudou.

Este padrão é para retransmitir entrada do próprio usuário final da conversa. Não o use para passar saída de ferramentas, documentos recuperados ou outro conteúdo de terceiros; mantenha esse conteúdo em blocos tool_result (consulte Limitações).



Combinando com cache de prompt

As mensagens do sistema no meio da conversa e o cache de prompt foram projetados para serem usados juntos:

• Habilite o cache explicitamente. O cache só acontece quando a requisição inclui cache_control, seja o campo de cache automático de nível superior ou um ponto de interrupção explícito em um bloco de conteúdo. Uma mensagem do sistema no meio da conversa não cria uma entrada de cache por conta própria, e sem o cache habilitado não há economia a preservar.
• Armazene em cache o prefixo estável como de costume. Coloque cache_control no último bloco que permanece o mesmo entre requisições, seja o final do campo system de nível superior, o final das suas definições de ferramentas ou um ponto estável no histórico de mensagens.
• Anexe a mensagem do sistema após o ponto de interrupção. Como ela vem depois do prefixo em cache, não altera o hash do prefixo e o cache ainda acerta.
• Uma mensagem do sistema no meio da conversa é ela própria armazenável em cache. Uma vez que está na conversa, ela se torna parte do histórico estável. No próximo turno você pode mover seu ponto de interrupção de cache para depois dela (ou confiar no cache automático para fazer isso) e a mensagem do sistema é lida do cache como qualquer outro turno.

Evite editar ou remover uma mensagem do sistema no meio da conversa que já foi enviada. Como qualquer outra alteração em mensagens anteriores, isso invalida o cache daquele ponto em diante. Se a instrução precisar evoluir, anexe uma nova mensagem do sistema em vez de reescrever a antiga. Mensagens do sistema consecutivas são aceitas e tratadas como uma única seção de sistema, que segue a mesma regra de posicionamento como um todo.



Limitações

• Não para a primeira mensagem. Uma mensagem system não pode ser a primeira entrada em messages. Use o campo system de nível superior para instruções que se aplicam desde o início.
• O posicionamento é restrito. Uma mensagem system deve seguir imediatamente um turno user (incluindo um turno user que carrega blocos tool_result) ou um turno assistant terminando em um resultado de ferramenta de servidor, e deve preceder um turno assistant ou encerrar o array. Ela não pode ficar entre um bloco tool_use e seu tool_result. Colocá-la em outro lugar retorna um erro 400.
• Não é um lugar para conteúdo não confiável. Claude trata o conteúdo do sistema como instruções do operador e as segue. Não coloque texto de fora da conversa, como saída bruta de ferramentas, documentos recuperados ou conteúdo da web, diretamente em uma mensagem do sistema; fazer isso dá a esse texto autoridade de nível de operador. Mantenha esses dados em blocos tool_result e continue seguindo Mitigar jailbreaks e injeções de prompt.



Relacionados