[Question]: some questions

[zx9597446]

What is your question?

I really like the design of this project, the KISS principle, simplicity, etc. Here are some minor suggestions:

1. Documentation: When adding the mcp tool, please include

env:
VAR: VAL

to avoid user confusion.

2. Can built-in variables be added for LANG LOCATION (maybe)?

3. It is recommended to add i18n support for prompts, etc.

4. Can you add some more useful examples? For example: deep research, [https://github.com/benhaotang/OpenDeepResearcher-via-searxng]

5. Still testing the search agent, sometimes it works well. I have a question here: why not use a workflow? Would it be more stable if a workflow was used?

[evilsocket]

I wish I could offer you a beer one day :D

1. doc: 100%, i'm working on the agent as an mcp server right now and will 100% add it to the docs
2. LANG -> great idea! LOCATION -> i need to think about it for privacy reasons and stuff ... let me figure it out ;)
3. will look into it, thanks
4. any specific agent (other than the searxng, that could be a generalization of the "search" agent) you'll like?
5. maybe? how would you structure the workflow? i'm actually thinking to refactor completely the workflow logic to leverage the agent-as-mcp-server ... so that you'll have one root agent using the other sub agents via mcp ... thoughts?

By the way, you're more than welcome to join the Nerve discord channel here -> https://discord.gg/kWW8ZceA

[zx9597446]

My initial goal was to find a deep research project similar to Google Deep Research, or like https://github.com/benhaotang/OpenDeepResearcher-via-searxng, that could be run locally. After testing a large number of projects, I found that most of them don't work very well for various reasons. Some are due to search engine rate limits, and some are due to unstable fetch-to-markdown functionality.

After discovering this project, I thought it might be possible to implement deep research or deep search like building blocks, even though these two are slightly different.

Regarding the workflow, although I haven't figured out your design and implementation yet, as far as I know, it should only be sequential execution?

From my expectations, the workflow design I would like to see should have roughly the following types (from a high-level view):

1. Sequential execution, just like what you've done.

2. Branching, switch or router or selector, switch to different agents.

3. Iteration, can iterate N times, with the current input being the output of the previous iteration.

4. Parallel processing, receive an array input, execute in parallel, and then aggregate into a single output.

Special attention should be paid to the context window. Users should decide whether the current node (agent) should see the global context window. This allows some small local models to handle simple, repetitive tasks without needing to see the global context window, while larger, smarter models can handle more complex tasks.

These are just some rough ideas.

Although you can implement MCP as a server, I think you still need some way to combine these agents (or nodes) together to solve more complex real-world problems.

One idea is to use something similar to a bash script (based on simple command-line usage):

pipe commands together: for example:

echo "user query" | nerve run search | nerve run agent1

And the shell script already has enough flow control.

For some other users (not that geeky), they can combine and implement the functions they need through built-in flow control.

Also, regarding the workflow, maybe YAML isn't a very good way to describe it? Especially if you want to implement flow control?

Just some ideas, I haven't thought carefully about how to implement them, for reference only.

[evilsocket]

Great ideas! I want to think about them for a while and see what solutions come to mind :D

In the meantime, I'll show you how I reimplemented the recipe workflow via MCP serving, check this out. The root agent (what otherwise would be the sequential workflow) now looks like this, while the sub agents are the same:

This already works like a charm, and the order of execution can be semi-controlled via the prompt of the root agent.

A slightly more complex example I'm still working on:

[evilsocket]

(this is on a local branch i'm working on, not pushed yet)

[evilsocket]

When serving as MCP server, the inputs for each agent are automatically parsed from its contents, and the output too is parsed from the worker output state, so it works pretty smoothly without complicating things.

Of course this can be served as MCP stdout server, or with SSE or via REST API:

[zx9597446]

what about built in print tools? and built in write to file maybe ?

[evilsocket]

@zx9597446 what do you mean with print tools, actual printing to paper? for the file write, check filesystem_w namespace ;)

[zx9597446]

I saw your screenshot. It just prints a result, but it requires defining so many things. From a user's perspective, this kind of thing could be considered built-in. Maybe I misunderstood. Perhaps a default end node?

There are also some implicit limitations when using mcp, for example, consider this situation: I only want to use a "curl" command to fetch a very large page and write it to a file. In this case, it is easy to blow up the context window, and at the same time, the content needs to be passed to the LLM and then to the filesystem to write. This situation is a waste of tokens.