关于你智能体的滥用申诉

搞清楚申诉方手里实际有什么。

不对称定义了这整件事。一个来申诉滥用的第三方，手里握着一个时间戳、一个来源 IP、一个 user-agent 字符串、一条路径或一个受影响的资源，可能还有一个流量数字。他们不知道你的租户模型、不知道流量来自哪个产品，甚至不知道你跑智能体。他们点不出一次运行、一个客户，或一条提示词。

而你这边握着关于运行的一切，却没有任何一项是按他们所发的东西建索引的。轨迹按运行与会话做键；出站按目的地做键；而那个分配了该 IP 的 NAT 或代理池会轮换，常常是按小时轮换，它的分配日志通常是整个栈里存活最短的记录。于是第一个问题——这是我们吗——是一次跨三个系统、归三个团队的联表查询，而联接键是三方都没有选过的那一个。

让出站请求自我标识，这就是全部的投资。

一个下午的工作，决定了今后每一份申诉是花一小时还是花一周。第三方能观测到的一切，都必须带上某个你能查的东西，而且它必须由 HTTP 客户端发出，不能靠约定来保证。

• 线路上的运行标识。在每一次由智能体发起的请求上加一个请求头，对接收方不透明、而你能把它解析到一次运行、一个租户与一个产品。这是本页杠杆率最高的那一行代码。
• 一个诚实的 user-agent，带联系 URL。一个产品标记、一个版本，以及一个能解析到「这是什么流量、怎么联系你」那一页的 URL。一个看得清是谁打了他的陌生人，通常会先写给你、而不是先写给你的供应商。
• 一份按他们所见建键的请求日志。目的主机、来源 IP、时间戳、运行标识——可按 IP 与时间窗查询，保留期长于你的轨迹，远长于你的 IP 分配记录。这就是那个让联表成为可能的索引。
• 让出站走一条会记日志的通路。一个按任务限定范围的代理是这三样天然的落脚处，也是唯一能把「没人记得的那些代码路径」发出的流量一并接住的地方。

有获授权的身份机制的地方，就用它：签名智能体一类的方案，让站点能以密码学方式核验某份流量确实是你的，而不是听一个请求头的说法——这就把一场归因争论变成了一次查表。这正是机器人核验与智能体访问所讲的事，站在接收的那一侧。

把那个收件箱路由给一个答得出来的人。

多数组织把 abuse@ 路由给一个安全队列，而那个队列是为「关于打进来的攻击的报告」调过的。一份滥用申诉是它的镜像——一份关于出站行为的投诉——而接到它的那个队列通常查不了智能体遥测、不拥有出站代理，也对某个产品团队的流量没有权限。

• 点名一个负责人，并在需要之前就把手册写好。接收、分诊、调查期间「先停下」的默认处置、谁可以跟申诉方说话、谁能把一个机群停掉。这就是把问责与角色套用到一个外部给你计着时的案子上。
• 把这条路公布出去。abuse@、user-agent 里的联系 URL，以及一个陌生人能从一条 IP WHOIS 记录找到的页面。找不到你的申诉不会消失；它们会改道经由你供应商的信任与安全团队抵达，而你坐在对话的错误一侧。
• 让「停下」在几分钟内可达。调查期间的默认答案是对那一个来源停止该行为，这要求熔断开关的粒度是按目的地、而不是按部署。如果你唯一的拉杆是「把产品关掉」，你就不会去拉它，而那份申诉就会升级。
• 每季度演练一次这条路。给自己发一份像真的申诉——一个 IP、一个时间窗、两句话——然后给作答计时。失败几乎从来不在调查上；而在于那封邮件在队列里躺了三天。

把那次运行重建出来，然后把问题放大。

有了 STEP 2 里的索引，第一次查询是机械的：IP 加时间窗给你候选请求，运行标识给你轨迹，而轨迹告诉你智能体当时想做什么。回信之前先读它，因为真正有意思的发现几乎从来不是申诉里那一条。

要确立三件事，按这个顺序：

• 是一次运行，还是一个总体？一个行为异常的智能体是一次事故；而同一个模式出现在几百次运行上，那是一个设计默认，而申诉方只是恰好是第一个大到能注意到的来源。请按目的地在整个机群上查，而不是按运行查。
• 那个行为在范围内吗？把实际发生的事，对着「这次运行被授权去做的事」比一比。一次超出了「它压根没有过」的预算的抓取，是一道缺失的控制；而对一个任务从未提到过的 URL 的探测，是一次任务范围失败，也是更严重的发现。
• 存在一条获授权的通路吗？批量 API、付费数据馈送、数据转储、一个限了速的合作方密钥。如果有一条、而智能体没走它，那么修法是一张客户端侧的路由表——因为对一份没有被写进代码的合约，循环里没有任何东西能知道。

以一种能把案子结掉的方式回信。

申诉方升级的力度，与他们感觉自己被忽视的程度成正比，所以回信是一道控制、不是一份客套。四件事，不要更多：几小时内带着一个案件编号确认收到；一旦查清就明确地确认或否认归因；说明你已经停掉了什么、什么时候停的；以及说明改了什么、使它不会再发生。

• 不要发出一个你支撑不住的结论。当你的索引很薄时，「我们没有证据表明这份流量源自我们」是站得住的；而「这不是我们」是那种在申诉方手里握着一个你忘了自己会发的请求头时、会收场得很难看的句子。
• 把「已修」和「在考虑」分开。今天上线的一份按来源预算，对申诉方的价值高于一个路线图条目，而它也正是那个能挡住第二份申诉的东西。
• 留下案件记录。申诉、证据、时间线、决定，以及随之而来的那次改动——放在跟你的审计轨迹同一个地方。一串申诉构成的模式，是关于你这套部署的一条事实，而监管方或客户的第二个问题会是关于那个模式、不是关于这个案子。
• 顺手检查一下监管这条分支。多数滥用申诉不是须申报的事件。有一些——对第三方系统的未授权访问、把本不该取的个人数据取走了——会跨入重大事故申报或违规通知义务，而那个时钟不由你控制。请把这个判断显式地做出来，而不是靠漏掉它来做。

把这份申诉当作你没造出来的那个外部探测器。

一个第三方发现了一个你的遥测评为成功的行为。这就是那个发现，与这桩具体投诉无关，而它该改变两件事、不是一件。

• 把探测器加上。申诉方用的那个信号——来自某一个来源的错误率、请求量、编辑频率，或一条不寻常的路径——都能从你自己的出站日志里算出来。每一份申诉都该留下一条「本可以先响」的告警。
• 让修法是结构性的，而不是行为性的。一条让智能体「礼貌一点」的提示词不是控制；一份由客户端持有、智能体无权上调的按来源请求预算才是。标识、路由选择与退避同理：这些是一个库的性质，不是一个模型意图的性质。
• 把它回灌成一条回归测试。把这个模式加进你的失败分类，并把一个用例加进评测集，这样下一次换模型或改外壳就不能悄悄把它带回来。