langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 12:05:30 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[PR #32332] feat: implement Plan Hydration Engine for Agent Nodes to reduce costs and latency (#32306) #33680

New Issue
Open
opened 2026-02-21 20:53:42 -05:00 by yindo · 0 comments
yindo commented 2026-02-21 20:53:42 -05:00
Owner
Copy Link
Copy Source

Original Pull Request: https://github.com/langgenius/dify/pull/32332

State: open
Merged: No

Fixes #32306

This PR implements the EROS (Efficiency-driven Reasoning Optimization System) for Agent Nodes** (ReAct/Function Calling).

Currently, the Agent Node operates statelessly. For repetitive enterprise workflows, the LLM must re-reason and reconstruct execution graphs from scratch on every run, leading to high latency (10-20s) and redundant token expenditure. This implementation introduces an Episodic Plan Cache that allows the system to recognize previously solved problems and execute them with deterministic precision.

Key Changes
I have shifted the FCAgentRunner and BaseAgentRunner from a "cold-start" model to a 3-Layer Hydration Architecture:

Layer 1: Intent Fingerprinting (Short-Circuit): Generates a deterministic hash of the Task Description + Tool Definitions + Agent Instructions. If a high-confidence match exists, the agent "hydrates" the previous execution plan and skips the initial reasoning loops entirely.

Layer 2: Contextual Hybrid Welding (Warm Start): For partial matches, the engine injects proven reasoning paths into the context, guiding the LLM toward a "Gold Path" tool sequence without redundant exploration.

Layer 3: Recursive Verification (Validation): A post-execution audit ensures only successful, non-hallucinatory outcomes are committed to the episodic cache, maintaining high-fidelity plan integrity.

Volatile State Management: Ensured fresh variable initialization during hydration to prevent context pollution (consistent with recent executor state fixes in the ecosystem).

Technical Components
Engine: api/core/agent/plan-hydration/engine.py handles the core logic.

Integration: Updates to BaseAgentRunner and FCAgentRunner to support the hydration lifecycle.

Tests: Unit tests added in api/tests/unit_tests/core/agent/test_plan_hydration.py to verify fingerprinting and retrieval.

Documentation: Internal README.md added to the module for maintainer clarity.

Checklist
[x] This change requires a documentation update, included: [Internal Module README]

[x] I understand that this PR may be closed in case there was no previous discussion or issues.

[x] I've added a test for each change that was introduced.

[x] I've updated the documentation accordingly.

[x] I ran make lint and make type-check (backend) to verify code quality.

[x] License headers (MIT) included in all new files.

**Original Pull Request:** https://github.com/langgenius/dify/pull/32332 **State:** open **Merged:** No --- **Fixes #32306** This PR implements the **EROS (Efficiency-driven Reasoning Optimization System) for Agent Nodes**** (ReAct/Function Calling). Currently, the Agent Node operates statelessly. For repetitive enterprise workflows, **the LLM must re-reason and reconstruct execution graphs from scratch on every run, leading to high latency (10-20s) and redundant token expenditure.** This implementation introduces an Episodic Plan Cache that allows the system to recognize previously solved problems and execute them with deterministic precision. **Key Changes** I have shifted the FCAgentRunner and BaseAgentRunner from a "cold-start" model to a 3-Layer Hydration Architecture: Layer 1: Intent Fingerprinting (Short-Circuit): Generates a deterministic hash of the Task Description + Tool Definitions + Agent Instructions. If a high-confidence match exists, the agent "hydrates" the previous execution plan and skips the initial reasoning loops entirely. Layer 2: Contextual Hybrid Welding (Warm Start): For partial matches, the engine injects proven reasoning paths into the context, guiding the LLM toward a "Gold Path" tool sequence without redundant exploration. Layer 3: Recursive Verification (Validation): A post-execution audit ensures only successful, non-hallucinatory outcomes are committed to the episodic cache, maintaining high-fidelity plan integrity. Volatile State Management: Ensured fresh variable initialization during hydration to prevent context pollution (consistent with recent executor state fixes in the ecosystem). **Technical Components** Engine: api/core/agent/plan-hydration/engine.py handles the core logic. Integration: Updates to BaseAgentRunner and FCAgentRunner to support the hydration lifecycle. Tests: Unit tests added in api/tests/unit_tests/core/agent/test_plan_hydration.py to verify fingerprinting and retrieval. Documentation: Internal README.md added to the module for maintainer clarity. **Checklist** [x] This change requires a documentation update, included: [Internal Module README] [x] I understand that this PR may be closed in case there was no previous discussion or issues. [x] I've added a test for each change that was introduced. [x] I've updated the documentation accordingly. [x] I ran make lint and make type-check (backend) to verify code quality. [x] License headers (MIT) included in all new files.
yindo added the pull-request label 2026-02-21 20:53:42 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#33680
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?