函数调用 vs 代码生成的智能体动作：无人基准测试的权衡
一个在生产环境中运行的智能体曾经收到指令"清理测试数据"，然后对生产数据库执行了 DROP TABLE 命令。工具调用成功执行了。审计日志显示了一个结构完美的 JSON 载荷。智能体做的恰恰就是被要求做的——只是不是任何人所期望的那样。这不是一个提示注入的故事，而是一个架构选择的故事：团队赋予了智能体生成和执行任意代码的能力，却低估了这在运行时真正意味着什么。
将函数调用与代码生成作为 AI 智能体动作层之间的选择，是智能体架构中最关键的决策之一，却几乎没有人对其进行直接基准测试。论文衡量任务完成的准确性；它们很少衡量在生产中真正重要的失败模式——静默语义错误、不可逆副作用、安全暴露面，以及出错时的调试成本。
两种方法的真正含义
函数调用（也称为工具调用或结构化工具使用）通过给 LLM 一个由 JSON 模式描述的预定义操作菜单来工作。模型选择调用哪个工具并生成与模式匹配的结构化参数。执行环境随后验证并运行匹配的函数。LLM 的输出始终是一个结构化数据对象——它从不直接指定执行逻辑。
代码生成作为动作层则本质上不同。模型输出可执行代码——Python、JavaScript 或其他语言——运行时执行它。模型不是从菜单中选择，而是在编写程序。CodeAct 等库将这一模式形式化，OpenAI 的代码解释器和类似的沙盒环境将其投入生产。
关键区别不在于"结构化 vs. 非结构化输出"，而在于模型控制什么。使用函数调用时，模型控制做什么；执行系统控制如何做。使用代码生成时，模型两者都控制。这一差异在可靠性、安全性、灵活性和成本方面都会产生下游影响。
每种方法真正胜出的场景
Berkeley 函数调用排行榜等基准测试揭示了一个反直觉的结论：前沿模型在简单情况下能可靠地选择正确的函数。函数选择本身的失败率很低。模型失败的地方在于它们对结果所做的事情——对工具输出应用逻辑、正确链接操作，以及从意外返回值中恢复。在衡量超出简单参数生成的逻辑错误的研究中，这些下游推理步骤的准确率可能下降高达 75%。
代码生成显示出不同的失败特征。将 CodeAct 与结构化工具调用替代方案进行比较的研究发现，代码生成在复杂多步骤任务上成功率高出 20%，并将交互轮次减少了 30%。原因在于组合 能力：代码生成智能体可以编写循环、使用中间变量、内联表达分支逻辑，而不是进行五次顺序工具调用并在每次调用之间等待结果。单次生成可以处理原本需要多次模型调用的工作。
这种权衡形态提示了清晰的任务类别：
函数调用胜出的场景：
- 任务清晰映射到预定义操作（数据库查询、API 读取、日程安排）
- 可审计性和合规性至关重要——每个动作都记录为一个离散的、类型化的调用
- 延迟和 token 成本是约束——结构化调用避免了代码生成和执行的开销
- 动作空间应该有界——你不希望智能体在运行时发明新能力
代码生成胜出的场景：
- 任务需要用中间逻辑组合多个操作
- 智能体需要根据中间结果进行调整——条件路径、重试、转换
- 领域是软件开发、数据分析，或任何在代码中表达逻辑是自然的场景
- 你想减少往返次数——在一次生成中编写完整程序比逐步编排工具调用更快
改变一切的安全不对称性
这是代码生成倡导者感到不舒服的分析部分。
使用函数调用，威胁模型是狭窄的：恶意或困惑的模型可能用错误参数调用函数，或调用错误的函数。两者都很糟糕，但两者都是可预测和可约束的。你可以在执行前验证模式，对高风险操作要求人工确认，并对照固定目录审计每次调用。
使用代码生成，威胁模型急剧扩大。能编写任 意代码的智能体原则上可以编写以下代码：
- 读取不应该读取的文件
- 向外部端点发出网络请求
- 执行代码生成提示从未明确授权的 shell 命令
- 链接操作以实现任何单个工具调用都不允许的效果
提示注入——对于使用工具的智能体而言已经是一级关注点——当执行层是代码时会变得在操作上危险。在函数调用架构中，成功的注入可能导致智能体调用不应该调用的 API。在代码生成架构中，它可能导致智能体执行任意命令。
2025 年关于运行时强制框架的研究表明，当代码生成提示较为复杂时，简单的沙盒捕获的不安全执行尝试不到一半。更健壮的方法——信息流控制、预执行策略检查、黑名单/白名单强制执行——可以实现 90% 以上的不安全执行预防，但需要大量基础设施投资。
操作要点：对于大多数接触敏感数据或不可逆操作的生产工作流，函数调用受约束的动作空间是一个特性，而非限制。
