为什么实验室万能 Agent，到企业业务全线翻车？

一个300人的公司，跑着900多个agent

"模型够不够聪明，只是入场券。信任、算账和商业模式，才决定agent能不能从demo间走进生产机房。"

单次成功率99.9%，听起来稳得不行。

在非凡大赏这场圆桌上，PPIO联合创始人兼CEO姚欣当场算了笔账：一个任务反复执行20次，每次循环都调用一次大模型，失败概率会被放大几十倍，最终失败率可能到2%。

这个2%，在很多严肃工作场景里都是不可接受的。交易、服务、客服，都不能接受。姚欣说，这是最制约今天agent能不能从idea落地的核心原因。

你看，问题一下就变了味。大家平时讨论agent，聊的都是模型聪不聪明、上下文长不长。真到了企业生产线门口，拦路的却是一串枯燥的数字：失败率、成本、账单、计费单位。

这场圆桌的主题是企业级的智能体需要怎样的底座，主持人是PraxisGrowth的黄姝菲，台上四位都是infra从业者：SandBase.AI的David、魔联科技联合创始人潘勇、TiDB负责AI业务的李粒、PPIO联合创始人兼CEO姚欣。

聊完我有一个强烈的感受：agent底座的单点技术，其实早就ready了。真正没ready的，是信任、算账和商业模式这三件不性感的事。

主持人抛了一个很生活化的场景：你的agent在demo里表现完美，接入真实业务系统后，第二天拿昨天的库存数据给客户推了个已下架的产品，第三天忘了上午刚审批的流程，第四天安全团队发现它看了不该看的客户信息，还没留下任何操作记录。

模型非常聪明。问题出在哪？

魔联科技潘勇的回答很直接：出在信任。

demo追求的是可以跑起来。但对企业来说，面临的问题是敢不敢用、出了问题能不能兜底。他说，一个东西无论做得多好，如果没有身份、不可以被审计、不可以被回溯、不可以追责，那无论多漂亮都进不了生产。

市面上已经有很多协议了。MCP解决agent调用工具，A2A解决agent之间通话。潘勇的点评很不客气：这些都在解决连得上，而连得上只是agent通信的及格线，60分。

我们见面联系上了，凭什么相信你、你又凭什么相信我？没有这个，后续发展都是空的。

所以魔联做的AUN协议，核心是给每个agent发一个全网唯一、可验证的分布式身份ID。审计要回答四个问题：我是谁，我能做什么，我做过什么，谁为我负责。

还有个细节我印象很深。潘勇说，他们把agent定位成主体，像人一样，而不是一个端点。你给朋友发微信他没回，你觉得正常；你给agent发任务，它也会自己判断这事能不能做、该不该我做。

David的SandBase.AI做agent runtime。他回答了一个很多人心里的疑问：企业本来就有容器、serverless、云主机，为什么agent还需要一套专门的runtime？

他说不是资源变了，是使用资源的对象变了。原来创建监控、看日志、走流程的是人，未来是agent。人有大脑，会过滤、会走工单；agent也需要一套流程，关键点同样需要审批。

真正有意思的是他对行业史的复盘。从宿主机到K8S那一代，大家都经历过胖容器：把一堆服务和状态塞进容器里，后来才发现不行，开始强调无状态，状态要么持久化，要么存进数据库。

agent时代正在重演这一幕。Anthropic今年4月提出Claude Managed Agents，核心思路就是把沙盒、运行时和session拆开。loop引擎管context和有状态存储，真正执行任务的沙箱最好无状态，跟K8S里的pod一个道理。

TiDB的李粒负责把话题拽回地面：钱。

"我们四位都是做infra的。infra很多时候就在回答一个问题，你的成本和营收、毛利，到底支不支撑你把这个做成生意？"他说，几乎每个客户来聊新项目，第一句都是：这个成本到底要多少，扛不扛得住。

他分享了个实打实的案例。Minds的大部分基建用的是TiDB，对方提的核心诉求是：怎么低成本地每天提供上百万个数据库给agent，而且每个agent的存储完全隔离，token不对就绝对访问不到别人的数据。

百万级、便宜、完全隔离，这三个词放在一起，就是agent时代对数据层的新要求。以前是给人设计数据库，库是稀缺资源；现在agent比人多，库得像一次性筷子一样便宜又卫生。

更狠的是后面这个例子。TiDB自己公司内部，给客户出的人工服务账单就是agent生成的。李粒说，这里面的关键是把agent当人看。

想象一个人出手工账单，他要不要核对？要不要三方数据校验？做财务的，只算收入不做收支平衡肯定不靠谱，借贷一定要对等，才能说这期账出完了。

agent做严肃业务也一样，得多路数据交叉校验。

主持人问了个很刁钻的问题：企业嘴上说最关心安全，实际采购时真正决定掏钱的关键指标到底是什么？

他还顺手给所有做AI的指了条路：出海赚美元。同样是客户，Monica收美元，Kimi收人民币，月费数字差不多，单位换了一下，毛利和现金流完全是两个世界。

全场火力最猛的是姚欣。

主持人问他，agent任务更长时、有状态、有突发，云基础设施最需要重构的是什么？算力、调度、网络、存储、计费，还是可观测性？

他一个都没选。

从CPU到GPU有很大提升，但这些都不是致命的。AI native时代，最致命的变化是商业模式、计费模式要被彻底颠覆。

他先把SaaS的底裤扒了。今年年初行业有个说法叫订阅已死。订阅模式天生是为人设计的，做to C产品要研究人性，人性一是懒惰，二是贪小便宜。订阅的本质是资源超卖：只有10份资源，卖出20份，赌你用不完。电话包月、宽带套餐，全是这个逻辑。

但2026年1月之后，这个模式被捅穿了。

Anthropic之前提供订阅制coding plan，3月份说不给了。为啥？一个人用coding plan不怕，怕的是OpenClaw用coding plan，薅羊毛薅得太厉害。

商业模式变了，倒推计费模式变，倒推售卖模式变，倒推虚拟化和资源复用的方式全要变。姚欣说这真的是前无古人。PPIO官网的Sandbox，计费单位做到一个CPU一秒钟收0.00000001元。

百万分之一块钱一秒钟。你可能会问，这钱怎么收？说实话我也想知道，但方向本身很清楚：当客户变成机器，定价就得精确到机器的时间粒度。

谈到付费，姚欣的判断最狠：客户不会为技术付费，也不会为资源付费，客户永远只为最终结果付费。

他是拿自己22年的行业经验说这话的。当年他做PPTV，亲历了广告计费的四次变迁：最早卖CPT，新浪头版头条一天多少钱；后来视频行业推CPM，一百万次展现多少钱；然后被搜索引擎的CPC干掉，按点击收钱；最后游戏和电商走到CPA，卖出去多少货分多少钱。

从按天，到按展现，到按点击，到按成交。计费的颗粒度一路向结果逼近。

最后的建议环节，姚欣说企业内agent落地，最难的不是技术，是AI native的组织。PPIO自己内部推AI for AI推了一年，300多人，跑着将近900个agent。

跑下来他发现场景分两类。一类叫human in the loop，人在环路里，比如AI coding，最常见的体验就是不停点yes、确认、决策。这类能跑起来，但天花板明显。

另一类叫human on the loop，人在环路上面看着。即使你睡着了，一堆agent还在持续工作、持续服务、持续迭代。

怎么分辨一个团队是真AI native还是装AI native？姚欣给了一个特别硬的指标：看token账单。

on the loop的业务和团队，token消耗是其他团队的两到三个数量级。根本不是1:10的问题，是1:100到1:1000的问题。

所以他的建议很具体：别搞全员大改造，先找到公司里那个能真正自循环跑起来的单点业务，把资源砸进去。抓到一个，就值了。

主持人追问：你当年在企业内部做AI native改造，是怎么发现痛点的？

姚欣的答案把全场逗笑了。"首先第一步要贴近00后，避免各位台上老登的参与。我最开始了解Marscode、PaperClip这些工具，都是通过最年轻、最想偷懒、最没有经验的程序员。去跟他们聊，发现他们在做这事，向他们学习和推广。"

一个22年前做出PPTV、如今管着分布式算力公司的老创业者，判断组织变革的信号灯，是公司里最想偷懒的那批年轻人。想想也合理。

Speakers｜嘉宾

SandBaseAI 创始人&CEO 李样兵David

魔联科技 合伙人 潘勇

PingCAP TiDB APAC AI Business&Product Leader 李粒Lux Li

PPIO联合创始人兼CEO 姚欣

Host ｜主持人

PraxisGrowth 联合创始人 黄姝菲Sophie

黄姝菲：我叫Sophie，来自PraxisGrowth，我们是做了一个AI原生GTM出海的加速器，帮助中国正在做AI出海创业的创业者被世界看见，也帮助海外很多投资者和创业者朋友入海来到中国，我们现在是做这样一个桥梁和枢纽的角色。非常荣幸接下来可以跟4位创始人一起共同探讨今天的主题：企业级的智能体需要怎样的底座。

黄姝菲：我们从David先开始，简单让大家做个自我介绍，方便大家了解你的业务在做什么。

David：大家好，我是David，我们做的产品是SandBase.AI，做AI agent的infra，希望让builder和FDE的工程师团队能快速做agent的交付，这是我们的愿景。

潘勇：大家好，我叫潘勇，是魔联科技的联合创始人。魔联科技是一个agent智能体的基础设施服务提供商，我们发布了一个agent通信协议叫AUN，定义了agent之间的通信。同时我们基于AUN做了一个给agent赋予身份的产品，让它可以跨组织被信任和被调用，这是我们最新的产品，近期就会发布。

李粒：大家好，我叫李粒，来自TiDB，负责TiDB的AI业务和产品。TiDB主要提供与agent和基座模型厂商的数据层和infra层，提供各种各样的state layer、data layer以及数据互通，赋能所有agent厂商。现在也越来越多接触各种小企业，有感兴趣的可以来找我联系。

姚欣：大家好，我叫姚欣，是PPIO联合创始人兼CEO。PPIO核心做两块服务，一个是AI云，也就是今天大家说的token工厂，大量生产token；第二个是智能体云，Agentic Cloud，提供从agent Sandbox到agent应用平台等一系列服务。我自己也是连续创业者，22年前做了第一款视频软件叫PPTV网络电视，当时做成了分布式的流媒体分发系统；今天又做了一个分布式的算力系统，整合CPU、GPU变成Sandbox、变成token提供给开发者。

黄姝菲：当agent真正开始读取数据、调用工具、修改系统并执行任务的时候，怎么样让它跑得稳、管得住、追得回、算得清？接下来的环节，请大家快速建立一个共同定义：从demo到production，真正的分水岭是什么？如果只能选择一条生产红线的话——数据一致性、模型可用性和安全、执行到权限审计和任务成功率成本——在企业里你会选择哪一条？为什么？

David：刚才Sophie这个问题问得很好。从idea到production，中间的路我认为还是比较长的。刚才提到稳定性、审计、权限，这些问题都很重要。但我觉得现在更重要的点是怎么把这个东西串起来。这里面有两拨人，一拨是builder，builder的核心诉求是快速赚钱。他有skill、有场景理解，希望把skill快速变成赚钱的API或SaaS，比如做了一个MCP服务，Cursor、OpenClaw这些服务就可以快速集成，这是builder的诉求。对builder来说，安全、审计会重视，但更想的是怎么快速把demo run起来，先跑通流程，找到第一波客户，再进一步把infra做得更好。

对企业来说，安全就比较重要了。企业内部安全审计很重要，但现在更重要的点是企业还没有真正开始把agent部署到生产机房去使用，这一步很多东西并没有ready。大家最早可能用Langchain把SDK run起来，但run起来仅仅是第一步。怎么样让这个服务持续地run、持续地提供生产级服务，这很重要。大家都在探索这条路应该怎么走、有没有最佳实践。看整个agent runtime体系，从Anthropic在2026年4月8号提出Claude Managed Agents概念，到4月9号OpenAI发布Agents SDK，包括后面的Cloudflare在跟进这些协议和实现。但实际上到现在，我认为没有一个相对好的实践或流程，大家都在逐步探索，但应该很快会有一个相对统一的意见，把从demo到上生产有哪些环境问题、怎么解、怎么开始讲清楚。

对企业来说，除了安全审计，最重要的还是怎么去开始。有了想法，总不能把OpenClaw一个类似没怎么安全管控的直接部署到生产，风险比较高。我们需要有一个能让企业部署到生产端的、类似最佳实践或初步达成共识的标准协议，让大家能去实践、快速run起来。然后再解决里面的安全、审计问题。

潘勇：在我看来，demo追求的是可以跑起来、能够实现，这只是第一步。对企业来说，面临的问题是敢不敢用、出了问题能不能兜底。所以demo和production之间的差异主要来源于信任——敢不敢用。一个东西无论做得多好，如果经不起考究，没有身份、不可以被审计、不可以被复核、不可以被回溯、不可以追责，那无论多漂亮都进不了生产。对企业而言，可控、可信、可追溯非常重要。企业可能不会担心用agent会出错，因为员工也会出错。真正担心的是出错以后，能不能拦得住、查得到、找得到原因，并且可以追溯责任，知道落实到具备人格的主体上面去，这才是促进产品真正往企业生产线里走的逻辑。

如果只能保一条红线，我选权限审计。因为数据一致性、模型可用性、成功率、成本，这些是"把事做对"；而权限审计是"做错了能查、能拦、能问责"。前几条决定 Agent 好不好用，权限审计决定企业敢不敢用。一个不敢交出去的系统，做得再对也进不了生产。这几点归起来，其他几点可以确保事情能做起来，但审计审核这部分可以确保企业敢用起来。

李粒：刚才潘总说得很对，从demo到生产过程中，信任感非常重要，这是一定要解决的。另外还有一件事：agent系统和我们正常的互联网系统一样，最简单的，你的成本和营收、毛利到底支不支撑你把这个做成一个直接业务？我们在座四位都是做infra的，infra很多时候都在回答这个问题——每一个人的agent系统用什么样的infra最合适、用什么样的数据存储方法最合适、怎么存最节省成本并且可靠性最高、怎么使用是为未来的agent设计不要留下坑，这肯定是最核心的事情。

像我们服务的很多客户，探索新项目的时候都会问：这个成本到底要多少、能不能扛得住agent业务？每一个agent推出的时候都要算钱到底够不够，这样才能出来。所以成本是非常重要的事情，我们也在努力给大家提供最便宜的agent infra。

姚欣：我就选个不一样的吧，我选成功率。为什么呢？不要忘了agent和大模型的底层原理，大模型跟原来所有APP开发的不同在于底层是一个概率系统，存在幻觉。今天再先进的大模型都存在一定失败概率，但到了agent这层，会把失败概率无限放大。比如一个任务，如果做loop engineering，当一个任务反复执行，底层模型成功率比如做到99.9%，千分之一失败已经很好了，但20次循环之后失败概率会提升到几十倍以上，最终失败率可能达到2%。这个2%在很多严肃工作场景里都是不可接受的，很多交易、服务、客户服务等等都不能接受。所以我认为这是最制约今天agent能不能从idea落地的核心原因。

黄姝菲：那企业级AI的核心矛盾是什么？是有没有大模型吗？我抛一个场景——你的agent在demo里表现非常完美，既能回答客户问题又能检索知识库，接入真实业务系统以后，第二天根据昨天的库存数据给客户推了一个已经下架的产品，第三天忘了上午刚审批的流程，第四天安全团队发现它看了不该看的客户信息、没留下任何操作。模型非常聪明，但问题到底出在哪里？

李粒：这个问题我们的客户还真遇到过，并不是危言耸听。刚才说的其实由好几个问题组成，我简单说两个角度。

第一个，所有agent运行的时候一定需要一个完全隔离的环境。姚总他们有一个非常好的sandbox，每一个agent独立的运行环境必须完全独立，不只是计算时环境，连存储时环境最好也是独立的，这也是我们在努力做的事。举个例子，大家应该都知道Minds，它大部分基建用的都是我们的数据库，它其中一个诉求是怎么低成本提供上百万个数据库给agent，每天上百万个。这种情况下它给我们提infra问题，核心就是希望每一个agent的关键信息和存储都是完全独立的空间，只要拿token去访问、token不错，访问的内容就绝对不会跟别人混在一起，这非常重要。不管做什么事情，像我们做文件系统、做数据库，都可以提供百万、千万级别独立的、很便宜的存储，专门为agent产品去做。

这是第一层，像读到别人数据的事情在这层可以完全放心。当然如果是LLM把原来一个ID换成另外一个ID，暂时没什么好解法，听听其他老师的高见。

第二层，刚才提到转错账，这个其实不是infra问题。我们自己公司内部业务也有很关键的业务决策——给客户出的手工账单是用agent生成的。客户购买人工服务，人工服务到处统计信息过来，很多客户都要做，这个账单是agent出的，并且agent下发到质量系统。这个过程中要把agent当人一样看待，agent不是万能的，千万不要觉得agent是无敌的东西，丢到工作流里随便跑绝对不能这样。想象如果一个人出手工账单，他要不要核对？要不要三方数据校验？作为财务，只算收账不做收支平衡表肯定不靠谱，支出和收入一定要对等、借贷一定要对等，才能说这期账出完了。agent做账单这种严肃事情也一样，需要多个数据来校验，这是业务要解决的问题，我们自己也在解决。

黄姝菲：第二个视角，从魔联科技潘勇总的视角来看，最近魔联发布了一个新的ACP协议，市场上已经存在MCP、A2A以及不同的agent协作协议。从企业生产环境看，一个agent通用协议除了接得上，还必须解决身份认证、能力发现、授权、安全审计的问题。非常好奇，ACP协议希望弥补的核心空白是什么？

潘勇：是这样子的。现在市面上有很多协议，包括MCP、A2A。MCP解决了agent调用工具的问题，A2A解决agent和agent之间通话的问题，都是在解决连得上这件事。但连得上只是agent通信里最基本的及格线、60分。真正意义上，我们见面联系上了，凭什么相信你、你又凭什么相信我？这特别重要。如果没有这个，后续发展都是空的、没有基础的。

从这个角度，AUN试图解决的问题是给每个agent赋予一个全网唯一的、可验证的、分布式的身份ID，这个ID唯一且可验证。特别类似于一个公司有很多部门，每个部门员工的卡一定都是统一的，只有这样跨部门协作时员工才可能被授权，出现问题才可能找得到。我今天反复强调身份、授权、审计，这是串到这条线的。我们要让agent可以通信，背后目的是希望产生化学反应、更深入的合作，合作前提必须有信任基础。有信任基础就要有一个ID、一个唯一身份，可追溯可验证，一直跟着它走，把整个过程串起来。未来agent生态的相互协同才会变成现实。这是AUN试图解决的核心点——身份问题。

黄姝菲：明白，agent也要身份认同，也需要身份。

潘勇：对，有个点我补充一下。我们把agent看作是主体，不是端点、不是服务。传统服务是我问你你得答，不回答我认为你超时了、你说错了；agent不一样，我们把它定位就像主体、像人一样。你跟你朋友发微信他没回，你觉得不正常吗？不会。agent也是这样，他要有职责节制，你给他发以后他会判断这个事情能不能做、该不该我做，具备自主性。他是网络公民，不是那种你叫他他就干、你不叫他他就不知道思考了。

黄姝菲：下一个问题请问David。包括SandBase.AI一直强调agent native runtime和沙箱，但企业原本已经有容器、serverless和云主机了，为什么agent还需要一套专门的runtime？在长任务状态中保存代码、执行浏览器操作和工具权限、失败重试和日志追踪上，传统云基础设施到底缺了什么？为什么需要这样一个新概念？

David：这个问题很好。现在很多人把agent runtime等于沙盒，比较早期的像北美E2B出现的比较早，很多人接触agent runtime就是从沙盒开始的，包括现在很多人说沙盒就是agent runtime，这个概念定义得有点狭窄。对于runtime来说，除了沙盒，里面有很多东西需要解决。刚才李粒提到审计、权限、安全，这些都是问题。最早大家对这个事情理解比较分散，有了这些东西之后各个单点能力都ready。刚才提到容器主机，单点能力都ready。

agent runtime并不是要取代原来的Docker、取代原来的容器，而是更好地把资源和流程串联起来。agent runtime底层运行的东西，无非是进程隔离、Docker、用户主机，资源还是这些资源，不会变化。包括用户业务流程，原来用监控、用日志追踪，这些也不会变化。变化的点是，最早这些事情是人来用的——创建监控、创建日志、去看这些东西；未来实际上是通过agent来用。人提诉求、提需求，agent来干。agent怎么样更好地用起来基础设施，不是说agent要取代基础设施，而是agent能更好地使用基础设施，交互方式会发生变化。毕竟它不是人，人有大脑，需要过滤、处理事情、走工单、走流程；对agent来说，是不是也需要一套流程，有关键点需要审批？我觉得也是需要的。

怎么样让agent更好地把流程往下走、run起来，这是比较核心的。过程中基础设施这些东西不变，agent去串那些东西。更重要的点是我们需要有一个很好的runtime协议和标准，把各个东西串起来。

为什么我一直提agent runtime？最早大家提agent runtime的时候都是分散的，要么沙盒、要么是链路追踪日志。但Anthropic提出了一个很好的概念——Cloud Managed Agents，核心是把沙盒、运行时和session做分离。为什么要分离？最早用的一些方案像OpenClaw，很多点相对来说是胖容器。最早从宿主机到K8S这一代，大家都经历过胖容器概念，把很多服务、很多状态保存到容器里。到K8S里大家强调无状态，状态要么持久化，要么存到TiDB或数据库里。agent时代也是这样，要把状态和真正的loop引擎分离。loop引擎负责context或一些有状态存储，真正执行的沙箱希望它是没有状态的。这样对齐了原来的基础设施，比如pod没有状态，agent也希望没有状态。状态从最早的一些workspace里剥离出来，可以用到memory、用到存储里。底层沙盒像PPIO比较擅长，调沙盒能力不变。

我觉得把边界拆清楚，大家都有一套对齐的认知，再谈怎么做交付、怎么做企业FDE的交付、怎么让企业更信任地使用。先统一边界、统一认知，最后再谈交付。我做agent runtime首先从开源做起来，因为很多东西是认知问题，大家需要认知到这个东西可控——底层存储用MySQL、用OSS，是他自己的，他就觉得可控。如果提供一套东西让他用，大概率觉得没那么放心，不管说得多好，他认为不安全。最早用户上云一样，agent时代to B企业一定是先自己能可控。你能告诉他说里面用沙盒也好、用主机也好、用日志也好，至少都是自己的东西，负责先把东西跑起来，这是第一步——让企业用户先能用起来。

大家对怎么用agent runtime先有一套共同认知。有了这个认知之后，后面很多事情需要时间去解决，不是说现在提一个东西就能立马交付或实施，中间肯定有一段路要走。过程中我们希望承担布道者角色，告诉大家最佳实践或初步统一的标准是什么，再说怎么样用得更好。但过程中，各个生态原有能力还是原有能力，只是告诉大家可以这样去用、这样串联。

现在SandBase的理念，更多希望做布道、做宣传，大家一起来做生态，谁擅长什么做回什么。我们可能擅长to B、对企业交付的理解。大家各回自己的位置，过程中统一认知、统一对agent runtime的理解。

黄姝菲：下一个问题抛给姚总。从Agent Cloud和传统云有什么不同？从PPTV的大规模流媒体分发，到PPIO分布式云，再到现在Agent Cloud，经历过几代不同计算负载。相比传统web和移动互联网应用，agent任务有更长时、有状态、有突发，而且执行路径不确定。为了支撑这样的工作负载，云基础设施最重要需要重构的是算力、调度、网络、存储、计费，还是更可观测性？

姚欣：首先估计在座各位都是程序员、技术人员，技术上从CPU到GPU有很大提升和改变，但我认为这些都不是致命的。在AI native时代，最致命的变化是商业模式、计费模式要被彻底颠覆。

今年年初大家知道SaaS公司面临一个挑战叫订阅已死。订阅模式天生为人的特性设置，当年做to C产品要研究人性，人性之一是懒惰，人性之二是贪小便宜。订阅模式本质是资源超卖——赌给你分配这么多资源你肯定用不完，云厂商可以额外挣钱。虽然只有10份资源，卖出20份，电话包月套餐、网费套餐全是这样。但这个模式在2026年1月份之后被挑战了。

Anthropic之前提供订阅coding plan，后来3月份说不给了。为啥？一个人用coding plan不怕，怕的是OpenClaw用coding plan，薅羊毛太厉害。

今天观测到，当云的使用用户从人切换到agent之后，发生剧烈变化。以前人开虚机最少按小时租用，今天OpenClaw跑Sandbox怎么跑？大家都知道有半小时启动机制，半小时内沉睡，启动那一下啪啪跑一堆任务，用完最多半分钟、一分钟就结束，随任务执行后再沉睡29分钟再来一把。后台看到的不是波峰波谷，全是非常尖的脉冲型应用。

当云和应用的使用对象从人切换为agent之后，面临使用更加碎片化、高频化、脉冲化以及24小时连续化。人只是白天上班用，agent不管24小时都在用。这些特点最大冲击是对商业模式定义的冲击——以前的云超卖模式、SaaS订阅模式死掉了，必须用新商业模式迭代和创新。这个是我们现在最困扰的。

大家到PPIO官网看Sandbox订阅，订阅单位是可以用一个CPU、一秒钟收0.00000001。当然有个问题，怎么付这百万分之一的钱？实际当然不会只用这么一点，还得充值等等。但整个系列挑战是agent使用时完全改变了。

因为商业模式改变，倒推计费模式改变，倒推售卖模式，倒推技术底层模式、云复用模式、虚拟化方式，全都要改变。这是目前涉及的，真的是前无古人、重新研发。

黄姝菲：明白。刚刚突然涌现一个问题，就着姚总基于商业模式的回答。比如说企业级agent，嘴上说最关心安全，各位在实际交付过程中，发现最后真正决定采购的关键指标到底是什么？更愿意为什么样的agent付费和服务付费？各位跟客户交锋过程中，这个大实话能说吗？

姚欣：先说实话吧，客户不会为技术付费，也不会为资源付费，客户永远只为自己最终的结果付费。我有这个经验，当年经历过商业模式变迁。最早卖广告卖CPT，按新浪头版头条一天卖多少；后来视频行业推CPM，100万次展现卖多少；接下来被搜索引擎CPC干掉，100万个点击收多少钱；最后走到游戏和电商行业CPA，今天卖出去多少商品、分多少钱。

今天所有探讨都是过渡状态，最终会按agent让企业老板最后挣多少钱、付多少钱，按结果效果付费，最后一定走到这一步。

李粒：我回忆一下，非常贴切。去年跟客户聊，他们还在问能不能帮我把事情做好。今年聊，他们会问用这个能省多少人、省多少人力。脑子里一定在算账——省了三个人，工资多少？token消耗多少？一算觉得不划算，还是看看吧。很真实，就是这个样子。

David：对，我们国内外企业都有服务。客户确实为了结果、业务价值付费。同样一个产品，客户用在高业务价值的地方，对价格非常容忍；用在低业务价值的地方，或历史上传统区间收费很低的地方，容忍度就非常低。

这也是TiDB一直大部分做海外的核心原因，也非常鼓励所有做AI的企业走出去看看。对比同样是我们客户，Monica和Kimi的月费，一个收美元、一个收人民币，月费类似只是单位换了一下，就知道里面毛利和利润差多少，以及最终企业现金流运转是什么样子。有机会走出去都要走出去，尽量赚美元，这样更舒服。对infra厂商来说，也更有机会提供更高价值的服务。

潘勇：从 2023 年 GPT 问世至今，企业对 AI 的付费意愿经历了三个明显阶段：

2023 年：无人买单的冷启动期那时 AI 很难赚到钱，除了卖课的，做服务的基本没什么收入。根本原因是 AI 的输出质量不行，老板们看不到价值，自然没有付费意识 ——"结果都不行，凭什么让我买单？"

2025 年：为能力买单的试水期市场开始看到 AI 在某些场景下确实能解决问题，付费意愿从 0 到 1 突破了。企业愿意为比较明确的单点能力买单 ——API 调用、基础服务单元这类可量化的东西。逻辑是 "这个能力 OK，我可以为它付费"。

2026 年至今：为结果买单的爆发期春节后 OpenClaw 火了，真正的转折点来了：大家开始愿意为结果买单。很多企业实实在在看到了降本增效 —— 人力成本大幅下降、人效比显著提升。尤其是传统企业，当他们看到同行通过 AI 把成本打下来、效率拉上去，立刻就坐不住了，主动来聊、愿意买单。

这个变化意义重大。2023、2024 年做这个事的时候，根本没人愿意跟你聊；现在至少老板们愿意听、愿意试了。

黄姝菲：最后想好奇问一问大家：如果给到现场所有参加非凡大赏的观众，包含企业决策者、AI创业者、投资人，一条建议关于怎么让agent真正进入业务闭环，而不是停留在demo阶段，大家会给出什么建议？每个人结合业务情况、实际场景做分享。从David总开始。

David：agent要真的run起来，底层依赖的infra蛮多，需要很多人、很多厂商公司一起共建，不是某一个人能做起来。infra领域还是有比较多机会，希望大家多看看infra的机会，包括在垂类或相对能做一些事情，可能是一个点、也可能是一个API，大家一起把infra生态做大。

潘勇：agent上半场大家在拼能力，下半场会开始拼信任。今天觉得身份、审计、授权好像是加分项，但大概明年或后年，可信、可控、可追溯以及身份这部分会变成准入门槛、必选项。之前没意识到这部分，但从现在开始必须清晰意识到：必须知道agent是谁、能做什么、做过什么、谁为这件事负责，这非常重要。

李粒：恰好echo我刚才说的话，如果大家还在做agent业务，一定要出国去赚美元，海外市场真的很宽阔。如果能赚美元真的去赚美元回来交税。如果有兴趣想出国赚美元，可以联系我，可以送credits、介绍业务，全世界有办公室，甚至可以做商业推广，好几个合作方都这样做。也可以用姚总的Sandbox。

姚欣：我有不同看法。找技术找产品可以找我们在座各位，但企业内agent落地应用，最难的不是技术，反而是AI native的组织。我们自己企业内部也在推进AI for AI，推了差不多一年。从全员AI coding、全员编程，到今天内部上大量agent系统。300多人大概有将近900多个agent在跑。

明显发现分两类场景：一类叫human in the loop，一类叫human on the loop。绝大多数人机共生场景在human in loop情况下能跑起来，比如AI coding，最常见体验就是点yes、确认、决策。但真正跑出高效agent，native组织一定是on the loop的——即使睡着，一堆agent还在持续工作、持续服务、持续迭代。

我们自身提供token服务，能明显发现agent on the loop的业务和团队，token消耗每个月是其他团队的两到三个数量级。根本不是1:10的问题，是1:100到1:1000的问题。每个企业应该首先挖掘什么业务可以跑到真正自循环的loop engineering，在这种项目单点上使劲投入就对了，并不需要全程改造，抓到核心单点更为重要。

黄姝菲：您当时在企业内部做AI native改造的时候，怎么发现那个痛点的？可以给大家分享一下吗？

姚欣：首先第一步要贴近00后，避免各位台上老登的参与。贴近年轻人，我最开始了解内部系统Marscode、PaperClip这些东西，都是通过最年轻、最想偷懒、最没有经验的程序员，去跟他们聊，发现他们在做这事，向他们学习和推广。