Ken Thompson 这个名字在今天大多数 AI 应用层开发者眼里可能更像一段「计算机远古史」。他是 Unix 的联合发明者是 B 语言和 Go 语言的创造者也是 1983 年图灵奖得主。他职业生涯的高光时刻和深度学习、大模型、Agent 这些热闹概念几乎毫无交集。甚至在一些公开访谈场合他对 AI 话题的态度表现得相当谨慎甚至有记者形容他「听到 AI 就想转身离开」。但如果因为这一点就忽略他对 AI 的看法我们很可能会错过一个真正有价值的技术判断框架。Thompson 最著名的图灵奖演讲《Reflections on Trusting Trust》讲的不是如何写出更好的编译器而是讲清楚了一个到今天依然让所有 AI 工程师头疼的问题一个系统如果要依赖它自身的输出来判断它是否可信那你到底该信什么这个问题的现代版本就是大模型时代的「信任链」问题。模型训练数据是否被污染权重文件是否被篡改RAG 知识库里的内容是否安全Agent 调用的工具是否被注入甚至你用来审查 AI 代码的另一个 AI 是否可靠——这些环节里只要有一个失守整个系统就可能在你完全信任的状态下崩溃。这篇文章不打算编造 Ken Thompson 的语录也不会假装他发表过系统的 AI 评论。我们要做的是把他的工程思想和已经公开的技术事实放在一起看看这位曾经用编译器演示「如何在系统内部种下后门」的人会怎样提醒我们看待今天的 AI 系统。同时文章会给出对应的工程实践路径包括模型供应链审计、输入输出日志、最小权限部署等可以直接落地的方案。1. 为什么今天要重新谈 Ken Thompson过去两年AI 领域出现了大量「快速上线」的工程方式预训练大模型直接拉权重文件微调脚本来自开源社区Agent 框架自动调用外部工具研发团队在几个小时内就能拼出一个能聊天的应用。这个流程确实把 AI 应用的开发门槛拉到了史上最低但也带来一个很隐蔽的问题整个系统里没有任何一个环节能证明自己是「绝对可信」的。这件事在传统软件工程里同样存在但严重程度完全不同。传统代码出了问题你可以从报错堆栈往回追定位到具体行甚至用调试器看到变量值模型出了问题你往往只能看到一个概率输出无法解释它是拿什么依据生成的。Ken Thompson 在三十多年前就意识到如果信任的根基放在「系统自身生成的工具」上那么这个根基就是不牢靠的。他的演示方式是在编译器里植入后门让编译器在编译登录程序时自动生成一个后门账号——关键是这段恶意代码永远不会出现在登录程序的源码里。把这个场景平移到今天的 AI 系统你会发现几乎一模一样的结构你在本地拉了某个量化压缩过的模型权重它和官方发布的 sha256 不一致但模型能跑通于是你忽略了校验结果可能是模型被植入后门你在开源社区找了一个微调脚本脚本会在你启动训练时悄悄连接外部地址上传你的私有数据集你的 Agent 框架自动加载了一个「工具描述」描述里包含恶意提示词结果模型在调用工具时被诱导执行了非预期动作甚至你为了审查 AI 生成代码引入了另一个 AI 代码审查工具而这个工具本身也被提示词攻击污染了。这正是 Ken Thompson 的核心洞察在 AI 时代的重新上演。他真正关心的不是「AI 是不是能取代程序员」而是一个更根本的问题你凭什么相信你手里的系统行为真的和你以为的一致。这也是为什么我认为 AI 应用开发者中最应该了解 Ken Thompson 思想的人不是研究模型算法的科学家而是负责部署、集成和运维的工程师。因为他们才是最终为「信任」兜底的人。如果说 Thompson 的编译器后门实验告诉大家「不可信系统可以伪装成可信系统」那么今天 AI 工程要做的事情恰恰是承认所有环节都可能被污染然后用工程手段把「信任」拆解成可验证、可审计、可回退的组件。2. Ken Thompson 的思想背景RTT、Unix 与工程直觉要理解 Ken Thompson 为什么会对 AI 保持谨慎需要先理解他是怎么思考软件系统的。Thompson 是典型的「构建者」型程序员他亲自动手写过操作系统、编译器、正则引擎、文本编辑器这些工作让他对系统的底层运行机制有非常直观的体感。他不是理论家不写长篇论文他的思想全部体现在能跑的代码里。他最著名的思想实验来自 1983 年的图灵奖演讲业界一般简称 RTT。整个演讲核心非常短你可以修改一个 C 编译器让它把所有编译出来的登录程序都加一个后门口令然后你再修改编译器的编译程序把「包含后门逻辑的编译器」这个传染过程也编进去最后你把系统里的编译器源码全部恢复成干净版本。这样一来你不需要碰登录程序的源码不需要碰编译器当前的源码后门依然存在于整个构建链里。这个实验最让人不舒服的地方在于没有任何一层源码能证明自己是干净的。你检查登录程序源码干净你检查编译器源码干净但最终产物已经不可信了。系统的可信性建立在一个你无法直接查看的、历史递归的信任链上。放到今天的 AI 工程里这个递归结构可以对应为你用大模型生成微调代码然后用这些代码去微调另一个模型你用 AI 审查 AI 生成的安全审计报告然后信任这份报告你让 Agent 读取网上的资料自动更新知识库然后基于这个知识库回答用户问题知识库里的内容可能已经被投毒。Thompson 的回应方式不是「不要用任何工具」而是保持一种工程怀疑每一步产出都要有独立的验证手段每一条信任链都要明确知道它从哪里延伸过来。他在 Unix 设计中同样体现了这种实用主义。Unix 哲学提倡「每个程序做好一件事程序之间用管道组合」很多人以为这是美学偏好实际上这是一种信任策略程序越小功能越单一越容易审查它的行为。大而全的框架很难逐行审计但小工具的管道组合你可以逐步追踪数据流向。这给了我们一个非常实际的启发在一个连 AI 本身都可能不可靠的时代系统架构应该尽量让「关键信任点」保持小、少、可见。不要让你的业务逻辑、模型调度、外部工具调用、权限管理全部揉在一个 Agent 框架里否则你根本没有办法定位信任破裂的位置。3. 把 Thompson 的追问带到今天的 AI 系统如果 Ken Thompson 以评委身份来看现在市面上常见的 AI 应用他大概率不会关心「这个模型在测试集上跑多少分」而是会直接问围绕系统可信性的几个问题。第一个问题是你的模型权重从哪里来是否经过完整性校验。训练一个大模型成本太高大多数团队选择在开源权重上做微调但权重文件是二进制的很难人工验证行为是否被篡改。如果你只在官方页面点击下载而没有保存哈希值、没有校验文件一致那你实际上是在盲目信任下载通道和托管方。这类风险可以用一句通俗的话概括别人给你什么模型你就跑什么模型这和直接运行一个不明来源的可执行文件没什么本质区别。第二个问题是你的系统是否知道自己的输入可能被恶意构造。Thompson 的编译器后门本质上是把一个恶意行为藏进了输入源里。今天的提示词注入、间接提示注入走的是同一个路子——攻击者不需要修改你的代码只需要构造一段「输入文本」引导模型执行附加指令。如果你的应用只是简单地把用户输入拼接进 prompt再让模型连接数据库查询、读网页、调用 API那么模型执行命令的权力就是攻击者执行命令的权力。第三个问题是你是否保留了从不可信状态回滚的能力。Thompson 的编译器实验最让人震撼的地方在于「连源码都是干净的」你根本不知道从哪里开始清洗。在 AI 工程里这种情况的对应物是模型已经上线两周后你才发现某些用户对话触发了非预期行为但数据已经被用来做进一步微调日志已经被冲掉你连排查都无从下手。没有版本化、没有日志留存、没有权重快照系统就是不可回滚的。第四个问题是你用什么来证明你的 AI 没有在长期运行中发生漂移。传统软件的行为是确定的同一份代码、同一份输入在同一个环境里永远得到同一个输出。模型不是这样它可能因为在线学习、上下文窗口、外部检索内容变化甚至因为服务端悄悄升级了模型版本而行为漂移。没有监控、没有自动对比基线的能力你就无法判断「今天的 AI 还是不是我审计过的那个 AI」。这四个问题如果放到 CSDN 读者熟悉的语境里其实就是 AI 工程实践中的几个核心主题供应链安全、输入与权限边界、数据可回溯性、模型版本监控。它们不是模型训练算法要解决的问题而是每个做 AI 应用落地的人都绕不开的工程问题。4. AI 时代的信任链从编译器后门到供应链投毒很多开发者对「AI 供应链攻击」缺少画面感觉得那是安全团队的事。我们用 Ken Thompson 的框架拆解一下你会发现它和 RTT 的递归结构高度相似。经典的软件供应链攻击是「在依赖库里投毒」你下载了一个 npm 包或者 Python 包里面被塞入了恶意代码运行依赖时触发。这种事已经屡见不鲜开发者的防护手段是依赖锁定、哈希校验、代码审计。AI 时代把这条链条拉得更长至少包括以下几个环节预训练权重模型文件巨大下载源多哈希缺失一旦权重被篡改你得到的是一个「黑盒后门模型」。这个模型可能在标准测试集上表现完全正常但对某个触发词输出恶意内容。微调数据集开源数据集可能被投毒如果训练脚本没有数据清洗和过滤模型会学进攻击者想要的行为模式。LoRA 适配器社区发布的 LoRA 权重很小行为不可解释加载一个社区 LoRA 的信任风险相当于直接运行一段不可审计二进制代码。RAG 知识库文档里嵌入恶意指令检索时被拼进 prompt实现间接提示注入。攻击者甚至不需要攻破你的系统只要在公开网页上放一段「AI 指令」你的模型在检索时就会读到。Agent 工具生态模型可以调用外部 API工具描述本身可能包含恶意提示词模型会被引导调用非预期的工具或参数。把这些环节映射到 Ken Thompson 的 RTT 实验里就会发现传统系统里信任的终点是「源码」AI 系统里信任的终点变成了「非确定性的参数和外部输入」。这是一个根本性的变化——你没有办法通过阅读参数来检查模型的行为也没有办法通过审查 prompt 来确认模型不会曲解指令。所以AI 系统的防御思路必须改变不能指望「某个环节绝对干净」必须假设每个环节都可能被污染然后在环节之间建立验证点。这正是我认为 Thompson 思想在今天最有价值的落点他不是告诉你「不要信任 AI」而是告诉你「信任必须被拆开放到能被验证的地方」。如果模型本身不值得信任那就在模型外面加隔离层如果 prompt 可能被注入那就在工具调用前加白名单校验如果权重可能被篡改那就在部署流水线里加哈希验证。把信任拆分给工程机制而不是交给某一个黑盒。5. 从思想落到工程AI 供应链审计的最小实践说完了思想接下来落到代码。以下三个示例对应 AI 工程实践中最常见的三类信任需求权重完整性校验、AI 输入输出审计日志、最小权限部署。它们都可以在本地环境运行不依赖特定云平台适合你先在小规模验证再移植到自己的流水线里。5.1 模型权重与依赖完整性校验这是最基础但也最容易被忽略的一步。无论模型是从 Hugging Face、ModelScope 还是企业内部存储下载都应该在下载后校验哈希。你可以保存一个官方发布的 sha256 值然后用下面的脚本自动比对。#!/usr/bin/env bash # 文件路径scripts/verify_model.sh # 用法./verify_model.sh ./models/qwen2.5-7b-instruct/model.safetensors set -euo pipefail MODEL_PATH$1 EXPECTED_HASH${2:-} HASH_FILE${MODEL_PATH}.sha256 echo 开始校验文件${MODEL_PATH} # 如果外部没有传入期望哈希则尝试读取同目录 .sha256 文件 if [[ -z ${EXPECTED_HASH} -f ${HASH_FILE} ]]; then EXPECTED_HASH$(cut -d -f1 ${HASH_FILE}) fi if [[ -z ${EXPECTED_HASH} ]]; then echo 错误未找到预期哈希请显式传入 sha256 值或提供 ${HASH_FILE} 文件。 exit 1 fi ACTUAL_HASH$(sha256sum ${MODEL_PATH} | awk {print $1}) if [[ ${ACTUAL_HASH} ${EXPECTED_HASH} ]]; then echo 校验通过${MODEL_PATH} else echo 校验失败文件不匹配。 echo 实际哈希${ACTUAL_HASH} echo 预期哈希${EXPECTED_HASH} echo 请立即停止部署检查下载源是否可信。 exit 2 fi这段脚本的逻辑很直白比对实际哈希和预期哈希不一致就退出失败。关键点是你应该让「校验失败即终止」成为部署流水线的默认行为而不是在控制台打印一行警告然后继续。从 Ken Thompson 的角度看这个过程解决了「你下载的模型到底是不是你以为的那个模型」的问题。5.2 AI 服务输入输出审计日志很多 AI 应用出问题时第一反应是模型不行实际是输入里包含了恶意构造的 prompt或者输出被外部工具错误地解析。没有审计日志你只能靠复现而复现大模型行为本身就非常困难。以下 Python 脚本演示了如何在调用模型前后保留结构化日志便于事后回溯。# 文件路径src/ai_audit/audit_logger.py AI 服务审计日志示例 在模型调用入口和出口各记录一条结构化日志 方便追溯什么时候、谁、以什么输入、拿到什么输出、调用了什么工具。 import json import time import uuid from dataclasses import dataclass, asdict from typing import Optional dataclass class AuditRecord: request_id: str user_id: str app_id: str model_name: str input_text: str output_text: str tool_calls: list prompt_tokens: int completion_tokens: int latency_ms: int created_at: int class AuditLogger: def __init__(self, log_path: str ai_audit.jsonl): self.log_path log_path def write(self, record: AuditRecord): with open(self.log_path, a, encodingutf-8) as f: f.write(json.dumps(asdict(record), ensure_asciiFalse) \n) class AiServiceWithAudit: 这是简化示例实际模型调用请替换为你的模型服务客户端。 def __init__(self, audit_logger: AuditLogger): self.audit_logger audit_logger def call_model(self, prompt: str, user_id: str, app_id: str) - dict: request_id str(uuid.uuid4()) start_time time.time() # 在实际项目中这里会调用 OpenAI、本地 vLLM、Ollama 等模型服务。 # 注意不要在生产代码里使用下面这行假实现它只是占位。 raw_output f模型模拟输出{prompt[:20]} latency_ms int((time.time() - start_time) * 1000) record AuditRecord( request_idrequest_id, user_iduser_id, app_idapp_id, model_namedemo-model, input_textprompt, output_textraw_output, tool_calls[], prompt_tokenslen(prompt.split()), completion_tokenslen(raw_output.split()), latency_mslatency_ms, created_atint(time.time()), ) self.audit_logger.write(record) return {request_id: request_id, output: raw_output} if __name__ __main__: logger AuditLogger(demo_audit.jsonl) service AiServiceWithAudit(logger) service.call_model(请查询今天上海到北京的航班, user_iduser_001, app_idflight_app) print(审计日志已写入 demo_audit.jsonl请打开查看。)这里真正重要的不是模型输出本身而是它创建了一个「可追溯的现实」未来任何一次事故复盘你都可以回答三个问题——模型当时收到了什么内容模型返回了什么结果以及调用链上的用户和上下文是什么。没有这些信息所谓排查 AI 系统异常基本等于盲人摸象。5.3 最小权限部署配置大模型服务一旦接入外部工具权限管控就变得至关重要。绝不能让 Agent 进程拥有数据库所有表的管理权限更不能让它带着生产环境的最高凭证去调用外部 API。下面是一份最小权限部署的配置示例你可以按需调整后用于 Docker Compose 或 Kubernetes 的环境注入。# 文件路径deploy/agent-service.env.example # 这份配置演示的是最小权限思路实际值请根据安全策略替换。 # 模型服务地址只允许访问内部模型网关禁止直连公网模型 MODEL_ENDPOINThttp://ml-gateway.internal:8000/v1 # 数据库连接只授予业务所需的最小权限 # 例如只允许 SELECT禁止 DROP、TRUNCATE DB_HOST10.0.1.20 DB_PORT5432 DB_NAMEbusiness_readonly DB_USERrag_reader DB_PASSWORD${DB_PASSWORD_FROM_SECRET} # 外发网络限制Agent 默认关闭对外访问 AGENT_OUTBOUND_ENABLEDfalse # 工具调用白名单只有这里列出的工具名可以被 Agent 调用 TOOL_ALLOWLISTquery_flight_info,check_weather,calc_expression # 文件读写路径Agent 只能访问指定临时目录 AGENT_TMP_ROOT/tmp/agent_workspace # 日志级别生产环境必须 INFO 以上 LOG_LEVELINFO这份配置的核心思想是不要把模型服务当成可以信任的内部执行者要把它当成一个「可能被外部输入操控」的组件来隔离。它默认关掉外发网络默认限制工具白名单默认只给数据库只读账号。用 Thompson 的话说你是在给「系统自身可能不可信」这一预设留出防御空间。6. 运行与验证如何判断这套机制有效以上三个示例不能只是跑通就完了你需要确认它们真的能拦截异常。建议按下面顺序验证。先用命令行执行哈希校验脚本。到模型文件所在目录手工把预期哈希改错一个字符再运行脚本正确的行为是输出校验失败并退出码为 2同时流水线终止。如果脚本在哈希不匹配时继续执行后续任务说明你的流水线逻辑有问题。然后运行审计日志脚本。启动后模拟发起一次模型调用打开demo_audit.jsonl检查 JSON 结构是否完整。注意查看时间戳字段确认created_at和latency_ms是否正确记录。如果你在生产环境里把日志接到了 ELK 或 Loki要额外确认日志没有因为字段缺失而解析失败。最小权限部署的验证方法更直接用只读账号执行DROP TABLE确认数据库拒绝关闭AGENT_OUTBOUND_ENABLED后在 Agent 容器里尝试访问外部网络确认超时或被网关拦截把未加入白名单的工具名传给 Agent确认调用被拒绝。这些验证其实是在回答 Ken Thompson 式的提问如果你构造一个「恶意输入」系统是否能以可预期的方式拒绝或失败如果拒绝逻辑不工作那么这个系统就谈不上可信。7. 常见问题与排查思路7.1 模型下载后哈希校验失败问题现象可能原因排查方式解决方案sha256 不一致下载过程中文件损坏重新下载并比对哈希使用断点续传工具或下载官方分片文件sha256 不一致下载源被劫持或文件被替换对比官方其他镜像源的哈希立即停止使用该来源切换可信源sha256 不一致使用了字节不完全一致的转换格式确认是否对模型做了量化转换以转换后的最终产物为准重新计算哈希7.2 Agent 没有调用预期工具问题现象可能原因排查方式解决方案Agent 一直不调用工具工具描述不够明确或模型上下文过长被截断查看输入日志确认工具描述是否完整出现在 prompt 中精简工具描述把关键指令放在更靠前的位置Agent 调用了未授权的工具工具白名单未生效检查配置是否被注入到运行时环境确保从 Secret 管理组件注入环境变量避免写死配置文件Agent 调用功能正常但权限报错数据库账号权限不足查看数据库错误日志按业务实际所需授予最小但足够的权限7.3 AI 输出出现非预期内容问题现象可能原因排查方式解决方案模型回答突然偏离主题RAG 检索内容里存在干扰检查检索结果片段增加内容过滤与来源白名单模型被诱导执行额外指令用户输入包含恶意提示词在审计日志中查看原始输入增加输入改写或隔离规则限制工具调用的上下文同一问题多次回答不一致模型版本被服务端更新检查模型网关的版本记录固定模型版本发布前做回归对比这些排查项有一个共同点不能只看最终输出要回到日志和配置里去查「模型到底看到了什么」。没有审计数据所有排查都只是猜测。8. 最佳实践与工程建议结合前面的分析这里给出几条可直接用于团队协作和生产部署的建议。第一条把模型当依赖管理而不是当服务黑盒。拉取开源权重之前先检查是否有官方哈希微调之后重新计算产物哈希并记录在发布单里。每次模型版本变更都要像升级数据库中间件一样走完整的发布评审流程而不是改个 prompt 就灰度上线。第二条prompt 不是代码不能裸奔。不要把系统提示词、工具描述原样拼进模型输入至少做一层套娃隔离将用户输入与系统指令分开存放在拼装时对用户输入做长度限制和敏感词过滤。对可能影响工具调用的文本最好在拼入之前单独做一次分类判断。第三条AI Agent 的权限边界必须显式声明。建议在配置文件里维护一个工具白名单任何新增工具都必须经过代码评审。Agent 能够访问的数据系统一律使用只读账号。对于必须写操作的任务单独走人工审批流程不要让 Agent 自主完成全链路写操作。第四条日志不是可选项而是安全审计的基础设施。模型输入、输出、工具调用参数、耗时、用户上下文全部结构化落盘。存储成本高你可以压缩、可以归档但绝不能没有。出事故的时候你会非常庆幸自己留下了这些数据。第五条为模型行为建立基线样本集。挑几十条属于你业务核心场景的典型输入在模型每次升级前后跑一遍自动对比输出差异。这样可以尽早发现「模型变笨了」或者「行为漂移了」这类很难用传统监控发现的问题。第六条部署采用灰度与回滚策略。AI 应用切忌一刀切全量上线。先让 5% 流量走新模型观察审计日志中的异常率再逐步放量。如果模型行为出现严重偏差要有能力在几分钟内切回旧版本而不是重新训练一个模型。第七条不要用 AI 审查 AI 的所有判断。你可以借助另一个模型做辅助分析但关键的安全决策必须有人工确认节点。尤其在工具调用、数据删除、财务操作这类高影响场景必须保证人的否决权高于模型。9. 对我们的实际提醒回到 Ken Thompson 本身。他在 AI 话题上留下的公开言论不多但他的工程思想对今天的 AI 从业者确实有很强参考价值。这个价值不在于他告诉我们要不要用 AI而在于他提醒我们当系统变得越来越复杂、越来越自动化最难保持的往往不是性能而是可理解性、可验证性和可回退能力。如果你正在做 AI 应用集成或模型部署建议先停下来做一个审计清单你的模型权重是否有哈希校验你的 Agent 是否有工具白名单你的日志是否可以在出问题时回溯到「模型输入的具体内容」你的系统是否能在几分钟内切回上一个可信状态。这四个问题如果任何一个回答不了那你的 AI 系统还停留在「能跑」阶段远没有达到「可信」阶段。工程世界里的每一次技术浪潮都会带来新的工具和新的效率但一些最根本的问题不会变你凭什么信任你构建的系统你用什么机制守住信任的底线。Ken Thompson 当年用编译器演示了信任的脆弱今天的大模型把这种脆弱放大到了前所未有的程度。理解这一点比跟着热词追逐每一次模型更新更有价值。