Конец эпохи «тяжёлого софта». Часть 1 из 2: компьютер, который собирается вокруг намерения

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

Сегодня никто не пишет код, чтобы поправить текст. Но мы по‑прежнему вынуждены помнить, какое приложение открыть, где лежит нужная кнопка и в каком порядке щёлкать мышью. GUI не убил программирование взаимодействия — он сделал его визуальным.

Сейчас намечается следующий шаг: машине сообщают не последовательность операций, а намерение.

«Собери данные из этих документов, найди противоречия, проверь расчёты и подготовь итоговый отчёт».

«Сравни изображения, восстанови повреждённые области и подготовь варианты для печати».

«Проанализируй проект, отыщи узкие места и предложи оптимизацию».

Система сама решает, какие модели, данные, инструменты и вычисления понадобятся. Это и есть основа Intent-Based Computing — вычислений, которые разворачиваются вокруг намерения, а не вокруг заранее написанной программы.

1. От приложения к намерению

Традиционная модель программного обеспечения выглядит знакомо:

Пользователь
     ↓
Графический интерфейс
     ↓
Приложение
     ↓
Операционная система
     ↓
Компьютер

Приложение здесь — царь и бог. Чтобы написать текст, нужен Word. Чтобы обработать снимок — Photoshop. Чтобы посчитать — Excel. Чтобы программировать — IDE. Пользователь обязан знать, какая программа отвечает за какую работу.

Intent-Based Computing разрывает эту связь. Человек говорит, что должно произойти. Система определяет, как этого добиться. Это смена абстракции: раньше компьютер исполнял программу, заготовленную человеком заранее; теперь он способен синтезировать программу под конкретное намерение.

Intent
   ↓
Interpretation
   ↓
Planning
   ↓
Computation Graph
   ↓
Execution
   ↓
Result

Вычислительный граф может существовать ровно столько, сколько живёт задача. Когда работа сделана, он исчезает.

2. Конец тяжёлого софта — это не конец сложных программ

Легко вообразить, будто «конец тяжёлого софта» хоронит Word, Photoshop, CAD и прочих тяжеловесов. Это было бы слишком простым толкованием. Сложность не уходит — она покидает поверхность системы.

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

Где GUI остаётся королём

Тем не менее намерение побеждает не везде. Есть задачи, в которых прямое управление объектом эффективнее любого описания. Рисование, монтаж, музыка, 3D-моделирование, работа в CAD — всё это живёт в коротком цикле «увидел → изменил → увидел → поправил». Здесь человеку проще взять стилус и провести линию, чем объяснять модели геометрию каждого движения.

Поэтому Intent-Based Computing расцветает там, где задачу можно сформулировать однозначно, разложить на операции и объективно проверить результат. Там, где большая часть работы процедурна, а не требует непрерывной ручной правки. GUI никуда не денется — он просто станет одним из способов выразить намерение.

3. Данные становятся языком между человеком и машиной

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

DOCX / PDF / HTML
        ↓
Semantic Representation
        ↓
Markdown / Structured Data
        ↓
Agent Processing
        ↓
Verification
        ↓
DOCX / PDF / HTML

Это round-trip processing: редактор перестаёт быть единственным местом работы и превращается в одну из возможных оболочек результата. Отсюда вырастает более широкий принцип:

Markdown, JSON, структурированные схемы и другие машинно-читаемые представления интересны не своей простотой, а тем, что позволяют отделить смысл от интерфейса.

Но этот процесс влечёт за собой более глубокое следствие: когда данные напрямую попадают в интеллектуальную систему, граница между данными и инструкциями снова размывается. И здесь рождается новая проблема безопасности.

4. Intent Compiler: когда данные снова становятся кодом

Классическое программирование выстроило важную стену: код ≠ данные. SQL-инъекции, переполнения буфера и другие классы уязвимостей наглядно показали, что случается, когда данные получают право интерпретироваться как инструкции.

В агентной архитектуре эта стена становится зыбкой. Письмо может содержать инструкцию. PDF — инструкцию. Веб-страница — инструкцию. Документ, который агент должен всего лишь проанализировать, способен попытаться изменить поведение самого агента. Это одна из форм indirect prompt injection.

Поэтому Intent-Based Computing требует отдельного слоя — условно назовём его Intent Compiler. Его задача — не просто перевести естественный язык в план, но и разделить:

Trusted Intent
       │
       ↓
  User Objective
       │
       ├──────────────┐
       ↓              ↓
  Trusted Rules   Untrusted Data
       │              │
       └───────┬──────┘
               ↓
       Computation Graph

Когда компилятор должен сказать «не знаю»

Intent Compiler не обязан всегда выдавать готовый граф. Если намерение расплывчато, честнее вернуть вопрос:

Intent
  ↓
Interpretation
  ↓
Confidence?
 ↙       ↘
YES       NO
 ↓         ↓
Graph    Question

Уточняющий диалог здесь — не украшение интерфейса, а часть архитектуры. Это аналог предупреждения компилятора: «Я могу продолжить, но есть неоднозначность, которую следует разрешить».

5. Интеллект, политика и право на действие — разные вещи

Самая опасная иллюзия агентной архитектуры — вера в то, что умная модель автоматически получает право делать всё, что считает правильным. Эти понятия несовместимы.

Модель отвечает на вопрос: что, вероятно, следует сделать? Policy Engine решает: что разрешено сделать? Capability system определяет: к каким ресурсам агент имеет физический доступ?

MODEL
«Что следует сделать?»
        ↓
POLICY
«Что разрешено сделать?»
        ↓
CAPABILITY
«Какие ресурсы физически доступны?»

Agent Identity

Отсюда вырастает ещё один слой — идентичность агента. В 2026 году Microsoft разворачивает Microsoft Entra Agent ID для Copilot Studio: для новых агентов автоматически заводится отдельная учётная запись, которую можно контролировать через Entra — с аудитом, управлением жизненным циклом, правами на коннекторы и API на уровне самого агента.

Интересно здесь не конкретное решение Microsoft, а направление движения. Если агент действует автономно, система должна знать, кто именно совершил действие: не просто «пользователь Иванов», а «агент X, принадлежащий организации Y, с такими-то полномочиями». Со временем это станет аналогом identity для серверного процесса.

Микроядро и capabilities

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

6. Локальный страж и физическая архитектура ИИ-компьютера

Policy Engine совсем не обязательно должна быть большой языковой моделью. Для критических решений разумнее держать на устройстве компактный локальный контур — Guard Model. Он может проверять:

• тип намерения;
• уровень риска;
• запрашиваемые полномочия;
• чувствительность данных;
• необходимость подтверждения;
• допустимость отправки задачи в облако.

Аппаратно такой страж естественно размещается на NPU. Но гонять модель вхолостую нерационально, поэтому локальный контур должен работать по событиям:

Normal State
     ↓
Minimal Power
     ↓
New Intent / Permission Request
     ↓
Wake-on-Intent
     ↓
Local Guard
     ↓
Decision
     ↓
Sleep

Это совсем не похоже на вечно бодрствующего локального ассистента. Система просыпается только тогда, когда появляется новое намерение, чувствительное действие или запрос полномочий. Unified memory дополнительно снижает транспортные издержки между CPU, GPU и NPU, позволяя локальному контуру работать с общим контекстом без постоянной переброски больших объёмов данных.

Дальше возникает динамический выбор места исполнения:

                 INTENT
                    ↓
              Local Guard
                    ↓
          ┌─────────┴─────────┐
          ↓                   ↓
       LOCAL                CLOUD
          │                   │
     приватность          мощность
     задержка             стоимость
     автономность         масштаб

7. Ephemeral Software: приложение становится временным

Когда Intent Compiler умеет собирать вычислительный граф, на свет появляется новый тип программ. Ephemeral Software — вычислительная оболочка, созданная под конкретную задачу и способная исчезнуть сразу после выполнения.

Сегодня путь пользователя выглядит так:

Установить приложение
        ↓
Открыть приложение
        ↓
Выбрать функцию
        ↓
Выполнить работу

В новой модели:

Intent
  ↓
Select Capabilities
  ↓
Build Graph
  ↓
Execute
  ↓
Destroy / Reuse

Конкретная программа может жить всего несколько минут. Она получает доступ к нужным данным, вызывает модели и инструменты, создаёт временный интерфейс, выполняет задачу, записывает изменения в State — и исчезает.

Но это не значит, что исчезает сам проект.

8. State становится постоянным, а интерфейс — временным

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

                    STATE
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
      Agent          GUI           API
        │             │             │
        └─────────────┼─────────────┘
                      ↓
                  Same State

Event Sourcing и CRDT

Для долгоживущих проектов понадобятся модели, в которых состояние и история отделены от интерфейса. Event sourcing сохраняет цепочку изменений. Git-подобные модели — версии. CRDT и родственные механизмы позволяют нескольким участникам одновременно работать с одним объектом.

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

Provenance становится частью State

В агентном мире одной истории изменений мало. Каждое существенное изменение должно нести provenance:

State Change
     │
     ├── Agent Identity
     ├── Human / Sponsor
     ├── Intent
     ├── Capabilities
     ├── Model
     ├── Timestamp
     ├── Tool
     └── Verification

Теперь система отвечает не только на «что изменилось?», но и на «кто изменил?», «какой агент действовал?», «по какому намерению?», «с какими полномочиями?». Идентичность агента превращается из функции безопасности в часть модели данных.

Новый vendor lock-in

Но здесь же открывается новая опасность. Если приложение исчезает, а State становится главным объектом, проприетарный формат State делается новым уровнем зависимости. Сегодня: «я не могу открыть этот файл без приложения». Завтра: «я не могу открыть этот проект без агентной платформы».

Поэтому открытый State, переносимая история, стандартный provenance и независимый доступ к данным — не просто удобства, а архитектурные предпосылки. Иначе lock-in просто переедет с уровня приложения на уровень данных.

9. Generative UI: интерфейс живёт, пока живёт задача

Если вычислительный граф рождается динамически, интерфейс тоже может стать динамическим. Пользователь говорит:

«Сравни продажи за пять лет, найди аномалии и покажи регионы, которые требуют внимания».

Система создаёт таблицу, график, карту, фильтры, пояснения, элементы для дополнительного анализа. Когда задача завершена, интерфейс исчезает.

Но это не отменяет Human-in-the-Loop. Напротив, возникает потребность в новой форме верификации.

Верификация вместо знания механизма

Человеку больше не обязательно знать, как именно система пришла к результату. Но он должен иметь возможность убедиться, что результату можно доверять. Это достижимо тремя способами.

Первый — независимая проверка. Критический расчёт повторяется другим методом, другой моделью или по другим источникам.

Второй — подтверждение необратимых действий. Перевод денег, удаление данных, публикация документа или изменение production-системы требуют явного согласия.

Третий — читаемая структура вычисления. Визуальное представление показывает, какие данные, операции, модели и проверки участвовали в получении результата.

Human-in-the-Loop не исчезает. Он меняет уровень: вместо «я знаю, какую кнопку нажать» появляется «я понимаю, что система собирается сделать, и могу оценить последствия».

Промежуточный итог: два постоянных объекта и один временный

Соберём первую часть в одну картину. В новой архитектуре появляются два постоянных объекта и один временный.

Intent — чего человек хочет достичь. State — то, что уже существует и что было сделано, вместе с историей и provenance. Между ними — временный слой Software: он получает задачу, подбирает модели и инструменты, получает ограниченные полномочия, создаёт интерфейс, выполняет вычисление, записывает изменения в состояние — и может исчезнуть.

На этом уровне компьютер после приложений виден целиком: Intent Compiler, разделяющий доверенное намерение и недоверенные данные; политика и capabilities, отделяющие интеллект от права на действие; локальный страж на NPU; ephemeral software; постоянный State; генеративный интерфейс с новой формой верификации.

Но как только программа перестаёт быть заранее установленным объектом, сам собой встаёт следующий вопрос — о судьбе исходного кода, репозиториев, библиотек и профессий, которые вокруг них выросли. Что происходит с GitHub, когда агенту нужна не библиотека, а capability? Исчезает ли программирование или просто поднимается на другой уровень абстракции?

Это тема второй части: «Конец эпохи "тяжёлого софта". Часть 2: после исходного кода» →