erpan's note

AI Agent编排范式

Fri, 06 Feb 2026 18:50:00 +0800

AI Agent编排范式

范式主要整理自Eino框架，文中有些概念仅属于Eino框架

引言

AI应用的核心任务极为简单：

接收指令
调用大模型
安全地执行工具（运行命令、操作文件、控制浏览器）
之后将结果反馈给你

三个关键原则，是解决一切花哨问题的基础：

执行是能控制的
状态是能追溯的
失败是能复盘的

AI应用的核心任务，即ReAct模式，通过让 ChatModel 进行显式的、一步一步的"思考"来解决复杂问题，在Eino ADK中将其直接抽象为ChatModelAgent了。在不同的领域、不同的场景下有各种各样的模型，也有各种各样的Agent来处理专有领域的任务，如Coding模型、视觉模型等。一个复杂的任务通常需要调用各种能力的模型和各种工具来完成任务，这就需要把这些拥有专有能力的Agent编排起来组成一个功能完善、强大的应用。

AI Agent编排范式分类

AI Agent编排范式大概分为以下几类：

    mindmap
  root((AI Agent编排范式))
    Eino框架原生范式
      基础编排层
        Chain链式编排: Graph的封装，除了 "环" 之外，Chain 暴露了几乎所有 Graph 的能力。线性单向流/简单任务
        Graph图编排: 支持pregel和dag模式/分支/并行/循环/复杂逻辑
        Workflow工作流编排: DAG模式，字段级别映射，控制流/数据流分离
        图嵌套：Eino中的chain、graph、workflow都可以嵌套进图
      Agent编排
        ChatModelAgent: 智能决策大脑，实现ReAct模式，LLM交互核心
        Workflow Agents: 流程协调
          Sequential Agent: 串行执行按顺序流转，如CI/CD流水线，数据ETL
          Parallel Agent: 并行执行/共享输入/结果聚合，如多源数据采集、多渠道推送
          Loop Agent: 循环执行/结果积累/条件退出，数据同步、压力测试
        Custom Agent: 可高度定制
      预构建Multi-Agent
        Plan-Execute Agent: 规划-执行-重规划，结构化解决复杂任务，如复杂任务研究，智能助理任务执行
        Supervisor Agent: 监督者统筹/子Agent分工/汇总决策
        DeepAgents: 规划驱动集中协作，强化拆解与上下文隔离
        
    通用行业主流范式
      经典协作模式
        Master-Slave（主从）: 主Agent分配任务/从Agent执行/无自主决策
        Swarm（蜂群）: 无中心/Agent自主协作/去中心化/高容错
        Hierarchical（层级）: 多层级Agent/上层决策/下层执行/复杂系统
        Peer-to-Peer（对等）: 平级Agent/自主协商/资源共享/无核心节点

详细编排范式解析

1. 基础编排层

Chain（链式编排）

定义: Graph的封装，除了"环"之外，Chain暴露了几乎所有Graph的能力，适用于线性单向流/简单任务
使用场景:
- 数据处理流水线（如ETL过程）
- 顺序执行的任务链
- 简单的工作流程

Graph（图编排）

定义: 支持Pregel和DAG模式，能够处理分支、并行、循环等复杂逻辑
使用场景:
- 复杂业务逻辑处理
- 需要条件分支和循环的任务
- 并行计算任务

Workflow（工作流编排）

定义: DAG模式，不支持环，支持字段级别映射，强调控制流和数据流分离
使用场景:
- 数据集成和转换
- 需要精确字段映射的场景
- 复杂的数据处理管道

2. Agent编排层

ChatModelAgent

定义: 智能决策大脑，实现ReAct模式，是LLM交互核心
使用场景:
- 需要推理和决策的场景
- 自然语言交互
- 复杂问题分解

Workflow Agents

Sequential Agent

定义: 串行执行按顺序流转
使用场景:
- 研究报告撰写流程
- CI/CD流水线
- 数据提取、转换和加载(ETL)

    flowchart LR
  subgraph one[Sequential Agent]
    PlanAgent[Plan Agent<br/>制定研究计划] --> WriteAgent[Write Agent<br/>撰写学术报告]
  end
    Start[开始研究主题] --> one
    one --> End[结束]

Parallel Agent

定义: 并行执行/共享输入/结果聚合
使用场景:
- 多源数据采集
- 并行数据分析
- 多渠道信息收集

    flowchart LR
  subgraph p[彼此之间无需交互，功能边界清晰]
    a[Stock Data Collection Agent<br/>股票数据采集]
    b[News Data Collection Agent<br/>新闻数据采集]
    c[Social Media Info Collection Agent<br/>社媒信息采集]
    d[聚合]
  end
    Start[开始] --> a
    Start --> b
    Start --> c
    a --> d
    b --> d
    c --> d
    d --> End[结束]

Loop Agent

定义: 循环执行/结果积累/条件退出
使用场景:
- 解决方案优化迭代
- 数据同步、压力测试
- 反馈循环改进

    flowchart LR
  subgraph loop[反思迭代]
    a[Main Agent<br/>生成初步解决方案] --> b[Critique Agent<br/>质量审查/反馈改进]
    b -->|结果不满意<br/>MaxIteration=5| a
  end
    Start[开始] --> loop
    loop -->|结果满足| End[结束]

3. 预构建Multi-Agent范式

Plan-Execute Agent

定义: 规划-执行-重规划，适合需要多步骤推理、动态调整和工具集成的复杂任务场景
使用场景:
- 复杂研究任务
- 需要多步规划的项目
- 动态任务调整

    flowchart TD
    A[1. UserInput] --> B[Planner]
    B -->|2. 生成具体的计划步骤| C[Plan Steps<br/>1. ...<br/>2. ...<br/>3. ...]
    C -->|3. 执行计划的第一步| D[Executor]
    D -->|4. 传达当前的计划和第一步运行的结果| E[Replanner]
    E -->|5a. 评估并生成已调整的新计划<br/>交给Executor执行新计划的第一步| D
    E -->|5b. 评估任务执行的完成情况<br/>或达到最大迭代次数| F[End]

Supervisor Agent

定义: 监督者统筹/子Agent分工/汇总决策
使用场景:
- 多Agent任务分配和管理
- 动态任务路由
- Agent间的协调

    flowchart LR
        subgraph subagents
                a[Agent1]
                b[Agent2]
                c[Agent3]
        end

        s[Supervisor Agent] <--> |dispatch mission</br>return result| a
        s <--> |dispatch mission</br>return result| b
        s <--> |dispatch mission</br>return result| c
        s --> Exit

Layered-Supervisor

使用场景: 多层级任务管理和动态路由

    flowchart LR
    TopSupervisor[Supervisor Agent<br/>顶层监督者-动态路由] --> Research[Research Agent<br/>信息检索]
    TopSupervisor --> MathSuper[Math Agent<br/>中层监督者-数学运算]
    MathSuper --> Subtract[Subtract Agent<br/>减法运算]
    MathSuper --> Multiply[Multiply Agent<br/>乘法运算]
    MathSuper --> Divide[Divide Agent<br/>除法运算]

DeepAgents

定义：规划驱动的集中式协作，Main Agent 统一协调下的 Multi-Agent 模式
流程：
1. 通过 WriteTodos 将用户目标拆解为结构化待办并记录进度
2. 通过统一入口 TaskTool 选择并调用对应的 SubAgent 执行子任务；主/子代理上下文隔离，避免中间步骤污染主流程。
3. 汇总各子代理返回的结果；必要时再次调用 WriteTodos 更新进度或进行重规划，直至完成。
适用场景：
- 多角色协作的复杂业务流程，集中委派子任务并统一汇总
- 严格上下文隔离的执行环境

    flowchart TD
    subgraph MainAgent
        ChatModel[ChatModel]
        subgraph Tools
            WriteTodos[WriteTodos]
            TaskTool[TaskTool]
            CustomTools[CustomTools]
        end
    end
    subgraph SubAgents
            GeneralPurpose[GeneralPurpose]
            CustomSubAgents[CustomSubAgents]
        end

    ChatModel -->|Reasoning & Action| Tools
    Tools --> ChatModel

    TaskTool -->|Delegate Tasks| SubAgents
    SubAgents -->|Return Results| TaskTool

4. 其他主流范式

Master-Slave（主从模式）

定义: 主Agent分配任务/从Agent执行/无自主决策
使用场景:
- 任务分配明确的系统
- 标准化执行任务
- 控制权集中的场景

Swarm（蜂群模式）

定义: 无中心/Agent自主协作/去中心化/高容错
使用场景:
- 去中心化系统
- 高容错需求
- 自适应环境

Hierarchical（层级模式）

定义: 多层级Agent/上层决策/下层执行/复杂系统
使用场景:
- 大型复杂系统
- 分层决策机制
- 组织化任务分配

Peer-to-Peer（对等模式）

定义: 平级Agent/自主协商/资源共享/无核心节点
使用场景:
- 平等协作环境
- 资源共享
- 无单点故障需求

选择编排范式

任务复杂度

简单 → Chain/Sequential
中等 → Graph/Workflow
复杂 → Plan-Execute/Supervisor

执行模式

顺序 → Chain/Sequential
并行 → Parallel
迭代 → Loop
动态调整 → Plan-Execute

总结

AI Agent编排范式的选择需要根据具体的应用场景、任务复杂度和系统需求进行综合考虑。无论选择哪种范式，都需要遵循"执行可控、状态可追溯、失败可复盘"的原则，确保系统的稳定性和可维护性。

基于Eino框架理解大模型工具调用

Fri, 18 Apr 2025 20:19:19 +0800

函数调用 Function Calling

Function Calling 是一种将大模型与外部工具和 API 相连的关键功能，大模型能够将用户的自然语言智能地转化为对特定工具或 API 的调用，从而高效满足各种场景需求，如动态信息查询、任务自动化等

工具调用的一般步骤：

应用程序将用户问题和tools列表一起发送给大模型，tools列表表明模型可以调用的工具
LLM 对用户意图进行分析，决定是否需要使用工具以及使用哪些工具

a. 无需工具则生成回答响应给应用程序

b. 需要调用工具输出工具名和参数信息响应给应用程序
应用程序解析模型响应
1. 有工具调用，则调用工具并将调用结果和之前的消息记录一并发给模型，继续处理
2. 无工具调用，继续处理程序逻辑或直接给用户
循环上面步骤，达到结束条件则会话完成

火山引擎文档中有一张图多轮工具调用的逻辑图，可以辅助理解多轮工具调用

MCP

官网 https://modelcontextprotocol.io/

MCP（Model Context Protocol）即模型上下文协议，与 function calling（函数调用）都是实现大语言模型与外部系统交互的关键技术概念

MCP 主要负责规范化函数的具体执行过程，为 AI 模型和外部数据源或工具之间建立统一的通信接口。

二者的关系表现为 function calling 是 MCP 生态下的一种具体功能实现形式。function calling 为 MCP 提供了函数调用的指令来源，而 MCP 则为 function calling 生成的指令提供了标准化的执行框架，确保这些指令能够在不同的外部系统中可靠地执行。

MCP也可以简单理解为function的共享，因此MCP开源社区在最近几个月都非常活跃。

MCP遵循CS架构（Client-Server），几个核心概念：

主机（Host）：通常是发起连接的 LLM 应用程序，如 Claude Desktop、IDE 插件等，负责管理客户端实例和安全策略
客户端（Client）：位于主机内，是主机与服务器之间的桥梁，与服务器建立 1:1 会话，处理协议协商和消息路由等
服务器（Server）：是独立运行的轻量级服务，通过标准化接口提供特定功能，如文件系统访问、数据库查询等

核心架构这块参考官方文档 https://modelcontextprotocol.io/docs/concepts/architecture

传输机制

MCP的client-server间传输层协议当前有两种，都使用JSON-RPC2.0作为消息交换格式：

Stdio

进程间通信
适用于命令行等同服务器通信

Client将Server作为子进程启动，Server从其标准输入（stdin）读取 JSON-RPC 消息，并将消息发送到其标准输出（stdout）。Server可以将 UTF-8 字符串写入其标准错误（stderr）以进行日志记录，Client可以捕获、转发或忽略此日志记录。Server不能向其 stdout 写入任何不是有效 MCP 消息的内容，Client不能向Server的 stdin 写入任何不是有效 MCP 消息的内容。

实现一个MutatingAdmissionWebhook

Tue, 18 Jun 2024 19:25:16 +0800

官方文档

概述

在 Kubernetes 中，准入控制是保障 API 请求安全和合规性的重要机制。它在 API 请求流程中扮演着关键角色，拦截即将发送到 Kubernetes APIServer的请求，在持久化之前，但在身份验证和授权之后。其位置如下图所示：

图片来源https://sysdig.com/blog/kubernetes-admission-controllers/

准入控制器适用于创建、删除或修改对象的请求，同时也可以阻止自定义动作。读操作会绕过准入控制层，不会受到准入控制器的影响。当有多个准入控制器存在时，它们会依次被调用，只要其中一个准入控制器拒绝请求，整个请求就会被立即驳回。

准入控制常常被用来自动化设置默认资源请求和限制、应用标签和注释以及强制命名约定等管理任务。

准入控制分两个阶段：

变更准入控制器，用于在请求处理过程中对对象进行修改。
验证准入控制器，负责验证请求是否符合特定规则。

需要注意的是，部分控制器兼具变更准入和验证准入的功能。

启用准入

`1`	`kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...`

关闭准入

`1`	`kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ...`

准入的两种类型：

静态准入：由 Kubernetes 内置提供，无需额外配置。
动态准入：允许用户根据自身需求进行扩展。

动态准入控制器：

MutatingAdmissionWebhook

此准入控制器调用任何与请求匹配的变更（Mutating） Webhook。匹配的 Webhook 将被顺序调用
ValidatingAdmissionWebhook

此准入控制器调用与请求匹配的所有验证性 Webhook。匹配的 Webhook 将被并行调用。如果其中任何一个拒绝请求，则整个请求将失败。该准入控制器仅在验证（Validating）阶段运行
ValidatingAdmissionPolicy

验证准入策略使用通用表达语言 (Common Expression Language，CEL) 来声明策略的验证规则，是一种声明式的、进程内的验证准入 Webhook 方案
MutatingAdmissionPolicy

提供了一种声明式的、进程内的方案，可以用来替代变更性准入 Webhook

实现

步骤概览

实现一个 MutatingAdmissionWebhook 主要包括以下几个步骤：

生成证书，Kubernetes 和 Webhook 服务使用 TLS 加密通信
1. APIServer对Webhook的认证
2. Webhook对APIServer的认证（可选）
实现一个接口，接收AdmissionReview请求，解析并填充response字段，响应相同版本的AdmissionReview
部署上面接口，集群内外都可以
注册准入控制器
监控 Admission Webhook

以下面需求为例：

OAuth 2.0 与 OpenID Connect

Sat, 15 Jun 2024 18:52:06 +0800

在现代身份认证与授权体系中，OAuth 2.0 和 OpenID Connect（OIDC）经常被一起提及，但它们解决的是不同层面的问题。理解两者的区别和协作关系，是构建安全、标准的身份系统的关键。

是什么？

OAuth 2.0 不是身份验证协议，而是一个授权框架，允许第三方应用在用户授权下访问受保护资源，而无需获取用户密码。

OpenID Connect（OIDC）是一种基于OAuth 2.0协议构建的‌身份认证标准‌，旨在为现代应用程序提供简单、安全且可互操作的用户身份验证方式。它通过在OAuth 2.0的授权框架之上添加一个身份层，解决了OAuth 2.0本身不完善的身份认证问题。

重要区分：

OAuth 2.0 = 授权

OpenID Connect = 身份认证+授权

OAuth2.0授权流程

OAuth2 定义了好几种授权模式，有Authorization Code、Client Credentials、Device Code、Implicit Flow和Password Credentials，隐式流和密码凭据模式被认为是不安全的，不推荐使用。

核心角色：

角色	描述
Resource Owner（资源所有者）	通常是用户自己
Client（客户端）	请求访问用户资源的应用（Web、移动、单页应用SPA 等）
Authorization Server（授权服务器）	颁发令牌（如 Casdoor、Keycloak、Google OAuth）
Resource Server（资源服务器）	托管用户数据（如 API 服务），接受并验证访问令牌，以确定请求是否合法

授权码模式（Authorization Code Flow）

适用于：服务器端 Web 应用、移动 App、单页应用SPA(配合 PKCE 使用)

    sequenceDiagram
    participant User as 用户
    participant Client as 客户端
    participant AS as 授权服务器
    participant RS as 资源服务器

    User->>Client: 访问应用
    Client-->>User: 重定向至授权服务器<br>(client_id, redirect_uri, scope, state, code_challenge)
    User->>AS: 登录并同意授权
    AS-->>User: 重定向回客户端<br>(?code=xxx&state=yyy)
    User->>Client: 浏览器携带授权码
    Client->>AS: POST /token<br>(code, client_id, client_secret*, code_verifier)
    AS-->>Client: 返回 access_token (+ refresh_token)
    Client->>RS: GET /api/data<br>Authorization: Bearer <access_token>
    RS-->>Client: 返回受保护资源

流程

磁盘IO类型

Tue, 18 Apr 2023 21:55:06 +0800

仅作为个人笔记，不保证完全的准确性和正确性，请自行甄别

顺序写

文件IO中的“顺序写”通常指的是对文件进行连续写入操作的过程，即从文件的一个位置开始，依次向后写入数据，即追加。可以提高写入效率，尤其是在传统的机械硬盘（HDD）上，因为不需要频繁地在不同的位置之间切换，减少了寻道时间和旋转延迟。

需要注意的是，“顺序写”并不直接等同于物理磁盘上的连续空间写入。虽然理想情况下，操作系统和文件系统会尽量将文件的数据块分配到物理上连续的存储空间中，以提高读写性能，但实际上由于多种因素（如文件系统的碎片、先前删除文件留下的空洞、以及其他文件的存在等），很难保证文件的所有部分都能被分配到完全连续的物理空间中。因此，通常说的“顺序写”，更多是指逻辑上的连续写入，即按照文件内部的偏移量顺序写入数据，而不是指物理磁盘上的连续写入。

即，“顺序写”主要关注的是逻辑层面的连续性，而物理层面的连续性则是文件系统和操作系统尽力优化的结果。

示例

顺序写：

package main

import (
  "fmt"
  "os"
)

func main() {
  fileName := "t.bin"
  fileSize := 1 << 30 // 1GB  1073741824
  // fileSize := 1073741825 // 测试不按照块的倍数写

  // 创建并截断文件（直接分配空间）
  file, err := os.Create(fileName)
  if err != nil {
    fmt.Println("Error creating file:", err)
    return
  }
  defer file.Close()

  fInfo, err := file.Stat()
  if err != nil {
    fmt.Println("Error getting file size:", err)
  }
  fmt.Println("create: ", fInfo.Size())

  err = file.Truncate(int64(fileSize))
  if err != nil {
    fmt.Println("Error truncating file:", err)
    return
  }
  fInfo, _ = file.Stat()
  fmt.Println("truncate: ", fInfo.Size())

  randomBlock := make([]byte, 0x1<<10<<2) // 4kB
  for i := 0; i < len(randomBlock); i++ {
    randomBlock[i] = 0x0
  }

  bytesWritten := 0
  for i := 0; i < fileSize; i += len(randomBlock) {
    n, err := file.Write(randomBlock)
    if err != nil {
      fmt.Println("Error writing to file:", err)
    }
    fmt.Println(n)
    bytesWritten += n
  }
  file.Sync()
  fmt.Println("written: ", bytesWritten)
  fInfo, err = file.Stat()
  if err != nil {
    fmt.Println("Error getting file size:", err)
  }
  fmt.Println("finally: ", fInfo.Size())

  // 文件指针在末尾
  n, err := file.Read(randomBlock)
  fmt.Println("read nums: ", n)
  fmt.Println("err: ", err)
}

输出：

golang context包用法理解

Tue, 15 Feb 2022 20:13:06 +0800

简要理解其用法

ArgoCD试用

Mon, 10 Jan 2022 22:05:12 +0800

ArgoCD

遵循GitOPS模式，应用定义、配置和环境等都应该是声明式和版本化的。应用部署和生命周期管理是自动化、可审计和易于理解的

特性

拥有GitOPS的一切特性，如回滚到任意git commit点
自动发布应用到指定环境，支持多集群管理
支持多种配置管理工具、模板 (Kustomize，Helm， Jsonnet， plain-YAML，自定义配置管理插件)
支持单点登录 (OIDC, OAuth2, LDAP, SAML 2.0, GitHub, GitLab, Microsoft, LinkedIn)
支持多租户及RBAC授权
服务健康状态分析
资源版本偏移检查和Web UI实时可视化
可自动或手动同步资源到目标状态
提供命令行工具，自动化集成简单方便
Webhook 集成 (GitHub, BitBucket, GitLab)
支持访问令牌
支持各阶段钩子定义PreSync, Sync, PostSync hooks to support complex application rollouts (e.g.blue/green & canary upgrades)
应用事件和API调用审计追踪
有暴露Prometheus 指标
Parameter overrides for overriding helm parameters in Git

几个核心概念

Application：指定manifest路径下的一组kubernetes资源，是一个CRD
AppProject：Application的逻辑分组，可以配置一些约束选项，如限制git源、目标集群、namespace和资源类型等，也可以订阅project roles
App of Apps：官网文档中的 cluster bootstrapping，一个Application包含多个子Application，在批量创建Application时比较有用，也可以用来自我管理（官方文档有示例）

下图是定义了一个Application对象，其指定的仓库目录下包含多种资源，其中的子Application对象所指定的仓库目录又可以包含多种资源，我们可以开启递归的选项，在往仓库添加资源对象的时候自动apply到对应集群当中去

注意点：

一个ArgoCD实例中，Application名字是唯一的，且只能放在与argo部署的同一名称空间中
Application中没有指定resources-finalizer.argocd.argoproj.io终结器，在删除Application的时候是不会删除它所管理的资源，App of Apps也是一样

ApplicationSet

跨集群和仓库灵活的管理Applications，补充了以集群管理为中心的场景

client-go RingGrowingBuffer 环形缓冲区

Mon, 11 Oct 2021 22:27:36 +0800

在client-go源码中，processorListener对象里面定义了一个RingBuffer用于缓存所有尚未分发的事件通知，在此记录下这个RingBuffer。

RingBuffer一般用于数据的缓存机制，例如tcp协议里面数据包的缓冲就利用到了RingBuffer。

client-go中的这个buffer是非线程安全、可增长、无边界的先进先出环形缓冲区。环是一个逻辑上的概念，有了环，此段内存空间就可以重复利用，不用频繁重新申请内存，本质上数据还是存在数组里面的，这个数组的大小可以按需进行倍数扩容，扩容后需要重新分配内存空间并拷贝未消费的数据到新数组来。因为它是数组，内存是预先分配的，数组是内存上连续的一段空间，它有一个容易预测的访问模式，因此对CPU高速缓存友好，垃圾回收（GC）在这种情况下也不用做什么。

在实现上，可以理解为两个指针：a) 读指针、b)写指针。在一段buffer上，读指针控制下一次该读数据的位置，写指针控制下一次该写数据的位置。在数组里面我们可以直接用数组下标。要遵循FIFO原则，读指针不能超过写指针，两指针重叠了要么buffer写满了，要么buffer为空。

参考这里的一张图

目前我们只需要考虑：

存储啥数据类型
数据如何存放
何时空间满了需要扩容
不能丢失未消费数据

k8s中的源码：

// 源码路径k8s.io/utils/buffer/ring_growing.go

package buffer

// 非线程安全、可增长的环形缓冲区
type RingGrowing struct {
    data     []interface{} // 存任意数据的数组
    n        int // 缓冲区大小
    beg      int // 第一个可用的元素位置索引
    readable int // 未消费的元素数量
}

// 初始化一个RingBuffer
func NewRingGrowing(initialSize int) *RingGrowing {
    return &RingGrowing{
        data: make([]interface{}, initialSize),
        n:    initialSize,
    }
}

// 取出未消费元素中的第一个元素
func (r *RingGrowing) ReadOne() (data interface{}, ok bool) {
    if r.readable == 0 {
        return nil, false
    }
    r.readable--
    element := r.data[r.beg]
    r.data[r.beg] = nil // Remove reference to the object to help GC
    if r.beg == r.n-1 {
        // 这种情况就是读到数组最后一个元素了，下次读就得从列表的头部开始，以免越界
        r.beg = 0
    } else {
        r.beg++
    }
    return element, true
}

// 在buffer尾部添加一个元素，buffer满了就扩容
func (r *RingGrowing) WriteOne(data interface{}) {
    // 满了的情况
    if r.readable == r.n {
        newN := r.n * 2
        // 新开辟一个两倍大小的数组
        newData := make([]interface{}, newN)
        to := r.beg + r.readable
        if to <= r.n {
            copy(newData, r.data[r.beg:to])
        } else {
            // 未消费的元素在数组两端的情况
            copied := copy(newData, r.data[r.beg:])
            copy(newData[copied:], r.data[:(to%r.n)])
        }
        r.beg = 0
        r.data = newData
        r.n = newN
    }
    r.data[(r.readable+r.beg)%r.n] = data
    r.readable++
}

client-go中的这个buffer是非线程安全、可增长、无边界的先进先出环形缓冲区，因此，在此client-go ringBuffer基础上可以继续考虑下面几个问题：

信号和容器关闭

Thu, 10 Jun 2021 23:36:38 +0800

前提概要

信号概念

进程间通信

socket
消息队列
管道：类似瀑布开发模式
共享内存
信号量：一般和共享内存一起使用
信号：应急事件、通知

信号，一般是异常情况下的工作模式（其他几种通信方式是常规情况下的），是进程间通信唯一一种异步通信方式，即可以在任何时候发送信号给一个进程。

为了响应各种各样的事件，定义了下面64种信号：

[root@whatfuck ~]# kill -l
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
 6) SIGABRT      7) SIGBUS       8) SIGFPE       9) SIGKILL     10) SIGUSR1
11) SIGSEGV     12) SIGUSR2     13) SIGPIPE     14) SIGALRM     15) SIGTERM
16) SIGSTKFLT   17) SIGCHLD     18) SIGCONT     19) SIGSTOP     20) SIGTSTP
21) SIGTTIN     22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO       30) SIGPWR
31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3
38) SIGRTMIN+4  39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9  56) SIGRTMAX-8  57) SIGRTMAX-7
58) SIGRTMAX-6  59) SIGRTMAX-5  60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2
63) SIGRTMAX-1  64) SIGRTMAX

对收到的信号有三种处理方式

为普通用户授权生成kubeconfig

Mon, 09 Nov 2020 16:56:00 +0800

本文主要说明如何让普通用户通过证书认证授权的方式访问kubernetes集群资源

Nginx优化

Sun, 02 Aug 2020 21:57:04 +0800

参考：https://www.nginx.com/blog/tuning-nginx/

nginx一般用作高性能反向代理。在http七层代理的情况下，它首先接收客户端请求，经过处理后再请求upstream server，因此nginx服务器上的连接数是客户端请求数的2倍，在高并发情况下，建立的连接数非常多，因此系统相关资源如打开文件数、tcp连接、可分配端口等很可能称为其瓶颈。可以从系统内核参数及nginx自身做一些优化。下面提到的相关参数按需调整。

bash中alias不生效

Fri, 12 Jun 2020 21:55:04 +0800

alias不生效

在修改一段shell脚本时，需要将函数里面的kubectl命令替换为kubectl --insecure-skip-tls-verify=True，使得脚本中的所有kubectl命令执行时会自动加上选项--insecure-skip-tls-verify=True。首先想到的就是利用alias别名，示例如下：

function func1(){
    ...
    kubectl get deployment -n ${NAMESPACE} ${CI_PROJECT_NAME}  # 不生效
    ...
}

...

function main(){
    ...
    alias kubectl="kubectl --insecure-skip-tls-verify=True"
    kubectl get ns # 不生效
    ...
}

但是用上面方式改来改去kubectl选项不生效。

原因是：alias不能直接在同一个命令解析单元里面定义并使用，必须在定义alias的命令解析单元解析执行完成后，才能生效。

因此，在函数里面使用alias时，可以用下面函数的方式：

function main(){
    kubectl() { /usr/bin/kubectl --insecure-skip-tls-verify=True "$@"; }
    kubectl get ns # 此处等同于kubectl加了--insecure-skip-tls-verify=True选项
}

当然也可以把alias放在函数外、脚本的前面。

读redis-py客户端源码

Fri, 06 Mar 2020 14:43:33 +0800

前言

看别人的代码也是对自己思维和经验的学习丰富过程

作为一个初学者，之前写过的代码量较少，很少涉及到完整的项目开发，看完redis-py库后，get到其中的

连接保活机制
连接池的实现
开辟buffer存入从socket接收来的数据及buffer管理
熟悉了RESP协议
多进程多线程的情况下，利用锁确保连接池数据结构安全

我读的过程中觉得值得注意的是，_in_use_connections使用集合结构；此连接池不是在初始化时创建好一定数量的tcp连接；其中用了两个互斥锁，一个保护连接池，一个保护多进程的池；较多的连接重连，确保连接可用

执行过程

该库主要有Redis、Connection、ConnectionPool、PythonParse、SocketBuffer几个类，下面大概理了一下redis-py的执行过程

开始使用redis-py客户端
class Redis实例化

可以关注下面几个参数：
- socket_timeout=None,
- socket_connect_timeout=None,
- socket_keepalive=None,
- socket_keepalive_options=None,
- connection_pool=None,
- retry_on_timeout=False,
- max_connections=None,
- single_connection_client=False, # 是否单个连接，不用连接池
- health_check_interval=0,

class ConnectionPool连接池初始化ConnectionPool()，此时尚未创建连接

 # 此处定义连接池最大连接数
 max_connections = max_connections or 2 ** 31

 # fork_safe，在_checkpid()方法中用到，保护临界区的锁。这个锁是在进程id改变时获得的。比如fork出一个子进程后，子进程id和池对象中保存的id不一致，那么子进程中的多个线程都可能会先获取此锁，第一个获得锁的线程将重置此池的数据结构并最终释放锁对象，后续的线程再执行时，pid已于子线程池中的pid熟悉一致，不再做其他操作，在下面也会有提到
 self._fork_lock = threading.Lock()

 # 定义了并初始化已创建连接数、使用中的链接、可用的连接等数据结构
 self._lock = threading.Lock()
 self._created_connections = 0
 self._available_connections = []
 self._in_use_connections = set()

注意此处_in_use_connections使用了集合存储池中的连接对象，这个与python数据类型时间复杂度有关，可点此参考官网，集合的内部实现与字典极为相似，此集合对象只用到两个操作，add和remove，时间复杂度均为O(1)，（有误烦请指正🤡🤡🤡）

初始化Redis-Client状态信息完毕，此时还没有任何连接被创建
假设开始执行 r.set('foo', 'baiqi')，此方法返回r.excute_command()的结果
1. 首先尝试从池中获取一个Connection对象 pool.get_connection(command_name, **options)
2. 获取时得先执行下_checkpid()方法，再执行get_connection()

Jenkins Pipeline初体验

Sun, 12 Jan 2020 22:52:13 +0800

使用jenkins pipeline共享库，各应用都可以引用共享库方法，更改共享库即可应用到所有使用此库的jenkins-job。我目前没有用到vars目录，但完全能够满足我们日常需求，使用方式上可能较low，直接开始体验。

下面列出了定义的部分方法，以作参考。

共享库目录结构：

jenkins-pipeline-libraries git:(master) ✗ tree .
.
├── jenkins-ci
│   └── jenkinsfile-java
├── out
│   └── production
├── src
│   ├── ops
│   │   └── jk
│   │       ├── appDetail.groovy
│   │       └── tools.groovy
│   └── pipeline.gdsl
└── vars
    └── pipelineCfg.groovy

7 directories, 6 files

appDetail.groovy文件里面部分函数如下：

vim 常用操作及配置

Thu, 20 Jun 2019 17:11:52 +0800

vim常用操作汇总

光标移动

上下左右 k/j/h/l

行首 0 或者 ^

行尾 $

单词和字符串间移动

指令	动作
w/W	正向移动到下一个单词开头，大写的忽略特殊字符、符号等
b/B	和w相对应的反向移动，移动到上一个单词开头
e/E	正向移动到下一个单词结尾
ge	反向移动
{num+} f/F+空格	正向/反向移动到本行空格的地方，num相当于移动几次

跳转

指令	动作
ctrl+f	向下翻页
ctrl+b	向上翻页
ctrl+d/u	向下/向上翻半页
gg	文件行首
G	最后一行
行号+gg/G	都是跳到指定行号的行
g+ctrl+g/G	查看光标位置，输出包含行、列、词、字节位置

缩进操作符

指令	动作
» 和 « 或者 :> 和 :<	当前行右缩进和左缩进，后者命令行模式
:line_num1,line_num1+x> 或者 :line_num>x	命令行模式，批量缩进，缩进x行

复制粘贴

复制剪贴内容存于寄存器， :reg可以查看寄存器内容

指令	动作
yy / 8yy	复制/8行
dd / 8dd	剪贴/8行
p/P	粘贴到光标前/后
u	撤销
ctrl+r	重做
yw	复制当前光标单词
y8w / y8W	复制含当前光标的正向8个单词，大写W的含义和W移动含义相同（忽略一些符号）
x/4x/X	剪贴单个字符/4个字符，大写就是反向
d{w/h/j/k/l}	可以各种组合
d$/D	删除光标到行尾
d^	删除光标到行首

插入、查找、替换

插入

指令	动作
I/A i/a	行首、行尾插入，向前向后插入
o/O	下一行、上一行插入
num + (i/I/A/a/o/O)	多次插入，即重复插入多个字符或者多行

转换

指令	动作
~	单个字符大小写转换
g~w	单词大小写反转
g~$ 或 g~~	整行大小写反转
gU或gu + 回车	整行转大写或小写
gU/uw	单词转大写或小写，转换光标到词尾的部分

’.’：点操作符表示重复上一次操作

Linux虚拟内存与物理内存

Sun, 12 Aug 2018 18:00:20 +0800

概念

在linux中，内存分为物理内存和虚拟内存，即ps命令中的RSS和VSZ。虚拟内存存在的原因是为了解决在物理内存上直接划分内存存在的一些问题，比如：

频繁申请和回收内存导致的空间碎片化
可以随意访问用于其他用途的内存区域，不安全
难以执行多任务

进程能看见的是虚拟地址空间，且地址段时连续的，而系统上搭载的内存的实际的地址是物理地址。通过命令 readelf和cat /proc/<pid>/maps输出的就是进程的虚拟地址。

虚拟内存以页为单位进行划分的，在x86_64的架构中页大小默认是4KB，getconf PAGESIZE可以查看页大小。通过内核管理的页表可以完成从虚拟地址到物理地址的转换，每个进程拥有独立的虚拟地址空间，进程的虚拟内存是连续的，但是在物理内存中不一定是连续，且进程只能访问自己的虚拟内存段，没法访问到其他进程的虚拟内存空间和物理内存。

利用虚拟内存机制的重要功能：

文件映射
请求分页
写时复制
swap
多级页表
标准大页

请求分页

如果内核直接从物理内存中获取需要的区域，然后设置页表并关联虚拟地址空间与物理地址空间，这样会导致内存的浪费，有一部分内存获取后可能进程到运行结束都不会使用，如：

用于大规模程序中的、程序运行时未使用的功能代码段和数据段
由glibc保留的内存池中未被用户利用的部分

所以利用请求分页来解决这个问题。对于虚拟地址空间内的各个页面，只有在进程初次访问页面时才会为这个页面分配物理内存。

过程：

① 进程访问入口点

② CPU 参照页表，筛选出入口点所属的页面中哪些虚拟地址未关联物理地址

③ 在CPU中引发缺页中断

④ 内核中的缺页中断机构为页面分配物理内存并更新页表

⑤ 回到用户模式继续运行进程

测试

现用以下测试代码观察虚拟内存和物理内存的分配关系

#include <unistd.h>
#include <time.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <err.h>
#define BUFFER_SIZE (100*1024*1024)
#define NCYCLE 10
#define PAGE_SIZE 4096

int main(void)
{
    char *p;
    time_t t;
    char *s;

    t = time(NULL);
    s = ctime(&t);
    printf("%.*s: before allocation, please press Enter key\n", (int)(strlen(s) - 1), s);
    getchar();

    p = malloc(BUFFER_SIZE);  //申请100MB的内存
    if (p == NULL)
        err(EXIT_FAILURE, "malloc() failed");
    t = time(NULL);
    s = ctime(&t);
    printf("%.*s: allocated %dMB, please press Enter key\n", (int)(strlen(s) - 1), s, BUFFER_SIZE / (1024 * 1024));
    getchar();

    int i; // 以页为单位访问内存，每10M且隔1秒就输出一次信息
    for (i = 0; i < BUFFER_SIZE; i += PAGE_SIZE) {
        p[i] = 0;
        if (i != 0 && i % (BUFFER_SIZE/NCYCLE) == 0) {
            t = time(NULL);
            s = ctime(&t);
            printf("%.*s: touched %dMB\n", (int) (strlen(s) - 1), s, i / (1024*1024));
            sleep(1);
        }
    }
    t = time(NULL);
    s = ctime(&t);
    printf("%.*s: touched %dMB, please press Enter key\n", (int) (strlen(s) - 1), s, BUFFER_SIZE / (1024 * 1024));
    getchar();
    exit(EXIT_SUCCESS);
}

示例说明：

限制svn上传文件大小

Wed, 13 Dec 2017 17:08:08 +0800

为了方便管理和避免一些问题，svn上传文件需要限制文件大小 svn有几种钩子，资料一搜一大把，限制上传文件大小需要用到 pre-commit 在仓库hooks目录下有示例配置文件，新建一个名为 pre-commit 的脚本，内容如下：

#!/bin/bash
REPOS="$1"
TXN="$2"
SVNLOOK=/usr/bin/svnlook
MAX_SIZE=512000

files=$($SVNLOOK changed -t $TXN $REPOS | awk '{print $2}')

# check check 
if [[ $files =~ "project_nuli" ]];then
for f in $files
do
    # check file size
    filesize=$($SVNLOOK cat -t $TXN $REPOS $f | wc -c)
    if [ $filesize -gt $MAX_SIZE ] ; then
        echo "File $f is too large (must <= $MAX_SIZE)" >> /dev/stderr
        exit 1
    fi
done
fi
exit 0

客户端提交大于500K文件会返回 File $f is too large (must <= $MAX_SIZE)

Linux系统平均负载和上下文切换

Sun, 12 Nov 2017 23:00:18 +0800

平均负载

top/uptime显示的平均负载到底是啥意思？它的值多少是比较合理的？

Linux系统中，不知道的命令、库和系统调用等都可以执行下man命令来查看。

man uptime说明：

System load averages is the average number of processes that are either in a runnable or uninterruptable state. A process in a runnable state is either using the CPU or waiting to use the CPU. A process in uninterruptable state is waiting for some I/O access, eg waiting for disk. The averages are taken over the three time intervals. Load averages are not normalized for the number of CPUs in a system, so a load average of 1 means a single CPU system is loaded all the time while on a 4 CPU system it means it was idle 75% of the time.

dns 概述

Sun, 15 Oct 2017 20:41:20 +0800

dns协议

介绍

Domain Network System（DNS），可以理解为将域名和IP地址相互映射的一个分布式数据库，能够使人更方便地访问互联网。DNS使用TCP和UDP端口53。当前，对于每一级域名长度的限制是63个字符（协议限制），域名总长度则不能超过253个字符。开始时，域名的字符仅限于ASCII字符的一个子集。2008年，ICANN通过一项决议，允许使用其它语言作为互联网顶级域名的字符。使用基于Punycode码的IDNA系统，可以将Unicode字符串映射为有效的DNS字符集。因此，诸如“XXX.中国”、“XXX.美国”的域名可以在地址栏直接输入并访问，而不需要安装插件。但是，由于英语的广泛使用，使用其他语言字符作为域名会产生多种问题，例如难以输入，难以在国际推广等。

早期的域名必须以英文句号.结尾。例如，当用户访问www.wikipedia.org的HTTP服务时必须在地址栏中输入：http://www.wikipedia.org.，这样DNS才能够进行域名解析。现在的DNS服务器会自动补上结尾的点号。

域名层级结构

主机名.次级域名.顶级域名.根域名

b.940504.top.

即：host.sld.tld.root

DNS层级结构

所有 DNS 服务器都属于以下四个类别之一：

本地域名服务器（DNS resolver/Local DNS，一般是递归解析器，用来响应客户端的递归请求，大多数 Internet 用户使用他们 ISP 提供的递归解析器）
权威域名服务器（authoritative nameserver，在特定区域内具有唯一性，保存了该区域内的域名与IP地址之间的对应关系）
顶级（TLD）域名服务器（top-level domains，管理顶级域名服务器下注册的二级域名，比如940504.com中，.com是顶级域名，向此域名服务器查询可返回940504.com的权威域名服务器地址）
根域名服务器（本地域名服务器查询不到时，会向根查询返回顶级域名服务器地址）

DNS Master Files (Zone Files)

常用记录类型

主机记录（A记录）：将域名映射到对应主机的IP地址。
别名记录（CNAME记录）: 返回另一个域名，即当前查询的域名是另一个域名的跳转。最常用到 CNAME 的场景包括做 CDN、企业邮箱、全局流量管理等。
IPv6主机记录（AAAA记录）: 与A记录对应，用于将特定的主机名映射到一个主机的IPv6地址。
服务位置记录（SRV记录）: 用于定义提供特定服务的地址和端口，下面有示例。
MX邮件记录（Mail eXchange）：返回接收电子邮件的服务器地址，dig 940504.top mx。
域名服务器记录（NS记录）：把子域名交给其他 DNS 服务商解析。该记录只能设置为域名，不能设置为IP地址。
PTR：逆向查询记录（Pointer Record）：用于从IP地址查询域名。
TXT：一个域可以具有许多 TXT 记录，通常用于发件人策略框架（SPF）代码，这些代码可帮助电子邮件服务器判断邮件是否来自受信任的来源，有有助于域所有权验证。dig _dnsauth.b.940504.top txt。
起始授权记录SOA：此记录可以存储有关域的重要信息，如管理员的电子邮件地址、上次更新域的时间，以及服务器在刷新之间应等待的时间。
url记录：有显性和隐性。隐性url记录使用的是iframe框架技术，不是重定向，访问后地址栏url不变；显性url记录支持url转发301、302重定向，地址栏会跟着重定向。

ns记录

NS 代表“域名服务器”，域名服务器记录指示哪个 DNS 服务器对该域名具有权威性（即，哪个服务器包含实际 DNS 记录）。一般来说，NS 记录表明了可从哪里找到域名的 IP 地址。为了服务的安全可靠，一个域名通常会有多个 NS 记录，这些记录可指示该域的主要和备用域名服务器。

erpan's note

AI Agent编排范式

AI Agent编排范式

引言

AI Agent编排范式分类

详细编排范式解析

1. 基础编排层

Chain（链式编排）

Graph（图编排）

Workflow（工作流编排）

2. Agent编排层

ChatModelAgent

Workflow Agents

Sequential Agent

Parallel Agent

Loop Agent

3. 预构建Multi-Agent范式

Plan-Execute Agent

Supervisor Agent

Layered-Supervisor

DeepAgents

4. 其他主流范式

Master-Slave（主从模式）

Swarm（蜂群模式）

Hierarchical（层级模式）

Peer-to-Peer（对等模式）

选择编排范式

任务复杂度

执行模式

总结

基于Eino框架理解大模型工具调用

函数调用 Function Calling

MCP

传输机制

Stdio

实现一个MutatingAdmissionWebhook

概述

实现

OAuth 2.0 与 OpenID Connect

是什么？

OAuth2.0授权流程

授权码模式（Authorization Code Flow）

磁盘IO类型

顺序写

示例

golang context包用法理解

ArgoCD试用

ArgoCD

特性

几个核心概念

ApplicationSet

client-go RingGrowingBuffer 环形缓冲区

信号和容器关闭

前提概要

信号概念

为普通用户授权生成kubeconfig

Nginx优化

相关内核参数

tcp连接队列调整

bash中alias不生效

alias不生效

读redis-py客户端源码

前言

执行过程

Jenkins Pipeline初体验

vim 常用操作及配置

光标移动

跳转

缩进操作符

复制粘贴

插入、查找、替换

插入

转换

Linux虚拟内存与物理内存

概念

请求分页

测试

限制svn上传文件大小

Linux系统平均负载和上下文切换

平均负载