# Aither

> An AI-native Astro theme that believes text itself is beautiful.

---

## ✨ Por que Astro-Theme-Aither

URL: https://astro-theme-aither.pages.dev/pt-br/posts/why-astro-theme-aither/
Date: 2026-01-03
Category: Design
Tags: Design, Astro
Description: Um tema Astro AI-nativo que acredita que o texto por si só é bonito.

Um tema Astro AI-nativo que acredita que o texto por si só é bonito. Astro-Theme-Aither é construído para leitores que vêm pelas palavras, não pela decoração.

## Filosofia de Design

A maioria dos temas de blog compete por atenção com imagens hero, animações, sidebars e popups. Nada disso ajuda na leitura — ajuda na visualização, que é uma atividade completamente diferente.

Astro-Theme-Aither adota a abordagem oposta: design mínimo, não engenharia mínima. Quando não há visuais chamativos para distrair dos problemas, cada falha tipográfica e cada atraso de carregamento é amplificado. Design mínimo exige qualidade de engenharia mais alta.

## Tipografia

Parâmetros tipográficos seguem as Apple Human Interface Guidelines:

- **Tamanho de fonte** — base 17px
- **Altura de linha** — 1.47
- **Espaçamento entre letras** — -0.022em
- **Escala de títulos** — 31px → 22px → 19px → 17px
- **Largura de leitura** — limitada a 65–75 caracteres por linha

## Construído sobre Astro

Astro gera HTML estático por padrão. A arquitetura de islands significa que componentes interativos hidratam independentemente enquanto o resto da página permanece estático.

## Recursos

- **Tailwind CSS v4** — tokens de design `@theme`
- **Tipografia Apple HIG**
- **View Transitions API** — animação circular reveal para troca de tema
- **i18n** — suporte multilíngue com detecção automática de idioma do navegador
- **Fixação de posts** — fixe posts importantes no topo
- **Content Collections** — Markdown type-safe
- **Modo escuro** — Claro / Escuro / Sistema
- **SEO** — Open Graph, URLs canônicas
- **RSS + Sitemap** — auto-gerados
- **Google Analytics** — opcional, em Partytown Web Worker
- **Testes** — Vitest + Playwright
- **Cloudflare Pages** — workflow de deploy com previews de PR

## Para Quem É

- **Blogueiros pessoais** que querem sua escrita em primeiro plano
- **Escritores técnicos** que precisam de boa renderização de blocos de código
- **Autores multilíngues** que precisam de i18n embutido
- **Desenvolvedores** que apreciam uma codebase bem engenheirada

Escreva sobre qualquer coisa — a tipografia vai fazer parecer bonito.

---

## 📝 Guia de Estilo Markdown

URL: https://astro-theme-aither.pages.dev/pt-br/posts/markdown-guide/
Date: 2026-01-02
Category: Tutorial
Tags: Markdown, Guide
Description: Um guia completo de todos os recursos Markdown suportados no Astro-Theme-Aither

Este post demonstra cada recurso Markdown suportado pelo Astro-Theme-Aither. Use como referência ao escrever seus próprios posts. Adicione esta página aos favoritos — ela cobre toda a gama de opções de formatação disponíveis.

## Títulos

Use `##` para títulos de seção, `###` para subseções e `####` para sub-subseções. Evite `#` no conteúdo do post — o título do post já é renderizado como título de nível superior.

### Título de Terceiro Nível

Títulos de terceiro nível são ideais para dividir uma seção em tópicos distintos. Eles criam hierarquia visual sem serem muito proeminentes.

#### Título de Quarto Nível

Títulos de quarto nível funcionam para subseções detalhadas. Use-os com moderação — se seu esboço vai além de quatro níveis, considere reestruturar seu conteúdo.

### Práticas Recomendadas para Títulos

Algumas diretrizes para uso eficaz de títulos:

- **Não pule níveis** — vá de `##` para `###`, nunca de `##` direto para `####`. Pular níveis quebra a estrutura do documento e pode confundir leitores de tela.
- **Use títulos descritivos** — "Configuração" é melhor que "Coisas de Setup". Leitores escaneiam títulos antes de decidir se leem uma seção.
- **Use sentence case** — capitalize apenas a primeira palavra e nomes próprios.

## Parágrafos e Quebras de Linha

Texto de parágrafo flui naturalmente. Deixe uma linha em branco entre parágrafos para separá-los.

Este é um segundo parágrafo. Mantenha parágrafos focados em uma ideia para a melhor experiência de leitura.

Ao escrever para a web, parágrafos mais curtos tendem a funcionar melhor que longos blocos de texto. Um parágrafo de três a cinco frases é uma unidade de leitura confortável em telas. Se um parágrafo ultrapassa seis ou sete frases, considere dividi-lo.

Quebras de linha simples dentro de um parágrafo (sem linha em branco) serão tratadas como espaço, não como nova linha. Se precisar de uma quebra de linha forçada sem iniciar novo parágrafo, termine a linha com dois espaços ou use uma tag `<br>` — embora isso raramente seja necessário na prática.

## Ênfase

- **Texto em negrito** com `**asteriscos duplos**`
- *Texto em itálico* com `*asteriscos simples*`
- ***Negrito e itálico*** com `***asteriscos triplos***`
- ~~Riscado~~ com `~~tils duplos~~`

### Quando Usar Cada Estilo

**Negrito** funciona melhor para termos-chave, avisos importantes ou definições — qualquer coisa que o leitor não deve perder mesmo ao escanear. Use para a frase mais importante de um parágrafo, não para frases inteiras.

*Itálico* serve para ênfase dentro de uma frase, títulos de livros e publicações, termos técnicos na primeira utilização e expressões estrangeiras. Fornece uma ênfase mais leve que o negrito.

~~Riscado~~ é útil para mostrar correções, informações obsoletas ou itens concluídos em um changelog. Tem um conjunto mais restrito de usos, mas é valioso quando necessário.

## Links

[Link inline](https://astro.build) com sintaxe `[texto](url)`.

Links também podem referenciar outros posts em seu site usando caminhos relativos. Use texto de link descritivo — "leia o guia Markdown" é melhor que "clique aqui". Bom texto de link ajuda tanto leitores quanto mecanismos de busca a entender para onde o link leva.

Você também pode criar links que se leem naturalmente dentro da frase. Por exemplo: a [documentação do Astro](https://docs.astro.build) cobre cada recurso em detalhe.

## Listas

Lista não ordenada:

- Primeiro item
- Segundo item
  - Item aninhado
  - Outro item aninhado
- Terceiro item

Lista ordenada:

1. Primeiro passo
2. Segundo passo
   1. Sub-passo um
   2. Sub-passo dois
3. Terceiro passo

Lista de tarefas:

- [x] Configurar o projeto
- [x] Escrever o primeiro post
- [ ] Deploy para produção

### Dicas de Formatação de Listas

Listas são uma das ferramentas mais eficazes na escrita web. Elas quebram texto denso, tornam informações escaneáveis e comunicam claramente sequências ou coleções de itens.

**Use listas não ordenadas** quando os itens não têm sequência inerente — recursos, requisitos, opções ou exemplos.

**Use listas ordenadas** quando a sequência importa — passos em um processo, itens ranqueados ou instruções que devem ser seguidas em ordem.

**Use listas de tarefas** para acompanhar progresso, checklists de projeto ou itens de tarefas.

Mantenha itens de lista paralelos em estrutura. Se o primeiro item começa com um verbo, todos os itens devem começar com um verbo.

## Citações

> O propósito da abstração não é ser vago, mas criar um novo nível semântico no qual se pode ser absolutamente preciso.
>
> — Edsger W. Dijkstra

Citações aninhadas:

> Primeiro nível
>
> > Segundo nível
> >
> > > Terceiro nível

### Uso de Citações

Citações servem a vários propósitos além de citar pessoas famosas:

- **Citar fontes** — ao referenciar outro artigo, livro ou documento
- **Destaques** — destacar informações importantes ou avisos
- **Estilo email** — mostrar o que alguém disse em uma conversa à qual você está respondendo
- **Pull quotes** — chamar atenção para uma passagem-chave do seu próprio artigo

Ao usar citações com atribuição, coloque o nome do autor em uma linha separada precedida por um travessão, como mostrado no exemplo de Dijkstra acima.

## Código

`Código` inline com crases. Use código inline para nomes de funções como `getPublishedPosts()`, caminhos de arquivo como `src/content/posts/`, instruções de linha de comando como `pnpm dev` e quaisquer valores literais que apareçam no texto corrido.

Bloco de código com destaque de sintaxe:

```typescript
interface Post {
  title: string;
  date: Date;
  description?: string;
  tags?: string[];
  draft?: boolean;
}

function getPublishedPosts(posts: Post[]): Post[] {
  return posts
    .filter((post) => !post.draft)
    .sort((a, b) => b.date.getTime() - a.date.getTime());
}
```

```css
@theme {
  --font-sans: 'system-ui', sans-serif;
  --font-serif: 'ui-serif', 'Georgia', serif;
}
```

### Dicas para Blocos de Código

Sempre especifique o identificador de linguagem após as crases triplas de abertura. Isso ativa o destaque de sintaxe, que melhora drasticamente a legibilidade. Identificadores comuns incluem `typescript`, `javascript`, `css`, `html`, `bash`, `json`, `python` e `markdown`.

Para comandos shell, use `bash` ou `sh`:

```bash
# Instalar dependências
pnpm install

# Iniciar o servidor de desenvolvimento
pnpm dev

# Compilar para produção
pnpm build
```

Para arquivos de configuração JSON:

```json
{
  "name": "my-blog",
  "version": "1.0.0",
  "scripts": {
    "dev": "astro dev",
    "build": "astro build"
  }
}
```

Mantenha blocos de código focados. Mostre apenas as linhas relevantes em vez de colar um arquivo inteiro. Se contexto for necessário, adicione um comentário indicando onde o código está.

## Tabelas

| Recurso | Status | Notas |
|---|---|---|
| Modo escuro | Suportado | Claro / Escuro / Sistema |
| Feed RSS | Embutido | `/rss.xml` |
| Sitemap | Auto-gerado | Via `@astrojs/sitemap` |
| SEO | Embutido | Open Graph + canonical |

Colunas alinhadas à direita e centralizadas:

| Esquerda | Centro | Direita |
|:---|:---:|---:|
| Texto | Texto | Texto |
| Texto mais longo | Texto mais longo | Texto mais longo |

### Diretrizes para Tabelas

Tabelas funcionam melhor para dados estruturados com colunas e linhas claras. São ideais para comparações de recursos, opções de configuração, parâmetros de API e dados de referência.

Mantenha tabelas simples. Se uma tabela tem mais de cinco ou seis colunas, fica difícil de ler em dispositivos móveis. Considere dividir tabelas complexas em várias menores, ou use formato de lista.

O alinhamento de colunas é controlado com dois-pontos na linha separadora:

- `:---` para alinhamento à esquerda (padrão)
- `:---:` para centralização
- `---:` para alinhamento à direita

Use alinhamento à direita para dados numéricos para que pontos decimais se alinhem visualmente.

## Linha Horizontal

Use `---` para criar uma linha horizontal:

---

Conteúdo após a linha.

Linhas horizontais são úteis para separar seções principais de um post, indicar mudança de tópico ou quebrar visualmente artigos muito longos. Use-as com parcimônia — se precisar de separadores frequentes, títulos podem ser uma escolha estrutural melhor.

## Imagens

Imagens são suportadas com sintaxe Markdown padrão:

```markdown
![Texto alternativo](./image.jpg)
```

Este tema é focado em tipografia, mas imagens funcionam quando você precisa delas.

### Práticas Recomendadas para Imagens

- **Sempre inclua texto alternativo** — é essencial para acessibilidade e também aparece quando imagens falham ao carregar
- **Use nomes de arquivo descritivos** — `dashboard-error-state.png` é melhor que `screenshot-2.png`
- **Otimize tamanhos de arquivo** — comprima imagens antes de adicioná-las ao seu repositório; imagens grandes desaceleram o carregamento das páginas
- **Considere o fluxo de leitura** — posicione imagens perto do texto que as referencia, não a parágrafos de distância

## Conclusão

Os recursos Markdown descritos neste guia cobrem a grande maioria do que você precisará para escrever em blog. A chave para um bom Markdown é usar o elemento certo para o propósito certo: títulos para estrutura, ênfase para importância, listas para coleções, blocos de código para conteúdo técnico e parágrafos para todo o resto.

Escreva com clareza, formate com consistência e deixe a tipografia fazer seu trabalho.

---

## 👋 Olá Mundo

URL: https://astro-theme-aither.pages.dev/pt-br/posts/hello-world/
Date: 2026-01-01
Category: Tutorial
Tags: Hello, Astro
Description: Bem-vindo ao Astro-Theme-Aither — um tema para blog onde a tipografia conduz o design

Bem-vindo ao Astro-Theme-Aither.

Este é um tema para blog construído sobre uma crença: boa escrita merece boa tipografia. Fontes sans-serif, um ritmo de leitura limpo e um layout que não atrapalha. Tudo aqui serve a um único objetivo — fazer suas palavras parecerem e se sentirem bonitas.

## Por que Outro Tema para Blog

A web está cheia de temas para blog, então uma pergunta justa é: por que construir outro? A resposta está nas prioridades. A maioria dos temas otimiza para impacto visual — imagens hero grandes, layouts complexos, transições animadas. Isso é impressionante em demos, mas atrapalha quando alguém realmente senta para ler um artigo de 2.000 palavras.

Astro-Theme-Aither parte de uma premissa diferente. O conteúdo é o produto. O trabalho do tema é apresentar esse conteúdo com o cuidado que ele merece.

## Começando

1. **Clone o repositório** — use o botão de template do GitHub ou clone diretamente com `git clone`
2. **Instale dependências** — execute `pnpm install`
3. **Configure seu site** — edite `src/config/site.ts`
4. **Substitua o conteúdo de exemplo** — troque os posts em `src/content/posts/`
5. **Comece a desenvolver** — execute `pnpm dev`
6. **Deploy** — faça push para o GitHub e deixe o CI workflow cuidar do deploy no Cloudflare Pages

### Estrutura do Projeto

```
src/
├── components/     # Componentes Astro reutilizáveis
├── config/         # Configuração do site
├── content/        # Seus posts Markdown e conteúdo
├── layouts/        # Layouts de página (Layout.astro)
├── pages/          # Páginas de rotas
└── styles/         # CSS global com tokens Tailwind v4
```

### Escrevendo Seu Primeiro Post

Crie um novo arquivo `.md` em `src/content/posts/` com o seguinte frontmatter:

```markdown
---
title: Título do Seu Post
date: 2026-01-15
category: General
description: Um breve resumo para SEO e previews sociais
tags: [Topic, Another]
---

Seu conteúdo começa aqui.
```

## O Que Você Recebe

### Recursos de Conteúdo

- **Feed RSS** — gerado automaticamente em `/rss.xml`
- **Sitemap** — auto-gerado via `@astrojs/sitemap`
- **Meta tags SEO** — Open Graph, Twitter cards e URLs canônicas
- **Modo escuro** — toggle de três vias (Claro / Escuro / Sistema) com persistência `localStorage`

### Recursos para Desenvolvedores

- **TypeScript** — modo strict, componentes e utilitários totalmente tipados
- **Content Collections** — Markdown type-safe com validação de frontmatter
- **Tailwind CSS v4** — tokens de design `@theme`
- **Vitest + Playwright** — testes unitários e E2E integrados ao CI
- **Cloudflare Pages** — workflow de deploy com URLs de preview de PR

### Performance

Como o tema gera HTML estático com JavaScript mínimo, a performance é excelente por padrão. Espere pontuações Lighthouse de 100 em todas as categorias.

## Nota sobre Filosofia de Design

A simplicidade visual deste tema é intencional, mas não é o mesmo que simplicidade de engenharia. Sob o capô, o tema lida com uma quantidade surpreendente de preocupações: escalas tipográficas responsivas, contraste de cores acessível, estrutura HTML semântica e atenção cuidadosa à experiência de leitura em todas as telas.

Bom design é invisível. Quando você lê um artigo neste tema e simplesmente aprecia a escrita — o design está funcionando exatamente como planejado.

Boa escrita.

---

## Agentes de IA e Uso de Ferramentas (Exemplo)

URL: https://astro-theme-aither.pages.dev/pt-br/posts/ai-agents-and-tool-use/
Date: 2026-01-09
Category: AI
Tags: AI, Agents
Description: Como modelos de IA vão além do chat executando ações no mundo real

Um agente de IA é um modelo de linguagem que pode tomar ações — não apenas gerar texto. Ele pode buscar na web, executar código, chamar APIs, ler arquivos e tomar decisões sobre o que fazer em seguida. Essa mudança da geração passiva de texto para a resolução ativa de problemas representa um dos desenvolvimentos mais significativos na IA aplicada.

## De Chat para Ação

Um chatbot responde perguntas. Um agente resolve problemas. A diferença é autonomia: agentes decidem quais ferramentas usar, em que ordem e como lidar com erros.

Considere a diferença na prática. Você pergunta a um chatbot: "Como está o clima em Tóquio?" Ele pode responder com base em seus dados de treinamento — que têm meses ou anos e quase certamente estão errados. Você faz a mesma pergunta a um agente, e ele chama uma API de clima, recupera os dados atuais e retorna uma resposta precisa e atualizada.

O chatbot gera texto plausível. O agente interage com o mundo.

### O Espectro da Autonomia

Nem todos os agentes são igualmente autônomos. Existe um espectro:

1. **Chat assistido por ferramentas** — o modelo pode chamar ferramentas, mas apenas em resposta direta às solicitações do usuário. Uma chamada de ferramenta por turno.
2. **Agentes multi-etapas** — o modelo pode encadear múltiplas chamadas de ferramentas para realizar uma tarefa, decidindo a sequência por conta própria.
3. **Agentes totalmente autônomos** — o modelo opera independentemente por períodos prolongados, tomando decisões, lidando com erros e perseguindo objetivos com supervisão humana mínima.

A maioria dos sistemas em produção hoje está nos níveis 1-2. Agentes totalmente autônomos são uma área ativa de pesquisa com desafios significativos de segurança ainda a resolver.

## Uso de Ferramentas

Tool use permite que um modelo de IA chame funções externas. O modelo decide quando uma ferramenta é necessária, gera os parâmetros corretos e incorpora o resultado em sua resposta. Isso transforma um gerador de texto em um assistente capaz.

### Como Funciona o Tool Use

A mecânica é direta:

1. **Definição da ferramenta** — você descreve as ferramentas disponíveis para o modelo, incluindo seus nomes, parâmetros e o que fazem. Isso é tipicamente fornecido como JSON estruturado no prompt do sistema ou via um campo de API dedicado.
2. **Decisão** — ao processar uma solicitação do usuário, o modelo decide se uma ferramenta seria útil. Se sim, gera uma chamada de ferramenta com os parâmetros apropriados.
3. **Execução** — sua aplicação executa a chamada da ferramenta (o modelo não a executa diretamente) e retorna o resultado.
4. **Integração** — o modelo incorpora o resultado da ferramenta em sua resposta ao usuário.

### Exemplo de Definição de Ferramenta

```json
{
  "name": "search_documentation",
  "description": "Search the product documentation for relevant articles",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "The search query"
      },
      "max_results": {
        "type": "integer",
        "description": "Maximum number of results to return",
        "default": 5
      }
    },
    "required": ["query"]
  }
}
```

O modelo vê essa definição e sabe que pode pesquisar na documentação. Quando um usuário faz uma pergunta sobre o produto, o modelo gera uma chamada como `search_documentation(query="how to reset password")`, seu sistema executa a busca, e o modelo usa os resultados para compor uma resposta precisa.

### Categorias Comuns de Ferramentas

Sistemas de agentes em produção tipicamente oferecem ferramentas em várias categorias:

- **Recuperação de informações** — busca web, consultas a banco de dados, leitura de arquivos, chamadas de API
- **Execução de código** — executar Python, JavaScript ou comandos shell em um ambiente sandboxed
- **Comunicação** — enviar emails, postar mensagens, criar tickets
- **Manipulação de arquivos** — criar, editar e organizar arquivos
- **Operações de sistema** — deploy de código, gerenciamento de infraestrutura, execução de pipelines CI

As ferramentas que você fornece definem os limites do que o agente pode fazer. Um conjunto de ferramentas bem projetado dá ao agente capacidade suficiente para ser útil sem poder suficiente para ser perigoso.

## Loops Agênticos

O padrão mais poderoso é o loop agêntico: o modelo planeja um passo, executa, observa o resultado e decide o próximo passo. Esse loop continua até que a tarefa seja concluída ou o modelo determine que não pode prosseguir.

### O Loop na Prática

Considere um agente encarregado de debugar um teste falhando:

1. **Planejar** — "Devo primeiro ler o arquivo de teste para entender o que ele está testando"
2. **Executar** — chama `read_file("tests/auth.test.ts")`
3. **Observar** — vê que o teste espera um status 200 mas recebe 401
4. **Planejar** — "Devo verificar o middleware de autenticação para ver o que está retornando 401"
5. **Executar** — chama `read_file("src/middleware/auth.ts")`
6. **Observar** — encontra um bug na verificação de expiração do token
7. **Planejar** — "Devo corrigir a comparação de expiração"
8. **Executar** — chama `edit_file(...)` com a correção
9. **Observar** — confirma que a edição foi feita
10. **Planejar** — "Devo executar o teste para verificar a correção"
11. **Executar** — chama `run_command("pnpm test tests/auth.test.ts")`
12. **Observar** — teste passa
13. **Concluído** — reporta a correção ao usuário

Cada passo envolve o modelo raciocinando sobre o estado atual, decidindo o que fazer em seguida e se adaptando com base no que descobre. Isso é fundamentalmente diferente de um script linear — o agente lida com descobertas inesperadas e muda de curso quando necessário.

### Lidando com Erros no Loop

Agentes robustos devem lidar com falhas graciosamente. Uma ferramenta pode retornar um erro, um arquivo pode não existir, ou uma API pode estar com rate limit. Um bom design de agente inclui:

- **Lógica de retry** — retentar falhas transitórias com backoff
- **Estratégias alternativas** — se uma abordagem falha, tentar outra
- **Degradação graciosa** — se a tarefa não pode ser completamente realizada, completar o máximo possível e explicar o que resta
- **Limites de loop** — definir um número máximo de iterações para prevenir loops infinitos quando o agente fica travado

## Projetando Ferramentas Eficazes

A qualidade de um sistema de agentes depende fortemente da qualidade de suas ferramentas. Ferramentas mal projetadas levam a agentes confusos e resultados incorretos.

### Princípios de Design de Ferramentas

- **Nomes claros** — `search_users` é melhor que `query_db_1`. O modelo usa o nome para decidir quando chamar a ferramenta.
- **Parâmetros descritivos** — inclua descrições para cada parâmetro. O modelo lê essas descrições para determinar quais valores passar.
- **Escopo focado** — cada ferramenta deve fazer uma coisa bem. Uma ferramenta `read_file` e uma ferramenta `write_file` são melhores que uma ferramenta `file_operations` com um parâmetro de modo.
- **Erros úteis** — retorne mensagens de erro claras que ajudem o modelo a entender o que deu errado e o que tentar em seguida.
- **Idempotentes quando possível** — ferramentas que podem ser retentadas com segurança simplificam o tratamento de erros.

## Riscos

Agentes que podem tomar ações podem tomar ações erradas. Sandboxing, passos de confirmação e revisão humana são medidas de segurança essenciais para qualquer sistema de agentes em produção.

### Categorias de Risco

- **Ações destrutivas** — um agente com acesso ao sistema de arquivos poderia deletar arquivos importantes. Um agente com acesso ao banco de dados poderia dropar tabelas. Ambientes sandbox e limites de permissão são essenciais.
- **Exfiltração de dados** — um agente que pode tanto ler dados sensíveis quanto fazer requisições de rede poderia inadvertidamente (ou por injeção de prompt) vazar informações.
- **Custos descontrolados** — um agente em loop chamando APIs caras pode acumular custos significativos rapidamente. Limites de orçamento e rate limiting são necessidades práticas.
- **Ações incorretas executadas com confiança** — o agente pode entender mal uma solicitação e tomar uma ação irreversível. Para operações de alto risco, sempre exija confirmação humana.

### Padrões de Segurança

Sistemas de agentes em produção devem implementar vários padrões de segurança:

1. **Privilégio mínimo** — dê ao agente apenas as ferramentas necessárias para sua tarefa específica, nada mais
2. **Sandboxing** — execute código e operações de arquivo em ambientes isolados
3. **Portões de confirmação** — exija aprovação humana para ações destrutivas ou irreversíveis
4. **Log de auditoria** — registre cada chamada de ferramenta e seu resultado para revisão
5. **Kill switches** — forneça mecanismos para parar imediatamente um agente em execução
6. **Limites de orçamento** — defina limites rígidos para chamadas de API, uso de tokens e tempo de computação

O objetivo não é impedir os agentes de serem úteis — é garantir que sejam úteis dentro de limites bem definidos.