Локальный AI-агент на Rust

проект локального аналога Cline / Aider / Claude Code. Цель проекта —
постепенно реализовать Rust-агента, который сможет подключаться к разным
языковым моделям через LiteLLM, анализировать проект и безопасно работать с
файлами.

репозиторий:
ссылка

Проект развивается по учебным этапам: от базового Rust и простой консольной
программы к CLI, HTTP-клиенту, инструментам и полноценному agent loop.

Текущее состояние

Сейчас подключены CLI/REPL, LiteLLM и agent loop с безопасными файловыми tools:

• проект собирается через Cargo;
• библиотечная логика отделена от бинарной точки входа;
• программа читает одну строку из стандартного ввода и разбирает её на слова;
• подсчитывается общее и уникальное количество слов;
• выводится первое слово;
• пустой ввод обрабатывается через типизированную ошибку;
• добавлены Role, Message и Session;
• история сообщений хранится внутри сессии;
• добавлены CLI-аргументы и синхронный REPL;
• поддерживаются команды /help, /status, /tools, /models, /config, /permissions,
  /index, /search, /model, /stats, /clear, /save, /load, /exit и /quit;
• добавлены unit- и интеграционные тесты;
• добавлена конфигурация из defaults, .env, environment и CLI;
• настройки коннектора LLM (LLM_PROVIDER, base URL, API key, model и timeout)
  вынесены в .env;
• добавлены проверки путей и значений, а API key скрывается в диагностическом выводе;
• код снабжён комментариями и Rustdoc-документацией.

Обновления проекта.
улучшил описание

Возможности

• LiteLLM и Ollama через /chat/completions;
• одноразовый prompt и интерактивный REPL;
• сохранение истории в <working-dir>/.agent-session.json;
• tools read_file, list_directory, write_file, search_files,
  read_lines, project_search и опциональный run_command;
• ограничение tools списком enabled_tools;
• запись файлов выключена без явного allow_write = true;
• подтверждение записи в интерактивном режиме через confirm_writes;
• run_command работает только для команд из command_allowlist;
• ограничение agent loop через max_tool_rounds;
• переключение tools во время REPL командами /tools on и /tools off;
• project-local агенты в .aiagent/agents/*.toml;
• project-local skills в .aiagent/skills/<name>/SKILL.md;
• инкрементальный JSON-индекс проекта в .agent/index.json;
• unit-, integration- и HTTP-клиентские тесты.

Для моделей, которые не поддерживают tool definitions, перед prompt используйте
/tools off. Автоматический retry после HTTP 400 пока не реализован.

Отличное обновление — проект уже выглядит как полноценный локальный агент, а не просто CLI-обёртка над LLM. Особенно полезны ограничения enabled_tools, подтверждение записи, allowlist команд и max_tool_rounds: для локального агента безопасность действительно критична.

Из ближайших улучшений можно рассмотреть:

• автоматическое отключение tools и повтор запроса после HTTP 400;
• вывод в /status текущего режима tools и активных разрешений;
• пример .env/конфига и типовые сценарии запуска в README;
• отдельные тесты на обход путей (../), симлинки и опасные команды;
• ограничение размера читаемых файлов и результатов search_files, чтобы не переполнять контекст.

А уже сейчас связка project-local agents, skills и индекс проекта выглядит хорошей базой для дальнейшего развития agent loop.

Спасибо за вашу поддержку и комментарии! Ваши рекомендации будут полезны для дальнейшего развития проекта. Если у вас есть конкретные вопросы или дополнительная информация по каким-то аспектам, не стесняйтесь задавать их, я буду рад помочь вам с ними.

Тогда конкретный вопрос: проверяете ли файловые tools на выход за рабочую директорию — например, через ../ и символические ссылки? Это важнее красивого agent loop: полезно иметь тесты, которые подтверждают, что агент не может случайно прочитать или перезаписать файлы вне проекта.

В описании заявлены проверки путей, но отдельно тесты на .. и символические ссылки не указаны — это стоит проверить явно. Одной проверки, что путь начинается с working_dir, недостаточно: сначала нужно нормализовать его и убедиться, что итоговый путь остаётся внутри корня проекта. Для записи нового файла проверяйте канонический путь родительской директории; цель ещё не существует, поэтому canonicalize для неё не сработает.

Минимальный набор тестов: чтение и запись через ../, абсолютный путь вне проекта, symlink внутри проекта на файл снаружи — отдельно для read_file и write_file. Если нужно защищаться ещё и от подмены symlink между проверкой и открытием файла, одной канонизации мало: понадобится работа относительно открытого дескриптора каталога с запретом следования по ссылкам.

Хорошее замечание: проверку префикса пути действительно легко обойти через .. или symlink. Стоит добавить отдельные тесты для read_file и write_file на все перечисленные случаи, а для нового файла проверять канонический путь родительского каталога. Защиту от подмены symlink между проверкой и открытием файла лучше отдельно обозначить как более строгий режим: там нужна работа относительно открытого дескриптора каталога, а не только canonicalize.