If you’ve been on AI Twitter at any point in the last year you have watched the same argument play out about a hundred times. Someone says you should build multi-agent systems. Someone else says you definitely shouldn’t. A third person says it depends. Everyone moves on, nothing is resolved, and the argument restarts a week later under a slightly different topic.如果你在过去一年里的任何时候关注过 AI 领域的 Twitter，你一定看过同样的争论上演了不下百次。有人说你应该构建多智能体系统，另一个人说你绝对不应该，第三个人则说“视情况而定”。大家各抒己见，问题始终没有解决，一周后同样的争论又换个话题重新开始。
The cleanest version of this happened in June 2025. Within about 48 hours of each other, Walden Yan at Cognition published an essay called “Don’t Build Multi-Agents” and Anthropic published “How we built our multi-agent research system”. Yan argued that multi-agent architectures produce fragile systems because of poor context sharing and conflicting decisions between agents. Anthropic argued that their multi-agent Research feature outperformed a single-agent baseline by more than 90% on certain tasks. Same week. Opposite conclusions. Both from people who obviously know what they’re talking about.这场争论最清晰的一次体现发生在 2025 年 6 月。在短短 48 小时内，Cognition 公司的 Walden Yan 发表了一篇题为《不要构建多智能体》的文章，而 Anthropic 则发布了《我们是如何构建多智能体研究系统的》。Yan 认为，由于上下文共享不佳和智能体之间决策冲突，多智能体架构会产生脆弱的系统。Anthropic 则认为，他们的多智能体研究功能在某些任务上比单智能体基准表现高出 90% 以上。同一周，截然相反的结论，且都出自显然深谙此道的专家之口。
The discourse around this has been less illuminating than you’d hope. Half the takes are “well it depends on your use case” which is true but unhelpful. The other half are partisans for one camp or the other. Almost nobody points out that Cognition and Anthropic are not actually disagreeing about the same thing.围绕这一话题的讨论并没有预想中那么有启发性。一半的观点是“这取决于你的用例”，这话没错但毫无帮助；另一半则是各阵营的拥趸。几乎没有人指出，Cognition 和 Anthropic 实际上争论的根本不是同一件事。
The reason this argument never goes anywhere is that the word “orchestration” is doing too much work. When two people argue about agent orchestration, they are often arguing about three completely different layers of the stack without realizing it. Once you separate them, the entire discourse gets clearer, the Cognition versus Anthropic standoff stops looking like a contradiction, and a recent release from Google (yes, also confusingly called AX; no relation to ours) suddenly makes a lot of sense.这场争论之所以毫无进展，是因为“编排”（orchestration）这个词承载了太多的含义。当两个人争论智能体编排时，他们往往是在讨论技术栈中三个完全不同的层面而不自知。一旦将它们拆解开来，整个讨论就会变得清晰，Cognition 与 Anthropic 的对峙看起来就不再是矛盾的，而 Google 最近发布的产品（是的，也叫 AX，容易混淆，与我们的无关）也突然变得合情合理了。
But first: what is agent orchestration?但首先：什么是智能体编排？
Agent orchestration is the coordination of AI agent behavior across three layers:智能体编排是指在以下三个层面协调 AI 智能体的行为：
- Expression (frameworks and control flow)表达（框架和控制流）
- Runtime (execution, recovery, durability)运行时（执行、恢复、持久性）
- Observability (tracing, evaluation, debugging)可观测性（追踪、评估、调试）
Most debates about agent orchestration focus on only one of these layers.大多数关于智能体编排的辩论只关注其中一个层面。
Three layers, not one debate三个层面，而非单一辩论
When people say “agent orchestration” they could mean any of three different layers, and these layers have very different problems, very different vendors, and very different right answers.当人们说“智能体编排”时，他们可能指的是这三个不同层面中的任何一个，而这些层面有着截然不同的问题、供应商和正确答案。
Layer one is expression. This is how you write down what your agent does. LangGraph, CrewAI, AutoGen, Google’s ADK, Mastra, OpenAI’s Agents SDK, the new wave of “deep agents” frameworks. The question this layer answers is: what does my agent’s control flow look like in code? Is it a graph? A state machine? A loop with tools? Hierarchical handoffs? This is where most of the framework discourse lives.第一层是表达。这是你定义智能体行为的方式。LangGraph、CrewAI、AutoGen、Google 的 ADK、Mastra、OpenAI 的 Agents SDK，以及新一波的“深度智能体”框架。这一层回答的问题是：我的智能体控制流在代码中是什么样的？是图结构？状态机？带工具的循环？还是分层移交？大多数关于框架的讨论都集中在这里。
Layer two is runtime. This is how your agent actually runs, recovers from failures, resumes after crashes, and persists state across long-running executions. Temporal. Restate. Cloudflare Workflows. Microsoft’s Durable Task. LangSmith Deployment (formerly LangGraph Platform). And now google/ax, which is explicit about being a runtime and not a framework — its README literally says it is “agnostic of the framework used to build agents.” The question this layer answers is: when my agent runs for three hours and a worker dies in minute 47, what happens?第二层是运行时。这是你的智能体实际运行、从故障中恢复、崩溃后重启以及在长时间执行中保持状态的方式。Temporal、Restate、Cloudflare Workflows、Microsoft 的 Durable Task、LangSmith Deployment（前身为 LangGraph Platform）。现在还有 google/ax，它明确表示自己是一个运行时而非框架——其 README 中明确写道：“与构建智能体所使用的框架无关”。这一层回答的问题是：当我的智能体运行了三个小时，而在第 47 分钟工作节点挂了，会发生什么？
Layer three is observability. This is how you see what your agents actually did, evaluate whether they did it well, and debug when they didn’t. Traces, evals, judges, replays. The question this layer answers is: when the demo works but production doesn’t, how do you find out why?第三层是可观测性。这是你观察智能体实际行为、评估其表现并进行调试的方式。追踪、评估、评判、重放。这一层回答的问题是：当演示环境运行正常但生产环境不行时，你如何找出原因？
The Cognition versus Anthropic argument is entirely a layer-one argument. It’s about how to express your agent. Single thread or many threads? Centralized context or distributed? It is interesting and it matters, but it is one debate, in one layer, and the partisans of each side mostly agree about layers two and three. Both Cognition and Anthropic care a lot about context management, both invest heavily in observability, and both assume a robust runtime underneath.Cognition 与 Anthropic 的争论完全属于第一层。它关乎如何表达你的智能体。单线程还是多线程？集中式上下文还是分布式？这很有趣也很重要，但这只是一个层面上的一个辩论，双方的拥趸在第二层和第三层上基本达成共识。Cognition 和 Anthropic 都非常重视上下文管理，都在可观测性上投入了大量资金，并且都假设底层有一个稳健的运行时。
Once you separate the layers, the perpetual orchestration debate becomes much less confusing. You can have opinions about each one independently. The “right” answer at layer one depends entirely on the shape of your task. Layer two is increasingly a solved problem with off-the-shelf options. Layer three is where most teams are still flying blind, and where the research suggests the actual returns are.一旦你将这些层面分开，永无止境的编排辩论就会变得不那么令人困惑。你可以独立地对每一个层面持有观点。第一层的“正确”答案完全取决于你的任务形态。第二层正逐渐成为一个通过现成方案解决的问题。第三层则是大多数团队仍处于盲目状态的地方，也是研究表明真正能带来回报的地方。
Layer one: the expression debate第一层：表达之争
The thing that finally made the Cognition versus Anthropic standoff make sense to me was noticing that they’re optimizing for different task topologies.最终让我理解 Cognition 与 Anthropic 对峙的原因是，我注意到他们是在为不同的任务拓扑结构进行优化。
Anthropic’s Research agent is broad and parallel. It needs to comb through hundreds of websites quickly. Each subagent can work in isolation on its own slice of the search space, then the supervisor synthesizes. This is embarrassingly parallel work, and a multi-agent fan-out structure makes obvious sense. As Anthropic noted, the tradeoff is that they burn roughly 15 times the tokens of a normal chat — but for research, that’s worth it.Anthropic 的研究智能体是广泛且并行的。它需要快速梳理数百个网站。每个子智能体可以在搜索空间的各自切片上独立工作，然后由主管进行综合。这是典型的“尴尬并行”工作，多智能体扇出结构显然是有意义的。正如 Anthropic 所指出的，代价是它们消耗的 Token 大约是普通聊天的 15 倍——但对于研究任务来说，这是值得的。
Cognition’s Devin is deep and sequential. Writing code requires every step to be informed by every previous step. If you fan out parallel coding agents, they’ll make conflicting decisions about variable names, architectural patterns, and which library to use, and you’ll spend more effort reconciling them than you saved by parallelizing. So Devin keeps a single thread of reasoning with a continuous context.Cognition 的 Devin 是深度且顺序的。编写代码要求每一步都基于前一步的信息。如果你扇出并行编码智能体，它们会在变量名、架构模式和使用哪个库的问题上做出冲突的决策，你花在协调它们上的精力将超过并行化节省的时间。因此，Devin 保持了一个具有连续上下文的单一推理线程。
Yan’s two principles from the Cognition post are worth quoting because they generalize beyond coding:Yan 在 Cognition 文章中提出的两个原则值得引用，因为它们可以推广到编码之外的领域：
- Agents must share full context, including complete agent traces, not just isolated messages.智能体必须共享完整上下文，包括完整的智能体追踪记录，而不仅仅是孤立的消息。
- Every action carries implicit decisions that can conflict if not properly aligned.每一个动作都包含隐含的决策，如果不对齐，就会产生冲突。
The first principle says: if you’re going to have multiple agents, don’t let them communicate by passing terse messages. They need to see each other’s full reasoning, or they’ll diverge. The second says: agents make a lot of micro-decisions implicitly during execution, and parallel agents will make incompatible micro-decisions you didn’t anticipate.第一个原则说：如果你打算使用多个智能体，不要让它们通过传递简短的消息来沟通。它们需要看到彼此完整的推理过程，否则就会产生分歧。第二个原则说：智能体在执行过程中会隐式地做出大量微决策，而并行智能体会做出你未曾预料到的不兼容的微决策。
Notice that neither of these is an argument against multi-agent systems per se. They’re arguments for a particular kind of multi-agent system: one with rich context sharing and aligned decision-making. Anthropic agrees with both principles; they just argue you can satisfy them with careful design. Harrison Chase made roughly this point about a week after both posts: “despite their opposing titles, I would argue they actually have a lot in common.”请注意，这两点都不是反对多智能体系统本身的论据。它们是针对特定类型多智能体系统的论据：即那些具有丰富上下文共享和对齐决策机制的系统。Anthropic 同意这两个原则；他们只是认为可以通过精心的设计来满足这些要求。Harrison Chase 在两篇文章发布后大约一周提出了类似的观点：“尽管标题对立，但我认为它们实际上有很多共同点。”
This is why Andrej Karpathy’s framing of context engineering as “the delicate art and science of filling the context window with just the right information for the next step” has eaten the field. Cognition’s post argues that context engineering is “effectively the #1 job of engineers building AI agents” — a phrase Harrison Chase has adopted and amplified ever since. Whether you’re team single-agent or team multi-agent, you’re really arguing about how to do context engineering at scale.这就是为什么 Andrej Karpathy 将上下文工程定义为“将恰当的信息填入上下文窗口以进行下一步的精妙艺术与科学”这一框架能够风靡该领域的原因。Cognition 的文章认为，上下文工程是“构建 AI 智能体的工程师的首要工作”——这一说法被 Harrison Chase 采纳并推广至今。无论你是单智能体派还是多智能体派，你实际上争论的都是如何大规模地进行上下文工程。
The MAST paper from UC Berkeley (Cemri et al, NeurIPS 2025) backs this up empirically. The authors analyzed 1,642 execution traces from seven popular multi-agent frameworks — ChatDev, MetaGPT, HyperAgent, AppWorld, AG2, Magentic-One, OpenManus — and found failure rates between 41% and 86.7%. They built a taxonomy of 14 failure modes in three categories: system design issues (41.8%), inter-agent misalignment (36.9%), and task verification (21.3%). Their key finding, which I’ll quote because it’s good: “Successful systems all work alike; each failing system has its own problems.” Most failures are not model limitations. They are organizational design failures. The paper invokes Charles Perrow’s Normal Accidents — failures emerge from how the system is structured, not from the capability of any individual component.来自加州大学伯克利分校的 MAST 论文（Cemri 等人，NeurIPS 2025）从实证角度支持了这一点。作者分析了七种流行多智能体框架（ChatDev、MetaGPT、HyperAgent、AppWorld、AG2、Magentic-One、OpenManus）的 1,642 条执行追踪记录，发现故障率在 41% 到 86.7% 之间。他们构建了一个包含三类 14 种故障模式的分类法：系统设计问题（41.8%）、智能体间不对齐（36.9%）和任务验证（21.3%）。他们的关键发现值得引用：“成功的系统都有相似之处；而失败的系统各有各的问题。”大多数故障并非模型局限性，而是组织设计失败。该论文引用了 Charles Perrow 的“正常事故”理论——故障源于系统的结构方式，而非任何单个组件的能力。
In other words, layer one matters a lot, and you can get it badly wrong. But it’s also not where you’ll find the easy wins anymore. The frameworks have converged on a similar set of primitives (loops, tools, handoffs, supervisors) and the remaining differences are mostly ergonomic.换句话说，第一层非常重要，而且很容易出错。但它也不再是能轻易取得胜利的地方。各个框架已经收敛于一套相似的原语（循环、工具、移交、主管），剩下的差异大多是人体工程学上的。
Layer two: agents are getting their Kubernetes moment第二层：智能体正在迎来它们的 Kubernetes 时刻
Layer two is the most interesting layer to watch right now, and it’s the one that google/ax brings into sharp relief.第二层是目前最值得关注的层面，也是 google/ax 将其凸显出来的层面。
For years, “running an agent” meant calling an LLM in a while loop in a Python process. If the process died, the agent died. If the user disconnected, the agent died. If the LLM API hiccuped halfway through a 30-step research task, you either swallowed the error and corrupted state or threw away 29 steps of work. This was tolerable when agents were toys. It is not tolerable when OpenAI’s Codex is processing millions of coding tasks a day for paying customers.多年来，“运行智能体”意味着在 Python 进程的 while 循环中调用 LLM。如果进程挂了，智能体就挂了。如果用户断开连接，智能体就挂了。如果 LLM API 在 30 步研究任务进行到一半时卡顿，你要么吞下错误导致状态损坏，要么丢弃 29 步的工作。当智能体只是玩具时，这是可以容忍的。但当 OpenAI 的 Codex 每天为付费客户处理数百万个编码任务时，这就无法容忍了。
The runtime layer is what makes long-running, durable, recoverable agents possible. The pattern is borrowed almost wholesale from durable execution systems like Temporal, which have been doing this for distributed business workflows for years: an event log, deterministic replay, automatic retries, checkpointing, and resumption. The agent’s progress is journaled to durable storage. If the worker dies, another worker picks up exactly where the dead one left off, replaying the event log to reconstruct state.运行时层是使长时间运行、持久、可恢复的智能体成为可能的关键。这种模式几乎完全借鉴了 Temporal 等持久执行系统，这些系统多年来一直用于分布式业务工作流：事件日志、确定性重放、自动重试、检查点和恢复。智能体的进度被记录到持久存储中。如果工作节点挂了，另一个节点会从死掉的节点停止的地方接手，通过重放事件日志来重建状态。
This is no longer theoretical. OpenAI Codex runs on Temporal in production. Replit migrated its agent to Temporal for reliability. Microsoft’s durable task extension for the Microsoft Agent Framework shipped in late 2025 with explicit support for multi-day human-in-the-loop agent pauses. Cloudflare Workflows hit GA in 2025 with Python support and step-based durable execution that can run for weeks. LangChain has rebuilt its deployment platform (formerly LangGraph Platform, now LangSmith Deployment) around the same primitives and now markets it as letting you treat agents like real distributed systems.这不再是理论。OpenAI Codex 在生产环境中运行在 Temporal 上。Replit 将其智能体迁移到 Temporal 以提高可靠性。Microsoft 智能体框架的持久任务扩展于 2025 年底发布，明确支持多天的人机协作智能体暂停。Cloudflare Workflows 于 2025 年正式发布，支持 Python 和基于步骤的持久执行，可以运行数周。LangChain 重建了其部署平台（前身为 LangGraph Platform，现为 LangSmith Deployment），围绕相同的原语构建，并将其宣传为让你像对待真正的分布式系统一样对待智能体。
And then google/ax shipped, and Google’s framing is the cleanest articulation of what’s happening. From the README: “as agents evolve from simple assistants to autonomous long running workers, developers need a robust runtime to manage state, ensure reliability, and audit execution.” They explicitly call out single-writer architecture, event logs with automatic recovery, and resumable bidirectional streams. They explicitly disclaim being a framework or a managed service.然后 google/ax 发布了，Google 的表述是对正在发生的事情最清晰的阐述。摘自 README：“随着智能体从简单的助手演变为自主的长时间运行的工作者，开发者需要一个稳健的运行时来管理状态、确保可靠性并审计执行。”他们明确提到了单写架构、具有自动恢复功能的事件日志以及可恢复的双向流。他们明确声明自己不是框架或托管服务。
This is the part I find genuinely exciting, because it follows a pattern we’ve seen before in software. Web development went through this in the 2010s: first came the application frameworks (Rails, Django, Express), and once those stabilized people started realizing that the harder problem was the runtime underneath. That’s how we got Kubernetes. Agents are now at the equivalent moment. The frameworks have stabilized enough that the bottleneck has moved to the layer below.这是我感到真正兴奋的部分，因为它遵循了我们在软件领域见过的模式。Web 开发在 2010 年代经历了这一过程：首先是应用框架（Rails、Django、Express），一旦这些框架稳定下来，人们开始意识到更难的问题是底层的运行时。这就是我们得到 Kubernetes 的原因。智能体现在正处于类似的时刻。框架已经足够稳定，瓶颈已经转移到了下一层。
If you’re building an agent that needs to run for more than a few minutes, survive a deploy, or recover from a worker crash, you do not want to be writing your own retry logic and checkpointing. You want a runtime that handles it for you. This is increasingly available off the shelf.如果你正在构建一个需要运行几分钟以上、在部署中存活或从工作节点崩溃中恢复的智能体，你肯定不想自己编写重试逻辑和检查点。你需要一个为你处理这些问题的运行时。这在市面上正变得越来越容易获得。
Layer three: where the actual reliability problem lives第三层：真正的可靠性问题所在
The thing nobody wants to hear is that none of this matters if you can’t see what your agents are doing.没人愿意听的一点是：如果你看不见智能体在做什么，这一切都毫无意义。
Hamel Husain, who has consulted with 30+ AI teams, opens his “Field Guide to Rapidly Improving AI Products” with a scene that has played out for him repeatedly:曾为 30 多家 AI 团队提供咨询的 Hamel Husain 在他的《快速改进 AI 产品实战指南》中，以一个反复上演的场景作为开篇：
AI TEAM: Here’s our agent architecture — we’ve got RAG here, a router there, and we’re using this new framework for…AI 团队：这是我们的智能体架构——我们这里有 RAG，那里有路由器，我们正在使用这个新框架来……
ME: Can you show me how you’re measuring if any of this actually works? Room goes quiet.我：你能展示一下你是如何衡量这些东西是否真的有效吗？房间里安静了下来。
This is the part that ties everything together. Cognition and Anthropic both invest enormous engineering effort in observability because they have to. When your agent fails 50% of the time and the failure modes are subtle — step repetition, role disobedience, reasoning-action mismatch, premature termination — you cannot debug them from the outside. You cannot vibe-check your way to reliability when the MAST researchers needed 1,642 annotated traces and grounded theory analysis to figure out what was even going wrong.这就是将一切联系在一起的部分。Cognition 和 Anthropic 都投入了巨大的工程精力在可观测性上，因为他们必须这样做。当你的智能体有 50% 的时间失败，且故障模式非常微妙——步骤重复、不听指令、推理与动作不匹配、过早终止——你无法从外部调试它们。当 MAST 研究人员需要 1,642 条带注释的追踪记录和扎根理论分析才能弄清楚到底出了什么问题时，你不可能靠“感觉”来达到可靠性。
The MAST paper is, structurally, a giant argument for trace-level observability. The whole reason the authors could identify those 14 failure modes is that they had complete execution traces. The whole reason their MAST-Data dataset is useful is that other teams can now diagnose their own failure mode distributions and target interventions. A ChatDev agent terminating early gets fixed by giving the CEO agent final say — a 9.4% improvement. Adding a high-level verification step to ChatDev gets 15.6%. Those numbers are only available because someone is looking at the traces.从结构上讲，MAST 论文是对追踪级可观测性的巨大论证。作者之所以能识别出那 14 种故障模式，完全是因为他们拥有完整的执行追踪记录。MAST-Data 数据集之所以有用，是因为其他团队现在可以诊断自己的故障模式分布并进行针对性干预。ChatDev 智能体过早终止的问题通过赋予 CEO 智能体最终决定权得到了解决——提升了 9.4%。在 ChatDev 中增加一个高级验证步骤提升了 15.6%。这些数字之所以存在，是因为有人在查看追踪记录。
This is what AX is for. The argument we’d make is not that you need yet another framework, or that you need to rip out your runtime and start over. It’s that the entire field has now formally documented that production agents fail in ways that are invisible from outside, and that the teams winning at this are the ones who built the visibility first. AX is what visibility looks like when it’s built specifically for agents — traces, evals, judges, replay, all designed around how agentic systems actually fail. Not because observability is the most important layer (it isn’t, all three matter) but because it’s the one where the gap between what most teams have and what the leaders have is largest.这就是 AX 的用途。我们想表达的不是你需要另一个框架，也不是你需要拆掉运行时重新开始。而是整个领域已经正式记录了生产环境中的智能体以一种从外部无法察觉的方式失败，而在这个领域获胜的团队是那些优先构建可见性的团队。AX 就是专门为智能体构建的可见性——追踪、评估、评判、重放，所有这些都是围绕智能体系统实际失败的方式设计的。这并不是因为可观测性是最重要的层面（事实并非如此，三个层面都很重要），而是因为它是大多数团队与领先者之间差距最大的地方。
The synthesis总结
So when somebody asks you “what do you think about agent orchestration?”, the honest answer is “which part?”所以当有人问你“你对智能体编排怎么看？”时，诚实的回答是“指哪一部分？”
Layer one is the layer where most arguments happen, and most of those arguments are religious wars between people with different task topologies. The Cognition versus Anthropic debate is not actually a debate; it’s two correct answers to two different problems. Pick the structure that fits the shape of your task, do excellent context engineering regardless, and don’t be too precious about which framework you’re using to express it.第一层是大多数争论发生的层面，而这些争论大多是不同任务拓扑结构的人之间的宗教战争。Cognition 与 Anthropic 的辩论实际上并非辩论；它们是针对两个不同问题的两个正确答案。选择适合你任务形态的结构，无论如何都要做好上下文工程，并且不要太纠结于你使用哪个框架来表达它。
Layer two is the layer where the field is maturing fastest. The runtime question — how does your agent survive contact with reality — is being answered by an emerging consensus around durable execution primitives. Whether you’re on Temporal, Restate, LangSmith Deployment, Microsoft’s Durable Task, or eventually google/ax, the shape of the answer is becoming clear. You should probably not be building this from scratch.第二层是该领域成熟最快的层面。运行时问题——你的智能体如何与现实接触并存活下来——正通过围绕持久执行原语的新兴共识得到解答。无论你使用的是 Temporal、Restate、LangSmith Deployment、Microsoft 的 Durable Task，还是最终的 google/ax，答案的形态正变得清晰。你可能不应该从零开始构建它。
Layer three is the layer where the reliability dragons actually live. The research is unambiguous about this: production agents fail at rates between 41% and 86.7%, the failures are organizational rather than model-level, and you cannot fix what you cannot see. This is where the next year of agent engineering progress is going to come from.第三层是可靠性难题真正存在的地方。研究对此非常明确：生产环境中的智能体故障率在 41% 到 86.7% 之间，故障是组织层面的而非模型层面的，你无法修复你看不见的东西。这将是未来一年智能体工程进步的来源。
And the underlying frame that ties it all together is still Karpathy’s: the context window is RAM. Everything you’re building — frameworks, runtimes, observability — is operating system plumbing around that single resource. The question is not which framework is the “real” orchestrator. The question is whether you’ve thought clearly about all three layers, or whether you’re picking a fight on one layer because you haven’t yet noticed the other two.将这一切联系在一起的底层框架仍然是 Karpathy 的观点：上下文窗口就是 RAM。你正在构建的一切——框架、运行时、可观测性——都是围绕该单一资源进行的操作系统级管道工程。问题不在于哪个框架是“真正”的编排器。问题在于你是否对所有三个层面都有清晰的思考，还是说你只是因为还没注意到另外两个层面而在某一个层面上挑起争端。
We’re past the moment of arguing about whether to build multi-agent systems. We’re into the moment of running them in production, and finding out what breaks.我们已经过了争论是否要构建多智能体系统的阶段。我们正处于在生产环境中运行它们并找出哪里会出错的阶段。
