--- title: Text Adventure Agent emoji: ⚡ colorFrom: purple colorTo: pink sdk: gradio sdk_version: 6.5.1 app_file: app.py pinned: false --- Check out the configuration reference at https://huggingface.co/docs/hub/spaces-config-reference --- title: Text Adventure Agent emoji: ⚡ colorFrom: purple colorTo: pink sdk: gradio sdk_version: 6.5.1 app_file: app.py pinned: false --- Check out the configuration reference at https://huggingface.co/docs/hub/spaces-config-reference # Report Zork Project ## Contributions Here is a short report for the Zork project. I will first list all my contributions for the agent and the MCP server and I will detail them further later on : **For the agent** : - Enriched prompt using baseline-provided information (look, listen, inventory,...) - Improved history of action in prompt - Simplified action calling to the MCP server - Overall prompt engineering - Ask the agent to list all possible moves in the situation **For the MCP server** : - Removed useless commands that can be directly included in-prompt (look, listen, inventory,...) - Improved, look-based "map" system as a location_based history ## More details on the implemented features ### Additional information in prompt Some actions, whether they are provided by the baseline or directly by the environment, are always useful for the decision-making process of the agent. Because of this, instead of relying on direct calls (and so useless actions), I decided to incorporate directly such information (look, listen, inventory, get_map), directly into the prompt. Although the prompt is longer, the agent has a better perception of its world and thus achieves better results. ### Improved history of action In the baseline, the history provided to the agent in the prompt are the three last actions together with their results, cropped after 80 characters. This very short history hindered the agent's performance, making it more enclined to do the same action repetitively (because its effectively had a 3 moves memory). To correct this, I extended a lot the history (to 30 moves), with adapted results length based on how ancient the move is. Here are the involved variables : ``` base_reason_size = 100 short_reason_size = 40 base_size_threshold = 3 short_size_threshold = 10 action_threshold = 30 ``` ### Simplified action calling Because the agent now doesn't rely directly on baseline-provided tools when outputting an action, it can directly output the argument of play_action, making it less likely for the agent to make the mistake (it actually happened quite a few times during testing.) ### Overall prompt engineering Based on experiments, (mainly on LostPig, Zork1 and 9:05), here are the things I added/modified in the prompt: - Encourage exploration much more - Avoid examining random things - Give a more detailed list of action, not provided in the baseline prompt (listen or ask for instance) - Added more exmamples of results for better ICL - Avoid repetition by paying attention to the location-based history. ### List all actions Because the agents had a tendancy to ignore actions that would seem obvious and beneficial, ask the agents to list every possibly interesting action before the chain of though process. ### Better "Map" system The map system provided by the baseline was not resilient enough for the 57 games and provided little to no information on games other than zork-like environments. Instead, I designed a "map" system based on the result of the command `look`. Even though the same location can have different `look` results (if an object is taken for instance), it still helps the agent for navigation and repetition. Because the `look`'s result is far longer than a simple location name, instead of building a litteral map, I built a location-based history. Meaning that the agent has access to all the previous actions done in this exact `look` state. The enables the agent to explore all directions and try new things. ## Ideas I didn't have time to try Here are some ideas I would I've liked to try : - Better map system : build a real map system, using for instance an LLM call on the `look` result in order to deduce a precise location name, that can the nbe used with the baseline map system - Planning agent : in such a situation, a multi-agent configuration could work, for instance adding a planning agent to the already existing action agent, in order to keep long-term goals and strategies - Adding a "go-to" system : based on the map system, a go-to command could be added to the MCP server, enabling the agent to go to a previously visited location automatically, by simply calling all the directions stored in the map without agent's intervention. This could simplify navigation and avoiding clutter in history