10 posts tagged with "Agent Loop"

Pi 在不同尺度上各有名字：Session 是磁盘上的工作单元，Trace 是一次完整的 agent 循环，Turn 是其中一轮模型响应，Steer 和 Follow-up 是两个不同时机的消息注入口。

1. 三个时间尺度：Session（持久化）包含 Trace（agent_start→agent_end），Trace 包含 Turn（turn_start→turn_end）
2. Session：一个 JSONL 文件，跨多次 Trace 复用，Pi 的 Session 是什么？ 里讲过存储和分支
3. Trace：一次用户 prompt 触发的完整运行。模型自己开多轮 不会 拆出多条 Trace
4. Turn：一次 assistant 响应 + 它的 tool 批，是事件层最细的颗粒度
5. Steer：每个 Turn 开头都会去取一次，抢下一轮 LLM 调用的发言权
6. Follow-up：只有 Trace 想结束时才去取，本质是续命，不是打断
7. Queue Mode：one-at-a-time 一条一条发，all 攒齐一次性发
8. 实战取舍：边跑边改用 steer，结束后追问题用 follow-up

Pi 和 DeepSeek Harness（DSH）都允许大幅扩展 Agent 能力，但对不可替换核心的态度恰好相反。

1. 共同起点：模型负责思考，harness 负责管工具、上下文、会话、Agent Loop
2. Pi 思路：4 层骨架 + 30 个扩展事件，深层替换受宿主接口限制
3. DSH 思路：模型、工具、会话、默认 Loop 全是插件，底座只有 Cordis
4. 时空可组合性：Cordis 用注册反向操作做时间可组合，用依赖图做空间可组合
5. 自进化：DSH 创造模式让 Agent 自己写插件重组 Harness，可逆卸载是基础设施

两种 agent 表面都"循环",但决定"什么时候退出循环"的主体完全不同——这才是它们真正的分野。

1. 决策主体：ReAct 退出由 LLM 自己判断，Loop 退出由外部规则验证。
2. 适用场景：ReAct 适合查天气这类 3 步内 完成的轻量任务，Loop 适合老代码升级这类需要客观验证的工程任务。
3. 工程难点：Loop 每轮会清上下文重建 prompt，反馈机制与状态持久化是真正的门槛。
4. 真实案例：Claude Code 是 ReAct 框架 + Loop 思维的混合体——LLM 驱动主循环，但把判官能力下放给 Bash 工具的 exit code。
5. 思想定位：Loop Agent 不是新模型，是承认 LLM 会幻觉出错，结合软件工程验证与 AI 生成能力的务实架构。

Graph Engineering 是 Loop Engineering 之后冒出来的下一个 AI Agent 工程热词——70% 是新瓶装旧酒，30% 是真东西。

1. 真变化：单 Agent 自迭代（Loop）升级为多 Agent 协同 + 治理（Graph），前者解决收敛，后者解决分工
2. 关键术语：节点 + 边 + 状态，再叠加节点契约、调度、持久化、并发、恢复、权限、评估
3. 触发事件：Peter Steinberger 7 月 18 日"还搞 Loop？该 Graph 了"推文两天 200 万浏览
4. 三层架构：Harness（运行躯干）→ Loop（收敛循环）→ Graph（编排网络），90% 的 Agent 死在 1-2 层
5. 踩坑提醒：单 Agent 任务硬上多节点是过度设计，先把 Loop 跑稳
6. 判断标准：单 Agent 自我迭代无法收敛时加 Loop；多个 Loop 互相打架时再加 Graph

OpenAI 把 Codex 编排做成了语言无关的规范。

1. 三 大要素：SPEC.md（规范） + elixir/（参考实现） + WORKFLOW.md（仓内配置）
2. 定位升级：从「管 agent」升级到「管工单」
3. 主循环：拉 tracker → 建 per-issue workspace → 跑 Codex app-server
4. 边界：低密预览版，只跑受信环境，无内置沙箱
5. 设计巧思：host 侧注入 tracker 凭据，主动从 Codex 子进程剔除
6. License：Apache-2.0，可绕过 Elixir 按规范自实现

Agent 跑得慢，90% 的情况锅不在模型，在架构。架构选错，模型再强也是给一个漏水的桶灌水。

1. 性能瓶颈在哪：不是 token 慢，是 agent 闲着没事干还在转圈
2. 两种范式：Pull 模式（Loop 主动要任务）vs Push 模式（Event 主动叫 agent）
3. 传统 Loop 不是死循环：真正的 ReAct / Plan-Execute 是有终止的思考-行动-观察链
4. Event-driven 核心不是 push：是控制反转——agent 不用关心"什么时候该醒"
5. 适用边界：Loop 适合推理密集，Event-driven 适合 I/O 密集 + 异步多源
6. 反直觉：用错 Event-driven 反而更慢，因为它把"思考"也异步化了
7. 实战选择：高并发客服用 Event-driven，长链科研推理用 Loop

什么时候干什么活，比怎么干活更决定成本——这是架构选择的第一性原理。

Loop Engineering 不是写更好的 prompt，是把"下指令的人"从自己换成一套你设计好的系统。

• Boris Cherny（Claude Code 负责人）："我已经不 prompt Claude 了，我的工作是写 loops"
• 从 ReAct 到 Ralph Loop 到 Claude Code /goal，底层逻辑是从"手工"到"工业"的范式迁移
• 六大构件：自动化触发、工作区隔离、技能沉淀、MCP 连接器、子代理分离、外部状态持久
• 关键前提：任务高度重复，验证可自动化，团队有充足 Token 预算
• 适合 CI 故障排查、依赖更新等标准化流程；不适合架构重构等需要人类判断的决策

Loop 越顺畅，人越容易停止思考——验证偷懒和理解债比 token 账单更危险。

Agent 死循环不是极端情况，是给模型自由度必须付的代价。

• 直接原因：工具调用失败后盲重试——不换参数，反复撞同一堵墙。
• 深层原因：循环缺少收敛信号，Thought 和 Action 之间没有"该停了"的显式判断。

1. 第一层防御：max_steps 硬限制，两行代码兜住 80% 的翻车。
2. 第二层防御：把 Finish 做成一个 Action，循环有了天然终止条件。
3. 第三层防御：system prompt 里写死"重试失败就换策略"，主动避障。

• 工程底线：step_id + 全局超时 + 连续重复 Action 检测，别信 Agent 能自己收敛。
• 三层防御一起上，单靠任何一层都有盲区。

ReAct 是默认范式但不是唯一解——选错工作模式比选错模型更致命。

1. Function Calling：无推理链的直接工具调用，延迟最低，仅适合单步任务。
2. Plan-and-Execute：先规划全局再逐步执行，长任务完成率高 2-3 倍，但无法动态调整。
3. Reflection：生成 → 批评 → 修正循环，能自纠低级错误，代价是每轮多烧一倍 token。
4. Multi-Agent：多 Agent 分工或辩论，适合复杂任务，协调开销和成本是硬伤。
5. Routing：先分类再分发到专精模型，成本可控但分类错误会连锁翻车。

最佳实践：确定性任务→Plan-Execute，开放探索→ReAct，质量敏感→加 Reflection，规模大→Multi-Agent。

ReAct 不是"推理"和"行动"的简单拼接，是把两者编织成一条交替推进的链路：每一步推理都有观测反馈，每一步行动都有推理支撑。

• 定义：模型交替生成"思考"和"行动"，每次行动后把环境返回的观测结果注入下一步推理，形成闭环。
• 与 CoT 的核心差异：CoT 在推理链中"脑补"事实，ReAct 通过外部工具或环境把推理接地——幻觉会触发不符预期的观测，反过来暴露推理错误。
• 关键循环：Thought → Action → Observation → Thought，这个循环给 Agent 带来自我纠错能力——工具调错了？看返回就知道，下一步改。
• Action Space 设计：工具描述、参数 schema、返回格式，这三样写不好，ReAct 的效果直接打对折。
• 常见翻车：Agent 陷入重复 Action-Observation 死循环，没有收敛判断——需要加 max_steps 或让模型自己输出 Finish。
• 适用场景：需要多步信息检索、代码执行、API 调用的任务。简单的单轮问答用 ReAct 是过度设计。