一个重要的实现细节是：Agent 状态栏在 API 层面实际上是作为**一条 user 角色的消息**插入到上下文末尾的——而不是修改开头的 system 消息。原因正是前面讨论的 KV Cache 约束：修改 system 消息会破坏整个前缀的缓存。这里需要澄清一个容易混淆的地方：这里的 user 角色只是 API 协议层面的技术选择，并不等同于第一章定义的“来自终端用户的输入”。换句话说，Harness 是在借用 user 角色这个消息槽位，向模型注入由 Agent 框架自动生成的系统状态信息——内容并非来自真实用户，只是复用了 user 角色的消息格式来挂到上下文末尾。

以下是 Agent 框架在第 N 次 API 调用时实际构建的消息列表：

```
messages: [
  { role: "system",    content: "You are a customer service assistant..." }  ← Fixed (KV Cache cached)
  { role: "user",      content: "Help me cancel my Xfinity plan" }  ← Original user request
  { role: "assistant", content: null, tool_calls: [...] }   ← Round 1: model decides to call
  { role: "tool",      content: "Call log..." }             ← Round 1: call result
  { role: "assistant", content: null, tool_calls: [...] }   ← Round 2: model decides to call again
  { role: "tool",      content: "Call log..." }             ← Round 2: call result
  ...(more rounds)
  { role: "user",      content: "Can you call them again to follow up?" }  ← User follow-up
  { role: "user",      content: "<agent_status>             ← Status bar injected by Agent framework
      Current State:                                           (as a user message)
      - phone_call invoked 3 times (Xfinity: 3/3 max)
      - Current time: 2025-09-14 10:30:45
      - TODO: [1] Cancel plan (in_progress)
    </agent_status>" }
]
```

注意最后一条消息：它的 role 是 `user`，但内容是 Agent 框架自动生成的元信息，用 `<agent_status>` 标签包裹以便模型识别其特殊性质。这条消息在上下文的最末尾，紧邻模型即将生成的新 token，因此能获得最高的注意力权重。同时，因为它是追加而非修改，前面所有已缓存的内容都不受影响。

这个设计正是 KV Cache 一节核心结论中“动态信息追加末尾、静态信息保持不动”原则在状态栏场景的应用。