高晓庄 札记

Function Calling / Tool Use 协议详解——从 JSON Schema 到多轮调用 Agent 的核心是”调工具”。但模型是怎么决定”调哪个工具、传什么参数”的?这一节彻底讲清楚。 什么是 Function CallingFunction Calling(也叫 Tool Use)是 LLM 的一个能力——模型根据用户意图,自动选择并调用外部工具。 最简单的例子: 用户问”今天上海天气怎么样?” 模型不直接回答,而是返回一个 JSON:1234{ "tool": "get_weather", "params": {"city": "上海"}} 你的代码拿到这个 JSON,真的去调用天气 API 把结果再喂给模型 模型根据工具结果生成最终回答 这是 Agent 的基石。 Function Calling 的协议格式各家协议大同小异,以 OpenAI 为例: 1. 定义工具(JSON Schema)123...

Token 经济学——为什么 API 调用这么贵 我做了 2 个 AI 项目，第一个月底账单超预算 3 倍。问题不是”模型贵”——是我不懂 Token 经济学。 先搞清楚 Token 是什么1 个汉字 ≈ 1.5 个 Token这是 GPT 系列的中文 Token 化规则。意思是: 一句话”今天天气不错”= 6 字 = 约 9 Token 一篇 1000 字的文章 = 约 1500 Token GPT-4o 当前定价(2026 年 7 月): 输入:$2.50 / 1M Token 输出:$10.00 / 1M Token 换算中文: 输入 1000 字 ≈ $0.00375 输出 1000 字 ≈ $0.015 1 张图片 = 1000+ TokenGPT-4o 处理一张图片,按图片尺寸算 Token: 低分辨率:85 Token 高分辨率:170 Token(每 512×512 块) 所以 OCR 一份扫描件,比让模型读文字贵几十倍。 为什么”输入便宜,输出贵”这是几乎所有 LLM API 的定价规...

主流大模型横评——我用 6 个模型做同一道题的实测 6 个模型、同一道题、6 轮对比。结果有几个反直觉的发现——尤其是国产模型。 横评背景我做 AI 项目这一年,几乎每周都要回答一个问题:“这个场景用哪个模型?” 网上横评很多,但大部分是跑 benchmark、跑分数。我自己用的是真实业务场景——所以这次我用 6 个主流模型,在同一组真实任务上跑一遍。 参与横评的 6 个模型(2026 年 7 月最新版): 模型 厂商 定位 GPT-4o OpenAI 通用旗舰 Claude Sonnet 4.5 Anthropic 长文+代码 Gemini 2.5 Pro Google 多模态 Qwen3-Plus 阿里 中文+开源 GLM-4.5 智谱 通用 DeepSeek-V3 DeepSeek 推理+代码 测试题目设计我不跑 benchmark——跑 6 道我自己业务里真实遇到的题: 长文本摘要:把一份 5000 字的产品 PRD 摘要成 5 段 代码 review:一段 200 行的 Python 代码,找出 3 个潜在 bug 复杂推理:经典...

气量智能问数：Text-to-SQL 的落地实践 这篇文章不是”Text-to-SQL 教程”——网上那种”用 LangChain 调 OpenAI 跑通 SQL 生成”的教程一堆一堆的，没什么好写的。这篇写的是真的在一个企业项目里把它做上线时，遇到的哪些没人会告诉你的破事。 起因：客户问”能不能用自然语言查？”这个项目不是”领导拍脑袋要做 AI”的产物，是客户真提出来的。 我们做的是燃气行业的 SaaS 系统（抄表 / 营收 / 客户管理）。客户提的需求模式很固定：”能不能加个报表，看 X / Y / Z 的统计？”——几乎每两周一个需求，每个需求都要定制开发。 客户业务人员原话：”我们自己也想试，但每次都找你们开发，太慢了。能不能让我们直接问？” 一开始我觉得这是”伪需求”——SQL 这么复杂，业务人员怎么可能问得清楚？后来做了才发现，他们 80% 的需求确实就是简单的”按某个维度统计一下”，这种需求如果能让 AI 解决，确实能省掉大量定制开发。 第一次尝试：直接调 OpenAI API最开始我的方案特别简单： 12345678d...

从传统后端到 AI 工程化：我的六年踩坑复盘 写这篇文章之前犹豫了很久——怕被说”凡尔赛”或者”成功学”。但想了想，简历上罗列的项目和文章里干巴巴的”问题 → 解决”，其实不能完整说明一个人是怎么走过来的。这篇文章试着把那些简历和文章里不会写的东西记下来，包括走错的弯路、推翻过的方案、深夜 debug 的崩溃时刻。 一个不太体面的起点我 2020 年底入职腾讯无线大连研发中心的时候，简历上写的是”熟悉 Spring Boot、MyBatis”，实际上对大厂那套工程化流程是两眼一抹黑的。第一次 code review 被打回来 30 多个 comment，包括命名、异常处理、日志格式、单元测试覆盖率——每个我都觉得”不至于吧”。 那段时间最大的心理冲击不是技术本身，是发现自己之前在小公司积累的”工程化”标准，在大厂眼里根本不达标。这种感觉挺打击自信的，但反过来也让我开始认真对待”工程”这两个字。 2020 - 2022：腾讯，安全中心，做自动化测试和安全运营这是我的第一个正经后端岗位，做了两个项目： 优测自动化测试平台：Golang（Beego）为主，混着 Java（Sprin...

Dify 编排企业级 Workflow 当 AI 能力要真正落地到业务，靠的不是”聊天框”，而是一条条可控、可调试、可复用的 Workflow。Dify 是编排这些工作流的利器。 为什么用 Workflow 而不是纯 Agent一开始我们也试过”让 Agent 自由发挥”，结果很惨：Agent 会乱调用工具、输出不稳定、难以调试。 Workflow 的价值在于”可控”：把 AI 能力拆成一条明确的执行链，每一步做什么、走哪个分支都是确定的。对企业场景，可控比”聪明”重要得多。 核心节点类型Dify 的 Workflow 由几种节点拼成： 节点 作用 LLM 调大模型生成 知识检索 从知识库召回 工具 调用外部 API / 自定义代码 条件分支 根据结果走不同路径 变量聚合 汇总多个分支的结果 一个真实场景：气量智能问数以我做的”自然语言查数据”为例，Workflow 大概是这样的： 123456789用户提问（"上个月各营业厅的用气量是多少"） ↓LLM：意图识别 + 实体抽取（时间、指标、维度） ...

YOLOv5 目标检测训练完整实践 网上”YOLOv5 教程”一大堆，从环境搭建到训练到部署都有。但没人会告诉你：标注质量差到模型根本训不出来是什么体验？现场 GPU 跑得好好的模型到客户机房延迟 1.2 秒怎么破？这些”破事”才是真做项目时遇到的。这篇写这些。 项目起源：客户一句”能自动识别吗？”这个项目不是从”我们想用 AI”开始的，是从客户一句”拍照不规范，能不能自动识别？“开始的。 背景：我们做的是燃气行业的巡检系统，巡检人员去现场拍调压箱、井盖这些设备，回来人工检查拍照是否符合规范。但人工检查不靠谱——拍糊了、角度不对、漏拍的情况太常见。客户希望自动识别。 当时我心里的第一反应是：”这个需求不靠谱，照片变化太多，AI 怎么可能都识别？”后来发现——业务方对 AI 的预期和 AI 的真实能力之间，永远隔着一道鸿沟。这个项目就是学着怎么填这道鸿沟。 第一阶段：数据采集，差点死在起点第一次数据清洗：扔掉了 40%我们从客户的真实巡检照片里收集了 2 万张，准备训练。但第一轮数据清洗就让我震惊： 重复照片：同一个巡检员上传 5 张几乎一样的图 拍照失败：模糊、过曝、角度...

LangChain Agent 实战：从原理到落地 这篇本来想写成标准的”LangChain 教程”——讲 ReAct、讲工具调用、讲 Memory。但写到一半发现，网上这种教程一搜一大堆，没必要再写一份。所以改成”我在做气量智能问数项目时用 LangChain Agent 的真实经验”，把那些官方文档和教程不会告诉你的事写出来。 Agent 是什么（不废话版）如果你已经知道 Agent 是大模型 + 工具 + 记忆，可以直接跳到下面”我踩的坑”部分。 简单说：传统 LLM 只能生成文本，Agent 让 LLM 能”行动”——决定要不要调工具、调哪个工具、怎么解析结果、多次推理直到完成目标。 经典范式是 ReAct（Reasoning + Acting）： 123456Thought: 我需要先查询天气Action: get_weatherAction Input: 北京Observation: 晴，25°CThought: 现在可以给出穿衣建议了Final Answer: 北京今天晴，25°C，建议穿短袖。 我用 Agent 做的真实项目：气量智能问数我在金建做的”气量智能...