预计字数6500 字 阅读时间22 分钟 难度等级⭐⭐小白友好技术概念有生活类比核心价值搞懂 AI Agent 为什么总崩以及怎么让它自己跑起来——用真实配置和代码讲清楚 Harness 与 Loop 两层骨架模型再聪明没有外面的这层包裹长任务里照样会崩。上下文溢出、工具调用一错就雪崩、子代理失控、状态丢失——这些事跟模型智商没关系。2026年AI Agent 工程的讨论焦点完成了一次下沉。从谁的模型分数更高变成了两个更具体的问题运行时怎么不崩 这就是 Agent Harness。怎么让运行时自己跑起来 这就是 Loop Engineering。这两个概念一个管内核、一个管调度。本文用我自己的系统当案例把这两层骨架拆开讲。读完你能直接对照自己的工具栈找出缺的那块。Framework、Harness、Loop三个词别搞混很多人把这三个词混着用。最危险的错觉以为装了个 LangChain 就等于有了完整的 Agent 系统。先把三层关系定下来。Framework框架提供标准化积木——Tool 接口、Prompt 模板、编排原语、基础路由。它解决零件怎么拼。LangChain、CrewAI、AutoGen 都是框架。Harness运行时把积木组装成一个能长期运行、自我纠偏、在安全边界内执行的完整系统。状态持久化、沙盒隔离、分层记忆、中断恢复。它解决拼好之后怎么不崩。Loop自主循环跑在 Harness 之上的调度逻辑。替代人工的一次次手动提示系统自主发现工作、分发任务、验证结果、记录状态、决定下一步。它解决系统怎么自己运转起来。类比Framework 是乐高积木。Harness 是拼好的城堡——有城墙、有门、有结构不会风一吹就倒。Loop 是城堡里的自动巡逻机器人——不需要你亲自去巡逻它自己按路线走。LangChain 官方自己就把前两层分得很清楚LangGraph 是图运行时Frameworkcreate_agent 是最小 HarnessDeepAgents 是在之上的全功能 Harness。再叠一层 Loop——Claude Code 的 /loop 和 /goalCodex 的 Automations Triage Inbox——就构成了 2026 年的完整心智模型。80% 的生产崩溃跟模型智商无关把一个 Agent 从Demo 跑通一次推到稳定服务中间隔着一道工程鸿沟。真实环境里的失败几乎全是四类运行时事故上下文溢出对话太长模型开始遗忘前面的内容工具调用雪崩一个工具报错后续调用全部跟着错子代理失控多个 Agent 并行工作互相不知道对方在干什么状态丢失进程崩了所有中间成果归零这四类问题不是换个更聪明的模型就能解决的。它们是模型外面那层包裹不够结实的问题。我的系统里有一段 YAML 配置专门对付这些问题# ~/.hermes/config.yaml核心片段 model: default: gpt-5.5 provider: openai agent: max_turns: 90 # 单轮对话最大工具调用次数防雪崩 gateway_timeout: 1800 # 网关超时防无限挂起 api_max_retries: 3 # API 重试次数工具调用失败自动恢复 tool_use_enforcement: auto # 工具调用失败时的行为策略这几行配置就是在堵四个洞max_turns 防上下文无限膨胀api_max_retries 给工具调用失败兜底gateway_timeout 保证状态不会永远挂着。但光有配置不够还需要分层记忆和验证闭环。Harness 的内核模型只是中间那个函数抛开框架差异一个生产级 Harness 的内核都围绕同一组职责展开。那篇原文里有句话我特别喜欢模型只是中间那个被反复调用的函数构成 Agent 的是外面那一圈。换框架只是换了那一圈的实现风格。换模型只是换了中间那个函数。长期能复用、能沉淀的工程资产全部在外圈。我的系统外圈长什么样直接看我的 AGENTS.md——这是整个 Harness 的宪法层# Core Identity - 用户大象 - 工作方式一人 AI高频执行重结果 - 主事实源Obsidian 根目录 /Users/dx/Hermes-agent # Core Rules 1. 不虚构案例、数据、经历不确定就标注不确定。 5. 以 Obsidian 为唯一事实源避免多份漂移。 10. 任一 Agent 遇到 token 耗尽、限额、skill 失败或网络故障时 先按 Agent Fallback 机制降级处理再决定是否切换 Agent。PSAgent.md 的部分摘录这是 Harness 的最外层。模型每次启动都会读它知道自己是谁、边界在哪、出了事怎么办。再往里一层是具体的技能文件。我有 78 个技能每个技能是一个 .md 文件--- name: obsidian description: Obsidian 笔记管理 — 读取/搜索/创建 Markdown 笔记 --- # Obsidian Vault **Location:** Set via OBSIDIAN_VAULT_PATH environment variable ## Read a note bash VAULT${OBSIDIAN_VAULT_PATH:-$HOME/Documents/Obsidian Vault} cat $VAULT/Note Name.md这些技能不会一次性全塞进上下文。Agent 决定用哪个技能的时候才加载用完就丢弃。这就是原文说的 **on-demand skills**。 78 个技能在索引里活跃上下文任何时候只有 3-5 个。Token 成本跟着实际用到的技能走不是跟着可用技能数走。 ❌ 别把上下文窗口当垃圾桶。什么技能都往 Prompt 里塞模型还没干活就爆了。按需加载不是优化是让系统能跑起来的前提。 --- ## 分层记忆上下文溢出的头号解药 这是我自己踩过最大的坑。 刚开始用 AI Agent我觉得信息越多越好。所有背景知识、历史对话、项目文档全部塞进上下文。结果上下文爆了模型开始忽略前面的指令越长的任务越不可靠。 后来学了分层记忆。核心思路**不是所有东西都进 Prompt。** 我的系统把记忆分成三层每层有独立的生命周期和衰减规则 python # memory_tiered.py 核心结构 # L1 会话摘要临时性衰减快avg_decay_score: 0.83 # L2 结构化知识稳定事实143条15个分类avg_decay_score: 0.278 # L3 核心洞察长期不变14条路由规则是这样的模型从不直接看到原始分层数据。由一个 Context Engine 决定每一轮从哪一层取什么、取多少进模型之前先做压缩。这套设计强制三条规则正好对应前面那四类崩溃预算在进模型之前就算不是事后救火 → 防上下文溢出只有稳定事实才晋升到长期记忆噪音不污染语义层 → 防幻觉积累每轮写 checkpoint崩了从上一次断点继续 → 防状态丢失做上下文压缩compact时不能用破坏性的纯文本摘要否则会彻底抹除数据源的引用元数据。生产级做法是保留骨架的结构化压缩确保模型回答能精准溯源回原始文件。验证闭环不要相信 Agent 第一次说任务完成先说一个很多人踩过的坑。有创作者让 AI 改标题。第一版普通人用 AI 翻身先学会这 4 个循环——有对象有钩子。AI 自查后觉得不够专业改到第五版变成了关于人工智能应用能力提升的系统性方法研究。看起来高级了实际上没人想点。这就是为什么验证闭环里必须有人类定义的验收标准。AI 能判断是否符合规则但不能判断改完是不是更差——品味判断不在它的能力范围内。验收标准不是写得好一点这种模糊要求而是机器可自查、人类可复判的具体规则——比如标题有没有具体收益正文有没有空话套话读完知不知道下一步。标准越具体AI 越不需要猜你越不需要盯。如果只能从这篇文章带走一条实践就是这条。大量看起来跑通了、其实留了一地破绽的事故都源于缺少一个独立的校验回路。我的系统有一个一票否决三问机制——每篇文章写完后必须回答1. 用户为什么要读完这篇文章2. 读完后能得到什么3. 有没有分享出去的欲望三点任一答不上来一票否决重写。这是在内容创作场景的验证闭环。代码场景也一样——DeepAgents 的安全模型精神内核是边界要在 tool/sandbox 层强制不是指望模型自我约束。自认为完成和被证据证明完成是两回事。执行和验证不能是同一个 Agent。Loop Engineering让 Harness 自己跑起来先用一个生活类比把 Loop 说透。你家的洗衣机不会每 5 分钟弹出来问你现在进水吗现在搅拌吗。你选一个模式它自己走完进水 → 搅拌 → 排水 → 甩干 → 结束。Loop Engineering 就是给 AI 选洗衣模式。一个最小 Loop 只有 5 个环节目标交付什么→ 步骤按什么顺序→ 执行做第一版→ 检查对照验收标准自查→ 修正不合格就改合格就停。Prompt Engineering 解决怎么问Loop Engineering 解决怎么做完。以我自己的系统举例我的每日记忆蒸馏Loop每天凌晨 2 点触发脚本自动扫描当天会话、蒸馏 L1 为 L2、晋升 L2 为 L33:10 同步到 Obsidian。整个过程不需要我坐在键盘前写任何 Prompt——cron 是触发器memory_tiered.py 是执行引擎L1/L2/L3 文件是外部记忆脚本退出码是退出条件。一个完整的 5 环节闭环。Harness 解决了怎么不崩。但谁来按下开始键谁来决定下一步2025 年之前这件事全靠人——坐在键盘前一次次写 Prompt。2025 年下半年开始社区共识变了不要手动提示 Agent去设计循环来提示它。Anthropic Claude Code 负责人 Boris Cherny 说他已经不再直接提示 Claude 了——他写循环由循环去提示 Claude 并决定下一步。Google 的 Addy Osmani 给的定义更直白Loop Engineering 就是用系统取代你自己去提示 Agent。更早的源头是 2025 年 Geoffrey Huntley 提出的 Ralph Loops——一个最朴素的 bash while 循环 一次只做一个任务 每轮全新上下文。极低成本却完成了原本要外包数万美元的活。循环本身比模型更重要。好模型配差循环得到的是昂贵的垃圾。普通模型配上优秀循环和强验证才能稳定出货。我的 33 个 Loop真实系统长什么样概念讲完了直接看我的系统。我每天有 33 个定时任务在后台跑。每一个都是一个 Loop。我不用手动触发任何一个。先看最核心的几个每日记忆蒸馏——每天凌晨 2 点自动触发# 每日凌晨 2:00 执行 python3 /Users/dx/Hermes-agent/memory/memory_tiered.py这个脚本自动扫描当天所有会话把高价值的 L1 摘要蒸馏为 L2 结构化知识把经过时间验证的 L2 晋升为 L3 核心洞察。每天 3:10 再把记忆同步到 Obsidian。这是 Loop 六大组件的实际映射触发器cron 定时隔离独立进程独立上下文技能memory_tiered.py蒸馏逻辑连接器读写 SQLite 写入 Obsidian子代理蒸馏、压缩、清理各是一个子脚本外部记忆L1/L2/L3 三层 SQLite Obsidian md 文件退出条件脚本执行完毕成功/失败都有日志再看一个更复杂的系统健康巡检——每 5 分钟一次这个 Loop 的逻辑是检查 Gateway 进程是否存活 → 如果挂了自动重启 → 检查 WebSocket 连接 → 检查密钥池健康度 → 生成健康报告。任何一个检查点失败都有对应的自动恢复逻辑。这就是原文说的 Plan-Execute-Verify Loop 的变体发现异常 → 执行修复 → 验证结果。还有内容运营方向的 Loop每天早上 5 点自动执行创作雷达——扫描竞品内容、分析公众号数据基线、生成选题建议每周一早上 6:30 生成每周创作策略——基于上周数据驱动决策每周二早上 9 点采集竞品内容这些 Loop 覆盖了五大领域领域Loop 数量举例记忆管理12蒸馏、压缩、清理、衰减、统计、同步、索引系统监控5健康检查、验证、备份、日志内容运营6选题雷达、竞品采集、创作策略、数据提醒知识沉淀5周总结、月归档蒸馏、知识图谱、Skill 审计自动化维护5Obsidian 清理、AI 新闻归档、Vault 检查每加一个 Loop我需要盯着屏幕的时间就少一点。动手搭建你的第一个 Loop我的建议从一个最小可用的 Loop 开始不要追求一步到位。我最早的 Loop 只有一个每天凌晨写日报。一个 cron 脚本触发一次对话生成总结写入文件。然后加了记忆管理。再加了系统监控。再加了内容运营。每一步都是在踩坑之后才明白为什么需要。推荐从一个日常维护 Loop 起步。你不需要 Claude Code任何能跑脚本的环境都行第一步创建你的 AGENTS.md核心规则文件。这是 Harness 的宪法层。把你的项目规则、工具用法、边界写进去。第二步创建一个 PROGRESS.md状态文件。这是 Loop 的外部记忆。记录已尝试什么、测试结果、开放项、下一步。第三步写一个最简单的 Loop 脚本。比如每天自动扫描你电脑上的笔记文件夹把超过 30 天没更新的笔记列出来。这就是一个完整的 Loop——有触发器cron、有技能扫描脚本、有外部记忆笔记文件夹、有退出条件脚本跑完。第四步加验证。让脚本不只列出旧笔记还要检查每个笔记是否有 TODO 项只报告有未完成 TODO 的。这就是一个 Plan-Execute-Verify Loop 的雏形。避坑清单这些弯路我替你走了原文总结的避坑清单每一条我都踩过必须做的明确退出条件。不要让循环一直跑到有人干预。我的每个 cron 都有超时和日志Maker-Checker 分离。执行和验证不能是同一个 Agent。我的内容创作是写作 Agent 一票否决三问严格上下文管理。用外部文件而不是无限聊天历史。我的三级记忆就是这个思路成本监控。无 guardrail 的循环很容易烧钱。我的 max_turns: 90 就是硬预算从小而窄的任务入手。先做每日笔记扫描再做全自动内容生产人类在环。生产变更和架构决策保留人工 checkpoint常见失败模式目标模糊 → Agent 反复猜测token 爆炸缺少退出条件 → 无限循环验证太弱 → 大量低质量输出进主分支忽略并行隔离 → 文件冲突或状态损坏把所有事都 Loop 化 → 吞掉需要人类创造力的部分最后一条我特别有感触。我的实践是Loop 负责把任务推到 90% 完成最后 10% 留给人精炼。四类失败你能在自己的栈里对号入座吗回到那四类生产崩溃。问自己四个问题你的系统有上下文管理吗 对话太长的时候有没有机制压缩、卸载、检查点没有 → 上下文溢出迟早发生。你的系统有工具失败恢复吗 一个 API 调用超时了Agent 知道重试还是换路吗不知道 → 工具调用雪崩。你的系统有子代理隔离吗 多个 Agent 并行的时候有没有独立的工作空间没有 → 子代理失控。你的系统有状态持久化吗 进程崩了中间成果还在吗不在 → 状态丢失。如果你无法在自己的栈里为这四条各指出一个具体模块那你手里的是 Demo不是生产系统。回头看过去三年 AI 工程的演化有一条清晰的脉络2023 年我们在学怎么写 Prompt2024 年我们在学怎么编排 Agent2025 年我们在学怎么给 Agent 加一层运行时到 2026 年我们终于在学习怎么让这个运行时自己跑起来。每一次跃迁都是把人需要亲自做的事往外推一层。这个过程里模型一直是最受关注的部分却也是最不属于你的部分。属于你的是你给模型套上的那个 Harness——它决定了你的系统在长任务面前会不会原地崩。以及你架在 Harness 之上的那个 Loop——它决定了你需不需要 24 小时盯着屏幕。这两层加在一起才是你可以累积、可以交接、可以变成护城河的工程资产。模型每周都在变强但能让强模型变成可靠产出的从来都不是模型本身。既然看到这里了如果觉得不错随手点个赞、在看、转发三连吧如果可以给我个星标⭐将不胜感激谢谢你看我的文章我们下次再见。#Harness #Loop Engineering #AI Agent #大象AI共学作者大象-推动 AI 共学让普通人轻松上手AI相关链接1. 社群站https://daxiangnaoyang.github.io/daxiang-ai-gongxue/2. Addy Osmani - Loop Engineering开创性框架文章3. Geoffrey Huntley - everything is a ralph loopRalph Loops 起源与哲学4. Cobus Greyling - Loop Engineering Playbook实战 playbook