Agent enhancements and configuration updates

[mgv99]

This pull request introduces several new action classes to support more flexible agent replies, enhances RAG (Retrieval-Augmented Generation) configuration, and improves code generation for agent assets. The changes expand the agent's ability to interact via LLM chat, web crawling, and various WebSocket reply types, while also making the agent generator more extensible and customizable.

New Action Classes and Reply Types:

• Added LLMChatReply, enabling chat-style LLM replies with optional system prompts and LLM selection.
• Introduced WebCrawlLLMReply for crawling websites and querying LLMs with the crawled content, including extensive configuration options.
• Added multiple WebSocket reply action classes: WebSocketReplyMarkdown, WebSocketReplyHTML, WebSocketReplySpeech, WebSocketReplyOptions, WebSocketReplyLocation, WebSocketReplyFile, WebSocketReplyImage, WebSocketReplyDataframe, and WebSocketReplyPlotly, covering a wide range of reply modalities.

RAG Configuration and Agent API Enhancements:

• Extended the RAG class and Agent's new_rag method to support an optional llm_prompt parameter for injecting prefix instructions before each RAG prompt. [1] [2] [3] [4] [5]
• Updated internal checks to support both LLMReply and the new LLMChatReply for validation.

Agent Generator Improvements:

• The agent generator now supports injecting a pre-rendered YAML config, generates a tools.py file for tool functions, and creates a skills/ directory with one Markdown file per skill. [1] [2] [3]
• Added utility functions for resolving RAG variable names and extracting function names to improve template logic and code generation. [1] [2]
• The agent template now conditionally imports crawl_website when needed and sets up the agent's working directory. [1] [2]

Other Notable Changes:

• Improved the CustomCodeAction class to dedent source code only when provided as a string, and to handle cases where neither source nor callable is given.
• Updated WebSocket platform initialization in the agent template to set use_ui=False by default.

These changes collectively make the agent framework more modular, extensible, and ready for richer multi-modal interactions and code generation workflows.

[ArmenSl]

Thanks for this — the converter symmetry across all the new action types is really solid.

One thing before merge: have you tested generating a full web-app with an agent end-to-end (and ideally a deploy) on this branch? A few of the changes here only surface at generate/deploy time rather than in unit tests, so I'd like to confirm they hold up:

• The new WebSocketReplyFile/Image/Dataframe/Plotly branches emit platform.reply_file(session, reply_file_obj) etc. with the target variable (reply_file_obj, reply_image_arr, reply_df, reply_plot) only defined in a # TODO comment — a generated agent that hits one of those states would NameError at runtime.
• The configYaml plumbing now threads through WebAppGenerator → collect_agents_from_diagrams (now a 3-tuple) → BAF generator. Does a web-app with an agent still build and run with both a user-supplied configYaml and the default (template-rendered) path?
• Tools/skills moved to external tools.py + skills/*.md loaded via agent.load_tools(...) / agent.load_skills(...) — does the deployed agent actually pick those up at runtime (does the BAF version in the deploy image expose those methods)?

If you've already run a web-app-with-agent generation + deployment and it works, great — just confirm and I think we're in good shape after the smaller fixes. If not, could you give that a spin? That's the path most likely to catch anything the tests don't.

[ArmenSl]

A few things I'd want sorted before this goes in:

crawl_format isn't escaped in the template. In baf_agent_template.py.j2 (~681 and 824) it's dropped straight into a single-quoted string without the replace('\','\\') | replace("'","\'") that every other string interpolation has. The default path is fine since it's always "markdown", but a hand-written or imported .buml could break out of the literal. Quick fix, same escape as the siblings.

The WebSocket File/Image/Dataframe/Plotly replies generate broken code. They emit platform.reply_file(session, reply_file_obj) etc. but reply_file_obj only exists in a # TODO comment — so the agent NameErrors as soon as it hits that state. Maybe emit a raise NotImplementedError stub instead so it fails clearly?

CustomCodeAction() with no args now sets code = None (state_machine.py), which __repr__ and the code builder's regex will choke on. Nothing calls it that way today so it's latent, but I'd just keep it as "".

Mixed bodies silently drop actions — if a body has a CustomCodeAction plus anything else, only the custom one survives. Old code had the same limit, but now that the loop handles multiple actions everywhere else it's an odd gap. Worth either rejecting mixed bodies or rendering all of them.

Last thing, more of a question than a blocker: the new actions (LLMChatReply, WebCrawlLLMReply, the WebSocket ones) and the configYaml path don't have tests yet. Given a couple of these only show up at generate/deploy time, could you add at least a codegen + round-trip case for them?