PEARL: Process-Experience Aware Reinforcement Learning for Multi-Turn Agents
Organizations: Fudan University · Shanghai Innovation Institute
Abstract
Terminal rewards make multi-turn agents trainable without step-level annotations, but group-relative advantages provide little guidance about which intermediate decisions to adjust. Failed trajectories also contain reasonable actions, while unfavorable decision patterns can recur as training proceeds. We introduce PEARL (Process-Experience Aware Reinforcement Learning), which improves local credit assignment without an additional critic. Given two continuations from the same history with different outcomes, PEARL locates their first divergence and builds a feature representation of each branch's local decision. It clusters these decision features in recent failure and success memories to identify recurring local patterns. Using this pattern memory, PEARL selectively strengthens negative advantages at lower-reward decisions, while leaving positive advantages and the base policy optimizer unchanged. On AppWorld, PEARL improves over ARPO on Normal and Challenge tasks at both 4B and 8B scales. On ALFWorld, it achieves 97.9% mean success at 4B, 2.7 points above the strongest baseline, while remaining competitive at 8B. Ablations of shaping location, success-bank filtering, and memory window support the value of selective, recurring-pattern-based updates.
Figures & tables
| AppWorld | ALFWorld | |||||
| Method | Normal | Challenge | Mean | Seen | Unseen | Mean |
| Qwen3-4B-Instruct-2507 | ||||||
| Base Model | 8.93 | 5.60 | 7.26 | 38.1 | 33.1 | 35.6 |
| GRPO | 52.38 0.79 | 24.38 0.16 | 38.38 0.48 | 94.9 2.8 | 94.3 5.7 | 94.6 4.2 |
| ARPO | 53.37 2.18 | 29.02 2.56 | 41.19 2.37 | 95.1 0.4 | 92.3 0.8 | 93.7 0.2 |
| GiGPO | 44.84 4.76 | 24.02 0.52 | 34.43 2.64 | 96.0 2.0 | 94.4 3.4 | 95.2 2.7 |
| Cluster | Trajectory behavior and outcome |
|---|---|
| Success | Behavior 1: friends and roommates. Inspect the contact-relationship API specification; receive a valid schema. Later, collect the matching requests before denying them, and reject all 14. The trajectory succeeds. Behavior 2: siblings. Inspect the same API specification; receive a valid schema. Later, check both transaction senders and receivers and like all 8 matching transactions. The trajectory succeeds. |
| Failure | Behavior 1: friends and roommates. Inspect the same specification; receive a valid schema. Later failure: Deny requests while paging through the pending list; reject only 13 of 14, missing request 1844. Modifying the list during traversal is consistent with a pagination skip. Behavior 2: siblings. Inspect the same specification; receive a valid schema. Later failure: Check only whether the sender is a sibling, ignoring sibling receivers. Like only 2 of the 8 matching transactions. |
| Shared pattern. Inspect the contact-relationship API specification before identifying people by relationship. | |
| Memory decision. filters . The same specification-inspection behavior occurs in successful trajectories. The corresponding failure cluster is excluded from additional negative shaping. | |
| Cluster | Trajectory behavior and outcome |
|---|---|
| Success | Behavior 1: finding a cup. Observe that cabinet 1 is closed; open it to check for the cup. Action: open cabinet 1 . The cabinet is empty. The trajectory succeeds. Behavior 2: finding bread. Observe that cabinet 1 is closed; open it to check for bread. Action: open cabinet 1 . The cabinet contains a plate. The trajectory succeeds. |
| Failure | Behavior 1: finding a cup. Open the closed cabinet to check for the cup. Action: open cabinet 1 . Later failure: Cool and place a mug instead of the required cup ; then repeatedly look around or check inventory until the 50-turn limit. Behavior 2: finding a pot. Open the closed cabinet to check for the pot. Action: open cabinet 1 . Later failure: Revisit searched locations without checking stoveburner 2, where a successful trajectory finds the pot. Exhaust 50 turns without acquiring or cooling it. |
| Shared pattern. When a candidate cabinet is closed, open it to inspect its contents for the target object. | |
| Memory decision. filters . The same closed-cabinet opening behavior occurs in successful trajectories. The corresponding failure cluster is excluded from additional negative shaping. | |
Appendix figures & tables2 assets
Supplementary material from the paper’s appendix.
Appendix
| Step | Failure entries | Success entries | Retained failure clusters | Retained entries | Filtered clusters | Success clusters |
|---|---|---|---|---|---|---|
| 100 | 297 | 347 | 0 | 0 | 2 | 2 |
| 200 | 716 | 798 | 1 | 19 | 2 | 2 |
| 300 | 1106 | 1195 | 0 | 0 | 5 | 4 |
| 400 | 1368 | 1509 | 1 | 1200 | 1 | 15 |
| Environment and cluster | Audited decisions, observed responses, and bank decision |
|---|---|
| AppWorld step 200 | Delay alarm by one hour: call apis.phone.show_alarms() without an access token; the API returns HTTP 401 (missing, invalid, or expired authorization). Delay alarm by twenty minutes: make the same unauthenticated call; the API again returns HTTP 401. Matched pattern: invoke a protected API without satisfying its authentication requirement. Bank decision: retained because the success bank does not veto . |
| ALFWorld step 300 | After turning on the lamp: issue examine desklamp 1 , which is outside the admissible set; the environment replies “Invalid action.” After a rejected inspection: following a rejected look under desklamp 1 , issue examine desklamp 1 and again receive “Invalid action.” Matched pattern: use an unavailable lamp-inspection command. Bank decision: retained because no success cluster has formed to veto . |