MVP of ACS plus initial port of CLI to new ACS abstractions#91
MVP of ACS plus initial port of CLI to new ACS abstractions#91andyk merged 13 commits intoagentos-project:masterfrom
Conversation
- agentos {init, train, test}
- agent.ini file
- functional basic agent
|
Updated this PR to remove the Trainer abstraction. |
|
Made some more progress on porting the core and CLI to the new abstractions. |
|
Can you link to the design discussion thread in the first comment of this PR conversation? |
|
Added a first cut at |
andyk
left a comment
There was a problem hiding this comment.
This looks like a good first step towards a 0.0.8. Do we want to cut 0.0.7 before we merge this into master?
| @@ -1,16 +1,31 @@ | |||
| """Implementation of agents available in AgentOS. See core.py for Agent API.""" | |||
There was a problem hiding this comment.
Should we get rid of the agents module entirely and instead have a them available via the registry?
There was a problem hiding this comment.
Yeah, this makes sense. Maybe we punt on it for now because the tests use this at the moment?
| raise NotImplementedError | ||
|
|
||
|
|
||
| def run_agent(agent, hz=40, max_iters=None, as_thread=False): |
There was a problem hiding this comment.
Maybe we should write down some user stories for the agentos.run_agent() helper function now that we have shifted towards an agent being defined by an agent.ini?
There was a problem hiding this comment.
I think we talked about this before, but I forget where we came down on it: are we thinking we'll keep agentos.run_agent()?
Either way seems reasonable to me. An initial stab at a user story:
Agent developer incorporating RL into their tech stack
As a developer incorporating RL into my tech stack, I need to run experiments with different agent configurations to determine what flavor of RL is best suited to the business problem my work is addressing. Being able to programmatically interact with agents allows me to run these experiments as well as train and deploy my agent in a reproducible way.
There was a problem hiding this comment.
Yeah, I like sticking to a guiding philosophy where anything you can do from the CLI you can also do via Python API and vice versa.
Good user story, should we add it to the design doc w/ the others?
There was a problem hiding this comment.
Yeah, I like sticking to a guiding philosophy where anything you can do from the CLI you can also do via Python API and vice versa.
SGTM!
I'll add it to the design doc.
port some example agents, fix bug in core
Just checking that I understand this proposal:
is that right? If so, sounds good to me! |
Yeah, this is what I was thinking with one more step before these that you listed being: @trush to review and [if/when it's ready] merge #93 |
I propose we update the version to 0.1.0-alpha because it will change core abstractions quite a bit |
|
@andyk branch and versioning plan sounds good to me! |
|
97014da adds the ability to install 2048 via the agentos CLI. Demo updated. |
Initial (rough) port of
agentos {init, train, test}command-line tools to the new abstractions. Issuing this PR in case you all want to start writing code against these changes.See design discussion here.
Demo
Limitations
This is a very rough first stab, some limitations:
I assume you will be running these commands within the agent directory (and don't support specifying customagent.iniyet)trainandrunnow support a-fflag to specify theagent.inito use.onetwo of the tests (😬). They'll come back online as we port example agents andrun_agentto the new abstractions.I addedagentos test(instead of modifyingagentos run)Next step
I'd like to portrun_agent(and the dependent tests) to the new abstractions. Thoughts?action_spaceandobservation_spaceinPolicy