- 博客(335)
- 收藏
- 关注
RSS订阅原创 30、【Agent】【OpenCode】模型配置（OpenRouter）
【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除。
2026-03-29 05:49:18
664
原创 29、【Agent】【OpenCode】模型配置（OpenCode Zen）（二）
本文分析了OpenCode Zen作为AI网关的价值与局限。OpenCode Zen通过精选优质模型、与供应商合作优化配置、严格基准测试，为用户提供编码代理的最佳版本（如minimax-m2.5-free），解决不同供应商配置差异导致的性能不稳定问题。其核心价值是统一入口+智能路由+质量保障，但存在境外服务器中转带来的网络延迟和数据出境风险。建议个人开发者可优先使用Zen简化流程，而企业/敏感项目应选择自建Provider直连国内API或本地模型部署。Zen本质是OpenCode提供的"精品AI礼
2026-03-29 05:48:49
370
原创 28、【Agent】【OpenCode】模型配置（OpenCode Zen）（一）
本文分析了OpenCode Zen模型服务的特性及其缓存优化机制。OpenCode Zen是经过精选调优的AI模型服务，专门优化编程任务，提供开箱即用的免费模型如big-pickle，支持工具调用和超长上下文处理。重点介绍了缓存机制如何通过cache_id避免重复传输长上下文，节省带宽和费用。OpenCode Zen处于测试阶段，用户也可自行配置其他模型API。文章还解释了模型属性的含义，如cost、limit等参数的作用。
2026-03-28 09:15:08
582
原创 27、【Agent】【OpenCode】模型配置（models属性）
本文分析了OpenCode模型配置中的模型信息，以big-pickle为例详细解读了各项参数含义。该模型是opencode供应商下的一个纯文本模型，具备推理逻辑和工具调用能力，支持调节temperature参数。配置信息包括模型ID、显示名称、家族分组、输入输出限制、训练数据时间、费用结构（目前完全免费）以及上下文长度限制（支持20万tokens）等。文章还指出该模型为闭源模型，不支持文件附件处理。所有技术案例均来自公开开源项目，不涉及企业机密。
2026-03-28 09:14:46
409
原创 26、【Agent】【OpenCode】模型配置（models-api.json）
本文分析了OpenCode项目中模型配置的实现细节。通过解析models-api.json测试文件，揭示了opencode/xxx模型供应商的工作机制：使用OpenAI兼容格式，通过https://opencode.ai/zen/v1统一入口中转请求，支持环境变量OPENCODE_API_KEY设置密钥（免费模型无需）。文章指出该方案存在跨境访问延迟问题，并详细解释了Provider配置中各字段的含义，包括唯一标识、内部ID、API地址、文档链接等。最后说明该配置相当于一个适配器，将不同模型请求统一封装为O
2026-03-24 09:21:18
573
原创 25、【Agent】【OpenCode】模型配置（opencode/xxx 分析）（二）
本文分析了opencode/xxx模型的境外中转架构及其潜在风险。所有请求需经api.opencode.ai境外服务器，存在数据出境合规、知识产权泄露等风险，企业用户需谨慎使用。对比了直连与中转方式的差异，建议企业采用国内模型或本地部署方案。文章还介绍了6款免费模型的特点及适用场景，并指出OpenCode实际支持更多模型但默认仅启用部分。最后提到其架构通过配置文件控制模型启用状态。
2026-03-24 09:20:55
370
原创 24、【Agent】【OpenCode】模型配置（opencode/xxx 分析）（一）
【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除。
2026-03-23 09:17:02
381
原创 23、【Agent】【OpenCode】模型配置（免费模型）
本文介绍了OpenCode平台中免费AI模型的使用与分析。平台提供5个免费模型（如Big Pickle），基于开源模型微调优化，适用于代码生成和理解。通过命令行工具可查看可用模型列表，所有模型通过OpenCode官方代理服务提供，隐藏底层API细节。测试显示模型访问速度良好（延迟190ms+），且无需配置API Key即可使用。文章还解析了模型命名规则（provider/model格式）及OpenCode Zen代理服务的工作原理。
2026-03-23 09:16:07
707
原创 22、【Agent】【OpenCode】源码构建（平台目标属性）
本文分析了OpenCode项目构建中的平台目标属性，重点解读了arch(CPU架构)、abi(Linux C标准库兼容性)和avx2(SIMD指令集优化)三个关键参数。其中arch区分x64和arm64架构，abi解决glibc与musl的兼容性问题，avx2则控制是否启用现代CPU的向量指令加速。这些配置共同确保了OpenCode二进制文件能在不同硬件环境和操作系统上高效运行，特别考虑了容器化场景和老旧设备的兼容需求。
2026-03-21 16:48:40
488
原创 21、【Agent】【OpenCode】源码构建（项目构建）
本文记录了使用Bun工具构建OpenCode项目的完整过程。首先通过国内镜像源解决了npm依赖安装缓慢的问题，然后详细介绍了bun run build命令执行TypeScript编译打包的操作步骤，重点分析了构建生成的多平台二进制文件特性。文章深入解析了OpenCode支持的12种平台目标配置（包括Linux、macOS和Windows系统），详细说明了os、arch、abi和avx2四个关键属性的作用，并介绍了通过--single参数实现单平台快速构建的优化方法。最终成功构建出可在Ubuntu系统运行的独
2026-03-21 16:48:11
946
原创 20、【Agent】【OpenCode】源码构建（依赖安装）
本文分析了TypeScript与JavaScript的区别及开发体验对比，指出TypeScript在大型项目中的优势。通过代码示例展示了TS到JS的编译过程，并解释现代工具（如Bun）如何自动编译运行TS代码。文章对比了两者在类型系统、错误发现时机等方面的差异，并演示了使用Bun安装依赖时如何切换国内镜像源以解决下载卡顿问题。最后展示了通过指定淘宝镜像成功安装依赖的过程。
2026-03-20 09:21:05
658
原创 19、【Agent】【OpenCode】源码构建（TypeScript&JavaScript）
本文分析了Bun工具集相比Node.js性能提升的核心原因，重点补充了Bun内置工具链实现零转译开销的优势。文章对比了传统前端开发流程与Bun的简洁执行路径，指出Bun直接解析TypeScript为字节码的特性。同时深入探讨了TypeScript作为JavaScript超集的特点，强调其类型系统的价值，并通过代码示例展示类型检查的优势。文章还列举了TypeScript新增的核心特性，说明这些特性在编译后会被移除，实现零运行时开销。最后预告了下篇关于依赖安装的内容。
2026-03-20 09:20:35
527
原创 18、【Agent】【OpenCode】源码构建（Bun&node速度对比）
本文对比分析了Bun工具集的多种安装方式，推荐使用官方脚本安装。测试显示Bun的启动速度（8ms）比Node.js（62ms）快约8倍，这得益于其采用Zig语言编写、零依赖设计以及数据库式包管理器。Bun将依赖缓存为SQLite数据库，通过内存映射直接读取，避免了npm/yarn的文件复制操作，显著提升了性能。文章还介绍了Bun与Node.js在架构设计上的核心差异，解释了Bun性能优势的技术原理。
2026-03-19 19:11:00
504
原创 17、【Agent】【OpenCode】源码构建（Bun安装方式）
本文介绍了使用Bun工具集安装OpenCode项目的方法。通过curl -fsSL https://bun.sh/install | bash命令下载并执行安装脚本，该脚本会自动检测系统环境、下载对应平台的Bun二进制包并配置环境变量。文章详细解析了curl命令选项含义，并指出这种安装方式的潜在安全风险（如域名劫持）及防范建议。安装完成后会在用户目录下创建.bun文件夹并修改.bashrc文件。Bun作为新一代JavaScript运行时，相比传统Node.js+npm工具链具有更快的速度优势。
2026-03-19 19:09:57
394
原创 16、【Agent】【OpenCode】源码构建（Bun介绍）
本文介绍了OpenCode项目的安装和初步分析过程。作者通过Git克隆了OpenCode源码，发现这是一个基于Bun的JavaScript/TypeScript项目。文章对比了Bun与传统Node.js工具链的差异，指出Bun作为一体化高性能运行时，在启动速度、包安装等方面具有显著优势。测试显示OpenCode会与opencode.ai服务器交互并上传项目上下文，提醒用户注意隐私保护。最后简要介绍了Bun的核心功能及其与Node.js的兼容性差异。
2026-03-18 18:55:16
552
原创 15、【Agent】【OpenCode】对话测试（免费模型）
本文分析了开源AI编码助手OpenCode的网络通信行为。通过流量监控发现，OpenCode在无配置情况下会默认连接opencode.ai主API端点，上传用户提示词及项目上下文（包括文件列表和部分代码），并接收AI回复；同时连接models.dev获取模型列表和策略规则。测试显示，即使简单提问"你是谁？"也会附带项目信息上传，存在代码泄露风险。文章还介绍了OpenCode的安装方法和基础使用流程，包括查看关联大模型等操作。
2026-03-18 18:54:39
428
原创 171、【OS】【Nuttx】【ARMV7M】任务跳转（上下文切换）（二）
本文分析了Nuttx操作系统在ARMv7M架构下的上下文切换机制。首先说明了up_switch_context宏的定义方式及其参数作用，指出其通过系统调用而非直接寄存器操作实现切换。重点讲解了up_interrupt_context()函数如何通过IPSR寄存器判断当前是否处于中断上下文，强调任务切换只能在普通任务模式下进行。最后介绍了系统调用触发后的异常处理流程，包括向量表映射和exception_common汇编函数的作用。文章还对比了SIM仿真环境和ARM架构在上下文切换实现上的差异。
2026-03-15 16:52:32
702
原创 170、【OS】【Nuttx】【ARMV7M】任务跳转（上下文切换）（一）
本文分析了Nuttx操作系统在Cortex-M架构下的任务切换机制。首先回顾了IPSR和EPSR寄存器的作用，以及栈溢出检测中R10寄存器的设置。重点介绍了up_switch_context函数的实现，该函数负责保存当前任务上下文并恢复新任务上下文，通过修改栈指针和程序计数器实现任务跳转。文章通过任务A切换到任务B的示例，说明了上下文切换的具体过程。最后预告了下篇将深入分析任务跳转和上下文切换的更多细节。
2026-03-15 16:52:02
569
原创 14、【Agent】【OpenCode】介绍
本文介绍了如何通过API连接大模型并部署AI Agent，重点推荐了开源终端原生编码工具OpenCode。OpenCode支持Plan/Build双模式，内置20+实用工具（如文件读写、代码检查等），开箱即用且完全免费。其终端优先设计适合开发者进行编程、系统操作等研究，能直接执行Shell命令、操作Git等，帮助用户掌握真实开发工作流。OpenCode降低了使用门槛，新手可快速上手并完成自动化研究任务。
2026-03-12 09:20:27
719
原创 13、【AI】【Agent】联网使用大模型（多轮对话&tokens）
本文探讨了大模型多轮对话中的上下文管理策略。首先分析了消息角色（system/user/assistant）对模型输出的影响，指出多轮对话会累积token导致超出上下文限制的问题。针对此问题，提出了四种解决方案：滑动窗口（保留最近N轮）、总结摘要（AI自动浓缩历史）、选择性保留（仅存关键信息）和外部存储（向量数据库检索）。文章建议根据应用场景选择合适的策略，如普通聊天推荐3-5轮滑动窗口，编程助手建议选择性保留代码片段。这些方法能有效平衡上下文连贯性与token消耗，适用于大多数AI对话场景。
2026-03-12 09:19:58
570
原创 12、【AI】【Agent】联网使用大模型（role 角色）
本文详细分析了大模型对话中message消息格式的三种role角色（system、user、assistant）及其作用机制。system用于设定AI行为规则且权重最高，user代表用户输入并触发响应，assistant保存AI回复以维持对话连贯性。文章通过实例演示了角色配置如何影响模型输出，并指出常见错误用法（如错误放置system、连续user消息等）。正确使用角色字段能显著提升对话质量，避免无效token消耗。
2026-03-10 08:58:30
569
原创 11、【AI】【Agent】联网使用大模型（DashScope&OpenAI）
本文对比了阿里云DashScope和百炼（Model Studio）平台的大模型API使用方式，提供了基于dashscope SDK和OpenAI SDK的两种连接脚本示例。文章详细介绍了两种SDK在模型类型、API兼容性、访问速度、价格等方面的差异，并解释了对话消息结构中的system、user、assistant三种角色含义。测试脚本展示了如何通过API Key连接大模型并获取响应，同时提醒用户关注token使用额度。最后指出这种消息格式已成为行业标准，为后续技术探讨奠定基础。
2026-03-10 08:57:40
509
原创 10、【AI】【Agent】联网使用大模型（ModelStudio）
摘要：本文对比了阿里云DashScope灵积平台与百炼平台在大模型API服务上的差异，重点分析了价格策略和免费期（灵积180天vs百炼90天），并提供了Python SDK安装指南。作者建议优先使用灵积免费期后转至更经济的百炼平台，同时详细说明了API密钥获取、环境配置及调用示例代码，特别处理了Python 3.12的pip安装兼容性问题。文中还包含两个平台的计费截图对比和实际调用Qwen-Max模型的代码演示。（149字）
2026-03-09 20:46:16
616
原创 9、【AI】【Agent】联网使用大模型（DashScope&ModelStudio）
本文对比了阿里云两大AI服务平台DashScope（灵积）和百炼（Model Studio）的核心区别。DashScope提供通义千问、通义万相、语音识别等原始模型API，适合开发者直接集成，定位为模型即服务（MaaS）底层接口。百炼则是一站式企业级大模型应用开发平台，在DashScope基础上封装了智能体、知识库、工作流等工具，支持可视化拖拽和低代码配置，适合企业用户快速构建AI应用。文章还解释了多模态AI概念，并指出百炼可视为DashScope的高级封装版，二者分别满足不同层次的技术需求。
2026-03-09 20:45:25
538
原创 169、【OS】【Nuttx】【栈溢出】up_initial_state（IPSR&EPSR）
本文分析了Nuttx操作系统中任务初始化函数up_initial_state对PSR寄存器的设置细节。重点阐述了xPSR寄存器中Thumb位的关键作用，指出Cortex-M只支持Thumb指令集，若未设置Thumb位将导致系统崩溃。同时详细解析了APSR中NZCV标志位的自动更新机制、IPSR在异常处理中的作用，以及EPSR中IT状态位对Thumb-2条件执行语句的支持原理。作者通过对比高级语言与底层标志寄存器的差异，澄清了Z标志表示"结果为零"而非直接表示相等的概念。最后强调了在任务初
2026-03-07 15:40:53
840
原创 168、【OS】【Nuttx】【栈溢出】up_initial_state（xPSR）
本文分析了Nuttx系统中ARMV7架构下任务初始化函数up_initial_state的关键设置，重点讲解了xPSR程序状态寄存器的配置细节。文章指出xPSR由APSR、IPSR和EPSR三个状态寄存器组成，其中Thumb位（T-bit）必须设置为1，否则会导致系统进入HardFault。作者详细解释了xPSR寄存器的位定义，包括条件标志位NZCV的含义，并说明了Nuttx如何通过设置xPSR=0x01000000来确保任务运行在Thumb模式下，同时保持其他状态位的合理默认值。本文为理解ARM Cort
2026-03-07 15:40:29
539
原创 8、【AI】【Agent】联网使用大模型（一）
本文分析了自回归模型中上下文长度对token生成速度的影响，指出在CPU推理场景下，上下文长度（≤8K）对速度的影响远小于模型参数量，主要受限于数据搬运效率。作者建议在硬件受限时优先选择小模型或使用云端API，并比较了免费网页版与收费API的本质区别：前者是用户产品，后者是生产力工具。API收费的核心原因在于防止滥用并覆盖高昂的GPU成本，而网页版存在功能限制。最后强调应合法使用官方API，避免违规抓取网页版数据。
2026-03-05 22:13:25
649
原创 7、【AI】【Agent】上下文长度对 tokens/s 的影响
本文分析了AI模型生成token时上下文长度对速度的影响。理论上，随着上下文变长，计算量会增加，生成速度会下降。但在CPU推理中，内存带宽是主要瓶颈，模型权重搬运时间远大于计算时间。实际测试显示，当上下文长度增加16倍时，速度仅下降10-15%；而模型参数量增加2.1倍时，速度下降60%以上。现代推理引擎通过KV Cache复用和内存访问优化，使上下文长度的影响显著降低。文章指出在CPU推理中，模型大小是主导因素，上下文长度是次要因素。
2026-03-05 22:13:01
573
原创 6、【AI】【Agent】输入/输出 tokens
本文分析了AI模型生成token速度(tokens/s)与用户体验的关系，指出30-60 tokens/s是流畅交互的基准。文章对比了输入和输出token处理的差异：输入处理（prompt分词）可并行且快速（~1600 tokens/s），而输出生成必须串行且依赖上下文（典型100 tokens/s）。关键发现包括：1)输出速度是用户体验的决定因素；2)输出阶段计算量随上下文长度增加；3)用户更关注输出速度因输入耗时短且输出长度不可控。最后强调参数量增加会显著降低生成速度，建议本地部署应优先考虑30-60
2026-03-03 20:13:38
649
原创 5、【AI】【Agent】tokens生成速度
本文分析了不同硬件环境下大模型生成tokens的速度差异。在纯CPU推理场景中，内存带宽成为主要瓶颈，导致即使强大CPU也无法充分发挥计算能力，如7B模型受限于DDR5内存带宽只能达到40-60 tokens/s。相比之下，GPU凭借更高显存带宽（如RTX 4090达1TB/s）能更好发挥并行计算优势。文章特别推荐了微软优化的Phi-3-mini模型（3.8B），其通过架构精简、CPU友好设计和算子融合等技术，在CPU环境下能达到接近Llama-3-8B两倍的速度。最终建议若要充分发挥大模型能力，应优先考虑
2026-03-03 20:12:40
468
原创 167、【OS】【Nuttx】【栈溢出】运行时检测细节（up_initial_state）
本文分析了Nuttx操作系统中栈溢出检测机制的实现细节，重点介绍了任务创建时如何设置栈底寄存器rBS。文章通过剖析up_initial_state函数，说明了RTOS如何为新任务伪造CPU寄存器状态：清空寄存器上下文、设置初始栈指针SP、程序计数器PC和链接寄存器LR。特别指出SP指向栈顶高地址，PC设置为任务入口函数，而LR则指向任务退出处理函数。这些初始化操作确保任务首次被调度时能正确执行，同时为栈溢出检测奠定基础。
2026-03-02 09:14:47
669
原创 4、【AI】【Agent】tokens 介绍
本文探讨了大模型中的关键概念"token"，解释了其在中文和英文中的不同处理方式（1个汉字≈1-2 tokens，1个英文单词≈1-3 tokens）。通过具体示例展示了文本和代码的token拆分过程，并区分了输入token和输出token（tokens/s）的概念。文章对比了不同参数量的模型（如Phi-3-mini、CodeLlama-7B等）在相同硬件条件下的推理速度，指出参数量越大生成速度越慢的规律，这源于每个token生成都需要遍历所有参数进行计算。最后用自回归过程解释了toke
2026-03-02 09:13:51
680
原创 3、【AI】【Agent】本地模型（硬件参数）
本文探讨了本地运行AI大模型的关键技术指标，重点解析了模型参数规模（如3.8B、7B等）、量化格式（如Q5_K_M）和性能表现的关系。作者通过实测数据展示了不同规模模型在CPU上的推理速度和内存占用情况，指出7B~13B量级模型适合主流开发者使用。文章详细解释了量化技术的原理（如将16位浮点数压缩为5位整数），并对比了不同量化级别在文件大小、内存占用和精度上的差异，推荐Q5_K_M作为CPU推理的黄金标准。最后提供了模型规模与适用场景的对照表，为开发者选择合适模型提供参考。
2026-03-01 11:33:02
824
原创 2、【AI】【Agent】LLM 连接（本地模型）
本文探讨了AI Agent的实现架构与本地部署方案。文章指出Agent本质是LLM大模型的代理执行器，需通过连接大模型才能运作。部署方式分为联网使用闭源模型（如GPT-4）和本地部署开源模型两种方案。重点分析了本地部署的两种实现路径：基于Docker的Ollama方案和原生Linux方案，并详细介绍了评估本地硬件（CPU架构、核心数、指令集等）的关键指标。作者以AMD Ryzen 9处理器为例，解析了CPU性能对模型推理的影响要素，为开发者选择硬件配置提供了实用参考。
2026-03-01 11:32:41
1141
原创 1、【AI】【Agent】项目简介
摘要： AI Agent（智能体）是具备自主性、目标导向性和环境交互能力的智能系统，区别于传统被动响应的AI模型。其核心特征包括自主运行、目标驱动、工具调用、记忆学习等，典型架构由LLM（大模型）、规划器、执行引擎和记忆模块组成。当前主流类型涵盖单智能体（如AutoGPT）、多智能体协作（如MetaGPT）等。未来趋势包括Agent OS、个性化数字分身等。值得注意的是，AI Agent可完全离线运行，依托本地LLM（如Qwen-Max、Llama-3）和工具（文件读写、代码解释器），满足企业数据安全、隐私
2026-02-28 19:08:03
796
原创 166、【OS】【Nuttx】【栈溢出】运行时检测细节（一）
本文分析了Nuttx系统中栈溢出检测的实现细节。首先通过R10和R11寄存器推算栈空间分配时需向上补齐12字节（8字节用于栈指针对齐，4字节应对异常入口等情况）。然后重点介绍了Per-Call Stack Checking机制，该机制通过GCC插桩在函数入口/出口检查栈指针SP与安全下限rBS（R10）的关系。文章详细说明了rBS的初始化时机，为避免死循环需禁止对__start()函数插桩，并解释了为何rBS被设置为比实际栈底高64字节的位置（预留安全余量防止刚好溢出、补偿中断开销、方便调试）。最后指出实际
2026-02-28 19:05:56
809
原创 165、【OS】【Nuttx】【栈溢出】R11 的特殊处理
本文分析了Nuttx操作系统中栈溢出检测机制的实现细节。通过寄存器R10(栈底)和R11(溢出时SP)的差值可计算实际栈使用量，并需额外补偿12字节(8字节对齐+4字节潜在开销)。重点解释了ARM架构下函数prologue对栈指针的影响，以及栈检查在prologue前执行的时机。文章指出栈溢出检测会带来性能损耗，建议仅在调试阶段启用。技术细节包括AAPCS规范要求、函数prologue/epilogue概念，以及Nuttx特定的诊断机制实现方式。
2026-02-26 20:03:56
786
原创 164、【OS】【Nuttx】【栈溢出】代价
本文分析了Nuttx系统中栈溢出检测机制的性能代价。启用CONFIG_ARMV7M_STACKCHECK后，每次函数调用会增加两次插桩调用，导致CPU占用率上升30-35%，可能影响实时性。建议调试阶段开启，生产环境采用更轻量方案如MPU保护或栈染色检查。文章还介绍了Nuttx利用R10/R11寄存器记录栈溢出地址的调试机制，通过保存栈底地址和溢出时的SP值，帮助开发者精确计算所需栈空间。该机制从2019年提交开始实现，在发生栈溢出时将非法SP值存入R11寄存器，便于故障诊断。
2026-02-26 20:03:14
611
原创 163、【OS】【Nuttx】【栈溢出】中断栈行为（单栈模型）
本文分析了Cortex-M架构中单栈和双栈模型的特点。单栈模型适用于简单系统，所有代码共享MSP栈指针，节省RAM但存在栈溢出风险；双栈模型通过PSP和MSP隔离任务栈与中断栈，安全性更高但占用更多资源。文章还介绍了Nuttx的栈检查功能（CONFIG_ARMV7M_STACKCHECK）带来的性能开销，包括代码体积增大和运行速度下降，因为该功能会在每个函数中插入额外的栈检查指令。两种栈模型各有优劣，开发者需根据应用场景权衡选择。
2026-02-24 08:25:08
749
原创 162、【OS】【Nuttx】【栈溢出】中断栈行为（双栈模型）
本文分析了Cortex-M架构中特权模式与栈指针的行为特点。通过模拟芯片复位、RTOS启动任务、中断发生和中断返回四个场景，详细说明了Privileged/Unprivileged模式与MSP/PSP双栈机制的交互关系。重点指出在RTOS双栈模型下，中断服务程序(ISR)会强制使用独立的中断栈(MSP)，无法共享任务栈空间(PSP)，这是安全且主流的设计方案。文章最后讨论了中断栈溢出检测的局限性，并预告将深入分析单栈模型场景。全文通过寄存器配置、模式切换和栈隔离机制，系统性地阐述了Cortex-M架构的栈管
2026-02-24 08:24:41
591
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人