契约式 AI 治理中没人谈论的问题：开发者随时可以修改契约，而没有任何东西能察觉到这一点。

# 为 AI 智能体搭建运行时治理层：两个反复出现的问题 过去几个月一直在为 AI 智能体构建一个运行时治理层。有两个问题反复浮现，而我在整个生态中都没有看到有人正面解决。 ## 问题 1 - 契约可篡改 你写了一份契约，内容是 `approval_points: [before: github.merge]`。智能体在这个契约下运行了一周。某位开发者修改了这个文件，删除了审批点。现在智能体不经任何人批准就直接合并了。审计日志指向一个已经不存在的契约版本。而没有任何东西能捕捉到这个变化。 这不叫治理。这叫一张贴着"治理"标签的文档。 **我们做的：加密封印。** 每份契约在加载时就会立即计算哈希。如果文件在智能体启动之后被修改，`ContractTamperError` 会触发，智能体随之停止运行。配合一个带版本号的追加式注册表——编辑契约会创建一个新版本，而旧版本永久可查。你随时可以回答："昨天下午三点时，是哪份契约在治理这个智能体？" ## 问题 2 - 无契约智能体 一个动态派生的子智能体没有 `contract.yaml`。一个你正在封装的第三方智能体没有。由你的框架在运行时生成的智能体当然也没有。如果治理要求为每个智能体手写一份文件，那它就无法治理一个真实的多智能体系统。 **我们做的：运行时编程式声明。** ```python enforcer = ContractEnforcer.from_declaration({ "node_id": "dynamic-researcher-v1", "permissions": ["qdrant.search", "web.read"], "side_effects": [], "approval_points": [], "lifecycle": "ephemeral", }) ``` 同样的执行力度。同样的审计日志。同样的篡改检测。无需任何文件。 **没有文件、也没有声明的任何东西，默认为只读模式，且每次操作都需要显式批准。** ## 第三件事：没有人解决的问题 门控本身是可选的。一个智能体可以干脆不去调用它。 解决方案是一个网关层——所有凭据都只存在于被网关保护的类内部。如果只有网关持有它，就没有令牌可以被窃取。一条 CI lint 检查会在任何网关之外的文件导入原始客户端时直接让构建失败。 **针对同一种失败模式，设置了三道独立的防线。** --- 我很好奇：其他在生产环境中构建多智能体系统的人，是否也遇到过这些问题？以及你们在契约版本化和治理动态派生智能体方面采用了什么方案？