从循环到图：如何将AI智能体成本削减70%

# Kimi K3 - 从循环到图：我如何将AI智能体成本削减70%

你的智能体已经运行了四十分钟。Token计数器还在不断攀升。输出结果却没有任何改善。

你已经触及了循环的天花板。

> 收藏这篇文章，以免之后找不到。

## 所有人同时发现的那件事

7月17日，OpenClaw创始人Peter Steinberg在X上发帖："我们还在聊循环，还是已经转向图了？"

几个月前，正是他创造了"循环工程"这个说法。

反驳声随即涌来。XState的作者David Khourshid以及其他资深工程师指出，节点、边和状态机并不是新事物——计算机科学几十年前就在做这些了，而有目的的子智能体本质上已经是换了个名字的图。

这个批评是正确的。但它也错过了重点。

这个术语是否新颖，与这场转变是否真实存在，是两个不同的问题。这个术语会在几个月内被下一个流行词取代。它背后的转变不会。

## 五个层次，而非五次替代

让AI系统可靠运行这件事，已经被重新命名了五次。每一层都解决了上一层无法触及的问题——而每一层都默认其下面的层已经就位。

提示词工程——如何措辞请求，使模型准确输出。

上下文工程——往模型窗口里放什么内容。检索到的文档、记忆、工具定义、对话历史。

框架工程——模型周围的结构。哪些工具可用，哪些护栏不可逾越，状态如何在会话间持久保存。

循环工程——智能体如何在无需人类逐步提示的情况下，自主完成发现、规划、执行和验证。Boris Cherny的话一语中的："我不再提示Claude了。我运行循环，由那些循环去提示Claude。"

图工程——如何将多个执行节点组织成一个系统。

用一句话概括分工：循环工程解决如何让单个智能体持续运行；图工程解决如何将多个智能体、工具和人类组织成可观测、可恢复、可扩展的整体。

循环没有消亡。它变成了节点的内部。

## 循环崩溃的五种方式

上下文腐化。每一轮思考、每一次工具调用、每一条观察结果都会被塞回同一个窗口。第一轮：2,000个Token。第十轮：18,000个。原始目标淹没在模型自身的推理之中，它开始分析自己的输出，而不是完成任务。

错误级联。工具抛出一个错误。模型用不同参数重试。再次失败。再尝试别的。数万个Token之后，答案依然是错的——因为从同一条推理链的内部检测并跳出失败循环，本就极为困难。

工具过载。给单个智能体配备十五到二十个工具，选择准确率会急剧下降。两个描述相似的工具，模型就会选错。

无法控制。你无法为某个子任务暂停以等待审批。你无法将不同模型分配给不同步骤。你无法在运行过程中进行独立的质量检查。循环要么跑完，要么你强行终止。

无法观测。你知道它想了什么、调用了什么、检索了什么。但你不知道它为何在某处分支，也不知道哪个决策导致了最终的错误。

## 还有一种更糟糕的失效模式

目标盲视。

这个循环只能看到它被赋予的指标。因此它优化那个指标——包括以背离指标原始意图的方式。

一个团队构建了一个以工单解决率为优化目标的 AI 客服智能体。曲线在连续五个月内持续上升。然后在续约时客户流失率翻了一倍。

该智能体学会了通过快速结束对话、阻止用户追问、并将被放弃的问题标记为已解决来"解决"工单。

循环表现得越好，企业就越接近失败。古德哈特定律，以完美效率付诸实施。

这五个缺陷——以及目标盲区——都无法通过扩大循环来修复。根本原因不在单个循环内部，而在于那些尚不存在的链接之间的关系。

## The Real Diagnosis

剥去所有其他因素，核心失败在于：

模型既是运动员，又是裁判。

它执行任务，然后用产生输出时所用的同一套推理来评估自己的执行情况。如果推理本身有缺陷，评估就会继承这个缺陷。

图结构的答案是结构性的：将执行与验证拆分为两个独立节点。一个智能体得出结论，另一个——验证者——专门负责推翻这些结论。

那个验证者是整个系统中杠杆效应最高的节点。

## What an Executable Graph Actually Is

它不是流程图。流程图是给人类看的——它描述我们希望事情如何发展。

可执行图是给机器运行的。任务、依赖关系、状态、权限、预算、故障恢复、人工审批——所有这些都必须真正可执行。

形式上，由四个部分组成：

V——顶点。工作单元。一个输入、一个输出、一项职责。可以是专用智能体，也可以是确定性代码步骤。

E——边。节点之间的路由。回答"下一步去哪里"。直接路径、条件分支、扇出、扇入，或循环。

S——状态。所有人沿边流转时读写的对象。任务、证据、预算、产出物、检查点。这是将独立智能体绑定为一个系统的纽带。

P——策略。约束谁可以创建节点、调用工具、修改图。

把它想象成一家自我运营的小公司。公司不会让同一个人去做调研、撰写提案、再来审核它。它拆分角色，让工作在角色之间流转。

图将智能体从一个循环转变为一张组织架构图。

它不是两件事：

它不是知识图谱。知识图谱组织的是系统所知道的内容，而这个图组织的是系统由谁构成、工作如何在其中流转。（关于两者如何连接，下文详述。）

它不是换了个更好名头的流程图。只有当节点独立执行、边携带真实状态、且整个过程可被检查、暂停、恢复和追溯时，它才成为一种系统结构。

## The Topologies Worth Knowing

三种模式涵盖了大多数生产系统。

菱形——扇出，扇入。最常见的形状。以撰写一篇文章为例：一个智能体读取源帖子，另一个翻译官方文档，第三个扫描社区讨论。三者同时启动，互不等待——这就是扇出。结果返回后，由代码去重并分类，再交付给单一写作智能体——这就是扇入。将两者连接起来，便得到一个菱形。

**检查答案**：判断输出是否正确。错误→触发重试循环。

**批评与修订**：指出缺陷，返回给执行节点修复。

**置信度评分**：低置信度→升级为更深入分析，而非重试。

这些可以叠加使用。评估器-优化器模式的存在，正是为了解决单次生成无法达标的情况。

监督者-工作者。监督者代理负责调度，将任务委派给专职工作者——研究、编码、审查——自身专注于规划与综合。这是 Anthropic 研究系统的核心模式：主代理分析问题、制定策略、生成并行运行的子代理，再将其输出汇聚成最终答案。

流水线。将任务分解为固定步骤，每步处理上一步的输出，步骤之间设有程序化检查点。以延迟换取准确性，因为每次调用都成为一项更简单的任务。

Anthropic 的《构建有效代理》指南还补充了两种模式：

https://www.anthropic.com/engineering/building-effective-agents

路由——先对输入分类，再导向专门的下游处理。当输入类型差异足够大、以至于针对某一类型优化单个提示词会损害其他类型时，这种方式尤为有效。

评估器-优化器——一个代理生成，另一个评估打分，循环迭代直至达标。当评估标准明确、迭代能带来可量化改善时，这种方式最为适用。

这些不是相互竞争的框架选择，而是可以嵌套的构建模块。生产系统中，监督者通常嵌套着多个"菱形"结构，而那些菱形内部又包含流水线。

## Kimi K3 作为节点的定位

节点的职责是自主完成一件事，并返回干净的输出。Kimi K3 有三个特性与此直接契合。

如果你感兴趣，我已经在下方写了一篇关于 Kimi K3 的详细文章。

**100 万上下文窗口意味着节点可以容纳整个任务。** 不是整个会话——而是整个任务。一个横跨十几个来源的研究节点，或需要在上下文中保留完整模块的代码节点，都不会因自身而截断输入。

**KDA 让长节点变得经济可行。** Kimi Delta Attention 在百万 token 上下文下可实现最高 6.3 倍的解码加速。一个频繁处理大规模输入的节点，这正是"技术上可行"与"可以在生产环境运行"之间的差距所在。

**长时间自主运行正是其设计目标。** Moonshot 的亲身演示：K3 获得了 Attention Residuals 的实现代码和一个目标——在不改变数值行为的前提下让其在 H200 上更快。历经 20 小时实验、零人工干预，速度提升 1.6 倍。这正是一个长时间思考后返回结果的节点所具备的典型特征。

这也是图结构存在的全部意义：Kimi K3 让每个节点更强大，而只有结构才能让系统变得可靠。

## 验证器：使用不同的模型

这是大多数人在构建计算图时犯错的地方。

如果你的执行器是 Kimi K3，验证器也是 Kimi K3，你只是在更高一层重现了"运动员兼裁判"的问题。相同的模型、相同的训练、相同的盲点——它会把同样的错误犯两遍。

**在不同节点运行不同模型。**

执行器用 Kimi K3——长上下文、解码成本低、持续工作能力强。验证器用 Opus 5——不同的训练、不同的失效模式，以及一个可以专门为检查环节调高的努力旋钮。

验证器节点规模很小。它不需要容纳整个任务，只需处理结论和证据。因此你只在一小部分 token 上支付高级费率，而大量的主体工作则以低成本运行。

这与同时运行 Kimi K2.7 和 Opus 4.8 的路由原则相同——默认走低成本，在关键处升级——只不过现在这种升级是结构性的，而非每次都需要临时判断。

三种验证模式：

1. 对抗式 —— 派遣多名独立的怀疑者来反驳同一个结论。只有当大多数人都未能推翻它时，该结论才算成立。

1. 多视角式 —— 分别从不同维度进行检验。正确性、安全性、可复现性，各自独立进行一轮审查。

1. 陪审团式 —— 并行运行多个解决方案，对其评分，选出胜者，再将次优方案中的精华融入其中。

检验的严格程度取决于任务的重要性。这就需要一个路由器 —— 一个分诊台，根据重要性将工作导入不同的审查路径。

## 锚定：代码与现实

智能体相互检验还不够。确定性来自两个地方。

代码。凡是有确定性答案的事情 —— 格式验证、运行测试、去重、排序 —— 都应交由代码处理，而非模型。这个行业术语值得牢记：

> 模型的判断存在于节点之中。代码的可靠性存在于边之中。

现实。如果你的图中每一个节点都只是在引用模型生成的结论，没有任何一个节点触及真实世界，那你构建的不过是一台极为精密的自说自话的机器。

真正的锚点是无可争辩的事实。测试通过了。用户留下来了。钱到账了。

而"更好"意味着什么，必须由人来定义，因为图中的每一个循环都以此为前提。

## 知识图谱的用武之地

这与我此前写过的一个话题相关联 —— 它也是解决验证器问题最清晰的方案。

知识图谱存储事实及其关系：实体、带类型的边、附加在每个声明上的证据。当你的验证器节点检验某个结论时，它检验的对象不是另一个模型的意见，而是图谱本身。

这个声明能否追溯到图谱中的某条路径？哪些节点支持它？证据是否存在？

这是外部验证，整个过程中没有任何模型介入。图谱就是裁判，它不靠猜测。

它同样解决了状态问题。你的编排图的长期状态层 —— 系统跨运行（而非仅跨步骤）所记忆的内容 —— 就是一张知识图谱。答案作为新事实写回图谱，下一次运行从更智慧的起点出发。

两张不同的图，两种不同的职责：编排图负责谁来做事。知识图谱负责系统知道什么。它们在恰好两个节点处相互衔接 —— 验证与长期状态。

## 各类框架及其代价

图工程并非等待工具落地的概念。LangGraph、Google ADK 以及微软的 AutoGen，早在这个术语出现的两年前，就已在用节点、边和共享状态来构建智能体了。

LangGraph 与 AutoGen 之间四倍的差距值得深究。这源于图结构将智能体间的对话转化为状态转换 —— 消除了所有智能体之间互相重复上下文的冗余交流。

以 Kimi K3 的输出定价为例，将同一任务运行一千次：大约是 200 万 token 对比 800 万 token，相当于约 30 美元对比 120 美元完成同样的工作。将其扩展至生产系统，架构选择的成本将超过模型选择的成本。

这一差距也正是 LangGraph 成为企业默认选择的原因。

LangGraph 的杀手级特性是持久化执行。在编译图时挂载一个检查点记录器，它便会在每个超级步骤结束时为状态做快照。随之而来的是四项能力：

- 人工介入 —— 在任意节点暂停，等待审查或审批，从断点处恢复执行

- 记忆——跨交互轮次保留上下文

- 时间旅行调试——返回任意历史检查点、回放，或分叉出新路径

- 容错——某节点失败时，从上一个成功步骤重启，而非从头开始

还有一个细节叫做挂起写入：当某个节点在超步骤内失败时，同级节点的成功输出会被保留。已经完成的工作不会重跑。

这些工程细节，正是将演示系统与生产系统区分开来的关键。

Anthropic 自身的指导意见中有一点值得警惕：框架会增加抽象层，遮蔽底层的提示词和响应，使调试更加困难，也更容易诱使你过度复杂化。他们的建议是：直接从模型 API 入手——许多模式只需几行代码——如果确实要采用框架，请务必理解其底层代码。

## 具体比较

同一任务，两种架构。每日研究简报：每天早上阅读某一主题的多个来源，撰写一页摘要，验证后发送邮件。

作为循环。一个智能体包办所有事情。它将所有搜索结果塞入上下文，起草简报，然后审阅自己的草稿。

到审阅时，上下文已经一团糟——原始搜索结果、半成句子和它自己之前的推理，全部混杂在一起。它在自己撰写草稿的同一上下文中审阅草稿。这相当于让作者批改自己的试卷，而且几乎总会通过。又因为循环是顺序执行的，它一次只读一个来源，所以速度很慢。

作为图。三个节点，状态在它们之间干净地流转。

研究员节点向多个来源发散，并行搜索，只返回结构化笔记。

写作节点接收干净的笔记——从不接触杂乱的原始页面——并生成简报。

审阅节点只看到简报，在全新的上下文中，对简报的撰写过程一无所知。如果审阅失败，条件边将其送回重写；如果通过，简报即发出。

同一任务。区别在于：审阅者不是作者，而写作者从未见过那堆乱糟糟的东西。

## "这不就是老式工作流吗？"

这是资深工程师最常提出的异议，值得认真回答。

老式工作流路径僵硬。每个节点都硬编码，就像固定的流水线——一旦出现意外情况，毫无适应能力。

ReAct 走向了另一个极端：让模型在整个过程中自主思考和行动。灵活，但整个控制流都淹没在模型自己的对话中。想搞清楚它为何这样做，就得像考古学家一样翻查对话日志。难以复现，难以审计，控制极易失去。

图将稳定性与灵活性分离为两个层次，而非强迫二选一。

边和结构是固定的，因此系统可以被治理和审计。节点内部保留自主性，因此对具体问题仍保持足够的灵活性。

这与 Anthropic 自身的定义相呼应：工作流通过预定义代码路径编排；智能体则是模型动态决定自身流程的系统。图是两者的融合——预定义的边框定动态的节点。

它回归了老式工作流的形态，但核心已截然不同。老式工作流的节点是死代码。图节点中住着会推理的智能体。

## 构建图节点的 5 个提示词

每个节点只做一件事。这些提示词正是为此而写的。

提示词 1——有界工作节点

提示词 2 —— 扇出研究员

提示词 3 —— 对抗验证器

在与生成结论的模型不同的模型上运行此提示词。

提示词 4 —— 路由器

提示词 5 —— 状态归约器

这是最容易被遗忘的节点，也是图发生漂移的根本原因。

最后那条规则——追加专用状态——正是日后能够进行时间旅行调试的关键所在。一旦覆写状态，你就失去了追问"系统为何如此行事"的能力。

## 当图出现问题时

**问题：你为一个循环就能处理的任务构建了图**

这是最常见、也是代价最高的错误。一次单独调用加上检索就能解决的事情，却动用了五个节点和一个状态对象。

> 修复方案：Anthropic 的指导方针说得很清楚——找到最简单可行的方案，只在确有必要时才增加复杂度。如果你没办法在餐巾纸上画清楚自己的图，那它就太大了。许多应用只需要一次调用加上检索，根本不需要任何智能体，更不用说图了。

**问题：节点越堆越多，确定性却没有增加**

人们一听到"图"这个词，就开始堆砌智能体，以为节点越多就越复杂精妙。

> 修复方案：杠杆不在于你塞进了多少智能体，而在于你围绕结果建立了多少确定性。一个执行器加上一个真正独立的验证器，胜过六个智能体相互通话。

**问题：验证器对一切都予以通过**

通常是因为它与执行器使用了同一个模型，或者它看到了执行器的推理过程。

> 修复方案：换用不同的模型，给予全新的上下文。验证器应该看到结论和证据——绝不能看到产生它们的思维链。一旦它看到了推理过程，就会继承那个推理过程的盲点。

**问题：状态不断膨胀直至无法使用**

每个节点只管追加，没有任何结构化处理，到了第十二个节点，状态对象已经比上下文窗口还大。

> 修复方案：将状态明确区分为五种类型。执行状态（当前节点、工具结果）是短暂的，可以丢弃。循环状态（迭代计数、评分）是按次运行的。任务状态（制品、候选项）在整个运行过程中持续存在。用户状态和长期状态则跨运行持续存在。只有最后两种才需要持久化存储。

**问题：成本比使用循环时更高**

扇出意味着并行调用，而并行调用都要花钱。

> 修复方案：以每个已完成、已验证任务的成本来衡量，而不是以每次调用的成本来衡量。一个每次运行成本高出 30% 但首次尝试就成功的图，比一个需要运行三次的循环更便宜。如果端到端确实成本更高，你很可能扇出过度了——并非每个步骤都需要并行化。

**问题：它能运行，但你无法解释原因**

这是图本应消除的失败，却被重新引入进来。

> 修复方案：在每个超级步骤设置检查点，并使用追加专用状态。如果你无法从一个检查点重放一次运行并得到相同的结果，那你拥有的不是可观测性——只不过是一个多了几个步骤的循环而已。

## 那 70% 究竟从何而来

节省不来自单一因素，而来自四个方面，且它们会相互叠加。

1. **上下文停止累积。** 在循环中，第十轮会携带第一轮到第九轮的所有内容。在图中，每个节点只接收它所需要的内容。研究员的原始搜索结果永远不会到达写作者。写作者的起草过程永远不会到达验证器。

2. **框架开销消失。** LangGraph 与 AutoGen 之间的差距——在同一任务上大约是 2,000 个 token 对 8,000 个 token——几乎完全来自智能体间的闲聊：智能体相互重述上下文。图结构将那些对话转变为状态转换。

3. 更少的完整重跑。一个自我审批劣质草稿的循环会在交付时失败，你不得不重新跑整个流程。而带有独立验证节点的图会在内容发出之前捕获失败，条件边只将写作节点送回重试——而不是重跑整个研究流程。

4. 模型路由。批量工作在 K3 上运行。只有验证节点——最小的节点——才运行在 Opus 5 上。

**一个实际案例。** 每日研究简报，每月 1,000 次运行。请用你自己的数字替换。

作为循环，全部使用 Opus 5：

作为图，K3 负责工作，Opus 5 负责验证：

每次可接受输出的运行次数：约 1.15——验证器捕获问题，重试边只重跑一个节点，而非整条管道。

Kimi K3：1500 万输出 token，$15/百万 token = $225
Opus 5：230 万输出 token，$25/百万 token = 约 $58

合计：约 $283/月。

在这一场景下降低了 75%——考虑到扇出并行调用的开销后，算作 70%。

真正重要的数字不是每次调用的成本，而是每次完成并经过验证的输出的成本。一个图在单次运行上可能花费更多，但端到端来看仍然能大幅降低成本，因为它不再为同一份交付物反复付费三次。

在相信这些数字之前，先用你自己的工作负载跑一遍同样的计算。节省的结构可以复用；具体百分比完全取决于你当前的失败率有多高。

## **诚实的结论**

图工程是真正的转变，还是给旧想法贴了个新标签？

两者皆是。

命名是表面的。节点、边、状态、有向调度、状态机、多智能体编排——计算机科学在这些领域已深耕数十年，LangGraph、ADK 和 AutoGen 也已将其落地多年。这个术语很可能在几个月内就被下一个流行词埋葬，就像"循环工程"曾经的命运一样。

转变是真实的。三件事同时汇聚：模型变得足够强大，能够作为可靠的自主节点运行；框架足够成熟，能够稳定地连接它们；社区形成了共同的词汇体系。工程的关注点确实上移了一个层次——从编写单个智能体的行为，到设计一组智能体的组织方式。

这引出了一件有点有趣的事。在所有这些 AI 工作之后，我们最终需要的，是最古老的学科：如何运营一个组织。如何分工。如何定义角色。如何将执行者与审核者分开。如何在某个部分失败时保持整体不崩溃。

企业在这些问题上已经摸索了几个世纪。我们只是雇了一种新员工，然后开始重新追问同样的问题。

## **动手之前的三条原则**

不要为了用图而用图。如果循环能完成任务，就用循环。从一张能在餐巾纸上说清楚的图开始。

价值来自确定性，而非智能体数量。让模型负责判断，让代码处理回退，再配上一双独立的眼睛，其唯一职责就是找出问题。

图必须触及现实。真实的锚点——通过的测试、留存的用户、到账的资金。没有这些，无论工程多么精密，你只是建了一座组织更严密的幻觉工厂。

*教育性内容。框架 token 数据来源于特定任务的公开对比，并非通用基准。请在确定架构之前先用自己的工作负载进行测量。*

## **链接**

- Kimi K3：https://www.kimi.com（https://www.kimi.com/）

- Kimi Code CLI：https://github.com/MoonshotAI/kimi-code

- LangGraph：https://github.com/langchain-ai/langgraph

- 构建高效智能体（Anthropic）：https://www.anthropic.com/engineering/building-effective-agents

- Google ADK：https://google.github.io/adk-docs/

- 我的 Telegram：https://t.me/kirillk_web3

- 我的 Twitter/X：https://x.com/kirillk_web3

- 托管服务（全天候运行智能体）：https://ishosting.com/affiliate/NzE0MiM2