AI Agent从无到有22: 理解大模型上下文窗口与Token管理实战

Token与上下文:大模型成本控制的底层逻辑 Token是大语言模型处理文本的基本语义单元,源于BPE等子词算法,而非简单字符或单词;其数量直接影响API调用成本与推理效率。上下文窗口则代表模型单次推理可关注的token上限,但并非越大越好——受注意力衰减、计算复杂度与响应延迟制约。理解token构成(如标点、代码符号、中英文差异)和上下文有效利用率,是实现精准计费、提示词优化与长文本处理的前提。本文结合实测数据与工程实践,解析token计量原理、上下文注意力机制及主流计费模型差异,为开发者提供可落地的成本效能平衡方法。 阅读详情

纲要

  • 上下文窗口的定义与边界
  • Token的本质与计算方式
  • 上下文窗口限制的成因
    • Transformer自注意力机制的复杂度
    • 硬件显存与推理延迟
    • 预训练数据的长文本分布偏差
    • 长距离依赖与注意力稀释
  • 突破窗口限制的主流策略
    • 检索增强生成(RAG)
    • 滑动窗口(Sliding Window)
    • 新型模型架构探索
  • LangChain中的Token用量追踪
    • usage_metadata 与 response_metadata 字段
    • 流式输出中的 stream_usage 参数
  • 实战:滑动窗口长文本处理与Token监控
    • 项目结构与依赖
    • tiktoken 精确计算Token数
    • 滑动窗口切分算法实现
    • 结合 ChatOpenAI 调用并记录用量
  • API速览
  • 关键技术要点总结

上下文窗口的概念

大语言模型的“上下文窗口”(Context Window)指模型在单次推理中能够处理的最大Token数量。它等价于一个固定长度的注意力视野:模型仅能“看到”窗口范围内的内容,超出部分在计算过程中被丢弃。该长度是模型架构设计时确定的超参数,直接决定模型能够处理的输入与输出总长度。

不同模型的上下文窗口差异显著。以OpenAI系列模型为例,GPT-4存在8K、32K及128K等不同变体,而早期的GPT-3.5仅支持4K。更大的窗口意味着更强的长文档处理与多轮对话能力,但同时也对计算资源提出更高要求。选择模型时需在窗口长度与推理成本之间进行权衡。

Token:模型的基本信息单元

人类自然语言以字符和单词为基本单元,但大模型底层处理的并非原始文本,而是Token。Token是模型能够识别和处理的最小语义单元,它可以是一个完整的单词、单词的一部分、标点符号,甚至在多模态模型中可以是图像或音频的离散化片段。

以OpenAI的cl100k_base分词器为例,英文文本中大约1个Token对应0.75个单词或4个英文字符。例如句子 “LangChain is cool.” 会被切分为 ["Lang", "Chain", " is", " cool", "."],共计5个Token,原始字符数为18。Token的信息密度显著高于字符级别,因此在开发AI Agent时,必须使用专门的分词工具精确计算文本的Token数量,避免因输入超出上下文窗口而导致截断或异常响应。

上下文窗口的制约因素

上下文窗口不能无限扩大,主要受以下四方面因素制约:

制约因素具体说明
计算复杂度Transformer的自注意力机制计算复杂度为 (O(n^2)),其中 (n) 为序列长度。序列长度翻倍,计算量与显存需求约增长四倍
硬件限制GPU显存大小直接决定可容纳的序列长度上限。长序列需存储更多注意力矩阵与中间激活值,同时推理延迟显著增加
训练数据分布预训练语料中长文本占比通常较低,模型对长距离依赖的学习天然不足。过大窗口可能导致早期信息与当前信息之间的“遗忘”
注意力衰减随序列增长,模型对早期Token的注意力权重呈衰减趋势,长距离问答场景中引用前文信息的能力下降

这些因素共同决定了每个模型必须设置一个经过权衡的上下文窗口值,而非简单的技术选择。

突破窗口限制的常见策略

当实际任务需求超出模型上下文窗口时,通常采用以下三种策略:

  • 检索增强生成(RAG,Retrieval-Augmented Generation):将历史对话或文档存储至外部向量数据库,每次请求时根据当前问题检索最相关的片段,仅将检索结果拼入Prompt。这种方法相当于为模型提供“外挂记忆”。

  • 滑动窗口(Sliding Window):维护一个固定长度的Token窗口,新内容加入时移除窗口最左侧的旧内容。该策略确保模型始终在有限的窗口内处理最近、最相关的信息,实现简单且效果稳定。

  • 新型模型架构探索:研究者尝试使用状态空间模型(State Space Models)、线性注意力(Linear Attention)等架构替代Transformer,以突破平方复杂度限制。目前这些方案仍处于快速演进阶段,尚未成为主流。

上述策略在实际Agent开发中往往组合使用。下文将重点实现一种基于滑动窗口的长文本处理方案,并配合LangChain的Token追踪功能,展示完整的窗口管理流程。

LangChain中的Token用量追踪

LangChain的大模型调用接口返回的 AIMessage 对象中包含 usage_metadata 字段,该字段以标准化结构提供输入Token数(input_tokens)、输出Token数(output_tokens)及总Token数(total_tokens)。无论底层使用OpenAI、DeepSeek还是Anthropic,该字段均被封装为统一格式(部分模型可能返回空值)。

此外,对于OpenAI等支持流式输出的模型,可在调用时设置 stream_usage=True,使每个流式响应块(chunk)附带累计的Token用量信息,便于实时监控成本。

以下代码将展示具体用法。

实战项目结构

本示例实现一个滑动窗口处理器,具备以下能力:

  • 使用 tiktoken 精确计算文本的Token数量;
  • 将超长文本按指定窗口大小和重叠步长切分为多个片段;
  • 逐片段调用大模型并记录每个窗口及总体的Token消耗。

项目目录结构如下:

├── main.py          # 滑动窗口处理与Token追踪主程序
└── requirements.txt # Python依赖列表

依赖清单(requirements.txt):

langchain-openai>=0.3.0
tiktoken>=0.7.0

滑动窗口切分器实现

SlidingWindowSplitter 类使用 tiktoken 将文本按Token数切分为多个带重叠的窗口,确保相邻窗口间的语义连续性。

import tiktoken
from typing import List

class SlidingWindowSplitter:
    """基于Token数的滑动窗口文本切分器"""
    def __init__(self, model_name: str = "gpt-4", max_tokens: int = 2000, overlap: int = 200):
        """
        初始化切分器
        
        :param model_name: 模型名称,用于获取对应的tiktoken编码器
        :param max_tokens: 每个窗口的最大Token数
        :param overlap:   相邻窗口间的重叠Token数
        """
        self.encoding = tiktoken.encoding_for_model(model_name)
        self.max_tokens = max_tokens
        self.overlap = overlap

    def token_count(self, text: str) -> int:
        """返回输入文本的Token数量"""
        return len(self.encoding.encode(text))

    def split(self, text: str) -> List[str]:
        """
        将文本切分为多个滑动窗口片段
        
        :param text: 输入长文本
        :return:     窗口字符串列表
        """
        tokens = self.encoding.encode(text)
        total = len(tokens)
        chunks = []
        start = 0
        while start < total:
            end = min(start + self.max_tokens, total)
            chunk_tokens = tokens[start:end]
            chunks.append(self.encoding.decode(chunk_tokens))
            # 向后滑动时减去重叠部分,保证信息平滑过渡
            start = end - self.overlap
        return chunks

主程序:Token追踪与模型调用

以下代码完整演示了如何使用滑动窗口处理长文本,并利用LangChain的 usage_metadata 追踪每个窗口及整体的Token消耗。

import os
from typing import List
from langchain_openai import ChatOpenAI
from sliding_window_splitter import SlidingWindowSplitter

def demo_sliding_window_processing():
    # 1. 初始化模型,须设置环境变量 OPENAI_API_KEY
    llm = ChatOpenAI(
        model="gpt-4",
        temperature=0.3,
        max_tokens=500,
        api_key=os.getenv("OPENAI_API_KEY"),
    )

    # 2. 构造一篇超长文本(重复内容以模拟长文档)
    long_text = """
    在人工智能的发展历程中,大语言模型的出现是一个重要的里程碑。
    它使得机器能够理解和生成自然语言,从而在对话系统、内容创作、代码生成等领域展现出巨大的潜力。
    然而,大模型并不是万能的,其固有的上下文窗口限制经常导致长文档处理、多轮对话等场景中的信息丢失。
    为了突破这一限制,研究者们提出了多种方案,包括检索增强生成、滑动窗口、以及探索全新的模型架构。
    其中,滑动窗口是一种简单而有效的方法:它将长文本切分成固定大小的片段,每个片段之间保留一定的重叠区域,
    使得模型可以在窗口内处理局部上下文,并通过对多个窗口结果的后处理来获得全局理解。
    这种技术在实际的AI Agent开发中被广泛采用,尤其适用于问答、摘要等需要长上下文的任务。
    """ * 50  # 重复50次,总Token数远超单次窗口上限

    splitter = SlidingWindowSplitter(model_name="gpt-4", max_tokens=2000, overlap=200)
    print(f"原文总Token数: {splitter.token_count(long_text)}")
    windows = splitter.split(long_text)
    print(f"切分成 {len(windows)} 个窗口\n")

    # 3. 逐窗口调用模型,累计Token用量
    total_input_tokens = 0
    total_output_tokens = 0
    results = []

    for i, win in enumerate(windows):
        print(f"--- 处理窗口 {i+1} (Token数: {splitter.token_count(win)}) ---")
        msg = llm.invoke(f"请用中文总结以下文本的核心要点:\n{win}")
        usage = msg.usage_metadata
        if usage:
            input_tokens = usage.get('input_tokens', 0)
            output_tokens = usage.get('output_tokens', 0)
            print(f"  输入Token: {input_tokens}, 输出Token: {output_tokens}, 总计: {usage.get('total_tokens')}")
            total_input_tokens += input_tokens
            total_output_tokens += output_tokens
        results.append(msg.content)

        # 对最后一个窗口演示流式追踪
        if i == len(windows) - 1:
            print("  流式追踪演示(累计用量):")
            # 注意:stream_usage 需在模型调用时启用
            for chunk in llm.stream(win, stream_usage=True):
                if chunk.usage_metadata:
                    print(f"    当前累计: {chunk.usage_metadata}")
            print()

    print(f"\n全部窗口总消耗 - 输入Token: {total_input_tokens}, 输出Token: {total_output_tokens}, 合计: {total_input_tokens + total_output_tokens}")
    return results

if __name__ == "__main__":
    demo_sliding_window_processing()

代码关键说明

  • SlidingWindowSplitter:通过 tiktoken.encoding_for_model 获取与模型匹配的分词器,确保Token计算与模型实际处理一致。split 方法按 max_tokens 切分,并通过 overlap 参数控制相邻窗口的重叠量,保证边界语义平滑。

  • usage_metadata 提取:ChatOpenAI.invoke 返回的 AIMessage 对象中包含 usage_metadata 字段,可直接读取输入、输出及总Token数。

  • 流式追踪:llm.stream(win, stream_usage=True) 启用了流式用量统计,每个chunk的 usage_metadata 携带截至当前块的累计值,便于实时监控。

  • 实际开发扩展:可将滑动窗口逻辑封装为LangChain的 RunnableLambda 步骤,无缝集成到Agent工作流中。

滑动窗口处理流程总览

以下流程图展示了从文本输入到窗口处理再到用量追踪的完整流程:

原始长文本

SlidingWindowSplitter.split

按Token数切分为多个窗口

窗口1

窗口2

窗口N

ChatOpenAI.invoke

返回AIMessage

提取usage_metadata

累计输入/输出Token数

可选: llm.stream with stream_usage

每chunk输出累计用量

API速览

以下列出本文涉及的核心API及其用法:

API / 类所属库方法签名说明
tiktoken.encoding_for_modeltiktokenencoding_for_model(model_name: str) -> Encoding根据模型名称获取对应的分词器编码器
Encoding.encodetiktoken.Encodingencode(text: str) -> List[int]将文本编码为Token ID列表
Encoding.decodetiktoken.Encodingdecode(tokens: List[int]) -> str将Token ID列表解码为原始文本
ChatOpenAIlangchain_openai__init__(model, temperature, max_tokens, api_key)初始化OpenAI聊天模型客户端
ChatOpenAI.invokelangchain_openaiinvoke(input: str) -> AIMessage同步调用模型并返回完整响应
ChatOpenAI.streamlangchain_openaistream(input: str, stream_usage: bool) -> Iterator[ChatMessageChunk]流式调用模型,stream_usage=True时每个chunk附带usage_metadata
AIMessage.usage_metadatalangchain_core.messages属性: Dict[str, int]包含input_tokens、output_tokens、total_tokens的标准化用量字典

关键技术要点

  • 上下文窗口:模型单次推理可处理的最大Token数,受注意力机制复杂度、显存容量、训练数据分布及注意力衰减共同制约。
  • Token计算:Token为模型的基本信息单元,需使用与模型匹配的分词器(如tiktoken)精确计数,不可直接按字符或单词估算。
  • 突破策略:RAG通过外部向量库扩展记忆,滑动窗口通过局部上下文保持信息连续性,新型架构探索则从底层突破平方复杂度。三者可根据场景组合使用。
  • LangChain用量追踪:usage_metadata 提供跨模型的标准化Token统计;流式模式下设置 stream_usage=True 可实现实时成本监控。
  • 滑动窗口实战:通过重叠切分保障边界语义,配合Token追踪可精确控制每次调用的输入长度,有效规避超出窗口导致的截断问题。

官方文档与参考链接

总结

本文从上下文窗口和Token的基本概念出发,系统分析了窗口限制的技术成因,对比了RAG、滑动窗口和新架构等突破策略,并基于LangChain和tiktoken给出了完整的滑动窗口长文本处理实现。

通过对Token用量的精确追踪,开发者可在实际AI Agent项目中有效控制输入长度,避免窗口越界,同时可视化监控推理成本。文中提供的代码可直接复用到生产环境,为长文本场景下的Agent开发提供可靠的工程实践参考。

从操作系统视角理解AI Agent:进程、系统调用与内存管理的核心映射 在软件工程领域,操作系统是管理计算机硬件与软件资源的核心系统软件,其核心职责包括进程管理、内存管理和系统调用。进程作为程序执行的实例,拥有独立的内存空间和生命周期状态;系统调用是用户程序与内核交互的受控接口;而内存管理则通过虚拟内存、分页和交换策略高效利用有限物理资源。这些基础概念为解决现代AI Agent系统面临的长程任务规划、工具调用稳定性和多Agent协作等工程挑战提供了成熟的设计范式。将AI Agent类比为智能进程,其工具调用机制可映射为系统调用,大模型上下文窗口则对应物理内存,需通过向量检索、摘 阅读详情

相关推荐

国内AI平台Plan机制深度解析:Coding/Agent/Token三类订阅技术本质

AI平台的‘Plan’已从简单计费单位演变为融合模型能力、调度策略与权限控制的技术封装单元。其底层涉及语义理解引擎、动态缓存网关、安全沙箱、工作流编排器及Token计数差异等关键技术原理,直接影响开发效能、系统稳定性与成本可控性。作为当前企业AI工程化落地的核心载体,Plan机制决定了代码补全准确率、Agent长周期记忆可靠性、长文本处理上下文利用率等关键指标。本文基于200人研发团队真实负载场景,实测火山、MiniMax、智谱等主流平台在Coding Plan、Agent Plan和Token Plan三

culh2177的博客 707

AI Agent上下文窗口管理:滑动窗口、摘要压缩、分层记忆三种方案的完整代码实现

核心逻辑:当窗口快满时,把早期消息压缩成一段摘要,用少量token保留关键信息。适用场景:需要保留历史上下文、长对话(客服、面试、协作编程)优点:保留了历史语义信息缺点:摘要可能丢失细节、摘要生成本身消耗token"""摘要压缩上下文管理器工作原理:1. 监视窗口使用率2. 当使用率超过阈值(如80%)时,触发压缩3. 把最早的一批消息用LLM压缩成摘要4. 摘要作为system消息插入到窗口开头"""

在渔村里看AI,偶尔捕点新鲜的。 785

AI大模型应用开发实战:从架构设计到工程落地的完整指南

大模型应用开发正从实验探索转向规模化工程实践。其核心在于构建稳定、可靠的应用系统,这涉及从需求定义到部署运维的完整工程链条。理解Agent、Copilot、Chatbot等主流架构模式是基础,它们分别对应自动化任务、工作流增强和智能对话等不同场景。技术选型需在云端API的便捷性与开源模型的可控性之间权衡,而提示工程与上下文管理则是确保模型效果的关键。工程化落地要求开发者构建具备流式响应、缓存、限流等能力的健壮后端服务,并设计提供流畅交互体验的前端。最终,通过成本控制、效果评估和持续迭代,才能将大模型能力转化

weixin_34221073的博客 381

AI编程Agent省钱实战:从任务分级到上下文控制

随着大模型技术在软件开发中深度应用,AI编程助手已从简单的代码补全走向自主执行多步任务的智能体。这一转变带来了效率提升,也带来了Token消耗量级的变化。AI编程Agent的成本并非由单一模型决定,而是受任务复杂度、上下文长度、缓存机制和失败重试策略等多因素共同影响。理解其工作原理,掌握模型路由、上下文压缩、工具输出限流和缓存命中优化,是控制成本的关键。无论是通过API调用还是本地推理,都需要建立任务分级机制,将简单任务与复杂推理任务分流,并辅以精确的Token耗用统计。从代码审查到批量重构,再到日常开发辅

weixin_34088583的博客 497

AI Agent上下文压缩技术:Headroom原理与工程实践

在AI Agent开发中,上下文窗口限制是常见的技术瓶颈,直接影响Agent的长期记忆和多轮交互能力。上下文压缩技术通过智能管理对话历史,在有限Token预算内保留关键信息,其核心原理是对历史对话进行重要性分析、内容重构和上下文重组,而非简单删除。这项技术的工程价值在于提升Agent的持续任务处理稳定性,降低API使用成本。在应用场景上,特别适合客服对话系统、复杂任务规划、文档分析等需要长程状态保持的AI应用。本文以Headroom为例,深入解析其作为Harness层基础设施的实现逻辑,并探讨如何避免记忆失

weixin_33843947的博客 422

大模型应用开发实战:RAG、Agent与Python工程化落地

在生成式AI席卷开发领域的当下,大模型应用开发已成为开发者必须掌握的核心技能。从基础的模型API调用,到提示词工程优化输出质量,再到通过检索增强生成(RAG)让模型掌握私有知识,以及借助AI Agent让模型自主调用工具完成复杂任务,每个环节都直接影响应用的可用性。掌握这些技术原理,能够帮助开发者从简单的Demo走向生产级系统。本文以Python为载体,结合对话记忆、工具调用等关键技术,展示如何构建一个具备多轮交互与外部工具调用能力的AI助手服务。无论您是初学者还是寻求工程化方法的开发者,都能从中获得可落地

weixin_33895657的博客 389

AI Agent成本优化实战:如何将Token消耗从100倍降至可控范围

在大语言模型应用中,Token是衡量计算资源消耗和成本的核心单位。其原理基于模型的词元化处理,直接影响API调用费用和推理性能。合理控制Token消耗对于构建高效、经济的AI应用至关重要,尤其在需要多步推理和工具调用的复杂任务中。AI Agent通过规划、工具调用和长上下文管理实现复杂问题求解,但这也带来了Token消耗激增的挑战,可能达到普通聊天的百倍。本文聚焦于AI Agent的Token消耗问题,从架构设计、工具交互和上下文管理三个维度,提供一套量化分析、瓶颈识别和性能优化的工程实践方案,帮助开发者在

weixin_34380948的博客 288

GitHub Copilot按量计费真相:Token消耗与Agent模式成本精算

在AI辅助编程从工具升级为服务的今天,'token'已不再是抽象的模型单位,而是可测量、可建模、直接影响开发成本的核心资源。其本质是子词切分(BPE)下的语义单元,消耗由输入上下文与输出内容共同决定,远超字符计数直觉。随着Copilot全面转向Agent模式,代码补全演变为具备目标分解、工具调用与结果验证的自主执行流程,导致token消耗呈指数级增长。这一变化正推动工程实践重构:从IDE配置优化、Prompt结构压缩,到本地模型兜底与企业级token配额治理。理解token计量逻辑与Agent运行机制,已成

weixin_34007020的博客 425

AI商业落地:大模型、Agent与MCP实战解析

在AI技术架构中,大模型作为基础引擎提供通用智能能力,Agent系统则通过记忆、决策和工具调用实现复杂任务处理,而MCP(多Agent协作平台)扮演着企业级AI中控系统的角色。理解这些核心概念的差异与协作关系,是避免技术落地陷阱的关键。以电商智能客服为例,合理组合GPT-4、Claude等大模型,配合定制化Agent和Skill,可实现人工干预率从42%降至7%的突破。在实际应用中,需特别注意Plugin与Skill的区别:前者是跨Agent通用的功能扩展件,后者则是绑定特定Agent的原子化能力单元。通过

weixin_34331102的博客 381

Jeff Dean谈AI范式升级:从大模型到推理与Agent协同

Scaling Law曾是大模型能力跃升的核心逻辑,但仅靠堆参数、堆数据已逼近瓶颈。Jeff Dean指出,下一代AI将转向高质量数据工程、受控推理与工具协作。合成数据、推理模型、AI Agent等概念被串联成新的技术框架:模型需具备长期推理与自我反思能力,并通过Agent架构与外部环境交互,真正解决复杂工程问题。这一范式升级正在重塑开发模式,从单一模型调用走向多模型协同、系统化部署。对开发者而言,理解推理模型与Agent的协作方式,掌握工具调用、工作流编排和评估体系,将成为AI工程实践的关键能力。本文结合

weixin_33762130的博客 550

AI Agent核心架构解析:从LLM、工具调用到循环与上下文工程

AI Agent作为人工智能领域的重要发展方向,其核心在于模拟智能体的自主决策与执行能力。其工作原理通常基于大语言模型(LLM)作为决策引擎,通过工具调用(Tool Calling)将决策转化为具体行动,并依赖循环(Loop)机制进行任务规划与状态迭代。这一架构的技术价值在于将强大的语言理解能力与外部工具及系统连接起来,实现了从“思考”到“行动”的闭环,极大地拓展了AI的应用边界。在应用场景上,它特别适用于需要多步骤规划、动态交互或自动化集成的复杂任务,例如智能客服、自动化数据分析与工作流编排。本文聚焦于A

weixin_34405557的博客 295

AI Agent开发实战:从函数调用到生产化落地

大模型能力的普及正在推动AI产业重心从模型训练转向应用落地,AI Agent也因此成为开发者关注的核心范式。函数调用(Function Calling)是其中关键的底层机制:模型负责理解用户意图,通过结构化参数请求外部工具,再由程序执行并将结果回传,形成完整的决策循环。本文以天气助手为例,逐步讲解工具协议定义、Agent主循环实现、多轮上下文管理以及日志、限流、成本监控等工程化能力,并对比学习环境与生产环境的差异,给出重试降级和上下文裁剪的实用策略。无论是熟悉后端还是初入AI领域的开发者,都可以借此理解AI

weixin_33882452的博客 364

腾讯云 Agent + AI Skills 实战:让大模型真正“干活”

大语言模型应用开发中,AI Agent 已成为从对话走向任务执行的关键范式。Agent 与普通 Chatbot 的本质区别,在于它是一套“感知-决策-行动”闭环:模型负责推理,外部能力模块负责落地执行。让模型真正“干活”的,正是 Function Calling 与 AI Skills 这类工程化能力单元——通过输入契约、状态管理和错误处理机制,把业务逻辑封装成可插拔的模块,供大模型按需调用。技术上,依托云端函数计算、容器镜像等基础设施,可以低成本搭建可观测、易扩展的智能体系统,覆盖订单查询、报表生成等真实

weixin_34209851的博客 492

腾讯云Agent养成记:AI Skills实战与避坑指南

大模型驱动的智能体(Agent)正从“能聊天”走向“能干活”,而实现这一跨越的关键,是让模型具备调用外部工具、执行确定性操作的能力。传统的Function Calling在面对复杂任务时,常因工具列表膨胀而出现选择准确率下降、Token消耗过高等问题。AI Skills作为一种带状态、可描述、可组合的能力单元,为Agent提供了更清晰的功能边界和更稳定的执行保障。本文基于腾讯云平台的真实开发经历,系统讲解AI Skills的核心设计理念、Skill拆解与编排策略,并结合系统巡检、Redis配置修改等场景,剖

371

libero烧录信号抓取

提示:如果改了东西需要重新烧录,需要把这两个界面都关闭再libero打开。两个红色的要关闭掉。然后返回libero开始烧录,观测信号(如果只烧录观测从这一步开始就行)等到下面的messige出现以下信息表示run好了。在下图中右侧可以自己设置,设置完之后记得保存一下。run一下,耐心等待,有警告就ok,run完之后。run成功会变绿色,然后点下面的这个看波形。设置抓取信号:在libero打开。打开的就是烧录界面,直接run。

qq_34047965的博客 1426

安装m_map以及用matlab绘制高精度海岸线地图

#如何用matlab绘制高精度海岸线地图

qq_38512775的博客 1万+

Spring AI实战:Java开发者如何快速构建大模型应用与Agent

大模型应用开发正成为企业数字化转型的核心技术,Java后端开发者无需深入算法训练,即可借助Spring AI实现ChatModel统一接入、RAG检索增强与Function Calling工具调用。围绕Java工程实践,讲解如何基于Spring Boot集成大模型模型服务,并梳理LangChain的Chain与Memory设计思想在Agent智能体开发中的映射。结合Spring AI Alibaba国内落地方案,覆盖对话接口、流式输出、结构化输出及多工具协作Agent的完整实现路径。无论是企业知识库问答还是

weixin_33794672的博客 443

高通SA8155P车载Camera开发避坑指南:从硬件拓扑到AIS服务调试全流程

本文详细解析了高通SA8155P车载Camera开发全流程,从硬件拓扑设计到AIS(Automotive Imaging System)服务调试,涵盖关键组件配置、软件架构剖析及高级调试技巧。通过实战经验分享,帮助开发者避开常见陷阱,优化系统性能,适用于智能驾驶系统的环境感知开发。

weixin_42550597的博客 332

AI技术岗位学习路线:从Python到大模型RAG与Agent实战

随着企业AI技术类岗位占比持续攀升,技术团队对AI工程化能力的需求已远超过纯算法研究。理解大模型的基本原理,掌握Prompt设计、RAG检索增强生成、Agent工作流编排,成为AI应用开发的核心技能。同时,Python工程能力、数据处理与特征工程仍是入场基础,而Java后端结合第三方大模型平台做二次开发,也为传统开发者提供了平滑转型路径。在AIoT与农业智能决策等场景中,模型与规则引擎的协同落地,更体现了技术价值向实际业务的延伸。本文从岗位技能拆解出发,梳理编程基础、大模型应用、行业实战与工程化注意事项,帮

weixin_30902251的博客 324

CentOS7无网环境实战:MySQL8.0完整离线安装与避坑指南(附依赖包下载)

本文详细介绍了在CentOS7无网环境下MySQL8.0的完整离线安装流程,包括依赖包获取、系统预处理、MySQL二进制安装、服务配置与优化等关键步骤。特别针对离线安装的特殊需求,提供了从依赖包下载到服务调优的全链路解决方案,帮助用户在企业内网或隔离环境中高效部署MySQL数据库。

bush的博客 177

AMBA-CHI协议详解(五)

 每个事务由许多不同的packets组成,这些数据包通过互连(interconnect)传输。packets内的一组ID域段用于提供有关包的附加信息。

Crazzy_M的博客 1967

AI Agent工程化实战:构建健壮智能体循环的架构设计与核心技巧

在人工智能领域,智能体(Agent)作为能够感知环境、自主决策并执行动作的软件实体,其核心运行机制依赖于一个持续迭代的思考-行动循环。这一循环机制的原理在于通过状态管理、上下文感知和工具调用,使智能体能够完成复杂任务。从技术价值看,工程化实现的智能体循环能够将前沿AI能力转化为稳定可靠的生产力工具,解决传统自动化脚本难以处理的非结构化问题。在实际应用场景中,智能体循环广泛应用于智能客服、自动化工作流、代码生成助手等需要多步骤推理的业务场景。本文聚焦于智能体循环(Agent Loop)的工程化实践,深入探讨了

weixin_34194087的博客 574

goahead(嵌入式Web服务器)之openssl 应用篇

1、环境配置 在me.h文件里修改以下宏定义 ME_COM_MBEDTLS 0 ME_COM_MATRIXSSL 0 ME_COM_NANOSSL 0 ME_COM_OPENSSL 1 2、添加 goahead-openssl.c goahead-openssl.c这个文件在有些goahead源码中是没有的,后面的章节中会提供openssl应用测例 3、依赖的库 goahead的openssl 应用需要依赖libssl.a与libcrypto.a(libssl.so与libcrypto.so)两个库,做好

weixin_40732273的博客 2089

Autoresearch实战:解析779M Token消耗与GPU调度三轮优化

在AI自动化研究领域,Autoresearch作为基于大模型的自主实验范式,正逐步成为数据分析和模型评估的重要工具。其核心并非简单的多轮Prompt,而是涉及Token消耗控制与GPU资源调度的系统工程。当任务运行上千次实验、消耗上亿Token时,如何高效管理上下文长度、避免显存溢出、实现多任务隔离,直接影响研究能否持续运行。通过理解模型推理与实验计算的GPU分工,结合设备隔离、显存预留、串行控制等策略,可以显著提升自动研究的稳定性。该技术适用于参数调优、性能基线测试、代码迁移适配等场景,为Agent应用开

weixin_30932215的博客 298

提示工程架构师揭秘:prompt优化中的“隐性成本”如何控制?

当我们谈论Prompt优化时,往往聚焦于“效果提升”——比如让模型生成更准确的回答、更符合要求的格式。优化的本质是“成本-收益”的平衡。那些看不见的“隐性成本”,比如反复调试的时间消耗、复杂Prompt带来的认知负荷、长文本导致的系统资源浪费、后续维护的无穷麻烦,往往会在长期运营中成为压垮效率的“稻草”。本文将从提示工程架构师的视角,揭秘Prompt优化中的“隐性成本”到底是什么、如何量化,以及通过哪些工程化手段将这些“看不见的消耗”转化为“可控制的效率”。

操作系统内核探秘的博客 700

Vue3 - Element Plus 表格组件 el-table “表格行数据中又嵌套了二维对象数组“,按平级循环渲染(嵌套数组视为同级行数据), 对嵌套的数组循环展示为表格,智能合并行或列详细教程

vue3,nuxt3,element-plus,table表格组件,el-table,vue3element表格组件,数据中有二维数组怎么遍历循环显示,表格数据带二级数组怎么循环渲染显示,表格数据中存在一个数组要怎么才能显示到表格,el-table表格合并详细教程示例,table表格如果对象里面还有对象数组那该怎么去渲染,平常都是数组中一个对象渲染成一行,每行中还有嵌套数组怎么办,每个行数据下还有一个数组怎么显示,怎么把表格相同的数据合并为一行,合并上下两行相同数据单元格,合并行或列如果遇到相同单元格就合

🏆 前端领域优质创作者 1万+
上一篇: AI Agent从无到有21: LangChain 大模型组件标准参数与事件驱动实战
下一篇: AI Agent从无到有23: 大模型速率限制应对与缓存机制实践
Wang's Blog
博客等级 码龄12年 7438粉丝 2422原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

Wang's Blog

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

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

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

打赏作者

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

抵扣说明:

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

余额充值