Agent一上线就疯狂报错？别怪大模型，是你没搞懂这三层架构

Agent一上线就疯狂报错？别怪大模型，是你没搞懂这三层架构 — AI大模型-阿水

AI大模型-阿水

AI-assisted summary of Agent一上线就疯狂报错？别怪大模型，是你没搞懂这三层架构 — original source. Check the original for full context.

Source published:

Key ideas

  • 生产环境中 Agent 频发报错的根基并非模型智商不足或提示词未写好，而是工程系统缺失；高可用 Agent 的核心公式为“大模型 + 工程系统”，需通过三层工程底座来保障稳定性。 (0:00)
  • Harness 层作为底层工作台与安全防护网，必须具备隔离沙箱、权限控制与轨迹审计日志，且工具设计应遵循“少而准”原则，故障排查须优先检查接口入参及鉴权配置。 (1:52)
  • Loop 层旨在打造涵盖客观证据验证的闭环，严禁轻信模型的单方完工声明，同时必须通过设置预算上限、连败熔断以及人机协同（HITL）机制防止无限重试引发的成本失控。 (3:47)
  • Graph 层通过状态检查点（Checkpoint）实现长流程断点续跑与任务并发调度；三层架构呈有机嵌套结构：Harness 为地基，Graph 为骨架，Loop 则是内嵌于各节点内部的执行肌肉。 (5:00)

Detailed notes

## Background 该视频由 UP 主“AI大模型-阿水”于 2026 年 10 月 12 日发布在 Bilibili 平台。视频简介提供了包括 Agent 学习资料、大模型学习路线、实战案例集与电子书在内的配套资源链接及答疑渠道。

## TL;DR 视频针对许多开发者面临的“Agent 本地运行流畅、一上线生产环境就频繁报错”这一痛点，指出核心症结并非大模型智商或提示词，而在于工程底座的缺失。作者提出了“能打的 Agent = 大模型 + 工程系统”的核心公式，并将系统解构为三层架构：充当运行沙箱与安全工具底座的 Harness、负责证据验证与熔断控制的 Loop，以及承载复杂业务骨架与断点恢复的 Graph。最后，视频总结了三层联动的排障口诀与从极简 MVP 到固化图节点的演进方法，帮助开发者在线上快速定位并解决稳定性问题。

## Atmosphere & style 讲解风格直击痛点且极其务实，开篇以“名校高材生入职却不给配电脑”的形象比喻直指工程配套缺失的尴尬现状，极易引发一线开发者的共鸣。整体叙述逻辑严密、节奏紧凑，褪去了对“调优提示词”的玄学迷信，充满了冷静严谨的后端架构思维。听感上犹如资深架构师在白板前复盘线上事故，既有条分缕析的故障定位法则，又有防止过度设计的清醒劝诫，兼具警示性与落地实操感。

## Bulletin - [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) 生产环境中 Agent 频发报错的根基并非模型智商不足或提示词未写好，而是工程系统缺失；高可用 Agent 的核心公式为“大模型 + 工程系统”，需通过三层工程底座来保障稳定性。 - [01:52](https://www.bilibili.com/video/BV15qpj6aEwY?t=112s) Harness 层作为底层工作台与安全防护网，必须具备隔离沙箱、权限控制与轨迹审计日志，且工具设计应遵循“少而准”原则，故障排查须优先检查接口入参及鉴权配置。 - [03:47](https://www.bilibili.com/video/BV15qpj6aEwY?t=227s) Loop 层旨在打造涵盖客观证据验证的闭环，严禁轻信模型的单方完工声明，同时必须通过设置预算上限、连败熔断以及人机协同（HITL）机制防止无限重试引发的成本失控。 - [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) Graph 层通过状态检查点（Checkpoint）实现长流程断点续跑与任务并发调度；三层架构呈有机嵌套结构：Harness 为地基，Graph 为骨架，Loop 则是内嵌于各节点内部的执行肌肉。

## Key takeaways - [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) 本地测试丝滑而线上频繁崩溃的根源在于忽视了工程底座，盲目升级大模型参数量或死磕提示词无法从根本上解决接口超时与状态丢失问题。 - [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) 大模型仅决定了 Agent 的能力上限，而底层的工程配套设施决定了其在生产环境中能否稳定交付业务结果。 - [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) Agent 工程底座必须拆解为 Harness、Loop、Graph 三层架构，分别解决“具备不具备条件干”、“干没干对”以及“复杂流程怎么稳住”的问题。 - [01:52](https://www.bilibili.com/video/BV15qpj6aEwY?t=112s) Harness 层必须标配执行沙箱、安全权限控制、工具集及上下文状态管理四大组件，防止 Agent 越权或误伤真实生产系统。 - [01:52](https://www.bilibili.com/video/BV15qpj6aEwY?t=112s) 工具配置切忌盲目堆砌，工具冗余和冗长背景资料会挤占上下文窗口并干扰模型决策，Harness 需坚决遵循“少而准”原则。 - [01:52](https://www.bilibili.com/video/BV15qpj6aEwY?t=112s) 工具调用轨迹必须全部落盘审计，线上报错时的黄金排查顺序应由外向内依次收敛：接口入参、系统鉴权、上下文冲突，最后才考虑模型能力与提示词。 - [03:47](https://www.bilibili.com/video/BV15qpj6aEwY?t=227s) Loop 的核心价值是引入客观证据验证机制，不能仅凭模型输出“任务已完成”即放行，必须依赖返回码、测试用例或数据格式等硬性证据检验结果。 - [03:47](https://www.bilibili.com/video/BV15qpj6aEwY?t=227s) 无限重试不仅会成倍推高端到端延迟，更会导致上下文拉长和 Token 费用暴涨，Loop 设计中必须严格限定单次任务的预算上限与连续失败熔断阈值。 - [03:47](https://www.bilibili.com/video/BV15qpj6aEwY?t=227s) 涉及资金支付、邮件群发、核心数据篡改等敏感操作时，Loop 必须强制挂起并引入人工介入（HITL）审批授权，规避系统失控风险。 - [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) Graph 层通过节点、流转条件和检查点（Checkpoint）编排复杂并发业务；检查点机制允许系统在突发中断时直接读档恢复，避免全局流程推倒重来。 - [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) 应警惕 Graph 架构的过度设计，过早将流程切分成极碎的节点会大幅降低流程柔性；健康的 Graph 只需固化核心业务边界，其余判断放权由模型动态处理。 - [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) 三层架构为深度嵌套的整体：Harness 提供底层沙箱与工具地基，Graph 负责全局拓扑调度骨架，Loop 则是内嵌在节点内部就地纠偏的肌肉。 - [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) 落地新业务应采取“三步走”演进策略：先以极简 Loop 跑通 MVP，再落盘分析沉淀执行轨迹，待调用规律彻底稳定后再固化为正式的 Graph 节点。 - [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) 快速故障定位口诀：接口调用报错排查 Harness 环境与权限，死循环与输出混乱排查 Loop 验证规则，流程卡死与状态断档排查 Graph 分支与检查点。

## Detailed walkthrough ### [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) 为什么本地像天才、线上疯狂报错：模型智商 vs 工程底座

很多开发者在做 Agent 时都会遇到一个极为尴尬的现象：在自己的本地电脑上跑测试，数据是精心喂好的，流程是单线条的，几乎不报任何错误，体验极其丝滑；可一旦推到线上生产环境，立刻变成车祸现场——外部接口动不动超时、上下文突然断档丢失、逻辑陷入死循环无限打转，打开后台日志看就是两眼一抹黑。很多人遇到这种线上 Bug，第一反应通常是怀疑大模型的理解能力不行，急着去换参数量更大的模型，要么就是觉得 Prompt 没写好，天天死磕提示词工程。但实际情况是，改了半天提示词，该调不通的接口依然报错，该丢的状态照样丢失。

归根结底，大模型充其量只是一个“大脑”。哪怕这个大脑再聪明，如果没有能施展拳脚的躯干和与之匹配的现实环境，它什么也干不了。这就好比一家公司花重金从顶尖名校挖来一个绝顶聪明的高材生，脑子极好使、教什么秒懂，但他第一天入职，你让他坐在一张空桌子前，不发电脑、不开内网权限、也不告诉他公司的审批与报销流程，他能产出什么业绩？只能坐在那里干瞪眼。这时候责任显然不在他的智商，而是公司的工程配套设施没有跟上。做 Agent 的逻辑完全一样，必须牢记一个核心公式：**一个能打的 Agent = 大模型 + 工程系统**。大模型只决定了能力的上限，真正决定它能不能在线上稳定干活的，是底层的工程底座。

为了让排查和架构设计更清晰，这个工程底座必须拆解为三层架构：**Harness（测试夹具/执行运行底座）**、**Loop（循环控制闭环）**、**Graph（图编排网络）**。很多人可能会问，写一个几千行的 Python 脚本全部包圆不行吗？分层的最大价值在于线上出事时能够迅速定位故障：“调外部 API 失败了去查权限与环境配置（Harness）；输出结果总是不对去查验证逻辑（Loop）；整个任务流卡死了去查节点流转（Graph）”。这种明确的分工是保命的工程规范： - **Harness**：负责运行环境与边界，解决“这活到底具备不具备条件干”的问题。 - **Loop**：负责反馈和证据验证，解决“这活到底干没干对”的问题。 - **Graph**：负责整体的协作与流转编排，解决“复杂流程怎么稳住”的问题。

---

[01:52](https://www.bilibili.com/video/BV15qpj6aEwY?t=112s) Harness 层：量身定制的工作台与防护网

Harness 可以被视作为大模型量身定制的工作台，同时外挂了一道严密的安全防护网。一个合格的 Harness 必须标配四大组件：第一是**执行沙箱**，模型运行代码必须在隔离的安全区内，绝不能直接操作真实环境以免误删主库；第二是**安全控制**，权限必须卡死，任何越权行为必须直接拦截；第三是**工具集**，给模型配备好用、干净的 API 作为手脚；第四是**上下文与状态管理**，必须让模型时刻清楚自己当前推进到了哪一步。

在给 Agent 配备工具时，很多开发者容易踩大坑，以为只要接口能调通就万事大吉。实际上必须做到全程可控、有据可查：模型发起工具调用前要先验证身份与权限，通过后放进上下文执行，执行完毕后的调用轨迹必须全部落盘记录。否则线上一旦发生严重事故，连当时 Agent 做了什么操作都没有审计日志，排查根本无从下手。

另一个常见的致命毛病是“贪多求全”：盲目塞入几十个名称相近的工具，或者塞满冗长的背景资料。这会导致模型彻底懵圈，就像让人在堆满杂物的巨大仓库里找一把特定扳手，效率极低；多余的废话和无用信息更会直接把关键上下文挤出窗口。因此，Harness 的核心原则是**少而准**。当工具调用出现报错时，排查的黄金顺序必须是从最外围向内收敛： 1. 先检查接口入参格式与定义是否正确； 2. 再检查系统权限与网络鉴权是否给足； 3. 接着检查上下文里是否存在冲突或矛盾信息； 4. 排除掉所有确定的工程因素后，最后再去怀疑模型的能力或调整提示词。

---

[03:47](https://www.bilibili.com/video/BV15qpj6aEwY?t=227s) Loop 层：打造证据闭环与刹车机制

往上走一层就是 Loop。Loop 的核心使命是确保每一步调用都有回音，并且系统明确知道什么时候该踩刹车。很多人误以为 Loop 就是让模型在那里无脑重试、无限死循环，但其真正的精髓在于打造一个**证据闭环**。常规的代码通常包含三步：读取状态、决定怎么做、调用工具执行。然而，至关重要的第四步——**验证（Verification）**——却常常被开发者遗漏。

如果不加验证，模型只要回复一句“任务已完成”，系统就盲目轻信并直接进入下一步，这就像比赛中运动员自己给自己当裁判宣布跑了第一名，成绩毫无可信度。模型说“做完了”不能算数，必须出具客观证据：例如底层接口是否真正返回了成功的状态码、测试用例是否全绿跑通、输出的数据格式是否严格匹配。

```mermaid flowchart TD accTitle: Agent Loop Execution and Stopping Flow accDescr: The execution loop of an agent covering status reading, decision making, tool execution, objective verification, and stop conditions. subgraph Execution["单步证据闭环"] A["读取当前状态"] --> B["决策行动方案"] B --> C["调用工具执行"] C --> D{"客观证据验证"} end

subgraph Evaluation["判定与出口"] D -->|"验证通过"| E["任务成功退出"] D -->|"验证失败"| F{"检查停止红线"} F -->|"超预算/连败3次"| G["强制掐断/告警"] F -->|"触发敏感操作"| H["转人工审核 (HITL)"] F -->|"在限额内"| A end ```

同时，工程实现必须算清经济账。模型多跑一次 Loop 都在真金白银地烧钱：每一次重试都会拉长上下文窗口，Token 消耗量和 API 账单呈倍数级暴涨；重试次数越多，端到端延迟越高，用户等待时间成倍增加。这在本地测试看似无伤大雅，但在生产环境高并发下，不仅会导致成本失控，更是严重的性能瓶颈。因此，设计 Loop 的重中之重是设立三条明确的红线停止规则： - **预算上限**：必须给单次任务设定死底线，限制最多重试调用次数以及消耗 Token 的最大额度。 - **终止规则**：除了任务验证成功自然退出外，若遭遇连续失败（例如连续报错 3 次），必须直接强制掐断并抛出异常，绝不容许无限重试。 - **人工介入（Human-in-the-Loop）**：一旦流程涉及到资金转账、敏感邮件发送、核心数据修改等高危操作，在执行前必须强制挂起，等待真人确认授权后方可继续。

---

[05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) Graph 层：复杂业务的骨架与三层联动心法

当业务逻辑变得极其复杂时，单靠对话或单个 Loop 已经无法承载，必须使用 Graph。Graph 能将复杂的端到端业务拆解为清晰、可控、随时可恢复的协作网络，其核心要素包括**节点（Node）**、**流转条件（Edge/Condition）**以及**状态检查点（Checkpoint）**。检查点机制类似于单机游戏中的“存档”：一旦中间某个环节因为偶发网络抖动或环境异常崩盘，系统可以直接读档恢复，从断点处继续执行，而不需要从第一步把整个长流程推倒重来。

以撰写行业研报为例，如果把所有要求打包扔给模型一次性吐出，模型大概率顾此失彼： - 通过 Graph 拆解，明确需求后拉出三个并行分支：分支 A 抓取市场公开数据，分支 B 解析技术文档，分支 C 整理竞品实际案例； - 三路任务并发推进，收集完成后汇总至聚合节点清洗与去重； - 最终基于整合信息生成完整研报，并流入人工审核节点。

在设计 Graph 时，开发者最容易犯的错误是“过度设计”，将节点拆得过碎。在业务逻辑还没完全跑通、边界尚不清晰时，就绘制了一张密密麻麻、布满条件分支的复杂巨型网络。这样做的后果是业务需求只要发生哪怕一点点微调，整张图都要伤筋动骨地重构。**真正健康的 Graph 应当只固化那些必须严格把控的关键卡点与业务边界，剩下的灵活发散与逻辑判断，大胆放权交给模型去动态处理。**

```mermaid flowchart LR accTitle: Three-layer Agent Architecture accDescr: Layered structure of Harness, Graph, and Loop showing how they nest together. subgraph Layer1["Harness (底座地基)"] H["环境沙箱 / 鉴权安全 / 工具集 / 状态存储"] end

subgraph Layer2["Graph (任务骨架)"] G1["节点 A"] --> G2["节点 B (分支/聚合)"] G2 --> G3["检查点存档 / 节点 C"] end

subgraph Layer3["Loop (局部肌肉)"] L["节点内部：状态 -> 决策 -> 执行 -> 验证闭环"] end

H -.->|"提供安全运行环境"| G1 H -.->|"提供工具与鉴权"| L G2 ---|"每个节点内嵌独立"| L ```

Harness、Loop、Graph 三者绝非平行的独立组件，而是深度嵌套的有机整体： - **Harness 是地基**：构筑在最底层，提供安全合规的沙箱、受控的工具集和运行状态； - **Graph 是骨架**：搭建在地基之上，负责全局任务的拓扑调度与分支流转； - **Loop 是肌肉**：嵌在骨架的每一个具体节点内部。某个节点内出现微小错误，直接在节点内部通过 Loop 的闭环与重试机制予以纠偏，绝不波及或打乱整个大流程的走向。

对于未涉足的新业务开发，建议严格遵循三步走落地策略： 1. **构建极简 MVP**：挑选最基础的工具，配置一个简单的 Loop，验证业务在逻辑上是否跑得通。 2. **分析沉淀轨迹**：把跑通的完整链路轨迹落盘保存，深入观察并提炼其中重复出现的流转规律与共性路径。 3. **沉淀 Graph 节点**：等业务模式与调用流程彻底稳定后，再将这些规律固化提升为正式的 Graph 节点，切忌一开始就空想架构、画超大复杂的图。

最后，牢记这套排障口诀，线上定位故障一目了然： - **遇到拿不到数据、接口抛错**：第一时间排查 **Harness** 的鉴权配置、执行环境与参数格式； - **遇到输出格式混乱、疯狂重试**：立刻去查 **Loop** 的客观验证规则与终止红线； - **遇到流程直接卡死、状态断档对不上号**：直接定位 **Graph** 的分支条件、流转逻辑与检查点。

## Notable quotes > [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) 一个能打的 Agent = 大模型 + 工程系统 — AI大模型-阿水

> [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) 大模型只决定了能力的上限，真正决定它能不能在线上稳定干活的，是底层的工程底座 — AI大模型-阿水

> [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) Harness：负责运行环境与边界，解决“这活到底具备不具备条件干”的问题 — AI大模型-阿水

> [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) Loop：负责反馈和证据验证，解决“这活到底干没干对”的问题 — AI大模型-阿水

> [00:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=0s) Graph：负责整体的协作与流转编排，解决“复杂流程怎么稳住”的问题 — AI大模型-阿水

> [01:52](https://www.bilibili.com/video/BV15qpj6aEwY?t=112s) Harness 的核心原则是少而准 — AI大模型-阿水

> [03:47](https://www.bilibili.com/video/BV15qpj6aEwY?t=227s) 这就像比赛中运动员自己给自己当裁判宣布跑了第一名，成绩毫无可信度。模型说“做完了”不能算数，必须出具客观证据 — AI大模型-阿水

> [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) 真正健康的 Graph 应当只固化那些必须严格把控的关键卡点与业务边界，剩下的灵活发散与逻辑判断，大胆放权交给模型去动态处理 — AI大模型-阿水

> [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) 遇到拿不到数据、接口抛错：第一时间排查 Harness 的鉴权配置、执行环境与参数格式 — AI大模型-阿水

> [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) 遇到输出格式混乱、疯狂重试：立刻去查 Loop 的客观验证规则与终止红线 — AI大模型-阿水

> [05:00](https://www.bilibili.com/video/BV15qpj6aEwY?t=300s) 遇到流程直接卡死、状态断档对不上号：直接定位 Graph 的分支条件、流转逻辑与检查点 — AI大模型-阿水

## Mentioned AI大模型-阿水, Agent, Harness, Loop, Graph, Python, Human-in-the-Loop, MVP

## Video description 视频Agent学习籽料、大模型学习路线、、实战案例集、电子书+问题解答👉https://www.bilibili.com/read/cv52978347/?spm_id_from=333.1387.0.0&jump_opus=1自取哦

[Source](https://www.bilibili.com/video/BV15qpj6aEwY)

中文简报

Agent上线频发报错？别怪大模型，关键在三层架构 视频针对许多开发者面临的“Agent 本地运行流畅、一上线生产环境就频繁报错”这一痛点，指出核心症结并非大模型智商或提示词，而在于工程底座的缺失。作者提出了“能打的 Agent = 大模型 + 工程系统”的核心公式，并将系统解构为三层架构：充当运行沙箱与安全工具底座的 Harness、负责证据验证与熔断控制的 Loop，以及承载复杂业务骨架与断点恢复的 Graph。最后，视频总结了三层联动的排障口诀与从极简 MVP 到固化图节点的演进方法，帮助开发者在线上快速定位并解决稳定性问题。 生产环境中 Agent 频发报错的根基并非模型智商不足或提示词未写好，而是工程系统缺失；高可用 Agent 的核心公式为“大模型 + 工程系统”，需通过三层工程底座来保障稳定性。 (0:00) Harness 层作为底层工作台与安全防护网，必须具备隔离沙箱、权限控制与轨迹审计日志，且工具设计应遵循“少而准”原则，故障排查须优先检查接口入参及鉴权配置。 (1:52) Loop 层旨在打造涵盖客观证据验证的闭环，严禁轻信模型的单方完工声明，同时必须通过设置预算上限、连败熔断以及人机协同（HITL）机制防止无限重试引发的成本失控。 (3:47) Graph 层通过状态检查点（Checkpoint）实现长流程断点续跑与任务并发调度；三层架构呈有机嵌套结构：Harness 为地基，Graph 为骨架，Loop 则是内嵌于各节点内部的执行肌肉。 (5:00)

Reading summary

AI大模型-阿水指出，Agent在生产环境中频繁报错通常并非由于模型理解能力不足或提示词未写好，而是工程系统配套缺失所致。作者提出“能打的 Agent = 大模型 + 工程系统”，并主张将底层工程系统拆分为 Harness（运行底座）、Loop（控制闭环）和 Graph（编排网络）三层架构以实现精确排障与稳定运行。 认知重塑：模型决定上限而工程底座决定稳定 (0:00) 很多开发者在本地测试时环境单一、输入理想，Agent表现优异；一旦推向线上生产环境，便接连出现接口超时、上下文断档和逻辑死循环等问题。作者指出，将故障简单归咎于大模型智商不足或死磕提示词工程往往无济于事，因为大模型本质上只是一个决策大脑，缺乏工程配套设施便无法在现实业务中施展拳脚。 底座三层架构的核心分工在于：Harness 负责解决“是否具备条件干活”的运行环境与安全边界；Loop 负责解决“活有没有干对”的反馈与证据验证；Graph 则负责解决“复杂长流程如何稳住”的拓扑流转编排。清晰的分层规范使得线上排障能够精准定向，避免单脚本包揽导致的定位困境。 Harness层：构建安全工作台与精简工具边界 (1:52) Harness 作为运行底座与防护网，标配四大核心组件：隔离的执行沙箱以防误操作真实生产环境、严格的权限安全控制、整洁实用的工具集，以及时刻同步任务进度的上下文与状态管理。针对工具调用，作者强调系统必须在调用前鉴权，执行完毕后将调用轨迹全链路落盘记录，杜绝出现事故后无法审计追溯的情况。 在工具设计上应遵循“少而准”的原则。盲目塞入几十个同质化工具或冗长资料，不仅会导致模型检索效率极低，还会直接将关键上下文挤出窗口。当工具调用出现报错时，排查的黄金顺序应当自外向内收敛：依次检查接口入参格式、系统网络鉴权、上下文冲突，排除掉所有确定性的工程因素后，最后再去调整提示词或怀疑模型能力。 Loop层：确立客观证据闭环与三重熔断红线 (3:47) Loop 层的核心使命是打造严格的“证据闭环”，而非让模型无脑盲目重试。在常规的“状态读取—决策行动—工具调用”流程之外，关键在于补充常被遗漏的“客观验证（Verification）”环节。系统不能轻信大模型自称的“任务已完成”，必须检验客观证据，例如底层接口是否返回成功状态码、测试用例是否全绿跑通以及输出数据格式是否匹配。 同时，工程设计必须严控重试带来的 Token 暴涨和响应延迟。系统需确立三条明确的红线规则：一是设定调用次数上限与最大 Token 额度作为预算底线；二是设立终止规则，遭遇连续失败（例如连续报错 3 次）时强制掐断抛错，禁止无限死循环；三是引入人工介入（Human-in-the-Loop），一旦涉及资金转账、敏感外发或核心数据变动等高危操作，必须强制挂起等待真人授权。 Graph层：长流程调度骨架与三层嵌套联动 (5:00) 当业务链路过长且复杂度攀升时，需借助由节点（Node）、流转条件（Edge）及状态检查点（Checkpoint）组成的 Graph 架构进行拓扑拆解。状态检查点机制相当于单机游戏的“存档”，在遭遇网络抖动或环境异常崩盘时支持断点读档续跑，无需从头重来。以行业研报为例，可通过并行分支分别抓取数据、解析文档和整理竞品案例，再经聚合节点清洗整合后流入人工审核。 在设计 Graph 时须警惕节点拆分过细的“过度设计”，Graph 应仅用于固化关键卡点与业务边界，具体逻辑应放权交由模型动态处理。三层架构本质上是深度嵌套的有机体：Harness 为地基，Graph 为骨架，Loop 则是嵌在各个节点内部的肌肉，各节点内的细微错误通过局部 Loop 闭环自我纠偏，从而避免全局流程溃散。 作者总结了线上故障排查口诀：接口调用报错查 Harness 的鉴权与配置，格式混乱与死循环查 Loop 的验证与红线，流程卡死查 Graph 的分支条件与检查点。针对新业务落地，建议避免一开始就设计庞大复杂的图，应遵循“构建极简 MVP 验证逻辑、沉淀分析真实运行轨迹、提炼规律固化为 Graph 节点”的三步走演进路径。

Source quotes

[0:00] AI大模型-阿水: 一个能打的 Agent = 大模型 + 工程系统 [0:00] AI大模型-阿水: 大模型只决定了能力的上限，真正决定它能不能在线上稳定干活的，是底层的工程底座 [0:00] AI大模型-阿水: Harness：负责运行环境与边界，解决“这活到底具备不具备条件干”的问题 [0:00] AI大模型-阿水: Loop：负责反馈和证据验证，解决“这活到底干没干对”的问题 [0:00] AI大模型-阿水: Graph：负责整体的协作与流转编排，解决“复杂流程怎么稳住”的问题 [1:52] AI大模型-阿水: Harness 的核心原则是少而准 [3:47] AI大模型-阿水: 这就像比赛中运动员自己给自己当裁判宣布跑了第一名，成绩毫无可信度。模型说“做完了”不能算数，必须出具客观证据 [5:00] AI大模型-阿水: 真正健康的 Graph 应当只固化那些必须严格把控的关键卡点与业务边界，剩下的灵活发散与逻辑判断，大胆放权交给模型去动态处理 [5:00] AI大模型-阿水: 遇到拿不到数据、接口抛错：第一时间排查 Harness 的鉴权配置、执行环境与参数格式 [5:00] AI大模型-阿水: 遇到输出格式混乱、疯狂重试：立刻去查 Loop 的客观验证规则与终止红线 [5:00] AI大模型-阿水: 遇到流程直接卡死、状态断档对不上号：直接定位 Graph 的分支条件、流转逻辑与检查点

Original transcript

[0:00] 为什么你的agent在本地像个天才一上线就疯狂报错别总想着去换更聪明的大模型了真正决定它能不能稳定落地的是三个底层的工程架构Harness、Loop、还有Graph作业开发的这几个词你平时肯定没少听但只要落到具体项目里谁负责兜底谁负责扭转很多人脑子里其实是一团浆糊的今天咱们就花点时间把这三层关系给你彻底打通听完你就会颠覆认知一个真正能干活的agent靠的根本不是模型智商我整理了一份大模型和agent系统学习路线只要是我粉丝留下666打包带走咱们先复盘一下问题到底出在哪儿你在自己电脑上跑测试数据是为好的流程是单线的基本不怎么报错看着特别丝滑但一推到生产环境,接口动不动超时上下文突然断档,甚至陷入死循环出不来这时候你去看后台日志肯定是一眼黑其实这些坑一直都在只是本地的简单环境没把它们暴露出来罢了很多人一碰到信上出bug 第一反应就是 哎呀是不是这个模型理解力不行赶紧切个禅数更大的要不就是觉得提示词写的不够好天天在那死刻prompt大家想想你改了半天该调不通的接口还是报错该丢的状态照样丢为啥因为模型说白了只是个大脑大脑再好使它也得有个能视掌拳脚的躯干和环境,对吧?举个最实在的例子假设你公司花重金,挖了一个顶尖名校的高材生脑子非常够用,教他啥秒懂但是你让他坐在空桌子前,不发电脑,不给开内网权限也不告诉他公司的报销审批流程你觉得他能产出什么业绩,他只能干瞪眼这时候你会觉得是他智商不够吗肯定是公司给的配套设施没跟上做Agent其实是一模一样的逻辑所以大家一定要记住一个核心公式一个能打的agent等于大模型加上工程系统大模型决定了能力的上限但真正决定它能不能在线上稳定干活的是这个工程底座为了方便大家理解我把这个底座拆解成了三个模块也就是咱们今天要重点拆解的Harness、Loop和Graph可能有朋友会问,搞这么复杂干嘛?我写个几千行的python脚本,全包园不行吗?分成的最大好处就是出了事你的迅速定位你想如果是调外部API失败了,咱们就去查全新配置如果是输出的结果总是不对,咱们就去查验证逻辑如果是整个任务流卡死了咱们继续查节点流转有了这三种划分排查现象故障就有了明确的方向这个是能保命的咱们先给这三兄弟订个调Anis他负责的是运行环境和边界解决的是这活到底具备不具备条件干的问题洛普负责的是反馈和验证,他要确认的是这活到底干没干对最后的Graph管的是整体的协作编排解决的是复杂流程怎么稳住的问题你现在这个大框架,咱们再组个击破听说Hannis你可以把它当成给模型量身定制的工作台外加一道防护网这个工作台标配四样东西第一是执行杀箱 跑代码得一个安全区 别把祖库给删了第二是安全控制 全线必须卡死 越拳操作直接拦截第三是工具集给模型配色好用的API当手脚第四是上下文和状态管理得让他知道自己现在干到哪一步了这里特别容易踩坑给模型配工具绝不是说接口能调通就万事大吉了你得做到全程可控 有机可循 模型想调工具得先验证身份和权限,没问题了,再放进上下里跑跑完之后所有的这些轨迹必须落盘记录你想想,要是线上出了严重的bug你连当时他干了啥的记录都没有你拿什么去排查顺带说个很多人常犯的毛病总觉得给agent塞的工具越多越好背景资料越全越好其实大错特错你搞几十个名字差不多的工具扔进去模型直接就蒙圈了这就好比让一个人在堆满杂物的仓库里找一把特定的扳手效率能高吗技艺也是同理 商业对没用的废话反而会把真正关键的信息给挤走Hallis的核心原则是扫而准 扫而准那万一工具雕用怎么报错了怎么查,千万别一上来就去改提示词或者换模型一定要从最外围开始排查先看接口参数对不对,再看权限,是不是没给够接着查上下文理,是不是有冲突信息把这些确定的工程因素都排除了最后再去怀疑模型的能力按照这个顺序查能帮你省掉一大半的无用功搞定了Hannis 咱们往上走一层聊聊路普Loop的核心使命是确保每一步都有回音并且知道什么时候该踩刹车大家千万别误会Loop可不是让模型在那无限循环重视他的精髓在于打造一个证据闭环读取状态决定怎么做调用工具执行这三部大家都会写但最关键的第四步 验证却经常被漏掉为啥验证这么关键?如果你不加验证,模型自己回一局任务搞定了系统就傻乎乎的相信了,直接进入下一步这就好比一场比赛运动员自己给自己当裁判说我跑了第一 这成绩能做数吗?所以摩西说做完了不算必须得有客观证据,比如接口,是不是真返回成功了?测试用力跑通没数据格式对不对得上但咱们也得算算经济账,路不循环可是要烧钱的模型每重试一次,上下文就会变得更长消耗的token和API调用费都在成倍增加而且从事 [5:00] 用户等的时间就越长在本地测的时候你觉得无所谓一旦上了生产环境,遇到高并发,这不仅是成本问题,更是严重的性能瓶颈因此设计路普的重中之重是给它设定明确的停止条件这里有三条红线一时预算上限最多允许挑几次花多少Token必须有个底线二是宗旨规则成功的自然退出但如果连续失败三次必须强制掐断绝不能死循环当时人工介入,只要涉及到转账,发邮件这种敏感操作执行前必须让真人来确认最后,咱们来啃最硬的骨头,Graph当你的业务流程变得极其复杂时Graph能把它拆解成清晰的、可控的、能随时恢复的协作网它主要由节点、流转条件和状态检查点构成这个检查点特别好用就跟咱们玩单机游戏存档一样万一中间哪个环节崩了直接独挡重来就行不用从第一步重新跑举个小行业研报的例子明确叙迟后咱们把任务拆开,分之A去收集市场数据,分之B去扒技术文档,分之C去整理竞品案例这三路同时开干拿回结果后再做个汇总去从最后生成报告让人工审核这么复杂的活你想靠一次对话让模型全干完根本不可能,但用graph拆解开,每一步就变得非常清晰好管了不过用graph很容易犯一个铜病,就是把节点切得太碎了业务逻辑还没完全跑通就换了一张密密麻麻全市条件分支的剧情之中网只要需求稍微变一点,整张图都得重构简直是给自己挖坑真正健康的挂妇只顾换那些必须严格把控的关键节点剩下的那些灵活判断大胆放全交给模型自己去处理那这三层到底是怎么联动起来的呢?大家记住,他们绝对不是平行的,而是互相嵌套的Hannis是最底层的地基提供安全的环境Graph是搭载地基上的股价负责全局的任务调度而路普就是长在骨架上的肌肉它运行在每一个具体的节点里面某个节点出错了就在节点内部用loop去纠正完全不需要整个大流程推导重来如果在实际开发中遇到没做过的新任务我强烈建议大家分三步走第一步 先用最基础的工具配个简单的loop跑个MVP出来看看这事到底行不行第二步 把跑通的轨迹存下来广场里面有哪些重复的规律第三步,等牛层彻底稳定了,再把这些规律停定成Graph节点千万别一上来就别大招画大土最后给大家送上一个超实用的排斗口诀遇到拿不到数据 结果报错 马上去查Hannis的权限和环境遇到俗俗乱七八糟疯狂从事,赶紧去查路普的验证规则和退出条件遇到流程卡死,任务对不上号直接去查Graph的分支逻辑只要把这三层吃透了,环境稳,能验证流程控得住你的Agent才能真正扛得住线上的毒打