Building Effective AI Agents

Over the past year, we've worked with dozens of teams building large language model (LLM) agents across industries. Consistently, the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns.

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

In this post, we share what we’ve learned from working with our customers and building agents ourselves, and give practical advice for developers on building effective agents.

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

What are agents?

Что такое агенты?

"Agent" can be defined in several ways. Some customers define agents as fully autonomous systems that operate independently over extended periods, using various tools to accomplish complex tasks. Others use the term to describe more prescriptive implementations that follow predefined workflows. At Anthropic, we categorize all these variations as agentic systems, but draw an important architectural distinction between workflows and agents:

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

Workflow — это системы, в которых LLM и инструменты оркестрируются через заранее заданные пути в коде.Агенты, напротив, — это системы, в которых LLM динамически направляют собственные процессы и использование инструментов, сохраняя контроль над тем, как они решают задачи.

Below, we will explore both types of agentic systems in detail. In Appendix 1 (“Agents in Practice”), we describe two domains where customers have found particular value in using these kinds of systems.

Ниже мы подробно рассмотрим оба типа агентных систем. В Приложении 1 («Агенты на практике») мы описываем две области, где клиенты нашли особую пользу в применении таких систем.

When (and when not) to use agents

Когда (и когда не) стоит использовать агентов

When building applications with LLMs, we recommend finding the simplest solution possible, and only increasing complexity when needed. This might mean not building agentic systems at all. Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense.

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

When more complexity is warranted, workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale. For many applications, however, optimizing single LLM calls with retrieval and in-context examples is usually enough.

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

When and how to use frameworks

Когда и как использовать фреймворки

There are many frameworks that make agentic systems easier to implement, including:

Существует множество фреймворков, упрощающих реализацию агентных систем, среди них:

Claude Agent SDK; Strands Agents SDK от AWS;Rivet — графический конструктор workflow для LLM с интерфейсом drag-and-drop; и Vellum — ещё один графический инструмент для создания и тестирования сложных workflow.

These frameworks make it easy to get started by simplifying standard low-level tasks like calling LLMs, defining and parsing tools, and chaining calls together. However, they often create extra layers of abstraction that can obscure the underlying prompts ​​and responses, making them harder to debug. They can also make it tempting to add complexity when a simpler setup would suffice.

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

We suggest that developers start by using LLM APIs directly: many patterns can be implemented in a few lines of code. If you do use a framework, ensure you understand the underlying code. Incorrect assumptions about what's under the hood are a common source of customer error.

Мы советуем разработчикам начинать с прямого использования API LLM: многие паттерны реализуются буквально в несколько строк кода. Если же вы используете фреймворк, убедитесь, что понимаете лежащий в его основе код. Неверные предположения о том, что происходит «под капотом», — частый источник ошибок у клиентов.

See our cookbook for some sample implementations.

Несколько примеров реализаций смотрите в нашем cookbook.

Building blocks, workflows, and agents

Строительные блоки, workflow и агенты

In this section, we’ll explore the common patterns for agentic systems we’ve seen in production. We'll start with our foundational building block—the augmented LLM—and progressively increase complexity, from simple compositional workflows to autonomous agents.

В этом разделе мы разберём распространённые паттерны агентных систем, которые мы видели в продакшене. Начнём с нашего базового строительного блока — расширенного LLM — и будем постепенно наращивать сложность: от простых композиционных workflow до автономных агентов.

Building block: The augmented LLM

Строительный блок: расширенный LLM

The basic building block of agentic systems is an LLM enhanced with augmentations such as retrieval, tools, and memory. Our current models can actively use these capabilities—generating their own search queries, selecting appropriate tools, and determining what information to retain.

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

We recommend focusing on two key aspects of the implementation: tailoring these capabilities to your specific use case and ensuring they provide an easy, well-documented interface for your LLM. While there are many ways to implement these augmentations, one approach is through our recently released Model Context Protocol, which allows developers to integrate with a growing ecosystem of third-party tools with a simple client implementation.

Мы рекомендуем сосредоточиться на двух ключевых аспектах реализации: адаптации этих возможностей под ваш конкретный сценарий использования и обеспечении простого, хорошо документированного интерфейса для вашего LLM. Хотя реализовать эти расширения можно множеством способов, один из подходов — через недавно выпущенный нами Model Context Protocol, который позволяет разработчикам интегрироваться с растущей экосистемой сторонних инструментов с помощью простой реализации клиента.

For the remainder of this post, we'll assume each LLM call has access to these augmented capabilities.

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

Workflow: Prompt chaining

Workflow: цепочка промптов (prompt chaining)

Prompt chaining decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one. You can add programmatic checks (see "gate” in the diagram below) on any intermediate steps to ensure that the process is still on track.

Цепочка промптов разбивает задачу на последовательность шагов, где каждый вызов LLM обрабатывает результат предыдущего. На любом промежуточном шаге можно добавить программные проверки (см. «gate» на схеме ниже), чтобы убедиться, что процесс идёт как надо.

When to use this workflow: This workflow is ideal for situations where the task can be easily and cleanly decomposed into fixed subtasks. The main goal is to trade off latency for higher accuracy, by making each LLM call an easier task.

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

Examples where prompt chaining is useful:

Примеры, где полезна цепочка промптов:

Создание маркетингового текста с последующим переводом его на другой язык.Написание плана документа, проверка того, что план соответствует определённым критериям, и затем написание документа на основе этого плана.

Workflow: Routing

Workflow: маршрутизация (routing)

Routing classifies an input and directs it to a specialized followup task. This workflow allows for separation of concerns, and building more specialized prompts. Without this workflow, optimizing for one kind of input can hurt performance on other inputs.

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

When to use this workflow: Routing works well for complex tasks where there are distinct categories that are better handled separately, and where classification can be handled accurately, either by an LLM or a more traditional classification model/algorithm.

Когда использовать этот workflow: Маршрутизация хорошо работает для сложных задач, где есть отдельные категории, которые лучше обрабатывать по-разному, и где классификацию можно выполнить точно — либо силами LLM, либо более традиционной классификационной моделью/алгоритмом.

Examples where routing is useful:

Примеры, где полезна маршрутизация:

Направление разных типов обращений в службу поддержки (общие вопросы, запросы на возврат средств, техническая поддержка) в разные последующие процессы, промпты и инструменты.Направление простых/частых вопросов к меньшим, экономичным моделям вроде Claude Haiku 4.5, а сложных/нетипичных — к более мощным, вроде Claude Sonnet 4.5, чтобы добиться наилучшего качества.

Workflow: Parallelization

Workflow: параллелизация (parallelization)

LLMs can sometimes work simultaneously on a task and have their outputs aggregated programmatically. This workflow, parallelization, manifests in two key variations:

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

Секционирование (sectioning): разбиение задачи на независимые подзадачи, выполняемые параллельно.Голосование (voting): многократный запуск одной и той же задачи для получения разнообразных результатов.

When to use this workflow: Parallelization is effective when the divided subtasks can be parallelized for speed, or when multiple perspectives or attempts are needed for higher confidence results. For complex tasks with multiple considerations, LLMs generally perform better when each consideration is handled by a separate LLM call, allowing focused attention on each specific aspect.

Когда использовать этот workflow: Параллелизация эффективна, когда разбитые подзадачи можно распараллелить для ускорения, или когда для получения более надёжных результатов нужны несколько точек зрения или попыток. Для сложных задач со множеством аспектов LLM, как правило, работают лучше, когда каждый аспект обрабатывается отдельным вызовом LLM, что позволяет сфокусироваться на конкретной стороне задачи.

Examples where parallelization is useful:

Примеры, где полезна параллелизация:

Секционирование:Реализация защитных ограничений (guardrails), когда один экземпляр модели обрабатывает запросы пользователя, а другой проверяет их на неприемлемый контент или запросы. Это обычно работает лучше, чем когда один и тот же вызов LLM отвечает и за защитные ограничения, и за основной ответ.Автоматизация оценок (evals) для измерения качества работы LLM, когда каждый вызов LLM оценивает отдельный аспект работы модели на заданном промпте.Голосование:Проверка фрагмента кода на уязвимости, когда несколько разных промптов просматривают код и помечают его, если находят проблему.Оценка того, является ли некий контент неприемлемым, когда несколько промптов оценивают разные аспекты или требуют разных порогов голосования, чтобы сбалансировать ложноположительные и ложноотрицательные срабатывания.

Workflow: Orchestrator-workers

Workflow: оркестратор-исполнители (orchestrator-workers)

In the orchestrator-workers workflow, a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results.

В workflow «оркестратор-исполнители» центральный LLM динамически разбивает задачи, делегирует их LLM-исполнителям и синтезирует их результаты.

When to use this workflow: This workflow is well-suited for complex tasks where you can’t predict the subtasks needed (in coding, for example, the number of files that need to be changed and the nature of the change in each file likely depend on the task). Whereas it’s topographically similar, the key difference from parallelization is its flexibility—subtasks aren't pre-defined, but determined by the orchestrator based on the specific input.

Когда использовать этот workflow: Этот workflow хорошо подходит для сложных задач, в которых нельзя заранее предсказать необходимые подзадачи (например, в программировании количество файлов, которые нужно изменить, и характер изменений в каждом из них, скорее всего, зависят от конкретной задачи). Хотя топологически он похож на параллелизацию, ключевое отличие — в его гибкости: подзадачи не заданы заранее, а определяются оркестратором на основе конкретного входа.

Example where orchestrator-workers is useful:

Пример, где полезен оркестратор-исполнители:

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

Workflow: Evaluator-optimizer

Workflow: оценщик-оптимизатор (evaluator-optimizer)

In the evaluator-optimizer workflow, one LLM call generates a response while another provides evaluation and feedback in a loop.

В workflow «оценщик-оптимизатор» один вызов LLM генерирует ответ, а другой в цикле даёт оценку и обратную связь.

When to use this workflow: This workflow is particularly effective when we have clear evaluation criteria, and when iterative refinement provides measurable value. The two signs of good fit are, first, that LLM responses can be demonstrably improved when a human articulates their feedback; and second, that the LLM can provide such feedback. This is analogous to the iterative writing process a human writer might go through when producing a polished document.

Когда использовать этот workflow: Этот workflow особенно эффективен, когда у нас есть чёткие критерии оценки и когда итеративная доработка приносит измеримую пользу. Два признака хорошей применимости таковы: во-первых, ответы LLM заметно улучшаются, когда человек формулирует свою обратную связь; во-вторых, LLM способен сам давать такую обратную связь. Это похоже на итеративный процесс письма, через который проходит человек-автор, доводя документ до готового вида.

Examples where evaluator-optimizer is useful:

Примеры, где полезен оценщик-оптимизатор:

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

Agents

Агенты

Agents are emerging in production as LLMs mature in key capabilities—understanding complex inputs, engaging in reasoning and planning, using tools reliably, and recovering from errors. Agents begin their work with either a command from, or interactive discussion with, the human user. Once the task is clear, agents plan and operate independently, potentially returning to the human for further information or judgement. During execution, it's crucial for the agents to gain “ground truth” from the environment at each step (such as tool call results or code execution) to assess its progress. Agents can then pause for human feedback at checkpoints or when encountering blockers. The task often terminates upon completion, but it’s also common to include stopping conditions (such as a maximum number of iterations) to maintain control.

Агенты появляются в продакшене по мере того, как LLM взрослеют в ключевых способностях — понимании сложных входных данных, рассуждении и планировании, надёжном использовании инструментов и восстановлении после ошибок. Агенты начинают работу либо с команды от пользователя, либо с интерактивного обсуждения с ним. Как только задача ясна, агенты планируют и действуют самостоятельно, при необходимости возвращаясь к человеку за дополнительной информацией или решением. В ходе выполнения агентам крайне важно на каждом шаге получать «ground truth» из среды (например, результаты вызова инструментов или выполнения кода), чтобы оценивать свой прогресс. Затем агенты могут приостанавливаться для обратной связи от человека на контрольных точках или при столкновении с препятствиями. Задача часто завершается по её выполнении, но также принято включать условия остановки (например, максимальное число итераций), чтобы сохранять контроль.

Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop. It is therefore crucial to design toolsets and their documentation clearly and thoughtfully. We expand on best practices for tool development in Appendix 2 ("Prompt Engineering your Tools").

Агенты способны решать сложные задачи, но их реализация зачастую проста. Как правило, это всего лишь LLM, использующие инструменты в цикле на основе обратной связи от среды. Поэтому крайне важно продуманно и ясно проектировать наборы инструментов и их документацию. Подробнее о лучших практиках разработки инструментов мы пишем в Приложении 2 («Prompt-инжиниринг ваших инструментов»).

When to use agents: Agents can be used for open-ended problems where it’s difficult or impossible to predict the required number of steps, and where you can’t hardcode a fixed path. The LLM will potentially operate for many turns, and you must have some level of trust in its decision-making. Agents' autonomy makes them ideal for scaling tasks in trusted environments.

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

The autonomous nature of agents means higher costs, and the potential for compounding errors. We recommend extensive testing in sandboxed environments, along with the appropriate guardrails.

Автономный характер агентов означает более высокие затраты и потенциальное накопление ошибок. Мы рекомендуем тщательное тестирование в изолированных (sandbox) средах вместе с соответствующими защитными ограничениями.

Examples where agents are useful:

Примеры, где полезны агенты:

The following examples are from our own implementations:

Следующие примеры взяты из наших собственных реализаций:

Кодинг-агент для решения задач SWE-bench, которые требуют правок во множестве файлов на основе описания задачи;Наша эталонная реализация «computer use», где Claude использует компьютер для выполнения задач.

Combining and customizing these patterns

Комбинирование и настройка этих паттернов

These building blocks aren't prescriptive. They're common patterns that developers can shape and combine to fit different use cases. The key to success, as with any LLM features, is measuring performance and iterating on implementations. To repeat: you should consider adding complexity only when it demonstrably improves outcomes.

Эти строительные блоки не являются предписаниями. Это распространённые паттерны, которые разработчики могут изменять и комбинировать под разные сценарии использования. Ключ к успеху, как и с любыми функциями на основе LLM, — измерять качество и итеративно дорабатывать реализации. Повторим: добавлять сложность стоит только тогда, когда это доказуемо улучшает результаты.

Summary

Итоги

Success in the LLM space isn't about building the most sophisticated system. It's about building the right system for your needs. Start with simple prompts, optimize them with comprehensive evaluation, and add multi-step agentic systems only when simpler solutions fall short.

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

When implementing agents, we try to follow three core principles:

Реализуя агентов, мы стараемся следовать трём базовым принципам:

Сохраняйте простоту в дизайне вашего агента.Отдавайте приоритет прозрачности, явно показывая шаги планирования агента.Тщательно прорабатывайте интерфейс «агент-компьютер» (ACI) через подробную документацию и тестирование инструментов.

Frameworks can help you get started quickly, but don't hesitate to reduce abstraction layers and build with basic components as you move to production. By following these principles, you can create agents that are not only powerful but also reliable, maintainable, and trusted by their users.

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

Acknowledgements

Благодарности

Written by Erik S. and Barry Zhang. This work draws upon our experiences building agents at Anthropic and the valuable insights shared by our customers, for which we're deeply grateful.

Авторы — Erik S. и Barry Zhang. Эта работа опирается на наш опыт создания агентов в Anthropic и на ценные наблюдения, которыми поделились наши клиенты, за что мы им глубоко признательны.

Appendix 1: Agents in practice

Приложение 1: агенты на практике

Our work with customers has revealed two particularly promising applications for AI agents that demonstrate the practical value of the patterns discussed above. Both applications illustrate how agents add the most value for tasks that require both conversation and action, have clear success criteria, enable feedback loops, and integrate meaningful human oversight.

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

A. Customer support

A. Поддержка клиентов

Customer support combines familiar chatbot interfaces with enhanced capabilities through tool integration. This is a natural fit for more open-ended agents because:

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

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

Several companies have demonstrated the viability of this approach through usage-based pricing models that charge only for successful resolutions, showing confidence in their agents' effectiveness.

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

B. Coding agents

B. Кодинг-агенты

The software development space has shown remarkable potential for LLM features, with capabilities evolving from code completion to autonomous problem-solving. Agents are particularly effective because:

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

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

In our own implementation, agents can now solve real GitHub issues in the SWE-bench Verified benchmark based on the pull request description alone. However, whereas automated testing helps verify functionality, human review remains crucial for ensuring solutions align with broader system requirements.

В нашей собственной реализации агенты теперь могут решать реальные GitHub-issue из бенчмарка SWE-bench Verified, опираясь только на описание pull request. Однако, хотя автоматическое тестирование помогает проверить функциональность, человеческая проверка остаётся критически важной для того, чтобы решения соответствовали более широким требованиям системы.

Appendix 2: Prompt engineering your tools

Приложение 2: prompt-инжиниринг ваших инструментов

No matter which agentic system you're building, tools will likely be an important part of your agent. Tools enable Claude to interact with external services and APIs by specifying their exact structure and definition in our API. When Claude responds, it will include a tool use block in the API response if it plans to invoke a tool. Tool definitions and specifications should be given just as much prompt engineering attention as your overall prompts. In this brief appendix, we describe how to prompt engineer your tools.

Какую бы агентную систему вы ни строили, инструменты, скорее всего, станут важной частью вашего агента. Инструменты позволяют Claude взаимодействовать с внешними сервисами и API, задавая их точную структуру и определение в нашем API. Когда Claude отвечает, он включает в ответ API блок использования инструмента (tool use block), если планирует вызвать инструмент. Определениям и спецификациям инструментов следует уделять не меньше внимания при prompt-инжиниринге, чем вашим основным промптам. В этом коротком приложении мы описываем, как заниматься prompt-инжинирингом ваших инструментов.

There are often several ways to specify the same action. For instance, you can specify a file edit by writing a diff, or by rewriting the entire file. For structured output, you can return code inside markdown or inside JSON. In software engineering, differences like these are cosmetic and can be converted losslessly from one to the other. However, some formats are much more difficult for an LLM to write than others. Writing a diff requires knowing how many lines are changing in the chunk header before the new code is written. Writing code inside JSON (compared to markdown) requires extra escaping of newlines and quotes.

Зачастую одно и то же действие можно задать несколькими способами. Например, правку файла можно описать, написав diff или переписав файл целиком. Для структурированного вывода можно вернуть код внутри markdown или внутри JSON. В разработке ПО подобные различия косметичны и без потерь конвертируются одно в другое. Однако некоторые форматы модели гораздо труднее писать, чем другие. Написание diff требует знания того, сколько строк меняется в блоке, ещё до того, как написан новый код (в заголовке чанка). Написание кода внутри JSON (по сравнению с markdown) требует дополнительного экранирования переносов строк и кавычек.

Our suggestions for deciding on tool formats are the following:

Наши рекомендации по выбору форматов инструментов таковы:

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

One rule of thumb is to think about how much effort goes into human-computer interfaces (HCI), and plan to invest just as much effort in creating good agent-computer interfaces (ACI). Here are some thoughts on how to do so:

Одно эмпирическое правило — подумать о том, сколько усилий вкладывается в интерфейсы «человек-компьютер» (HCI), и запланировать столько же усилий на создание хороших интерфейсов «агент»-компьютер (ACI). Вот несколько мыслей о том, как это сделать:

Поставьте себя на место модели. Очевидно ли, как пользоваться этим инструментом, исходя из описания и параметров, или над этим пришлось бы серьёзно подумать? Если да, то, вероятно, это верно и для модели. Хорошее определение инструмента часто включает пример использования, граничные случаи, требования к формату входных данных и чёткие границы по отношению к другим инструментам.Как можно изменить имена или описания параметров, чтобы сделать вещи более очевидными? Думайте об этом как о написании отличного docstring для младшего разработчика в вашей команде. Это особенно важно при использовании множества похожих инструментов.Тестируйте, как модель использует ваши инструменты: прогоните множество примеров входных данных в нашем workbench, чтобы увидеть, какие ошибки делает модель, и дорабатывайте.Применяйте к инструментам принцип poka-yoke (защита от ошибок). Меняйте аргументы так, чтобы ошибиться было труднее.

While building our agent for SWE-bench, we actually spent more time optimizing our tools than the overall prompt. For example, we found that the model would make mistakes with tools using relative filepaths after the agent had moved out of the root directory. To fix this, we changed the tool to always require absolute filepaths—and we found that the model used this method flawlessly.

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