一张图看懂 Harness / Loop / Graph
@alexxubyte 一图建立直觉，@N01ennn 长篇综述拆开三层定义，并附两个大规模实证研究。
开篇：一图建立直觉
@alexxubyte 用一张图讲清了 Harness 工程的全部直觉：LLM 能推理并生成文本，但仅凭此不可靠；可靠性通常来自包裹在 LLM 外层的那一层框架——用户向工具发查询，上下文构建器随即处理，然后是推理、政策门、工具执行、验证，一环扣一环。
评论区把这张图打磨得更精确：
- @thechajo 追问"LLM 难道不应该在框架之外吗"——作者回应：LLM 运行在 harness 内部，但不属于 harness 的一部分；可视化上应标记为"可替换"并用虚线边框；
- @erelof1：第一步（状态逻辑）是 90% 配置悄悄失败的地方；若状态逻辑静态，其余工具链只会让你高置信地执行错误操作；
- @getduraton：多数失败在约束（constraints）和验证（verification）步骤——agent 尝试危险操作时没什么能拦住，等你检查结果时已经做完了；
- @petarivanovv9 的精炼定义：harness 是 agent 周围构建的环境、护栏、权限模型和反馈循环；框架给的是编排，harness 定义 agent 能碰什么、不能碰什么、失败如何在扩大前被捕获。
LLM 像一位天才但冒失的实习生：点子多、手也快。harness 就是给他配的工位、门禁、操作手册和质检员——实习生还是那个实习生，但出错会被拦下，做完有人验收。
三层辨析：harness 让模型运行，loop 让执行可迭代，graph 让控制流可检查
以下来自 @N01ennn 的长篇综述。记忆口诀只有一句：
公式：Agent = Loop(LLM + Harness)。harness 决定能力的可用性，loop 决定如何持续交互与适应——二者合在一起，产生个体智能（Individual Intelligence）。
三层像盖楼：harness 是地基和脚手架（决定楼能盖多高），loop 是施工队每天"砌墙→验收→返工"的循环（决定楼持续往上盖），graph 是施工总平面图（决定哪队先砌哪面墙、哪两队可并行、哪面墙要监理签字）。
Loop 工程小史：40 天从命名到"被宣告死亡"
@N01ennn 考证了 loop engineering 这个词的出生证明：
- 2026 年 6 月第一周被创造：6/2 Boris Cherny 访谈"我不再写提示词，我写循环"；6/7 Peter Steinberger 发文获 800 万+ 浏览；同日 Addy Osmani 正式命名 loop engineering；
- 技术早于名称：2025 年 7 月 Geoffrey Huntley 的 Ralph Wiggum 循环就已经在跑：
while :; do cat PROMPT.md | claude-code ; done- 厂商吸收：Claude Code 2026-03 上线
/loop；Codex 4 月推出 goal 对象（机器可检查的完成条件）；harness 5 月跟进/goal； - Osmani 的循环分类：turn-based / goal-based / time-based / proactive，后来又区分自主性 × 编排两维度——"验证成本决定委派上限"。
实证一：36,710 个仓库扫描——loop 的真实存活率
理论之外，@N01ennn 引用了一项大规模扫描：36,710 个工程仓库，找运行中的自主 agent loop。
- 确认 217 个运行中的自主 agent loop，仅占 0.59%，其中 189 个是 Claude Code；
- 形态：180 个仅由仓库事件触发（多为 PR review）、21 个仅定时（多为 issue triage）、15 个两者兼有；
- 社区共识处方（提交状态文件、verifier 子代理、预算声明、机器可检查的停止条件）在 36,645 个扫描仓库中几乎全军覆没：0 个 verifier subagent、0 个 budget 文件、0 个 stop condition；
- 结论：配置被提交了，运行时状态没有被提交。
还有一个黑色幽默：AI-Hypercomputer / xpk 的每小时 Gemini triage，曾记录 6,290 次成功运行、零 agent 执行——"成功的运行，是事情发生的弱证据。"
你的 loop 有 verifier 子代理吗？有预算声明吗？有机器可检查的停止条件吗？三项全无的话，它可能只是个定时器。
实证二：IAL-Scan——无限循环是怎么烧掉钱的
第二项研究 IAL-Scan 扫描了 6,549 个 LLM agent 仓库、246,748 个 Python 文件，确认 47 个项目、68 个无限智能体循环（IAL）故障，检测准确率 91.9%。
根因分布：
- 缺强边界：100%；
- 工具控制重试：41.2%；
- 模型控制终止：38.2%；
- 缺出口：33.8%；
- 状态增长放大器：27.9%。
影响：95.6% 烧光 API 成本、95.6% 造成模型拒绝服务、27.9% 耗尽上下文窗口。
值得注意：LangGraph（23）+ AutoGen（22）占了 45 个——因为反馈是经 API 编码的，而不是写在可见的循环语法里，躲过了代码评审。各框架的 loop 控制参数（LangChain 的 max_iterations、OpenAI Agents SDK 的 max_turns、LangGraph 的 recursion_limit、CrewAI 的 max_iter）都存在，但常常覆盖不了真正的反馈路径。
可见的出口像消防通道的牌子，边界像真的能上锁、断电、停水的总闸。牌子挂了不等于火来时打得开门——上限必须覆盖真正的反馈路径，否则只是心理安慰。
GPT-6 Astra 与 five rules
@N01ennn 把 GPT-6 Astra 放在图工程的位置上讲：Astra 的四个特性直接对应图的工程需求——
- async tool calling（
async:true）：长工具运行时继续推理、调其他工具，按 call_id 取回结果——对应超步内的并行分支； - 中途转向：工作期间可发额外用户指令，Responses API 保留已完成工作融入更新，无需重启节点；
- 每阶段推理力度：可调难节点的推理力度且保留提示缓存——推理力度是节点属性；
- 错位监控：异步监测 misbehavior 并告警，属于安全防护层。
- $10 / 1M input，$50 / 1M output，缓存输入 $1；
- 定价悬崖：超 272K 输入 token 的请求，整单按 2x 输入、1.5x 输出计费；
- 不支持 none 推理力度——每个节点调用都推理；
- Astra 默认更爱问澄清问题（无人值守节点要显式 prompt 跟进）、对 skill / AGENTS.md 指令更敏感、委派程度可能低于预期。
Five rules（源自 zero-trust 论文《迈向智能体云工程》，arXiv 2609.00050）：
- 只凭证据推进（代码、部署、测试绿，而非 agent 的散文）；
- 限制重试，且上限必须覆盖反馈路径；
- 终止态只能是"已验证输出"或"已记录拒绝"；
- 权限按步骤授予，而非按会话；
- 你拥有图，Astra 不自由选择 296 中的下一个。
术语翻卡：点卡片看解释
自测一下：点问题展开参考答案
Harness 回答"模型能访问什么、如何控制执行"；Loop 回答"系统如何持续运行到证据表明完成"；Graph 回答"下一步运行哪一步、在什么条件、什么状态"。公式：Agent = Loop(LLM + Harness)；harness 决定能力可用性，loop 决定如何持续交互适应。
LLM 运行在 harness 内部，但不属于 harness 的一部分；可视化上应标记为"可替换"并用虚线边框。harness 定义 agent 能碰什么、不能碰什么、失败如何在扩大前被捕获。
仅 217 个（0.59%）运行中的自主 agent loop，其中 189 个是 Claude Code；社区共识处方（verifier 子代理、预算声明、机器可检查停止条件）在 36,645 个仓库中几乎全军覆没——0/0/0。黑色幽默：6,290 次成功运行、零 agent 执行——"成功的运行，是事情发生的弱证据"。
核心教训："A visible exit is not a bound"（可见的出口不等于边界）；根因第一位是缺强边界（100%）。LangGraph（23）+ AutoGen（22）占比高，是因为反馈经 API 编码而非写在可见循环语法里，躲过了代码评审；框架的 loop 控制参数常覆盖不了真正的反馈路径。
"你拥有图，Astra 不自由选择 296 中的下一个。"296 个智能体是池容量，调度权在人手里——图是你画的，不是模型选的。