企业官网建设流程全解析

s前言

Harness 决定模型在什么环境中工作，Loop 决定它如何根据反馈持续改进，Graph 决定任务接下来可以流向哪里。最简单的记忆方式是：环境、反馈、流程。

Agent Harness Engineering、Loop Engineering 和 Graph Engineering 经常出现在同一场讨论中。

它们都围绕大模型构建，都可能包含工具调用、状态管理与循环，因此很容易被当成三个近义词。

但当 Agent 离开演示页面，开始读写文件、调用 API、联系客户或修改生产代码时，这种混淆就会导致错误的架构决策。

三者解决的是不同问题：

Harness：模型凭什么完成工作？Loop：结果不合格后，系统如何继续？Graph：当前状态下，哪个组件可以接着运行？

更直观地说：

Harness = 工作环境Loop = 反馈机制Graph = 流程拓扑

它们相互嵌套，却不能彼此替代。🧭

一、为什么现在必须区分这三层？

一个原始语言模型本身不能稳定完成以下工作：

跨会话保存项目状态；访问文件、数据库和浏览器；调用 Shell 与外部 API；运行测试并读取结果；控制权限、成本与执行时间；在任务失败后恢复；等待人工审批；记录完整执行轨迹。

这些能力并不来自模型参数，而来自模型外部的工程系统。

随着 Agent 开始承担长期任务，一套相对清晰的结构逐渐形成：

Harness 提供上下文、工具、状态和权限Loop 负责执行、检查、反馈和有限重试Graph 组织多步骤、多角色和多分支流程

实际系统中，Graph 由 Harness 执行，其中部分节点包含 Loop；Harness 则持续为两者提供工具、状态和安全边界。

区分三层的目的不是创造术语，而是让系统出错时，能够修改真正拥有问题的那一层。🧩

二、Harness Engineering：为模型建设工作环境

Agent Harness 是包裹在模型外部的运行系统。

Agent 不只是一个模型：

Agent= 模型+ 上下文+ 工具+ 状态+ 执行控制+ 权限+ 可观测性

两个团队即使采用同一款基础模型，也可能得到完全不同的结果。

一方提供结构清晰的工具、稳定的工作区、最小权限和可恢复状态；另一方只有模糊提示词与不稳定的 API。模型能力可能接近，工作条件却完全不同。

当 Agent 出现以下问题时，应优先检查 Harness：

无法安全访问必要数据；工具参数模糊，频繁调用错误；新会话开始后忘记进度；拥有超出任务需要的权限；环境变化后行为不一致；任务中断后无法恢复；无法追踪它执行过什么。

长期编码任务尤其依赖 Harness。仅扩大上下文通常不够，还需要初始化说明、进度文件、Git 历史和检查点，让新的上下文知道已经完成什么、接下来要做什么。

Harness Engineering 关注的不是让模型想得更聪明，而是让它在稳定、受控、可恢复的环境中工作。🏗️

三、Loop Engineering：设计可验证的反馈循环

几乎所有能够调用工具的 Agent，内部都有一个基础循环：

调用模型→ 选择动作→ 执行工具→ 返回结果→ 继续或结束

Loop Engineering 不只是写一个 while 循环，而是有意识地设计执行后的反馈机制。

常见循环包括：

• 验证循环：生成结果、运行测试、根据错误修复；

• 事件循环：收到定时任务、Webhook 或新文件后启动；

• 改进循环：分析失败，调整指令或工具，再运行回归测试；

• 审批循环：准备方案，等待人类反馈后继续；

• 恢复循环：失败后根据错误类型重试、降级或升级。

一个完整 Loop 至少要回答七个问题：

最重要的原则是：

不要围绕信心循环，要围绕证据循环。

Prompt 规定模型在一次调用中应该做什么；Loop 则规定回答之后，系统如何观察结果、生成反馈、决定继续还是停止。

每轮重试都会增加成本和延迟。只有当失败成本高于验证成本时，增加 Loop 才值得。

好的 Loop 不是让 Agent 一直尝试，而是让每一轮获得新证据，并在明确边界内接近终点。🔄

四、Graph Engineering：让执行路径显式可控

Graph Engineering 关注的是：

当前节点完成后，哪些组件可以继续运行？

图中的节点可以是：

普通代码函数；一次模型调用；专业 Agent；确定性验证器；人工审批步骤；外部服务请求。

边则表示允许发生的状态转移，

Graph 可以表达顺序、条件分支、并行分发、多路汇合、有限循环、人工中断和异常恢复。

设计 Graph 时，需要确定六件事：

节点边界：哪些任务交给代码、模型、专业 Agent 或人类？状态结构：每个节点可以读取和修改什么？路由条件：哪些证据让任务前进、返回或升级？并发关系：哪些任务可以并行，哪些资源不能同时修改？循环出口：最多重试几次，什么情况必须停止？持久恢复：在哪些节点保存检查点，中断后从哪里继续？

Graph 的价值，是把原本隐藏在临时代码和对话中的分支、并行、审批与恢复路径，变成可以检查的系统结构。

Graph Engineering 管理的不是模型如何思考，而是系统允许工作向哪里流动。🕸️

五、三层如何组成一个真实系统？

假设要构建一个“研究并发布行业简报”的 Agent。

Harness 提供能力：

搜索和浏览工具；文件工作区；来源数据库；凭据代理；权限控制；运行日志；成本和超时限制；人工审批接口。

Graph 定义流程：

接收主题↓并行研究↓汇总去重↓事实验证├── 通过 → 撰写简报├── 失败 → 返回研究└── 冲突 → 人工复核↓发布审批

Loop 改进节点结果：

研究节点可能反复检索，直到获得足够来源；写作节点可能生成草稿、运行事实检查、接收反馈并有限修订；发布节点则等待人工批准。

三层的嵌套关系可以概括为：

Harness 承载运行环境└── Graph 组织任务路径└── Loop 在部分节点内反复改进

Harness 让系统能够工作，Loop 让结果能够改进，Graph 让复杂流程能够被控制。⚙️

六、五种常见的昂贵错误

1. 不了解工作就先画巨型 Graph

先使用简单 Harness 收集真实运行轨迹，识别稳定路径后，再将其固化为 Graph。

2. 让同一个模型既写又评

优先使用确定性测试。需要模型评审时，应使用独立上下文；高影响操作仍需人工批准。

3. 把“继续尝试”当作 Loop

无限重试只是费用泄漏。每个循环都需要目标、证据、最大次数、预算和升级路径。

4. 把 Harness 变成工具垃圾场

工具过多会增加选择错误，噪声记忆会干扰判断，宽泛权限会扩大事故范围。

5. 用 Graph 掩盖 Harness 缺陷

流程图无法修复陈旧数据、不可靠工具和缺少权限控制的问题。Graph 只能安排路径，不能替代底层运行质量。

架构复杂度应该来自已经观察到的真实需求，而不是来自对“高级 Agent”的想象。🚧

七、最合理的建设顺序

生产系统可以按照以下顺序演进：

• 第一步：建立可靠 Harness

• 第二步：为高价值失败增加 Loop

• 第三步：将稳定的复杂路径固化为 Graph

优先建设 Harness，解决工具、状态、权限、恢复和可观测性。

当单次结果经常接近正确，却需要测试和修订才能稳定交付时，再增加 Loop。

只有任务出现明确分支、并行工作、多个专家、人工审批和恢复路径时，才值得引入 Graph。

上线前至少检查：

工具是否职责单一、参数明确？状态能否跨会话保存？权限是否遵循最小化原则？什么证据能够证明成功？最多重试多少次？哪些任务可以并行？哪些资源不能并发修改？人工审批位于哪里？是否监控成本、延迟、失败率和人工介入率？

最成熟的架构，不是三层都做到最复杂，而是每一层只承担它真正需要解决的问题。✅

结语：环境、反馈、流程

记住三者的最简单方式：

Harness Engineering：建设工作环境，给模型能力和边界Loop Engineering：设计反馈循环，给执行过程反馈和终点Graph Engineering：控制执行流程，给复杂任务清晰、可检查的路径

它们不能互相替代。

没有持久状态和安全工具，再漂亮的 Graph 也无法稳定运行；没有外部证据与停止规则，再好的 Harness 也可能让 Agent 不断消耗预算；当分支、并行和审批藏在临时代码里时，再精心设计的 Loop 也会难以调试。

下一次 Agent 出现故障时，不要先问“是不是模型不够强”。

先问三个更准确的问题：

它缺少正确的工作环境吗？
它缺少基于证据的反馈循环吗？
它的执行路径是否需要显式控制？

找到拥有问题的那一层，才是 Agent 工程真正开始的地方。🚀