Replies: 1 comment
-
|
Assistants in Marvin can be powerful. Here are some thoughts on patterns and features: Assistant State Managementfrom dataclasses import dataclass, field
from typing import Dict, Any, List, Optional
import json
@dataclass
class AssistantState:
# Conversation context
conversation_id: str
messages: List[Dict] = field(default_factory=list)
# Persistent memory
user_preferences: Dict[str, Any] = field(default_factory=dict)
learned_facts: Dict[str, Any] = field(default_factory=dict)
# Session state
current_task: Optional[str] = None
pending_actions: List[Dict] = field(default_factory=list)
def add_message(self, role: str, content: str):
self.messages.append({
"role": role,
"content": content,
"timestamp": datetime.utcnow().isoformat()
})
def remember(self, key: str, value: Any):
self.learned_facts[key] = {
"value": value,
"learned_at": datetime.utcnow().isoformat()
}
def get_context_window(self, max_messages: int = 10) -> List[Dict]:
return self.messages[-max_messages:]Multi-Turn Conversation Handlerclass ConversationalAssistant:
def __init__(self, marvin_agent):
self.agent = marvin_agent
self.states: Dict[str, AssistantState] = {}
async def chat(self, conversation_id: str, user_input: str) -> str:
# Get or create state
if conversation_id not in self.states:
self.states[conversation_id] = AssistantState(
conversation_id=conversation_id
)
state = self.states[conversation_id]
state.add_message("user", user_input)
# Build context
context = self._build_context(state)
# Get response
response = await self.agent.run(
f"{context}\n\nUser: {user_input}"
)
state.add_message("assistant", response)
return response
def _build_context(self, state: AssistantState) -> str:
recent = state.get_context_window(5)
return "\n".join([
f"{m["role"]}: {m["content"]}"
for m in recent
])Ideas for Enhancement
More patterns: https://github.com/KeepALifeUS/autonomous-agents |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Over the past days I've spent a lot of time building what I would consider a fairly complex multi assistant system with marvin Applications and I wanted to share a few thoughts, insights and shortcomings of the current state. This is not meant as criticism but food for thought and I would be very interested in getting some feedback.
First of all, I see marvin with all its features as a high level OpenAI API that makes things simpler and semantically closer to how developers think. For example, the concept and execution of the AI function is just 🤌. I definitely had this moment of "Yes, that's what the interaction always should have been". Anyway, for Assistants and Applications, I'm not entirely sure that the same can be said about the current implementation. I found myself going back to the native OpenAI SDK because it was more straight forward.
Assistants vs. Applications
I'm not convinced the naming and mental model for Applications is great. I don't think they should be called Applications or even exist in the first place. I think a nicer and cleaner way to go about it, would be to allow assistants to have an optional State parameter, which would then also add the necessary update_state tool and additional prompt. I see what you wanted to do with the application idea, but I think calling it an assistant better describes what it is and what it does.
Persistence
Applications add the idea of persistence and state, but they don't persist anything really. The state exists in the runtime of the variable but once that's gone, so is the state. Loading the respective thread doesn't bring back the state either. It's just gone. I found this cool project, which adds the persistence by using the currently unused metadata field of the assistant. It feels like a hack and is limited to 16 512 byte entries, but I believe it would be a great addition to the marvin assistant/application. On top of that, it should be considered to add an "easy" way of connecting the state to a local database or JSON file to really persist the information the application collected.
{ "thread_CE3QsgNJIelGq4vedG5ZxUGA": { "todos": [ { "name": "Visit the store", "done": false } ] } }Real World vs. Toy App
If you build a small local demo using the interactive
chat()function or CLI tool that marvin provides, the experience is excellent. However, I believe that most real world applications won't benefit from that. For example, I'd be much more interested in integrating marvin applications/assistants into web servers like fastAPI. It's not impossible or even super complicated to do that now, but I think if my vision of marvin is correct, it should be made a lot easier. Imagine something like:This would be dope. It would have generated endpoints like this:
Assistants & Thread
I think for the OpenAI SDK it makes a lot of sense to separate the assistant from the thread, but in a higher level tool like marvin, I'm not sure that's true. Have you considered baking an optional
thread_idinto the assistant? I think that would make the interaction a bit cleaner.Alright, that's it for now! Happy to discuss these ideas!
Beta Was this translation helpful? Give feedback.
All reactions