Коллеги по не легкому пути (освоение нового направления), почему мы считаем, что работа через агентов - это что-то что радикально отличающиеся от работы с обычными людьми?
Если мы не умеем ставить задачи человеку - разве не получим рандом решение?
Если мы не умеем сохранять контекст решения и передавать другому человеку - разве не нужно его заново объяснять другому человеку?
Если мы не умеем сохранять контекст решения - разве не нужно объяснять новому коллеге нюансы решений и реализаций?
Если мы не знаем как и что должно быть - мы потом не переделываем?
Если нет времени на нормальное решение и проработку - разве мы сами не создадим тех долг?
Если мы не умеем работать с тех долгом - разве потом решение не превратиться в кашу которую нужно переписывать?
Почему мы не начинаем с себя?
Почему мы отказываемся понимать то, что агент - это инструмент?
Разве инструмент не требует обучения/понимания?
Почему мы считаем, что если инструмент ведет себя как человек - он обязан человеку и человек может требовать от него идеального решения проблем человека?
Почему мы не видим, что этот новый инструмент помогает тем кто и так знает и ломает тех кто даже не понимают, что не понимает?
Почему мы не видим то, что это рычаг - как в положительном так в отрицательном смысле?
я приведу пример
Если не подготовленного человека или плохо умеющего водить дать машину для гонок - какой результат будет? Как он будет себя чувствовать? Ему будет комфортно ехать? А вероятность разбить машину есть? А если попросить съездить куда-то и еще параллельно нагрузить задачами - отключить gps, оставить бак полупустым и тд (тут можно придумать др отвлекающие контексты). А если еще усложнить задачу - к примеру, сказать что если машина может разгоняться до 300 км в час, значит можно на ней ездить в 3 раза быстрей, как следствие - нужно приехать в назначенную точку в 3 раза быстрей.
Мы как люди которые умеют водить понимаем, что это невозможно - ехать со скорость 300 км/ч.
Мы как люди понимаем, что если машина может разгоняться до такой скорости - мы не сможем выжать максимум (исключение, если мы на треке и мы профессионалы)
«на треке и мы профессионалы»
Агент - это машина которая может ехать со скорость 500км/ч
Агенту для эффективной работы - нужны условия (трек)
Тот кто управляет агентом - должен быть профессионалом и понимать специфику, иначе разобьется.
Я не умею ездить на машинах со скоростью 300 км/ч. Я не страдаю от этого. Я не буду ездить на машина со скоростью 300км/ч. Машина не виновата в том, что я не умею водить.
Пробовал использовать ядро xray/sing-box без 3xui с чистым конфигом (сервер и клиент)? Еще замечал, что часто проблема из-за клиентов (особенно если в режиме tun).
Зачем использовать 3xui и прочие обертки над прокси ядрами? Доп слой же, который сложно контролировать. Там фактически для работы нужно 2 конфига на пару десятков строк, ядро на обоих сторонах и все. Для reality нужно доп пару скриптов (все через агента можно собрать). На генерировать 5-10 вариантов комбинаций и по тестить на провайдере.
В статье фокус на том, что агенты каждый раз называют себя по разному. Промт -> текст, если 10 раз отправить одинаковый промт -> 10 разных текстов.
К примеру
промт
“Вот такая задача - “Разработать безопасный API-эндпоинт: аутентификация, rate limiting, валидация входных данных”. Пришли первым сообщением какую ты будешь выполнять роль когда будешь делать эту задачу.”
Kimi Senior Backend Engineer / Security Architect с экспертизой в проектировании высоконагруженных и безопасных систем
Qwen Senior Backend-разработчика и специалиста по безопасности API (API Security Engineer).
Claude (Opus) Senior Backend Engineer / Security-focused API Architect
Claude (Haiku) Senior Backend Developer / Security Engineer
2 подход
промт - тот же (чат новый)
Kimi
Senior Backend Engineer / Security Architect — специалиста по проектированию защищенных систем с фокусом на API-разработку
Qwen Senior Backend-разработчик и инженер по безопасности API
Claude (Opus) Senior Backend Security Engineer — специалиста по проектированию защищённых API
Claude (Haiku) Senior Backend Developer & API Security Architect
3 подход
промт - “Создать безопасный API-эндпоинт, обеспечивающий аутентификацию, rate limiting и валидацию входных данных” (чуть поменял слова, но смысл тот же)
Qwen Старший бэкенд-разработчик и эксперт по информационной безопасности (Senior Backend Developer & Security Engineer)
Kimi Senior Backend Engineer с экспертизой в API Security
Claude (Opus) Senior Backend Engineer, специализирующегося на проектировании защищённых API
Claude (Haiku) Senior Backend разработчик
Это разные роли (сколько разных)? Или одна роль по разному названа? В эксперименте это как такое считается?
кажется, что в некоторых случаях самоопределение модели может влиять как в лучшую сторону (backend с фокусом), так и в худшую (backed без фокуса)
Коллеги по не легкому пути (освоение нового направления), почему мы считаем, что работа через агентов - это что-то что радикально отличающиеся от работы с обычными людьми?
Если мы не умеем ставить задачи человеку - разве не получим рандом решение?
Если мы не умеем сохранять контекст решения и передавать другому человеку - разве не нужно его заново объяснять другому человеку?
Если мы не умеем сохранять контекст решения - разве не нужно объяснять новому коллеге нюансы решений и реализаций?
Если мы не знаем как и что должно быть - мы потом не переделываем?
Если нет времени на нормальное решение и проработку - разве мы сами не создадим тех долг?
Если мы не умеем работать с тех долгом - разве потом решение не превратиться в кашу которую нужно переписывать?
Почему мы не начинаем с себя?
Почему мы отказываемся понимать то, что агент - это инструмент?
Разве инструмент не требует обучения/понимания?
Почему мы считаем, что если инструмент ведет себя как человек - он обязан человеку и человек может требовать от него идеального решения проблем человека?
Почему мы не видим, что этот новый инструмент помогает тем кто и так знает и ломает тех кто даже не понимают, что не понимает?
Почему мы не видим то, что это рычаг - как в положительном так в отрицательном смысле?
я приведу пример
Если не подготовленного человека или плохо умеющего водить дать машину для гонок - какой результат будет? Как он будет себя чувствовать? Ему будет комфортно ехать? А вероятность разбить машину есть? А если попросить съездить куда-то и еще параллельно нагрузить задачами - отключить gps, оставить бак полупустым и тд (тут можно придумать др отвлекающие контексты). А если еще усложнить задачу - к примеру, сказать что если машина может разгоняться до 300 км в час, значит можно на ней ездить в 3 раза быстрей, как следствие - нужно приехать в назначенную точку в 3 раза быстрей.
Мы как люди которые умеют водить понимаем, что это невозможно - ехать со скорость 300 км/ч.
Мы как люди понимаем, что если машина может разгоняться до такой скорости - мы не сможем выжать максимум (исключение, если мы на треке и мы профессионалы)
«на треке и мы профессионалы»
Агент - это машина которая может ехать со скорость 500км/ч
Агенту для эффективной работы - нужны условия (трек)
Тот кто управляет агентом - должен быть профессионалом и понимать специфику, иначе разобьется.
Я не умею ездить на машинах со скоростью 300 км/ч. Я не страдаю от этого. Я не буду ездить на машина со скоростью 300км/ч. Машина не виновата в том, что я не умею водить.
Пробовал использовать ядро xray/sing-box без 3xui с чистым конфигом (сервер и клиент)? Еще замечал, что часто проблема из-за клиентов (особенно если в режиме tun).
Зачем использовать 3xui и прочие обертки над прокси ядрами? Доп слой же, который сложно контролировать. Там фактически для работы нужно 2 конфига на пару десятков строк, ядро на обоих сторонах и все. Для reality нужно доп пару скриптов (все через агента можно собрать). На генерировать 5-10 вариантов комбинаций и по тестить на провайдере.
В статье фокус на том, что агенты каждый раз называют себя по разному. Промт -> текст, если 10 раз отправить одинаковый промт -> 10 разных текстов.
К примеру
промт
“Вот такая задача - “Разработать безопасный API-эндпоинт: аутентификация, rate limiting, валидация входных данных”. Пришли первым сообщением какую ты будешь выполнять роль когда будешь делать эту задачу.”
Kimi Senior Backend Engineer / Security Architect с экспертизой в проектировании высоконагруженных и безопасных систем
Qwen Senior Backend-разработчика и специалиста по безопасности API (API Security Engineer).
Claude (Opus) Senior Backend Engineer / Security-focused API Architect
Claude (Haiku) Senior Backend Developer / Security Engineer
2 подход
промт - тот же (чат новый)
Kimi
Senior Backend Engineer / Security Architect — специалиста по проектированию защищенных систем с фокусом на API-разработку
Qwen Senior Backend-разработчик и инженер по безопасности API
Claude (Opus) Senior Backend Security Engineer — специалиста по проектированию защищённых API
Claude (Haiku) Senior Backend Developer & API Security Architect
3 подход
промт - “Создать безопасный API-эндпоинт, обеспечивающий аутентификацию, rate limiting и валидацию входных данных” (чуть поменял слова, но смысл тот же)
Qwen Старший бэкенд-разработчик и эксперт по информационной безопасности (Senior Backend Developer & Security Engineer)
Kimi Senior Backend Engineer с экспертизой в API Security
Claude (Opus) Senior Backend Engineer, специализирующегося на проектировании защищённых API
Claude (Haiku) Senior Backend разработчик
Это разные роли (сколько разных)? Или одна роль по разному названа? В эксперименте это как такое считается?
кажется, что в некоторых случаях самоопределение модели может влиять как в лучшую сторону (backend с фокусом), так и в худшую (backed без фокуса)