给智能体系上绳索:Two Sigma 让云端 AI 以你的身份安全运行

Shu Fang, Two Sigma · 2026-09-29
听中文精华AI 合成朗读00:00
你和你的智能体现在是完全相同的身份。
— Shu Fang, Two Sigma

关联

这一集是一场题为《Tethered, Our Agents Are Us》的企业 AI 实践演讲,主角是量化基金 Two Sigma 的 Xu Fang。开场他先解释了公司名字:Two Sigma 的「两个 sigma」不是指两位很潮的联合创始人,而是指小波动率与大波动率之和——把它们加总起来对冲风险、获取差异化的 alpha。他强调观点仅代表个人,不是在推销任何东西或股票。

真正的主题相当大胆:这家有 25 年历史、身处严格监管行业的公司,做到了公司里每个人都有一个云端智能体,而且这些智能体以用户本人的身份运行。为什么他们不但不怕,反而觉得这样更安全?这就是本集要讲的事。

问题:机器身份方案为什么走不通

回到 2025 年 6 月前后,Claude Code 正式发布,大家开始在本地机器上用智能体。能力很强,但有两个限制:一是受限于命令行界面(CLI,就是黑底白字的命令窗口),二是只能在本地跑。

他们想实现的世界是:无论你用手机、Slack 还是浏览器,都能远程使用智能体。这不仅是能力问题——很多很多人,不管懂不懂技术,根本不习惯完全在 CLI 里操作。

于是问题变成:智能体以什么身份运行?常规做法是给它一个机器身份,关联到你的用户账号。但他们发现这条路很快崩溃:权限同步极难维持;任何涉及软件许可的地方,现在得处理两份许可;有些系统(比如 Google Workspace、邮箱)压根不支持多个身份操作同一份底层数据;还有些系统的第一步就是拦截这种身份;另外你还得重新设计公开与私密的边界。

那就反过来——让智能体直接以用户本人的完全相同身份远程运行,之前所有的约束就都不成立了。

地基:现成的个人命名空间

他们手里已有现成基础设施:一个 Kubernetes(管理容器的系统)集群体系,每个区域里每个用户都有专属命名空间,里面所有东西都以该用户身份运行。这套东西不是为智能体建的——而是为了那些不适合塞进某人本地机器的自动化运维:自动化任务、代码容器、研究 notebook 等。

某个触发器进入控制器,请求启动计算资源;一个独立的身份服务被 pod 里的 sidecar(随行辅助容器)拉取凭据,容器挂载该身份后,就以「你」的身份运行。任何用户已有这套东西,所以部署智能体时「一切都已经配置好了」,个人构建智能体、部署进自己的命名空间、以自己的身份运行,不需要额外流程;想推广成全公司通用的,走和普通应用一样的标准机制——生产支持、安全审查。

危险一:分不清是「你」还是「你的智能体」

人和智能体同身份,第一个危险是内部的:某些行动你可能想审计、想拦截,或者至少要有追踪记录和归属——到底是以人类身份操作,还是智能体在做事?演讲者开玩笑说「我留这胡子就是为了让你们暂时分清我们俩」。

他们的解法非常朴素:用一个 header(HTTP 请求头),确保每一个智能体持续向它附加标记,原理和你平时在确定性代码里做 trace ID 完全一样——让可观测性栈把一个 trace ID 贯穿不同系统传播下去。差别只在控制向量是智能体本身。你可以通过 HTTP 客户端、MCP、skills 等已有手段,强制 header 最初被填充、沿途每一处持续被填充——「你对智能体、harness 和框架的控制手段比你想象的要多得多」。

而且收益超出预期:不只是知道行动者是谁,还能获得贯穿系统的完整传播——能够重放导致某个最终结果的整条行动链。对比之下,如果用机器身份,你只会知道「某个时刻机器身份触发了初始流程」,后续动作无法正确回溯到起源点;而有了这个 header,行动者始终是你,链条完整。

有人在问答里质疑:header 本身能被伪造吧?他的回答是:某人当然可以在字段里写上自己在用智能体,但底层的来源身份本身无法被模仿、无法被截获——既有完整的身份生态和链,又有 header,两者配合。

危险二:开放网络访问是最大的恐惧

更大的危险来自 LLM 本身的特性:这些是「时间点上的数学函数」,无法基于当前数据自行更新,所以访问外部网络是核心能力——网页搜索、网页抓取工具。但一旦有了这个能力,你就暴露在巨大的漏洞攻击面之下:数据外泄风险(丢失 IP、暴露敏感信息)、不可信内容回流(提示词注入、恶意软件),还有版权授权合规问题。他坦承「说实话,这是我们最大的恐惧」。

他们的解法是 Google 的 Web Grounding for Enterprise——一个专为受监管行业设计的产品,允许在你现有的 VPC(虚拟私有云网络边界)之内使用 Google 的网页索引,提供搜索(search)和抓取(fetch)两个核心能力,正好镜像智能体需要的网络访问,并附带各种安全保证。唯一缺点是数据不实时:普通内容 24 小时内新鲜、更新频繁的网站 6 小时内新鲜。但对智能体的大多数用例来说绰绰有余,并且完全消除了外部出站(egress)这个漏洞攻击面。

怎么强制智能体走这条路?同样是现有原语:直接 deny 掉 Claude Code 等工具原生的 WebSearch、WebFetch 工具——「这些甚至根本不在你可用的工具套件之中」,然后用重定向,通过 MCP CLI 和客户端代码,让一切网络访问都经过那个缓存索引。有听众追问 Google 自己的策展会不会被攻破——策展很可能是用生成式 AI 做的,确实可能失败,但因为一切保持在内部,提示词注入风险被大大降低。

结果:风险大降,价值没丢

用金融的方式总结:这是个风险与回报的定位问题,他们在优化「回报/风险」比率(类似夏普比率)。最终结论是:没有损失期望价值,同时极大地降低了风险——索引固然有滞后,但相比单纯的纯身份验证,光靠那个打标原语就获得了多得多的可观测性。

最终交付的是一整套框架:云端智能体以用户身份运行,配上部署好的护栏与攻击面防护,以及多种交互入口(让不习惯 CLI 的人也能用),外加为每个用户托管的一队 Claude 等智能体。他还特别想对企业里的人说:生成式 AI 领域确实有大量让安全团队害怕的事情,你不会想在自己本地机器上以完全权限运行一个智能体——恐怖故事一大堆。但在企业里,你可以利用企业资源真正压低那些风险因素,把能力的真实价值拿出来,这才是该投入时间的地方。

问答里还有一个值得注意的前瞻判断:被问到本地 LLM(自托管模型)时,他表示对于企业的大量 token 使用和推理,「自己管理的本地模型」可能是最终方向——因为成本、因为模型弃用、因为每当前沿实验室发新模型就出现性能退化,这种波动性太大;随着开放权重模型越来越先进,他们不需要冒这个险。

本集带走

  • 别用「用户+机器身份」的双身份方案:权限同步、双份软件许可、Google Workspace 这类系统不支持多身份操作同一数据、部分系统直接拦截——这条路会快速崩溃。
  • 让智能体以用户本人身份跑,但必须系上绳索:利用企业已有的个人命名空间基础设施(每用户、每区域、以用户身份运行),智能体部署进去就行,不需要新建东西。
  • 归属追踪用打标原语就能做:一个持续附加的 header + trace ID 式传播,不仅分清了「人做还是智能体做」,还能重放完整的行动链;身份本身防伪造,header 负责标记。
  • 安全上网用内网化的缓存索引替代开放访问:封掉原生的 WebSearch/WebFetch 工具,把所有网络访问重定向到 VPC 内的索引服务,数据新鲜度 24 小时内对多数用例足够,换来外部出站攻击面归零。
  • 对企业的启示:别因为「太前沿不敢上」就把智能体拒之门外——用企业级资源把风险因素压下来,期望价值可以不丢。
全部金句 3 条

你和你的智能体现在是完全相同的身份。
You have you and your you agent are now the exact same identity.
—— Shu Fang, Two Sigma · [05:19]

你对智能体、harness 和框架的控制手段比你想象的要多得多,你可以用一些已有的原语来强制执行它。
You have a lot more determinants to control over agents and the harnesses and the frameworks than you may think, and you can enforce it with some of the already existing primitives.
—— Shu Fang, Two Sigma · [08:44]

但提示词注入的风险被大大降低了,因为一切都保持在内部。
But the prompt injection risk is far reduced because everything still remains internal.
—— Shu Fang, Two Sigma · [18:15]

接着看

顺着「智能体」挖下去

换个口味