卷疯了！这个清华系Agent框架开源后迅速斩获1.9k stars，还要“消灭”Prompt？

随着大模型能力的突破，“可调用工具的智能体”已经迅速从实验室概念走向应用落地，成为继大模型之后的又一爆发点。与此同时，围绕 Agent 构建的开发框架和基础设施在迅速演进，从最早的 LangChain、AutoGPT，到后面崛起的 OpenAgents、CrewAI、MetaGPT、Autogen 等，新一代 Agent 框架不仅追求更强的自主性和协同性，也在探索深度融合进业务的可能。

框架之争的背后，实则是新一轮开发范式和商业模型的重构起点。清华 MEM 工程管理硕士、SeamLessAI 创始人王政联合清华大模型团队 LeapLab 发布了一款面向 Agent 协作的开源框架 Cooragent，参与到了 Agent 框架生态中。Cooragent 的最重要的特点之一就是用户只需一句话描述需求，即可生成专属智能体，且智能体间可自动协作完成复杂任务。王政团队分别发布了开源版本和企业版本，进行社区和商业化建设。其中，开源版本已获得 1.9k stars。

本次访谈中，王政向 InfoQ 分享了其对 Agent 发展的洞察，以及 Cooragent 的设计思路背后对行业现状和未来发展的思考。

王政指出，盈利对于大模型的发展来说是极为重要的，Manus 的 ARR 增长迅速表明了人们愿意为其付费。虽然有各种 Agent 产品，但它们真正差异在于使用方式、面向场景、工作流的打磨程度以及 Agent 本身的优化程度。此外，他也表示，现有的 Agent 和框架在产品确定且不变的情况下能够解决问题，但这种静态的解决方案远远不够。

王政：2022 年 12 月，OpenAI 发布了 ChatGPT，随后 Agent 的概念便应运而生。2023 年，众多开发者开始着手尝试构建 Agent，当时一个名为 Auto-GPT 的开源项目迅速走红，获得了 100 多 K 星。

但在实践过程中，大家发现当时的 Agent 还不够成熟，核心问题是大模型本身的能力存在很大局限：不仅存在诸多幻觉问题，而且尚未具备长思考模式以及有效的 post train 方法，导致其输出的答案和 API 调用结果都不太行。这种技术短板制约了 Agent 的商业化进程，因为商业化要求模型必须具备高稳定性等，而在千问、DeepSeek 等模型崭露头角之前，国内其他模型与顶尖水平相比仍存在差距，难以满足商业化所需的可靠性等。

从 2023 年到 2024 年，尽管大模型的商业化落地面临诸多挑战，但其能力的增长却十分显著。如今，大模型在几个关键方面取得了本质性的提升。首先，它具备了较为精确的长任务思考能力，这对于深入思考和进一步挖掘信息至关重要，使得模型能够从单步思考迈向多步思考。其次，大模型的代码能力，尤其是 function call 的能力取得了大幅提升。2025 年以后，国产开源大模型又取得了令人欣喜的进步。例如 Qwen2.5/3、Deepseek V3-0526 模型等，在工具调用的准确率和复杂指令遵循上都取得了长足进步升，这不仅激发了大家对 Agent 的热情，也为 Agent 的商业化奠定。

王政：MCP 是 Agent 的基础，如果没有 MCP，Agent 便无法充分发挥作用。自 2023 年 Anthropic 提出 MCP 后，其重要性逐渐被认识并开始流行。MCP 实际上是一种工具池化，类似于当年的算力虚拟化。如果不进行池化，接入门槛就会很高，标准化也难以实现。而一旦池化，工具就可以像水一样灵活使用。

Manus 在这方面做出了不少贡献，其在相关领域的尝试却引起了大家的关注，揭示了许多有趣的方向。尽管有人对 Manus 提出质疑，但关键还是从何种角度看待它。至少，它促使人们重新聚焦 Agent 赛道，并且其商业模式和盈利路径相较于以往的 Agent 应用更为清晰。Manus 的 ARR 增长迅速，这表明人们愿意为其付费，而盈利对于大模型的发展来说无疑是极为重要的。

王政：整体看，各种系统或产品的原理大致相似，真正的差异在于使用方式、面向场景、工作流的打磨程度以及 Agent 本身的优化程度。

要建立长期的技术优势，需要构建一个完整的体系，包括底层模型的创新、数据链的工程能力以及工具的使用。以我们清华大学的实验室为例，每月都会有一些底层算法的创新，并将其融入到 Agent 架构中。长期来看，这会成为一个独特的竞争优势。未来，在知识场景下形成的数据飞轮以及不断优化的体系，都会使我们的产品与他人产生差异。

不过，产品的好坏很难一概而论，这取决于具体用途。以 Manus 为例，它在日常报告和提供灵感方面做得不错，但可能不太适用于撰写较为严肃的报告，至少不能直接拿来用。你也可以自己动手进一步优化和调整，但这需要花费一定的时间和精力。但这对于许多场景来说已经是一个很好的解决方案了。

现在，我们不能完全将底层能力和工程能力分开。底层的算法创新依赖于工程能力，而工程能力也会反过来影响算法。对于用户来说，整个体系都是重要的。Agent 实际上要解决的问题是如何将大模型的能力真正带到用户的生活场景中。

王政： 目前，Agent 的框架已经非常丰富，各自的立足点都不相同。但在我看来，未来 AI 的发展趋势是将 Infra 与应用场景紧密结合。与传统通用的 Infra 不同，AI 的商业化和应用正在逐渐“出圈”，不再局限于互联网模式下的几种常见商业化路径，如计算广告、会员制或 B 端服务。AI 的应用也已拓展到传统行业，例如律所也开始尝试使用 Agent 提升生产效率或进行创新。这些都与以往的需求大不相同，这种需求的多样化导致市场上出现了众多框架和新算法。

另一方面，我们在为 B 端客户落地时发现了许多痛点，其中一个关键痛点是泛化性与精确性的平衡，这在商业化和产业落地中尤为重要。很多时候，Infra 需要程序员花费大量时间去打磨工作流或编写提示词，而一旦场景、用户习惯改变或模型能力提升，就都要重新调整，这无疑增加了工作量。此外，调试工作流也是一大难题。传统的调试工具虽然丰富，但在 AI 领域，尤其是涉及到 Function Call 和调用失败的原因时，往往只能依靠工程师的经验。

现有的 Agent 和框架在产品确定的情况下能够解决问题，但这种静态的解决方案远远不够。如今的趋势是快速变化，一旦将解决方案固定下来，未来升级和适应变化就会变得非常困难。例如，有些框架为了方便用户，将底层代码封装得过于死板，导致定制化变得极其困难。

我们开发 MetaAI 框架的初衷是希望通过 Agent 创造 Agent，利用它生成无限多的 Agent 来适应不同的场景，从本质上解决泛化能力与精确性的平衡问题。

MetaAI 可以根据用户场景和环境的变化动态调整 Agent 的生成，使 Agent 能够快速适应新场景。当然，一些细节的微调，如提示词和工具的调整，仍然需要人工参与，我们称之为 Cooragent，即人与 Agent 之间的协作以及 Agent 与 Agent 之间的协作，这种协作理念极大地提升了生产效率和环境适应能力。

王政：工具的使用能力是 Agent 的第二大要素，我们提供了一些通用工具，如浏览器工具、编程工具和报告工具，方便开发者使用。这些工具的选择和配置机制，使得 Agent 能够更好地适应不同场景的需求。我们还设计了一种通用机制，让 Agent 能够分析用户的指令和生产需求，同时能够从工具池中挑选合适的工具进行配置。

王政： 我们正在探索“Prompt free”的概念，旨在减少用户，尤其是 C 端用户，在提示词方面的负担。对于大多数人来说，处理大量的提示词非常令人头疼，几乎没人愿意花费大量的时间去精心设计这些词。用户更倾向于用一句话、一个简单指令，来表达需求。

我们做的事情就是基于用户的上下文来补充信息。这里的上下文与大模型的上下文维度有所不同。大模型的上下文通常是基于单次输入的上下文，而我们所指的上下文则是用户的全部历史数据，甚至可能追溯到用户最初使用平台时的数据。这就好比数据飞轮，用户使用得越多，系统就越能符合他的使用习惯。

在上下文的处理上，大家通常采用的方式大体相似，包括检索召回、知识库、向量库、知识图谱等，但关键问题在于如何高效地利用和整合这些数据。问题可能不是数据不够，而是没有高效利用数据。

目前，大家都在数据产生上探索。合成数据是一种新方式，但它的问题在于泛化性、多样性和其中的偏差，另一种方式是建立关于物理世界的一些模型。但对我们来说，目前最重要的是提高数据的利用率。

数据并不是越多就越有效，我们需要对数据进行有规则的筛选和保留，以保证数据的正交性。高效利用数据是一个巨大的挑战，大量的工程工作实际上都是围绕数据展开的。如何精细化使用数据，依赖于数据工程能力和对数据的深刻理解。我们在这方面做了一些尝试，包括基于强化学习的方法。

王政： 在算力方面，不同阶段有不同的优化要求。实际上，算力优化的上限是很高的。我们曾经将一台机器的利用率从 30% 提高到 80%-90%，整个链路的使用效率提升了两到三倍。从成本角度来看，仅这一项就能节省三分之二的成本，甚至更多。如果再加上对算法的定制优化，成本可以降低到原来的十分之一。但这个前提是规模要足够大，因为算力优化工程也需要耗费大量的人力和时间，而且业务流程需要确定并达到一定的量才能使这种优化变得划算。

当然，OpenAI、DeepSeek 等公司的工程化团队会持续研究这些问题。对我们来说，在不同阶段采用合适的工作策略非常重要，但这需要很多专业人才。

我们的工程人员会从设计角度规避大部分可以解决的问题。比如，Agent 实际上是基于大模型体系生长起来的，也会存在一些问题，像是 Agent 多步骤完成工作的过程中，大量的上下文和推理过程会导致信息爆炸，治理这一问题非常重要。我们会采用工程化的常规手段，比如一些验证过程来判断某些推理是否合理，对指令进行精简，并对上下文进行优化。、

王政： 结合我们的开发经验，难点主要集中在底层，比如接口设计、架构设计以及数据流设计等。多智能体系统也存在一些问题，比如需要考虑是固定多个智能体，还是可以无限扩展智能体的数量。这两种方式在复杂性管理上存在显著差异。

王政：Agent 的控制和分工问题，也是我们一直在思考的。我们之所以要对 Agent 进行分工，其实与人因工程学有关。当任务量增多时，如果让一个 Agent 完成所有任务，它很容易在适应通用性的同时牺牲掉自己的专业性，但我们其实希望 Agent 能够专注于某一特定领域。根据经验，一个 Agent 能够熟练运用一到两个工具，最多不超过三个工具来完成其工作，是比较现实且易于打磨的。

这背后涉及到了责任划分和协作机制的设计。责任划分本身是一个复杂的过程，我们希望通过自动化流程来实现这一点，并实现 Agent 间的协作。我们设计了一些沟通机制来促进 Agent 之间的协作，可能“领导”会给出一个大致方向，但具体的执行细节 Agent 可以根据实际情况进行调整。

王政： 从单 Agent 到多 Agent，设计理念必然有所不同，多 Agent 系统的设计理念更为原生。但其实，我认为对 Agent 进行这种分类的意义或许并不大，最关键的问题还是在于 Agent 能否适配特定场景，以及框架是否足够易用。

此外，框架的适应性与扩展能力至关重要。 由于模型本身和 MCP 工具生态都在快速发展，框架必须能够快速集成新工具并显著降低用户的开发成本。毕竟，要求开发者持续追踪所有新技术进展是不现实的，因此，一个优秀的框架应快速迭代和演进，以应对技术生态的持续变化。

王政： 融合不同的框架也是一种方法，但是否是最优解则值得商榷。融合框架还与融合模型不同，融合模型对外呈现为单一模型，其内部融合了多种网络结构。而融合不同框架显著增加了系统的复杂性，因为涉及到工程层面的融合，系统的复杂度会上升，通信也会变得冗余。

对于用户而言，只要框架好用、扩展性强且易于维护，无论底层是融合了多个框架还是单一框架，都是好的选择。然而，在大多数情况下，融合框架或架构的维护性相对较差。维护一个框架已经需要大量人力，如果融合多个框架，可能还需要额外聘请工程师来维护。而且，这种架构中往往存在大量重复的特性，拉高了维护成本。

王政： 在 C 端，我们已经开源了一部分项目，大家的热情非常高。基于此，我们计划近期上线一个 SaaS 平台。这个平台不是传统意义上的企业版，而是一个触手可及的平台，一个人就可以使用，它将以社区的形式呈现。

由于我们的项目源于在落地过程中遇到的一些问题，B 端自然是我们的一个天然场景。最近，我们也在和一些大型客户讨论战略合作。B 端对我们来说无疑是一个很好的场景。未来，我认为 B 端和 C 端都需要并行发展。一个有意思的现象是 B 端客户的需求会向 C 端借鉴。这背后的原因可能是关注 C 端的活跃用户会引起一些产品思路上的变革，而这种变革是具备通用属性的。例如我们最近和最高法大数据平台的合作就是一个这样的典型案例。

王政： 我们会先将项目打磨好后再开源。我们希望开源的是一个相对成熟的产品，而不是半成品。目前，我们开源的部分是我们已经使用过且效果不错的一部分。未来，我们还会进一步开源，包括一些更完善的工具和可视化功能。

王政：B 端商业化产品将基于我们的框架开发，其核心在于与 B 端客户的数据共享和工作流打磨，更偏向于定制化场景。虽然工具本身可能会开源，但还是会遇到一些私有数据、定制数据和工作流方面的挑战，我们会帮助定制开发一些东西。

我们更希望与头部 B 端客户合作，共同成长。Agent 还处于早期阶段，我们也不敢确定它未来会发生怎样的变化，所以希望与我们共同成长的合作伙伴能够多投入一些精力，不仅仅是我们在努力，而是大家愿意长期投入。

王政： 开源初衷各有不同，这个问题不好一概而论。拿我们目前的开源框架来说，它属于清华大学，记录在清华大学的开源项目之中。高校做开源往往更注重长期价值，这与商业逻辑有所不同。高校开源更多是出于一种责任感，一种分享知识、推动技术发展的义务。像清华大学、厦门大学、中国人民大学、上海交通大学等高校，在开源方面都做了不少工作，取得了不错的成果。高校作为学术研究的高地，有责任也有义务去推动开源文化的发展。企业开源的目的则不同，企业开源主要是为了提升品牌影响力，或者作为一种获客渠道。

开源项目还有一个关键问题，就是更新频率。有些项目可能会在一段时间内集中更新，然后慢下来，甚至暂停一段时间。这种情况在国外也较为常见。这其实也很正常，毕竟开源在某种程度上类似于做公益，当精力有限或者有其他优先更高的事情时，适当放缓更新速度是可以理解的。只要后续能够重新加速，继续推动项目发展，就依然值得肯定。

王政： 我接触到的很多用户喜欢使用 ADK，它更偏向于开发者。但目前市面上的框架确实繁多，很难给出一个绝对的建议。但在选择框架时，我们需要从多个角度综合考虑。

首先，要明确这款框架的特点是什么、面向何种场景设计的、是否与项目场景相匹配。其次，需要考虑团队的使用习惯，有些团队可能更熟悉传统的 SDK 开发方式，而有些团队可能更倾向于低代码或者拖拽式的开发方式，那么选择适合自己团队风格的框架会更合适。再者，需要考虑后期的扩展性问题，因为随着用户需求的变化，应用场景也会随之改变。设计从来都不是一蹴而就的，需要经验的积累、长期的学习，甚至还需要一些直觉。

王政: 每个人对于开发工具的理解和偏好各有不同。有些人习惯使用 SDK 这种开发方式，这无可厚非。其实，每一种开发方式都有其独特的优势与局限性。

以 SDK 为例，它的优势在于定义清晰，接口规范明确，这对于那些长期从事传统软件开发、熟悉互联网开发流程的开发者来说，无疑是非常便捷的。然而，一些新手开发者可能从未接触过传统开发模式，甚至对 SDK 的概念都较为陌生，那通过我们的开发方式或其他方式也能顺利开发。

对于我们来说，在面对不同用户群体时需要做出的取舍。但无论采用哪种方式，我们的目标始终是服务用户，让用户能够高效开发。如今，市场上的产品服务很多，都定义好了各自特定的用户群体。很难说这些产品之间的差距有多大，但可以肯定的是，不可能用一款软件满足所有人的需求，这在当下是不现实的。

王政： 从国际视角来看，目前国外的框架主要以模型为界限，大多围绕 OpenAI 的技术构建。国内则有所不同，我们主要围绕自己的模型构建体系，虽然在理论上我们也能支持 Anthropic 或 OpenAI 的工具，反之亦然，但目前双方的结构体系确实存在差异。尽管国外的框架曾被广泛使用，但越来越多的用户开始倾向于使用国内的框架。