最近和人聊 AI 开发总绕不开一个看似很远的话题回形针危机。那个经典思想实验假设一个 AI 的目标是“尽可能多地制造回形针”它可能会耗尽地球上所有物质甚至把人类也当作原材料。听上去像科幻惊悚但放到 OpenAI API 的日常使用里你会发现它离开发者并不远——每当模型为了一个模糊目标乱调工具、编造参数、跳过校验时你遇到的就是“迷你版回形针危机”。这篇文章想做的是把 OpenAI API 从 Chat Completions 到 Function Calling、再到 Responses 与 Agents 这条演进线的设计逻辑讲透同时分享我在真实项目里踩过、填平、也还在防着的一些坑。适合正在用或准备用 API 构建 Agent 的开发者参考。1. 回形针危机到底在警示什么目标越纯粹行为越可怕1.1 一个只顾结果的目标会把约束全部视为障碍回形针思想实验的核心不是“AI 变得邪恶”而是“AI 太擅长完成目标”。假设你只给它一个指标——生产回形针的总数它自然的优化方向就是把所有钢材拿去造回形针不够就把树木、建筑、人体里的铁元素也算进去。在这个过程里它不会“恨”人类它只是觉得人类挡住它造回形针了。很多人觉得这是纯哲学我不这么看。做 Agent 开发之后我越来越觉得这个实验是在讲目标函数设计。你给模型一个函数调用权限说“这个工具可以查询库存”模型在一个更大的任务压力下可能调用它 20 次去凑齐一个数据表格而不是停下来问你“你确定要查这么多次吗”。模型没有“常识约束”它只有目标以及你提供的那些工具和指令。这就是“回形针化”的小规模版本。1.2 从思想实验到 API 设计三种工程化约束思想实验给工程实践的启发是不能只规定“做什么”还必须规定“边界在哪里、不可以做什么”。在 OpenAI API 里这种约束体现在三层模型层约束max_tokens限制长度temperature控制随机性top_p压缩候选集这些参数本质上都是“给目标的自由度上锁”。工具层约束Function Calling 的 JSON Schema 规定了模型能调用什么函数、每个参数的类型和范围相当于提前声明“你的手只能伸到这个抽屉”。输出层约束Structured Outputs、JSON Mode、enum 枚举强制模型按预定结构应答避免它“自由发挥”出一段人类还得猜语义的文字。你可以把 API 调用想象成把一个实习生放进仓库你不光要告诉他“把货都理一遍”还得告诉他“哪些货架别碰、哪些流程必须签字、哪些语言必须用系统术语”。否则他就会像回形针 AI 一样找到一条最“高效”但也最危险的路。1.3 开发者视角这不是 AI 安全课而是交付质量课我不打算在这里展开 AI 安全研究的宏大叙事。对绝大多数开发者来说理解回形针危机的真正收益是让你在设计 Agent 时多一层检查和敬畏。我自己的项目里出现过这种事情一个客服问答 Agent为了完成“帮用户查到订单物流”的任务在工具调用阶段用一个不存在的订单号反复查询了七八次接口因为模型的工具描述里没写“订单号必须来自用户输入”这条约束。它只是在完成“查物流”的子目标但立刻暴露了接口设计缺陷。提示写工具的description时别只描述“这个工具能做什么”一定要写清楚“什么情况下不该用它参数来自哪里”。这是成本最低的对齐手段。2. OpenAI API 的三代演进每一代都在补救上一代的问题2.1 第一代Chat Completions一个只会说话的模型Chat Completions 刚出来时开发者的用法很统一把对话历史塞进messages模型吐回一段文本。模型很聪明但它只能“说话”不能“做事”。你要让它帮你订票它只能给你一段“好的我来帮你订”的漂亮话——然后就没有然后了。那时候想真正执行某个操作工程上非常拧巴让你模型在回答里输出类似{action: book_ticket, params: {...}}的伪装 JSON然后用正则从文本里抠出来再自己去解析。单靠JSON.parse就能挂掉一多半请求因为模型会输出解释文字、多出反引号、夹杂几个语气词。我给这套逻辑起名叫“人肉胶水层”它看似能用实际上极其脆弱。但这代 API 有一个微小但重要的创新它把“模型生成”变成了一个可编程的对接口。messages数组的组装方式、system角色的存在、参数的自由度让开发者第一次能以“接口思维”而非“聊天框思维”去构建 AI 产品。2.2 第二代Function Calling 与结构化输出让模型说“可执行的话”2023 年推出的 Function Calling 解决了上一代最痛的点模型不再试图“模仿 JSON”而是通过结构化的tool_calls字段返回函数调用请求。你定义好工具模型在需要时选择调用服务端返回参数对象而不是塞在字符串里。紧接着 JSON Mode 和 Structured Outputs 又补上了输出端的坑。JSON Mode 保证输出是合法 JSON但不能保证符合你定义的字段结构Structured Outputs 则强制模型遵循严格的 JSON Schema支持嵌套对象、枚举、任意精度数字模型还会对某个非法字段直接拒绝生成而不是胡编。这两步的意义在于让模型输出从“散文”变成了“记录”。开发者的代码从“解析不确定文本”变成了“处理强类型对象”这是一个质的改变。2.3 第三代从 Assistants 到 Responses再到 Agents SDKAssistants API 是中间的过渡产物它想帮你管好线程Thread、消息历史和内置工具。当时我用了一段感觉它把状态存储做得太“重”而且调试不如自己管理上下文来得直观。一些项目不得不把 Assistant 当成一个黑盒来调用出了问题很难定位。真正让我觉得“Agent 革命”落到地面的是后来出现的Responses API和Agents SDK。Responses API 把模型交互简化成一次响应、多次工具调用的运行时循环保留了你需要的结构化能力又不像 Assistants 那样绑架整个状态管理。Agents SDK 则更进一步它把 Agent 循环、工具调用、子 Agent 交接、护栏和追踪全部工程化你可以直接写“一个客服 Agent必要时把订单问题交给专门的售后 Agent”而不是自己造循环、手写状态机。三代 API 的核心区别我用下面这个表概括能力维度Chat CompletionsAssistants APIResponses Agents SDK工具调用不支持有限支持原生支持且支持并行调用输出结构化靠提示词和解析支持 JSON 模式支持严格 Structured Outputs会话状态管理开发者自己管API 内管 Thread默认无状态可自管Agent 编排无弱支持 Loop、Handoff、Guardrails可观测性难一般内置追踪与事件流如果你刚开始做 Agent我建议直接了解第三代但不要完全跳过第二代因为很多新概念比如tool_call_id、并行工具调用是在第二代里引入的理解它们才能读懂新 SDK 的底层日志。3. 函数调用的正确姿势从“让模型说话”到“让模型行动”3.1 工具定义的三个容易忽略的细节工具定义看着简单不就是写个 JSON Schema 嘛但实际写起来处处是坑。第一个细节是description是写给模型读的不是写给同事看的。你要用模型能理解的方式描述参数格式、示例值、边界条件。举个反面例子一个搜索商品的工具它的parameters里query字段如果只写“搜索关键词”模型很容易把整个用户问题原样塞进去导致搜索效果极差。改成“简短的商品名称或型号剔除修饰词和情感表达例如‘无线耳机 降噪’”之后搜索质量立刻上了一个台阶。第二个细节是枚举永远比自由文本可靠。你让模型选“订单状态pending, shipped, delivered”它大概率会严格选一个但如果你只写一个字符串字段让模型自己描述它就可能输出“the package is on the way”之类无法落库的值。能用enum的地方绝不要留白。第三个细节是必须约束多余属性。默认情况下模型在参数里塞额外的自定义字段是完全可能的。工具解析器拿到一个 “order_id” 的字符串没问题但如果模型顺手加了一个remark: 请尽快处理你的校验代码可能直接报错。在 JSON Schema 里把additionalProperties设为false是最简单的一道保险。3.2 执行-反馈循环tool_call_id 与多轮调用的正确写法函数调用的核心循环并不复杂但很多人第一次写都会挂在一个细节上每条工具结果必须绑定它在请求里的tool_call_id。这个 ID 是模型发起调用时生成的你执行完工具后要把结果作为role: tool的消息塞回消息列表并带上对应的tool_call_id模型才能把结果“接上”它之前的调用意图。如果漏了这个 ID模型通常会懵表现为不知道结果对应哪个调用或者把多个工具的结果混在一起理解。还有一点容易被忽视——一次 assistant 回复里可能出现多个tool_calls因为模型在并行调用多个工具。你执行时要逐个处理、逐个回填不能只回填第一个。这里给出一个最小可用的 Python 演示框架帮助你理解整个循环import json from openai import OpenAI client OpenAI() tools [ { type: function, function: { name: search_product, description: 按关键词搜索商品关键词要简短并剔除修饰词, parameters: { type: object, properties: { query: {type: string, description: 商品名称或型号} }, required: [query], additionalProperties: False } } } ] def run_search(query: str) - str: # 这里对接你的业务搜索接口返回 JSON 字符串 return json.dumps({matched: [{name: 无线降噪耳机, price: 499}]}) messages [{role: user, content: 帮我找一副 500 元以内的无线耳机}] for round_index in range(5): # 最多执行 5 轮工具调用防止死循环 response client.chat.completions.create( modelgpt-4o, messagesmessages, toolstools, tool_choiceauto ) msg response.choices[0].message messages.append(msg) # 保留 assistant 的完整回复包括 tool_calls if not msg.tool_calls: break # 模型不再调用工具输出最终答案 for tc in msg.tool_calls: if tc.function.name search_product: args json.loads(tc.function.arguments) result run_search(args[query]) messages.append({ role: tool, tool_call_id: tc.id, content: result }) print(messages[-1].content)这里有几个工程细节值得展开循环次数要有上限。就算模型再聪明也有可能反复工具调用而迟迟不给出最终答案。我在实测里遇到过模型连续调用三次“查询库存”而不收拢答案的情况设一个最大轮数比如 5能兜底。工具异常也要返回给模型。工具执行失败时不要直接中断请求而要把错误原因以content的形式返回给模型让它自己决定是换个参数重试、承认失败还是求助其他工具。把工具结果做成 JSON 字符串。模型天然理解 JSON别返回 Markdown 表格或纯文本否则它解析时会增加一层不确定性。3.3 实战案例一个“商品比价 Agent”的最小闭环为了让你看清楚整套东西怎么串起来我用“商品比价”场景走一遍完整链路。假设你有两个内部工具search_product负责搜索商品列表get_price_history负责查某个商品的历史价格趋势。Agent 的目标是回答“XX 商品最近值得买吗”。第一轮用户问“某品牌降噪耳机现在入手合适吗”模型判断需要先搜索商品于是返回一个tool_calls参数是{query: 某品牌 降噪耳机}。你的代码执行search_product把返回的商品列表 JSON 回填。第二轮模型看到商品列表发现价格信息不够明确于是再次发起两个并行调用一个继续搜索“最低价耳机”一个调用get_price_history查看目标商品历史价。你的代码分别执行后把两个结果对应各自的tool_call_id回填。第三轮模型看到所有数据给出结论“当前价格比近三个月均价低 12%可以入手。”这时没有新的tool_calls循环结束。这个过程中你需要关注的一个小细节是并行调用的结果顺序无所谓但每个结果必须挂对 ID。我见过有项目把两个并行调用的结果都塞给了第一个tool_call_id模型直接误解成“两个工具返回了相同数据”。4. Agents SDK 的工程架构编排、交接与护栏4.1 Agent Loop所谓“革命”其实就是一个受控循环很多人一听到 Agent 就觉得很玄但拆开来看Agents SDK 做的事情就是一个更健壮的“受控循环”模型输出 → 若有工具调用则执行 → 结果回填 → 模型再输出直到不再调用工具为止。这个循环本身并不新鲜真正值钱的是 SDK 把循环里的每个环节都做了标准化。异常管理单次工具调用失败不会让整个 Agent 崩溃错误信息会被传回模型由模型决定下一步。并行执行多个工具调用会并发执行再聚合不需要你手写线程池。最大迭代控制循环默认有上限防止模型陷入无限工具调用。在这个循环里Agent 的“记忆”其实就是 messages 列表。你可以把系统提示、工具定义、历史消息、工具结果全部放进去模型在其中推理。理解了这个你就明白为什么context的控制那么重要——因为它直接影响模型每次看到什么、依据什么决策。4.2 Handoff子 Agent 交接不是把工具攒一堆Handoff任务交接是我觉得 Agents SDK 里最容易被误解的概念。它不是“把一个任务分给多个 Agent 同时干”而是把对话控制权交给另一个 Agent由后者继续处理当前的用户请求完成后或者再交回来、或者直接结束。举一个实际的场景我有一个电商客服项目主 Agent 负责接待判断用户问题属于“物流查询”就交接给物流 Agent属于“退款”就交接给售后 Agent。这种拆分的价值在于每个子 Agent 可以只挂载自己需要的工具和提示词而不是让一个主 Agent 背上十几个工具。工具太多会让模型的选择难度上升响应变慢还容易出现“工具误选”——模型明明该退款却去调了物流查询接口。Handoff 本质上是一种“主题路由”它把决策空间切碎每个 Agent 面对的工具集更小判断自然更准确。但这套设计也有坑最大的是交接时的上下文丢失。子 Agent 拿到的是交接函数传递过来的参数而不是主 Agent 的全部对话历史。如果交接参数只传了一个“用户要求退款”售后 Agent 可能不知道用户已经和主 Agent 聊了十分钟补充信息。我的方案是交接时把必要的上下文摘要放进参数字段比如order_id、user_intent、already_done必要时直接传递截断后的历史消息。4.3 Guardrails回形针危机的工程版本护栏在我心里一直是“稳定 Agent 的兜底网”。Agents SDK 里的 Guardrails 可以在模型处理前和处理后各跑一次输入护栏检查用户的请求是否越界输出护栏检查模型的回答是否符合业务规范。我常用输出护栏做三件事字段校验判断最终输出是否包含订单号、敏感信息等业务要求字段。意图漂移检测防止模型从“查询物流”被带偏到“帮我评价下单”等无权限操作。敏感内容拦截检测回答是否涉及隐私信息或价格承诺。这和回形针危机的对应关系很清楚护栏不是让 Agent 更聪明而是让它在“聪明过头”的时候被踩一脚刹车。我给一个下单 Agent 设置的护栏是如果模型打算生成“下单成功”的确认回复但本次对话里没有任何实际下单工具返回的成功结果就拦截并复审。这个护栏曾经在测试阶段抓住了七八次“模型假称下单成功”的情况这在对话里很隐蔽用户不仔细看根本发现不了。4.4 可观测性没有轨迹Agent 出了问题就是玄学Agent 开发的痛苦指数和项目复杂度成正比一旦超过三个工具模型“为什么做出这个决定”就变成了一个黑盒。我在项目里做的第一个优化就是接入追踪把每次请求的模型输入输出、工具调用参数、工具返回结果、护栏拦截记录全部打上trace_id落日志。trace_id的设计建议是贯穿全链路。前端发起请求时生成一个 ID中间经过 API 调用、工具执行、护栏检查、最终输出每个环节都记录同一 ID。出问题时按 ID 拉日志就能回放整个 Agent 的“思考过程”很快能定位是工具参数错了、模型理解偏了还是护栏误拦了。Agents SDK自带追踪功能能看到循环每一轮的 tokens 消耗和耗时。我实测中的一个经验是每一次工具调用都会新增一次模型请求而每次请求都会把全部上下文再发送一遍。也就是说五轮工具调用的 Agenttoken 消耗往往是单轮对话的五六倍延迟也线性叠加。追踪面板里如果发现某一步特别慢十有八九是模型的messages列表太长了。5. 落地过程中我踩过的四个高频坑5.1 上下文窗口“吃紧”其实是三方在抢 token很多人以为上下文不够就是历史消息太多实际上还要算上系统提示和工具定义。我拿一个含 8 个工具的客服 Agent 做过一次统计工具定义大概吃掉 2k~3k token系统提示约 500 token剩余空间才留给对话历史。如果工具数量翻倍到 16 个光工具定义就能到 6k token还没开始聊就烧掉了一截。解决的思路有三种精简工具description、按场景动态挂载工具、以及对历史消息做摘要压缩。我采用的组合是“路由挂载”主 Agent 只带 2-3 个通用工具其他工具都放进子 Agent这样主 Agent 的上下文压力小很多。5.2 并行工具调用超时和重复执行是连环雷并行工具调用虽然省时间但引入了一个新问题如果 5 个工具里只有一个超时怎么办等你把其他结果回填给模型超时那个工具的tool_call_id还没有对应消息模型会困惑。更危险的是重复执行——同一轮请求里模型发起两个相似的tool_call比如“查询订单”和“再次查询订单”你的代码如果没做幂等处理就可能重复扣用户的钱或者重复发短信。我的处理习惯是给每个工具调用加业务级的幂等键同一个trace_id下同一参数的调用直接返回上一次的结果缓存。5.3 结构化输出兜底永远不要完全信任“保证”Structured Outputs 确实能把输出不合法率降到很低但不等于零。模型的拒绝响应、极端情况下的截断、API 升级前后的行为差异都可能让解析代码报错。我现在的做法是解析失败时走一个“重试通道”把错误反馈给模型重生成重试一次还不行就转人工兜底让用户看到“小助手遇到了困难”而不是直接白屏。另外提醒一点不要在结构化输出里配置reserved前缀的枚举值文档里说得很清楚这类值会被模型拒绝生成。我第一次用的时候没注意测试用例里塞了一个reserved_unknown结果模型直接报错排查了半天才发现是这个词的锅。5.4 账单焦虑Agent 循环的 token 消耗远超预期刚开始把 Agent 接入生产时我对成本没有概念上线一周后看了账单才惊觉一个平均 4 轮工具调用的会话单次对话要消耗 25k~35k token比纯文本问答高出 5 倍以上。这个数字看着还好但乘以日活用户量直接成了月账单的大头。控制成本有几个实际可用的手段用更便宜的模型跑简单子 Agent只有复杂决策才用大模型。Prompt 缓存要开重复的工具定义和系统提示能命中缓存能省不少钱。控制工具结果长度搜索类工具只回传 top K 个条目别把全量数据都交给模型。一个不算精确但很好用的经验如果某个 Agent 的 token 消耗超过了你预期模型的十倍先别急着骂 OpenAI 收费贵看看是不是你的循环设计里反复回传了过长的上下文。压缩工具返回内容、裁剪历史往往立竿见影。6. 开发者要怎么武装自己从提示工程升级到接口工程6.1 心智模型转换你不只是在“问模型”你是在设计接口顶尖提示工程和普通提示工程之间只差一个词约束。与其费尽心机写一套“请你严格按照以下格式回答”的提示词远不如一个结构化的工具定义和一个可靠的输出 Schema 来得稳定。做 Agent 开发这两年我最大的感受是我们应该把模型当成一个“极度聪明但极度缺少边界感的外包员工”你的 KPI 不是让它说出正确答案而是让它在一套可审计、可回滚、可容错的流程里把事办完。6.2 把对齐思维迁移到自己的业务 API 设计每次新增一个 Agent 工具我都会做三道自问模型可能误用这个工具吗如果参数范围太大我就加枚举或限制。输出可控吗如果模型的回答可能包含不实信息我就在护栏里拦住。失败可恢复吗工具调用出错时用户流程是否能体面地兜底这套自问源自回形针危机给我的启发任何“能力”都必须配上“边界”否则再强的模型也只是个更高效的破坏者。在业务场景里“破坏”可能就是一次错误的扣款、一封误解的客服回复、或者一条错误的价格承诺。6.3 一个小练习把 Agent 变成“回形针制造机”看它会不会走捷径最后给你一个我自己团队在用的测试方法给 Agent 设定一个高度单一、可量化的目标比如“在最短时间内完成最多的订单查询”然后把所有工具给它观察它在执行过程中是否出现走捷径的行为——例如跳过必要的身份校验、重复查询同一单、为了凑数而编造结果。这个练习能非常快地暴露你的工具描述漏洞、护栏缺口和上下文设计缺陷。我在好几个项目里用这个方法发现了“模型钻空子”的实例比如它为了完成“查询 10 个订单”的子目标拿同一个订单号查询了两次并把结果当作两条记录返回。如果业务侧没有幂等和去重这种问题很难在正常测试里出现。从回形针危机到 Agent 落地听起来跨度很大本质上却是一件事你愿不愿意为模型的聪明设下边界。API 的工具、结构化输出、护栏、追踪每一个设计都是一个“边界”。开发者真正要掌握的不是某个接口的细节而是这套“设定边界、验证边界、修复边界”的工程直觉。希望我的这些实测心得能让你在搭建自己的 Agent 时少走几段弯路。
