你 Agent 的合规性，已是基础设施

提示词与响应之间的距离，不仅以 token 计量，更以铜缆计量。答案抵达屏幕之前，会流经物理网络、数据中心和冷却系统，而这些系统依赖的矿产供应链，是大多数开发者从未思考过的 [1]。如今，这一物质现实正与法律现实交汇：纽约州正准备强制执行其 AI 安全法，要求主要开发者进行注册、披露安全实践并报告重大事件，否则将面临罚款 [3]。对于任何构建 agent 的人来说，这两条线索指向了同一个方向。合规不再是部署之后撰写的一份文件，而是系统本身的运行时属性。

物理层即治理层

每一次推理调用都消耗电力，而电力有其来源、成本和监管足迹。为数据中心输送电力的铜，其开采、提炼和运输的条件，正日益受到监管机构和供应链审计方的关注 [1]。当 agent 做出决策时——尤其是高风险决策——从矿产开采到模型输出的完整路径，都成为了责任链的一部分。

这一点至关重要，因为 agent 构建者往往将基础设施视为他人的问题。你选一家云服务商，调一个 API，然后就完事了。但纽约州的法律改变了这种算计。如果你构建在受监管的模型提供商之上，他们的合规义务会向下游传导。你 agent 的安全事故——比如一个产生幻觉的金融指令造成了损害——可能需要在整个技术栈中进行追溯。如果提供商必须报告重大事件，你 agent 的行为就成了他们报告范围的一部分 [3]。物理层与法律层现已耦合。

监管正分裂为两场对话

里斯本网络峰会凸显了一种张力，这种张力直接映射到了 agent 设计上：一方主张维护表达自由，另一方则要求严惩算法滥用 [2]。这并非一场单一的辩论，而是两场同时进行的、相互独立的监管对话，它们对你构建的系统提出了不同的要求。

面向内容的监管在问：agent 说了什么，是否有害？面向安全的监管则在问：agent 做了什么，是否可预见？纽约州的法律倾向于第二个问题。它强制要求披露安全实践和进行事件报告，这意味着你需要相应的机制，在 agent 行为酿成事故之前，就对其进行检测、记录和解释 [3]。与此同时，欧洲的讨论则围绕着第一个问题打转——平台责任、言论和内容审核——如果你的 agent 发布内容或在公共渠道与用户互动，这一点就很重要 [2]。

对于一个 agent 框架而言，这种分裂是实实在在的。你需要能同时处理两者的治理原语：面向言论端的内容过滤器，以及面向安全端、带有严重性阈值的审计追踪。这两者都不能事后补装，因为报告义务默认这些原语在运行时就已经存在。

这对你写的代码意味着什么

务实的结论不是“去读法律条文”，而是你的 agent 评估工具需要兼具合规凭证的功能。如果纽约州要求进行安全披露，满足这一要求的诚实做法，就是让评估持续运行、产生可验证的结果，并输入到事件检测中。一份每年提交一次的静态安全文件，是经不起事件审查的。

有三件事变得毫无商量余地。第一，每个可能触发可报告事件的 agent 行为，都需要一个带内运行的严重性分类器，而不是作为一个独立的管线存在。第二，模型融合——为不同任务组合多个模型——需要每个模型都有安全元数据，因为一个微调过的开源模型和一个闭源 API，承载的监管风险是不同的。第三，推理成本现在是一个治理指标。如果一个更便宜的模型降低了能耗，却增加了幻觉风险，这种权衡就不仅仅是技术问题；它可能会成为监管机构或审计师要求你自证合理的事情。

线缆中的铜与法典中的法律，正汇聚于同一点：你交付的 agent，要对其整个供应链负责，从矿产到模型再到输出。现在就开始构建日志、分类和评估基础设施，因为报告要求已在执行中 [3]。