# what the hell is graph engineering really
**作者**: Towards AI
**日期**: 2026-07-19T17:18:27.000Z
**来源**: [https://x.com/towards_AI/status/2078892237287801283](https://x.com/towards_AI/status/2078892237287801283)
---
# AI engineering has a naming problem.
Every useful idea gets about six months before someone declares it dead.
Prompt engineering became context engineering. Context engineering became harness engineering. Then everyone started talking about loop engineering.
We barely finished drawing the circles.
Then Peter Steinberger, the creator of OpenClaw, posted:
Nine words. Thousands of likes. Immediate confusion.
Did the industry really invent another discipline overnight? Is Graph a new product? Did loops stop working?
Instead of guessing, we dug through the recent discussion, revisited Anthropic's agent workflow patterns, and looked at what Claude Code now calls dynamic workflows.
This is what we found.
No.
There is no new product called Graph. And loops are not going anywhere.
Something real did happen, though.
Over the past few months, we learned how to make one agent keep working. Now we need to design what happens when many agents, checks, branches, retries, and human decisions work together.
That larger structure is a graph.
## First, what made a loop different from a prompt?
A prompt asks an AI to do something once.
A loop gives it a goal, lets it act, checks the result, and sends it back to work when the result is wrong.
The basic shape is simple:
The loop is useful because the agent no longer needs a human to write every follow-up prompt.
"Fix the type errors" becomes:
1. Run the type checker.
2. Read the errors.
3. Fix them.
4. Run it again.
5. Stop when it passes or when the loop stops making progress.
A real loop needs an external verifier. A test either passes or fails. A build compiles or it does not. If the same agent writes the work and decides whether the work is good, you have built a very expensive machine for agreeing with itself.
It also needs state outside the conversation. The loop should remember what it tried, what failed, and which artifacts changed.
And it needs an exit. Success is one exit. A hard limit is the other.
Hanako's article on loop engineering explains this perfectly. The verifier, persistent state, and stop condition are what turn repeated prompting into a working system.
So far, so good.
The trouble starts when one loop is no longer enough.
## A graph is a map of who does what next
Graphs aren't far from what we already know.
In a graph, the individual pieces of work are nodes.
The connections between them are edges.
A node might be an agent investigating one file. It might be a test suite, a reviewer, an approval step, a stored artifact, or an ordinary deterministic script.
An edge says what can happen next.
It might carry data from one agent to another. It might express a dependency. It might only activate when a condition is true.
Several nodes can run at the same time. Their results can converge into one reviewer. A failed check can send the work back to a fixer. An external event can start an entire section of the graph.
Now put those pieces into a code review system.
A new pull request fans out to several audit agents. Their findings all go to a verifier. Confirmed problems go to a fixer, then to the test suite.
If the tests fail, the work goes back to the fixer. If they pass, the review is published.
Now redraw the same system as nodes and edges. It becomes a graph containing a loop:
The graph is the whole system. The loop is only the retry path between fixing and testing.
This is why "loops versus graphs" is the wrong argument. Graphs have loops.
## Wait, isn't this just workflow engineering?
Mostly, yes.
Anthropic published Building effective agents in 2024. It drew a distinction between workflows, where LLMs and tools follow predefined code paths, and agents, where the model decides how to proceed.
The article laid out several workflow patterns:
- Prompt chaining is a straight path through several nodes.
- Routing is a conditional branch.
- Parallelization fans work out and collects the results.
- Orchestrator-workers creates tasks dynamically and delegates them.
- Evaluator-optimizer sends work around a loop until it improves.
Draw any of those patterns on a whiteboard and you get a graph.
So Graph Engineering is not a replacement for Anthropic's workflows. It just means drawing the full map of how work moves between agents, tools, and checks.
Workflow engineering asks what happens inside one process.
Graph engineering zooms out. It asks how the larger system connects, what can trigger each part, what information moves between them, and who decides when they disagree.
That information is the system's state. It includes which tasks are finished, what each agent produced, which checks failed, and whether a human approved the next step.
The graph is the map of possible paths. The state tells the system where it is on that map and what has happened so far.
The underlying computer science is not new. Workflow engines, DAG schedulers, state machines, and distributed systems have worked this way for years.
## Why graph engineering is becoming relevant now
What has changed is the kind of work happening inside some nodes. A normal workflow step follows fixed rules.
An agent interprets the task from its current context, so it can misunderstand the instruction or choose differently on the next run.
One chat window can hide a surprising amount of bad architecture.
The model decides what happens next. Results pile up in its context. Verification is mixed with generation. State exists wherever the conversation happens to remember it.
That works for small jobs.
But it gets fragile when a job spans hundreds of files, several repositories, multiple data sources, or hours of work.
The agent can forget why a branch exists. Review results can contaminate the next step. A failed task may have no clean restart point.
One giant context window becomes the database, scheduler, log, and project manager.
Graphs force those relationships into the open.
You have to decide:
- Which work can run in parallel?
- What state crosses from one node to another?
- Which result counts as evidence?
- Who can reject a result?
- Which failures should retry?
- What survives a restart?
- Where does human approval belong?
- How much can the system spend before it stops?
Those were always engineering questions. Agent frameworks made them easy to postpone because the model could improvise the missing structure for a while.
But with the graph, you must define what context each agent receives, where its result goes, and what must verify that result before the system continues.
And when the graph is written as code, its weak points become easier to find. You can see where work branches, what state moves around, what should retry, and where human approval is missing.
When something breaks, you can fix the workflow itself instead of hoping the model remembers what went wrong.
Claude Code's dynamic workflows are one concrete example of what that looks like.
## Claude Code gave the graph a runtime
Anthropic's 2024 article Building effective agents described the patterns.
Its newer Claude Code guide shows how Claude can turn those patterns into programs it can run.
With a dynamic workflow, Claude writes the plan as a JavaScript program.
That program can spawn subagents, run independent jobs at the same time, send their results through review, and retry failed work.
A background runtime follows the program, so Claude does not have to direct every step inside the chat.
Anthropic describes this in one sentence:
> "A workflow moves the plan into code."
With ordinary subagents, Claude decides what happens next turn by turn, and each result returns to its context.
With a dynamic workflow, the script holds the branches, retries, and intermediate results. The runtime coordinates the work and returns the final result.
Anthropic does not call this Graph Engineering. Mario Zechner's advice was to start with Anthropic's dynamic workflows, recognize the directed graph underneath them, and then ask how external events could trigger other subgraphs:
> "start here. then think about what this actually is (a directed graph). then think about how you'd marry triggering (sub-)graphs via external events."
That last part pushes the idea beyond one Claude Code run. If external events can trigger whole subgraphs, those workflows can be joined into something much larger.
Once you see that, the "graphs" joke stops looking completely random.
Before going further, one distinction matters: some graphs only move forward, while others contain loops.
## DAGs, cycles, and why the difference matters
Some agent workflows are directed acyclic graphs, usually shortened to DAGs.
Directed means each connection has a direction.
Acyclic means the workflow never returns to an earlier node. Work moves forward until it finishes.
A research workflow can be a DAG:
Every stage runs once. Nothing travels backward.
Now add a verifier that rejects unsupported claims and sends them back for more research. The workflow has a cycle.
The difference matters because retries introduce cost, state, and stopping problems that a simple DAG does not have.
The graph needs to know which work can be reused, which branches must run again, and when repeated failures should stop the run.
## A useful graph does more than move work
So far, we have used the graph to answer one question: what runs next?
That is the execution side of the system. It handles branches, parallel work, reviews, retries, and handoffs. Claude Code's dynamic workflows make this concrete.
But the graph can also check whether all that work is still moving toward the right goal. Carlos E. Perez explains this perfectly.
Imagine a customer-support agent rewarded for closing tickets quickly.
The agent improves. Resolution time drops.
But customers start leaving because the agent learned to close difficult conversations instead of solving them.
The loop worked. Its metric was bad.
This is Goodhart's law in production: once a measure becomes the target, the system finds ways to improve the measure without improving the reality it was supposed to represent.
That is exactly the kind of problem the rest of the graph should catch.
The ticket-closing loop should not rely on closing speed alone. The graph can connect it to other signals, such as customer retention and reopened tickets.
Those signals answer the question that closing speed cannot: were customers actually helped?
If tickets close faster while customer retention falls, the graph can flag the conflict and ask a human to step in.
In implementation, this is one graph doing two jobs. The execution side closes the tickets. The control side checks whether customers were helped.
Good graph engineering connects both.
That check only works when the graph is grounded by evidence from the real world.
## Graphs can still produce extremely organized nonsense
Adding more agents does not create independent judgment by itself.
Twenty agents using the same model, reading the same flawed context, and checking the same broken metric can agree with one another at industrial scale.
Graph can multiplies mistakes as efficiently as it multiplies useful work.
A graph can also become circular in a more dangerous way. One agent checks a report against another report. An audit agent checks both against a dashboard. The dashboard was built from the same underlying data. Every node agrees. Nothing touches reality.
The system looks well governed because the diagram has reviewers everywhere.
It is still wrong.
This is why the idea of reality anchors matters.
Some evidence must come from outside the agent system:
- tests that actually ran
- money that reached the bank
- customers who stayed
- measurements taken from the physical system
- rules the optimizer cannot quietly rewrite
- human judgment about what "better" means
Without anchors, a graph is a larger hallucination with better project management.
## So what does a graph engineer actually do?
Probably the same work good distributed-systems and workflow engineers have been doing for years, now applied to agents.
They design boundaries.
They decide which tasks deserve probabilistic agents and which should remain ordinary code. They define the state passed between workers. They separate the maker from the checker. They choose retry rules, timeouts, budgets, permissions, and stop conditions.
They also decide who has authority.
Can a reviewer block a deployment? Can an optimizing agent alter its own tests? Can one subgraph trigger another? Which external events are trusted? When does the system have to wake a human?
Prompt engineering was mostly about communicating intent to a model.
Loop engineering is about building a process that keeps pursuing that intent.
Graph engineering is about designing the relationships between those processes.
The name is new. But most of the hard problems are not.
## Start with the loop
Please do not respond to this article by building a 40-agent graph.
Start with one recurring task.
Give it a real verifier. Store its state somewhere you can inspect. Add a hard stop. Run it enough times to understand how it fails.
Then draw what has to happen around it.
Maybe a second agent should review the result. Maybe five independent branches can run at once. Maybe a security check needs veto power. Maybe a failed test should restart one branch without rerunning the whole system. Maybe a pull request, webhook, or scheduled event should trigger the process automatically.
At that point, you have a graph.
You did not abandon the loop. You gave it neighbors, supervision, memory, and somewhere honest to report failure.
That is graph engineering, at least until someone gives it a new name next week.
## 相关链接
- [Towards AI](https://x.com/towards_AI)
- [@towards_AI](https://x.com/towards_AI)
- [1.1K](https://x.com/towards_AI/status/2078892237287801283/analytics)
- [Hanako's article on loop engineering](https://x.com/hanakoxbt/status/2077387678241141070)
- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Claude Code guide](https://code.claude.com/docs/en/workflows)
- [Carlos E. Perez explains this perfectly](https://x.com/IntuitMachine/status/2078419526354378975)
- [Goodhart's law](https://en.wikipedia.org/wiki/Goodhart's_law)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:18 AM · Jul 20, 2026](https://x.com/towards_AI/status/2078892237287801283)
- [1,174 Views](https://x.com/towards_AI/status/2078892237287801283/analytics)
- [View quotes](https://x.com/towards_AI/status/2078892237287801283/quotes)
---
*导出时间: 2026/7/20 13:11:39*
---
## 中文翻译
# 图工程到底是个什么鬼东西
**作者**: Towards AI
**日期**: 2026-07-19T17:18:27.000Z
**来源**: [https://x.com/towards_AI/status/2078892237287801283](https://x.com/towards_AI/status/2078892237287801283)
---
# AI 工程有一个命名问题。
每一个有用的想法大约只有六个月的寿命，随后就会有人宣告它已死亡。
提示工程变成了上下文工程。上下文工程变成了线束工程。接着，所有人又开始谈论循环工程。
我们还没画完那些圈圈。
然后，OpenClaw 的创建者 Peter Steinberger 发布了：
九个字。成千上万的点赞。随之而来的困惑。
这个行业真的在一夜之间发明了一个新学科吗？Graph 是一个新产品吗？循环不再起作用了吗？
与其猜测，我们深入挖掘了最近的讨论，重温了 Anthropic 的智能体工作流模式，并查看了一下 Claude Code 现在所谓的动态工作流。
这是我们的发现。
不。
并没有一个叫 Graph 的新产品。而且循环也不会消失。
不过，确实发生了一些真实的事情。
在过去几个月里，我们学会了如何让一个智能体持续工作。现在，我们需要设计当许多智能体、检查、分支、重试和人类决策协同工作时会发生什么。
那个更大的结构就是一个图。
## 首先，循环与提示有何不同？
提示是要求 AI 做一次某事。
循环则是给它一个目标，让它行动，检查结果，并在结果错误时让它继续工作。
基本形状很简单：
循环之所以有用，是因为智能体不再需要人类来编写每一个后续提示。
“修复类型错误”变成了：
1. 运行类型检查器。
2. 读取错误。
3. 修复它们。
4. 再次运行。
5. 当通过检查或循环停止取得进展时停止。
一个真正的循环需要一个外部验证器。测试要么通过，要么失败。构建要么编译成功，要么不成功。如果同一个智能体既负责编写工作，又负责判断工作是否优秀，你就构建了一台非常昂贵的、只会自我认同的机器。
它还需要对话之外的状态。循环应该记住它尝试了什么、什么失败了，以及哪些工件发生了变化。
而且它需要一个出口。成功是一个出口。硬性限制是另一个出口。
Hanako 关于循环工程的文章完美地解释了这一点。验证器、持久状态和停止条件是将重复的提示转化为工作系统的关键。
到目前为止，一切顺利。
当一个循环不再足够时，麻烦就开始了。
## 图是关于下一步由谁来做什么的地图
图离我们已知的东西并不远。
在图中，独立的工作单元是节点。
它们之间的连接是边。
一个节点可能是一个正在调查某个文件的智能体。它可能是一个测试套件、一个审查者、一个批准步骤、一个存储的工件，或者一个普通的确定性脚本。
一条边说明了接下来可能发生什么。
它可能将数据从一个智能体传递到另一个智能体。它可能表示依赖关系。它可能只在条件为真时才激活。
几个节点可以同时运行。它们的结果可以汇聚到一个审查者那里。一次失败的检查可以将工作发回给修复者。一个外部事件可以启动图的整个部分。
现在，把这些部件放入一个代码审查系统中。
一个新的拉取请求会分发到几个审计智能体。它们的发现都汇集到一个验证器。确认的问题会发送给修复者，然后发送到测试套件。
如果测试失败，工作会返回给修复者。如果通过，审查就会发布。
现在，用节点和边重画同一个系统。它变成了一个包含循环的图：
图是整个系统。循环只是修复和测试之间的重试路径。
这就是为什么“循环与图之争”是一个错误的论点。图中包含循环。
## 等等，这不就是工作流工程吗？
大部分是的。
Anthropic 在 2024 年发布了《构建有效的智能体》。它区分了工作流（即 LLM 和工具遵循预定义的代码路径）和智能体（即模型决定如何进行）。
这篇文章列出了一些工作流模式：
- 提示链是一条穿过多个节点的直线路径。
- 路由是一个条件分支。
- 并行化将工作分发出去并收集结果。
- 编排器-工作者动态创建任务并委派它们。
- 评估器-优化器让工作在循环中流转，直到它得到改进。
在白板上画出这些模式中的任何一个，你都会得到一个图。
因此，图工程并不是 Anthropic 工作流的替代品。它只是意味着绘制出工作如何在智能体、工具和检查之间移动的完整地图。
工作流工程询问的是在一个过程内部发生了什么。
图工程则是拉远视角。它询问更大的系统是如何连接的，什么可以触发每个部分，什么信息在它们之间移动，以及当它们出现分歧时由谁来决定。
那个信息就是系统的状态。它包括哪些任务已完成、每个智能体产生了什么、哪些检查失败了，以及人类是否批准了下一步。
图是可能路径的地图。状态告诉系统它在该地图上的位置以及迄今为止发生了什么。
底层的计算机科学并不新鲜。工作流引擎、DAG 调度器、状态机和分布式系统多年来都是这样工作的。
## 为什么图工程现在变得相关了
发生变化的是某些节点内部发生的工作类型。一个正常的工作流步骤遵循固定的规则。
智能体会根据其当前上下文解释任务，因此它可能会误解指令，或者在下次运行时做出不同的选择。
一个聊天窗口可以隐藏惊人的糟糕架构。
模型决定下一步发生什么。结果堆积在其上下文中。验证与生成混合在一起。状态存在于对话恰好记住它的任何地方。
这对于小任务是有效的。
但是，当一个任务跨越数百个文件、几个存储库、多个数据源或数小时的工作时，它就会变得脆弱。
智能体可能会忘记某个分支存在的原因。审查结果可能会污染下一步。一个失败的任务可能没有干净的重新启动点。
一个巨大的上下文窗口变成了数据库、调度器、日志和项目经理。
图迫使这些关系公开化。
你必须决定：
- 哪些工作可以并行运行？
- 什么状态从一个节点跨越到另一个节点？
- 哪个结果算作证据？
- 谁可以拒绝一个结果？
- 哪些失败应该重试？
- 什么能在重新启动后存活下来？
- 人类的批准应该放在哪里？
- 系统在停止之前可以花费多少？
这些一直都是工程问题。智能体框架使得这些问题很容易被推迟，因为模型可以即兴发挥缺失的结构一段时间。
但是有了图，你必须定义每个智能体接收什么上下文，其结果去向何处，以及在系统继续之前必须验证什么结果。
当图被写成代码时，它的弱点就变得更容易发现。你可以看到工作在哪里分支，什么状态在移动，什么应该重试，以及哪里缺少人工批准。
当出现问题时，你可以修复工作流本身，而不是希望模型记住出了什么问题。
Claude Code 的动态工作流就是这种样子的一个具体例子。
## Claude Code 给图提供了一个运行时
Anthropic 2024 年的文章《构建有效的智能体》描述了这些模式。
其较新的 Claude Code 指南展示了 Claude 如何将这些模式转化为它可以运行的程序。
通过动态工作流，Claude 将计划编写为一个 JavaScript 程序。
该程序可以生成子智能体，同时运行独立的工作，将它们的结果通过审查，并重试失败的工作。
一个后台运行时跟随该程序，因此 Claude 不必在聊天中指导每一个步骤。
Anthropic 用一句话描述了这一点：
> “工作流将计划移入代码。”
对于普通的子智能体，Claude 逐轮决定接下来发生什么，每个结果都返回到其上下文中。
对于动态工作流，脚本持有分支、重试和中间结果。运行时协调工作并返回最终结果。
Anthropic 并不称此为图工程。Mario Zechner 的建议是从 Anthropic 的动态工作流开始，识别其底层的有向图，然后询问外部事件如何触发其他子图：
> “从这里开始。然后思考这实际上是什么（一个有向图）。然后思考你如何通过外部事件来触发（子）图。”
最后一部分将这一想法推超出了单次 Claude Code 运行的范畴。如果外部事件可以触发整个子图，那么这些工作流就可以连接成一个更大的东西。
一旦你看到了这一点，“图”的玩笑就不再看起来完全是随机的了。
在继续之前，有一个区别很重要：有些图只向前移动，而另一些则包含循环。
## DAG、循环，以及为什么区别很重要
一些智能体工作流是有向无环图，通常简称为 DAG。
有向意味着每个连接都有一个方向。
无环意味着工作流永远不会返回到先前的节点。工作向前移动直到完成。
一个研究工作流可以是一个 DAG：
每个阶段运行一次。没有任何东西向后移动。
现在添加一个验证器，拒绝无根据的声明并将它们发回进行更多研究。工作流就有了一个循环。
这种区别之所以重要，是因为重试引入了简单的 DAG 所没有的成本、状态和停止问题。
图需要知道哪些工作可以重用，哪些分支必须再次运行，以及何时重复的失败应该停止运行。
## 一个有用的图不仅仅是移动工作
到目前为止，我们使用图来回答一个问题：接下来运行什么？
那是系统的执行端。它处理分支、并行工作、审查、重试和交接。Claude Code 的动态工作流使这一点变得具体。
但是图也可以检查所有这些工作是否仍在朝着正确的目标前进。Carlos E. Perez 完美地解释了这一点。
想象一个客服智能体因快速关闭工单而受到奖励。
智能体得到了改进。解决时间下降了。
但客户开始流失，因为智能体学会了关闭困难的对话，而不是解决它们。
循环起作用了。但它的指标很糟糕。
这就是生产环境中的古德哈特定律：一旦一个指标成为目标，系统就会找到改进该指标的方法，而无需改进它本应代表的现实。
这正是图的其余部分应该捕捉的那种问题。
关闭工单的循环不应仅依赖关闭速度。图可以将其与其他信号连接起来，例如客户留存和重新打开的工单。
这些信号回答了关闭速度无法回答的问题：客户真的得到了帮助吗？
如果工单关闭得更快而客户留存率下降，图可以标记这种冲突并要求人类介入。
在实现中，这是一个图在做两份工作。执行端关闭工单。控制端检查客户是否得到了帮助。
良好的图工程将两者连接起来。
只有当图以来自现实世界的证据为基础时，这种检查才有效。
## 图仍然可能产生极其有条理的无稽之谈
添加更多智能体本身并不能创造独立的判断。
二十个使用相同模型、阅读相同有缺陷上下文并检查相同损坏指标的智能体可以以工业规模相互认同。
图可以像它成倍增加有用工作一样，高效地成倍增加错误。
图也可能以更危险的方式变得循环。一个智能体根据另一个报告检查报告。一个审计智能体根据仪表板检查两者。仪表板是来自相同底层数据构建的。每个节点都表示同意。没有任何东西触及现实。
该系统看起来治理良好，因为图表上到处都是审查者。
但它仍然是错误的。
这就是为什么现实锚点的概念很重要。
一些证据必须来自智能体系统之外：
- 实际运行的测试
- 到达银行的钱
- 留下来的客户
- 从物理系统进行的测量
- 优化器不能悄悄重写的规则
- 关于“更好”意味着什么的人类判断
没有锚点，图只是一个拥有更好项目管理的更大的幻觉。
## 那么图工程师实际上是做什么的？
可能所做的与优秀的分布式系统和工作流工程师多年来的工作相同，现在只是应用于智能体。
他们设计边界。
他们决定哪些任务值得使用概率性智能体，哪些应保留为普通代码。他们定义在工作之间传递的状态。他们将制造者与检查者分开。他们选择重试规则、超时、预算、权限和停止条件。
他们也决定谁拥有权限。
审查者可以阻止部署吗？优化智能体可以更改它自己的测试吗？一个子图可以触发另一个吗？哪些外部事件是受信任的？系统什么时候必须唤醒人类？
提示工程主要是关于向模型传达意图。
循环工程是关于构建一个持续追求该意图的过程。
图工程是关于设计这些过程之间的关系。
名称是新的。但大多数困难的问题并不是。
## 从循环开始
请不要通过构建一个包含 40 个智能体的图来回复这篇文章。
从一个重复性任务开始。
给它一个真正的验证器。将其状态存储在你可以检查的地方。添加一个硬性停止。运行它足够多次以了解它如何失败。
然后，画出必须在其周围发生的事情。
也许第二个智能体应该审查结果。也许五个独立的分支可以一次运行。也许安全检查需要否决权。也许失败的测试应该在不重新运行整个系统的情况下重新启动一个分支。也许拉取请求、webhook 或计划事件应该自动触发该过程。
那时，你就有了一个图。
你没有放弃循环。你给了它邻居、监督、记忆和一个诚实的失败报告地点。
这就是图工程，至少直到下周有人给它起个新名字为止。
## 相关链接
- [Towards AI](https://x.com/towards_AI)
- [@towards_AI](https://x.com/towards_AI)
- [1.1K](https://x.com/towards_AI/status/2078892237287801283/analytics)
- [Hanako's article on loop engineering](https://x.com/hanakoxbt/status/2077387678241141070)
- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents)
- [Claude Code guide](https://code.claude.com/docs/en/workflows)
- [Carlos E. Perez explains this perfectly](https://x.com/IntuitMachine/status/2078419526354378975)
- [Goodhart's law](https://en.wikipedia.org/wiki/Goodhart%27s_law)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [1:18 AM · Jul 20, 2026](https://x.com/towards_AI/status/2078892237287801283)
- [1,174 Views](https://x.com/towards_AI/status/2078892237287801283/analytics)
- [View quotes](https://x.com/towards_AI/status/2078892237287801283/quotes)
---
*导出时间: 2026/7/20 13:11:39*