火山引擎升级「扣子」平台:开启 Agent 全生命周期管理新范式

火山引擎升级「扣子」平台,提供从开发、调优到协作的全生命周期Agent管理方案,助力企业高效构建和优化AI Agent。

原文标题:一粒「扣子」,开启了Agent的全生命周期进化

原文作者:机器之心

冷月清谈:

火山引擎在Force 2025大会上重点展示了全面升级的「扣子」平台,该平台已从Agent开发平台进化为覆盖Agent全生命周期的平台,包含扣子开发平台(低代码Agent开发)、Eino框架(开源大模型应用开发框架,全代码开发)、扣子罗盘(Agent效果调优)和扣子空间(Agent协作)四大组成部分。扣子开发平台旨在让零代码基础的用户也能快速构建Agent,Eino框架则为习惯代码开发的开发者提供Agent构建框架。扣子罗盘构建了Agent全生命周期体系,贯穿Agent开发、效果评测、线上观测和效果优化等阶段,实现Agent的持续优化迭代。扣子空间则作为一个通用AI Agent平台,通过Agent协同解决实际工作任务。火山引擎希望通过更完善的扣子平台,成为大模型时代Agent发展的“基础设施”。

怜星夜思:

1、文章提到扣子空间集中了精通各项技能的通用实习生以及各行各业的领域专家,你觉得这种 Agent 协作模式在实际应用中会遇到哪些挑战?有什么方法可以解决?
2、文章中提到了Eino框架,作为一个开源的LLM应用开发框架,你认为它有哪些优势和不足?对于开发者来说,它最大的吸引力是什么?
3、扣子罗盘通过Agent效果评测、线上观测等手段来优化Agent,你认为在Agent的实际应用中,哪些指标最能反映Agent的真实效果?如何避免指标作弊或者被误导?

原文内容

机器之心报道

编辑:杜伟


2025 年被很多人称为 Agent 爆发元年,它们可以极大地具像化大模型的能力,并改变 PC、移动等端侧人机交互的范式,尤其是跨场景的多任务自动执行显著提升了操作的便捷性和智能化程度。


自年初首个通用 Agent 产品 Manus 出现以来,Agent 受到了前所未有的关注,互联网大厂和大模型初创企业将它作为竞逐的 AI 重心之一,并利用 MCP、A2A 等协议扩展 Agent 的能力边界以及赋能的应用场景。


昨日,在火山引擎 Force 2025 大会上,除了最新版本的豆包大模型 1.6 系列之外,Agent 成为另一个焦点。


大会开发者主论坛以「基于 AI 云原生的 Agent 开发新范式」为主题,展示了全面升级的「扣子」如何利用 Agent 来重塑生产力。


扣子罗盘技术负责人王新盟


全新升级后的扣子已经由原来的 Agent 开发平台进化为了一个「全生命周期平台」,覆盖了以下四大组成部分:


  • 扣子开发平台,低代码 Agent 开发;

  • Eino 框架,开源的大模型应用开发框架,全代码开发;

  • 扣子罗盘,Agent 效果调优;

  • 扣子空间,Agent 协作。


可以说,更完备的扣子产品矩阵进一步适应大模型时代多样化的 Agent 开发、调优需求,最大可能地提供智能化的体验。



我们接下来一一来看。


Agent 终于有了「全生命周期」平台


首先是扣子开发平台,作为新一代 AI 应用开发平台,旨在让没有任何代码开发经验的人也能快速、低门槛地构建基于大模型的 Agent 或应用,并支持一键发布到飞书、微信公众号、豆包等渠道。


总结一波,扣子开发平台从智能体 IDE、应用 IDE、丰富的插件和工作流模板以及企业级安全能力四大方面来赋能 Agent 开发体验。


其中智能体 IDE 方便开发者高效地开发、调试 Chatbot 类的 Agent,还提供上千个插件供开发者使用,支持搭建工作流并利用基于火山引擎搭建的知识库;同时基于火山方舟平台,支持了业界大多数模型;打通主流发布渠道,尤其是 C 端,比如豆包、飞书、微信、抖音、小程序等渠道,让用户更方便地使用基于扣子搭建出的 Agent。


此外,一些开发者仍然希望通过拖拉拽的方式搭建 GUI 形态的应用,针对这种特定的开发需求,2024 年上线的应用 IDE 赋予了大模型的能力。企业级安全与数据保护能力支持私网连接客户的 VPC(虚拟私有云),避免了公网访问带来的一些潜在风险。



不仅如此,为了达到低门槛、零门槛构建 Agent 的目的,预置的大量 Agent 模板让开发者可以一键复制,快速构建一个成熟可用的 Agent,比如智能客服助手模板、文章转博客模板、智能助教模板,实现了开箱即用。


扣子开发平台让零基础开发 Agent 成为了可能,而面对更习惯写代码的开发者,同样推出了一个 Agent 构建框架 ——Eino,并进行开源


作为一个用 Go 语言编写的 LLM 应用开发框架,Eino 既从 LangChain 和 LlamaIndex 等开源社区的优秀框架中汲取灵感,又借鉴了实际应用,兼顾简洁性、可扩展性、可靠性与有效性。


Eino 的亮点之一在于将 Agent 开发的一些核心模块,比如 Chat Template、Document 解析、Embedding 模型、Retriever 检索等提炼成了一些标准化组件。这样一来,无论是对于开源或闭源模型,还是在代码中处理文档或者向量数据,都可以通过抽象好的统一接口进行调用。


同时面对复杂任务拆解和多工具协同,Eino 提供了灵活的编排能力,通过可视化拖拽或者代码开发的方式来轻松编排一个 Agent 流程。此外还支持完善的流处理功能,并提供了极强的工具链。


目前,字节内部基于 Eino 开发的系统数量已经超过了 300,在 GitHub 上的星标数量达到了 4.3k,这表明越来越多的内外部开发者都开始对使用该框架开发 Agent 产生了兴趣。以抖音电商为例,基于 Eino 搭建的智能客服工作流程可以让 Agent 代替人工客服,整体效率提升了 50% 以上。



GitHub 地址:https://github.com/cloudwego/eino


上面这些内容都是关于 Agent 的搭建,但搭建成功只是完成了第一步,还需要持续的优化迭代以及全生命周期的运用。火山引擎通过扣子罗盘构建了 Agent 全生命周期体系,贯穿 Agent 开发、效果评测、线上观测和效果优化等四个阶段


其中开发阶段主要涉及撰写和调试 Prompt、搭建工作流(知识库、MCP), 可以选择以低代码或全代码方式完成;接着进入评测阶段,通过 Agent 的效果量化来判断是否达到了准出标准;在发布上线之后进入第三个阶段 —— 观测,通过实时收集和分析线上运行的数据,让 Agent 从黑盒运行变成透明决策;最后到了线上调优阶段,针对暴露出的每一个问题进行精准的分析与解决。


当然,并不是到调优阶段就停止了,相反优化后的 Agent 会重新进入到新一轮的开发、效果评测、线上观测以及效果优化,如此循环往复,达到用户满意为止。



再具体到效果评测阶段,扣子罗盘在评测流程方面做到了以下四点:


  • 灵活的评测集版本管理,让开发者方便地管理和生成评测集。未来也会预置更多评测集,并开箱即用;

  • 评测对象支持 Prompt、扣子 Agent,未来还将基于 A2A 协议支持自定义 Agent;

  • 预置大量开箱即用的评估器,覆盖通用 Agent 评测的各个方面,包括任务完成度评估、正确性评估、工具选择评估以及轨迹评估等,并成为国内首家支持 Agent 轨迹评估的线上商业化平台;

  • 丰富的评测报告以供直观的查看与分析。


到了线上观测阶段,则需要一整套的观测体系来洞察 Agent 的运行情况,包括运行性能(token 消耗、请求量和能力)、运行效果以及用户的问题以及分类。综合下来,开发者可以更有针对性地根据用户兴趣来调整 Agent。对于一些细节问题,比如针对线上运行的一些 Bad case,进行问题点定位并展开定向优化。


为此,扣子罗盘提供了一整套的 AI Agent 观测功能。在数据上报方面,针对扣子的 Agent 进行提前预置,系统可以自动上报数据,因而可以在罗盘上查看这些 Agent 的所有数据。另外针对全代码开发者自定义的 Agent,同样提供了 SDK,供他们按照协议上报数据。同时针对开发者用得比较多的其他框架(比如 LongChain)也进行适配,支持一键将数据上报至扣子罗盘。


不仅如此,火山引擎认为线上运行数据的价值远不止用来观测。在扣子罗盘上,开发者可以根据线上用户的 query 分析与分组,获得用户行为的分析报告;也可以将线上的 query 进行自动评测以获得线上效果的报告。这样一来,开发者可以实时掌握 Agent 线上运行效果的优劣变化,并通过多种方式(比如用户的点踩)来识别 Bad case。


当然这些 Bad case 也可以基于预置的评估器来识别,过程中构建 Agent 的 Bad case 集,这些集在经过系统预置的人工标注之后可以沉淀为评测集,为后续的例行迭代和评测提供支持。


此外,扣子罗盘还将与火山方舟的 Prompt 优化能力和模型微调能力贯通。王新盟表示,以上这些功能已在本周正式发布上线,并开启了企业灰度测试。总之,有了扣子罗盘,Agent 的迭代与调优进入到了透明可视化时代,告别了「盲人摸象」。



最后是扣子空间,它是一个通用 AI Agent 平台,今年 4 月首次上线,并拿下了当月国内 AI 产品增速榜的第一。扣子空间并不是一个 Agent,而是一群高质量 Agent 的协同办公场所,集中了精通各项技能的通用实习生以及各行各业的领域专家。在各种 Agent 的协作下,用户可以更高效地解决实际工作任务。


利用扣子空间,用户可以分析市场调研报告、选择高考院校和专业,还能够获得专家能力的深度支持。此外通过 MCP 协议来不断地扩展能力边界,比如联动高德生成旅游攻略、联动飞书进行文档撰写等。接下来,火山引擎还将上线更多高质量、覆盖各行各业的专家 Agent。



可以预见,未来更加完善的扣子平台将成为大模型时代 Agent 发展的「基础设施」。


© THE END 

转载请联系本公众号获得授权

投稿或寻求报道:[email protected]

别忘了**“成本”! Agent 的运行需要消耗大量的计算资源,如果 Agent 的效果提升不大,但成本却很高,那么就得不偿失了。 所以,在评估 Agent 效果时,需要综合考虑其带来的收益和付出的成本**,找到一个平衡点。 感觉就像做生意,光看利润不行,还得看投入产出比。

我觉得Eino有一个潜在的风险是**“过度依赖”。如果开发者过于依赖 Eino 提供的标准化组件,可能会限制其创新能力。毕竟,真正的创新往往来自于对现有框架的突破和超越。 所以,Eino 的开发者们应该保持开放的心态,鼓励开发者基于 Eino 进行二次开发和定制**,而不是将其视为一个封闭的“黑盒子”。

我认为最能反映 Agent 真实效果的指标是用户满意度。这不仅仅体现在点赞、好评等显性指标上,更重要的是用户是否愿意持续使用 Agent,以及是否会向他人推荐。当然,用户满意度很难量化,需要结合其他指标进行综合评估。 此外,任务完成率、错误率和平均处理时间等指标也很重要,可以反映 Agent 的效率和准确性。

为了避免指标作弊或者被误导,需要建立完善的监控体系,并定期进行人工抽查。同时,要关注指标的长期趋势,而不是短期波动。 感觉就像股票投资,不要只看一天的涨跌,要看长期的走势。

除了前面提到的,我觉得 “Agent 的可解释性” 也很重要。 也就是说,Agent 在做出决策时,需要能够给出合理的解释,让用户理解其背后的逻辑。如果 Agent 总是给出一些莫名其妙的答案,即使其他指标再好,用户也难以信任它。 为了提高 Agent 的可解释性,可以尝试引入“知识图谱”等技术,让 Agent 能够更好地理解和表达知识。

我比较关注实际应用中的**“责任划分”问题**。如果多个 Agent 协作完成一个任务,但最终结果不理想,那么责任应该归咎于哪个 Agent 呢?如何建立一套有效的 Agent 评估体系,从而明确每个 Agent 的贡献和责任,我觉得这很重要。 也许可以尝试引入“仲裁Agent”,专门负责监督协作过程、评估Agent表现,并在出现问题时进行责任判定。 感觉这样可以提高Agent协作的效率和可靠性。

Eino 的优势在于标准化组件和灵活的编排能力。它将 Agent 开发的核心模块抽象成标准化组件,降低了开发门槛。同时,可视化拖拽和代码开发相结合的编排方式,方便开发者快速构建复杂的 Agent 流程。 不足之处在于其生态系统可能还不够完善,相比 LangChain 等老牌框架,Eino 的社区支持和插件数量可能还有待提升。但它的简洁性和可扩展性,以及字节内部的实践经验,对开发者来说应该很有吸引力。

别把Agent想得太完美啦,我觉得Agent 的“人格化”可能导致人们过度信任,反而降低了警惕性。举个例子,如果一个Agent自称是某个领域的专家,那么用户可能会盲目相信它的建议,而忽略了潜在的风险。所以,我认为应该明确 Agent 的“身份”和“能力边界”,避免用户对其产生不切实际的期望。 换句话说,得让用户知道,这玩意儿再智能,也只是个工具而已!

我认为 Agent 协作模式最大的挑战在于不同 Agent 之间的沟通和协调。Agent 能力各异,如何保证它们高效协作,避免信息传递中的偏差和误解,是一个需要解决的问题。可以考虑建立统一的 Agent 沟通协议和知识共享平台,让 Agent 之间可以更好地理解彼此的需求和能力,从而实现更高效的协作。

另外,安全性和隐私也是需要考虑的。Agent 协作可能涉及访问不同的数据源和服务,需要确保数据安全和用户隐私。可以采用权限控制和数据加密等技术手段来解决这个问题。

Eino最大的吸引力我觉得是**“出身名门”,字节跳动内部已经在大量使用,并且经过了实践检验。这意味着它在解决实际问题方面,可能更有优势。而且,背靠字节跳动,Eino 的更新迭代速度和技术支持**应该也比较有保障,这对于开发者来说是很重要的。

此外,Go语言编写也算一个加分项,性能和并发能力都比较强,适合构建高并发的 Agent 应用。