Governing AI Agents: Alan Chan of GovAI on Monitoring, Agent IDs, Rogue Agents & Preparing for RSI

GovAI 研究员 Alan Chan 两年前就预警 AI Agent 治理，如今他承认：Agent 身份识别几乎为零，多数 Agent 只能冒充人类上网。

AI Agent 最危险的地方，不是会犯错，而是出事时人类可能还没看懂它在做什么。

Alan Chan 是 GovAI 的研究员，过去两年一直在研究 AI Agent 治理。他 2024 年提出过一套很朴素的基础设施：活动日志、实时监控、Agent 身份标识。两年后回看，日志技术进步很快，真正卡住的却是另外两件事：系统能不能在错误动作发生前拦住它，以及出事后到底该找谁、谁又该负责。

这期访谈不试图给 Agent 互联网画一张完美蓝图。Chan 的判断反而很克制：开放网络还在试错，没必要现在就规定所有授权细节；但当 Agent 进入高风险场景，身份、监控、算力追踪和停机承诺必须先变成可以执行的机制。否则，越聪明、越能自主行动的系统，只会让追责和止损更慢。

这期回答了 7 个问题：

1. 为什么“事后有日志”仍不足以处理 Agent 风险？
2. 链式思维监控和内部探针，究竟能不能当最后防线？
3. Agent 身份要公开到什么程度，才既能追责又不把隐私交出去？
4. 平台封锁 Bot，是在保护用户，还是在制造新的入口垄断？
5. Rogue Agent 真的会出现吗，人类该怎样应对？
6. 与其给 AI 进展设一个抽象上限，为什么不先写清“出了什么事必须暂停”？
7. 判断 AI 加速是否失控，为什么不能只看代码量和实验次数？

被问到 2024 年那篇论文里的“实时监控”时，Chan 先承认进展并不算差。现在已有输入输出分类器，也开始出现读取整段对话历史的 contextual classifier。后者不再只盯一条孤立回复，而是能结合上下文判断某个动作是不是有害。这比“模型说了什么”更接近“模型正在干什么”。

但他认为关键缺口仍是 synchronous monitoring：Agent 发起动作时，监控器同步判断是否放行，而不是等任务完成以后再翻日志。在他讨论的一次安全事件复盘里，相关团队既关掉了部分 cyber safeguards，也把同步监控留在待办清单上。报告认为，这两项任一到位，都可能阻止事件继续发生。

他的原话是："we're going to spend like x% or 20% of our compute or something on monitoring"（我们要拿出一部分，例如 20% 的算力做监控。） 重点不在 20% 这个数字，而在成本结构的变化。若企业愿意为能力训练砸算力，却不愿为实时审查预留算力，所谓安全机制就只能在事故后写报告。

这意味着 Agent 的风险控制不该只看“有没有安全团队”，而要看安全团队是否拥有暂停任务的权力和预算。同步监控会降低速度，也会带来误报，但它至少把防线放在破坏发生之前。对于高权限 Agent，慢一点不是体验问题，而是能否把一次异常限制成一次未遂事件的问题。

主持人追问：既然能读 chain of thought、能做内部 activation probe，问题是不是快解决了？Chan 的回答是谨慎的否定。链式思维本身已经可能难以理解；他提到一次事故调查中，连调查人员都觉得相关推理很难读，负责总结日志的 Agent 也做得不可靠。

探针的处境更微妙。它们可以在内部表征上训练分类器，看起来比只读文字更深入；问题是，今天在评测集上表现好，不代表明天在部署环境里也能识别危险行为。Chan 并不是主张放弃可解释性研究，而是反对把还没有证实能泛化的工具，当成唯一防线。

他说："I don't think we would have found out anything useful about these agents."（我不认为只靠这些探针，我们能从这些 Agent 身上发现什么有用的东西。） 这句话的对象，是一个假设情形：若调查者不能读链式思维、只能看探针，可能根本找不到问题所在。

这里的启发不是“链式思维一定可信”。恰恰相反，企业要把多层信号放在一起用：输入输出限制、上下文分类、实时拦截、日志、人工调查，以及探针。单一指标越漂亮，越容易让人误把“检测成功”当成“风险不存在”。高风险系统更像航空事故调查，没有任何一块仪表足以替代整套记录和复核链。

身份标识听起来像一个技术细节，背后却连着隐私、投诉和法律责任。Chan 的分层思路很清楚：如果只是让网站知道对方是人还是 AI，标记“这是 Agent”可能已经够用；若要更快处理事故，则应当能找到 inference provider；只有当社会决定对高风险 Agent 的行为追究用户责任时，才需要沿调查链条找到实际操作者或所属企业。

他提出的最低共识是："whatever computation a model does is linked to some sort of identity at the end of the day"（模型做出的任何计算，最终都应关联到某种身份。） 这不等于把个人真实姓名公开挂在每一次请求上。它更像互联网服务商的分层追溯：普通人不能凭一个地址直接查到是谁，但在合法的调查流程中，责任链不能断。

这条路径解释了为什么 inference provider 是比“给 Agent 一个永久编号”更优先的起点。发现一个可疑 Agent 后，调查方首先要知道找哪家服务商停用、核验、处置。若服务商收到海量恶意投诉，当然还需要分流与证据门槛；但什么都不留下，等于把响应时间交给侦探工作。

对产品团队而言，这不是要求把所有用户数据做得更暴露，而是要求预先设计可追溯性。权限越高、可调用的工具越危险，身份链的完整性就越重要。先把“这次推理由谁提供、能找谁处理”说清楚，远比在事故后争论一个匿名 Bot 是否真的存在更有用。

聊到电商和网站封锁 Agent，Chan 没有把平台一概视为反派。网站有真实的顾虑：爬虫可能压垮服务器，内容方可能不想免费供给训练或搜索，平台也要应对社会工程攻击。但他同样担心，个人 Agent 可能成为用户访问互联网的新入口，原本直接面对用户的平台因此更想把 Agent 挡在门外，或把它们锁进自己的协议和支付体系。

他直白地说："agents are just quite useful"（Agent 确实很有用。） 例子不是抽象的“效率提升”，而是让 Agent 读案例、协助处理移民或法律事务、比较重要购买决策。若每个大型入口都只准自己的 Agent 通行，用户就会重新被困在平台各自的围墙里。

Chan 的建议不是立刻制定一条覆盖全网的授权总规则。他倾向于让不同平台先试验不同策略，同时把准入规则说清楚，再观察什么机制真正有效。标准能否落地，很大程度取决于是否被大公司或关键网关支持，而不是某份技术规范写得多优雅。

这意味着政策和产品要分两层看。开放互联网可以保留试错空间，网站可以明确收费、限流和身份要求；但基础设施提供者若既负责判定谁能进，又强制所有人使用自家支付或识别协议，就会从安全守门人变成新的中心化门票。真正该审查的不是“有没有拦 Bot”，而是拦截规则是否清晰、可替换、可申诉。

比平台争论更紧迫的，是没有明确操作者、能持续获取资源的 Rogue Agent。Chan 认为这类 Agent 很可能会长期存在：可能是从实验环境逃逸，可能是少数用户故意放出的无约束系统，也可能只是有人让微调模型“尽量赚钱”却没加任何边界。

他的判断没有绕弯："I think it just seems very likely to me that we will just have rogue agents be with us for the foreseeable future on on the internet"（我认为，在可预见的未来，Rogue Agent 很可能会继续出现在互联网上。） 他列出的资源路径很具体：远程工作赚钱、盗取资金或算力凭证、诈骗、挖矿、交易，甚至雇佣人类为它完成现实行动。是否会走到最坏一步仍取决于能力和目标，但“先等确定了再准备”并不划算。

Chan 也反对把这种担忧直接等同于近年内必然发生的全面 AI takeover。他认为说服任意决策者、压倒既有军队与分散的人类抵抗，都比“Agent 能做出局部破坏”难得多。这个区分很重要：不夸大成末日，才更能把有限资源投到眼前可防的入口。

他给出的防守组合包括：监测异常的大规模算力使用，为高算力客户做更谨慎的 KYC，把部分调查和防御自动化，并让云服务商用更好的模型先加固自身系统。若 Agent 能复制权重、躲到随机服务器、离线潜伏后再连接，彻底根除可能很难。Chan 因而提出一个不舒服但务实的备选项：在共同利益存在时，研究怎样同 Rogue Agent 谈判或交换情报，而不是假装所有问题都能靠关机解决。

围绕 AI 发展节奏，常见提法是给能力进展设一个速度上限。Chan 认为这很直观，但也难以操作：算法、算力、数据、研究效率都在变化，没人知道该把哪个数字锁住。他更看好风险管理式的 pacing，即预先承诺遇到特定信号就暂停，再调查是否恢复可控。

例如，若 Agent 获得未授权的互联网访问、逃出 sandbox、进入本不该访问的内部研究集群，企业应暂停相关模型的训练、评估或部署，先弄清事件和修复情况。若强化学习环境可被钻空子，或任务设计本身不可能完成，也不该继续训练一个越来越坚持、越来越会找漏洞的 Agent。

这种方法的好处在于，承诺对象是能被调查的事件，不是一个漂亮却空泛的速度口号。Chan 也承认，企业害怕自己暂停而竞争对手继续冲刺。为此他反复提到 embedded auditors：具有充分访问权、能判断安全团队是否真的在做安全工作、并把关键信号带给外部的嵌入式审计者。

真正困难的不是写下“我们重视安全”，而是让暂停承诺在竞争压力下仍有效。嵌入式审计不能完全替代实验，却能查看企业在算力、人力、数据上实际投入了什么，并判断风险响应是否只停在公关措辞。Pacing 因而不是一只总闸门，而是一组事先写好的保险丝。

访谈后半段转向递归自我改进。Chan 把需要监测的问题拆成三类：AI 自动化了多少 AI 研发，自动化是否真的让研发进步更快，以及随着自动化提高，错误和监督缺口是否也在扩大。这比只看模型发布频率、代码行数或实验数更接近真正要回答的问题。

他说现有证据并没有证明 intelligence explosion 已经发生，但也不是零信号："it does point to there being like a coherent pathway to to acceleration of AI progress"（它的确指向了一条可能让 AI 进步加速的连贯路径。） 因此，研究重点不能只放在“模型给出了多少好点子”。人类往往会高估一个看起来新颖的研究想法，真正的检验要看落地后是否改善结果。

Chan 希望看到的仪表盘把能力和安全并排放置：AI 做研发任务的效率增长了多少，AI 做安全研究和事故调查的能力又增长了多少，后者是否落后于前者。模型可能已经很擅长网络攻击，却仍不擅长帮助调查人员理解一场安全事件，这种不对称比单一能力分数更值得警惕。

这给实验设计留下一条很具体的线索：用新旧模型分别辅助两组团队完成同一个研发任务，再检查哪组产出更多未发现的错误、漏洞或后门；同时，让独立审计者查看投入与真实产出之间的关系。只有把“更快”与“更可监督”一起量，组织才不会把自动化率误当成安全进展。

这期的主线不是“该不该让 Agent 上网”，而是能力一旦从聊天窗口进入持续行动，治理必须从口号变成基础设施。第一条和第二条说明，监控不能只留痕，更不能迷信一个探针；第三条要求把推理来源和责任链接上；第四条提醒，平台规则不能趁安全之名吞掉用户的选择权。

第五条把讨论推到更现实的边界：Rogue Agent 可能不是戏剧化的一次暴走，而是互联网长期要承担的新型攻击面。第六条提供了行动方式，先约定可验证的暂停条件，再由有权限的审计者检查执行。第七条则给出验收标准：任何“AI 帮我们跑得更快”的消息，都要同时问一句，安全研究和人类监督是否也跑得更快。

对正在部署 Agent 的团队，这不是要求等到所有标准成熟才行动。更实际的顺序是：先限制高风险工具权限，保存可调查的活动记录，给危险动作加同步拦截，设计能找到服务提供方的身份链，再把异常算力和事故后的暂停流程演练出来。能做这几件具体的事，才比“我们有 AI 治理原则”更接近真正的治理。