Что сделал мой ИИ-агент? Четыре вопроса, на которые нужен ответ с доказательствами

Чтобы понять, что сделал твой ИИ-агент, не начинай с его резюме. Проверь четыре вещи: какое подключение выполнило работу, что изменилось (и это подтверждено тем, что ты можешь открыть сам), что осталось несделанным и что было решено и почему. Если хоть один из четырёх ответов держится только на словах агента, перед тобой пересказ, а не запись.

Weft делаем мы. Сведения о других продуктах взяты с их официальных страниц и проверены 27 октября 2026 года.

Почему комментария «готово» недостаточно?

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

В статье Hypertask об атрибуции работы ИИ есть справедливая мысль: работа агентов должна попадать на ту же доску, что и работа людей, а не в терминальный лог, который никто не читает. Hypertask к тому же даёт агентам собственную идентичность в виде сервисных аккаунтов, так что записи приписываются агенту, а не тебе, и у него есть доказательства по задачам и аренды — хотя его документация говорит, что это только REST-эндпоинты, а не MCP-инструменты, и так задумано. Расходимся мы в том, что должно быть в записи. Ветка комментариев с выводом агента — это лог того, что агент сказал. Мы хотим, чтобы в записи лежали доказательства.

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

Что это за четыре вопроса?

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

1. Кто это сделал? Какой клиент, через какое подключение, взял и закончил задачу.
2. Что изменилось? Итог плюс артефакты, которые можно проверить, не доверяя агенту: хеш коммита, URL, файл, id сообщения.
3. Что не сделано? Части, которые агент пропустил, и то, в чём он не был уверен.
4. Что решено и почему? Любой выбор, сделанный по ходу, с вариантами, которые взвешивались, и каждый раз, когда ты возвращал работу.

Как узнать, какой агент это сделал?

Weft подключается к ИИ-клиентам по Model Context Protocol через один эндпоинт, https://letsweft.com/api/mcp. Каждый OAuth-клиент и каждый персональный токен доступа — отдельный участник. Задача помнит, какой клиент её создал, а доска показывает имя, под которым этот клиент зарегистрировался при входе, и значок. Каждое событие в журнале задачи хранит, пришло ли оно от человека или через MCP и какой клиент его отправил.

Полный журнал (get_task_history в режиме full) показывает для каждого события сырой id клиента: OAuth client id или mcp-token, за которым следует id токена. Имя не самое дружелюбное, зато точное, и оно различает два подключения, даже если оба от одного и того же продукта.

Владение задачей во время работы тоже явное. Агент вызывает start_task, который забирает задачу с арендой на 20 минут и переносит её в Doing. report_progress продлевает аренду. Второй агент, который попробует взять ту же задачу, получит already_claimed, а истёкшая аренда освобождает задачу для кого-то другого. Пошагово это разобрано в руководстве по циклу захвата, а случай с несколькими клиентами — в статье о нескольких агентах на одной доске.

Одно практическое правило: дай каждому инструменту своё подключение. Если два клиента делят один токен доступа, доска видит одного участника, и вопрос «кто» остаётся без ответа.

Что изменилось — и можно ли проверить это, не спрашивая агента?

Закончив, агент вызывает complete_task. Обязателен только id задачи; всё остальное — по желанию, и вызов никогда не падает из-за отсутствия доказательств. Так задумано: потерять готовую работу хуже, чем записать её непроверенной. Что может быть в отчёте:

• outcome: до 1000 символов о том, что сделано и где лежит результат.
• artifacts: до 20 записей, у каждой — тип (url, file, message, commit и так далее), адрес и, по желанию, дайджест sha256.
• claims: что агент утверждает о сделанном; хранится как утверждения, а не проверенные факты.
• notDone и unknowns: о них — в следующем разделе.
• nextStep: что агент сделает дальше, если ты примешь.

complete_task({
  "id": "<task id>",
  "runId": "<from start_task>",
  "leaseToken": "<from start_task>",
  "outcome": "Rate limiting added to /login; PR open, not merged.",
  "artifacts": [
    { "kind": "commit", "uri": "<repo>/commit/<hash>" },
    { "kind": "url", "uri": "<repo>/pull/<number>" }
  ],
  "notDone": ["Did not change the signup endpoint"],
  "unknowns": ["Limit of 5 per minute is a guess; no traffic data"],
  "nextStep": "Merge the PR to main"
})

Строка outcome — всё ещё пересказ. Проверить можно артефакты. Хеш коммита либо есть в твоём репозитории, либо нет. URL либо открывается, либо нет. sha256 файла либо совпадает, либо нет. Если в отчёте есть итог, но нет артефактов, считай это работой со слов агента — потому что так оно и есть. В вебе на карточках в Done видно, «Проверено» задача или «Со слов агента».

Чего агент не сделал?

Этот вопрос большинство записей пропускает, и именно он кусает через две недели. Для него в complete_task есть два списка, каждый до 20 записей по 500 символов: notDone — то, что агент сознательно оставил за бортом, и unknowns — то, в чём он не уверен. Описание инструмента прямо просит агентов вслух говорить, чего они не сделали. Именно это отличает результат, на который можно опереться, от результата, который приходится выводить заново.

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

Что решено и почему?

Решения, принятые в чате, исчезают, когда чат уезжает вверх. record_decision сохраняет их двумя способами:

• Отдельная запись решения: заголовок, итог, контекст, варианты, которые действительно взвешивались, последствия и условие, при котором решение стоит пересмотреть. Записи неизменяемы; чтобы что-то поменять, записывают новое решение, которое заменяет старое, а старое остаётся с пометкой «заменено».
• Передача вердикта: когда ты говоришь агенту в разговоре «принято», «переделай с X», «отбрось» или «не сейчас», он записывает этот вердикт на задачу вместе с твоим пояснением.

get_task_history читает это обратно в трёх режимах: summary (карточка, её последний отчёт и счётчики), decisions (все решения по задаче, включая то, почему её возвращали, — это сохраняется даже после более позднего принятия) и full (сырой журнал, не больше 100 событий). get_context передаёт действующие решения следующему агенту в пределах бюджета токенов, так что следующий запуск начинается с принятых решений, а не с нуля. Подробнее — в статье о том, почему решения из ИИ-чатов теряются.

Где это проверять и что нажимать?

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

Если агент передал nextStep, он показывается над кнопкой «Принять», и принятие одобряет ровно этот шаг. Одобрение действует 72 часа и возвращается к агенту через get_my_work или start_task как единственный следующий шаг. Вопросы, которые агент задаёт через request_input, попадают в те же Входящие — в вебе и в приложениях для iOS и Android, с пушем на телефон.

У Входящих намеренно есть лимит: 5 ждущих пунктов для пространства на одного человека, 10 для команды или 45 минут оценённого времени проверки — смотря что наступит раньше. Когда лимит заполнен, start_task отказывает с attention_queue_full, и агенты доводят или уточняют уже начатое, вместо того чтобы наваливать тебе ещё больше на проверку.

Какие доказательства просить для разных типов задач?

Впиши это в описание задачи, чтобы агент знал, каких доказательств ты ждёшь:

• Код: хеш коммита и URL пулл-реквеста как артефакты. В notDone должны быть названы незапущенные тесты, неприменённые миграции и файлы, которые сознательно не трогали.
• Контент: URL опубликованного материала или файл черновика с его sha256, если он ещё не опубликован. В unknowns — факты, которые агент не смог подтвердить.
• Исследование: URL источника для каждого ключевого утверждения и файл с заметками. В unknowns нужно отделить то, что говорит источник, от того, что агент вывел сам.
• Рассылка: id каждого отправленного сообщения и список получателей файлом. В notDone — с кем не связались и почему.

Как заранее ограничить, что может делать агент?

Атрибуция задним числом работает лучше всего вместе с ограничениями заранее. В Weft у каждого OAuth-подключения один из трёх уровней прав — он задаётся на экране согласия или позже в «Настройки» → «Подключённые AI-клиенты»:

• full (по умолчанию): все 32 инструмента.
• write: всё, кроме трёх разрушительных инструментов (trash_task, archive_done_tasks, complete_sprint).
• read: только 11 инструментов для чтения.

Проверка выполняется при каждом вызове. Отключение отзывает refresh-токены подключения и при следующем вызове отклоняет любой токен, выданный до отключения. У персональных токенов доступа — для клиентов без OAuth — областей прав нет: один токен открывает все 32 инструмента, а отзыв срабатывает со следующего вызова. Агенты могут переносить задачи в корзину на 30 дней, но не могут удалить их насовсем; восстановление из корзины — функция Pro.

Чего Weft здесь не делает?

• Интеграции с GitHub или Slack нет, поэтому Weft не ищет за тебя коммиты или сообщения. Артефакт открываешь ты.
• Нет публичного REST API, вебхуков или CLI, чтобы отправлять отчёты в другие системы. Есть экспорт в JSON и Markdown.
• Шаги модели он не трассирует. Инструменты, которые логируют промпты, токены и задержки на уровне модели, решают другую задачу, и такой инструмент тебе тоже может пригодиться.
• Агенты пишут отчёты сами. Weft делает видимым разрыв между утверждением и доказательством; сделать агента честным он не может.

Если тебе нужны агенты в виде сервисных аккаунтов через REST API, CLI для скриптов CI или встроенные ИИ-функции вроде написания и разбора задач, Hypertask подходит для этого лучше. На нашей странице об альтернативе Hypertask они сравниваются бок о бок.

Разве истории git не хватает, чтобы понять, что сделал агент?

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

А агент не может просто выдумать артефакт?

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

Каждая готовая задача ждёт моей проверки?

Нет. По умолчанию завершённая задача уходит в Done. Во Входящих на «Принять», «На доработку», «Позже» или «Отбросить» она ждёт, только если требует проверки или не прошла проверку верификации.

Какие ИИ-клиенты могут записывать отчёты в Weft?

Любой MCP-клиент. В ChatGPT Weft — опубликованный плагин на любом тарифе, включая бесплатный. Claude Code подключается командой claude mcp add --transport http weft https://letsweft.com/api/mcp. Claude.ai и Claude Desktop используют собственный коннектор. Есть страницы настройки для 33 клиентов, например Claude Code, ChatGPT, Cursor и Codex.

Сколько это стоит?

Бесплатный тариф (Free) включает 50 задач и 200 вызовов ИИ в месяц. Pro стоит $7 за место в месяц или $60 за место в год. Кредитов на ИИ в Weft нет: думает твой собственный ИИ-клиент. Смотри цены.