Mensagens de sistema e alterações de ferramentas no meio da conversa

As instruções de 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 aproveitam 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 início do prompt e invalida o cache para tudo o que vem depois.

Mensagens de sistema no meio da conversa resolvem esse problema. 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 de sistema, e não como texto comum do usuário.

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



Alterações de ferramentas no meio da conversa

O array tools fica ainda mais no início do prefixo de requisição com hash do que o campo system de nível superior, então editá-lo invalida o cache de prompt para toda a conversa. Alterações de ferramentas no meio da conversa, um beta introduzido com o Claude Opus 5, são o equivalente para ferramentas das mensagens de sistema no meio da conversa. Em vez de fixar a lista de ferramentas para toda a duração da conversa, você altera quais ferramentas são oferecidas ao modelo entre os 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 combinados com blocos text na mesma mensagem. A mensagem segue as mesmas regras de posicionamento de qualquer mensagem de sistema no meio da conversa (consulte Limitações), e a alteração se aplica daquele ponto da conversa em diante. O campo tool de cada bloco referencia uma ferramenta em vez de defini-la: {"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 disponibilize. tool_addition também volta a oferecer 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 antecipadamente 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.",
        },
        # Retire 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 ainda é 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)

Alterações 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 de sistema no meio da conversa

O cache de prompt calcula o hash do prefixo da requisição nesta 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 quebra do cache.

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

Mensagens de sistema no meio da conversa permitem que você adicione a instrução no final do histórico de mensagens. 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 é importante:

• Mudanças de política ou persona no meio da sessão. Uma longa sessão agêntica 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 o Claude deve tratar como um fato de nível de operador: arquivos foram alterados no disco, o usuário ativou ou desativou 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 mensagem de acompanhamento enquanto o Claude ainda está executando ferramentas para a solicitação anterior. Retransmiti-la como uma mensagem de sistema após o próximo resultado de ferramenta permite que o Claude incorpore a nova entrada ao trabalho que já está fazendo, em vez de tratá-la como uma nova solicitação para a qual mudar. Consulte Posicionamento após resultados de ferramentas abaixo.
• Mudanças de modo que concedem permissões permanentes. Um modo de nível de sessão pode usar uma mensagem de sistema no meio da conversa para conceder consentimento permanente a uma capacidade custosa, como iniciar automaticamente fluxos de trabalho multiagente, com um breve lembrete a cada vários turnos e um aviso de saída quando o modo é desativado. Para um exemplo detalhado, consulte Construir um modo de orquestração.

Em todos esses casos, você poderia colocar a instrução em uma mensagem user comum, e o 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 de 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 se o usuário final pedir algo diferente. Uma mensagem de sistema no meio da conversa mantém essa prioridade de nível de operador sem pagar o custo de perda 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 instruções entram em conflito, mensagens de sistema posteriores têm precedência sobre as anteriores, e mensagens de 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 a toda a conversa. Reserve mensagens de 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
        # atender à política rigorosa de tipagem da equipe. Anexar 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 (opt-in): se uma requisição não tiver o campo cache_control (automático ou um ponto de quebra explícito), nada é armazenado em cache e toda requisição paga o preço normal de tokens de entrada pela conversa completa. Com o cache habilitado, anexar a mensagem de 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 atinja o comprimento mínimo de prompt cacheável; um exemplo tão curto quanto este fica abaixo desse limite, então cache_creation_input_tokens e cache_read_input_tokens permanecem em 0 até que a conversa cresça.

Uma mensagem de sistema no meio da conversa deve vir imediatamente após um turno user (ou um turno assistant que termina 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 de sistema logo após os resultados de ferramentas, antes do próximo turno do Claude. Qualquer outra posição, incluindo entre um bloco tool_use do 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 de sistema vai depois da mensagem user que entrega os resultados de ferramentas. Este também é o ponto em que sua aplicação pode retransmitir a entrada que o usuário digitou enquanto o 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 de sistema como contexto, e não 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 o Claude agir com base nisso. O Claude é treinado para resistir a instruções que parecem agir contra o usuário, e essa proteção ainda se aplica ao papel de sistema, então linguagem como "ignore o que o usuário disse" é menos eficaz do que declarar o que mudou.

Este padrão serve 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

Mensagens de sistema no meio da conversa e 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 quebra explícito em um bloco de conteúdo. Uma mensagem de sistema no meio da conversa não cria uma entrada de cache por si só, e sem o cache habilitado não há economia a preservar.
• Armazene em cache o prefixo estável normalmente. Coloque cache_control no último bloco que permanece igual 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 de sistema após o ponto de quebra. Como ela vem depois do prefixo em cache, não altera o hash do prefixo e o cache ainda é aproveitado.
• Uma mensagem de sistema no meio da conversa é, ela própria, cacheável. 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 quebra de cache para depois dela (ou contar com o cache automático para fazer isso), e a mensagem de sistema é lida do cache como qualquer outro turno.

Evite editar ou remover uma mensagem de 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 de sistema em vez de reescrever a antiga. Mensagens de 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 serve 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 vir imediatamente após um turno user (incluindo um turno user que carrega blocos tool_result) ou um turno assistant que termina 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 é lugar para conteúdo não confiável. O Claude trata o conteúdo de 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 de 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