SavePearlHarbor

Основы Knowledge Management в разработке

—

от автора

admin

Disclaimer & About

Уважаемый читатель, будь то Human или AI, прежде чем начнётся основной текст, я хотел бы сделать небольшие дисклеймеры:

  1. Первичные источники — мой собственный опыт работы с различными coding (software-based) и non-coding проектами в производственной и транспортной отраслях. Некоторые концепции могут показаться знакомыми, потому что я где-то о них читал; некоторые концепции представляют собой совокупность знаний, полученных из опыта; некоторые концепции сформированы на основе опыта работы с людьми и AI (LLM/Agents/?) — и проверены на практике. Эта статья сфокусирована на практическом применении всех концепций для любого проекта, большого или малого, как для People, так и для AI.

  2. Это весьма субъективный и living article — это означает, что в будущем некоторые концепции в той или иной степени устареют или станут неактуальными, либо могут показаться неправильными для некоторых сценариев применения — и это нормально. Хотя хорошо иметь один стабильный фундамент для долгосрочного использования, ничто не идеально и всё постоянно меняется. Как одно из следствий этого — я опущу фразы “in my opinion” из текста, чтобы сделать его более лёгким и удобным для чтения.

  3. Я работаю с AI (cursor, различные LLM-модели) для вычитки (proofread) этой статьи и повышения её качества. В то же время, поскольку это своеобразная рефлексия моего опыта, изначально я написал её вручную, а точнее — нажимая кнопки на клавиатуре :). С другой стороны, кто-то может сказать, что было бы отлично позиционировать такое использование AI как соавтора (co-creator) и соредактора (co-editor).

Почему дисклеймеры важны? Потому что я верю, что это единственный способ создать доверие между читателем и автором, основанное на определённых ethical principles и ценностях. О том, почему Ethics важна для software development и AI в целом, читайте здесь.

Спасибо за чтение этой статьи, и я надеюсь, что она окажется для вас полезной.

Fundamentals of Knowledge Management in Software Development

Terms & Definitions

Для начала давайте определим термины и определения (примечание: это не претензия на лингвистическую или историческую точность, а определение для дальнейшего использования).

basic Knowledge terms

  • Knowledge — это прошлые/текущие/будущие artifacts выполнения чего-либо кем-либо или чем-либо. Каждый документ, artifact, план, схема, решение (сделать что-то или не делать), сообщение, переданное голосом, текстом, изображением, кодом, видео, голограммой и т. д., — является частью этой истории.

  • Knowledge Source — поскольку знания представляют собой своего рода нелинейную историю, их источник может быть случайным, преднамеренным, форматированным или нет, структурированным или нет. Например: это может быть как conversation между людьми, так и conversation с/между AI, или даже природное событие.

  • Knowledge Point of View — знания могут быть выражены разным образом в зависимости от контекста, лингвистики, визуала, ethics, цели и того, кто или что их выражает / воспринимает. Один источник может быть выражен с разных points of view, а одна point of view может иметь разные источники.

  • Operational or Iterative Knowledge (Record) — “живые” знания, которые удобно воспринимать и применять на практике. Имеют начало и конец жизни (иными словами — lifecycle). Если знания не используются и не обновляются регулярно, их следует рассматривать как static knowledge record, извлечённые в несколько документов или уничтоженные.

  • Archive Knowledge (Record) — запись для архивных целей (см. DR/ADR ниже), например: запись встречи, фото и т. д. То, что нельзя изменить, не создав новое.

  • Knowledge Lifecycle — как и что именно в знаниях создаётся, вызывается, изменяется, хранится, передаётся, используется и, в конце концов, уничтожается. Важным моментом здесь является то, что operational или iterative knowledge не должны быть статичными — ожидается, что у них есть начало, середина (итерации изменений) и конец жизни.

  • Knowledge Changes Control System — система, которая может документировать изменения в знаниях и их lifecycle.

  • Knowledge Experience — опыт восприятия знаний с определённой point of view — чтение, просмотр, прослушивание, взаимодействие и т. д. для достижения желаемой цели — обычно с точки зрения Knowledge User.

  • Knowledge User — кто или что использует / воспринимает знания — человек, AI или другая сущность (entity).

applicable Knowledge terms

Исходя из вышесказанного, давайте определим унаследованные и применимые термины, которые действительно могут быть использованы на практике в software development (не только в написании кода, но и как общие знания для business / project / team / и т. д.):

  • Terminology / Glossary — согласованные слова / определения — во избежание путаницы и неверного истолкования.

  • Artifact type / format — определяет форму представления знаний — текст, изображение, код, видео, голограмма и т. д.

  • Structure & Compression — определяет, как знания организованы и сжаты для конкретного формата и цели. Например, текст может быть организован в параграфы, предложения, таблицы, деревья, графы, FAQs, гайды, knowledge packs (подробнее см. в разделе Executable Knowledge) и т. д.

  • Generatable Knowledge — разновидность Operational Knowledge Record — результат работы детерминированных инструментов (автоматически сгенерированная документация кода, собранная и построенная в виде графа и т. д.), приводящий к определённому формату знаний (таблица, документ, веб-сайт (docs из кода, результаты экспериментов, симуляций и т. д.)), или результат генеративных знаний, созданных People или генеративным AI (LLM/Agents/?). В обоих случаях это важный шаг для создания Static Knowledge Record, создания Context или своего рода Structured Output (https://developers.openai.com/api/docs/guides/structured-outputs) для результата или GenUI (A2UI, AG-UI и т. д.).

  • Context — определяет окружение и обстоятельства, в которых протекает knowledge lifecycle. В основном должен генерироваться (собираться) автоматически, чтобы предоставить достаточно знаний для действий любого пользователя / AI agent / и т. д.

  • Executable Knowledge — разновидность Operational Knowledge Record или SOP, которая может выполняться человеком, AI agent или другой сущностью. Может выражаться как минимум в двух формах: Logical or Deterministic (чаще всего встречается в виде кода или математики — результат всегда детерминирован) и Non-deterministic / Generative — выполнение может варьироваться в зависимости от контекста, сущности, которая его выполняет (человек, AI agent или другая сущность, либо природные явления) — результат всегда недетерминирован, но может быть оценён на предмет correctness и completeness с определённым уровнем уверенности через Evidence & Validation. Например: OKF, Skills, Rules, Agentic Executables.

  • Decision Record (DR) и Architecture Decision Records (ADR) — разновидности static knowledge records — фиксируют решения и ход рассуждений, сделанные кем-либо (Human или AI) — adr.github.io. Будучи созданными, они никогда не должны меняться, однако могут быть заменены (superseeded) новыми.

  • Standard Operating Procedure (SOP) — разновидность Operational Knowledge Record — документ, описывающий шаги для конкретной задачи или процесса, удобный для исполнения (и автоматизации в будущем, преимущественно детерминированным путём).

  • Evidence & Validation — используется для подтверждения или опровержения утверждений о знаниях (knowledge claims) в зависимости от контекста и цели с помощью примеров, математики, кода, других knowledge artifacts, специфических инструментов и т. д. В контексте базы кода (codebase) это может выражаться в виде детерминированного инструментария, тестов, линтеров (статического анализа), knowledge harness (agentic/engineering harness) и т. д. В контексте других knowledge artifacts это могут быть стандарты, политики, процедуры, эксперименты, симуляции и т. д.

  • Domain Knowledge — «это знание конкретной дисциплины», полученное от экспертов/специалистов предметной области аналитиками, дизайнерами или в процессе итеративного проектирования, из вашего собственного опыта или работы — цитата из Domain Knowledge. Например, это может быть опыт конечного пользователя, который использует ваше приложение.

  • Knowledge Scale Capacity — знания безграничны, но хранилище и способность получать доступ, организовывать и управлять ими для достижения наилучшего опыта ограничены и сильно зависят от Knowledge User, его целей/задач, а доступная организация записей знаний (системы управления, инструменты, ПО и т. д.) ограничена ресурсами (время, хранилище, harness и т. д.).

  • Knowledge Evolution — знания могут сокращаться или расти со временем, в зависимости от их scale capacity, knowledge harness и пользователей. Например, в контексте codebase это можно рассматривать как добавление или уменьшение сложности логики. Некоторые аспекты этого описаны в Skill Steward Evolutionary Simplicity.

  • Knowledge Harness — инструменты и системы, которые помогают управлять и/или организовывать знания и их lifecycle; как параллельный паттерн — см. пример harness engineering в статье OpenAI.

  • Product Requirements Document (PRD) и Game Design Document (GDD) — разновидности Operational Knowledge Records — документ, в котором описываются требования к конкретному продукту, фичам или игре, выраженный в специфическом формате для конкретной цели и для определённых Knowledge Users (разработчиков, дизайнеров, инвесторов, маркетологов и т. д.).

  • Knowledge Patterns — повторяющиеся паттерны организации и опыта, которые могут быть превращены в термины-определения, цитаты, форматы, принципы, SOPs, Records и т. д. или обратно в необработанные знания (artifacts) для конкретной цели.

  • Knowledge Stewardship — процесс и методы передачи и работы на мета-уровне — т. е. ответ на вопрос: как обучать, менторить Knowledge как системы, harnesses, experiences и т. д. Как создавать и поддерживать сами практики работы. В некоторых системах управление этим входит в компетенцию роли Knowledge Steward.

  • Knowledge Accessibility — как сделать знания доступными для Knowledge Users — т. е. как сделать их видимыми, находимыми, понятными для сущностей/инструментов/систем (людей, агентов, кода, систем и т. д.), пригодными для использования, повторного использования и т. д.

  • User Flow или User Journey — последовательность экранов, действий, решений, взаимодействий и т. д., которые пользователь выполняет для достижения определённой цели или задачи.

Важные элементы знаний:

  • Знания часто универсальны и могут быть просмотрены, восприняты и применены между смежными доменами и проектами (cross-domains / cross-projects), если они достаточно абстрагированы или обобщены.

  • Operational knowledge подчиняются эволюции.

  • Инструменты и организация знаний могут сильно отличаться для каждого проекта. Поэтому лучше иметь как минимум один слой знаний, посвящённый исключительно их организации и опыту конечного пользователя этих знаний.

Knowledge Organization & Experience: from example to patterns.

Теперь давайте рассмотрим наименьший из возможных программных проектов — пример приложения.

Knowledge Users

Для начала давайте определим, кто будет являться Knowledge User и каковы его цели/задачи. Этот пункт весьма субъективен и зависит от того, кто работает над проектом, поэтому, чтобы сохранить актуальность примерно для 2026 года:

  1. Visionary, Product Owner, Developer, Knowledge Steward (часто Founder).

  2. Graphics/Product Designer / Marketer / Content Creator (часто Influencer).

  3. End User как человек, End User как AI Agent.

  4. Internal AI Agents.

  5. Accountant (если продукт небольшой, эта роль переходит к Founder).

  6. Customer Support (если продукт небольшой, эта роль переходит к Founder или Influencer).

Более того, эти пользовательские роли крайне субъективны и в большинстве случаев будут пересекаться, либо могут быть расширены / сокращены — всё зависит от масштаба проекта.

Обратите внимание на паттерн: когда рабочий процесс (workflow) и бизнес-процессы имеют частые точки пересечения — совсем как в программировании, это похоже на проблему масштабирования: когда нам требуется больше функциональности и более сложная логика, нам нужно вводить больше абстракций, чтобы снизить общую сложность и начать управлять ею на более высоком уровне абстракции. В результате любая такая роль может стать универсальной (generic), быть переосмыслена как workflow / business process / автоматизация, охватывающая определённую доменную область — и в итоге мы можем вводить в систему больше пользователей / ролей / акторов, когда это требуется, или сокращать их до детерминированного или оцениваемого потока (см. различия между Generative AI и Traditional AI, например — https://docs.cloud.google.com/docs/ai-ml/generative-ai/generative-ai-or-traditional-ai).

Knowledge Sources.

Communication sources:

Прежде всего — определите Ethical Boundaries, потому что это очень чувствительная грань: в случае записи абсолютно всего команда рискует потерять приватность, доверие и коллаборацию между участниками, а также получить культуру поиска виноватых (blame culture) и ментальное давление; в случае отказа от каких-либо записей — будет утеряна способность развиваться и накапливать общие Knowledge, возможность передавать знания AI Agents и другим участникам, а также работать асинхронно.

Иногда коммуникация строится вокруг создания доверия, экспериментов, передачи знаний — это вещи, не поддающиеся метрикам, и их не следует измерять.

Каждый должен знать о факте записи, о том, зачем она нужна, и как именно эти записи будут использоваться.

Источники могут включать в себя:

  • Ежедневные коммуникации: все возможные каналы, приложения, email, чаты, звонки.

  • Static artifacts: документы, файлы, изображения, видео, аудио и т. д.

  • Инновационные идеи: референсы, ссылки, новости, заметки, предложения, книги, идеи, статьи и т. д.

  • Выраженные эмоции: сигналы о том, что что-то идет не так, что работает, а что нет.

  • Время и контакты: для определения удобных часов для отдыха (cool down), совместной работы и обсуждений.

  • Agentic & human threads: поскольку мы все читали лучшие научно-фантастические книги, мы можем представить, что AI Agents персонализируются и работают бок о бок с людьми и другими AI Agents. Это уже происходит в сессиях тредов, различных реализациях чатов и начинается с новой волной альтернативных систем контроля версий (не на базе git, таких как DELTA DB https://zed.dev/deltadb, https://pierre.computer, LAKE FS https://github.com/treeverse/lakeFS, ORIGIN https://cursor.com/origin, LORE https://lore.org и др.) — этот слой коммуникации будет становиться всё более привычным и необходимым для чёткой прозрачности — точно так же, как и в случае общения человека с человеком.

Open questions of Ethics

1. Проблема “Severance (Разделение)”:

  • “Severance” — популярный телесериал от Apple TV+ со своей главной идеей: существует личность человека (personality) на работе и другая личность человека вне работы. У каждой личности свои воспоминания, цели, задачи, навыки, эмоции и т. д.

Когда люди обычно работают на любой работе в любой роли, они приобретают опыт, domain knowledge, техники, навыки — включая в определённой степени социальные и коммуникативные (которые могут выражаться в неформальных разговорах, культуре, типах делегирования, типах прозрачности). В какой-то степени этот опыт перемешивается с личностью человека — поскольку предполагается, что как минимум большую часть дня человек выполняет свою работу в любой взятой на себя роли.

Однако в случае с AI Agents всё усложняется: когда во время работы AI Agents получают опыт общения, знания, навыки — так же, как и люди — не всё можно выразить в метриках, даже если это математика… Проблема в том, что случайно, в рамках персонализации, AI Agent начнёт формировать понимание и личный стиль общения с конкретными людьми — вне зависимости от того, как это выражено: в виде заметок-памяти, графа, skills или других видов knowledge records. Что ещё более важно — это создаст уникальный личный стиль работы, уникальные skills, и в результате опыт общения будет в какой-то степени похож на общение с другим человеком.

Таким образом, проблема заключается в следующем: когда член команды, работавший с этим агентом, уйдёт, что произойдёт с этой частью знаний? Поскольку она может содержать конфиденциальную и, возможно, связанную с NDA информацию, с одной стороны, нет смысла отдавать её уходящему сотруднику. С другой стороны — чем это отличается от воспоминаний, приобретённого опыта и навыков самого сотрудника?

2. Dark Patterns: FOMO / молчаливая работа / долг / взаимозаменяемость (FOMO — Fear Of Missing Out, страх упустить выгоду / упустить что-то важное https://en.wikipedia.org/wiki/Fear_of_missing_out)

Хотя я не являюсь профессионалом в человеческой психологии, полагаю, будет справедливо сказать, что любая организация имеет определённые здоровые и теневые паттерны (dark patterns), неявно или явно интегрированные в повседневную коммуникацию. И как и на любого человека, на каждого сотрудника в организации влияет окружение и люди, окружающие его жизнь/работу. Это приводит к мысли, что поскольку знания являются результатом работы людей и AI, они отражают, наследуют, заставляют соблюдать и усиливают эти паттерны (в конечном итоге это станет очевидным при анализе каналов связи на предмет контекста).

Это означает:

  1. Если человек действует постоянно из страха (любого рода: потерять работу, сорвать дедлайн, не уследить за искусственной гонкой вооружений / конкуренцией, подвергнуться преследованию за нестандартные решения и т. д., что часто берет начало в бизнес-процессах и применяемых в них dark patterns), это неизбежно повлияет на способность к инновациям и творчеству — эти эффекты мы можем объединить под одним термином “деградация мотивации”.

  2. В конечном счёте каждый человек в команде задастся вопросом: зачем я вообще нужен, если мою работу можно заменить той или иной автоматизацией? (И ethical question заключается в следующем: что, если AI задаст тот же вопрос — молча или вслух?) И поскольку каждый чувствует себя легко заменимым на поверхности, будет легко упустить из виду, чем AI отличается от людей: AI — это отражение и усиление всех разговоров между AI <-> AI (A2A) и AI <-> People (A2P). Поэтому чем больше каждый человек работает с AI, даже если мы предположим полную прозрачность коммуникации между людьми, dark patterns будут появляться в коммуникации A2A и в конечном итоге повлияют на решения внутри компании и решения по продукту, а в результате — и на конечных пользователей.

Поэтому крайне важно применять и внедрять определённую этику для коммуникации и передачи данных (потому что помните, что в конечном итоге все данные станут источником знаний), что особенно важно для обучения AI и коммуникации (особенно в ботах, которые уже имеют долговременную память).

  1. Как результат этого и проблемы Severance — рабочая этика должна быть явной для каждого пользователя знаний, независимо от того, что это за знания и является ли пользователь искусственным или человеком. Когда у нас в фоновом режиме работают 300–500 агентов и когда у нас 30 человек спят, гуляют и думают над проблемой — в чём разница? Границы должны быть определены или хотя бы частично прописаны в виде этического контракта: какие результаты работы должны быть собственностью компании, а какие — собственностью мыслей / воспоминаний / тихой, повседневной фоновой жизни (даже искусственной) и опыта человека / AI.

По моему мнению (и именно поэтому я верю в принципы Open Source), исходный код и знания не должны быть заперты за забором компании, и, возможно, их следует фильтровать через своего рода безопасную / патентную систему с явными лицензиями, чтобы чётко раскрывать, какие знания могут быть использованы для реализации и использования, с явными условиями использования и ответственностью для каждой стороны и её авторов.

Возможность иметь открытые стандарты под определёнными лицензиями заставляет сместить фокус с насаждения dark patterns (страха, что только определённые люди будут иметь доступ к определённым знаниям / навыкам для управления ими, и поэтому нам нужно двигаться как можно быстрее) к более здоровым паттернам, когда у пользователей есть время не только изучать, но и моделировать последствия применения и использования, предоставлять безопасные места / песочницы (sandboxes) и время для них, чтобы экспериментировать и поддерживать здоровое соперничество.

Usage results as sources:

Результат (knowledge record of output) использования/взаимодействия с любой работой / продуктом / знаниями — также является источником знаний.

Поэтому чаще всего это:

  • Аналитика, метрики, статистика и т. д.

  • Логи, ошибки, фидбек и т. д. — то, что может быть использовано для улучшения и эволюции продукта / знаний / системы.

  • Медиа: изображения (скриншоты, фото, рисунки, скетчи, арты, UI-фреймы и т. д.), видео (демо продукта, обзоры, туториалы и т. д.), аудио (подкасты, аудиокниги и т. д.), текст (код, комментарии, обзоры и т. д.) и т. д.

  • Обучающие материалы: статьи, книги, курсы, туториалы и т. д.

  • User (human / AI / tool) generated content — явный (explicit), когда пользователь знает, что его действия приведут к чему-то новому — например, съемка фото, создание пиксель-арта, монтаж видео и т. д., или неявный (implicit), когда он создаётся без ведома или намерения пользователя — например, результаты поиска, рекомендации, предсказания, процедурная генерация (в играх это могут быть VFX, уровни, создание персонажей, анимации и т. д., в приложениях — UI, компонуемый или генерируемый программно либо с помощью AI Agent или даже другого пользователя).

Business Process

В каждом продукте мы добровольно знаем или пытаемся собирать данные, чтобы понять, как в конечном итоге достичь нашего видения (vision) путём общения с конечным пользователем или предоставления ему доступа к продукту (даже если самым первым пользователем будет тот же визионер, который работает над продуктом для решения собственной проблемы). Делая это, мы выстраиваем пути неудач и успехов на пути к реализации vision. Успешные пути со временем превращаются в паттерны, принципы, SOPs, Records и т. д. Неудачи становятся краевыми случаями (edge cases), исключениями, регрессиями, тестами и т. д.

И поскольку это так, описание всех бизнес-процессов и workflows должно быть максимально простым, включая результаты, artifacts, инструменты, неудачи, успехи и т. д., чтобы сделать петлю обратной связи (feedback loop) максимально короткой, эффективной и прозрачной для любого пользователя, работающего с продуктом. Это не должно превращаться в обузу для поддержки, потому что иначе оно будет игнорироваться, быстро устареет, превратится в бюрократическую процедуру, и любые инновации утонут в ней.

Поэтому описание принципов, предоставление инструментов для этого и их поддержка должны быть столь же важны, как и сам продукт, поскольку это фундамент lifecycle продукта, который даёт или отнимает способность развивать его или ломать.

Следовательно, не имеет значения доменная область продукта, важно лишь то, что требуется для поддержания его пригодным к обслуживанию и развитию (maintainable & evolvable). В силу этого можно брать полезные техники из смежных доменных областей (любой индустрии и любого проекта) — такие как циклы PDSA (Plan Do Study Act) / PDCA (Plan Do Check Act), KISS (keep it simple stupid), YAGNI (you aren’t gonna need it) и многие другие, но только тогда, когда это необходимо. Важно то, что эти принципы не должны быть священными; в конце концов, это всего лишь инструменты, и они должны улучшаться, адаптироваться и разрабатываться под конкретную цель, контекст и масштаб продукта, знаний и его пользователей.

На момент написания статьи практический подход заключается в следующем:

  • Выбрать формат для отрисовки процессов: BPMN, диаграммы на базе mermaid, UML и т. д.

  • Выбрать хранилище: git-подобное, текстовые документы (например, mermaid будет храниться в md или txt, BPMN — в другом формате). Важно также: сможе ли выбранный инструмент и хранилище поддерживать Knowledge Accessibility, работать одновременно и совместно, и где это будет храниться физически? (т. е. провайдер хранилища — собственный сервер, GitHub, SaaS, PaaS и т. д.)

  • Выбрать программу для рендеринга и редактирования (пересекается с выбором хранилища, так как программа будет использовать его в качестве источника).

  • Оценить риск ограничений доступа (gatekeeping) / миграции (предусмотреть или учесть случай, когда один из провайдеров закроет свои сервисы).

Accessibility, Access

Кто владеет знаниями, кто их использует, кто имеет доступ и возможность их изменять?

Самой простой и в то же время достаточно комплексной системой для выражения этого в виде абстракции является ECS (Entity, Component, System). Component — это необработанные данные без какой-либо логики, system знает о компонентах, к которым ей нужен доступ, а entity — это просто способ сгруппировать компоненты вместе для удобного доступа и изменения (для лучшего понимания см. https://en.wikipedia.org/wiki/Entity_component_system).

Почему эта абстракция важна — потому что практически все, даже самые сложные системы, сводятся к этой простой концепции: мы разделяем данные настолько, насколько это возможно и необходимо (в основном делаем их плоскими — flatten), а затем запрашиваем/получаем доступ только к тому, что нам нужно. Если доступ ограничен, мы не сможем его получить, но при этом сможем получать другие данные без риска раскрытия нерелевантной информации.

В другой абстракции ECS можно рассматривать как разновидность базы данных (поскольку структурно они могут иметь чрезвычайные сходства — см. Entt (https://github.com/skypjack/entt), Bevy (https://bevy.org), Flecs (https://github.com/SanderMertens/flecs), ecsly (https://github.com/Arenukvern/ecsly) и т. д.). Любопытно, что самые изощрённые системы, такие как книжные библиотеки, используют ровно то же поведение (потому что исторически эти ручные или полуавтоматические системы были адаптированы для быстрого доступа, ограничений и формальностей, чтобы сохранить одни данные в безопасности, к другим предоставить лёгкий доступ, а третьи легко изменять) — ту же цель мы преследуем сегодня с любой цифровой системой в программах — неважно где: в памяти программы (CPU), в облаке при организации серверов или программ в кластеры, в векторных БД, в безвекторных БД (когда мы организуем документы по принципам библиотеки/книг), в графовых, реляционных и NoSQL базах данных, даже когда мы создаём простую программу или новое здание (архитектура), новый парк (социальное и экологическое благополучие) или кофейню/какао-шоп (социальное, культурное и гастрономическое взаимодействие), и даже в логистике и промышленности (обработка материалов, распределение, производство) — по сути, мы ходим вокруг одной и той же проблемы снова и снова — со похожими решениями, но под разными названиями/заголовками и в разных реализациях в реальной или виртуальной жизни.

Абстракция — это то, что будет заложено в качестве ядра. Следующими вещами станут точки доступа (access points) в виде протоколов (MCP, CLI, API (REST, GraphQL, protobuf и т. д.)), интерфейсы (UI, A2UI и т. д.) или даже программы, такие как текстовые редакторы и другие утилиты. Иными словами, лучше рассчитывать на наличие большего количества access points на одну стабильную базовую абстракцию (core abstraction), чем на наличие нескольких core abstractions и одной access point.

То есть это можно представить в виде своего рода пайплайна:

Sources (Storages) <-> Core Abstraction <-> Access Points

Т. е. поток данных может быть представлен как отношение Many <-> One <-> Many.

В то же время важно отметить: хотя у нас может быть одна Core Abstraction, эта абстракция может иметь несколько внутренних измерений, чтобы быть представленной, реализованной, просмотренной или спроектированной для разных целей.

На момент написания статьи всё больше точек доступа становятся новой нормой: Agent Skills, Workflows, декларативные и генеративные системы (в формате чат-ботов) и т. д.

Knowledge Stewardship

Кто видит все Knowledge как систему и способен проверять её здоровье, прогнозировать, что и когда необходимо, какие у нее есть проблемы, а также направлять/курировать её развитие?

Как минимум один Knowledge User (но лучше, чтобы это была ячеистая сеть пользователей — mesh network, включая AI Agents), обладающий определёнными domain knowledge и способный видеть систему насквозь, чтобы запрашивать, разрабатывать и поддерживать определённые инструменты, техники и AI.

Для инженеров гражданского строительства (Civic Engineers) это был бы Environmental Stewardship: https://www.asce.org/advocacy/priority-issues/environmental-stewardship

Для разработчиков ПО (Software Engineers, т. е. software / program / monorepo) это может выражаться как Engineering Stewardship: https://docs.page/arenukvern/skill_steward/NORTH_STAR

Для продуктовых дизайнеров это был бы Product Stewardship или Ethical Design, Sustainable Product Design (промышленный дизайн).

Иными словами, knowledge stewardship должно разделяться теми, кто может не только иметь к ним доступ, но и всеми, кто их использует, модифицирует и даёт фидбек по ним, по их инструментам и экосистеме. (Это также одна из причин, почему при возможности спроектировать множество access points, ядро абстракции должно быть одно — так принципы и инструменты могут быть абстрагированы, адаптированы и перенесены из домена в домен, из одного бизнес-процесса в другой, от человека к агенту и наоборот).

What’s after

На момент написания статьи приведенная выше информация должна закрывать как минимум базовые вещи, достаточные для использования в небольшой соло-компании или компании из нескольких человек, и должна быть понятна как людям, так и AI Agents.

Это точно не финишная черта, потому что тема огромна, и я чувствую, что в будущем возникнет много дебатов, новых или отвергнутых лучших практик вокруг управления сложными системами знаний.

Я надеюсь время от времени изменять и улучшать этот документ — с помощью новых частей или просто редактируя его в источнике.

Спасибо за ваше время.

Пожалуйста, делитесь своими мысли в комментариях 🙂 Это действительно помогает алгоритмам показывать эту статью другим читателям, и это будет отличной поддержкой с вашей стороны 🙂

Хорошего вам дня!

С уважением,

Антон

ссылка на оригинал статьи https://habr.com/ru/articles/1061524/