Se você construiu um agente de IA conectando uma gigantesca máquina de estados if/else, você sabe o quão rapidamente isso se torna frágil. O Strands Agents aposta no oposto: deixe o modelo fazer o planejamento, e você fornece um prompt e uma lista de ferramentas. É um SDK de código aberto da AWS, lançado em maio de 2025 sob a Licença Apache 2.0, e ele alimenta agentes de produção dentro de equipes da Amazon como Amazon Q Developer e AWS Glue.
O que Strands Agents realmente é
Strands Agents é um SDK para construir e executar agentes de IA com poucas linhas de código. Você dá a um agente três coisas: um modelo, um prompt de sistema e um conjunto de ferramentas. O modelo lê o prompt, decide quais ferramentas chamar, as executa, analisa os resultados e continua até que a tarefa seja concluída. Esse ciclo é todo o produto.
Ele é fornecido para Python e TypeScript. O nome é uma referência às duas "strands" (fios/vertentes) que compõem um agente: o modelo e as ferramentas. A AWS o tornou código aberto após executá-lo internamente, então o design reflete as necessidades de produção, e não uma demonstração. Desde o lançamento da prévia, ele superou 150 mil downloads no PyPI e alcançou uma versão 1.0 que adicionou primitivas multiagente e suporte ao protocolo Agente-para-Agente (A2A).
Se você já leu sobre outros SDKs de agente, o formato parecerá familiar. Strands se encaixa na mesma categoria que LangGraph e Google ADK, mas se apoia mais fortemente no modelo para conduzir o fluxo de controle, em vez de pedir que você desenhe o gráfico por conta própria.
A filosofia orientada por modelo vs orquestração hard-coded
A maioria dos primeiros frameworks de agente pedia que você definisse o fluxo de trabalho antecipadamente. Você construiria nós, arestas e condições, e então rotearia o modelo através deles. Isso funciona, mas cada nova capacidade significa mais gráfico para manter.
Strands inverte a responsabilidade. Modelos modernos já planejam, encadeiam o raciocínio, chamam ferramentas e refletem sobre os resultados. Então, em vez de codificar essa lógica manualmente, você descreve o objetivo e entrega as ferramentas. O modelo descobre os passos.
Aqui está o contraste em termos simples:
| Abordagem | Você define | O fluxo de controle reside em | Custo de uma nova capacidade |
|---|---|---|---|
| Orquestração hard-coded | Nós, arestas, condições, roteamento | Seu código de gráfico | Editar o gráfico, retestar caminhos |
| Orientado por modelo (Strands) | Prompt + lista de ferramentas | O loop de raciocínio do modelo | Adicionar uma ferramenta, atualizar o prompt |
O trade-off é real. Agentes orientados por modelo são mais rápidos de construir e adaptar, mas você abre mão de certo determinismo. Para fluxos de trabalho que devem ser executados da mesma forma todas as vezes, você ainda pode adicionar estrutura com padrões multiagente e hooks. O ponto não é que os gráficos estejam errados; é que você os utiliza quando precisa, em vez de por padrão.
Um agente mínimo
O menor programa útil do Strands é curto. Você importa a classe Agent, opcionalmente define uma ferramenta com o decorator @tool e chama o agente como uma função.
from strands import Agent, tool
@tool
def word_count(text: str) -> int:
"""Conta as palavras em um bloco de texto."""
return len(text.split())
agent = Agent(
system_prompt="Você é um assistente de escrita conciso.",
tools=[word_count],
)
response = agent("Quantas palavras há nesta frase?")
print(response)
O decorator @tool transforma uma função Python comum em algo que o modelo pode chamar. Sua docstring e type hints se tornam a descrição da ferramenta e o esquema de entrada, para que o modelo saiba quando e como usá-la. Não há um registro separado para manter. Chamar agent(...) executa o loop até que o modelo decida que terminou.
Ferramentas e provedores de modelo
As ferramentas são como o agente interage com o mundo exterior. Uma ferramenta pode ser uma função Python que você escreveu, uma ferramenta empacotada da comunidade, ou um servidor completo do Model Context Protocol (MCP) exposto ao agente.
No lado do modelo, Strands é flexível quanto ao provedor. O provedor padrão é o Amazon Bedrock, e de fábrica um agente usa um modelo Claude Sonnet na região us-west-2 (o ID exato do modelo padrão mudou entre as versões do SDK, então verifique sua versão instalada em vez de codificá-lo diretamente). Você pode apontá-lo para outros locais:
- Qualquer modelo Amazon Bedrock que suporte uso de ferramentas e streaming
- Família Claude da Anthropic através da API Anthropic
- Modelos Llama via API Llama
- Ollama para desenvolvimento local
- Outros provedores como OpenAI através de LiteLLM
Trocar provedores é uma mudança no objeto do modelo, não uma reescrita. O loop do agente, suas ferramentas e seu prompt permanecem os mesmos. Isso torna prático desenvolver com um modelo Ollama local e implantar no Bedrock.
Suporte multiagente e MCP
Um único agente lida com muito, mas sistemas reais frequentemente precisam de vários. Strands 1.0 adicionou primitivas para aplicações multiagente, incluindo um padrão Agente-como-Ferramenta onde um agente chama outro agente da mesma forma que chama qualquer ferramenta, e coordenação estilo Swarm para grupos de agentes trabalhando juntos em um problema. Ele também suporta o protocolo A2A, para que agentes Strands possam conversar com agentes construídos em outros frameworks.
MCP é um cidadão de primeira classe. O Model Context Protocol é um padrão aberto para conectar modelos a ferramentas e fontes de dados. Com Strands, você pode se conectar a servidores MCP publicados e usar suas ferramentas diretamente, o que significa que milhares de integrações existentes se tornam disponíveis sem código de conexão personalizado. Você gerencia a conexão através de um cliente MCP e passa suas ferramentas para o agente como qualquer outra lista de ferramentas.
Se você já está executando servidores MCP, esta é a maneira mais barata de dar novas capacidades a um agente. O trade-off é que agora você depende do comportamento desses servidores, o que é uma das razões pelas quais testar os endpoints subjacentes é importante.
Implantação de um agente Strands
Strands é construído para ir do seu laptop para a produção sem uma mudança de framework. Você testa localmente e depois implanta no destino que se encaixa na sua pilha:
- Amazon Bedrock AgentCore para um runtime de agente gerenciado
- AWS Lambda para agentes de curta duração, orientados a eventos
- AWS Fargate ou Amazon EKS para serviços conteinerizados de longa duração
- Docker simples em qualquer lugar onde você possa executar um contêiner
Como o agente é Python ou TypeScript comum, seu empacotamento segue as mesmas regras de qualquer aplicativo. A AWS também documenta hooks de observabilidade, para que você possa rastrear o que o modelo decidiu e quais ferramentas ele chamou assim que o agente estiver ativo.
Onde o Apidog se encaixa
Strands constrói o agente. Ele não constrói as APIs que seu agente chama, e essa é a lacuna que vale a pena planejar. Todo agente Strands se apoia em dois tipos de endpoints HTTP: a API do provedor LLM por trás do modelo, e as APIs REST ou de ferramentas por trás de suas funções @tool e servidores MCP. Se esses endpoints se comportarem mal, o agente falha de maneiras que parecem problemas do modelo, mas não são.
Apidog é onde você testa e simula essas APIs subjacentes antes mesmo que o agente as toque. Alguns usos concretos:
- Simule o modelo ou um endpoint de ferramenta enquanto você itera no loop, para não gastar tokens ou atingir limites de taxa a cada execução. O artigo sobre a construção de um conjunto de testes para agentes de IA com Apidog mostra o padrão.
- Afirme os formatos de resposta da ferramenta para que uma ferramenta que retorne um payload malformado seja detectada em um teste, e não em produção. Veja o guia de asserções de API para saber como validar campos, tipos e códigos de status.
- Configure uma API de simulação que imita as respostas de um serviço real, incluindo casos de erro que seu agente precisa tratar com elegância.
- Gerencie chaves de API por ambiente para que seus agentes de desenvolvimento, staging e produção se autentiquem contra os backends corretos sem vazar credenciais para o código.
Para ser claro, Apidog não é um framework de agente e não orquestra nada. Strands permanece o cérebro. Apidog é a bancada de trabalho para a infraestrutura subjacente. Você pode baixar o Apidog e configurar simulações para seus endpoints de ferramentas em alguns minutos.
Quando usar Strands Agents
Busque o Strands quando quiser se mover rapidamente e confiar no modelo para planejar. Ele se encaixa bem se você está na AWS e já usa o Bedrock, se você quer começar com um agente e evoluir para multiagente mais tarde, ou se você quer ferramentas MCP sem escrever código de integração.
É uma opção menos adequada quando você precisa de fluxos estritos, auditáveis e determinísticos, onde cada ramificação deve ser predefinida. Você ainda pode chegar lá com hooks e estrutura multiagente, mas um framework focado em gráficos pode ser uma correspondência mais direta. A abordagem honesta é que os métodos orientados por modelo e por gráfico resolvem problemas diferentes, e Strands é o orientado por modelo.
Perguntas frequentes
Strands Agents é gratuito e de código aberto?
Sim. Strands Agents é de código aberto sob a Licença Apache 2.0, com o código-fonte no GitHub. Não há taxa de licença para o SDK. Você paga pelo modelo e por quaisquer recursos de nuvem nos quais você implanta, como inferência do Bedrock ou execução do Lambda, mas o framework em si não custa nada.
Preciso usar Amazon Bedrock com Strands?
Não. Bedrock é o provedor padrão, mas Strands suporta a API da Anthropic, a API Llama, Ollama para execuções locais e outros provedores através do LiteLLM. Você muda o objeto do modelo e mantém o restante do seu código. Isso facilita o protótipo localmente e a transição para um provedor gerenciado para produção.
Qual a diferença entre Strands e um framework baseado em gráfico?
Strands é orientado por modelo: você fornece um prompt e ferramentas, e o modelo decide os passos. Frameworks baseados em gráfico pedem que você defina o fluxo de controle como nós e arestas. Strands é mais rápido para construir e adaptar; frameworks de gráfico oferecem uma execução mais rigorosa e previsível. Muitas equipes usam ambos para serviços diferentes.
Como testo as APIs das quais meu agente Strands depende?
Teste-as independentemente do agente, antes e durante o desenvolvimento. Simule os endpoints LLM e de ferramentas, afirme seus formatos de resposta e execute essas verificações na CI. Uma ferramenta como o Apidog lida com a simulação e as asserções, e o guia sobre testar a API ChatGPT com Apidog cobre autenticação, streaming e testes de chamadas de ferramentas que se mapeiam diretamente para os backends do agente.
Conclusão
Strands Agents é uma abordagem clara para construir agentes: defina um modelo, um prompt e ferramentas, e então deixe o modelo executar o loop. Ele escala de um agente para muitos, se comunica via MCP e A2A, e é implantado em toda a pilha da AWS sem uma reescrita. O framework lida com o raciocínio. Seu trabalho é garantir que as APIs subjacentes sejam sólidas, e é exatamente aí que o Apidog ganha seu lugar, simulando e testando os endpoints que seu agente chama para que as falhas apareçam em seus testes em vez de em produção.