feat(dsl,nodes): support agent_strategy plugin invocation

[BenjaminX]

Summary

Implements the two integration surfaces flagged in RFC #102 so external integrators can drive Dify chatflows containing agent nodes through graphon.dsl.loads.

• PR-A — dsl/slim learns the invoke_agent_strategy slim action via a new SlimAgentStrategyClient. Reuses ToolRuntimeMessage as the wire DTO because the Dify Plugin SDK defines AgentInvokeMessage(InvokeMessage): pass — wire format is identical, the tool-side decoder is shared.
• PR-B — Adds AgentNode, AgentNodeRuntimeProtocol, and SlimAgentNodeRuntime; routes BuiltinNodeTypes.AGENT through SlimDslNodeFactory. Mirrors the structure of ToolNode / SlimToolNodeRuntime.
• Example — Adds examples/chatflow_dsl_runner, a canonical downstream-integration pattern using graphon.dsl.loads against a real Dify Studio chatflow export. Two fixtures bundled: one runs out of the box, one documents a known limitation (see below).
• Chore — Bumps the pinned openai plugin in examples/slim_llm from 0.3.8 to 0.4.0 to align with the new chatflow example.

What's new

• src/graphon/dsl/slim/agent.py — SlimAgentStrategyClient, SlimAgentStrategyError, AgentRuntimeMessage alias, SlimActionInvoker DI seam.
• src/graphon/dsl/agent_runtime.py — SlimAgentNodeRuntime (AgentNodeRuntimeProtocol), mirrors SlimToolNodeRuntime.
• src/graphon/dsl/_provider.py — extracted shared canonical_vendor helper (deduped from node_factory.py).
• src/graphon/nodes/agent/{agent_node.py, entities.py, exc.py} — AgentNode, AgentNodeData (typed-wrapper agent_parameters), AgentParameterValue, AgentNodeError.
• src/graphon/nodes/runtime.py — new AgentNodeRuntimeProtocol.
• src/graphon/dsl/{node_factory.py, importer.py} — route BuiltinNodeTypes.AGENT; add to _SUPPORTED_DEFAULT_FACTORY_NODES.
• examples/chatflow_dsl_runner/ — main.py (CLI with inspect() / loads() / event streaming), chatflow_dsl_simple.yml (runnable), chatflow_dsl_agent.yml (reference fixture, see limitations), README.md, credentials.example.json.

Out of scope (deliberate)

tenant_id / user_id are intentionally not propagated through the slim runtime. When an agent strategy plugin does self.session.model.llm.invoke(...), the daemon currently performs backwards-invocation against the Dify Server inner API at :5001, which requires a tenant context. Teaching graphon to forward tenant_id / user_id would leak Dify's business-side identity model into a tenant-agnostic execution engine.

The correct long-term fix is the daemon redesign outlined in the RFC #102 "long-term direction" — let plugin code perform nested invocations without depending on Dify Server's inner API. Until that lands, chatflow_dsl_agent.yml ships as a structural reference (this is what a real Dify Studio export of a chatflow with an agent looks like) but cannot run end-to-end from a graphon-only runner. chatflow_dsl_simple.yml is the runnable out-of-box fixture.

This trade-off is documented in examples/chatflow_dsl_runner/README.md#architecture--limitations.

Test plan

• pytest tests/ — 348 passed (28 new tests across test_slim_agent.py, test_agent_node.py, test_slim_agent_node_runtime.py, test_node_factory_agent.py).
• make tc — ruff format + check + ty all green.
• Local end-to-end: python3 examples/chatflow_dsl_runner/main.py chatflow_dsl_simple.yml "Say hi in 5 words." streams a real LLM response from langgenius/openai:0.4.0.
• CI run on this PR. Unit tests use a fake action_invoker injection seam — no e2e slim-binary tests on CI by design.

Open questions for reviewers

1. PR scope — RFC RFC: Slim runtime support for agent_strategy and tool plugin invocation #102 originally split the work into PR-A (slim) and PR-B (node). They're bundled here because PR-B is hard to verify without PR-A and the example is the smallest end-to-end witness we have. Happy to split into stacked PRs if preferred — the three commits (984a416 slim+node, 23855bd example, f439196 slim_llm bump) are natural boundaries.
2. AgentRuntimeMessage = ToolRuntimeMessage alias — keeps a semantic name so future agent-only message variants can diverge, while structurally reusing the tool DTO and decoder. Alternative is to inline ToolRuntimeMessage at the agent call sites. The reasoning is in a comment at src/graphon/dsl/slim/agent.py:15.
3. AgentNode.version() → "1" — matches the start / llm / tool convention. Distinct from tool_node_version: "2" in AgentNodeData, which is the Dify plugin protocol version forwarded verbatim to the strategy plugin.
4. chatflow_dsl_agent.yml placement — kept under examples/ with a README disclaimer rather than tests/fixtures/ because it doubles as documentation for the architecture limitation. Open to relocation if examples/ is meant to be strictly run-out-of-box.
5. slim_llm openai bump (f439196) — kept as a separate commit; trivially droppable from this PR if maintainers prefer it as a follow-up chore.

References

• RFC: RFC: Slim runtime support for agent_strategy and tool plugin invocation #102

[github-actions]

All contributors on this pull request have signed the CLA.
_{Posted by the CLA Assistant Lite bot.}

[BenjaminX]

I have read the CLA Document and I hereby sign the CLA

[WH-2099]

Hi @BenjaminX, thank you very much for the thoughtful work here and for the detailed RFC/prototype. I am sorry for the delayed conclusion.

After aligning our DSL import roadmap in #154, we have decided not to support the agent node in Graphon in the short term. The main reason is that the runtime boundary for Dify agent execution is still changing: agent strategies may require nested model/tool invocation and control-plane context that we do not want to model in Graphon right now.

Because of that, we are going to close this PR and the related RFC issue for now. This is not a reflection on the quality of your contribution; the implementation and tests gave us useful reference points, and we appreciate the time you put into it.

To share a little more context: internally, we are about to start a larger refactor of Dify's agent node/runtime design. We expect that work to change the right integration surface for agent execution, so landing AgentNode support now would likely create churn for both maintainers and downstream users.

Apologies again for the back-and-forth, and thank you for pushing this area forward. Once the agent refactor direction is clearer, we would be happy to revisit the support path with a more stable boundary.

[BenjaminX]

Hi @BenjaminX, thank you very much for the thoughtful work here and for the detailed RFC/prototype. I am sorry for the delayed conclusion.

After aligning our DSL import roadmap in #154, we have decided not to support the agent node in Graphon in the short term. The main reason is that the runtime boundary for Dify agent execution is still changing: agent strategies may require nested model/tool invocation and control-plane context that we do not want to model in Graphon right now.

Because of that, we are going to close this PR and the related RFC issue for now. This is not a reflection on the quality of your contribution; the implementation and tests gave us useful reference points, and we appreciate the time you put into it.

To share a little more context: internally, we are about to start a larger refactor of Dify's agent node/runtime design. We expect that work to change the right integration surface for agent execution, so landing AgentNode support now would likely create churn for both maintainers and downstream users.

Apologies again for the back-and-forth, and thank you for pushing this area forward. Once the agent refactor direction is clearer, we would be happy to revisit the support path with a more stable boundary.

I also saw the Dify main repository, which refactored the Agent runtime. Are there any refactoring plans and roadmaps for this new Agent runtime?