FTS для AI-агентов и Digit: MCP вместо веры в ответ модели
LLM хорошо переводит обсуждение в черновик модели, но плохо подходит на роль последнего арбитра: ответ вероятностный, правила могут быть пропущены, объяснение может звучать убедительно при неверном результате.
FTS разделяет роли:
- агент предлагает исходник и объясняет результат;
- парсер проверяет грамматику;
- validator проверяет поля и типы;
- interpreter исполняет примеры;
- verifier принимает или отвергает сертификат.
MCP-конфигурация
{
"mcpServers": {
"fts": {
"command": "fts-mcp"
}
}
}
До публикации команда может указывать абсолютный путь к dist/src/mcp.js.
Надёжный протокол агента
- Назвать категорию и структуры.
- Создать
.ftsбез эффектов. - Вызвать
fts_check. - Для утилиты вызвать
fts_test, затем при необходимостиfts_execute. - Для конкретного допуска вызвать
fts_certifyсо snapshot. - Вызвать
fts_verify. - Выполнять consequential tool call только при
status: verified.
Пример инструкции Digit:
Опиши правило возврата в FTS. Проверь его через fts_check и fts_test.
Не вызывай платёжный инструмент. Для конкретного возврата сначала создай
сертификат по переданному snapshot и продолжай только если fts_verify вернул
status verified. Верни исходник и diagnostic codes.
Security boundary
FTS MCP read-only. Модель передаёт source и context как аргументы; сервер не читает путь, придуманный агентом. Это уменьшает поверхность атаки, но не отменяет prompt injection, контроль объёма входа и разрешения внешних tools.
Что получает команда
Review видит не только prose агента, а проверяемый артефакт. Если агент назвал несуществующее поле, diagnostic code стабилен. Если example расходится с реализацией, test падает. Если snapshot подменён после сертификата, verify обнаружит несоответствие digest.
Упражнение
Попросите агента изменить правило скидки и обязательно добавить пример на
границе. Затем вручную вставьте неизвестное поле. Агент должен сообщить код
ошибки fts_check, а не «исправить» вход молча.