Pi 1C Agent
Pi-профиль для разработки на 1С:Предприятие — ASK / PLAN / BUILD, субагенты, MCP, знания проекта и тестовый контур.
Агент разбирает существующую конфигурацию, планирует изменения, выбирает правильный контейнер, работает с метаданными через MCP, делегирует части задачи специализированным агентам, собирает артефакты и помогает проверить результат.
Если ты агент — установи · Быстрый старт · Возможности · Команды · ACP · Как работает · AGENTS.md
Если ты агент — устанавливай по этой инструкции.
О проекте
Pi 1C Agent — профиль для Pi Coding Agent, заточенный под реальные 1С-проекты.
Одного знания BSL мало. В рабочей базе нужно понимать, где лежит объект, можно ли менять основную конфигурацию, есть ли расширение, какие правила действуют именно в этом проекте, как получить настоящие метаданные без догадок и что считать готовым результатом: исходники, .cfe, .cf, тест или план.
Pi 1C Agent добавляет этот слой поверх обычного coding agent.
Если коротко: агент сначала разбирается в проекте, потом планирует, потом меняет код и проверяет результат. Режим вопросов отделён от записи, знания конкретной конфигурации живут отдельно от общего промпта, а большие задачи можно разложить между специализированными субагентами.
В 0.9 runtime сам собирает короткий system kernel, выбирает структурный MCP до широкого поиска, держит бюджет контекста и включает multi-agent только с нужного tier.
Возможности
| Что | Как это работает |
|---|
| ASK / PLAN / BUILD | ASK читает и отвечает. PLAN исследует задачу и готовит план. BUILD меняет файлы и выполняет работу |
| Путь работы | /taskmode выбирает docs-fix / spec-authoring / analytics / quick-fix / full-cycle / auto. Пин сессии виден в футере рядом с режимом |
| Работа с 1С-проектом | Учитывает src/cf, src/cfe, epf, erf, build-артефакты, .dev.env и проектные правила |
| Выбор контейнера | Перед изменением определяет, куда писать: в основную конфигурацию или существующее расширение |
| Метаданные через MCP | Может получать реальную структуру конфигурации и объектов вместо угадывания имён реквизитов и типов |
| Субагенты | Аналитик, explorer, planner, developer, tester, reviewer, architect, fixer и другие роли |
| Знания проекта | Хранит проверенные факты и правила конкретной конфигурации в .pi/1c, с evidence и приоритетами |
| OpenSpec | Поддерживает spec-driven workflow: исследование → предложение → реализация → проверка |
| MCP-инструменты | Подключаются отдельно: 1С MCP bundle, EDT MCP, browser, Windows UI, Vanessa и другие |
| Vanessa / КД / Humanizer | Дополнительные скиллы для Vanessa Automation, КД 2/3 и редактуры русского текста |
| Сборка и перенос | Выгрузка из ИБ, загрузка в тестовую базу, сборка .cf / .cfe, deploy-and-test |
| Память | Опциональная связка Cognee + OpenViking: короткие факты отдельно от развёрнутых отчётов. Ход пишет pending-файл и не ждёт MCP |
| Продолжение между сессиями | /session-rotate при заполнении контекста создаёт handoff, открывает свежую Pi-сессию и продолжает задачу с сохранённого состояния |
| Сессия | Футер из двух русских блоков: «Сессия» и «Среда». Ответ агента слева, сообщение пользователя справа. Щелчок по подписи открывает тот же оверлей, что и команда |
| Разделы команд | /groups и Ctrl+Alt+G раскладывают команды и готовые задания по темам: 1С, Cursor, MCP, настройки, агенты, знания, сессии и профиль. Команды Pi и навыки остаются своими разделами. Пустой раздел не показывается. Имена слэшей те же, подписи в списке русские |
Что умеет агент
Разобрать существующую конфигурацию
Можно дать агенту выгрузку и попросить:
- найти реализацию механизма;
- объяснить, откуда берётся значение;
- найти подписки, обработчики, регламентные задания и интеграции;
- проследить цепочку вызовов;
- сравнить основную конфигурацию и расширения;
- разобраться в чужой доработке;
- определить, какой объект реально нужно менять.
В ASK это делается без записи файлов.
Спланировать доработку до кода
В PLAN агент не должен сразу «накидать решение». Он исследует исходники, проектные знания и доступные MCP, после чего формирует план:
- что меняем;
- в каком контейнере;
- какие файлы и объекты затронем;
- какие есть риски и edge cases;
- как будем проверять результат.
Готовый PLAN можно продолжить в BUILD с тем же контекстом.
Реализовать изменение
В BUILD агент может менять исходники, создавать артефакты, вызывать инструменты проекта и передавать части задачи субагентам.
Правила проекта имеют приоритет над общими правилами агента. Если в проекте записано «новые объекты только в расширение X», это учитывается до записи кода.
Работать в мультиагентном режиме
В репозитории есть отдельные роли:
| Агент | Для чего |
|---|
| 1c-analytic | требования, сценарии, логика задачи |
| 1c-explorer | исследование проекта и существующей реализации |
| 1c-planner | план изменения |
| 1c-developer | реализация |
| 1c-tester | тестовый сценарий и проверка |
| 1c-code-reviewer | ревью кода |
| 1c-arch-reviewer | архитектурное ревью |
| 1c-architect | проектирование решения |
| 1c-error-fixer | локализация и исправление дефектов |
| 1c-performance-optimizer | производительность |
| 1c-metadata-manager | работа с метаданными |
| 1c-refactoring | рефакторинг |
| 1c-doc-writer | техническая документация |
Read-only роли можно запускать параллельно. Агенты, которые пишут в одно рабочее дерево, идут последовательно, чтобы не устроить гонку изменений.
В TUI субагент — один живой блок: таймер каждую секунду, лог дочерних tool call раскрывается. Дочерняя модель по умолчанию наследуется от родителя; короткое имя роли резолвится (explorer → 1c-explorer).
Работать с тестовой базой и релизными артефактами
Для типового цикла есть отдельные команды:
Если пользователь просит «собрать для переноса» или «собрать в прод», ожидается бинарный .cfe / .cf, а не просто XML-дерево исходников.
Использовать знания конкретного проекта
Агент не обязан каждый раз заново выяснять одно и то же.
В .pi/1c можно хранить проверенные знания:
- где лежат остатки;
- какое расширение считается целевым;
- какие объекты нельзя менять;
- какие интеграции есть в конфигурации;
- какие локальные правила приняты в команде.
Знание содержит scope, confidence и evidence. Черновик не становится активным сам — его нужно подтвердить.
Как проходит задача
flowchart LR
U["Задача пользователя"] --> A{"Режим"}
A -->|ASK| Q["Исследование<br/>без записи"]
A -->|PLAN| P["Исходники + MCP +<br/>знания проекта"]
A -->|BUILD| B["Реализация"]
P --> T["План:<br/>объекты · файлы · риски · проверка"]
T --> B
B --> S{"Нужны<br/>субагенты?"}
S -->|да| R["Explorer / Developer /<br/>Tester / Reviewer / Fixer"]
S -->|нет| C["Изменения"]
R --> C
C --> V["Проверки / тесты / сборка"]
V --> D["Готовый результат"]
Здесь нет схемы «попросил — модель сразу написала код». Исследование, планирование, запись и проверка разделены.
Продолжение работы при заполнении контекста
Длинная задача не обязана упираться в compaction или обрываться из-за заполненного context window.
В Pi можно включить автоматическую ротацию сессии:
По умолчанию функция выключена. Стандартный порог — 85% контекста; его можно изменить:
Когда порог достигнут, агент завершает текущий turn, формирует handoff с состоянием задачи и проверяет, что он действительно записан. После этого Pi открывает новую сессию, связанную с предыдущей, передаёт ей kickoff со ссылкой на handoff и продолжает работу уже в свежем контексте.
Схема выглядит так:
flowchart LR
A["Текущая сессия"] --> B{"Context ≥ threshold?"}
B -->|нет| A
B -->|да| C["Остановить новые tool calls"]
C --> D["Записать handoff"]
D --> E["Проверить handoff"]
E --> F["Открыть новую Pi-сессию"]
F --> G["Передать kickoff + handoff"]
G --> H["Продолжить ту же задачу"]
Для пользователя это выглядит как продолжение одного рабочего потока, но технически между сессиями есть граница: текущий turn аккуратно завершается, затем задача продолжается в новой сессии. Это Pi-only механизм; он не гарантируется в Cursor.
Если handoff не записался или новая сессия недоступна, ротация не делает вид, что всё прошло успешно: она останавливается и оставляет обычный compaction доступным.
Режимы работы
ASK
Режим по умолчанию для новой Pi-сессии. Подходит, когда нужно разобраться в коде, найти причину ошибки, изучить архитектуру или проверить гипотезу.
Запись файлов отключена.
PLAN
Подходит перед нетривиальной доработкой.
PLAN исследует проект и готовит planning-артефакты, но не меняет рабочий код. Готовый план содержит:
- Plan;
- ожидаемые файлы и объекты;
- риски и edge cases;
- способ проверки.
BUILD
Рабочий режим для реализации: изменение файлов, сборка, deploy, тесты и другие разрешённые действия.
Переключение ASK → PLAN → BUILD доступно командой или Ctrl+Alt+P.
Путь работы
/taskmode задаёт, как вести эту сессию. Это не /mode: ASK, PLAN и BUILD остаются на месте, syntaxcheck изменённого BSL и триггеры повышения до full-cycle тоже.
Пустой вызов открывает оверлей. Выбранный путь виден в футере.
| Путь | Что это |
|---|
| docs-fix | только текст: структура, ссылки, согласованность. Проверки BSL не запускаются |
| spec-authoring | требования и план. Факты 1С подтверждаются, код пишется позже |
| analytics | объяснить или сравнить. Исходники не меняются |
| quick-fix | одна локальная правка, короткий план и нужные проверки |
| full-cycle | требования, реализация, проверка результата и ревью |
| auto | снять метку. Дальше путь выбирается по задаче |
Сессия в терминале
Футер собран двумя группами.
«Сессия»: режим (Вопрос, Планирование, Реализация), путь, доступ, глубина, экономия, интерфейс, обучение.
«Среда»: проект, граф / код / ИБ, заполнение контекста, модель, число MCP, мышление, ротация, захват, открытые изменения OpenSpec, вид базы и ветка git. На узком терминале прячутся второстепенные подписи. Режим остаётся.
Чат идёт парами рамок: ответ агента слева, сообщение пользователя справа. Тихие чтения (read, grep, find, ls) и повторные блоки Thinking одного хода сворачиваются в одну строку, чтобы между пачками путей не открывался новый блок.
/groups и Ctrl+Alt+G раскладывают команды и готовые задания по темам: 1С, Cursor, MCP и интеграции, настройки, агенты, знания, сессии и память, профиль. Команды Pi и навыки остаются своими разделами. Пустой раздел не показывается. Выбор /mode, /learning, /init, /mcpconfig и других переключателей сразу открывает их оверлей. Остальные команды вставляются в строку ввода и сами не запускаются. Поиск предыдущего совпадения в транскрипте Pi остаётся на Ctrl+Shift+G.
Быстрый старт
Требования
- Node.js 22.19+
- Pi Coding Agent 1.1.x
- Windows, Linux или macOS
- Git
- для работы с ИБ — установленная платформа 1С и доступ к нужной базе
- MCP, Docker, память, Vanessa и browser-инструменты не обязательны и подключаются отдельно
1. Клонировать профиль
Linux / macOS:
git clone https://github.com/z03ps00/pi-1c-agent.git ~/pi-1c-agent
Windows PowerShell:
git clone https://github.com/z03ps00/pi-1c-agent.git "$HOME\pi-1c-agent"
Архив релиза pi-1c-agent-<version>-client.zip — тот же профиль без тестов, CI и истории git. Node и Pi ставятся отдельно. Распакуйте его и переходите к setup, подставив каталог распаковки вместо клона.
2. Выполнить setup
Переменную PI_CODING_AGENT_DIR задают только на время setup. Её нельзя записывать в ~/.bashrc, ~/.profile, ~/.zshrc и в пользовательские переменные среды Windows. Иначе каждый запуск pi станет агентом 1С, а прежний профиль Pi пропадёт.
Linux / macOS:
PI_CODING_AGENT_DIR="$HOME/pi-1c-agent" node "$HOME/pi-1c-agent/scripts/setup.mjs"
Windows:
$env:PI_CODING_AGENT_DIR = "$HOME\pi-1c-agent"
node "$env:PI_CODING_AGENT_DIR\scripts\setup.mjs"
Remove-Item Env:PI_CODING_AGENT_DIR
Setup прописывает пакет в settings.json этого клона и создаёт локальные auth.json / trust.json из примеров, если их ещё нет. Повторный запуск безопасен. Файл ~/.pi/agent и любой другой профиль Pi он не трогает.
3. Отдельный запуск, не профиль по умолчанию
Профиль 1С запускают своей командой. Обычная команда pi остаётся тем профилем, который был до установки.
Linux и macOS — ссылка в ~/.local/bin (каталог должен быть в PATH; на macOS при необходимости добавь его в ~/.zprofile одной строкой export PATH="$HOME/.local/bin:$PATH", без PI_CODING_AGENT_DIR):
chmod +x "$HOME/pi-1c-agent/scripts/pi-1c"
mkdir -p "$HOME/.local/bin"
ln -sfn "$HOME/pi-1c-agent/scripts/pi-1c" "$HOME/.local/bin/pi-1c"
Windows — scripts/pi-1c.cmd уже держит профиль только на свой запуск. Положи его в каталог из PATH, не в переменные среды пользователя:
$bin = "$env:LOCALAPPDATA\Programs\pi-1c"
New-Item -ItemType Directory -Force -Path $bin | Out-Null
Copy-Item "$env:USERPROFILE\pi-1c-agent\scripts\pi-1c.cmd" "$bin\pi-1c.cmd" -Force
$machinePath = [Environment]::GetEnvironmentVariable('Path', 'User')
if ($machinePath -notlike "*$bin*") {
[Environment]::SetEnvironmentVariable('Path', "$bin;$machinePath", 'User')
}
Дальше pi-1c из папки проекта 1С или pi-1c /путь/к/проекту. Если первый аргумент — существующий каталог, лаунчер открывает агента в нём и не передаёт этот путь в pi. Путь вида /…, ~/…, ./…, ../… или с буквой диска, которого нет, даёт ошибку. Флаги и текст (pi-1c -c) уходят в pi без смены каталога. Из той же папки pi открывает прежний профиль. Новый терминал Windows подхватит PATH после перезапуска.
4. Ярлык на рабочем столе
Ярлык открывает панель управления этого профиля (scripts/pi-1c-ctl / scripts/pi-1c-ctl.cmd): статус, новый чат, открыть проект по пути, сессии, модели, диагностика, backup settings.json, обновление Pi. В shell rc и в переменные среды пользователя PI_CODING_AGENT_DIR не пишется. Команда pi-1c по-прежнему запускает агента без панели.
Linux — шаблон scripts/Pi-1C-Agent.desktop.in, в Exec абсолютный путь к scripts/pi-1c-ctl, Terminal=true. Если есть каталог ярлыков агентов (~/Рабочий стол/Программы/AGENTS, ~/Desktop/Программы/AGENTS или тот же каталог на рабочем столе), положи Pi-1C-Agent.desktop туда. Иначе — на рабочий стол (xdg-user-dir DESKTOP) и копию в ~/.local/share/applications/.
ctl="$HOME/pi-1c-agent/scripts/pi-1c-ctl"
desktop_dir="${XDG_DESKTOP_DIR:-$(xdg-user-dir DESKTOP 2>/dev/null || true)}"
agents_dir=""
for candidate in "$HOME/Рабочий стол/Программы/AGENTS" "$HOME/Desktop/Программы/AGENTS" "$desktop_dir/Программы/AGENTS"; do
if [ -n "$candidate" ] && [ -d "$candidate" ]; then agents_dir="$candidate"; break; fi
done
chmod +x "$ctl"
sed "s|@PI_1C_CTL@|$ctl|" "$HOME/pi-1c-agent/scripts/Pi-1C-Agent.desktop.in" > /tmp/Pi-1C-Agent.desktop
chmod +x /tmp/Pi-1C-Agent.desktop
if [ -n "$agents_dir" ]; then
cp /tmp/Pi-1C-Agent.desktop "$agents_dir/Pi-1C-Agent.desktop"
else
desktop_dir="${desktop_dir:-$HOME/Desktop}"
mkdir -p "$desktop_dir" "$HOME/.local/share/applications"
cp /tmp/Pi-1C-Agent.desktop "$desktop_dir/Pi-1C-Agent.desktop"
cp /tmp/Pi-1C-Agent.desktop "$HOME/.local/share/applications/Pi-1C-Agent.desktop"
fi
macOS — файл Pi 1C Agent.command на рабочем столе. Двойной щелчок открывает Terminal и панель профиля 1С:
desktop="$(osascript -e 'POSIX path of (path to desktop folder)' | tr -d '\r')"
cat > "${desktop}Pi 1C Agent.command" <<EOF
#!/bin/bash
clear
exec "$HOME/pi-1c-agent/scripts/pi-1c-ctl"
EOF
chmod +x "$HOME/pi-1c-agent/scripts/pi-1c-ctl" "${desktop}Pi 1C Agent.command"
Windows — ярлык .lnk на рабочем столе. Цель — scripts\pi-1c-ctl.cmd:
$desktop = [Environment]::GetFolderPath('Desktop')
$target = "$env:USERPROFILE\pi-1c-agent\scripts\pi-1c-ctl.cmd"
$shell = New-Object -ComObject WScript.Shell
$link = $shell.CreateShortcut((Join-Path $desktop 'Pi 1C Agent.lnk'))
$link.TargetPath = $target
$link.WorkingDirectory = "$env:USERPROFILE\pi-1c-agent"
$link.WindowStyle = 1
$link.Description = 'Панель управления Pi 1C Agent'
$link.Save()
Если файл иконки уже есть (~/.local/share/icons/pi-1c-agent.svg на Linux и macOS), в .desktop можно добавить строку Icon= с этим путём. Без иконки ярлык всё равно запускается.
5. Проверить установку
6. Инициализировать 1С-проект
Мастер предложит:
- пустой каркас;
- выгрузку из существующей ИБ;
- импорт из .cf;
- импорт из .cfe;
- импорт из .dt.
После Apply в проекте остаются только данные проекта. Сам агент живёт отдельно в PI_CODING_AGENT_DIR.
Что создаётся в 1С-проекте
.pi/mcp.json появляется пустым, если файла ещё не было. Уже записанный файл /init не перезаписывает. Токены туда не кладут: одинаковое имя сервера в проекте перекрывает профиль.
Секреты остаются в .dev.env и локальных файлах авторизации. В knowledge, handoff и документацию их переносить нельзя.
Основные команды
Полный список — в prompts/CATALOG.md.
| Команда | Что делает |
|---|
| /commands | каталог команд |
| /init | инициализация проекта |
| /doctor | проверка профиля и runtime |
| /installtools | меню установки дополнительных MCP |
| /checkmcp | состояние MCP |
| /mode ask | вопросы и исследование без записи |
| /mode plan | исследование и план |
| /mode build | реализация |
| /taskmode | путь работы сессии: docs-fix, spec-authoring, analytics, quick-fix, full-cycle, auto |
| /loadfrom1cbase | выгрузить конфигурацию из ИБ в репозиторий |
| /update1cbase | загрузить репозиторий в указанную ИБ |
| /deploy-and-test | загрузить в тестовую ИБ и запустить проверки |
| /build-release | собрать .cf / .cfe из git-снимка |
| /learning | обучение: off, safe, auto. Пустой вызов открывает оверлей |
| /groups | разделы команд по темам. Клавиша Ctrl+Alt+G. Пустой раздел скрыт |
| /mcpconfig | локальный .pi/mcp.json или mcp.json профиля: добавить или убрать один сервер |
| /layout-view | HTML-схема Form.xml или Template.xml в .pi/previews |
| /reglog | последние строки журнала регистрации живой базы |
| /ext-plan | сухой план обновления поставщика через расширение, без записи файлов |
Пустой вызов /anon, /approve, /learning, /session-rotate, /capture-model, /sdlc, /litemode, /uitests, /previewmode, /caveman, /economymode, /rulesmodel и /mcpconfig открывает тот же оверлей, что /mode. Пустой /init — тот же оверлей: источник (empty | from-ib | from-cf | from-cfe | from-dt) и затем режим. /theme выбирает палитру TUI: standard (VS Code Dark+) и dracula. Футер подписан по-русски: режим, путь, обучение, MCP, мышление, ротация и остальные поля сессии и среды.
Инициализация проекта
/init — не просто генератор папок.
Сначала мастер открывает оверлей источника: пустой scaffold, существующая ИБ, .cf, .cfe или .dt. Рекомендуемый режим заполнения — стандартный: агент сам собирает платформу и общие настройки с соседних проектов, показывает список и ждёт «Всё верно». Подробный опрос всех переменных остаётся как /init advanced. В зависимости от сценария он может настроить:
- пути платформы;
- параметры ИБ;
- структуру src/ и build/;
- префикс и данные разработчика;
- Configuration Knowledge Layer;
- OpenSpec;
- Vanessa;
- КД 2 / КД 3;
- Humanizer RU.
Секретные значения остаются локально. Выбранные extras подключаются только после Apply.
Если проект уже существует и нужен только слой знаний:
Знания и правила проекта
Приоритет контекста такой:
Так знания по конкретной конфигурации не приходится запихивать в один огромный prompt.
Добавить знание
Сначала создаётся черновик. Активировать его можно отдельно:
Проанализировать конфигурацию
Агент исследует исходники и предлагает факты/правила с evidence.
Обновить знания после обновления конфигурации
Система сравнивает fingerprint исходников и предлагает:
- invalidate — что устарело;
- update — что нужно уточнить;
- add — что появилось нового.
Изменения вступают в силу только после ревью и /config apply.
MCP
MCP в профиле opt-in. Дефолтный mcp.json не поднимает сервисы автоматически.
Pi читает mcp.json профиля и .pi/mcp.json текущего проекта. Одинаковое имя сервера в проекте перекрывает профиль. /init и /init knowledge создают пустой .pi/mcp.json, если файла ещё нет, и оставляют существующий как есть.
/mcpconfig без аргумента выбирает локальный или глобальный файл, затем добавляет или убирает один сервер. После записи нужен /reload. Токены в .pi/mcp.json не хранят.
Отдельные установщики:
| Команда | Интеграция |
|---|
| /installmcp | основной 1С Docker MCP bundle |
| /install-memory-mcp | Cognee + OpenViking |
| /install-edt-mcp | EDT MCP |
| /install-agent-browser | browser для web-client сценариев |
| /install-windows-mcp | Windows desktop UI, когда без него никак |
| /install-vanessa-mcp | Vanessa Automation MCP |
Фрагменты конфигурации лежат в mcp.optional/.
Скиллы
В skills/ лежат процедуры под конкретные задачи. Среди них:
- 1c-mcp-toolkit — работа с 1С MCP Toolkit;
- 1c-metadata-manage — операции с метаданными;
- 1c-repository-manage — работа с хранилищем;
- mcp-1c-tools — общие MCP-инструменты 1С;
- v8unpack-cf — работа с .cf;
- vanessa-mcp — Vanessa Automation;
- kd2-rules и kd31-rules — КД 2 / КД 3;
- humanizer-ru — редактура русского текста;
- reglog — последние записи журнала регистрации живой базы;
- handoff и session-handoff — передача контекста;
- context-bootstrap, context-router, knowledge-retrieval — работа с контекстом;
- mermaid-diagrams — схемы;
- powershell-windows — Windows/PowerShell сценарии.
Скилл — закреплённая процедура с правилами, а не «магическая кнопка».
Humanizer RU
Humanizer RU нужен для русских инструкций, статей, писем, ТЗ и README, которые после генерации звучат слишком «нейросетево».
Он не пытается обмануть AI-detector. Его задача — убрать то, что мешает читать:
- пустые зачины;
- канцелярит;
- безличный пассив;
- маркетинговую накачку;
- обёртки чат-бота;
- стены текста.
Факты, 1С-термины и авторский голос сохраняются. Для текстов владельца проекта в репозитории есть отдельный voice profile.
OpenSpec
Если в проекте есть openspec/, агент может работать в spec-driven режиме:
Исследование и предложение относятся к PLAN, реализация — к BUILD.
Память
Память по умолчанию выключена.
Используются два бэкенда:
| Бэкенд | Для чего |
|---|
| Cognee | короткие факты, решения, предпочтения, уроки из ошибок |
| OpenViking | развёрнутые отчёты, процедуры, handoff и документация |
Перед записью данные проходят redaction секретов. Ход агента пишет файл в state/agent-memory/pending/ и запускает фоновый воркер, не дожидаясь Cognee и OpenViking. Воркер переживает закрытие сессии, вызывает MCP и переносит запись в done/ только после проверки recall. /memory-flush стартует воркер и сразу возвращает управление.
Анонимный режим
- 1 — не писать в память;
- 2 — не читать и не писать;
- 3 — дополнительно не создавать локальные handoff-трейсы.
Субагент получает тот же уровень /anon, что и родительская сессия.
Approval mode
- off — без дополнительных подтверждений;
- safe — подтверждать опасные BUILD-действия;
- strict — подтверждать каждый tool call.
Это Pi-only механизм. Cursor читает AGENTS.md как инструкции, но Pi-runtime gates там не работают так же, как в Pi.
Обучение
Пустой вызов открывает оверлей. Значение хранится в профиле. По умолчанию safe. В футере это строка «Обучение».
После законченного хода в BUILD Pi может разобрать повторяемую процедуру и записать локальный skill в state/evolution/learned/. В режиме safe такой skill ждёт /evolve approve. В режиме auto включается только procedure-skill без опасных инструментов. Факты, правила, workflows и уроки остаются черновиками. В Cursor этот разбор не запускается.
ACP
scripts/pi-1c-acp и scripts/pi-1c-acp.cmd поднимают этот профиль как процесс Agent Client Protocol v1. Сообщения идут JSON-RPC по stdin и stdout. Свой HTTP-порт процесс не открывает. Лаунчер выставляет PI_CODING_AGENT_DIR на клон профиля и стартует pi --mode rpc. Слэш-команды те же, что в TUI. Каталог проекта приходит в session/new. Один процесс держит одну сессию.
В OpenClaw встроенное имя pi запускает обычный Pi. Для этого профиля нужна отдельная запись с именем pi-1c. Пример и передача аргументов оверлея: packages/pi-1c-agent/docs/acp.md. Пустой оверлей в ACP отменяется сразу: в тексте задачи пишут /init from-cfe или /mode build.
Типовые сценарии
Разобраться, почему не работает код
Агент читает исходники, ищет связанные объекты и может обращаться к MCP, но проект не меняет.
Подготовить план доработки
На выходе — целевой контейнер, конкретные файлы/объекты, риски и проверка.
Реализовать задачу с ревью
Для большой задачи исследование, разработку, тестирование и ревью можно развести по отдельным субагентам.
Поднять проект из существующей базы
Выберите existing infobase, настройте доступ, проверьте preview и примените.
Собрать артефакт для переноса
Результат — .cf / .cfe, а не копия XML-исходников.
Безопасность
В профиле несколько независимых слоёв:
- новая сессия стартует в ASK;
- ASK не пишет файлы;
- PLAN не меняет рабочий код;
- перед изменением определяется целевой контейнер;
- проектные знания активируются только после отдельного approve;
- секреты не должны попадать в knowledge, handoff и память;
- память делает redaction перед записью;
- /approve safe|strict добавляет подтверждение действий;
- /anon отключает memory/traces для чувствительных задач.
Это не отменяет тестовую базу, резервные копии, Git и ревью перед Production.
Тесты и CI
Runtime-пакет находится в packages/pi-1c-agent/.
Локально:
cd packages/pi-1c-agent
npm run typecheck
npm test
npm run doctor:package
npm run scan:public
Стресс-набор:
npm run test:stress
GitHub Actions запускает основной набор на Ubuntu и Windows с Node.js 22.19, 22 и 24. Отдельный nightly workflow гоняет stress tests.
Что где лежит
| Путь | Содержимое |
|---|
| AGENTS.md | основные правила профиля |
| rules-1c/ | базовые и адаптированные правила 1С |
| rules-1c/core/ | modes, orchestration, handoff, knowledge, delivery, overlay-options, project init |
| agents/ | специализированные 1С-субагенты |
| skills/ | прикладные скиллы |
| prompts/ | команды и prompt-процедуры |
| prompts/CATALOG.md | полный каталог команд |
| packages/pi-1c-agent/ | Pi runtime-пакет |
| mcp.optional/ | opt-in MCP-конфигурации |
| scripts/ | setup, запуск pi-1c, панель pi-1c-ctl, ACP pi-1c-acp |
| state/agent-memory/ | очередь памяти: pending / processing / done / failed |
| openspec/ | ресурсы spec-driven workflow |
Обновление
Профиль:
Pi CLI:
Это разные операции. /updaterules относится к правилам внутри 1С-проекта и не заменяет обновление профиля.
После обновления:
Важные ограничения
- MCP-сервисы не считаются установленными только потому, что профиль умеет с ними работать.
- Cursor читает правила профиля, но runtime-защиты ASK/PLAN/APPROVE реализованы именно в Pi.
- Новое расширение не создаётся автоматически — нужен явный запрос.
- Память выключена по умолчанию.
- Агент не должен придумывать метаданные, если их можно проверить по исходникам или MCP.
- Production всё равно требует человеческого ревью и проверки на тестовой базе.
Документация
Лицензия и благодарности
Собственный код проекта распространяется по MIT.
Используются и адаптируются сторонние материалы:
Точные границы лицензирования перечислены в NOTICE.
Pi 1C Agent — Pi с контекстом и рабочими процессами реальной 1С-разработки.
z03ps00
