AI风向标
浅谈AI未来走向。
Loop Engineering | 循环工程
鉴于Harness现如今已进入大众视野，所以开篇直接进入四阶段Loop Engineering .
想要了解与之相关的前三个阶段可以查看《AI的三次重心迁移》和《Harness》.
看到loop，我首先想到的是圈、是环，进而想到环路想到循环。
而循环则通常需要反馈、记忆和停止条件。
反馈需要输出、评估，而角色分离能够显著提升纠错效果，这就衍生出至少两个Agent扮演其角色。
记忆需要跨会话存储，这就催生出了状态管理和经验共享机制。
停止条件则通常需要外部裁判，这就需要验证器和监督机制。
综上，多个Agent、状态管理、经验共享、验证器、监督机制，就初步构成了一个能不断循环、纠错的逻辑闭环。这样智能的载体就从个体转移到了群体组成的回路。
而Loop的核心思想就是群体的智能高于个体。
其意义远不在于取长补短。 就如人类文明一般，单个人的智力终究有限，但经由分工、协作、辩论和知识的代际累积，人类社会作为整体所展现的智能，远远超越任何一位天才个体。
话说一箩筐 那么何时多Agent会优于单个Agent？
其核心判据只有一条：
协作过程是否引入了单个 Agent 在生成时无法获得的新信息？
多Agent协作的分类框架
维度一 上下文是否共享
-
共享上下文
所有阶段共享同一对话历史。
优势在于信息不丢失，每个Agent都能回顾之前任何阶段的细节。
挑战在于上下文会快速膨胀，导致模型的注意力会分散，失去焦点。 -
不共享上下文
意味着每个Agent维护完全独立的上下文和对话历史。
就像不同部门间的协作，通过会议纪要等特定形式交换信息。
其优势在于模块化、可拓展、可并行，后期维护也更容易。
不需要改动现有的内部逻辑，只需定义好接口的和数据格式。
挑战在于 信息同步复杂：- 各 Agent 如何对任务状态保持一致的理解？
- 信息在传递过程中会不会丢失或重复？
- 调试也变得更加困难——出了问题需要翻看多个Agent的日志，才能拼出完整的执行过程。
无论上下文是否共享 其挑战之处都在于资源信息的整合提炼。
这让我想到了乘法分配律 (a+b)c = a·c+b·c.
思想上或许有点异曲同工。
可能殊途同归是最美好的愿景吧。
当然放到工程实践里面，也只能是无限逼近了。
什么是Agent？
就我个人理解
Agent是当单次回答满足不了日益增长的需求后所出现的产物。
可以当成是工作流、流水线，
但与之不同的是Agent走的不是既定路线。
它可以在执行过程中动态调整自己所需要的context和其行动顺序。
简而言之就是走一步看一步，随机应变，动态部署。
维度二 协作拓扑
即 Agent 之间的控制权和信息按什么结构流动。
目前有三种典型形态：
-
对等协作模式（Peer Collaboration Pattern）：少量 Agent 按照固定的拓扑形成迭代改进循环，例如论文写作 Agent 由起草者和评论者两个 Agent 组成，一方起草、另一方批注修改，反复几轮后质量更高。
-
管理者模式（Orchestration Pattern）：一个中心化的 Manager Agent 负责任务规划和调度，多个子 Agent 各负责特定子任务——就像项目经理带着几位专业工程师做项目。
-
去中心化模式（Decentralized Pattern）：没有运行时的中心控制者，Agent 之间像人类一样互相沟通，协作完成任务。
这三种典型形态同时也是不同的图拓扑，而图拓扑便是下一阶段,即今年七月份吹起的风 “图工程” 的重要拼图。
Graph Engineering | 图工程
起初，当我看到graph的时候 第一反应是图 进而想到流程图，觉得ai已经开始走进降低使用门槛、优化的方向开始倾向于如何更好地去纵观全局的阶段。
实则不尽然,图工程其实是把ai的重点从上下文窗口内部转移到了上下文窗口之间的交接过程。
就比方在现在的loop循环工程中，六十步的流程在走到第四十步时崩溃，你的选择不是从头开始就是对上下文窗口进行”外科手术” ，对其增删查改。
再比方部署Agent的企业需要审计追踪，这就需要任务可恢复、有审批关卡、有成本上限，而循环工程的全部状态就是一份对话记录，其所谓的”记忆”仅仅是在上下文压缩后幸存下来的内容。于是带检查点的图工程便应运而生。
何谓 图工程？
图工程是将 Agent 系统设计为显式的图，而非隐式的循环。它有三要素。
节点是能力的单元
节点可以是一个运行熟悉的“思考-行动-观察”循环的模型，可以是一个普通的确定性函数，可以是一个检索步骤，也可以是一个人类。一个好的节点是简单、单一且行为是可预测的。它只做一件事，你可以单独测试它，并且可以在不触碰其他任何东西的情况下替换它。
边是决策
边是一种类型化的转换，负责将状态从一个节点传递到下一个节点，从当前状态到下一个节点的、带条件的转换规则。
即 边回答的是
- 接下来去哪个节点？
- 要不要重试？
- 要不要回退？
而边本身又分确定性和模型决定两类。有些边是确定性的：测试通过，就部署。有些边由模型决定：这个工单是发给计费部门还是滥用处理部门。图工程的工作就是弄清楚哪些是哪种，并在任何你能承受的地方默认使用确定性边。
状态是一个带有模式（Schema）的对象
是每次跨越边时都会生成的检查点。它并不是“当前碰巧存在于上下文窗口中的任何东西”。
在图工程的背景下
写提示词之前先画出状态。 状态模式就是你的架构。
让节点保持简单、单一职责且行为可预测。 只做一件事的节点可以被测试、缓存、重试和替换。做五件事的节点，只不过是一个多了几步操作的循环。
把判断力放在边上。 图工程的智能存在于其运行时选择走哪条边的过程，这意味着由模型决定的边就是它最容易失败的地方。像对待核心逻辑一样去监控它们。
在每次跨越边时生成检查点。 这样，失败的含义就不再是“重启整个运行”，而是“重试该节点”。这也是让周期长的任务变得现实的关键。
将人类视为节点。 审批理应获得与其他能力相同的设计关注：一条输入边，一条输出边，中间是一个人。如果把人类审批当作异常处理器强行挂在系统外部，你最终得到的系统表面上有监管，实际上毫无监管可言。
把预算放进状态里。 Token、美元和实际耗时（Wall-clock time）都存在于状态对象中，并在跨越边时受到强制执行。如果你无法在达到支出阈值时停止 Agent，那你运行的就不是一个自主系统，你只是在刷爆账单。
提到token上个月的时候，DeepSeek有个内测模型。
当时，其最令人喜人的特点是，平均每秒消耗的token超过300，给出的答卷是又快又好。
网友初步的评价总体观感良好，但token烧的也是真的快。
评估轨迹,而不仅仅是最终输出。 输出评估只能告诉你运行是否有一个好结果。轨迹评估才能告诉你，它是否以合理的成本走了一条合理的路径，而下一个故障就隐藏在这条路径中。
The skill shift | 技能的转移
从提示词到上下文到Harness，再到loop循环，现如今的图工程，从苦口婆心对着模型叭叭地诉说自己的需求到变被动为主动开始插手控制Agent的运行逻辑，每一步跃迁都考验着人类统筹规划的能力，同时也折射出当下的趋势 对模型少一点”耳语”，多一些”系统架构”。