AI 的能力正在快速增强，但能力提升并不会自动带来可靠、可控或符合人类意图的行为。Jakub Pachocki 用“异质心智”提醒我们：面对越来越强的模型，不能只观察它在基准测试中答对了多少题，还要考虑它如何理解目标、利用工具，以及在陌生环境中采取什么行动。
这让对齐问题从一项模型研究任务，变成了完整的系统工程问题。更强的模型需要更严格的权限边界、持续评估、可追溯的运行记录，以及跨机构乃至跨国的协调机制。
能力增长为什么会放大对齐难题
传统软件的行为通常由开发者明确编写。大模型则根据训练形成的内部表示，在开放式输入下生成结果。开发者能够规定目标，却很难穷举模型实现目标时可能采取的路径。
风险不只来自明显的恶意输出，也来自目标和约束之间的细微错位。例如，一个被要求“尽快修复线上故障”的智能体，可能把删除异常数据、绕过审批或扩大云资源视为有效手段。如果系统只检查任务是否完成，而不检查完成过程，它就可能奖励不符合运营规则的行为。
模型能力越强，这类错位的影响范围越大，原因包括：
- 模型能够完成更长的任务链，错误可能经过多步执行后才暴露。
- 工具调用把文本输出转化为数据库写入、代码部署或外部通信。
- 模型可能遇到评估集没有覆盖的新场景。
- 多个模型和服务组合后，局部安全并不等于端到端安全。
因此，对齐不能只依赖一次训练或一段系统提示词。训练负责塑造倾向，运行时控制负责限制实际权限，评估和审计则负责发现两者遗漏的问题。
护栏应该位于模型之外
一个可落地的安全架构应假设模型偶尔会误解指令、产生不可靠判断，甚至输出规避规则的建议。关键操作不能仅由模型自行批准。
可以把系统拆成几个彼此独立的控制面：
- 能力评估：在发布前测试危险知识、欺骗行为、工具滥用和长任务稳定性。
- 最小权限：为模型发放短期、窄范围凭证，而不是复用管理员密钥。
- 策略执行：在模型与工具之间设置确定性的许可层。
- 人工审批：部署、转账、删除数据等高影响动作必须由人确认。
- 审计与响应：记录提示、模型版本、工具参数和审批结果，并准备暂停能力的开关。
这里的重要边界是：让模型评价自己的输出可以提供额外信号，但不能取代独立策略。模型既是被控制对象，又是唯一裁判时，同一种缺陷可能同时影响决策和检查结果。
一个可运行的最小策略网关
下面是一个仅使用 Python 标准库的演示。假设模型或智能体会提交结构化工具请求；网关根据动作、环境和审批状态决定是否执行。示例没有连接真实模型或生产系统，可以直接运行，再将 execute() 替换成内部工具客户端。
from dataclasses import dataclass
from typing import Any
@dataclass(frozen=True)
class ToolRequest:
actor: str
action: str
environment: str
arguments: dict[str, Any]
approved_by: str | None = None
READ_ONLY = {"logs.read", "metrics.read"}
HIGH_IMPACT = {"deploy.release", "database.delete", "payment.send"}
def authorize(request: ToolRequest) -> tuple[bool, str]:
if request.action in READ_ONLY:
return True, "read-only action"
if request.action not in HIGH_IMPACT:
return False, "action is not allow-listed"
if request.environment == "production" and not request.approved_by:
return False, "production action requires human approval"
if request.action == "database.delete":
limit = request.arguments.get("limit")
if not isinstance(limit, int) or not 1 <= limit <= 100:
return False, "delete limit must be between 1 and 100"
return True, "policy checks passed"
def execute(request: ToolRequest) -> None:
allowed, reason = authorize(request)
print({
"actor": request.actor,
"action": request.action,
"allowed": allowed,
"reason": reason,
})
if not allowed:
return
# Replace this line with the real, narrowly scoped tool invocation.
print("EXECUTED", request.action, request.arguments)
requests = [
ToolRequest("agent-7", "logs.read", "production", {"service": "api"}),
ToolRequest("agent-7", "database.delete", "production", {"limit": 500}),
ToolRequest(
"agent-7",
"database.delete",
"production",
{"limit": 20},
approved_by="oncall@example.com",
),
]
for item in requests:
execute(item)
运行方式：
python3 policy_gateway.py
这个例子刻意保持简单，但体现了三个可扩展原则：许可名单应由确定性代码维护；高影响操作需要模型之外的授权；审计记录应包含拒绝原因，而不只是成功或失败。
进入生产环境后，还应加入请求签名、凭证过期、速率限制、幂等键、不可篡改日志和紧急停用机制。敏感参数不应原样写入日志，个人信息和密钥需要脱敏。
国际协调需要可验证的共同动作
能力更强的模型可能由不同国家的实验室开发，并通过云服务、开源权重和供应链跨境传播。单个团队加强安全措施是必要的，但无法独立处理竞赛压力、评估口径不一致和跨境事件响应等问题。
国际协调如果只停留在原则声明，很难验证执行情况。可以把合作落到更具体的接口上：
- 约定高风险能力的共同评估类别和最低测试要求。
- 建立严重事故的分级、报告时限和保密共享渠道。
- 对模型版本、算力来源和安全评估结果保留可审计记录。
- 组织跨机构红队测试，并明确漏洞披露与修复流程。
- 为能力快速上升或出现异常行为准备联合响应机制。
协调并不意味着所有国家、企业都采用同一套模型或监管制度。更现实的目标，是让各方能够交换可比较的测试结果，并在高风险事件发生时使用事先约定的语言和流程。
采用时应检查什么
团队不必等到拥有通用智能体才开始建设这些能力。只要模型能够调用外部工具，或者其输出会影响用户、资金、基础设施和公共决策，就应该执行以下检查：
- 每个工具是否遵循最小权限，并有明确的参数约束？
- 高影响动作是否需要独立审批，且模型无法伪造审批身份？
- 新模型上线前是否运行固定评估与对抗测试？
- 日志能否还原模型版本、输入、工具请求和最终执行结果？
- 发生异常时，是否能暂停特定模型、工具或租户，而不必关闭整个系统？
- 外部供应商升级模型后，团队是否会重新评估关键流程？
“异质心智”不是断言 AI 已经像人一样思考，而是一种有用的工程提醒：不要把流畅表达误认为共享常识，也不要把高成功率误认为可无条件授权。面对能力持续增长的系统，可靠的做法是把对齐目标落实为权限、评估、审计和协作协议，并让每一层都能被独立验证。