这两年AI工程实践里我越来越常听到一个词被滥用Agent 工程。大家说我们在做 Agent 工程但往下问一句你具体在搭哪一层十个人能给出八个不同的东西。有人其实在画工作流有人在做模型自循环还有人写了大半年 glue code。这中间缺的不是能力是一个能把话说清楚的分类框架。我习惯把构建 Agent 系统的工程实践切成三类Graph Engineering、Loop Engineering、Harness Engineering。这三者不是互相替代的关系而是从结构到行为再到底座的三个层次。绝大多数团队卡在只会在第一层打转真正决定一个 Agent 能不能上生产的往往是第三层。今天把这三者的边界、各自难点、和怎么配合讲清楚。这个分类不是拿来当标签玩的它是一把诊断尺。下次有人跟你说我们在做 Agent 工程先别急着点头追问一句你投的是哪一层如果他在聊怎么把流程画清楚那是Graph如果他在聊模型怎么自己转、怎么退圈那是Loop如果他在聊工具怎么重试、链路怎么回放、成本怎么看住那才是Harness。一个团队如果三句话都离不开 graph 和 loop却从来没人提过工具挂了怎么办基本可以断定它离生产还差着一条护城河。反过来当你 review 一个 Agent 项目别只看它演示时多惊艳要看它的 harness 厚度——那才是它能不能活过上线第一周的证据。Graph Engineering把系统画成一张图Graph Engineering 关心的是工作怎么流动。它把 Agent 系统定义成一张有向无环图或者更一般的图节点是工具、模型调用、条件判断边是数据和控制流。LangGraph、Dify 这类框架的核心抽象就是这个。你拖几个节点、连几根线一个先检索、再生成、后审查的流程就成型了。它最大的优点是直观和确定性。结构是显式的谁能调谁一眼看清调试时可以沿着边一步步追。对于步骤明确、分支有限的任务比如根据工单分类并路由到对应队列graph 是最省力的表达。很多内部工具型 Agent用一张 graph 就够用了。你甚至可以让非工程师通过拖拽来维护流程这是 graph 独有的协作优势。但它有明显的天花板。第一真实世界的不确定性很难塞进静态的边。一个分支条件写死了模型却给出了边没覆盖的情况graph 只能靠堆更多节点和边来兜底图越画越臃肿。第二graph 描述的是意图不是运行语义。当某个节点失败了、超时了、需要重试这些事情 graph 本身不负责得靠外面再包一层。第三graph 天然鼓励把复杂留给编排而忽略了每一步执行时的工程保障。我见过最典型的图几百个节点看着壮观跑起来一遇异常就整体崩因为没人处理中间任何一步挂了怎么办。更隐蔽的是graph 越复杂越像写死的逻辑反而牺牲了模型本可以提供的弹性最后变成用大模型去硬撑一个传统工作流。所以 Graph Engineering 适合回答做什么、按什么顺序不适合回答出事了怎么办。它该是表达层而不是全部。把它当成给确定性问题一个清晰的骨架比当成万能编排器要明智得多。Loop Engineering让模型自己在环里转Loop Engineering 关心的是行为怎么迭代。它的核心是一个持续运行的循环观察observe当前状态和上一步结果推理reason下一步该做什么行动act调用工具或产出然后反思reflect结果对不对不对就再来一轮。ReAct 是这种范式最经典的骨架AutoGPT、各种 agentic 框架里那个think-act-observe的圈都属于这一类。Loop 比 graph 更贴近自主 Agent的直觉。它不预设完整路径而是给模型一个目标让它自己决定走几步、怎么走。面对开放式任务比如调研某个竞品并产出一份对比报告你没法提前画好每一步loop 才是合适的表达。模型在环里自我纠正、自我规划能处理很多 graph 写死就 cover 不到的长尾。很多让人惊艳的 demo靠的就是一个跑了很多轮的 loop。Loop 的难点恰好也在它的自由。第一循环需要退出条件否则模型会一直转token 和钱一起烧。第二每一步都要有护栏调工具带超时、带预算不能让它陷入调同一个工具一百次的死循环。第三loop 的不可解释性比 graph 强得多你只知道它转了很多轮但说不清为什么最后给了那个答案。第四多步累积的上下文会膨胀要靠压缩和摘要续命。一句话loop 给了模型自由也把失控的风险交给了你。能管好一个 loop 的前提是外面已经有足够的工程约束否则自由就是事故的同义词。我见过一个 loop 因为没设预算半夜把一个月的额度在几小时里烧光第二天账单把负责人看傻了这种故事在自主 Agent 项目里一点都不罕见。Harness Engineering被低估的底座Harness Engineering 这个词借自harness原意——给马套上挽具让它能真正拉车干活。放到 Agent 上它指围绕模型运行所需的一切外围工程设施工具接入与沙箱、状态与检查点、评估与回放、可观测与追踪、权限与人工兜底、部署与灰度。模型是那匹马harness 是让它能在真实世界里稳定拉车的整套装备。这一层最不性感却最决定生死。前面两篇我们反复聊的 runtime、生产底座本质上就是 harness。它要解决的不是怎么编排或怎么循环而是更朴素也更难的问题工具调失败了怎么重试长任务挂了怎么续跑单次成本怎么控出了事怎么回放定位敏感动作谁来拦这些问题graph 和 loop 一个都不管全在 harness 里。我观察到一个有意思的现象行业里写 graph 和 loop 的文章铺天盖地讲 harness 的却很少因为它没什么demo 效果。你没法在答辩或融资 pitch 上展示我给工具加了超时和重试但你能展示我的 Agent 自己转了八圈完成了任务。可恰恰是这个没人愿意写的层是 Agent 从 PPT 走到生产的分水岭。一个把 graph 画得再漂亮、loop 转得再花哨的 Agent只要 harness 没做上线第一天就会因为工具抖动、成本失控、出事没人知道而翻车。反过来harness 扎实的 Agent哪怕 graph 简单、loop 朴素也能稳稳跑在生产里。这就是为什么我总说Agent 的护城河不在它有多聪明在它周围的工程设施有多厚。三者怎么配合而不是选边站最常见的误区是把这三者当成哪个更好来做单选题。其实它们是分层的缺一不可只是难点分布不均。我的建议是一个三层栈用 Graph 表达确定性的主干流程用 Loop 承载需要模型自主判断的开放环节再用 Harness 把前两者稳稳托住。graph 解决结构清晰的部分loop 解决需要弹性的部分harness 解决出事怎么办。一个成熟的做法是把 loop 嵌在 graph 的某个节点里让自主迭代只发生在受控的子任务上而整个系统的稳定性由 harness 兜底。举个具体的例子。一个客服 Agentgraph 负责接单→分类→路由→回复→归档这条主干分类和回复之间那个需要模型灵活处理的部分用一个小 loop 来多轮澄清意图、查知识库、生成草稿而 harness 全程托底分类调的是稳定 API带超时重试、loop 里每轮都有 token 和轮数上限、涉及退款这类敏感动作强制转人工、整条链路可回溯。这样graph 保持清晰、loop 的弹性被关在笼子里、harness 兜底所有意外。反过来如果把这整个东西都画成一张巨 graph或者把整个流程丢给一个无约束的大 loop上线后大概率在分类接口抖一下时就崩给你看。落到选型上给几个实在的判断任务步骤明确、几乎不开放上 graph 就够了别硬上 loop任务开放、路径难预设用 loop但一定要配好预算和退出条件无论哪种只要打算上生产harness 都得补而且越早补越便宜。我甚至觉得决定一个团队 Agent 成熟度的不是它用了多酷的 graph 或 loop而是它的 harness 做到了哪一步。我的看法我越来越确信过去两年大家卷 graph、卷 loop是把力气花在了最显眼、最容易出 demo 的地方。但 Agent 真正难啃的工程是那个谁都不爱写的harness 层。它不性感没有看我的 Agent 自己转了好几圈的惊艳感它就是一堆超时、重试、检查点、看板、回放。可正是这堆东西决定你的 Agent 是停留在演示视频里还是真能扛住用户的毒打。如果你正准备动手搭 Agent我的建议很直接先别急着画最复杂的 graph也别急着上最自主的 loop。先把 harness 的最小集搭起来——工具超时和重试、状态持久化、单次成本看板、敏感动作人工确认——然后再看哪些部分值得用 graph 固化、哪些值得用 loop 放开。一个 harness 扎实、结构清晰、局部自主的 Agent远比一个 graph 华丽但一上线就崩的 Agent 值得信任。最后补一句给技术负责人的。招人和考核上别再用做出了多惊艳的多智能体编排来评价产出那只会鼓励大家继续在 graph 和 loop 上堆花活。真正该奖励的是那些把工具治理写厚、把评估回放做全、把线上事故率压下来的脏活。Agent 这个方向拼到后面全是苦活谁肯把 harness 老老实实织起来谁才能把 Agent 真正用好。
)
