通信 on 红旗下的蛋

1995—2000年，我在深圳遇到的那些通信公司

Sun, 27 Sep 2026 09:07:00 +0000

1995 年 11 月，我来到深圳。

那时候刚大学毕业，对通信行业几乎一无所知。

当时主要还是跟着做一些通信设计相关的事情：跑腿、接待、整理资料、画图、完成领导交办的工作。

那几年，跟着项目做过宝安邮电局的电缆设计，也参与过宝安电信大厦的5A设计、蛇口通讯公司赤湾机楼的一些设计协调工作。后来在高新区惠特普公司刚成立的时候，又做了一些深圳高新区的光缆网络设计的一些基础性工作。

当时没想那么多。

下面这些内容，一部分来自我自己的记忆，一部分是后来根据网上能找到的资料重新查的。二十多年过去了，记忆难免有偏差，网上资料也未必完整，所以就当作一次个人回忆和粗略整理，难免会有不准确的地方。

现在回头看，这些项目把我带到了几家很不一样的公司和单位。

有宝安邮电局以及后来的宝安电信局，是传统邮电体系里的地方电信单位；有深大电话，是经济特区改革中形成的电信企业；有蛇口通讯，是依托工业园区发展起来的通信体系；还有惠特普，负责高新区的电信业务和信息网络建设运营的专业公司。

而我当时看到的，其实没有这么复杂。

就是一个个院子、一座座机楼，一个个具体项目。

关外，宝安邮电局：一个大院子

宝安邮电局给我的印象，就是一个挺大的院子。

那时候邮政和电信还在一起。

我跟着做电缆设计，属于电信这一边，但一个大院子里，邮政和电信是在一起的。

1984 年，原宝安县邮电局改为深圳市邮电局宝安分局。到我 1995 年来到深圳时，宝安的通信网络还在不断建设，电话业务也是当时通信建设最主要的内容之一。

还有后来的宝安电信大厦的5A设计，那时刚开始流行5A智能化大楼的概念，我当时并不太懂，主要是跟着师傅打下手，跑跑腿、画画图，跟着做了一些基础的工作。

画图、改图、跑现场，具体到哪一段电缆怎么走，哪个地方放分线盒，和机房怎么衔接，更多想的是把手头的事情做好。

后来到了 1998 年，邮电分营，邮政和电信开始分开。

原来一个院子里的两套业务，慢慢变成了两个体系。

那时回关内要过南头关，好在我们工程车上有一块带着五角星的“人民邮电”的牌子，过关检查时就容易些，很多时候车子稍停，探头一看，摆手就让过了。车上这块牌子，让我们去关内关外很多地方都很方便。

多年以后再回头看，才发现自己当年做的那些电缆和机楼，正好碰上了传统邮电体系分开的那个阶段。

一个大院子，后来慢慢变成了两个体系。

关内，深大电话：电话卡和电话厅

深大电话和前面几家不太一样。

我没有在深大电话做过项目，和它没有工作上的接触。

但对它并不陌生。

在关内生活、工作，深大电话卡和街头的公用电话亭是经常遇到的。打电话、买卡、路过营业厅，它就在日常生活里。

后来才知道，1983 年，深圳市电信发展公司与英国大东电报局合作成立深大电话有限公司。它从一开始就带着经济特区的特点，是深圳早期中外合作发展电信业务的一种尝试。1988 年，又由中外合资转为合作经营，英方退出管理。

等我 1995 年来到深圳的时候，这家公司已经存在十多年了。

它和宝安邮电局很不一样。

宝安是传统邮电体系里的分支，深大电话则是在经济特区的特殊环境下形成的另一种电信企业。

我当时不会去想这些。

对我来说，它就是生活里的一张电话卡、一个街头电话亭。

现在再回头看，这个名字背后，其实也能看到深圳早期电信业的一种特殊发展方式。

关内，蛇口通讯：赤湾的一座机楼

蛇口通讯又是另外一种感觉。

我参与过蛇口通讯公司赤湾机楼的一些设计协调工作。

那时候在我眼里，就是一座通信机楼。

后来才知道，蛇口工业区很早就有自己的通信建设。

1981 年，蛇口工业区微波通信站建成，并实现了与香港的通信。

蛇口当时是一个特殊的工业区。这里企业多，和香港以及境外的联系也多，通信自然成了工业区运行的一项基础条件。

所以它很早就形成了自己的通信体系。

到了 1990 年代，这套体系依然存在。

现在回头看，蛇口通讯和宝安邮电局其实是两条不同的路。

一个是在传统邮电体系里发展起来的通信网络，一个则是在园区发展过程中自己建立起来的通信体系。

而我当年接触它们时，并没有意识到这一点。

我看到的，只是一边是宝安那个大院子，一边是赤湾的一座机楼。

高新区，惠特普：一张刚开始建设的光缆网

高新区又不太一样。

惠特普成立不久，我跟着做过一些光缆线路设计的基础工作，也参与过他们三网合一的一些建设方案。

那时候更多接触的是具体的光缆线路。

这时候，网络面对的已经不只是电话。

高新区需要的是一张服务园区的信息网络。

我对那个时期还有一个比较具体的记忆。

高新区开通了上星的电视转播，我印象比较深的是 Fashion TV。

但从后来高信网的发展来看，电话、数据、电视等不同信息业务，确实逐渐走到了一张网络上，“三网融合”也成为它后来发展的一个方向。

现在再看，当年做的那段光缆网络，和宝安的通信电缆已经不是完全一样的东西了。

它开始有点像后来所说的“信息网络”。

后来才知道，惠特普由高新区服务机构和中国电信深圳公司共同参与组建的。

还有一个鸿波：组织关系挂靠的地方

还有一个鸿波，电信的三产。

当时我的组织关系挂靠在那里，除此之外，我和鸿波没有业务上的往来。

所以这里也不用展开讲它。

再回头看这些公司：几条不同的路

这些公司和单位，我是在几年时间里一个个遇到的。

当时没有把它们放在一起想过。

宝安邮电局，就是一个需要做通信电缆设计的单位；深大电话，是生活里经常遇到的电话卡和电话厅；蛇口通讯，有一座需要协调设计的机楼；高新区，则是一张正在建设的信息网络。

后来这些单位各自发生了变化。

宝安经历了邮电分营，邮政和电信从一个体系里分开；深大电话则随着中外合作经营合同到期，最终退出了历史舞台；蛇口通讯后来成为中国电信控股的工业园区通信企业；惠特普后来更名为深圳高新区信息网有限公司，业务在原来的基础上增加了移动业务。

现在把这些名字重新放在一起，才发现，它们恰好对应了那个时期深圳通信业几条不同的路。

而我当时做的事情其实很简单。

只是跟着师傅做项目，交待什么就做什么，心思很单纯，事情也简单。不像现在，考虑多、事情杂。现在回头想想，挺怀念当年那种清爽和纯粹。

很多年以后，再把这些公司、院子、机楼和那些做过的项目串起来，才发现，1995—2000 年这几年，正好是它们交错变化的一段时间。

当时只是遇见。

现在再理一遍，觉得挺有意思。

专场

Sun, 20 Sep 2026 21:45:00 +0000

文化馆换了馆长。

新馆长到任一个月，点了一出戏，不是现成的，是个题。

专场，演给他和他带来的人看。

社长去接活，回来只记住一句：

“看看水平。”

他学这句话的时候，眉头皱了。

我们问社长馆长还说了什么，他说就这一句。

我们问他馆长要什么样的戏，他说他要是问了，就是承认社里没水平。

所以他没问。

社长回来就把活儿压给了导演。

导演问社长，馆长到底想要什么。

社长说：

“你排出来，他看了就知道。”

导演没再问。

后来导演跟我说，他其实也不知道“看看水平”是什么水平。

但他不能跟社长说不知道——

社长已经不知道了，导演再不知道，这活儿就没人接了。

“看看水平”就这样长成了一张单子。

单子是我拟的，拿去给社长勾，勾完就成了“馆长的要求”。

八条。

没有一条是馆长说的，条条是路上怕他的人添的：

导演怕冷，添热闹；

演员怕接不住，添短；

社长怕砸，添稳。

最可笑的是我。

单子是我拟的，却分不清哪句是听来的，哪句是我替他想的。

动笔前我卡了半个月。

写浅了，怕他当我是糊弄；

写深了，怕他当我是显摆。

社长说，你得摸他的耳朵——他爱听什么，不爱听什么。

我问怎么摸。

社长说：

“你写戏的，自己想办法。”

我想了几天，没办法。

他刚调来，镇上没人跟他熟。

后台的老头给了唯一一条：

“馆长看节目，手爱在扶手上打拍子。”

“歌舞队出来的，”老头说，“他听的是板眼，不是词。”

我把这句抄在本子第一页。

排了小一个月。

导演的尺子换了刻度，从前量台上立不立得住，这阵子量馆长爱不爱看。

可一屋子人，谁也没见过他。

排一出给一个没见过的人看的戏，每把尺子上刻的都是同一个人，一个想出来的人。

每过一轮，屋里的把握多一分；

磨到定稿，满屋子只剩我一个人没把握。

因为只有我知道，那个人是想出来的。

社长那阵子老来排练厅。

他不看戏，看导演。

导演说行了，他就点头；

导演皱眉，他就问要不要再改改。

有一回他问我：

“这出戏能不能拿得出手？”

我说能。

他说：

“不是问你，是问馆长。”

我说我不知道馆长要什么。

他说：

“我也不知道，但你不能让馆长觉得我们不知道。”

演出那天，我照旧坐最后一排。

他坐正中间。

从正中间到最后一排，七排椅子。

平时这七排各坐各的，那天我头一回觉得，它们是一串的。

他的后脑勺我盯了全场。

手也确实在打拍子。

可我不知道那拍子是什么意思。

入了戏，还是数还剩几分钟？

该响的包袱，齐齐整整地哑了。

他笑了两回。

一回落在我最板的那段独白上。

我最用力的地方，他没动；

我随口带过的地方，他倒回头跟旁边的人咬了句耳朵。

管灯的说，第三幕他看了表。

掌声很齐，也很客气。

我头一回知道，掌声也能是空的。

散场时社长站在门口送。

馆长握他的手，说了句什么。

社长笑着点头，笑得比平时久。

那天晚上社长喝多了，说了一句：

“他也没说好，也没说不好。”

我问：

“那你笑什么？”

他说：

“我不能不笑。”

之后几天，我收各层的话。

社长说，馆长很满意。

导演说，社长说了，馆长很满意。

后台的老头私下跟我说，中场休息，馆长问过一句：

“后头还有没有？”

这一句，谁也没往上送。

馆长跟社长握手时说的话，三天后传到我这儿，有了三个版本。

我去找社长，要他点戏时的原话。

社长想了半天。

“看看水平”之外，又想起半句：

“前头……老问文化的事。”

这半句，是散场之后才想起来的。

我愣的不是头一句，是这一句。

原来他也是角儿。

他也有他的台，他的观众。

这出戏是演给他看的，更是演给他台上看的——

他要拿这出戏，回他的台上说事儿。

我们排一个月，是给他备台词。

馆长要什么？

他要的未必是一出多好的戏。

他要的是从这出戏里带走一句话。

但他不能说“我要一句能带回去的话”，那太露。

他只能说“看看水平”。

他心里大概也不知道“水平”长什么样，只知道到时候看见了，他就知道了。

我们排了一个月，他等了一个月。

他比我们还怕这出戏不成——

不成，他回去没法说。

社长要什么？

他要一个能交差的东西。

但他不知道馆长认什么，也不敢问。

他只能一层一层往下压，压到导演，压到我。

他嘴上说“看看水平”，心里想的是：

“别砸在我手里。”

他笑了一晚上，笑到最后腮帮子疼。

这回我大概明白了。

以后再碰到这种专场，我不会先猜他懂多少戏，也不会先猜他喜欢什么。

我只琢磨一件事：

散场之后，他要带哪句话出这个门。

带得走的话是戏钱，剩下的都是白送。

浅和深的死结，也是这么解开的。

头里加一段短的，三句话，把门里的规矩递到门外。

正戏照正戏写，该多深多深，门道埋在底下，遇上内行自己会亮。

再印一份戏单，搁在座位扶手上，看不看随他。

没人翻，它也在；

懂行的翻两页，就知道这出戏底下有东西。

板眼也要清。

戏可以深，几折、每折多大、哪里起哪里落，句句要带数。

下一个专场不知道哪天来。

来之前我备三样。

先打听他从前在哪儿，爱听什么，是从哪儿养出来的。

再要一句原话。

原话是这条路上唯一没被改过的东西。

最后，头里那三句短话，先写出来。

写完这篇，我该去写那三句了。

从“承载”到“服务”：我对传输网络业务化的一点理解

Wed, 16 Sep 2026 16:54:00 +0000

最近参与一个材料的编写，反反复复被灌输“业务网”、“承载”、“客户需求”、“产品”、“能力”这些概念。同一个词，对不同的领导来说，或者概念不同，或者范围不同，搞得拼命去理解一个本以为了解的词的真正含义。不同的章节，用词也随意：有时“能力”和“产品”混着用，有时“承载”一会儿指网络、一会儿指网络干的事。材料改了好几轮，我也被绕了好几轮。刚好有个空隙，索性停下来，先把这些词的定义自己梳理一遍、理解一遍。

先看“承载”。这个词含义应该很清楚：连接业务网元。5G 基站连BBU，OLT 连 BRAS，专线节点之间互联，IDC 之间打通。业务网在上面，传输网在下面；业务负责功能，传输负责连接。传输网回答的问题是：“业务网元之间怎么连？”这就是承载。

网络能力：网络本身能做什么

如果先不管上面的业务，只看传输网自己，会发现它其实有很多“本事”：能建端到端连接，能给不同带宽，能做小颗粒承载，能动态调带宽，能选低时延路径，能做保护和恢复，能给 QoS 保障，还能在光层、电层之间协同调度。

过去习惯把这些叫“传输网的功能”。但换个角度，它们其实是网络自身的能力。承载说的是网络承担什么角色，能力是说这个网络本身到底能做什么？

我暂时把网络能力理解成：网络在技术和资源层面能够执行的基本功能单元，可以被网管系统配置。

网络产品：把能力打包成什么

单个网络域还好，一旦跨域、跨厂商、跨层次，事情就复杂了。比如有人要一条“跨区域 100G 端到端连接”，底层可能经过多个省份、多个网络域、多个厂家。如果每个网络都按自己的方式配，上层系统就得懂下面所有细节，显然不现实。

更合理的方式是：上层只说“我要一条 100G 跨域连接”，下面的编排系统自己去算路径、协同资源、配置设备、开通业务。对上层来说，原来一堆复杂的能力，被打包成了一个简单的东西。

这就是我理解的“网络产品”：把一个或多个网络域中的网络能力组合、抽象、封装，形成一个标准化、可被调用的能力单元。

这里有个有意思的现象：能力和产品的定义，其实是被网络边界决定的。如果整条链路就在同一个厂家、同一个网络域内，网管开一条电路，能力几乎就是产品，两者基本等同。只有跨省、跨域、跨厂商，封装和抽象才真正显示出价值。所以这两个概念有时一样有时不同。

TM Forum：一个可以参照的现成框架

查了些资料才知道，这个思路在 TM Forum（电信管理论坛）那里已经有成熟的框架。

它的核心是把网络世界分成三层：

• Resource（资源） ：物理/逻辑的设备、波道、连接
• Service（服务） ：对资源的技术性配置组合，面向网络的技术视角
• Product（产品） ：面向客户的销售视角，含价格、SLA、合同条款

每一层又分规格和实例：规格进目录、可以定价上架，实例才是真正交付和运行的东西。

配套的运营架构叫 ODA，由老的 eTOM（流程）、SID（信息）、TAM（应用）三大框架收敛而来，思路是把运营系统拆成标准化“积木块”，块之间用统一编号的 Open API 通信——比如 TMF620 产品目录、TMF633 服务目录、TMF641 服务订单、TMF622 产品订单。

我的理解和 TMF 的对应

对照下来，大致是这样：

我的理解	含义	TMF 对应
承载	网络承担的角色	Resource（资源层）
能力	网络能做什么	分散在 Resource 和 Service 之中
网络产品	把能力打包成什么	Service 规格（进服务目录）
网络服务/商品	客户可以买到什么	Product 规格 + 定价（进产品目录）

TMF 的 “Service” 对应我说的“网络产品”，TMF 的 “Product” 对应我说的“网络服务/商品”，正好错位半层，不过知道就行了，我也不必改正我的说法。

至于“能力”，TMF 没有单独设一层。这让我意识到，“能力”更像一个视角而不是层级——同一个网络功能，站在网络侧看是能力，被参数化、封装之后，就是产品。一句话概括三层的“用户”： 能力是给系统调的，产品是给订单用的，服务是给客户签的 。

网络服务：客户最终买到的是什么

有了“跨域 100G 连接”，是不是就已经是业务了？我觉得还不能这么简单说。客户真正买的，通常不是抽象的“能力”，而是一条可以签合同的专线。

专线要成为可销售的商品，还需要很多网络之外的东西：客户受理、订单、资源确认、开通、交付、SLA、计费、故障处理、运维保障。这正是 TMF 里 Service 和 Product 的分界：技术规格在服务目录里，加上定价和商务条款进入产品目录，才真正进入运营商的业务体系。

承载并没有消失

写到这里，有一点我觉得特别重要：这并不是说“承载不重要了”。

无论能力、产品还是服务，最底层仍然是传输网的连接和承载能力。没有这些，后面的东西都不存在。真正变化的不是“传输网不再承载”，而是：传输网除了承载，自身的能力开始被显性化、抽象化和产品化。

过去的关系是：业务提出连接需求 → 传输网负责承载。现在可能逐渐变成：业务提出意图 → 网络提供能力 → 能力组合成产品 → 产品再变成服务。

所以我更愿意把“传输网络业务化”理解成：在继续做好承载的基础上，网络自身的连接、调度和保障能力开始被抽象、封装、编排，并逐渐以产品和服务的形式向上提供。

只是我目前的一个理解

说到底，这篇文章不是要给这几个概念下标准定义。同一个词，不同人理解本来就不一样，不同企业、不同系统、不同业务体系里更是如此。

我现在暂时把它们理解成：

• 承载：网络承担的角色（TMF 的 Resource）
• 能力：网络能做什么（视角，而非独立层级）
• 产品：把能力打包成什么（TMF 的 Service）
• 服务：让客户可以买到什么（TMF 的 Product）

也许还不够严谨，但把这几个概念分开、再挂到 TMF 的框架上，以后读相关文档、想传输网怎么建、怎么开放、怎么支撑新业务，好像都比以前清楚了一些。

顺带记一笔：GSMA / Linux Foundation 的 CAMARA 项目（TM Forum 参与 API 规范）正在做网络能力开放，比如应用按需申请时延/带宽等级的 QoD API，算是“能力产品化”的最新实践，闲了可以去看看。

从 Anthropic 报告谈起，一个不容忽视的安全问题

Sun, 13 Sep 2026 07:40:00 +0000

云端 AI 服务的可见性

近日，Anthropic 发布了关于模型输入风险、凭据滥用、供应链攻击、越权访问以及 AI 应用安全的研究和威胁情报报告，再次引发了业界对大模型安全问题的关注。

报告本身当然值得关注。但从另一个视角看，更值得关注的其实是报告背后的一个问题：为什么 AI 服务商能够发现、分析和还原这些攻击行为？

一个重要原因是，在现有主流云端 AI 服务架构中，用户与 AI 的交互发生在服务商控制的计算和服务环境中。用户请求最终需要进入服务端的计算链路，由模型完成 Tokenization、推理以及必要的工具调用；与此同时，服务侧还可能产生与请求相关的安全检测、会话信息、调用记录和其他遥测数据。具体哪些数据会被记录、保留多久、是否用于模型改进，取决于各服务商的产品策略、企业协议和合规要求；但从架构上看，服务侧至少需要获得足够的明文或明文派生数据，才能完成推理和基础的安全检测。

这些信息使服务商具备了对 AI 交互过程进行观测、关联和分析的能力，从而能够在一定条件下识别异常行为、分析攻击链条，甚至还原部分攻击过程。

当然，这并不意味着服务商可以任意查看所有用户数据，也不意味着所有请求都会被完整保存。具体能够看到什么、记录什么、保存多久，取决于具体服务的架构、产品策略和安全机制。

但从架构层面看，一个基本事实是明确的：只要 AI 推理发生在服务商控制的计算环境中，用户数据就必须进入一种能够被该计算环境处理和理解的状态。对于文本、代码、文档等数据而言，这通常意味着数据本身以人类可理解的形式进入服务端，或者经过 Tokenization 等处理后，仍然保留能够被模型解析和推理的信息，而不是像端到端加密那样始终保持为服务端无法理解的密文。

这与传统意义上的端到端加密通信存在一个根本区别。

在端到端加密场景中，服务提供者可以负责传输和转发数据，但通常无法获得应用层的明文内容；而在云端 AI 推理场景中，模型本身必须对用户输入进行计算，因此服务端计算环境必须能够获得并处理相应的数据。

这就带来了一个过去并不那么突出的安全问题：当数据进入计算环境之后，如何保护它？

这个问题对于企业用户尤其重要。

当企业把源代码、内部文档、客户资料、业务数据甚至核心知识交给 AI 进行分析时，安全边界已经不再只是“数据在网络上传输时是否被窃取”，而进一步涉及：

数据进入 AI 服务后的处理过程；
模型推理过程中的数据保护；
上下文、缓存和中间数据的安全；
AI Gateway、日志和监控等服务环节；
第三方代理、插件以及工具调用形成的新数据链路。

因此，AI 时代的数据安全边界正在发生一个重要变化：传统网络安全关注数据如何安全地传输和存储，而 AI 进一步提出了一个问题，数据如何在计算过程中保持安全。

这也是为什么 Confidential AI、可信执行环境、Confidential GPU、私有化 AI 以及安全 AI Gateway 等技术开始受到关注。

对于运营商而言，这意味着需要重新审视 AI 基础设施的安全边界，以及自己在这一新的安全边界中能够承担什么样的角色。

AI时代的数据安全边界正在发生结构性变化

在传统互联网体系中，数据安全的核心边界相对明确：

确保数据在网络传输过程中不被第三方获取。

因此形成了 HTTPS、TLS、VPN、IPSec 等成熟的网络安全体系。用户发送数据之前进行加密，数据通过网络传输，服务器收到以后再解密处理。对于中间网络而言，看到的主要是一段不可理解的密文。这种安全模型在过去几十年中非常有效。

但生成式 AI 改变了数据的使用方式。

企业今天交给 AI 的，往往已经不是普通的互联网信息，而是越来越有价值的生产数据：

源代码、内部文档、客户信息、网络配置、业务流程、生产数据以及企业知识库。

这些数据进入 AI 服务以后，不再只是“经过网络”。它们还要被：

理解、转换、计算、缓存和生成。

一次典型的 AI 请求，大致会经历：

用户 → API 网关 → 应用服务 → Token 化 → 模型推理 → GPU 计算 → 返回结果

用户请求通过 HTTPS 加密（TLS）传输到云端后，需要在服务端完成解密、解析和后续计算。文本经过 Tokenization 等处理后，进一步转换为模型可以计算的数值表示，进入推理引擎和 GPU 完成计算。

当企业应用的信息通过加密进入AI服务的入口后，转换成可被大模型计算的数据，之后的每一个环节都可能形成新的数据安全隐患。因此，AI 时代安全与传统网络的主要变化就在于：过去主要关注 数据在网络中是否安全 ，而现在还必须关注： 数据在计算过程中是否安全。

为什么数据到了 AI 服务端必须被“看见”？

LLM 的数据处理流程决定了这一点

大模型推理并不是简单地把一段文本送进一个“黑盒”。

一次典型的文本LLM 交互大致经历以下环节：

用户客户端通过 HTTPS（TLS）将文本请求发送到云端 API 网关；
TLS 在网关或负载均衡处终止，被解密为明文数据（包含 Prompt、上下文、参数等）；
服务将文本送入分词器（Tokenizer）转换为 Token ID 序列，再映射为高维向量（Embedding）；
这些向量以浮点数矩阵形式进入 GPU 显存，参与大模型计算。

在这个过程中： TLS 只保护“网络传输阶段” ，一旦到达云端网关就被解密，后续在应用层、推理引擎和显存中均以明文或明文派生形式（Token ID，向量等）存在；拥有服务器权限的运维人员、被攻破的服务进程、以及拿到日志/追踪数据的攻击者，都有能力读取这些内容。

这就是传统传输加密与 AI 计算之间的边界。

澄清误区：Token 化与向量不是加密

部分人存在一个误解：认为文本进入大模型前被分词并转成 Token ID（如把 “Hello” 转成

\[9906\]

），或者转成高维向量（Embedding），就相当于完成了“加密”，这种认识是错误的。

Token化（分词）是公开编码，而非加密，原因是分词只是基于公开词表（如 BPE 算法）进行的确切语义映射与离散化编码，类似将英文字母转为 ASCII 码。任何人拿着公开词表调用 decode() 函数，都能无损还原原始文本。

而向量则是保留明文语义，Embedding 是为模型计算设计的语义表示，保留了高精度的空间与语义关联。研究显示，在特定攻击模型和假设条件下，攻击者有可能从这些向量中部分反推原始文本或推断敏感属性，因此不能把向量化理解为“安全转换”。

所以Token化和向量依然属于“明文数据（plaintext）”的派生表示。只要数据以这种形式在服务侧流转或在显存中计算，数据泄露风险就依然存在。

为什么不能即时通信那样做“端到端加密”？

传统即时通讯的端到端加密（E2EE）要求服务器只做中转，不理解内容：客户端 A 加密，客户端 B 解密，中间服务器看到的只是一堆无意义的密文。

但大模型推理的基本条件就是“ 服务商的大模型必须深度理解文本 ”，总结下来，主要有两点制约了采用加密数据进行大模型计算。

• 语义破坏 ：现代加密算法（如 AES-256）的目标之一，是让不知道密钥的观察者无法从密文中识别原始数据的结构和规律，理想情况下，密文在统计上应呈现接近随机的特征。对于没有密钥的大模型而言，加密后的文本表现为近似随机的序列，其中原有的词汇、句法、语义和上下文关系都不可直接获得。将这样的密文直接用于普通大模型训练，模型无法从中学习原始数据所包含的语言和知识规律，因此无法训练出具有相应语义能力的模型。
• 计算局限 ：普通大模型的推理需要将输入转换为 Token，并进一步形成模型可以进行数值计算的表示，再通过 Transformer 的矩阵运算完成推理。AES 等传统加密产生的密文不能直接作为具有原始语义的输入参与这一过程；在没有专门隐私计算机制的情况下，数据需要先在受信任的计算环境中解密，再转换为模型可以处理的表示。

大模型要能工作，就必须“看懂”原始内容，这本身就决定了它在服务侧不可能处于传统意义上的加密保护状态 。问题也由此发生了变化，过去需要解决的是“ 传输过程中的数据保密 ” ，现在需要进一步解决" 计算过程中的数据保密 ”。这就是所谓的 计算安全 。

从传输安全走向计算安全：两条技术路线

如果希望 AI 在处理数据的同时，又尽可能减少计算环境对数据的暴露，目前大致存在两条技术路线。

全同态加密：密码学上的长期方向

全同态加密（FHE）的核心思想非常直接：允许直接在密文上进行加减乘除等运算，解密后的结果与在明文中计算完全一致。这是一个非常理想的方案。但问题在于计算效率。

现代大模型涉及巨量矩阵运算，同时还包含注意力机制和各种非线性计算。在这些复杂计算场景下，FHE 仍然面临较大的性能和工程成本。在当下，用 FHE 运行大模型生成一个词可能需要数十分钟，暂不具备商业实用性。因此现阶段更适合把它看成： 值得长期关注的密码学技术方向，而不是当前大规模通用 LLM 推理的主流工程方案 。

硬件机密计算（TEE / Confidential AI）：工程上的最佳现实解法

另一种思路完全不同。利用现代芯片（如 Intel TDX、AMD SEV-SNP、NVIDIA H100/B200、远程证明 + 密钥管理）在 GPU 和 CPU 内部搭建硬件级物理隔离的“黑盒飞地（Enclave）”。它并不试图让 AI 永远看不到数据。而是基于一个现实： AI 必须看到数据才能计算。 那么需要解决的就是： 能不能让只有可信计算环境看到这些数据？

这就是 Confidential Computing 和 Confidential AI 的核心思想。其原理就是：数据在用户端通过密钥加密；密文通过加密通道（如 attested TLS）进入芯片内部的硬件安全区；仅在飞地内部解密并计算，计算结果加密后再输出。这种方式的优势在于： 在 TEE 实现本身未被攻破、远程证明可信的前提下 ，哪怕云服务商的运维人员或操作系统被彻底攻破，也无法读取 TEE 内部的内存明文。其性能损耗通常仅在 2%–7% ，多数场景低于 5%，是目前较为可行的“硬件级安全计算端到端保护”方案。

需要强调的是，真正的“机密推理”不是简单打开某个 GPU 的安全功能，而是要把 CPU、GPU 和两者之间的数据传输一起保护起来，并在计算开始前确认整个环境是可信的。

防患于未然：应用部署层面的安全防护措施

在计算安全技术没有大规模应用普及之前，企业在部署 LLM 应用时，可以根据数据敏感程度采取分层防护措施。

客户端与网关侧：动态数据脱敏（Masking & Redaction）

在数据离开企业内网之前部署 AI 网关或脱敏中间件，利用规则和模型识别 API Key、身份证号、客户信息、财务数据等敏感内容，并用占位符（如 [USER_1] ）替换后再发送给公网大模型，返回结果后在企业内部完成还原。

这种方式对结构化敏感信息比较有效，但对于上下文中隐含的敏感信息，以及通过多轮对话逐步暴露的信息，仍然存在识别遗漏的风险。

云端服务侧：严格控制数据留存（Zero Data Retention）

对于需要使用公网大模型、但又不希望数据长期留存在服务商侧的场景，应优先选择具有明确数据留存和训练使用策略的企业级 API 服务，并通过合同、配置和审计等方式进行约束。

需要注意， ZDR 的核心是“不留存”或尽量减少留存，并不意味着数据在 GPU 中推理时就自动处于不可见状态 。如果对计算过程本身也有较高的安全要求，则需要进一步采用机密计算等技术。

部署形态侧：敏感场景采用本地私有化部署（Local LLM）

对于核心代码、重要内部资料以及高度敏感的业务数据，可以将模型直接部署在企业私有云或内部计算节点中，使用 Ollama、vLLM 等推理框架运行开源模型。

这种方式的核心优势是 数据不需要离开企业控制范围 。但本地部署并不意味着“天然安全”，企业仍需负责模型更新、系统安全、访问控制、数据管理以及 GPU 资源和运行成本。

因此，实际部署中可以根据数据敏感程度形成简单的选择：

一般数据 → 云端 AI

敏感数据 → 脱敏后使用云端 AI

核心数据 → 企业私有化部署

这比试图用一种技术解决所有 AI 数据安全问题，更符合目前的实际情况。

对电信运营商的深刻启示

作为拥有庞大网络基础设施、海量高价值用户数据以及承接大量政企信息化建设的运营商（如中国联通、中国移动、中国电信）来说，Anthropic 的报告提供了极具战略价值的启示。AI 时代，运营商参与 AI 安全，不能理解为增加一个新的安全产品，而应充分发挥自身在 网络、云、算力和边缘资源 方面的优势，逐步从“提供连接”向“提供可信的 AI 基础设施”延伸。AI 数据安全将成为运营商进入这一领域的重要切入点。过去运营商解决的是 “企业如何连接云” ，AI 时代可以解决 “企业如何安全地连接 AI” ，再进一步则是 “企业如何获得可信的 AI 计算环境” 。

从连接安全向 AI 使用安全延伸

通过增强AI智能网关能力，将 AI 访问纳入运营商现有的政企网络和安全服务体系。

重点不是运营商自己去做一个大模型，而是帮助企业解决AI 可以访问什么、数据能不能出去、应该使用什么模型，以及整个使用过程如何管理。将 AI 安全与政企专线、云联网、SD-WAN 等现有业务结合，逐步形成面向企业的 AI 安全接入能力。

从提供算力向提供可信 AI 计算环境发展

随着 GPU 算力逐步成为基础资源，单纯提供 GPU 的差异化空间将大大压缩。

运营商可以进一步强化 AIDC 的 可信计算和安全保障能力 ，面向金融、政务、能源、工业以及大型企业等高敏感客户，提供从网络连接到 AI 计算的一体化可信环境。

发展方向可以概括为： 从“卖算力”向“提供可信的 AI 计算服务”转变 。

发挥网络和边缘资源优势，发展分布式 AI

AI 的计算位置将不再全部集中于少数大型数据中心。

运营商应利用现有的省、市、县、园区和企业节点资源，根据业务对时延、数据安全和算力的不同要求，推动 AI 能力向网络边缘延伸。形成 中心算力负责通用 AI，边缘算力支撑低时延场景，本地算力承载高敏感业务 。通过云边协同，使运营商广泛分布的网络和机房资源转化为 AI 基础设施优势。

从单点能力建设走向云—网—边—算一体化

运营商最大的优势并不是掌握某一项 AI 安全技术，而是能同时掌握 网络连接、数据传输、计算资源和分布式节点 ，形成系统级的可信 AI 基础设施解决方案。通过逐步打通 AI 接入、网络连接、算力部署和安全管理，形成统一的 AI 基础设施服务体系，最终实现： 让数据去合适的地方、让 AI 在合适的位置计算，并让整个过程可控、可管、可信。

结语：AI时代的安全边界正在进入“计算内部”

AI 的发展正在改变数据安全的边界。

过去，重点是保护数据在网络传输和存储过程中的安全；现在，企业越来越多地将代码、文档、客户信息和业务数据交给 AI 处理，安全问题进一步延伸到了 数据进入计算环境之后 。因此，AI 时代的数据安全正在从： 传输安全 → 计算安全 → 全生命周期安全。

对运营商而言，在 AI 安全领域的演进可以归纳为一条主线： 从“保障网络连接安全”，向“保障 AI 使用安全”，进一步向“提供可信 AI 基础设施”演进。 其核心不是与专业 AI 厂商竞争模型和算法，而是发挥运营商 网络、云、算力和边缘资源的综合优势 ，成为企业 AI 应用与算力基础设施之间可信赖的连接者、服务者和安全保障者。

最终需要解决的核心问题其实也很简单： 让数据安全地到达 AI，让 AI 在可信的环境中计算。