AI工具与应用

前言：为什么要把工具调用放到本地 过去两年，很多团队在做 AI 应用时都会先接一个云端大模型 API：把用户问题发出去，拿回一段文本，再在业务系统里解析。这个方案上手快，但一旦进入现场环境，问题很快就会浮出来：工厂内网不能直接访问公网，设备日志里可能含有客户数据，弱网场景下延迟不稳定，云端调用成本也不容易预估。更麻烦的是，一些“看起来只是聊天”的需求，本质上并不是聊天，而是让模型根据自然语言选择工具、填好参数、调用接口、再把结果解释给用户。比如“帮我查一下 3 号产线最近 10 分钟的温度异常”，模型需要决定调用 query_metric，参数包含产线编号、时间窗口和指标名；再比如“把这台边缘网关切到低功耗模式”，模型需要识别这是一个有副作用的动作，必须做权限确认和参数校验。 这类场景如果完全依赖云端，系统链路会变长，失败点会变多。相反，如果把小到中等规模的语言模型以 GGUF 格式部署在本地，通过 llama.cpp 提供推理服务，再在旁边放一个严格的 Function Calling 网关，就能得到一个更可控的架构：模型负责“理解意图”和“生成结构化调用计划”，网关负责“验证、授权、执行、审计”。这种分工非常适合工控边缘盒子、门店私有服务器、实验室内网助手、个人知识库一体机等场景。 本文不是简单介绍如何运行 ./llama-cli -m model.gguf，而是围绕一个可落地的本地工具调用网关展开：如何选择模型和量化格式，如何设计提示模板让模型稳定输出 JSON，如何用 Python 写一个流式调用编排器，如何处理超时、重试、权限和审计，最后如何把它部署到一台资源有限的边缘设备上。文章中的代码尽量保持小而完整，方便你按自己的业务接口替换。 一、整体架构：模型不要直接碰业务系统 一个常见误区是：既然模型可以生成函数名和参数，那就让模型输出什么就执行什么。这个做法在演示里很顺，但在生产环境里非常危险。语言模型是概率系统，它可能拼错函数名，可能把用户随口说的一句话理解成执行命令，也可能在上下文受到污染时生成越权参数。正确的做法是把模型放在“建议者”的位置，业务网关才是“裁判”和“执行者”。 本文采用的架构由五层组成： 客户端层：Web UI、命令行、企业微信机器人、串口控制台都可以作为入口。它们只负责收集用户输入和展示结果。 会话编排层：维护上下文、拼接系统提示词、把可用工具列表注入给模型，并解析模型输出。 本地推理层：llama.cpp 或 llama-server 加载 GGUF 模型，提供 OpenAI 兼容接口或原生命令行接口。 工具安全层：根据白名单、参数 schema、用户权限、二次确认规则决定是否允许执行。 业务适配层：真正访问数据库、设备驱动、HTTP API、MQTT、Modbus、文件系统等外部资源。 这个拆分的关键点是：模型输出永远只是“候选动作”，不能直接等价于“已授权动作”。即使模型说要调用 set_relay_state(channel=1, state="on")，网关也要检查当前用户是否有控制继电器的权限，channel 是否在允许范围内，动作是否需要二次确认，执行结果是否要写审计日志。 下面是最小化的工具描述格式。它不依赖某个云厂商的 Function Calling 协议，但足够表达函数名、用途、参数类型和安全属性。 { "name": "query_metric", "description": "查询某条产线或设备在指定时间窗口内的指标数据", "side_effect": false, "parameters": { "type": "object", "required": ["device", "metric", "window_minutes"], "properties": { "device": {"type": "string", "description": "设备或产线编号，例如 line-3"}, "metric": {"type": "string", "enum": ["temperature", "humidity", "current"]}, "window_minutes": {"type": "integer", "minimum": 1, "maximum": 1440} } } } 这里的 side_effect 很重要。查询类工具通常可以直接执行，控制类、写入类、删除类工具则应默认要求确认。很多事故不是模型“不聪明”，而是系统把模型的建议当成了不可质疑的命令。 ...

前言：为什么本地推理服务会成为团队的基础设施 过去两年，很多团队已经把大模型从“能聊几句的玩具”推进到了真正的业务链路里：客服质检、代码助手、文档检索、知识库问答、BI 分析、研发自动化、设备运维助手，场景越来越具体，调用量也越来越稳定。这个阶段最容易遇到的矛盾是：单次体验看起来不错，但一旦多人同时使用，延迟、成本、限流、数据安全、模型版本控制都会变成工程问题。 如果只是给个人写一个脚本，直接调用云端 API 最省事；如果团队已经有私有数据、内网系统、稳定 QPS、固定模型和合规要求，本地推理服务就值得认真建设。它不是为了“完全替代云服务”，而是为了把一部分可控、可预测、可缓存、可审计的请求沉到自己的基础设施里：模型版本自己定，日志留在内网，显卡利用率自己优化，业务峰值也可以通过队列和降级策略来处理。 在这一类方案中，vLLM 是目前很常见的选择。它的优势并不是“启动一个模型”这么简单，而是围绕大模型在线推理做了系统级优化：OpenAI 兼容 API、连续批处理、PagedAttention、张量并行、流式输出、Prometheus 指标、较成熟的服务端参数。对于很多团队来说，vLLM 正好站在“研究代码”和“生产服务”之间：比手写 Transformers server 更接近生产，比完整平台又轻量许多。 本文不打算只列一组启动命令。我们会按工程落地的顺序讲清楚：怎样选择模型与硬件，如何启动 OpenAI 兼容服务，为什么 PagedAttention 对吞吐和显存很关键，压测时应该看哪些指标，常见参数如何调，最后再补上网关、监控、systemd、Docker Compose 和故障排查。读完以后，你应该能搭出一个可用的内网推理服务，并知道下一步该怎么把它调稳。 一、先把目标说清楚：不是“跑起来”，而是“稳定地跑” 很多本地大模型项目的第一步都很顺利：下载模型，装依赖，跑一个 demo，看见回复，大家都很兴奋。真正的问题通常在第二周出现：同事开始接入，输入长度不一样，输出长度不一样，有人跑 8K 上下文，有人开流式输出，还有人批量生成摘要。GPU 显存看起来还剩不少，但请求排队越来越长；某些请求首 token 等待十几秒；升级模型后，原来的参数突然不合适；日志里偶尔出现 CUDA OOM，却很难复现。 所以在搭 vLLM 前，建议先明确四个目标。 第一，服务对象是谁。是给内部研发少量调用，还是给业务系统持续调用？如果只是研发使用，优先保证灵活性；如果是业务链路，优先保证限流、监控、灰度和回滚。 第二，模型规模是多少。7B、14B、32B、70B 对显存和并行方式的要求完全不同。模型越大，单卡部署越困难，吞吐和延迟的权衡也越明显。不要只看参数量，还要看量化格式、上下文长度、是否需要多 LoRA、是否要跑 embedding 或 rerank。 第三，请求形态是什么。短问短答、长文摘要、代码生成、Agent 工具调用的 token 分布差别很大。Prefill 阶段主要处理输入 token，Decode 阶段逐 token 生成输出；输入特别长会拉高首 token 延迟，输出特别长会占用更久的 KV Cache。压测时如果只用“你好”这种请求，结果没有参考价值。 第四，接受什么样的服务等级。比如 P95 首 token 延迟小于 3 秒，平均输出速度大于每秒 40 token，排队超过 30 秒直接返回忙碌，单 GPU 显存利用率维持在 85% 左右。这些指标越早写下来，后面调参越不会靠感觉。 ...

前言 2024 年被称为 AI Agent 元年。从早期的 AutoGPT 到后来的 CrewAI、AutoGen，再到如今的 LangGraph，多智能体系统的开发框架经历了快速的迭代。我在 2023 年第一次尝试用 AutoGPT 构建自动化任务系统时，整个流程充满了不确定性：Agent 经常"走神"、任务执行到一半就偏离主题、错误处理几乎为零。 到了 2024 年中，我开始使用 LangGraph，这种基于状态机的设计思路彻底改变了我对 Agent 开发的认知。与传统的"让 LLM 自由发挥"不同，LangGraph 让你可以： 精确控制 Agent 的执行路径 在节点间共享完整的状态信息 实现条件分支、循环、重试等复杂逻辑 可视化整个工作流的执行过程 过去半年里，我用 LangGraph 构建了十几个生产级别的多智能体系统：从自动化代码审查工具到技术文档生成器，再到市场研究助理。这些系统的共同特点是：稳定性高、可观测性强、出错时可以优雅回滚。 这篇文章是我对 LangGraph 多智能体开发的系统性总结。从最基础的 State 定义，到复杂的多 Agent 协作模式，再到生产环境的部署优化，我会带你一步步构建一个完整的、可运行的多智能体工作流系统。 一、为什么选择 LangGraph？ 在深入技术细节之前，我们需要先回答一个问题：市面上有这么多多智能体框架，为什么我最终选择了 LangGraph？ 1.1 传统 Agent 框架的痛点 让我先分享几个真实的"踩坑"经历： 故事一：CrewAI 的"集体幻觉" 去年用 CrewAI 做一个市场分析系统，三个 Agent（研究员、分析师、写作者）协作。一开始效果很好，但当任务涉及需要精确数字的财报分析时，我发现三个 Agent 会"互相说服"，最终产出完全虚构的财务数据。更糟糕的是，整个执行过程是一个黑盒，我无法定位是哪个环节出了问题。 故事二：AutoGen 的无限循环 在用 AutoGen 构建代码生成系统时，我经常遇到"代码评审 Agent"和"代码编写 Agent"陷入无限争论的情况。一个说"这个代码有性能问题"，另一个反驳"这是在可读性和性能之间的权衡"，几十个来回后还在原地踏步。AutoGen 缺乏一个明确的"终止条件"机制。 故事三：纯 LangChain 的复杂度 ...

前言 2023 年被称为「大模型元年」，但到了 2026 年，真正的革命才刚刚开始——不是在云端，而是在你的本地机器上。 如果你还在依赖 OpenAI API 做所有 AI 相关的工作，那你可能已经错过了一个重要的趋势：本地大模型正在以惊人的速度追赶云端模型的能力。今天，一个 7B 参数的量化模型在中端消费级显卡上就能跑出接近 GPT-3.5 的效果，而 70B 参数的模型在高端显卡上的表现甚至能在某些任务上超越 GPT-4。 更重要的是，本地部署带来了三个无可替代的优势：绝对的数据隐私、零 API 调用成本、完全的控制权。对于企业来说，这意味着敏感的内部文档永远不会离开公司内网；对于个人开发者来说，这意味着你可以 24/7 不间断地运行 AI 工作流而不用担心账单爆炸。 这篇文章是我过去两年部署本地大模型的经验总结。从最基础的 Ollama 一键部署，到深入 llama.cpp 的性能优化，再到企业级的 API 服务架构，我会把每一个踩过的坑、每一个优化技巧都毫无保留地分享给你。 一、为什么要部署本地大模型？ 在谈论技术细节之前，让我们先回答一个根本问题：既然 OpenAI、Anthropic 这些公司已经提供了这么好用的 API，为什么还要费心自己部署本地大模型？ 我给出的答案是四个「自由」。 1. 隐私自由 这是最核心的理由。当你把数据发送给 OpenAI API 时，你实际上放弃了对这些数据的控制权。虽然 OpenAI 的服务条款说不会用用户数据训练模型，但谁也无法保证 100% 的安全——更不用说政府监管、数据泄露、内部人员滥用这些潜在风险。 而本地部署意味着： 你的代码永远不会离开公司内网 客户的敏感数据永远在你的掌控之中 内部知识库的问答不会有任何泄露风险 我有一个朋友在金融公司工作，他们的合规部门绝对不允许任何客户数据出现在第三方 API 中。最后他们用本地部署的 Qwen-72B 搭建了内部的文档问答系统，成本只有云端方案的 1/10，安全性却高了几个数量级。 2. 成本自由 API 调用的成本看起来很低——每 1K tokens 几美分，但当你真的开始大规模使用时，账单会让你大吃一惊。 我做过一个简单的计算：如果一个开发团队有 10 个人，每人每天用 AI 辅助编程 4 小时，平均每 10 秒生成 100 tokens，那么一个月的 API 费用大概是： ...

前言 在大语言模型已经成为日常开发工具的今天，很多人都有过这样的经历：同样的问题，你问出来得到的是敷衍的回答，别人问出来却是条理清晰、质量极高的专业输出；你写的 Prompt 让模型频频犯错，高手写的 Prompt 却能让模型表现出专家级的能力。 这中间的差距，就是 Prompt Engineering（提示工程）。 很多人对 Prompt Engineering 存在误解，认为这不过是"话术技巧"，是"哄骗 AI 的小把戏"，只要模型足够强大，Prompt 就不重要了。但事实恰恰相反：模型越强大，Prompt 的重要性就越高——因为模型的能力边界被极大拓宽，如何引导这些能力就成了决定输出质量的关键因素。 从 GPT-3 时代简单的 Zero-Shot 提问，到如今基于 Agent 的多轮反思、工具调用、结构化输出，Prompt Engineering 已经发展成了一门拥有完整理论体系和实践方法论的工程学科。一个好的 Prompt 工程师，能够让模型在相同参数下，将任务完成率从 50% 提升到 95% 以上，这其中的价值不言而喻。 本文将从零开始，系统地讲解 Prompt Engineering 的每一个核心技术。我们不仅会讲解理论，更会提供大量可直接复用的 Prompt 模板、代码示例和调优策略。无论你是刚开始接触 LLM 的新手，还是希望进一步提升 Prompt 水平的开发者，相信这篇文章都能给你带来实质性的帮助。 一、为什么 Prompt Engineering 如此重要？ 在深入具体技术之前，我们首先要理解：为什么 Prompt Engineering 值得我们花时间去学习？ 1.1 大语言模型的工作本质 大语言模型的核心能力是"预测下一个 token"。给定一段文本，模型会根据它在海量训练数据中学到的统计规律，计算出最可能出现的下一个词。这个看似简单的机制，在模型规模足够大时，涌现出了惊人的推理能力。 但这里有一个关键问题：模型的"智能"是被动触发的，它不会主动去做你没有明确要求它做的事情。 举个简单的例子，如果你问： 1 7 × 2 4 等 于 多 少 ？ 模型可能会直接给出一个错误答案（比如 398），因为它在"快速预测"模式下，倾向于给出看似合理的数字。但如果你换一种问法： ...

前言 2023 年被称为"大模型元年"，ChatGPT 的横空出世让全世界见识到了大语言模型的惊人能力。然而，当企业真正尝试将 LLM 落地到业务场景时，很快就遇到了三座大山：知识过时、幻觉严重、无法与内部系统集成。 于是，RAG（检索增强生成）应运而生——通过将外部知识库的内容检索出来，与用户查询一起送入 LLM，既解决了知识时效性问题，又能在一定程度上减少幻觉。一夜之间，几乎所有的 AI 应用都声称"我们用了 RAG"。 但好景不长。随着业务复杂度的提升，开发者们发现 RAG 也有明显的天花板： 检索准确率的瓶颈：无论怎么优化分块策略、嵌入模型、重排序，总有 20%-30% 的查询无法检索到正确的上下文 无法处理多步任务：“帮我分析上个月的销售数据并生成图表"这种需要多步骤操作的请求，RAG 根本无从下手 缺乏状态管理：复杂对话中，上下文丢失、记忆混乱的问题时有发生 工具集成困难：想要调用数据库、API、代码解释器时，RAG 架构显得力不从心 正是在这样的背景下，LLM Agent 开始走进人们的视野。与 RAG 相比，Agent 的核心突破在于：从被动的"检索-回答"模式，转变为主动的"感知-规划-行动-反思"循环。一个优秀的 Agent 不仅能回答问题，还能分解目标、调用工具、执行任务、修正错误，最终完成复杂的工作流。 本文将带你系统性地了解从 RAG 到 Agent 的完整演进路径，从基础概念到架构设计，从代码实现到性能优化，最后给出企业级落地的最佳实践。无论你是正在考虑从 RAG 升级到 Agent，还是想要从零构建一套 LLM 应用体系，这篇文章都将为你提供一份可操作的实战指南。 一、RAG 的三代演进史 1.1 Naive RAG：最朴素的起点 几乎所有开发者接触 RAG，都是从"三段式"架构开始的： 索引阶段：文档加载 → 文档分割 → 向量化 → 存入向量数据库 检索阶段：用户查询向量化 → 相似度搜索 → 返回 Top-K 相关文档 生成阶段：查询 + 上下文 → Prompt Engineering → LLM 生成答案 ...

前言 2026 年，AI Agent 的发展已经进入了一个全新的阶段。从早期的单轮对话，到如今能够自主完成复杂任务的智能体，AI 的能力边界正在被不断拓展。然而，在构建真正实用的 AI Agent 时，我们依然面临着一个核心难题：如何让大语言模型安全、高效地与外部世界进行交互？ 传统的 Agent 框架如 LangChain、AutoGPT 等虽然提供了工具调用的能力，但它们普遍存在几个致命问题：工具定义分散、权限管理混乱、不同客户端之间无法复用、安全性难以保障。当你为 Claude Desktop 开发了一个文件操作工具后，想要在 Cursor 或 Cline 中复用几乎不可能，一切都要从头开始。这种碎片化的开发生态严重制约了 Agent 技术的普及。 正是在这样的背景下，Anthropic 提出了 MCP（Model Context Protocol）——一个开放的、标准化的协议，旨在彻底解决 AI 工具生态的碎片化问题。MCP 定义了一套统一的接口规范，使得任何遵循该协议的工具服务器都能被所有兼容的 LLM 客户端无缝使用。这就像是为 AI 世界建立了一个通用的"插座标准"，从此电器不再需要特制插头。 本文将从底层原理出发，带你深入理解 MCP 的设计哲学和技术架构，通过完整的代码示例，手把手教你构建生产级别的 MCP 服务器。无论你是想要为自己的开发环境增强 AI 能力，还是想要构建企业级的 Agent 平台，这篇文章都会为你提供完整的解决方案。 一、为什么我们需要 MCP？ 在深入技术细节之前，让我们先回答一个根本问题：现有的工具调用方案到底出了什么问题？为什么我们需要一个全新的协议？ 1.1 传统工具调用的痛点 让我们以最常见的场景为例：你想要让 AI 助手帮你读取本地文件、执行终端命令、查询数据库。在没有 MCP 的时代，你需要怎么做？ 如果你使用 Claude Desktop，你需要编写它特定格式的工具定义；如果你切换到 Cursor，又要重写一遍；如果是 VS Code 的其他 AI 插件，可能又是完全不同的格式。每换一个客户端，工具就要重新开发一次。 更糟糕的是安全问题。大多数工具调用方案都是"全有或全无"的——AI 要么拥有完整的文件系统访问权限，要么什么都做不了。你无法精细地控制它只能读取某个特定目录，只能执行某些白名单内的命令。 最后是可维护性问题。当你的工具逻辑更新时，你需要在所有客户端中同步更新，这在团队协作场景下几乎是不可行的。 1.2 MCP 的设计目标 MCP 的诞生正是为了解决上述所有痛点，它的核心设计目标包括： ...

前言 在大语言模型飞速发展的今天，单纯的问答已经远不能满足复杂场景的需求。AI Agent 作为一种能够自主理解任务、制定计划、调用工具并完成执行的智能体，正在成为下一代 AI 应用的核心形态。从最早的 AutoGPT 引发轰动，到如今 LangChain、CrewAI 等框架日趋成熟，AI Agent 的落地应用正在从概念验证走向生产环境。 然而，真正将 AI Agent 应用到实际工作流中，远不止是调用几个 API 那么简单。如何设计合理的 Agent 架构？如何处理任务分解与执行中的不确定性？如何保证工具调用的可靠性？如何在多 Agent 协作中避免冲突与死锁？这些都是每个开发者在构建生产级 Agent 系统时必须面对的问题。 本文将从实际应用出发，系统介绍 AI Agent 的工作流设计方法论，结合大量实战代码，带你从零构建一个能够完成复杂任务的自动化 Agent 系统。无论你是想在个人项目中引入 AI 自动化，还是在企业中落地 Agent 应用，本文都能为你提供可直接复用的思路与代码。 一、AI Agent 的核心设计理念 1.1 什么是真正的 Agent？ 很多人对 AI Agent 的理解停留在"能调用工具的大模型"，但这只是最表层的特征。一个完整的 Agent 应该具备以下四个核心能力： 自主规划能力：面对模糊的任务描述，能够将其分解为清晰的执行步骤，并动态调整计划。这是 Agent 与普通脚本最大的区别——脚本按固定流程执行，而 Agent 能根据实际情况动态决策。 工具使用能力：根据任务需要，自主选择并调用合适的工具，包括代码执行、网络搜索、API 调用、文件操作等。这是 Agent 突破大模型知识边界的关键。 记忆与反思能力：能够记住之前的执行结果，从中学习并调整后续策略。反思机制让 Agent 能够从失败中恢复，不断优化执行路径。 多轮迭代能力：一次执行往往不能得到完美结果，Agent 需要具备自我评估和迭代改进的能力，直到达到任务目标。 这四个能力层层递进，共同构成了 Agent 的智能基础。缺少任何一环，都只能算是"半成品"的 Agent。 1.2 ReAct 框架：思考与行动的循环 目前主流的 Agent 实现大多基于 ReAct（Reasoning + Acting）框架，其核心思想是让大模型在思考和行动之间交替进行，形成"思考-行动-观察-再思考"的循环。 ...