WEBVTT

00:00.100 --> 00:01.760
大家好,我是为什么叫QQ

00:01.760 --> 00:05.100
Resell最近发布了一个全新的开源Agent框架

00:05.100 --> 00:05.660
EVE

00:05.660 --> 00:07.640
官方给它的定位极其嚣张

00:07.640 --> 00:09.500
Agent领域的NextDNJs

00:09.500 --> 00:11.740
你可能会想现在市面上的Agent

00:11.740 --> 00:13.880
框架没有100也有80个了

00:13.880 --> 00:15.720
从Line Chain到AutoGen

00:15.720 --> 00:18.180
从MetaGPT到CrewAI

00:18.180 --> 00:20.320
Resell凭什么敢喊出这种口号

00:20.320 --> 00:22.200
难道又是一个套壳的玩具

00:22.200 --> 00:25.180
但当我仔细扒了它的原码和架构设计后

00:25.180 --> 00:26.840
我发现事情没那么简单

00:27.000 --> 00:29.900
这个框架可能会彻底改变我们写Agent的姿势

00:29.900 --> 00:32.340
如果你在过去一年里写过Agent

00:32.340 --> 00:35.740
你一定体会过那种被手搓基建支配的恐惧

00:35.740 --> 00:37.240
写一个demo很简单

00:37.240 --> 00:38.560
调个API写断

00:38.560 --> 00:40.260
Prompt跑个Python脚本

00:40.260 --> 00:42.200
一个简单的Agent就跑起来了

00:42.200 --> 00:44.400
但推到生产环境就不一样了

00:44.400 --> 00:46.220
你需要自己做持久化

00:46.220 --> 00:47.900
Agent可能会运行好几天

00:47.900 --> 00:49.180
中间网络断了怎么办

00:49.180 --> 00:50.660
Agent状态丢了吗

00:50.660 --> 00:52.080
对话历史没了吗

00:52.080 --> 00:53.480
你得自己处理这些

00:53.480 --> 00:54.680
然后是沙香隔离

00:54.980 --> 00:57.820
AI生成的代码不能直接跑在业务服务器上

00:57.820 --> 00:59.600
万一Agent写了个RM

00:59.600 --> 01:00.400
RF

01:00.400 --> 01:01.700
这样的命令怎么办

01:01.700 --> 01:02.580
谁负责

01:02.580 --> 01:04.200
还要自己接Slack

01:04.200 --> 01:04.820
接丁丁

01:04.820 --> 01:05.760
接企业内部系统

01:05.760 --> 01:07.740
甚至还要自己写一套审批流

01:07.740 --> 01:09.420
防止Agent的自作主张

01:09.420 --> 01:10.840
把生产数据库给删了

01:10.840 --> 01:12.380
这些脏活累活

01:12.380 --> 01:14.320
跟Agent的核心业务逻辑

01:14.320 --> 01:15.600
半毛钱关系都没有

01:15.600 --> 01:18.700
但你需要花80%的时间去搞定它们

01:18.700 --> 01:19.380
这合理吗

01:19.380 --> 01:21.240
其实现在的Agent开发

01:21.240 --> 01:22.540
就特别像当年

01:22.540 --> 01:24.600
没有Next.js时的Web开发

01:24.600 --> 01:27.180
大家都在疯狂地重复造轮子

01:27.180 --> 01:30.320
拼凑各种路由 打包工具和状态管理

01:30.320 --> 01:32.740
每个团队都在写自己的一套脚手架

01:32.740 --> 01:35.400
Rissel这次搞出Eve的思路非常明确

01:35.400 --> 01:37.960
不要让开发者再去拼凑零件了

01:37.960 --> 01:40.000
我把生产环境需要的所有基建

01:40.000 --> 01:41.160
直接打包送给你

01:41.160 --> 01:44.000
而且它用了一个极其讨巧的设计理念

01:44.000 --> 01:45.200
文件系统优先

01:45.200 --> 01:46.440
File System First

01:46.440 --> 01:49.320
就像Next.js把目录变成了路由一样

01:49.320 --> 01:51.400
Eve把目录变成了Agent

01:51.400 --> 01:53.980
接下来我们从工程落地的视角

01:53.980 --> 01:56.840
硬核拆解一下Eve到底解决了哪些痛点

01:56.840 --> 01:58.360
文件系统及Agent

01:58.360 --> 02:01.700
在Eve里你不需要写一堆复杂的注册代码

02:01.700 --> 02:03.240
一个目录就是一个Agent

02:03.240 --> 02:05.840
你的Agent.ts用来配模型

02:05.840 --> 02:08.460
Instructions.md就是系统提示词

02:08.460 --> 02:09.820
你想加个工具

02:09.820 --> 02:12.740
直接在Tools目录下建个TypeScript文件

02:12.740 --> 02:14.580
文件名就是工具名

02:14.580 --> 02:17.360
Eve会在构建时自动发现它

02:17.500 --> 02:20.700
比如你建一个Tools.run下滑线SQL.ts的文件

02:20.700 --> 02:22.840
里面有Zo的定义输入Schema

02:22.840 --> 02:25.540
Eve就会自动把这个工具暴露给模型

02:25.540 --> 02:28.280
模型可以直接调用RunSQL

02:28.280 --> 02:30.320
不需要任何额外的注册步骤

02:30.320 --> 02:31.780
你想教它个新技能

02:31.780 --> 02:33.260
在Skills目录下

02:33.260 --> 02:34.180
Deal个Markdown

02:34.180 --> 02:36.660
模型在需要的时候会自动加载

02:36.660 --> 02:37.960
比如你有个Skills

02:37.960 --> 02:38.720
Revenue

02:38.720 --> 02:39.840
Definitions

02:39.840 --> 02:40.840
.md

02:40.840 --> 02:43.840
里面写着收入是扣除退款后的金额

02:43.840 --> 02:46.320
按周统计周一为起点

02:46.320 --> 02:47.300
这样的业务规则

02:47.300 --> 02:49.660
当用户问上周收入多少时

02:49.660 --> 02:51.580
模型会自动加载这个技能

02:51.580 --> 02:53.500
确保回答符合公司的定义

02:53.500 --> 02:55.080
这种设计太直觉了

02:55.080 --> 02:57.820
你一眼扫过去就能知道这个agent是干嘛的

02:57.820 --> 02:58.980
能用什么工具

02:58.980 --> 02:59.820
有什么技能

02:59.820 --> 03:02.640
它消除了传统框架里那种到处注册

03:02.640 --> 03:04.800
到处引用的意大利面条代码

03:04.800 --> 03:07.780
这极大的降低了团队协作时的认知负担

03:07.780 --> 03:09.540
新人上手也快得多

03:09.540 --> 03:11.720
你不需要学习一堆复杂的API

03:11.720 --> 03:13.680
只需要理解目录结构就行了

03:13.680 --> 03:15.880
开箱即用的生产机基建

03:15.880 --> 03:18.040
这才是EV最核心的杀手键

03:18.040 --> 03:20.280
它底层集成了Workflow SDK

03:20.280 --> 03:21.480
这意味着什么

03:21.480 --> 03:24.460
意味着你的agent是自带持久化执行的

03:24.460 --> 03:27.080
每一步操作都会被checkpoint记录下来

03:27.080 --> 03:29.300
EV把绘画做成checkpointed workflow

03:29.300 --> 03:31.520
已完成的步骤会记录结果

03:31.520 --> 03:32.220
不会重跑

03:32.220 --> 03:33.420
崩溃或部署后

03:33.420 --> 03:35.220
可以从已确认的步骤继续

03:35.220 --> 03:37.780
遇到人工审批或等待后续消息时

03:37.780 --> 03:39.960
Session可以暂停不消耗计算资源

03:39.960 --> 03:43.080
这解决了一个agent的开发中最头疼的问题

03:43.080 --> 03:44.860
状态管理想象一个场景

03:44.860 --> 03:48.240
你的agent在处理一个复杂的数据分析任务

03:48.240 --> 03:50.280
它需要先从数据库查询数据

03:50.280 --> 03:52.560
然后调用一个外部API做分析

03:52.560 --> 03:53.520
最后生成报告

03:53.520 --> 03:54.860
在传统框架里

03:54.860 --> 03:57.460
如果在第二部API调用时网络断了

03:57.460 --> 03:59.260
整个任务就得重新开始

03:59.260 --> 04:01.560
在EV里已完成的第一步会被记录

04:01.560 --> 04:03.860
网络恢复后直接从第二部继续

04:03.860 --> 04:05.220
但这里有个重要细节

04:05.220 --> 04:07.440
如果某个Tool在执行中被打断

04:07.440 --> 04:08.680
这一步可能会重跑

04:08.680 --> 04:10.280
所以调用外部系统时

04:10.280 --> 04:11.660
你要么做好密等设计

04:11.660 --> 04:13.040
要么加上人工审批

04:13.040 --> 04:14.740
这样才能保证数据一致性

04:14.740 --> 04:16.360
安全问题他也想好了

04:16.360 --> 04:17.820
这里要注意一个细节

04:17.820 --> 04:20.360
EV把agent的生成和执行的代码

04:20.360 --> 04:21.720
放进独立sandbox

04:21.720 --> 04:24.300
包括shell命令脚本和文件读写

04:24.300 --> 04:25.920
但开发者定义的tools

04:25.920 --> 04:27.620
运行在应用run time中

04:27.620 --> 04:30.220
可以通过ctx.getsandbox

04:30.220 --> 04:31.200
调用沙箱

04:31.200 --> 04:33.620
所以安全边界不是绝对的隔离

04:33.620 --> 04:35.200
而是靠窄工具设计

04:35.200 --> 04:38.300
权限控制审批和密等设计一起完成的

04:38.300 --> 04:40.560
EV支持多个sandbox后端

04:40.560 --> 04:42.700
在生产环境用versail sandbox

04:42.700 --> 04:45.320
本地开发可以用darker micro sandbox

04:45.320 --> 04:46.140
或纯bash

04:46.140 --> 04:47.440
这样的分层设计

04:47.440 --> 04:49.380
让你既能灵活调用业务系统

04:49.380 --> 04:51.960
又能隔离AI生成的不可信代码

04:51.960 --> 04:54.660
极简的human indial loop和多渠道分发

04:54.660 --> 04:56.300
在EV的工具定义里

04:56.300 --> 04:58.700
加个人工审批简直不要太简单

04:58.700 --> 05:00.940
只要加一行needs approval判断

05:00.940 --> 05:03.340
比如发现SQL查询超过50G

05:03.340 --> 05:05.260
Bagent就会自动停下来

05:05.260 --> 05:06.780
等你点个头它才继续

05:06.780 --> 05:10.180
这解决了企业对agent行为失控的终极恐惧

05:10.180 --> 05:12.200
当agent要执行一个会扫描

05:12.200 --> 05:14.560
超过50GB数据的查询时

05:14.560 --> 05:17.200
系统会自动暂停等待人工审批

05:17.200 --> 05:20.360
这种细利度的控制是传统框架很难做到的

05:20.360 --> 05:21.860
同一个agent的代码库

05:21.860 --> 05:24.340
加个slack.ts就能接入slack

05:24.340 --> 05:26.680
加个discord.ts就能接discord

05:26.680 --> 05:28.320
核心逻辑完全不用改

05:28.320 --> 05:31.200
这才是真正意义上的write once run anywhere

05:31.200 --> 05:33.440
定时任务则放在schedules下

05:33.440 --> 05:35.720
用chrome表达式触发同一个agent

05:35.720 --> 05:38.680
你可以用同一个agent处理多个平台的请求

05:38.680 --> 05:40.600
比如你的数据分析agent

05:40.600 --> 05:42.220
可以在slack里回答问题

05:42.220 --> 05:44.740
也可以通过API被其他系统调用

05:44.740 --> 05:47.280
还可以通过定时任务每周生成报告

05:47.280 --> 05:49.380
所有这些都用同一份代码

05:49.380 --> 05:51.100
但这里有个很离谱的地方

05:51.100 --> 05:54.160
很多人觉得用这种高度封装的框架

05:54.160 --> 05:56.340
会失去对底层逻辑的控制力

05:56.340 --> 05:57.480
觉得它太重了

05:57.480 --> 05:59.020
其实你理解错了

05:59.020 --> 06:00.500
EVE的重是重在

06:00.500 --> 06:04.040
他帮你兜底了那些最容易出bug的基建层

06:04.040 --> 06:05.600
他把脏活包揽了

06:05.600 --> 06:07.440
反而释放了你的精力

06:07.440 --> 06:08.920
让你能真正去思考

06:08.920 --> 06:11.540
这个agent到底该怎么解决也有问题

06:11.540 --> 06:12.960
在过去的框架里

06:12.960 --> 06:14.960
你花大量时间在写连接器

06:14.960 --> 06:16.460
写重视逻辑

06:16.460 --> 06:17.420
写状态机

06:17.420 --> 06:18.500
而在EVE里

06:18.500 --> 06:20.580
你只需要关心两件事

06:20.580 --> 06:22.180
你要给agent什么指令

06:22.180 --> 06:23.180
你要给他什么工具

06:23.180 --> 06:25.160
而且EVE并不是一个黑盒

06:25.160 --> 06:26.720
它是完全开源的

06:26.720 --> 06:28.660
基于APACHE 2.0许可证

06:28.660 --> 06:30.700
你可以看到所有的原代码

06:30.700 --> 06:32.020
可以自定义任何部分

06:32.020 --> 06:34.540
如果你需要特殊的sandbox后端

06:34.540 --> 06:36.100
你可以写自己的适配器

06:36.100 --> 06:38.180
如果你需要特殊的渠道集成

06:38.180 --> 06:39.900
你可以用Define Channel自己写

06:39.900 --> 06:42.000
所以EVE不是限制你的自由

06:42.000 --> 06:43.980
而是给你一个坚实的基础

06:43.980 --> 06:45.880
让你可以在上面自由地构建

06:45.880 --> 06:49.260
所以EVE给我们带来了一个非常重要的认知升级

06:49.260 --> 06:51.200
agent不再是一段脚本

06:51.200 --> 06:52.760
而是一个系统工程

06:52.760 --> 06:55.200
一个真正能落地的企业级agent

06:55.200 --> 06:58.460
它的核心竞争力不在于你用了多牛的prompt

06:58.460 --> 07:00.180
而在于你有没有一套稳定

07:00.180 --> 07:02.800
安全可追溯的工程脚手架

07:02.800 --> 07:05.100
EVE其实是在用工程化的手段

07:05.100 --> 07:07.680
却对抗大模型本身的不确定性

07:07.680 --> 07:10.820
它把大模型包装成了一个可靠的工程组件

07:10.820 --> 07:14.340
这才是它自称agent领域的nextdngs的底气

07:14.340 --> 07:16.040
让我给你举个具体的例子

07:16.040 --> 07:19.200
假设你要为一个电商公司构建一个客服agent

07:19.200 --> 07:22.400
这个agent需要查询订单信息处理退货申请

07:22.400 --> 07:25.240
在slack和webchat两个渠道同时运行

07:25.240 --> 07:27.000
每天生成一份客服报告

07:27.000 --> 07:28.980
用传统框架你需要自己

07:28.980 --> 07:31.420
写数据库连接和查询逻辑

07:31.420 --> 07:34.660
自己实现状态管理确保退货申请不会丢失

07:34.660 --> 07:36.520
自己写两个渠道的适配器

07:36.520 --> 07:38.820
自己实现定时任务和报告生成

07:38.820 --> 07:41.380
自己处理错误恢复和日志追踪

07:41.380 --> 07:43.540
这可能需要几周的开发时间

07:43.540 --> 07:45.540
用eve你只需要在tools query

07:45.540 --> 07:47.700
orderts里写个查询函数

07:47.700 --> 07:50.040
在tools process下划线refund

07:50.040 --> 07:52.300
ts里加个nextapproval标记

07:52.300 --> 07:54.740
在channels目录下加两个文件

07:54.740 --> 07:57.420
在schedule s目录下加个定时任务

07:57.420 --> 07:59.300
整个过程可能只需要几天

07:59.300 --> 08:01.660
而且意味会自动处理持久化

08:01.660 --> 08:04.720
错误恢复日志追踪等所有的基建工作

08:04.720 --> 08:06.220
Rissell内部的应用实践

08:06.220 --> 08:07.640
Rissell公开提到

08:07.640 --> 08:10.840
他们在生产环境运行100多个基于eve的agent

08:10.840 --> 08:13.300
其中包括D0数据分析agent

08:13.300 --> 08:15.240
每月处理3万多个分析问题

08:15.240 --> 08:18.480
还有销售线索agentathena销售cockpit

08:18.480 --> 08:20.300
Vertex支持agent

08:20.300 --> 08:22.940
Draft0内容agent和Vluoagent等

08:22.940 --> 08:25.240
这些都是真实的生产级应用

08:25.240 --> 08:28.360
说明eve的持久化执行sandbox隔离

08:28.360 --> 08:31.680
Human in the loop和多渠道能力已经经过验证

08:31.680 --> 08:33.760
这些agent的共同特点是

08:33.760 --> 08:36.220
他们都需要处理长期运行的任务

08:36.220 --> 08:40.060
调用多个外部系统在关键操作前获得人工确认

08:40.060 --> 08:42.100
这正是eve设计的核心场景

08:42.100 --> 08:44.160
未来随着模型能力的提升

08:44.160 --> 08:46.540
agent的业务逻辑会越来越复杂

08:46.540 --> 08:48.580
多agent的编排会成为常态

08:48.580 --> 08:51.240
一个主agent带着一群子agent的干活

08:51.240 --> 08:54.220
eve这种约定优于配置自带基建的模式

08:54.220 --> 08:56.420
给出了一个很有参考价值的方向

08:56.420 --> 08:57.560
需要说明的是

08:57.560 --> 09:00.480
eve当前仍处于public preview阶段

09:00.480 --> 09:02.060
官方文档明确说

09:02.060 --> 09:05.040
API文档和行为在GA前可能会变化

09:05.040 --> 09:08.020
但这不妨碍它成为一个有影响力的设计参考

09:08.020 --> 09:11.320
Rissel把agent的工程化问题收敛到文件系统

09:11.320 --> 09:13.900
Workflow Sandbox Channel和Evos这几个约定里

09:13.900 --> 09:15.980
这个思路本身就很值得借鉴

09:15.980 --> 09:17.480
eve的开源属性

09:17.480 --> 09:19.820
意味着社区会不断贡献新的工具

09:19.820 --> 09:21.100
新的技能

09:21.100 --> 09:22.060
新的集成

09:22.060 --> 09:24.320
随着更多团队的时间和反馈

09:24.320 --> 09:25.880
这个框架会不断完善

09:25.880 --> 09:28.000
最后让我分享一些eve的最佳实践

09:28.000 --> 09:29.700
写好你的instructions

09:29.700 --> 09:30.860
instructions

09:30.860 --> 09:32.880
md是agent的大脑

09:32.880 --> 09:35.780
好的instructions应该清晰具体有约束

09:35.780 --> 09:38.700
不要写你是一个有帮助的助手这样的废话

09:38.700 --> 09:40.960
要写你是一个数据分析师

09:40.960 --> 09:43.740
你的工作是回答关于公司数据的问题

09:43.740 --> 09:45.540
优先使用精确的数字

09:45.540 --> 09:46.420
而不是估计

09:46.420 --> 09:48.840
如果你不能从数据中得出答案

09:48.840 --> 09:49.540
就直说

09:49.540 --> 09:51.000
精心设计你的tools

09:51.000 --> 09:53.320
每个tool应该做一件事并且做好

09:53.320 --> 09:54.780
不要设计一个超级tool

09:54.780 --> 09:55.620
什么都能做

09:55.620 --> 09:58.340
而且tool的输入输出要清晰

09:58.340 --> 10:00.000
用zod定义scammer

10:00.000 --> 10:01.380
让模型知道怎么调用

10:01.380 --> 10:02.960
用skills来教导agent

10:02.960 --> 10:04.820
skills是markdown文件

10:04.820 --> 10:06.680
用来教导agent的如何做事

10:06.680 --> 10:08.380
比如你可以写一个

10:08.380 --> 10:09.520
skillshowto

10:09.520 --> 10:13.540
-write-good-sequel-md

10:13.540 --> 10:14.600
里面写着

10:14.600 --> 10:18.540
写sql时要避免n加1查询这样的建议

10:18.540 --> 10:20.460
当agent需要写sql时

10:20.460 --> 10:22.180
他会自动加载这个skill

10:22.180 --> 10:24.180
充分利用human in the loop

10:24.180 --> 10:25.920
不要让agent的完全自主

10:25.920 --> 10:28.300
对于重要的操作加上审批流

10:28.300 --> 10:30.120
这不仅提高了安全性

10:30.120 --> 10:31.660
也提高了用户的信任度

10:31.660 --> 10:32.740
监控和追踪

10:32.740 --> 10:36.000
eve生成的open telemetry追踪非常详细

10:36.000 --> 10:37.540
充分利用这些信息

10:37.540 --> 10:38.860
来理解agent的行为

10:38.860 --> 10:40.560
定期审查追踪日志

10:40.560 --> 10:42.300
找出agent的问题所在

10:42.300 --> 10:43.220
总结一下

10:43.220 --> 10:45.140
别再手搓玩具agent了

10:45.140 --> 10:46.640
eve把企业机基建

10:46.640 --> 10:48.140
直接塞进了文件系统

10:48.140 --> 10:49.480
如果你也收购了

10:49.480 --> 10:51.120
天天修agent的底层bug

10:51.120 --> 10:52.940
真的建议去试一下eve

10:52.940 --> 10:55.120
那么你目前在开发agent的时

10:55.120 --> 10:57.540
遇到最头疼的工程化问题是什么

10:57.540 --> 10:59.320
把你的看法打在公屏上

10:59.320 --> 11:00.940
或者在评论区告诉我

11:00.940 --> 11:02.140
我是为什么叫QQ

11:02.140 --> 11:03.180
我们下期见

11:03.180 --> 11:04.500
别忘了长按点赞

11:04.500 --> 11:05.500
一键三连