Agent 状态栏将隐式状态显式化。但如果状态栏本身包含了错误信息（比如工具计数器出了 bug），Agent 可能基于错误的信息做出有害的决策。这种“元信息可靠性”问题如何缓解，难道再写一个工具监督或者更好的修改边界？

回复 Erfan： 千万不要为了监督一个状态去再加一层监督 Agent 或监督工具，那样只会掉进“谁来监督监督者”的套娃里，既加延迟又多一层幻觉。 缓解状态栏（元信息）污染，核心思路是划分写入边界和信源优先级，把“硬事实”和“软总结”彻底分开： 1. 硬状态由 Harness 代码纯确定性计算，严禁 LLM 手写 凡是能用代码精确算出来的状态，比如工具调用计数、当前所在 git 分支、已修改的文件列表、最近一次单测的 exit code，全部由底层运行时每次循环直接从环境或内存里实时读取生成（Stateless 实时渲染，而不是累加一个容易出 bug 的状态变量），以只读方式注入上下文，不给 LLM 任何修改权限。如果连宿主代码的计数器都有 bug，那是常规软件工程的单元测试问题，靠写单测修代码解决，不是靠 Agent 架构解决。 2. 软状态与真实环境冲突时，以 Tool Output 为唯一事实源 像 Todo 进度、已排除的假设这类必须由 LLM 维护的“软状态”，确实可能写错或过期。解决办法是在 System Prompt 里立一条死规矩：状态栏仅作导航参考，一旦状态栏记录与当前工具返回的实际结果（如文件内容、报错信息）冲突，无条件信任工具输出，并立刻修正状态栏。 3. 用 Schema 校验和 Hook 守住修改边界 模型更新软状态时，不要让它自由覆写整段文本，而是通过强类型的状态更新工具（比如要求传入 task_id 和明确枚举状态），或者在状态更新后挂一个轻量 Hook 做一致性校验（比如模型想把任务标为 done，Hook 自动检查一下对应测试是不是真过了，没过就直接驳回这次状态修改）。