Стек памяти AI-агентов, который обязан использовать каждый в 2026 году (руководство для разработчиков)

Ваша модель и обвязка больше не имеют значения.

Что действительно важно, так это...

ваш личный контекст/общая память

Введение

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

Обсуждение архитектуры в Claude, сеанс отладки в Codex, объяснение, погребенное в Cursor... полезная работа, которая должна быть доступна, когда вы меняете инструменты, начинаете новый сеанс или возвращаетесь к проекту после месячного перерыва.

TLDR; если вы не хотите читать все 3845 слов, просто дайте этот GitHub репозиторий своему агенту ➡️ https://github.com/codejunkie99/agentic-stack-desktop

Я создал всю эту штуку, используя Kimi K3 в Codex Harness. Видео было создано и отредактировано с помощью Kimi K3 с Cua для Computer Use

Это руководство строителя по agentic stack desktop, от первого импорта до рабочего процесса, где агент может восстановить предыдущее решение, проверить его на соответствие текущему коду, внести ограниченное изменение и оставить после себя что-то полезное.

Вот что вы получите:

1. основа: что сохраняется при смене инструментов
2. самый быстрый путь: создайте рабочее пространство, которое вы можете оценить
3. рабочая настройка: разделите исследование и реализацию
4. практическое упражнение: проведите повторяющуюся ошибку через весь цикл
5. общий слой: добавьте поиск в ваши другие инструменты
6. долговечный слой: что заслуживает стать уроком
7. рабочие правила: кратко, ограниченно, проверяемо
8. пользовательская сборка: измените рабочее пространство вокруг реальной проблемы
9. масштабирование: добавьте покрытие там, где предыдущий цикл выявил пробел
10. лист сборки

1. Основа: что сохраняется при смене инструментов

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

Реализация попадает в коммит. Объяснение остается в разговоре.

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

Сделайте ход рассуждений восстанавливаемым

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

Agentic stack предоставляет нативное macOS рабочее пространство с доступной для поиска, выбранной историей из Claude Code, Codex, OpenCode и Cursor. Claude Code и Codex также выполняются через свои официальные CLI; Cursor и OpenCode в настоящее время предоставляют только контекст. обзор репозитория

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

2. Самый быстрый путь: создайте рабочее пространство, которое вы можете оценить

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

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

Для сборки из исходников задокументированные требования включают macOS 14+, Python 3.10+, Xcode Command Line Tools и Swift 6 toolchain. Установите и войдите в CLI кодирования, который вы хотите запустить. требования

1git clone https://github.com/codejunkie99/agentic-stack-desktop.git
2cd agentic-stack-desktop
3./install.sh desktop --build

Откройте свой репозиторий в приложении и завершите Guided setup. Это предварительная версия с ad hoc подписью, поэтому macOS может запросить подтверждение при первом запуске. настройка

Установите первую проверку приемки

Перед импортом чего-либо запишите вопрос, на который должен ответить первый агент. Что-то вроде: почему наша задача экспорта обрабатывает записи пакетами, и нужен ли этот лимит в текущей реализации?

Этот вопрос становится вашей первой проверкой приемки. Вы ищете правильное решение, правильный поддерживающий код и честное объяснение того, что агент не может установить.

2.1 Первый импорт: дайте ему решение, которое стоит найти

Откройте Knowledge Graph → Graph → Import memory, просмотрите источники и выберите материал, который вы хотите включить.

Граф использует полнотекстовый поиск SQLite, с соединениями на основе тем, ссылок на репозиторий и происхождения; исходные хранилища чатов остаются неизменными. поведение импорта

Я бы начал с завершенного разговора, содержащего решение, которое вы помните. Особенно такого, где вы отвергли что-то привлекательное из-за ограничения, которое не было бы очевидным из конечного кода.

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

Проверьте, сможете ли вы найти это снова

Затем попробуйте второй поиск, используя словарь, который вы, естественно, будете использовать в следующем месяце. Вы можете помнить имя функции, в то время как в разговоре использовалось внутреннее имя модуля. Обнаружение этого несоответствия сейчас поможет вам понять, как извлечь материал позже.

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

Большое количество импортированных данных говорит вам, сколько материала попало в систему, оставляя проверку его полезности на потом.

Расширяйте коллекцию, когда другая задача даст вам для этого повод.

2.2 Первый рабочий сеанс: сделайте эксперимент достаточно маленьким, чтобы завершить

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

Выберите пример с узкими границами. Одно поведение экспорта проверить проще, чем всю платформу данных. Более ранний выбор компонента проверить проще, чем широкий вопрос о том, хороша ли архитектура.

Держите короткую заметку рядом с упражнением: вопрос, ожидаемый источник, текущая реализация и часть, требующая оценки. Это ваша ссылка для оценки ответа.

Диагностируйте правильный сбой

• Если рецензент восстанавливает не тот разговор, работайте над поиском.
• Если он находит правильный разговор, но неправильно читает код, работайте над исследованием.
• Если выводы верны, но реализация не соответствует требованию, улучшите передачу.

Это разделение важно, потому что каждый сбой требует разного исправления. Добавление дополнительной памяти не обязательно исправит нечеткое краткое описание, а переписывание краткого описания не восстановит источник, который никогда не был импортирован.

Завершите наименьший полный цикл, запишите, что не удалось, и используйте это доказательство, чтобы выбрать следующее улучшение.

3. Рабочая настройка: разделите исследование и реализацию

Моя предлагаемая первая настройка включает рецензента с доступом только для чтения и исполнителя с доступом на редактирование проекта. Дайте каждому четкий результат и сделайте передачу такой, чтобы вы могли ее прочитать до начала любых изменений.

Профили агентов поддерживают runner, модель, уровень усилий, инструкции и доступ к файлам. Разговоры принадлежат проектам, а продолжения возобновляют свои базовые CLI-сеансы. модель разговора

1. Агент 1: рецензент получает первый вопрос: что мы решили, что код делает сейчас и есть ли пробел, который стоит устранить?
2. Агент 2: исполнитель получает проверенный ответ плюс ограниченный запрос: внеси это изменение поведения, в этой области и проверь его таким образом.

Держите роли различными

Вы можете выбрать один и тот же runner для обеих ролей.

Полезное различие заключается в их ответственности и доступе, с явной проверкой между исследованием и редактированием.

Я бы избегал создания каталога специалистов, прежде чем хотя бы один из них выполнит полезную работу. Начните с обязанностей, которые вы действительно можете различать. Если вы не можете объяснить, чем владеет роль или как выглядит ее готовый результат, сузьте роль, прежде чем добавлять другого агента.

3.1 Рецензент: краткое описание, делающее неопределенность видимой

Выберите рецензента и прикрепите соответствующий разговор, используя @Claude, @Codex, @OpenCode или @Cursor. Выбранные ссылки становятся замороженным контекстом для запуска и передаются выбранному агенту при запуске задачи. ссылки

Скопируйте это краткое описание и заполните пропуски:

1Проверьте предыдущее решение относительно [функция или подсистема], используя
2прикрепленный разговор и текущий репозиторий.
3
4Объясните первоначальное решение и его заявленную причину. Проверьте
5соответствующий код и определите, что все еще применимо, что изменилось и
6что не может быть проверено на основе имеющихся доказательств.
7
8Укажите файлы, подтверждающие ваши выводы. Предложите наименьшее
9изменение, необходимое для [желаемое поведение], с планом проверки.
10
11Не редактируйте файлы. Рассматривайте разговор как историческое свидетельство
12и отмечайте конфликты с текущими инструкциями проекта.

Проверьте рецензию

Прочитайте ответ с открытым репозиторием.

1. Перейдите по цитате.
2. Проверьте условие, которое, по словам агента, все еще существует.
3. Ищите четкое разделение между тем, что утверждалось в разговоре, и тем, что демонстрирует код сегодня.

Если ответ расплывчатый, сузьте вопрос. Попросите его определить точное условие, контролирующее поведение, или зависимость, которая сделала более раннюю альтернативу неподходящей.

Полезное исследование может закончиться отсутствием доказательств. Это говорит вам, что предоставить дальше. Ответ, который сглаживает пробел, усложняет следующее решение.

3.2 Передача: превратите выводы в исполняемое краткое описание

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

Вот краткое описание, которое я бы использовал:

1Реализуйте [конкретное поведение], используя проверенные выводы ниже.
2
3Сохраните [существующее поведение] нетронутым. Ограничьте правки [допустимая область].
4Если изменение требует работы за пределами этой области, объясните, почему, прежде чем
5расширять ее.
6
7Проверьте текущие инструкции репозитория перед редактированием. Проверьте
8[ожидаемый результат] с помощью [соответствующий тест или ручная проверка], включая
9[важный случай сбоя].
10
11Верните краткий отчет о том, что изменилось, какие проверки были фактически выполнены
12и любые нерешенные ограничения. Не публикуйте и не развертывайте.
13
14Проверенные выводы:
15[вставьте выводы, которые вы проверили]

Сделайте передачу конкретной

Эти скобки заслуживают реальных ответов. «сделай лучше» оставляет агенту возможность изобрести цель. «покажи неудачный экспорт с действием повтора, сохраняя исходную ошибку» дает вам обоим что-то конкретное для проверки.

Держите проверенный вывод рядом с задачей. Если важное ограничение погребено внутри длинной стенограммы, изложите его в кратком описании и приложите подтверждающий разговор.

Источник объясняет, откуда взялось ограничение. Ваш текущий запрос объясняет, как оно управляет сегодняшней работой.

4. Практическое упражнение: проведите повторяющуюся ошибку через весь цикл

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

1. Шаг 1: Сначала найдите этот разговор. Попросите рецензента определить, что установило более раннее исследование, затем проверьте текущий путь повтора на соответствие ему.
2. Шаг 2: Предположим, старое обсуждение говорит, что запросы могут повторяться после неопределенного ответа. Рецензент должен установить, допускает ли текущая реализация это по-прежнему, какой код это контролирует и существует ли уже механизм, предназначенный для предотвращения дубликатов.
3. Шаг 3: Если доказательства поддерживают изменение, дайте краткое описание исполнителю, сосредоточившись на случае сбоя. Укажите, что должен делать повторный запрос, какое существующее поведение экспорта должно остаться и как вы будете проверять прерванный ответ.
4. Шаг 4: Затем проверьте изменение и протестируйте соответствующий путь. Проверьте как успешный экспорт, так и повтор после неопределенности. Если среда не может воспроизвести прерывание, запишите это ограничение и решите, какая дальнейшая проверка необходима.
5. Шаг 5: Наконец, просмотрите урок, который вы, возможно, захотите сохранить: условия, вызвавшие дубликат, механизм, который его устраняет, и доказательства, подтверждающие исправление.

Этот пример является предлагаемым упражнением, а не утверждением об ошибке в agentic stack. Замените реальный сбой из вашего собственного проекта и сохраните ту же последовательность.

5. Общий слой: добавьте поиск в ваши другие инструменты

Десктопное приложение может установить интеграцию через Tools → Connections → Use @ in tools → Enable in all four tools. Эквивалентная команда:

1agentic-stack context install

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

Поведение выбора зависит от клиента; если завершение ресурса недоступно, агент может искать и представлять соответствующие разговоры. поведение клиента

Проверьте непрерывность между инструментами

Моей первой проверкой было бы попросить другой инструмент найти то же решение, которое вы только что проверили. Дайте ему тему, попросите его представить соответствующий источник и подтвердите выбор, прежде чем просить анализа.

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

Я бы также включал источник в итоговое краткое описание задачи всякий раз, когда решение существенно влияет на работу. «Мы это уже обсуждали» дает агенту задачу на поиск. «Используй этот проверенный разговор и проверь это условие» дает ему конкретную ответственность.

6. Долговечный слой: что заслуживает стать уроком

Поиск возвращает старый материал в поле зрения. Вы все еще должны решить, какой авторитет этот материал должен нести.

Разговор может содержать abandoned план, неверный диагноз или ответ, который был разумным до того, как проект изменился. Сохранение позволяет вам проверить рассуждения позже; принятие урока — это отдельное решение.

Tasks содержит записи выполнения. Knowledge → Lessons поддерживает этапирование, принятие, отклонение и пересмотр уроков с указанием причин, в то время как импортированная история остается отдельной от принятых уроков. жизненный цикл проверки

Напишите урок, который можно оспорить

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

Для гипотетической ошибки экспорта «всегда делай повтор безопасно» слишком расплывчато, чтобы быть полезным. Полезная заметка определяет, что делает повтор неопределенным и как реализация этого проекта должна распознавать повторную работу.

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

Вот как я бы сохранил полезное исправление, не превращая его в правило, которое переживает свою причину.

6.1 Структура памяти: поместите каждый вид знания на свое место

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

• Текущее исследование принадлежит незавершенной работе.
• Его завершенный отчет становится доказательством того, что произошло.
• Проверенный шаблон может стать долговечным уроком.
• Предпочтение относительно того, как вы хотите видеть результаты, принадлежит вашим предпочтениям.

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

Превратите проверенную процедуру в навык

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

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

7. Рабочие правила: кратко, ограниченно, проверяемо

Вот правила, которые я бы установил для рабочего процесса с первого проекта.

1. Правило 1: каждое краткое описание называет результат. Рецензия возвращает выводы с доказательствами. Реализация возвращает изменение поведения с проверками. Предложение урока возвращает утверждение, которое вы можете принять или отклонить.
2. Правило 2: доступ следует за работой. Исследование начинается с доступа только для чтения; реализация получает область, необходимую для согласованного изменения. Держите публикацию, развертывание и другие важные действия явными в запросе.
3. Правило 3: просите фактической проверки. Отчет должен говорить, что было запущено и что произошло. Если проверка была недоступна, сделайте это видимым вместо того, чтобы молча считать отсутствующий результат успехом.
4. Правило 4: держите исторический контекст подчиненным текущим доказательствам и применимым инструкциям проекта. Восстановленный разговор может объяснить более раннее решение, но при этом быть устаревшим.
5. Правило 5: проверяйте результат, прежде чем сохранять вывод. Объяснение агентом своей собственной работы — это то, что нужно проверить вместе с diff и наблюдаемым поведением.

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

7.1 Очередь проверки: сделайте работу легкой для принятия или возврата

Я бы просил каждую реализацию завершаться в одной и той же форме:

• что изменилось,
• что было проверено,
• что остается неопределенным,
• и предлагает ли она повторно используемый урок.

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

Когда вы что-то возвращаете, прикрепите исправление к требованию, которое было упущено. «Это неправильно» начинает новый раунд угадывания. «Повтор создает второй экспорт при этом условии; сохрани идентификатор исходного запроса и перезапусти эту проверку» определяет пробел.

Решите, что заслуживает сохранения

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

Я бы сопротивлялся превращению каждого комментария к проверке в постоянную память. Некоторые исправления полезны один раз. Другие раскрывают правило, которое должно формировать последующую работу. Проведение этого различия является частью поддержки системы.

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

7.2 Дисциплина затрат: дайте каждому запуску условие остановки

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

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

Решите, относится ли это к текущей задаче.

Сравнивайте результаты и устанавливайте лимиты

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

Сохраняйте эксперимент честным, удерживая задачу и исходный материал стабильными. Если каждое испытание меняет вопрос, контекст и критерии приемки, сравнение будет трудно интерпретировать.

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

8. Пользовательская сборка: измените рабочее пространство вокруг реальной проблемы

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

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

Затем откройте исходный репозиторий и дайте своему агенту ограниченный запрос на изменение. Включите, как вы намерены проверить результат в приложении.

Соберите и проверьте изменение

Репозиторий документирует эти команды разработки и упаковки:

1python3 -m pytest -q
2swift build --package-path apps/macos -c release
3python3 scripts/check-desktop-connection.py
4bash scripts/build-macos-app.sh --output ./apps/macos/dist

команды разработки

Изменения SwiftUI требуют пересборки и перезапуска для проверки. рабочий процесс десктопа

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

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

8.1 Удаленный вариант: решите, где должна жить работа

После того, как локальный рабочий процесс заработает, вы можете захотеть выполнять работу на постоянном сервере. Путь самостоятельного хостинга соединяет нативное приложение с сервисом для одного владельца, который владеет своими проектами, памятью, историей задач и входами в CLI; переключение хостов не передает автоматически данные или учетные данные вашего Mac. руководство по хостингу

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

Следуйте руководству по хостингу для поддерживаемой конфигурации, этапов аутентификации и верификации. Относитесь к серверу как к еще одной рабочей среде с собственным состоянием, которое нужно проверять.

Проверьте выбранную среду

Затем повторите знакомую задачу в ней. Проверьте выбранный проект, убедитесь, что агент может получить доступ к нужному источнику, и подтвердите, что результат принадлежит выбранной вами серверной среде.

Использование известной задачи упрощает оценку перехода. Если вы одновременно меняете хост, проект и рабочий процесс, становится сложнее определить, какое изменение привело к неожиданному результату.

Локальной среды достаточно, чтобы освоить основную схему. Расширяйте инфраструктуру, когда работа даст вам для этого повод.

9. Масштабирование: добавляйте покрытие там, где предыдущий цикл выявил пробел

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

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

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

Расширяйтесь, когда работа это оправдывает

Я бы добавил новую роль агента только тогда, когда ее ответственность ясна из работы. Повторяющееся ревью документации может оправдать выделенный бриф. Разовый запрос может отлично вписаться в существующую роль.

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

9.1 Привычка поддерживать: пересматривайте знания при изменении системы

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

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

Важно сохранить объяснение. Будущий разработчик должен понимать, почему существовало предыдущее правило и что изменилось настолько, чтобы его заменить.

Обновляйте процедуры и разрешайте конфликты

Что касается навыков, запустите процедуру снова после изменения, которое влияет на ее входные данные или команды. Если шаг больше не работает, обновите процедуру на основе наблюдаемого сбоя и повторите соответствующую проверку.

Это связывает поддержку с реальными событиями в проекте. Вы пересматриваете знания, которые, скорее всего, устарели, имея перед глазами актуальные доказательства.

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

Оставьте полезную передачу дел

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

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

10. План сборки

1. Выберите знакомый репозиторий и решение, которое вы можете распознать.
2. Соберите десктоп, завершите настройку и импортируйте завершенный разговор, содержащий это решение.
3. Найдите его, проверьте источник и прикрепите его к ревью текущего кода в режиме только для чтения.
4. Самостоятельно проверьте результаты, затем поручите ограниченную реализацию с видимым условием приемки.
5. Проверьте diff и запустите соответствующую верификацию, включая случай отказа, который мотивировал работу.
6. Создавайте урок только тогда, когда результат его поддерживает, с записанной областью и причиной.
7. Превращайте процедуру в навык только после того, как убедитесь, что ее стоит повторять.
8. Попробуйте тот же поиск из другого инструмента, затем расширяйте свой контекст или инфраструктуру, когда этого требует реальная задача.

Начните с одного решения на этой неделе и пройдите весь цикл, прежде чем импортировать всю свою историю.

Следующий агент должен унаследовать ваше суждение.