函数调用之所以正在取代提示工程、成为企业 AI 准确性的首要杠杆，是因为它修好了提示工程修不了的那个失效模式：一个被问到自己没有的事实的模型，会编出一个可信的事实。提示工程决定答案表达得多好；工具使用决定它是否为真。当组织从演示走向生产，这个区分就不再是学术性的——董事会材料里一个文采斐然的错误数字，代价高于一次简短的拒答；而最早明白这一点的团队，正是那些系统活过了规模化的团队。
这并不是说提示不再重要。它依然一如既往地重要，只是它不再是杠杆所在。杠杆转移到了工具、schema 与护栏的设计上——它们决定模型能够触达什么。本文解释原因、实践中的变化，以及你该怎么做。
什么是函数调用？
函数调用——也称工具使用——是这样一种机制：语言模型不直接作答，而是发出一个结构化请求，调用一个带类型参数的具名操作。应用程序执行它、返回结果，模型再把结果纳入自己的答案。
一个具体例子。用户问：「我们北区上季度的毛利率是多少，和计划相比如何？」一个仅靠提示的模型会产出一段文字；一个带工具的模型则会发出类似这样的请求：
get_metric(metric="gross_margin", region="north", period="2026Q1")get_plan_value(metric="gross_margin", region="north", period="2026Q1")
应用程序针对受治理的系统执行这两条调用、返回数字，模型再写出对比。差别不是文体上的：在第二种情况下，答案里的每个数字都来自一个记录系统，并且可以追溯回去。
让这套机制运转起来需要三个组件：一个工具注册表，描述每个函数、参数与语义；一份参数契约，通常是带类型、枚举与必填标记的 JSON schema；以及一条执行与返回路径，以调用者的权限执行该调用，并以模型可用的形态返回结果。
为什么提示会撞上天花板？
因为有四重限制是结构性的，不是靠更好的措辞能修好的。
不确定时的虚构。一个缺少某事实的模型照样会把模式补全。「只使用所提供的数据」这类指令能减少但不能消除这一点，因为模型仍是在按合理性而非按检索结果来生成 token。
算术与聚合。语言模型是在近似地做算术。让它在上下文里把三十个数字相加，等于接受一个任何财务部门都无法容忍的错误率。正确的架构是：让模型请求一次计算，由确定性系统来执行。
新鲜度。训练截止之后发生的一切，或者今天早上刚变的一切，都在模型知识之外。提示够不到它；工具调用可以。
约束坍塌。随着同时施加的规则增多，指令遵循能力会退化。团队的反应是把提示写得更长，这只有边际效果，还增加了延迟与成本。替代方案——把约束表达为运行时强制执行的带类型 schema——之所以有效，是因为执行是机械的，而不是统计性的。
简而言之：提示控制的是行为，而行为从来不是真正的约束。准确性、新鲜度与可审计性才是。
转向工具之后实际发生了什么变化？
五重转变，而第三重是组织最容易低估的。
1. 从指令转向接口。你不再用散文描述想要什么，而是定义一个带类型参数的操作。一个命名良好、描述精确的函数，比三段指令更可靠地教会模型，因为 schema 从机械层面约束了输出空间。
2. 从希望转向强制。约束从「请返回合法 JSON」变成运行时会校验并拒绝的 schema。一次带越界枚举值的工具调用，要么校验失败并带着错误重试，要么根本不执行。在说服是概率性的地方，执行是确定性的。
3. 工作量转移到数据层。一旦模型能调用工具，答案质量的上界就由底层系统的质量与可访问性决定。大多数组织在几周内就会发现这一点：模型没问题，问题在于数据没接上、没定义、或不是当前的。这正是让团队措手不及的转变，因为它在预算刚刚花完的那个时点，把一个 AI 问题变成了一个数据工程问题。
4. 从答案转向出处。一个以工具为落地依据的答案里，每个数字都能引用系统、查询与时间戳。这正是让输出在 CFO、监管方或法庭面前站得住脚的东西，而单靠提示永远得不到它。
5. 从单次调用转向循环。有了工具，模型就能规划：调用、观察、调整、重试。这正是智能体成为可能的原因，也正是"工具设计而非提示设计"决定了这个循环表现好坏的原因。
如何设计出模型会正确使用的工具？
工具设计如今是核心技能，而且它有具体的规则。
按业务意图命名操作，而不是按数据库对象命名。get_gross_margin 优于 query_fact_table。模型是靠用户问题与工具描述之间的语义匹配来选择工具的，因此描述本身就是接口。
在描述里写明"何时用"与"何时不用"。「用于按区域与期间查询实际毛利率。不要用于预测值或计划值——那请用 get_plan_value。」负向指引可以拦下最常见的选择错误。
激进地约束参数。对类别取值使用枚举，并显式声明类型、必填标记与取值范围。你编码进 schema 的每一条约束，都是模型不必去猜的一条，也是运行时可以校验的一条。
以模型能够推理的形态返回结果。包含单位、币种、期间标签与一个状态字段。一个只返回裸数字的工具，是在邀请模型自行补充上下文——错误正是从这里进入的。
让错误信息具有可操作性。当调用失败时，返回一个模型可以采取行动的结构化错误：「区域 north 无法识别；有效取值为 north、south、east、west。」这会把失败变成可恢复的一步，而不是死胡同。
把工具数量控制在可管理范围。几十个重叠的工具会降低选择准确率。请把相关操作分组，并按领域路由到相关子集，而不是一次把全部工具都摆出来。
工具需要哪些治理？
工具是可被执行的能力，这使它成为一个安全边界，而不是一项便利。五项控制不容妥协。
- 在执行处强制授权。工具以调用用户的权限运行，且在服务端解析。绝不要相信模型关于「谁在提问」的陈述。一个返回了他人数据行的工具，就是一场用自然语言交付的数据泄露。
- 对有副作用的动作使用白名单。读与写是不同风险等级。任何会创建、更新或发送的操作都应单独授权，高价值动作还应要求显式人工审批。
- 成本与迭代天花板。对每次请求的调用数、每个任务的循环次数、以及每次运行的支出设定硬上限。一个循环失控的智能体，可能在失败之前烧掉一大笔预算。
- 对每次调用做审计日志。谁、什么工具、什么参数、什么结果、什么时间。这既是事件响应的证据基础，也是合规的证据基础。
- 独立于模型做输入校验。在执行前，于工具边界按 schema 校验参数——正如你会校验任何不可信 API 输入那样，因为它本来就是。
提示工程还重要吗？
重要，而且这个分工是稳定的，不是过渡性的。
提示依然拥有「理解」：模型如何拆解问题、以什么顺序提问、如何处理歧义、如何呈现结果、使用什么语气，以及何时拒绝作答。这些都是行为属性，没有哪个 schema 能定义它们。
提示依然拥有「拒答行为」：「数据未覆盖此项」而不是临场发挥，这是一条提示层面的控制，而且它是你会写下的价值最高的指令之一。
提示依然拥有「错误恢复」：模型在一次工具调用失败后做什么——带着修正后的参数重试、换一个工具，还是升级给人工——是在系统指令里规定的，而它决定了这个循环能否优雅降级。
变化的是投入比例。在一个成熟系统里，大部分工程时间花在工具、schema、评估与数据层上；提示变成一个更小、更稳定的表面。我们那篇关于「什么是提示工程」的配套文章，涵盖了在这个更小的表面上仍然必不可少的技术。
迁移路径长什么样？
四个阶段，而大多数组织正处在中间某处。
第一阶段——提示式答案。模型凭自身知识作答，检索到的文档只是被粘贴进上下文。构建快，但对任何事实性或数字性的内容都不可靠。
第二阶段——把检索变成工具。模型调用一个搜索函数，而不是被动地接收上下文。这是第一项也是最大的一项准确率提升，而且几乎所有人都能立刻获得它。
第三阶段——结构化数据工具。模型针对受治理的度量与实体调用具名操作，由语义层定义可用范围。企业级的答案正是在这一阶段变得可审计，大部分持久价值也在这一阶段。
第四阶段——编排式智能体。带工具循环的多步规划、验证，以及对重大动作的人工审批。威力强大，但只有在第三阶段牢固之后才安全，因为一个建立在无治理工具之上的智能体，会放大其下方的每一个弱点。
不要跳到第四阶段。过早引入自主性的失效模式是：一个令人印象深刻、却无法被托付真实决策的演示，随之而来的是组织信心的流失，把整个项目拖后一年。
基于工具的系统有哪些失效模式？
选错工具，却给出自信答案。模型选择了一个看似合理但错误的操作。缓解手段是精确的描述加负向指引、更小的工具集，以及在真实问题分布上做评估。
工具对、参数错。操作正确，但期间或区域错了。缓解手段是枚举、校验，以及返回能让模型带着修正重试的可操作错误。
把静默的工具失败当成数据。调用实际失败，却被渲染成「无数据」。请始终返回显式的状态字段，并指示模型区分缺失与失败。
绕过治理。某个工具读取了调用者无权查看的内容。请在服务端、按每次调用强制授权，并用刻意过宽的问题来测试它。
循环失控。强制迭代与支出上限，并对高成本或高影响的动作设置审批阈值。
虚假精确。工具返回一个数字，模型却以超出数据支撑的自信呈现它。请指示模型报告新鲜度与覆盖范围，并在答案中展示它们。
工具蔓延。每个团队各自加工具而不协调，会产出语义不一致的重叠操作。请把注册表当作产品来治理——有负责人、有版本、有弃用机制。
组织应该如何起步？
从高管最常问的那五个问题出发，让每一个都能由一个受治理的工具来回答。这是一个小而有限的表面——通常涉及两到四个源系统和少数几个经过认证的度量。构建工具、接好授权，并度量端到端答案的准确率，而不是单次调用的准确率。
蜂启咨询（Beehive Strategy）正是围绕这一点构建的：MCP 连接器在既有系统之上暴露受治理的操作；语义层定义这些操作可以返回哪些经过认证的度量；行级安全在执行时按角色施加。用户在 Teams、Slack 或 WhatsApp 里用自然语言提问，平台把问题解析为针对实时数据的工具调用——SQL 与来源均可见以供审计。以托管服务方式约两周部署，这是从提示式猜测走向你能够捍卫的答案的最短路径。
常见问题
1AI 中的函数调用是什么？
函数调用——也称工具使用——是这样一种机制：语言模型不直接作答，而是发出一个结构化请求，调用一个带类型参数的具名操作；应用程序执行该调用、返回结果，模型再把结果纳入答案。它需要三个组件：描述各函数及其参数的工具注册表；通常以带类型与枚举的 JSON schema 表达的参数契约；以及以调用者权限执行调用、并以可用形态返回结果的执行路径。
2为什么函数调用正在取代提示工程？
因为提示决定答案表达得多好，而工具使用决定它是否为真。提示的四重限制是结构性的：缺少某事实的模型会编出可信的事实；语言模型只是近似地做算术，不应被信任去聚合数字；训练截止之后的一切都在其知识之外；以及随着约束增多，指令遵循能力会退化。工具调用同时回应了这四点：让事实来自检索、让计算由确定性系统执行、让数据保持当前、让约束被机械地强制执行。
3有了函数调用，提示工程还重要吗？
重要。这个分工是稳定的，而非过渡性的。提示拥有理解——问题如何拆解、歧义如何处理、结果如何呈现、使用什么语气、何时拒绝作答；它也拥有拒答行为与错误恢复，规定模型在一次调用失败后做什么。变化的是投入比例：在成熟系统中，大部分工程时间花在工具、schema、评估与数据层上，而提示变成一个更小、更稳定的表面。
4如何设计出模型会正确使用的工具？
按业务意图而非数据库对象命名操作，因为模型是靠问题与工具描述之间的语义匹配来选择工具的；在描述中写明何时用与何时不用，因为负向指引能拦下最常见的选择错误；用枚举、类型、必填标记与取值范围激进地约束参数；返回结果时带上单位、期间标签与状态字段；让错误信息具有可操作性，使失败可恢复；并把工具数量控制在可管理范围，按领域路由到相关子集。
5AI 工具需要哪些安全控制？
五项控制不容妥协：在执行处于服务端强制授权，使工具永不返回调用者无权查看的记录；对有副作用的动作单独使用白名单并要求人工审批；对每次请求的调用数、循环迭代次数与单次运行支出设定硬上限；对每次调用做审计日志，记录主体、工具、参数、结果与时间；以及在执行前于工具边界按 schema 校验参数，正如你会校验任何不可信的 API 输入。
6基于工具的 AI 系统主要有哪些失效模式？
反复出现的有：选择了看似合理但错误的工具，可用精确描述与更小的工具集缓解；工具对但参数错，可用枚举与可操作错误缓解；把静默的工具失败渲染成无数据，需始终返回显式状态字段来修正；治理被绕过，即工具读取超出调用者权限的内容；循环失控，需靠迭代与支出上限控制；虚假精确，需靠报告新鲜度与覆盖范围应对；以及工具蔓延，需要把注册表当作产品来治理。
7从提示工程迁移到函数调用的路径是什么？
四个阶段。第一阶段是凭模型知识的提示式答案，构建快但事实不可靠；第二阶段把检索变成工具，这是第一项也是最大的准确率提升；第三阶段暴露针对受治理度量的结构化数据工具，由语义层定义可用范围，答案在此阶段变得可审计，大部分持久价值也在此阶段；第四阶段加入带验证与人工审批的编排式智能体——威力强大，但只有在第三阶段牢固后才安全，而直接跳到它是最常见的战略错误。
