• New AzureOpenAIAdapter using AzureOpenAI client from openai SDK
• Registered 'azure-openai' in SupportedProvider and createAdapter()
• model field is primary deployment name; AZURE_OPENAI_DEPLOYMENT as fallback
• Default api-version: 2024-10-21
• Example in examples/providers/azure-openai.ts
• 14 tests covering chat, stream, tool_use, deployment fallback, error path
• Updated README.md, README_zh.md, examples/README.md, src/cli/oma.ts

What

Adds AzureOpenAI as a first-class provider (provider: 'azure-openai') with a dedicated adapter using the AzureOpenAI client from the openai SDK.

Why

Azure OpenAI's deployment-based URL scheme and api-version query parameter don't work cleanly with a plain baseURL override, so a dedicated adapter is warranted.

Fixes #24

Design decision: model vs AZURE_OPENAI_DEPLOYMENT

The issue spec lists AZURE_OPENAI_DEPLOYMENT as an env var. After reviewing how existing providers work, I kept the primary pattern consistent with the rest of the framework: the model field in AgentConfig is the deployment name, same as how other providers use model.

AZURE_OPENAI_DEPLOYMENT is supported as an optional fallback — if model is blank, the adapter falls back to the env var, and throws a clear error if neither is set.

// Recommended (consistent with all other providers)
const agent: AgentConfig = {
  provider: 'azure-openai',
  model: 'my-gpt4-deployment',
}

// Also works (env var fallback)
// AZURE_OPENAI_DEPLOYMENT=my-gpt4-deployment
const agent: AgentConfig = {
  provider: 'azure-openai',
  model: '',
}

Env vars

Checklist

• npm run lint passes
• npm test passes (647 total, 14 new for this adapter)
• Added/updated tests for changed behavior
• No new runtime dependencies