套餐 1:全家享两千兆套餐,月租费 199 元(目前有活动打 7 折,长期有效),包含 220G 通用流量、60G 宝卡定向流量(包含很多 APP)、1000 分钟通话、2000 兆宽带(上行 200 兆),另外再加送一条 1000 兆宽带(1000/40)。FTTR 全屋覆盖一主一从。最多可以开 4 张 0.1 元月租副卡,共享主卡流量通话使用。

该套餐可以订购 9929 国际加速,每月 40 元,加载在主宽带或者副宽带上随意。

需要机顶盒可以送一年 IPTV 收视费减免,第二年开始每个月 9.9 元。

宽带安装费 100 元/路,新开用户需要预存 399 元,上海某动,上海某信携转可以免预存。

套餐 2:平价 300 兆套餐,月租费 59 元,包含 70G 通用流量、30G 宝卡定向流量、300 分钟通话、300 兆宽带(300/40)(每月+10 元可以升级 1000/40),最多可以开 1 张 0.1 元副卡,共享主卡流量通话使用。

宽带安装费 100 元/路,IPTV 如需开通 9.9 元/月。

新开上海联通号码或者上海某动/某信用户可以携转办理。

套餐 2 目前办理优惠活动:每月立减 10 元,综合优惠可以做到首年 59 元千兆,次年开始 69 元千兆,

联系 shunicom021 绿色联系 shunicom021

金仓数据库中包含各种数据库对象,常见的KingBase对象有:数据库、模式、表、索引、视图、存储过程、存储函数和触发器等等。这里将介绍金仓数据库中常见的数据库对象以及如何使用它们。视频讲解如下:
https://www.bilibili.com/video/BV1RQz3B9ERT/?aid=115930646454...

一、 数据库与模式

数据库本身也是一个KingBase的数据库对象。数据库对象中包含其他所有的数据库对象,如:模式、表、视图、索引等等。使用命令create database可以创建一个新的数据库,下面展示了该命令的格式:

CREATE DATABASE name
     [ WITH ] [ OWNER [=] user_name ]
           [ TEMPLATE [=] template ]
           [ ENCODING [=] encoding ]
           [ LC_COLLATE [=] lc_collate ]
           [ LC_CTYPE [=] lc_ctype ]
           [ TABLESPACE [=] tablespace_name ]
           [ ALLOW_CONNECTIONS [=] allowconn ]
           [ CONNECTION LIMIT [=] connlimit ]
           [ IS_TEMPLATE [=] istemplate ]

一个数据库包含一个或多个模式(Schema),模式中又包含了表、函数及操作符等数据库对象。创建新数据库时,KingBase会自动创建名为public的模式。使用命令create schema可以创建一个新的模式,下面展示了该命令的格式:

CREATE SCHEMA schema_name [ AUTHORIZATION role_specification ] [ schema_element [ ... ] ]
CREATE SCHEMA AUTHORIZATION role_specification [ schema_element [ ... ] ]
CREATE SCHEMA IF NOT EXISTS schema_name [ AUTHORIZATION role_specification ]
CREATE SCHEMA IF NOT EXISTS AUTHORIZATION role_specification

其中 role_specification 可以是:

    user_name
  | CURRENT_USER
  | SESSION_USER

在了解到数据库与模式的概念后,下面通过具体的操作来演示如何创建和使用它们。
(1)创建一个新的数据库dbtest。

scott=# create database dbtest;

(2)查看已存在的数据库列表。

scott=# \l

# 输出的信息如下:
                                        数据库列表
   名称    | 拥有者 | 字元编码 |  校对规则   |    Ctype    | ICU 排序 |     存取权限      
-----------+--------+----------+-------------+-------------+----------+-------------------
 dbtest    | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
 kingbase  | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
 scott     | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
 security  | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
 template0 | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | =c/system        +
           |        |          |             |             |          | system=CTc/system
 template1 | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | =c/system        +
           |        |          |             |             |          | system=CTc/system
 test      | system | UTF8     | zh_CN.UTF-8 | zh_CN.UTF-8 |          | 
(7 行记录)

(3)切换到数据库dbtest。

scott=# \c dbtest 
您现在以用户名"system"连接到数据库"dbtest"。

(4)查看数据库dbtest中的模式。

dbtest=# \dn

# 输出的信息如下:
       架构模式列表
       名称       | 拥有者 
------------------+--------
 anon             | system
 dbms_job         | system
 dbms_scheduler   | system
 dbms_sql         | system
 kdb_schedule     | system
 perf             | system
 public           | system
 src_restrict     | system
 sys_hm           | system
 sysaudit         | system
 sysmac           | system
 wmsys            | system
 xlog_record_read | system
(13 行记录)

# 这里的public的模式是创建数据库对象的默认模式。

(5)创建一个新的模式。

dbtest=# create schema firstschema;

(6)重新查看数据库dbtest中的模式。

dbtest=# \dn

# 输出的信息如下:
       架构模式列表
       名称       | 拥有者 
------------------+--------
 anon             | system
 dbms_job         | system
 dbms_scheduler   | system
 dbms_sql         | system
 firstschema      | system
 kdb_schedule     | system
 perf             | system
 public           | system
 src_restrict     | system
 sys_hm           | system
 sysaudit         | system
 sysmac           | system
 wmsys            | system
 xlog_record_read | system
(14 行记录)

二、 创建与管理表

表是一种非常重要的数据库对象。金仓数据库的数据都是存储在表中。KingBase的表是一种二维结构,由行和列组成。表有列组成,列有列的数据类型。下面通过具体的步骤来演示如何操作金仓数据库的表。这些操作包括创建表、查看表、修改表和删除表。

(1)创建一张新的表test2.

dbtest=# create table test2(id int,name varchar(32),age int);

# 由于创建表时没有指定模式的名称,因此表将创建在public模式下。
# 如果要在指定的模式下创建表,可以使用下面的语句:
dbtest=# create table firstschema.test2(id int,name varchar(32),age int);

(2)查看表的结构。

dbtest=# \d test2

# 输出的信息如下:
                    数据表 "public.test2"
 栏位 |            类型            | 校对规则 | 可空的 | 预设 
------+----------------------------+----------+--------+------
 id   | integer                    |          |        | 
 name | character varying(32 char) |          |        | 
 age  | integer                    |          |        | 

(3)在表中增加一个字段。

dbtest=# alter table test2 add gender varchar(1) default 'M';

# 这里增加了一个gender字段用于表示性别,默认是“M”。

(4)重新查看表的结构。

dbtest=# \d test2

# 输出的信息如下:
                         数据表 "public.test2"
  栏位  |            类型            | 校对规则 | 可空的 |     预设     
--------+----------------------------+----------+--------+--------------
 id     | integer                    |          |        | 
 name   | character varying(32 char) |          |        | 
 age    | integer                    |          |        | 
 gender | character varying(1 char)  |          |        | 'M'::varchar

(5)修改表将gender字段的长度改为10个字符。

dbtest=# alter table test2 alter gender type varchar(10);

(6)删除gender字段。

dbtest=# alter table test2 drop column gender;

(7)删除表test2。

dbtest=# drop table test2;

三、 在查询时使用索引

数据库查询是数据库的主要功能之一,最基本的查询算法是顺序查找(linear search)时间复杂度为O(n),显然在数据量很大时效率很低。优化的查找算法如二分查找(binary search)、二叉树查找(binary tree search)等,虽然查找效率提高了。但是各自对检索的数据都有要求:二分查找要求被检索数据有序,而二叉树查找只能应用于二叉查找树上,但是数据本身的组织结构不可能完全满足各种数据结构。所以在数据之外,数据库系统还维护着满足特定查找算法的数据结构。这些数据结构以某种方式指向数据,这样就可以在这些数据结构上实现高级查找算法。这种数据结构就是索引。金仓数据库官方对索引的定义为:索引(Index)是帮助KingBase高效获取数据的数据结构。索引是一种数据结构。金仓数据库默认的索引类型是B树索引。下图是一颗简单的B树,可见它与二叉树最大的区别是它允许一个节点有多于2个的元素,每个节点都包含key和数据,查找时可以使用二分的方式快速搜索数据。

image.png

在了解到了KingBase索引的基本知识以后,下面将通过具体的步骤演示来说明如何在KingBase中创建索引,并且在查询语句中使用它。
(1)查看scott数据库中部门表dept和员工表emp上的索引信息。

scott=# select index_name,index_type,table_name,status
        from user_indexes where table_name in ('DEPT','EMP');
        
# 输出的信息如下:
 index_name | index_type | table_name | status 
------------+------------+------------+--------
 DEPT_PKEY  | BTREE      | DEPT       | VALID
 EMP_PKEY   | BTREE      | EMP        | VALID
(2 行记录)

# user_indexes是一个视图,可以通过它获取某个用户创建的索引信息。

(2)使用create index命令在员工表emp的薪水sal字段上创建完全索引。

scott=# create index index_full on emp using btree(sal);

# 完全索引会基于该字段上的所有值创建索引。
# 同时,在创建索引的时候会进行锁表的操作,可以使用 CIC (create index concurrently),
# 但创建索引的时间相对较长。例如:
scott=# create index concurrently index1 on emp using btree(sal);

(3)下面的语句将在员工表上创建一个部分索引。

scott=# create index index_part on emp using btree(sal) where sal<3000;

# 部分索引是对于表的部分数据创建索引。
# 如果发现表的某一部分数据查询次数较多时,可以考虑在这部分数据上创建一个部分索引。
# 部分索引相较于完全索引,查询的性能将得到提高,并且部分索引文件所占的空间也会小于全索引。

(4)在员工表emp的员工姓名ename上创建表达式索引。

scott=# create index index_exp on emp(lower(ename));

# 对于表达式索引的维护代价比较高,因为在每一行插入或更新时需要重新计算相应表达式的值,
# 但是针对于表达式索引在查询时的效率更高,因为表达式的值会直接存储在索引中。

(5)使用explain语句查看SQL查询时的执行计划。

scott=# explain select * from emp where lower(ename) like 'king';

# 输出的信息如下:
                     QUERY PLAN                     
----------------------------------------------------
 Seq Scan on emp  (cost=0.00..1.21 rows=1 width=42)
   Filter: (lower((ename)::text) ~~ 'king'::text)
(2 行记录)

# 从输出的执行计划可以看出,此时并没有使用到表达式索引。
# 这是由于KingBase并不能强制使用特定的索引,或者完全阻止KingBase进行Seq Scan的顺序扫描。
# 但可以通过将参数enable_seqscan设置为 off的方式让KingBase尽可能避免执行某些扫描类型,
# 但这样的方式多用于开发和调试中。

(6)禁止金仓数据库使用顺序扫描。

scott=# set enable_seqscan = off;

(7)重新使用explain语句查看SQL查询时的执行计划。

scott=# explain select * from emp where lower(ename) like 'king';

# 输出的信息如下:
                              QUERY PLAN                              
----------------------------------------------------------------------
 Index Scan using index_exp on emp  (cost=0.14..8.16 rows=1 width=42)
   Index Cond: (lower((ename)::text) = 'king'::text)
   Filter: (lower((ename)::text) ~~ 'king'::text)
(3 行记录)

四、 使用视图简化查询语句

当SQL的查询语句比较复杂并且需要反复执行,如果每次都重新书写该SQL语句显然不是很方便。因此金仓数据库数据库提供了视图用于简化复杂的SQL语句。视图(View)是一种虚表,其本身并不包含数据。它将作为一个select语句保存在数据字典中的。视图依赖的表叫做基表。通过视图可以展现基表的部分数据;视图数据来自定义视图的查询中使用的基表。在金仓数据库中创建视图的基本语法格式如下:

CREATE [ OR REPLACE ] [ TEMP | TEMPORARY ] [ RECURSIVE ] [ FORCE ] VIEW name [ ( column_name [, ...] ) ]
    [ WITH ( view_option_name [= view_option_value] [, ... ] ) ]
    [ BEQUEATH { CURRENT_USER | DEFINER } ]
    AS query
    [ WITH { [ CASCADED | LOCAL ] CHECK OPTION } | READ ONLY ]

在了解的视图的作用后,下面通过具体的步骤来演示如何使用视图。
(1)基于员工表emp创建视图。

scott=# create or replace view view1
as
select * from emp where deptno=10;

# 视图也可以基于多表进行创建,例如:
scott=# create or replace view view2
as
select emp.ename,emp.sal,dept.dname
from emp,dept
where emp.deptno=dept.deptno;

(2)查看视图view2的结构。

scott=# \d view2

# 输出的信息如下:
                      视图 "public.view2"
 栏位  |            类型            | 校对规则 | 可空的 | 预设 
-------+----------------------------+----------+--------+------
 ename | character varying(10 char) |          |        | 
 sal   | integer                    |          |        | 
 dname | character varying(10 char) |          |        | 

(3)从视图中查询数据。

scott=# select * from view2;

# 输出的信息如下:
 ename  | sal  |   dname    
--------+------+------------
 MILLER | 1300 | ACCOUNTING
 CLARK  | 2450 | ACCOUNTING
 KING   | 5000 | ACCOUNTING
 SCOTT  | 3000 | RESEARCH
 JONES  | 2975 | RESEARCH
 SMITH  |  800 | RESEARCH
 ADAMS  | 1100 | RESEARCH
 FORD   | 3000 | RESEARCH
 WARD   | 1250 | SALES
 TURNER | 1500 | SALES
 ALLEN  | 1600 | SALES
 BLAKE  | 2850 | SALES
 MARTIN | 1250 | SALES
 JAMES  |  950 | SALES
(14 行记录)

(4)通过视图执行DML操作,例如:给10号部门员工涨100块钱工资。

scott=# update view1 set sal=sal+100;

# 并不是所有的视图都可以执行DML操作。在视图定义时含义以下内容,视图则不能执行DML操作:
# 1.  查询子句中包含distinct和组函数
# 2.  查询语句中包含group by子句和order by子句
# 3.  查询语句中包含union 、union all等集合运算符
# 4.  where子句中包含相关子查询
# 5.  from子句中包含多个表
# 6.  如果视图中有计算列,则不能执行update操作
# 7.  如果基表中有某个具有非空约束的列未出现在视图定义中,则不能做insert操作

(5)创建视图时使用WITH CHECK OPTION约束 。

scott=# create or replace view view3
as
select * from emp where sal<1000
with check option;

# WITH CHECK OPTION表示对视图所做的DML操作,不能违反视图的WHERE条件的限制。

(6)在view3上执行update操作。

scott=# update view3 set sal=2000;

# 此时将出现下面的错误信息:
# ERROR:  新行违反了视图"view3"的检查选项
# DETAIL:  失败, 行包含(7369, SMITH, CLERK, 7902, 1980/12/17, 2000, null, 20).

Matrix 首页推荐 

Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。 

文章代表作者个人观点,少数派仅对标题和排版略作修改。


回看西班牙旅行的时候突然感觉到倦怠。

我去的格拉纳达是大部分人不会花费超过两天停留的地方,我却留了五天,买了连续三天的阿尔罕布拉宫的门票,在不同时间进入就为了看到「最好」的时段、最好的阳光,留下最好看的照片。最后一天早上也像我之前的许多旅游一样,去机场前塞进一个离得远又不是最感兴趣的景点,匆匆看完后带着满身大汗跑去赶车赶飞机。

对我来说,这种程度的 FOMO1 已经有点超乎理解了——西班牙是政局稳定、离我近、消费也算便宜的目的地,但我却总想着「这个地方我没法再来所以这一次要全部看完」,实在是掺杂了太多不必要的焦虑。

加上当时看到了一些周末往返旅游的博主,于是心想:为什么不能试试呢?如果我在一座城市只有 8 小时的停留时间,我还会强逼自己把所有想看完的都看过再离开吗?于是断断续续定了一些周末单日往返旅行,开启了对这种旅行模式的探索。

具体操作

1. 城市选择篇

我的旅行习惯告诉我,我一天的有效游览时间大概是 5–6 个小时、2–4 个景点是比较舒服的模式。加上航班和往返机场的时间,附近飞行 2 小时以内的城市基本可以满足我的要求。我住在伦敦,所以对我来说最方便的就是去欧洲各国。

欧洲城市很多,但也不是每个城市都适合「一日游」的。小红书上虽然有很多贴文分享她们如何「一日游遍某个城市」,但我看了几篇后就发现他们的旅行逻辑和我不太一样——比如我无法想象怎么能一日游完罗马、雅典和巴塞罗那的——所以最后还是自己做了功课。

从我的旅行模式来说,最合适的城市就是:有 4–5 个最出名且我想看的景点,而且景点都在市中心较为聚集的地方,同时可以从伦敦直飞且单程时间在 2 小时以内。当然,也参考了机票价格和季节,最后我选择的城市是:巴黎、米兰、柏林、苏黎世、布鲁塞尔。

2. 机票机场篇

我大部分的机票买在 7 点左右出发,晚上 8-9 点左右到家,这样简单洗漱后也能保持在 11 点前入睡。找目的地是先去 FlightConnections 网站 上面找合适目的地,选择出发机场后就能筛选特定周几的可用机票、飞行时间、起降时间等等(需要会员)。如果已经确定了自己的最终目的地,在这个网站也可以很方便地对比当日的不同航班和机型,帮自己选出时间最合适的那一班。

找机票一般都在 Skyscanner(天巡网),并做航班比价。我倾向选择大航司、出发于成熟/大/商务机场。虽然廉航机票便宜,一日游也通常不会有行李超重的问题,但廉航比较容易出各种问题,比如超售、比如需要单独排队检查签证等等问题,偏远的小机场往往更容易出现交通问题,也很少会像商务机场那样有高级安检机器(不用拿出液体/充电宝之类的),可以做到 15 分钟速通。

选落地机场的考量主要是:机场游客来源,和它们去市中心的距离。

比如米兰有三个机场:马尔彭萨(Malpensa, MXP)、林纳特机场(Linate, LIN)、贝加莫机场(Bergamo, BGY)。MXP 的国际航班最多,也常因非欧盟护照入境排队动辄三小时而闻名小红书;而 LIN 和 BGY 的航班往往来自欧盟内部,机场规模更小,因此从入关排队的角度更合适。另一方面,MXP 去市中心知名景点需要火车转地铁,BGY 需要大巴转地铁,且基本都需要一小时以上;而 LIN 可以地铁直达,20 分钟即能到市中心。从这个角度而言,落地米兰选择 LIN 更合适,给 day trip 留出了更多探索城市的时间。

当然,欧洲的铁路业也十分发达,而且火车站的位置通常都在市中心交通方便的地方,如果价格合适也可以考虑。

选离境机场的考量包括了:交通时间,出海关排队时长,购物方便程度。交通问题和选落地机场的原则是一样的,都是为了尽可能延长在市区探索的时间。出海关排队时长也基本可以参考落地机场的排队情况,比如小红书避雷贴、官网信息(如果有自助出关闸口的话就会快很多;临近时间如果有很多去往非免签国的航班,也有更大可能在机场排队)。

【如图:苏黎世机场的安检时间预测,在 官网 选择自己要搭乘的航班后可以收到 WhatsApp 提醒。同样提供机场快速通道的还有柏林机场的 BER Runway

这些旅程里,我一半买的是全价票,一半用了积分换票。我会在购票前给机票价位设置一个心理底线(比如 BA 往返欧洲不超过 £120),超过那个底线的机票再去用积分换,整体而言会更划算。因为积分换票是按旺季/非旺季算的,但机票价格是根据供需关系浮动的,因此如果某天机票特别贵,但归属于航空公司划定的淡季的话,用积分兑换是更划算的做法。

查询英航积分票用 Reward Flight Finder 就能比较方便地看到不同仓位的余票情况

3. 随身行李篇

我第一次单日往返游之前,还会担心自己忘带东西而装了满满一包,后来经验多了就渐渐松弛下来,对照着行李清单检查一遍就能安心了。

单日往返最大的好处就是不用带替换衣物、洗漱包、充电的全套设备,我实践几次下来,每次必带的其实就是:

  • 护照
  • 手机(+备用手机),相机,充电宝
  • 一个塑料袋
  • 水瓶
  • 纸巾

其他的要么根本用不到,要么当地完全可以买到,所以不用担心这个问题。

考虑飞机安检要求,「一包走天下」是最高效的。如果你像我一样喜欢逛博物馆的话,在欧洲很重要的是:不要带双肩包。因为在很多博物馆/美术馆会要求寄存,容易带来一些不那么丝滑的体验。

欧洲风评在外,偷盗猖獗,我的解法是:选一个有内袋的外套,把护照和备用手机放在那里,接下来的旅程都能比较安心。其余的物品,只要确保相机随时都在就行,别的都没什么偷窃价值。

旅伴某种程度也算是随身行李的一部分,在此一并提了。

我尝试了两次和人一起一人游,结论是——「还是 solo 香!」

盖因对我来说,这种类型的旅行最重要的是「看完我想看的东西」,多日旅行中有更多时间余裕互相迁就,在单日旅游中就显得奢侈了。精力只能支持我最多看四个景点,和人一起去就只能看两个,也要考虑别人的饮食习惯,还不能通过 AA 酒店钱省开销……所以最后的结论就是:以看景点为主要目的的旅行没有必要找旅伴;以「陪朋友」的目的出去玩,朋友的存在就必不可少了。

4. 当地交通篇

能让我做到当日往返旅游的目的地,一般都会有和我常居地通用的支付方式。在欧洲,我的个人理解就是:Apple Pay 和 Google Maps 走天下。而且欧洲国家的优势在于,大多数市中心步行可达,哪怕办一张当地的 24h 交通卡,其实也省不下多少钱。

我去的大部分城市都可以用 Apple Pay 直接刷卡上车或者买车票,唯一需要注意的就是有些地方的实体票可能需要在机器上「打票」才能使用,不过所有旅行攻略都能查到这一点,不用太担心。

当然欧洲还是有一定比例的现金支付需求,可以带两个 €1 硬币以防万一。但没带的话也问题不大,因为通常有用卡的解法(比如工作人员突然掏出来一个 POS 机)、和工作人员交际就能解决的问题(比如看你可怜给你免费了)、找到中国人换钱。

我去的所有欧美城市,Google Maps 都有不错的覆盖率。我偶尔也会和 CityMapper 联用。这两个 app 现在基本都会告诉你这个车次的花费,路程中也会建议你去做哪部分的车厢离出站口更近。CityMapper 的好处是更新及时,公交车和地铁的时效性通常比 Google Map 好,整体而言能让旅行体验更丝滑。

如果从机场往返坐火车的话(ie 需要买点到点的票),我的经验是不要买往返票!因为上下车的地方可能不是同一个站,或许因为随机推荐去了离机场更近的地方,有更方便的交通方式。总之往返票省不了多少钱,但如果从最后一站真有更方便的路线的话,这个往返票反而是麻烦。

5. 旅行计划篇

我从前以为定好时间表、再按照时间表定时打卡是最高效的游览方式,实际体验中或许可以这么说,但时间压力会让我陷入在赶路情绪中不可自拔,反而是更大的压力,不能够完全沉浸旅游。如果带着目的去的(比如拍照出片),这样做是合适的,但如果首要目的是「感受城市」或者「看到想看的东西」,这就不适合了。

于是,现在我采用的方法是:排优先级。首先确定最想看的景点,并把精力体力最好的时间留给它(对我来说是早上刚落地后)。之后也会计划一些交通方便、或想看、或知名的景点,但都要等我看完最想看的那个之后,再根据交通情况、精力体力、心情决定要不要看。当然心里要有数,提前看好开馆时间、规划交通,尽量避免走回头路浪费时间。

另一个提升旅行体验的方法是,尽量穿插参观不同类型的目的地,比如「博物馆 → 公园 → 美术馆」的行程就比「博物馆 → 美术馆 → 公园」的行程更不容易审美疲劳。

在网上能很轻松地找到这种景点分布图,可以帮助更好地规划路线。图源:https://carolblog.tw/zurich/

有一些比较难定且入场时间卡得很紧的景点,如果定的时候已经没得选了那当然没办法,但如果还有一些选择的话,尽量先搞出当天的行程计划图,把这个景点放在时间和位置合适的地方(最好是当天第一场或者最后一场),会少一些压力……有些体验中途被打断,不得不去赶场去下一个更难定的景点,是非常不好的体验,而我暂时还没达到可以假装自己没抢到这张票的松弛感。

另一个建议是,尽量在冬令时到来之前完成行程,因为每天日照时间多,有更多时间探索城市。欧洲冬天的天气也会更不稳定,如果看到天气预报上说当天是阴天或下雨的话,尽量多安排室内景点,不下雨的时候(如有)再去体验城市氛围或者去户外享受自然风光。

伦敦日照时长图表。绿色竖线是夏令时起止日期。图源:https://www.timeanddate.com/sun/uk/london

6. 消费分析篇

综合了这么多次旅行的经验,我平均每次花费是 £225,其中机票花费 £77.35,当地交通 £19.16,食物 £53.95(正餐次均 £40.87,其余是零食和简餐),门票等 £45.56,购物(手信+礼物+话费等)£28.99。

我觉得这里面的固定花费很难再有压缩的空间了,比如虽然欧洲内部经常能蹲到 £50 左右的往返机票,但通常起降在去市中心不那么方便的地方,加上往返车票就没有价格优势了。当日往返的情况下,理论上也可以依靠步行和自带三明治省下吃饭和当地交通的钱,但省下来的钱必会以另一种方式偿还,比如时间和精力的折损,或者更波折的体验。也很难说有踩坑或者体验不好的部分,整体而言还算比较满意,所以我觉得再往下省是没有必要的事。

图上是从我家出发去各大机场的时间和花费表格,可以发现,如果机票省了 £20 但从 STN 出发的话,也相当于没便宜还倒贴

但这也并不是说,「单日往返」的旅行模式是经济上合算的——以我这几年在欧洲的单人短途游做参考,近似的消费水平下,加上住宿的日均花费大约 £180 左右,不包含住宿的日均消费是 £120 左右,和单日往返游没有什么区别。由此可见,欧洲内部的生活成本其实大差不差(。)

当然,选择当日往返旅行的主要目的也不是省钱。对我来说最大的收获是,能放下对「欧洲城市」的恐惧,。另一个便利则是省去了很多挑选酒店的纠结、比较、困扰,以及在出发前可以不用在意是否把家里门锁好、垃圾清空、水闸电闸关闭这种让人挂心的小事。

7. 精力管理篇

很多人一听到我每两周就要来一趟周末单日往返游,第一反应就是:「哇你的精力也太好了吧!」坦白讲,我 2025 年几乎没怎么进健身房锻炼,体力也不算特别出众。单日往返看着累,实际上也有很多可以让自己轻松一点的方法。

我比较确信的一点是,睡眠质量对我的体力精力有最大的影响。所以在每一场一日游前,我都要保证自己有至少连续三天的良好睡眠。具体行为包括但不限于:谢绝一切社交活动、拒绝加班、健康饮食、睡前 3 小时不吃东西,以及选择一个离得近的机场出发,这样哪怕坐早上七点的早班机,也不会太缺觉。

出于同样的考虑,我的返程航班也经常定在晚七点左右,这样也能确保自己到家的时候还来得及去健身房蒸个桑拿洗个澡,当天的入睡时间也不会太晚。

旅途过程中,对我来说最重要的是看想看的地方/东西,至于当地美食和购物都是可有可无。所以我通常只在飞机上吃一顿简餐,下了飞机直奔最想看的地方,既可以趁着时间早避开人流,也可以确保自己在看想看的东西时有最好的精力。看完最想看的两个景点后,找个地方吃一顿正餐,慢慢悠悠地回血了,再去看下午的计划的景点。

旅途前的规划也必不可少。比如从之前的旅行经验我大概能知道自己的能量上限就是「一天最多看三个景点」,所以在计划时不会给自己太大的压力。单日往返这个设定本身也在暗示我「这座城市你以后可以轻松地来很多次」,所以自然少了点「我必须全看完」的 FOMO。

就像在消费那一部分提过的,我不会在这类型的旅途中特别在意省钱,比如为了省 €3 选择走路半小时(一部分原因也是伦敦公共交通太贵,让我脱敏了),或者去需要排队买折扣票的景点。转场途中也是很好地给自己回血的机会,稳定的交通方式(如地铁、火车)本身也不容易占用太多情绪带宽,通常无需担心堵车、换乘、坐过站该怎么办。

最后,我大部分的旅行都只有周六一天,就给我留下了周日帮助自己回到日常 routine,买买菜、补补觉、修修图,就能非常容易地回到日常的工作生活状态中了。

旅途的背面

我在 9–12 月间共计划了五次欧洲短途旅行,其实到第三次已经有些倦怠,等到最后一次行程结束更是确信:这不是一个可以长期持续的旅行方式,将来如果不是去巴黎,应该不会再选择这样的旅行方式了。

原因其一是,这样快餐式的旅行并不能看到城市的全貌,而是只能停留在最游客的那些地方。欧洲的精华是世界旅行者的目的地,我想看的很多东西要么本身就是世界知名景点,要么就在知名景点周围,总是离不开那一片游客聚集的区域。能全程讲英语、蹭讲解固然方便,但总让我有种「根本没出国」的感觉。忍不住怀念起在西班牙用一周时间,从一句西语不会说、到可以和当地人进行简单西语对话,仿佛真的生活在那里的感觉还是大不一样。

原因其二是,欧洲的景点同质化太相似,短时间内多次频繁地看很容易腻。我还记得我在西班牙看到华丽的天主教堂无比震撼的时刻,比伦敦的圣保罗不知道华丽多少倍,每天都大饱眼福;等我在米兰和布鲁塞尔看教堂的时候,已经觉得「哦,挺厉害的但也就那样吧」;等我到了柏林大教堂的时候,已经无法被震撼了,只觉得「就这点东西你也敢收我门票?」对旅途的心情无益,更是折损热情。博物馆也是同理,看到最后画像和雕塑都觉得没什么区别,总觉得还不如坐地铁去看伦敦国家美术馆和泰特不列颠美术馆看画,后来专注于看东亚和埃及文物,总算有了点不一样的东西。

原因其三是,单日的可控性太差。一部分原因是我去的时候,欧洲已经进入秋冬,很容易遇到下雨或者阴天,导致旅行体验变差。想穿漂亮衣服,也会因为气温和天气而不太能同时满足特种兵、精简行李和精心打扮这三个条件。

原因其四是旅行的「后劲」。由于经常活动在游客区,而且周一前必须「收心」,沉浸感远不如多日旅行那么深刻。我的 FOMO 也转移到了拍摄上,花在修图上的时间可能比我在当地体验感受的时间还久,以至于提到某个城市,很难在脑中描绘出具体的景色,首先想到的是「我在这里有过一张照片」,而不太能回忆起取景框外的世界,真实的颜色、声音、气味、感受、脑中的想法。以至于去了这么多地方,年终总结看起来航线图还是厉害的,但脑子只是「如去」,在我看来有点违背了旅行的本心。

原因其五则是,这样高频、快节奏、高刺激的旅行模式也在重塑我大脑的神经回路,让我不停地在期待旅行、回味旅行、期待下一次旅行中横跳,以至于有连续三个周末没有安排什么事时,会觉得「居然周六就把菜买好了,好无聊不知道周末做什么」。又因为期待三周后的下一场旅行,有意选择性遗忘还需要我处理的各种生活事务,和工作之余的自我提升,直到所有计划的旅行结束后才捡起这烂摊子,训练自己重回原先的生活方式也花了一点时间。旅行不是逃避现实的解药,也不能像社交媒体上说的那样「帮我重拾生活的勇气」;对我来说,要直视问题,解决问题,要把旅行当成休息,而不是逃避、获得快乐和刺激的方法。

结语

开头说我这么高频次的短途旅行,是因为想要找个办法治治自己的 FOMO。后来在这么多次的旅行中,真的慢慢和 FOMO 和解了。

一日游中多去一个景点至少是 1h 的投入,随便加一个都太奢侈;而多日长途游的时候,景点间转移的时间常常到拉长至 2–3 小时,反倒还很容易觉得「快点收拾行李就赶得及」。时间有限了,做计划的阶段,反而能更快看明白,某个景点会出现在我的目的地清单中,到底是因为它真的有吸引我的地方,还是只是随手收藏一下。

其次,「当日往返」的行程会给我很强烈的心理暗示:「这个地方我还能轻松地来第二次」。我 FOMO 的原因之一就是「担心这个地方来不了第二次了,所以必须一次看完」,但这些旅行经验让我更加觉得「欧洲就是后花园一样的存在」,而我既有说走就走的精力和体力,也有计划各式各样旅途的能力。既然我过来这么轻松,以后何愁没有机会再来?

我真正需要有 FOMO 的地方反而是那些因为自然环境变化而即将消逝的自然景观、政局不稳定可能随时消失的地方,但这些都是我短期内没法放心自己去体验的地方。至少在欧洲,我想以后我都不会给自己太大的压力了。想想二十年后,还真是期待啊。

外篇

在此也分享一下我在这五座城市的旅行计划,供感兴趣者参考:

巴黎

时间行程评价
10:30巴黎歌剧院拍照好看
13:30埃菲尔铁塔值得一去
15:00凯旋门 + 香榭丽舍大街拍拍照可以
17:00卢浮宫(闭馆日,没进去)应该进去看

米兰

时间行程评价
10:00米兰大教堂登顶 + 内部 + 博物馆值得一去
15:00《最后的晚餐》值得一去

柏林

时间行程评价
11:00洪堡论坛值得花一天
14:00新博物馆值得看但体验差
16:00柏林大教堂来都来了

苏黎世

时间行程评价
10:30Museum Reitberg值得一去
15:30林登霍夫山随便逛逛
16:30ETH Zurich随便逛逛

布鲁塞尔

时间行程评价
10:00老城区闲逛 + 吃华夫饼来都来了
13:00圣弥额尔圣古都勒主教座堂还行吧
14:30比利时皇家美术馆值得一去
17:00原子塔 Atomium来都来了

> 关注 少数派小红书,感受精彩数字生活 🍃

> 实用、好用的 正版软件,少数派为你呈现 🚀

    这两年企业上移动ERP,很多时候不是“想升级”,而是被现实推着走:人在外面跑业务,单据在电脑里卡着;仓库要扫码盘点,结果还在纸上写;老板想看数据,最后只能等人导表。

    所以移动ERP系统这件事,本质上比的不是功能堆得多不多,而是谁能把高频动作放到手机上跑通。

    本文排行榜怎么排的

    1、我用的标准很直白,按“能不能真的用起来”来排:

    2、移动端是否能覆盖审批、开单、库存、对账等高频动作

    3、产品与厂商信息是否能在官网/官方应用商店核验

    4、是否有清晰的定位:更适合哪类企业、哪类业务模式

    5、落地成本是否可控:上线路径清晰,推广阻力别太大

    一、移动ERP系统排行榜 TOP 5

    1、支道

    支道更像“把业务系统当积木搭”的路线,不是那种固定菜单的传统ERP。

    它最打动人的点是:业务流程变了,系统也能跟着你改,不用每次都等开发排期。

    支道更适合哪类企业?一句话概括就是:流程不太标准、变化很快、跨部门协同靠人盯的团队。你不用一上来就“全上ERP”,更现实的做法是先跑通1-2条关键流程,然后逐步扩。

    支道常见落地方式可以按这种节奏走:

    (1)先做移动端待办与审批,把“卡在路上”的事打通

    (2)再把业务填报和单据录入搬到手机上,现场就能闭环

    (3)最后用报表与看板把数据收口,减少重复统计

    如果你最痛的是“Excel满天飞、版本对不上、事情靠催”,支道的思路通常更贴近现实:先把流程固化,再谈精细化管理。

    2、金蝶

    金蝶移动端的卖点写得很实在,官网直接列出一串高频动作:扫码开单、蓝牙打印、出入库、盘点调拨、库存分析等。

    如果你是“手机要能开单、仓库要能快速做动作”,金蝶这类路线通常更稳。

    适合场景也很清晰:

    (1)业务员:手机下单、跟进客户、交易管理

    (2)仓库:出入库、盘点、调拨

    (3)管理者:业绩、库存、经营数据随时看

    3、用友

    用友在移动端的主张也很明确:一个App管理所有应用系统,一键访问业务系统单据,移动快捷审批,实时处理业务。

    你们系统多、待办多、审批多,用友这类“统一入口”的价值就会更明显。

    更适合的企业画像:

    (1)组织层级较多,跨部门流程复杂

    (2)需要把多个系统的待办统一到手机端处理

    (3)希望移动端是入口,而不是“另一个孤岛”

    4、鼎捷

    鼎捷在制造业中小企业的定位很明确,它在“掌上易助”页面直接写:易助小程序,全面满足ERP用户移动化需求,并说明易助是面向中小微企业、涵盖制造全流程的ERP。

    小程序入口的好处很现实:推广阻力小,一线人员更愿意用。

    如果你是机械、五金、汽配、电子加工这类行业,鼎捷官方也明确写到易助ERP适用这些制造业场景,并涵盖财务、进销存、生产等管理范畴。

    5、网上管家婆

    网上管家婆移动端讲的是“手机开单、扫码出入库、欠款对账、数据看板”这种中小企业最常用的动作。手机开单、查询欠款、一键生成对账单并发送链接或二维码对账,扫码出入库与多方式盘点。

    如果你是商贸批零、电商网店,想要的是上手快、动作快,这类产品往往更省事。

    二、5款产品对比表

    三、最快的选型方法

    1、你们移动端最常干的三件事是什么

    (1)审批、开单、盘点

    (2)对账、收款、查库存

    (3)项目回填、工单处理

    2、你们流程到底变不变

    (1)经常变:优先看支道这种可配置能力强的路线

    (2)基本不变:优先看标准化更成熟的套件

    3、你们现有系统多不多

    (1)多系统并存:用友这类统一入口更省心

    (2)就一套进销存:金蝶、网上管家婆这类会更快落地

    四、结语

    移动ERP系统排行榜看一眼就好,真正决定成败的是:手机端能不能把你们最痛的那条流程跑通。如果你希望先把协同和流程跑顺、再逐步扩模块,支道放在第一位是合理的选择。

    Sulaiman Ghori 在一期播客中,用了一个多小时详细讲述了他在 xAI 的经历。他说,在那里“从来没有人对我说不”,每个人都被充分信任去做正确的事;只要是好想法,当天就能落地、当天就能得到反馈。他还提到,马斯克愿意被证明是错的,只要你能拿出实验数据。

     

    他也坦言,在上一家公司,很多事情也许他一个人能做得更快;但在 xAI,整体反而更快,因为几乎没有官僚流程。这些话,听起来都是对公司的认同和马斯克的赞扬,实际上他还说自己是马斯克粉丝。

     

    然后,播客发出来后第 3 天,他被解雇了。

     

    外界猜测是因为他说了太多敏感信息。节目中,他透露了利用闲置特斯拉汽车驱动的人类模拟器 AI 代理的计划、还有马斯克如何快速构建 Colossus 超级集群、xAI 在模型策略上的核心决策,曝光了公司内部部署测试的 AI 虚拟员工等,还有 xAI 也被完全曝光。他坦率地谈到了激进的时间表、马斯克亲自参与的 Cyber​​truck 奖金计划、内部文化和运营方式以及一些非公开的策略,这些言论引发了外界的强烈反响。

    经历被玩梗:如何在 1 小时内毁掉你的一生,对应了最近 x 的爆文“如何在 1 小时内修复你的一生”

     

    Sulaiman 自 2019 年起持续创业。在德国上大学一个月后退学,为了实现童年创办航天公司的梦想,在自家后院亲手制造过一台液体燃料火箭发动机。创业失败后,他进入 xAI。对于他的经历,有网友表示,“这位兄弟跑去上播客,没拿到明确授权,就顺手把一堆内部敏感信息抖出来,这就是纯纯的新手行为。可以说,这是职业生涯级别的大忌。任何一家严肃的公司都会立刻把你原地开除,更别说是像马斯克这样的人。”

     

    我们翻译并整理了他这期“超级爆料”的播客对话,并在不改变原意基础上进行了删减,以飨读者。

     

    在 xAI,事情永远是“昨天就该完成”

     

    主持人:今天我很高兴能和 Sulaiman Ghori 坐下来聊聊,他是 xAI 的一名工程师。我从 2023 年马斯克刚开始搞 xAI 的时候就一直很关注这家公司,感觉它可能是史上增长最快的公司之一。你能不能跟大家讲讲,现在 xAI 到底在发生什么?

     

    Sulaiman:说实话,我们几乎没有所谓的 deadline,永远都是“昨天就该完成”。基本没有什么人为障碍。马斯克一直强调要“追根溯源”,找到最底层、最根本的东西,不管是物理层面的还是其他的。我们通常会非常快地深入到那个层面,能多快就多快。

     

    这在软件行业其实挺有意思的,因为你平时不太会把硬件这件事放在心上,但我们确实花了很多精力去考虑这些。而且严格来说,我们现在也不完全算是一家纯软件公司了,毕竟基础设施的建设占了很大一部分。

     

    主持人:对,现在明显是被硬件限制住的。

     

    Sulaiman:没错。硬件可能是我们最大的优势之一,因为在部署能力上,几乎没有其他公司能接近我们。不过,软件方面的人才密度也高得惊人,我从来没在任何地方见过这样的团队。

     

    主持人:我觉得马斯克有一点特别厉害:他很擅长提前判断未来几个月、甚至几年后会出现什么瓶颈,然后从那个未来的瓶颈反推,确保自己现在就站在一个很好的位置上。这种思维方式在日常工作中是怎么影响普通工程师、AI 开发者的?

     

    Sulaiman:通常我们一旦要快速启动一个新项目,不管是我们还是他自己,都会先定一个指标。这个指标一般都非常核心,要么直接关系到财务回报,要么关系到硬件层面的产出,有时候两者都有。之后,所有事情都会围绕着这个指标来推进。而且我们不太接受那种“这事本来就不可能”的说法,就算真有极限,那也必须是一个扎根在最底层的、本质性的限制,而不是人为的。

     

    软件行业里,尤其是过去十年做 Web 开发的人,往往会默认、接受很多所谓的限制,比如速度、延迟之类的。但实际上这些限制很多都是假的。技术栈里有大量没必要的开销和“蠢东西”,如果你能把这些清掉,很多系统都能直接提升 2 到 8 倍,至少是那些相对比较新的东西。当然,也有些老东西确实不好动。

     

    主持人:你最近一次真正感受到“传统认知被彻底打碎”的经历是什么?

     

    Sulaiman:最近一次就是我们在 Macrohood 上做模型迭代。我们同时在做几种全新的架构,而且是并行推进的。现在我们几乎每天都会出新版本,有时候一天不止一次,有些甚至是从预训练阶段就开始重新来。这在业内其实非常少见。

     

    这背后有几个原因:第一,我们有一支非常强的超算团队,他们解决了很多训练过程中常见的障碍。即便我们的硬件环境变化很大,但通常一个机架搭好后,一天之内就能开始训练,有时候甚至几个小时就可以。

     

    主持人:这真的很不正常,一般不是都要好几天吗?

     

    Sulaiman:甚至好几周。过去十年里,大多数人都是把这些事情抽象掉,交给 Amazon、Google 去管,他们给你多少算力你就用多少。但在 AI 时代,这种方式是行不通的。要么你死掉,要么你自己把这些东西建出来。

     

    入职初体验:没人管,做模型和产品默认资源到位

     

    主持人:当初为什么加入 xAI,以及前几周入职体验怎样?

     

    Sulaiman:我当时刚搬到湾区,在做自己的创业项目。那段时间,xAI 的联合创始人之一 Greg Yang 主动联系了我。他真的很会招人。

     

    我一开始收到邮件的时候还以为是垃圾邮件,因为那时候我经常收到那种“嘿,想聊聊吗”“我很欣赏你做的事情”之类的邮件。正准备删掉的时候,看到发件人的域名是 xAI,我一下反应过来:等等,这不是那帮人吗?当时他们大概成立了八个月左右,我就答应先聊聊。我们聊了好几次,我本来还想再试试别的机会,但后来发现时机不太对。

     

    那个项目最后也没做下去,原因很明显:用一百万美元是不可能把 Macrohard 这种东西做出来的,但想法本身是对的。接下来六七个月,我基本是在烧钱,做各种航天相关的小项目,还试过一个“空气空间”相关的概念,后来也发现大概率行不通,但至少试过了。于是,我又给 Greg 发邮件,说能不能再聊聊。他直接回我:要不要明天面试?我说“好”。

     

    面试还算顺利,我周一就搬家,直接入职了。第一天真的没人管我,就给了我一台电脑和工牌。我当时想:那现在怎么办?我去找 Greg,说我连团队都没有,也没人告诉我该干嘛。他当初招我进来,更多是因为他认可我之前做的事情,也觉得和 Macrohard 的长期方向相关,但那时候 Macrohood 甚至还算不上一个正式项目。

     

    后来正好 Ask Grok 要启动,做和 X 的集成,他们问我能不能帮忙,我说当然可以。第一周我基本就是和另外一个人一起干活。但我很快意识到,在 xAI,你坐在工位上,甚至站起来一看,就能指着某个东西说:哦,这是那个人做的。这种感觉非常酷。而且我连固定工位都没有,就坐在当天没来的人桌子旁。

     

    主持人:那时候公司里人其实也不多吧?

     

    Sulaiman:对,大概也就几百人,工程团队一百来号人。基础设施团队具体多少人我也说不太清,因为有些人是从其他团队慢慢转到我们正式编制里的。但整体规模确实比其他实验室小个数量级。当时我们刚做完 Grok 3。

     

    主持人:真的很酷。我特别喜欢的一点是,xAI 从成立到现在的速度实在太夸张了。我记得马斯克一开始还说,不确定在别人已经领先好几年的情况下能不能成功。结果你们第一个 Colossus 数据中心 122 天就建完了,这在行业里几乎是不可想象的。这种速度塑造了一种怎样的文化?

     

    Sulaiman:他让我们在做模型和产品的时候,可以默认资源是到位的。事实也确实如此,我们并没有被资源严重卡住。

     

    当然,我们还是会把资源用到极限,但那是因为同时在推进二三十个、甚至更多事情。有大量训练任务并行跑着,通常是由少数几个人在推动。这也是为什么我们在模型和产品迭代上能这么快。而且这种速度让我们可以更长期地去思考。比如 Grok 4、Grok 5,其实在我加入之前、甚至 Grok 3 落地之前,规模和预期就已经设计好了。

     

    主持人:也就是说,至少提前一年在规划?

     

    Sulaiman:对,而且你能感觉到,这些预期大概率是能实现的,因为团队整体非常可靠。这就极大地解放了你的思维,让你不用老是纠结“我会不会做不到”。举个例子,我们之前假设的最低延迟,其实比真正需要的高了大概三倍,而基础设施的建设让我们可以做到这一点。

     

    主持人:这是什么意思?

     

    Sulaiman:我们在做的一种新架构,如果没有足够高的实验频率,基本是不可能推进的,因为它完全不建立在现有研究基础之上。你需要全新的预训练体系,也需要新的数据集。这本身并不完全受制于硬件资源,虽然也有一些因素,比如 Tesla 计算平台的问题。这个其实已经是公开的了。

     

    我们现在在想一件事:如果我们用 Macrohard 去做“人类模拟器”,那要怎么部署?如果要部署一百万个“人类模拟器”,就需要一百万台计算机,这怎么可能?

     

    结果两天后答案就出现了:Tesla 车载计算机。它的资本效率非常高,我们可以在上面跑模型,甚至跑一个完整的人类工作环境,成本比在 AWS、Oracle 的虚拟机上,甚至直接买 Nvidia 硬件都要低得多。这让我们可以假设:我们能以更快的速度、在更大的规模上部署。所以我们也相应调整了预期。

     

    主持人:也就是说,你们基本上可以直接利用汽车网络?

     

    Sulaiman:所以这其实是一种潜在的解决方案。简单来说,我们想要一百万个虚拟人(VMs)。仅在北美,就已经有大约 400 万辆特斯拉汽车。假设其中有三分之二,或者哪怕一半,已经配备了 Hardware 4。而且在 78% 到 80% 的时间里,这些车基本都是停在那里,要么闲置、要么在充电。那我们完全可以付费,让车主把车的算力时间“租”给我们。车本身已经有网络、有散热、有电力。我们可以直接在车上运行一个“人类模拟器”,也就是 Digital Optimus。这样一来,车主的租赁费用能被覆盖,我们这边则得到一个可以投入工作的完整人类模拟器。整个过程几乎不需要额外的基础设施建设,基本就是一个纯软件层面的方案。

     

    主持人:对,这个资产本来就放在那里,你们只是把它用起来了,太厉害了。那从宏观层面看,这种“人类模拟器”规模化到几百万个,它的目的是什么?

     

    Sulaiman:其实核心概念非常简单。Optimus 就是把人类能做的任何物理任务,让机器人自动完成,成本更低,而且可以 24×7 全天候运行。

     

    我们现在做的,是把这个逻辑复制到“数字世界”。凡是人类需要通过键盘、鼠标、看屏幕、做决策来完成的数字化工作,我们都可以直接去模拟人类的操作过程。完全不需要软件方做任何适配,也不需要改系统。只要现在有一个岗位是人类在用电脑做的,我们理论上都可以直接部署。

     

    主持人:挺有意思的。那具体会怎么推进、怎么落地呢?

     

    Sulaiman:我们还没公开详细的落地计划,整体来说会是先慢后快。对我们来说在于,要么基础设施已经建好了,要么我们可以直接用特斯拉的网络,或者自己扩数据中心、测试算力。实际上,从一千个“人类模拟器”扩展到一百万个,差别对我们来说并没有想象中那么大,这反而不是最难的部分。

     

    马斯克一个电话“救火”,个人“生死自负”

     

    主持人:马斯克最擅长的一件事,就是在公司里不断“救火”,哪里有问题就冲到哪里把问题解决掉。你有没有见过那种,本来是个大问题,但被他非常快地解决掉的情况?

     

    Sulaiman:有,最典型的就是基础设施建设,这是最大的一个。模型这边也有过一些小波折,但整体还算顺利。在模型侧,因为涉及很多非常底层、非常具体的算子,每一代 ASIC、CPU 都是为特定操作优化的,当我们引入新硬件,比如从 Nvidia 或其他厂商拿到新产品时,往往不是所有东西都能直接跑起来。

     

    去年年初有几次内部会议,他听到这些问题之后直接打了一个电话,第二天软件团队就给我们交付了补丁。我们几乎是并肩作战,直到问题解决,然后就能很快在新硬件上跑模型或训练任务,否则这种来回沟通可能要拖上好几周。

     

    所以很多这种“卡点”,真的就是一个电话就解决了。要么是我们主动提出来,要么他自己会问。经常在会议快结束、或者讨论暂时停顿的时候,他会突然来一句:“我能怎么帮忙?怎么能把这件事再加快一点?”然后就有人把问题抛出来。

     

    主持人:我知道你们在并行做很多不同的产品,这在一定程度上是必须的。但在大多数组织里,同时推进多个目标,其实很难保持专注。你们是怎么做到多线并行还能高效执行的?

     

    Sulaiman:说实话,很多时候,是在全员会议或者大家私下聊天时,我们才真正搞清楚每个人在做什么、各个项目进展到哪一步。

     

    比如,我们当时做语音模型和语音部署,其实很多极低延迟的端到端能力早就已经在系统里了,从数据包发到客户端那一整套链路都准备好了。后来只是把正确的开关打开、解决一些冲突,延迟就直接降了两三倍。

     

    这种情况非常常见:在软件或硬件某个角落里,存在一个“很蠢”的问题,而恰好已经有人想好了方案。你可能是在翻代码库的时候发现,或者随口问一句,有人就会说:“哦,这个 XYZ 已经搞定了,你去找他就行。”基本不需要花太多时间对齐、同步、请示。提出一个想法,反馈要么是“这想法不行”,要么是“那为什么还没做完?”然后你就直接去做,事情就这么推进了。

     

    主持人:在马斯克的公司里,好像你只要主动要责任,就得“生死自负”。事情做成了就担负更多责任,做不成可能就出局。你的体验是这样吗?

     

    Sulaiman:是的,基本就是这样。我参与过很多不同的项目,大多只是因为有人找我帮忙,我就一直帮下去。结果到最后,我就成了某个模块、甚至一大块系统的负责人。

     

    对所有人来说都是这样。如果你在某个领域有经验,或者能非常快地推进事情,几天之内,这个组件就归你负责了。从“正式流程”上看其实挺混乱的。我在 HR 系统里可能还是挂在 voice 和 iOS 名下,安全系统甚至还以为我在做 X 的集成,从来没人更新这些信息。

     

    主持人:也就是说,你进公司时并没有一个非常清晰的工作方向,就是先开始干活,然后不断在不同项目之间流动,谁需要你你就去哪?

     

    Sulaiman:差不多是这样,会有很多重叠和流动。入职之后,我通常同时参与两三个项目,哪个最紧急、或者我能帮上最多忙,就会占用我大部分时间。然后项目之间会像瀑布一样自然切换。

     

    主持人:那从入职到现在,你大概都做过哪些项目?

     

    Sulaiman:一开始我做的是 Ask Grok 以及相关集成,也和后端团队一起处理过可靠性和扩展性问题,当时系统规模增长得很快;之后我独立承担了桌面端套件的开发,把它做到内部可用的完整状;接着又被拉去帮做 Imagine 的发布,以及 iOS 相关工作。说真的,iOS 团队小得离谱,和用户规模完全不匹配,你绝对猜不到有多少人。

     

    主持人:五个?

     

    Sulaiman:三个。当时推出时,我正好是第三个。但大家都非常强。这是我第一次感觉到,自己必须拼命跑才能跟上整体的节奏和人才密度。

     

    主持人:那你第一次真正感觉到“自己被充分使用”的时刻是什么?

     

    Sulaiman:肯定是 Imagine 的那次发布。我们基本是 24 小时一个迭代周期:晚上收到反馈,当晚就改;第二天早上再看新一轮反馈,接着马上修 bug、加大家想要的新功能。模型这边有新变化,我们也立刻跟进。整个节奏非常快,那可能是我连续每天都在办公室待着时间最长的一段时期。

     

    主持人:那段时间持续了多久?

     

    Sulaiman:大概两三个月。那段时间几乎没有周末,但我反而挺开心的,也算验证了自己能扛住这种强度。之后我就被调去做 Macrohard 产品了,当时那边只有另一个人,一开始就我们俩。我从项目启动一直做到现在。

     

    疯狂推进度,马斯克直接送 Cybertruck

     

    主持人:关于 Colossus 的建设,我不知道你了解多少。早期 xAI 团队为了把 Colossus 跑起来,在供电、算力、各种基础条件上都做了很多“疯狂”的事。到现在,其实还是到处是瓶颈,总觉得还需要更多芯片、更多 GPU、更快的速度。你当时的感受是什么?

     

    Sulaiman:这一路上有太多“战争故事”,也下过不少赌注。

     

    主持人:挑几个讲讲吧。

     

    Sulaiman:好。我记得 Tyler 当时和马斯克打了个赌。我们在上新机柜的时候,具体是哪一代 GPU 我都忘了。马斯克说,“如果你能在 24 小时内用这些 CPU 跑起来一次训练,我今晚就送你一辆 Cybertruck。”结果那天晚上我们真的把训练跑起来了。

     

    主持人:他拿到了吗?

     

    Sulaiman:拿到了。现在从我们午餐的窗户望去就能看到那辆车,马斯克人挺酷的。

     

    说到供电,其实我们必须和市政、电力公司还有州一级的电力机构高度协同。因为当他们那边负载飙升时,我们就得立刻切断公共电网,全部切到自备电源上——大概是八十台,甚至可能更多,用卡车拉来的移动发电机。

     

    整个切换过程必须无缝完成,不能影响任何正在跑的训练任务。你要知道,那些训练极其不稳定,GPU 和硬件的功耗可以在毫秒级别上下波动,动辄就是几兆瓦。这件事本身就非常夸张。

     

    主持人:那是不是也是为什么你们会把巨型电池组直接放在数据中心旁边?这样负载上下波动就能更快响应?

     

    Sulaiman:对。没有电池的话,很难这么快地调整负载,发电机毕竟是物理设备,你是在让一个真实旋转的东西加速或减速,它天然就有时间延迟,电池的反应速度要快得多。从物理层面看,整个链路是:本地电容、数据大厅侧的电容、电池、发电机,最后才是公共电网。当然,这套架构我们现在可能也在不断调整,尤其是散热这块,反应速度必须非常快。

     

    主持人:你还有没有那种“本来不可能,但最后居然成了”的故事?

     

    Sulaiman:有。比如我们这块地的租约,从法律意义上讲其实是临时的。这样做是为了最快通过审批、尽快开工。我猜以后会转成永久的,但现在确实是短期租约。对数据中心来说,这是目前能把事情推进得最快的方式。

     

    主持人:他们是怎么允许这种操作的?

     

    Sulaiman:算是一种地方和州政府层面的特殊豁免。你只是“临时”改造这块土地,类似嘉年华那种用途。

     

    主持人:所以 xAI 本质上就是个要来的“嘉年华”?

     

    Sulaiman:差不多就是这个意思(笑)。但正因为这样,事情推进得特别快。内部规划加建设,全程不到一个月就搞定了。

     

    主持人:规模接下来肯定会继续疯狂扩张。马斯克 也说过,能源会是最大的瓶颈,其次才是芯片。在这种很难预测未来一到两年项目和资源需求的情况下,你们是怎么做规划的?

     

    Sulaiman:我们会尽量从“杠杆率最高的目标”倒推。先想清楚:在某个时间点之前,我们最值得做的事情是什么。比如,如果我们想在某个日期前做到一千万甚至一亿美元收入,那从经济和系统设计角度,最有效的事情是什么?然后再倒推:需要什么软件、什么物理基础设施,最后一步步拆解。所以我们几乎不会从“硬件需求”开始,那通常是最后才考虑的。

     

    主持人:那是不是也有一套类似 SpaceX 的“让事情发生”的算法?

     

    Sulaiman:你是说那种“先删掉,再加回来”的逻辑?那确实一直都在用。我们经常先把某个东西砍掉,等确认必须要的时候再加回来。

     

    主持人:你最近一次这么干是什么时候?

     

    Sulaiman:今天(指录制当天)。Macrohard 上部署大量变化极快的物理硬件,让测试变得很难,所以我们尽量减少下游的“特殊情况”。比如,我们要让三十年前的老显示器到最新的 5K Apple 显示器,全都跑在同一套技术栈上,结果发现并不是所有系统在任何时候都能愉快地配合。比如视频编码器,在某些层级上就得反复调。

     

    我之前不知道,后来才发现,有些编码器对“最大像素数”是有硬上限的。所以我们一开始删掉了多编码器的特殊分支,后来在 5K 分辨率上撞墙了,又不得不把这个特殊逻辑加回来。

     

    “优秀的人太多了,反而变得很难判断”

     

    主持人:在你看来,xAI 本身有哪些特别值得讲的地方?

     

    Sulaiman:首先是人,这里的角色非常多样;其次是我们的招聘方式也挺“怪”的。有些我原本觉得很蠢的做法,结果发现居然行得通,那我们就直接试。比如搞 hackathon,如果能从五百个人里挑出五个顶级选手,这件事就非常划算。他们未来给公司带来的预期价值,远远高于这次活动的成本。

     

    我们前几天还算了一笔账,现在主仓库里,每一次 commit 的“价值”大概是 250 万美元。我今天提交了五次。

     

    主持人:那你今天直接加了差不多一千两百万美元?

     

    Sulaiman:轻轻松松的一天(笑)。确实不错,杠杆效应非常强。你用更少的努力和时间就能做更多事,因为身边的人和内部工具都很棒。还有我的老板。

     

    主持人:那什么样的人会想来这里工作?我听你描述,感觉第一天来的人就已经准备好周末、熬夜、全天候投入了。

     

    Sulaiman:大家刚来的时候都非常兴奋,非常有热情。

     

    主持人:使命感驱动?

     

    Sulaiman:是的,但野心的类型不一样。有些人想往管理层走,看有多少人向自己汇报;也有人想“拥有”一大块技术栈。比如现在,我们在重构核心生产 API,基本上是一个人+20 个 Agent 在做,而且做得非常好。你完全可以独立拥有代码库中的很大部分。

     

    主持人:有点像 X 被收购之后那样,人很少,但每个人负责的范围巨大。

     

    Sulaiman:没错。

     

    主持人:除了 hackathon,你们在招聘上还有什么不太常规的做法?

     

    Sulaiman:我们在 Macrohard 上推得非常猛。有两、三周的时间,我每周面试 20 多个人。有的只聊十五分钟,有的就是一整小时的技术面。优秀的人太多了,反而变得很难判断。

     

    主持人:那你怎么判断?

     

    Sulaiman:我有一道自己解决过的、非常具体的问题,是几年前在创业时遇到的一个计算机视觉问题。我会给候选人半小时去实现解决方案。

     

    这个问题本身其实很简单,但“简单得很有欺骗性”,大多数人都会想复杂。我特别看重一点:你能否不过度思考,给出一个朴素但有效的方案。因为我们的系统要跑在跨三、四十年的各种硬件、操作系统上,如果不保持简单,下周代码量就能膨胀到一千万行。

     

    主持人:你还会看重哪些杠杆能力?

     

    Sulaiman:我喜欢会质疑需求、也会质疑我的人。这个方法我从 Chester Ford 那里学来的。

    他在招聘时,常常会故意在题目里塞一个错误的需求、不可能的条件,期待候选人指出来。如果对方没发现,他就不招。我现在也这么干,效果非常好。

     

    主持人:你们的节奏真的快到离谱。你自己也在做很多不同的事情,面对新任务时,怎么最快上手?

     

    Sulaiman:要看具体是什么。如果是代码多,那就老老实实读代码,反复跳转定义,很快就能摸清楚。很多时候,实现代码比想象的要少。只有在高度活跃开发的模块里,才会同时存在二十个版本,你根本不知道哪个是主线,这时候就只能去问人。

     

    让我惊喜的是,这里的人都非常开放、友好。我原本以为大家会很聪明、也很傲慢,但事实是:大家都很聪明,而且非常乐于帮忙。

     

    我们不怎么写文档,因为写文档的速度跟不上开发速度(笑)。现在我们也在尝试用 AI 自动生成文档。好处是,我们有几乎无限的算力和很聪明的 AI,可以大胆试各种“蠢办法”。在别的创业公司,这可能要烧掉几十万、上百万美元,但我们几乎是零成本。结果就是:实验更多、失败更多,但成功也更多。

     

    马斯克极限压缩时间,“办法总会有的”

     

    主持人:在实验这件事上,你们是怎么最大化“尝试次数”的?

     

    Sulaiman:通常都会有时间限制。我们经常在模型侧同时跑两、三个实验。有时候不是因为时间紧,而是因为两周后某个前置条件才会就绪:可能是硬件,也可能是数据。但今天你必须上线一个东西,那就先跑几种方案,看哪个今天就能交付、能产生收入或客户效果,两周后条件成熟了再切换。这种做法在 Macrohard 里是常态。

     

    主持人:你有没有遇到过这种情况:按理说一个项目的周期应该拉得很长,但你们却压缩后提前了好几周甚至几个月完成?这种事经常发生吗?

     

    Sulaiman:每次都是这样,无论是跟马斯克的会议,还是内部讨论,只要有人强力推动一件事,或者有外部的人——哪怕他并不对这件事负责——提出了新的需求、要求你把某件事做出来。我们一开始都会觉得,这个时间要求太离谱了。通常会花两分钟想一想、抱怨几句,然后剩下的时间就全部用来想:怎么在这个时间内把事情做完。

     

    说到底,对完成时间的预估,永远建立在一堆假设之上。一旦时间被压到原来的二分之一、甚至十分之一,你就会回头看这些假设并问自己:这些假设对时间的影响到底有多大?然后你要么把它们砍掉,要么调整掉。这样一来,时间线立刻就能快一倍。你多做几次这样的优化,基本上任何要求都能满足。当然,最终还是会撞上物理极限,但一开始的时候,你离那个极限其实远得很。

     

    主持人:我知道像完全自动驾驶、SpaceX 的火箭也是类似的情况。马斯克给的时间线通常都比实际要长得多,所谓的 “马斯克时间” 可能只有真实周期的四分之一或者一半。但正因为一开始把时间线定得这么激进,事情反而真的快了好几倍。xAI 这边是不是也差不多?虽然现在更多是软件,但哪怕在数据中心这类硬件侧,感觉进展也快得离谱,而且基本都落在他最初说的那个时间范围内。

     

    Sulaiman:我觉得他自己也在不断校准他的时间判断。毕竟现在马斯克已经在大规模部署各种各样的硬件了,所以他的估算明显比以前准很多。而且他更新时间线的频率也更高了,有时候甚至每天都在变。他会跟我们不断沟通,根据不同的参数来调整进度。

     

    有些变化甚至是他那边直接带来的,尤其是在基础设施层面。比如某个交易提前敲定了,或者某批设备可以提前排进生产,那就可能直接省下一个月、两个月,甚至更多,具体要看部署的情况。软件这边其实也是一样。

     

    他一直说的一句话是:你完全可以试着用一个月去做一件原本要一年才能做完的事,最后你可能两个月就搞定了,但那也已经快得多了。

     

    主持人:我记得在 SpaceX 的早期,有一种内部共识:马斯克说每拖延一天,就相当于损失一千万美元的收入。我不知道在 xAI 是什么感觉,你心里会不会也有一种直觉:如果今天没有再 push 一点、没有把事情往前拱一步,就等于损失了多少本可以创造的价值?

     

    Sulaiman:有的。至少在 Macrohard 这个项目上,我们确实有一些非常明确的收入目标。具体数字我不能说,但在我脑子里,只要一件事被延迟或者被加速,我几乎立刻就能算出来:我们刚刚是多赚了多少钱,或者少赚了多少钱。

     

    主持人:这也太夸张了。

     

    Sulaiman:是的,数字会非常大。一方面是因为预期回报本身就极高,另一方面是时间线实在太短了。所以哪怕只是几天的变化,按比例来看,对收入的影响都已经非常可观了。

     

    主持人:马斯克一直以“快速下重注”闻名。有没有那种在一次会议里,就做出了投入巨大资本、时间或者承诺的决定?

     

    Sulaiman:有一个非常典型的决定,就是在 Macrohard 上,我们选择了一条路线:模型的速度至少要比人类快 1.5 倍,而现在看起来,实际速度远远不止如此。

     

    在其他实验室,类似“人类模拟器”的尝试,更多是走“更强推理能力、更大的模型”这条路。但我们当时的这个决定,几乎是完全走在了和所有人相反的方向上。之后我们做的几乎所有事情,基本都是这个决定的下游结果。虽然不能说百分之百,但它影响了绝大多数事情,而且这个决定是在非常早期就定下来的。

     

    这在某种程度上也是一种共识,尤其是类比完全自动驾驶就很容易理解。没有人会等电脑花十分钟去做一件自己五分钟就能做完的事。但如果电脑十秒就能搞定,那我愿意为此付出任何价格。这其实是个非常直观的判断。

     

    正常情况下,我们这些工程师可能会站出来反对,有二十个理由说明事情不能这么做。但当一个决定已经被拍板了,你只能从结果倒推路径,办法总会有的。

     

    没有 AI 研究员, 就是工程师

     

    主持人:我记得马斯克之前说过一次,好像是在 YC 的活动上,他和 Gary Tan 做问答。Gary 提到 AI 研究员这件事,结果马斯克说不存在什么 AI 研究员了,现在全都是 AI 工程师。

     

    Sulaiman:对,我们跟他开过一次关于招聘的会,也有人提到过类似的话题,比如岗位描述之类的。然后他大概讲了十分钟,核心就一句话:工程师,就是工程师,别的都不重要。只要是好工程师,本质上是个会解决问题的人就行。不管你以前是做哪一块的,用过什么架构、做过哪种基础设施,这些都不重要。

     

    主持人:为什么“工程师”这么重要?

     

    Sulaiman:因为这样边界就被拉得很宽。意味着我们可以从很多不同背景的人里招人,现实中也确实是这样。AI 领域可能还不算特别明显,但 SpaceX 有很多这样的故事:有人来自你完全想不到的背景,按传统眼光根本不可能进来,但最后却在工程上做成了非常大的事情。所以定义宽一点,就等于给这些人留了一条路,也能帮助我们整体跑得更快。

     

    “没人指挥你干这个、干那个”

     

    主持人:那对你个人来说,在那工作最有意思的地方是什么?

     

    Sulaiman:没人管我。真的,没人指挥你干这个、干那个。如果我有个好想法,通常当天就能自己动手把它做出来,然后拿去展示。看看合不合理,跑个评估,或者直接给客户看,给马斯克看,给相关的人看,一般当天就能知道这个方向对不对。

     

    没有冗长的讨论,也不用等各种流程和官僚审批,我特别喜欢这一点。说实话,我从非常小的创业公司来更大的公司,本以为会牺牲一些自由度。我加入时公司 100 人,是我之前公司的 10 倍。但对马斯克的公司来说算小的,确实感觉很小的公司,没有什么繁文缛节。

     

    主持人:你进去之前,有没有什么特别大的预期,结果后来发现完全不是那么回事的?

     

    Sulaiman:我原来以为会更“自上而下”一些,结果发现有一些,但不多。管理层级非常少,基本就三层:最底下是 IC,中间是联合创始人和一些新晋的经理,再往上就是马斯克,没有了。

     

    现在每个经理下面的人都很多,事情反而很少是自上而下推动的。通常是我们自己先想出解决方案,跟经理对一下,马斯克点头,就直接干了。有反馈就再调整。整体比我想象中要“自下而上”得多。

     

    主持人:感觉就是在刻意设计一种状态,让所有人都在做东西,管理者更少,真正的“建造者”更多。

     

    Sulaiman:对。我刚加入的时候,几乎所有经理都还在写代码。现在有些人下面管着上百号人,写得少了一点,但总体上,大家还是工程师。

     

    我记得第一周,有天吃晚饭,一个人坐我旁边。我就随口问他在哪个团队。他说他是做销售的,主要负责企业客户。我当时还想,“哦,原来是销售。”结果,他接着跟我讲他最近在训练的模型。

     

    没错,销售也是工程师。销售团队全是工程师,几乎每个人都是工程师。那会儿公司里,可能真正不算工程师的人不到八个。即便如此,大家也都是在为同一台“机器”做贡献。

     

    主持人:所以是不是更像这样:一个工程师负责一个项目,可以直接面对客户,理解他们的问题,然后快速实现解决方案?

     

    Sulaiman:是的,而且层级越少,信息损失就越小。本质上是信息压缩的问题。语言本身就是有损的。如果信息要从客户脑子里变成语言,再进销售脑子,再变成语言、再到经理、再到工程师,每过一层,就像传话游戏一样丢一大截。如果你能尽量减少层级,那就只剩下一次压缩:客户直接告诉你他们要什么、体验是什么,然后工程师直接去解决。

     

    主持人:有没有什么你以前在别的公司从没见过,但 xAI 在做的事情,能让事情推进得特别快?

     

    Sulaiman:最让我意外的是团队之间、职责之间的“模糊性”。这在其他大公司,甚至规模差不多的公司里,都很少见。

     

    比如我要修虚拟机基础设施的一个问题,我就直接修,修完给负责那块的人看一眼,对方说 OK,马上合并、上线。几乎没有那种严格的边界,大家基本都可以改任何东西。当然,危险的操作还是有检查的,但总体上,公司是信任你的,默认你会把事情做对。这种感觉真的很不一样。

     

    主持人:我记得之前马斯克在搞 DOGE 的时候,删掉了一些防控措施然后又很快加回来了。在这种高速试错的过程中,有没有什么东西被删掉、又重新做回来的?

     

    Sulaiman:几乎没有那种不可逆的破坏。我想不起来有什么东西是真的被永久性毁掉的。但像你说的,删掉、移除某个东西,然后有人说“我需要这个”,这种情况非常常见。可能一个小时后就回滚了。

     

    也有那种情况,一个项目做了好几个月,依赖某块基础设施,结果等你真要上线的时候,那块基础设施已经被重构过三次了。那就再适配一次,继续往前走。

     

    主持人:你觉得工程团队人这么少是件好事吗?

     

    Sulaiman:绝对是。人越多,反而越慢。一个人能做完的事,两个人来做,往往要花两倍时间,这在任何规模下都成立。尤其是现在,你已经不需要像以前那样写那么多代码了,更多是在做决策、做架构设计。每个人都可以是架构师,不需要那么多“手”,一个大脑能做的事情多得多。

     

    主持人:你之前自己也尝试过创业,做过很多不同的项目。是什么让你决定来这里?使命感也好,文化也好,哪一点真正打动了你?

     

    Sulaiman:说实话,我一直是马斯克的粉丝。小时候第一次看到猎鹰火箭回收着陆,那种震撼真的忘不了。我后来还专门跑去看了 星舰的第五次发射,那次是第一次成功“接住”,真的值回票价,是我这辈子见过最酷的事情。所以只要能参与任何跟这些事情沾点边的东西,对我来说就已经非常有吸引力了。

     

    主持人:那你当初为什么选择这家公司,而不是 SpaceX 或特斯拉?

     

    Sulaiman:主要还是因为我骨子里就是个创业者吧。xAI 是这几家公司里规模最小、也最新的一家。我当时的一个判断,就是在这种体量的公司里,个人能产生的杠杆和改变会最大,事实也基本验证了这一点。因为从比例上看,你在公司里的“占比”更大。不是说其他公司不酷、或者个人不重要,而是这种比例带来的影响力不一样。

     

    主持人:也就是说,对决策产生影响的可能性要大得多。

     

    Sulaiman:甚至不只是决策,而是从想法到落地、到看到结果,速度都非常快。我之前以为很多事情自己单干会更快,比如自己做某个功能、跑某个实验。但现实是,在 xAI 反而更快,因为已经有现成的基础设施和团队,很多我本来要手动完成的步骤,他们早就做过了,而且基本没人会对你说“不”。

     

    内部 AI 虚拟员工

     

    主持人:你之前提到,公司里不同人、不同事情之间的边界其实挺模糊的。那你能不能随时去找其他同事帮忙?

     

    Sulaiman:经常啊。基本就是走到别人桌前,直接说:“我有个问题。你现在在做什么?我能不能帮你一点?你能不能帮我这个?”大家都在同一栋楼里,这种事非常自然。

     

    挺有意思的是,我们后来在公司内部测试“虚拟员工”(human emulator),有时候甚至没提前告诉大家,所以就会出现这种情况:有个真人员工在干活,突然有人找他说“你能不能帮我做这个”,虚拟员工就回:“行啊,来我工位吧。”结果那人真的走过去,发现什么都没有。

     

    好几次我收到消息说:“组织架构里这个人向你汇报,他今天是不是没来?”但其实他是个 AI,是虚拟员工。

     

    不过整体来说,大家默认都是在同一栋楼、随时能联系到的。所以互相求助这件事非常频繁。我可以找别人帮忙,别人也经常来找我。

     

    主持人:那在这些过程中,最容易“翻车”或者最让你意外的点是什么?

     

    Sulaiman:主要发生在“人类行为模拟”这块,尤其是和客户一起做的时候。我们会尽量全面地理解客户的工作内容:先聊天、访谈,让他们讲,或者写下来他们是怎么做这份工作的。再过一周,我们回头看虚拟员工犯的错误,发现它总是在某些特定场景出问题。

     

    这时候我们就去观察真人是怎么做的,结果发现真实流程里其实有二、三十个步骤,对方之前完全没提。我们一问,他们就说:“哦对,这一步我们是这么做的,刚才忘了说,不好意思。”这种情况太常见了。

     

    很多事情在人脑里是默认存在的,全靠“自动驾驶模式”在跑。就像你开车开了一小时,完全不记得自己刚才是怎么开的。人类对任何重复性的工作都是这样,而我们想解决的正是这些问题:把人类现在反复做、其实根本不需要人来做的“蠢活”,全部替掉。

     

    主持人:那你是怎么决定“先解决哪一类问题”的?除了开车以外,人类还有哪些事情是天天在做、但其实没必要继续做的?

     

    Sulaiman:只要是电脑上的重复性工作,基本都在这个范围内。比如客服就是一个特别典型的场景:不断接收各种格式、各种内容的用户输入,然后把它们转化成一个标准化的处理流程。这样人类就可以去做更有创造性、更需要大脑的事情。

    和编程领域发生的变化几乎是完全平行的:以前你要把同样的实现写二十遍,现在你用三句话描述一下,它就帮你搞定了,这是一次巨大的“压缩”。我们做的,其实就是把这种“压缩”,应用到所有数字化工作流上。

     

    主持人:在公司内部推这些“虚拟员工”的时候,除了“人不存在但被叫去工位”这种情况,还有什么让你觉得意外的吗?

     

    Sulaiman:意外的一点是,它的泛化能力比我们预期的强很多。有很多测试案例,模型根本没针对这个任务训练过,但表现却非常完美,远远超出我们的预期。因此,可以很确定地说,泛化效果真的比想象中好,而且我们现在还处在非常早期的阶段,之后只会越来越强。

     

    这点其实和完全自动驾驶很像:有些场景并不在训练数据里,但车就是能正确应对。这本质上是一个“权重效率”的问题。

     

    马斯克给反馈,要么宏观、要么细节

     

    主持人:你参加过几次和马斯克的会议?那种会议一般是什么样的?

     

    Sulaiman:说实话都挺简单的,而且我运气不错,大多数都进行得很顺利。

     

    主持人:在 SpaceX 这种地方,成本和零部件细节特别重要。但在你们这里,他给反馈时会不会不太一样?比如不会去抠每个流程的细节?

     

    Sulaiman:他的反馈通常要么非常宏观,要么非常微观,很少停在中间。

     

    宏观层面上,可能是产品方向、客户判断,比如“只专注这个细分市场”“这件事完全不要做”。微观层面,尤其是算力效率、延迟这些问题,他往往会给出非常具体的建议,比如“试试这个方案”。而且他是愿意被证明错的,但前提是要有证据,必须做实验、看结果,而不是靠观点对喷。有些实验的结果甚至会出乎所有人的意料,然后我们就顺着那个方向继续走。

     

    主持人:所以你们后来选择小模型,而不是一味堆大模型。

     

    Sulaiman:对,小模型在算力效率上的选择,带来了很多改进。有些是直接的,有些是间接的。最直观的当然是响应更快。但更重要的是,特斯拉在自动驾驶上也发现了同样的事:模型小了,迭代速度就快得多。

     

    不仅模型对环境反应更快,部署新版本的速度也快了。以前可能四周一次,现在一周一次。这又反过来影响了实验方式:为什么我们能同时跑二十个实验,其实就是源于这个早期决策。

     

    主持人:那一开始的设想,是不是想直接上大模型?

     

    Sulaiman:算是吧。我们确实想比所有人都快,但后来发现,“快”这件事的效果,被放大了很多倍。

     

    “war room”真实存在

     

    主持人:维基百科一直被诟病有偏见,马斯克也很关注构建一个“更接近真实”的替代体系。那你们怎么看待清理互联网来找到真相这件事?

     

    Sulaiman:这是个极其困难的问题,因为互联网本身往往并不是所谓的“事实真相”。我们能做的,是尽可能往“底层原理”去钻,但这本身也很难。比如你问“宪法在物理意义上的底层原理是什么”,这其实很难有人真正给出一个严谨的答案。

     

    但思路是类似的:尽量往下挖,再从那里往上构建。问题是真正这样写、这样做的资料并不多。比较接近的一个例子,是 James Burke 的《Connections》系列,他会把看似完全不相关的概念,通过物理和发明串联起来,非常有意思。我们想做的,其实是类似的事情,只不过这条路还很新。

     

    主持人:你们是怎么找到更好的数据的?

     

    Sulaiman:数据并不是决定结果的唯一因素。

     

    主持人:我有时候会在 X 上看到有人贴出 Grok 的输出,说“这明显不对”,然后马斯克直接回复说“我们会修”,接着可能过了十二个小时、一天,他又说“好了,已经修好了”。这种事情发生时,内部一般是怎么运作的?

     

    Sulaiman:通常是他把哪里出问题了直接指给我们看,然后当时还醒着的人就会马上拉一个线程开始解决问题,一般先是个人处理,如果需要就再拉几个人。之后我们会做一次复盘,把到底哪里出了问题、以后怎么避免都讲清楚。原则上,犯一次错是可以接受的,但同样的错误犯第二次就很严重了。

     

    主持人:在 SpaceX 的历史里,包括特斯拉,其实有过很多这种“冲刺时刻”。比如马斯克半夜突然出现,发一封全公司邮件,说大家都来公司干活。你们也有这种情况吗?

     

    Sulaiman:这种更多发生在做大模型的时候。就 Macrohard 这个项目来说,我们已经在“作战室”里连续干了四个月了,基本一直就是这种状态。

     

    主持人:你们门口是不是还真挂着一块牌子写着“war room”?

     

    Sulaiman:是的,真的。最早那个作战室后来扩张了,我们就把东西全搬走了。有一次马斯克走进作战室,发现里面空无一人,就问“人呢?怎么回事?”然后他又走到我们现在待的地方,其实就是健身房,我们把健身器材全清掉,把人都塞进来了——然后他就在那儿开始一连串追问到底发生了什么。

     

    主持人:在那种很多事情被打乱又被迅速推进的夜晚,或者经历那种大规模冲刺时,是什么感觉?

     

    Sulaiman:我最近正好看到 xAI 的一位联合创始人 Igor 发的一条内容。他人特别好,我也很喜欢跟他一起工作。他以前在 StarCraft AI 工作,大概十年前吧,是我高中时尝试复现过的最酷的机器学习项目之一,难得要命,所以后来能和他一起共事真的挺神奇的。

     

    他说的一句话我特别有共鸣:有些时间里,感觉只过去了几天;但有些夜晚里,仿佛发生了几个月的事情。那天晚上就是这样。说“几个月”可能有点夸张,技术结果我们本来也可能几周内做到,但一晚上把它搞出来,冲击感非常大,而且真的熬了一个通宵。

     

    主持人:有没有那种情况,大家连续五天、甚至一整周都没怎么离开过办公室?

     

    Sulaiman:有的。模型冲刺的时候,经常会有很多人直接在公司过夜。

     

    主持人:之前提到你们有五、六个睡眠舱,大家轮着用?

     

    Sulaiman:对,有睡眠舱,现在还有一些上下铺,条件差点,但至少能睡。后来帐篷那张照片传出来后,很多人都发给我。我只能说确实有帐篷,但我从没见过一次搭那么多。反正……确实挺极端的。

     

    成长经历:从小不服权威

     

    主持人:我知道你小时候做过很多不同的项目,好像还做过指尖陀螺。可能是在你房间里搞的?这种折腾、动手的心态,对你现在的工作影响大吗?

     

    Sulaiman:影响挺大的。我很小就开始学编程,大概十一岁的时候,我爸给我买了一本书。我一开始觉得还行,但真正开始喜欢是在我意识到它能赚钱之后。我在网上认识了一些人,他们给游戏写脚本、外挂,然后卖一点钱。对我来说,能在网上赚到几百美元已经是天大的事了。

     

    主持人:第一次有人给你钱,那种感觉真的很奇怪。

     

    Sulaiman:太疯狂了。我还记得当时得让我爸帮我弄一个 PayPal 的托管账户之类的,然后钱真的打进来了。对我来说,那简直是世界上最酷的事情。我干了几个月,攒了点钱,当时我对 3D 打印特别着迷,RepRap 那套体系正火。

     

    那其实就是一群大学生搞的项目,目标是造一台能打印出自己大部分零件的机器,所以才叫 RepRap。他们在不同大学里搞了一些实验室,从一台打印机开始,让它打印下一台的零件,一步步扩展。当然,这里面问题很多,他们也一直在解决,但那确实推动了后来的 3D 打印浪潮。我当时特别痴迷,就照着他们的零件清单,在阿里巴巴上把东西全买齐了。

     

    主持人:然后呢?

     

    Sulaiman:一个月后东西到齐了,我一晚上把它装起来,但过程其实挺惨的。我在拆电源的铜线,那是个非常不靠谱的电源,结果真的着火了。铜线全散开,有一根直接扎进我拇指里,大概有五厘米深。

     

    主持人:去医院了吗?

     

    Sulaiman:没有。那是个上学的夜晚,已经凌晨了。我十三岁,动手能力也不行,在卫生间用镊子折腾了一个小时也没拔出来,最后我干脆把露在外面的剪掉了。接下来几周,它一点点往外长,我每天早上再剪一点。现在想想还挺离谱的。

     

    不过打印机最后还是装好了。那时候正好赶上指尖陀螺爆火。我从中国买了一千个滑板轴承,在自己卧室里搞了个小工厂。晚上每隔两个小时起来一次清理打印平台,重新打印一批陀螺。白天上学前,我在车库里装轴承、喷漆、晾干,然后跑去其他学校的公交站,把货卖给“分销商”,其实就是别的学校的学生。他们白天卖,我放学后收钱,线上也卖、发货。

     

    生意做了两个月,最后被叫停了。官方理由是,学校餐饮公司有独家销售权,不能在校园里卖东西。但我觉得,他们主要是不爽我一边分散大家注意力,一边还赚钱。这事让我学到了一种“健康的不服从权威”。

     

    主持人:这种对权威保持距离,好像一直贯穿你的经历。你提到你不太信任机构,这种态度是怎么形成的?在你的人生里具体体现在哪?

     

    Sulaiman:我从很小就知道,我想要的是一种不寻常的结果,而走一条常规路径,基本不可能得到。于是我本能地抗拒一切“惯例”,而机构的本质就是维护惯例。我觉得,几乎所有真正有创造力、有意思的成果,都是来自自由的人。至少在我看到的世界里是这样。所以,忠于这一点,对我来说才是正确的选择。

     

    主持人:我很喜欢 John Carlson 的一个观点:所有东西都这么难造、难实现。看看周围,世界就是充满人们的激情项目。

     

    Sulaiman:对,完全就是个奇迹。每一样东西背后都有故事,比你想象的要多得多。我记得以前读过 YKK 拉链的故事。你会发现,全世界真正做得好的拉链厂商就两、三家。拉链看起来很便宜,但机械结构其实挺复杂的。之所以能这么便宜、这么可靠,是因为有极少数公司、甚至可以说是极少数人,花了几十年把这件事做到极致。

     

    这几乎适用于所有东西。任何特别具体、又能大规模生产的东西,背后通常只有几家公司、甚至几个人在做。就像有时候你会听说,德国某个不起眼的小公司一停产,大众汽车整条产线都得停。疫情期间这种事就更明显了。

     

    主持人:在我们见面之前,你还做了一个液体燃料火箭发动机,我记得很小一个,你说是临时起意,二十四小时内点火的?

     

    Sulaiman:整个项目其实前后做了大概四周。一开始我就是买了一堆教材,研究火箭发动机的设计原理。和软件完全不一样,软件你可以上 GitHub 看别人的代码,但火箭没有现成文件。你得搞清楚材料特性、化学性质、怎么加工、参数怎么定,推力怎么估算,怎么避免超压。还有喷注器的设计,这个特别难,大概占了一半时间。

     

    主持人:这是最难的部分吗?

     

    Sulaiman:是的,喷注器最难,也是最后问题最大的地方。我花了三、四周时间,找中国工厂加急做了很多零件。那时候正好感恩节,我准备飞回东海岸看家人。我当时想,要么今晚把它装好、点火,要么就拖两周,然后我决定不能拖,就现在干。我早上灌了很多咖啡,一整天都在干活,搭测试架、装发动机,当晚就点火了。当然,为了能当晚完成,做了不少妥协。

     

    主持人:我真的觉得特别好笑,你当时离它其实就几步远?

     

    Sulaiman:对。我其实设计了远程点火,但问题是,用来给板载计算机供电的电源还没到,只能用笔记本通过 USB 供电。而我最长的 USB 线只有一米多,所以我只能站在旁边点火。我心里估计,大概有三成概率它会炸,或者喷得到处都是火。

     

    视频里其实能看到,我的外套着火了。因为喷注器设计不好,产生了很多超压,没完全燃烧的乙醇直接喷出来,溅到我身上就点着了。那件烧焦的外套现在还留着,当纪念品了。

     

    参考链接:

    https://www.youtube.com/watch?v=8jN60eJr4Ps&t=41s

    作者:肖振威

    背景

    随着云端业务规模的持续扩大,AI 训练数据、实时日志与多媒体资料等数据量呈现指数级增长,云存储因此逐渐成为主流选择,同时也带来了 I/O 请求量的快速上升。在共享式的多租户架构中,多个租户共同使用底层存储资源,高并发访问极易引发 I/O 资源争抢与性能瓶颈。此外,混合云与多云部署日益普及,数据在多个云环境之间频繁流动,而不同云服务商在存储策略与监控机制上的不一致,使得 I/O 类故障的定位与追溯变得更加复杂。为提升此类问题的处理效率,阿里云云监控 2.0 结合 SysOM 智能诊断功能围绕常见的 I/O 异常场景,构建了一套覆盖“异常检测—根因分析—修复建议”全链路的 I/O 一键诊断功能。

    业务痛点解析

    痛点一:用户难以准确判断 IO 异常类型

    大多数用户对 IO 问题的具体类型缺乏清晰认知,例如往往搞不清当前是 IO 延迟升高、IO 吞吐被打满,还是其它类型的异常,导致很难主动选用对应的排障工具和方法,只能依靠运维专家介入排查,整体诊断效率偏低,人力投入也随之增加。IO 一键诊断聚焦 IO 延时偏高、流量异常、iowait 居高不下等高频场景,自动捕捉 IO 子系统的异常特征,帮助用户快速完成问题类型的判定。

    痛点二:异常发生瞬间难以“抓现场”,取证不充分

    传统监控系统通常只采集操作系统层面的通用 IO 指标,比如 await、util、tps、bps 等,并以指标突变作为告警条件。然而,当指标被检测到异常时,真实问题往往已经发生甚至结束,此时再想获取更细致的采样和上下文信息,往往为时已晚,关键线索已经流失,难以形成完整的诊断证据链。要做到有效定位,就必须尽可能在异常刚出现或仍在持续时就触发针对性采集,因此,快速识别并及时行动,是获取最佳诊断数据的关键。

    痛点三:指标体系割裂,监控数据与诊断结论之间缺乏直连

    现有监控往往仅提供一组相互独立的指标,彼此缺乏联动,也没有与具体 IO 故障类型建立直观映射。以 util(磁盘繁忙度)偏高为例,实际分析时还需参考 await 等多项指标,并结合设备的理论 iops、bps 上限进行综合判断。即便勉强推断出问题类型,接下来仍离不开对各种诊断工具的经验性操作,包括如何按照指标数值选择合适的采样区间、参数配置等。IO 一键诊断的设计目标,就是将这一串复杂的关联分析与工具选型过程封装在系统内部,对用户直接呈现整理好的诊断报告和结论。

    解决方案

    架构介绍

    在阿里云云监控 2.0 中,SysOM 管控模块原本就支持对 IO 延迟异常、IO 量异常以及 iowait 高等问题开展诊断。不过,大部分客户并不希望在业务环境上长时间运行高频诊断程序,以免对生产带来干扰。因此,IO 一键诊断采用了“监控先行、按需抓取”的架构:在用户指定的诊断时间段内,系统定期读取 IO 监控指标,用于异常识别与问题圈定,一旦满足条件,再触发具体的子诊断工具进行深度分析并输出报告,构成一个从发现到定位的闭环流程。

    考虑到不同业务类型对 IO 行为和性能阈值的容忍度不尽相同,如果强行规定统一的固定阈值,势必会导致误报大量增加或严重漏报。因此,IO 一键诊断引入“动态阈值”机制进行异常识别,其总体处理链路可以概括为:

    image

    • 指标采集: 定期从系统中抓取关键 IO 指标,如 await、util、tps、iops、qu-size、iowait 等。
    • 异常检测: 当采集到的指标突破动态阈值,就将其标记为潜在异常。动态阈值的计算方法是整个检测环节的核心,后文会展开说明。
    • 自动诊断触发: 依据异常的指标类型与特征,自动选择合适的诊断工具,并设置触发频率限制,避免频繁调用。
    • 结果处理与展示: 对诊断输出进行归纳和可视化呈现,为用户提供导致问题的根本原因以及可执行的优化建议。

    实现原理

    指标采集机制

    当用户在控制台启动 IO 一键诊断后,系统会按配置好的时间间隔(cycle 毫秒)循环读取 iowait、iops、bps、qusize、await、util 等一系列 IO 指标,并在每个周期对最新采集的数据做异常检测判断。

    动态阈值计算

    为了能在秒级甚至更细粒度下捕获 IO 突发、短时抖动等异常,必须将各类单一 IO 指标联动起来,从整体上刻画 IO 子系统的“正常波动区间”。动态阈值就是用来界定这一“正常区间”和“异常尖峰”的边界。其计算过程主要分为三层:基础阈值、补偿阈值和最小静态阈值。

    基础阈值:刻画整体波动幅度

    从时间序列的角度看,IO 指标在大多数时刻处于平稳运行状态,曲线起伏较小;当出现异常负载或者突发流量时,曲线会突然出现明显偏离均值的峰值。因此,首要任务是利用基础阈值,找出这些显著高于日常波动的“尖峰”。

    实现策略是:使用一个滑动时间窗口持续观察数据点,在每个窗口中计算所有点相对于窗口平均值的“最大偏离量”,把这个偏离量记为该窗口的“瞬时波动值”;随后对连续多个窗口的“瞬时波动值”求平均,形成动态更新的“基础阈值”。随着新数据不断进入,该阈值也会自适应地调整,始终反映 IO 指标近期的真实波动特征。

    image

    补偿阈值:削弱基础阈值快速下降带来的误报

    基础阈值曲线(如示意图中的黄色线条)虽然能够反映指标的总体波动情况,但在系统处于稳定期时,IO 指标通常只在很窄的一段区间内轻微波动,此时基础阈值可能随波动减弱而快速下降,容易让一些微小的正常抖动被误判为异常。因此,需要额外引入一个“补偿阈值”,叠加在基础阈值之上,对其下降速度进行一定缓冲,从而抑制误报。

    image

    具体逻辑是:当系统监测到基础阈值在一段时间内持续走低,可以认为当前进入了相对“安静”的常态阶段。此时先过滤明显噪声点,再在剩余的稳定数据里计算一个“常稳态补偿值”,以刻画这类稳定状态下的细小波动。补偿值尚未收敛前,先用当前窗口内出现过的最大基础阈值暂时代替,并在每个新窗口开始时重新计算。一旦基础阈值停止下降或开始回升,就意味着系统波动模式发生了变化,此时补偿机制会被重置,重新进入更宏观的观察期。

    image

    最小阈值:兜底的静态门槛

    最小静态阈值可以理解为预先设定的“绝对下限”,是业务方能接受的最低告警基线。最终用于判定异常的阈值,是“最小静态阈值”和“动态调整阈值(基础阈值 + 补偿值)”之间的较大者。只有当指标既超过了日常波动的正常范围,又突破了业务底线时,才真正被视为异常事件。

    此外,如果指标本身已经明显高于“最小静态阈值”,则无需再额外叠加常态补偿值,此时仅以基础阈值作为判断依据即可,将分析重点聚焦在更显著的异常波动上。

    image

    异常识别策略

    在运行时,一旦采集到的某项 IO 指标值高于其对应的动态阈值,即可认为存在异常风险。虽然不同指标(如 iowait、util、iops 等)的判定逻辑略有差异,但整体遵从以下共通规则:

    • 确定告警基线: 为每一类指标定义一条“警戒线”,其数值为“最小静态阈值”和“动态阈值”中的最大值,既考虑业务底线,也考虑历史波动范围。
    • 决定是否触发诊断: 当监控值超过警戒线,同时满足一定的监测条件(如持续时间、触发次数等),就可以启动对应的诊断流程。
    • 持续更新模型: 随着新数据不断加入,动态阈值会被持续修正,使其适配当前环境的正常波动模式,而非依赖一次性的静态配置。

    智能诊断与频率控制

    当系统确认存在 IO 异常后,一键诊断模块会自动调用相应的分析工具,抓取关键现场信息并进行自动化处理,帮助用户快速锁定问题。为避免过于频繁的诊断操作影响业务,系统通过以下两个参数对诊断频率进行约束:

    • 诊断冷静期(triggerInterval): 规定两次诊断之间必须间隔的最短时间,用来避免在短时间内重复对同一类异常进行频繁扫描。
    • 异常累积阈值(reportInterval): 设置触发诊断所需的异常累积条件。当该值为 0 时,只要异常满足冷静期结束的条件,就立即启动诊断;当该值为非 0 时,则需要在冷静期之后、限定时间窗口内出现一定次数的异常事件,才会真正触发。

    根因分析

    在完成现场数据采集之后,面对复杂多样的系统信息,如何从中筛选出与当前问题强相关的线索,是传统人工分析的难点。IO 一键诊断在工具层面内置了一套自动分析逻辑,能从采集结果中提炼结论,并以结构化信息的形式反馈给用户,包括但不限于:

    • IO Burst 场景: 分析在异常时间段内各进程对 IO 的贡献度,在报告中标明最“耗 IO”的进程。对于写 buffer IO 而由内核 kworker 线程负责刷脏的情况,也能追溯到最初发起写入的用户进程。
    • IO 延迟异常: 统计并展示异常区间内 IO 延迟的整体分布情况,标记延迟最高的路径(如对应的设备或文件/目录),帮助快速找到性能瓶颈所在。
    • iowait 异常偏高: 记录和展示导致 iowait 偏高的关键进程,以及引发大量等待的具体原因(例如磁盘被占满、脏页刷写过慢等)。

    案例分析

    iowait 高

    在某些场景下,业务反馈系统整体响应慢,通过监控发现 iowait 指标异常升高。借助 IO 一键诊断,可以直接定位到哪一个或哪些进程在大量等待磁盘 IO,以及每个进程累计等待的时间长度,并进一步分析等待背后的原因。

    在示例案例中,诊断结果显示:业务写入量过大导致 IO 压力偏高,系统中脏页堆积,最终使业务进程 task_server 长时间阻塞在 IO 等待上。针对这种情况,报告建议谨慎下调 dirty_ratio、dirty_bytes 等内核参数,以减少一次性刷脏量,降低磁盘压力,从而缓解 iowait 过高问题。

    image

    IO延迟高

    另一类常见问题是写 IO 的延迟持续走高。某用户通过基础监控发现写入延迟异常后,通过 IO 一键诊断进行进一步排查。

    image

    诊断报告指出,在问题发生期间,DiskBlockWrite 进程是主要的 IO 负载来源,并且耗时主要集中在刷脏阶段,也就是说核心瓶颈在于磁盘将缓存数据落盘的过程。依据这一结论,系统给出两类优化建议:一是调整业务逻辑,减少短时间内大量 buffer IO 的写入;二是通过适当调整 dirty_ratio、dirty_background_ratio 等参数,控制脏页生成和回写的节奏,从系统层面降低写 IO 延迟。

    image

    相关链接:

    [1] IO 一键诊断

    https://help.aliyun.com/zh/cms/cloudmonitor-2-0/io-key-diagnosis

    [2] 云监控-ECS 洞察-SysOM 系统诊断

    https://cmsnext.console.aliyun.com/next/region/cn-shanghai/wo...

    [3] 操作系统控制台实例纳管

    https://help.aliyun.com/zh/alinux/user-guide/system-management

    摘要​:大模型技术的成熟与落地推动智能体从单任务自动化工具升级为全链路数字化协同主体,其凭借自然语言理解、任务自主拆解、跨系统联动核心能力,重构企业内外部协同逻辑,破解传统数字化协同中的信息偏差、响应延迟、流程内耗等痛点。本文系统剖析大模型为智能体赋予的技术能力升级,拆解智能体在企业核心协同场景的应用价值,梳理技术落地的核心挑战,并从技术、流程、安全、组织四大维度提供可落地实施策略,补充行业高频 QA 问答模块覆盖用户核心诉求,为企业把握大模型与智能体融合趋势、构建高效数字化协同体系提供专业参考。

    关键词​:大模型;智能体;企业数字化协同;跨部门协同;AI 落地;数字化转型;多智能体协作

    一、大模型与智能体的融合:重构企业协同的技术底层

    大模型是智能体实现智能化协同的核心技术底座,与传统规则化智能体的结合,彻底突破了传统自动化工具的能力边界,实现从“被动执行指令”到“主动理解意图、自主规划执行”的本质升级。

    传统智能体仅能完成预设规则内的单一自动化任务,对非标准化指令理解能力弱,无法实现跨系统、跨场景联动;而大模型凭借海量数据训练形成的自然语言理解(NLU)、逻辑推理、知识生成能力,为智能体赋予三大核心升级:一是精准解读自然语言需求,捕捉显性要求与隐性协作意图,无需标准化指令;二是自主拆解复杂任务,规划最优执行路径;三是跨系统无缝联动,打通企业 CRM、OA、财务等系统的数据与流程,无需人工介入系统切换。

    大模型与智能体深度融合,形成“大模型做决策 + 智能体做执行”的协同模式,让智能体成为企业数字化协同的“超级枢纽”,实现从员工单一需求响应到企业全链路业务协同的技术突破,这也是其成为企业数字化协同新引擎的核心逻辑。

    二、大模型驱动智能体在企业数字化协同的核心应用场景

    2.1 企业内部跨部门协同:打破信息壁垒,实现全流程实时联动

    跨部门协同是企业数字化转型的核心痛点,传统模式依赖会议、周报同步信息,存在响应延迟、信息偏差、责任模糊等问题,导致项目推进效率低下。

    大模型赋能的智能体以“全流程协同枢纽”为定位,实现跨部门协同的智能化与实时化:接入企业项目管理系统,实时同步各部门工作进度;当某部门提交成果或反馈问题时,智能体解读核心信息并自动推送给关联部门,明确协作要求与时间节点;针对研发、生产、市场、销售全链条项目,自主规划协同路径、动态调整工作安排,若出现产能不足、供应链延迟等突发情况,立即触发预警并联动相关部门生成解决方案。

    例如新品研发项目中,研发部门完成迭代方案后,智能体可自动提取核心参数同步生产部门核实产能,向市场部门推送卖点与推广节点建议,向销售部门同步上市计划,全程无需人工转达,将跨部门协同响应周期缩短 80% 以上。

    2.2 企业业务全流程协同:从需求到落地的智能化闭环

    企业单一业务落地涉及多环节、多岗位协作,传统模式下各环节衔接依赖人工,易出现流程断层、执行偏差。大模型驱动的智能体可实现业务全流程智能化协同闭环,覆盖需求发起、任务分配、执行落地到结果反馈全链路。

    以华东地区美妆品类 618 推广活动为例,市场人员仅需输入“策划活动实现销售额环比提升 30%”,智能体即可完成需求拆解:对接销售系统提取历史数据、联动供应链核实库存、制定推广方案、分配设计部门制作物料、协调运营部门线上投放、同步销售部门线下承接;活动执行中实时监控数据,动态调整推广策略;活动结束后自动整合数据生成分析报告,同步管理层与执行部门。

    该模式让智能体承担任务规划、跨岗协调、数据监控、策略优化核心工作,将业务从需求到落地的周期压缩 60% 以上,大幅降低人工执行偏差率。

    2.3 企业对外服务协同:前端接待与后端支撑的无缝衔接

    企业对外服务的协同效果直接影响客户体验与商业合作效率,传统模式下一线服务人员因专业能力限制,常需转接后端人员,导致客户等待时间过长、体验不佳。

    大模型赋能的智能体实现“前端接待 + 后端支撑”无缝协同:前端智能体精准解读客户需求,标准化问题直接解答;复杂技术问题、定制化商务需求,自动提取核心信息同步后端部门,快速获取解决方案后反馈前端,由服务人员结合个性化需求优化回复;同时将解决案例录入企业知识库,通过大模型持续优化,提升后续服务响应效率。

    在 ToB 企业技术服务场景中,该模式可将客户问题解决效率提升 70% 以上,客户满意度提升 60%,减轻前后端部门重复沟通压力。

    三、大模型驱动智能体落地企业数字化协同的核心挑战

    3.1 数据安全与隐私保护风险

    智能体实现协同的核心前提是接入企业核心数据,包括 CRM 客户数据、财务资金数据、供应链商业数据等,部分数据涉及商业机密与用户隐私。若采用公有云部署模式,数据将脱离企业管控边界,存在泄露、滥用风险;多智能体协同中数据流转路径复杂,缺乏完善权限管控易出现越权访问、数据篡改,违反《数据安全法》《个人信息保护法》,给企业带来法律与经济损失。

    3.2 跨系统适配与业务融合难度

    不同企业数字化建设水平差异大,部分仍使用老旧系统,部分搭建了多元化系统矩阵,各系统数据格式、接口标准不统一,导致智能体难以深度对接与适配。同时各行业、企业的业务逻辑、专属术语差异显著,通用大模型与智能体无法精准理解个性化需求,易出现解读偏差、执行错误,未进行定制化训练则难以与企业业务深度融合,无法发挥协同价值。

    3.3 大模型“幻觉”与智能体执行偏差问题

    大模型的“幻觉”问题是核心技术痛点,即对企业需求理解不充分时,会生成虚假、错误信息与决策,进而导致智能体执行偏差。如数据统计场景中,大模型对统计口径理解偏差将导致智能体提取错误数据、生成错误报告;跨部门任务分配中,对职责边界判断失误将导致任务分配错误。且智能体执行复杂任务时,单一子任务偏差会引发“蝴蝶效应”,人工排查与修正难度大。

    3.4 企业人员的技术接受度与能力适配问题

    部分员工对大模型、智能体存在认知偏差,认为其会替代自身工作,产生抵触情绪;同时现有员工缺乏与智能体协同的能力,无法精准表达需求、有效复核执行结果,导致智能体价值无法充分发挥。此外,企业内部缺乏专业的 AI 运营与维护人员,无法对大模型与智能体进行日常调试、更新优化,限制了智能体的深度落地。

    四、大模型驱动智能体落地企业数字化协同的实施策略

    4.1 技术选型:私有化部署为主,定制化训练适配

    企业落地需坚持“私有化部署为主、公有云服务为辅”原则:核心数据协同场景采用私有化部署,确保数据存储在企业自有服务器,实现全链路管控;非核心标准化场景可调用公有云大模型 API,降低投入成本。基于企业业务逻辑、专属术语、流程规范,对通用大模型进行微调与定制化训练,让其精准理解个性化需求;开发专属接口适配层,实现智能体与 OA、CRM、财务等系统的无缝对接,打破数据与流程壁垒。

    4.2 流程规范:明确协同边界,建立人工复核机制

    结合企业业务特点,明确智能体的协同边界与执行权限:数据统计、信息同步、标准化客服等低价值、重复性工作,由智能体全程自主执行;财务审批、核心业务决策、重要商务谈判等高价值、高风险工作,建立“智能体执行 + 人工复核”机制,智能体仅负责信息整理、方案生成,最终决策与执行由人工完成。制定智能体协同标准化流程,明确各部门、岗位的协同职责与要求,规范任务发起、执行、反馈流程,确保协同工作有序开展。

    4.3 安全体系:全链路管控,实现实时监控与审计

    构建全链路数据安全管控体系:建立精细化权限管控机制,按岗位、职责分配智能体操作与数据访问权限,遵循“最小权限原则”;对数据提取、传输、存储、分析全环节进行加密处理,防止数据泄露、篡改;搭建实时监控与审计系统,对智能体操作行为、数据访问记录、执行结果全程监控,异常行为立即触发预警并停止执行,所有操作记录留存可追溯、可问责。

    4.4 组织建设:强化人员培训,搭建专业 AI 运营团队

    通过多层级、多维度培训,提升员工对大模型、智能体的认知与接受度,明确其核心价值是释放人力而非替代工作,引导员工主动拥抱变革;开展针对性技能培训,提升员工精准表达需求、复核执行结果、与智能体协同工作的能力,快速适配新工作模式。搭建专业的 AI 技术运营与维护团队,成员涵盖 AI 算法工程师、大数据工程师、企业业务专家,负责大模型与智能体的日常调试、更新优化,解决执行中的技术问题,结合企业业务发展持续迭代智能体协同能力。

    4.5 落地路径:从单点试点到全流程覆盖,渐进式推广

    遵循“先易后难、从单点场景到全流程覆盖”的渐进式路径,规避技术与管理风险:首先选择数字化基础好、需求标准化程度高的场景试点,如行政信息同步、人力资源考勤统计、标准化客服接待,快速验证价值、积累经验;试点成功后,逐步推广至跨部门协同、业务流程协同等复杂场景;最终实现全流程协同深度落地,推动多智能体协同网络构建,实现不同功能智能体的联动协作。

    五、大模型与智能体融合的未来发展趋势

    5.1 单智能体向多智能体协作网络升级

    企业数字化协同将从单智能体执行向多智能体协作网络发展,企业将按业务需求部署数据处理、沟通协调、风险预警、决策支持等不同功能的智能体,各智能体通过大模型实现信息共享、任务协同、能力互补,形成智能化协同网络。如企业战略规划中,数据处理智能体提取内外部数据,风险预警智能体分析市场与行业风险,决策支持智能体生成规划方案,沟通协调智能体同步各部门并收集反馈,多智能体协同的效率与精准度远超人工。

    5.2 智能体向“人机共生”的协同模式演进

    技术的持续迭代将推动企业协同向“人机共生、优势互补”模式发展:智能体承担所有重复性、标准化、低价值协同工作,员工从繁琐日常中解脱,聚焦创意策划、战略决策、客户关系维护等高价值、非标准化工作。同时,智能体将成为员工的“个性化智能助手”,根据员工工作习惯、能力特点提供定制化工作建议与协同支持,实现人机协同的精准化与个性化,提升企业整体效率与创新能力。

    5.3 跨企业智能体协同成为行业新方向

    随着技术成熟,智能体的协同边界将从企业内部延伸至企业与企业之间,实现产业链、供应链的跨企业智能体协同。如制造企业智能体与上游原材料供应商、下游经销商智能体实时联动,生产计划、产能库存、销售数据自动同步,实现全产业链智能化协同,提升整体运行效率。

    5.4 技术门槛持续降低,普惠化趋势凸显

    未来大模型与智能体研发将向普惠化发展,头部科技企业将推出更多标准化、低代码、零代码的开发与部署平台,企业无需专业 AI 研发能力,通过简单拖拽、配置即可搭建适配自身业务的智能体,大幅降低技术与资金门槛。同时大模型“幻觉”问题将得到有效解决,智能体执行精度与可靠性持续提升,为大模型与智能体在中小企业数字化协同中的广泛落地奠定基础。

    六、行业高频 QA 问答

    6.1 大模型驱动的智能体,适合中小微企业落地吗?

    适合。中小微企业无需自建大模型,可通过调用第三方大模型 API(如 GPT-4o、文心一言 4.0)或使用低代码/零代码智能体平台(如 Coze),低成本接入智能体能力。建议优先选择标准化协同场景(如行政信息同步、标准化客服)试点,验证价值后再逐步推广,无需投入大量技术与人力成本,反而能快速解决中小微企业跨部门协同效率低、人力不足的核心痛点。

    6.2 企业落地协同智能体,需要先完成全流程数字化改造吗?

    不需要。协同智能体可适配企业现有数字化基础,支持“渐进式融合”:即使企业仅部分系统完成数字化,也可先让智能体对接现有数字化系统(如 CRM、OA),在已有数字化环节实现协同优化;未数字化的环节可通过智能体的自然语言交互、轻量化表单等功能,实现半自动化协同,后续再逐步推进全流程数字化改造,降低落地门槛。

    6.3 如何判断企业的协同场景是否适合引入智能体?

    核心判断标准有 3 点:1. 场景是否存在重复性工作(如固定格式的报表生成、标准化信息同步);2. 是否存在跨岗位/跨部门的高频沟通对接;3. 需求是否具备可明确描述的目标(如“缩短数据统计时间”“提升客户响应效率”)。满足以上任意 2 点的场景(如跨部门项目协同、客服前后端对接、业务数据汇总),引入智能体后提升效果更显著。

    6.4 协同智能体与传统 OA 系统的区别是什么?

    核心区别在于“被动响应”与“主动协同”:传统 OA 系统需人工发起流程、手动选择对接对象,仅能完成预设流程的流转记录;协同智能体可主动理解需求、自主拆解任务、自动联动跨系统与跨部门资源,无需人工干预即可推进协同落地,还能通过大模型分析数据并优化协同策略,具备更强的智能化与自主性,覆盖 OA 系统无法触达的非标准化协同场景。

    6.5 企业落地协同智能体后,员工的工作会被替代吗?

    不会完全替代,而是实现“能力升级与分工重构”。智能体仅替代重复性、标准化的协同工作(如信息同步、数据录入、简单报表生成);员工将聚焦高价值工作,如需求定义、协同策略规划、核心决策、复杂问题协调等,从“繁琐执行”转向“战略把控”,同时需要掌握与智能体协同的基础能力(如精准表达需求、复核执行结果),提升自身不可替代性。

    七、结论

    大模型与智能体的深度融合,正重构企业数字化协同的底层逻辑,从技术层面打破传统协同的信息、流程、数据壁垒,为企业提供更高效、智能、低成本的协同解决方案,成为企业数字化转型深水区的核心新引擎。

    大模型驱动的智能体落地,并非简单的技术叠加,而是企业技术、流程、组织、人员的全方位变革。企业需正视数据安全、技术适配、执行偏差等挑战,通过科学的技术选型、完善的流程规范、严密的安全体系、系统的人员培训,实现智能体的渐进式落地与深度融合。

    未来,多智能体协作网络、跨企业智能体协同将成为主流趋势,人机共生的协同模式将彻底释放企业人力价值与创新能力。对于企业而言,主动拥抱这一技术变革,构建适配自身业务的智能化协同体系,将成为提升核心竞争力、实现高质量发展的关键所在。

    八、参考文献

    [1] 斯坦福大学. AI 指数报告 2026[R]. 斯坦福大学人类与人工智能研究院,2026. [2] 中国人工智能产业发展联盟. 大模型与智能体融合应用白皮书 2026[R]. 2026. [3] 麦肯锡咨询. 企业数字化协同转型趋势与实践指南 2026[R]. 麦肯锡全球研究院,2026. [4] 腾讯云 AI 研究院. 大模型私有化部署与企业应用实践 2026[R]. 2026. [5] 字节跳动 AI 实验室. Coze 智能体平台企业协同场景应用指南 2026[R]. 2026. [6] 德勤咨询. 企业 AI 技术落地的风险管控与实施策略 2026[R]. 2026.

    “电子签章”是电子签名的一种可视化表现形式。它不仅仅是一个简单的图片,而是一套由法律背书的、具备完整密码技术的安全解决方案。可以将其理解为传统物理公章或手写签名的数字化、法律等效体。

    核心组成部分

    一个有效的电子签章通常包含两大核心部分:

    Ø 可视化的印章图片

    这就是我们通常“看到”的电子签章,外观上模仿了实体公章或签名样式。

    作用: 提供与传统方式一致的可视化确认,让人直观地知道签署方和签署位置。

    Ø 数字证书与密码技术

    这是电子签章的“灵魂”,是法律效力的关键。

    数字证书: 由依法设立的电子认证服务机构(CA机构) 颁发,相当于一个实体的“网络身份证”。它绑定了签署方的真实身份。

    数字签名: 在签署时,系统会使用与数字证书对应的私钥对文件进行运算,生成一个唯一的“数字指纹”(哈希值),并锁定文件内容。任何对文件的篡改都会导致指纹失效

    电子签章的法律效力

    在中国,电子签章具有明确的法律效力。《中华人民共和国电子签名法》 第十三、十四条明确规定:

    可靠的电子签名与手写签名或者盖章具有同等的法律效力。同时规定了何为“可靠的电子签名”,核心就是身份真实、签署意愿真实、文件原文未改、签名未改。

    满足上述条件的电子签章,在民事活动中(如合同、票据、公文)具有完全的法律效力。除了法律规定的少数特殊情况(如涉及婚姻、收养、继承的人身关系文书,以及涉及停止供水、供热、供气等公用事业服务的文书),绝大多数场景均可使用。

    电子签章是中国数字化转型中的关键一环。它不是一个简单的图片水印,而是一个集身份认证、数字签名、时间戳和存证保全于一体的完整法律和技术解决方案。它的普及极大地提升了企业运营效率,降低了成本,并确保了电子文件的法律。

    https://www.x2follow.xyz/

    hysteria2 机场注册后获取测试 utc 2026/1/22 之前注册 用户可以随机获得社区积分,积分最高$100
    2026/2/17 之前发送。系统正常测试和优化中

    未来更多的稳定的节点服务器

    积分有没有作用?
    例如可以购买可乐 🥤::)))
    等等的隐私服务,希望大家测试一下:)))

    网站使用了 python+rust 编写

    可能是最早的一批使用 Kyber1024 Dilithium5 落地应用。当然可能是,请大家多多包涵

    协议使用 抗量子破解算法编写
    聊天部分采用了 https://openquantumsafe.org/ Kyber1024
    nostr 协议部分 https://openquantumsafe.org/ Dilithium5

    未来的方向会做,例如区块链的积分和隐私为主的 web+app

    写在前面,本人目前处于求职中,如有合适内推岗位,请加:lpshiyue 感谢。同时还望大家一键三连,赚点奶粉钱。本系列已完结,完整版阅读课联系本人

    现代分布式系统的可观测性不是简单的数据收集,而是基于业务目标的智能过滤与决策体系

    在掌握了风险可控的发布策略后,我们需要解决一个更根本的问题:如何准确判断发布是否成功?如何在海量监控数据中识别真正重要的信号?全栈监控与告警设计正是连接系统状态与人工干预的关键桥梁。本文将从SLO定义出发,深入探讨监控指标体系构建、告警规则设计、分级抑制策略的全链路实践,帮助企业构建既敏感又精准的可观测体系。

    1 监控体系的哲学转变:从数据收集到价值判断

    1.1 传统监控的局限性:数据丰富而洞察匮乏

    传统监控系统面临的核心矛盾是数据收集能力价值提取效率之间的巨大鸿沟。随着微服务和云原生架构的普及,单个系统产生的指标数量呈指数级增长,但运维团队能够有效处理的告警数量基本恒定。

    监控数据的三个价值层次

    • 基础指标:CPU、内存、网络等资源消耗数据(容易收集但价值有限)
    • 应用性能:请求延迟、错误率、吞吐量等业务相关指标(需要业务埋点)
    • 用户体验:真实用户感知的可用性和性能(最难测量但最具价值)

    根据行业数据,未经验证的监控告警中超过70%属于噪音或误报,导致团队产生"告警疲劳",反而忽略真正重要的异常信号。

    1.2 SLO:监控价值的锚点

    Service Level Objective(服务等级目标)为监控系统提供了价值判断的基准。SLO将模糊的"系统健康"概念转化为可量化的目标,成为区分信号与噪音的核心依据。

    SLO的核心价值在于:

    • 目标一致性:使技术指标与业务目标对齐
    • 优先级判断:基于错误预算确定问题处理的紧急程度
    • 资源分配:根据SLO达成情况指导稳定性投入
    # SLO定义示例:API服务可用性目标
    api_service_slo:
      availability: 99.9%  # 每月最多43分钟不可用
      latency_p95: 200ms   # 95%请求延迟低于200ms
      error_rate: 0.1%     # 错误率低于0.1%
      rolling_period: 30d  # 滚动计算周期为30天

    2 全栈监控体系构建:从基础设施到用户体验

    2.1 监控数据的三位一体

    现代监控体系需要整合指标(Metrics)、日志(Logs)、追踪(Traces) 三类数据,形成完整的可观测性能力。

    指标监控提供系统量化度量,适合趋势分析和阈值告警:

    • 基础资源指标:CPU、内存、磁盘、网络(通过Node Exporter采集)
    • 应用性能指标:QPS、延迟、错误率(通过应用埋点暴露)
    • 业务指标:订单量、支付成功率、用户活跃度(自定义业务埋点)

    日志分析记录系统详细行为,用于故障排查和审计:

    • 结构化日志收集(Filebeat/Fluentd)
    • 日志聚合与检索(Elasticsearch)
    • 模式识别与异常检测(机器学习分析)

    分布式追踪提供请求全链路视角,优化性能诊断:

    • 请求级跟踪(Jaeger/SkyWalking)
    • 服务依赖拓扑自动发现
    • 瓶颈分析与链路优化

    2.2 监控数据采集的技术选型

    Prometheus生态已成为云原生监控的事实标准,其拉取模型多维数据模型特别适合动态环境。

    # Prometheus配置示例
    scrape_configs:
      - job_name: 'api-service'
        static_configs:
          - targets: ['api-service:8080']
        metrics_path: '/metrics'
        scrape_interval: 15s
        # 指标Relabeling,增强元数据
        relabel_configs:
          - source_labels: [__address__]
            target_label: __param_target
          - source_labels: [__param_target]
            target_label: instance
          - target_label: __address__
            replacement: blackbox-exporter:9115

    多数据源整合是大型系统的必然选择。Zabbix适合传统基础设施监控,Prometheus擅长云原生环境,商业方案如CloudWatch提供开箱即用体验。

    2.3 监控数据建模与存储优化

    监控数据的时序特性要求专用存储方案。Prometheus TSDB适合短期数据存储,长期存储需考虑Thanos、Cortex或M3DB等分布式方案。

    数据降采样策略对成本控制至关重要:

    • 原始数据:保留2天,15秒精度
    • 5分钟聚合数据:保留30天
    • 1小时聚合数据:保留1年
    • 日级别聚合数据:永久保留

    3 从SLO到告警规则:精准告警的数学基础

    3.1 错误预算:SLO的可操作化表达

    错误预算将SLO转化为可消耗的资源,为告警触发提供客观依据。例如,99.9%可用性目标意味着每月有43分钟错误预算。

    错误预算消耗速率(Burn Rate)成为告警的关键指标:

    • 快速燃烧:高错误率短时间消耗大量预算(需要立即处理)
    • 慢速燃烧:低错误率持续消耗预算(需要计划性修复)
    # 错误预算消耗计算
    def calculate_burn_rate(slo_target, error_rate, time_window):
        """计算错误预算消耗速率"""
        error_budget = 1 - slo_target  # 错误预算比例
        actual_consumption = error_rate * time_window
        burn_rate = actual_consumption / (error_budget * time_window)
        return burn_rate
    
    # 示例:99.9%可用性目标,1%错误率持续30分钟
    burn_rate = calculate_burn_rate(0.999, 0.01, 30)
    if burn_rate > 10:  # 消耗速率超过10倍
        trigger_critical_alert()

    3.2 多维度SLO指标映射

    不同服务需要不同的SLO定义方式,核心是建立技术指标与用户体验的直接关联。

    API服务SLO映射

    -- 基于SLI(服务等级指标)计算SLO达成率
    SELECT 
        time_bucket('1 hour', timestamp) as hour,
        -- 可用性SLI
        SUM(CASE WHEN status_code < 500 THEN 1 ELSE 0 END) * 1.0 / COUNT(*) as availability,
        -- 延迟SLI 
        PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY latency) as latency_p95,
        -- 错误率SLI
        SUM(CASE WHEN status_code >= 500 THEN 1 ELSE 0 END) * 1.0 / COUNT(*) as error_rate
    FROM api_requests 
    WHERE timestamp >= NOW() - INTERVAL '30 days'
    GROUP BY hour

    批处理服务SLO特性

    • 完整性:数据处理是否100%成功
    • 及时性:作业是否在时间窗口内完成
    • 正确性:输出结果是否符合质量要求

    3.3 告警规则的数学建模

    有效的告警规则需要基于统计学原理而非简单阈值。

    动态基线告警考虑历史模式和周期性:

    -- 基于时间序列分析的异常检测
    WITH baseline AS (
      SELECT
        AVG(latency) as historical_avg,
        STDDEV(latency) as historical_stddev
      FROM api_metrics
      WHERE time > NOW() - INTERVAL '4 weeks'
        AND hour_of_day = EXTRACT(HOUR FROM NOW())
    )
    SELECT 
      current.latency,
      (current.latency - baseline.historical_avg) / baseline.historical_stddev as z_score
    FROM current_metrics current, baseline
    WHERE ABS((current.latency - baseline.historical_avg) / baseline.historical_stddev) > 3

    多指标复合告警提高准确性:

    • 条件1:错误率 > 2%(持续5分钟)
    • 条件2:P95延迟 > 基线200%
    • 条件3:流量下降 > 30%
    • 触发条件:条件1 AND (条件2 OR 条件3)

    4 告警分级体系:避免雪崩的防御工事

    4.1 分级原则:基于业务影响而非技术症状

    告警分级的目标是确保重要告警得到及时处理,而非处理所有技术异常。分级应基于业务影响程度而非技术严重性。

    四级分类体系在实践中证明有效:

    • P0(紧急):业务核心功能不可用,影响大量用户(立即呼叫)
    • P1(高):功能降级或部分用户受影响(2小时内处理)
    • P2(中):潜在问题或边缘功能异常(24小时内处理)
    • P3(低):轻微异常或需要观察(无需立即处理)

    4.2 智能抑制与降噪策略

    告警抑制是避免告警雪崩的关键技术。

    层级抑制确保只收到根本原因告警:

    # Alertmanager抑制规则示例
    inhibit_rules:
      - source_match:  # 源告警(更严重)
          severity: 'critical' 
        target_match:  # 目标告警(被抑制)
          severity: 'warning'
        equal: ['cluster', 'alertname']  # 相同集群和告警名称

    时间窗口聚合将相关告警合并发送:

    # Alertmanager路由配置
    route:
      group_by: ['cluster', 'alertname']
      group_wait: 10s  # 初始等待时间
      group_interval: 1m  # 同一组告警发送间隔
      repeat_interval: 4h  # 相同告警重复发送间隔

    动态静默基于条件自动抑制已知问题:

    -- 智能静默规则示例
    CREATE RULE auto_silence_maintenance 
    WHEN alert_name = 'NodeDown' 
    AND description LIKE '%for maintenance%'
    DO SILENCE FOR 2h;

    4.3 分级通知渠道与升级策略

    不同级别的告警需要不同的通知强度和升级路径

    通知渠道矩阵

    严重等级即时通知1小时内未确认4小时内未解决
    P0电话+短信+钉钉升级主管升级总监+运维总监
    P1钉钉+短信升级团队主管升级部门主管
    P2钉钉每日站会同步周报汇总
    P3工单系统每周评审月度优化

    人性化通知内容提升响应效率:

    {
      "alert_id": "API_HIGH_ERROR_RATE_20250115",
      "title": "【P1】订单服务错误率超过阈值",
      "summary": "订单服务错误率在5分钟内从1%上升到5%,已消耗15%错误预算",
      "impact": "可能导致0.1%用户下单失败,预计影响金额5万元/小时",
      "actions": [
        "1. 检查订单服务日志:https://logs.company.com/order-service",
        "2. 查看相关监控:https://grafana.company.com/d/order-overview",
        "3. 最近部署:订单服务v1.2.3(2小时前部署)"
      ],
      "runbook": "https://runbook.company.com/order-service-high-error-rate",
      "slo_impact": "错误预算消耗速率:3倍(正常阈值:1倍)"
    }

    5 全栈监控实战:从配置到优化的完整流程

    5.1 监控即代码:声明式配置管理

    将监控配置版本化,实现可重复、可审计的监控体系。

    Prometheus规则即代码

    # api_service_alerts.yml
    groups:
    - name: api_service
      rules:
      - alert: APIHighErrorRate
        expr: |
          # 基于错误预算的智能告警
          sum(rate(api_requests_total{status=~"5.."}[5m])) by (service)
          / 
          sum(rate(api_requests_total[5m])) by (service)
          > 0.05  # 5%错误率阈值
        for: 5m
        labels:
          severity: critical
          service: api-gateway
        annotations:
          summary: "{{ $labels.service }} 错误率超过5%"
          description: "服务 {{ $labels.service }} 当前错误率为 {{ $value }},已持续5分钟"
          runbook: "https://runbook.company.com/api-high-error-rate"

    Dashboard即代码(JSON配置)确保监控视图一致性:

    {
      "dashboard": {
        "title": "订单服务监控",
        "tags": ["microservice", "order"],
        "timezone": "browser",
        "panels": [
          {
            "title": "API成功率",
            "type": "graph",
            "targets": [
              {
                "expr": "sum(rate(orders_api_requests_total{status=~'2..'}[5m])) / sum(rate(orders_api_requests_total[5m]))",
                "legendFormat": "成功率"
              }
            ]
          }
        ]
      }
    }

    5.2 监控自愈与自动化响应

    自动化响应逐步降低人工干预需求。

    基于严重程度的自动化策略

    def evaluate_autoremediation(alert):
        """评估是否适合自动修复"""
        if alert.severity == "critical":
            if alert.metric == "cpu_usage" and alert.value > 90:
                return scale_out(alert.service, factor=1.5)
            elif alert.metric == "memory_usage" and alert.value > 95:
                return restart_pod(alert.pod_name)
        return None

    渐进式应急响应

    1. Level 1:自动扩容/重启(无状态服务)
    2. Level 2:流量切换/降级(有状态服务)
    3. Level 3:人工决策介入(数据敏感操作)

    5.3 监控效能度量与持续优化

    监控系统本身需要被监控和优化。

    关键效能指标

    • 告警准确率:有效告警比例(目标>90%)
    • 平均检测时间(MTTD):异常发生到告警的时间(目标<1分钟)
    • 平均响应时间(MTTR):告警到修复的时间(目标<15分钟)
    • 告警疲劳指数:人均每日处理告警数(目标<5条)

    定期健康度评估

    -- 监控系统健康度SQL查询
    SELECT
      DATE(timestamp) as day,
      COUNT(*) as total_alerts,
      SUM(CASE WHEN acknowledged = true THEN 1 ELSE 0 END) as acknowledged_alerts,
      AVG(acknowledge_time - trigger_time) as avg_ack_time,
      PERCENTILE_CONT(0.95) WITHIN GROUP (ORDER BY acknowledge_time - trigger_time) as p95_ack_time
    FROM alerts
    WHERE timestamp >= NOW() - INTERVAL '30 days'
    GROUP BY day
    ORDER BY day;

    6 组织协同与文化建设

    6.1 监控责任共担模型

    监控不是运维团队的独角戏,而需要全组织协同

    三级责任模型

    • 平台团队:负责监控基础设施稳定性和通用指标
    • 业务团队:负责业务指标和SLO定义
    • SRE团队:负责SLO达标和错误预算管理

    监控素养培养

    • 新员工监控工具培训
    • 定期监控案例分享会
    • 监控配置代码审查

    6.2 监控质量内建流程

    将监控要求嵌入开发流程,而非事后补丁。

    开发阶段检查清单

    • [ ] 应用暴露必要的监控指标
    • [ ] 定义清晰的SLO和目标
    • [ ] 设计告警规则和响应流程
    • [ ] 准备运维手册和排查指南

    部署流水线集成

    # CI/CD中的监控校验
    - name: Validate Monitoring
      steps:
        - name: Check Metrics Exposure
          run: |
            curl -s http://$APP_URL/metrics | grep -q "http_requests_total"
        - name: Validate SLO Definition
          run: |
            python scripts/validate_slo.py --manifest slo/manifest.yaml

    总结

    构建有效的全栈监控与告警体系是一个持续演进的过程,需要技术、流程和文化的协同发展。从SLO定义到告警规则,再到分级抑制策略,每一层都需要精心设计和不断优化。

    成功监控体系的核心特征

    1. 业务对齐:监控指标与业务目标紧密关联
    2. 精准告警:基于SLO和错误预算的智能触发
    3. 分级处理:重要信号优先处理,噪音自动抑制
    4. 持续优化:定期评估效果并迭代改进

    避免的常见反模式

    • 监控指标丰富但缺乏业务关联
    • 告警数量庞大但有效信号稀少
    • 响应流程冗长但解决效率低下
    • 工具堆砌但缺乏整体设计

    监控的终极目标不是收集更多数据,而是提供更好的决策支持。通过本文介绍的方法论和实践,团队可以构建既能够及时发现真实问题,又避免告警雪崩的高效监控体系。


    📚 下篇预告
    《压力测试方法论——目标设计、场景建模、指标评估与容量规划的完整闭环》—— 我们将深入探讨:

    • 🎯 目标制定:基于业务目标的压测场景设计与成功标准定义
    • 📊 场景建模:真实流量模拟、异常场景构造与容量边界探测
    • 📈 指标体系:性能基线、瓶颈识别与容量规划的数据基础
    • 🔄 优化闭环:从性能测试到系统调优的持续改进机制
    • 🏗️ 容量规划:基于压测结果的资源预估与扩容策略

    点击关注,掌握系统性能评估与容量规划的完整方法论!

    今日行动建议

    1. 评估当前监控体系的告警准确率,识别主要噪音来源
    2. 为关键服务定义明确的SLO和错误预算消耗机制
    3. 实施告警分级策略,建立基于业务影响的分级体系
    4. 配置告警抑制规则,减少重复告警和告警雪崩
    5. 建立监控效能度量机制,持续优化告警质量

    本月可观测热文回顾

    文章一览:

    构建数据资产“导航地图”:详解 UModel 数据发现与全链路分析能力

    基于 UModel 高效构建可观测场景统一实体搜索引擎

    揭开 Java 容器“消失的内存”之谜:云监控 2.0 SysOM 诊断实践

    打通可观测性的“任督二脉”:实体与关系的终极融合

    一行代码实现智能异常检测:UModel PaaS API 架构设计与最佳实践

    一文带你玩转 WebSocket 全链路可观测

    Android 崩溃监控实战:一次完整的生产环境崩溃排查全流程

    已上线!云监控 2.0 面向实体的全链路日志审计与风险溯源

    阿里云操作系统控制台一招解决网络丢包

    加入我们,一起定义「Data x AI」的未来

    iOS 崩溃排查不再靠猜!这份分层捕获指南请收好

    跨云日志统一:对象存储数据导入 SLS 的智能之路

    拒绝查询超时:一次真实高并发场景下的 SLS 物化视图调优实战

    阿里云可观测联合 Datadog 发布 OpenTelemetry Go 自动插桩工具

    功能快报

    image

    点击此处,了解更多产品详情。

    大家好,我是《交易学徒》的独立开发者。

    最近在重构后端行情网关,目标是支撑 10w+ 同时在线用户。在技术选型时,很多“标准答案”是微服务、Redis 集群、Kafka 消息队列。但作为独立开发者,维护这一套重型架构的运维成本和心智负担太高了。

    于是我反其道而行之,选择了一种“极致单机”的方案:没有任何外挂组件( No Redis, No Kafka ),所有状态在进程内解决,纯 Rust 函数调用。

    经过实战验证,这套架构不仅部署简单(就一个 Binary ),而且足够稳定。今天分享一下我是如何用 Rust 的特性“白嫖”性能的,欢迎 V 友们拍砖。

    一、 核心理念:按需订阅,算一笔带宽的账
    早期的 demo 喜欢大包大揽,客户端连上来就推 Top 20 币种。这在用户量大时是灾难。我的做法是“用户看哪里,就只推哪里”

    客户端停留在 BTC/USDT 的 15 分钟 K 线界面,服务端就只建立这一个订阅关系。一旦切换,立马移除旧订阅。

    算一笔账( Resource Cost ): 假设一个行情包 Payload 是 200 Bytes ,推送频率 5 次/秒。

    全量推送(推 Top 20 ):10 万用户 x 20 个币种 x 200B x 5 = 2 GB/s (带宽直接破产)。

    按需订阅(推 1 个):10 万用户 x 1 个币种 x 200B x 5 = 100 MB/s 。

    结论: 简单的逻辑改变,带宽节省 95%,单机千兆网卡轻松抗住。

    二、 列表行情:Polling + 边缘计算(白嫖 CF )
    对于“行情列表”这种一屏显示几十个数据的页面,建立长连接维护成本太高。 我采用了 1 秒轮询 + Cloudflare 边缘缓存 的策略。

    策略: 设置 HTTP 响应头,让 CF Edge Cache TTL = 1 秒。

    效果:10 万人同时刷新列表,99% 的流量被 CF 的全球节点挡住了,真正打到我源服务器 Rust 进程的 QPS 只有个位数。

    收益: 既利用了 CDN 的带宽,又保护了单机后端。

    三、 架构做减法:进程内通信替代中间件
    这是我这次重构最大的感悟:单机并发足够高时,不需要 Redis 和 Kafka 。

    替代 Redis: 使用 Rust 的 DashMap (Concurrent HashMap)。数据就在内存里,读写是纳秒级,没有网络 IO 开销,没有序列化/反序列化成本。

    替代 Kafka: 使用 tokio::sync::broadcast 和 mpsc::channel 。

    优势: 传统的“发布-订阅”为了解耦上了 MQ ,但在单机 Rust 里,一个 Arc<Channel> 就能解决问题。部署时不需要操心 MQ 挂没挂,只要我的进程活着,消息系统就活着。

    四、 信使模式 (Messenger Pattern) 与背压
    在 Tokio 异步编程中,最忌讳 await 阻塞。 如果客户端网络卡顿(比如进电梯),socket.send().await 可能会阻塞,导致同个 Loop 下的心跳包处理被卡死,造成“假死”。

    我的解法:

    读写分离: 为每个连接 spawn 一个独立的 send_task ,通过 mpsc::channel(128) 通信。

    严格背压 (Backpressure): 使用 try_send 。如果 Channel 满了(说明客户端来不及收),直接丢弃新行情。

    理由: 实时行情旧数据无价值。这行代码是系统的“保命符”,防止慢客户端拖垮服务端内存( OOM )。

    五、 极致性能:Zero-Copy (零拷贝)
    在广播行情时,不要为 10 万个用户 copy 10 万份数据。

    Rust
    // 内存中只有一份二进制 Payload
    let payload = Arc::new(Bytes::from(vec![...]));

    // 10 万次分发只是增加了 10 万次引用计数( Reference Counting )
    // 几乎没有任何内存分配开销
    for client in clients {
    client.tx.try_send(payload.clone());
    }
    利用 Rust 的 Arc 和 Bytes ,让 CPU 缓存极其友好。
    六、 扫地僧:资源清理
    长运行的单机服务最怕内存泄漏。 当 socket 断开时,必须像外科手术一样精准清理:

    从 DashMap 移除 Client 。

    清理反向索引 subscriptions 。

    如果某个 Topic 无人订阅,立即 drop 掉对应的 channel 发送端,停止上游数据生产。

    总结
    作为独立开发者,资源有限。这套“Rust 单机 + 无外挂组件”的架构,让我用最低的成本(一台服务器)抗住了业务压力,而且睡得很安稳。

    Simplicity is the ultimate sophistication.

    🎁 V 友专属福利
    软件名字叫 《交易学徒》,是一个辅助交易员复盘、模拟、练盘感的工具。前端也是我用 Flutter 写的( Rust + Flutter 真是全栈开发的绝配)。

    官网下载: https://www.zgjiazu.top

    Google Play: https://play.google.com/store/apps/details?id=com.zengkai.jyxtclient

    回帖福利: 在本帖回复并附上 App 内的 ID (在‘我的页面’可以看到),我后台人肉送一个月 VIP 会员。

    同时也欢迎大家在评论区提 Bug ,或者交流关于 Rust 后端与 Flutter 前端开发的坑!

    2libra 没有自带的图片上传功能,昨天看到 一个帖子 后突然来了灵感,
    把之前做的 v2ex 脚本中的图片上传功能抽离出来,做了一个通用的图片上传脚本。

    主要功能

    • 支持在所有网站使用。(需要配置 match 规则)
    • 对 2libra, v2ex, nodeseek, deepflood, greasyfork.org 做了适配,显示“插入图片”按钮。其他网站可以自己添加规则。
    • 保存图片上传记录,可以重复利用上传过的图片。
    • 目前支持上传到 Imgur,后续会支持更多图床。
    • 可以批量上传,支持粘贴、拖拽、文件选择收集图片。

    2025-10-22-21-23-13
    2025-10-22-21-09-33

    🔗 安装链接

    项目地址: https://github.com/utags/userscripts

    目前 是第一个也是唯一一个 2libra 的油猴脚本

    本文由TinyPro贡献者王晨光同学原创。

    一、背景:让 TinyPro 真正“走到掌心里”

    TinyPro 是一套基于 TinyVue 打造的前后端分离后台管理系统,支持菜单配置、国际化、多页签、权限管理等丰富特性。
    TinyPro 在桌面端具备良好的体验和模块化架构,但随着移动办公、平板展示等场景增多,移动端体验的短板逐渐显现:

    • 页面缩放不均衡,布局出现溢出或错位;
    • 模态框在小屏上遮挡内容;
    • 图表和表格在横屏与竖屏间切换时无法自适应;
    • 操作区过于密集,不符合触控习惯。

    为此启动了 TinyPro 移动端适配项目,目标是在不破坏现有结构的前提下,实现“一次开发,跨端流畅”的体验。

    二、技术选型与总体架构

    本次移动端适配要求在复杂的中后台系统中实现「一次开发,多端自适应」,既要保证样式灵活,又要维持可维护性和构建性能。

    在技术选型阶段,综合评估了三种常见方案:

    方案优点缺点
    纯 CSS 媒体查询简单直接、依赖少样式分散、逻辑重复、维护困难
    TailwindCSS 响应式类社区成熟、类名直观、生态完善样式表体积大、断点固定、不够灵活
    UnoCSS 原子化方案按需生成、性能极轻、断点与变体完全可定制需要自行配置规范与规则体系

    最终选择了 UnoCSS + Less 的混合架构

    • UnoCSS:负责通用布局、间距、排版等高频样式,原子化写法提升开发效率;
    • Less 媒体查询:用于模态框、导航栏等复杂场景的精细控制;
    • 统一断点配置:集中管理屏幕尺寸分级,保持视觉一致性;
    • 自定义变体(max-<bp>:支持“桌面端优先”策略,通过 max-width 实现移动端自适应,样式逻辑更直观。

    UnoCSS:轻量、灵活、即时生成

    UnoCSS 是一个 按需生成的原子化 CSS 引擎,最大的特点是 零冗余与高度可定制
    不同于 TailwindCSS 的预编译方式,UnoCSS 会在构建阶段根据实际使用的类名即时生成样式规则,从而显著提升构建性能与灵活性.

    在配置中通过 presetMini()presetAttributify() 组合使用,使开发者既可以写:

    <div class="p-4 text-center bg-gray-100 max-md:p-2"></div>

    也可以使用属性化语法:

    <div p="4" text="center" bg="gray-100" max-md:p="2"></div>

    presetMini 提供轻量原子类体系,presetAttributify 则允许以声明式方式书写样式,更直观、组件化友好。

    断点配置与响应式策略

    TinyPro 的适配核心之一,是在 uno.config.ts 中建立统一的断点体系,并通过自定义 max-<bp> 前缀实现“桌面端优先”的响应式策略。

    const breakpoints = {
      sm: '641px',     // 手机(小屏)
      md: '769px',     // 平板竖屏
      lg: '1025px',    // 平板横屏 / 小型笔电
      xl: '1367px',    // 常规笔电
      '2xl': '1441px', // 高清笔电
      '3xl': '1921px', // 桌面大屏
    }

    并通过自定义 variants 扩展 max-<bp> 前缀:

    variants: [
        (matcher) => {
          const match = matcher.match(/^max-([a-z0-9]+):/)
          if (match) {
            const bp = match[1]
            const value = breakpoints[bp]
            if (!value) return
            return {
              matcher: matcher.replace(`max-${bp}:`, ''),
              parent: `@media (max-width: ${value})`,
            }
          }
        },
      ]

    让开发者能自然地书写:

    <div class="w-1/2 max-md:w-full"></div>

    含义:

    默认宽度为 50%,在宽度小于 769px 的设备上改为 100%。

    TinyPro 采用「桌面端优先(max-width)」的布局策略:默认以桌面端布局为基础,在移动设备上再进行针对性优化。相比常见的「移动端优先(min-width)」方式,这种做法更符合中后台系统的特性,同时让 UnoCSS 的断点逻辑更直观,并确保主屏体验的稳定性。

    三、样式与编码策略

    • 优先级

      • 简单场景:使用 UnoCSS 原子类。
      • 复杂样式:使用 Less 媒体查询。
    • 布局与滚动

      • 首页及核心业务模块完成适配,小屏模式下侧边栏默认收起、导航栏折叠,确保主要内容可见。
      • 页面主要容器避免横向滚动,必要时在小屏下开启局部横向滚动。
      • 表格与大区块在不同断点下自动调整宽度、栅格与间距,小屏下支持横向滚动;分页与密度支持响应式控制。

      布局与滚动.gif

    • 图表自适应

      • 图表组件接入 resize 监听,在侧边栏展开/收起、窗口缩放、语言切换等场景下保持自适应。
      • 小屏下使用 vw 宽度与较小字号,保证图表展示效果与可读性。

      图表自适应.gif

    • 表单与模态框

      • 接入 useResponsiveSize(),控制弹窗在小屏下铺满显示,大屏保持固定宽度。
      • 表单项在不同断点下动态调整排布与间距,优化触控体验。

      表单与模态框.gif

    • 导航与交互

      • 小屏下隐藏导航栏非关键元素,操作聚合到"折叠菜单"。
      • 移动端默认收起侧边菜单栏,提升主要内容展示区域。

      导航与交互.gif

    • 性能优化

      • responsive.ts 中对 resize 事件处理增加节流机制,避免窗口缩放等场景下的频繁无效渲染。

    四、常用代码片段

    1. 基于栅格系统 + 响应式断点工具类,通过为 tiny-row 和 tiny-col 添加不同屏幕宽度下的样式规则,实现自适应布局:
    <tiny-layout>
        <tiny-row class="flex justify-center max-md:flex-wrap">
            <tiny-col class="w-1/4 max-md:w-1/2 max-sm:w-full max-md:mb-4">···</tiny-col>
            ···
            <tiny-col class="w-1/4 max-md:w-1/2 max-sm:w-full max-md:mb-4">···</tiny-col>
        </tiny-row>
    </tiny-layout>
    
    <div class="theme-line flex max-sm:grid max-sm:grid-cols-4 max-sm:gap-2">
      <div···
      </div>
    </div>
    1. 基于 响应式工具类 + 自定义响应式 Hook,解决(1)对话框宽度自适应;(2)表格尺寸和密度自适应;(3)逻辑层响应式控制
    <template>
      <section class="p-4 sm:p-6 lg:p-8 max-sm:text-center">
        <tiny-dialog :width="modalSize">...</tiny-dialog>
      </section>
    </template>
    
    <script setup lang="ts">
    import { useResponsiveSize } from '@/hooks/responsive'
    const { modalSize } = useResponsiveSize() // 小屏 100%,大屏 768px
    </script>
    <template>
      <div class="container">
        <tiny-grid ref="grid" :fetch-data="fetchDataOption" :pager="pagerConfig" :size="gridSize" :auto-resize="true" align="center">
          ···
        </tiny-grid>
      </div>
    </template>
    
    <script setup lang="ts">
    import { useResponsiveSize } from '@/hooks/responsive'
    const { gridSize } = useResponsiveSize() // 小屏为mini grid,大屏为medium grid
    </script>
    1. 通过 useResponsive 获取屏幕断点状态 sm/md/lg,如:在模板中结合 v-if="!lg" 控制分隔线的渲染,从而实现了小屏下纵向菜单才显示分隔线的效果
    <template>
      <ul class="right-side" :class="{ open: menuOpen }">
        <!-- 小屏下才显示分隔线 -->
        <li v-if="!lg">
          <div class="divider"></div>
        </li>
        ···
      </ul>
    </template>
    
    <script lang="ts" setup>
    import { useResponsive } from '@/hooks/responsive'
    const { lg } = useResponsive()
    </script>

    五、结语

    通过本次移动端适配, TinyPro 实现了“从桌面到掌心”的统一体验:
    开发者可以继续沿用熟悉的组件体系与布局方式,同时享受 UnoCSS 带来的原子化灵活性与性能优势。在不改变核心架构的前提下,TinyPro 变得更轻盈、更顺滑,也更符合移动时代的使用场景。

    关于OpenTiny

    欢迎加入 OpenTiny 开源社区。添加微信小助手:opentiny-official 一起参与交流前端技术~
    OpenTiny 官网:https://opentiny.design
    OpenTiny 代码仓库:https://github.com/opentiny
    TinyPro源码:https://github.com/opentiny/tiny-pro

    欢迎进入代码仓库 Star🌟TinyPro、TinyEngine、TinyVue、TinyNG、TinyCLI、TinyEditor
    如果你也想要共建,可以进入代码仓库,找到 good first issue标签,一起参与开源贡献\~

    iOS沙盒的封闭性从来都不是简单的权限隔离,而是一套贯穿运行时的上下文绑定机制,Python在其中的适配困境,本质上是解释型语言的动态特性与iOS静态执行规范的底层冲突。很多开发者初期仅关注文件访问限制,却在实际操作中陷入模块加载失败、依赖库兼容失衡、系统调用无响应等隐性陷阱,这些问题背后,是沙盒对执行环境的深度管控——从二进制文件格式到内存分配规则,从代码签名校验到资源调度优先级,每一项都与桌面端的Python运行逻辑存在本质差异。真正的适配高手,往往是在理解沙盒底层设计逻辑后,通过重构执行环境的适配路径,让Python的动态优势在静态约束中找到生存空间,这种平衡术既需要对iOS系统架构的深刻认知,也依赖对Python解释器内核的灵活改造。在长期的适配实践中,我发现多数开发者的误区在于将沙盒限制等同于“功能阉割”,实则沙盒的核心是建立一套可预期的执行边界,Python的适配并非被动妥协,而是主动构建与这套边界兼容的运行体系。例如,当遇到解释器无法加载系统动态库时,并非简单替换库文件就能解决,而是需要追溯沙盒对动态链接路径的映射规则,通过静态编译将依赖库嵌入解释器二进制文件,同时调整链接符号的查找逻辑,这种底层改造才能从根本上解决兼容性问题,而这一过程需要开发者同时具备系统底层知识与Python解释器原理认知,缺一不可。

    沙盒对Python运行时的核心限制,集中体现在解释器与系统内核的适配断层上。iOS基于达尔文内核构建的执行体系,要求所有运行代码必须符合特定的二进制格式,且需经过严格的签名校验,而Python作为解释型语言,其传统运行模式依赖动态加载解释器与脚本文件,这种特性与iOS的静态执行要求形成天然矛盾。更隐蔽的是,沙盒会对进程的内存空间进行隔离划分,Python解释器在分配内存时,既无法访问系统级的共享内存区域,也难以与原生应用形成有效的内存交互,导致数据流转效率低下。同时,系统对动态链接库的加载路径有着强制约束,Python标准库中部分依赖系统级动态库的模块,在沙盒环境中会因路径无法识别而失效,这种失效并非模块本身不存在,而是加载机制与沙盒的路径映射规则不兼容。应对这一困境,不能仅停留在表面的模块替换,而需要通过静态编译将解释器与核心依赖打包为符合要求的二进制格式,同时重构模块加载逻辑,让Python脚本的执行流程与沙盒的内存分配、路径映射规则形成对齐。在实践中,我曾尝试使用常规打包工具将Python解释器移植到沙盒,结果发现解释器虽能启动,但调用涉及系统调用的模块时频繁失效,后来通过拆解达尔文内核的执行流程,发现沙盒会对进程的动态链接行为进行拦截,只有符合特定签名与路径规则的库文件才能被加载。基于这一发现,我通过定制化编译脚本,将Python核心依赖库与解释器打包为单一二进制文件,同时修改解释器的模块查找逻辑,让其优先从内置路径加载模块,而非依赖系统共享库,这一改造让解释器的兼容性提升了近八成,也让我深刻意识到,沙盒适配的核心是让Python的运行逻辑“嵌入”iOS的执行体系,而非独立于系统之外。

    二进制扩展模块的框架化转换,是Python在iOS沙盒中实现功能扩展的关键路径,也是最容易被忽视的深层适配环节。iOS要求所有二进制模块必须以独立框架的形式存在于指定目录下,且每个框架只能包含一个二进制文件,这种规范与Python传统的模块加载方式完全相悖——后者允许从任意路径加载扩展模块,无需特定的目录结构与元数据配置。这意味着,普通的Python扩展模块若要在沙盒中运行,必须经过复杂的后期处理:不仅要将原始二进制文件封装为符合标准的框架,还要通过特定的标记文件建立模块导入路径与框架位置的映射关系,同时确保框架包含完整的签名信息与元数据。更关键的是,这种转换并非简单的文件格式变更,而是需要调整模块的依赖引用方式,让模块在加载时能够通过沙盒的路径校验与权限审核。实践中,开发者需要借助专门的工具链处理依赖剥离与框架封装,同时手动配置元数据文件,确保模块的导入路径与沙盒的目录结构形成逻辑闭环。我曾为了让一个图像处理类扩展模块在沙盒中运行,花费了近两周时间进行框架化转换,初期直接将二进制文件放入框架目录,结果模块导入时提示“路径未授权”,后来排查发现,iOS框架不仅要求特定的目录结构,还需要在Info.plist文件中配置模块的导入路径映射,且二进制文件必须包含与应用一致的签名信息。通过工具链剥离模块的外部依赖,手动编写Info.plist文件中的路径映射规则,再使用开发者证书对框架进行签名,最终实现了模块的成功导入。这一过程让我明白,沙盒对扩展模块的约束本质上是对“执行单元”的标准化要求,只有让Python模块符合iOS的框架规范,才能获得沙盒的权限认可,而这种转换需要同时掌握Python模块编译原理与iOS框架开发规范,是技术跨界融合的具体体现。

    沙盒环境下Python标准库的隐性缺失,需要通过“功能等效重构”而非简单的库替换来解决。iOS中的Python运行环境并非完整移植桌面端的标准库,而是存在诸多基于系统安全与资源限制的省略,例如部分涉及系统底层调用、网络服务端功能的模块会被默认禁用,这种缺失并非技术疏漏,而是沙盒对应用功能边界的强制界定。很多开发者会尝试寻找第三方替代库,却发现多数库要么依赖被禁用的系统调用,要么因体积过大导致沙盒内资源占用超标。真正有效的应对策略,是基于沙盒允许的功能范围进行功能等效重构:对于数据处理类模块,可通过拆分计算逻辑、优化算法复杂度,在原生支持的轻量级模块基础上实现等效功能;对于网络相关功能,可借助iOS原生框架提供的网络能力进行桥接,而非依赖Python的网络模块;对于文件操作类功能,则需要严格遵循沙盒的目录访问规则,通过自定义数据序列化方式替代传统的文件读写逻辑。在一次数据可视化项目的适配中,我需要使用Python的绘图模块生成图表,但该模块依赖的系统图形库在沙盒中被禁用,直接使用第三方替代库又会导致应用体积超标。为此,我拆解了绘图模块的核心功能,将复杂的绘图逻辑拆分为基础图形绘制、数据映射、色彩渲染三个步骤,基于Python内置的数学模块实现坐标计算,通过iOS原生的图形框架提供的绘制接口完成图形渲染,最终在不依赖外部库的情况下实现了等效功能,且应用体积控制在合理范围。这一实践让我深刻体会到,沙盒环境下的功能重构并非“削足适履”,而是通过对核心功能的本质拆解,找到与系统规则兼容的实现路径,这种重构能力不仅能解决标准库缺失的问题,更能提升代码的轻量化与兼容性,是Python在移动环境中长期生存的关键。

    Python与iOS原生应用的交互壁垒,根源在于沙盒的上下文权限隔离,突破这一壁垒需要构建“语义对齐的桥接层”。沙盒不仅隔离了文件与内存资源,更隔离了不同应用的运行上下文,Python脚本若要调用iOS的原生功能,不仅需要通过桥接工具实现语法层面的交互,更需要解决上下文权限的传递问题——原生API的调用往往依赖特定的应用权限与运行状态,而Python解释器的运行上下文在沙盒中处于独立状态,直接调用会因权限不匹配而失败。此外,两种环境的数据类型与内存管理机制存在本质差异,Python的动态数据类型在传递给原生应用时,若未经过适当的类型转换与生命周期绑定,极易导致资源泄漏或交互失效。应对这一问题,需要构建一层专门的桥接逻辑,该逻辑不仅负责数据类型的转换,更要实现权限上下文的传递与同步:在调用原生API前,桥接层需先校验沙盒赋予的权限范围,确保调用行为符合安全规范;在数据传递过程中,需同步两种环境的内存管理规则,避免出现数据悬空或重复释放的情况;在交互完成后,需及时清理桥接层的中间资源,确保沙盒内的资源占用处于合理范围。我曾在一个交互项目中尝试让Python脚本调用iOS的相机功能,初期使用常规桥接工具直接调用API,结果因权限上下文不匹配导致调用失败,且出现内存泄漏问题。后来通过分析沙盒的权限传递机制,在桥接层中加入了权限校验模块,先通过原生应用获取相机权限,再将权限上下文传递给Python解释器,同时设计了数据类型转换池,对Python的动态数据进行定型处理后再传递给原生API,最后通过生命周期绑定机制确保内存资源的及时释放。这一改造不仅解决了交互失效问题,还将内存占用降低了约40%,让我认识到,Python与iOS原生应用的交互核心并非语法层面的对接,而是上下文与资源管理规则的对齐,桥接层的价值就在于构建一套“翻译机制”,让两种不同技术体系的运行逻辑实现语义互通。

    iOS沙盒中Python适配的长期演进,依赖于“解释器定制化”与“系统规则适配”的双向优化。随着iOS系统的不断更新,沙盒的安全规则与执行规范也在持续迭代,传统的适配方案往往会因系统版本升级而失效,这就要求开发者不能满足于静态的适配策略,而需要建立动态的适配体系。解释器定制化是关键方向之一,通过裁剪Python解释器的内核功能,保留沙盒环境中必要的执行逻辑,去除依赖系统底层调用的冗余模块,可显著提升解释器与沙盒的兼容性;同时,针对iOS的内存管理机制优化解释器的垃圾回收策略,可有效降低资源占用,避免因内存不足导致的执行中断。另一方面,需要建立对系统规则的动态追踪机制,及时掌握沙盒权限配置、二进制格式要求、审核规范等方面的变化,提前调整适配方案。更高级的适配思路是让Python脚本具备环境感知能力,通过检测当前沙盒的权限范围、系统版本、资源配额,自动调整执行逻辑与资源占用策略,实现“自适应式运行”。在长期的适配实践中,我建立了一套解释器定制化模板,通过脚本自动化裁剪解释器内核,保留核心执行模块与轻量级标准库,同时集成了系统规则检测模块,让脚本在启动时自动扫描沙盒环境参数,根据检测结果调整模块加载策略与内存分配方案。

    Android生态的硬件碎片化与Python解释型语言的执行特质,构成了性能优化的底层矛盾——这并非简单的代码精简或资源压缩所能破解,而是要深入两者运行逻辑的核心,实现从指令执行到资源调度的全链路协同。多数开发者在Android平台部署Python应用时,极易陷入“表层调优”的误区,过度纠结于脚本执行速度的零散提升,却忽视了ART虚拟机的字节码转换损耗、Python解释器与系统资源调度的节奏错位、跨层数据交互的隐性开销、硬件架构适配的精准度不足等深层问题。真正的性能突破,始于对Android运行时环境的本质认知:从不同CPU架构(ARMv8、x86等)的指令集差异到内存层级(高速缓存、物理内存、虚拟内存)的数据流转规律,从进程调度的优先级动态调整规则到原生能力调用的底层效率,每一个环节都暗藏着未被挖掘的优化空间。实践反复证明,只有让Python的动态执行逻辑与Android的静态资源管理体系形成“同频共振”,通过重构执行路径、优化资源分配策略、打通跨层交互壁垒、适配硬件特性,才能实现从“勉强运行”到“高速响应、低耗运行”的质变,这种底层逻辑的深度融合与动态协同,正是Android Python性能优化的核心要义,也是区分普通开发者与优化高手的关键所在。

    Python解释器在Android平台的运行效率瓶颈,根源在于解释器内核与Android硬件架构、系统调度机制的适配断层,这种断层并非单一因素导致,而是多重逻辑冲突的叠加。不同品牌、不同价位的Android设备,其CPU架构存在显著差异,ARMv8架构的指令集精简高效,而x86架构则侧重兼容性,默认Python解释器的指令解析模块多为通用设计,未针对特定架构进行优化,导致在ARMv8设备上出现指令执行冗余,在x86设备上则因指令转换产生额外开销。同时,Android设备的内存层级缓存策略各不相同,部分中低端设备的高速缓存容量有限,而Python解释器的内存访问逻辑未考虑缓存命中率,频繁出现缓存失效,导致内存访问效率低下。更关键的是,Android的进程调度机制会根据应用的生命周期状态(前台、后台、休眠)动态分配CPU资源,而Python解释器的默认线程管理逻辑是独立于系统调度的,往往在应用进入后台后仍维持高资源占用,引发系统资源竞争,或在前台高负载运行时因CPU资源分配不足导致卡顿。应对这一困境,核心思路是对Python解释器进行“架构化定制”而非“通用化改造”:针对目标设备的CPU指令集,裁剪解释器内核中冗余的指令解析模块,保留与该架构高度兼容的核心执行逻辑,甚至对关键指令的解析流程进行重写,让指令执行更贴合硬件特性;同时优化解释器的线程调度模型,通过调用Android系统API感知应用的生命周期状态,在前台交互场景下自动提升线程优先级以保障响应速度,在后台运行时则降低线程调度频率、释放非必要资源,主动适配系统调度规则。在长期的实践探索中发现,经过架构化定制的解释器,在ARMv8架构的中高端Android设备上,指令执行效率提升近五成,内存占用降低三成,而在x86架构的平板设备上,兼容性未受影响的前提下,运行速度提升约三成,这一优化路径的关键在于“针对性适配”,要求开发者深入理解不同硬件架构的指令特性、Android的进程管理机制与线程调度规则,而非依赖通用化的解释器版本。

    跨层数据交互的隐性开销,是Android Python应用性能损耗的重要来源,这种开销往往被开发者忽视,却在实际运行中占据了大量的响应时间,尤其在高频交互场景下更为明显。Python脚本与Android原生组件(如Activity、Service、ContentProvider)的交互,传统方式需经过多轮数据类型转换与序列化/反序列化过程,Python的动态数据类型(如列表、字典)需先转换为中间格式,再序列化后传输至原生组件,原生组件接收后需反序列化再转换为自身支持的数据类型,这一系列操作不仅存在数据格式不兼容的风险,更会因转换逻辑复杂、数据冗余导致响应延迟。在处理大数据量场景时,如实时传感器数据流(加速度传感器、陀螺仪数据)、图像像素数据、音频采样数据,这种开销会被急剧放大,甚至出现数据传输中断、交互卡顿的现象。很多开发者会选择第三方桥接库简化交互流程,但多数桥接库为兼容多场景、多数据类型,设计了通用化的转换逻辑,反而增加了额外的性能损耗,无法满足高频、大数据量交互的需求。有效的优化策略是“定制化数据交互协议”:基于具体业务场景的数据流特性,定义轻量化的私有数据格式,仅保留必要字段,剔除冗余信息,减少数据传输体量;同时绕过中间件的多层转发,直接调用Android原生的跨进程通信接口(如Binder),实现Python脚本与原生组件的直接数据传输,甚至将Python输出的数据直接封装为Android原生支持的内存缓冲区格式,彻底避免序列化/反序列化过程。例如在处理实时传感器数据时,通过定制化协议将传感器数据封装为连续的二进制流,直接写入原生组件的内存缓冲区,可将数据传输延迟降低六成以上,且数据丢失率几乎为零;在图像数据交互场景中,采用原生支持的像素格式进行数据传输,避免格式转换的性能损耗,可让图像处理的整体响应速度提升近一倍。这一优化思路的本质是“场景化精简”,即根据数据的传输频率、体量、格式要求,设计最贴合的交互路径,而非依赖通用化的桥接方案,这需要开发者同时掌握Python的数据处理逻辑与Android的原生通信机制、数据格式规范。

    内存管理的动态均衡,是解决Android Python应用资源占用过高、运行卡顿的核心抓手,其关键在于让Python的内存分配逻辑与Android的内存回收机制形成深度协同,而非各自独立运行。Python解释器的默认垃圾回收策略是基于自身的内存占用阈值触发,完全未考虑Android设备的内存层级结构与系统级的内存回收机制,导致频繁出现“Python内存未释放而Android系统触发低内存查杀预警”的矛盾——Python解释器认为内存占用未达阈值,未触发垃圾回收,而Android系统已因整体内存紧张开始清理后台应用,若Python应用此时处于后台,极易被系统查杀;更隐蔽的是,Python的对象引用机制与Android的内存泄漏检测逻辑不兼容,部分Python对象的隐性引用无法被Android的内存检测工具识别,长期运行后会产生隐性内存占用,导致应用可用内存逐渐减少,响应速度变慢。此外,Python脚本中频繁创建与销毁短期对象的行为,会导致内存波动剧烈,增加Android系统内存管理的负担,进一步影响性能。优化的核心路径是“双维度内存调控”:一方面修改Python解释器的垃圾回收触发条件,通过调用Android系统API获取当前设备的可用内存比例、系统内存紧张状态,将其与Python自身的内存占用阈值结合,在系统内存紧张时提前触发垃圾回收,释放冗余对象,主动适配系统内存管理策略;另一方面优化Python脚本的对象创建逻辑,采用对象池复用机制,对频繁创建的短期对象(如数据处理过程中的临时变量、循环中的迭代对象)进行复用,减少对象创建与销毁带来的内存波动,同时通过代码重构避免循环引用、全局变量过度使用等导致垃圾回收无法识别的隐性占用。实践表明,通过这种双维度调控,Python应用的内存波动幅度可降低七成,后台运行时的内存占用可压缩至原来的一半,应用被系统低内存查杀的概率降低八成以上,且长期运行后的响应速度衰减幅度控制在10%以内,这一过程需要开发者深入理解Python的垃圾回收原理(如引用计数、标记-清除算法)与Android的内存管理架构(如内存分级、低内存查杀机制),实现两者的动态适配而非独立调控。

    原生能力的深度融合,是突破Python在Android平台性能上限的关键路径,核心在于“用原生优势弥补解释型语言短板”,构建Python与Android原生的协同执行体系,而非让Python单独承担所有任务。Python作为解释型语言,在CPU密集型任务(如复杂数学计算、图像视频处理、大数据解析)和IO密集型任务(如高并发网络请求、大文件读写)中,受限于解释执行的特性,性能往往远不及Android原生开发语言(Java、Kotlin)编译后的机器码执行效率。但多数开发者仅满足于通过桥接库简单调用原生API,却未充分利用原生组件的底层优化能力——如原生图形处理框架的硬件加速、网络框架的并发调度优化、文件系统的高效读写接口,导致“原生优势未充分发挥”,整体性能仍受限于Python的解释执行速度。真正的深度融合,是基于“优势互补”的模块化分工:将核心性能瓶颈模块交由Android原生实现,充分利用原生框架的硬件加速、系统级优化能力,而Python则专注于业务逻辑编排、动态扩展、数据灵活处理等其擅长的领域,通过轻量化的交互接口实现两者的协同执行。例如在图像识别场景中,将图像预处理(如像素裁剪、格式转换、降噪)等CPU密集型操作封装为Android原生组件,利用原生图形框架的硬件加速能力提升处理效率,Python脚本仅负责调用该组件、传入原始图像数据,并处理最终的识别结果,这种分工可将整体处理效率提升三倍以上;在网络请求场景中,利用Android原生的网络框架实现高并发请求调度、缓存管理、断点续传等功能,Python则专注于数据解析、业务逻辑判断,避免解释型语言在网络IO调度中的低效问题;在大数据解析场景中,将数据读取、格式转换等IO密集型操作交由原生组件处理,Python专注于数据过滤、统计分析,可显著提升解析速度。这一优化思路的本质是“模块化分工”,即根据不同模块的性能需求与语言特性,合理分配执行载体,打破“单一语言开发”的思维定式,让Python与Android原生各自发挥优势,实现1+1>2的性能提升,这需要开发者同时掌握Python的业务编排能力与Android的原生开发技术。

    性能监控与自适应调优体系的搭建,是保障Android Python应用长期稳定高效运行的核心支撑,而非依赖“一次性优化”的静态方案——Android生态的复杂性决定了固定优化策略无法适配所有场景。Android设备的硬件差异巨大,高端旗舰机的CPU性能、内存容量是入门机型的数倍,固定的运行参数在高端机上可能浪费资源,在入门机型上则可能导致卡顿;系统版本迭代频繁,从Android 10到Android 14,运行时特性、权限机制、资源调度规则均有变化,旧版本的优化方案可能在新版本上失效;用户的使用场景更是多样,前台交互场景需要高响应速度,后台计算场景需要低资源占用,低电量场景则需兼顾性能与功耗,固定的优化策略无法满足多场景需求。很多开发者在完成初期优化后缺乏持续监控机制,无法及时发现新场景、新设备、新版本系统下的性能退化,导致应用体验不稳定。

    阿里云函数计算 AgentRun 全新发布后,我们整理了“探秘 AgentRun”系列文章,本系列将梳理企业落地Agent 常见难题,给出具体解法,助力 Agentic AI 快速走进生产级环境。欢迎加入“函数计算 AgentRun 客户群”与我们交流,钉钉群号:134570017218。

    AI Agent 时代的沙箱需求

    从 Copilot 到 Agent:执行能力的质变

    在生成式 AI 的早期阶段,应用主要以“Copilot”形式存在,AI 仅作为辅助生成建议。然而,随着 AutoGPT、BabyAGI 以及 OpenAI Code Interpreter(现为 Advanced Data Analysis)的出现,AI 开始扮演“Agent”的角色。Agent 被赋予了目标,并能自主规划步骤、使用工具来达成目标。

    这种质变的核心在于代码执行(Code Execution)。为了回答“分析这层楼的销售数据并绘制趋势图”这样的请求,LLM 不再只是生成一段 Python 代码文本,而是需要在一个真实的 Python 环境中运行这段代码,并获取绘图结果。同样,为了“帮我预订一张去东京的机票”,Agent 可能需要在一个无头浏览器(Headless Browser)中模拟用户点击。

    不可信代码的安全隐患

    当 LLM 生成代码并执行时,这段代码在本质上是不可信的(Untrusted)。如果直接在应用服务器或用户的本地设备上运行,将面临灾难性的安全风险:

    • 系统破坏:AI 生成的代码可能无意或恶意地包含 rm -rf / 等破坏性指令,或者修改关键系统配置文件。
    • 数据泄露:代码可能尝试读取环境变量中的 API Key,或者扫描内网数据库,将敏感数据发送到外部服务器。
    • 资源耗尽:死循环或内存泄漏代码可能导致宿主机崩溃,影响其他租户的服务。
    • 网络攻击:恶意 Prompt 注入(Prompt Injection)可能诱导 AI 将执行环境作为跳板(Jump Box),对内部网络发起 DDoS 攻击或端口扫描。

    Agent 场景面临的独特挑战

    除了基础的安全性,AI Agent 的交互特性还给沙箱环境带来了前所未有的工程挑战,这也是传统沙箱(如简单的 Docker 容器或虚拟机)难以应对的:

    • 状态保持:与传统的“请求-响应”模式不同,Agent 往往需要进行多轮对话。上一轮定义的变量(如 df = load_data())需要在下一轮(df.plot())中继续可用。这就要求沙箱环境必须具备上下文记忆能力,而非每次请求都重置环境。
    • 极速启动:用户无法忍受每次交互都等待数秒甚至数十秒的虚拟机启动时间。为了保证流畅的对话体验(Time to First Token),沙箱必须具备毫秒级的冷启动能力。
    • 环境依赖多样性:不同的 Agent 任务可能需要完全不同的依赖库(如 Pandas、Scipy 用于数据分析,Puppeteer 用于网页操作)。沙箱需要支持灵活的自定义镜像或动态依赖加载,同时不能影响启动速度。
    • 资源成本控制:Agent 的调用往往具有稀疏性和突发性(例如一天只用几次,但一次用很久)。长期运行独占的虚拟机(VM)成本高昂且资源利用率低,而传统的 FaaS 虽然便宜但往往缺乏状态保持能力。如何在低成本和高性能之间找到平衡点,是一个巨大的挑战。
      因此,构建一个沙箱(Sandbox)——一个与宿主机、内网以及其他用户数据严格隔离,同时具备高性能、低成本、有状态的封闭执行环境——成为了 AI Agent 沙箱落地的前提条件。

    AgentRun Sandbox:专为 Agent 设计的工程化方案

    为了解决上述挑战,我们推出了 AgentRun Sandbox。这是一个以高代码为核心,开放生态、灵活组装的一站式 Agentic AI 基础设施平台。

    AgentRun 并非从零构建传统的虚拟机集群,而是基于阿里云函数计算(FC)这一强大的 Serverless 底座构建。通过充分利用 Serverless 的按需付费、极致弹性以及免运维(NoOps) 特性,AgentRun 解决了一直困扰沙箱领域的成本与效率难题,并在此基础上通过工程化封装,提供了面向 Agent 场景的专业能力。

    为什么选择函数计算作为 Sandbox Infra

    在构建 Agent 沙箱时,我们坚定地选择了函数计算(FC)作为底层基础设施,这主要基于以下核心优势的考量:

    • 强安全隔离: 沙箱的核心诉求是安全。函数计算底层采用神龙裸金属与 RunD 安全容器技术,每个执行环境都运行在独立的 MicroVM 中。这种基于虚拟化技术的内核级隔离,相比传统的 Docker 容器隔离具有更高的安全性,能有效防止恶意代码逃逸,为不可信代码执行提供了坚实屏障。
    • 极致弹性与冷启动优化: Agent 的调用往往具有突发性。函数计算具备毫秒级的弹性伸缩能力,结合 RunD 技术对启动速度的极致优化,使得沙箱能够在数秒甚至毫秒内完成创建和启动。这不仅满足了高并发场景下的需求,也保证了 Agent 交互的流畅性,避免了传统虚拟机启动慢带来的延迟感。
    • 成本效益:自建虚拟机集群通常需要为峰值流量预留资源,导致低谷期资源浪费。函数计算采用按需付费(Pay-as-you-go)模式,且 AgentRun 利用了 FC 的空闲自动回收机制,真正做到了“有请求才计费”。对于稀疏调用的 Agent 场景,这种模式能显著降低基础设施成本。
    • 免运维: 基于 Serverless 架构,开发者无需关心底层服务器的操作系统补丁、网络配置及集群维护。AgentRun 团队可以将精力集中在沙箱的核心逻辑与业务体验上,而非底层基础设施的繁琐运维。
    • 会话能力:函数计算围绕 AI Agent Sandbox 场景推出了会话亲和、隔离以及管理能力。在一次会话生命周期内,相同会话的请求均会被亲和路由到同一个实例中,并独占该实例,保证了会话交互的连续性、上下文完整性以及多租安全性,同时提供完整的管理接口来主动对会话生命周期进行控制,降低了开发门槛。

    AgentRun 的核心运行机制

    传统的 Serverless 通常是无状态的,难以满足 Code Interpreter 这类需要上下文保持的场景。AgentRun 借助函数计算的会话产品能力,在无状态的计算底座上构建了有状态、会话级的沙箱体验。

    1. 沙箱请求亲和

    AgentRun 允许开发者显式地创建一个具有生命周期的执行环境,解决了传统 Serverless“用完即走”导致的上下文丢失问题。

    • 会话亲和:AgentRun 依赖函数计算会话亲和机制。当开发者创建沙箱后,AgentRun 会维护一个唯一的 SessionID。后续所有携带该 ID 的请求,都会被精准路由到同一个底层的计算实例。这意味着用户在第一步定义的 df = pd.read_csv(...) 对象,在第二步 df.plot() 时依然存在于内存中,完美复刻本地开发体验。
    • MCP 协议原生支持:针对模型上下文协议(Model Context Protocol, MCP),AgentRun 提供了 MCP SSE 及 MCP Streamable HTTP 会话亲和支持。AgentRun 可以直接作为 MCP 网关,让 LLM 与外部工具的交互更加顺滑。

    2. 多层次安全隔离

    在多租户 SaaS 平台中,安全性是 AgentRun 的基石。

    • 计算隔离:AgentRun 利用底层基础设施的神龙裸金属与 RunD 安全容器技术,确保每个沙箱实例在内核级别进行隔离。通过强制将会话并发度设置为 1,AgentRun 保证租户 A 的进程空间、内存数据与租户 B 物理分离,防止容器逃逸。
    • 网络隔离:网络隔离完全由用户控制。用户可以根据安全需求灵活配置,选择开启或关闭沙箱的公网访问权限,或者将沙箱接入指定的 VPC 网络环境,从而在满足业务连通性的同时,防止恶意代码对内网发起攻击。

    3. 灵活的生命周期控制

    AgentRun 通过函数计算的会话能力,接管了底层计算资源的生命周期,为上层应用提供精细化管理:

    • 自动闲置回收(Idle Timeout):为了通过 Serverless 架构降低成本,AgentRun 支持设置空闲超时(例如 5 分钟)。如果 Agent 在这段时间内没有新指令,底层实例会自动销毁并停止计费,完美适配 AI 交互“突发性强、稀疏度高”的特点。
    • 状态暂停与恢复(即将上线):针对长时间的任务间歇,AgentRun 能够将沙箱的内存与磁盘状态快照保存,在用户回归时通过快照快速恢复现场,既节省成本又保留了上下文。

    4. 会话粒度存储隔离(即将上线)

    代码执行需要隔离,数据存储更需要隔离。AgentRun 创新性地规划了会话粒度存储粘性。

    • 动态绑定:AgentRun 允许用户为每个沙箱环境中动态分配一个存储挂载点的专属子目录。
    • 逻辑沙箱:通过底层的挂载技术,沙箱内部只能看到属于自己的 /workspace,物理上无法访问其他租户的文件(如 ../../tenant-b/secret.txt),从文件系统层面根除了数据交叉风险。

    AgentRun 开箱即用的沙箱能力

    AgentRun 不仅提供了底层隔离环境,还预置了经过工程化调优的标准化模版,让开发者开箱即用:

    • Code Interpreter(代码解释器):预装 Python/Node.js/Java 等环境,支持文件上传下载、数据分析、图表绘制及命令行操作。
    • Browser User(浏览器沙箱):提供基于 CDP over WebSocket 协议的浏览器环境,兼容 Puppeteer / Playwright,让 Agent 能够安全地访问互联网进行网页操作。
    • All In One:集成了代码解释器与浏览器环境的全能型沙箱,满足复杂 Agent 任务需求。
      这些模版镜像具备高度的灵活性,AgentRun 未来将开放镜像定义,允许用户基于标准镜像定制私有依赖库或安全策略。

    AgentRun 沙箱架构详解
    image.png

    AgentRun 网关

    这是 AgentRun 的门户,负责接收来自 AI Agent(如 LangChain 应用、ChatGPT Plugin)的 HTTP 请求,除了标准的身份验证、鉴权以及协议转换(如将 HTTP 转为 WebSocket)之外,其核心能力便是沙箱管理以及沙箱请求路由的功能,它屏蔽了底层 Serverless 基础设施的复杂性,实现了如下能力:

    • 沙箱管理:管理沙箱资源,维护业务层沙箱 ID 与底层计算资源 SessionID 的映射关系
    • 状态维护:监控沙箱的活跃状态,基于沙箱超时配置以及底层资源情况及时对状态进行更新
    • 资源调度:根据用户指定的计算规格(CPU、Memory),向底层申请相应的资源。

    函数计算沙箱环境

    主要由函数计算作为底层算力来承载沙箱的运行。AgentRun 利用函数计算提供的极致弹性能力,实现在分钟内启动成三万个独立的沙箱环境,每个环境都运行在独立的 MicroVM 中,搭配自研开箱即用的沙箱镜像模版,在功能以及性能上为用户提供了双重保障。

    典型工作流:从指令到结果

    以“用户让 Agent 根据上传的 Excel 文件绘制图表”为例,AgentRun 的工作流程如下。

    阶段一:模板创建

    1. 用户请求:Agent 接收到用户指令后,由 LLM 决策使用 Python 来实现该需求。
    2. Agent 工具调用:AI Agent 会向 AgentRun 网关发送 Code Interpreter 沙箱模板的创建请求。
    3. 模板创建:AgentRun 网关会调用函数计算接口创建一个 Code 沙箱模板函数,镜像配置为前文提到的自研 Code Interpreter 沙箱模板,该函数需要同时配置会话亲和以及会话隔离。

    阶段二:沙箱创建

    1. Agent 工具调用:模板创建完成后,Agent 继续进行沙箱创建,创建时传入已有的模板 ID,标识沙箱实例运行时的配置和镜像
    2. 沙箱创建:AgentRun 收到沙箱创建请求后,会调用 FC 的 CreateSession 接口来创建一个沙箱实例,该沙箱会有一个合适的闲置超时时间,最长可存活 24h
    3. 创建完成:AgentRun 会保存 FC 返回的会话 ID,并生成沙箱业务 ID 与之对应,最终将沙箱业务 ID 返回给用户

    阶段三:任务执行

    1. 上传文件:Agent 通过 Code Interpreter 的文件上传接口,将 Excel 文件上传。若想将该文件持久化,可以在创建沙箱时配置持久化存储 NAS,将其挂到沙箱中,并将文件上传到 NAS 挂载的目录上。
    2. 绘制图表:Agent 生成代码 import pandas as pd; df = pd.read_excel('data.xlsx'),并调用 Code Interpreter 的 run_code 接口执行代码。
    3. 会话亲和:Agent 所有发往 Code Interpreter 的请求中,都必须带上对应的沙箱 ID 才能保证请求都路由到同一个沙箱实例。
    4. 内存驻留:代码执行完毕,变量 df 驻留在内存中.
    5. 二次代码执行:Agent 根据数据列名生成绘图代码 df.plot()。再次发送代码运行请求
    6. 上下文复用:请求再次到达同一实例,直接使用内存中的 df 对象进行绘图,生成图片文件。
    7. 结果回传:图片被写入 NAS,下载链接返回给 Agent。

    阶段四:资源销毁

    1. 空闲检测:Agent 完成任务,不再发送请求。
    2. 自动回收:达到 SessionIdleTimeout(如 5 分钟)后,函数计算会自动销毁该沙箱实例,此时除了持久化到 NAS 上的数据,其余环境相关数据均被销毁。
    3. 文件回收:如果 NAS 上的文件是会话隔离的,当用户会话结束后,NAS 上文件需要进行主动或者定时自动清除。

    工作时序图

    image.png

    AgentRun 的核心设计原则

    AgentRun 的工程化实践遵循以下五大核心原则,这构成了其安全、高效、可扩展的基石:

    原则一:配置即代码

    AgentRun 将沙箱环境定义(环境变量、资源规格、健康检查等)封装为标准化模版。这种设计实现了沙箱配置的版本化管理,使得 Agent 环境可以像代码一样进行复制和回滚。

    原则二:会话即沙箱

    AgentRun 将“会话”作为沙箱的唯一实体。通过 SessionID 绑定底层的计算实例与上下文状态,实现了真正的按需分配与状态保持。沙箱的创建与销毁完全独立于底层物理设施,对用户透明。

    原则三:生命周期可编程

    AgentRun 不仅提供创建(Create)和删除(Delete)接口,还引入了“暂停”、“恢复”和“自动超时”机制。这种可编程性让上层应用能根据业务价值最大化资源利用率,实现成本与性能的最优平衡。

    原则四:网络接入标准化

    AgentRun 抹平了底层网络的差异,提供标准化的 HTTP/WebSocket 接口,并支持 Server-Sent Events(SSE)。无论底层如何升级,上层 Agent 沙箱始终通过标准的 Header 或 Cookie 携带 SessionID 进行交互,降低了集成复杂度。

    原则五:存储隔离细粒度化(即将上线)

    AgentRun 不仅支持模版粒度的文件系统共享,同时也能够配置沙箱粒度目录级动态挂载。每个沙箱单独挂载一个目录,从根源上杜绝了多租户环境下的数据越权访问风险。

    总结与展望

    AgentRun Sandbox 是 Serverless 技术在 AI Agent 领域的最佳工程化实践。

    通过将阿里云函数计算(FC)在 RunD 安全虚拟化(解决隔离与启动速度)、会话亲和性(解决状态保持)以及 动态 NAS 挂载(解决数据隔离)等方面的底层技术创新,封装为面向业务的 AgentRun 平台,我们成功降低了企业构建 AI Agent 的门槛。

    对于构建下一代智能体应用的企业而言,选择 AgentRun Sandbox 不仅是选择了一个沙箱工具,更是选择了一套兼顾安全性、用户体验与商业效率的弹性基础设施。未来,AgentRun Sandbox 将继续在启动延迟优化、状态秒级快照恢复以及更多样化的存储支持上深耕,致力于成为 AI Agent 时代最佳的沙箱基座。

    立即体验函数计算 AgentRun

    函数计算 AgentRun 的无代码到高代码演进能力,现已开放体验:

    查看更多产品详情https://www.aliyun.com/product/fc/agentrun

    1.快速创建:访问控制台(https://functionai.console.aliyun.com/cn-hangzhou/agent/explore),60秒创建你的第一个 Agent

    2.深度定制:当需要更复杂功能时,一键转换为高代码
    3.持续演进:利用函数计算 AgentRun 的基础设施能力,持续优化你的 Agent

    从想法到上线,从原型到生产,函数计算 AgentRun 始终是你最好的伙伴。欢迎加入“函数计算 AgentRun 客户群”,钉钉群号:134570017218。

    快速了解函数计算 AgentRun

    一句话介绍:函数计算 AgentRun 是一个以高代码为核心的一站式 Agentic AI 基础设施平台。秉持生态开放和灵活组装的理念,为企业级 Agent 应用提供从开发、部署到运维的全生命周期管理。

    image.png

    函数计算 AgentRun 架构图

    AgentRun 运行时基于阿里云函数计算 FC 构建,继承了 Serverless 计算极致弹性、按量付费、零运维的核心优势。通过深度集成 AgentScope、LangChain、RAGFlow、Mem0 等主流开源生态。函数计算 AgentRun 将 Serverless 的极致弹性、零运维和按量付费的特性与 AI 原生应用场景深度融合,助力企业实现成本与效率的极致优化,平均 TCO 降低 60%

    让开发者只需专注于 Agent 的业务逻辑创新,无需关心底层基础设施,让 Agentic AI 真正进入企业生产环境。

    作者:江昱

    阿里云函数计算 AgentRun 全新发布后,我们整理了“探秘 AgentRun”系列文章,本系列将梳理企业落地 Agent 常见难题,给出具体解法,助力 Agentic AI 快速走进生产级环境。欢迎加入“函数计算 AgentRun 客户群”与我们交流,钉钉群号: 134570017218

    当你已经用 LangChain、AgentScope、LangGraph 等框架开发了 Agent 应用,如何让它们享受函数计算 AgentRun 提供的 Serverless 运行时、企业级 Sandbox、模型高可用、全链路可观测等能力?好消息是,你几乎不需要改动现有代码,只需要简单的适配就可以迁移到函数计算 AgentRun。

    这篇文章将通过真实的代码示例,展示如何将不同框架的 Agent 应用部署到函数计算 AgentRun 上,以及如何充分利用函数计算 AgentRun 的各种能力。

    为什么要部署到函数计算 AgentRun?

    在讨论具体的集成方案前,让我们先明确一个问题:如果你的 Agent 应用已经在本地或自建服务器上运行良好,为什么还要迁移到函数计算 AgentRun?

    答案很简单:从开发环境到生产环境,有一道巨大的鸿沟。  本地运行只需要考虑功能实现,但生产环境需要考虑性能、稳定性、成本、安全、可观测等一系列问题。函数计算 AgentRun 提供的不是又一个 Agent 框架,而是让你的 Agent 能够以企业级标准运行的完整基础设施。

    具体来说,部署到函数计算 AgentRun 后,你能获得:零运维的 Serverless 运行时(自动扩缩容、按量付费),企业级的 Sandbox 环境(高性能、安全隔离),模型高可用保障(自动熔断、多模型 Fallback),全链路可观测(完整的 Trace、成本归因),以及统一的工具和 MCP 管理。

    image

    快速上手:5 分钟部署你的第一个 LangChain Agent

    让我们从最流行的 LangChain 框架开始,通过一个完整的例子展示如何将 LangChain Agent 部署到函数计算 AgentRun。

    第一步:安装 Serverless Devs

    函数计算 AgentRun 使用 Serverless Devs 作为部署工具。如果你有 Node.js 环境,一行命令即可安装:

    npm i -g @serverless-devs/s

    第二步:创建项目

    使用脚手架快速创建项目(注意:需要 Python 3.10 及以上版本):

    # 初始化模板
    s init agentrun-quick-start-langchain
    # 进入代码目录
    cd agentrun-quick-start-langchain/code
    # 初始化虚拟环境并安装依赖
    uv venv && uv pip install -r requirements.txt

    第三步:配置认证信息

    通过环境变量(建议使用 .env 文件)配置你的 AgentRun 访问凭证:

    export AGENTRUN_ACCESS_KEY_ID="your-access-key-id"
    export AGENTRUN_ACCESS_KEY_SECRET="your-access-key-secret"
    export AGENTRUN_ACCOUNT_ID="your-account-id"
    export AGENTRUN_REGION="cn-hangzhou"

    第四步:理解集成方式

    这是最关键的部分。打开生成的代码,你会看到集成非常简单:

    from agentrun.integration.langchain import model, sandbox_toolset
    from agentrun.server import AgentRunServer
    # 使用 AgentRun 的模型(自动享受高可用、熔断等能力)
    llm = model("<your-model-name>")
    # 使用 AgentRun 的 Sandbox 工具
    tools = sandbox_toolset(
        template_name="<your-sandbox-name>",
        template_type=TemplateType.CODE_INTERPRETER,
        sandbox_idle_timeout_seconds=300,
    )
    # 创建 LangChain Agent(和原来的代码完全一样)
    agent = create_agent(
        model=llm,
        tools=tools,
        system_prompt="你是一个智能助手"
    )
    # 定义调用函数
    def invoke_agent(request):
        result = agent.invoke({"messages": request.messages})
        return result["messages"][-1].content
    # 启动 HTTP Server(提供 OpenAI 兼容的 API)
    AgentRunServer(invoke_agent=invoke_agent).start()

    核心要点:

    • model() 函数返回的是 LangChain 可以直接使用的模型对象
    • sandbox_toolset() 返回的是 LangChain Tools 列表
    • 你的 Agent 创建代码完全不需要改动
    • AgentRunServer 自动处理 HTTP 请求,提供标准的 OpenAI API

    第五步:本地测试

    启动服务后,可以通过 HTTP 请求测试:

    curl 127.0.0.1:9000/v1/chat/completions \
      -X POST \
      -H "content-type: application/json" \
      -d '{"messages": [{"role": "user", "content": "通过代码查询现在是几点?"}], "stream":true}'

    第六步:部署到生产环境

    项目中已经包含了 s.yaml 配置文件。你只需要修改其中的 role 字段为你的阿里云角色:

    role: acs:ram::{您的阿里云主账号 ID}:role/{您的阿里云角色名称}

    配置部署密钥:

    s config add
    # 按照引导输入 Access Key ID 和 Secret,记住密钥对名称(如 agentrun-deploy)

    执行部署:

    s deploy -a agentrun-deploy

    部署完成后,你会得到一个 HTTPS URL,就可以在生产环境调用你的 Agent 了。

    不同框架的集成案例

    函数计算 AgentRun 不仅支持 LangChain,还深度集成了主流的 Agent 开发框架。所有框架都遵循同样的理念:通过简单的适配层,让你的代码无缝迁移到函数计算 AgentRun,享受企业级能力。

    LangGraph:工作流编排

    LangGraph 是 LangChain 团队推出的工作流编排框架,适合构建复杂的多步骤 Agent。集成方式和 LangChain 类似:

    from agentrun.integration.langgraph import model, tools
    from langgraph.graph import StateGraph, MessagesState
    from langgraph.prebuilt import ToolNode
    # 使用 AgentRun 的模型和工具
    llm = model("<your-model-name>").to_langgraph()
    agent_tools = tools()
    # 构建 LangGraph 工作流(和原来的代码一样)
    def call_model(state: MessagesState):
        messages = state["messages"]
        response = llm.invoke(messages)
        return {"messages": [response]}
    workflow = StateGraph(MessagesState)
    workflow.add_node("agent", call_model)
    workflow.add_node("tools", ToolNode(agent_tools))
    workflow.set_entry_point("agent")
    # 定义条件边...
    app = workflow.compile()
    # 调用
    result = app.invoke({"messages": [HumanMessage(content="查询上海天气")]})

    LangGraph 的优势是可以精确控制 Agent 的执行流程,比如条件分支、循环、并行执行等。部署到函数计算 AgentRun 后,这些复杂的工作流都能自动享受弹性伸缩和可观测能力。

    AgentScope:多智能体协作

    AgentScope 是阿里达摩院开源的多智能体框架,特别适合构建多 Agent 协作场景。集成方式:

    from agentrun.integration.agentscope import model, tools
    from agentscope.agent import ReActAgent
    from agentscope.tool import Toolkit
    # 使用 AgentRun 的模型和工具
    llm = model("<your-model-name>").to_agentscope()
    agent_tools = tools()
    # 注册工具到 Toolkit
    toolkit = Toolkit()
    for tool in agent_tools:
        toolkit.register_tool_function(tool)
    # 创建 Agent(和原来的代码一样)
    agent = ReActAgent(
        name="assistant",
        sys_prompt="你是一个智能助手",
        model=llm,
        toolkit=toolkit,
    )
    # 调用
    result = await agent.reply(Msg(name="user", content="查询上海天气", role="user"))

    AgentScope 的优势是对多 Agent 系统的原生支持,包括 Agent 之间的通信、协调、记忆共享等。部署到函数计算 AgentRun 后,每个 Agent 都在独立的隔离环境中运行,确保安全性。

    PydanticAI:类型安全的 Agent 框架

    PydanticAI 是一个新兴框架,强调类型安全和结构化输出。集成方式:

    from agentrun.integration.pydantic_ai import model, tools
    from pydantic_ai import Agent
    # 使用 AgentRun 的模型和工具
    llm = model("<your-model-name>").to_pydantic_ai()
    agent_tools = tools()
    # 创建 Agent
    agent = Agent(
        llm,
        instructions="Be concise, reply with one sentence.",
        tools=agent_tools,
    )
    # 同步调用
    result = agent.run_sync("上海的天气如何?")
    # 异步调用
    result = await agent.run("上海的天气如何?")

    PydanticAI 的优势是强类型和结构化输出,特别适合需要严格数据验证的企业场景。

    充分利用函数计算 AgentRun 的核心能力

    将 Agent 部署到函数计算 AgentRun 后,你不仅获得了 Serverless 运行环境,还可以深度利用平台提供的各种企业级能力。

    模型高可用:告别单点故障(搭配 AI 网关)

    部署到函数计算 AgentRun 后,你的 Agent 自动享受模型高可用能力。当你配置的主模型出现故障、限流或超时时,系统会自动切换到备用模型,整个过程对你的代码完全透明。
    在函数计算 AgentRun 控制台配置模型时可以和 AI 网关进行联动,可以设置:主模型(如 GPT-4),备用模型列表(如 Claude-3、Qwen-Max),熔断策略(错误率阈值、超时时间),负载均衡策略(轮询、权重、最少连接)。
    你的代码完全不需要改动,只需要在创建模型时使用函数计算 AgentRun 的模型名称,所有的容错、切换、负载均衡都由平台自动处理。

    企业级 Sandbox:安全执行代码

    函数计算 AgentRun 提供的 Sandbox 不是简单的代码执行环境,而是企业级的安全隔离沙箱。每个 Sandbox 实例都是独立隔离的,支持多种执行类型:

    Code Interpreter 支持 Python、Node.js、Java、Bash 等语言,可以执行数据分析、文件处理等任务。Browser Tool 提供浏览器自动化能力,支持网页爬取、表单填写、截图等操作。All In One 集成了代码解释器和浏览器工具,提供更丰富的交互能力。

    使用时,通过 sandbox_toolset() 函数就可以获取相应的工具集合,这些工具会自动转换为你使用的框架所需的格式。

    工具和 MCP:标准化集成

    函数计算 AgentRun 提供统一的工具管理和 MCP(Model Context Protocol)机制。你可以从工具市场选择现成的工具,也可以自定义工具并发布到市场。

    更强大的是 MCP 的 Hook 机制。通过前置 Hook,可以在工具调用前自动注入用户凭证、记录请求日志、校验参数合法性。通过后置 Hook,可以对结果进行转换、记录审计日志、处理异常情况。这些通用逻辑不需要在每个工具中重复实现,大大提升了开发效率。

    全链路可观测:不再是黑盒

    这是函数计算 AgentRun 最强大的能力之一。你的代码不需要做任何改动,平台会自动记录 Agent 的完整执行链路

    在可观测平台上,你可以看到:Agent 接收到用户请求的时间和内容,调用了哪个模型、使用了多少 Token、花费了多少钱,调用了哪些工具、每个工具的执行时间和结果,访问了哪些知识库、检索了多少数据,每个环节的耗时分布,完整的调用链 Trace。

    这些能力都是平台自动提供的,通过探针注入实现,无论是高代码还是低代码创建的 Agent,都自动享受这些可观测能力。

    记忆和知识库:数据不出域

    函数计算 AgentRun 深度集成了 RAGFlow、Mem0 等开源项目,提供灵活的记忆和知识库管理。你可以选择一键托管模式,由平台统一管理部署运维,享受 Serverless 的弹性和按量付费优势。也可以选择绑定模式,将 Agent 连接到已经部署在企业 VPC 或 IDC 内的实例,数据完全不出企业内网

    这种灵活性让你可以根据数据的敏感级别选择不同的策略:核心业务数据私有化部署,一般数据托管上云,在安全性和便利性之间找到最佳平衡。

    立即体验函数计算 AgentRun

    函数计算 AgentRun 的无代码到高代码演进能力,现已开放体验:

    1. 快速创建: 访问控制台( https://functionai.console.aliyun.com/cn-hangzhou/agent/explore ),60 秒创建你的第一个 Agent
    2. 深度定制: 当需要更复杂功能时,一键转换为高代码
    3. 持续演进: 利用函数计算 AgentRun 的基础设施能力,持续优化你的 Agent

    从想法到上线,从原型到生产,函数计算 AgentRun 始终是你最好的伙伴。欢迎加入“函数计算 AgentRun 客户群”,钉钉群号:134570017218。

    快速了解函数计算 AgentRun:

    一句话介绍:函数计算 AgentRun 是一个以高代码为核心的一站式 Agentic AI 基础设施平台。秉持生态开放和灵活组装的理念,为企业级 Agent 应用提供从开发、部署到运维的全生命周期管理。

    image

    函数计算 AgentRun 架构图

    AgentRun 运行时基于阿里云函数计算 FC 构建,继承了 Serverless 计算极致弹性、按量付费、零运维的核心优势。通过深度集成 AgentScope、LangChain、RAGFlow、Mem0 等主流开源生态。函数计算 AgentRun 将 Serverless 的极致弹性、零运维和按量付费的特性与 AI 原生应用场景深度融合,助力企业实现成本与效率的极致优化,平均 TCO 降低 60% 。 

    开发者只需专注于 Agent 的业务逻辑创新,无需关心底层基础设施, 让 Agentic AI 真正进入企业生产环境。

    本次更新主要是体验优化上,列一下更新内容:

    代码高亮方案换为 ShiKi

    新方案体验有问题希望可以及时反馈我做修正,旧方案比较老旧了所以用了新的。

    介绍页内容变化

    经验值与金币值的常量现在实时了,另外可以输入站内表情以及自动优化中英文空格。

    评论列表性能优化

    之前楼层数多了,尤其是楼中楼多的情况下,输入会出现卡顿,新版做了优化看体验是否更好一些。

    浏览优化

    现在滚动时在左侧上方会出现返回按钮,方便回到上一页。

    输入优化

    现在评论的编辑框增加了@当前楼层的所有人以及@所有人。目前@所有人只取当前评论列表的所有用户名,后续再看是否查询全部。

    金币消耗变动

    ♥️与 👍 现在的消耗增加,让这两个表情的分量更加重一些,且获得会被系统扣除掉 10%。同时金币打赏的最低额度设置为 100 金币,最高 500 金币,各位现在不那么容易慷慨解囊了。

    既然有用户慷慨的发现有些操作不消耗金币,我就勉强加入了:

    • 编辑评论、帖子、附言均需要消耗金币;
    • 新增附言需要消耗金币。

    消息提醒优化

    现在长连接通知收到后,会在浏览器的标题上显示未读计数。

    还有不少优化

    不列了,比较琐碎。sobbing