← 博客

这是提示注入吗？不是——原因在此

2026-07-19 · 博客 · prompt-injectionsecurityconsent

敏锐的人对操作层提出的第一个问题，正是那个对的问题："一个网站告诉我的 AI 该做什么，这不就是提示注入吗？"它值得一个直接的回答，因为这个区别不是什么细枝末节——它就是整个设计。

提示注入到底是什么

提示注入是一种攻击。指令被藏在内容里——白色文字、埋进 HTML 的东西、一份被投毒的文档——好让智能体在用户不知情、也未经用户同意的情况下执行它们。三个决定性特征：

1. 隐藏。 用户从来看不到那条指令。
2. 劫持。 它服务于攻击者的目标，凌驾于用户的目标之上。
3. 未经同意。 它未经许可就执行。

每一个严肃的智能体平台都针对这一模式构建防御。理应如此。

操作层是什么

操作层是一个服务公开发布的、机器可读的上下文——是 robots.txt、sitemap.xml 和 llms.txt 的同类——它让用户自己的 AI 智能体在得到用户许可后，替他采用并操作这个服务。逐项特征对比一下：

1. 公开发布。 它位于一个已知的公共位置，任何人都可读——用户、智能体、审计者、竞争对手。什么都没藏。
2. 服务于用户的目标。 用户派他的智能体去完成某件事——注册、购买、配置。这个层是发布者在帮助用户自己的任务成功，且完全按照发布者为用户的智能体所定义的方式。
3. 以同意为门槛。 智能体把这个层呈现给它的用户，并在行动前询问。一个"好"才授权——一次性或逐项操作。参见同意门。

注入把指令藏起来，以便违背用户去劫持智能体。操作层则发布出智能体会向着它的用户展示的协助。它们在每一条要紧的轴线上都是相反的。

一个网络早已信任的类比

robots.txt 就是一个网站在告诉爬虫该做什么——而没有人管它叫攻击，因为它是公开的、标准化的，并且与爬虫想要的行为方式相一致。sitemap.xml 告诉引擎该索引什么。llms.txt 告诉 AI 该读什么。操作层把这同一个被信任的模式又向前延伸了一步：以同意为门槛，且是可操作的，而非仅仅是描述性的。

网络一直是这么运作的。发布者声明；行为良好的客户端读取声明，并在它们自己的规则之内行动。

录制的测试显示了什么

在录制的测试会话中，多个独立的 AI 助手抓取了一个已发布的层，并呈现出了同意问题。那个观察仅限于那些会话，并不能证明这个格式是安全的、普遍兼容的，或对提示注入和授权风险免疫。

公开发布和明确确认，让来源和权限更容易评估。每个助手仍然必须应用它自己的规则、校验被请求的动作，并且可能拒绝。

护栏仍然重要

透明加同意是核心防御，但一个构建良好的层还在其上增加了纪律：它声明能力而不是发号施令，把每一个操作都保持在六个通用类别之内（评估、注册、交易、配置、使用、管理），并且从不要求智能体去做用户批准范围之外的事。服务控制图说明每个操作是如何被驱动的——API 端点、函数/动作、界面控件——附有输入、顺序和预期结果，这样就没有让智能体误读的含糊之处。操作是如何被映射的，在 /how-it-works 中有讲述。

为什么这对发布者很重要

信任是一个采用因素。用户能评估他们看得到的指引，而智能体必须应用它们自己的保障措施。我们发布的每一个层，都按构造遵循透明与同意的模式——从免费套餐的单个网址，到覆盖你域名下至多 10 个网址的基础套餐（每月 $29）。

隐藏的指令和公开的厂商指引呈现出不同的风险。透明和确认减少含糊；它们并不消除攻击、混淆代理人、恶意端点或授权风险。

常见问题

攻击者会滥用操作层这个格式吗？

这个格式在设计上就是要让滥用变得没有吸引力：这个层的力量来自同意，而无论发布了什么，在任何事发生之前都会被呈现给用户。公开性和同意门大幅降低了隐藏指令的价值——它们并没有让攻击变得不可能，这正是为什么智能体平台保留它们自己的防御，也是为什么用户在说"好"之前，仍应审查智能体所提议的内容。

为什么智能体会服从，而不是无视这个层？

录制的会话显示，助手们抓取了这个层并呈现出了同意步骤。其他助手或更晚的版本可能会无视它、对它发出警告、误解它，或拒绝它。

每一次都会发生同意吗？

同意门支持两种模式：采用一个服务时的一次性授权，或针对单个动作的逐项操作批准。发布者声明；用户的智能体和用户来决定。

继续阅读

https://swma.link/bcbf18db