7 posts tagged with "Agent Loop"

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 是过度设计。