li_at — це cookie, яку LinkedIn ставить у браузер після входу. Віддайте її, і ви підключите обліковий запис, жодного разу не набравши пароль, — а отже, і не зустрівши жодного з чекпоїнтів, які здатен підняти свіжий вхід.
Це і є причина її використати. Якщо обліковий запис раз по раз вимагає перевірку, на яку ви не можете відповісти, вставити cookie з браузера, що її вже пройшов, — це шлях наскрізь.
User agent не є необов'язковим
LinkedIn прив'язує сесію до браузера, який її створив. Надішліть cookie з іншим user agent, і сесія часто відвалюється — іноді одразу, іноді за годину, що гірше, бо виглядає як хистка інтеграція, а не як розбіжність. Скопіюйте user agent із того самого браузера, з якого скопіювали cookie.
Скільки вона живе
Cookie сесії не вічна. LinkedIn гасить її за власним розкладом, а вихід із браузера, звідки ви її скопіювали, може припинити її негайно. Коли вона зникає, обліковий запис перестає працювати, а статус знову каже, що потрібні облікові дані, — це перепідключення, а не збій.
Cookie — це жива сесія. Той, у кого вона є, і є обліковим записом: без пароля й без другого чинника на шляху. Поводьтеся з нею так само, як із паролем, і вийдіть із того браузера, коли закінчите.
Часті запитання
Чи варто вставляти li_at у проєктну кімнату, щоб ШІ-агент підключив обліковий запис?
Ні. Усе, що там написано, можуть прочитати всі в кімнаті, зокрема гості. Підключіть обліковий запис поза розмовою й дайте ШІ-агентові працювати з ним, коли він підключений.
Чи може асистент підключити обліковий запис через cookie?
Такий інструмент є, POST /linkedin/connect/cookie, тож асистент через MCP може це зробити, якщо передати йому cookie і user agent браузера. Особиста розмова з вашим власним асистентом — єдине місце, де це має сенс.