人工智能

Anthropic 官方专门写了一篇文章来解释。看完之后你会发现，这几个概念不仅不重复，反而各有分工，组合起来才能发挥完整的 AI 能力。

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 Agent Skills 的发展简史 Agent Skills 的出现，其实是 AI 能力组织方式自然演进的结果。 早期的大模型应用主要靠提示词工程，把任务规则、流程说明、输出格式全部写进 System Prompt。这种方式简单直接，但提示词越写越长，上下文窗口被大量占用，关键指令容易被淹没，而且很难在不同项目之间复用。 随后 Function Calling 和工具调用逐渐普及，模型开始能够调用搜索、代码执行、数据库查询等外部能力。但这更多解决的是"能不能调用工具"的问题，还没有很好地回答"应该按什么流程、遵循什么标准、产出什么格式"的问题。 2025 年 10 月，Anthropic 在 Claude Code 中首次推出 Agent Skills 能力，把可复用的任务流程封装成以 SKILL.md 为核心的文件夹结构。 同年 12 月 18 日，Anthropic 将 Agent Skills 规范作为开放标准发布，并开源官方技能库，随后 OpenAI Codex、GitHub Copilot、VS Code、Cursor 等产品陆续跟进支持。 到 2026 年，Agent Skills 已经从单一产品的功能扩展为跨平台的能力封装格式，公开可用的 Skills 数量逼近百万级，累计安装约 2.8 亿次。 从技术演进看，Agent Skills 标志着 AI 应用开发从"手搓提示词"走向"标准化技能工程"。它把专业知识、执行流程、脚本工具和验收标准打包在一起，让 Agent 不再只是会聊天，而是能稳定完成具体工作。 一个 Skill 长什么样 最简单的 Skill 只需要一个文件： my-skill/ └── SKILL.md 完整结构可以包含这些目录： my-skill/ ├── SKILL.md # 必需：元数据 + 指令 ├── scripts/ # 可选：可执行脚本 ├── references/ # 可选：参考文档 ├── assets/ # 可选：模板、资源 └── ... 核心文件 SKILL.md 的结构 SKILL.md 由两部分组成：YAML Frontmatter（元数据） 和 Markdown 正文（指令），用 --- 分隔。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 10.1 AI 安全风险的来源和分类 系统风险：AI 模型软件的供应链风险、暴露面风险以及算力劫持风险。 网络风险：面向公网的入侵攻击，以及内网的隔离风险。 身份风险：对非人类身份的管控，越权访问，身份冒充等。 数据风险：Agent 模型训练时的数据投毒，以及输入/输出阶段的敏感信息泄露等。 模型风险：Agent 模型输入输出内容的恶意诱导、提示词攻击等风险。 应用风险：当 AI 在线上提供服务时，会面临 Web 入侵、DDoS 攻击导致服务不可用等风险。 10.2 保护应用安全 10.2.1 背景和挑战 攻击者不再需要直接寻找暴露在公网服务中的漏洞，他们只需操纵相关的 AI Agent，就能让这些 AI Agent 代为攻击内外部的弱电服务。 服务器端请求伪造（SSRF）是引入 AI Agent 后最突出的威胁。攻击者仅需通过自然语言提示，即可诱导受信任的 Agent 向内部网络发起恶意请求，窃取云环境凭证或扫描内网资产。Agent 也可能被攻击者诱导产生包含 SQL 注入或 XSS 等恶意载荷，攻击与之交互的后端服务。 10.3.2 新的攻击面 构造恶意的语言诱导，让 AI Agent 变为一个无节制的资源消耗工具，使其无法正常为其他用户提供服务。构造复杂度炸弹式的指令，诱使 AI Agent 陷入生成海量文本的陷阱，生成数万乃至数十万的 Token，导致其自身的计算成本飙升。 攻击者也可以攻击 AI Agent 调用的外部 API，高频或海量触发复杂或昂贵的 API 调用。攻击者还能将恶意指令隐藏在 AI Agent 将要处理的网页、表格、PDF 等外部数据中，当 AI Agent 处理这些被污染的数据时，隐藏的指令就会被执行。 10.3.3 防护思路 沿用并强化传统的应用安全最佳实践，同时实施严格的资源治理策略，针对工作流劫持类攻击，则需要设计更加完善的上下文隔离机制。 10.3.4 解决建议 一方面，对在 AI 场景下输入输出做安全检测的 AI 安全护栏方案，以及相关 AI 应用开发平台和网关对 AI 安全护栏的集成。另一方面，由于 AI Agent 进一步打破了传统的攻击面和网络边界，要更加关注纵深防御、动态检测、运行时安全等多种安全措施的组合。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 9.1 基于评估降低 AI 应用的不确定性 9.1.1 从确定性到不确定性 传统软件在很大程度上是确定性的，而 AI 应用其行为本质上是非确定性和概率性的。不确定性，就意味着对于相同的输入，它们可能产生不同的输出。 传统的 QA 流程，专为可预测的、基于规则的系统而设计，已无法充分应对这些由数据驱动的、自适应系统的挑战。 9.1.2 幻觉和不确定性的根因 AI 应用的核心功能是基于从海量数据中学到的统计模式，来预测序列中的下一个词，而非真正意义上的理解。这就导致了“幻觉”现象，即模型生成听起来合理但实际上不正确或无意义的输出。 产生幻觉和不确定性的根本原因错综复杂：数据导致的缺陷、架构与建模的产物、错位与不确定性。 9.1.3 AI 评估的重要些 从服务客户上看，评估是构建信任的核心机制。从商业视角看，严格评估直接转化为竞争优势。 AI 的非确定性催生了评估经济，这是一个由可观测性平台、持续监控、自动化评估与治理即服务构成的新生态。评估不再是阶段性任务，而是与开发并行的持续工程实践，标志着 AI 原生时代质量保障的新范式。 9.2 AI 评估体系 9.2.1 评估方法的基础二分法 1、内在评估 vs 外在评估 内在评估：侧重于孤立地评估模型输出的固有质量，而不考虑其在特定任务中的应用效果。评估的维度通常包括流畅性、连贯性、语法正确性以及事实准确性。 外在评估：通过衡量模型在特定下游任务或应用中的表现来评估其质量。 2、自动化评估 vs 人工评估 自动化评估：利用计算指标或利用其他 AI 模型来对模型输出进行打分。 人工评估：依赖人类评估员的判断来评估 AI 系统的输出质量，特别是在衡量帮助性、创造力、用户满意度等主观维度时。 在实践中，最佳的评估策略通常是自动化和人工评估的混合模式，利用自动化的效率进行大规模初步筛选，并结合人工的深度洞察力对关键或模糊的案例进行精细评估。 9.2.2 从静态到动态评估的演进 静态基准：静态基准是固定的、预先定义的数据集和任务组成。 动态评估：动态评估旨在模拟真实世界场景的复杂性和不可预测性，通过变化的变量、意外的输入和演进的上下文来测试系统。主要的动态评估方法包括：基于模拟的测试、实时对抗性基准、程序化生成。 9.2.3 现代 AI 评估的多范式全景 6 个主要的评估范式：基准测试范式、“Evals”范式、心理测量学范式、人机交互范式、形式化方法范式、社会技术范式。 一个组织的评估栈，即其选择、组合和优先排序不同评估范式的策略，深刻地揭示了该组织在性能、用户价值和风险规避之间的权衡。 9.2.4 构建一个整体性的评估体系 一个完整的评估体系应包含 8 个核心组件： 性能指标，包括准确率、精确率、召回率、F1 分数等。 鲁棒性与泛化测试 偏见与公平性评估 可解释性 合理性与伦理考量 持续监控与模型飘移检测 决策框架 自动化与人在回路 9.3 基于 LLM 的自动化评估 9.3.1 传统指标的局限性 传统的自动化评估指标，其核心是基于词汇或短语的重叠度来计算分数，这种方法对于需要捕捉语义、风格、语气和创造力等细微差别的现代生成 AI 模型来说，存在根本性不足。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 8.1 AI 可观测 8.1.1 什么是 AI 可观测 AI 应用具有非确定性，即便是相同的提示，在不同次的运行中也可能产生不同的输出。如果没有可观测，在发生幻觉虚假错误等严重问题时根本无从查起。相反，一个好用的可观测工具会记录每一次的提示与响应、追踪使用模式，并标记异常。AI 可观测是确保 AI 应用高效稳定安全运行的基础能力。 8.1.2 可观测 vs 监控：从“是什么”到“为什么” 监控关注“什么”：比如 API 响应时间、错误率、请求吞吐量和 Token 使用量等指标。 可观测性探究“为什么”：比如一个聊天机器人的回答不正确且耗时过长，监控可能只会显示错误率上升或延迟过高，但可观测能揭示为什么：可能是一次长时间的 RAG 请求最终得到了错误的召回，导致模型给出不准确的答案。 AI 应用的每一次请求，都可以被弯针的追溯，包括调用工具的出入参、发送给大模型的具体提示词、任何中间步骤（如调用数据库或其他 API），以及最终收到的输出。可观测工具就可以提供极其丰富的排查数据和上下文，帮助定位问题的根因。 8.1.3 AI 可观测应对的核心挑战 性能与可靠性问题：大模型是资源密集型的，延迟峰值和瓶颈时有发生。 成本问题：许多大模型服务按 Token 使用量收费，若无控制，成本可能意外飙升。 质量问题：大模型的可能输出从训练数据中继承偏见或有害内容，也很可能产生幻觉。 8.1.4 AI 可观测解决方案的关键能力 端到端全链路追踪：提供端到端的日志采集和链路追踪，可视化请求在整个 AI 应用中的执行路径。 全栈可观测：包含应用、AI 网关、推理引擎可观测 3 个维度。 自动化评估功能：通过引入评估 Agent，对应用和模型的输入输出进行自动化的评估，检测幻觉、不一致或答案质量下降等问题。 8.2 端到端全链路追踪 一个典型的 LLM 应用架构可能包含用户终端、认证模块、会话管理、对话服务、大模型路由、流程编排等。需要具备 3 项可观测能力：标准化的数据语义规范、低成本高质量的数据采集、端到端全链路追踪。 8.2.1 端到端全链路追踪的实现方式 面向 AI 应用的领域化 Trace 语义 基于 OpenTelemetry 的高质量数据采集 标准化协议 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 7.1 AI 应用运行时的演进趋势 7.1.1 从云原生到 AI 原生 云原生时代的核心是应用。将单体应用拆解为更小、更独立、更具弹性的微服务，并高效地在云基础设施上进行部署、扩展和管理。 而 Agent 的工作流，不再是执行一段固定的 main 函数，而是一个动态的、长周期的、充满不确定性的“思考-行动”循环。需要极致弹性和成本效益。需要数小时上下文记忆、拥有完整文件系统、并能与浏览器进行复杂交互。 7.1.2 Agentic AI 应用的典型场景 场景一：交互式智能内容创作助手 对轮对话、上下文记忆、模型自托管、异构任务流、流式响应。 场景二：个性化 AI 客服 事件驱动、企业数据、实时在线。 场景三：通用 Agent 平台+病毒式传播的 AIGC 创意应用 Agent 智能体、代码执行验证、部署与分享、脉冲式流量、大文件处理。 7.1.3 AI 原生应用运行时的核心能力 1、面向会话的状态管理与安全隔离 2、大规模实时弹性与精益成本管理 3、异构算力与标准化工具连接能力 7.2 模型运行时 7.2.1 企业模型使用的核心痛点 资源浪费：业务流量波动大，高峰 10 万，平日几千，预留峰值会导致算力闲置。 冷启动：低频模型无法保持实例存活，使用时冷启动耗时长。 定制化：业务产品需要定制化，产品迭代周期长。 7.2.2 Serverless 模型运行时的核心能力 Serverless 是什么？ Serverless 不是完全没有服务器，而是开发者不需要关心服务器的管理。对于开发者来说，只需关注代码，其他的交给云平台。主流 Serverless 平台包括阿里云函数计算、腾讯云云函数等。 Serverless 和云服务器的区别？ 云服务器只是一台远程的服务器；Serverless 只上传代码片段（函数），不管服务器，当有请求触发时，代码才会运行。 1、异构算力和 1/N 卡切分使用 在算力层，Serverless 模型运行时通过 GPU 虚拟化技术将单张 GPU 显卡划分为 N 个独立计算单元，每个实例具备隔离的显存空间与算力资源，不同实例通过 GPU 分时复用技术实现并行推理。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 6.1 网关的演进历程 是什么在推动软件架构的演进呢？业务规模。业务从互联网、移动互联网以及即将到来的万物互联，其规模仍然在高速增长，也就意味着软件架构的复杂度也会越来越高，网关的特性也会越来越多。越来越复杂、越来越智能。 6.1.1 流量网关 代表软件是 Nginx，将客户请求分配到不同的服务器上，从而实现流量负债均衡，避免单点故障，确保服务的稳定性和连续性。 6.1.2 ESB 网关 ESB，企业服务总线，通过集中管理消息路由、转换和安全，实现服务的快速部署和高效运作。 6.1.3 微服务网关 微服务网关可以实现负载均衡、限流、熔断、降级、身份验证等功能，通过统一入口管理和优化各微服务间的交互。Spring Cloud Gateway 是一个广泛应用的微服务网关。 6.1.4 云原生网关 云原生网关是伴随 K8S 的广泛应用而诞生的一种创新网关。既能有流量网关的特性来处理海量请求，又具备微服务网关的特性来做服务发现与服务治理，同时要求网关也具备弹性扩缩容能力解决容量调度问题。 6.1.5 AI 网关 之前的几种类型网关处理的流量基本是以 HTTP、RPC 为主，多采用长连接，长连接采用 request-response 模式。AI 采用的协议以 SSE/Websocket 为主，虽然也是长连接，但跟 request-response 模式相比，Server 可以主动发送数据给 Client，Websocket 更是一种全双工协议，主要在语音类的实时通讯场景中使用。 AI 场景对网关有新诉求，比如：多模型代理、智能路由、模型增强、安全防护、流式传输、无损变更等。 Higress 网关已经在阿里云内部大规模生产落地，可以访问项目地址了解：https://higress.ai/ 6.1.6 API 网关 从流量网关，再到 AI 网关，都是 API 网关在不同软件架构下的网关形态。HTTP/gRPC/Dubbo/Websocket 都可以称之为 API，MCP、A2A 也可以称之为 API。 6.2 AI 网关的定义、特点与应用场景 AI 网关是提供多模型流量调度，MCP 和 Agent 管理，智能路由和 AI 治理的下一代网关。AI 网关不仅完整继承了 API 网关的通用能力，如安全认证、路由转发、流量控制等，也演进出了大模型 Fallback、大模型负载均衡、Token 级别的精细化流量管控、语义化缓存、内容安全、联网搜索、MCP 协议转化和管理、工具精选和搜索效果优化等面向 AI 场景的能力。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 5.1 AI 工具简介 5.1.1 Function Calling Function Calling 需要编写代码，并且存在规格碎片化、可靠性挑战、工程治理缺位、厂商锁定与迁移成本高等问题。 5.1.2 MCP MCP，Model Context Protocol，模型上下文协议，是一个开放标准，帮助连接 AI 助手与数据所在的系统，包括内容存储库、业务工具和开发环境。 MCP 可以看作是 AI 应用程序的“USB-C 端口”，就像 USB-C 为连接设备与各种外设提供了标准化方式，MCP 为 AI 模型连接不同数据源和工具提供了标准化方法。 MCP 把工具（Tools）、资源（Resources/用于检索与长上下文读写）、提示（Prompts）、会话（Sessions）、取样/推理（Sampling）等能力统一纳入协议语义，并标准化“枚举-描述-请求-响应-权限-审计”的全链路。传输层上，MCP 不限定具体载体，既可以通过 HTTP/WebSocket，也可以通过 stdio 等方式交换消息。 5.1.3 MCP 就足够了吗 无论是 RAG、Function Call 还是 MCP，其实都是为了让模型获取更多知识，调用更多工具来完成更复杂的事情。MCP 并不是万能的，短期内存在不确定性与不同声音，国内是否成为事实标准亦未定。以 MCP 为协议底座，叠加 AI 工具接入的最佳实践与企业级安全治理，才能把“可接入”变成“可规模、可移植、可审计”的 Agent 能力。 5.2 AI 工具标准化 5.2.1 MCP 协议介绍 MCP 协议遵循客户端-服务器（Client-Server）架构，允许 AI 应用程序通过 MCP 客户端与多个 MCP 服务器建立连接。MCP 架构包含以下几个部分： MCP Host：协调和管理一个或多个 MCP 客户端的 AI 应用程序，如 Claude Desktop、Visual Studio Code 等，需要通过 MCP 协议访问数据。 MCP Client：MCP 客户端，运行在 MCP Host 内部，负责与 MCP Server 建立并维护连接。MCP Host 会为每一个 MCP Server 单独创建一个 Client，Client 与 Server 保持一对一连接。 MCP Server：MCP 服务器，轻量级程序，通过 MCP 协议公开特定功能。MCP 协议规定了 MCP Server 可为 Client 提供工具、资源文件以及提示词模板。 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 4.1 提示词工程 提示词工程，不是简单的提问，而是一套涵盖指令设计、上下文注入、角色设定和格式控制的综合性技术。 4.1.1 优秀提示词的核心实践 明确角色与目标 范例：“假设你是一位拥有 10 年经验的市场营销总监，请为一款新型智能手表起草一份面向年轻专业人士的产品介绍文案。” 提供清晰指令与完整上下文 范例：“请总结以下技术文章的核心观点（不超过 200 字），并列出其中提到的三个关键数据。不要添加个人评论。文章内容如下：[在此处粘贴文章]” 运用范例进行引导 范例：“请分析以下句子的情感及关键对象。范例：输入：‘我喜欢这部电影的剧情。‘输出：{‘sentiment’: ‘positive’, ‘aspect’: ‘plot’}。现在，请分析这个句子：‘这台相机的画质很棒，但电池续航太短。’” 定义结构化输出格式 范例：“请将你的回答组织成 JSON 格式，包含’product_name’和’key_features’两个字段，其中 key_features 是一个包含至少三项功能的数组。” 4.1.2 提示词工程的固有局限性 应对动态及长流程任务的局限 应对模型固有的无状态特性 无法突破模型固有的知识边界 长上下文中的信息利用不均衡 正是因为提示词工程有诸多局限性，上下文工程（Context Engineering）应运而生。 4.2 上下文工程 上下文工程的核心理念，在于将 AI 应用开发的焦点从优化单次交互的指令，转向为模型的每一次推理动态构建一个完整、准确且高效的认知环境。它不再局限于设计静态的提示词模板，而是致力于创建一个系统，确保模型在执行任务时，能够实时获取并利用完成该任务所需的所有相关信息，包括外部知识、历史记忆、可用工具及执行环境。 4.2.1 上下文工程与提示词工程的核心区别 4.2.2 上下文工程的关键组成部分 外部知识库的动态供给 长期与短期记忆系统 工具与能力的扩展 运行时的上下文管理 4.3 RAG 技术原理与挑战 4.3.1 RAG 的基础范式：三阶段工作流 1、第一阶段：索引（Indexing） 将原始的外部知识转化为机器可高效检索的格式。文档解析与提取，文本分块（Chunking），语义向量化（Embedding），构建向量索引库。 2、第二阶段：检索（Retrieval） 根据用户的自然语言查询，从已构建好的向量索引库中，快速、准确地找出最相关的 N 个知识块（Top-K）。 3、第三阶段：生成（Generation） 将前一阶段检索到的多个相关知识块与用户的原始查询进行整合，构建一个增强的提示词（Augmented Prompt）。比如： 4.3.2 RAG 在工程化落地中面临的挑战 知识单元的完整性与信息密度的抉择 难以精准捕捉模糊、多样的用户意图 召回匹配时难以兼顾语义相关性与关键词精确性 需要探索如何在检索精度与完整性之间取得平衡 应对需要多知识点综合推理的查询实现 ...

本书作者：测试开发刚哥，文章版权归个人所有，未经授权请勿转载。 3.1 智能体的定义与主流开发范式 3.1.1 什么是智能体 智能体（Agent）可以理解为一个具备自主理解、规划、记忆和工具使用能力的数字化实体。 我们在前面了解到 LLM、MCP，它们和 Agent 是啥关系呢？LLM 是“大脑”，Agent 是“身体”，Agent 通过 MCP 协议访问外部能力（Tools / Resources）。 【纯LLM交互】 用户：帮我分析main.py文件 LLM：我无法直接访问文件，请您将文件内容粘贴给我 【Agent交互】 用户：帮我分析main.py文件 Agent：我来读取并分析这个文件 → 调用文件读取工具 → 分析代码结构 → 提供详细分析报告 智能体让 AI 从一个只会内容生成的语言模型，进化成一个具备自主规划能力的行动者。 3.1.2 智能体的主流开发范式 简单 LLM 应用：直接调用模型 API 实现内容生成 单智能体：增加 RAG、Tool、Memory 等，让模型具备与特定环境交互的能力 工作流：将应用拆分，形成多个独立子智能体，再按照预定义的流程编排起来 多智能体系统：相比于工作流，多智能体系统采用的是模型驱动的、对话式的流程编排，各个子智能体具备更多的自主决策权 3.1.3 单智能体 典型的单智能体架构如下： 单智能体非常依赖底层模型能力。 3.1.4 工作流 1、Chain - 链式工作流 每一步由一个独立的 LLM 调用完成，并将上一阶段的输出作为下一阶段的输入。 2、Routing - 路由工作流 对输入进行分类，将它们分派到专门设计的下游任务或处理路径。 3.1.5 多智能体系统 由多个具备一定自治能力的 Agent 组成，每个 Agent 有自己的角色、能力或工具使用范围。它们之间可以通过消息或上下文进行交互，协同完成复杂目标。 ...