【零基础入门 LLM 开发 · Day 15】:LangChain 注册工具——告别手写 JSON Schema

LangChain工具调用原理与调试实战:从tool_call_id到稳定Agent 工具调用(Tool Calling)是大语言模型连接现实世界的核心机制,其本质是通过结构化协议实现LLM推理能力与外部执行能力的解耦。LangChain将其工程化为标准化接口,涵盖@tool装饰器、Pydantic参数校验、tool_call_id消息绑定等关键组件。该机制显著提升开发效率,但也因抽象层级过高而加剧调试难度——尤其在ID匹配错位、invalid_tool_calls未拦截、流式chunk累积失当等场景下极易失效。本文聚焦真实项目中高频出现的工具注册一致性、消息链路完整性、少样本提示引导等实践 阅读详情

【零基础入门 LLM 开发 · Day 15】:LangChain 注册工具——告别手写 JSON Schema

场景

Day 8-9 用原生 SDK 手写工具说明书:一个 get_weather 就写了二十来行 JSON Schema。工具一多,手写说明书又臭又长,还容易写错字段名。

今天用 LangChain 把这件事变省力,三种姿势逐级进化:手写字典 → Pydantic 模型 → @tool 装饰器。

起步:bind_tools 一行顶一坨

工具说明书还是 Day 8 那套字典,但绑定和调用交给 LangChain:

import os
from dotenv import load_dotenv
from langchain.chat_models import init_chat_model

load_dotenv()
model = init_chat_model(
    model=os.getenv("YUMC_MODEL_NAME"),
    model_provider="openai",
    api_key=os.getenv("YUMC_MODEL_API_KEY"),
    base_url=os.getenv("YUMC_MODEL_BASE_URL"),
)

# 用字典描述工具(和 Day 8 手写的一样)
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "查询指定城市的天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称,如 杭州、北京"}
                },
                "required": ["city"],
            },
        },
    }
]

# bind_tools() 将工具绑定到模型
model_with_tools = model.bind_tools(tools)

response = model_with_tools.invoke("杭州今天天气怎么样?")

if response.tool_calls:
    for tc in response.tool_calls:
        print(f"工具名称:{tc['name']}")
        print(f"参数:{tc['args']}")
        print(f"调用ID:{tc['id']}")

response.tool_calls 是个列表——AI 觉得需要的话会一次请求多个工具调用,别只取第一个。

进阶:Pydantic 模型直接当工具

手写字典的问题:字段名、类型、描述全靠人肉对齐。换成 Pydantic 模型,LangChain 自动帮你生成说明书:

from pydantic import BaseModel, Field


class WeatherInput(BaseModel):
    """查询指定城市的天气情况"""

    city: str = Field(description="城市名称,如 杭州、北京")
    unit: str = Field(
        default="celsius",
        description="温度单位,celsius(摄氏度)或 fahrenheit(华氏度)",
    )


class CalculatorInput(BaseModel):
    """执行数学计算"""

    expression: str = Field(description="要计算的数学表达式,如'(3+5)*2'")


# 传入 Pydantic 模型,LangChain 自动转换为工具描述
model_with_tools = model.bind_tools([WeatherInput, CalculatorInput])

response = model_with_tools.invoke("北京今天多少度?顺便帮我算一下123*456")

print(f"模型请求了{len(response.tool_calls)}个工具调用:")
for tc in response.tool_calls:
    print(f"{tc['name']} ({tc['args']})")

为什么 Pydantic 模型能当工具?

LangChain 拿到对象后自动提取三样东西——和 Day 8 手写的 JSON Schema 是同一个东西,只是框架替你生成:

Pydantic 里的变成说明书里的
类名function.name
docstring("""查询指定城市的天气情况""")function.description
字段类型 + Field(description=...)parameters 的 JSON Schema

更简:@tool 装饰器

普通函数也能注册——函数名、docstring、类型注解就是现成的说明书:

from langchain_core.tools import tool


@tool
def get_location(location: str) -> str:
    """获取指定位置的经纬度"""
    return f"获取{location}的经纬度"


# 和 Pydantic 模型混着用也没问题
model_with_tools = model.bind_tools([WeatherInput, CalculatorInput, get_location])

response = model_with_tools.invoke("北京今天多少度?顺便帮我算一下123*456,经纬度")

三种方式对比

方式工具名描述参数 schema适用场景
bind_tools(字典)手写手写手写和 Day 8 等价,没必要再用
bind_tools(Pydantic)类名docstring字段定义参数结构复杂、需要校验/复用
@tool函数名docstring类型注解最常用,一行搞定

@tool 的本质:LangChain 根据函数签名现场生成一个 Pydantic 模型(get_location.args_schema 可以看),所以后两种方式殊途同归。

和 Day 13 的血缘

with_structured_output(method="function_calling") 的底层就是 bind_tools:Pydantic 模型 → JSON Schema → 发给模型。

  • 注册工具:模型主动"申请"调用,你执行后把结果喂回去(Day 8 流程);
  • 结构化输出:强制模型把你的 Pydantic 模型当工具调用一次,直接拿到参数当结果。

同一套机制,两个用途。学会一个,另一个就是白送。

运行效果

模型请求了3个工具调用:
WeatherInput ({'city': '北京', 'unit': 'celsius'})
CalculatorInput ({'expression': '123*456'})
get_location ({'location': '北京'})

一个问题触发三个工具调用——AI 自己决定"要不要用、用哪几个、传什么参数"。

今日踩坑点

  1. @tools 写成装饰器:from langchain import tools 导入的是模块,模块不能调用,报 TypeError: 'module' object is not callable。要用 from langchain_core.tools import tool 然后 @tool(或者 @tools.tool)。
  2. Field(decription=...) 拼错:Pydantic 不认识的关键字被当"额外参数",只给一条 DeprecationWarning 不报错——结果描述丢了,模型只能瞎猜参数含义,工具质量悄悄下降。警告也要看!
  3. f-string 括号位置:f"{tc['name'] ({tc['args']})}" 会把 tc['name'] 当函数调用(name 后面跟了个括号),报 'str' object is not callable。正确写法 f"{tc['name']} ({tc['args']})"。
  4. Pydantic 类名直接变工具名:WeatherInput 这种名字出现在给模型看的说明书里很怪。@tool 用函数名更自然;坚持用 Pydantic 就把类名起得像工具名。

今日小练习

  1. 必做:用 @tool 写一个 get_current_time(),跑通"现在几点了?"——对比 Day 8 的必做题,感受少写了多少行。
  2. 进阶:print(get_current_time.args_schema),看看 @tool 现场生成的 Pydantic 模型长什么样。
  3. 思考:把 Day 8 手写说明书的工具全部换成 @tool 版本,模型的工具选择行为有变化吗?

明日预告

Day 15:工具又多又杂时,AI 容易选错、token 也贵。学公司设前台——主 Agent 只管转接,子 Agent 各管一摊。


附录:完整练习代码

langchainTest4-tools.py(字典版 bind_tools)

import os
from dotenv import load_dotenv
from langchain.chat_models import init_chat_model

load_dotenv()
model = init_chat_model(
    model=os.getenv("YUMC_MODEL_NAME"),
    model_provider="openai",
    api_key=os.getenv("YUMC_MODEL_API_KEY"),
    base_url=os.getenv("YUMC_MODEL_BASE_URL"),
)

# 用字典描述工具
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "查询指定城市的天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名称,如 杭州、北京"}
                },
                "required": ["city"],
            },
        },
    }
]

# bind_tools() 将工具绑定到模型
model_with_tools = model.bind_tools(tools)

response = model_with_tools.invoke("杭州今天天气怎么样?")

if response.tool_calls:
    print("模型调用了以下工具")
    for tc in response.tool_calls:
        print(f"工具名称:{tc['name']}")
        print(f"参数:{tc['args']}")
        print(f"调用ID:{tc['id']}")
else:
    print(f"模型直接回复:{response.content}")

langchainTest4-tools2.py(Pydantic 模型版)

import os
from dotenv import load_dotenv
from langchain.chat_models import init_chat_model
from pydantic import BaseModel, Field

load_dotenv()
model = init_chat_model(
    model=os.getenv("YUMC_MODEL_NAME"),
    model_provider="openai",
    temperature=0,
    api_key=os.getenv("YUMC_MODEL_API_KEY"),
    base_url=os.getenv("YUMC_MODEL_BASE_URL"),
)


class WeatherInput(BaseModel):
    """查询指定城市的天气情况"""

    city: str = Field(description="城市名称,如 杭州、北京")
    unit: str = Field(
        default="celsius",
        description="温度单位,celsius(摄氏度)或 fahrenheit(华氏度)",
    )


class CalculatorInput(BaseModel):
    """执行数学计算"""

    expression: str = Field(description="要计算的数学表达式,如'(3+5)*2'")


# 传入pydantic 模型,LangChain 自动转换为工具描述
model_with_tools = model.bind_tools([WeatherInput, CalculatorInput])

response = model_with_tools.invoke("北京今天多少度?顺便帮我算一下123*456")

print(f"模型请求了{len(response.tool_calls)}个工具调用:")
for tc in response.tool_calls:
    print(f"{tc['name']} ({tc['args']})")

langchainTest4-tools3.py(@tool 装饰器版)

import os
from dotenv import load_dotenv
from langchain_core.tools import tool
from langchain.chat_models import init_chat_model
from pydantic import BaseModel, Field

load_dotenv()
model = init_chat_model(
    model=os.getenv("YUMC_MODEL_NAME"),
    model_provider="openai",
    temperature=0,
    api_key=os.getenv("YUMC_MODEL_API_KEY"),
    base_url=os.getenv("YUMC_MODEL_BASE_URL"),
)


class WeatherInput(BaseModel):
    """查询指定城市的天气情况"""

    city: str = Field(description="城市名称,如 杭州、北京")
    unit: str = Field(
        default="celsius",
        description="温度单位,celsius(摄氏度)或 fahrenheit(华氏度)",
    )


class CalculatorInput(BaseModel):
    """执行数学计算"""

    expression: str = Field(description="要计算的数学表达式,如'(3+5)*2'")


@tool
def get_location(location: str) -> str:
    """获取指定位置的经纬度"""
    return f"获取{location}的经纬度"


# 传入pydantic 模型,LangChain 自动转换为工具描述
model_with_tools = model.bind_tools([WeatherInput, CalculatorInput, get_location])

response = model_with_tools.invoke("北京今天多少度?顺便帮我算一下123*456,经纬度")

print(f"模型请求了{len(response.tool_calls)}个工具调用:")
for tc in response.tool_calls:
    print(f"{tc['name']} ({tc['args']})")
LangChain V1.0 + Harness工程:从Agent工具调用到TextToSQL落地实践 大模型应用开发中,Agent与工具调用是连接模型能力和业务系统的关键桥梁。LangChain V1.0作为模型调用与流程组装的基础框架,为智能体工具注册、参数校验和结果回传提供了统一接口。而Harness工程则负责为Agent套上可控骨架,涵盖超时、重试、日志与状态管理,确保每一步可观测、可恢复。在TextToSQL场景,模型生成SQL后必须经过语法解析、命令白名单、表名字段校验和资源限制四层防线,再通过只读账号执行,才能真正安全落地。本文结合农业监测项目,详解从环境搭建、最小Agent循环到SQL校验、评 阅读详情

相关推荐

从App到智能体:AI时代应用开发范式转型与LangChain实战

最近,一个观点在技术圈里被反复讨论:“AI将会取代90%的App。” 乍一听,这像是一个博人眼球的标题党,但如果你深入观察近期的技术风向——从各大科技公司All in AI Agent,到开发者工具如Cursor、GitHub Copilot的普及,再到“超级App”概念的重新升温——你会发现,这背后指向的是一场远比“App替代”更深刻的交互范式变革。 这篇文章不打算空谈趋势,而是要回答一个务实的问题: 作为一名开发者,当“AI优先”的浪潮袭来,我们现有的App开发技能、技术栈和产品思维,哪些会失效,哪些会

congju3179的博客 421

LangChain自定义工具开发实战:从BaseTool到StructuredTool

LangChain工具是大模型Agent能力扩展的核心机制,其本质是为LLM提供结构化、可验证、可审计的外部函数调用接口。理解BaseTool的底层控制权、Tool的函数封装逻辑、StructuredTool的Pydantic强校验能力,是构建稳定AI应用的关键技术基础。尤其在企业级场景中,需兼顾输入验证、超时熔断、错误降级与审计日志等工程要求。本文聚焦生产环境高频需求——如天气查询、知识库检索、贷款试算等典型工具的落地实现,详解如何通过args_schema定义、description优化、异常拦截与缓存

weixin_33733810的博客 385

AI编排实战:MuleSoft+LangChain构建企业级LLM集成架构

AI编排(AI Orchestration)是企业将大语言模型(LLM)深度融入现有IT系统的关键范式,其核心在于分层解耦——用成熟企业集成平台(如MuleSoft)处理协议适配、数据清洗、安全治理与运维保障等‘企业语法’问题,再由LangChain专注语义理解、提示工程与动态模型调度等‘AI语义’任务。这种架构规避了直连风险、满足GDPR/CCPA等合规要求,并支撑SAP、Salesforce、Oracle等遗留系统的稳定对接。本文基于医疗器械、银行、零售等真实客户案例,详解如何通过职责分离实现高可用、可

weixin_34034261的博客 413

记录下学习agent应用开发的第11天(Langchain框架)

原手写代码段要通过if来匹配工具函数名,而Langchain框架在内部维护了一个注册表,可以自动按函数名查找执行,而且添加新工具函数时不需要去改动代码,注册表会自动更新。同时,Langchain可以自己管理发送给llm的历史会话记录message,而手写的则要手动上传和维护。(各位访问大哥能否留一些宝贵建议给小弟,没人的话就当个人日常blog)为了方便理解底层原理,前面学习过程中的功能性代码大部分都是自己手写,出于便捷,今天我采用Langchain框架来代替那些复用率高的代码段。

2301_80428473的博客 369

普通人三个月AI实战路径:Python+RAG+LlamaIndex零基础入门

RAG(检索增强生成)是当前最实用的大模型应用范式,其核心在于将私有数据与大语言模型能力安全、可控地结合。它不依赖模型训练,而是通过数据向量化、语义检索与提示工程三步实现知识调用。技术价值在于降低AI落地门槛,让非算法背景者也能构建企业知识库、智能客服等真实系统。典型应用场景包括内部文档问答、销售支持、合规查询与自动化报告生成。本文聚焦2026年已验证的轻量级技术栈:以Python为胶水语言,Chroma为本地向量数据库,LlamaIndex为RAG主框架,全程离线可运行,无需GPU与云服务。

dicha7140的博客 436

企业级AI编排:MuleSoft与LangChain分层协作实战

AI编排(AI Orchestration)是连接大模型能力与企业现有数字基础设施的关键技术,其核心在于解决数据孤岛、权限割裂、流程断点、安全合规与系统治理五大挑战。它并非替代LLM或Prompt工程,而是构建可审计、可追溯、可治理的智能调度中枢,通过标准化协议(如REST)、企业级中间件(如MuleSoft)与AI微服务(如LangChain)的分层协同,实现数据接入→上下文注入→模型路由→结果封装→系统集成的端到端闭环。该模式已在金融、制造、医疗等强监管行业验证,支撑CRM智能助手、设备预测维护、临床患

weixin_33769125的博客 346

AI Agent Skill Day 3:Tool Use技能:工具使用能力的封装与集成

Tool Use技能是指将外部工具(包括API、CLI命令、数据库操作、自定义函数等)抽象为具有统一描述、输入输出规范和执行逻辑的“工具对象”,供大语言模型(LLM)在推理过程中动态选择并调用的能力。扩展Agent能力边界:使LLM能访问实时数据、执行计算或操作系统资源。提升任务完成率:对于需要外部信息或操作的任务(如“今天北京天气如何?”),仅靠模型内部知识无法准确回答,必须依赖工具。标准化集成接口:通过统一的Tool Schema,支持多模型(OpenAI、Claude、通义千问等)无缝对接。

在未来等你的专栏 973

LangChain Tools、MCP Tools与Function Calling 三者分工解析

大模型智能体(Agent)中的工具调用能力,本质是‘意图理解→结构化决策→标准化执行’的技术闭环。Function Calling 是模型内置的结构化意图解析引擎,决定能否识别并生成工具调用指令;LangChain Tools 是面向开发者的工具封装范式,解决多源异构系统在统一框架下的可调度性问题;MCP Tools 则定义了模型与工具间通用的通信契约,确保参数传递、错误处理与流式响应的跨平台一致性。三者分属能力层、工程层与协议层,不可替代亦不可混淆。本文结合7个生产级落地案例,深入剖析其协同机制与典型误用

weixin_34075268的博客 362

Langchain技能系统开发实战与优化指南

大语言模型应用开发中,模块化技能系统是实现复杂AI代理的关键技术。通过将功能封装为标准化Skills,开发者可以构建具备自然语言理解能力的智能工作流。其技术原理基于元数据描述、执行逻辑封装和验证规则定义三要素,相比传统函数库增加了意图识别和自动编排能力。在工程实践中,这种架构显著提升了第三方API集成效率和业务逻辑复用性,特别适用于客服机器人、智能助手等需要多步骤协作的场景。以Langchain框架为例,其Skills系统支持Python/JavaScript实现,配合TypeScript类型提示可增强可维

weixin_30562507的博客 440

AI应用开发实战:从LLM、Function Call到Agent与Workflow的完整技术栈解析

在人工智能应用开发领域,大语言模型(LLM)作为核心推理引擎,通过函数调用(Function Call)机制与外部世界交互,实现了从理解到执行的闭环。这一技术组合的价值在于将LLM的认知能力转化为可落地的自动化解决方案,广泛应用于智能客服、内容生成、数据分析等场景。在此基础上,开发者通过封装可复用的技能(Skill)和构建具备自主规划能力的智能体(Agent),进一步提升了系统的模块化和智能化水平。而工作流(Workflow)则为流程固定的复杂任务提供了可视化的编排能力。本文以构建一个“智能旅行规划助手”为

weixin_34175509的博客 445

大模型原生能力崛起:LLM编排中间件为何正在归零

LLM编排中间件(如LangChain、LlamaIndex)曾是构建RAG与Agent系统的核心抽象层,其本质是弥补早期大模型在长上下文理解、工具调用鲁棒性及多跳推理一致性上的能力缺口。随着Claude 3.5 Sonnet等新一代模型在原生上下文稳定性、强类型函数调用协议和隐式推理路径规划三方面实现质变,该中间层正从‘必要协作者’退化为‘故障引入源’。技术价值上,它不再提供不可替代的语义增强或流程保障;工程实践中,其高延迟、高配置熵与低功能复用率已导致TCO显著倒挂。当前主流场景——尤其是客服问答、报告

470

LangChain Agent进阶:Function Calling与自动Tool注册实战指南

在大语言模型(LLM)应用开发中,如何让AI智能体(Agent)精准、可靠地调用外部工具是核心挑战。Function Calling作为一种标准化协议,通过JSON Schema明确定义工具的接口契约,使LLM能够结构化地理解和调用函数,显著提升了工具调用的准确性和稳定性。这一技术为构建复杂、实用的AI系统提供了坚实基础,广泛应用于客服自动化、数据分析、智能助手等场景。结合自动Tool注册机制,开发者无需手动配置,系统可动态发现并集成新功能,实现了从“硬编码工具箱”到“开放能力平台”的架构升级。本文以Lan

weixin_34079177的博客 301

OpenHarmony实战开发-如何实现文件分布式同步编辑

在分布式文件场景中,分布式设备管理包含了分布式设备搜索、分布式设备列表弹窗、远端设备拉起三部分。首先在分布式组网内搜索设备,然后把设备展示到分布式设备列表弹窗中,最后根据用户的选择拉起远端设备。两台设备组网的分布式场景是工作中常常需要的。这样的分布式场景有助于加快工作效率,减少工作中的冗余,本例将为大家介绍如何实现上述功能。​ (2)订阅分布式数据变化:通过this.distributedObject.on(‘status’, this.statusCallback)监听分布式数据对象的变更。

2401_82546228的博客 754

LangChain4j 中文文档

欢迎!LangChain4j 的目标是简化将大语言模型集成到 Java 应用中的过程。它的实现方式如下:统一 API: 大语言模型提供商(如 OpenAI 或 Google Vertex AI)和嵌入(向量)存储(如 Pinecone 或 Milvus)都使用专有 API。LangChain4j 提供统一 API,避免你为每个提供商或存储分别学习和实现特定 API。想尝试不同的大语言模型或嵌入存储时,你可以轻松切换,而无需重写代码。LangChain4j 目前支持 20+ 个主流大语言模型提供商 和 30+

qq_43356685的博客 989

虚幻引擎5 AR开发教程02:构建和测试AR Android App

在本教程中,我们将学习如何在虚幻引擎 5 上构建和测试 AR 安卓应用。

mopanchun的博客 2650

使用.NET 免费开源包ViewFaceCore做一个人脸识别并注册的功能,没有比我更全的

本文介绍了一个基于WinForm的免费人脸识别系统实现方案。系统使用AForge和ViewFaceCore库,支持从USB或电脑自带摄像头采集图像,具备人脸注册和快速识别功能。硬件方面仅需普通摄像头,软件依赖多个NuGet包(如AForge.Video、ViewFaceCore等)。界面包含视频显示、图像预览和功能按钮控件,后台采用SQLServer存储用户面部特征数据。核心代码展示了人脸检测、特征提取和多线程处理逻辑,通过ViewFaceCore实现高效识别。系统具有识别速度快、准确率高的特点,适合Win

一个靠“吃代码”长大的程序猿,专治各种“Bug 饥饿症”。 817

大模型中间层蒸发:从LangChain到Claude原生能力的架构减法

在大语言模型工程实践中,‘中间层’指代连接应用逻辑与模型能力的抽象封装,如语义解析、工具调度和状态编排。其演进本质是模型原生能力(如结构化输出、流式工具调用、上下文锚点)对传统胶水代码的持续替代。随着Anthropic Claude 3.5等新一代模型提供JSON Schema强制输出、双向流式tool use、step anchoring等能力,中间层的单位价值密度急剧坍缩——不再被‘替换’,而是被‘蒸发’:删代码反而提升性能、降低错误率与运维成本。这一趋势标志着AI工程范式正从‘封装驱动’转向‘原生驱动

weixin_30599769的博客 308

MagicDraw小白必看:BDD图中模块的5种属性详解(含SysML v1.6最新端口配置指南)

本文面向MagicDraw初学者,详细解析SysML BDD图中模块的五种核心结构属性,包括组成部分、引用、值、约束属性及端口。重点阐述了SysML v1.6中端口设计的范式转移,对比了完整端口与代理端口的区别与应用场景,并通过实战案例指导如何利用代理端口进行清晰的接口定义与系统架构设计。

rum55的博客 374

springboot+langchain4jDay6-Day11后续学习计划

springboot+langchain4jDay6-Day11后续学习计划

qq_44909430的博客 78

微信小程序 - 实现Java微信支付退款功能以及退款流程,微信小程序前端+java后端完整示例源码,微信小程序退款功能详解,小程序订单申请退款和退款回调方法、查询退款等(新版微信支付,详细示例代码)

微信小程序开发-微信支付退款功能以及退款回调方法,微信支付退款API详解,微信小程序支付V3(支付、退款)Java实现微信小程序开发 小程序支付开发-小程序退款功能,微信小程序小程序和公众号 退款功能教程(含申请退款和退款回调,退款回调地址在商户后台配置或者代码自定义)最新版微信小程序支付,退款问题,小程序支付和退款功能详解,小程序申请退款,小程序处理退款,微信小程序支付与退款java,微信小程序退款及回调,JAVA实现微信小程序支付退款功能,退款api调用报错,如何解决退款申请无响应,如何用实现小程序订单

🏆 前端领域优质创作者 4159

Vue3 - 手机移动端H5网页强力解决弹起软键盘后页面被挤压变形或页面整体上移问题,点击input输入框键盘弹出底部被上推往上顶遮挡及各种问题(兼容安卓苹果ios手机,微信公众号网页微信内置浏览器)

vue3,h5网页,input输入框组件,vue3 h5软键盘弹出,vue3输入框,键盘弹起时页面整体上移问题,uni,H5页面,解决软键盘弹起页面被挤压、被往顶的问题,解决vue3输入框,键盘弹起时页面整体上移问题,vue3调用手机系统软键盘,页面窗口被顶起,布局定位失效,解决VUE3软键盘弹起导致页面fixed定位元素被顶上去,输入法软键盘弹起,窗口顶起,变形解决办法,Vue中input组件在IOS设备上弹出软键盘时页面整体上移问题的解决方案,以及input组件聚焦后弹出软键盘固定在,Vue3软键盘把界

🏆 前端领域优质创作者 1万+

AI Agent零基础入门:从核心概念到实战,掌握工具调用与日志分析

大语言模型的出现让计算机从被动问答走向主动任务执行。理解AI Agent的核心在于掌握工具调用机制、记忆管理和规划拆解,而Function Calling正是连接模型与外部系统的关键桥梁。通过将搜索、数据库查询等能力封装为可调用工具,Agent能够在动态循环中完成复杂业务目标,例如基于Elasticsearch REST API的日志智能分析场景。文章从概念原理出发,结合最小可运行代码,剖析Agent内部数据流,并对比主流框架选型,帮助开发者快速构建生产级应用。

weixin_34417183的博客 401

*手把手教你学 Simulink——压缩机用永磁同步电机无位置传感器 I‑F 启动(Sensorless I/F Starting)控制仿真

dtdi^α​​zα​e^α​ω^θ^​=Ls​1​(−Rs​i^α​+usα​−zα​)=K⋅sign(i^α​−iα​)=zα​+Kpll​⋅(i^α​−iα​)同理 β=PLL(e^α​,e^β​)=∫ω^dt​。给定 Id​=Iset​, Iq​=f(θopen​)按设定 fstart​(t)Iq​=k⋅sin(θopen​)投影 → 恒幅 Is​=Id2​+Iq2​​。​ 将 Id​,Iq​→ Iα​,Iβ​→ SVPWM。Id​=Ialign​(弱对齐 → 防抖动)

amy_mhd的博客 39

Tool Calling 层蒸发:LLM 应用架构的协议下沉革命

Tool Calling 是大语言模型与外部系统交互的核心协议机制,其本质是定义模型如何理解、调用和解析工具函数的语义契约。传统实现依赖应用层手动维护 JSON Schema、JSON 解析、错误恢复与状态编排,导致高延迟、低鲁棒性与代码膨胀。随着 Anthropic 等厂商将 tool calling 能力从应用层下沉至推理运行时(Runtime),Schema 编译、参数校验、结构化响应、自动重试与声明式编排等能力被系统级接管,显著压缩抽象层级。这一变化并非功能削弱,而是工程范式的升级:开发者从胶水代码

weixin_34090562的博客 386

​网格划分理论:CFD理论67 网格划分-三大理论问题_哔哩哔哩_bilibili传统解释非结构化网格是不对的——计算传热学大叔专题讨论2--CFD网格类型_哔哩哔哩_bilibili

传统解释非结构化网格是不对的——计算传热学大叔。fluent计算理论和离散方法原理视频推荐。

qq_15963745的博客 183

IMSL CNL 7.0.0 (x86-64)Crack

IMSL CNL 7.0.0 (x86-64)Crack intel的算法库破解文件,这是C++版本的破解文件

上一篇: 【零基础入门 LLM 开发 · Day 14】:让 AI 输出结构化 JSON
下一篇: Apollo 配置中心入门:一所“小学校“读懂 Portal、Meta Server、Config Service
IT_Octopus
博客等级 码龄8年 1727粉丝 303原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

IT_Octopus

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值