跨国深谈← 返回←三位 AI 智能体公司 CEO 圆桌：从 Copilot 到智能体，还要几年？

三位 AI 智能体公司 CEO 圆桌：从 Copilot 到智能体，还要几年？

关联

人物 Corinne Riley · Spiros · Jesse · Varun

公司 Decagon · Windsurf · Resolve

概念 智能体 · Copilot · 多智能体协作 · 护栏 · 红队测试 · MCP · 自建还是购买 · 人在回路

这一集是 Greylock 合伙人 Corinne Riley 主持的一场圆桌，嘉宾是三家把智能体做进产品的公司 CEO:Decagon 的 Jesse 做 AI 客服智能体，Windsurf 的 Varun 做 AI 编程编辑器，Resolve 的 Spiros 做「写代码之外」的软件工程自动化。三个人来自完全不同的行业，却对智能体的现状和边界给出了惊人一致的判断。

为什么是智能体，而不是 Copilot

Spiros 的开场判断最狠：「你需要智能体，因为 copilot 不会替你值班守寻呼」。他做了半辈子可观测性(监控软件系统运行状况的工具)，在 Splunk 负责 可观测性团队时，SRE 团队一度有 90% 的人因为维持系统可靠性的压力太大而离职。所以 Resolve 的目标是：出了故障时智能体自己去查——看几十个仪表盘、跑几百个查询、做多步开放式调查——甚至不打扰人类，只在关键或不可逆的决策时才来问人。

Varun 的数据更能说明智能体的指数级提速：一年前他说 Windsurf 能把开发时间缩短 40%,写 40-50% 的代码；一年后，在公司内部，缩短超过 40%、写了 80-90% 的软件。他还发现了智能体的新特性：过去 Copilot 只帮你快速写样板代码，现在它渗入了代码审查、部署、设计——软件开发生命周期的每个环节都在被逐个优化，「我们只是处于非常早期的阶段」。

自建还是购买：demo 一天，生产十年

三人对「企业该不该自己造智能体」的答案高度一致：看它是不是你的业务核心。Jesse 说客服领域客户试过自建，很快发现要做告警、监控、护栏，还要让非技术的客服团队(客服支持负责人)能自己定制——「为什么要把宝贵的工程资源花在非核心的东西上」。Spiros 补了一刀：在模型的世界里，搭一个 demo 是最简单的事，做一个生产级应用可能是最难的事——他上一家公司用 10 个工程师做出了号称全球最具扩展性的分布式追踪平台，而 Resolve 用 40 多人做智能体，「这是一个难得多的多的多的问题」。

但 Varun 补充了另一个面向：民主化。Windsurf 公司里最大的高级用户是一位负责合作伙伴关系的 VP(非技术岗)，这位领域专家已经用自己造的销售工具取代了购买销售工具——那些原本要花六位数买的、很烂的报价类小工具，现在不需要再买了。所以分界线大概是：底层难题和深度系统买，贴合自己业务的浅层小工具自己造。

定制化的关键：教智能体像教人一样

Jesse 分享了 Decagon 的核心方法论。客服自动化已经迭代了几代：决策树(按 1 选这个、按 2 选那个)→ NLP 聊天机器人 → 现在的 AI 智能体。

老思路的通病是把想让 AI 做的事「近似塞进一个框架里」，结果很快撞上天花板——而且负责决定客服该做什么的人通常不懂技术，每次改动都要找工程师改决策树，迭代极慢。Decagon 的解法是 AOP(Agent Operating Procedures,智能体操作流程)：企业本来就有大量教人做事的自然语言 SOP,那就用同样的方式教智能体——非技术团队用自然语言快速、严谨地搭建逻辑，工程师保留底层代码的控制权。

Varun 那边则坦言还没找到答案：大企业客户有超过一亿行代码的单一代码库、五万个仓库，现在靠按团队写指南来定制，但这就像写 readme——「两个月后就完全过时了，没人想去修」。他想要的是一种 Google 式的体验：系统理解团队的意图。

MCP(一种让模型连接外部数据系统的协议)是方向，但安全是大漏洞——你不可能让随便一个开发者有权访问最关键的数据库。他的估计：「也许就像还差一代模型」。

怎么衡量 ROI,以及人类何时介入

Windsurf 早期砍掉了「接受率」这个指标——太容易被操纵：一个产品只显示行末花括号，接受率就是 100%,但价值为零。他们改用「代码编写百分比」：提交的代码里有多少是 AI 生成的。

有意思的是，企业几乎不做大规模 A/B 生产力测试，因为等三个月测完，产品已经实质性变好，又得重测。Decagon 的指标则天然可衡量：自动处理的工单占比 + 客户满意度，而且客户本来就在衡量这些(人工客服也得衡量)。Jesse 的另一个关键点：智能体不必一开始就完美——一千个使用场景里把最常用的 25 个做好，剩下的升级转人工，已经是巨大价值。

人类何时介入？Spiros 的框架是按可逆性：可逆的操作智能体做，完全不可逆的目前必须人批准——「今天生产环境中的智能体更像自动驾驶汽车，我们也许有证据表明它比人类司机安全得多，但仍不足以完全放开」。Jesse 补充是按复杂度和监管分级：简单的一级任务先交给 AI,受监管领域(如欺诈调查)保留人工流程。

多智能体协作：说得热闹，没人见过

这可能是全场最泼冷水的一段。Varun 直说：「我们尝试过，我不认为我们在多智能体上取得过很多成功」。

他做过自动驾驶——当年也是多个组件、多个模型互相通信，现在整个行业回归了一个巨大的单一模型，他们当年还嘲笑特斯拉「像素到扭矩」的思路，现在所有人都在回归它。Spiros 也一样：「我个人在生产环境中还没见过任何真正智能体对智能体的用例，比如一群智能体的蜂群」。

他的产品内部确实是一组智能体(懂代码的、懂遥测的、懂基础设施的)，但对用户完全不可见——用户面对的是一个做所有事的智能体。跨产品协作更远：连协议都不存在，「甚至语言都没有」——你如何在软件系统里表示「发布」这个词的本体含义？ 而且他不信智能体能不受控地在企业里跑，安全和合规迟早要像 SaaS 一样管起来。

快问快答：今天的天花板

Jesse 的天花板：开放式探索型问题——没有标准答案、但聪明人能推理出来的那种。比如硬件产品文档不全，客户得靠「背面红灯代表这个、绿灯代表那个」来推理，这种三线问题今天还得靠训练了一年多的专业人工客服，他估计至少还要几年。

Varun 的天花板：改一份规格说明、系统自动写越来越多的代码——对简单应用已经成立，复杂应用还差的是对现有应用的理解、对构建原因的理解、对领域知识的理解，「但这感觉不是一个会持续存在的问题」。Spiros 的天花板：真正的推理。智能体擅长横向铺开的大量检索工作，却在人类轻松应对的简单任务上失败，「因为真正的推理能力并不存在」——遇到从未见过的新问题、需要从第一性原理做判断时，人类做得很好，智能体做不到。

观众提问环节，Jesse 还回应了两个行业疑问：受监管行业(医疗、保险)渗透慢纯粹是合规问题、不是技术问题，而且垂直化本身并不带来合规优势;护栏方面，大客户会对他们做红队测试(雇安全公司千方百计让智能体出错)，产品里内置了客户自建单元测试的测试平台，责任上则和普通 SaaS 一样设赔付上限。

本集带走

• 判断自建还是买，就看一条：是不是你业务的核心竞争力。客服、运维这类非核心能力，自建要补的护栏、监控、告警成本远超想象——demo 一天能搭出来，生产级要一支 40 人的多元团队。
• 教智能体像教新员工一样：用自然语言的操作流程(SOP 思路)让非技术业务团队自己定制，别把逻辑硬塞进决策树或 SDK 代码里——那是上一代自动化撞天花板的原因。
• 别用「接受率」衡量编程助手：太容易刷。看提交代码中 AI 生成占比这类不可篡改的指标，再叠一层使用者的直觉。
• 智能体不必完美才能上线：把最高频的 25 个场景做好、其余升级转人工，价值已经成立；人类保留在不可逆操作和关键决策点上。
• 对多智能体蜂群保持冷静：三位一线 CEO 都没在生产中见过真正的 agent-to-agent 用例——连「发布」这类概念都没有跨系统共享的语言，现在更靠谱的路线是把一个模型做聪明、做更多事。
• 受监管行业渗透慢是合规问题不是技术问题：金融会比医疗快，垂直化本身买不到合规捷径，只能等。

你需要智能体，因为一个 copilot 是不会替你值班守寻呼的。
You need agents because a copilot is not going to hold your pager.
—— Spiros · [03:56]

我们的目标实际上是当出了问题时甚至不打扰人类。
Our goal is to actually not even interrupt humans when something goes wrong.
—— Spiros · [04:36]

而现在在我们公司内部，我想说 Windsurf 把我们构建应用的时间减少了超过 40%,而且它写了我们公司内部超过 80% 或 90% 的软件。
And now within our company, I would say Windsurf is reducing the time it takes for us to build apps by over 40%, and it’s writing over 80 or 90% of all software inside our company.
—— Varun · [02:32]

但另一个现实是，你知道，构建一个 demo,在那种智能体世界或者说模型的世界里，是最简单的事情，但构建一个生产级的应用可能是最难的事情。
The other reality, though, is that, you know, building a demo, you know, in kind of the Agenda world or, you know, world of models is the easiest thing, but building a production grade app is probably the hardest thing.
—— Spiros · [09:39]

我认为，总的来说，如果你用同样的框架来构建东西，那某种程度上就是一个败招，我猜，因为你并没有真正利用 LLM 所擅长的东西。
I think, generally, if you’re using the same framework to build stuff, that’s kind of an L, I guess, because you’re not really taking advantage of what LMs are good at.
—— Jesse · [13:07]

你写好了 readme,两个月之后它就完全过时了，而且没人真的想去修它。
You write the readme, and then two months later, it’s just completely wrong, and no one wants to really fix it.
—— Varun · [16:03]

如今生产环境中的智能体更像是自动驾驶汽车，我们也许有证据表明它比人类司机安全得多，但这仍然不足以让它完全放开，对吧？
Agency production today are more like self-driving cars, almost, where we might have proof that it’s a lot safer than a human driver, but still, this is not good enough to let it go, right?
—— Spiros · [24:03]

我不认为我们在很多智能体上取得过很多成功。
I don’t think we’ve had a lot of success with many agents.
—— Varun · [25:15]

我个人还没有见到很多用例，实际上在生产环境中还没有任何真正的智能体对智能体的用例，比如一群智能体的蜂群。
I have personally not seen many use cases, actually any use cases in production yet that are truly agent to agent, like a swarm of agents.
—— Jesse · [26:29]

因为真正的推理能力并不存在。
Because the actual reasoning is not there.
—— Spiros · [30:56]