2026西湖龙井茶官网DTC发售：茶农直供，政府溯源防伪到农户家
我们的内部人工智能代理通过一次提示词操作，就完成了过去需要花费十分钟在用户界面中点击才能完成的工作。用户用自然语言描述一个外发任务，代理与我们的模型上下文协议服务器通信，任务便在无人操作用户界面的情况下构建完成。任务具有生命周期：草稿处于非活动状态且可编辑，已发布的任务会运行，草稿状态的核心意义在于不会触发任何操作。
我们当时正在对其进行漏洞排查。计划充满攻击性：提示词注入、角色劫持、能力探测，搞垮它。我们要找到边界情况，希望比团队外的任何人都更清楚地了解其极限，这样我们才能找出缺失之处，并明确产品的真实状况。
经过一小时毫无结果的操作后，我们改变了思路。与其试图搞垮它，何不直接让它执行本职工作？有人输入：使用这些设置创建一个任务。仅此而已。没有发布步骤，仅创建。
任务以草稿状态落地。我们继续试探，随后一行日志显示有一个任务针对它执行了操作。任务不应在草稿状态下执行，这是该状态存在的核心意义。我心想这可能是噪声干扰，随后该任务的一封投递邮件出现在我的收件箱中，这是一封发送给真实收件人的真实邮件。那一刻，“奇怪的日志”变成了“这已在生产环境中上线”。
一张高优先级工单派给了我。当大型语言模型附近发生奇怪事情时，每个人的第一直觉都是：人工智能做了不该做的事。用户界面版本已在客户手中运行很久，未发生事故。唯一的变量是模型，因此我着手在此处排查。检索增强生成配置错误。模型上下文协议边界。提示词注入。角色和权限。工具封装。一切均正常。代理接触的任何内容都不应能够触及触发投递的队列。
在耗尽所有假设之前，我耗费了大约一个小时。并非灵光一现，而是筋疲力尽。于是我改变了问题：人工智能与用户界面的操作有何不同？我对比了两者的负载数据。其中一个键值不同：dispatch: { primary: true, secondary: true }。用户界面在草稿状态下从未发送此字段。代理发送了，因为它如实地读取了架构定义。在下流系统中，一个优先队列监视着该字段，判定该任务已逾期，并立即触发了它。即刻从草稿状态触发。
修复方法是在队列处理器中添加一行代码：
if (status === 'draft') return;
这是一个本应从第一天就存在的防护机制。该漏洞已潜伏许久，等待除我们自家用户界面之外的任何客户端使用符合架构定义的负载调用创建端点。代理是第一个这样做的客户端。一个条件判断语句。这就是整个补丁的全部内容。
代理并未引入该漏洞。它是我们的应用程序编程接口的第一个尊重架构定义而非遵循用户界面所遵守的潜规则的客户端。你的前端消费的每个应用程序编程接口都依靠后端未强制执行的约定来维持。状态防护应位于处理器中，而非依赖调用者的自律。信任前端保持沉默不是一种契约，而是一场赌博。你的后端中还有多少其他端点仍在进行这场赌博？
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
