TGViewer
PRO продукты и системы | Иннокентий Бодров PRO продукты и системы | Иннокентий Бодров @spherical_analyst · 2.62K subscribers
Post #1283 54
Под постом о Portfolio OS меня спросили, как устроена система и зачем там граф.

Покажу на недавнем примере.

Одна публикация в Дзен несколько дней не доходила до проверенного результата. Было исходное поручение, несколько попыток и технический ремонт. Журнал одной попытки зафиксировал ответ площадки с ID объекта. На момент контрольного чтения публичная статья не была подтверждена, а факт публикации в Planner отсутствовал. Значит, работа оставалась незавершённой.

В системе эта история выглядит как цепочка:

источник → сигнал → поручение штабу → задача → результат

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

Агенты внутри штабов выполняют ограниченные шаги: читают источники, готовят изменения, запускают проверку, приносят доказательства. Доставка поручения агенту ещё не означает, что штаб принял результат. И ответ агента «готово» не превращает попытку в выполненное действие.

Граф помогает пройти по этой цепочке назад. Я могу открыть задачу и увидеть, из какого поручения она появилась, к какому продукту относится и какие события меняли её состояние. У каждой связи есть тип и источник. Если связь не подтверждена, система показывает пробел, а не достраивает историю по похожим словам.

Сам граф у меня сейчас довольно приземлённый: локальная проекция SQLite только для чтения. Он собирает разрешённые связи из реестра продуктов и Portfolio Ops. Роли продуктов и маршруты живут в реестре, портфельные поручения — в Portfolio Ops, согласования и факты публикаций — в ContentOps Planner.

Граф знает, что задача относится к AnalystCraft и появилась из конкретного документа пилота. Но он не решает, опубликована ли статья. За этим ответом нужно идти в Planner и на сторону Дзен.

Отсюда две разные проверки.

Первая: почему появилось решение и какие объекты с ним связаны. Здесь помогает граф.

Вторая: кто сейчас отвечает за действие и насколько свежи данные. Это проверяется у владельца задачи и в системе, где произошло действие.

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

Для меня в этом и есть смысл Portfolio OS: в любой момент можно увидеть, откуда пришла работа, кому она принадлежит и какого доказательства ещё не хватает.
  • 👌 1
More from @spherical_analyst
  1. Oct 13, 2026Агент написал код. Потом написал тесты. Что именно они доказали? В худшем случае — что две…
  2. Oct 13, 2026Всем привет, мы в эфире
  3. Oct 12, 2026🔥 Иногда лучший способ улучшить собственный фреймворк — показать его другим аналитикам и…
  4. Oct 11, 2026Почему я всё ещё работаю диспетчером Я собираю систему, которая должна разгружать меня. На…
  5. Oct 8, 2026Сегодня при проверке своей системы управления проектами увидел статус «карта связей устаре…
  6. Oct 7, 2026Анонс стрима "ИИ vs Системный аналитик" 13 октября в 19:00 - стрим «ИИ vs Системный аналит…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →