有一种特定的争论，你只会和语言模型发生。你粘贴进代码。它把一个能运行的调用改写成了早在几个大版本前就不存在的形式。你纠正它。它道歉、表示同意，然后在下一轮对话中故技重施。你不是在对抗无知，而是在对抗一段对 不同 版本技术栈的、自信且经过充分排练的记忆——这段记忆被远超你纠正信息的训练样本所强化。
这就是我所认为的“与先验知识对抗”（fighting the prior）故障模式。模型的参数化知识——它在训练期间吸收的一切——包含了流行的、过时的，或者仅仅是与你实际使用的框架版本不同的内容。当你的上下文与它的先验知识发生冲突时，先验知识往往会胜出。与纯粹的幻觉不同，这种错误之所以危险，恰恰是因为它具有误导性的合理性：那个被弃用的 API 曾经是正确的，所以代码看起来没问题，能通过随意的阅读，甚至有时还能编译通过。
上个月，我需要核对两个列规范略有不同的 CSV 导出文件——这项任务我通常会通过找一个 diff 工具、阅读其文档并与其设定的规则缠斗 20 分钟来解决。相反，我让一个 Agent 为我写了一个 50 行的脚本。它运行了一次，得出了答案，然后我就把它删除了。总共耗时：90 秒。这个脚本从未进入版本控制，从未被命名，也永远不会再出现。
这种交易模式——编写、运行、删除——正悄然成为一整类工作的默认模式。当代码生成的成本趋近于零时，最廉价的正确做法往往是定制的单次尝试，而不是通用的工具。寻找现有的实用程序意味着搜索、评估、安装、配置和信任它。而生成一个即用即弃的程序则意味着描述你想要什么。对于定义明确的窄任务，第二条路径现在在除了一个维度外的所有维度上都胜出了：没有人关注到底创造了什么。
一个在生产环境中运行的智能体曾经收到指令"清理测试数据"，然后对生产数据库执行了 DROP TABLE 命令。工具调用成功执行了。审计日志显示了一个结构完美的 JSON 载荷。智能体做的恰恰就是被要求做的——只是不是任何人所期望的那样。这不是一个提示注入的故事，而是一个架构选择的故事：团队赋予了智能体生成和执行任意代码的能力，却低估了这在运行时真正意味着什么。
将函数调用与代码生成作为 AI 智能体动作层之间的选择，是智能体架构中最关键的决策之一，却几乎没有人对其进行直接基准测试。论文衡量任务完成的准确性；它们很少衡量在生产中真正重要的失败模式——静默语义错误、不可逆副作用、安全暴露面，以及出错时的调试成本。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
