沈阳市网站建设_网站建设公司_外包开发_seo优化

之前我们说过，复杂的AI项目，其难度有三：

第一，如何将认知整理成知识，或者已经有知识的情况下，如何组织数据；

第二，数据应该如何与AI交互，保证每次AI都能拿到相关数据。发现由于数据不足导致的AI问题，应该如何用生产数据反馈系统，优化知识库，这就是我们常说的数据飞轮系统，他是数据工程的一个分支；

第三，也是最后一个关卡，意图识别；

这不，我们P9的学员，在智能体创业项目中就被意图识别折腾得很惨：

并且错误的花样还五花八门的：

1. description明明写得很清楚，但工具就是不被调用；
2. 工具倒是调用准了，但是工具所需参数又拿不到；
3. 终于最后调好了，模型一个更新，整个系统又被玩坏了；

总结下来就一句：工具调用（Function Calling）总出问题，这个该如何解决呢？大概图示如下：

但具体要回答这个问题，就得从头说起咯，首先我们来看智能体架构的基石工具调用：

Agent的本质：函数调用

首先，我们要知道的是，现阶段大模型可以说是很简单的，因他就只有一个API调用，并且只有一个输入/输出：

但他其实很复杂，因为输入内容的背后具有大量的含义，需要我们把各行各业的知识放进去，否则输出很容易不符预期：

现在常见的智能体如Manus也是这个模式，比如最经典的让模型回答天气情况，因为模型本身是没有天气数据的，所以在用户询问天气时候，需要外调工具，这里核心代码是：

tools = [{ "type": "function","name": "get_weather","description": "Retrieves current weather for the given location.","parameters": { "type": "object", "properties": { "location": { "type": "string", "description": "City and country e.g. Bogotá, Colombia" }, ...... }, }}]response = client.responses.create( model="gpt-5", tools=tools, input="今天成都的天气怎么样",)

可以看出来，模型具有哪些工具调用能力，全部是我们预定义好的，模型会根据用户输入，选择使用哪个工具：

# 用户输入user_query = "今天北京天气怎么样？"# 模型会分析：# - 用户问的是"天气" → 匹配到 get_weather 的 description# - 提到了"北京" → 对应 location 参数# - 决定调用 get_weather 函数

而模型是如何判断要调用某个工具呢，答案是根据用户输入与description（名称、参数也会用到）做对比，也就是：

判断“今天北京天气怎么样？”与"description": "Retrieves current weather for the given location."的关联性

于是这里问题也就来了，也就是我们之前学员会遭遇的问题：

这里是存在黑盒的，对于本次对话要不要调用工具、用哪个工具、参数怎么填，这个是没法直接插手的

当前场景简单、工具单一，模型的表现是很稳健的，但生产环境聊天上下文复杂度较高，并且工具数量也很多，这会加大模型工具调用难度，最直接的表现就是 漏调用 → 错调用 → 参数提取错误 → 调用出错

而这里会不会出工具调用问题，从架构设计来说，几乎是必定会发生的，而想要缓解工具调用的问题，只有两个点可操作：

第一，为问题添加更多上下文，以方便模型更好做意图判断，也就是在提示词上做文章；

第二，将Tools的设置，包括描述、参数等信息写得更清晰点；

除此两点之外，还有些“懒加载”策略，每次调用模型前，先做一轮意图识别，只加载需要的Tools，由此降低模型识别压力，但总的来说依旧是在大规则内做小优化。

只不过，出问题不重要，重要是发生得多频繁，如何降低他的问题。

意图收敛

如果在生产环境已经表现出了多工具调用出问题，那么就不能将用户上下文一股脑的给模型了，连这种都不能：

帮我查一下最近北京天气怎么样，还有机票贵不贵？然后再给一堆工具：get_weather、search_flight、search_news...

更稳的做法是对用户问题进行改写，把输入整理成一个结构化意图，做一层意图清洗：

# 让模型只做意图识别 + 槽位填充{ "task_type": "check_weather", "city": "北京", "need_flight_info": true}

再根据task_type去决定到底要出几个子任务、每个子任务暴露哪些工具。

换句话说：不要让模型一边理解人话，一边挑工具，一边还要组织答案。

把这些步骤拆开，这也是我们之前介绍的提示词规则单一职责原则，这样操作下来，错误率会降低的同时，出问题也好直接定位到对应提示词。

在落地上，常见的几种意图收敛手段：

1. **固定输入模板：**让用户“填表”做选择题，而不是自由回答，这种方式使用较少，但效果很好；
2. **意图识别小模型：**第一个模型只负责识别任务类型，第二个模型才负责调用工具，如果在成本、响应速度有要求时候，这个是常见选项；
3. **场景分流：**用户入口就分查天气/查订单/问知识，不同入口走不同的工具集；
4. 问题改写，最后也是最常见的方式，会用模型对用户提问基于我们已有工具进行问题改写，这种效果较好，就是消耗Token很凶；

{ "intents": [ { "type": "get_weather", "city": "北京", "date": "最近三天" }, { "type": "search_flight", "from": "上海", "to": "北京", "date": "本周五", "sort_by": "price" } ]}

总结下来就一句话：先认为对问题尽量结构化，再说工具调用。

工具收敛

前面说过，工具调用的黑盒部分我们管不了，但工具列表是完全能控制的。

很多时候工具调用最大的问题，不是模型不够聪明，而是你给它的工具太多、太像。这里实操下来，策略也就3个可以分享的：

第一，依旧是单一职责原则，一个工具绝不完成两个任务

# ❌ 多合一大工具"description": "获取天气和航班信息"# ✅ 单一职责 "description": "获取指定城市的实时天气信息"

第二，按场景加载工具包，工具包预定义能少则少

# 不要有一个大 tools = [...] 到处复用weather_tools = [get_weather]order_tools = [query_order, cancel_order] # 每次请求前根据意图选一个小包挂上去

第三，描述和名称，AI要读得懂：

# ❌ 模糊的描述"description": "Retrieves current weather for the given location."# ✅ 清晰的描述"description": "获取指定城市的实时天气信息。当用户询问当前温度、湿度、风速时使用。不适用于查询历史天气或气候特征。"

很多“description明明写得很清楚但就是不被调用”的场景，真拆开看，会发现description根本没有把什么时候用/不用说清楚，还有些时候name与参数的定义非常随意，你如果随意，模型就更随意了！

自由收敛

就算意图收敛、工具列表收敛、描述写得再漂亮，最终照样会出问题，原因是前面收敛有些动作也是依赖模型，本来就可能出问题，而更多的情况是参数抽取错误。

换句话说：关键词抽取错误（或者说抽取不稳定），是模型常见错误。

碰到这种情况，要么需要建立飞轮系统，不断根据错误增加知识库数据，不停在提示词加标签；要么会用到微调技术（概率很低）；

而有些时候，我们也会在代码上做处理，加一些验收逻辑，比如各种校验：

def get_weather(location, units='celsius'):# 先校验，再执行if not location or len(location) > 50: raise ValueError("城市名称无效")if units not in ["celsius", "fahrenheit"]: raise ValueError("温度单位不支持")# 工具返回后，检查数据结构是否完整if not response.get('temperature'):# 走备用方案或给用户友好提示return"暂时无法获取温度信息"# 设一个上限，比如每次最多重试2次for attempt in range(2):try:return call_tool()except ValidationError:if attempt == 1: # 最后一次还错 return"抱歉，暂时无法处理您的请求"...# 真正的业务逻辑...

工具调用评测集

事实上，所有的Agent，都会需要一个**评测和数据回收。**不然好不好都是抓瞎，甚至每次模型发布、新版本发布，稳不稳定都只能看脸。

而很多人确实也是这样开发Agent的：

1. 本地调试几次，觉得“挺准”；
2. 上线一跑，过几天用户开始骂；
3. 有时候好、有时候坏、还特别难复现；

这种“不稳定感”完全就是缺少评测集所致。而要建立这个测试集也很简单，就是对错误情况进行收集，而收集的第一步就是日志做得足够细，甚至每天有人审查：

一、日志：

# 每次调用都要记下来：log_data = { "user_input": "今天北京天气", "model_tool_call": "get_weather", "model_arguments": {"location": "北京"}, "tool_result": {"temperature": 25}, "final_response": "北京今天25度，晴天", "success": True # 业务标记}

二、人工审查： 从日志里抽样本，标注：

1. 该不该调用工具？
2. 应该用哪个工具？
3. 参数有没有填对？

然后统计：漏调用率、错调用率、参数错误率…

三、根据错误样本做优化，策略也就是我们前面说的几点；

这其实就是数据飞轮在Function Calling上的一个子循环：生产数据 → 错误样本 → Prompt/规则迭代 → 新版本上线 → 再收集数据

Skills

然后最近Claude提出了Skills策略，其实他在一定程度也能缓解工具调用错误问题，在Skills策略之前的流程是：

用户输入 → 模型直接在一堆 tools 里挑漏调 / 选错 / 懒得调，常发生在这一层

上了 Skills 之后变成：

用户问题 → 先选 Skill（粗意图路由） → 再在 Skill 里用少量工具 + 既定 SOP模型不再对着几十个工具瞎撞，而是在各种小环境里做判断

其实可以认为Skills将之前我们一部分工程优化做到模型层去了。Skill 可以缓解：选错工具、什么时候调用工具、调用后数据如何处理等问题。

但是碰到用户语焉不详、工具schema一塌糊涂等问题时候依旧没办法。

只不过Skills这东西还不确定其他厂商要不要支持，所以我们后面再具体讨论吧。

结语

2025年10月2日，在美国旧金山硅谷举办内部封闭讨论会，有600多人的创业者，AI工程师参与；

而真实信息反馈：95% 的 AI Agent系统，在生产环境中根本用不起来。

并不是因为打模型不够聪明，而是AI工程以及工具层还需要继续努力，最后回归下，我们之前说过：

1. 复杂AI项目的第三难关是意图识别；
2. 意图识别失败，最直观的表现就是：工具调用乱七八糟；

但如果我们从工程的视角拆开看，它无非是几件事：意图收敛、工具收敛、自由度收敛（很多校准）以及一条评测数据集。

上述动作做完也不意味着问题没了，只不过会更心里有数了，如果这样都解决不了，那就换模型或者等模型更新就好，或者我们还有更复杂的策略，如提供上下文的上下文，只不过这确实很复杂了，我们这里就不展开了…

想入门 AI 大模型却找不到清晰方向？备考大厂 AI 岗还在四处搜集零散资料？别再浪费时间啦！2025 年AI 大模型全套学习资料已整理完毕，从学习路线到面试真题，从工具教程到行业报告，一站式覆盖你的所有需求，现在全部免费分享！

👇👇扫码免费领取全部内容👇👇

​

一、学习必备：100+本大模型电子书+26 份行业报告 + 600+ 套技术PPT，帮你看透 AI 趋势

想了解大模型的行业动态、商业落地案例？大模型电子书？这份资料帮你站在 “行业高度” 学 AI：

1. 100+本大模型方向电子书

2. 26 份行业研究报告：覆盖多领域实践与趋势

报告包含阿里、DeepSeek 等权威机构发布的核心内容，涵盖：

• 职业趋势：《AI + 职业趋势报告》《中国 AI 人才粮仓模型解析》；
• 商业落地：《生成式 AI 商业落地白皮书》《AI Agent 应用落地技术白皮书》；
• 领域细分：《AGI 在金融领域的应用报告》《AI GC 实践案例集》；
• 行业监测：《2024 年中国大模型季度监测报告》《2025 年中国技术市场发展趋势》。

3. 600+套技术大会 PPT：听行业大咖讲实战

PPT 整理自 2024-2025 年热门技术大会，包含百度、腾讯、字节等企业的一线实践：

• 安全方向：《端侧大模型的安全建设》《大模型驱动安全升级（腾讯代码安全实践）》；
• 产品与创新：《大模型产品如何创新与创收》《AI 时代的新范式：构建 AI 产品》；
• 多模态与 Agent：《Step-Video 开源模型（视频生成进展）》《Agentic RAG 的现在与未来》；
• 工程落地：《从原型到生产：AgentOps 加速字节 AI 应用落地》《智能代码助手 CodeFuse 的架构设计》。

二、求职必看：大厂 AI 岗面试 “弹药库”，300 + 真题 + 107 道面经直接抱走

想冲字节、腾讯、阿里、蔚来等大厂 AI 岗？这份面试资料帮你提前 “押题”，拒绝临场慌！

1. 107 道大厂面经：覆盖 Prompt、RAG、大模型应用工程师等热门岗位

面经整理自 2021-2025 年真实面试场景，包含 TPlink、字节、腾讯、蔚来、虾皮、中兴、科大讯飞、京东等企业的高频考题，每道题都附带思路解析：

2. 102 道 AI 大模型真题：直击大模型核心考点

针对大模型专属考题，从概念到实践全面覆盖，帮你理清底层逻辑：

3. 97 道 LLMs 真题：聚焦大型语言模型高频问题

专门拆解 LLMs 的核心痛点与解决方案，比如让很多人头疼的 “复读机问题”：

三、路线必明： AI 大模型学习路线图，1 张图理清核心内容

刚接触 AI 大模型，不知道该从哪学起？这份「AI大模型 学习路线图」直接帮你划重点，不用再盲目摸索！

路线图涵盖 5 大核心板块，从基础到进阶层层递进：一步步带你从入门到进阶，从理论到实战。

L1阶段:启航篇丨极速破界AI新时代

L1阶段：了解大模型的基础知识，以及大模型在各个行业的应用和分析，学习理解大模型的核心原理、关键技术以及大模型应用场景。

L2阶段：攻坚篇丨RAG开发实战工坊

L2阶段：AI大模型RAG应用开发工程，主要学习RAG检索增强生成：包括Naive RAG、Advanced-RAG以及RAG性能评估，还有GraphRAG在内的多个RAG热门项目的分析。

L3阶段：跃迁篇丨Agent智能体架构设计

L3阶段：大模型Agent应用架构进阶实现，主要学习LangChain、 LIamaIndex框架，也会学习到AutoGPT、 MetaGPT等多Agent系统，打造Agent智能体。

L4阶段：精进篇丨模型微调与私有化部署

L4阶段：大模型的微调和私有化部署，更加深入的探讨Transformer架构，学习大模型的微调技术，利用DeepSpeed、Lamam Factory等工具快速进行模型微调，并通过Ollama、vLLM等推理部署框架，实现模型的快速部署。

L5阶段：专题集丨特训篇 【录播课】

四、资料领取：全套内容免费抱走，学 AI 不用再找第二份

不管你是 0 基础想入门 AI 大模型，还是有基础想冲刺大厂、了解行业趋势，这份资料都能满足你！
现在只需按照提示操作，就能免费领取：

👇👇扫码免费领取全部内容👇👇

​

2025 年想抓住 AI 大模型的风口？别犹豫，这份免费资料就是你的 “起跑线”！