雷峰网(公众号：雷峰网)讯 自 2024 年底 Anthropic 发布 MCP，将 AI 与 API 连接，人造大脑从此便有了“手脚”。从 AutoGPT、Manus 到各类垂直的新Agent产品，短短月余间智能体百花齐放，诸多创业公司走完了从技术突破到产品落地的长路。昨日还是科幻故事中的幻影，今天便已触手可及。
产品与生态碰撞，期望与信心交织，2025年终被冠以“Agent 元年”之称。
2025年6月14日，雷峰网、AI科技评论 GAIR Live 品牌举办了一场主题为“Agent 元年已至，我们会有自己的智能助理吗”的线上圆桌沙龙。
圆桌主持人为明势创投合伙人夏令，并邀请了 AutoAgents.ai 创始人兼 CEO 杨劲松、Pokee.ai 创始人朱哲清、ANP 开源技术社区发起人常高伟、艾语智能创始人张天乐，一起进行了一场深度讨论。
Agent 产品成为创业公司新宠，百花齐放之际，如何真正落地？从不同市场对 Agent 的需求出发，主持人夏令与四位嘉宾探讨了 Agent 的前沿技术、模型效用提升与评估方案，以及 SaaS 生态之下 Agent 产品战略方向。
创业总伴随着创新，四位嘉宾在对谈中还分享了各自从 day one 便开始坚持的非共识。事易时移，其中有些今天仍在经受行业的审视，也有些慢慢变成了共识，Agent 技术的脉络就藏于其中。
Agent 商业化问题成为本次圆桌的关注焦点，几位嘉宾分别提出了独到见解。朱哲清指出，Agent 在很大程度上是让 SaaS 生态更加集成化，在软件工具高度标准化的海外市场，Agent 产品与 SaaS 相辅相成。
“我们畅想的未来，是任何 business 和专业用户的 workflow 都可以被 Pokee.ai 完全取代，最终不管是生成还是执行，都真正做到在没有human in the loop 的情况下，也可以端到端地完成任务。”
AutoAgents.ai 的商业化思路另辟蹊径，“卖铲子”、“定场景”两步走。杨劲松认为，新技术出现的早期总会出现对相应基础设施的需求，当头部企业将技术应用于具体业务，就可以一窥潜在价值更大的场景。循着这一思路，AutoAgents.ai 在寻找那些 Agent 能够提效五至十倍的场景。
“这些场景一定可以做出不一样的东西。”张天乐则表示，Agent 商业化最核心的问题是交付结果，艾语智能追求让客户在传统作业方式和他们的方案之间无缝切换。“甲方需要的是你帮他解决问题，而不是你用 AI 帮他解决问题。”
Agent 协作同为今年热门话题，MCP、A2A 始于海外，先后掀起 Agent 协议热潮。作为 ANP 开源技术社区发起人，常高伟看法冷静：“协议受制于基模能力，没有非常好用的智能体，智能体间的连接需求也就不会特别多。”
虽然落地为时尚早，但探索技术和构建影响力已经可以提上日程。ANP 正与标准化组织和开源社区合作构建 Agent 协议生态，积极在各个开源框架中寻找一席之地。
以下是此次圆桌讨论的精彩分享，AI 科技评论进行了不改原意的编辑整理：
百花齐放之后，Agent 如何落地
夏令：非常高兴这次沙龙有机会与大家一起探讨 Agent 这个当前最热的话题之一。我们今天请到了四位非常重量级的嘉宾，虽然大家同在 Agent 赛道，但是深耕于不同的市场，做着不同的业务。所以相信这样的一次对话，不管是对于听众还是我自己理解整个 Agent 赛道及其后续的发展，都会有非常大的帮助。
请大家先做一个自我介绍吧，作为主持人我先开个头。我是明势创投的合伙人夏令，我们基金成立于 2014 年，是一支专注在科技赛道的早期 VC。在过去的十年里，我们很有幸地成为了国内一批技术驱动的头部公司的早期投资人。比如我们是理想汽车最早的机构投资人，一路陪伴它从成立到上市。在汽车电动化、智能化的趋势中，我们投资了二三十家公司，有四五家都是天使轮，后续包括裕太微、知行科技等企业成功在国内的科创板和港股上市。也是因为对汽车智能化的密切跟进，我们在 21 年就比较早地关注到了 Transformer 和端到端数据驱动这波 AI 变化的新趋势，所以在 21 年底 22 年初的时候，我们就投资了 AI 六小龙之一 MiniMax。
我们是比较早地进入 AI 投资赛道的基金，23 年国内 AI 应用逐步起量之后，我们也积极布局了一批国内的 AI 应用公司。其中有一些大家可能已经比较熟悉了，比如文生图领域的 LiblibAI，秘塔和造梦次元。此外还有今天的嘉宾之一，做法律垂直行业的艾语智能，这些都是我们早期投资的代表性项目。我们明势会非常认真、积极地推动 AI Agent 相关赛道的投资，很高兴今天能够跟各位一起交流。
下面请各位嘉宾逐次来做一下介绍，我们先从杨总这边开始。杨总是 AutoAgents.ai 的创始人和 CEO。
杨劲松：谢谢夏总。直播间的各位听众们好，我是 AutoAgents.ai 创始人杨劲松，我们是一家 23 年 6 月份成立的 Agent Native 公司，三位创始成员都来自阿里巴巴达摩院，之前是通义团队的同事。我们希望解决大语言模型在企业落地应用的挑战，目前定位在企业级 Agent 这样一个应用基础设施赛道。虽然现在有很多开源的 Agent 工具，但我们认为既然大语言模型是用来降低技术门槛的，那我们希望 Agent 构建和使用的门槛也可以更低，而不需要用户再去学习一整套相关技术。
我们目前的用户主要以大型企业为主，比如国家电网、三桶油，或者是一些比较头部的企业。对我们来说，对产品最大的要求是 Agent 要真正做到落地、可用，而非仅仅作为一个玩具。这对 Agent 执行长链条任务时的精准度，以及数据安全、权限控制提出了更高的要求，这也是我们的主业。同时我们基于自己的 Agent 技术，也会和行业头部玩家合作，以合营的方式切入垂直场景，这会是我们接下来落地 Agent 的思路。目前我们通过技术驱动工程造价审计，用 Agent 直接交付审计项目结果，在这个赛道取得了比较好的效果。
夏令：好的。前段时间看了好几篇对朱总的采访，能看出您对于目前要做的事情非常有野心，能不能为我们介绍一下 Pokee.ai？
朱哲清：大家好，我叫 Bill。我们 Pokee.ai 是去年 10 月份刚刚成立的公司，主要目标是希望通过强化学习把 Agent 可以使用的工具拓展到整个互联网的范围，最终不再需要额外训练或者是集成的 overhead。我们目前已经有一个单一 Agent 可以集成上万个不同工具，并且在各种不同的垂直场景里执行任务，未来一个月左右就会开始真正的公测。
Pokee.ai 团队的大多数成员都来自 Meta，我创业之前也在 Meta 负责应用强化学习团队，带了很多 Meta 内部的大型项目，比如 RL 在广告、推荐系统的落地，以及 Meta 的 RL 平台开源项目。我从本科就开始做 RL 的理论和落地，在这个方向已经研究了快十年，我认为这一波 Agent 对 RL 的依赖性会持续提升。未来 Pokee.ai 也会在这个方向上有更深入的继承和发展。
夏令：我去年也跟 Bill 总深入探讨过 RL。现在大家都在讲，AI 进入了下半场，RL 也会变得越来越重要。常总是 ANP 开源社区的负责人，现在做的事情也非常有意思，请您也为听众们介绍一下。
常高伟：好的。大家好，我是 ANP 开源技术社区的发起人。我们并不是一家商业化的公司，而是一个开放、中立、非营利性的技术社区。我们的目标是成为智能体互联网时代的 HTTP，而 ANP 是我们开发的一个智能体通信协议，和 MCP、A2A 比较类似。但是我们做得比较早，大概在去年三四月份就开启了 ANP 项目，比 MCP 早了大概半年时间，比 A2A 早大概一年时间。
我们的愿景是定义智能体的联系方式。我们一直认为，协议是智能体连接最高效的方式，也是 AI 原生的连接方式。ANP 社区现在有 200 左右开发者，大部分来自于国内的大厂，还有一线的 AI 从业者。另外我们社群现在大概有1100多人，在 W3C 成立了一个社区组，这是 W3C 中唯一面向智能体协议的社区组，华为、谷歌、字节、蚂蚁、微软、中国移动，还有北大、上交大、MIT 等好几个大学都是我们社区组的成员。我们最终的目标，是构建一个更加开放的互联网，我们认为只有开放的互联网才是最适合释放 AI 的生产力的。
夏令：好的，谢谢。在 Agent Infra 这一层，智能体与工具之间的通信也是构建 Agent 必不可少的环节，一会可以请常总和我们重点分享一下。最后请艾语智能的创始人、CEO，张天乐总为我们介绍一下艾语的情况。
张天乐：谢谢夏总又投我们，又邀请我们参加这次的活动。首先我们的定位是做法律 Agent，这个场景下中美的情况有很大差异。我们认为法律 Agent 在中国市场的落地，应该更多地聚焦在细分市场以及复杂场景里，直接交付结果。我们现在选择了两个落地的应用场景，一是针对网贷逾期客户提起 AI 立案之后的调解服务，目前这块业务已经与 40 多家金融机构进行了合作。二是知识产权侵权行为的发现和追索。
我自己的 background 是在复旦读计算机，算是已经做了三代 AI。我最早在 MSRA 做图像识别，16 年我们做了神经网络，就开始应用在信贷的风控上，现在又开始做法律 Agent。这一轮 AI 兴起的时候我特别激动，因为我看到了它和前两代 AI 之间的巨大差异，并且 AI 真的走向了智能。另外我们一直在创业，一家公司做到了 Pre IPO，还有两家卖掉了，算是 AI 老兵和持续的创业者。再次感谢夏令总的邀请，很高兴能跟大家做深入的交流。
夏令：感谢四位嘉宾对自己和公司业务情况的介绍。我们可以看到大家聚焦于 Agent 赛道不同的业务和环节，每一家都很有代表性。比如说 Bill 总这边，Pokee.ai 的定位是什么？您对于 toC 的通用 Agent 有什么看法，可能的机会在哪？以及大家最关心的问题，和 Manus 相比我们的特色是什么？这些问题希望可以听到您进一步的分享。
朱哲清：好的。首先我们不是一家单纯 toC 的公司，而且大多数的 use case 都不是 toC。我们目前公开发布的 demo 更侧重于 to professional 的能力，同时有一些 enterprise 客户现在已经开始通过我们背后的 API 和 SDK 和我们做集成了。
我们畅想的未来，是任何 business 和专业用户的 workflow 都可以被 Pokee.ai 的 API call 或者 SDK 的集成完全取代。比如对于企业来说，原来从 market research（市场调研）到 reporting（报告生成），到 slide sheet（PPT 和 Excel）的集成和制作，再到 marketing content（营销内容），甚至于最后发布到各种社交媒体网站上的这一整套工作流，都可以由一个 prompt 加一个 API call 完成。不一定要用前端来完成整个操作，我们的目标是提供一个基础的 Agent 平台，使任何开发者或者 professionals 可以在不需要自己手动集成工具和 promoting 的情况下，就能够完成一个非常复杂的工作流的构建以及执行。最终不管是生成还是执行，都真正做到在没有 human-in-the-loop 的情况下，也可以端到端地完成任务。
相比之下，Manus 的定位更多地偏向一款 consumer facing 的产品。而我们的目标并非完全 toC，而是希望取代互联网上所有冗长的、人的工作流，构建一个完全自动化的互联网世界。
夏令：对于 Manus 这种 toC 的产品来讲，完成任务的过程中其实是 Agent 自己做 plan。而 Pokee.ai 希望能够解决更多个性化的任务，而不仅仅聚焦在某一个场景、某一类客户，所以考虑到场景和客户的差异性，我们选择提供一个平台，支持企业用户构建适合自己的 workflow，然后让 Agent 具备任务规划和完成任务的能力。不知道这种理解是不是正确。
朱哲清：是的。Pokee.ai 和 Manus 有一个很大的区分点，那就是我们所集成的能力应该远超现在市面上的大多数Agent。我们集成的工具几乎包括了海外的所有社交媒体、文档工具和 chat 工具，比如 WhatsApp、Messenger、Slack 等等，所以我们所能够执行的场景是非常多的，而且这些执行场景就是目前企业和商业用户最需要的工作流中的瓶颈。比如说你是一个个人用户或者商业用户，即使你有了 ChatGPT、Manus 和各种各样的生成式 Agent，在你完成所有生成任务后，把内容 deploy 到相应平台上这个环节还是需要人来做。这是目前几乎所有 Agent 闭环当中缺失的一部分，而我们可以替人做到这一点。
夏令：明白。我们知道北美有非常多的创业公司会选择特定的垂直场景耕耘，比如 SDR 是销售的一个小环节，都有非常多的 AI 创业公司在深入，提供相应的 AI 产品。现在和过去的区别，不过是从 SaaS 变成了 toB 的 Agent。您觉得 Pokee.ai 做的事情和这些产品之间是什么样的关系？
朱哲清：首先是 SDR（销售开发代表）场景下，比如 Artisan、ElevenX 或者 Hyperbound 这些公司，它们非常聚焦于一个垂类，而且几乎不需要任何的工具集成。它们只需要能发 Email，有 video chat 这种功能就可以了，有些甚至不能读取Email。大多数这类 Agent 公司还没有完全用 MCP 来 build up，很多时候都是手动完成 integration 以后，再用LLM 处理，去看这个进来的 text 是什么样的 intention，然后去找对应的 function，手动 construct function call，然后再去 call 那个 function。不需要 authentication（认证）的集成还好一点，如果你需要 authentication 集成，比如 Google Workspace、Microsoft ecosystem，这些东西对于所有企业来说都是特别头疼的事情。
我们的不同就在于，任何 Developer 或者 Business 都可以把那层最复杂的 integration 和工具调用全部 shield 掉，不再需要操心这一部分。你只需要知道自己想干什么，把这个 prompt 输进来，Pokee.ai 都可以帮你解决。之前一个时代，是各种 language model 或者 vision model 通过 API prompting 去完成生成，而我们现在希望通过prompt 完成从生成到执行的整个闭环。您刚才提到的 AI marketing 这种垂类 Agent，未来如果要做得更复杂、真正打通端到端的话，他们可以 build on top of us。
我举个例子。AI SDR 现在可以收发邮件、看 calendar，但如果用户想写进 CRM 怎么办？如果要构建一个 database 怎么办？要做 analysis 怎么办？不可能每一家 AiSDR 都手动去构建自己的 database和 analysis system，这些系统都有现有的解决方案，他们只需要 call Pokee.ai，说我已经完成了 inbound，得到了这些信息，你帮我写入 database，做个分析，最后写一个 report 给到某一个 employee。这些东西完全可以通过一个 prompt 来完成，所以从 ecosystem 的角度来说，我们给这些公司提供了一个 unify 的、to usage 的 solution。
夏令：好的。Bill 总这边主要从美国市场的角度来看，构想一个 Agent 产品如何在企业里落地，再逐步走向面向企业的定制化 Agent 平台。不同创业公司的切入视角不一样，所在国家的需求场景也不一样。杨总做的是面向国内市场的 Agent，也是要在不同行业、不同岗位落地。您能不能来讲一讲，同样是做 toB 的 Agent 平台，相较于 Pokee.ai 或者 Glean，咱们的思路是什么样的？从落地的情况来看，中国企业更需要什么样的 Agent 产品或者 Agent 平台？
杨劲松：好嘞。首先澄清一下，我们其实也是面向全球的，也有一批海外客户。我们作为创业者都是技术背景，但从用户视角来看，他们并不关注产品底层到底是 MCP 还是什么，关键还是能解决什么问题。目前 Agent 产品在国内有比较明确的扩散路径，掏钱的以国央企业、大企业为主，小企业更多还是尝鲜，真正投入生产的相对还比较少。我们最开始就选择这个方向切入，原因就是大企业能够投入比较大的资金预算把事情跑通，然后建立自己的竞争力。未来每个企业都会围绕自己的核心生产业务去打造一系列大模型或者 Agent，我们的定位就是企业级 Agent 构建平台。其实产品具体叫什么名字，只是技术上的定位，从企业的角度来说，他们想要的是自身生产价值链上的每一个环节都可以更高效，或者以更低的成本实现。我们的逻辑就是解决这些核心诉求，客户会比较关心我们具体集成哪些工具、什么方案最高效或者成本最低。
我想先讲一下我们和 Glean 这类产品的区别。Glean 最开始是做企业内搜，我们认为内搜确实很重要，但是对于企业更重要的是业务的精准执行，也就是如何基于企业内部已有的上下文，把业务流程完整地执行下来，这是我们比较强调的功能。我们判断未来 Agent 要在企业内部做到相对可用的话，需要先完成端到端的优化，就是从底层的模型到中间层的工具，以及上层的业务和数据，都要实现比较好的整合，最终才会有比较好的效果。
比如刚才说到，我们在和一些行业头部公司做垂直场景。对于底层的模型，我们就会基于特定领域进行微调，让它能够在这个领域里做更好的任务规划和场景应用。然后在工具这一层，每个行业都有一些典型的工具，仅仅把工具和模型进行简单的连接是不够的。这里有很多的挑战要解决，有一些是通过接口，还有一些可能要添加数据，对模型做上下文嵌入式的辅助，让它能够更好地应用工具。朱总那个方案，我们觉得也是一个思路。但是对接企业的时候，如果按照 OpenAI 那套 RFT 的思路，企业每增加一个工具，训练成本都会增加一个量级，所以我认为这对于大部分行业都不会特别适用。
我们现在针对供应链通过上下文嵌入进行工具整合，做到了完全可用，再往上就到了数据和业务场景。对于这个部分，我反倒觉得垂直行业里的价值会更大。因为在工具层面大家会慢慢趋同，你的技术能领先半年可能就已经很不错了，更大的差距源于在供应层面能不能基于客户的业务或者用户使用 Agent 的结果，产生一些可以建立飞轮的数据。因此我们比较关心的是尽量让 Agent 投入生产，然后基于用户使用过程中的反馈，尤其是对于规划层面的反馈数据优化底层模型。这种端到端的优化会和拿脚手架搓出来的东西有非常明显的区别。
我们最终的目标是可以在若干个垂直场景里构建这个领域的最强 Agent，现在我们在特别细分的小场景下已经可以直接交付结果，但是对于天花板更高的垂直场景，这其实需要一个渐进的过程。我们会基于工具和数据不断迭代，逼近这个目标。一旦我们在一个垂直场景里构建了垂类最强 Agent，让它拥有超过人类专家的水平，同时又达到了比较好的规模的话，基本上就可以把这个垂直场景比较大的价值吃掉了。这是我们的思路。
夏令：好的。我们来到天乐总这边。同样是做 toB 的 Agent，天乐总又和前面两家显著不同，我们艾语智能并不是服务于更细分的一个行业或若干场景，而是变成了新型的律所。您能不能也为我们介绍一下，跟海外做法律服务的 Agent 公司相比，特别是大家比较熟悉的 Harvey，艾语智能有什么不同？
张天乐：我觉得在整个行业里，Harvey 是一家特别值得我们学习和了解的公司。他们是 OpenAI 在 22 年投资的，到现在也就两年多时间，但是最新估值可能已经到 50 亿了。Harvey 从 day one 就特别强调用 LLM 而非上一代 AI 技术解决法律问题，而且完成的效果非常好。它早期的切入点就是为律所和律师提供法律服务工具，比如诉状的生成、法律文书的识别等等。我们看过 Harvey 很多视频的 demo，从结果角度来说，生成质量确实非常好。但是客观来讲，我认为生成效果好的根源在于 LLM 技术和法律行业的匹配程度高，在复杂文本场景下 LLM 的生成效果天然地就会更好。所以今天我也会建议大家，选择大于努力，这是我在公司说得最多的一句话。而且大家要尽量快速地看到效果再落地，所以可以多尝试一些法律＋AI 的方向。
去年整个美国市场，法律 AI 的投资总额是 21 亿美金。从单个公司的估值最高，以及投资数量和规模来说，可以证明法律或者复杂文本和 LLM 技术的匹配程度确实非常高。但是中国和美国市场的情况差异非常大。比如美国律师的收入大概是每年 10 万到 15 万美金，而中国律师可能只有两三万美金，付费能力和付费意愿有很大差异。所以我们在落地一个商业模式的时候，一定要客观地考虑到中国的国情。另外两个市场对 AI 的认知和付费能力不一样，那一样的东西是什么？是对法律服务的需求。所以我们选择直接针对律师或者律所的甲方，比如我们现在面向金融机构，交付法律服务的结果。我们认为这样更触及法律服务的本质，而且长期来看模型能力会越来越强，交付结果是有可能实现的，所以选择这样一条切入路径。
我们创业 13 年了，每次创业都会选择一个新的市场，或者传统服务没有服务好的市场切入。这种选择背后的逻辑是，我们认为一个行业更紧迫、更缺乏好的服务的需求，更应该被 AI 解决。所以我们这次切入市场，就选择了一个传统律师服务不了的事情，就是线上的无抵押网络信贷。这些客户的单笔金额都太小了，律师做 50 万、 100 万的案子都觉得麻烦，而我们做的都是一两万的。我们的客户可以完全通过 AI 线上提起立案、跟进流程、制定更长的分期还款计划，然后用机器跟进分期结果。大家总说国内的市场卷，我们觉得避免卷最好的方式，就是去做一件新的事情。快速地切进去，没有人竞争，也就不卷了。另外我们在公司经常讨论一个问题，就是技术平权。AI 的发展速度很快，技术透明度也很高，在这个过程中对我们来说更本质的问题是什么？我觉得应该更关注商业模式本身。用户最本质的需求是一个更好的结果，所以我们在选择切入路径的时候，选择直接交付结果。
站在整个创业的角度来看，首先我非常反对不关注海外。我认为美国的 AI 落地是有先进性的，应该去关注他们在技术上面到底解决了什么样的问题。但是中美的商业环境差异又是极大的，一定要选择适合中国的商业落地方法。大家总说卷，我能给大家最贴心的建议就是创新，做一件不一样的事情，然后去交付结果。
我想分享一个 Harvey CEO 今年 3 月份的访谈。他们是一个非常典型的 by license 或者 by SaaS 的商业模式，但是他们 CEO 在今年 3 月份的访谈中提到，未来他们会开拓更复杂的一些场景，比如并购投资，并且按照效果来 take rate。很多时候我们看到的其它机构的商业模式，大部分是昨天的商业模式。Harvey 是 23 年开始落地的，你 23 年让我去交付结果，我觉得我也做不到，因为 LLM 本身的能力就不够。但是长期来看，随着模型的能力变强，Agent 的能力变强，更重要的还是从商业的角度看客户需要什么，以及选择一个传统方案没有服务好的市场。所以我想说，大家不要做存量市场，要尽量做新增的市场，并且伴随着技术能力的提升，往交付结果的方向调整。我们从 day one 就逼着公司必须交付结果，用这样的方式往前推进。这在中国可能是更好、更适合的落地方式。
夏令：天乐总讲得还是很详细的。艾语这家公司服务的不是律所，它自己就是一个新型律所，所以它交付的是结果。下面这个问题想请常总谈一谈。我觉得从 3 月份开始，MCP 在国内外就非常火，后来 Google 也推出了自己的 A2A。咱们的 ANP 解决的也是智能体之间的交互问题，从切入方向和特点上，大家有什么区别，您能不能简要地说一下。
常高伟：好的。A2A 是今年 4 月初发布的一个协议，因为谷歌的体量和影响力是非常大的，所以它发布之后，把整个行业又在智能体协议上带火了一把。我们和 A2A 其实有很多相似点。首先我们解决的问题是一样的，都是为了解决智能体的协作问题。除此之外，我们和谷歌有一个共同的认知，那就是 MCP 可能并不太适合用于智能体之间的连接和协作。智能体的连接协作，应该是个 P2P 架构，但 MCP 可能是 CS 架构。我们和 A2A 还有一个相同点，就是我们在很多技术上也是相似的。比如在智能体的发现和描述上，我们用的是类似的技术，不过我们做得比谷歌更早。
我们和 A2A 在不同点上也蛮多的，最大的不同点就是出发点不一样。我们希望解决的问题是，智能体在一个不可信的互联网环境中怎么进行协作。而谷歌虽然并没有在官网中明说，但是从技术、生态以及谷歌 CEO 的访谈中都可以看出，A2A 的出发点是解决智能体在企业之间以及企业内部的协作。谷歌 CEO 前段时间有个访谈，他认为智能体最早应该会在企业内部落地。另外从生态来说，谷歌有 50 家公司，这 50 家公司全部是做 B 端业务的。最后我们回到技术本身，A2A 这种交互模式并不太适合在互联网上协作，因为它是一个任务分包的模式。
什么叫任务分包呢？就相当于我把一个大任务分成了若干小任务，然后让远端的智能体来处理。在互联网中，这种模式天然地具有很高的个人隐私泄露风险。比如说我要订个酒店，我必须告诉远端智能体我喜欢什么、不喜欢什么，那我的隐私就通过任务的上下文被泄露了。在这一点上，我们的交互方式和 MCP 有点类似。我们把远端信息拉到本地进行处理和决策，这样就不需要把隐私信息交给其他人。
除此之外，我们和 A2A 还有一个最大的不同点，就是身份。刚才朱总介绍过，一个智能体要连接到谷歌、Meta 是非常非常难的。这涉及到智能体协议非常非常核心的问题，那就是智能体的身份。智能体之间要进行通信，首先要解决的问题就是我是谁和你是谁。我们在研究过程中发现，MCP 和 A2A 并没有完全解决这个问题。比如 A2A ，他们用了一个带外的方案，所谓带外是指用其它途径、协议来解决身份问题。比如我有个身份中心，智能体每次和另外一个智能体交互的时候，就去身份中心拿一个令牌，然后通过 A2A 协议把令牌传过去。这个方案非常有意思，我认为用在在企业内部是非常不错的，但是在互联网当中可能不太适用。因为互联网中没有一个大的身份中心可以解决身份问题，而且用在互联网中，这个方案的成本还是有点高。
可以说身份就是我们在技术上区别于 MCP 和 A2A 最大的地方。MCP 用的其实是一个中心化的身份，而我们用的是 DID 身份，类似于去中心化身份的技术。不过和区块链还不一样，我们使用的是 Web 技术，类似于 Email，一个邮箱可以和互联网中所有的邮箱进行互通。比如说你有 163 的邮箱，那你不需要再去申请 QQ 账号或者 Gmail 账号，就能和 QQ 邮箱或者 Gmail 邮箱互通。这是我们做的最大的创新。张总刚才的话我非常认可，要想不卷就得做创新的东西。
Agent 创业，从非共识出发
夏令：创业是必须要创新的，同时作为创业者，也必须要有自己坚持的非共识。下面一个问题，我想请大家谈谈，如果说我们现在有一个坚持的非共识，那会是什么。我们这次的顺序反过来，请常总先讲。
常高伟：在去年三四月份的时候，我们就坚定了一个非共识，那就是智能体之间要协作，协议肯定是最高效、最原生的方式。智能体最擅长处理的就是直接的、底层的数据，而承载这些数据最好的方式就是协议，这是我们坚持的第一个非共识。这一点目前也在慢慢变成行业的准共识。
另外一个非共识就是智能体互联网。我们认为 Agentic web 就是智能体化的 Web，这是互联网的未来。当未来的互联网中有越来越多的智能体，现在的互联网结构会发生一些非常大的改变。现在有很多互联网平台，比如微信、淘宝、拼多多，未来是否真的有必要存在？如果我有一个个人助手，企业也有一个智能体，那么我的个人助手是否可以通过协议直接连接到企业的智能体，帮我完成预订酒店、点外卖、买衣服这些操作？我认为未来，互联网的连接方式会从以平台为中心的封闭的生态，回归到以协议为中心的开放连接，这是我们现在坚持的另一个非共识。
可以说这是我们现在坚持的一个最大的非共识。现在整个行业中，看到这个非共识的人可能并不是特别多，认可的人也不是特别多。但是前段时间，微软的一场发布会就提到了一个叫 Agentic web 的概念，他们也认为未来的互联网应该是一个开放的互联网。
张天乐：我想谈两个非共识。去年 o1 出来之后我想了很多，我觉得 o1 出来代表着 AI 进入了下一个阶段，当时整个行业觉得 AI 能做的事情已经很多了，创业的机会也变多了。但是我个人觉得，o1 对于人类整体来说是一件受益的事情，但是对于创业公司来说，其实机会减少了，未来有很多场景可能会直接通过大模型或者更通用的 Agent 实现。所以我觉得从 o1 出来之后，大家应该更多地思考一些商业上面的事情，比如什么场景是适合的、要如何切入。我会觉得这个场景是复杂文书和复杂流程，另外一定要选择更难的场景，深入地做，这样才会更有价值。这是在商业上，我们坚持的第一个非共识。
另外我最近找了很多论文的一作，和他们讨论了一个问题。对于 AI，很多时候我们盯着怎么让大模型变得越来越聪明这个问题，特别是 DeepSeek 出现以后，大家通过 RL 让模型的推理能力和逻辑性持续地变强。但是现实世界的任务需要两件事，第一件是聪明，第二件是有经验，这两件事本质上并不一样。聪明更像是从一个高中生变成爱因斯坦，但是有经验，更像是在作业过程中有非常详细的标准，在遇到 corner case 的时候有指导我们应该如何去做的百科全书。
我觉得在技术路径上，未来的趋势是让模型的推理能力变得越来越强，但是我们在实际应用过程中会想，我们真的需要一个爱因斯坦来帮我们完成律师的所有工作吗？其实是不需要的。我们需要的是一个受过非常良好教育的法律专业智能体，它在日常工作过程中会变得越来越有经验，能够总结出如何把工作变得高效的方案，在遇到 corner case 的时候能找到更好的方法。所以我们现在会觉得，还是要找到一些方法让模型变得更有经验，而不是单纯地变得更聪明，并且在有经验这条路径上可以做到自学习和自优化。而且我们认为让模型变得有经验和变聪明是 totally different，变聪明可能是在参数层面上要做很多优化，但是变得有经验，严格意义上来说不应该改变模型本身，而是有一个非常 detail 的百科全书外挂式的经验，然后让模型充分地使用。这是我想说的第二个非共识，就是我认为在 AI 应用落地之后，可能有经验会比更聪明更有价值。
夏令：天乐总这个观点跟 OpenAI 的姚顺雨的观点比较像，就是说我们已经把模型训练得可以在奥赛拿金牌了，但是它却还记不好账。那杨总，接下来想听您谈谈。
杨劲松：我想分享一个我们自己也踩过的坑，也是目前行业里比较非共识的一点。我们最开始追求 Agent 在底层技术和理论上的创新，比如说所谓的多智能体协作。但我们在实践的过程中会发现，对于一项之前由人类完成的工作，比如说写一个软件，按照我们人类的分工把 Agent 也分成产品经理、UI 设计师或者开发者这么几个角色，这种做法在模型能力达到一定水平之后，效果可能并没有那么明显了，反而可能限制 Agent 的发挥。
我们有另外一个思路提升模型的工作效果，就是想办法让模型更多次地动用智力。人在完成一项任务的时候，大脑会工作非常多次，可能我说这一句话大脑会转三四次，做一个工作大脑会运作几百上千次。对于模型，我们现在也通过提高工作密度和不同维度的对抗来提升它的效果，说白了就是让模型从不同角度反复地对同一个工作内容进行加工，来提升输出结果的质量，这样效果反而会比角色分工更好。
由这个思路延伸，这里还有一个效率问题。主流 Agent 系统是串行结构，消耗时间是要乘上去的，同时有些任务的幻觉和错误会被放大。用我们现在的思路，如果有一个共享的 working memory，然后多路地、对抗地去完成任务，最后的质量就会比较好。这算是一个小小的非共识。
朱哲清：其实我去年年底的时候跟很多投资人聊，大家都觉得 Pokee.ai 这个方向根本不能做，但它现在已经慢慢变成了共识，所以非共识这件事很难说。
我想沿着天乐总刚刚说的，从产品逻辑来讲，聪明跟经验从理论上来说就是 generality vs adapt to like a specific field（通用性vs特定性），也就是说只是训练方式的区别。它们可能是完全一模一样的模型，当这个模型的 generalization capability（通用能力） 非常强的情况下，它可能是一个完全通用的模型，当你需要将它 adapt 到法律这个领域，你可能需要顺序 overfit 到只有法律方面的知识，把剩下的知识屏蔽掉。
我觉得大多数的套壳应用，或者说大多数 vertical（垂直领域）的公司，其实都需要走这么一步。通用 Agent 本身的核心训练数据是让它对于语言、数学和逻辑具有基本概念，也就是形成 A 和 B 是不能能够推到 C 这么一个简单的逻辑链，然后通过 autoregressive 加 RL 的方式来帮助它构建这样一个逻辑链。
要把这种逻辑链转化到一些特有的领域里，其实是需要做一些 fine tuning 的，这就是天乐总所说的有经验。但是我觉得单纯让模型本身有经验可能是不够的。因为有大量的法律文献，你不可能指望一个模型把它完全记下来，还保证不出现任何幻觉。国内的法律体系全都是条例，可能会相对好记，但海外的判例法体系会导致 retrieval（检索）能力变得非常非常重要。未来的经验可能在很大程度上来自于 retrieval 能力，而 retrieval 单靠 RAG 可能还解决不了。
RAG 的核心问题在于，我需要通过 similarity metric（相似性度量）这种固定关系，从 retrieval 的 seed 或者 prompt 里找到一个巨大的 groups 里相关的文字或者图片。这个寻找的过程可能不是一个固定的 a 对 b 的关系，而可能是一个非常复杂的，甚至于是推理的关系。我之前给很多投资人举过一个例子。大家都在问，为什么不能直接用 RAG 来解决最简单的推荐系统的问题？假设一个人想去夏威夷旅游，那他需要购买的东西是非常多样化的，他可能需要简单的泳衣、泳裤，也有可能想去登山、想去潜水、想去坐直升机。每一样东西都会跟夏威夷有关，但是你没有办法通过一个单一的 distance metric（距离度量）来找到所有内容。当你只有一个单一的 distance metric 的时候，你找到的东西都是类似的，所以这当中就要有一个推理的过程。我觉得特别是在企业环境和特有领域下，未来的 Agent 要在这个方面花大功夫。也就是它的 retrieval 过程不只是简单地找相似性，而是要带着推理去做 retrieval，这是很难的。
张天乐：之前我也跟夏总讨论过这个问题。我从 day one 就觉得 RAG 这个方式局限性极高，是一个非常过渡的方案。我想分享一下我们觉得什么是经验。首先基于法律这个场景，条款内容其实是很少的一部分，美国的判例还多一些，国内的条款我们的模型已经可以解决得非常好了。但是在作业过程中，我们觉得还有大量业务经验性的信息需要挖掘出来。什么叫业务上的经验？我给您举个例子。比如我们会涉及到开庭，中国的法院是有些有线上开庭设备，有些没有，那我们有一条经验就是，遇到没有线上开庭设备的法院，我们的成本就高，所以我们可能会少接这个法院的案件。还有些案件，法院是上午开会，下午打电话，那我们就会等下午再跟法院联系。
所以你会发现，其实我们在去年做对了一件事情，就是做垂直细分领域应该从 day one 就开始做 evaluation。实际上我们每天要对所有的结果做 evaluation，而且我们现在在 evaluation 这件事情上是 freely 的，更多地交给模型，它们会自己挖掘出来更多的信息。在一个细分的场景里，整个组织在作业过程中提高的就是这些小细节。实际上我们每天产生的经验是极多、极零散的，而且比人类组织的效率高很多。我一天能开多少会，模型能开多少会？模型一天能总结 700 条经验，但是想要让这 700 条经验通过 RL 或者 post train 的方式再训练进模型，我觉得这是不 work 的。
所以我们觉得，可能通过一些更松散的结构，一定要和模型本身的训练解耦合，才能保证每天产生大量的经验。而且这些经验有可能今天 work，明天就不 work，然后所以我们还会快速地删减。我一直在公司内部说，它特别像是用一个聪明的模型翻百科全书，这个匹配过程肯定不是个 RAG，而是一个复杂的、逻辑性的匹配过程，然后再去提炼出来。无非是效率低一点，那效率低一点就搞并发嘛，把压力都给阿里云。我们就是每天晚上跑并发，每天用阿里的夜场 API，一到晚上就开始调模型，把这些东西全部归纳好，白天再去用。我们大概是这个思路。
朱哲清：强化学习有两个目的，第一是目标驱动的模型推理，第二个其实算非共识，就是在 generalization capability 方面，用 RL 做出来的推理模型要比常规的 control base planning（基于控制的规划）方案训练出来的更强。RL 的泛化性其实就是在现有的所有技术之内做一个规划性模型，它能达到的泛化性是最强的。目标驱动的推理和在规划层面上更强的泛化性，这两件事情是现在在大模型上取得成功的核心。那从这两点来说，大模型就不应该去尝试 memorize（记忆）任何东西。用 RL 来达到 memorization 的唯一方式是，只有把这个东西一模一样地搬出来了，才能给它 reward。但这件事情本身就是错的，因为我的目标是在非常繁杂、不同的 input 情况下，能够推理出我想要的结果，而不是一模一样地照搬原来已经有的东西。这种东西应该用 autoregressive 的 Pre-training 来完成。如果在 Pre-training 的情况下已经完成不了了，你再倒逼这个模型尝试 overfit 到能够把原始的经验原封不动输出，它就会损失大量的这个模型本身的能力，这是一件本末倒置的事情。大模型真正应该要做到的事情，是在经验层面上只要给到这个 prompt，它能够把 prompt 所对应的内容给找出来，我们不需要它能够从零开始做这件事情，这是不 make sense 的。
杨劲松：对。我稍微补充一句，其实把经验再训进模型这个问题，现在在实践上有一种解法，我们现在叫所谓的 Agentic RAG，实际上就是有点推理性质的 RAG。它并不是去广泛地做搜索，而是先基于业务逻辑做一些推理，然后把相关的经验拉回来，给模型提升效果。
朱哲清：是的，这是一个非常火的 research topic。但是这个东西用 RL 来做非常麻烦，因为它的整个 action space for state space（状态空间的动作空间）是完全 dynamic。在原来的情况下，你是用一个有限 context window（上下文窗口）的文本作为 context 来做一个 state，然后去做 decision making，这整个过程相对比较 tractable（可控）。如果用一个完全 open space 的corpus（语料库），或者一个巨大的内部 graph，想办法用 RL 来解其实是个非常复杂的问题，所以目前还没有什么特别好的 RL 的 Agentic RAG 解决方案，更多的是拿已经用 RL 训练完的 reasoning model 加一个简单的 chain of thought，一步一步去找哪些部分是相关的，然后进行 reasoning 的过程。
我再补充另外一个 anecdote（趣闻），对天乐总可能会有点帮助。其实美国有好多家做法律的公司，他们有类似的经验，就是某个地方的地检和某些地方的法院，对于某一种案例有什么样的偏好，他们自己有一个几乎像是数据库一样的东西。他们收集好这个数据库以后，在决策要到某个地检和法院去提交这个案子的时候，就可以有选择性。这跟你所得到的经验完全一致，就是说很多经验没办法从一个 offline 的数据库，或者从哪些数据里面拿到，都需要在实际的实践过程当中得到。
张天乐：其实经验的数学表达很简单，我们就两列，一列叫 trigger，一列叫 action，说白了就是遇到什么事该怎么干。我们正在构建一个底层的、非常简洁的经验数据库，最后会发现整个公司下面就是一个超级模型，有一堆 action，叫立案的工具，相当于手和脚，然后还有一个巨大的、非常 detail 的百科全书，告诉模型遇到什么事该怎么办。所以我们会觉得，我们最终的形态可能是一个超级脑子有一堆 action，然后还有一个大百科全书。这个大百科全书其实才是核心，它需要能够持续地优化和挖掘经验。
更好的模型效用，更好的效用评估
夏令：现在大家用 RL 实现更好的 planning，然后做泛化，同时大家也在探讨，实际落地的过程中到底怎么样把经验拿过来，让这个模型真的有效。所以下一个问题也想请教大家，我们现在是怎么评估模型效用的，以及如何让效用真正发挥出来，这块有没有值得分享的经验？我们请 Bill 总先开始。
朱哲清：我们公司在这个地方是有一些 secret sause 的，因为如果完全靠 self-training 和 self-learning，完全没有 self-evaluation 方式的话，这个东西完全 intractable。我可以分享一些比较简单的事情，首先是至少在目前的 function calling 层面上，普通的 LLM 在 evaluation 的能力上已经非常好了，大家可以依赖普通 LLM 对于本身就单一 function calling 的能力进行简单的 violation，这是可以做到的。我举个例子，比如说你要构建一个 Agent workflow，当一个工具被调用以后，你想知道它是不是调用正确，其实是可以让 LLM 自己去看一眼的，这其实就是个非常简单的 semi-automatic check，而且 stability 已经非常高了。
除此之外，我觉得在 evaluation 过程中很重要的一点在于，当你调用工具的时候，并不只是调用本身重要，调用完成以后那个结果也很重要，但这个结果很难 evaluate。我举个例子，比如我要调用工具写一个 Google doc，但那个 Google doc 写完以后只返回给你一个link，你也不知道里面是什么，所以你要去 evaluate 整个端到端的流程，可能包括整个规划是不是正确、是不是调用了正确的工具、是不是调用了正确 API 的 parameters、完成 parameters 的结果是不是正确，这一系列都需要它自己的 evaluation。最后那一步甚至于是最难的，因为当你把这个东西写入以后，就没有办法再修改，调出来看看到底写没写对。你可能需要手动写一些东西才能把它做好，而这一步能做对，是整个 Agent workflow 能端到端地打通的一个关键。不管是走垂直路线还是走通用路线，这个东西都是值得大家注意的。
夏令：非常好。杨总这边也在做非常多的实际落地，也特别想听听您对于模型评估和效用有什么看法。
杨劲松：我们的评估其实更多地面向用户场景，所以实际上不能说它是一个标准化东西，而是偏向 customer specific 的评估方式。我们自己进行评估，主要围绕通用能力，比如 Agent 的准确度。但在客户层面，我们会基于应用场景下客户的项目范围，确定 Agent 的核心任务和主链路，通过所谓客户提供的方式把任务常见的数据进行整理，包括它的输入和准确答案。然后我们会有一个自动化工具来进行评估，类似于你来答题我来查的思路。
不同客户的关注维度也不一样，比如有的是准确度，模型可以不回答，但只要回答就必须是准确的。也有的客户要模型把整个推理过程进行展现，他们自己做判断和确认。所以评估也要根据场景需求做不同的设定，我们的自动化评估工具会针对每一类场景做调整和改动，收集到对应的测试 case。从迭代产品的角度来说，有一些常规的 case 会在每一次迭代以后用于验证。我们根据执行任务的链路长短，对验证问题也做了分层，尝试让它不断提升，达到更可用的状态。如果模型在某一个场景上有了突破，我们就会发布一些新的能力。
张天乐：我对这个事情还挺有感触的。首先我们为什么要评估模型？还是希望模型变得会越来越好，交付的结果越来越好。但是在实践过程中，我想给大家的一个建议是，先想人类法则，再想 AI 法则。这是啥意思呢？我给大家举一个场景，
我们有一个用 AI 在微信里跟借款人沟通分期还款的过程，在这件事情上，话术在提升到一定程度以后对效果的增益就很小了。最后我们的解决方案就是把借款人拉到一个群里，群里好几个角色，有人唱红脸，有人唱白脸。比如有人会说，哥你要不就还钱吧，别因为这个事再把房子给查封了。然后另外一个 Agent 可能就是律师的角色，就说反正我们一直在推流程，你爱还不还。所以我想分享的事情是什么呢？就是尤其在创业这件事情上，大家不要一味地追求 AI，天天做 evaluation 让它在话术上做得有多好，一定要去想想商业模式或者其它维度上，还有没有创新可做。
第二件事情是，其实我们在 day one 的时候就很难采用传统方案，比如先确定一个结果，然后去做 evaluation，再去完成。法律服务不像数学或者 coding 问题一样，是有一个准确结果的。早期我们确实没有找到特别好的方法，但是现在我们会把完整的信息更 freely 地全部交给模型，然后也不做过多的干预，让它根据借款人历史的沟通记录、微信记录、法院信息，自己评估怎么做更好。
在这个过程里我们也找到了很多 Aha Moment。比如说我们内部会区分 good case、bad case，有一种情况是借款人分期 12 期，还了 10 期就不还了，那这到底是一个 good case 还是 bad case？这个问题上模型给出的结果就特别好，它说如果分期的金额很少，还了 10 期，后面 2 期不还了，那借款人可能是恶意的，这就是一个 bad case。但如果每期的金额很大，借款人还了 10 期，那已经挺不容易了，这就应该是一个 good case。所以在这整个流程里，我们会觉得还是要更少地 control，然后把更多、更全面的信息扔给模型，这样可能会有相对好的结果。
夏令：明白。常总做的是智能体之间的通信，本质是为了让智能体之间能够协作起来。从协作成本和效率这个角度来讲，您这边有没有比较好的评估方法，或者您看到了什么问题？
常高伟：我们在评估方面的研究暂时并不多，目前更关心的还是连接和通信的效率。比如两个智能体在协作的时候需要收发数据，那么双方对数据理解的一致性要如何才能更高，以及智能体是否能够直接地、低成本地连接到其它智能体，这些是我们目前更关心的问题。
Agent 商业化前途何在
夏令：Agent 的商业化这个问题，相信也是大家都非常关心的。大家能够感受到，在中国做 toB 的 SaaS 工具，其实是非常有挑战的。优质的客户少，客单价小，市场环境也不是特别友好。所以我想请杨总和天乐总重点分享一下，因为两位都是做 to B的，如何在中国这个 toB 环境下，让 Agent 取得比较好的商业化效果？从商业模式来讲，如何和客户形成比较好的合作关系？从价值层面来讲，如何创造客户愿意付费的价值？我们请杨总先来谈谈。
杨劲松：我首先简单介绍一下我们商业化的成果。我们做到了一年大概千万左右的收入，今年大概会有四五倍的增长，所以我认为 Agent 商业化这件事情还是可以做的，这是基本的背景。具体来讲，大家对 Agent 市场的判断基本上是十倍于云的体量。以前 SaaS 很难做大，可能是因为市场规模就相对较小，但 Agent 的市场规模是比以前更大的。
从具体的商业化思路来讲，不确定我们对大家有没有借鉴意义。我们的想法是在一项新技术出现的早期，有一个市场是所谓的卖铲子。对于 Agent 来说，Agent 基础设施或者构建 Agent 需要的一套工具链，就是铲子的需求，我们在商业化早期主要就是做这块市场。虽然那个时候已经有了很多的开源工具，但是我们差异化的点在于，一家相对严肃的企业如果所有核心应用都通过开源工具去构建，他们可能是不太好接受的。所以我们就面向他们对铲子的需求，通过这个过程，再挖掘可以靠交付结果收费的应用场景。如果你的工具没有被客户用起来，其实这些应用场景是很难自己找到的。
自己拿着铲子找垂直场景、验证可行性，其一是速度比较慢，其二是时间窗口比较短。我们的做法是先卖出去一批铲子，等若干大的企业、行业用起来，就观察到存在部分场景 Agent 已经可以部分地做到端到端，或者在人的辅助下能实现效率五倍到十倍的提升，这些场景是一定可以做出一些不一样的东西的。所以我们的商业化思路就是，第一步卖铲子，铲子进入行业以后会定义出来垂直场景，我们就聚焦在这几个点上用结果计收。
我们现在切入了一个场景，就是通过 Agent 进行审计。这是一个非常细分的市场，最头部审计公司的市场占有率有只有 1%。为什么这么分散？因为这个行业高度依赖人工专家亲自去到现场，做很多的 paperwork。这些专家很值钱，一个审计项目报价大几十万是很常见的，利润率也很高。在这个场景里，Agent 可以创造的价值就是原本需要全部由人完成的 paperwork，我们通过 Agent 完成大部分的中间结果，人只起到验证性，或者最终签字盖章的作用。从提升效率的角度来说，我们算下来相当于节省了 10 倍以上的人力。这种场景是很有可能按照结果计收的。如果提升只有百分之十几或者二十几，那很难按结果计收，但如果有 10 倍的提升，你甚至可以直接进入这个行业，做一个新玩家。铲子是一个基础，我们的思路就是识别这些场景，然后切入。
夏令：明白。我自己经历过之前国内那一波 SaaS 的商业化，所以 23 年下半年的时候我也比较感触，toB 要在中国落地的话，很多用户就是更愿意为结果，而不是为效率工具买单。可能在一段时间内，国内的 toB 服务领域还会是这样。
我们都比较认可，商业化最好的方式是交付结果，让用户为结果买单。这个问题也想和天乐总探讨一下，那就是这个路径会不会变相地成为一种人力外包业务？从您的经验来看，Agent 交付结果和传统的人力外包，在商业上有哪些显著的不同？以及可以规避以前的哪些问题？
张天乐：我觉得我们比较幸运的一点是，我们算是做了三代 AI。最早在微软做图像识别，后来做卷积神经网络的那一套东西。我认为今天的商业模式一定是跟着 AI 的，要和当前的技术强相关。几年前没有大模型的时候，我觉得 AI 还是只有工具属性，中国的 SaaS 生态也不够好。但是今天我们看到 Agent 和 LLM 的能力已经大幅增强了，这种时候就更应该在结果上选择一种自然的商业化方式。
第二点，我们在交付结果的时候是不是像以前的人力外包公司一样，这个问题我想分成两个维度来谈。首先对于甲方，我们尽量让自己看起来和传统方案是一样的，让他们的切换成本最低。尤其是跟金融机构谈合作的时候，我们不怎么强调 AI，这对他们来说不重要，重要的是我们能交付结果。我们会非常关注甲方能不能在传统作业方式和我们的方案之间无缝切换，甲方需要的是你帮他解决问题，而不是你用 AI 帮他解决问题。实实在在地解决问题，这是最核心的。
其次，我们觉得 AI 最好的模式不是 Chatbot。早期 OpenAI 的 Chatbot 完全限制了 AI 的能力，o1 出现之后，我们认为 AI 最强的能力是 planning，所以去年我们就一直在做 planning，这是我们做对了的事情。但做得不对的事情是，我们没把 planning 做透，没有在整个作业过程里把 planning 的能力充分发挥出来。我们目前的基础方案是，有一个 planning 能力非常强的 Agent 进行整个案件和任务流程的规划，把每天的日程、跟各方的沟通内容形成 task。我们内部严格意义上都是 task 交互，机器一直在下达 task，Agent 和人也是拿着 task 工作，这样人和机器就能在一个体系里更好地执行。
我们认为最终的结果应该是 Agent 把人替代掉，但是这个过程的中间状态很重要，因为组织不可能完全没有人，也不可能 day one 就一下子把人全换成机器。我们现在用机器进行规划，然后尽量平滑掉人和机器之间的差异性，就是为了慢慢降低人的占比。但我们也不是要做纯粹的无人化，因为我们在这个过程中发现有很多岗位，其实没办法用 Agent 替代。比如我最开始觉得邮寄文件这项工作好像很容易被替代，但是后来发现这个岗位的工作其实非常麻烦，他不光需要从 call EMS，还需要修打印机、换纸，是挺难替代的。我们公司最应该被替代的就是我。所以我觉得人机混同，然后直接交付结果，这就是最好的组织形态。
Agents 生态如何建立
夏令：下面希望跟大家探讨一下生态问题，这方面主要想请 Bill 总和常总谈谈。首先 Bill 总的重点还是服务海外的企业级客户，相比于中国客户，美国企业的信息化程度和 SaaS 渗透率是相当高的。我们之前看过一些调查，很多美国企业会购买三四十个不同的 SaaS 工具，Agent 进入企业之后也不会把这些 SaaS 全部替换掉，而是成为生态的一部分。所以我们的产品要怎么融入企业生态以及海外的 Agent 生态，Bill 总有没有初步的设想？
朱哲清：我一直有这么一个观点，不知道大家会不会同意，那就是在海外，SaaS 和 Agent 之间是没有冲突的。Agent 在很大程度上是把 SaaS 的生态做得更加集成化，原来企业可能需要对各个 SaaS 单独集成，然后让员工熟悉怎么使用这些工具。未来如果由 Agent 集成所有的 SaaS 工具，这就变成了一个 single prompt 的问题，员工只要知道怎么 prompt，就可以调用所有的 SaaS 工具，这可能是 Agent 在海外生态的优势。
我对国内的生态不是很熟悉，但是据我了解，国内很多时候是外包公司直接进入某个公司 build 一个 solution，然后这家公司直接使用，最后每一家公司都做了自己的集成，但是没有统一的接口。这就导致即使有了 Agent，Agent 还是要从零开始重复构建功能，Agent 在一家公司串联以后，没办法在另一家公司也能串联。海外生态可以保证大多数公司的 SaaS 服务体系都类似，一个 Agent 在 A 公司成立，那它在 B 公司大概率也成立，这是我目前看到的海内外生态的最大区别。
我举个简单的例子，海外几乎所有公司都在用 JIRA 作为 SaaS management tool。如果说到 sales，那几乎所有公司都在用 Salesforce 的 CRM。所有公司 financial 的 bills 都是通过 Bill.com、NetSuite 或者 SAP 来完成。这一系列工具全部都是标准化的，只要你的 Agent 知道怎么调用这些工具，就可以把整个工作流全都串起来。但据我了解，除非可以把所有集成公司全部打通，让大家都用一套接口，否则这件事情在国内很难完成。
张天乐：现在国内的很多技术方案是做一套 RPA，嘚嘚点完，然后交付结果。
夏令：杨总对这块是不是比较有经验？
杨劲松：我们现在可以看到一个变化，那就是各个大厂都在试图建立自己的 MCP 协议联盟，这会倒逼 SaaS 厂商，至少头部 SaaS 厂商开放自己的核心能力。这样不管是哪一家，最后肯定会有一个 Agent 入口来调配这些工具。但是在这个事情发生之前，至少目前国内生态还是非常封闭的，和海外生态会相差几个量级。
朱哲清：是的。我们在海外集成了很多工具，虽然有些工具也挺难集成，需要很多 approve process，但我们还是把它打通了。其实去年年底我们尝试了解过国内生态，但是后来直接放弃了，因为这件事情不太可能由我们完成。
杨劲松：其实我觉得 RPA 思路可能会稍微弱一点，如果纯粹从打通生态的角度来说，现在有一种基于多模态模型的方案可能会更通用，也会更快。其实对于海外生态，我有一点很好奇，就是像 Zapia 这种集成了几千个工具的产品，进去之后主要的优势是什么？
朱哲清：从 MCP 的角度来说，现在市面上有超过 15, 000 个 MCP，其中可用的不到 200 个，大多数都是 complete trash。即便是那两百个我们 evaluate 出来已经可用的 MCP，它们的 input 和 output 也是跟整个 context 完全无法衔接的。也就是说，这些工具是基于以前非 AI native 的 API 做出来的。所以首先，构建一个相对比较 AI native 的工具链就很重要。
第二点是工具调用的问题。Zapia 集成了将近 8, 000 个工具，但是如果仔细去看，会发现它在每一个平台上的集成都很有限，比如说 Facebook page，它只有两三个 function，可以 post 一个 text，可以 fetch 一些 comments。但是真正的 Agent workflow，是当一家公司有 marketing 的需求，它可以横跨整个媒体矩阵发帖，监控所有的comments、likes、转发，然后再基于所有的 comments、likes、转发实时观察、决策哪些值得回复。如果有必要的话，这个 Agent 还应该可以发 Email 给我，让我找真人去回复，或者发一个 coupon 出去。这种级别的 Agent workflow 才是真正的企业级需求，但是目前 Zapier 完全没有办法做到，所以它的集成都非常 high level。
然后第三点是构建方式。它目前的构建方式是 fixed workflows，也就是某个 function 的 output 和下一个 function 的 input 必须是固定的关系。如果你要把整个 workflow 稍微改一改，那就得从头开始构建整个workflow，这也是一个巨大的包袱。我们在做 Pokee.ai 的时候，希望把这些问题都规避掉，做到这一点的前提是整个规划过程得靠模型能力完成。而拿模型能力直接从零开始 plan 一个二十几步的 workflow 是不现实的，所以我们建了一个自己的 foundation model，把 planning 和工具调用过程变成我们自己的模型的任务。当这个最难的部分去掉之后，语言模型唯一的任务就变成了理解用户需求。
夏令：好的。下面一个问题想请教常总，就是智能体之间的通信应该也非常依赖生态。您目前在做开源社区，从构建 Agent 之间的通信和协作的角度来讲，您对打造生态有什么想法和见解？
常高伟：我先回应一下朱总刚才的观点。首先我们也比较认可当前的协议整体可能还处于早期阶段，智能体之间的连接和协作还不是特别强烈的需求。第二我们也非常认可 AI native 的连接，我认为在现有的系统上可能有办法解决，但是会比较困难。未来有没有可能有其它系统，比如企业软件或者我们使用的软件慢慢智能体化之后，出现更多 AI 原生的连接，这个时候可能会有更简单的解决方案。我特别看好这个方向，我们也正在做这样的尝试。
555
回到生态的问题上，我们在通过几个不同的渠道构建生态。第一个渠道是通过标准化组织打造影响力，比如我们现在和 W3C 合作还蛮多的，我们在里面也成了一个智能体协议相关的社区组，有很多国内外的大厂都在里面。我认为现阶段要谈落地的话，可能还比较早期，但是在影响力和技术的探索上，确实已经可以着手去做了。我们能看到其他的标准化组织也在做这样的事情，比如 IETF、思科、IEEE，大家都在考虑智能体协议应该怎么做。
另一个渠道是开源社区。目前我们一方面在自己做开源项目，围绕我们的协议开发一些软件，让这个协议更加好用。同时我们也会和其他开源社区合作，做一些开源框架的设计，观察我们的协议怎么更好地融入他们的开源框架里。未来，我们希望自己的协议能够支持大部分的开源框架。
我们认为目前智能体协议最大的瓶颈，可能在于基模能力的限制，也就是还没有一个非常好用的智能体，所以智能体之间的连接需求也不是特别多。但我认为这个瓶颈迟早是能够突破的，所以我们更关心的是和标准化组织以及开源社区的沟通和合作。在国内以及国外，我们都在推进这方面的事情。
长上下文与动态记忆，Agent 走向未来
夏令：不同业务场景对 Agent 技术的突破也有不一样的期待。下一个问题，想请大家分享一下最期待的 Agent 技术突破分别是什么。我们从常总开始。
常高伟：我们用最先进的模型测试协议调用能力，发现它们对协议的理解能力已经非常强了，调用的准确度也非常高，在 95％ 以上。对我们来说，目前最大的问题就是耗时太长，成本也比较高。
访问速度问题比如用 ANP 协议定酒店，我告诉 Agent 我想找西湖周边的酒店，它会帮我找二十几家，并且查看未来一个月的时间里这家酒店的房源，找到之后再预定下单。这一整套操作下来需要 5~6 分钟，时间还是非常长的，所以我们现在比较关心的就是智能体的反应速度什么时候能提高。另外还有成本，我认为这个问题和协议非常相关。因为不管使用哪种协议，对上下文的消耗都是非常非常大的。如果成本降不下来，就会成为阻碍协议落地的关键点。
夏令：好的。天乐总最期待哪块技术的突破？
张天乐：首先我认为，未来我们公司的状态是一个很聪明的 Agent 去调度一堆 action 的工具，目前 action 对于我们是一个工程问题，只要花时间就能解决得相对好，但是在经验上，我刚才也提到从 day one 开始我就觉得 RAG 机制不本质。我最近在看 memory 相关的论文，想找到做信息 retrieval 更有效的方式。我觉得 memory 有一个很重要的逻辑在于遗忘，人是会忘掉一些东西的，模型应该有一本百科全书，但百科全书里面也有一些 rubbish。我们希望构建一层 memory，把匹配的效率、retrieval 效率和正确率大幅提升，并且实现自动地记忆和遗忘，甚至还要修正。
夏令：明白。杨总您最关心的是什么？
杨劲松：有两块。首先是张总刚刚提到的 memory，我也觉得其实目前行业里并没有做得特别好的相关实践。第二块是上下文。目前的 Agent 对于大部分复杂任务，可能工作一段时间之后上下文就断掉了，需要通过一些工程化手段来恢复断点，然后再继续，这种模式限制了很多 Agent 完成复杂、长链路、高价值任务的可能性。动态记忆可能是这个问题的解法之一，这两项技术具有相关性。
夏令：这里我想插一句。对于 OpenAI 和 DeepSeek 来说，它们都是 128K 的上下文长度。从目前来看，大概什么数值的 long context 对您来说可能是够用的？
杨劲松：首先这 128K 其实大部分都是输入的 context，输出的长度会小很多。我们觉得首先最好能先到百万级别，但肯定是越长越好。我觉得更重要的是能不能出现一种新的机制，让上下文不再是一个瓶颈，而是可以从模型侧不断拓展。我看到有些项目在底层做 memory 的基础设施，这可能是一种方法。但是我们看现在的 Coding Agent，Sonnet 因为上下文更长，任务质量就会好很多，用动态记忆的话，其实上下文在中间就断掉了，那任务质量一下就降低了。
夏令：是的。这还不是单纯的上下文长度问题，背后还涉及到成本。另外上下文长了之后，海底捞针，我们还要考虑命中率的问题。
杨劲松：是的。
夏令：朱总最近在硅谷，您比较关注和期待的技术前沿是哪一块？
朱哲清：其实现在有很多东西都在并行发展，其中很多可能和我们今天聊的没有太大关系，但既然大家都讲到了 memory 跟 context，那我再补充一点。在别的访谈中，我提到过自己一个叫 large concept model（大型概念模型）的 line of research（研究方向），意思就是在生成的时候，并不是以 token by token generation 的方式，而是以 concept embedding（概念嵌入）的方式去做 autoregressive generation。然后会有一个 decoder，把 concept embedding decode 成一段或者一句话，这样就可以把整个 retrieval 以及生成的过程，当然还有上下文长度给极致地压缩。这是因为对语义理解来说，我们并不需要每个 token 或者每一个词都展示出来，才能知道语义是什么，很多时候模糊的语义就足以用来完成所有的 inference 以及问答了。
另外从生成速度以及成本来说，diffusion model text（扩散模型文本生成）可能是一个值得大家关注的方向，原因在于它的生成不再是以一个完全 token level autoregressive 的方式，而是在整个 text 的整个 output corpus level（语料库级输出）进行 autoregressive generation。这样一来，它生成所需的 information 就更少，compression（压缩）更多，整体的效率也会提高。我觉得如果这两条线未来能有比较大的突破，那生成的 context 以及 speed 都会有比较大的进展。
夏令：下面是今天的最后一个问题。因为大家都在创业，也都很关注这个行业里其它技术和产品的进展，可不可以每人分享一个自己最近的 Aha Moment？我们从 Bill 总这边开始。
朱哲清：这还真问倒我了。我觉得最近出来的产品同质化比较严重，还真没有什么特别的 Aha Moment。
夏令：那技术上有没有一些 paper 让你印象很深刻？
朱哲清：要说最近的 paper 还真有几篇。首先是 RL 相关，特别是跟 RL fine tuning 相关的 paper。最近有一篇 paper 说 random reward function（随机奖励函数）也可以帮助一个 RL base solution 找到更优的 policy。
其实很多年前就有一篇文章说，当你拿同一个 RL 算法做 30 次实验，至少可以得到 5~6 次实验结果是 state-of-the-art，剩下的实验都是 complete trash，这篇 paper 也有点类似的感觉。RL 算法的稳定度本身就不够，在进入 LLM 时代之前就是这样。现在我们拿了很多我们认为可能已经是做到了最好的 RL 算法放进 LLM，然后大家用各种各样的 hack 尝试得到更好的 LLM 放进 production，但其实这整个背后的理论以及 RL 算法体系的构建都还不是很成熟，这是值得大家关注的一点。
在 LLM 这个生态系统中，RL 未来的发展空间是非常非常大的，而大家对技术的了解又很不够。比如当年 GRPO 出来的时候，大家都觉得它是更好的RL算法，但事实上它是一个从 PPO 退化而来的 RL算法，所以我觉得这当中的 gap 以及可以探索的方向是非常非常多的。
夏令：好的。杨总这边有没有什么可以分享的？
杨劲松：我就讲一个产品上让我比较惊艳的点，它来自一款我们可能已经有点忽视的产品，就是 ChatGPT。它在去年晚些时候上线了一个记忆能力，给了我所谓的 Aha Moment。我之前用 ChatGPT 做了很多对外演讲稿的润色，做这件事情的时候我会把 OKR 给它，所以它基本上对我这个人的画像已经熟悉到了恐怖的程度，比如它知道我是从哪所学校毕业的，目前在做什么方向的创业，以及我们创业的定位和打法。今天我们讨论的几个问题，如果我让它站在我的角度思考，然后给我一个大概的 context，那他输出的 bullet point 会和我自己的想法差别非常小，这是一个我觉得非常可怕的体验。
虽然就产品本身我们没有看到它任何界面上的调整和变化，但是从用户体验和粘性来讲，我肯定不会再去找什么 Claude 或者是 Gemini。我们之间的记忆已经被拆解到它的思考里面了，那它的效果肯定是更好的。如果未来我们的产品，也可以把过往和用户交流中有价值的信息融入服务，产生粘性，那也会是挺可怕的一件事情。
夏令：这个我也有同感。ChatGPT 也准确地知道我是一个投科技的风险投资人，还说什么我人生路演 PPT 的标题应该写“投资未来：从神经网络到孕育新生”，这个彩虹屁真是可以。天乐总最近有没有感受到一些 Aha Moment？
张天乐：我不是恭维啊，Pokee.ai 这个产品对我来说算是一个 Aha Moment。
朱哲清：谢谢谢谢，有点震惊到我了。
张天乐：确实是这样。Manus 出来之后我特别认真地学了好几天，我觉得它确实把我们以前想到的一些事情非常好地工程化了，但是后续我个人觉得没有特别多新意。你们发布 Pokee.ai 的时候谈到了一个问题，就是未来会有很多的 tools 让我们在日常场景调用。我当时想了一下，我们的 tools 现在可能没有那么多，但是长期来看确实会越来越多，那当我们真的到了有大量 tools 的时候，如何能够有效地调用。我觉得用 RL 的方式去解决，这个还挺有意思的。
另外一个 Aha Moment 是在我个人的兴趣方面，就是文生 3D。有一个产品叫 AdamCAD，是一家美国公司做的。我最早是做图形学的，那时候我们做高性能计算，我觉得文生 3D 的价值非常大。如果我们有足够多非常好的 3D model，那就可以把整个世界 construct 出来。我觉得它是在结构性地碾压今天很多应用，还挺有意思的。
夏令：好的。常总最近有什么 Aha Moment？
常高伟：我这个不是最近，应该是在一两个月之前。我们在调协议的时候是让模型驱动协议的生成，收到响应之后也不会用代码来处理，而是直接把响应给到模型。在这个调联的过程当中我们发现了一个非常有意思的现象，一直到那天晚上都很激动。就是模型第一次发起请求的时候，对协议的理解有问题，发送给另一端的时候少带了一个城市的字段。另一端发现之后，就直接返回了错误，告诉它你没有带城市，所以这次请求是失败的。我当时在看日志，我本来以为模型到这就会把这次流程结束掉，结果模型没有结束。我们没想到这个模型又把请求修改了一下，修改成功之后又发送过去，然后第二次请求就成功了，这整个流程居然走完了。
夏令：它在自我迭代。
常高伟：是的，自我迭代。虽然我们通过分析也能够明白这件事情，但是真正看到它这样做的时候，感觉是很不一样的。我认为包括我们现在在用的很多软件在内，未来可能都不需要太多代码，完全可以把复杂度内化到模型里，我们给它几个工具，再让它学习怎么收发协议就够了。模型未来有可能可以自己慢慢学习，未来的智能体有可能就是模型加工具能力。比如说内存有没有可能也变成一个可调用的工具，智能体自己就可以学会写内存，非常有可能。这是最近一两个月让我非常兴奋的一点，我认为它对软件形态也会有很大的改变。
朱哲清：内存和硬件调用这件事情，其实微软、高通、英特尔内部都在做。未来硬件的调用会由 Agent 来完成这件事情，可能已经变成了一个共识，在硬件厂商里是一件非常 common 的事情。我认识一些硬件厂商的 VP，他们希望能够尽可能把硬件上的软件极简化，使得整个硬件更可控。
夏令：Agent 确实应该能成为 OS，因为 OS 本身的功能就包括更好地兼容和调用不同的硬件或硬件模块。
朱哲清：对对。
夏令：今天听了大家两个小时的分享，我觉得收获还是非常大的。我们各位嘉宾的观点从 AI 的技术框架到落地应用，以及未发展的趋势，都有相互关联的脉络，很开心能够和大家一起交流。因为时间关系，今天线上听众的提问就只抽取一个问题，我们看到这个提问是留给常总的。这位听众希望进一步了解一下，ANP 或者 A2A 跟 MCP 的区别是什么，它们分别更适合应用于什么样的场景？这块能不能请常总再为我们进行一下补充？
常高伟：好的。我们先回到问题本身。首先我们一直认为，MCP 在设计之初是为了解决模型连接工具和连接资源的问题，假设你在 GitHub 上有一个代码仓库，或者在谷歌上有个文档，这个时候用 MCP 进行连接是最合适的方案。而 A2A 和 ANP 的是用于连接智能体的，假如未来我们每个人都有一个智能助理，那这个时候我要给夏总发消息，我想直接找到夏总，夏总也想直接找到我，那 A2A 或者 ANP 就是更加合适的方式。一个是智能体之间的协议，一个是智能体和工具、资源之间的协议，这是它们最大的差异。
夏令：谢谢常总。今天非常感谢大家的时间，也再次感谢雷峰网和 AI 科技评论主办的这次活动。也希望后续能够在线下有更多时间跟大家交流，共建这样一个属于 AI Agent 的全新的创业时代。谢谢大家。
雷峰网文章
雷峰网原创文章，未经授权禁止转载。详情见转载须知。