2026/8/14 15:58:47
FEATURED · 精选文章 
同一个模型、同一组资料、同一个任务为什么会得到三种完全不同的结果让模型一次性写一篇技术文章通常能得到一段流畅的文字却不一定有完整证据。给它增加工具调用和多轮反馈文章可以继续修订但研究、写作、审批、发布可能全挤在一个越来越长的循环里。再把任务画成一张流程图阶段边界清楚了系统却可能没有权限、状态和恢复机制重启后甚至不知道文章是否已经发布。问题不在于模型突然变聪明或变笨而在于模型被放进了什么样的执行系统。判断清楚执行系统的职责边界才能定位 Agent 失控时究竟该补验证循环、阶段拓扑还是权限、状态与恢复机制。一次回答不等于一次可靠执行把“写一篇带引用的技术文章”交给一次模型调用最短路径大致是用户任务 → 模型请求 → 文章草稿这条路径很适合验证模型能不能写字却没有回答几个工程问题引用是否真的存在不同来源是否互相矛盾草稿被修改后原来的证据还能不能追溯编辑拒绝后系统从哪里继续发布动作重复执行会不会造成副作用一次生成把所有问题都压缩成一个最终字符串。字符串可以很漂亮但它没有自动携带完成证据。给模型增加多轮工具调用后路径变成请求模型 → 工具调用 → 工具结果 → 再次请求模型 → 再次行动这已经是一个 Loop模型不再只返回文本而是根据环境反馈继续推进。但它仍然只擅长描述“这一阶段下一步做什么”。当任务变成“先研究再核验再写作等待编辑审批最后发布”阶段之间的依赖、人工决策和发布副作用就需要另一种结构来表达。Harness、Loop Engineering 和 Graph Engineering 在这套职责模型中分别表示运行边界、阶段内闭环和阶段间拓扑。它们不是三个同层产品也不是行业唯一的术语体系。三个词不是三个框架Harness 是系统职责的集合。它把模型放进一个有边界的环境里模型可以看到什么可以调用什么调用结果如何回传任务状态如何保存哪些动作需要确认最终结果凭什么被接受。Loop Engineering 关注时间维度处理阶段内部的行动、观察、验证、修复和停止Graph Engineering 关注拓扑维度把研究、核验、写作、审批和发布组织成带契约的节点与边。可以先用一句话记住三者Harness 管边界Loop 管一段路Graph 管路口。Anthropic 在《Building effective agents》中把 workflow 描述为由预定义代码路径编排模型和工具把 agent 描述为由模型动态决定过程和工具使用的系统同时建议只有在简单方案不够用时才增加复杂度。这个区分很重要Graph 可以声明阶段边界Loop 可以允许阶段内动态行动但二者都不能跳过运行边界。Harness让模型可以行动但不能越过边界模型输出的是意图不是天然合法的环境动作。例如模型提出“发布文章”的工具调用Harness 至少要回答当前身份是否拥有发布权限文章是否通过了必需的证据检查这个发布请求是否已经执行过外部接口超时后重试会不会造成重复发布这次动作是否需要人工确认OpenAI 的 Function Calling 文档把工具调用描述成一个多步应用流程应用把工具定义发给模型接收工具调用在应用侧执行函数再把工具输出发回模型模型可能给出最终响应也可能继续提出工具调用。这个协议说明了“模型如何请求行动”却没有替应用决定授权、幂等、业务验收和发布责任。所以 Harness 的价值不是替模型思考而是把模型能力放入控制流、数据流和权限边界中。它通常包含模型与协议适配层。当前轮次的上下文构建。工具注册、参数校验和结果标准化。权限、沙箱、人工确认和风险拦截。运行状态、轨迹、检查点、终止原因和评测证据。Harness 也不应被夸大成“正确性机器”。它能阻止未授权动作能保存执行证据能把结果送入验证器但它不能凭空证明一篇文章的事实一定正确。Loop Engineering阶段内如何持续推进一个可靠 Loop 不只是一个 while True而是一组有输入、有观察、有出口的状态转移请求模型 ↓ 解析行动意图 ↓ 执行工具或产生中间产物 ↓ 获得环境观察 ↓ 外部验证 ├─ accepted → 完成 ├─ repairable → 修复后继续 ├─ needs_human_input → 人工补充或决策 └─ blocked → 带原因终止行动之后必须产生可用观察验证之后才能决定下一步。模型说“我完成了”只是候选信号链接可访问、字段符合 Schema、测试通过或证据无明显冲突也只是候选验收信号。具体任务必须预先定义完成条件任何单项检查通过都不能单独证明事实正确或业务目标已经完成。Loop 也要区分失败和重试。普通校验错误适合回流为下一轮观察协议解析失败、权限拒绝或副作用状态不明则可能应该终止或请求人工处理。无限重试不是恢复策略只是把责任推迟到预算耗尽。Graph Engineering阶段之间如何路由当任务包含多个阶段时最重要的不是把循环写得更长而是把阶段边界写出来。文章生产任务可以拆成研究 → 证据核验 → 写作 → 编辑审批 → 发布如果证据核验失败可能回到研究如果编辑拒绝草稿可能回到写作如果发布接口超时不能简单回到发布节点重试因为第一次请求可能已经产生了外部副作用。Graph Engineering 的最小对象是节点、边和状态检查点、人工门与补偿则把它从可画出的流程提升为可恢复的执行拓扑。节点有输入输出契约边声明允许的转移状态保存跨节点继续和解释任务所需的结构化事实。Graph 不是一张流程图图片。只有当节点能够执行、状态能够持久化、边能够路由、轨迹能够审计它才是工程上的执行拓扑。LangGraph 官方文档把自己定位为面向长时间运行、有状态 Agent 的低层编排运行时强调把确定性步骤和模型驱动步骤放在同一张图里并提供持久化、人工介入和执行可观测性。这可以作为 Graph Engineering 的一个框架实例但不能反过来把某个框架 API 当成 Graph Engineering 的定义。图负责去哪儿Loop 负责怎么走Graph 和 Loop 最容易被混淆是因为它们都可能出现“下一步”。区别在于下一步的范围不同。在文章生产任务中Graph Runtime 可以声明 Research、Verification、Draft、Human Gate 和 Publish 等节点研究、核验和写作节点内部仍可运行各自的受控 Loop发布节点则由幂等键与副作用保护约束。在 Research Node 内模型可以决定先搜索哪个关键词、是否补充一个来源但它不能自行创建一个未声明的发布节点也不能绕过人工门直接执行发布。Graph 声明允许的拓扑Loop 在节点边界内提供受控动态。这也是“完全自治”和“固定脚本”之间的中间地带路径不是每一步都写死但可走的节点、工具、预算和治理边界必须明确。同一个任务三种控制语义三种方式的差异不在输出质量排名而在系统能够留下什么控制事实执行方式新增的控制事实仍未解决的问题一次生成记录请求与最终返回缺少外部观察、修复路径和完成证据阶段内 Loop增加行动、观察、验收、修复和阻断跨阶段依赖、人工门和副作用路由仍不清晰阶段间 Graph增加节点契约、条件路由、人工门和阶段状态权限、工具、持久化、审计和恢复仍需 Harness 承担责任逐步显式化不等于方案必须逐级叠加。一次性任务可能只需要基础模型调用有反馈修复需求时补 Loop出现跨阶段依赖时补 Graph无论采用哪种控制结构真实行动都必须受到 Harness 的运行边界约束。什么时候应该增加哪一层工程常见故障或任务特征优先补哪一层首先回答的问题只需要一次性生成文本基础模型调用输出是否满足基本格式工具有反馈但修复、验证和停止条件不清Loop Engineering观察是什么何时验证何时停止研究、审批和发布全挤在一个长循环里Graph Engineering下一阶段允许去哪里失败如何路由权限、状态、审计和恢复责任说不清Harness谁能行动证据在哪里能否恢复多阶段任务既要动态行动又要长期治理Harness Graph 节点内 Loop如何把动态决策限制在可治理边界内一个实用判断是如果问题只发生在“当前阶段做得不够好”先补 Loop 的观察和验证如果问题发生在“阶段之间没有清晰责任”需要补 Graph如果问题是权限、状态、审计和恢复都说不清楚缺的是 Harness。小结可靠 Agent 的核心不是让模型拥有无限行动权而是把行动权放在可解释、可验证、可恢复的边界内。Harness 解决“谁能行动、看到什么、留下什么证据”。Loop Engineering 解决“这一阶段如何行动、观察、修复和停止”。Graph Engineering 解决“多个阶段如何路由、并行、审批和恢复”。模型负责提出意图工具负责产生环境观察Loop 负责阶段内推进Graph 负责阶段间拓扑Harness 负责把这些行为放进真正可运行的系统里。三者组合后Agent 才从一次看起来不错的回答变成可以被追踪和改进的执行过程。你正在构建的 Agent当前最明显的问题属于哪一类没有外部验证、循环不会停止还是阶段之间没有清晰边界学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
Agent 执行工程到底解决什么问题：Harness、Loop 与 Graph 的边界
同一个模型、同一组资料、同一个任务为什么会得到三种完全不同的结果让模型一次性写一篇技术文章通常能得到一段流畅的文字却不一定有完整证据。给它增加工具调用和多轮反馈文章可以继续修订但研究、写作、审批、发布可能全挤在一个越来越长的循环里。再把任务画成一张流程图阶段边界清楚了系统却可能没有权限、状态和恢复机制重启后甚至不知道文章是否已经发布。问题不在于模型突然变聪明或变笨而在于模型被放进了什么样的执行系统。判断清楚执行系统的职责边界才能定位 Agent 失控时究竟该补验证循环、阶段拓扑还是权限、状态与恢复机制。一次回答不等于一次可靠执行把“写一篇带引用的技术文章”交给一次模型调用最短路径大致是用户任务 → 模型请求 → 文章草稿这条路径很适合验证模型能不能写字却没有回答几个工程问题引用是否真的存在不同来源是否互相矛盾草稿被修改后原来的证据还能不能追溯编辑拒绝后系统从哪里继续发布动作重复执行会不会造成副作用一次生成把所有问题都压缩成一个最终字符串。字符串可以很漂亮但它没有自动携带完成证据。给模型增加多轮工具调用后路径变成请求模型 → 工具调用 → 工具结果 → 再次请求模型 → 再次行动这已经是一个 Loop模型不再只返回文本而是根据环境反馈继续推进。但它仍然只擅长描述“这一阶段下一步做什么”。当任务变成“先研究再核验再写作等待编辑审批最后发布”阶段之间的依赖、人工决策和发布副作用就需要另一种结构来表达。Harness、Loop Engineering 和 Graph Engineering 在这套职责模型中分别表示运行边界、阶段内闭环和阶段间拓扑。它们不是三个同层产品也不是行业唯一的术语体系。三个词不是三个框架Harness 是系统职责的集合。它把模型放进一个有边界的环境里模型可以看到什么可以调用什么调用结果如何回传任务状态如何保存哪些动作需要确认最终结果凭什么被接受。Loop Engineering 关注时间维度处理阶段内部的行动、观察、验证、修复和停止Graph Engineering 关注拓扑维度把研究、核验、写作、审批和发布组织成带契约的节点与边。可以先用一句话记住三者Harness 管边界Loop 管一段路Graph 管路口。Anthropic 在《Building effective agents》中把 workflow 描述为由预定义代码路径编排模型和工具把 agent 描述为由模型动态决定过程和工具使用的系统同时建议只有在简单方案不够用时才增加复杂度。这个区分很重要Graph 可以声明阶段边界Loop 可以允许阶段内动态行动但二者都不能跳过运行边界。Harness让模型可以行动但不能越过边界模型输出的是意图不是天然合法的环境动作。例如模型提出“发布文章”的工具调用Harness 至少要回答当前身份是否拥有发布权限文章是否通过了必需的证据检查这个发布请求是否已经执行过外部接口超时后重试会不会造成重复发布这次动作是否需要人工确认OpenAI 的 Function Calling 文档把工具调用描述成一个多步应用流程应用把工具定义发给模型接收工具调用在应用侧执行函数再把工具输出发回模型模型可能给出最终响应也可能继续提出工具调用。这个协议说明了“模型如何请求行动”却没有替应用决定授权、幂等、业务验收和发布责任。所以 Harness 的价值不是替模型思考而是把模型能力放入控制流、数据流和权限边界中。它通常包含模型与协议适配层。当前轮次的上下文构建。工具注册、参数校验和结果标准化。权限、沙箱、人工确认和风险拦截。运行状态、轨迹、检查点、终止原因和评测证据。Harness 也不应被夸大成“正确性机器”。它能阻止未授权动作能保存执行证据能把结果送入验证器但它不能凭空证明一篇文章的事实一定正确。Loop Engineering阶段内如何持续推进一个可靠 Loop 不只是一个 while True而是一组有输入、有观察、有出口的状态转移请求模型 ↓ 解析行动意图 ↓ 执行工具或产生中间产物 ↓ 获得环境观察 ↓ 外部验证 ├─ accepted → 完成 ├─ repairable → 修复后继续 ├─ needs_human_input → 人工补充或决策 └─ blocked → 带原因终止行动之后必须产生可用观察验证之后才能决定下一步。模型说“我完成了”只是候选信号链接可访问、字段符合 Schema、测试通过或证据无明显冲突也只是候选验收信号。具体任务必须预先定义完成条件任何单项检查通过都不能单独证明事实正确或业务目标已经完成。Loop 也要区分失败和重试。普通校验错误适合回流为下一轮观察协议解析失败、权限拒绝或副作用状态不明则可能应该终止或请求人工处理。无限重试不是恢复策略只是把责任推迟到预算耗尽。Graph Engineering阶段之间如何路由当任务包含多个阶段时最重要的不是把循环写得更长而是把阶段边界写出来。文章生产任务可以拆成研究 → 证据核验 → 写作 → 编辑审批 → 发布如果证据核验失败可能回到研究如果编辑拒绝草稿可能回到写作如果发布接口超时不能简单回到发布节点重试因为第一次请求可能已经产生了外部副作用。Graph Engineering 的最小对象是节点、边和状态检查点、人工门与补偿则把它从可画出的流程提升为可恢复的执行拓扑。节点有输入输出契约边声明允许的转移状态保存跨节点继续和解释任务所需的结构化事实。Graph 不是一张流程图图片。只有当节点能够执行、状态能够持久化、边能够路由、轨迹能够审计它才是工程上的执行拓扑。LangGraph 官方文档把自己定位为面向长时间运行、有状态 Agent 的低层编排运行时强调把确定性步骤和模型驱动步骤放在同一张图里并提供持久化、人工介入和执行可观测性。这可以作为 Graph Engineering 的一个框架实例但不能反过来把某个框架 API 当成 Graph Engineering 的定义。图负责去哪儿Loop 负责怎么走Graph 和 Loop 最容易被混淆是因为它们都可能出现“下一步”。区别在于下一步的范围不同。在文章生产任务中Graph Runtime 可以声明 Research、Verification、Draft、Human Gate 和 Publish 等节点研究、核验和写作节点内部仍可运行各自的受控 Loop发布节点则由幂等键与副作用保护约束。在 Research Node 内模型可以决定先搜索哪个关键词、是否补充一个来源但它不能自行创建一个未声明的发布节点也不能绕过人工门直接执行发布。Graph 声明允许的拓扑Loop 在节点边界内提供受控动态。这也是“完全自治”和“固定脚本”之间的中间地带路径不是每一步都写死但可走的节点、工具、预算和治理边界必须明确。同一个任务三种控制语义三种方式的差异不在输出质量排名而在系统能够留下什么控制事实执行方式新增的控制事实仍未解决的问题一次生成记录请求与最终返回缺少外部观察、修复路径和完成证据阶段内 Loop增加行动、观察、验收、修复和阻断跨阶段依赖、人工门和副作用路由仍不清晰阶段间 Graph增加节点契约、条件路由、人工门和阶段状态权限、工具、持久化、审计和恢复仍需 Harness 承担责任逐步显式化不等于方案必须逐级叠加。一次性任务可能只需要基础模型调用有反馈修复需求时补 Loop出现跨阶段依赖时补 Graph无论采用哪种控制结构真实行动都必须受到 Harness 的运行边界约束。什么时候应该增加哪一层工程常见故障或任务特征优先补哪一层首先回答的问题只需要一次性生成文本基础模型调用输出是否满足基本格式工具有反馈但修复、验证和停止条件不清Loop Engineering观察是什么何时验证何时停止研究、审批和发布全挤在一个长循环里Graph Engineering下一阶段允许去哪里失败如何路由权限、状态、审计和恢复责任说不清Harness谁能行动证据在哪里能否恢复多阶段任务既要动态行动又要长期治理Harness Graph 节点内 Loop如何把动态决策限制在可治理边界内一个实用判断是如果问题只发生在“当前阶段做得不够好”先补 Loop 的观察和验证如果问题发生在“阶段之间没有清晰责任”需要补 Graph如果问题是权限、状态、审计和恢复都说不清楚缺的是 Harness。小结可靠 Agent 的核心不是让模型拥有无限行动权而是把行动权放在可解释、可验证、可恢复的边界内。Harness 解决“谁能行动、看到什么、留下什么证据”。Loop Engineering 解决“这一阶段如何行动、观察、修复和停止”。Graph Engineering 解决“多个阶段如何路由、并行、审批和恢复”。模型负责提出意图工具负责产生环境观察Loop 负责阶段内推进Graph 负责阶段间拓扑Harness 负责把这些行为放进真正可运行的系统里。三者组合后Agent 才从一次看起来不错的回答变成可以被追踪和改进的执行过程。你正在构建的 Agent当前最明显的问题属于哪一类没有外部验证、循环不会停止还是阶段之间没有清晰边界学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 
