mirror of
https://github.com/microsoft/agent-framework.git
synced 2026-06-16 21:04:09 +08:00
1e350ea22f
* PR2: Wire context provider pipeline and update all internal consumers - Replace AgentThread with AgentSession across all packages - Replace ContextProvider with BaseContextProvider across all packages - Replace context_provider param with context_providers (Sequence) - Replace thread= with session= in run() signatures - Replace get_new_thread() with create_session() - Add get_session(service_session_id) to agent interface - DurableAgentThread -> DurableAgentSession - Remove _notify_thread_of_new_messages from WorkflowAgent - Wire before_run/after_run context provider pipeline in RawAgent - Auto-inject InMemoryHistoryProvider when no providers configured * fix: update all tests for context provider pipeline, fix lazy-loaders, remove old test files * refactor: update all sample files for context provider pipeline (AgentThread→AgentSession, ContextProvider→BaseContextProvider) * fix: update remaining ag-ui references (client docstring, getting_started sample) * fix: make get_session service_session_id keyword-only to avoid confusion with session_id * refactor: rename _RunContext.thread_messages to session_messages * refactor: remove _threads.py, _memory.py, and old provider files; migrate devui to use plain message lists * rename: remove _new_ prefix from test files * refactor: rewrite SlidingWindowChatMessageStore as SlidingWindowHistoryProvider(InMemoryHistoryProvider) * fix: read full history from session state directly instead of reaching into provider internals * fix: update stale .pyi stubs, sample imports, and README references for new provider types * fix: remove stale message_store, _notify_thread_of_new_messages, and session_id.key references in samples * refactor: merge context_providers and sessions sample folders into sessions, remove aggregate_context_provider * refactor: UserInfoMemory stores state in session.state instead of instance attributes * feat: add Pydantic BaseModel support to session state serialization Pydantic models stored in session.state are now automatically serialized via model_dump() and restored via model_validate() during to_dict()/from_dict() round-trips. Models are auto-registered on first serialization; use register_state_type() for cold-start deserialization. Also export register_state_type as a public API. * fix mem0 * Update sample README links and descriptions for session terminology - Replace 'thread' with 'session' in sample descriptions across all READMEs - Update file links for renamed samples (mem0_sessions, redis_sessions, etc.) - Fix Threads section → Sessions section in main samples/README.md - Update tools, middleware, workflows, durabletask, azure_functions READMEs - Update architecture diagrams in concepts/tools/README.md - Update migration guides (autogen, semantic-kernel) * Fix broken Redis README link to renamed sample * Fix Mem0 OSS client search: pass scoping params as direct kwargs AsyncMemory (OSS) expects user_id/agent_id/run_id as direct kwargs, while AsyncMemoryClient (Platform) expects them in a filters dict. Adds tests for both client types. Port of fix from #3844 to new Mem0ContextProvider. * Fix rebase issues: restore missing _conversation_state.py and checkpoint decode logic - Add back _conversation_state.py (encode/decode_chat_messages) lost in rebase - Fix on_checkpoint_restore to decode cache/conversation with decode_chat_messages - Fix on_checkpoint_restore to use decode_checkpoint_value for pending requests - Add tests/workflow/__init__.py for relative import support - Fix test_agent_executor checkpoint selection (checkpoints[1] not superstep) * Add STORES_BY_DEFAULT ClassVar to skip redundant InMemoryHistoryProvider injection Chat clients that store history server-side by default (OpenAI Responses API, Azure AI Agent) now declare STORES_BY_DEFAULT = True. The agent checks this during auto-injection and skips InMemoryHistoryProvider unless the user explicitly sets store=False. * Fix broken markdown links in azure_ai and redis READMEs * Fix getting-started samples to use session API instead of removed thread/ContextProvider API * updates to workflow as agent * fix group chat import * Rename Thread→Session throughout, fix service_session_id propagation, remove stale AGUIThread - Fix: Propagate conversation_id from ChatResponse back to session.service_session_id in both streaming and non-streaming paths in _agents.py - Rename AgentThreadException → AgentSessionException - Remove stale AGUIThread from ag_ui lazy-loader - Rename use_service_thread → use_service_session in ag-ui package - Rename test functions from *_thread_* to *_session_* - Rename sample files from *_thread* to *_session* - Update docstrings and comments: thread → session - Update _mcp.py kwargs filter: add 'session' alongside 'thread' - Fix ContinuationToken docstring example: thread=thread → session=session - Fix _clients.py docstring: 'Agent threads' → 'Agent sessions' * Fix broken markdown links after thread→session file renames * fix azure ai test
70 lines
3.6 KiB
Markdown
70 lines
3.6 KiB
Markdown
# Custom Agent and Chat Client Examples
|
|
|
|
This folder contains examples demonstrating how to implement custom agents and chat clients using the Microsoft Agent Framework.
|
|
|
|
## Examples
|
|
|
|
| File | Description |
|
|
|------|-------------|
|
|
| [`custom_agent.py`](custom_agent.py) | Shows how to create custom agents by extending the `BaseAgent` class. Demonstrates the `EchoAgent` implementation with both streaming and non-streaming responses, proper session management, and message history handling. |
|
|
| [`custom_chat_client.py`](../../chat_client/custom_chat_client.py) | Demonstrates how to create custom chat clients by extending the `BaseChatClient` class. Shows a `EchoingChatClient` implementation and how to integrate it with `Agent` using the `as_agent()` method. |
|
|
|
|
## Key Takeaways
|
|
|
|
### Custom Agents
|
|
- Custom agents give you complete control over the agent's behavior
|
|
- You must implement both `run()` for both the `stream=True` and `stream=False` cases
|
|
- Use `self._normalize_messages()` to handle different input message formats
|
|
- Store messages in `session.state` to properly manage conversation history
|
|
|
|
### Custom Chat Clients
|
|
- Custom chat clients allow you to integrate any backend service or create new LLM providers
|
|
- You must implement `_inner_get_response()` with a stream parameter to handle both streaming and non-streaming responses
|
|
- Custom chat clients can be used with `Agent` to leverage all agent framework features
|
|
- Use the `as_agent()` method to easily create agents from your custom chat clients
|
|
|
|
Both approaches allow you to extend the framework for your specific use cases while maintaining compatibility with the broader Agent Framework ecosystem.
|
|
|
|
## Understanding Raw Client Classes
|
|
|
|
The framework provides `Raw...Client` classes (e.g., `RawOpenAIChatClient`, `RawOpenAIResponsesClient`, `RawAzureAIClient`) that are intermediate implementations without middleware, telemetry, or function invocation support.
|
|
|
|
### Warning: Raw Clients Should Not Normally Be Used Directly
|
|
|
|
**The `Raw...Client` classes should not normally be used directly.** They do not include the middleware, telemetry, or function invocation support that you most likely need. If you do use them, you should carefully consider which additional layers to apply.
|
|
|
|
### Layer Ordering
|
|
|
|
There is a defined ordering for applying layers that you should follow:
|
|
|
|
1. **ChatMiddlewareLayer** - Should be applied **first** because it also prepares function middleware
|
|
2. **FunctionInvocationLayer** - Handles tool/function calling loop
|
|
3. **ChatTelemetryLayer** - Must be **inside** the function calling loop for correct per-call telemetry
|
|
4. **Raw...Client** - The base implementation (e.g., `RawOpenAIChatClient`)
|
|
|
|
Example of correct layer composition:
|
|
|
|
```python
|
|
class MyCustomClient(
|
|
ChatMiddlewareLayer[TOptions],
|
|
FunctionInvocationLayer[TOptions],
|
|
ChatTelemetryLayer[TOptions],
|
|
RawOpenAIChatClient[TOptions], # or BaseChatClient for custom implementations
|
|
Generic[TOptions],
|
|
):
|
|
"""Custom client with all layers correctly applied."""
|
|
pass
|
|
```
|
|
|
|
### Use Fully-Featured Clients Instead
|
|
|
|
For most use cases, use the fully-featured public client classes which already have all layers correctly composed:
|
|
|
|
- `OpenAIChatClient` - OpenAI Chat completions with all layers
|
|
- `OpenAIResponsesClient` - OpenAI Responses API with all layers
|
|
- `AzureOpenAIChatClient` - Azure OpenAI Chat with all layers
|
|
- `AzureOpenAIResponsesClient` - Azure OpenAI Responses with all layers
|
|
- `AzureAIClient` - Azure AI Project with all layers
|
|
|
|
These clients handle the layer composition correctly and provide the full feature set out of the box.
|