GenericLlmConfig#108
Conversation
Add GenericLlmConfig as a provider-agnostic LLM configuration and wire it into the LangGraph, OpenAI Agents, AutoGen, and Agent Framework adapters. Each adapter maps GenericLlmConfig to its OpenAI-compatible path, using provider.endpoint for custom base URLs and auth.credential_ref for API keys.
…d issues in GenericLlmConfig - Extract shared prepare_openai_compatible_url into adapters/_url.py, fixing a bug where https:// URLs were corrupted in Agent Framework and AutoGen adapters - Add AuthConfig.resolve_credential() to resolve env var references, falling back to literal values - Wrap LlmEndpoint.auth in SensitiveField so fallback endpoint credentials are redacted during serialization
- URL helper now preserves user-provided paths instead of always overwriting with /v1, so non-OpenAI providers (Azure, Anthropic, custom gateways) work correctly. /v1 is only appended when no path is given. - credential_ref now uses an explicit $env: prefix for env var lookups. Without the prefix the value is treated as a literal credential, eliminating the ambiguous fallback behavior. Missing env vars raise ValueError instead of silently using the var name.
Instead of always creating an OpenAI-compatible client, the GenericLlmConfig branch in each adapter now dispatches based on provider.type (vllm, ollama, openai, openai_compatible) to match the behavior of the corresponding specific config classes. Also renames the V2 comment in llms/__init__.py to Generic.
|
Hi @spichen, thank you for your work, we really appreciate contributions. Since this is a new feature for Agent Spec, I would ask you to check and follow the guidelines to file an RFC, you can find the instructions at https://oracle.github.io/agent-spec/26.1.0/contributing.html#submitting-a-request-for-comments-rfc. The main goal is to be able to design and review the new feature conceptually before diving into implementation. Note that the design should mainly fit Agent Spec as a language specification, while the implementation in I already gave a look at the changes in this PR, and I can give you already some hints and a first feedback that you can take into account in your design:
|
|
@cesarebernardis Thanks for the detailed feedback and for pointing me to the RFC process! I wasn't aware of it, that's why I went ahead and created the GitHub issue and draft PR to get early eyes on the idea. Totally makes sense that this should go through an RFC first. I'll get that written up. Regarding your feedback, I agree with all of it. My goal was to make the spec more flexible and extensible, which is why I was introducing additional components like AuthConfig, fallback, etc. But I think your suggestion to start simpler is the right call. We can begin with fewer options while keeping the design extendable for future iterations. On GenericLlmConfig as a parent class, that's the right approach. I actually thought about this initially, but I didn't want to override or update any existing components. Good to know that direction is welcome. I'll incorporate your hints (GenericLlmConfig as a parent class, sticking with LlmGenerationConfig, dropping AuthConfig in favor of an optional api_key, and skipping fallback/LlmEndpoint for now) into the RFC design. Thanks again for taking the time to review, really helpful to have this direction early on. |
Resolves #104