我在网上看到有些人可以把 token 用的非常多，比如说跑几百个 agent 做这种类似 one-person company。 我感觉我现在虽然也用 Claude，但我还不是这种状态，我基本还是 single thread，或者 at most 也就 3 个 thread 这样子
提问
几百个 agent 不是靠人同时盯几百条线程，而是把大部分任务交给自动化流程，人只看关键节点和结果。
“几百个 agent”背后是自动化，不是注意力扩容
材料里的观点梁津晶描述自己的 400 多个任务时，说其中可能 200 多个已经是自动化在跑，像 SOP 一样由类似 manager thread 的东西定时执行；她举的 release agent 每小时跑一次，自己搜集 Linear、Slack 里的 bug 信息、做决定，需要问人时发 Slack 消息1。立正把这种模式概括为：人几乎不参与中间过程，只看第一步和最后一步交出来的东西是否合理1。所以“用很多 token”和“同时开很多线程”不是一回事，前者更接近把重复流程写成可自动运行的脚本。
任务一多，瓶颈从写代码转到找状态
材料里的观点梁津晶说，只有两个文档时列表就够用，到上千个就要靠搜索；她们的搜索会抓 agent session 标题、worktree 名称、相关 Linear ticket 的关键词，让人快速跳回几天前在做什么、进展如何1。她还提到 Claude Code 能改终端标题，但展示不了完整的 agent 状态，比如在跑、需要关注2。这说明规模上去后，真正花力气的是状态可见性和检索，而不是多开几个窗口。
从单线程到多线程，可以先换工作方式再谈数量
AI推演立正在另一场分享里说，要用好 AI 应停止只用聊天模式，改用 Cursor、Claude Code、Codex 这类 agent 工具；他用蒸汽机换电机的例子说明，只把旧流程里的一个环节换成 AI，上下游仍是瓶颈，围绕 AI 重构整个流程才可能带来数量级提升3。另一位讲者引述 Karpathy 的说法：多数人只和 AI 聊天，只有少数人用 agentic 工具，因而清楚 AI 的上限4。对你现在的单线程或三条线程，可检验的做法是挑一件重复性高、步骤固定的任务，先写成一段可复用的流程交给 agent 跑，观察它在哪里需要你介入；这比直接追求线程数更能暴露真实瓶颈。这是 AI 基于上述材料的应用建议。
材料只来自嘉宾对 Orca 用户和自身工作方式的描述，没有给出从单线程过渡到多 agent 的具体步骤或效果数据；你的工作类型是否适合这种自动化也未提供。
回到4份原文
梁津晶说明 400 多个任务中大量由自动化流程运行，以及人只看首尾的协作方式。
说明 agent 数量增多后状态展示和检索成为实际难点。
立正解释聊天式使用与 agent 式使用的区别，以及重构流程而非单点替换的理由。
提供聊天工具与 agentic 工具使用分化的背景说法。