尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
Tool Calling 前端怎么接:工具进度、错误回传、权限边界
《AI 前端实战》第 4/8 篇上篇Streaming UI 工程化下篇预告生成式 UIJSON Schema → React第 23 篇解决了「模型会说话而且说的过程体验还行」。第 4 篇进入分水岭模型开始调用工具。前端此时不再只是对话框而要当「调度台」——展示进度、回收错误、守住权限。你将学到Tool Calling 的前端数据流工具进度组件怎么设计失败重试与 Human-in-the-loop权限白名单怎么落地一个双工具 Demo 的结构一、先看数据流前端视角用户输入 → 模型流式输出可能含 tool_call → 前端识别 tool_call展示「运行中」 → 前端/后端执行工具建议后端执行 → tool_result 回灌模型 → 模型继续生成最终回答关键点tool_call 不是最终答案只是中间事件UI 要用parts模型而不是一条纯文本气泡硬拼接工具执行尽量在服务端前端负责状态与确认承接第 3 篇的消息模型type ChatPart | { type: text; text: string } | { type: tool; id: string; name: string; args?: unknown; status: pending | running | done | error | cancelled; output?: string; error?: string; };二、工具进度组件用户要看见「它在干什么」最少展示 4 个信息字段例子工具名searchDocs状态运行中 / 成功 / 失败关键参数q退款规则注意脱敏结果摘要「找到 3 条文档」或错误原因示意function ToolCard({ part }: { part: ExtractChatPart, { type: tool } }) { return ( div classNamerounded-lg border p-3 text-sm div classNamefont-medium工具{part.name}/div div状态{part.status}/div {part.error div classNametext-red-500{part.error}/div} {part.output pre classNamemt-2 overflow-auto{part.output}/pre} /div ); }体验原则运行中可取消若业务允许成功默认折叠详情失败默认展开不要把敏感参数token、手机号明文甩在 UI三、错误回传失败也是给模型的上下文工具失败时前端/网关至少要回传结构化错误{ tool_call_id: call_123, ok: false, error_code: TIMEOUT, error_message: searchDocs timed out after 8s }然后让模型决定换参数重试、换工具、或向用户道歉并给建议。前端侧注意区分「工具失败」和「模型生成失败」同一tool_call_id只更新一个 part避免裂成多条自动重试要有上限并在 UI 显示「第 2/3 次重试」四、权限边界默认不信任模型生产环境建议三级级别例子策略L0 只读自动搜文档、查天气可自动执行L1 低风险写入创建草稿可自动或二次确认L2 高风险删数据、转账、发生产必须人工确认前端确认框示例逻辑async function maybeRunTool(tool: ToolCall) { const level permissionOf(tool.name); if (level L2) { const ok await askUserConfirm(tool); if (!ok) return { ok: false, error_code: USER_DENIED }; } return executeTool(tool); }白名单应来自服务端配置前端只做展示与确认不能只靠前端拦截。五、Human-in-the-loop把人嵌进环里而不是事后救火适合打断确认的时机参数看起来危险批量删除、对外发送模型连续两次工具失败费用敏感操作大额 API 调用UI 上给三个明确动作允许执行修改参数后再执行拒绝并让模型换方案这比「全自动」更慢一点但能上线。六、双工具 Demo结构即可目标用户问「北京天气怎么样并写进笔记草稿」。工具getWeather(city)saveNote(title, content)推荐状态序text(思考/开场) → tool(getWeather, running) → tool(getWeather, done) → text(简述天气) → tool(saveNote, pending_confirm) // L1/L2 → 用户确认 → tool(saveNote, done) → text(最终回复)前端只要保证每个 tool part 可独立更新确认动作绑定到具体tool.id。七、三个高频坑坑 1把 tool 结果直接当最终气泡用户会看到原始 JSON。应回灌模型再生成可读回答或对结果做摘要展示。坑 2前端直接拿着模型参数去打内网接口容易变成 SSRF / 越权。工具执行放 BFF前端只传tool_call_id与用户确认结果。坑 3停止生成后工具还在跑停止要同时abort 模型流 取消进行中的工具请求能取消的才取消 UI 标cancelled。八、和本系列前后篇的关系第 3 篇消息合并与重连给 tool parts 打底第 4 篇Tool Calling UI 与权限第 5 篇生成式 UI——工具不只返回文本还可返回界面描述若你做的是 Agent 产品这一篇是「能不能上线」的门槛之一。小结Tool Calling 前端三件事进度可见用户知道模型在调用什么错误可回传失败成为下一轮上下文而不是白屏权限可阻断高风险必须人确认把对话框升级成调度台你才算跨过 L2 → L3。下篇预告《AI 前端实战》第 5/8 篇生成式 UI 实战用 JSON Schema React 动态渲染 AI 界面。系列导航1 能力地图 · 2 流式 Chat · 3 Streaming 工程化
RELATED

相关推荐

新一代连接器技术解析与选型指南

新一代连接器技术解析与选型指南

1. 连接器新品发布背景解析最近TE Connectivity(泰科电子)、JAE(日本航空电子工业株式会社)和锦凌电子三家行业头部企业相继发布了新一代连接器产品。作为电子设备中不可或缺的基础元件,连接器新品往往预示着行业技术发…

📅 2026/9/14 14:06:45
程序员如何应对AI带来的职业角色冲突

程序员如何应对AI带来的职业角色冲突

1. 程序员群体的"AI人格分裂"现象解析最近在技术社区里,一个有趣的现象正在蔓延——不少开发者开始戏称自己患上了"AI人格分裂"。这种现象特指程序员在日常工作中,同时扮演着两种截然不同的角色:一方面作为AI技术的创造者…

📅 2026/9/12 2:01:30
NoScript安全机制解析与防护盲区

NoScript安全机制解析与防护盲区

1. NoScript的安全机制解析NoScript作为一款知名的浏览器安全扩展,其核心工作原理是通过默认阻止所有JavaScript、Java、Flash等动态内容的执行,除非用户明确允许特定域名的脚本运行。这种"默认拒绝"的安全模型确实能有效阻断大多数基于脚本的…

📅 2026/9/11 4:19:42
MORE NEWS

更多资讯

📰

串口服务器:工业物联网设备联网的“开山鼻祖”与实操全解析

串口服务器这东西,放在工业物联网的整个版图里,算不上多光鲜,但你要是把时间线拉长,从设备联网的角度往回看,它确实是当之无愧的"开山鼻祖"。十几年前,现场密密麻麻的PLC、电表、传感器&#xff…

📰

STM32CubeProgrammer安装配置与AI编程烧录实战指南

这几年我一直把嵌入式软件开发和AI编程结合起来玩,用Claude、VS Code里的AI编程插件写STM32代码,再用STM32CubeProgrammer把固件烧进板子。前阵子帮朋友搞一块STM32F103板子,他正好在学怎么用AI写嵌入式代码,结果卡在最后一步&…

📰

STM32驱动TM1640数码管:从GPIO时序到段码映射的完整实现

简介:STM32 TM1640数码管驱动例程面向嵌入式入门开发者,基于STM32F103C8T6最小系统板,借助STM32CubeMX完成GPIO初始化,实现八位数码管逐位显示指定数字,并演示圆周率输出。压缩包共145个文件,解压后约5.97M…

📰

STM32C552 ADC电压采集精度实战指南

1. 项目概述:为什么STM32C552的ADC电压采集不是“接上线就出数”那么简单你手头有一块STM32C552开发板,想测个电池电压、电源轨电压或者传感器输出——看起来就是配置一下ADC通道、启动转换、读取寄存器值,三步搞定。但现实往往是&#xff1a…

📰

霞鹜文楷:免费商用开源中文字体上手指南

霞鹜文楷:免费商用开源中文字体上手指南 【免费下载链接】LxgwWenKai An open-source Chinese font derived from Fontworks Klee One. 一款开源中文字体,基于 FONTWORKS 出品字体 Klee One 衍生。 项目地址: https://gitcode.com/GitHub_Trending/lx…

📰

C#程序员必看!var和显式类型该用哪个?编译器早藏好答案

一、90%的C#开发者都踩过的坑,代码评审吵翻天针对C#开发领域的人而言, 差不多人人皆历经了一种困惑呢: 当着手书写变量之际, 究竟该选用var, 还是采用显式声明类型? 有的人认为var具备简洁且高效的特性, 书写起来不但节省时间而且还省力气;有的人则坚决…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬