WEBVTT
Kind: captions
Language: zh-Hans

00:00:08.000 --> 00:00:10.113
哈喽大家好，我是 Lewis。

00:00:10.113 --> 00:00:11.201
大家好，我是 Will。

00:00:11.201 --> 00:00:13.750
这期我们其实想接着上次，我们留

00:00:13.750 --> 00:00:16.294
了一个话题，是说讲 agent harness。

00:00:16.294 --> 00:00:18.756
然后 agent harness 最近也是非常的火，

00:00:18.756 --> 00:00:21.906
感觉这一波是 Deepseek 带起来的。

00:00:21.906 --> 00:00:24.206
他把自己的这套 core 的 harness 给

00:00:24.206 --> 00:00:26.295
open source 了，然后一下就点爆了

00:00:26.295 --> 00:00:29.794
这个 community，大家就开始试它。

00:00:29.794 --> 00:00:32.080
这个东西不如我们先给大家来说一说，

00:00:32.080 --> 00:00:35.040
agent harness 到底是什么。我的理解的话呢，

00:00:35.040 --> 00:00:37.775
这个 harness 还是非常重要的一个环节，

00:00:37.775 --> 00:00:40.885
就特别是在 agent 这个年代。咱先说它

00:00:40.885 --> 00:00:44.309
功能性上来说的话，它提到的一个最大的、

00:00:44.309 --> 00:00:48.259
提供一个最大的一个价值在于，以前的话呢，

00:00:48.259 --> 00:00:52.275
大家认为这个 agent 都是这种对话式的，

00:00:52.275 --> 00:00:55.487
他做任务都是一件事一件事，就就说我要

00:00:55.487 --> 00:00:59.372
生成一个 doc、生成一个 image。但是的话，

00:00:59.372 --> 00:01:03.488
就是这个 harness 就变、就是让这个 agent 能

00:01:03.488 --> 00:01:06.453
run 这种 long horizon task，就是几个小时

00:01:06.453 --> 00:01:08.648
的这种 task。然后整个过程当中，它需要

00:01:08.648 --> 00:01:12.155
一个一整套的 evaluation validation

00:01:12.155 --> 00:01:15.045
然后 self correction，这一套的机制能

00:01:15.045 --> 00:01:18.125
保证它能做一个更长的 task。我的从功能

00:01:18.125 --> 00:01:20.766
上理解是这样理解的，我不知道你怎么看。

00:01:20.766 --> 00:01:22.903
从产品来说吧，我觉得可能就是说，

00:01:22.903 --> 00:01:25.817
大家刚开始做这个大语言模型，可能更

00:01:25.817 --> 00:01:28.657
多的就是看这个叫什么，这个光标对吧，

00:01:28.657 --> 00:01:31.461
就是我打进去一个一个问题，然后你模型

00:01:31.461 --> 00:01:33.972
给我一个答案，这可能是第一个雏形。

00:01:33.972 --> 00:01:35.450
那个时候就是比较热门的就是叫

00:01:35.450 --> 00:01:38.428
prompt engineering 对吧，大家想怎么把

00:01:38.428 --> 00:01:41.568
这个 prompt 写好。然后当时其实我们内部

00:01:41.568 --> 00:01:45.424
还在说，每一个模型它都有自己的个性，

00:01:45.424 --> 00:01:48.409
所以你用你自己的一套 prompt 去跟

00:01:48.409 --> 00:01:52.185
OpenAI 说话，再去跟 Gemini 说话，他的理解

00:01:52.185 --> 00:01:54.673
不太一样。所以当时模型能力也是受限，

00:01:54.673 --> 00:01:56.748
所以我们说 prompt engineering。对，后来

00:01:56.748 --> 00:01:58.552
就变成了叫 context engineering 对吧。

00:01:58.552 --> 00:02:00.971
context engineering 就是说你怎么把

00:02:00.971 --> 00:02:03.598
合适的东西放在 prompt 里面，然后让

00:02:03.598 --> 00:02:06.421
模型可以更有效。这个时候我觉得好像

00:02:06.421 --> 00:02:09.414
大家还都是在做怎么回答好一个问题。

00:02:09.414 --> 00:02:12.233
现在我觉得就是说，我们一直得强调

00:02:12.233 --> 00:02:15.229
ROI 对吧，就是说企业要买模型然后

00:02:15.229 --> 00:02:17.802
部署这个东西，他要的是能够落地，

00:02:17.802 --> 00:02:20.758
他能让模型真正的去做一些任务。

00:02:20.758 --> 00:02:24.802
一旦做任务的话，就不只是简单是拿一个

00:02:24.802 --> 00:02:27.890
这个叫什么答案回来了，那他就可以要、

00:02:27.890 --> 00:02:31.904
要去执行代码对吧，要去 call API，然后要

00:02:31.904 --> 00:02:35.565
保证这些东西能够安全然后合规对吧。

00:02:35.565 --> 00:02:38.162
这个 Harness 其实就是衍生出来的这

00:02:38.162 --> 00:02:41.419
一套在模型外面的系统，能够更好的、就是

00:02:41.419 --> 00:02:44.253
让这种像你刚刚说了这个可以跑很多

00:02:44.253 --> 00:02:47.223
天的这种这种任务对吧，能够真正落地。

00:02:47.223 --> 00:02:50.353
我觉得就是说，可能他就是帮人们从一个

00:02:50.353 --> 00:02:54.984
简单的一个模型扩展到了一个一个系统。

00:02:55.609 --> 00:02:58.322
所以我是一个自然的 agent 发展的过来

00:02:58.322 --> 00:03:00.291
一个，在我眼里的话，不觉得它是一个

00:03:00.291 --> 00:03:03.110
新生物种。我觉得它就是一个 agent 在

00:03:03.110 --> 00:03:06.380
自我发展的过程当中自然而然产生

00:03:06.380 --> 00:03:10.809
的一个更系统化、更复杂、更大规模、

00:03:10.809 --> 00:03:14.598
更 engineering 的一个系统组件吧。

00:03:14.598 --> 00:03:18.047
对，这就是一个就像你说的，在每一个发展的

00:03:18.047 --> 00:03:20.430
阶段，好像大家意识到一个新的问题对吧。

00:03:20.430 --> 00:03:22.856
遇到一个新的问题，我们再给它起一个名字，

00:03:22.856 --> 00:03:24.774
把它当成一个问题然后来解决对吧。

00:03:24.774 --> 00:03:27.826
可能在当前那个阶段，现在大家要讲求它

00:03:27.826 --> 00:03:31.227
可以帮你去、就是自动化这些 task 对吧，

00:03:31.227 --> 00:03:34.677
那 harness 就产生了。那我们不如来说

00:03:34.677 --> 00:03:39.282
一说 Deepseek 它做的 harness 系统。

00:03:39.282 --> 00:03:42.717
Deepseek 好像它 Open Source 大家都非常

00:03:42.717 --> 00:03:45.434
喜欢的原因，是它把它变成了模组化，

00:03:45.434 --> 00:03:49.762
好像每一个都是一个 plugin、都是一个

00:03:49.762 --> 00:03:52.872
插件，然后大家都可以用来不同的

00:03:52.872 --> 00:03:56.466
组件来更换。这个的话是不是对企业、

00:03:56.466 --> 00:03:59.622
对很多开发的时候就有很大的帮助？

00:03:59.622 --> 00:04:04.078
对，从本质上的话，就把 harness 这个

00:04:04.078 --> 00:04:07.389
事情变得更容易 engineering 了，

00:04:07.389 --> 00:04:09.869
就变得更容易去拆组，然后根据自己

00:04:09.869 --> 00:04:13.822
的需求然后调整 harness 的 behavior。

00:04:13.822 --> 00:04:16.222
像以前的话大家都是在 Agent Loop 里面

00:04:16.222 --> 00:04:19.591
加一些 tool、加一些 command、加一些

00:04:19.591 --> 00:04:23.950
permission check 这些事情，但是它

00:04:23.950 --> 00:04:28.118
没有更系统化的去把整个 Agent Loop

00:04:28.118 --> 00:04:32.496
里面不同的组件可以任意地搭配起来。

00:04:33.158 --> 00:04:36.575
其实我们之前好像讲 memory 那期也涉及

00:04:36.575 --> 00:04:39.556
到了这些方面的话题。我们通常来说这个

00:04:39.556 --> 00:04:43.765
Agent Loop 是比较简单的，就说你有没有

00:04:43.765 --> 00:04:47.599
达到最终的目标、也完成这个任务，没完成

00:04:47.599 --> 00:04:50.798
你就自动去、自己去发现为什么没有完成。

00:04:50.798 --> 00:04:53.427
在这个过程中的话，就需要这种不同

00:04:53.427 --> 00:04:56.337
的组件然后去支持它完成这件事情。

00:04:56.337 --> 00:04:59.597
所以可能这种模块化的话，就让这种

00:04:59.597 --> 00:05:04.040
工程学来说更容易，大家只需要用同样

00:05:04.040 --> 00:05:07.683
的这么一个模板，对，把适应、对应的这些

00:05:07.683 --> 00:05:10.446
东西拿进来，它很容易就可以工作了。

00:05:10.446 --> 00:05:15.627
对，其实就是把 agent 的一些 best practice

00:05:15.627 --> 00:05:18.186
以一种可拼装的形式组在一起。

00:05:18.638 --> 00:05:21.697
你觉得这个 Deepseek 为什么会 open source

00:05:21.697 --> 00:05:23.482
这个？因为你像我们之前内部的话，曾经

00:05:23.482 --> 00:05:26.191
还有一段时间看这个 Claude Code 对吧，

00:05:26.191 --> 00:05:28.147
他做了这个 managed agent，然后大家

00:05:28.147 --> 00:05:30.097
都说，哇，他这个 harness 做的真不错。

00:05:30.097 --> 00:05:32.610
他就会觉得这个 harness 感觉是

00:05:32.610 --> 00:05:34.838
又是一个下一个风口对吧，所以要

00:05:34.838 --> 00:05:37.720
赶快去做这件事。但是这个 Deepseek

00:05:37.720 --> 00:05:40.258
直接就把他自己的这一套给开源了。

00:05:40.814 --> 00:05:43.847
我当时看到开源的时候，我主要是

00:05:43.847 --> 00:05:46.739
当时的思考逻辑就是说，他把它、因为

00:05:46.739 --> 00:05:50.620
Deepseek 他们是开源模型对吧，他是模型。

00:05:50.620 --> 00:05:53.240
一般的人都不会自己在、不会用这个

00:05:53.240 --> 00:05:55.876
Deepseek 自己的提供 API 去用这些大模型，

00:05:55.876 --> 00:05:58.222
或者用 Deepseek 的 service 去用这些

00:05:58.222 --> 00:05:59.955
大模型，他可能在任意地方去 serve。

00:05:59.955 --> 00:06:01.994
他一旦自己 serve 这些 model 的时候，

00:06:01.994 --> 00:06:03.519
他就会面临一个问题：那我用什么样的

00:06:03.519 --> 00:06:06.118
harness environment 去做这件事情？

00:06:06.118 --> 00:06:09.621
你也可以用 OpenAI 的，你也可以用 Claude，

00:06:09.621 --> 00:06:12.420
但是可能最好的就不如用一个它自、这个

00:06:12.420 --> 00:06:15.677
Deepseek 调制好的这样的一个 harness。

00:06:15.677 --> 00:06:17.894
这样的话，大家对于这个 Deepseek 这个

00:06:17.894 --> 00:06:20.089
model，特别是那些小一点 weights

00:06:20.089 --> 00:06:22.168
的 model、小一点的 model，可能就是

00:06:22.168 --> 00:06:24.296
使用体验会好很多。所以整体来说，

00:06:24.296 --> 00:06:26.614
可能就是这个能 help 他们的 adoption。

00:06:26.614 --> 00:06:29.313
对，我们刚才提出说到一点我还觉得挺、

00:06:29.313 --> 00:06:32.320
就突然我想到了哈，就是用 Deepseek

00:06:32.320 --> 00:06:34.377
的很多企业，可能他真的不会去、

00:06:34.377 --> 00:06:37.978
就是去 call 这个 Deepseek 的 API 对吧。

00:06:37.978 --> 00:06:39.987
他可能觉得不、这个对吧，不太信任。

00:06:39.987 --> 00:06:43.288
反而他可能就是把这个 open weights model

00:06:43.288 --> 00:06:45.745
用在自己的数据中心，或者是其他的云

00:06:45.745 --> 00:06:48.665
对吧。那这个时候他就非常的独立了，

00:06:48.665 --> 00:06:51.178
那他就等于这个、这个系统没有。

00:06:51.178 --> 00:06:53.230
那对于 Deepseek 来说，那可能我把这

00:06:53.230 --> 00:06:56.551
一部分也开源了，也是他唯一的途径。

00:06:56.568 --> 00:07:01.334
要不然他也很难说有一套像 Claude

00:07:01.334 --> 00:07:03.746
一样，他做一个 managed service，

00:07:03.746 --> 00:07:05.036
大家可能也很难信任他，然后去

00:07:05.036 --> 00:07:07.104
把这个服务 run 在他这个上面。

00:07:07.104 --> 00:07:11.341
其实 Deepseek 的 CEO 梁文锋之前在一次

00:07:11.341 --> 00:07:13.693
的这个泄露的内部会议上面，其实提到

00:07:13.693 --> 00:07:16.384
过一次，他们说他们就要专注、专注于做

00:07:16.384 --> 00:07:20.711
generic 大模型，其实没有提到这个 harness。

00:07:20.711 --> 00:07:22.887
然后我觉得他们现在把这个放出来，

00:07:22.887 --> 00:07:26.340
不知道是他们以后就要专注这个方向、

00:07:26.340 --> 00:07:28.508
然后持续放出来这个东西，还是说我这

00:07:28.508 --> 00:07:30.845
东西做了一个版本把它 open source

00:07:30.845 --> 00:07:33.324
出去，不做我们一个拳头产品做研发。

00:07:33.404 --> 00:07:36.498
你这个角度很有趣，其实也可以是我们下

00:07:36.498 --> 00:07:39.417
一个话题：这东西为什么就突然火了对吧？

00:07:39.417 --> 00:07:42.025
是不是因为这些像你说 Deepseek 这些

00:07:42.025 --> 00:07:44.802
大模型公司突然发现，好像模型卷的东西

00:07:44.802 --> 00:07:48.162
不多了，然后这个外边有好多新的一个领域

00:07:48.162 --> 00:07:51.904
可以去卷，然后所以大家都开始做 harness。

00:07:53.308 --> 00:07:56.906
其实我觉得在应用环境当中，除了这非常

00:07:56.906 --> 00:08:02.498
generic 的 task，harness 这个东西还是

00:08:02.498 --> 00:08:05.976
非常复杂的。包括我内部的 API 怎么调用，

00:08:05.976 --> 00:08:08.459
假如你一个公司内部开发了某一个 API，

00:08:08.459 --> 00:08:11.008
或者说某一个 validation 那个东西，或者

00:08:11.008 --> 00:08:14.865
某个 rule，这些大模型其实很难知道的。

00:08:14.865 --> 00:08:17.719
然后这些 API 可能定义的非常的不直觉，

00:08:17.719 --> 00:08:21.908
也非常不符合这个 semantic 的定义，就需要

00:08:21.908 --> 00:08:25.320
去做这个 harness。以前大家做法就是说，

00:08:25.320 --> 00:08:27.808
要不就写在 prompt 里面我这里面都有什么

00:08:27.808 --> 00:08:30.265
东西，然后后来做 context engineering，

00:08:30.265 --> 00:08:33.604
就是我写一些 skills 把这些说清楚。

00:08:33.604 --> 00:08:35.596
现在更进阶的办法，就是我把这些东西都

00:08:35.596 --> 00:08:38.122
编制在我的 harness environment 里面，才能

00:08:38.122 --> 00:08:41.820
让我系统化的开发所有 agent 都比较好用。

00:08:41.820 --> 00:08:44.258
所以这可能也是我们为什么看到多数的

00:08:44.258 --> 00:08:47.753
harness 的系统现在还都是在 coding agent

00:08:47.753 --> 00:08:50.120
上。可能你要是做这种企业的部署，这

00:08:50.120 --> 00:08:54.120
vertical 这种垂直领域的还是比较难。

00:08:54.460 --> 00:08:56.867
说到这个头，其实 harness 它对于企业

00:08:56.867 --> 00:08:58.791
的一部分需求解决挺好的。就是说这种

00:08:58.791 --> 00:09:01.867
quality 来看，就是刚才说是 coding 嘛。

00:09:01.867 --> 00:09:04.600
他 coding 大家现在看的主要还是这个

00:09:04.600 --> 00:09:06.840
quality 怎么样，因为都是 human in the loop，

00:09:06.840 --> 00:09:08.874
不会太会让这个 coding 完全自动化。

00:09:08.874 --> 00:09:11.150
你最后还是要看一下，哪怕我不看 code，

00:09:11.150 --> 00:09:12.940
我也要看一下这个生产的 app 的结果。

00:09:12.940 --> 00:09:15.540
所以说结果更重要、效率更重要，

00:09:15.540 --> 00:09:18.340
我结果正确概率越大，觉得越好用。

00:09:24.414 --> 00:09:26.981
企业它很多这种自动化的要求的话，

00:09:26.981 --> 00:09:30.393
它希望这东西就是帮我把它做对，

00:09:30.393 --> 00:09:33.085
那这个就需要很大的 guarantee，或者

00:09:33.085 --> 00:09:35.404
是 follow 某一个 rule，永远都要 follow

00:09:35.404 --> 00:09:38.454
这个 rule，那不 follow 的话就是不可以的。

00:09:38.454 --> 00:09:40.395
那这种情况下，在 harness、这种通常的这

00:09:40.395 --> 00:09:43.674
harness 的并没有实际的解决这类问题。

00:09:44.252 --> 00:09:47.965
其实也就是说，harness 并不能够真正的把

00:09:47.965 --> 00:09:52.493
一个可以重复反复的这种 workflow 变成

00:09:52.493 --> 00:09:57.038
一种、就是更 deterministic 这种情况对吧。

00:09:57.038 --> 00:10:00.554
它还是等于做了很多的希望能够让它

00:10:00.554 --> 00:10:04.220
变成更可靠，但是事实上还是会出现各种

00:10:04.220 --> 00:10:06.245
问题。所以如果说用咱以前说的这个

00:10:06.245 --> 00:10:09.164
availability 是几个 9 嘛是吧，我觉得

00:10:09.164 --> 00:10:12.514
现在可能就是一个 9 的状态，90% 做对，

00:10:12.514 --> 00:10:15.660
但是企业可能需要三个 9、四个 9，但一直都

00:10:15.660 --> 00:10:18.784
是这样子，所以还是有很大的距离要做。

00:10:19.068 --> 00:10:21.766
对，确实是。因为像我们内部当时在做这个

00:10:21.766 --> 00:10:24.981
Agent Memory 的 benchmark，我们开源的

00:10:24.981 --> 00:10:27.433
一个东西叫 State-bench，对，之前有说过。

00:10:27.433 --> 00:10:30.345
其实我们另外定义了一个 metrics，

00:10:30.345 --> 00:10:33.050
就是 run 同一个 task run 五遍，看看你

00:10:33.050 --> 00:10:35.284
是不是都能拿到同样的结果对吧。

00:10:35.284 --> 00:10:38.265
就是如果你发现这个有起伏，那就说明

00:10:38.265 --> 00:10:40.991
你这一套 workflow 定义的 harness 就

00:10:40.991 --> 00:10:44.744
不够，对 enterprise 里面就不够可靠。

00:10:44.744 --> 00:10:47.368
5 次都做对，其实也不是那么可靠听起来。

00:10:47.368 --> 00:10:50.754
哈哈。哈哈，对。那这个东西是吧，你要做到多少？

00:10:50.754 --> 00:10:54.688
这个三个 9，那就得 run 多少次，就几万次可能。

00:10:55.624 --> 00:10:58.891
感觉整个就算 harness 现在我们想到的

00:10:58.891 --> 00:11:01.827
这个雏形就做到非常好，也很难去解决这个

00:11:01.827 --> 00:11:04.904
真正 enterprise 里面的这些部署问题。

00:11:04.904 --> 00:11:05.604
对。

00:11:05.604 --> 00:11:09.866
所以我觉得这个 harness 本身的话，

00:11:09.866 --> 00:11:12.280
那可能是至少跟现在的这种方式，

00:11:12.280 --> 00:11:14.454
可能不足以解决 enterprise 的问题。

00:11:14.454 --> 00:11:16.932
那你说下一个东西能解决 enterprise 的

00:11:16.932 --> 00:11:19.245
问题是不是叫 harness？又会起一个新的

00:11:19.245 --> 00:11:22.956
名字对吧。可能现在有叫 Control plane。

00:11:22.956 --> 00:11:25.196
loop engineering 算不算？

00:11:25.196 --> 00:11:26.596
有 loop engineering。

00:11:26.596 --> 00:11:29.407
还有 governance 对吧。然后这些

00:11:29.407 --> 00:11:31.456
东西可能就是下一代东西能

00:11:31.456 --> 00:11:33.656
帮助企业把这个确实做好。

00:11:33.996 --> 00:11:38.144
其实我们前一期录的时候我有分享一点。

00:11:38.144 --> 00:11:41.085
我觉得像 Deepseek 的这种方式，它把所有

00:11:41.085 --> 00:11:44.536
的东西都变成一个 plugin，然后这个其实

00:11:44.536 --> 00:11:47.445
是我觉得是相信大模型的一个做法。

00:11:47.445 --> 00:11:51.308
它甚至连 agent loop 你都可以换掉，

00:11:51.308 --> 00:11:54.248
当然这是需要人去换。我们当时做的

00:11:54.248 --> 00:11:58.499
memory 就是说，大模型可能不能够很

00:11:58.499 --> 00:12:02.686
稳定的去 call memory，我要做一个

00:12:02.686 --> 00:12:05.096
knowledge base 的种 retrieval 什么时候，

00:12:05.096 --> 00:12:07.763
我就 hard code 进去，每次都做，保证一定

00:12:07.763 --> 00:12:11.344
会有这个 context。这个其实大家就等于

00:12:11.344 --> 00:12:14.219
在这个 loop 里面做了很多很多工作。

00:12:14.219 --> 00:12:17.527
现在这么看来的话，就说 Deepseek 的这个

00:12:17.527 --> 00:12:20.381
角度，它就很明确的是说我们放权了对吧，

00:12:20.381 --> 00:12:25.814
让大模型、让 intelligence 去 lead the way。

00:12:25.814 --> 00:12:29.590
这个我觉得还是、我觉得还是怎么说，我

00:12:29.590 --> 00:12:31.751
觉得从他的角度来，他做这件事非常合理，

00:12:31.751 --> 00:12:34.456
作为一个 open source、相信一个未来的角度。

00:12:34.456 --> 00:12:36.586
对。对于 enterprise，可能大家现在

00:12:36.586 --> 00:12:38.574
还是会说我都 hardcode 起来，

00:12:38.574 --> 00:12:40.876
这样就更确定性更高一点。

00:12:41.870 --> 00:12:44.921
对，所以其实你提到这个所有东西，

00:12:44.921 --> 00:12:46.882
对于我们来说都特别兴奋的。就是说，

00:12:46.882 --> 00:12:48.971
因为我们在做 self improving agent，

00:12:48.971 --> 00:12:51.936
就自我迭代嘛，那你要是能系统性的

00:12:51.936 --> 00:12:55.806
决定你所有东西都是可以自我调整的，

00:12:55.806 --> 00:12:59.633
那就会有最大的 flexibility。就像基因

00:12:59.633 --> 00:13:02.435
对吧，你所有的这个链组都是可以改的，

00:13:02.435 --> 00:13:05.118
那你就是进化就无限的可能对吧。

00:13:05.118 --> 00:13:08.531
所以就是看到他们这样做的时候觉得，

00:13:08.531 --> 00:13:10.943
哦，这个还是有人跟我们想的思路挺

00:13:10.943 --> 00:13:13.865
像的，就认为所有东西都是可以改的。

00:13:13.865 --> 00:13:17.154
但是现在还没有看到改这个 model 自己的

00:13:17.154 --> 00:13:20.674
architecture、自己 weights 的这个事情，

00:13:20.674 --> 00:13:22.726
可能把这个 fine-tuning 的这东西加进去

00:13:22.726 --> 00:13:24.703
之后，它的连接 model 自己也可以改自己。

00:13:24.703 --> 00:13:28.643
对，这个主要就是叫什么时间 compute 对吧？

00:13:28.743 --> 00:13:30.950
这个可能现在还不是特别 feasible。对，

00:13:31.158 --> 00:13:35.096
但我相信肯定最后也会有人做。但是事实上，

00:13:35.303 --> 00:13:37.603
我觉得这也是一个迷思，我们可能扯远了。

00:13:37.723 --> 00:13:40.843
就是 continuous training 这个话题其实

00:13:40.843 --> 00:13:44.830
是感觉是老生常谈了，其实当时我们在

00:13:44.830 --> 00:13:47.883
做 AI 的很多年前就在做这个，但是好像

00:13:47.883 --> 00:13:51.369
在那个时代也都没有落地。这个就里面

00:13:51.369 --> 00:13:55.295
感觉还是有很多这个叫什么 bottleneck。

00:13:55.295 --> 00:13:56.295
对。

00:13:57.503 --> 00:14:02.514
还是价值不是特别清楚我觉得。因为你像

00:14:02.514 --> 00:14:05.127
之前是 continuous learning 一般都是做

00:14:05.127 --> 00:14:08.341
fine tuning，然后 fine tuning 还比较花数据，

00:14:08.341 --> 00:14:11.605
然后能提高的东西也比较有限，然后还有

00:14:11.605 --> 00:14:15.247
解决这个、还解决不了以前这个会忘记过去

00:14:15.247 --> 00:14:20.082
的问题。所以这东西作为一个卖点的话，

00:14:20.082 --> 00:14:22.857
让用户看到效果可能需要很长的时间。

00:14:22.857 --> 00:14:25.569
我觉得现在的这个 self improvement

00:14:25.569 --> 00:14:27.457
像咱上次聊的，还是面临同样的问题：

00:14:27.457 --> 00:14:31.161
我又怎么样能给这个用户看到价值？他们

00:14:31.161 --> 00:14:34.597
还是很希望现在我买东西现在开箱即用。

00:14:35.071 --> 00:14:37.690
确实是。但我觉得像这个 Deepseek 的话，

00:14:37.690 --> 00:14:41.157
就应该已经帮助很多公司可以做到这个了。

00:14:41.157 --> 00:14:44.160
因为我其实发布以后试了试，然后看了

00:14:44.160 --> 00:14:47.220
网上那些大家用的体验，很多人就是说

00:14:47.220 --> 00:14:50.398
拿来啪一跑，然后换上千问的模型就

00:14:50.398 --> 00:14:53.498
非常强。我觉得这个东西其实就是让

00:14:53.498 --> 00:14:57.311
大家更能够离 frontier 就更近一步。

00:14:58.243 --> 00:14:59.543
对，确实。

00:14:59.551 --> 00:15:01.931
我们刚才提到了这个 Claude 是有

00:15:01.931 --> 00:15:05.864
managed agent。当时其实我们很担心的

00:15:05.864 --> 00:15:09.033
一块，就是你如果是大模型公司，你的

00:15:09.033 --> 00:15:12.684
harness 其实是可以和模型一起去训练的。

00:15:12.684 --> 00:15:16.151
如果我们是说一些非常通用的这些

00:15:16.151 --> 00:15:19.151
工具的话，比如说读写一个文件什么，

00:15:19.151 --> 00:15:22.237
这些大家都可以；但一旦涉及到有一些

00:15:22.237 --> 00:15:25.392
比如说你私有化的一些工具，如果是

00:15:25.392 --> 00:15:31.690
frontier lab，Anthropic、Gemini、OpenAI，

00:15:31.690 --> 00:15:33.715
它是不是就会比其他的这种公司要有

00:15:33.715 --> 00:15:36.565
一个很大的一个优势？当然 Deepseek

00:15:36.565 --> 00:15:38.979
我们说的也是它拥有这个模型。

00:15:38.979 --> 00:15:42.081
那有一些开源的这种做 harness 的话，

00:15:42.081 --> 00:15:44.497
它不能够跟模型强绑定，这种情况

00:15:44.497 --> 00:15:48.065
是不是他们的这竞争力就会差很多？

00:15:48.667 --> 00:15:52.047
这个确实我两边都觉得有可能。

00:15:52.047 --> 00:15:54.819
一方面就是在大模型的话，他们自己

00:15:54.819 --> 00:15:57.647
train 自己的 harness，但是他们其实

00:15:57.647 --> 00:16:00.540
想要开发的是更通用的智能对吧。

00:16:00.540 --> 00:16:05.522
所以就是说，一方面我觉得他应该不会

00:16:05.522 --> 00:16:09.918
说是我就要 customize 的 model，假如说

00:16:09.918 --> 00:16:13.515
OpenAI 就是给我 Codex 去 train 我这个

00:16:13.515 --> 00:16:17.072
model，以至于它在这 harness 做的很好。

00:16:17.072 --> 00:16:19.213
有可能的可能是说，它能有更早的

00:16:19.213 --> 00:16:22.439
access 这个 model，然后可能根据这个

00:16:22.439 --> 00:16:27.239
事情把它 harness 做的优化，这个有可能。

00:16:27.239 --> 00:16:31.003
然后回到创业的话，其实你像 Pi 现在大家，

00:16:31.003 --> 00:16:33.095
我虽然说我还没有自己用过，但是现在就是

00:16:33.095 --> 00:16:36.703
feedback 特别好，就说他们特别的省 token。

00:16:36.703 --> 00:16:37.943
省 token。

00:16:40.559 --> 00:16:42.339
所以至于说这个模型怎么能跟

00:16:42.339 --> 00:16:45.639
harness 做好、然后怎么跟 coding agent

00:16:45.639 --> 00:16:47.539
做的更好的话，我觉得这个也不是说

00:16:47.539 --> 00:16:50.001
别人就没有这个 technology，在大家

00:16:50.001 --> 00:16:52.415
都有这个大模型 access 的前提下。

00:16:52.415 --> 00:16:55.165
因为你像说 Pi 的话，就是我看到他说他很省、

00:16:55.165 --> 00:16:58.018
省 token 的原因，一个就是说他 system

00:16:58.018 --> 00:17:00.959
prompt 是少于 1000 个 token，就非常小；

00:17:00.959 --> 00:17:04.945
其次他整个 harness 里面就只有四个 tool，

00:17:04.945 --> 00:17:07.855
就是读写文件然后改文件，就这些东西。

00:17:07.855 --> 00:17:11.248
从 Deepseek 的角度说，他就非常广泛。

00:17:11.248 --> 00:17:14.881
你再看 Claude code 的话，其实我相信他就

00:17:14.881 --> 00:17:17.475
更多了，因为他还要 manage 自己的 memory。

00:17:17.475 --> 00:17:19.581
他可能、我不知道 Claude 里面还有一些

00:17:19.581 --> 00:17:23.335
API，他要 set 一个 outcome 这种东西。

00:17:23.388 --> 00:17:26.455
其实从一定的角度来说，你把这个模型

00:17:26.455 --> 00:17:31.045
和 harness 绑定去做这件事的，其实

00:17:31.045 --> 00:17:34.568
你是有飞轮的、飞轮效应的。因为你说

00:17:34.568 --> 00:17:38.917
coding Agent 的话，我落地的 Use Case 是这样，

00:17:38.917 --> 00:17:42.589
我可以试试怎么能够把它弄得更好，然后

00:17:42.589 --> 00:17:46.269
反而去看看这东西能不能变成通用的。

00:17:46.269 --> 00:17:49.589
好像就是说直接去做通用，我只是猜想，

00:17:49.589 --> 00:17:54.869
就是说直接做通用的话感觉太广泛了。

00:17:55.123 --> 00:17:59.758
对，确实做通用、直接做通用的难度高很多，

00:17:59.758 --> 00:18:02.613
然后要求也高很多。对，但是如果能把它

00:18:02.613 --> 00:18:05.400
做通，像 cursor 一样对吧，他最后也能

00:18:05.400 --> 00:18:08.086
创业自己的 model，然后他反向的去控制

00:18:08.086 --> 00:18:10.867
这件事情，说不定也是一个创业的机会。

00:18:10.867 --> 00:18:13.673
那说到创业的话，你觉得在企业这边，

00:18:13.673 --> 00:18:16.071
比如说我们做 vertical 和做比较

00:18:16.071 --> 00:18:19.717
generalized 的一个 harness 是有区别的吗？

00:18:19.717 --> 00:18:22.999
因为我马上能想到的就比如说我们刚才

00:18:22.999 --> 00:18:25.495
说有不同的工具，我们现在看到的这些

00:18:25.495 --> 00:18:29.166
harness 的工具，好像很难说我想去内部

00:18:29.166 --> 00:18:33.037
调用一个什么 Google Workspace 的 tool，

00:18:33.037 --> 00:18:34.819
或者说想去调用一个微软的什么你的

00:18:34.819 --> 00:18:37.577
identity 的 tool 对吧。这些东西好像还

00:18:37.577 --> 00:18:41.190
都是比较 specific，而且我们还现在

00:18:41.190 --> 00:18:43.881
说的是……但是对于很多像公司来说，

00:18:43.881 --> 00:18:47.671
它要 private，这个东西就要变得非常难。

00:18:47.671 --> 00:18:50.087
我觉得它是有机会的，就是特别是像

00:18:50.087 --> 00:18:52.356
企业这种应用啊。就特别现在是我们

00:18:52.356 --> 00:18:54.914
看到一个 trend，就是现在很多的企业、

00:18:54.914 --> 00:18:57.431
不同的 industry 的话都在 train 自己

00:18:57.431 --> 00:19:02.778
的这个 domain specific 这些大模型。

00:19:02.778 --> 00:19:06.006
像这个呃，刚刚那个 Harvey 自己那个 legal

00:19:06.006 --> 00:19:09.039
的模型，我们一个叫 Tenet，其中一个例子。

00:19:09.039 --> 00:19:12.714
然后现在还有一些 insurance 公司也要做

00:19:12.714 --> 00:19:16.629
自己的大模型，然后他们每一个 industry

00:19:16.629 --> 00:19:20.315
里面它有非常多的自己的这些条款。

00:19:20.315 --> 00:19:23.071
虽然你说这些 information 有一部分是

00:19:23.071 --> 00:19:25.461
public information 对吧，但是这个说

00:19:25.461 --> 00:19:28.383
Train 模型的时候可能没有那么多的区别。

00:19:28.383 --> 00:19:30.752
但是从 harness Environment 来讲，

00:19:30.752 --> 00:19:32.904
如果我们认为 coding 你可以做很多的

00:19:32.904 --> 00:19:36.249
harness，然后我觉得做这些某一个企业

00:19:36.249 --> 00:19:38.735
domain 的具体业务流程，也会有很多这种

00:19:38.735 --> 00:19:43.670
domain knowledge 可以强制的加进去的。

00:19:43.670 --> 00:19:45.940
所以我觉得还是，要是这些既然有

00:19:45.940 --> 00:19:49.029
Open weights 这些模型 fine tune for 某个

00:19:49.029 --> 00:19:51.689
domain，那我觉得也会有很多这种跟着

00:19:51.689 --> 00:19:55.649
这些模型一起的这些 harness 系统的存在。

00:19:55.799 --> 00:19:59.643
其实我可能看的就跟你不是特别一样。

00:19:59.643 --> 00:20:03.419
我是觉得你要是走 vertical 的话，我相信它

00:20:03.419 --> 00:20:06.794
一定是会有一些 quality，但是我其实比较

00:20:06.794 --> 00:20:10.736
持怀疑态度是，它到底能够有多大的提升。

00:20:10.736 --> 00:20:16.467
因为我们还是回到模型的通用的智能，

00:20:16.467 --> 00:20:21.923
它的能力是变得越来越强了，有些东西

00:20:21.923 --> 00:20:24.089
可能你把它放到模型内部或者放到

00:20:24.089 --> 00:20:27.771
harness 里面，可能就节约更多的一些 token。

00:20:27.771 --> 00:20:31.430
但是事实上它是不是真正能够使得这个

00:20:31.430 --> 00:20:35.140
模型有巨大的提升，这个我确实不知道。

00:20:35.140 --> 00:20:38.832
而且像像 Harvey 那个例子，其实他是把

00:20:38.832 --> 00:20:42.021
模型 train 了对吧，他其实在这个 harness

00:20:42.021 --> 00:20:45.023
上面的话，可能就是说 interaction 也

00:20:45.023 --> 00:20:47.305
是同样的一些东西，这个我就不知道了，

00:20:47.305 --> 00:20:49.871
不知道他们怎么去 run the benchmark。

00:20:49.871 --> 00:20:54.033
我猜应该是会做一些这个 work。就当像我们

00:20:54.033 --> 00:20:56.782
当年在 Orby 做这个 computer use 上面的话，

00:20:56.782 --> 00:20:59.048
我们也下了很多的一些限制吧，当时不叫

00:20:59.048 --> 00:21:01.775
harness，但是现在其实这些事情也都是

00:21:01.775 --> 00:21:04.390
定义在 harness：你怎么 maintain state，

00:21:04.390 --> 00:21:06.418
怎么进入下一步，什么东西可以做、什么

00:21:06.418 --> 00:21:09.567
东西不可以做。所以我觉得可能那个

00:21:09.567 --> 00:21:15.088
这些 legal firm 还是没有到这里吧，他们

00:21:15.088 --> 00:21:19.825
可能还都比较早期，所以说可能有机会。

00:21:19.825 --> 00:21:22.985
它确实像你说的，就是这些小模型啊

00:21:22.985 --> 00:21:25.437
做 harness 这些事情能不能有一个

00:21:25.437 --> 00:21:29.055
实际 meaningful 的提高，这个不知道了。

00:21:29.055 --> 00:21:32.078
但是至少有一个是大家都认可的，

00:21:32.078 --> 00:21:34.305
就是这个会给至少这些企业认为他们

00:21:34.305 --> 00:21:36.672
有 better control，然后至少感觉还是

00:21:36.672 --> 00:21:39.869
有 better control。实际有没有的话呢，

00:21:39.869 --> 00:21:42.977
可能也比较难以衡量，因为你就是很主观

00:21:42.977 --> 00:21:45.551
的事情，它不太容易 apple to apple compare。

00:21:45.551 --> 00:21:47.779
明白。因为我看到的可能就是这些

00:21:47.779 --> 00:21:51.066
Open Source 的 harness 的 framework

00:21:51.066 --> 00:21:52.599
出来以后，大家测的第一步其实是测的

00:21:52.599 --> 00:21:55.066
这个 token saving，就是看那个 cache 的

00:21:55.066 --> 00:21:57.837
hit rate 到底是有多少。就是你一个 harness

00:21:57.837 --> 00:21:59.999
系统应该是能做到就是 95% 就可以到

00:21:59.999 --> 00:22:03.311
那个 cache 上，这样就是 token cost 一下

00:22:03.311 --> 00:22:05.584
就降下来了对吧。真正的那个你能不能

00:22:05.584 --> 00:22:09.591
Deliver 那个 High Quality，可能还是要

00:22:09.591 --> 00:22:12.150
靠那个模型本身。对，然后要靠那个 tool

00:22:12.150 --> 00:22:14.676
拿回来的这个 quality 好不好。所以我的、

00:22:14.676 --> 00:22:19.030
我可能看到就是说，可能在 cost saving

00:22:19.030 --> 00:22:21.631
上面我觉得它可能会有一个比较大

00:22:21.631 --> 00:22:25.005
的区别，但是 quality 可能打一个问号。

00:22:26.023 --> 00:22:28.634
不管怎么说，现在刚才提到的话，现在

00:22:28.634 --> 00:22:31.318
企业的整个 Agent 的正确率还是不够，

00:22:31.318 --> 00:22:34.535
还是有很大的差距。虽然说有的一些的

00:22:34.535 --> 00:22:38.503
业务流程它对正确率要求没有那么高，

00:22:38.503 --> 00:22:43.091
那些就会更先落地；但是像那些对于正确率

00:22:43.091 --> 00:22:46.599
要求很高、然后它又需要很低的 cost，

00:22:46.599 --> 00:22:49.377
我觉得这里面的话还有很长的路要走。

00:22:49.377 --> 00:22:52.520
说不定你专注做的，还是你做时间够长了，

00:22:52.520 --> 00:22:55.662
可能就变成下一代的系统了。所以这个

00:22:55.662 --> 00:22:59.591
可能也就朝着像所谓的叫做 AI Operating

00:22:59.591 --> 00:23:03.302
System，就 AI 操作系统、Agent 操作系统。

00:23:03.302 --> 00:23:06.387
对，还有一个名词叫企业 AI 操作系统。

00:23:06.387 --> 00:23:08.896
那这些其实也都是我要这样一个概念，

00:23:08.896 --> 00:23:10.867
说我要有一个这样一个环境，能让我

00:23:10.867 --> 00:23:13.171
这些 Agent 去做我自己企业的事情。

00:23:13.171 --> 00:23:16.163
确实是。我觉得可能就像我们刚才说这个

00:23:16.163 --> 00:23:19.039
Pi 的例子哈，就是它是一个非常迷你版

00:23:19.039 --> 00:23:23.055
的这么一个 harness，那它的受众可能更

00:23:23.055 --> 00:23:26.396
多就是我们说开发者觉得，哎呀好小啊，

00:23:26.396 --> 00:23:28.734
就非常 light weight 非常快就可以，

00:23:28.734 --> 00:23:31.718
我作为一个开发者我可以去、去拓展它。

00:23:31.718 --> 00:23:34.550
但可能对于一个社会来说，它可能更多的是

00:23:34.550 --> 00:23:36.964
需要像你说的就是 Deepseek 这样样类型

00:23:36.964 --> 00:23:39.463
的对吧。他可能要把这个不同的分层啊、

00:23:39.463 --> 00:23:42.622
分级啊，把这个能、这个权力给他分开，

00:23:42.622 --> 00:23:46.390
这样可能大家才会有真正的这种掌控感，

00:23:46.390 --> 00:23:49.545
才能够相信这个模型它做的事情对不对。

00:23:49.545 --> 00:23:52.345
我给你说一个就是我们做的一个

00:23:52.345 --> 00:23:56.167
案例的 use case 很有趣。就是我们聊了

00:23:56.167 --> 00:23:59.067
很多企业，他们其实会有自己的这个

00:23:59.067 --> 00:24:02.451
叫商业逻辑 business logic，然后很多

00:24:02.451 --> 00:24:04.851
这种 business logic 都是说我要先执行

00:24:04.851 --> 00:24:06.645
第一步、执行第二步、再执行第三步，如果

00:24:06.645 --> 00:24:09.862
遇到什么问题，就说我们说的 workflow。

00:24:09.862 --> 00:24:13.008
然后我们让大模型就是说去理解这个，

00:24:13.008 --> 00:24:16.317
看到比如他有这些 flow chart 也好、

00:24:16.317 --> 00:24:19.727
写的这些 manual 也好，他去理解他都可以

00:24:19.727 --> 00:24:22.362
做到非常好。但是当让一个大模型说你

00:24:22.362 --> 00:24:25.410
按照这个东西去一步一步执行的时候，

00:24:25.410 --> 00:24:28.105
大模型就挂掉了。我们虽然说很多模型

00:24:28.105 --> 00:24:30.535
可以在做 instruction following 很正好，

00:24:30.535 --> 00:24:34.708
但是到执行这种真正的、就是实打实的这种

00:24:34.708 --> 00:24:37.750
API 然后一步一步执行，它就全都乱掉了，

00:24:37.750 --> 00:24:42.101
它无法真正的去 follow 这个 instruction。

00:24:42.101 --> 00:24:46.199
这个感觉这个地方就像你说的，可能需要

00:24:46.199 --> 00:24:48.709
确实是有一个系统可以保证它对吧，

00:24:48.709 --> 00:24:50.824
按部就班的把它执行好。当然我们说

00:24:50.824 --> 00:24:53.794
codify 这个东西可能也是一个方式对吧。

00:24:53.794 --> 00:24:57.951
还有举一个例子就是 payment 系统，以后

00:24:57.951 --> 00:25:02.051
可能大家说拿 agent 去买东西或者什么的。

00:25:02.051 --> 00:25:05.143
然后我聊了天的时候有个朋友遇到的

00:25:05.143 --> 00:25:07.564
问题是说，他曾经有一次跟这个模型

00:25:07.564 --> 00:25:11.137
说这是我的 credit card number，然后

00:25:11.137 --> 00:25:15.155
这个大模型就下一次、就是他就直接就

00:25:15.155 --> 00:25:17.987
会拿 credit card 去帮他结算了对吧。

00:25:17.987 --> 00:25:22.402
就是这个东西因为做 decision 和执行的

00:25:22.402 --> 00:25:25.988
发生在同一个层面对吧，他没有把他剥

00:25:25.988 --> 00:25:29.475
离开，这个时候人就完全就 lose control

00:25:29.475 --> 00:25:31.015
了对吧。我觉得好像企业包括我们

00:25:31.015 --> 00:25:33.673
日常还有很多 work，我觉得是真正让

00:25:33.673 --> 00:25:36.433
这个可以让他落地的话，有事情要做。

00:25:36.433 --> 00:25:41.180
对，企业最大的问题是要上 scale 对吧。

00:25:41.180 --> 00:25:44.657
你要是 99% 的正确率，100 次错一次它也

00:25:44.657 --> 00:25:47.530
不能接受，就像你星巴克买咖啡 100 杯

00:25:47.530 --> 00:25:50.560
做错一次，这也不太能接受。所以企业

00:25:50.560 --> 00:25:54.066
的要求还是非常非常高的，对于他们

00:25:54.066 --> 00:25:57.683
不仅是从企业的营收方面考虑，它还有

00:25:57.683 --> 00:26:01.508
很多的 regulation constraints 对吧。

00:26:01.508 --> 00:26:03.978
那些保险公司、银行，它有的非常非常具体

00:26:03.978 --> 00:26:07.463
的机构，那都是涉及到 legal 问题，他会要

00:26:07.463 --> 00:26:13.597
面临罚款，那是比较实打实这个 impact 吧。

00:26:13.597 --> 00:26:16.904
但是如果你说你省的钱只是说少雇了

00:26:16.904 --> 00:26:20.209
一些人的话，这个最后这个 ROI 还是不 work。

00:26:20.209 --> 00:26:23.749
所以企业的话，我觉得这个 harness

00:26:23.749 --> 00:26:26.929
肯定是需要还要升级迭代。然后我还也

00:26:26.929 --> 00:26:31.889
觉得这个 neurosymbolic 也会是其中

00:26:31.889 --> 00:26:35.286
一个很重要的一个互动。我不能想象

00:26:35.286 --> 00:26:37.366
一个至少在企业环境里面一个没有

00:26:37.366 --> 00:26:41.399
neurosymbolic 这样的一个 harness 系统

00:26:41.399 --> 00:26:44.749
的存在，不管这个 model 能力提升有多高。

00:26:45.041 --> 00:26:48.150
后来这个可能就是现在系统的一个 gap，

00:26:48.150 --> 00:26:50.548
我们现在还没有看到一个非常有效的

00:26:50.548 --> 00:26:54.481
系统可以做到这一点。你觉得这一块其实

00:26:54.481 --> 00:26:58.023
可能是一个 one billion dollar question：

00:26:58.023 --> 00:26:59.771
这个 harness 这个东西会不会真正

00:26:59.771 --> 00:27:06.057
的就被模型吃掉呢？因为我们看之前、

00:27:06.057 --> 00:27:08.882
刚才我们刚才也说到了这个，可能

00:27:08.882 --> 00:27:12.438
这个 harness 跟模型一起 train 效果

00:27:12.438 --> 00:27:14.902
更好对吧。那如果就说大模型公司说，

00:27:14.902 --> 00:27:17.948
那这个 harness 包括我们想说的这些

00:27:17.948 --> 00:27:20.780
在 wishlist 上面的东西他们都做到了，

00:27:20.780 --> 00:27:23.885
是不是这一块蛋糕就就都没有了？

00:27:25.056 --> 00:27:27.681
我觉得不太会，还是我还是觉得不太会。

00:27:27.681 --> 00:27:29.839
因为还是像刚才说，我觉得 harness

00:27:29.839 --> 00:27:31.657
系统里面有个重要的部分，就是这个

00:27:31.657 --> 00:27:34.681
会有一个 neurosymbolic 系统的存在。

00:27:34.681 --> 00:27:37.558
它还是要去 symbolify 很多很多事情，

00:27:37.558 --> 00:27:40.744
一个原因在于它很高效，另外一个它

00:27:40.744 --> 00:27:43.657
就是更能做到百分之百的 control。

00:27:43.657 --> 00:27:47.041
所以的话我觉得大模型可以演化、可以演化

00:27:47.041 --> 00:27:51.169
它的能力更强，它可能变得越来越高效。

00:27:51.169 --> 00:27:55.372
但是从让我们变得更容易 control、更容易

00:27:55.372 --> 00:27:57.558
让系统变得更 scalable 的话，我觉得这个

00:27:57.558 --> 00:28:01.009
harness 系统还是必要存在的。你怎么看？

00:28:01.101 --> 00:28:04.486
我跟你相反，我觉得可能这个东西要被

00:28:04.486 --> 00:28:06.881
大模型吃掉。codify 那就是把你现在的

00:28:06.881 --> 00:28:09.789
东西写成 code、code generation，我觉得

00:28:09.789 --> 00:28:12.394
这个问题现在基本上解决了。然后我是

00:28:12.394 --> 00:28:14.341
觉得我同意的一点就是没有解决的，

00:28:14.341 --> 00:28:17.536
就是怎么做这种 permission escalation，

00:28:17.536 --> 00:28:19.780
什么时候 agent 能够干这件事、不能

00:28:19.780 --> 00:28:22.300
干这件事，可能还需要一个第三方

00:28:22.300 --> 00:28:25.194
的一套系统或者 layer 介入对吧。

00:28:25.194 --> 00:28:29.622
是不是 harness 的一部分我不太确定，至少

00:28:29.622 --> 00:28:33.654
我现在来看的话，它可能是不在 harness

00:28:33.654 --> 00:28:38.019
系统里面。其实我给你举个例子，像这个现在

00:28:38.019 --> 00:28:41.721
CPU 芯片对吧，大家都认为 CPU 计算它绝对

00:28:41.721 --> 00:28:44.724
不会出错，但是其实它也是电压控制。对。

00:28:44.724 --> 00:28:46.004
他也会出错。

00:28:46.148 --> 00:28:48.090
它还要是一个 validation 的东西，

00:28:48.090 --> 00:28:50.821
确保我这个 bit 是没有乱掉的。然后呢

00:28:50.821 --> 00:28:54.888
那个东西就是 harness。其实我觉得像

00:28:54.888 --> 00:28:58.964
CPU 这么已经这么规模化、然后这么的、

00:28:59.144 --> 00:29:01.440
这么稳定的一个东西，它也是需要这个

00:29:01.440 --> 00:29:05.947
check 的系统的存在。所以我觉得包括电话

00:29:05.947 --> 00:29:09.064
信号传输、高速信号传输，它全都会有一个……

00:29:09.064 --> 00:29:09.764
对。

00:29:09.764 --> 00:29:14.690
checksum。但是不、就是说用你的理论

00:29:14.690 --> 00:29:17.465
打你的话，它就变成了 CPU 的一部分了。

00:29:17.465 --> 00:29:20.587
你在卖 CPU 的时候你就可以卖这个系统对

00:29:20.587 --> 00:29:24.844
吧，你说你可能要需要另外一套对吧。

00:29:24.844 --> 00:29:27.887
这个东西会不会被这个 Open AI 吃掉？

00:29:27.887 --> 00:29:30.864
确实像你说的可能会被它吃掉。它就是给

00:29:30.864 --> 00:29:34.040
大模型的时候，以后大模型出来了就自带

00:29:34.040 --> 00:29:37.666
harness，那我就配套来的，是很有可能发生

00:29:37.666 --> 00:29:40.242
的吧。是不是需要一个通用的 harness？

00:29:40.242 --> 00:29:42.305
或者说 harness 就会像变成 Checksum

00:29:42.305 --> 00:29:44.289
这样的一个技术，就谁也不能 charge

00:29:44.289 --> 00:29:46.016
钱了，因为它就是一个免费的东西。

00:29:46.016 --> 00:29:48.699
就像 Internet 现在这个技术基本就是

00:29:48.699 --> 00:29:51.339
免费的东西，也有可能变成这个样子。

00:29:51.339 --> 00:29:55.739
终于 OK。好，我们这期 harness 就先聊到这里。

00:29:55.739 --> 00:30:00.266
然后我们说两个上周发生的事情，我可以

00:30:00.266 --> 00:30:03.915
先来。我先说的一个事就是打脸。我们其实

00:30:03.915 --> 00:30:07.962
之前没过两期聊到 OpenRouter，它就被

00:30:07.962 --> 00:30:12.532
Stripe 天价收购了，我们说它没有护城河，

00:30:12.532 --> 00:30:17.179
然后啪啪打脸，所以这个还是蛮有趣的。

00:30:17.267 --> 00:30:20.723
确实是，没有护城河也能卖六个 billion。

00:30:20.723 --> 00:30:23.747
比如说你有 volume 对吧、有用户，我觉得

00:30:23.747 --> 00:30:26.197
就可以。但是我也是瞎猜测，就是说毕竟

00:30:26.197 --> 00:30:29.803
你看他们的 business model 很像，就是说

00:30:29.803 --> 00:30:32.568
都是做这种平台中枢型的东西对吧，

00:30:32.568 --> 00:30:36.398
然后集散。只不过 Stripe 并没有说是

00:30:36.398 --> 00:30:39.359
在核心的这个 GenAI 的赛道，它通过

00:30:39.359 --> 00:30:41.974
这个可能也就是说拓宽了它这个赛道，

00:30:41.974 --> 00:30:45.631
并且可以 diversify 它的 business。

00:30:45.631 --> 00:30:47.905
我觉得可能还是这个 Stripe 比较

00:30:47.905 --> 00:30:52.072
desperate，他就是想要讲一个 AI 的 story，

00:30:52.072 --> 00:30:55.676
然后也是找了一个这么一个非常 unique、

00:30:55.676 --> 00:30:57.789
像你说的一种非常契合的一个东西，

00:30:57.789 --> 00:31:00.241
他们作为其入口。相当于就是花六个

00:31:00.241 --> 00:31:03.338
billion 买一个机会，说不定这个

00:31:03.338 --> 00:31:06.191
下个季度财报就把这钱挣回来了。

00:31:06.191 --> 00:31:10.831
可以看看他们怎么去运行。

00:31:10.831 --> 00:31:13.451
咱们如果是到时候他们 CEO

00:31:13.451 --> 00:31:15.451
上来讲这事，咱们会回答。

00:31:17.583 --> 00:31:21.497
然后我可能要讲的话，就是这周的话

00:31:21.497 --> 00:31:27.112
NVidia 宣布他们要投入 6 个 billion，

00:31:27.112 --> 00:31:30.775
这是真金白银 6 个 billion 去做 open

00:31:30.775 --> 00:31:34.117
weights model。他们的口号要做最好的 US

00:31:34.117 --> 00:31:38.177
的 open weight model，我觉得这个让我看到

00:31:38.177 --> 00:31:41.663
还是挺振奋人心的。然后连着这个的话，

00:31:41.663 --> 00:31:43.708
说不定他们下一步就会 launch 一个

00:31:43.708 --> 00:31:45.943
Nvidia 版本的 harness system 给大家用。

00:31:45.943 --> 00:31:47.218
有可能，有可能。

00:31:47.218 --> 00:31:49.469
我觉得还蛮看好的，因为之前还有不少

00:31:49.469 --> 00:31:52.288
的谷歌的同事都跑到了 NVidia，对。

00:31:52.288 --> 00:31:54.647
然后包括他们的一个 Infra 啊、

00:31:54.647 --> 00:31:57.527
Training 啊，对，所以还挺拭目以待的。

00:31:57.527 --> 00:31:59.825
现在我们用 Nemotron 体验就特别好。

00:31:59.825 --> 00:32:02.872
现在我们有个 Spark 那个机器，DGX 的 Spark，

00:32:02.872 --> 00:32:06.271
那个机器跑那个千问 3.8，就比那个那个

00:32:06.271 --> 00:32:10.767
Nemotron 慢很多，就慢将近 10 倍左右。

00:32:10.767 --> 00:32:13.567
好的，我们这期就聊到这里，大家拜拜。

00:32:13.567 --> 00:32:14.567
拜拜。