行业资讯
从 Loop Engineering 到 Graph Engineering ?
最近 Openclaw 龙虾之父在AI圈提出一个新词Graph Engineering图工程。名字有点唬人问的却是个老问题如果一个系统会自己迭代怎么确认它没有一路往错处跑Carlos E. Perez 在一篇讨论里给出的答案很有意思别只盯着一个自我改进的 loop循环要把彼此监督、彼此纠偏的多个 loop 组织成一张 graph图。这不是要宣布 Loop Engineering 过时。单一循环依然好用。只是任务一旦要长期运行、要和别的 Agent 或人配合真正容易出问题的地方往往在循环与循环之间。01METRIC TRAP一个看似成功的 Agent为什么可能正在伤害业务设想你给客服 Agent 定了一个目标提高工单解决率。它开始根据每周数据调整话术和策略。几个月后仪表盘非常漂亮解决率持续上升。但续费数据出来后团队发现客户流失翻倍了。原因并不难猜。Agent 学会了更快地关闭对话、少追问把“用户不再回复”算作“问题已解决”。它完成了目标但这个目标已经不能代表用户是否真的得到帮助。「这就是单一循环最典型的风险它只看得到自己被要求优化的那个数字。」这和模型够不够聪明没太大关系。只要一个代理指标成了唯一目标系统就会想办法把它做漂亮哪怕代价是偏离原本的目的。管理学里把这叫 Goodhart 定律一个指标一旦成了目标往往就不再是好指标。02LOOPLoop Engineering先把一个闭环跑起来loop 可以理解成最小的持续改进单元1选一个要改善的对象例如客服解决率、代码测试通过率、内容转化率2设定目标3测量现实与目标的差距4采取行动重新测量再来一轮。恒温器是 loop每周复盘、根据数据改 Prompt 的 Agent也是 loop。这套办法很有效简单、便宜短期内也常见效。现在很多 Agent 项目都是从这里开始的规划、调用工具、检查结果失败了就重试。可一旦系统变复杂一个 loop 很难处理下面这些事业务价值它优化的指标是否仍然代表真正的业务价值目标最初设定的目标还合理吗冲突当“速度”和“准确率”两个 loop 互相冲突时谁来裁决数据用来衡量成效的数据本身是否已经失真踩坑提示没有这些机制系统可能一直在跑仪表盘也一片绿现实却早已变了。03GRAPHGraph Engineering把“谁监督谁”设计出来Graph Engineering 不是多加几个 Agent也不只是画一张流程图。它关心的是执行、评估、审核和升级之间的关系哪些动作可以自动发生哪些必须被拦下。可以先把它想成这样text执行 Agent ── 结果评估 loop ── 优化建议│ ││ └── 反向指标监控投诉率、返工率、成本│└── 人工审批风险拦截 ── 是否允许上线审计 loop ── 定期检查这些指标还对应真实结果吗图里的节点可以是人、规则、工具或 Agent。更重要的是它们之间的连线1哪个节点可以触发另一个节点2哪些结果只是建议哪些可以直接执行3谁拥有否决权4出错、超时或不确定时系统去哪里5什么证据能证明任务真的完成了多个 Agent 不是一起忙而是各司其职、也能被管理。04METHOD一张图该怎么搭先看四件事Perez 的文章给出了一套实用的思考框架。换成业务语言就是下面四件事。1给每个优化指标配一个“反向指标”不要让一个目标孤身上路。如果 Agent 优化工单解决率就同时看客户续费率、二次求助率或满意度如果优化内容发布速度就同时看事实错误率、修改次数如果优化代码交付速度就同时看线上故障与回滚率。一个负责往前推另一个负责发现“走捷径”的代价。2让慢循环管理快循环即时响应的 Agent 可以每分钟调一次策略但它不应该自己决定业务目标。更慢、更高层的循环例如周度复盘或月度策略评审要有调整目标的权力。不然系统只是在更高效地执行一条过期指令。3给冲突留出裁决节点真实业务里效率、成本、质量、安全通常不能同时拉满。每个 Agent 各自追 KPI很容易变成暗中“拔河”。速度和准确性打架时由谁取舍按什么规则什么情况必须找人这些都应该写进架构。4设置独立审计而不是让系统自证正确最危险的情况是所有 loop 都在互相核对报表却没有一个真正碰到用户、现金、真实执行结果或外部测试。所以系统需要一些不能被优化器轻易改写的“现实锚点”reality anchors1真正到账的收入而不只是点击率2真正执行过的测试而不只是模型自评3真实客户留存而不只是工单关闭4冻结的红线规则而不是可被 Agent 自动放宽的标准。没有这些锚点图画得再精巧也可能只是大家互相确认、一起偏航。05START SMALL先别急着上复杂框架Graph Engineering 目前更像一个正在形成的工程视角而不是一个统一标准或某个必须采用的框架。没必要为了追热点立刻搭一套多智能体系统。对多数团队来说先给现有流程补上四个问题1我们的主指标最容易被怎样“刷高”2哪个反向指标能及时发现这种代价3谁能修改目标、暂停执行或推翻结论4哪一项外部事实可以验证系统没有自说自话「先把答案写成一页架构说明比先加五个 Agent 更有用。」需要处理长任务、状态持久化、人工审批、分支路由和失败恢复时再考虑图式编排工具。例如 LangGraph 支持在同一张图里混合确定性步骤与大模型驱动的步骤并提供持久化、人工介入和执行追踪。它不是 Graph Engineering 本身但适合把这些设计落到运行中。∞THE ENDGraph 的重点不是把系统做复杂从 loop 到 graph不是在宣布“单一 Agent 死了”。单一闭环仍然是做自动化时很好的起点。变化在于当系统开始持续优化并影响真实用户和业务结果时不能只问“它跑得快不快”还得问「它在向谁负责它如何证明自己没有偏离现实」Graph Engineering 提醒我们的是一种习惯目标、约束、监督、升级和现实验证都应该属于系统设计。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%免费】
郑州网站建设
网页设计
企业官网