20 行代码的循环，为什么是 LLM 时代的发动机？
LLM 本身是无状态的一次性函数，而真实任务是"边做边看"的过程。loop 是粘合这两者的唯一方式 —— 五个底层原因：
没有某一个人发明。这是一条多源汇流的演化线 —— 从机器人到认知科学，最后在 2022 年的 ReAct 论文定型。
从 Shakey 机器人到强化学习，"用循环解决序列决策"在 AI 界早已是常识。下一节会详细讲这段血脉。
最早让 LLM 在浏览器里循环执行动作，拉开 LLM agent 的序幕。
提出 LLM + 外部模块路由的范式，Karpas 等人给出概念框架。
第一次清晰提出 Thought → Action → Observation 交替循环。这被公认为现代 agent loop 的教科书形态。
LangChain（Harrison Chase）把 ReAct 变成人人可调；AutoGPT（Toran Richards）让大众第一次看到全自动 loop；BabyAGI（Yohei Nakajima）把 loop 拆成任务队列。
Anthropic 《Building Effective Agents》区分 workflow vs agent；Claude Code、Cursor、aider 把 loop 做成基础设施。loop 从论文走进生产。
今天的 agent loop 不是 2022 年凭空发明的。从 1960 年代的机器人到 1990 年代的强化学习，"感知→规划→行动"这个结构被反复验证过六次 —— ReAct 只是把它搬到了 LLM 上。理解这六条源流，才能看清 loop 的本质不是"循环调用"，而是带反馈的决策过程。
拿着摄像头在走廊里推箱子，第一次把"感知-建模-规划-执行"做成可运行系统。它用的 STRIPS 规划器（前置条件 + 动作 + 后置效果）至今仍是所有 AI 规划的语法基础。
Shakey 一次完整任务内部就是一个大 loop：拍照 → 更新世界模型 → 求解 STRIPS → 执行动作 → 再拍照。
perceive → model → plan → act → perceive ...把智能体拆成三个独立阶段：Sense（传感器读入）→ Plan（符号推理生成动作序列）→ Act（执行器输出）。每一轮结束后，新感知反哺模型，下一轮重新规划。
这是现代 agent loop 的直系祖先。ReAct 的 Thought/Action/Observation 本质上就是 Plan/Act/Sense 换了个马甲。
sense → plan → act → (loop)Brooks 的著名论文 "Intelligence Without Reason" 抨击 SPA 太慢太脆 —— 机器人还没想完，老鼠已经跑了。他提出反应式分层架构：多个感知-动作 loop 并行运行，底层反射快，高层规划慢，高层压制低层。
这对今天多 agent、subagent、并行 loop 的架构思想影响深远。
多个 sense→act loop 并行 · 分层压制图灵奖得主 Newell 的毕生心血：把所有认知活动统一为一个 decide cycle（决策周期）。每个 cycle 包含：阐述状态 → 提议算子 → 评估 → 选择 → 应用。目标栈遇到僵局就自动生成子目标 —— 这就是 subagent 的原型。
elaborate → propose → decide → apply → (impasse → subgoal)认知心理学建模的标杆。核心是产生式规则（IF pattern THEN action）不断匹配工作记忆并触发。每一次触发就是一轮 loop，触发结果更新工作记忆，引发下一轮匹配。
ACT-R 明确区分程序性记忆（规则）与陈述性记忆（事实）—— 这正是今天 agent 的"工具" vs "上下文"。
match → select → fire → update memory → (loop)《Reinforcement Learning: An Introduction》把 agent 抽象为数学对象：
每个 timestep t，agent 观察状态 sₜ，选择动作 aₜ，环境反馈奖励 rₜ₊₁ 和新状态 sₜ₊₁。目标是最大化累积奖励。
这是今天所有 agent loop 的数学骨架。当你把 LLM 的 "Thought/Action/Observation" 映射到 "policy/action/reward"，它们其实是同一个东西。
sₜ → π(aₜ|sₜ) → env → rₜ₊₁, sₜ₊₁ → (loop)每轮 loop 把 assistant turn + tool_result 追加进对话历史，再整个喂回模型。状态 = messages 数组，不是变量。
关键不是"窗口多大"，而是每一轮 loop 都会把上一轮的 tool_result 追加进来，context 单调递增。一次调用的成本 = 当前累积 token × 单价。所以 loop 跑得越深，单步越贵、模型越容易开始"遗忘目标"。
每点一次按钮 = loop 再转一轮：prompt + assistant + tool_result 追加到历史。看四种模型分别在第几轮撑爆。
"工具粒度决定 loop 长度" 想说的是：同一个任务能不能一步到位，完全取决于 harness 给 LLM 暴露了什么 API。工具太碎，LLM 要跑十几轮拼装；工具太粗，LLM 又容易失控。这是 harness 设计最重要的 API 决策，直接决定了成本、延迟、可靠性。
rm -rf /。粒度 = 效率 vs 安全的平衡点。这就是 Claude Code 为什么默认给细粒度工具 + 可选 bash。
主 loop 调子 loop，是隔离 context 污染、实现并行的关键模式。Claude Code 的 Agent tool 就是这么做的。
必须亲手观察过这些病症，才算真正懂 loop。
不是所有任务都适合 loop。Anthropic 的建议：能用预编排 workflow 解决的，不要动 agent。
两者都用 LLM，但控制权归属完全不同。选错模式 = 要么束手束脚、要么失控烧钱。
"只读不动"学不会 agent loop。每一步都给了要读的材料、要动手做的事、验收产出。按顺序走，每步产出叠加到下一步，到 Step 6 你手里就有一个能跑 SWE-bench 的完整 agent。
arxiv 2210.03629（重点 §3-4）~60 行的 ReAct loopcalculator、search（mock 数据即可）react_loop.py，能看到 Thought/Action/Observation 交替modelcontextprotocol.ioaider 或 sweep 任一开源 harness，本地跑通arxiv 2310.08560arxiv 2303.11366arxiv 2305.10601arxiv 2305.16291arxiv 2310.06770 + SWE-bench VerifiedSWE-bench-Lite（~300 题），Docker 里跑通评测流水线
真正的学问在 loop 周围的四个约束：
① context（能塞多少）·
② tools（能做什么）·
③ planning（怎么决定下一步）·
④ safety（做错了谁兜底）
这四条任何一条松掉，loop 就变成玩具。