OxYGC

💡 Claude Code 是跑在终端里的 Agent，不是命令行版 IDE。本文按“装得上、连得通、用得放心”三步展开：三条安装路线、官方订阅与兼容端点接入、权限规则与六种模式，再给一份日常命令清单和十五分钟最小闭环。

AI 编程助手不缺能力，缺的是让需求有地方住。这篇按我自己跑通的顺序讲 OpenSpec（npm 包 @fission-ai/openspec，1.16.0）：init 实际往仓库里写了什么、explore/propose/apply/archive 一轮闭环每步在做什么、Requirement 与 Scenario 要写成什么样才不会被静默忽略，以及它和 Spec Kit、Kiro 的分工差异。命令输出与校验报错全部本机实测。

本文探讨大模型技能（Skill）的四种变现路径：买断、订阅、定制与开源+付费增强，核心观点是“能收钱的不是文件本身，而是持续交付的能力”。作者指出，复制成本为零的指令文本无法定价，真正价值在于环境维护、持续适配与售后支持。四类模式中，个人作者更适合定制与开源增强；渠道抽成方面，海外平台如Lemon Squeezy（5%+）较优，国内平台则存在“两头收费”问题，实际到手不足标价80%。定价应锚定“对方省时价值”，而非投入工时，避免陷入“免费陷阱”。

本文剖析了从“自用技能”到“可公开开源技能”的五大关键差距：目录名与name不一致、嵌套技能、残留备份文件、缺失LICENSE与CHANGELOG、以及缺乏版本管理。作者通过自检12个技能仓库，揭示了规范中三条硬线（name长度、description限制、正文行数建议）及一条易忽略的引用层级规则。强调技能需按Metadata/Instructions/Resources三层结构设计，正文应引导模型调用外部资源，避免冗余加载。最终提出：真正可共享的技能，必须经得起“他人机器一键安装”的考验。

本文探讨为Agent添加状态管理的实践，强调“记忆”对重复任务的关键性。对比Notion、飞书多维表格与本地Markdown三种方案，指出外部状态是实现跨会话记忆的核心。作者最终选择以Notion为主档，因其支持行级操作、可远程写入且便于人工核验；本地Markdown仅作导出备份。文章提出“一库一职责”“幂等键约束”“结构留归档”三大设计原则，并警示需通过回读验证写入成功，避免因回收站隐藏导致静默失败。最终构建起以配置库为根、各状态库分责运行的稳定系统架构。

第二天开始动手：RAG 知识库调参加低代码智能体开发。RAG 九步流程里真正决定效果的只有解析、切割、检索、重排序四个卡点，差距落在参数上：段落切分、最大长度 1024、重叠 50、Top K 3、Score 阈值 0.5、混合检索配 bge 系列模型，再加一句「只根据知识库」当防幻觉约束。后半篇讲三个 level 与五要素清单、Function Call 到 MCP 的标准化，以及 Coze、Dify、n8n 三条路线各自的代价。

入门大模型最容易踩的坑不是模型笨，而是选错了落地手段。这篇先把地基摊平：B、token、FLOPs 三个计量单位各量什么、四类模型怎么分、开源为什么不等于免费；三段式训练各自解决什么问题，训练卡在显存容量、推理卡在显存带宽；幻觉为什么消不掉，以及提示词、RAG、微调、续训、智能体这条成本递增的路径该怎么选。结论：绝大多数场景停在提示词和 RAG 就该收手，企业场景 RAG 加微调通常够用。

这一篇讲剩下四条工程落地路径。RAG、微调、续训、智能体经常被放在一起宣传，但它们解决的根本不是同一个问题：最常见的两个误判，是用微调去补领域知识，以及把 Function Call 和 MCP 当成竞争关系。文中按模块给出 RAG 的工作流程与三种实现、微调的前置条件、从全参到 QLoRA 的方法谱系，以及 RAG 与微调的对照。

工程落地五条路里第一位是提示词工程：最便宜、开箱即用，也正因看起来谁都会写，它是最容易被做坏的一环。给我一个英语学习计划，和一段带角色、学情、期限的完整指令，输出质量差的不是一星半点。这篇把六要素逐个拆开，讲分隔符为什么就是提示词里的墙、提示注入为什么能成立，以及稳定约束和动态约束该怎么分到 System 与 User。

前三篇讲的都是模型侧：它是什么、怎么训出来、跑在什么硬件上。从这篇开始换视角——一个开发者到底怎么把大模型用起来。最省事的路径是打开官网对话框，但只要你试着做点真实需求：接进自己的系统、挂个私有知识库、跑一条多步骤流程，马上就会撞到墙：官网没提供这些能力，你得去调 API。篇里先把 AIGC 与 AGI 两个词校准，再讲幻觉的五种类型。

显存爆了、这个 7B 要多少显存、为什么推理慢不是算力问题而是带宽问题——这些说法在群里天天出现，但很少有人把它们放在同一张图里讲清楚。更反直觉的是：训练阶段和推理阶段的瓶颈压根不是同一套。这篇先把两个概念分开，再讲 CPU / GPU / NPU / TPU 的分工，然后列出训练侧三个瓶颈、推理侧四个瓶颈。

同一个模型，早期你问它下雨要带什么，它可能回你一个东西；现在的模型会老实告诉你带伞。中间差的这一步是什么？为什么模型明明读完了整个互联网，却还学不会好好回答？更棘手的是，正面问它写诈骗短信它拒绝，绕两个弯包装成安全培训课件它就答应了。这篇按预训练、SFT、RLHF / RLAIF 三个环节拆开：每段学什么、给了什么、没给什么。

DeepSeek、通义千问、GPT、Gemini 名字一个比一个响，宣传口径却大同小异：参数很大、能力很强、什么都懂一点。但真要把这些讲清楚，很多人卡在几个很基础的问题上：所谓 7B、36T token、5 PFLOPS 到底在说什么？为什么有的模型能看图、有的只能写字？同样是开源，为什么有人说免费、有人说自己部署还得买机器？这篇把三个计量维度、两套分类和开源闭源的七个维度一次对齐。

本文聚焦于如何实操使用 systemone API，详解一次调用的骨架结构：state、model、questions 输入，返回 answers 与 usage。强调5个关键数值——价格（$0.042/Mtok，仅计输入）、上下文预算（64k总+32k单题）、速率限制（1,200 rpm/250k tps）、输入类型（仅文本）及语言支持（英语为主）。指出官方文档分散，需综合多处才能判断是否可上线。提出三条接入路径：Playground试措辞 → curl验证 → SDK或裸HTTP进服务。重点讲解三原语选

本文深入剖析Jev-1.13模型的官方缺陷清单，逐条拆解其九大失败模式：字面理解、数值不可靠、日期处理偏差、间接推理失效、无关信息干扰、对抗性注入、指令矛盾、恒等式不保、无法生成文本。强调其本质是“仅作结构化判断”的模型，不擅长算术、生成或解释，且存在“自信地答错”风险。建议将生成、算术、审计解释类任务交由LLM或代码处理，仅在明确判断场景使用，并严格过滤输入、校准指令。最终指出：技术选型应基于官方实证边界，而非营销话术，避免将“新范式”盲目写入架构评审。

Jev是TypeSafe推出的首个System One模型，不生成文本，而是输出带类型的决策与概率，颠覆了“一次调用返回可读文本”的传统假设。它适用于生产链路中的自动化判断，如工单分流、反欺诈等，核心优势在于结构化输出、低延迟、低成本及高可靠性。其定位并非替代编码助手，而是作为智能函数调用嵌入系统，推动机器间交互的智能化演进。

存量REST接口MCP化改造需三步：先按读写性、幂等性、副作用与用户表达度四维度盘点接口，区分可开放工具；再理解三条注册路径——@Tool复用、@McpTool显式声明、手动构造SyncToolSpecification，其差异在参数传递与上下文注入；最后通过_meta传递身份信息，确保模型调用时具备完整上下文。关键在于描述清晰、权限分级、避免过度暴露，提升模型选工具准确率。

本文提出将评估集回归纳入CI流水线，构建四层测试体系：L1单元测试（Mock模型，验证逻辑）、L2集成测试（Testcontainers启动向量库）、L3评估集测试（真模型+批量评测，监控质量退化）、L4端到端测试（真实用户路径）。通过触发规则识别关键变更（如prompt、分块参数等），自动运行评估集，以“通过率门禁”阻断质量退化。结合成本监控与失败归类（模型漂移 vs 代码回归），实现可度量、可拦截的AI应用质量保障。

本文探讨多 Agent 编排在 Spring AI 2.0.1 中的实践与挑战。指出拆分 Agent 需满足上下文预算、权限隔离、独立伸缩三条件，否则将引入链路复杂性。跨进程拓扑中，中心化编排最适业务场景；流水线需结构化输出，点对点协作难维护。针对工具箱规模化问题，Spring AI 新增 tool-search 全家桶（含 Lucene/向量索引），实现模型按需检索工具，避免 schema 爆炸。核心是：先用单 Agent + 动态工具集撑住，再依需拆分，跨进程通信依赖 MCP 或自研协议，补偿与可观测需

AI应用安全边界模糊，攻击面延伸至模型决策链。传统鉴权无法覆盖模型生成参数与工具调用场景，导致Prompt Injection、身份断链、指令伪造等风险。Spring AI 2.0.1 提供SafeGuardAdvisor关键词拦截，但仅能防简单匹配，无法识别语义或绕过字符变体，且可能误伤正常流程。真正防护需在工具层重审权限，结合ToolContext传递身份，强制人工确认关键操作，实现“模型不可信”下的安全闭环。

本文探讨从传统8字段表单向多轮对话式UX重构的可行性与技术挑战。核心观点：仅当字段多、有依赖、用户难记忆时才值得改造；简单表单应保留。关键实践包括：用结构化输出（Record + Schema）实现精准槽位抽取，追问逻辑由代码控制而非模型生成，服务端负责状态管理与校验。强调2.0版本中ChatMemory已无get(conversationId, lastN)接口，需通过构造参数配置窗口大小。最终建议采用“对话填单+表单确认”混合模式渐进落地，避免盲目追求自然语言交互。

存量系统AI化应从L1能力接入起步，优先确保结构化输出合格率、延迟与成本可度量，并完成供应商替换演练。每层需独立验收：止步层由“拿掉AI流程仍可运行”决定，错误成本高则禁用写操作。推荐“顺次叠、跳着做、倒着验”——可跳过L2直连L3只读，但必须补足评测集。最终目标不是全栈上AI，而是在可控风险下，以最小代价实现最大业务价值。

本文详解 Spring AI 2.0 结构化输出的实战应用，解决大模型自然语言输出在 Java 业务中“不可用”问题。通过 entity()、responseEntity() 及 ParameterizedTypeReference 实现精准类型转换，结合 validateSchema() 与 useProviderStructuredOutput() 两大开关，确保输出合规可消费。以智能票务助手为例，实现从对话到退票服务的端到端自动化，让模型真正参与企业流程。

Spring AI 2.0 引入强大的 Advisors 机制，解决大模型调用“黑盒”难题。通过 CallAdvisor 与 StreamAdvisor 分离设计，支持日志、校验、重读等切面逻辑。内置 SimpleLoggerAdvisor 可清晰追踪请求响应，自定义 Advisor 如“重读策略”可实现答案复核。基于 getOrder() 控制执行顺序，支持递归调用，助力开发者高效调试与增强 AI 交互。

本文解析大模型效果不佳的根源——非模型能力不足，而是提示词设计缺陷。通过Spring AI 2.0，系统阐述如何用Message分角色构建上下文、用PromptTemplate动态注入参数、自定义分隔符避免冲突，并将长提示词文件化管理。强调提示词应明确任务、结构与格式，实现从“让模型猜”到“给模型清晰指令”的转变，提升AI应用可复用性与稳定性。

Spring AI 2.0发布后，旧有1.x代码大量失效，官方文档按API组织，难以应对实际工程问题。本文专题聚焦“上线视角”，以15篇内容从最小可用客户端到Agent编排，系统解决版本断层、问题导向学习与工程化缺失三大痛点。涵盖提示词、RAG全链路、MCP复用、可观测性及五种Agent模式，强调生产可用性与可维护性，帮助开发者跳过踩坑陷阱，快速构建稳定高效的AI应用。

摘要（148字）： Spring AI Agent Utils（0.12.0）是社区孵化项目，将Claude Code的核心工具链重写为Spring AI的@Tool组件，支持文件操作、命令执行、grep、Web搜索等能力。它提供技能管理、任务编排与跨会话记忆，助力Java开发者构建真正能“干活”的Agent。虽非官方组件，但可灵活对接千问、OpenAI等模型，实现安全可控的智能体工作流。适合需自主控制工具链的Agentic应用，与Spring AI Alibaba框架形成互补。

本文详解Spring AI 2.0中Agent的五种核心编排模式：Chain、Parallelization、Routing、Orchestrator-Workers与Evaluator-Optimizer，结合实战Java代码说明其适用场景与常见陷阱。强调“是否用Agent”的关键在于任务不确定性是否值得交由模型决策，而非盲目引入智能体。通过对比工作流（Workflow）与Agent的本质差异，指出应避免在流程固定或简单逻辑中滥用Agent，推荐在任务分解依赖中间结果时使用，并提供Spring AI 2.

RAG系统上线后，模型仍会因“有据不读”“无中生有”“张冠李戴”等事实性错误出错，根源在于检索到资料≠准确回答。本文通过Spring AI内置的FactCheckingEvaluator与RelevancyEvaluator实现可量化的评测：精准提取上下文、校验事实支持度、评估相关性，并结合StructuredOutputValidationAdvisor构建闭环优化。关键在正确构造EvaluationRequest，确保判卷依据来自dataList，避免常见参数混淆。评测不仅用于回归测试，更可集成至线上监

本文详解航司客服系统中RAG、Tools与会话记忆的集成实践，聚焦1.0→2.0迁移痛点：向量库改用builder构造、@Tool注册规范、Advisor执行顺序及多租户记忆隔离。通过离线ETL灌库与在线多路协同链路设计，实现政策查询（RAG）、订单状态（Tools）与操作执行（工具调用）的无缝衔接。附完整代码与迁移对照表，支持Naive与Modular双模式切换，确保系统可落地、可维护。

本文系统解析RAG（检索增强生成）在解决非结构化知识查询中的核心作用，厘清其与Tools、微调的边界。通过完整链路拆解：向量模型选型（如DashScope、Ollama）、向量库部署（Milvus/PgVector等）、ETL管道构建及四阶段可插拔流程，强调“语义检索”依赖高质量Embedding与一致维度。重点指出：真实业务中，文档更新频繁、多租户权限隔离、长文本成本控制等问题，使RAG成为企业知识库的首选方案，且与Tools天然串行互补。2.0版本强化了检索链路稳定性与配置规范性，纠正过时模型名与实践误

MCP协议解决跨应用、跨语言工具复用难题，通过JSON-RPC统一接口实现工具标准化。相比@Tool的进程内调用，MCP支持多语言、远程服务与企业级共享，具备工具、资源、提示词三类原语。Spring AI 2.0采用三层架构，推荐使用Streamable-HTTP传输，避免过时的SSE；STDIO适合本地调试，Stateless模式则牺牲双向通信能力。正确配置与选型对稳定性至关重要，尤其注意Stateless下工具消失的隐性风险。

Spring AI 2.0 引入的 Tool Calling 机制，核心是让大模型“能动手”而非仅“会思考”。通过 ToolCallingAdvisor 将工具调用循环移入链式拦截器，实现工具、RAG、日志等组件统一可插拔。支持三种工具定义方式，强调模型需原生支持 tool_calls 协议。一次调用可能引发多轮往返，带来延迟与 token 成本上升。关键优势在于 ToolContext 可安全传递敏感上下文（如 tenantId），避免模型越权。但需警惕工具数量膨胀带来的性能损耗，以及框架内部循环逻辑对顺

大模型无状态导致对话记忆丢失，Spring AI 2.0 通过 ChatMemory 体系实现多轮对话。核心为 MessageWindowChatMemory，结合 ChatMemoryRepository 实现记忆持久化。支持内存、JDBC、Redis、Cassandra 等多种存储方案，可按用户隔离（CONVERSATION_ID），并配置消息窗口大小。生产环境推荐使用数据库或 Redis，避免重启丢失。未来将推出基于事件溯源的 Session API，ChatMemory 或将被弃用。

Spring AI 2.0 引入 ChatClient 作为高层统一接口，替代直接使用 ChatModel，支持系统提示、对话记忆、流式输出、工具调用与多模型动态切换。通过 Builder 构建，可集中配置默认系统提示、温度、日志、记忆及工具，实现代码整洁与能力复用。defaultTools() 与 tools() 语义不同，前者全局生效，后者追加；多模型场景下（如 DeepSeek、Ollama）可通过显式注入实现灵活路由，提升开发效率与可维护性。

做 AI 应用，第一步不是 RAG，也不是 Agent，而是把模型调用、流式输出、参数控制和多模态能力先跑通。Java 开发者常见的三条路径：通过 DeepSeek 使用云端模型；通过 阿里云百炼 接入通义与多模态能力；或使用 Ollama 在本地运行模型。这篇文章从零创建 Spring AI 2.0 项目，完整演示三种接入方式，以及 temperature、推理模型、流式响应与多模态的使用。

这两年 Java 开发者做 AI 应用，已经不只是调一个大模型接口这么简单了。企业数据怎么接入？工具怎么调用？RAG 怎么拆模块？Agent 工作流怎么控制？ 如果项目本身就是 Spring Boot，那么 [Spring AI](https://spring.io/projects/spring-ai) 值得重点关注。它不是训练模型的框架，而是把企业数据、业务 API 和 AI 模型连接起来的应用框架。Spring AI 2.0 的变化尤其大：升级到 Spring Boot 4 基线，同时重构了 M

2025年10月，Anthropic 推出了 Agent Skill，起初定位相当克制——只是想提升 Claude 在特定任务上的表现。那么这个让大厂纷纷跟进的 Agent Skill，到底解决了什么核心痛点？它和我们熟悉的 MCP（Model Context Protocol）又有着怎样的区别和联系？实际项目中到底该选哪一个？这篇文章从实际使用的角度，把 Agent Skill 的概念、基本用法、高级玩法（Reference / Script）、渐进式披露机制，以及和 MCP 的对比，一次性讲清楚。

AI编程工具兴起，但重复指令、输出不稳定等问题凸显。Skill作为可复用、按需加载的指令模块，有效封装复杂工作流，解决上下文浪费与团队协作难题。相比Rules、Context等，Skill以结构化方式实现高效执行与跨平台复用。当前主流平台如SkillsMP、Claude Skills Hub等提供海量公开技能，支持搜索、安装与分享。实践表明，Skill是目前最成熟的Agent能力封装方案，尤其适用于需反复执行的复杂任务，但其效果依赖高质量描述。

本文梳理了国内AI生态中的主流产品，按用户群体分为通用助手与编程工具两类。千问、豆包、元宝等面向普通用户，提供聊天、写作、图文生成等服务；而Qoder、Trae、CodeBuddy等则聚焦开发者，支持代码生成、项目理解与自动化开发。阿里系多产品并行，体现“通用+专业”双轨布局。值得注意的是，如Qoder、Trae等工具可调用多种大模型（如Qwen、DeepSeek），并非绑定单一模型，本质是AI开发平台。理解其定位差异，有助于高效选择适合自身场景的AI工具。