AI所承担的任务时长一旦变长, 那么问题就远不止于“怎样把提示词写得好”这一方面了。当存在多个Agent、工具以及人一同去完成一项工作时, 节点之间究竟该如何进行连接, 状态到底怎样去保存, 还有哪里是必须要停下来转交给编辑处理的, 这些方面开始对整条工作链是否可靠起决定性作用。几年前, 生成式AI进入大众视野, 此后人们最常问的是, 提示词该如何写, 角色是否要设定, 任务是否要分步做, 最好能给几个例子, 提示词工程因此广为人知, 面对一次具体的模型调用, 把要求说得更清晰, 结果通常就会更佳。然而, AI 一旦着手读取多份材料, 调用工具, 连续处理一项任务, 问题迅速发生了变化。模型不但得听得懂指令, 而且得在有限的上下文里找出此刻切实需要的信息它得清楚有哪些工具能够使用, 操作失败之后如何处理, 何种结果才算完成。于是, 上下文工程、Agent 运行环境以及行动循环愈发受到关注。人们不再仅仅询问“怎样获取一个好答案”, 也开始探究“怎样使 AI 持续做一件事”。首先得说明一下, 这可不是一条有着规整性的技术升级路径。提示词、上下文、运行所处环境、循环以及图, 早就彼此相互交织在一起了, 直至今日也依旧会同时存在着。本文是顺着这条线索来进行展开的, 目的在于观察一个更为关键的变化, 那就是: 当AI所承担的任务变得越来越长的时候, 工程设计的着眼点是怎样从一次模型调用, 一步步地转移到模型之外的整个工作上面的。有一种工作模式极重要, 它存在于这种变化里, 那就是循环。有一个 Agent智能体, 当它写完代码后, 能够运行测试, 一旦发现错误便去修改即便生成一段文字, 它同样可以依据规则检查、重写, 直至通过或者达到停止条件。AI 并非仅仅输出一次, 而是在“行动—观察—修正”的过程中来回反复进行。近来, 一些从业者把围绕反思考验出来的、停止的条件以及失败之后的处理方式所做的设计, 概括为“Loop ”。这个名称十分新颖, 然而循环其本身并非新的创造发明。2026年7月, 一场讨论, 将Graph再次推至人们眼前, 创始人Peter于X上发问: “我们于循环的探讨仍在继续, 还是已然转向图了呢? ”随后, Hamel采用了一个更具醒目效果的标题: “循环已逝, 图的时代来临。”这是一句颇具传播性的判断, 却不可被当作循环已因技术而遭淘汰的结论。它切实碰到困难的是, 一项工作已然容纳了多个 Agent, 还有各种工具、规则以及人工判断, 在超出单个循环的范围, 需以何种方案来安排它们之间进行协作。在这场讨论里被借用的“Graph ”, 在本文中被称作图工程, 专门针对面向 Agent 工作流的图式编排设计而言, 并非知识图谱工程, 也不是图数据库工程。这里所说的“图”, 其目的并非是绘制出更美观的流程。它关注的是, 谁应当先行开展工作, 谁能够同时进行工作前一个步骤交付的是什么内容, 后续步骤凭借什么予以信任出现疑问时应前往何处, 任务中断后应从哪里重新开始当涉及删除、外发以及发布这类操作时, 谁有权力使系统停止运行。即便一个节点内部能够多次运行, 图工程所处理的却是这些节点之间的关联范畴, 而非仅仅是节点本身的反复运行。这同样是它值得科技期刊编辑予以关注的缘故。编辑工作原本就并非一次就完成的: 存在稿件初筛这一环节, 还有信息核验环节, 也有同行评议环节, 另外有修改复核环节, 包含排版校对环节, 以及发布回读环节, 各个环节有着不一样的依据, 还由不同的角色来负责。要是 Agent 往后进入到这条工作链之中, 那么真正需要去设计的将不单单是某一步如何提升效率, 而是证据该如何进行交接, 错误在何处会被拦截住, 以及哪些决定依旧必须保留在编辑手中。一开始人们只想把问题问得更好工程视线不断向外移动提示词 说清一次调用上下文 给出此刻所需信息Loop 行动、观察与修正Graph 组织分支、状态与责任提示词工程并非已然过时, 直至今日, 清晰地阐明对象, 明确任务, 界定材料边界以及提出输出要求, 依旧是善用大模型的根基所在, 指令模型“概括这篇论文”和要求其“针对非专业读者, 在不延展结论的情形下, 以三百字阐述研究问题、方法以及主要发现”, 所获得的结果常常存在差异。然而要清晰地阐述提示词工程首先着重优化的内容, 是在一次模型调用这件事情当中, 究竟该以怎样的方式去组织指令, 以及如何安排例子、材料和输出要求。它并非仅仅局限于为单轮问答提供支撑, 而是在长任务的每一个节点处, 以及长任务的每次循环过程里, 始终都能够发挥其应有的作用。只是当任务一旦出现延长的情况时, 那些能够决定最终结果的因素就会呈现出迅速增加的态势。能否区分论文结论与媒体报道同样是概括论文时模型看到的是摘要还是全文补充材料有没有进入上下文前面提取过的数据是否还保留着来源位置这些问题并不能靠把将第一条提示词写得更长来解决上下文窗口再大也不意味着应该把所有材料一股脑塞进去真正困难的是在任务进行到某一步时把正确可以而且可信的信息送到模型跟前。这类问题一直长期存在着, “上下文工程”是近来颇受聚焦关注的相关说法, 它所关心在意的, 不单单只是一句话该如何去写, 还涵盖了系统指令, 原始材料, 历史状态, 工具取得的返回结果, 以及哪些信息在当下应当予以保留, 哪些信息应当暂时移出。提示词仿佛是给出一项要求, 上下文则构成了Agent作出判断时所处的信息环境。二者也并非是完全截然分开的: 提示词自身就是上下文的其中一部分。AI 开始行动以后周围的环境也要被设计人们容易把问题都归到模型或提示词上, 当大模型只能生成文字的时候。可事情就不同了, 在Agent开始搜索资料、读取文件、执行代码、调用数据库和访问外部系统以后。真正让这些动作能够发生的, 是它周围的一整套运行环境, 由模型负责判断下一步做什么。工具描述是不是清晰, Agent 能够访问哪些目录, 操作有没有权限方面的限制, 执行结果以何种方式返回, 失败 case 会不会留下记录, 这些情况都有可能致使任务结果发生改变。一个模型没能找到文件, 有些时候并非是推理能力欠缺, 而是工具未将正确路径传递给它一次操作被再度执行, 或许是由于系统未能区分“上次失败”以及“上次已完成但是回执遗失”。近来, 有部分从业者采用一种表述来涵盖包于模型之外的那套运行支撑。中文目前不存在统一的译法, 暂且可将其理解成 Agent 的“工作台”, 模型处于其中, 能够看见材料, 能够拿到工具, 能够保存状态, 同时也会受到权限以及规则的约束。所谓的这个表述, 同样是一个行业边界尚没有得到统一的表达, 有时候还会把上下文管理、行动循环以及编排涵盖进去。它并非是在提示词工程之后独立出现的一代技术成果, 仅仅是在提醒人们, 诸多关乎成败的因素已然位于模型之外了。这一步的变化极为关键, AI应用的质量, 并非仅仅取决于模型的一次回答, 工具能否被正确调用, 结果是否具备可追溯性, 状态在中断之后是否会丢失, 同样成为系统可靠性的一部分。Loop 让 AI 从回答者变成了行动者有了工具以及运行环境, Agent便能够进入循环, 它先是采取行动, 接着观察外部结果, 依据此来决定下一步, 代码要是没有通过测试, 那就阅读错误信息后进行修改, 检索要是没有找到足够材料, 那就调整查询, 稿件要是没有满足格式要求, 那就根据检查结果重新处理。这类Loop的意义, 是将反馈接回到任务上, 以往在模型生成单一结果静止后, 发现问题以及重新提问都需借由人达成, 现在, 测试程序、规则检查或者工具返回值能够成为下一轮行动的依据, 所以Agent能够接连进行一些目标清晰、反馈明确的工作。但是, 循环是存在着边界的。存在这样一个 Agent, 它既持续生成着内容, 与此同时, 又依据自身所生成的摘要来核查内容, 如此一来, 最初所产生的误解便极有可能会被带入到下一轮之中展开循环。循环诚然能够让一句本身错误的话语在修改过程中变得愈发通顺流畅, 然而却并不能够自动带来具有独立性质的数据证据。并且, 它还有可能陷入到另外一种困境当中, 那便是不断地进行重试, 可是却根本不知道究竟在什么时候应当承认失败, 又或者是将问题交付给其他人去处理。因此, 一条能够使用的Loop, 不可以仅仅只有“再试一回”, 它 必须清晰地反馈源自何处, 何种情形算作通过, 最多能够重试几回, 何时停止。被概括为“Loop ”的设计, 近来所真正关心的, 正是这套行动与反馈的闭环, 并非仅仅是让 Agent 在原地反复生成。这个名称是否会长期保留下来, 目前尚难判断, 不过它所指出的停止、重试以及外部反馈问题, 已然存在于真实系统之中。从一个循环到一张图只开展一桩局部的任务, 一条Loop通常就已然足够。然而复杂的工作鲜少有仅一种反馈的情况。存在有人负责去生成, 有人负责进行核查的状况其中某些步骤能够同时予以开展, 而另外一些则必须要等待前一步骤完成要是碰上不同的结果, 任务便会朝着不同的分支去发展。在这样的时候, 单单只是把每个Agent自身的循环设计妥当, 根本无法解答整项工作到底该如何去推进。这同样是近期借“图工程”尝试概要表述时所探讨的问题, 在本文关于工作性的解释当中, 图是由一组节点以及它们之间的关系所构成的, 当中的节点并非一定都得是Agent , 它能够是一个大模型扮演的角色 , 能够是一条具有确定性的规则 , 能够是一项数据库查询 , 能够是一个等待人工予以确认的位置 , 连接节点的边也并非仅仅只是“下一步” , 它还能够带有相应条件 , 此条件是核验通过便持续进行 , 材料出现缺失便予以退回 , 风险无法判定便交付给编辑。现有工具, 从不同方向, 提供了这类能力, 通过用节点、边和共享状态, 来组织Agent工作流, 仍处于实验阶段的, 侧重于多个Agent的顺序、并行、分支与循环, ADK 2.0也支持, 由Agent、工具、函数和人工输入组成的图式工作流, 更底层还有Graph这样的类型化图与状态机工具, 以及处理状态、失败和恢复的 、。它们并非是同一种产品, 然而却共同表明了一件事情, 那就是图、状态机、工作流以及耐久执行早就已经存在, “Graph ”所作的仅仅是将这些思路再次带入到Agent协作的探讨之中。存在这样一层变化, 它能够以一句话来进行概括, 即提示词工程所关注的是怎样去构造一次模型调用, 而近期所说的图工程则是将注意力进一步朝着整项工作怎样得以被组织起来这一方面进行转移, 两者之间不会相互替代, 因为在一张图里的每个模型节点依旧是需要有好的提示词以及上下文的。并不能说组织起来就意味着把节点画得越多便越好, 标题改写、格式统一等这类简单任务, 一条有限的Loop可能就能够完成, 若硬是拆分成五个Agent, 额外的传递、等待以及核查反倒会使成本增加, 只有在任务存在明确的前后依赖、并行工作、分支、暂停以及人工审批时, 图才真正具有作用。把一篇投稿送到审稿人面前一篇投稿进入送审前的图式结构确定性检查 字段、文件和格式Agent 核验 研究范围、声明与证据位置条件分支 疑点触发暂停或补件状态恢复 从相关节点继续不必全部重跑人工关口 送审、退修和正式邀请由编辑确认把这个变化放进科技期刊投稿初检是一个较合适的观察场景。