Библиотека задач по PHP | тесты, код, задания

🏃‍♀️ Мы собрали бесплатный мега-гайд по ии-агентам 👇 В первой части постов навалили жесткой базы, чтобы вправить мозги на место. Во второй дали конкретные инструменты, фреймворки и пошаговые инструкции, что нужно кодить прямо сейчас. Часть 1. Введение, юзкейсы и реальность Разбираемся с терминами, снимаем розовые очки и смотрим, где ИИ реально приносит бабки, а где только жжет нервы: 1. «Так что вообще считается AI-агентом?» 2. «Где тут бот, а где уже AI-агент?» 3. «Не надо пихать AI-агента в каждую задачу» 4. «Что уже можно спокойно делать через AI-агентов?» 5. «А что через AI-агентов пока лучше не трогать?» Часть 2. Изнанка, ошибки и архитектура Как всё это устроено под капотом, чтобы не слить бюджет и не наломать дров на старте: 6. «Можно ли просто сесть вечером и собрать себе AI-агента?» 7. «С чего вообще начать, если хочется попробовать AI-агентов» 8. «Почему AI-агент может внезапно начать творить дичь» 9. «Где AI-агенты реально экономят время, а где только добавляют возни» 10. «Почему они жрут столько денег?» Часть 3. Хардкорная практика (Что делать руками) Хватит теории. Открываем ноут, запускаем Cursor и делаем нормальные, отказоустойчивые системы: 11. «Почему одного промпта мало?» 12. «Почему AI-агенту мало просто “дать доступ к данным”» 13. «Если не следить за AI-агентом, он быстро начинает жить своей жизнью» 14. «Собрать демку легко. Но как же сделать нормально» 15. «Как сделать, чтобы это не развалилось через неделю?» 👍 Сохраняйте пост в избранное, чтобы не потерять. 🤫 А завтра стартует наш курс по ии-агентам

💬 Обратная связь Какие темы освещать чаще? 🔥 — PHP Core 👍🏼 — Laravel / Symfony ❤️ — Паттерны и дизайн 😁 — Предложу в комменты

❓ Что такое событийно-ориентированная архитектура? Event-driven architecture — это когда компоненты общаются через события, не зная друг о друге напрямую.

// Событие:
class UserRegistered {
    public function __construct(public readonly User $user) {}
}

// Listener:
class SendWelcomeEmail {
    public function handle(UserRegistered $event): void {
        $this->mailer->send($event->user->email, 'Welcome!');
    }
}

// Диспетчер:
$dispatcher->dispatch(new UserRegistered($user));

Зачем ✔️ Слабая связанность (UserService не знает о SendWelcomeEmail) ✔️ Легко добавить новый listener без изменения существующего кода (Open/Closed) ✔️ Можно делать асинхронные listeners (через очередь) В Laravel: Event / Listener, EventServiceProvider. В Symfony: EventDispatcher, декларация через атрибуты. Подводный камень: сложно трейсить цепочку — одно событие вызывает другое.

💬 Обратная связь Текущий уровень сложности задачек? 🔥 — Слишком просто, хочу сложнее 👍🏼 — В самый раз ❤️ — Иногда сложновато 😁 — Часто не понимаю

😱 Если ваш продукт не умеет отдавать данные в формате, понятном AI-агенту, то вас просто не существует Скрипт не будет кликать по красивым кнопкам в браузере, он уйдёт к конкуренту с нормальным API. Перестроить архитектуру под машинных клиентов — это уже не хайп, а необходимое условие сохранения конкурентоспособности. Как адаптировать продукт и не исчезнуть из выдачи: — интегрировать MCP и A2A-взаимодействие, чтобы агенты могли вас читать; — научиться контролировать стоимость (лимиты, кэш, роутинг между моделями); — настроить AgentOps: трейсинг, логирование и отлов регрессий. Всё это ждёт вас на обновлённом курсе «Разработка AI-агентов». Мы специально сделали фокус на утилитарном инжиниринге и production-ready решениях. Кстати, до 29 марта можно забрать курс с большой скидкой, и стоит поторопиться — мест на потоке всё меньше. Зафиксировать цену и начать деплоить агентов без слива бюджета 👈

❓ Чем отличается Optimistic Lock от Pessimistic Lock? Pessimistic Lock — блокируем строку в БД на время транзакции. Никто другой не может её изменить до снятия блокировки.

  SELECT * FROM orders WHERE id = 1 FOR UPDATE;

Применять когда: высокая вероятность конфликта, критичные финансовые операции, короткие транзакции. Минус: снижает throughput, риск дедлоков при блокировке нескольких строк в разном порядке. Optimistic Lock — блокировки нет. У записи есть поле version. При обновлении проверяем, что версия не изменилась:

  UPDATE orders SET status = 'paid', version = 6
  WHERE id = 1 AND version = 5;

Если affected_rows = 0 — кто-то успел раньше, делаем retry или возвращаем ошибку. Применять когда: конфликты редки, операции долгие (нельзя держать блокировку), высокий параллелизм. Минус: нужен retry-механизм, сложнее реализовать корректно.