Agent Status Bar

Какую проблему решает

В длинной траектории факты о текущем положении разбросаны по сообщениям: сколько раз уже вызывался инструмент, какие подцели закрыты, какой бюджет остался, где находится рабочая директория, появилось ли предупреждение. Модель может восстановить их из transcript, но вынуждена делать это заново перед каждым решением и иногда ошибается в подсчёте или забывает раннее ограничение.

Status bar превращает несколько агрегатов в явное наблюдение:

agent_status:
  state_version: 42
  phase: verify
  remaining_goals: ["migration test"]
  budgets:
    tool_calls: {used: 17, limit: 24}
  environment:
    cwd: /workspace/service
    branch: fix/schema
  alerts:
    - "edit_file повторён с теми же аргументами 3 раза"

Поля выбираются по тому же критерию, что и у State Centric Execution: значение должно менять следующий выбор. Полный лог, длинный traceback и объяснение прошлых решений сюда не помещаются — они остаются в tool result, trace или внешнем артефакте.

Производное представление, а не второй state

Status bar занимает роль производного представления:

канонический state + счётчики runtime + проверенные наблюдения
                         ↓ детерминированный renderer
             ограниченный status bar для модели

Из этого следуют жёсткие правила:

модель не редактирует статус напрямую; она предлагает действие или patch к state, который валидирует runtime;
счётчики, бюджеты, время и состояние среды вычисляет код;
каждый статус несёт версию исходного state или timestamp наблюдения;
статус можно пересобрать и сравнить с показанным агенту снимком;
данные из недоверенной страницы или tool output не повышаются до статуса без валидации;
противоречие между status bar и каноническим state считается дефектом renderer, а не поводом переписать state по статусу.

Это особенно важно потому, что статус сформулирован как авторитетная техническая сводка и модель склонна ему доверять. Ошибка счётчика или подмешанный внешний текст становится status poisoning: ложное производное представление получает больше влияния, чем сырой источник.

Место в контексте и цена кэша

Статическая инструкция остаётся в начале; динамический статус размещается как можно позже, рядом с новым решением. Так он не меняет длинный стабильный префикс и не заставляет модель искать актуальный агрегат в середине истории (Prompt Caching).

Конкретная API-роль зависит от провайдера и harness. Книга демонстрирует техническое сообщение с ролью user, но это не универсальный контракт: автоматическое состояние нельзя семантически выдавать за слова пользователя. Если API не имеет отдельного канала метаданных, сообщение маркируют как runtime-generated, отделяют от пользовательского ввода и проверяют, что инструкциям пользователя не приписывается ложный авторитет.

У обновления две стратегии:

Стратегия	Выигрыш	Цена
заменить предыдущий статус у хвоста	в контексте только актуальный снимок	инвалидируется короткий suffix после старой вставки
только дописывать новый	префикс остаётся неизменным	копятся токены и противоречащие устаревшие статусы

Выбор делается по измеренному cache hit rate, размеру статуса, частоте обновлений и длине сессии. Append-only безопасен только при явном правиле «актуальна максимальная state_version» и bounded session; иначе экономия кэша покупается неоднозначностью.

Когда можно удалять сырой контекст

Status bar — потеряющая детали проекция. Он достаточен только для заранее названных запросов: счётчика, текущей фазы, остатка бюджета, списка открытых подцелей. Он ничего не сообщает о причине решения, дословном условии пользователя или наблюдении, для которого не завели поле.

Поэтому есть два разных режима:

добавление: status bar лежит рядом с сырой траекторией и экономит повторное восстановление агрегатов;
замена: сырые записи удаляются из prompt только после теста достаточности проекции для всех поддерживаемых решений; trace всё равно сохраняется вне prompt.

Первый режим безопаснее и является начальным. Второй уже относится к Context Compaction и требует regression set на вопросы внутри и вне представленных измерений. Запрос вне схемы должен приводить к чтению источника или честному unknown, а не к догадке по неполному статусу (Unknown Not A Value).

Как проверять

Минимальная абляция сравнивает одинаковые задачи и состояние с включённой и выключенной проекцией. Ведущей метрикой остаётся task success или соблюдение ограничения; токены, задержка и число повторов — диагностические.

Отдельно нужны негативные тесты:

status bar намеренно расходится с каноническим state;
рядом остаётся старый статус с меньшей версией;
tool output пытается внедрить собственный <agent_status>;
renderer пропускает неизвестное или просроченное наблюдение;
вопрос требует детали, которой в проекции нет;
status renderer недоступен — система не подставляет прошлый снимок как текущий молча.

Границы

Не заменяет канонический state, checkpointer или audit log.
Не исправляет отсутствие самого наблюдения: красиво показать можно только известное системе.
Плохо подходит для открытого исследования, где заранее неизвестны важные измерения.
Может усилить ошибку renderer сильнее, чем сырой transcript, потому что выглядит как готовый вывод.
Кэш-оптимальная раскладка не обязательно семантически оптимальна; обе проверяются на своей системе.

Связано с

State Centric Execution — канонический state, из которого строится проекция
Context Compaction — условия, при которых проекция может заменить часть сырой истории
Prompt Caching — стабильный префикс и динамический suffix
Context Layers — статус как runtime-слой с коротким сроком жизни
Agent Audit Log — сохранённый снимок того, что реально видел агент