设备调试与会前准备
Speaker 0: 我们这边现在应该已经开始直播了，就是你这边突然加进来之后，就会自动开始这个 Riverside。昨天也是这样子情况。
Speaker 0: 弹幕里面就说他听还好啊，Jack 说听还好。不知道效果怎么样，看到时候如果需要的话我可以戴个耳机。那我把这个麦克风关掉，你说话我听。
Speaker 0: 对，这个是嘉宾链接。因为嘉宾到时候过来应该会选择一个 session 然后开始，然后我这边应该都能看到 chat 什么是的。然后你这边帮我去 verify 一下那个微信视频号上推流，等会儿就是跟那个 V to AGI 他们那个 team 好吗？
Speaker 0: 你这边等会儿帮我 monitor 一下就是那些推流的地址到底有没有都发送到，行吗？OK，或者我们微信上我跟你讲，就是如果我这边说话你听不清楚。
Speaker 0: 吴总，我这边收到您这个最新的 slides 了，然后您到时候这边分享一下方便吗？
Speaker 0: 我看了一下吴总您这边的这个分享，比如说分两部分，先是讲关于 attention，然后后面是讲关于 infer。我们可以在中间稍微停一下，就是 attention 讲完之后我们停一下，看看观众有什么问题，然后稍微互动一下。
Speaker 3: 是的是的是的，我觉得您这两点提得都非常好，非常契合我们的主题。我们主题就是如何用 AI 把一个 demo 变成一个可生产落地的应用。我觉得还是有非常多的路要走的，包括你说的 infer 和 attention 都是。
Speaker 0: 对对对。我们现在直播间里面有十九位小伙伴，有小伙伴的话可以在弹幕里面扣个 1 啊，我这边应该能看到的。好，我们再稍微再等几分钟，十点零一分。我再看一下社区里面，欢迎新来的朋友们，新来的朋友们可以在弹幕里面跟我们互动一下，发个表情什么的。非常感谢大家今天来参加我们的活动，我们会在十点零五分的时候准时开始，陆陆续续等朋友们再进来一些。
活动开场与嘉宾介绍
Speaker 0: 那我们差不多时间，十点零五了，我们准备开始吧。非常感谢大家来参加今天的活动，我们今天这一系列的活动是 AI Engineer 和他的朋友们。我是本场活动的主持人，我叫 Gordon，我之前在 Meta 担任工程师，也是超线性学院的老朋友了。
Meta AI 大会是在美国极富盛名的一个大会，也会在今年 11 月 5 号到 11 月 6 号首次登陆上海。届时会有非常多中美一线的 AI 企业来进行精彩的分享与交流。那么针对不能参加线下活动的朋友们，我们特地准备了此次线上的直播活动。我们请来了九位 AI Engineer 的金牌赞助商嘉宾前来进行分享。这九位 AI 企业嘉宾都在各自的 AI 领域进行了非常多前沿的探索，他们分享的主题是有关于他们的一些精彩案例的实践、一些行业的观察以及趋势的判断。
我们今天的主题是如何系统性、规模化地管理 AI。因为我们都知道，在 2026 年以来，我们任何人用 AI 搓一个小的 demo 是一个非常容易的事情，但是从一个 demo 到真正落地到大规模生产环境的 AI 应用，依旧有非常多的路要走。这中间要包括解决的难题可能会有质量与安全，有可观测性与评测，也有基础设施，甚至如何分发和宣传。
那么今天来的三位企业嘉宾都是在各自的领域有非常多丰富的实践。他们分别是深耕于企业级 AI 平台的 Retone 锐动 AI，专注于代码质量把控与安全的 Sonar，以及专注于 Agent 可观测性与评测的来自 Click 的 Langfuse。他们将分别从不同的角度来回答这个问题，那就是 AI 应用从 demo 到大规模可落地生产还有多长的路要走。
在直播的过程当中，也欢迎各位观众用社区里的 chat 和 Q&A 功能来与我们进行互动。在这里如果有观众可以扣个 1 的话，我会非常感谢，希望让我看到你们的弹幕。好，那么话不多说，我们进入我们第一场精彩的分享吧。我们第一位分享嘉宾是来自锐动 AI 的 CTO Jack 吴总，我们请吴总跟大家打个招呼吧。
全民 Build 时代：Attention 与 Infer 的交集
Speaker 0: 大家好，非常荣幸今天借助 AI Engineer 和超线性学院这个机会跟大家一块儿分享一下我们在做 AI 转型中看到的一些趋势以及我们的一些想法吧，跟大家一块来抛砖引玉、探讨一下。
Speaker 0: 大家早上好，周六的早上非常荣幸有这个机会跟大家来一块儿做一个分享。本身 AI Engineer 的话其实也是我一直以来最关注的一个社群的活动。因为最早 AI Engineer 在美国举办的时候，虽然不能亲临现场，但是从最早的几期我们都在去看，也是我们最早去学习 AI、去跟业界朋友探讨一个我觉得非常非常有价值的平台。所以在里边我们也学了很多东西。那今天借这个机会，其实我们也是想把我们锐动 AI 看到的一些内容跟大家做一个简单的分享跟探讨。
锐动 AI 的定位，其实我们给自己一个定位是在做一个全民 build 时代的一个 token 基础设施的这样一个定位。所以其实我们一直很关注的就是在这个 AI 变革的年代，尤其是 AI 对软件行业的冲击的年代，大家到底应该关注些什么东西。我今天分享内容我起了个题目叫《在全民 build 时代的一个 Attention and Infer 的交集》。我们都知道这轮 AI 变革的核心论文就是 Attention Is All You Need，那其实我们在这里面稍稍加了一点点，那就是在今天面向开发者，我们未来也要构建我们自己的 attention 机制，同时要构建我们的 infer 机制，这是我今天想分享的内容。
具体定义这件事情的话，其实我们最近看到了很多的趋势，我不知道大家有没有关注。如果大家在关注一些社区的变化的话，会看到很多的趋势。比如说 OpenCraft 这个社区里非常有名、非常火的软件，它基本上把过去十年、二十年、三十年在我们的商业软件里边最强大的、最稳固的一些商业软件，基本上都用 open source 的方式给重构掉了，借助 AI 的能力，包括像 Photoshop，包括像 Office，包括像其他的一些全都重构掉了。当然我觉得其实是一个尝试，其实也代表了一种趋势。可能未来的软件，传统这么多年去做买 license、卖订阅这种方式是不是还能存在，可能就会打一个很大的疑问了。那这个基本上对这么多年的软件行业存在的商业模式就会产生一个新的重构了。
另外一个，比如说最近很火的 Open Interpreter 这套 open source 的工具，基本上把软件的分析甚至一些逆向能力全部交给他。当然这些能力不是说今天靠 Open Interpreter 才出现的，但是其实很多能力能够让每一个使用这种前沿 coding 工具的人都能够去具备这样的能力。
还有一些像 Generative Office，基本上像这样的软件，它的接口已经从原来面向人类用户转向了面向 agent。所以整个行业我们看到一些非常大的变化在不知不觉中发生了。
我们回来看，因为我自己做了好多年的软件工程，尤其企业软件开发，做二十多年的职业软件开发，所以其实我们过去做一套软件是很麻烦的。它是一个工厂的逻辑，是一个大的协同分工的逻辑：你看到这个需求，你有产品经理去做需求分析，你要组织项目经理，你要组织架构师、开发者，你要组织测试团队，你要组织甚至客户的交付团队，一整套的内容全完成。但是在今天，可能我想在座的所有开发者，今天你在做大部分软件的时候，都是你一个人完成的：你一个人既是产品经理又是开发者，或者说你是产品经理加架构师，你的 agent 集群是你的开发者。所以这个需求变化非常非常大。
那这带来了两个趋势：
第一个的话就是门槛一定是降低了。我们经常会看到很多非专业的开发人员，比如原来是一些歌手、演员，或者各个角色，他都可以自己去做 web coding，自己去构建软件了，所以这个门槛在降低。
另外一方面的话，其实我们也会发现，现在开源社区的软件非常多，代码非常多，但是真正高质量的、有影响力的，还是能快速地获得大家的认可，我相信大家也都是有感受的。所以这个变化发展得很快。
其实我们怎么理解这个变化？我们也回顾了一下，其实这件事情历史上已经发生过了。我们就看过去的传媒。编程语言它也是语言，它也是内容的一个部分。其实内容产业在整个互联网发展过程中已经经历过一次非常非常深刻的变化。我们看到若干年前在纸媒的那个年代，本质上纸媒承载的是文字的内容、图片的内容，过去它的商业模式其实是靠卖 copy 的：我一份报纸多少钱，我一份杂志多少钱，是这样去做售卖的；主导方也都是一些大型的机构，报社、杂志社或者是电视台。
但是其实后来到了自媒体时代，大家发现：第一，创作门槛降低了，不用专业机构，每个人都能自己创作，都能发出自己的意见；第二，商业模式变了，因为供给足够丰富之后，没有人再去说我卖一个 video、卖一个什么东西、卖一个 copy，大家卖的本身就是你能不能吸引更多的注意力，你能不能把注意力变成流量、变成其他的方式去做变现。核心就是你创作的内容能不能被别人看见。
今天我觉得软件业可能逐渐也在往这个趋势去做转型了。另外一个非常透彻的像 B 站这样的平台，其实就是一个完整的、端到端的、面向个人 builder 的一个完整的生态平台。从他个人的制作到平台连接到持续的回报，这个是非常非常成熟的。当然其他的一些平台也是类似的。
所以我们觉得未来的软件行业，不排除说从今天单纯买 license、买订阅这种商业软件，变成说真正是一个社群化的、注意力机制驱动的商业模式。这种模式的话对我们大量的个人开发者来讲，我觉得是一个非常非常利好的状态。因为你借助这些平台——虽然现在还没有这样的平台，但我相信很快会有这样的平台——借助这样的平台，你不需要像大的软件公司或者大的平台一样需要大量的资金去宣发，可能你就能很快地构建一个自己的闭环的商业模式。
当然这里边其实也带来了一些挑战。刚才说了，因为我相信今天来参与的可能大部分都是以专业的开发者为主。但其实我们看到统计数据，在新增项目、代码量上是非常非常多、指数级增长的。某种意义代表说，软件或者代码本身的供给变得非常非常丰富了。那在这个时候，稀缺性就开始变了：过去的稀缺性是功能的实现，那今天的稀缺性可能就变了，变成说……
功能的实现可能变成一个标配的能力，谁都能实现，不能靠功能的实现去赢得用户了，那可能更多的是你在功能实现的基础上要附加其他的东西。所以这个变化我相信大家一定要深刻认识到。
可能我跟很多开发者聊，大家其实有个共同感受，说 OK，今天有 AI，我交付代码速度、交付代码质量都变得非常非常快。但是很多尤其是自己尝试做一些 OPC 的一些朋友发现，说 OK，我变现的速度未必有很快的增长。所以这个商业模式的构建，大家一定要重新去思考这件事情。
然后呢，我们也看到了一些趋势吧，我觉得也是给大家一块去做一些探讨。
那第一个的话呢，其实大家不要关注一些特别和我们特别通用的那种需求，大家一定要看一些很 niche 的、很小的一些需求。因为原来的软件也受制于它的生产能力，所以它生产的软件一定解决的是很多共性的问题，出现一千次、一万次、十万次这样的问题，这样的话呢，他的商业回报才会 OK，因为他投入的生产成本很高，所以他一定要是做一些很普适性的、解决一些很普适的问题。但今天可能不一样了，那些解决很普适问题的，我相信是一些大厂甚至中厂的赛道。但是对于我们的个人开发者或者小的团队来讲，那可能我们真的要 focus 在一些小的场景上。但是因为今天的 AI coding 的能力给我们的加持，让我们的供给成本会不断地降低，所以我们有机会在一些很小的场景把它打磨得非常好，并且解决得很好，获得一部分很稳固的应用，但这用户体量可能不会特别大，成本也不会特别高，但我觉得是一些很值得做的一些事情，尤其是作为起步。
第二个的话呢，其实我们在做的很多平台上的软件，或者我们的作品吧——不一定是软件，可能是整体的一个作品——那可能都不是一次性的工作了，可能它都是一些这种交互性的、持续性的工作。在这个过程中的话呢，我们其实怎么能够跟我们的观众或者叫我们这个项目的受众能够互动起来，是一个非常重要的过程，它就不再是一次性交付的过程了。比如说我们相当于一个链接，这个是我们写的一个，当时去研究 strata 这个推理引擎的时候，我们一边在研究它，一边在用它，我们一边也在去学习它，就把里面的一些……它怎么去实现，它到底怎么像魔法一样把一个很低显存的，加上内存加上 SSD，就能跑起来一个很大尺寸的模型，并且性能还不错。然后把里面的机制给它深挖出来，发现这个机制我们就把它做成一个小小的互动平台，发现学 LLM 的一些基础原理、学推理引擎的一些基础原理的很多基础知识就在里面了。那我们互动性地也会更新这个平台，所以类似这样的东西呢，我觉得可能形式都会发生一些新的变化了。
第三个的话，我觉得对很多开发者来讲，对我个人、对于其他很多开发者来讲，可能都是一件比较挑战的事情：我们从开发功能变成经营自己的作品，这个思路上的转换可能是一个非常非常大的变化。因为过去开发功能的话呢，我们更多的是在思考说：哎，我有一个问题，我怎么解决这个问题？把功能给它做出来就好了。但是负责一款产品的时候呢，可能这个问题就会复杂得多。那可能第一步，在你写所有的代码、在你做所有的事情之前，你可能就要面临第一个问题：就是我到底选择做什么？我解决什么问题？有可能你这个问题选得不对，你后面做得再好可能都没有意义了。那包括你做完之后你怎么去接触用户，怎么样获得用户的感知？那包括你能不能持续地去获得用户的反馈，用来改进你的这个作品？
我们之前在社区里面也看到一些很好的开发者，他做很流程化的东西，他发出去之后呢，他通过一些社群或者一些社媒的渠道收集很多用户的意见，然后再把用户意见直接放到他的 web coding 的流程里面，让一个 agent 专门根据这些意见直接去提新的 issue，然后在整个的流程就能完全地滚起来了。所以这里边技术上不是难度，核心是大家思路上可能要思考，从过去单纯的功能实现，变成涵盖从产品经理到开发到测试到整个运转流程的所有环节可能都考虑进来，这样全面地去搭建你的流程。对，所以其实这里边你只有把你的作品经营好了，你才可能有获得直接的收费或者商业回报的可能，因为大家竞争越来越激烈。
所以第一部分其实我是想跟大家说的话呢，这个可能也是因为我一直在做技术，那很多的开发者，我觉得在这个时代大家思路上一定要转换，如果你还想从事这个行业，那你一定要从一个 coder 到 builder 的一个转换。
Speaker 3: 转换里面一定要注意的是，你除了功能实现之外，一定要注意 attention，注意你的用户的注意力，怎么吸引别人的注意力，这个可能是非常非常重要的。
这是我今天想分享的第一部分。后面还有另一个部分呢，是分享 infra 的一些思路。更多的是讲我们要构建什么样的基础，能在这个时代我们能够占领先机。对，OK。
互动问答：如何从 Coder 转向 Builder
然后我个人呢也是有两个问题。因为我非常认同吴总您说的，我们需要从一个 coder 变成一个 builder 这么一个过程。然后我也是在今年年初的时候，真正自己走过这一步。
Speaker 0: 然后我自己因为做了一些独立开发的项目，然后在社交媒体上面宣传，变成了一个小红书的博主。然后我也能看到小红书这个平台，也是跟你刚刚说 B 站一样，它有在非常大力地宣传，比如说挂载一些 skill、挂载一些小工具，然后把自己变成一个真正的 AI builder，可以让他们来形成一个商业闭环的这么一个平台。
那我比较好奇的是，您认为比如说作为一个……我现在还是一个 coder 的状态，我希望能够去获得一些 attention，您觉得最好的一个方式是什么？因为我们知道年初的时候大家都在讲 building public、building in public，那现在社交媒体上面的 building in public 内容非常的多嘛，就是有没有什么一些独特的可以找到差异化，或者说是其他的您觉得可以去获得 attention 的思路呢？
这个其实很难的。有时候你觉得：哎，我做这个东西很好、很牛，某一个功能很牛。但是其实站在受众的角度上，你会发现正好能解决他一个什么样的问题，那你一定要站在他这个角度上去考虑问题。这个我觉得是最最重要的转变。
一旦有了之后呢，其实后面的方法上的话，有很多种的方法。无非就是大家去做……我觉得有一件事情大家就是可以去尝试的，大家去逼自己去做持续性的分享。我们也看到过很多例子，很多独立开发者一开始也是无人问津的，对吧？但是他对这个方向确实对他自己想做的东西非常非常有兴趣，他也能够理解说让很多人在这方面有痛点、有需求。那不要等，不要等你这个东西做出来了，你可能在 day one 你在做这个东西的时候，你有什么好的 idea，你就在通过各种社媒的渠道去分享了。然后你的过程中你做了什么新的功能，你有什么新的想法，你把它当做你的日记都可以啊，你的一个技术日记都可以。那你一边 build 一边分享，那你这个过程中自然而然你就会发现你获得了很多关注。因为现在算法是非常强的，他一定给你找到你的同道中人推荐过来的，所以自然而然这个事情也就做起来了。
所以其实我觉得只要这个理念转过来，其实有很多方法的。我觉得现在的开发者要做 AI 的开发，一定都是最聪明也是最有想法的一波人了。
Speaker 0: 对对，非常非常同意。因为我自己感觉也是在今年也是有这么一个心态上的转变。最开始做了一些项目，可能只是以 code 为主，然后后面感觉开始拍起来或者开始发表观点起来之后，就觉得其实发表观点也没有这么的困难，然后收到的反馈大部分也都是一些正向反馈。因为很多人一开始可能会觉得：哎，我发社交媒体万一别人过来骂我怎么样？那其实根据我亲身经历，我觉得算法真的是很智能，就会把你的内容一开始都会推给那些跟你同道中人，然后你收到的一些反馈基本上都是非常好的。
Speaker 3: 对，我相信大家其实你有一个很好的 idea 你想跟别人表达的时候，你这个想法大部分情况都是非常有价值的，这个不用怀疑自己，想说我被别人笑话，其实完全没有必要。
Speaker 0: 嗯，对对对。好，那我们时间有限，我们请吴总来进行一下第二部分关于 infra 的分享吧。
第二部分：AI 时代的基础设施（Infra）构建
Speaker 3: OK，第二部分的话呢，其实我是觉得为什么在说 infra？其实我觉得因为刚才提到了软件的供给越来越多了之后呢，其实真正软件行业里面越来越多的价值在往 infra 层去压缩，这是第一个。第二个的话呢，其实对于每个个人开发者来讲，或者对于一个小团队来讲，你构建自己的 building 的 infra，可能是构建你长期价值、长期竞争力的一个最最重要的基础。
那这个 infra 的话呢，其实我核心总结两点：
一个呢是一定要有接入 SOTA 的能力，然后能够去拓展自己软件上限。那这个其实怎么讲呢，尤其是对中国的开发者，这是一件非常现实、非常有挑战的事情。那一定要你有能力去尝试 SOTA 模型，尝试 SOTA 模型的最新的能力。因为每一次大的 SOTA 模型的变革的发布，它可能带来了一些新的标志性的能力，它可能不仅仅说对过去的 coding 能力进一步的深入，它一般还会带来新的能力边缘的拓展，所以这个一定要去拓展。
第二个的话呢，我是想说到另外的 infra 的话呢，我们一定要去构建你本地 AI 的能力，你一定要具备一个自主运行和智能运行的能力。因为现在的整个 AI 的业态的环境也变化非常快，那你本地的 AI 是你完全能控制的能力。而且同时的话呢，如果你去做商业化变现，你在很多环境里边其实受制于数据安全和合规方面的影响，本地 AI 能力是一个非常重要的一个点。
那 SOTA 能力的话呢，其实我后面截了几张图啊。当然这个大家可能在社群上面也能看到，因为这是个 video 我就不放了，Claude 3.5 的，但是现在 3.5 已经出了。其实 Opus 3.5 觉得非常重要的一个点呢，就是它除了它自己的传统的长程 coding 能力在不断地增长之外，现在我不知道大家如果用 Opus 去写代码的话呢，可能你可能已经用得少了，因为你现在其实一句 prompt，它就能给你执行一个非常长长的一个任务。
除了这些之外呢，其实像 Opus 我觉得非常典型的能力，就是它的这种用代码去做 video、去做 3D 这方面的一些能力是非常非常有特点或者非常非常强的能力。甚至说可能有人觉得他在某些特定类型的 video 上，比如说广告片、宣传片，或者一些知识分享类的这些 video 的能力上，可能它比这种视频生成的模型都更合适了一点。所以其实这些能力呢，是大家一定要去尝试使用，并且去回过来去思考你自己的项目、你自己的软件怎么受这些能力影响。
本质上，我记得是谁讲的，就是你做的 agent 也好，你做的智能化软件，一定要踩中模型的发展方向，你这个软件才能获得更大的红利。所以这个模型的发展方向、模型往哪个方向走，大家一定要最多去尝试做做，到模型去感受这个方向。
那包括 GPT 也是，GPT 的话呢，它在 3D 制作上，尤其比如说在硬件 PCB 板很多方面的设计，它做得非常非常好。那所以它的这种交互式的空间能力也非常好，所以它也代表了一个模型的方向。因为这些 SOTA 模型的方向，其他的模型也都会去跟进的，所以在这些模型上呢，我们就可能就要考虑基于这些模型能力，我们的产品往哪个方向走。比如说我认识一个朋友非常好的，他 GPT 刚发布之后，他看到在硬件能力之后呢，他就做了一个很好的社区，跟比如深圳很多原来的比如 PCB 或者 CNC 的一些生产，做了很多的交互，做了很好的产品出来。所以这是对 SOTA 模型的能力的认知是非常非常重要的一个点。
另外一个的话呢，其实我们除了 SOTA 模型能力运行之外的话呢，其实我们实际上一定要构建自己的一个完整的 local 的 infra。Local infra 非常重要的一个点在于说呢，其实我们在做很多东西的时候，不管是开发还是运行的时候是需要大量的试错的，那是需要一套完整的自己的环境的。比如说我们在做的一些尝试性的项目里面呢，除了我们用核心的 SOTA 模型做我们的支柱模型之外，可能我们周边还会做一些比如说你的语音的、生成图片的、生成音乐的甚至生成歌曲的等等等等各种各样的模型，TTS、STT 这些模型都需要去构建。所以你要构建一整套这样的环境，包括你的协同的 agent 运行环境、你的 MacBook、你的 Mac mini、你的云上的 VPS，很多的环境你都要把这个自己构建好。所以这是我们的一个最基本的 infra 了。
还有一块的话呢，我觉得重点是大家谈到的话呢，是最近的一个趋势在于说本地模型、本地推理引擎在做进一步的深化。因为我们知道过去的推理引擎更多
本地专用推理引擎与模型优化
Speaker 3: 是标准化推理引擎，像 llama.cpp 啊、vLLM 啊这些标准的这个推理引擎。这个推理引擎其实不区分模型，也不区分硬件的。但是其实最近几个月呢我发现，社区有很多非常有意思的项目，大家都在做这个专用推理引擎的优化。基本上一个非常重要的特点就是围绕某一个最流行的模型去做深度优化，比如 DS4 最早 for DeepSeek Flash 的，STREATA 最早 for 千问那个呃 100 LB 这个新的 3.8 这个模型的，然后 SIMD 的话呢是它在这个比如说单台 Spark 这种统一内存设备上用得非常好。
其实这些社区的发展方向的话呢，一个是说呢它会去大大的降低你本地去运行推理的成本；另外一个的话呢，我觉得也是给了这个个人开发者一个机会，我们能够以相对低的成本——因为知道现在硬件价格飞涨，显卡、内存大家都在涨的——但是呢我觉得即使在涨的情况下，借助这些社区的项目，其实大家有机会说我在本地构建一个完整的推理技术栈，并且能够运行一个不一定是 SOTA 的，但是可能是个性价比最好的一个模型出来，并且解决你日常的很多的问题。
比如说千问 3.8 的模型，甚至你如果设备更充裕点，用 DeepSeek 的 Flash 的模型在本地跑起来，我觉得这个是非常非常……大家要充分使用这个红利啊。那包括 STREATA 这个项目我们也看了一些，它其实你比如说现在在 12G 的显存加 64G 内存上呢，可以——但它的量化会深一点，到 Q2 的量化——那它可以达到一个也达到一个很快的一个速度吧，70 多 TPS 的这个速度。
云端 SOTA 与本地模型协同架构
Speaker 3: 所以借助社区的这些能力的话呢，我们能快速的在本地构建一套你的这个推理基础设施，跟你的这个云端的 SOTA 模型结合起来用。因为我们其实有个理论呢，未来长期看，如果你的这个 build 构筑在 token 上面，那其实长期的 token 的价格，我们觉得 SOTA 模型的 token 价格还会涨，因为它的参数越来越大，它成本越来越高；同时的话呢，你这个便宜的模型可能会降。所以你可能用 SOTA 模型去做你的架构，做你的这个设计，然后用你本地的这些模型去做一些具体的推理、具体的实现，那可能未来是一个非常好的这个组织形式。
对，所以这里面的话呢，还有一个点呢就结合回来说，我们刚才说我们的去这些项目的 build，我们的这些场景，尤其一些很 niche 的、很专用的小的场景里边的构建。那其实未来的构建我们觉得是一定是 SOTA 去做设计，但是这个构建的软件呢，可能会是一个去不断试错、不断优化、不断调整的一个过程，某种意义上可能是个不断抽卡的过程。所以你本地模型的这种试错成本它不是线性的，它相对试错成本也是低的。所以这种本地跟云端结合的能力，可能未来是一个最有性价比的去构建你这个智能化应用支撑的一个能力。
然后这是当然本地模型的构建上呢，可能也会去做很多的这个优化呀，就是你从基本的运行性能到你上面的 agent 的构建，到你的这个任务的这个完成率，这个我觉得大家都可以去自己评测。因为现在的 harness 也都是开源的，推理引擎栈也都是开源的，再加上你的本地的硬件能力，其实你完全可以去磨合调整出来一套完全适合自己的一套。
比如说有些人拿两个这种 Spark 的设备跑一个 DeepSeek 的本地 Flash 的模型，上面再跑一个就像 DeepSeek Harness 这样的一个 Harness，然后再调试出来自己的一些插件，它可能能把整个的流程调得非常顺。然后在上面再对接上云上像 Claude、GPT 作为它的这个架构模型，那整个的技术栈就会非常顺滑，你在上面再去 build 你的整个的这个软件项目的时候，这个产出就会非常非常快。当然如果你在做一些视频、多模态模型的接入，那你会发现你的整个生产的工厂的能力就全都起来了。
对，所以回到我们这个软件本身的话呢，其实我们觉得说：第一个呢，软件会成为未来大的内容创造的一个非常重要的一个部分，当然也非常非常有影响力的一部分，因为它比传统的文字、视频这些都会更加立体，但是它的本质还是会成为内容创造本身。在内容创造的所有的商业模式上，可能都会在软件这个未来的生态里去体现。那未来在软件上呢，我们建议所有的开发者就是关注两个方面：构建自己的 infer，构建自己的 attention 的机制，去完成整个商业化的闭环链路的基础。
瑞通 AI 与 Token 基础设施
Speaker 3: 对，然后呢回来我就再花两分钟时间跟大家介绍一下瑞通 AI。瑞通 AI 我们的定位是面向全民构建时代的 token 基础设施提供商。
Speaker 0: 那为什么我们叫 token 基础设施提供商的话呢？其实我们所有的这个……我们的产品也很杂，然后也在不断迭代。但是我们的产品的核心的一个点呢，就是说围绕所有的开发者——所有未来的可能开发者还不准确了，可能围绕未来所有的 builder，我们去提供这个 token 的基础设施。那包括 SOTA 模型，包括本地的这种推理算力的基础设施，让每个 builder 都能够接入、管理、运行基本的 AI 的能力。
那后面那我们有几个我们的主要的产品跟大家简单 share 一下啊。
一个的话呢，我们有两个站，一个是国外 return.ai，国内是 i 动。这里边的话呢提供一些不断的产品的一些能力。第一个能力的话呢，当然我们会提供一个全性能的 Router，这个我相信大家就接触得非常多了，所有的大家常规应用转发站做的事情或者汇聚站做的事情，其实我们也会提供这样的能力，尽可能把一些比较优质的、然后价格好的模型接入进来。
第二个的话呢，其实我们还有一些平台，比如说我这个右边截图，我们会提供一些 agent 托管的能力。这个平台还没正式发布，可能很快就会 release 出来了。在云端虚拟机中呢，我们会托管完整的 coding agent，包括 Codex 啊、包括 OpenCode 啊、Pi 这些，所有的这些 DeepSeek Harness 这个都可以在上面去托管。本质上它就是在云端去提供一整套的沙箱环境，只不过沙箱里边呢我们会把 bash use 啊、computer use 啊、file 管理啊，很多能力都统一地加进来，然后去提供出来。这个平台本身呢我们会托管在全球的不同的 region 里边去做。
那我们核心解决一个什么问题呢？因为这也是我们自己的痛点。我们过去在做开发的时候，coding agent 都在我笔记本上跑，但是有时候大家也要出门啊、要怎么怎么样，那其实一合上笔记本它可能就关掉了。所以你看硅谷里边很多用那个笔记本的撑子，保证那笔记本不完全合上等等，但是笔记本它电池总是有限的，所以这个开发体验还是受影响的。尤其今天这些 coding agent，SOTA 大模型的长程任务能力强了之后，所以我们就提供一个云端的这种平台，而且是不是单一模型和单一 agent 锁定的来用。
另外一个的话呢，我们会有自己的桌面的 AI 工作环境。左边呢是我们出的一个硬件，这个是 NVIDIA 的芯片，然后是一个它的一百二十八 G 显存的一个设备，能够跑一个千问，或者是两台级联可以跑一台 DeepSeek 这样的一个环境。而右边是我们在本地做的一些 ReadWork 的一些客户端。
对，基本上分享内容就这些吧，那也欢迎大家去我们的这个平台上去注册、尝试使用，也欢迎大家跟我们去交流。我觉得其实今天是一个起点，我觉得是一个可能是非常宏大的 builder 时代的起点。
当然我也希望大家除了说……我也有一个个人的感受呢，我也希望大家除了在做一些我们传统应用软件之外，大家可能多去尝试超过我们现在做 coding 的认知的一些东西，就是能够让 AI 去尝试它智能上限的更多东西。你放开让他去跑，他可能会跑出一些超出你认知的东西，我觉得大家可以思想更加探讨一点。
我今天分享的就这些。罗丹，OK？
问答与讨论
关于 infer，其实我个人有一些好奇的点啊。然后就是您刚刚有提到说云端 SOTA 模型来进行架构的设计，然后本地的推理模型来进行推理。我觉得我们可不可以讲得深一点？就是说您觉得什么样子的资源该放在云端，什么样子的资源该放在本地，然后为什么这样子做会比较好呢？
Speaker 0: 首先这个我觉得有几块，一个是模型，一个是 agent。在模型方面的话呢，其实我们做这件事情最开始的来源呢，就是我们有个很大的困扰：我们团队有些同学就是 AI native 的，用得非常熟练，后来我们发现呢，他 token 消耗量非常大，我给他一个 Max 订阅可能都不够他一个人用的。当然他的使用方式呢可能有些需要优化的地方，但是我觉得很多人呢他是 token-maximizing 的这种逻辑在去用的。
后来我们就发现，也跟他再去做一些尝试，那是不是说你把流程里边去做一些优化？比如说你的整个的 design 你可以交给比如说 Claude 或者交给 GPT 来做，甚至交给某一个 SOTA 大模型做，另一个 SOTA 大模型校验都没问题。当你 design 出来之后，你的每个模块详细的设计、技术的架构这部分的内容都出来之后，你切下来的具体一个个的开发任务，你是不是可以交给一些这种所谓的 Flash 级别的模型来跑？
而且你还会获得一个优势，就是这些 Flash 级别的模型一般就会跑得更快，就比如像 DeepSeek 它现在的速度非常快，那你整个的速度还会加强。但是某个模块开发完了之后，它的代码的质量呢，你还要交给这个 SOTA 大模型来去做校验、来去做审核。审核校验之后，比如说有 bug 的话呢，你再交给它去修改；或者说有一些修改的就让 SOTA 大模型来评估吧，如果修改得不够全面的地方，它也可以自己来接受修改。
然后呢我们现在的……反正这是我个人的用法啊，基本上我会让比如说 Claude 来做这个整个的 design，因为我觉得它的沟通会更好，它的人机交互会更好，它不像 GPT 那么……另外它速度还比 GPT 快一点。然后第三个呢，就是它在设计、在很多架构设计上的过度防御的机制会比 GPT 少一点，GPT 有时候太过于……过度防御得太多了。
但是我把 GPT 放在什么地方呢？我会把 GPT 放在 code review 或者是找茬的这份工作上，它很细。Claude 我觉得 3.5 会好了很多，但是像 3.5、3.0 那个时代的话它很跳，它的很多东西是推测性的，它是跳的，它不是说全面检查的，所以让它去做测试的话是靠不住；3.5 会好很多，但我觉得可能还是不如 GPT。GPT 就像一个老黄牛一样，一二三四五给你所有的都给你拆得实实在在的，所以让它拿来做测试非常好。
所以其实就是大家怎么把这不同的优势组合到一块，可能获得一个最优的状态。
Speaker 1: 对对对，我相信搭建一个这样子的 infer，个人或者企业搭建这样子 infer 都是比较不容易的。那我相信 Return AI 也有类似的产品来帮助企业和个人更好地构建这样子的一个 Router 对吧？我记得 Return AI 的最主要的产品是 Token Router，是可以做这种管理不同模型……
Speaker 0: 对对，包括我们的特殊 Router 里边也把 GFE 啊这种做判断的模型加了进去，如果需要一些智能化判断的去做。
另外一个呢就是我们还做了一些刚才类似盒子。我们跟很多 OPC 啊包括 FDE 的开发者都在聊，包括前几天我还见了上海的一个同学，很强一个人，给很多企业提供服务，一年可能收入也蛮不错的。但是我把那个盒子拿给他之后他就很感兴趣，因为他跟很多企业的场景做好了设计，他从网关、agent 全套都做好了之后，他会发现我需要一个 local 的一个算力。因为他的客户的应用场景里边是有数据安全性要求的，他不能用公网的或者是外部的大模型；或者他要用外部的大模型，他要经过很多 legal 的一些审核，这个周期就会非常长。那现在给他一个盒子，他把这个盒子拿进去放到整个私有的环境里边，整个流程就通了，而且成本也不高，所以我觉得这个也是蛮有价值的一个点。
Speaker 0: 单台 128G 的……
Speaker 0: 马上发布那个 RTX Spark 的，其实已经发布了，只不过第一批发布可能都是笔记本形态的。你看到微软啊、华硕啊都是笔记本形态的，但是我们后面会跟机械革命联合发布一个盒子形态的，其实都是 128GB 的显存的形态。这边是英伟达的芯片，大概 1 PFLOPS 的算力。单台的话呢大概能运行一个 200B 以内的模型；如果你多台级联的话呢，可能就会运行一个更大尺寸的，像 DeepSeek Flash 现在应该 700 多 B 的，那可能需要三台，就是 1017 的；然后如果五六百 B 的可能两台左右就能跑起来。基本上现在市面上以 Flash 后缀的模型都能在一台或者两台这样的设备上跑起来，速度还不错。所以我觉得还是一个非常有用的点。
对，那就我个人而言呢，我也是非常认同吴总分享的就是 attention 和 infer，因为我自己也是身在其中。那么对于每一个 AI builder 来说呢，有一个好的获取 attention 的渠道以及一个好的 infer，我认为确实是每个 AI 时代的 builder 一个新的开发方式的基础。但同时呢我们也知道，在这个开发的过程当中，依旧有非常多由这个新的开发范式所带来的问题，那其中一个问题就是代码的安全跟……
Speaker 1: 质量。所以我们下一位嘉宾呢是来自 Sonar 的 Justin，他是 Sonar 的 solutions engineer。呃，Sonar 的主要产品是 SonarQube，就是一个致力于解决代码质量与安全的这么一个产品。我们首先先请 Justin 也跟大家打个招呼吧。
Speaker 1: 周磊好，你好 Justin。唉没问题，您的声音非常非常不错，对啊。
Speaker 1: 好的好的，呃那我们呃对对对，Justin 呃这边可以简单介绍一下，比如说你呃 Sonar 是做什么样子的工作的，然后你在 Sonar 是做什么样的事情的，可以吗？
Speaker 1: 好的，大家周六好，我是 Justin，Sonar 的解决方案工程师。然后我们大概在业内已经有十八年了吧。啊之前开始的时候呢主要是看代码质量的，后来呢我们就进入了代码安全方面。那最近呢这个跟供应链相关的问题非常多，比方说上个星期那个呃 LogtoShell 还有呃 PHP to shell，所以我们也开始可以检测跟这个第三方的这个开源软件相关的安全漏洞呢，也是可以用 SonarQube 来检测的。然后最近呢这个 AI 的开发的呃这个发展非常的快，那如果大家想确保这个 AI 的工具本身的安全的话呢，也是可以考虑使用 SonarQube 的，感谢。
Speaker 1: 哎好的，谢谢 Justin。呃这边有朋友说听不到声音，哦可以可以听到，好的好的，那没问题没问题。嗯那行，那我们就把时间交给您吧，就是您这边可以分享一下屏幕，然后来开始一下你的精彩的分享，好，感谢。
基于 AI 代理的软件开发与代码质量挑战
Speaker 1: 哎好。我们今天感谢，我们主要所要讨论的话题呢，就是大家啊怎么样使用 SonarQube 来协助我们如果是用这个 AI 代理来驱动软件开发的话。
Speaker 2: 啊首先呢，我先做一个这个公司的介绍。Sonar 呢大概嗯在 2026 年啊有做大概七百万到八百万的研发人员在使用 Sonar、SonarQube。然后我们在 Docker Hub 上面的下载量呢有十亿左右。啊我们目前为止呢最新的版本是 26.5，是在今年九月份发布的。支持的编程语言呢大概在四十种左右。然后每一天呢，我们扫入到 SonarQube 分析的代码呢在这个八千亿行上下。
那我们连续五年呢在这个 G2 的这个使用者评分当中是评为最受欢迎的代码质量和安全的检测工具了。那就啊全球这个前可能 75% 在这个财富一百强公司当中呢，除了这个大摩呀、小摩呀，或者是这个 NVIDIA 呀、微软啊，这个阿斯麦就是做那个光刻机的，还有这个 Deloitte 还有 KPMG 在使用这个 SonarQube 之外啊，有很多公司都在使用 SonarQube 去确保它的代码的质量和安全了。那国内的话呢，这个金融、保险啊、高科技行业都是有这个客户在使用 SonarQube。
那目前我们这个行业的现状跟挑战是什么呢？我相信大家肯定呃有看到相关的新闻啊，呃比方说某一个这个 AI 代理把这个客户的整个的数据库都删除掉了，又或者是说啊某一些不规范跟安全的使用这个 AI 的工具过程当中呢，导致这个客户的这个啊数据或者是密码、密钥的泄露。那嗯这说明什么呢？就说明我们需要对这个 AI 所生成的代码进行验证，然后才可以去发布它。
啊那呃 Sonar 呢也给大家提供了一个免费的服务，我们就是说对这个最新发布的模型的版本呢，就代码的质量和安全进行了一个测评。那这个测评呢是使用标准的这个 OpenAI 的代码，去把它扫入到 SonarQube 之后跟不同的这个模型协作。我们发现呢就代码行数，就这个每百万的百万级代码的代码量的生成的复杂度、它的品质和安全，还有问题的密度，不同的模型的表现力都是不一样的。所以大家在这个考虑使用不同的模型完成不同的任务的过程当中呢，是可以首先到这个 SonarQube 的官网上面去查看我们的测评，然后就不同的任务可以选择不同的模型去完成它。啊那么这个服务呢是免费提供给我们所有的客户的。
好，那我们在在这个啊去年年底和今年年初，对我们的这个七百万的这个会员呢进行了一个问卷调查。那呃大概呢在这个只有百分之啊三十左右的客户是对这个 AI 所生成的代码呢是具有高度的信任度的，啊还是有啊非常多的研发呢对这个 AI 所生成的代码的信任程度呢还是很缺乏的。
那在这个啊如果使用这个智能体或者是说 AI 代理完全做这个软件开发当中，会遇到哪些问题跟隐患呢？首先就是它缺乏一致性。我们发现如果把相同的任务啊交给这个 AI 代理或者跟不同的模型协作的话，它很有可能啊生成的代码的这个质量是不一致的。那另外呢就是呃可能过一段时间之后我们需要去维护它。啊作为研发来讲，想要读懂 AI 所生成的代码呢是有一定的困难的。那另外呢就是啊在这个缺乏上下文的前提之下，那很有可能呃 AI 呢会自主做一些很有趣的决定，那这样的话呢就导致可能跟我们的任务所期望呢是有一定的差距的。
那除了这个 AI 所生成代码的质量之外呢，就是面临这个合规呢也是有一定挑战的。啊我们说这个由于它生成的这个内容呢缺乏一致性，所以想要通过审计，或者是我们某一些客户是有这个出海的需要的，那出海的话呢是有很多这个啊业内的安全标准，不管是 OWASP 还是 CWE 啊或者是 PCI。那最近欧盟又推出了一个新的标准叫 CRA。那其实呃我们呃出海呢，就安全方面、这个审计方面的要求呢，其实就 AI 本身是很难去满足它的，因为它具有高度的不一致性。那如果我们的客户已经百分之百的由 AI 生成代码和由 AI 审代码的话，那到最后如果生产环境产生问题的话，那这个责任归属的问题呢也是很不明确的。
那就啊运维的角度上来看，我们发现其实啊大家如果看看到这个，Uber 今年大概在四月份的时候，应该是已经把它全年的 AI 预算都烧完了，啊所以呢呃就管控这个使用 AI 工具的这个费用跟消耗的话，其实也是有挑战的。那如果我们想要这个使用 AI 的代理或者是模型生成的结果具备一致的一致性的话，那么我们就要啊去管理它所使用的上下文。那这个上下文管理呢，目前来讲其实也是一个各自为政的状态。为什么这样说呢？因为不同的项目可能它的需求是不一样的，那这个上下文是在我的管控平台去管理它，使用这个第三方工具去管理它，然后我的任何一个研发人员可以在本地去修改它吗？所以这个方面的工程管理也是具备一定挑战。
那另外可能现在大家选择集成的工具呢，通过不管是 MCP 也好，直接调用 API，还有或者是说 agent 和 agent 之间直接去沟通的话，其实在这个运维方面也是有一定成本的。
Sonar 围绕 AI 代理的三个开发闭环与核心 Agent
Speaker 2: 那所以呢，SonarQube 就推出了一个基于这个 AI 代理为中心的软件开发周期的三个闭环。
这三个闭环当中呢，第一个就是在这个开发过程当中，我们为大家提供了一个 Sonar Cortex 的服务，啊去啊给给我们的这个 AI 代理和模型提供充足的上下文。啊有了这个上下文之后呢，就可以确保这个模型所生成的代码是没有质量和安全问题的。那如果模型呃自主做了决定以后，您也是可以通过这个 Cortex 的服务把 AI 生成的代码直接丢给 SonarQube 去分析它的。
那第二个闭环呢，就是在这个 CI/CD 的过程当中，那大部分的客户呢会在这个呃版控平台里边，或者是说创建一个 pipeline，把相对应的这个修改扫入到 SonarQube 的服务器端。那如果大家开通了这个 Advanced Security 的话，所有跟这个供应链安全相关的，也就是说跟这个第三方的服务器端扫入的安全漏洞呢，也是可以在 SonarQube 当中去检测到的。在 SonarQube 当中去扫代码呢是完全基于规则的，目前最新的版本呢，我们服务器当中的规则有九千、九千条左右。那 git-agent 呢是完全通过 AI 的方式去扫描代码的，等一下如果有时间的话呢，我们可以给大家做一个演示。
那最后的这个闭环呢，就是和这个啊代码维护相关的。呃因为管道呢通常情况下在这个 CI/CD 的过程当中，可能我们去呃分析最新的修改，或者是说这个目前开发周期的改动罢了。那如果一个项目已经有五年或者是十年的话，就历史的代码我们如何去快速地把它解决掉呢？在 Sonar 当中呢，我们为大家推出了另外一个代理叫 remediation agent，是来这个啊帮助大家使用这个 AI 的方式，自动地把系统的问题抓出来，然后去解决掉它的。
那最后一个很重量级的这个代理呢，我们叫它 hunter agent。在讲 hunter agent 之前呢，我们首先想分享的就是，目前呢全球可以直接使用 OpenAI Deep Research 的公司呢，大概啊二四六小于五十个，那 Sonar 呢就是其中之一。那 hunter agent 我们是直接和 OpenAI 的 Deep Research 对接的。那么为什么我们引入了 hunter agent 的概念呢？就是因为目前所有市场上面的静态的代码检测工具呢，基本上 99.9% 了全部呢都是基于规则的，它只是针对您的这个代码的语法和格式去扫描质量和安全的问题罢了。所以 hunter agent 呢是百分之百完全使用大模型的方式去扫代码的，而且是针对于不仅是当前的开发周期，而是整个开发分支的。
那就目前 hunter agent 的检测能力呢，首先是包括三个方面：和这个访问控制相关的，和这个业务逻辑相关的，和这个授权和会话、或者是说在这个 session 啊、token 啊或者是 cookie 啊在这个会话当中有不安全操作的，啊主要是针对这三个方面的安全去扫描它。将来呢我们会把更多不同的安全隐患的检测的能力也添加到 hunter agent 当中。
我们很多客户呢，如果是需要做这个 VAPT，不管是这个黑盒的还是还是白盒的这个压力测试的话，可能对我们的这个研发团队是不友好的，因为往往是在这个啊项目开发的后期可能您才可以拿到这个压力测试的报告的。那使用这个 hunter agent 的话呢，您就可以在这个开发周期的过程当中做任何的修改，在某一个开发分支当中做这个白箱的压力测试了，所有的报告呢都会集成到相对应的业内的安全标准当中，等一下呢我们就会给大家去演示它了。
那我们刚才说啊有很多的历史遗留问题呢，大家不管使用的是任何类型的这个静态代码检测工具的话，它都是基于规则的，这就是为什么我们推出了另外一个代理叫 hunter agent，它是基于模型的、基于 AI 的，是一个白箱的测试，因为这个呃代理呢是可以直接访问到您的源代码的。那么我们研发每天面临的压力都很大，然后我们开通了这个 hunter agent 服务之后呢，我们可能有更多的问题需要去解决它，那么这样怎么办呢？所以在 Sonar 当中呢，我们推出了另外一个代理叫 remediation agent。这个代理呢也是百分之百这个模型原生的啊。我们的研发呢就不需要自己去查看这个呃静态代码工具根据规则扫出的问题，还有这个 AI 的 agent 扫出的问题呢，都不需要自己去解决掉它了，我们使用 Sonar 的这个 remediation 去解决掉它就可以了。
那使用 Sonar 的这个代理和使用您自己，不管您用的是这个 Claude Code 还是 Codex，还还是其他的这个 AI 工具的话，啊去查看现有的问题和解决掉它的主要区别是什么呢？啊 remediation agent 在提供建议之后，同样也会使用我们静态代码的规则去扫描它，去确保它一定是可以通过质量门禁的，才会把相对应的修改建议和修改提交到您的版控平台当中。那使用其他的代理去修改代码的话，很有可能是没有办法通过 SonarQube 的质量门禁的验证的。那么当然这个质量门禁当中的条件，不管是和安全、质量、这个复杂度、重复度，还是功能性的测试度，还是跟这个第三方供应链安全相关的这个定义的这个条件，都是可以由客户去管控的，但是我们的 remediation agent 所提供的修改建议呢，一定是可以通过这个质量门禁的验证的，那么客户呢就可以直接去进行测试、部署，或者甚至去发布它了。
好，那在这个代码维护的过程当中，去用 AI 的这个工具去修复现有的质量和安全问题呢是不足够的，因为大部分的客户呢其实是没有办法直接修改某一个开发分支的。研发在啊引入一个改动的过程当中呢，一定是需要创建一个 PR/MR 的。那如果我们的客户呢已经使用 SonarQube 或者是说其他的静态代码检测工具的话，您通常情况下会创造一个 pipeline，它会自动地监听这个版控平台当中的某一个提交或者是 PR/MR。那正常情况下呢，它就会去扫入到 SonarQube 的服务器端。那么一样的，这个扫入呢是基于规则的。那么基于规则的扫描呢，同样地会生成一个质量门的结果。如果这个质量门是失败的话，就表示目前这个 PR/MR 当中的修改是不应该啊合并到目标开发分支当中去的。
那如果这个 PR/MR 是这个通过质量门禁的话，啊我们在 SonarQube 当中引入了一个百分之百 AI 原生的代码检测工具，它叫 git-agent 啊。它也是一个呃 AI 的代理啊，我们是通过 AI 的方式去检测 PR/MR 当中的修改。那如果啊您有把相对应的这个修改同时扫入到 SonarQube 当中的话，这个 git-agent 的 AI 代理呢是可以读取到这个检测结果的。所以在 agent 当中除了用 AI 的原生的方式去检测您的修改以外，也是可以读取到 SonarQube 的检测结果的。在这之后这个 agent 会做什么呢？这个 agent 就会提供相对应的修改建议，那么这个修改建议呢也是可以自动地提交到相对应的目标的开发分支当中去的。也就是说在您创建这个 PR/MR 之后，甚至如果这个 PR/MR 是这个另外一个 AI 代理创建的，它是可以自动地通过 git-agent 去分析它，通过这个 git-agent 的这个 AI 代理呢去读取 SonarQube 的检测结果，然后提供相对应的修改建议，甚至直接提交到相对应的开发分支当中去。
那由于如果您允许这个 AI 代理去修改这个代码的话呢，它又会触发另外一个自动的扫描，这个自动的扫描呢就会重新把 AI 的代理所提交的修改扫入到 SonarQube，您就会看到新的质量门的结果。那么这个循环呢就会继续，直到我们的 AI 的代理呢成功地使用基于 AI 的方式和使用 AI 的方式呢把这个问题解决掉。这个质量门禁通过的时候呢，啊系统才会提示您可以继续进行测试、部署，甚至啊可以直接去发布它了。
好，这个就是在在这个 CI/CD 持续集成的这个闭环当中，Sonar 所给大家提供的相对应的工具是什么。是可以完全要求这个 git-agent 的这个代理呢自主地去检测代码，啊去提供修改建议，啊去读取这个基于规则的这个问题，然后直接把它修改掉了，并且提交到这个开发分支当中去的。
那最后的闭环呢，就是在这个开发过程当中。啊往往我们的研发呢啊会把相对应的任务从这个需求文档当中呃拿出来，然后把它交给这个 AI 去完成它，或者啊可能会就是直接把整个这个文档就交给就给某一个 AI 代理的话，由 AI 去自己决定如何去设计它，如何去把这个相对应的这个啊代码去完成它。那么使用 SonarQube 这个 Cortex 的服务之后，啊您就可以要求这个 AI 的代理呢，在把这个任务分享给某一个模型之前，先去 SonarQube 的服务器端拿到相对应的上下文。
这个上下文包括什么呢？这个上下文包括您目前项目当中的架构啊。目前业内可能这个跟架构相关的工具并没有非常的多，那在我们的代理跟模型生成新代码和修改代码之前呢，一定是需要读取这个目前项目当中的架构的，不管是比方说这个 delegate service stem 还是 persistent stem，它需要决定我新生成的代码要放到什么地方去。那使用 SonarQube 就可以提供跟这个项目架构相关的上下文，因为服务器端呢会分析您目前不同的代码之间的调用调用关系是什么，并且把调用关系呢以 JSON 文件的形式返回到代理端，然后代理呢就会把这个上下文分享给模型了。
那么第二个上下文是什么呢？就是在执行相对应的任务的过程当中，有哪些业内的质量和安全的标准是我们的模型应该去参考的。啊这样的话呢就可以确保这个我们的模型在生成代码的过程当中，避免生成的代码当中存在跟这个业内的质量和安全规则相关的问题了。
那第三个方面呢，就是跟这个开源软件的安全漏洞相关的。在这个模型生成新代码之前，我们是可以要求代理去 SonarQube 的服务器端拿到目前的项目是否有跟第三方这个开源软件相关的安全漏洞的。如果有的话，那么我们的模型就应该避免去使用它；如果没有的话，在模型生成这个代码之后我
Speaker 2: 们同样的可以要求代理把新生成的代码、使用的开源软件提交到当 sa help 的服务器端去分析它。这样的话呢，您就可以避免发生这种 node to shell 还有 PHP to shell 的这个跟供应链安全相关的安全隐患的问题了。
那我们在之前有讨论到说用这个 AI 也是可以去解决代码当中的质量、安全或者是说跟这个业务逻辑相关的问题的。那去修改这个相关的问题的过程当中呢，我们会发现就相同的安全隐患呢，其实在不同的模型和不同的这个上下文的前提之下，模型所生成的这个修改建议呢也是具有高度的不一致性的。那么如何我们可以在这个修改的代码的过程当中提供高度的一致性呢？大家是可以去要求这个代理呢去三八 q 去拿到相对应的修改问题的上下文的有哪些是最佳实践，用这个最好的方式把这个问题解决掉。这样的话呢，我们在这个解决问题的过程当中也可以同时具备高度的一致性了。
那在我们拿到相关的上下文之后呢，我们的代理就会把上下文分享给模型，并且去生成相对应的代码或者是修改现有的项目当中的代码了。在这个修改和生成的任务完成之后，我们可以要求模型呢不要直接报告给研发说这个问题已经完成了，我们可以要求我们的代理呢把这个模型生成的中间结果发送到相当 cube 的服务器端去分析它。那么这个分析的代码之后，如果有质量问题的话呢，我们是可以要求我们的代理把相关的问题还有生成的代码一起发送给模型端，要求模型去把这个问题解决掉的。所以直到我们的这个代理去这个三八 q 服务器验证之后没有问题的时候，才会去开始去构建它，去测试它。如果测试通过的话呢，我们的研发也可以要求我们的代理呢直接就创建一个 PRMR 了。如果这个构建的动作或者是测试的这个动作是失败的话，我们就可以继续再和这个 AI 代理去交互，然后把这个问题去完成它了。
好，这个就是我们在这个开发的过程当中所给大家提供的解决方案，叫 vote tax，是帮助模型可以访问到更好的上下文，然后可以动态的在这个模型的生成代码的过程当中呢，由这个代理去发送相对应的这个扫描请求，然后由代理把这个生成的这个问题分享给模型，由模型去把这个问题修改掉的。
好，谢谢 Justin。您这边还有其他的 slides 要分享吗？还是我们可以互动一下？
啊可以互动。对对对，我们评论非常精彩。我觉得我个人也是之前在公司工作的时候也是经常性的觉得，一个人写代码是真的很挺爽的一件事情，但是大家一起写代码就会需要有非常多对像刚提到的在本地、在 CI/CD、在这个 agentic 闭环
Speaker 1: 一个是这些 a 折腾的具体实现方式方便分享一下吗？我想刚刚您其实已经介绍过挺详细的了，不知道比如说对于这个 soar cube 或者说是其中的一个 agent，你有没有可以希望可以再展开讲一讲的一个部分？
好的好的，我们就讲这个可能最近最流行的就是使用模型来去检测这个安全问题的话，其实我们的模型内部呢是有相对应的 playbook。就不同的安全隐患呢，其实我们检测的方式是有很大的差别的。在模型内部呢，其实他拿到的问题是非常多的，我们会在模型当中去确保其实这个问题对客户是有真实的影响的，才会去报告出来。
Speaker 2: 那今天的这个幻灯片里面，我们并没有列出说我们跟这个比方说跟科色还有 clock code 的横向对比。那用 AI 的工具去扫描代码呢，其实它目前来讲是有高度的不一致性的。大家如果在线下去尝试的话就会发现，用同样的模型和代理去扫相同的这个开源软件的话，第一次、第二次和第三次扫描的结果其实相差是非常大的。那如果扫描的结果具有高的不一致性的话，其实在实际的工作的过程当中呢，却是很难去使用它的。
所以如果大家想要自己设计一个百分之百基于安全的这个代理去扫代码，是不是可以呢？当然是可以的，可是您会发现如果没有一定的 harness 的话，它就具有高度的不一致性。那 harness 涉及几个方面呢？就是您需要对业内的安全标准首先要很了解，那所有的安全标准当中所涉及的使用场景，比方说这个未经授权的访问的使用场景分别是什么，其实在我们的 asian 内部的 playbook 都是有相对的定义的。目前的这个 harness 的跟安全漏洞相关的这个使用场景的定义呢，是没有开放给我们的客户的，而且我们目前呢是不允许客户去修改它的。
那么在将来呢，如果使用的客户足够多，然后客户发现我们内部的这个代理所定义的这个 harness 的规则，不管它是基于 workfload，我们内部叫它 plybook，是不是会开放给客户去自定义它呢？我觉得是很有可能的。所以如果大家自己尝试去开发一个 AI 的代理去对接某一个本地的模型去扫代码的话，一定是可以的，但是您一定会发现：第一，它具有高度的不一致性；第二，我们也跟那个 class security 除了扫描质量、扫描一致性做了横向对比之外，我们也和消耗的偷窥跟这个 cloud，sorry，跟那 cloud security 做比较，我们大概是它的大概百分之十的费用。
所以在 harness 的过程当中，您是不是直接就复制粘贴，从比方说从那个 o 瓦斯的官网上面把整个的文档都复制粘贴下来丢给 agent，让 agent 自己去想、自己去读、自己去扫，和您有足够的 harness 去明确的规定不同使用场景的话，我们的代理是如何去扫代码的，那么对这个扫描的质量和最终所消耗的坑量是会产生很大的影响的。所以这个 toagent 扫、用 AI 的方式去扫代码的结果跟效率还有费用怎么样，就取决于您的这个 harness 是做的怎么样了。
了解了解，谢谢 Justin 的分享。我们这边还有一个问题啊，就是关于代码审查的，也就是说，抱歉我再抛一下，想问一下就是关于代码审查验证当中，现在您认为或者搜纳认为人或者工程师参与度应该有多少？因为我自己体感也是，代码现在 a 证式的代码速度太快了，肯定不能用原生的用人眼看的方式来进行审查。那这边松 ina 是怎么思考这样的问题的，或者有
是的，大方向的话，一定是生成代码的模型第一个级别的审查代码的模型和第二个级别的一定是分开的。首先我们是不可以用同一个模型既去生成代码又去审代码的。那审代码呢，又涉及到和本身和质量安全相关的，那然后另外呢又有跟这个业务逻辑相关的、跟这个功能性相关的，其实呢也是要分开的。
那就在审代码的过程当中，其实我们是可以定义内部规范
Speaker 2: 的，哪些工作流是关键工作流，比方说跟这个绘画相关的，比方说跟这个支出相关的，一定是有一些工作流是关键工作流，那有一些可能是非关键的，比方说我下载一个消费记录。这个在要求 AI 选代码的过程当中，您是可以要求 AI 与此同时去标识某一个特定修改的。如果某一个关键路径当中有修改，并且不同的 AI 标识的结果是不一样的话，这种环境下的话，我们就其实认为需要人为去审代码了。
所以大家在使用这个 AI 去型代码的过程当中，希望是可以使用不同权力的模型去做设计、做生成、做第一个级别的验证。那就质量安全和功能性最好是可以分开的。那另外呢，就是我们一定是要定义 AI 在审代码的过程当中哪些是关键的、哪些是非关键的，这样的话呢我们才可以更好的分配我们这个研发有哪些的任务需要人为的去干预它。
了解了解，就是模块化我们的代码，然后把重要的东西、最重要的东西人还是需要去把关的，然后一些是不重要的可能非常 agent 的实现自动化。那关于审代码的能力未来还重要吗？我个人认为还是重要的，不知道您这边是怎么看？
对对，我们其实我们内部呢也有很多时候我发现说，我们我我自己的团队，因为我们有些时候会帮客户写写工具什么的，然后就在思考说为什
Speaker 1: 么 AI 的工具的代码写的还是挺复杂的。对，因为他可能思考的方式跟我们是有差别的。那就工能上功能性本身而言，其实我觉得百分之百的要求 AI 去写代码是没问题的。但是还是那句话，就是就关键路径而言，就是有某一些功能如果出
所以我们在定义给 agent 定义一个 workflow 和提供上下文的话，一定要标识。有很多时候如果大家就是充分使用我们的 a en 的话，一定会发现说它就算就算我们定义的规则，它其实也会自主做很多决定的，更何况如果我们没有的话。所以去明确的标识哪些是关键任务，甚至要求 AI 其实是有一个发送消息的机制的。那不同的客户使用的这个消息的机制可能方式是不一样的，那一定是要求 AI 去提醒我们的研发，其中的其他的 AI 代理只有关键模块做了修改。然后问这个省代码的代理，如果是要求你来改代码的话，您所提供的建议是不是跟生成代码的这个模型是一致的？那如果不一致的话，其实就应该发送消息给研发去看了。所以其实就涉及到我们的这个内部流程的管控的话，其实每一个客户可能的选择都是有一定差异的。
了解了解，对，而且就是 echo 一下刚刚我们前一位分享者吴总的这个观点啊，就确实也能看到就是不同的模型在不同的工任务当中的能力是不一样的。比如说代码这个环境当中，确实像我个人体感也是 GPT 的这个能力会非常的强，因为它显的非常细致；但是在某些比如架构设计上面，它很可能会过于细致。所以在这个过程当中用不同的模型来做不同的任务，审代码用什么样子的模型来做也是
Speaker 1: 一个非常有意思的观察。对，好，就西您这边还有一个小的 demo 要做是不是？
啊是，我对就是想跟大家分享一下，我们现在相当 keill 最新版本当中呢，其实给大家提供了当中，我们刚才说这个上下文和这个在开发的过程当中去分析代码的叫 voar tax，然后百分之百使用 AI 去解决问题的这个代理呢叫 remediation agent，然后百分之百对接这个模型去扫描安全问题的话呢叫 hunter agent，那如果是跟供应链安全相关的呢就叫做 advance security。那如果大家所有的服务都开通之后呢，这个安全本身访
Speaker 2: 问这个安全报告的话呢，比方说我打开某一个安全报告的话，那研发所手动编写的代码和代理所生成的，还有这个跟供应链安全相关的 hunter agent 所检测到的问题的话呢，全部在这个报告当中一次性的就都可以查看到了。所以大家就不用去不同的平台等这个最终的报告来，就可以快速的在每一天的开发当中去了解到具有某一个安全标准的话，系统当中目前高严重级别的漏洞是什么。
那就已经检测到的问题，在三三 q 的服务器当中呢，其实我们是不需要手动的去修改它的，把它发送给一个代理就可以了。那么这个代理呢，除了可以您手动的把这个问题发送给他要求他去解决掉之外呢，也是可以用这个自主的方式要求我们的这个 remediation agent 呢，比方说每天等这个大家都回家了、凌晨的时候，然后你就开始去我们的项目当中找问题并且把它解决掉，也是可以的。
如果是这个 PRMR 的话，在这个 PRMR 阶段的话，同样的也是可以把这个 PRMR 当中的这个问题呢发送到我们的代理端，要求代理去解决掉它的。那当代理接受到这个解决问题的任务之后呢，他就会创建一个 remediation 的 branch，然后去读取这个问题呢是从哪一个分支报告出来的或者是检测出来的，然后他就会提供相对应的修改建议，然后呢直接把相对应的修改提交到这个 remediation 的这个分支当中去。那我们的研发呢就只需要查看相对应的修改，
Speaker 2: 审批到对应的分支当中去就可以了。那大家想要手动的去使用它，或者是说自动去使用它，我们自主决定就 ok 了。
那在这个 hunter agent 呢，我们刚才说是分三类，那 hunter agent 的 issue 呢也会列到这个问题的列表当中去。我们如果快速的查看某一个类型的问题的话，让大家对这个行州有一定的了解的话，我们可以去筛一下。我们就发现说某一个这个 API，他可能允许用户执行任何的这个客户端的程序的话，并且是没有被安全授权的。那这一类型的问题的话呢，使用规则是没有办法检测到的，只有使用这个模型的这个方式呢才可以被检测到的。
好，我还有时间吗？
我们差不多，时间差不多了。
好好好。
对，我觉得非常详细了，对对对。非常感谢 Justin，我觉得我个人也是学到非常多。我们弹幕里面可以给 Justin 鼓个掌或者扣个一啊，谢谢谢谢。然后谢谢家家。
Speaker 1: 对对，谢谢大家啊。对，那 Justin 我们的时间差不多到这儿了，非常感谢您精彩的分享。
然后有，对，sooner 的这个官网是什么？我可以在 chat 里面发一下，然后后一 m 对，要您这边方便发一下吗？
Speaker 0: 在这个单发对日水 ok，
行，那我们感谢 Justin，然后我们期待跟社区的更多的这个互动之后，好吧？
那么 Justin 的分享我觉得是非常的扎实的，就是说在这个真实的开发环境当中呢，代码质量与安全审核一定是一个值得被讨论和探索的话题。但我们代码制作出来 AI 应用之后呢，我们如何在这个生产环境该被这个观测以及调试也是一个非常重要的话题。那么我们今天非常开心也请到了这个隶属于开源数据库 ClickHouse 的 lengths 产品团队，来作为这个 LM engineering 的平台之一呢来进行一个自己的分享。我们请到的是 Sarah 葛葛总，是以 ClickHouse 在这个大中华地区的 country manager。对，那我们先请 Sarah 跟大家打个招呼吧。
Speaker 2: 嗨各位小伙伴大家好啊，非常感谢 super leineer 社区的安排啊。今天上午我也是学到了很多业内新鲜的知识，非常感谢 Gordon。
Speaker 1: 哎好，你好 Sarah。对，就非常感谢您能来。然后这边的话 Sarah 主要分
Speaker 1: 享的话题是 Langfuse 是如何帮助一个 AI demo、AI 应用从 demo 到一个可观测、可落地的这么一个生产环境的这么一个状况。呃那这边我们，画面呃您这边有有，可以分享一下屏幕吗？就是有这个？可以的。
Speaker 2: 后这边好的。啊 sorry 啊，各位小伙伴啊，线上的小伙伴，大家好。这一上午非常感谢啊。
Agent 白盒化与可观测性背景
那我今天分享的主题呢，主要就是 Agent 的白盒化——一个基于 ClickHouse 和 Langfuse 技术搭建的 Agent 可观测。哈之前前面特别是桑呃特别是 Justin 这个，特别是 Justin 啊从 Sonar 也在讲了这个方面的一些重要性。今天我主要分享的是在生产实践中如何让 Agent 呃跑得更好、跑得更快。
那我呃我是 ClickHouse 中国区的 team leader，那跟我一起参加这个分享的呢，还有我们中国区的 engineering manager 佳琦唐。好，呃这个呢我们也看到哈，刚呃这是这是几则新闻啊，大家看到 Uber 和 Microsoft 都是大量的在使用 Agent，可是他们在半年的时间就用掉了一年的 budget。那第二个，中间这则新闻呢是来自于我们国内的一个同行，他呢在使用 Agent 的这个编程的过程中出现了一个 bug，一个星期就用掉了两百万人民币，这一个小组啊。所以可见费用是非常的不可预估的。那在 web coding，刚才 Sonar 的同事已经介绍了一些啊，在 web coding 方面存在的一些隐忧。
好，那今天呢我主要是从这个 Agent 可观测在生产实践中呢它遇到的一些挑战，以及 Langfuse 一些独特的独特的能力，和这个底座 ClickHouse 这几个方面呢来跟大家讲一下，这个介绍一下 Agent 的可观测。
好，那我们在企业中呢，Agent 现在已经大量上线了。但是从 Agent 上线的那一天起，我们就会发现传统的可观测 APM 这套体系呢已经渐渐失效了。为什么呢？因为当我们月底看到账单的时候，模型费用可能是这个月预算的三倍、四倍甚至五倍。那么可是打开我们的现有的 APM 的这种可观测系统呢，你会发现它的延迟是正常的，它的错误率是正常的，一切都是绿灯。那么我们这时候就需要一个有力的工具来告诉我们到底每一个 token 都花在了哪里，为什么这么花，花的是否有效。
好，那我今天会有一次机器巡检的这样一个例子贯穿始终，来描述一下作为 Langfuse 的这个 Agent 可观测是怎么解决这样的挑战的。好，一次机器巡检呢，基本上我们有分为四个阶段哈： 第一个阶段，我们对 Agent 提出一个需求，我要做一个巡检，呃提出一些范围，让 Agent 呢给我做一个方案； 那第二个阶段，方案回来了，我要做一些修改，跟它调整一下巡检的重点了，确定一下执行的顺序； 好，接下来第三步，也就是重头 token 消耗工作，Agent 开始调用多个工具来这个执行这个巡检，三十多分钟以后这个巡检完成了。 那好，它给我提供一份初步的报告。对这个报告我看了一下，我有一些质疑。譬如说我会发现：哎，怎么在某个端口有三千多个这个三千多个威胁？这是为什么？那我会让 Agent 再一次深入地去调研，就这个给我一个深入的调研结果。
所以这个呢，一般就这个是我们做机器巡检的四个过程哈。那这样的一个过程对于传统的 APM 的这个可观测体系很有压力的，它无法去感知到底我们在这个过程中 Agent 它做了什么、调用了哪些 token、执行了什么工作。所以说好传统的 APM 工具它不是不够好，只不过呢它不能够承担在 Agent 时代 Agent 运行时候的这个我们的监测需求。
好，那 Agent 可观测它有几个特点啊： 第一个，它的路它的路径是动态，只有在 Agent 在生产的时候那才能选择路径，无法预先埋点； 那第二个，成本不透明，在 Agent 每次运行、模型每次在做决策的时候都在消耗 token、上下文呢，这些都是呃在滚雪球的消耗，你看不到它的在传统的 APM 里你看看不到的消耗耗在哪了； 再有一个我们称之为静默偏差，也就是当 Agent 给我们一个答案的时候，我们并不知道它对错，如果它是一个错的，这个就被诱导了，那整个最终产生的结果是错的，可是系统却浑然不知； 呃再有一个呢，我们 Agent 的可观测呢它是一个多轮交互的过程，每一次都有很多会话，累积了大量的上下文长文本、海量数据。那么这个对于传统的 APM 来讲，这个数据库呢是支撑起来这个压力甚大力不从心的啊。两点之间假如这两点是固定的，在这两个时间段最小值，那这两点之间之接短了。
好，那么针对 Agent 的可观测，我们确定了三步走的方向，怎么才能更好地做一个可观测方案： 第一步，我们要有工具去支持我们去通过告警和 dashboard 去发现到底问题出现在哪，出现在了什么时间段； 那第二步呢，我们要通过工具来排查，通过 trace 下钻呢、trace 评估来排查到底问题出现在了哪，怎么去改正； 那第三点呢，就是所有的这个学习、所有所有的好的 practice 要能够好的 prompt 要得到沉淀，把它沉淀进知识库，然后让 Agent 呢反哺 Agent，这样在 Agent 下次工作的时候可以提升它的这个呃工作质量。
Langfuse 的核心能力与实践
好，那 Agent Langfuse 这套呢是一个非常专业的专门为 Agent 设计的一个可观测体系。那我们会从它的链路追踪、它的质量评估和它的提示词管理三个方面来跟各位啊分享，来跟各位做一个介绍。
好，先说它的三个能力哈。首先在链路追踪方面，它可以给用户一个宏观的视角，从 user session trace 的角度去告诉你，那么这个整个在这个执行过程中这个这个工作是怎么完成的；那么在微观角度呢，当我们发现某一个 trace 会很非常比如说消耗了大量的 token 的时候，我们会下钻到 trace，可以看到每一个 generation 其中的每一个 span，那么这样我们来看一下所有的这个工作是怎么样被执行的、token 是怎么被消耗的。
那第二部分呢在于做质量评估，这个在 Sonar 的也有介绍过。那 Langfuse 里是用大模型来做质量评估的，它提供了大模型和人工标注双轨评分的呃双轨评分的这样的一个机制，可以我们可以识别静静默偏差呀，衡量这个输出的质量。
那第三个也是我非常喜欢的是提示词管理。那么提示词管理呢它是采用了一个 prompt 的注册中心这样一个机制，它把 prompt 这个提示词与代码去分离了，能够独立地版本管理，这样在企业的生产实践中呢，每一次代码更新都是加快了这样的流程，提高了工作效率，是吧？
好，先从看见故事全貌哈，还回到刚才我们在文前讲的这个一个机器巡检的案例。这是从一个 user 是 James 发起的这样的一个巡检案例，他巡检工作他有了三这个这个 session 分有三个 trace 来完成这个工作。那随着这当然了 token 消耗大家也都看到了，它的 token 消耗也都是在逐步的滚雪球逐渐滚起来了。那么我们看到随着它三次的这个呃只随着三次的这个 token 消耗哈，那用户的意图呢它逐渐清晰了，我们 Agent 的执行质量也都在提升。
那当我们如果看到说第三步它是一步步安全审计一共进行了七步，那我们想看这个七步到底是敏么完成的时候，还可以从一个微观视角从 trace 层面进到 trace 3 的界面，我们可以看到他在 trace 3 Langfuse 提供了他调用了多少个 generation。他发生的比方说他有一个 generation 他会执行确认值日，他会这个拆解这个工作哈，然后他还有的 span 他会告诉我们他在执行身份确认，这样呃 generation 1、2、3 直到 11 步他完成了所有的工作。那在每一步的 span 都都清晰的呃列在这个界面上，那作为用户我们可以看到每一个 span 它花了多长时间、花了多少 token。所以这个就是整个的过程非常呃可以追溯，使每一个这个呃使用户可以看到这个整个 token 消耗的全貌。
好，嗯这就是这样的一个界面吧，Langfuse 这一个界面。那可以看到右上角这边是我们用自然语言跟他说好，那我要这个我要再补充一些嗯内容跟这个呃跟 Langfuse 进行一些交互。那左边我们可以看到这个 trace 是怎么样这个，它是按时间轴左上边是按时间轴列出了那这个 Agent 是如何工作的，在什么时间调用了什么工具、花了多少 token、产生了多少费用。那么左下角也是我们用户很喜欢的是一个流图哈，它会把这个 Agent 的这个工作流呃非常清晰地展现在这里，那么你可以看到它对 skill 的调用，它对 span 调用，包括它的这个工作流是串行还是并行，那么对于我们未来 Agent 迭代提升效率的时候会有一个比较直观的依据。
好，第二个我们再来讲一下 trace 的质量评估。那在传统的 trace 质量评估呢，在 APM 里面基本上客户就是通过状态码啦、延迟啊，比如说关键词搜索是 fatal 是不是有没有 fatal 还有 error 这些来判断究竟这个嗯这个这个系统是否运行得平稳。但是它只是衡量一个输入和一个输出和一个延迟，但是 Agent 时代我们除了知道这些，还要知道这个 Agent 做得对不对、Agent 做得好不好。所以对这样一个特别多维需求的评估来讲呢，那我们这个这个 Langfuse 它提供了这个几十种内置的评估器来协助用户来判断执行的是否完整、推理的是否正确啊，包括工具调用质量等。那么大家可以看到哈有几十种评估器，如果这个评估器还不能满足企业的实践生产需要的话，那么用户是可以通过自然语言来来这个定制、来客制化，通过提示词来客制化你自己的评估器来进行这个切合企业实际的一个评估。
好，嗯讲一下 ClickHouse 的这个 Langfuse 的这个评估呢它是双轨评估哈：第一个它是调动大语言模型，通过大语言模型呢它阅读完整的 trace，按照预置的呃评估器它它可以按它可以进行多维度的打分；那如果企业有自己一套成熟而复杂的、具有企业特色的一些人工的一些打分呃一些打分手段呢，那企业可以就是说把自己成熟的软件或者 script 写到 workflow 里，再用 SDK 调取这些 workflow 来对这个 trace 的输入输出进行一些评价，来评价它的质量。所以说通过大模型和人工标注相结合的方式，那么满足企业的生产实践哈。
那举一个小例子，呃这个这个比如说同样是 HTTP 200 这样一个评价吧，那作为传统的这个 APM 是无法评价它的完整性的。那我们如果我们如我们这个例子是设置了一个完整完整性的这样一个评估器，那么对 trace 分段的 trace 1、trace 2、trace 3 进行打分。大家可以看到它给 trace 2 打的分特别低，因为在这个呃大模型呢发现了它会它会有一些漏洞，所以呃给的提的是建议不完整，0.2 分。那这样的话我们就可以根据这个打分去进行不断地迭代了。那第三步刚才我们说了啊，七步 11 个 generation 我们去这个巡检的这步它做得非常好，所以给出了 0.95 分的评呃一个评估分数哈。
好，那我们就刚才讲到评估器，这就是一个评估器的界面哈。大家可以看到右边右边呢是我们用这个我们用脚本生成的这样一个评估器。那比如说我们输入输出，这是我们可以用用户可以自己去配置的哈。他可以比如说他想评评估它的完整度，它分四个维度，你要把评估的这个维度呃输出告诉大模型，然后把评分的标准告诉它，这样的话呢把它存储在这个评估器里。看左边的 completeness 就是完整性的这样一个评估啊，这就是你生成了一个客呃自己定制的一个评估器。那同时系统里有几十个评估器哈，比如说 toxicity 我们叫有毒性、是否有毒，它也是一个评估器。
好，呃那我们看一下哈，刚才我们设置了一个叫做完整性的评估器，那带到 trace 3 里，大家可以看到它对这个 trace 的这个经过经过大模型的这个评估，那会发现给它一个 0.95 分的评分哈。那么它还会自带一个 comment，这个 comment 是根据呃我们给的标准、我们给的这个呃我们给的评价的评价的角度，它会总结一个简单的为什么它给了 0.95 分。那再举一个例子，内置的有一个 toxicity 就是毒性的这样的一个嗯毒性就是是否调用了嗯有这个是否调用了不该调用的敏感性资料，这种叫做毒性哈。那它会分 0 和 1，可见我们 run 了这样的一个系统内置的评估器，它给它的是非常安全、没有毒，那它也会给一个小小的这个 comment、一个 general 的总结。所以这个对用户是非常有帮助的一个 feature 啊。
另外呢，这个评估器呢还可以多维地有一个视图呈现，它可以以数字的形式、以这个评估器的这个分数的分布形式这个柱图，嗯或者可以时间维度的这样的一个趋势以及热点图，它都可以呃很方便的用户来使用。
好，我们再讲一个提示词管理，这个是 Langfuse 非常有特色的地方。我们看一下传统的方式的提示词，一般业务会发现：哎，提示词需要修改，那么他自己无法手动，一般都上报给研发，研发等排期。呃那这个等到他研发把走代码这个修改了代码发布了之后，经过这一套完整的流程上线了，开始让业务部门去测试，如果不合如果效果不好又返回。那么这一整套的这个工作呢，基本上是以天或者以周计的这样的一个流程。
但是在 ClickHouse 在在 Langfuse 里面呢 Langfuse 里面你会看到，它有一个提示词管理、有个注册中心的功能，它会当业务发现 prompt 有问题的时候，它可以打直接打开 Langfuse 对这个 prompt 进行修改，那么它的版本和代码是完全解耦的，不需要研发的干预。而且呢用户可以在这个 Langfuse 里进行这个提示词的 AB 版本测试，调用过去一周的数据来给它跑一些测试的结果，直到他找到最好的版本，自己就决定一键发布呃热更新上线了。那么可以做到当天改当天看效果，这样的话对于这个企业特别 24 小时服务的一些呃行业岗位不能停服的，这个是非常非常具有这个时效性的。
所以在所以 Langfuse 这个也是因为这个特点，Langfuse 是在全球嗯都是非常受受推崇的一款这个 Agent 的这个 Agent 可观测的平台哈。像研发排期以前要等数天，现在就做到当天改当天看到效果。
好，那我们看一下在 Langfuse 里是通过 playground 这样一个界面大家来修改的。现在在屏幕上大家可以看到哈，是客户正在做 AB test 的。你看左边 system 后面他是用这个在修在修改这个 prompt 哈，他用了两个 prompt 来通过跑测试看出他的结果之后，他选择最优的一个可以去发布上线。我
Speaker 2: 们就我依然为，刚才我们就是讲了 Langfuse 从链路追踪、质量评估和提示词管理这几个方面的优势，来跟大家介绍了一下 Langfuse 这样的一个 Agent 可观测系统目前模样了。那 Langfuse 呢，Langfuse 其实大概是今年三月份被 ClickHouse 收购的。在这之前呢，其实 Langfuse 试了多款数据库，但是我特别是听创始人 Clemens 这次跟我聊，也就是说呢，他们发现只有 ClickHouse 能够承接到他的这个工作需求。这是因为 Agent 可观测呢，它的数据量非常的大，而且它的长上下文引起了很大批量的这些数据，而且都是高基数的数据，这些是有非常大的隐性的数据成本，不仅对数据库的性能，还有它的成本都是有非常大的压力。所以 Langfuse 的底座最确定的就是 ClickHouse 数据库作为它的底座。
好，ClickHouse 数据库呢，是一个开源非常热的产品，从大概零九年就传到了中国，大家都用了很多年。那么 ClickHouse 维持了一个打榜叫 ClickBench，基本上是他邀请大概一百多个世界各地的数据库厂商，来针对一些特定的场景用特定的程序来做一些打榜。那我们可以看到，在这个宽表场景下，在数据载入方面，它可以领先我们业内的同行到三十七倍；那在 query 速度上，它可以领先到二十倍。那最近随着 Agent 更多地使用了 JSON，很多分析类型都是 JSON-typed，所以我们也维护了一个新的 JSON Bench。那在 JSON Bench 上呢，ClickHouse 的这个数据查询返回可以做到秒级甚至是毫秒级。
好，再讲一个 ClickHouse 的存储成本是非常低的。那我们其实是做了两个对比。最左边我们以传统的行存数据库作为一个标杆，那么在行存的数据库基础上，从技术角度我们把数据库改为列存，节省了空间；同时呢，又把以前传统的倒排索引改为稀疏索引。这样通过不断的技术优化，我们把数据库的成本降到了百分之五十；那又通过使用字典和采用新的一些压缩形式，使这个数据库的成本降低到了原来的百分之十；那最后的这百分之五呢，是说 ClickHouse Cloud 在发布了以后，它是一个 serverless 的这样一个 ClickHouse Cloud，它后端采用的是 OSS 的对象存储，那通过这样一个存算分离的形式呢，又把成本降低了百分之五。所以试想一下，如果你企业的数据库成本一个月是一百万，有这样的一个数据库性能很好用，成本只是五万块钱，那么试问有哪个企业的老板能够抵得住这种诱惑呢？所以说如果你是一个真的做 infra 的 IT 人员，如果你跟企业的 manager 提出这样一个降本的技术 proposal 的话，我想也会真正地受到这个团队的重视的。
好，那 Langfuse 它的数据库底座是 ClickHouse，我觉得这是一个现在的流行词叫双向奔赴的过程。不知道大家都用过有没有用过 Langfuse 版本的，不知道是 3 还是 4，大家互动一下，让我们的技术经理看一眼。那在版本 3 的时候呢，Langfuse 它是有两张表，它的 trace 和 observation 是单独存放的，那在进库的时候它需要两表进行合并。大家都明白，在 ClickHouse 数据库里边这是一个比较昂贵微的行为。那随着这个产品的演进，在 Version 4 的 Langfuse 里边，它把这两种数据存到了一张大宽表里面，这样对 ClickHouse 数据库用起来就是非常的丝滑。
最后呢，我要介绍一下 ClickHouse 支持原生 AI Agent 这个特色。因为 ClickHouse 在我们在硅谷现在是比较热的一款数据库，我们支撑着 OpenAI、Anthropic，他们后台数据库都是用的 ClickHouse。原因呢就是说它是一个可以支撑 Agent 的原生接入，它有 MCP 的 server；另外呢，它支持十二种这种 Agent 框架，像 LangChain、像 OpenAI 的 SDK 这些；而且 ClickHouse 有完整的 Agent 集成指南。那最后一个就是我们实际上在云端的服务和我们在阿里云上的服务呢，都可以使用自然语言描述我们的分析，然后跟数据库进行互动，自动生成 SQL 查询，或者是自动生成可视化视图或者摘要。那我来 show 一个例子。
好，大家看一下，这是我们之前做的一个 demo。我看到我有一个数据库叫 open_crawl_1，我可以就直接打入文字，我想让 Agent 帮我查一下我这个数据库下面有什么数据。那好，Claude 做了一番思考，给我展现了这样的一个数据库，我看了看还不错。那我要跟老板汇报，我需要做一个分析表。好，我进一步再跟他说，请你帮我做一个分析的表格 dashboard，要从 cost、agent behavior 和 security 三个方面帮我做一个。那 Agent 思考一段以后，然后就形成了右侧的这样的 dashboard，这个对我的工作是非常有帮助的。这也是 ClickHouse 现在我们所谓的用户全球用户增长很快，有很多 AI 的 workload，比如说像 P 打头的、像一些 D 打头的一些 AI 公司、AI 公司都是我们非常好的客户的一个原因。
好，那接下来呢，我介绍一下客户实践吧。这是一个国内的新能源车企，那我也是这个品牌的一个忠实的用户，我很喜欢。这个项目我们大概是从四月份开始介入的，到五月份就开始陆续逐渐地接入各个 Agent 上线了。到现在呢，在差不多八月份的时候，我们项目就已经完工了，接入了八千多个 Agent，有一万多日活员工每天在跟这些 Agent 进行互动。那我们实现的业务的 value 是什么呢？这个项目是他的 infra 平台部去立项的。过去的话，老板只看到了他们 infra 是花出了大量的钱去买 token，但是有什么样的商业价值看不到。那经过引用了 Langfuse 这套监控平台以后呢，我们可以看到每一个 Agent 的使用，它的质量和投入产出都可以清晰地展现在管理层面前。比如说他们可以对 Agent 进行一些监控，它使用率到底有多少的使用率，然后对 Agent 质量进行评分，把所有 Agent 被调用的也可以用各个维度进行 ROI 的排名。所以很有意思的是，他的低价值的 Agent 会得到及时下线的待遇，然后高价值的 Agent，公司的资源会向他进行倾斜。所以这个对企业是确确实实从这个上面看到了一些产出。
另外还有一个关键，刚才我们前边引用到，Langfuse 是可以提供从宏观、微观两个视角去追踪 Agent。那在成本可分摊上面他就做得很好，他可以把 token 的消耗摊分到部门、摊分到 Agent、摊分到每一个用户。所以在月度可以做部门归因、做项目预算，就都做到有据可依了。另外最好的现象是，过去的 token 都是平台部烧的，平台部是一个 infra cost 的部门；但是经过这一套拆解以后呢，实际上就是把这些消耗归咎到了业务部门，跟真正的业务价值产生了联系。所以这一点我特别喜欢。其实上个月跟客户交流的时候我也很受启发，客户说他们的 Agent 不仅仅是帮助企业提效了，他下一步要用到他的智能座舱中去，也就是作为驾驶员的我可以在这个过程中享受到这个 Agent 跟我进行的互动，所以我也非常高兴能帮到企业提供这样的一个价值。
好，我们在讲第二个案例。这是一个性能车的案例。第二个案例呢，是有一个手机厂商，他有几千个工程师坐席，然后调用 Agent 做 web coding。那我们也是给他上用了这套 Langfuse 监控的整个平台。那上线了之后呢，可以看到每个工程师、每个团队它的人均产出、它的代码的接受率，以及整个团队千名工程师大家可以拉到同一个起跑线上来对比一下到底每一个人的 performance 是什么样的，这个是做到非常清晰。那第二点，我也是非常喜欢的一点，他做了一个提示词工程的优化，他把个人的最佳 prompt 变成了一个组织的资产，反过来作为一个资讯提供给每一个工程师，来帮助他们改进 web coding 的工作质量。大家看一下左下角这个白窗，字比较小，实际上就是说这个是系统自动给某个工程师推送了一下，根据观察他过去一周的写代码的 Agent 的方法，给他推荐了一个最佳实践。譬如说像 context 怎么做减重、怎么做减脂这样子。所以这个系统上线以后呢，给客户带来的 token 成本节约在百分之二十以上，研发的效能提高到百分之三十，这是一个非常经典的降本增效的案例。
好，第三个案例是一个国际头部的交易所。当然大家都知道，后台都是我们华人工程师在维护、在 drive。这个客户目前的规模呢，每秒写入量的 trace 大概是百万级，他的异常 trace 的回溯可以做到分钟级。这是一个全链路的监测，从客户的充币交易一直到客户成功了以后提币，整套都是在用 Langfuse 做监控的。带给企业的业务价值是什么呢？大家都知道，上了 Langfuse 以后，使这个 Agent 的每一次决策都是可以追溯、可以解释、可以审核的。这个对金融行业至关重要，它是满足了金融监管要求，而且使企业避免了天价的罚单，所以这是一个合规方面的非常优秀的案例。那另外呢，这个 Agent 也被用到了他企业的客服当中去。那么投诉处理呢，之前的客服没有量化评估的客服体系，他们处理客户投诉是以天来计算的，以天为单位来计算的；那么有了整套支撑 Agent 的客服之后呢，他们处理客户投诉的时间缩短到秒级，用户的留存和口碑就是大大的提升。如果考虑到这个交易所是全球运行二十四小时不停服，那么给企业带来的业务价值也是相当可观的。
好，这就是我讲的这三个案例。因为今天时间非常有限，我就非常浮光掠影地介绍了一下 Langfuse、ClickHouse。那么有一些资源呢，我这边也在后边列给大家。
首先我们原厂大家有很多技术资料，可以到 ClickHouse 官方的网站上去找。这里边有我们所有的视频案例，有我们的技术 doc，有我们所有最新的产品 feature，包括一些开源的资料，也都在网站上可以找到。
另外第二个呢，关于 Langfuse，目前 Langfuse 是有一个单独的网站的，长这个样子。刚才我说的 Langfuse 的一些特色，包括 Langfuse 上面是有 demo 的，大家如果感兴趣，可以去网站上去下载一个 demo 去试一试。
那第三个我要提一下，就是阿里云。ClickHouse 在海外是自己运行的一个 ClickHouse 云服务，是没有 enterprise 云服务的，基本上都是云端的 service offer 在海外；那在国内呢，我们是和阿里云合作推出了官方的 ClickHouse Cloud 企业版，这个界面是这样子，link 放在左边，大家可以去找。目前呢，阿里云的 ClickHouse 企业版已经上线了 Langfuse hosted 的功能，而且呢是免费的。所以如果你已经是 ClickHouse 企业版的用户，我推荐大家直接去打开这个 function，直接去用这个功能，现在是免费的，将来也是免费的去用这个功能。如果你还不是，你可以到这个网站上去注册一个 ClickHouse，然后去使用一下 hosted Langfuse ClickHouse。
像开源社区一样，我们也是非常注重社区的建设。那我们在中国呢，为了方便中国的 developer，我们有一个 ClickHouse 的中国区官方公众号，它会经常把我们针对中国地区比较适用的一些技术文章、一些案例转载过来，方便中国地区的 developer 来阅读。另外我们在中国区每个 quarter 都有线下 event，接下来我们也做一些线上的 event，这些通知都会在官方公众号上，大家可以去看。另外我们在 B 站呢，也放了我们所有的在中国的这些技术社区分享的一些视频资料，我们也都会放上去。
好，last but not least，我们也介绍一下 AI Engineer。AI Engineer 其实我们公司是非常重视的，我们也是它的全球 partner。从法国我的法国同事、纽约，那这一站是上海站，我们也是非常荣幸受到邀请。那 Langfuse 的创始人之一叫 Clemens Rawert，他们是三个创始人，非常年轻有为，也是很感谢受邀去做一个 keynote speech 在 Day 1 的时候。另外呢，我们公司在 AI Engineer 上也会有展台，那像我刚才介绍的研发工程师佳琪和我的团队都会在那里边。所以如果对产品非常感兴趣，又恰恰去到 AI Engineer 大会的同学们，特别欢迎大家来到我们的 booth，来跟我们的团队进行交流。
那我今天的分享呢就到这里了，非常感谢。如果有业务咨询，有任何事情想问我们，直接发邮件到 china@clickhouse.com。好，那我的介绍就这样，谢谢各位。Back to Gordon。
Speaker 0: 耶，谢谢 Sarah，谢谢赛尔，非常非常精彩！我觉得您前面的这个技术讲解非常详细，后面的案例也是非常精彩。那我个人呢，也是因为我最近其实在面试嘛，然后面试很多 AI 智能体开发相关的岗位，它的 AI 智能体上线之后的可观测性以及评测到底怎么去做，是每一个面试都会被问到的问题。那其实在刚刚分享的过程当中呢，我也有一些问
Speaker 1: 我们这边方便的话可以当面请教您一下。一个其实就是说，其实也是我们这个 Tom 同学在弹幕里面也回答了非常多的问题。就是我们在做 agent evaluation 的过程当中，因为我们很多 trace 它是非常复杂而且是非结构化的数据，就像您刚刚说的 JSON，对吧？它比如说每一个 agent 观测当中它的 tool call 结果、它的 prompt 和 message 都是怎么样的，都是被存在一个比较非标的这么一个数据结构里面的。那么在这个过程当中，我们如何去管理这些非标的数据在底层，我觉得是一个比较重要的问题。我不知道您这边可不可以分享一下像这些数据在 Langfuse 当中是如何被储存起来的呢？
嗯，好的，很感谢这个问题。今天研发经理佳琪他也在线上，这个问题佳琪你来 take 一下。喂，佳琪？哎，可以听见吗佳琪老师？哎，我们还是听不见您。如果您在的话可以在弹幕里面扣个 1。哎，对，听不见您的声音。对不起，我看看这边您是 unmute 的，可能是麦克风什么的没有设置好。对，佳琪，如果您不行的话，我们可以先跳到下一个问题，然后等佳琪老师准备好了我们再……
Speaker 2: 好，好，继续。我看一下这个问题啊。佳琪应该在 rejoin 哈。
Speaker 0: prompt engineering 的，
Speaker 1: 我不知道葛总这边有没有对于这个 prompt engineer 有什么心得可以分享？就是经常性的，我们如何去确保我们 prompt engineering 是往正确的方向去调这个 prompt 的？
下一页，现在呢？加钱？哎，可以……
Speaker 2: 说是 Langfuse 它是怎么去处理多 agent 它不同的格式化规范的日志数据是吧？
Speaker 1: 啊，对，是的，是的。其实是这样的，就是 Langfuse 它自身的那个数据组织结构，它其实相比于 log，它更倾向于的是一种 trace 的结构去组织数据。相当于是你的 agent 的每一个调用，它都是通过一个
Speaker 3: 来去把各个层层去给它完整地组织起来，最后组织成一个类似于 DAG 的图。然后这个图里面，你的各个 step，比如说你的 tool use 或者说你的 scale load，或者说你的那些 memory search，以及包括你的那些 model call，它其实都是可以完整地看成一个 step 的。这样子的话，它其实按照这个组织逻辑，你在各个 agent 那里都是可以完全去适配的。并且说，我们的 Langfuse SDK 其实也是支持你去按照它的建模方式来去组织你的 agent 数据埋点接入，包括一些比较常见的 agent 开发框架，比如说是 LangGraph 这些，它其实都已经预接入了。你在使用的时候，如果直接配置好 Langfuse 相关的一些导入设置，它其实就可以完全把你的 agent 调用链路按照标准的格式接入进来。
然后像刚刚说的那些它吐出的格式不标准，比如说可能部分 model 它是 JSON，部分 model 它可能就是一个纯文本，这些其实都是 OK 的。因为它其实只是 model 里的一个步骤，我们只需要把它的 response 给它存储进来，然后最后我们可以按一个 string 和一个 JSON 来去存储它。并且在它上面你去接一些 full-text search，然后你就可以比较良好地去对它进行检索了。
Speaker 1: 对对对，好的好的，谢谢佳琪，非常非常详细。那我个人也是有一个问题，就是说，我们有了这么一个 DAG 之后，或者有这么这个 trace 的储存之后，我们能够非常清楚地看到单条 trace 它是怎么在运行，单条 model 是怎么在做的。但是我们如果去做宏观上面的一些调控，就是知道我们宏观上 agent 比如一开始同时可能有一百个或者一千个 session 在跑，我们这个 agent 质量怎么样？那我知道 Langfuse 上面刚刚 Sarah 也是介绍了一些 evaluator 对吧，有这些评估器，也是可以定制化的评估器。我就比较好奇，像 Langfuse 有没有提供类似于像预警系统？就是比如我某个评估器它突然有问题了，它会主动地告诉用户说这是一个问题出现了，那我开发工程师就可以上去检查。这样子的系统 Langfuse 是怎么去考虑的呢？
Speaker 3: 呃，有的。其实告警这一块的话，其实还是基于 metric 然后加阈值的方式去告警，只不过就是这个 metric 加阈值的产生，它其实就是通过评估器去产生。所以说它可以更加贴合你 agent 的业务语义，反而不是单纯的一个技术指标。就相当于是你的 evaluator 通过你自己定义的业务上的一个评估规则，然后产出了一个指标以及说一个分数。
当然可能有几种不同的指标，比如说是多分类的，或者说是打分的。有这类指标之后呢，我们其实在对它进行告警的话，其实就是一个比较成熟的工程问题，就相当于是指标然后加聚合窗口，然后再加满足某个阈值，然后我们去对线上进行告警。告警之后，我们相当于也可以看到它触发的告警源的一些 session 和 trace，然后我们也可以针对性把这些去定位问题，以及说我们看看是不是要把线上这些数据加入到我们离线的一个 dataset 里，去帮助我们下一次去做 prompt 或者说进行其他迭代的时候我们去做 A/B test。
Speaker 1: 好的好的，谢谢佳琪。那我们再问最后一个问题，也是 Tom 同学的最后两个问题，我把它融合成：其实我们做 prompt engineering 的时候会发现，它的这个方向怎么去定义？我们如何去定义我们做 prompt 迭代是一个正确的方向？以及因为现在其实 prompt 已经不是最重要的嘛，其实整个 harness 里面的其他工具也是非常重要的。就是说 Langfuse 团队或者 AI House 团队对于这方面有没有什么一些经验可以分享呢？确保我们是在往正确的方向去迭代的。
Speaker 3: 了解。是这样，首先第一个，就是说我们怎么去保证我们迭代正确性，这个其实就涉及到我们刚刚提到的一个点，就相当于是我们的 evaluator，然后加我们构建 dataset，以及说在我们的 dataset 上基于我们的 evaluator 去做 A/B test 的一个能力。这个其实就和我们模型训练的时候我们要怎么去做 align 一样，相当于是我们要怎么去：
首先第一个就是我们在业务上要能够去定义出我们觉得什么样是好的，至少说是在人文上我们有一些经验或者说我们有一些正反例，然后我们能够定义出我们什么是好的。
然后第二个的话，就相当于是我们可以通过这些典型的例子，以及说我们线上跑出来的一些正反例，在 Langfuse 里去构建业务自身的一个 dataset。然后在这个 dataset 的基础上，我们可以在迭代了我们的 agent 以及迭代我们 prompt 的时候，我们可以不断地去对它做 A/B test，然后再确认我们能够观测到基于这些业务对齐之后的离线 dataset 上做 A/B test 后有明显提升，然后再去对它做一个灰度和上线。其实相当于还是把它做成了一个比较标准工程的一个 loop 的循环，就相当于是线上然后离线，然后到 A/B test。
然后第二个就是说 prompt 和 harness 相关。刚刚 Sarah 也介绍了，我们现在已有的功能是一个 prompt 管理。像 agent 它其实包含了非常多的组成，比如说 agent 自身的框架，然后包括了 agent 的 memory 以及说 scale，以及说 prompt 这些非 code 相关的东西。然后这个我们就要分两类来看：
一类是 code 相关。这一类迭代的话，我们肯定还是不在 Langfuse 上进行过多的管理，肯定还是说 agent 的开发团队自身在 code 上去对我们 agent 做了哪些迭代。然后这一块的话，你迭代完之后可以在 Langfuse 上去做一个 test 来判断你迭代后的效果。
然后剩下一块就是非代码侧的，就比如说你的 scale、你的 context system，以及说你的 context manager 这套机制。我们 Langfuse 团队后续有一个规划，就是 context manager，就是希望把在 agent 的过程中我们各种非 code 相关的，但是也能影响 agent 运行效果的各种文本，我们都希望把它管理起来。并且说可以在这些文本上不断地去做多版本，以及说做在线的 A/B test、离线的 A/B test，然后来去确定我们最后用怎样的一个 context 来去配合我们的 agent 上线我们的业务。大概是这样的一个过程，其实就是把它分成 code、非 code 两块，然后我们做非 code 这块的管理。
Speaker 3: 我也做一个补充哈，Gordon。明天在这个 AI 上面，其实联合创始人之一他是做一个分享，今天、明天和未来，那在这个会议上他也会分享一些 roadmap 这方面的事情。那如果各位对这个感兴趣，欢迎来我们的 booth 交流。
Speaker 2: 好的好的，谢谢 Sarah，非常非常感谢！我非常希望我在面试之前就参加这个活动，学到了非常多的东西。对，那我们今天的分享就差不多了，我们评论区还在的小伙伴可以给佳琪和 Sarah 老师扣个 1，表示一下感谢，非常感谢大家参与。
明天呢我们依旧会有……谢谢各位。好，谢谢，谢谢 Sarah。明天呢我们依旧会有三个企业然后来进行精彩的分享，同一时间。然后我们也希望可以在那边见到你们。希望这个活动对大家有帮助。我们今天的直播活动呢，
Speaker 1: 就到此结束了。再次谢谢 Sarah，再次谢谢佳琪。好，谢谢，拜拜，辛苦了 Gordon。Gordon 拜拜，拜拜。