过去这几个月，社区里关于 Agent 的讨论焦点经历了一次完整的下沉。年初大家还在比模型分数，到 2026 年中，X 与 GitHub 上的工程师已经在讨论两件更具体的事：

• 运行时怎么不崩——也就是 Agent Harness。模型再聪明，没有外面这层包裹，长任务里照样会上下文溢出、工具调用一错就雪崩、子代理失控、状态丢失。
• 怎么让运行时自己跑起来——也就是 Loop Engineering。从「人坐在键盘前一遍遍打字提示」转向「设计一个能自主发现工作、分发、验证、记录、决定下一步的循环系统」。

这两件事一上一下：Harness 是内核，Loop 是跑在内核上的自主进程。本文把它们放在一起讲，希望提供一份能直接拿去对照自己技术栈的工程笔记。

1. 术语先收敛：Framework、Harness、Loop 三者的分层

很多人把 Framework 和 Harness 混为一谈，于是误以为「装了 LangChain 等于有了 Harness」。再叠上一个 Loop 的概念，更容易乱。先把三层关系定下来：

• Framework（框架）：提供标准化积木——Tool 接口、Prompt 模板、Graph/Crew 编排原语、基础路由。它解决「零件怎么拼」。
• Harness（运行时）：把这些积木组装成一个长期运行、能自我纠偏、在严格安全边界内执行的完整生命周期系统。它解决「拼好之后怎么不崩」——状态持久化、沙盒隔离、分层记忆、HITL 中断恢复。
• Loop（自主循环）：跑在 Harness 之上的调度逻辑——它替代了人工的「一次次手动提示」，由系统自主发现工作、分发任务、验证结果、记录状态、决定下一步。它解决「系统怎么自己运转起来」。

LangChain 官方文档把前两层讲得很清楚——LangGraph 是图运行时，create_agent 是最小 Harness，DeepAgents 是在其之上的"opinionated 全功能 Harness"。再往上叠一层 Loop（如 Claude Code 的 /loop、/goal，Codex 的 Automations + Triage Inbox），就构成了 2026 年的完整心智模型：

下面先讲 Harness（第二到第七节），再讲 Loop（第八节起）。最后用一节把两层重新合并起来。

2. 为什么 80% 的生产崩溃和模型智商无关

把一个 Agent 从「Demo 跑通一次」推到「在 SaaS 生产环境里稳定服务」，中间隔着一道工程鸿沟。真实环境里的失败，绝大多数与模型聪不聪明无关，而是死在四类运行时事故上：

这张表是后面所有架构与实践的「问题定义」——所有模块本质上都是在系统性地堵这四个洞。

值得注意的是，这一层关注点已经写进了头部项目的自我定位：LangChain 的 DeepAgents 直接把自己定义为 “the batteries-included agent harness”，字节的 DeerFlow 2.0 把自己描述为 “Super Agent Harness”。术语已经从社区黑话变成了产品命名。

3. Harness 的解剖：一张图看懂运行时内核

抛开框架差异，一个生产级 Harness 的内核都围绕同一组职责展开。下图把「模型」放在正中央，外面那一圈才是真正决定成败的工程。

读这张图的正确姿势：模型只是中间那个被反复调用的「函数」，构成 Agent 的是外面那一圈——规划、上下文工程、工具层、沙盒、验证闭环，以及随时介入的记忆和检查点。换框架本质上只是换了这一圈的实现风格；换模型则只是换了中间那个函数。长期能复用、能沉淀的工程资产，全部在外圈。

4. 头部 Harness 框架格局

结合 GitHub 活跃度、生产案例与工程化体感，当前生态高度分化。下表把主要项目按「核心定位 + 最佳场景」摊开——不存在「最好」，只存在「最匹配你的任务时序与合规需求」。

数据基准（截至 2026 年 6 月）：DeerFlow 2.0 约 72.8k stars、DeepAgents 约 24.9k stars，均为当期 GitHub 趋势顶流；LangGraph 在企业案例（Klarna、Uber 等）与下载量上领先。

5. 多维落地对比：拒绝理论，直击痛点

光看定位不够。真正决定选型的，是把它们丢进同一组生产维度里压测。

5.1. 长时程任务可靠性

这是评估 Harness 的试金石。DeerFlow 与 LangGraph / DeepAgents 在这一维度领先：前者靠动态子代理 + 隔离沙盒文件系统 + 上下文 offload + 持久记忆；后者靠 checkpointing + state persistence + 隔离上下文。共同的工程内核是——把上下文卸载到外部存储，用检查点机制对抗长对话中的幻觉与逻辑崩塌。相对地，CrewAI / AutoGen 在超长 workflow 上更容易出现委派链失控或对话循环。

5.2. 多代理协同

• CrewAI 提供最直观的团队拓扑（角色 Crew）。
• LangGraph 允许手写任意复杂的层级（Hierarchical）拓扑。
• DeerFlow 走 supervisor + 动态 spawn + 结果聚合。

一条被反复验证的经验：在代码生成这类复杂流里，给 Agent 喂「通过专门 Indexing 工具精准提取的代码片段」，远比让它自主漫游整个仓库有效。上下文的精准投喂本身就是一种 orchestration 能力。

5.3. 可观测性与生产护栏

LangGraph + LangSmith 提供全链路 Trace 与可视化调试，是合规审计场景的上限。在数据隐私优先的场景，DeerFlow 的本地沙盒执行 + 严格权限 Hook 更关键——它官方明确标注"为本地可信环境设计"，跨网络部署必须自行加 IP 白名单、认证网关与网络隔离。

5.4. 溯源与幻觉抑制

在知识管理或可视化工作区场景，AI 回答必须 100% 来源可追溯。LlamaIndex Workflows 与定制化的 LangGraph 节点可以强制 Agent「仅从注入的上下文中提取信息」，落地为一条硬规则：无证据，不输出。

柱状 = LangGraph 系（含 DeepAgents）；折线 = DeerFlow 系。LangGraph 系在可观测/合规上封顶，DeerFlow 系在长时程自主与子代理 spawn 上更激进，两者上手曲线都更陡。

6. 验证闭环：被低估的命脉

如果只能从本文带走一条实践，是这条：不要相信 Agent 第一次输出的「任务完成」。

大量「看起来跑通了、其实留了一地破绽」的事故，都源于缺少一个独立的校验回路。生产级 Harness 必须引入 Critic 子代理、沙盒内试运行、或严格的结构化校验节点，把「自认为完成」替换成「被证据证明完成」。

这条回路把「LLM 的乐观自评」替换成了「沙盒的客观裁决」。它也正是 DeepAgents 安全模型的精神内核——官方原话是 “trust the LLM” 模式下，边界要在 tool / sandbox 层强制，而不是指望模型自我约束。这条原则在第九节讲 Loop 时还会再次出现——循环里如果没有独立验证者，跑得越多越糟。

7. Harness 工程的两个深水区

7.1. 分层记忆：把 Context Window 当倾倒场是上下文溢出的头号成因

生产级的 Harness 会把记忆按用途和生命周期切开，读写都走显式路由：

下图的关键不是分层本身，而是路由规则：不是所有东西都进 Prompt，由 Context Engine 决定每一轮从哪一层取什么、何时取，并在送进模型之前完成 compaction。

一份框架无关的最小路由示意——模型从不直接看到原始分层数据，只看到压缩、限额后的组装结果：

class TieredMemory:
    def assemble_context(self, turn, token_budget):
        parts = []
        # 1. 常驻：当前任务的工作记忆（最高优先级）
        parts += self.working.recent(turn.task_id)
        # 2. 定向召回：与本轮相关的语义事实
        parts += self.semantic.search(turn.query, k=5)
        # 3. 连续性：本项目情景历史的摘要（不是原始日志）
        parts += [self.episodic.summary(turn.project_id)]
        # 4. 知识：RAG 检索，附证据用于溯源
        parts += self.rag.retrieve(turn.query, k=8, attach_source=True)
        # 5. 硬预算：在送进模型之前完成 compaction
        return compact(parts, max_tokens=token_budget)

    def commit(self, turn, model_output):
        self.working.update(turn.task_id, model_output.progress)
        if model_output.durable_facts:           # 只有稳定事实才晋升到长期
            self.semantic.upsert(model_output.durable_facts)
        self.checkpoint.write(turn.session_id)   # 用于崩溃恢复

💡 Tips：在执行 compact() 进行上下文压缩时，切记不能使用破坏性的纯文本摘要，否则会彻底抹除数据源的引用元数据（Metadata Pointers）。生产级做法是在压缩时采用"保留骨架"的结构化压缩，确保后续模型生成的每一句回答都能带着 ID 精准溯源回原始卡片、文件或特定坐标。这是打造高可信、无幻觉知识库工作区的底层铁律。

这套设计强制三条规则，正好对应第二节的失败表：

• 预算在进模型之前就算，不是事后救火；
• 只有稳定事实才晋升到长期记忆，工作记忆的噪音不污染语义层；
• 每一轮都写 checkpoint，崩了从上一次 commit 继续，不从零开始。

7.2. MCP 延迟绑定 + on-demand skills

上下文溢出的第二大成因是工具/技能清单本身。最直白的做法是把所有 MCP 工具的完整 schema、所有技能的完整说明，统统塞进 system prompt——一个还没干活、prompt 就已经爆掉的"monolithic prompt"。两个正在成为 2026 标配的技术互相补位地解决了这个问题：

MCP 延迟绑定：Harness 不再前置注入每个工具的完整 schema，而是只注入一份轻量目录（名字 + 一行描述）。具体工具的完整 schema，只在 Agent 决定调用它的那一刻才被拉取并绑定。Token 成本随「实际用到的工具数」而非「可用的工具数」伸缩。

on-demand skills：DeerFlow 和 DeepAgents 都用 Markdown 技能。技能体平时只是磁盘上的索引，Agent 真正需要时才把完整技能正文加载进上下文，用完即可丢弃——也就是「渐进加载」，让技能库可以很大，而活跃上下文很小。

然而，延迟绑定并非免费的午餐，它带来了一笔隐藏的**「规划税（Planning Tax）」**。由于 Agent 在初始阶段只能看到极其精简的工具目录，系统必须在 Harness 的编排层（Orchestrator）中注入更具强度的语义路由（Semantic Routing）提示词或轻量分类模型。否则，智能体很容易因为缺乏对工具参数细节的预知，导致「选错工具」或「不敢选工具」，反向引发规划阶段的逻辑死循环。

一份示意性的对照（数字仅供说明结构）：

在动辄几十个 MCP server 和成长中的技能库的环境里，延迟绑定不是优化项，而是让 Agent 能跑起来的前提。它也和验证闭环天然契合：Critic 需要校验工具时就 just-in-time 绑定，跑完即释放。

8. Loop Engineering：让 Harness 自己跑起来

Harness 解决了「运行时怎么不崩」。但即使有了一台稳定的"OS"，谁来按下开始键、谁来决定下一步？2025 年之前，这件事几乎全靠人——程序员坐在 IDE 前一次次写 prompt。从 2025 下半年到 2026 年中，社区的共识发生了第二次位移：

不要再手动提示 Agent，去设计循环来提示它。

Anthropic Claude Code 负责人 Boris Cherny 的说法是：他已经不再直接提示 Claude，而是写循环，由循环去提示 Claude 并决定下一步。Google 的 Addy Osmani 给了一个清晰的定义——Loop Engineering 就是用系统取代你自己去提示 Agent：你设计一个能自主发现工作、分发任务、验证结果、记录状态并决定下一步的循环；循环可以理解为一个递归目标，你定义目的，AI 不断迭代直到完成。

这件事更早的源头是 2025 年 Geoffrey Huntley 提出的 Ralph Loops：一个最朴素的 bash while 循环 + 一次只做一个任务 + 每轮全新上下文，就能以极低成本完成原本要外包数万美元的活。现代 Loop Engineering 做的，是把 Ralph 的朴素做法系统化、组件化，再扩展到多子代理、持久技能、外部记忆和企业级编排。

Anthropic 内部的数据给了它一个量级参照：用了良好循环的工程师，代码合并量可提升 8 倍以上，Claude 贡献了约 80% 的合并代码。需要强调的是后半句——这个倍数的前提是循环里有真正的验证闭环，否则跑得越多，进主分支的低质量代码（slop）越多。

Loop 也不是万能药：token 成本可能失控，验证不足会量产 slop，过度自动化会把需要人类创造力的部分也一并吞掉。一个胜任的 Loop Engineer，同时是系统设计者、验证工程师和成本控制者。

9. Loop 的六大组件与退出条件

Addy Osmani 把一个健壮的 Loop 拆成六个支柱，加上一个不能省的退出条件。上面几节讲的 Harness 模块与它一一对应——Loop 是调度层，Harness 是执行层。

1. Automations（自动化触发器） —— 循环的心跳。不是简单的 cron，而是能自主发现工作并分诊的调度器。Claude Code 原生支持 /loop（按节奏重跑）和 /goal（跑到条件满足，如"所有测试通过且 lint 干净"）；Codex 有类似的 Automations + Triage Inbox。自定义则可以用 GitHub Actions、cron + 脚本，或编排器定时触发"发现未解决 issue / CI 失败 / 新 PR 评论"。
2. Worktrees（工作树隔离） —— 并行 Agent 不互相踩脚。每个 Agent 在独立的 git worktree + 分支上工作：git worktree add ../agent-wt feature/xxx，或 Claude Code 的 --worktree 标志 + isolation: worktree 配置。这是规模化的前提，否则并行会变成文件冲突。
3. Skills（技能 / 持久知识） —— 不让 Agent 每次都从零猜项目惯例。把规则、架构决策、构建命令、"我们为什么不这么做"写进 SKILL.md 或 AGENTS.md；Claude Code / Codex 支持 $skill-name 显式调用或隐式匹配。这与第七节的 on-demand skills 是同一件事在 Loop 层的体现。
4. Plugins & Connectors（基于 MCP 的连接器） —— 让 Agent 触及真实世界：读 Linear/Jira、查数据库、调 staging API、发 Slack、开 PR。MCP 让不同工具的连接器可互操作，并可以配合第七节的延迟绑定控制成本。
5. Sub-agents（子代理分工） —— Maker-Checker 分离是关键防线。写代码的 Agent 往往对自己太宽容，必须有独立验证者。典型分工：Explorer（快、只读、规划）、Implementer（执行）、Reviewer（强模型、高推理 effort，负责安全与测试审查）。子代理可并行运行，结果折叠回主循环。这正是第六节验证闭环在 Loop 层的实例化。
6. External Memory / State（外部记忆与状态） —— LLM 会遗忘，但 repo 不会。用 AGENTS.md、PROGRESS.md、TODO.md、Linear 看板或结构化 Markdown 记录"已尝试什么、测试结果、开放项、下一步"。这也是自改进循环的基础：失败模式被记录后，可以转化成新技能或 guardrail。它与第七节的分层记忆互为补充——Harness 的分层记忆是运行时的内部状态，Loop 的外部记忆是跨轮、跨会话、人可读的沉淀。值得注意的是，如果你的 Agent 运行在面向用户的视觉画布（Visual Canvas）或卡片化工作区中，这里的外部记忆必须从「人可读的 Markdown」晋升为「机可读的结构化 Schema」。你需要将画布的 XY 轴坐标、卡片之间的 Graph 拓扑关系、以及临时交互状态实时同步至数据库。此时，Loop 的验证回路（Verification Loop）不仅要跑测试，还要强校验输出的 JSON 是否契合前端 UI 渲染引擎的严格类型。

退出条件是六个组件之外最容易被忽略、但一旦缺失就最致命的一项。 不要让循环「一直跑到有人干预」，要用硬条件：测试通过、特定文件变更、预算耗尽、或显式标记需人工介入。

10. Ralph Loops：最朴素的那套经验

现代 Loop Engineering 的很多"高级"特性，都能在 Ralph 的极简实践里找到雏形：

• 一次只做一个任务 + 每轮全新上下文：极大缓解 context rot（上下文腐烂）。
• Backpressure（背压）：改动后只对受影响单元跑测试/类型检查，而不是全量构建。
• 单体优先：先在一个 repo 里把循环跑通，再考虑复杂的多代理通信。
• 子代理当工具用：主循环只做调度与决策，重活交给并行子代理去搜索/分析。

核心示例简单到可以直接扩展：

while :; do
   cat PROMPT.md | claude --worktree agent-wt || true
   # 验证、提交或更新计划
   sleep 30
done

Ralph 的结论是一句反直觉但反复被验证的话：循环本身比模型更重要。好模型配差循环，得到的是昂贵的 slop；普通模型配上优秀循环和强验证，才能稳定出货。

11. 动手搭建第一个可用的 Loop

推荐从一个最小可行结构（MVP）起步。项目根目录创建：

• CLAUDE.md / AGENTS.md（核心规则 + 技能）
• PROGRESS.md 或 TASKS/（状态）
• skills/（具体技能文件）
• .claude/agents/（子代理定义，如果用 Claude Code）

一个日常维护 Loop 的典型设计：

1. 设置 /goal 或 automation：每晚或 CI 失败时触发。
2. 指令：“扫描最近失败的测试和 PR 评论，优先修复高影响 bug；更新 PROGRESS.md，创建必要 PR，只在验证通过后提交。”
3. 结合 Skills：自动调用"测试修复技能"和"PR 描述生成技能"。
4. 退出条件明确：“所有相关测试通过 + lint 干净 + 无高危安全问题，或明确标记需人工介入。”

如果你用的不是 Claude Code，同样的形状用脚本也能表达：

#!/bin/bash
# daily-triage-loop.sh
while true; do
  echo "=== $(date) starting triage loop ===" >> loop.log
  # 1. 发现工作（gh CLI / Linear API / grep 等）
  # 2. 为每个任务生成带上下文的 prompt
  # 3. 调用你的 Agent（claude-code / local-llm / 编排器）
  # 4. 验证（跑测试、lint、安全扫描）
  # 5. 更新 memory / state 文件
  # 6. 决定是否继续或休眠
  sleep 3600
done

几个进阶模式值得照搬：

• Plan-Execute-Verify Loop：先让规划子代理输出详细计划 → 执行子代理实现 → 验证子代理跑测试/审查。
• Explore-Narrow Loop：调试时并行探索多个假设，逐步收窄。
• Self-Improving Loop：运行后让 Agent 分析自身失败模式，提案更新 SKILL.md 或 guardrail。

12. 避坑清单

必须做的：

• 明确终止条件，不要"一直跑到人干预"。
• Maker-Checker 分离 + 多层验证（单元测试 + 集成测试 + 关键路径人工抽查）。
• 严格上下文管理：每轮总结 → 注入必要记忆 → 丢弃噪音。用外部文件而不是无限聊天历史。
• 成本监控：设置 token 预算，优先用快模型做探索、强模型做验证。无 guardrail 的循环很容易烧钱。
• 从小而窄的任务入手。先做「修复特定类型 bug」或「每日 Git 历史摘要 + Slack 通知」，再扩展到完整的 feature 构建。
• 人类在环：生产变更、模糊需求、架构决策保留人工 checkpoint。

常见失败模式：

• 目标模糊 → Agent 反复猜测，token 爆炸。
• 缺少退出条件 → 无限循环或死循环。
• 验证太弱 → 大量低质量代码进主分支。
• 忽略并行隔离 → 文件冲突或状态损坏。
• 把所有事都 loop 化 → 吞掉需要人类创造力的部分。一个中间状态的实践是：循环负责把任务推到 90% 完成，最后一段留给人工精炼。

13. 两层重新合一：四类失败 · 三架架构 · 一条路径

13.1. 四类失败与对应模块的映射

本文的一切，都可以回到第二节那张表。评估或搭建一个 Harness + Loop 系统时，这是能直接对照的清单：

如果你无法在自己的栈里为这四条箭头各指出一个具体模块，那你手里的是 Demo，不是生产系统。

13.2. 三架代表性 Harness 的架构对照

LangGraph、DeepAgents、DeerFlow 三者同源但押注不同：LangGraph 是运行时基底；DeepAgents 是它之上 opinionated 的完整 Harness；DeerFlow 在内部使用 LangGraph，但叠加了重型沙盒、动态 spawn 与运营通道。

选型一句话：DeepAgents 适合想要开箱即用的完整 Harness；需要完全自定义拓扑时下沉到 LangGraph；任务小时级、需要真实沙盒 + IM 运营通道时选 DeerFlow。三者可以组合——任何 LangGraph CompiledStateGraph 都可以作为子代理传入 DeepAgents。

13.3. 一条可执行的路径

不要去找「完美」的框架。找最匹配你任务时序、状态复杂度、合规需求的运行时。

第一步用轻量框架把 MVP 跑通，重点观察失败模式而不是功能；业务逻辑验证后立刻迁到具备强类型、强状态、完整可观测性的生产级 Harness；然后把精力压在工具失败恢复逻辑与 Token 成本曲线上。

14. 总结

回头看，过去三年 AI 工程的演化其实有一条清晰的脉络：2023 年我们在学怎么写 Prompt，2024 年我们在学怎么编排 Agent，2025 年我们在学怎么给 Agent 加上一层运行时，到 2026 年，我们终于在学怎么让这个运行时自己跑起来。每一次跃迁，都是把「人需要亲自做的事」往外推一层。

这个过程里，模型一直是最受关注的部分，却也是最不属于你的部分。属于你的，是你给模型套上的那个 Harness——它决定了你的系统在长任务、并发、真实工具面前会不会原地崩；以及你架在 Harness 之上的那个 Loop——它决定了你需不需要 24 小时盯着屏幕。这两层加起来，才是一支团队真正可以累积、可以交接、可以变成护城河的工程资产。

模型每周都在变强，但能让强模型变成可靠产出的，从来都不是模型本身。

#harness #AI #Agent #LangGraph #DeepAgents #LoopEngineering

15. 参考文献

• Addy Osmani - Loop Engineering（开创性框架文章，强烈推荐首读） @addyosmani
• MindStudio - What Is Loop Engineering? The New Meta for AI Coding Agents（清晰定义 + 架构 + 最佳实践）
• 你不知道的 Agent：原理、架构与工程实践（@HiTw93 大佬精品长文，推荐细读）
• What Is Loop Engineering? AI Feedback Loops（反馈循环深度解析 + 编码实战）
• WTF Is a Loop? Part 2: The 15 Loops People Are Actually Running (and the Commands to Steal Them) @mvanhorn
• Lush Binary - Loop Engineering: The Guide for AI Agents（全面指南）
• Geoffrey Huntley - everything is a ralph loop（Ralph Loops 起源与哲学，2025 奠基之作）
• Geoffrey Huntley - Ralph Wiggum as a “software engineer”（Ralph 实战技术细节）
• TrueFoundry - Loop Engineering at Enterprise Grade（企业级 runtime 视角）
• Firecrawl - Loop Engineering: Should You Stop Prompting Agents（与 harness 结合的实用讨论）
• Cobus Greyling - The core of Loop Engineering（核心概念 + 演进）
• Cobus Greyling - Loop Engineering Playbook（实战 playbook 与模式）