Где мне пригодился OpenClaw, а где обычный код оказался лучше. 3 истории из практики

[danilovmy]

даааа.... Если это не супер-слоп, то неужели это тот инжиниринг, который мы заслужили. Не этого я желал, ох не этого....

1. Каждое доставленное телеграмм сообщение имеет message_id. нет id - не доставлено. Есть id - доставлено. В openclaw это сделано по умолчанию. Агент точно знает доставлено сообщение или нет. Openclaw Telegram Brige работает надежно с 2026.3.23-3.24. Проблема недоставки непонятна. Даже в случае детерминированного кода.

2. Timeout отправки. В openclaw по умолчанию. Не может висеть отправка часами. Ну точнее может.... но тогда уж точно не по вине openclaw...

3. Слава богу у вас код не асинхронный. Поскольку иначе - у вас вычисляется длина объекта дважды и если длина объекта поменяется между вычислениями - получится "bigbadabum, lilu dallas miltipass".

4. К этому моменту накопилось 16 записей с неоднозначным результатом. Оставалось 4 заявки, по которым нужно было отдельно проверить доставку. Как восстанавливали состояние... берем и ручками проверяем эти 4! записи, это несколько минут и 0 токенов. Понимаю несколько сотен тысяч логов за пару минут... вот тут действительно сложновато ручками.

5. Говорить о том что mаnagers у вас константа, хотя должна быть переменной, в приведенном коде, вероятно, не стоит. Это либо фантазия, либо неудачный пример.

6. "Eсли просто повторять отправку после каждого timeout, можно получить дубли". Иногда, вы не поверите, дубль не так страшно, как кажется. Но спамить по таймауту без retry_count немного странно. Как и не сообщать об этом, ведь именно отсутствие фидбека было объявлено проблемой в начале статьи.

7. Про регэксп вы еще наедитесь. когда встретится текст в стиле "я получил ФЛАЭР1234567, что мне с ним делать". И это точно будет не название заказа.

В общем успехов, @RomanOpenclaw вам с агентами. Предположу, что основные проблемы вам доставит не они. И извините, если категоричен - иногда меня заносит.