Agent 陷入无限循环、数不清工具调用次数、遗忘 TODO 或目标偏离、长任务中思考 token 持续膨胀时使用——Agent 状态栏机制、作为 user 消息注入末尾的 KV Cache 理由、每轮替换与持久追加两种实现及成本模型、五种状态栏技术（时间戳、工具计数器、TODO、详细错误、系统状态）与维护铁律。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
提示工程给的是静态指令，而 Agent 执行中还需要动态感知自身状态与任务进展。Agent 状态栏把任务进度、环境变化、工具调用计数等运行时状态整理成结构化摘要，由框架在上下文末尾持续注入。类比手机屏幕顶部始终显示时间、电量、信号——模型每次生成新回复时都能「瞥一眼」，据此做出更准确的决策。
messages: [
{ role: "system", content: "You are a customer service assistant..." } ← 固定，KV Cache 已缓存
{ role: "user", content: "Help me cancel my Xfinity plan" }
{ role: "assistant", content: null, tool_calls: [...] } ← 第 1 轮决策
{ role: "tool", content: "Call log..." }
{ role: "assistant", content: null, tool_calls: [...] } ← 第 2 轮决策
{ role: "tool", content: "Call log..." },
{ role: "user", content: "Can you call them again to follow up?" },
{ role: "user", content: "<agent_status>
Current State:
- 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>" } ← 框架注入的状态栏
]
<agent_status> 标签包裹，便于模型识别其特殊性质。实现一：每轮替换——每次 API 调用前移除上一轮状态消息，在末尾追加最新状态。保证永远只有一份最新状态，但移除旧状态会使其位置之后的所有缓存失效（与「动态时间戳」同一失效机制，区别仅在于状态消息位于末尾，失效范围只覆盖上次注入后新增的消息，通常是一轮，整个前缀仍可复用）。
实现二：持久追加——状态消息一旦注入就永久留在轨迹中，每轮只在末尾追加新状态。Claude Code 的 <system-reminder> 即此方式，历史状态保留在 transcript 中从不删改。对缓存完全友好（只追加不修改，前缀始终稳定），代价是陈旧状态累积，既占 token 又要求模型自己关注最新一条。
选择规则：
粗略成本模型：设每条状态 S token，两次更新间新增后缀 R token，预计更新 N 次，缓存输入单价为普通输入的 α 倍：
C_替换 ≈ (N-1) * (1-α) * R
C_追加 ≈ α * S * N * (N-1) / 2
→ 当 α*S*N/2 < (1-α)*R 时倾向实现二，否则倾向实现一
该估算未计上下文占用和陈旧状态带来的歧义，实际选择还应结合服务商缓存计费与实测命中率。
[2025-09-14 10:30:45] 格式作为前缀添加到用户消息和工具响应中（不是放在系统提示词里，否则破坏 KV Cache）。让 Agent 理解时序关系，也为调试和审计提供信息；配合时间模拟可理解「昨天的文件」和「今天的修改」。Tool call #3 for 'read_file'。显式计数触发模型的模式识别：第一次失败后检查路径，第二次失败后列出目录，第三次主动放弃并找替代方案。深层价值是隐式的成本感知。rewrite_todo_list 和 update_todo_status 两个工具，每项含唯一标识符、内容、状态（pending / in_progress / completed / cancelled）和时间戳。借鉴 Manus「通过复述操纵注意力」理念。实验数据：启用 TODO 的 Agent 平均 15 次迭代完成任务，禁用时需 21 次且经常遗漏子任务。cd 后自动更新；OS 信息让 Agent 做平台相关决策（Linux 用 apt、macOS 用 brew）。这些技术单独使用效果有限，组合起来会产生涌现效应：时间戳 + 工具计数器让 Agent 理解操作的频率和时间分布；TODO + 系统状态让 Agent 根据环境调整策略；详细错误 + 工具计数器让 Agent 多次失败后不仅改变策略，还理解失败原因。
chapter2/system-hint/ — 实验 2-9（agent-status-bar 框架）：实现时间戳、工具计数器、TODO 列表、详细错误、系统状态五种状态栏技术，可独立开关；python main.py --mode preview 无需 API key 即可对比有无状态栏时模型看到的上下文差异；python run_experiment_2_8.py 跑冻结的对照实验。book/chapter2.md「Agent 状态栏：通过元信息增强 Agent 轨迹管理」まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
为 Agent 建立或改进评估体系时使用——设计评估指标（Pass@k/Pass^k/成本）、搭建可重复运行的评估环境、选择确定性验证器或 LLM-as-a-Judge 及各自适用边界、编写 Rubric、做失败归因与回归任务、评估驱动的模型选型、判断统计显著性、建设可观测性与内部评估基础设施（消融、AB 测试、特性开关、提示词回归）、从 Benchmark 报告走到系统改进。
日本語の概要は準備中です。原文の説明を表示しています。
让 Agent 从运行经验中持续学习、构建自进化闭环时使用——涵盖从运行轨迹提取学习信号（三层轨迹验证）、四种进化方式（经验知识库、Prompt/Skill、程序/Harness、模型参数）的适用边界与选择依据、Prompt 自动优化、轨迹编译为程序、Agent 自我修改与安全门禁、睡眠学习与长期分层评估。触发词：持续进化、自进化、经验学习、轨迹验证器、自我修改、进化闭环。
日本語の概要は準備中です。原文の説明を表示しています。
中文文案去「AI 味」检查清单，由用户纠正反馈持续提炼而来
日本語の概要は準備中です。原文の説明を表示しています。
构建异步/事件驱动 Agent，或让 Agent 响应外部事件（新邮件、webhook 回调、IM 消息、定时器、系统告警）、 处理工具执行期间的用户打断与多任务并发时使用。覆盖事件循环与安全点、三类事件触发工具、用户沟通与多渠道召回、 虚拟身份与隔离执行环境、队列式/取消式/并行式三种事件处理策略及紧急度判定，以及模型原生异步与同步接口兼容两条路线。 触发词：异步 Agent、事件驱动、event-driven、webhook、定时器、心跳、任务句柄、打断、steering、并行工具执行。
日本語の概要は準備中です。原文の説明を表示しています。
把生产 bad case / 失败轨迹转成训练数据时使用——从失败归因、轨迹前缀截取、DPO 偏好对构造、LoRA 训练到边界集与保留集双集验证的完整链路；也用于判断某类问题该走 SFT、DPO、RL 还是先修 Harness/工具/tokenizer，以及如何从运行轨迹中提取带证据的结构化学习信号。触发词：bad case、失败归因、DPO、偏好对、轨迹前缀、拒绝采样、过度矫正、边界集、保留集、过早结束、reward hacking、LoRA 微调、训练评估隔离。
日本語の概要は準備中です。原文の説明を表示しています。
编写并运行 Python 代码，验证脚本逻辑和输出。
日本語の概要は準備中です。原文の説明を表示しています。