[RFC]: Agent-Aware KV Cache Support in Mooncake (Phase 1)

### Changes proposed

## Summary

This RFC proposes Phase 1 of agent-aware KV cache support in Mooncake.

The goal of this phase is to add a minimal, backward-compatible metadata path for agentic workloads so that workflow information can flow from the API layer into runtime requests and KV cache nodes, and optionally affect radix cache eviction.

This is intentionally a foundation/prototype phase, not a full workflow-aware cache system.

## Motivation

Current KV cache eviction policies (e.g., LRU, LFU, SLRU) treat requests mostly independently. That works well for standard chat/completion workloads, but it misses reuse opportunities in agentic workflows, where requests often share:

- Repeated prompt prefixes across planner/tool/worker steps
- Parent/child step relationships
- Short-term reuse after tool calls
- Workflow-level TTL or reuse intent

Without workflow-aware signals, cache entries that are likely to be reused by upcoming steps may be evicted too early, increasing latency and compute cost for LLM serving frameworks that rely on Mooncake for distributed KV cache management.

## Proposal

Phase 1 introduces:

- An optional `agent_hints` field in OpenAI-compatible requests forwarded to Mooncake
- Propagation of `agent_hints` through the internal request pipeline
- Lightweight workflow DAG tracking in the cache scheduler
- KV cache node annotation with workflow metadata
- A new optional eviction policy: `agent_aware`

Initial `agent_hints` fields include:

| Field | Type | Description |
|---|---|---|
| `workflow_id` | string | Identifies the top-level workflow |
| `agent_id` | string | Identifies the agent within the workflow |
| `step_id` | string | Unique ID for this step |
| `step_index` | int | Ordinal index of the step |
| `total_steps` | int | Total expected steps in the workflow |
| `parent_step_id` | string | ID of the parent step |
| `children_step_ids` | list[string] | IDs of child steps |
| `tool_name` | string | Name of the tool being called, if any |
| `expected_tool_duration_ms` | int | Estimated tool execution time in ms |
| `cache_ttl_ms` | int | Desired TTL for this cache entry |
| `shared_prefix_hash` | string | Hash of a known shared prompt prefix |
| `reuse_hint` | string | One of: `keep`, `discard`, `neutral` |

## Scope

Phase 1 covers:

- Request schema support for `agent_hints`
- Metadata plumbing through the cache layer
- Scheduler-side workflow DAG tracking
- Cache node metadata annotation
- A prototype workflow-aware eviction strategy

Phase 1 does **not** attempt to fully solve:

- `shared_prefix_hash`-driven prefix reuse
- HiCache / storage-layer metadata inheritance
- Cross-process workflow coordination
- Production-tuned scoring for all agent topologies

## Example

```json
{
"agent_hints": {
"workflow_id": "wf-1",
"agent_id": "planner",
"step_id": "step-1",
"children_step_ids": ["step-2"],
"cache_ttl_ms": 60000,
"reuse_hint": "keep"
}
}

### Before submitting a new issue...

- [ ] Make sure you already searched for relevant issues and read the [documentation](https://kvcache-ai.github.io/Mooncake/)

No source files, tests, or concrete entry points are named. Start by reading this RFC and tracing the OpenAI-compatible request path, internal runtime requests, cache scheduler, and KV cache node metadata; done would require an agreed Phase 1 design and implementation for the listed metadata and eviction-policy scope.

Written by the indexing model from the issue text.