LinkedIn 不公布上限，而且上限本来也不是一个数字：它随账号、随账龄、随动作、随过去两周过得怎么样而变。你查不到它，所以设计必须在不知道它的前提下成立。
把 429 当信息，不要当失败
429 是你能拿到的唯一一个直接信号。它一来就退 — 指数地退，并设一个上限 — 而且计数要按账号，而不是按进程。顶着 429 硬撞，是唯一一种可靠地把情况弄得更糟的行为：等待会被拉长。
队列按账号，不按任务
一个全局的工作池会把负载摊到你的整套基础设施上，同时又把它堆到那个碰巧最忙的账号上。每个已连接账号一条队列，各有各的节奏，代码确实更多，却是唯一撑得住的形状。它也让按账号计费这件事变得好读：你按什么排队，就按什么付钱。
让工作可以被打断
任何没法在半路暂停的东西，早晚会在半路被杀掉。把进度存下来，让每一步都幂等，再让这件事能接着跑。这和让 webhook 重投变得无害的，是同一个性质，而且这并非巧合 — 它们本来就是同一个问题。
量一量到底有多少到了 LinkedIn
把被接下的请求和看得见的结果分开数。当这两者岔开时，你就学到了关于这个上限的、别的办法看不到的东西，而且是在客户告诉你之前学到的。
常见问题
AI 智能体该怎样处理 429？
停下来，说明情况，把重试留到以后。把它写进指令里：收到 429 之后，不要在同一条回复里重试。房间设置里的工具步骤上限，是给忘了这条的 AI 智能体准备的第二道防线。
项目房间会按账号给 LinkedIn 调用排队吗？
不会。房间限制的是 AI 回复，而不是 LinkedIn 调用。如果许多智能体对同一个账号操作，上文描述的按账号排队，仍然要由你自己来建。