ZPF, FPF, SPF, TPF – фреймворки нулевых, первых, вторых, третьих принципов: масштаба “теории всего”, общепроектной работы, предметной области, конкретного рабочего процесса. Сегодня я сделал первый TPF, “Codex App principles-framework engineering TPF” (TPF инженерии фреймворков принципов в Codex App): разработка всех паттернов в моём Codex App сейчас идёт по этому TPF как по исполняемому AI-агентами и поддерживаемому питоновскими скриптами хелперов регламенту. Я долго к этому шёл, вот дошёл.
Некоторое время изучал управление вниманием агентов. Например, прошлой ночью один из проходов executor по семи паттернам кампании архитектурного синтеза удачно шёл 11 часов 10 минут; паттерны тем самым были серьёзно почищены. Ну, ещё и частично попорчены: точность языка иногда существенно влияет на понятность, пришлось потом делать отдельный проход по повышению понятности и переводу хотя бы проблемной ситуации на понятный архитекторам язык. Но почищены больше, чем попорчены.
Далее я ещё половину вчерашнего дня потратил на эксперименты с удержанием внимания. Вот я писал в руководстве по системному моделированию (Aisystant): “Собранность тоже работает с управлением вниманием в 4D, её нужно рассматривать на разных шкалах времени: прямо в споте, «вот сейчас» на несколько секунд, на время длинного рассуждения (от пары минут до пары часов), на время постановки привычки или выполнения проекта (месяц-год), на время удержания длинных периодов времени (несколько лет, планирование образования, планирование занятости в какой-то сфере, выполнение очень длинных проектов типа проектирования и строительства атомных станций). И кроме этих временны́х интервалов нужно отмечать, какие системы, их надсистемы и подсистемы выделены вниманием и на каком системном уровне мы работаем, какие важные характеристики рассматриваем, как и когда (ритм!) запоминаем прерванное рассуждение про одни объекты и переходим к другим. Собранность тоже вроде как существительное, но это метод/культура/практика, которым занимается «собранный» агент (в нашем случае мы отдаём предпочтение инструментальному, а не чисто «мозговому/ментальному» методу собранности, это чаще всего агент-киборг, то есть человек с компьютером или хотя бы бумагой-ручкой — собранность обеспечивается не мастерством «тренированного на хорошую память мозга», а мастерством использования надёжной внешней памяти, внимание удерживается напоминаниями о важных объектах на внешнем по отношению к мозгу носителе)”.
Для AI-агентов ничего менять в этом руководстве и этом конкретном абзаце не надо, им тоже для удержания внимания нужна ручка-бумажка! Поэтому все эти “инженерии циклов” и прочие “харнесс-инженерии” должны это учитывать. Вот итоги экспериментов и принятые меры (меры – как обычно, “согласно руководствам”, нашим в МИМ, “я писал”):
- цель (это команда в Codex App) ничего не гарантирует, кроме неостановки до достижения цели. Падает связь, прерывается ход агента, но потом всё одно цель достигается, агент до этого момента не останавливается: его тыкают там где-то внутри вилкой в бок, чтобы, если упал, вставал и полз дальше, уж как может. Используем, но этого мало.
- Есть поддерживаемые Codex “шаги плана”, которые он точно выполнит, – этого для удержания внимания тоже не хватает. Шаги плана – очень крупная нарезка, вроде как в проектном управлении верхнеуровневая нарезка “начните проект, потом спланируйте работы, потом выполните работы, потом проверьте результаты и передайте их куда надо, потом закройте проект”, – а внутри планирования и выполнения микрошаги делаются невнимательно, “в общем и целом”. Самолёт взлетает и садится, это под контролем, а вот куда там он летит и как петляет в воздухе – бесконтрольно, автопилот может впасть в кому (подвиснуть, ага), этого никто не заметит. Тоже для AI-собранности (вспомним этот удачный термин для удержания внимания на важных объектах) в споте не хватает – помним, что собранность ведь многоуровневая! Используем, но этого мало.
- Дальше делаем ledger для разрядки (discharge) микрошагов, но писать туда надо очень коротко, “только для учёта” (иначе лекарство превращается в болезнь), и этого тоже мало! AI-агент влёгкую делает “в общем и целом”, затем заполняет чеклист задним числом, весь, одной записью. Используем, но этого мало.
- Идём на уровень происходящего внутри одного микрошага: добавляем отчёт после каждого шага в чат (он воспринимается как “обязательное действие” и вынуждает что-то написать – и только потом перейти к следующему шагу). Всё налаживается, но не всегда: иногда эта инструкция забывается, но тогда сразу видно, сделано ли за три минуты “в общем и целом” или-таки за три часа, поскольку по шагам. И результат: один найденный баг при проверках “в общем и целом” там, где десяток находится при проверке “по микрошагам”.
Дальше я перевёл основные документы процесса в формат паттернов (и сделал, конечно, перед этим DRR) и прогнал их в цикле улучшения. Появился шанс использовать одну и ту же процедуру улучшения как для самого FPF, так и для паттернов процесса. И там в документах есть ещё всякие scaffolds (читай: чеклисты) для стартовых написаний DRR и паттернов. И ещё немного документов, которые не очень похожи на паттерны. Да, вы правильно поняли: я тренируюсь делать TPF. Надо же как-то начинать! Тут важно, что я не сочинял эти паттерны, а именно конвертировал в них имевшуюся документацию.
Это ещё не всё: в этот Codex App principles-framework engineering TPF я добавил ещё и domain model паттерн для хелперов, описание тамошних fitness functions (их у меня девять), а также правила разработки хелперов (например, там “нельзя отлаживаться на живых чатах”, ибо это тоже надо говорить явно). После этого был архитектурный проход согласования самих хелперов с процессом. Одна из задач согласования была: “всё, что можно из процессного, убрать в хелперы, AI-агентам оставить только содержательную работу”.
Текущая кампания идёт уже на этом новом TPF, всё стало побыстрее: меньше ручных уточнений, меньше борьбы с транспортом, меньше “проверили в целом”, быстрее передача хода (baton и handoff), меньше fanout. Добавил чуть-чуть skills, но это сейчас просто “синтаксический сахар”. Скажем, skill “передай ход” вызывает механизм делегирования Codex App, чтобы один агент мог послать сообщение в чат другому агенту: я не звал питоновский скрипт, а просто писал что-то вроде “передай ход”. Ну и ещё отладка: агент, который сейчас встречает проблему в процессе (скажем, отвалился транспорт по передаче хода), сразу сам сообщает этот баг моему ProcessEngineer. Раньше это делал я: замечал, что что-то неладное, затем объяснял профильному агенту. Теперь можно писать вот этот текст, а они там как-то сами работают. Сложность: всё реально быстро, иногда уже не успеваю вовремя читать тамошние размышления и что-то говорить под руку работающим AI-агентам, а это всё-таки надо делать – без присмотра всё не так хорошо получается, как с присмотром. Чистой воды присмотр/governance, но уже не руководство (руками водство, “микроменеджмент”).
Вот список имён паттернов этого TPF. Помним, что “паттерн” – это решение проблемы, которая часто встречается в каком-то контексте (в нашем случае – AI-native разработка языка паттернов согласно спецификации FPF), так что читайте это как список “типовых сбоев в AI-native разработке и их решений”:
MicrostepLiveBeatPass@Process– паттерн удержания внимания на одном проверяемом микрообъекте: строке, координате, finding, файле, trigger, source item.QualityReviewPass@Process– паттерн проверки качества объекта, когда он заявлен как готовый, стабильный или достаточно улучшенный.HLPackageDischargePass@Process– паттерн разрядки sharedH1..H15иL1..L12по одному пункту, без “проверили в целом”.LexicalKindGovernancePass@Process– паттерн управления лексикой, kind-словами, метафорами маршрута, umbrella terms и точностью имён.ReviewerE19GatePass@Process– паттерн reviewer-runE.19gate для admission, refresh, release, external-review или landing readiness.DRRAdequacyPass@Process– паттерн проверки, чтоDRRгодится как decision basis, а не просто имеет правильный заголовок.AcceptedBasisCarryThroughPass@Process– паттерн протаскивания accepted intake,DRR, audit, returned finding или steward instruction в реальные правки.ExternalReviewPacketReadinessPass@Process– паттерн готовности target/context packet, если external review уже выбран by value.LandingRegressionPass@Process– паттерн проверки, что landing в монолит или canonical indexed source не потерял смысл, структуру, ссылки и discovery.ProtocolResiduePass@Process– паттерн уборки process residue: что оставить current, что архивировать, что заменить указателем, что удалить.PrelandingOntologicalHardeningPass@Process– паттерн онтологического hardening перед landing/review-facing gate: kind recovery, locus distribution, source-action discharge, readability.HelperDomainModel@Process– pattern set для helper/domain model: baton, active handoff, current seam, dispatch projection, transport attempt, receipt, generated projection и regression invariants.PlatformProcessChange@Process– паттерн изменения самого процесса, хелперов, транспорта, панели, fit functions и recovery-механики: сначала domain model и architecture, потом patch.- ещё не написаны, но уже названы как кандидаты (backlog) –
CampaignStartupAndDRROpening@Process,ReturnedFindingsIntakeAndRevalidation@Process,SafeWorkspaceEditAndRecovery@Process.
Управляющие сущности этого TPF:
ProcessPatternHostCatalog@Process– внешний ToC и catalog host-set; он не копирует тела паттернов, а удерживает discoverability, first useful move, output и boundary.PROCESS-MICROSTEP-CHECK-PATTERN-FAMILY-DRR.md– семейный DRR, который объясняет, почему эти wrapper-patterns именно так разделены и где проходит anti-duplication boundary.PROCESS-PATTERN-ROUTING-AND-RETIREMENT-LEDGER.md– routing/retirement ledger: какие старые prose obligations уже patternized, какие ещё в migration frontier.PROCESS-FIT-FUNCTIONS.mdиFF1..FF9– исполняемые fit functions процесса: от отсутствия rival current files и administrative fanout до helper-domain integrity и catalog integrity.HDM.1..HDM.7– helper-domain invariants: active handoff truth, seam/dispatch projection, projection-only refresh, delivery attempt and receipt, stub DRR startup route, generated projection editing boundary, internal architecture review sufficiency.
Итог всех этих хлопот: по получившемуся TPF дальше можно делать как FPF, так и SPF, так и TPF – хотя именно этот “Codex App principles-framework engineering TPF” и его хелперы специфичны для Codex App. Впрочем, он очень легко адаптируется для самых разных агентских workspace.
На этом обновлённом процессе я закончил работать над набором архитектурных паттернов.
Дальше я рисовал картинки к семинару. Вот промпт (и одна из картинок):
Мы готовим серию семинаров на тему FPF. Нам надо подготовить инфографику. Инфографику надо делать в стилистике Альфонса Мухи, яркие цвета.Для начала надо сделать варианты инфографики (сделай пять по каждому view), показывающие разницу между ZPF, FPF, SPF, TPF (фреймворки нулевых, первых, вторых, третьих принципов).
Инфографика нужна с нескольких views:
- состав FPF: ZPF входит в FPF как часть, SPF – множество, и они снаружи, а TPF основываются на самых разных SPF, и их ещё больше. Это про тексты-артефакты: ZPF внутри FPF, SPF разрабатываются на уровне отрасли, TPF – на уровне рабочего процесса в конкретном предприятии.
- область применения: ZPF отсекает на карте всех возможных решений каких-то проблем огромное пространство нежизнеспособных решений, “там драконы”. FPF из этого пространства высекает общую область более вероятных решений, SPF – небольшую область решений конкретной задачи предметной области (общей для многих предприятий), TPF – область уже совсем узкую, решения конкретной задачи в условиях конкретного предприятия.
- гибридное view, которое показывает связь первого и второго view (какие тексты что высекают).
Вот одна из метафор, но надо придумать их больше – и попытаться выразить в инфографике:
– ZPF: нулевые принципы – threshold concepts. Отсекают “там драконы”.
– FPF: первые принципы “как оно бывает в жизни” (P2W – как вообще думать, как работать), общая карта, “где мы вообще на этом глобусе” (масштаб городов, в них бывают библиотеки)
– SPF: мелкомасштабная карта: “построить маршрут”, “как пройти в библиотеку” (и тут надо знать, где тут рядом библиотека)
– TPF: конкретная инструкция (схема здания, часы работы библиотеки, как записаться в библиотеку, как получить книгу, когда её возвращать)Сделай пять вариантов с разными сюжетами картинок инфографики к первому view, я скажу “продолжай” – сделай пять вариантов ко второму view, я скажу “продолжай” – к третьему гибридному view.
