Agent 架构模式——ReAct、Plan-and-Execute、Reflection 三大范式实战对比
Agent 架构模式——ReAct、Plan-and-Execute、Reflection 三大范式实战对比 同样是 Agent,”边想边做”、”先想再做”、”做后再想”——三种架构差别巨大。选错了成本能差 3 倍。 三种架构的核心区别ReAct(边想边做)1思考 1 → 行动 1 → 观察 1 → 思考 2 → 行动 2 → ... → 结束 特点:每一步都基于上一步的结果,强适应性。 Plan-and-Execute(先想再做)1计划 → 行动 1 → 行动 2 → ... → 行动 N → 总结 特点:先一次性规划好所有步骤,强一致性。 Reflection(做后再想)1行动 → 反思 → 改进行动 → 反思 → ... → 结束 特点:每次行动后都”复盘”,强改进能力。 ReAct 深度解析工作流程12345678910111213141516171819202122class ReActAgent: def __init__(self, llm, tools, max_iter=10): self.llm = llm self....
模型蒸馏 vs 微调——两个 80 分,一个 120 分
模型蒸馏 vs 微调——两个 80 分,一个 120 分 “我想让模型懂我的业务”——这是大多数 AI 项目第一步。蒸馏 vs 微调,选错了浪费 10 倍成本。 两个概念的清晰区分蒸馏(Distillation)让小模型学大模型的行为。 教师:大模型(GPT-4o、Claude) 学生:小模型(自己训练的 7B/13B) 过程:用大模型生成数据,训练小模型模仿 目的:用小模型达到大模型 90%+ 效果,成本降 10 倍 微调(Fine-tuning)让模型学特定知识或风格。 基础:已有模型(GPT-4o、Llama、Qwen) 过程:用特定数据集继续训练 目的:让模型”专业”——懂医疗、法律、企业内部术语 关键区别 维度 蒸馏 微调 目的 缩小成本 增加专业能力 数据来源 大模型生成 业务数据 改变的是什么 模型规模 模型知识/风格 典型场景 通用 Agent、成本敏感 垂直行业、企业内部 蒸馏:什么时候用适合场景 通用任务 + 成本敏感 客服机器人、内容审核、简单分类 用大模型标注几万条数据,训一个 7B 小模型 推理成...
长上下文窗口——100K、200K、1M Token 背后的工程难题
长上下文窗口——100K、200K、1M Token 背后的工程难题 Gemini 1.5 Pro 已经支持 1M Token 上下文。Claude 200K,GPT-4o 128K。但”支持”和”好用”是两回事。 长上下文的吸引力理论上: 把整本《三体》扔给模型,直接问”程心为什么这么选择?” 把 1000 行代码扔给模型,直接说”重构这个模块” 把整个项目代码库扔给模型,让它”理解我的代码” 这是 Agent 时代最性感的想象。 但实际呢? 长上下文的”中段迷失”问题我做过实测——模型在长上下文中段表现最差。 测试方法: 准备 100 个事实,均匀分布在 100K Token 的文本里 让模型回答”事实 #X 是什么” 观察不同位置事实的召回率 结果: 12345位置 1 (开头 10%): 召回率 95%位置 2 (10-30%): 召回率 88%位置 3 (30-70%): 召回率 62% ← 中段最差位置 4 (70-90%): 召回率 75%位置 5 (90-100%): 召回率 89% 中段信息丢失最多——这是 LLM 的”中段迷失”现象。...
Prompt Engineering 进阶——CoT、ReAct、Reflexion 三种范式
Prompt Engineering 进阶——CoT、ReAct、Reflexion 三种范式 简单 Prompt 只能让模型”回答问题”。要让模型”思考 + 行动 + 反思”——需要 Chain-of-Thought、ReAct、Reflexion 三种范式。 范式 1:Chain-of-Thought(CoT)核心思想:让模型”一步步想”,而不是”直接答”。 朴素 CoT1234问题:小明有 5 个苹果,给了小红 2 个,又买了 3 个,现在有几个?直接答:6CoT: 小明有 5 个,给小红的 2 个 - 5-2=3 个,又买 3 个 +3=6 个。 Few-shot CoT(更有效)1234567问题:小明有 5 个苹果,给了小红 2 个,又买了 3 个,现在有几个?解答:小李有 8 个糖果,给了小王 3 个,又收到小赵的 5 个,现在有几个?小李 8 - 3 + 5 = 10 个。解答:小李有 8 个糖果,给了小王 3 个,又收到小赵的 5 个,现在有几个?小李 8 - 3 + 5 = 10 个。 给几个”示范样例”,模型就能学会”一步步想”。 Zero-shot ...
Function Calling / Tool Use 协议详解——从 JSON Schema 到多轮调用
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 调用这么贵
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 个模型、同一道题、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 的落地实践 这篇文章不是”Text-to-SQL 教程”——网上那种”用 LangChain 调 OpenAI 跑通 SQL 生成”的教程一堆一堆的,没什么好写的。这篇写的是真的在一个企业项目里把它做上线时,遇到的哪些没人会告诉你的破事。 起因:客户问”能不能用自然语言查?”这个项目不是”领导拍脑袋要做 AI”的产物,是客户真提出来的。 我们做的是燃气行业的 SaaS 系统(抄表 / 营收 / 客户管理)。客户提的需求模式很固定:”能不能加个报表,看 X / Y / Z 的统计?”——几乎每两周一个需求,每个需求都要定制开发。 客户业务人员原话:”我们自己也想试,但每次都找你们开发,太慢了。能不能让我们直接问?” 一开始我觉得这是”伪需求”——SQL 这么复杂,业务人员怎么可能问得清楚?后来做了才发现,他们 80% 的需求确实就是简单的”按某个维度统计一下”,这种需求如果能让 AI 解决,确实能省掉大量定制开发。 第一次尝试:直接调 OpenAI API最开始我的方案特别简单: 12345678d...
