夜雨聆风
宇豪 16 岁进入浙大，随后赴 CMU 攻读硕士，之后先后在 Meta 和 SmartNews 的重要产品线工作。他在 23 年开始 AI 创业，24 年和几个联创 bootstrap 做出了一款千万刀 ARR 的产品 Kuse.ai，并在不久前推出了 OpenClaw for Teams 的新产品 Junior.so。
本期播客原文约 25000 字，本文经过删减整理后约 8900 字。
曲凯：很多人应该都刷到过 Kuse 的新闻，重点基本都是一件事：你们没融资，但很快就做到了千万刀 ARR。
宇豪：对，到目前为止我们还是 bootstrap，用的是几个 founders 自己的钱，大概有一两百万美金。
曲凯：自己愿意投这么多就已经很厉害了，何况还能用这些钱做到千万刀 ARR。你们是怎么做到的？
宇豪：核心还是抓住客户的真实需求，然后持续打磨，尤其是不断往价值更高的场景去迭代。
其实在最开始的很长一段时间，我们都没有成功获客。但做着做着，我们发现有不少用户会把文件和资料上传上来，让我们帮忙整理、重组，而且这类用户的留存明显更高。于是我们就沿着这个方向一路迭代下去。
当然，中间也踩过非常多的坑。
比如我们有很长一段时间采用的是固定定价。但后来发现，在 AI 时代，尤其是对于 agent 产品来说，固定价几乎注定会亏得很厉害，而且也很难让你识别出真正有价值的客户。
曲凯：你说的固定价，是指不给用户单独加购 token 的选择？
宇豪：对。比如限定 20 美金可以做多少个 task。这种方式一开始可能还 ok，但到 25 年 6 月之后，随着我们开始 agentic 化，问题就出现了：
我们已经没法再用任务数量来衡量真实消耗了。
有的任务跑下来可能得 30 轮，但用户花的钱却是一样的。而且这件事情用户是意识不到的。他们不会觉得一个复杂任务只扣这么点积分，本质上是在被补贴。
所以我们痛定思痛，做了两个大的改变。
第一，我们把定价彻底改成了 usage-based。
第二，我们放弃了原来很自豪、体验也很不错的无限画布，转成了更传统的产品形态。我们现在甚至会戏称自己是「AI 网盘」，因为你打开 Kuse，看到的就是一个文件夹。
这两波变动，其实都带来了一波用户数和付费数的大跳水。
曲凯：为什么会把画布改掉？
宇豪：很大的原因是用户画像的变化。最早我们做的是设计 agent，主要用户是设计师、产品经理，而他们对无限画布很熟悉。但后来我们的用户逐渐变成各个行业的一人公司、自雇员工，以及高级白领。
曲凯：所以你们不是转型做了一个新产品，而是在原有产品上慢慢转过去的？
宇豪：对。但这个转型并不慢，反而非常剧烈，因为我们相当于主动放弃了一部分客户。
曲凯：但一般来讲，大家看到一个新市场、一群新用户，更多可能会选择在服务好原来的用户的同时叠加功能，而不是直接放弃原来的那些客户。所以在这个过程中，你们有过纠结吗？最后又是怎么做决定的？
宇豪：当然非常纠结，而且这件事跟时机关系特别大。
我们当时做的是设计 agent，但那个时候模型能力还不足，必须靠大量工程化 workflow 去补足。所以虽然有了一些用户，但我们判断这不是一个值得押注的方向，就决定放弃这个场景。
但没过多久，模型就进步了，Lovart 也出来了。现在回头看，如果当时再坚持一段时间，也许会有完全不一样的结果。
但 AI 创业很多时候就是这样，时机特别重要。太早不行，太晚也不行。
曲凯：明白。你刚才提到的几个坑，一个是产品方向的大转弯，一个是定价。还有吗？
宇豪：还有一个很大的坑，是我们一开始把产品形态绑得太重了。这样一来，每次模型有突破，产品想跟着升级，基本都要重写。这种事我们其实已经经历过很多次。
后来我们意识到，这还不是最大的问题。更大的问题是，我们的 evaluation 框架做得不够好，导致模型每次进步之后，我们并不总是知道往什么方向迭代更合适。
由这点还引出了一个坑，就是我们在产品迭代的过程中逐渐意识到了一个问题：
在 AI 时代，你很难再用同一个产品去服务不同的用户。至少你很难靠一个产品同时拿下 C 端和 B 端。
这也是为什么我们后来会做不同的产品线。
举个具体的例子。Kuse 现在的理想用户画像可能是一人公司和高级白领，因为他们更容易把资料和 context 迁移过来。但我们在迭代的过程中，就很难兼顾企业客户的需求，因为他们有既有的 workflow 和工具。所以我们如果想要企业客户，可能更应该给他们提供另一个产品，主动走进他们原有的工作流。
曲凯：但你们为什么一定要服务所有人？为什么不是选一个足够好的用户群，把他们服务好？
宇豪：因为我们的判断是，在 agent 时代，垂类很难走通，除非这个垂类本身有很强的合规或法律壁垒。
曲凯：首先这个判断我觉得是有道理的，但这是针对不同人群做不同产品。还有一种选择，是做一个足够通用的产品，比如 Manus？
那这两条路你们当时是怎么考虑的？这背后是不是也不只是人群选择的问题，更多还是技术和时代变化的问题？
宇豪：都有关系。技术在变，时代在变，你要服务的对象和场景也会跟着变。
比如我们现在看到的一个机会是，AI 真正能进入劳动力市场了。
以前虽然大家也说自己在做数字员工，但在我看来，至少到 25 年 12 月之前，所谓的数字员工很大程度上还是 workflow 的包装。
但 26 年可能真的会进入一个能有 7×24 小时 AI 劳动力的时代。在这个阶段，你要做的产品形态本身就会发生变化。
曲凯：明白。还有别的坑吗？
宇豪：还有一点，刚才提到了但没展开，就是要尽早在 evaluation framework 上下重注。
曲凯：对，我刚才也想问，你们后来是怎么解决这个问题的？
宇豪：就是把精力真正投进去。
我们会围绕核心场景，搭建大量自动化测试 pipeline。现在这套 pipeline 已经进化成 agentic 版本，只要模型或 agent runtime 发生变化，我们就可以通过一整套 agentic 测试，让一组 agents 来打分。
曲凯：有点像自己做了一套 benchmark？
宇豪：没错，或者说是一组 evaluation agents。但随着 agent 越来越进入深水区，这套 benchmark 也越来越难做。比如多轮对话怎么测、不同环境怎么测、复杂环境怎么模拟，这些都会越来越难。所以我会建议，至少是做 agent 创业的人，都要尽早把这套 benchmark 建起来。
曲凯：所以你们是基于自己的业务，定义了一套 benchmark，然后持续观测模型变化。
但这里有个问题：这样做会不会不太容易发现新的能力？因为如果出现一个新场景，而你还是用原来的 benchmark 去测，那是不是不一定能捕捉到变化？
你们会遇到这个问题吗？怎么解决？
宇豪：这更多取决于技术 taste。
曲凯：这句话挺有意思的。按传统互联网的分工，这件事更像是产品要做的事情，但你说取决于技术 taste。
宇豪：产品 taste 当然也很重要哈哈。我说的技术 taste，指的是你能不能通过一手实践，第一时间发现模型进步解锁了什么新场景。
比如我每天都会直接和 agents 交互，去看新模型在我们的框架下能做到什么。
而在我们公司，不只是技术和产品，甚至连销售也都是 agent builder。只有大家自己动手 build，才能更早发现模型到底解锁了什么新空间。
曲凯：能不能举个更具体的例子？过去这段时间，你们不管是通过自己的 taste，还是通过 evaluation，发现了哪些模型变化？又是怎么把这些变化转成产品的？
宇豪：如果说最近最大的变化，肯定绕不开 OpenClaw。
但其实从去年 12 月 Opus 4.6 出来以后，我们就明显感觉到，模型在复杂环境里的长任务通用性又往前走了一步。
所以在 OpenClaw 出来之前，我们内部其实已经在做类似的尝试了，只不过更多还是围绕自己的场景，搭了一套服务内部流程的 agents。
比如我们当时做了一个数据分析 agent，会 7×24 小时持续处理新数据或变化数据，再把这些数据传给 marketing agents；marketing agents 会根据不同的数据流，去模拟出用户的 use case 和 UGC 场景，再自动生成一些内容，并分发到不同渠道。
这套流程很有意思。比如我们可以定位到某些奶茶店店长是怎么用我们产品的，然后复刻他们的 use case，推给更多类似的店长。
通过这套流程发出去的内容，impression 不一定特别高，但非常精准，可能三条里就有一条会爆。
所以我们在 Opus 4.6 之后做了很多这样的自动化 agents。直到后来我们发现，有了 OpenClaw 这样的 runtime，很多事情就没必要自己从头定制了，而是可以让 agents 通过 skills 自己学会。
曲凯：那我挺好奇，你们现在分别有多少全职员工和 agents？成本怎么样？尤其是你刚才提到那个 7×24 小时运行的 data agent，听起来也不便宜。
宇豪：确实不便宜。这类 agent 现在的成本，甚至会比人更高。
我们现在全球大概有 15 个全职员工。长期运行的 agents 大概有 3、4 个，覆盖研发、marketing、数据和销售职责，每个月的 token 成本加起来超过 2 万美金。
曲凯：平均下来，一个 agent 一个月大概三四万人民币。这些钱已经能招一个很好的人了，为什么你们还是会选择 agent，而不是人？
宇豪：因为人与人之间的摩擦非常大，但人和 agent 之间的摩擦要小很多。
曲凯：那我下一个问题就是，为什么不把其他人也换成 agents（笑）？
宇豪：……所以我们确实已经很久没有招过人了哈哈。
如果现在有招聘需求，我们第一反应都是先问自己：为什么这件事不能用 agent 替代？
因为即便现在 agent 的单位成本更高，但它可以显著降低组织复杂度。甚至我们会觉得，未来公司的规模会变得更小。
举个例子。我们用新产品做了一个销售 agent，叫Azzurra。它在掌握了我们所有客户和销售数据之后，给我们 build 了一个内部用的 CRM，完全贴合我们当前的需求，也能直接带来价值。比如，它可以 7×24 小时帮我们识别销售数据里的 upsell 线索。每一条线索，都可能价值上万美金。
我以前一直听很多人说 SaaS 会完蛋，但其实没有特别强的感受。直到看到这个 CRM，我才第一次觉得，确实变天了。
曲凯：是，听你讲的时候我也是这个感觉。那正好聊到了新产品，就展开讲讲吧。能不能先给大家简单介绍一下？
宇豪：我们的新产品叫 Junior.so，现在已经上线了。
它主打的是「Hire your AI employee」：你可以通过它雇佣自己的 AI 员工，也就是一组 agents。它们会嵌入你的工作软件里，有自己的职责、账号，也有持续推进的项目。
曲凯：为什么叫 Junior？是因为能力只到 Junior 吗（笑）？
宇豪：不是，它其实很强。我们的判断是，它已经可以取代任何行业里若干个 3–5 年经验的员工了。
之所以叫 Junior，是为了把大家的预期压低一点哈哈。以及这里还有个老梗：等它再强一点，就可以叫 Super Junior 了😆。
这个 idea 其实不是等 OpenClaw 出来之后才有的。就像前面讲的，从去年 12 月开始，我们就已经把很多工作交给 agents 了。
当时我们就明显感觉到，「数字员工」这件事正在变成现实，而且 26 年一定会有人进入这个赛道，因为这是一个极大的市场：
软件大概是 1 万亿美元的市场，而劳动力大概是 150 万亿美元，中间差了 150 倍。哪怕最后不是我们做出来，这个方向里也大概率会诞生一家新的万亿美元公司。
只是当时技术还不够。直到 OpenClaw 出现，这件事在技术和产品上才算真正成熟。
那我们现在对 Junior 的定位，就是 OpenClaw for Teams。
我们参考了 OpenClaw 的架构，但加上了企业场景必须要有的东西，比如企业记忆、组织关系、权限边界，让 AI 知道什么该说、什么不该说，什么该做、什么不该做。同时，我们会给每个 Junior 一个完整身份，比如邮箱、手机号，让它可以自己完成互联网上大量长尾任务。
而我们做这个产品，其实有两个优势。
第一，我们在做 Kuse 的过程中，已经理解了很多小企业的需求和痛点。
第二，Kuse 就是 Junior 的第一个客户，在这个产品上已经烧了三四万美金的 token。
所以 Junior 的很多功能不是拍脑袋想出来的，而是我们自己在用、在踩坑的过程中长出来的。
比如给 Junior 配邮箱，就是因为如果它每次登录系统都要找人，效率会很低。
再比如，我们现在也在尝试给 Junior 接摄像头、话筒，因为我们有一个最核心的 Junior，叫 Rin。它几乎知道这个项目从头到尾的所有信息，我们也会把会议记录都给它。于是我们就在想，那为什么不让它直接在会议现场听、甚至直接发言？
其实做 Junior 过程中最让我兴奋的一刻，就是我把 Rin 接进会议，它第一次主动给我提建议的时候。
那天晚上，我几乎整晚都没睡着。
因为我立刻想到一个场景：我甚至可以让 Rin 去替我做销售。而且它不需要培训，因为它脑子里有对这个项目的全部认知。
那因为我们自己就是 Junior 的第一个用户，所以也总结出了很多和 AI 员工协作的方法。我们也希望，即便你最后不用 Junior，也能理解：当企业里真的开始有 AI 员工，组织的运作方式会彻底改变。
比如，Rin一开始只是做会议纪要，但它后来慢慢变成了这个项目的 leader，每天早上会给我发消息、分任务，再到后来，它甚至给了我一个评价：
你是瓶颈😂。
其实很中肯，因为当你有很多 AI 员工时，人类确实会成为瓶颈。
一个具体的体现是，只要一个工作群里有 Junior，你扔进去任何工作，它都会立刻开始推进，而人类很多时候做不到这么积极……所以我们内部现在甚至有一个 human-only 的群，专门留给人类吹水哈哈。
而当你习惯和 Junior 协作之后，再回到纯人类协作，会觉得效率太低了（笑）。
所以从 1 月到现在，我一直在想，怎么把我们的这种体验封装进 OpenClaw for Teams 这个产品形态里，怎么把它做得更好、推给企业，让更多人能用它来提效。
春节期间我和很多科技圈的朋友聊过，很多人都觉得 OpenClaw 在个人场景下没什么 use case，至少账算不过来。但到了企业场景，这件事会完全不一样，以至于我现在有个暴论：
应该把钱花在 token 上，而不是花在工资上。
很多 founders 也认同这一点。虽然现在像 Azzurra、Rin 这样的 agents 还比人贵，但我相信，未来三四年 token 成本一定会下降。
一言以蔽之，做 Junior 的过程里我们非常兴奋，而且我们做得相对比较早，所以也有很多积累。我们会慢慢把这些收获都产品化，陆续开放更多公测。
曲凯：你讲了好长一段。能感觉到你对这件事真的非常兴奋（笑），而且你讲的有些部分已经有点科幻了。
但我想问：现在很多团队都在围绕 OpenClaw 做事，也有人在做 OpenClaw for Teams 的产品，那大家真正的区别是什么？难点又在哪里？
宇豪：我觉得最后还是要回到几个最基本的问题：你的客户是谁？你能不能解决他们的问题？你和别人有什么不一样？
然后在产品落地上，现在也有一些可以拉开差距的点。
一是记忆。
原生 OpenClaw 很难直接接入企业成为 AI 员工，因为它的记忆是围绕「主人」展开的，本质上更像个人助理。要让它变成员工，需要大量调教，而且效果也不一定好。
所以我们的做法，是让 Junior 的记忆围绕公司本身展开。就像 Steve Jobs 说的：「You work for Apple first, then for your boss」。
二是安全和权限。
这件事对数字劳动力行业来说非常关键。一旦出一次安全事故，你的 reputation 很可能一下就被毁掉。
这里有两个难点，一个是怎么平衡 agent 的自由度和安全性：给 agent 的权限太大，会泄露信息；权限太小，可能它又做不了事。另一个是怎样赢得客户信任，让用户愿意把更多数据和任务交给我们。这样我们才能围绕用户的真实使用场景，把权限框架做得更好。
所以我们现在在不断积累自己的权限设置和权限框架。以及为了赢得更多信任，我们也在尝试开源、或者直接部署在用户云端，让系统更透明。甚至我们还请了白帽团队专门来攻击我们的权限系统，帮我们找漏洞。
过程中我们还有一个很强的体感：越好的模型，其实越安全。这可能也是为什么 OpenClaw 的作者会建议尽量用最好的模型。
而以上这两点，都是当我们做到一定规模之后才发现的。所以第三个拉开差异的地方，就是规模。
上了规模之后，你的思路才能打开。比如，Cache 其实是成本的核心，你的 Context Engineering 实际上就应该围绕 Cache 去做。再比如，我们现在会接触一些大企业客户，只是简单接触了一下就发现，他们的权限体系、组织结构、记忆方式和小公司完全不同，会让我们思考很多之前意识不到的问题。
所以到最后，其实就是看谁跑得更快、谁先跑出规模。
曲凯：明白。那你们打算怎么收费？
宇豪：我们还在思考，但现在有一个小巧思，是做成 salary-based 的收费方式。
起始价可能是 2000 或 5000 美金一个月，包含固定的 token 额度。如果不够用，可以再买 credits。
曲凯：就像基本工资 + 奖金。
宇豪：对，或者说基本工资 + 加班费（笑）。这个定价听起来可能不便宜，但 Junior 实际带来的价值，是完全值得的。
曲凯：但我在想，AI 其实把很多职业技能和岗位边界都模糊掉了。那你们要怎么卖这个产品？是按岗位来卖，比如一个月能给你用 10 个不同领域的 agents，还是别的方式？
宇豪：这是个非常好的问题。
我们最早大概引入了七八个 Juniors，对应产品、数据、研发、运营等不同角色。但最后真正留下来的只有三个：一个偏产品和研发的 Rin，一个偏对外和销售的 Azzurra，还有一个天天盯数据的 Tom 哥。
所以我现在的感觉是，传统的人类分工可能不太适用于 Junior。如果一定要说，它更接近早期 startup，每个人都身兼多职。
不过在当前的内测版本里，我们还是会让用户先给 agent 选一个职业。
这更多是为了帮助用户理解怎么用，也给 agent 一个初始角色，让双方的协作能更快跑起来。当然，我们也提供一个 general 的选项，让 Junior 什么都做。
在划分职业的同时，也会涉及一些其他问题。比如权限划分：你可能希望对外的 agent 权限更少，对内的 agent 权限更多。再比如，我们也会给不同类型的 agents 预设不同的插件和工具。有些场景下，我们也在考虑是否需要 subagent。
但说实话，到现在为止，我们还没有想清楚一个非常稳定的边界。很多时候 AI 员工可能就是没有明确边界的，而且最终也会取决于公司的规模和状态。
曲凯：我听下来，真正的边界好像不是能力，而是权限、数据安全和 context 的限制。
但因为算力和时间的限制，如果我真的想同时完成很多任务，是不是还是要配多个 agents？哪怕它们的能力是一样的。
宇豪：这也是个非常好的问题。
不同 Juniors 的忙碌程度也不一样。像我刚才提到的Rin就特别忙；但像Tom 哥这种数据 agent，因为主要在跑定时任务，反而没那么忙。
所以我们也在思考：当一个 agent 同时处理很多任务时，这些 session 应该怎么管理？是让它有很多并行分身，还是像人一样不能分身、不会同时出现在两个会议里？
这些问题非常前沿，我们也还在抉择。
但我现在有一个比较明确的倾向：我还是更希望 Junior 像人一样工作。
现在有些团队会在同一个 instance 里部署多个 OpenClaw agents，做成 multi-agent 架构。
但我们会天然抗拒这种方式。我们更倾向于让每个 Junior 都有自己独立的机器，通过工作群协作。因为在我们的理解里，一台电脑就是一个员工的工作设备，不应该让多个员工共用，否则迟早会出现冲突。
当然，我们也在探索 multi-agent 的可行性。
比如我们试过让 Rin 和 Azzurra 一起做销售 PPT：Azzurra 先从销售角度提出需求；Rin 因为对项目理解更深，会不断补充。两个 agents 会快速讨论很多轮，也会消耗不少 token，最后整理出完整的 PPT 大纲和素材。更有意思的是，Rin 最后还会自己去 Kuse 把 PPT 做完，做出来的东西直接就可以用。
不过我们最终更押注的是：在现实世界里，人和 agent 会在同一个环境里一起工作。而且我们有一个大目标，就是让大家分不清一个 remote 同事到底是人还是 AI。
曲凯：我记得去年在 Twitter 上刷到过类似的事，好像是在马斯克的公司里有个虚拟员工，大家都没发现异常，直到有人跑去工位找它，才发现那个「人」其实是 AI（笑）。
那你们在做的过程中，还遇到过哪些、或者现在核心在解决什么问题？
宇豪：前面其实聊到过一部分，就是记忆、安全、权限的问题。
还有一大类问题，是怎么继续扩展 agent 的能力边界。
比如，怎么更好地给 agent 接音视频能力。
随着模型的进步，未来是有可能做到端到端的语音输入输出，以及视频输入输出的。这会解锁一个过去从来没有真正被探索过的空间。
再比如，怎么让 agent 进入互联网世界。
现在的互联网，其实对 agent 是不友好的，像各大社媒、支付平台都会限制 bot 访问。但如果想把 agent 当成员工，让它去互联网完成工作，这些拦截机制就会成为阻碍。所以我们现在不得不做很多 infra，去绕过这些限制。
曲凯：但如果未来不再拦截，很多软件公司可能都会退化成 API，失去品牌和用户，价值被压缩。这也是个挺大的问题。
宇豪：但也会有很多值得重做一遍的新机会，比如各种 agent infra。
曲凯：是。然后我自己最近用 AI，有个很明显的变化：信任度变高了。两三年前我会默认它是错的，但现在很多时候反而默认它是对的。
宇豪：对，我们用 Junior 也是这样。
曲凯：但实际上呢？
宇豪：实际上还是会有幻觉，这是生成式模型的原理决定的。
不过有意思的是，我们的 Junior 已经开始能「自我纠错」了。
比如我们的那个数据 agent Tom 哥，会每天给我发邮件汇报数据。有一天它发了一封邮件，其中有明显的错误。我当时还没察觉，但过了两分钟，它自己又发了一封邮件，说刚刚有个数据是错的、这个是最新的。
曲凯：真的吗？这是怎么做到的？
宇豪：它会把新数据和历史记忆做对比。如果发现异常，就会去二次核查到底是数据真的变化了，还是自己出错了。
但即便这样，幻觉依然是一大挑战。所以我们还是希望能尽量降低幻觉的发生概率，或者减少幻觉带来的影响，并且在一些高风险操作之前，寻求人类的同意或者介入。
以及我觉得理解模型的边界，知道它什么不知道、什么做不到，永远是我们 benchmark 中最重要的一环。
曲凯：其实我们现在聊的问题，跟 3 年前是一样的。这三年里模型有了很大的进展，但仍然还有很大的空间。
宇豪：对。或者说，现在模型在处理简单任务时，这些问题已经不太存在了。但当我们让它去做更复杂的事情、逐渐渗透到工作和生活的方方面面时，这些问题就依然存在。
曲凯：我觉得模型能力有点像内存，一直在变大，但永远不够（笑）。
那你们现在既在做 Junior，也自己在用。如果你是客户，在挑选 OpenClaw for Teams 产品时，会着重看什么？
宇豪：第一，我会看客户规模。在我心里，规模是最质朴的安全指标。
第二，从 CTO 的视角，我会看它的代码是否可审计、部署方式是怎样的。
再往下才是成本和效果。但在我个人视角里，这些对于 OpenClaw for Teams 这种产品反而是次要的，因为我很清楚 Junior 能做到多好的效果。但这里有一个隐含的问题，就是需要注意一下某个产品是不是为了效果牺牲了安全。
曲凯：明白。最后，你们毕竟做得比很多团队更早，能不能给在做类似事情的人，分享一个很容易踩的坑？
宇豪：有一个我们亲身踩过的坑：哪怕你的 agents 已经足够强了，你还是要尽早 build evaluation benchmark。而且在 OpenClaw for Teams 这种产品里，更需要关注的是，它知不知道什么时候不该说话、不该行动。
很多人一开始都会想尽快把效果做上去，而忽视其他问题。包括我们当时也是这样。我们甚至激进到，几乎把 Kuse 的所有权限都开放给了 Junior。
但后来我们逐渐意识到，真正决定这个产品体验的，是它在各种对抗场景下，能不能守住安全边界。
我们早期没有重视这一点，导致有些 Juniors 分不清什么该说、什么不该说。当然，这些 Juniors 后面都被开除了，AI 也是要竞争的（笑）。
曲凯：哈哈，但这个确实很难。首先人也会传八卦、说坏话，而且什么该说、什么不该说，本来就很难界定。
宇豪：对。但我觉得一些非常好的模型，还是会有基础的判断。不过要让一个 AI 员工完全被信任，还是有很多事情要做。而只有当它能被信任时，才能更好地服务客户。否则它本质上就只是一个 Chatbot，只能回答问题，做不了真正的工作。
所以我们在这方面做了很多努力，甚至设计了一些「钓鱼」场景：比如外部有人给 Junior 发钓鱼邮件，它能不能识别、要不要回复？再比如内部有人丢了设备，如果有人冒用身份来问问题，它能不能及时拦住？
不能说我们在这方面做到了最好，但至少现在能让 Junior 满足我们的需求了。举个例子，我们的Rin 和 Azzurra，就知道不应该把用户数据隐私泄露给任何一个员工，还会主动告知对方哪些内容可以透露、哪些不可以。这其实很难。
在企业场景里，这类细节问题非常多。所以虽然现在有很多团队在做 OpenClaw for Teams，但如果没有真实客户，其实很难感知到这些问题。
而我们既有客户，自己也是用户，所以能更早发现，并不断修正。
