XIAOSUO 记录个人学习的足迹

摘要：一、Agent Skill 协议概述 1. Agent 的知识困境 假设你正在为公司开发一个 AI 助手，老板要求它能回答费用报销相关的问题： 员工: 出差期间的小费可以报销吗？ AI 助手: 一般来说，合理的小费可以报销…… ← ❌ 太模糊！ 期望回答: 根据公司政策，餐饮消费中 20% 以内的小费可以报销， 超过 $50 的单笔餐饮需要附上收据。 ← ✅ 精准！ 问题在于：模型的参数里没有你们公司的报销政策。 能力与知识的区别，我们先做一个关键区分——这是理解 Agent Skills 的基础： 能力 (Capability) 知识 (Knowledge) 含义 Agent 能做什么 Agent 知道什么 类比 给员工配一台电脑 给员工发一本操作手册 AI 例子 调用天气 API、发送邮件、执行 SQL 公司政策、操作流程、领域规范 技术手段 Function Calling / MCP Tools ??? Function Calling 解决了能做什么的问题——让 Agent 可以调用 API、查数据库、发邮件。 但知道什么呢？这正是 Agent Skills 要解决的问题。 现有方案的局限 方案 做法 问题 ❌ 塞进 System Prompt 把整个政策文档放到系统提示里 Token 浪费严重！20 个领域的知识全量加载，每次请求可能消耗数万 Token ❌ 硬编码 用 if-else 把规则写到代码里 不灵活，业务人员无法维护，改个限额就要重新部署 ⚠️ RAG 建向量索引，语义检索 对结构化的政策文档来说过于复杂，且检索结果不可控 ⚠️ 微调 (Fine-tuning) 收集数据训练模型 成本高（$10K+），周期长（数周），需要 ML 专家 我们需要一种方式：像插 U 盘一样，把领域知识按需加载给 Agent，简单、标准化、人人可维护。 2. 什么是 Agent Skills 定义：Agent Skills 是一种开放规范，定义了如何将领域知识打包为模块化、可复用的知识包，供 AI Agent 按需使用。 A simple, open format for giving agents new capabilities and exp…… 阅读全文

摘要：一、AG-UI 协议概览 1. 为什么需要 AG-UI 随着 AI Agent 技术的发展，传统的 Web 应用交互模式面临新的挑战。AI Agent 的响应具有以下特点： flowchart LR subgraph 传统API A1[请求] --> B1[处理] --> C1[响应] end subgraph AI Agent A2[请求] --> B2[思考...] B2 --> C2[工具调用] C2 --> D2[中间结果] D2 --> E2[继续思考...] E2 --> F2[流式输出] F2 --> G2[最终响应] end style A1 fill:#e1f5ff style C1 fill:#e1f5ff style A2 fill:#ffe1e1 style G2 fill:#ffe1e1 在构建 AI Agent 应用界面时，传统 API 模式面临诸多挑战： 问题 传统 API AI Agent 需求 影响 响应模式 请求/响应（阻塞等待） 流式实时响应 用户体验差，等待时间长 中间过程 无法展示 需要可视化思考/工具调用 用户无法理解 Agent 行为 状态同步 单次请求完成 需要持续状态同步 复杂 UI 状态管理困难 交互模式 确定性 UI 非确定性（Agent 决定 UI） 难以提前规划界面 长时间任务 超时问题 需要进度反馈 无法处理复杂任务 AG-UI (Agent User Interaction Protocol) 专为 AI Agent 与用户界面的交互而设计： flowchart TB subgraph AG-UI协议 direction LR Streaming[流式响应] Events[事件系统] State[状态同步] Tools[工具可视化] end UI[用户界面] -->|AG-UI 协议| AG-UI协议 AG-UI协议 -->|实时交互| Agent[A…… 阅读全文

摘要：一、A2A 协议 1. 为什么需要 A2A 协议？ 随着 AI 技术的发展，企业中的 AI Agent 数量不断增加。这些 Agent 可能来自不同的团队、不同的技术栈，甚至不同的组织： flowchart LR subgraph 企业A A1[客服 Agent] A2[销售 Agent] end subgraph 企业B B1[物流 Agent] B2[库存 Agent] end subgraph 第三方服务 C1[支付 Agent] C2[天气 Agent] end A1 -.->|如何通信?| B1 A2 -.->|如何协作?| C1 B2 -.->|如何发现?| C2 style A1 fill:#e1f5ff style A2 fill:#e1f5ff style B1 fill:#ffe1e1 style B2 fill:#ffe1e1 style C1 fill:#e1ffe1 style C2 fill:#e1ffe1 在没有标准协议的情况下，Agent 之间的互联面临诸多挑战： 问题 描述 影响 协议不统一 每个 Agent 使用不同的 API 格式 集成成本高，难以扩展 发现困难 无法自动发现其他 Agent 的能力 需要人工配置，耦合度高 状态不透明 无法追踪跨 Agent 任务的执行状态 调试困难，可靠性差 安全性参差 缺乏统一的认证授权机制 安全风险高 Agent-to-Agent (A2A) Protocol 提供了一套标准化的解决方案，核心价值： 统一发现机制：通过 Agent Card 声明和发现能力 标准化通信：基于 JSON-RPC 2.0 的统一消息格式 任务生命周期：完整的任务状态管理和追踪 流式支持：SSE 实时事件推送 安全机制：内置认证和授权方案 2. 什么是 A2A 协议？ Agent-to-Agent (A2A) Protocol 是由 Google 发起并开源的一个开放协议，旨在实现 AI Agent 之间的标准化通信与协…… 阅读全文

摘要：一、自定义工作流事件 1. 为什么需要自定义事件？ 场景 内置事件 自定义事件 粒度 Executor 级别 业务逻辑级别 语义 系统通用 (调用、完成) 业务特定 (审核通过、风险预警) 数据 执行元数据 业务数据 (敏感词、风险分数) 监控 技术监控 业务监控 + 审计 前端 通用进度条 具体业务状态展示 2. 自定义事件类定义 基本定义模式：自定义事件本质上就是继承 WorkflowEvent 的普通 C# 类。让我们从最简单的开始： /// summary /// 表示检测到敏感词的事件 /// /summary public class SensitiveWordDetectedEvent : WorkflowEvent { public SensitiveWordDetectedEvent(string word, int position) : base(data: null) // 可以传递简单数据到 base { Word = word; Position = position; } public string Word { get; } public int Position { get; } } 设计原则 DO (推荐做法)： 类名以 Event 结尾，语义清晰 使用只读属性 ({ get; })，确保事件不可变 添加 XML 注释说明事件的业务含义 属性类型尽量简单（string, int, DateTime 等可序列化类型） DON'T (避免做法)： 不要在事件类中包含方法逻辑 不要引用不可序列化的对象（如 DbContext, HttpClient） 不要使用可变属性（{ get; set; }） 不要在构造函数中执行耗时操作 3. 携带复杂数据的事件 当需要传递更复杂的业务数据时，有两种设计模式： 模式 1: 使用属性传递结构化数据 /// summary /// 风险评估完成事件 /// /summary public class RiskAssessmentCompletedEvent : WorkflowEvent { public RiskAssessmentCom…… 阅读全文