Rich Hickey：AI不是工具，而是另一种东西

一场被低估的哲学辩论

Clojure 之父 Rich Hickey 最近在一篇被整理成 Gist 的演讲稿中提出一个尖锐判断：「AI」不是工具。这篇内容在 Hacker News 上拿下了 281 分和 148 条评论，说明它戳中了不少工程师心里的某种不适感——只是大家一时说不清那是什么。

说「AI 不是工具」听起来像文字游戏。但 Hickey 的论点不是修辞层面的，而是关于我们如何归类一个东西，以及这种归类如何反过来决定我们会怎么用它、怎么信任它、怎么为它负责。

工具的本质：可预测、可掌握、可归责

要理解 Hickey 的判断，得先看他眼里的「工具」意味着什么。

工具是有确定行为的物件。锤子敲下去会留下凹痕，编译器会把源码变成目标代码，数据库会按事务语义读写数据。工具的关键属性包括：行为可预测、边界可描述、使用者可以完全掌握其运作方式、出问题时责任在操作者。

这是一套很朴素但很有力的标准。它解释了为什么我们敢把锤子交给学徒，敢让生产环境跑一个经过测试的排序库——因为这些东西的行为是可穷尽描述的，它们不会「自己决定」点什么。

Hickey 的逻辑往下走：如果一个东西的行为无法被完整指定、无法被可靠预测、并且其输出不由使用者的意图单独决定，那么把它叫「工具」就是在美化它。

为什么大模型不满足「工具」的资格

把大语言模型放进这个框架里对照，问题就清楚了。

传统软件的规格说明是：给定输入 X，输出 Y。模型的规格说明更像：给定输入 X，在某个概率分布下采样出某个看起来合理的输出。它不是「不确定的工具」，而是本质上不承诺确定性的系统。

Hickey 的深层担忧不在于「结果可能错」，而在于归责链条断裂。用锤子砸到手，是自己的问题。用模型生成的代码上线导致事故，责任在谁？模型没有意图，厂商说「输出仅供参考」，使用者说自己只是「按模型建议操作」。每一环都能把责任推给下一环，最终没有人真正为那个输出负责。

这正是工具与「非工具」的分水岭：工具让责任清晰，非工具让责任蒸发。

大语言模型的核心机制是自回归采样：在每一步根据上下文计算词表上的概率分布，再从中抽取一个 token。即使温度设为 0 做贪心解码，输出也会因为模型权重、训练数据分布和提示形式而带有不可约的随机性与敏感性，同一提示在不同版本、不同上下文中可能产生语义迥异的回答。这与传统软件中「规格即行为」的范式根本不同：SQL 查询在给定数据下结果确定，编译器对合法源码的输出可复现，而模型没有任何可证明的行为承诺。更关键的是，模型的内部状态由数千亿参数承载，其决策路径无法被逐条审计，这使「可穷尽描述其行为」这一工具前提彻底失效。

它更像什么？Hickey 的替代框架

如果 AI 不是工具，那它是什么？

Hickey 倾向于把它类比为有能力的合作者或代理人——一个行为受自身内部状态驱动、其输出需要被审视而非被信任的对象。这个类比的实践后果很不一样：

• 对工具，我们要求正确性；对合作者，我们要求可靠性、判断力和可协商性。
• 对工具，我们做单元测试；对合作者，我们做评审、抽查和边界约束。
• 对工具，出问题就修 bug；对合作者，出问题要调整协作方式和信任边界。

Hickey 还强调一个不对称性：工具的正确性可以证明，合作者的可靠性只能在长期互动中累积经验。这意味着围绕 AI 的工程实践，需要从「验证规格」转向「建立信任」。

在 AI 领域，「代理（agent）」通常指能感知环境、自主选择行动序列以达成目标的系统，与只能响应单一指令的「工具」形成对照。代理性阶梯从低到高大致是：被动响应、按规则触发、在目标空间内规划、再到具备自身偏好并主动改变环境。把大模型放进这个阶梯并不整齐——单个模型本身没有持久目标，但一旦被接入工具调用、记忆与循环决策框架，就呈现出明显的代理特征。这也解释了为什么围绕 AI 的安全讨论会从「对齐输出」扩展到「对齐目标」：对工具只需保证它按指令执行，对代理则需要持续确认它所追求的目标是否仍与人类意图一致。

工程实践里的连锁反应

这套框架不是哲学空谈，它在工程决策上有直接推论。

权限设计。 如果 AI 是工具，给它读写生产数据库的权限只是配置问题；如果它是合作者，那它需要的是一套与人类成员同等的权限分级、审计日志和最小授权原则。

测试策略。 工具可以靠确定性测试保证质量。合作者的输出是分布式的，测试重心要从「验证每个输出」转向「统计性评估 + 人工审查关键路径」。这也是为什么「AI 生成代码的测试覆盖率」这个指标本身就很可疑——它测的是工具的问题，而面对的可能是非工具的对象。

架构隔离。 把 AI 组件当成不可信的外部依赖来对待，而不是当成一个库函数。这意味着接口边界、失败降级、超时和输出校验都需要显式设计。

人的位置。 当 AI 不再是工具，「人机协作」这个词的权重就变了。人不再是「用工具的人」，而是「和一个不完全可预测的对象共同完成任务的人」。这要求人保留判断环节，而不是把判断也外包出去。

最小授权原则（principle of least privilege）是安全工程中的基础范式：任何主体只应拥有完成其当前任务所必需的最小权限，且权限应能随上下文动态收缩。当把 AI 组件当作不可信外部依赖时，这一原则的运用会明显不同于普通库——外部依赖通常有明确版本、可静态分析调用面，而模型的行为随输入漂移，因此需要通过沙箱、能力令牌、作用域限定和出口审计来收窄其可触达面。与之配套的还有失败降级设计：把模型的输出视为可能为空、可能超时、可能语义偏差的信号源，在架构上为一等公民预留校验、回滚和人工兜底路径，而不是在调用点假设它会返回「正确」结果。

分歧与争议

Hacker News 上的讨论并不一致。

一部分人认为这是术语洁癖：无论叫什么，工程上该做的审计、测试、权限管理一样要做，「不是工具」这个判断改变不了实际操作。

另一部分人认为 Hickey 点中了要害：正因为我们习惯性地把新东西叫「工具」，才导致了一系列低估风险的设计决策——把模型当成一个可以信赖的组件，而不是一个需要持续监督的对象。命名决定心智模型，心智模型决定架构选择。

值得注意的中间立场是：AI 可能不是单一类别，而是工具性与代理性的混合体。同一个模型用在代码补全上更接近工具，用在自主 Agent 上更接近代理者——归类应该随使用方式而变，而不是给模型本身贴一个固定标签。

「工具性与代理性混合体」这一立场在学界与工程界都有回响。一个实用的操作化方法是按调用模式而非模型类型来分类：单轮、低风险、可被确定性校验的调用（如代码补全、格式转换）更适合按工具对待；多轮、持久的自主行为、涉及不可逆操作（如自动合规审查、生产变更）则更适合按代理对待，并匹配相应监督强度。这意味着同一次技术选型中可能同时存在两种治理路径，团队需要按具体用例而非笼统的「我们用了 AI」来设定测试、权限与审查标准，从而避免因一刀切归类而放大风险敞口。

对开发者的实际启示

抛开命名之争，Hickey 的观点可以提炼成几条实用的判断标准：

问自己：这个 AI 组件的失败模式能不能被完整描述？ 如果不能，就别把它当工具用，别指望测试能覆盖它。

问自己：出问题时，谁负责？ 如果答案模糊，说明这个组件在你系统里的定位本身就不清晰。

问自己：我是在验证它，还是在信任它？ 工具靠验证，合作者靠信任加约束。选错模式，风险敞口会完全不同。

问自己：我保留了判断环节吗？ 如果人的判断已经被完全替代，那你拥有的既不是工具也不是合作者，而是一个无人监督的决策来源。

Hickey 的核心贡献不在于给出了一个标准答案，而在于提醒：把 AI 叫做「工具」是一种心智上的便利，而便利往往会掩盖代价。想清楚它到底是什么，比急着用它做出点什么更重要。