tiankonguse blog

Agent 的万能插座：MCP 协议

2026-05-13T21:00:00+08:00

前四篇文章分别讲了 Agent 的 Loop、Tools、Prompts 和 Context Compact。

这篇聊一个工程上绕不过的问题——工具。

Agent 的核心价值在于能调用工具。
工具越多，Agent 能干的事就越多。
但工具是谁来写的？
谁来维护？
怎么让 Agent 用上别人已经做好的工具？

这就是今天要聊的东西，MCP。

一、痛点：每个工具都要单独对接

先回顾一下。

在第二篇里，我们实现了一套工具注册机制：每个工具写一个 Go 文件，通过 init() 自动注册，Agent 就能调用它。

这套机制对内置工具来说，挺好用的。

但现实里，工具的来源不只是你自己写的代码。

比如你公司有一个数据查询服务，你想用某个开源的文件搜索工具，或者你想调用某个第三方的 API 封装。

如果每接入一个外部工具，都要专门写一段 Go 代码来适配，这个成本会越来越高。

更麻烦的是，这些外部服务的维护方不是你。
服务升级了，你的适配代码也要跟着改。

打个比方。

这就好比你家的电器，每一种都需要专门定制的插头。
换一台新电视，就得重新改一次墙上的插座。

你说这事烦不烦？

能不能有一个统一的标准插座，所有工具都按这个标准接入，Agent 就能直接用上？

这就是 MCP 的出发点。

二、MCP 是什么

MCP，全称 Model Context Protocol，是 Anthropic 在 2024 年底推出的一套开放协议。

它的核心思路就一句话：

把”AI 调用外部能力”这件事，标准化成一套协议。

有了这套协议，工具的提供方只需要实现 MCP Server，遵守协议规范。
Agent 只需要实现 MCP Client，学会跟任何遵守协议的 Server 通信。

双方都不需要知道对方的内部实现细节。

就像网页浏览器和 Web 服务器的关系。
浏览器不需要知道服务器是用 Python 还是 Go 写的，只要服务器遵守 HTTP 协议，浏览器就能访问它。

graph LR
    A["Agent\n(MCP Client)"] -- "标准 MCP 协议" --> B["MCP Server A\n数据查询服务"]
    A -- "标准 MCP 协议" --> C["MCP Server B\n文件搜索工具"]
    A -- "标准 MCP 协议" --> D["MCP Server C\n第三方 API"]

    style A fill:#c8e6c9
    style B fill:#bbdefb
    style C fill:#bbdefb
    style D fill:#bbdefb

有了 MCP，Agent 的工具生态就从”自己写、自己维护”，变成了”任何人都可以发布 MCP Server，Agent 接入即用”。

这是一个质的变化。

三、底层通信：JSON-RPC 2.0

聊完了”是什么”，来看看它底下是怎么跑的。

MCP 的底层通信协议是 JSON-RPC 2.0。

这东西非常轻量。
每条消息就是一个 JSON 对象，通过 method 字段声明调用什么方法，通过 params 字段传参数，通过 result 字段返回结果。

长什么样呢？
看一眼就明白了：

// 请求（Client → Server）
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "QueryUnionPlus",
    "arguments": {
      "view_name": "2003",
      "key": "mzc002009g0nh88",
      "field_name": "title"
    }
  }
}

// 响应（Server → Client）
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "content": [
      {
        "type": "text",
        "text": "Union value: {\"title\":\"主角\"}"
      }
    ]
  }
}

就这么简单，一来一回。

MCP 在这套基础上，定义了三个核心方法：

initialize，握手。
Client 和 Server 互相确认协议版本和能力。

tools/list，工具发现。
Client 拉取 Server 提供的所有工具列表及参数格式。

tools/call，工具调用。
Client 发起具体的工具请求，Server 执行并返回结果。

整个连接的生命周期，画出来是这样的：

sequenceDiagram
    participant Client as MCP Client
    participant Server as MCP Server

    Client->>Server: initialize（协议版本、能力声明）
    Server-->>Client: 确认握手
    Client->>Server: notifications/initialized
    Client->>Server: tools/list
    Server-->>Client: [{name, description, inputSchema}, ...]
    Note over Client,Server: 工具已发现，开始正常调用
    Client->>Server: tools/call {name, arguments}
    Server-->>Client: {content: [{type, text}]}

先握手，再拿工具列表，然后就可以按需调用了。

逻辑非常清晰。

四、三种传输方式

JSON-RPC 消息需要一个”管道”来传输。

MCP 规范定义了三种传输方式，适用于不同的部署场景。

第一种，stdio（标准输入输出）。

最简单的方式。
Client 把 Server 当作一个子进程启动，通过进程的标准输入和标准输出传递 JSON-RPC 消息。

Client ──stdin──→ Server 子进程
Client ←─stdout── Server 子进程

适合本地工具，比如文件系统操作、代码执行等场景。
Server 就是一个可执行文件。

第二种，SSE（Server-Sent Events）。

基于 HTTP 长连接。
Client 向 Server 发起一个 GET 请求，建立一条持久的 SSE 推送流；同时通过 POST 发送请求消息；Server 的响应通过 SSE 流推回来。

Client ──POST──→ Server（发请求）
Client ←─SSE─── Server（收响应，持久连接）

适合远程 Server，需要维护一条持久连接。

第三种，streamableHttp（可流式 HTTP）。

更简单的远程方案。
每次调用都是一个独立的 HTTP POST 请求，Server 可以直接返回 JSON 响应，也可以用 SSE 格式返回流式内容。

Client ──POST──→ Server（每次独立请求）
Client ←─JSON── Server（或 SSE 流）

适合无状态的远程服务，对 Server 部署要求最低。

graph TD
    A["MCP 传输方式"] --> B["stdio\n本地子进程\n适合本地工具"]
    A --> C["SSE\n持久长连接\n适合远程服务（有状态）"]
    A --> D["streamableHttp\n独立 HTTP 请求\n适合远程服务（无状态）"]

    style B fill:#c8e6c9
    style C fill:#bbdefb
    style D fill:#bbdefb

三种方式，覆盖了从本地到远程、从有状态到无状态的所有场景。

按需选择就行。

五、evo-agent 怎么实现的

了解了协议本身，来看看 evo-agent 是怎么落地的。

evo-agent 目前已经实现了五个核心模块：Loop（Agent 主循环）、Tools（工具注册与调用）、Prompts（系统提示管理）、Context Compact（上下文压缩）、MCP（外部工具）。

代码托管在 https://github.com/tiankonguse/evo-agent ，感兴趣可以配合代码一起看。

先说配置。

配置文件。

MCP Server 的配置统一放在 .evo_agent/mcp.json 里：

{
  "mcpServers": {
    "unionplus_mcp_normal": {
      "type": "streamableHttp",
      "url": "https://example.com/mcp",
      "headers": {
        "Authorization": "Bearer <token>",
        "other_header": "xxx"
      },
      "disabled": false
    }
  }
}

每个 Server 有一个名字，配置里指定传输类型、连接地址和认证信息。

disabled: true 可以临时关闭某个 Server，不用删配置。

对应的 Go 结构体长这样：

type MCPServerConfig struct {
    Type     string            `json:"type"`
    Disabled bool              `json:"disabled"`
    Timeout  int               `json:"timeout"`

    // stdio 专用
    Command string            `json:"command"`
    Args    []string          `json:"args"`
    Env     map[string]string `json:"env"`

    // HTTP 传输专用
    URL     string            `json:"url"`
    Headers map[string]string `json:"headers"`
}

统一接口。

三种传输方式的内部实现完全不同，但对外暴露的是同一套接口：

type mcpClient interface {
    getTools() []mcpToolSpec
    callTool(toolName string, arguments json.RawMessage) (string, error)
    stop()
}

mcpProcess（stdio）、mcpHTTPClient（streamableHttp）、mcpSSEClient（SSE）分别实现这个接口。

上层代码完全不感知传输细节，只需要调 callTool。

这个设计其实就是经典的策略模式——底层实现随便换，上层调用完全透明。

工具命名与路由。

这里有个小巧思。

MCP 工具在 Agent 侧有一套固定的命名规则：

mcp__{服务器名}__{工具名}

比如 mcp__unionplus_mcp_normal__QueryUnionPlus。

这个前缀有两个用途。

第一，让 Agent 知道这是一个 MCP 工具，跟内置工具区分开来。

第二，携带了路由信息。
调用时只需要按 __ 分割，就能知道该把请求转发给哪个 Server。

路由代码写出来就这几行：

func DispatchMCP(name string, input json.RawMessage) (string, error) {
    rest := strings.TrimPrefix(name, "mcp__")
    sep := strings.Index(rest, "__")
    serverName := rest[:sep]
    toolName := rest[sep+2:]

    client := mcpServers[serverName]
    return client.callTool(toolName, input)
}

信息藏在名字里，不需要额外的映射表。

启动流程。

程序启动时，InitMCP() 负责加载配置、连接所有 Server、拉取工具列表：

sequenceDiagram
    participant Main as main.go
    participant InitMCP as InitMCP()
    participant Server as MCP Server

    Main->>InitMCP: tools.InitMCP()
    InitMCP->>InitMCP: 读取 .evo_agent/mcp.json
    loop 每个启用的 Server
        InitMCP->>Server: initialize 握手
        Server-->>InitMCP: 握手成功
        InitMCP->>Server: tools/list
        Server-->>InitMCP: 工具列表
        InitMCP->>InitMCP: 缓存工具到 mcpServers
    end
    InitMCP->>Main: 打印已连接的 Server 和工具数

工具列表在启动时就全部拉取并缓存在内存里。

每次 Agent Loop 调用 tools.Tools() 时，MCP 工具会和内置工具合并，一起打包进 LLM 的请求里。

整个调用链路画出来是这样的：

graph TD
    A["LLM 返回 tool_use\nmcp__unionplus__QueryUnionPlus"] --> B["executor.go\nDispatch(name, input)"]
    B --> C{"名字是否以 mcp__ 开头？"}
    C -- 是 --> D["DispatchMCP(name, input)"]
    C -- 否 --> E["内置工具 Registry"]
    D --> F["按服务器名查找 mcpServers"]
    F --> G["mcpHTTPClient.callTool()"]
    G --> H["POST /mcp\nJSON-RPC tools/call"]
    H --> I["返回结果字符串"]

从 LLM 的返回到最终拿到结果，整个链路一目了然。

六、跑一次真实的看看

光看代码和架构图不够直观。
来看一次真实的运行记录。

接入的是之前我开发的 UnionPlus 数据 MCP 查询服务，通过 streamableHttp 方式连接。
Server 提供了 9 个工具，涵盖视图查询、字段查询、枚举翻译等能力。

启动时的输出：

[MCP] Connected to "unionplus_mcp_normal" (9 tools)
Server: unionplus_mcp_normal
  - QueryUnionPlus: 查询Union数据，单key多字段，字段需要在appid上已授权
  - QueryViewList: 查询视图列表，支持按视图名搜索
  - QueryViewFields: 查询指定视图下的字段列表
  - QueryEnumValues: 按枚举库ID查询枚举值翻译列表
  ...（共9个工具）

9 个工具，全部自动发现，自动注册。

然后我试了第一次查询。

查视图 2003，主键 mzc002009g0nh88，字段 title。

LLM 收到请求后，先判断”视图 ID 2003 对应的视图名是什么”，尝试调用 QueryViewList 搜索：

$ mcp__unionplus_mcp_normal__QueryViewList({"view_name":""})
Error: bufio.Scanner: token too long

返回数据太多，报错了。

但 LLM 并没有放弃。

它调整了策略：直接把 “2003” 作为 view_name 传给 QueryUnionPlus 试一试：

$ mcp__unionplus_mcp_normal__QueryUnionPlus({"view_name":"2003","field_name":"title","key":"mzc002009g0nh88"})
Union value: {"title":"主角"}

成了。

LLM 凭借对工具的理解和错误反馈，自己找到了正确的调用方式。

这正是 Agent Loop 的价值所在——遇到错误，观察，调整，再试。
不需要人去干预，它自己就能摸索出路。

第二次查询就更有意思了。

同一个 key，这次查多个字段。

LLM 直接复用了上一次探索出来的调用方式，用逗号分隔多个字段名：

$ mcp__unionplus_mcp_normal__QueryUnionPlus({
  "view_name": "2003",
  "key": "mzc002009g0nh88",
  "field_name": "title,type_name,publish_date,second_title,description,stars"
})
Union value: {
  "title": "主角",
  "type_name": "电视剧",
  "publish_date": "2026-05-10",
  "second_title": "张艺谋监制！命运共振大剧",
  "description": "电视剧《主角》讲述了秦腔名伶忆秦娥..."
}

整个过程，Agent 没有用任何专门为 UnionPlus 写的适配代码。

它只是拿到了工具的描述和参数格式，自己摸索出了正确的调用方式。

这就是 MCP 的价值所在——工具的接入和工具的使用，完全解耦了。

七、回到最初的问题

回到开头说的那个问题。

工具越写越多，每个系统都要单独对接，怎么破？

MCP 给出的答案很简单：标准化。

在 MCP 之前，每个 Agent 框架有自己的工具格式，每个外部系统需要专门的适配层。
工具越多，维护成本越高，生态越碎片化。

MCP 之后，工具的提供方和消费方各自只需要遵守一套协议。
任何实现了 MCP Server 的服务，任何实现了 MCP Client 的 Agent，都能直接对接。

evo-agent 的 MCP 实现，说到底就做了三件事：

统一接口。
三种传输方式（stdio、SSE、streamableHttp）背后，对上层暴露同一套 mcpClient 接口，调用方完全透明。

统一命名。
mcp__{服务器名}__{工具名} 的命名规则，让工具路由信息直接藏在名字里，无需额外的映射表。

无缝融合。
MCP 工具和内置工具在 tools.Tools() 里合并，LLM 看不出区别，Agent Loop 也不需要做任何特殊处理。

接入一个新的 MCP Server，只需要在 .evo_agent/mcp.json 里加几行配置，重启就生效。

对 Agent 来说，工具的边界消失了。

就像有了标准插座之后，你再也不用为每台电器定制插头了。
买回来，插上，就能用。

MCP 做的，就是这件事。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号ID：tiankonguse-code

Agent 的上下文压缩：3个策略

2026-05-12T21:00:00+08:00

前三篇文章分别讲了 Agent 的 Loop、Tools 和 Prompts。

这篇聊一个迟早得正面面对的问题。

Agent 跑着跑着，messages 越滚越大，context window 快撑不住了，怎么办？

一、项目进度回顾

先简单回顾一下。

evo-agent 是我从零构建 Agent 的学习项目。
https://github.com/tiankonguse/evo-agent

第一篇，搭骨架：接入 Anthropic API，实现 ReAct Loop，第一个工具 bash。

第二篇，扩展工具系统：新增 read_file、write_file、edit_file，重构工具注册机制。

第三篇，理解记忆层：System Prompt、Messages History、Tools Schema 三位一体。

这一篇，解决一个绕不过去的工程问题——上下文压缩。

当前项目的目录结构如下：

src/
├── main.go
├── internal/
│   ├── agent/
│   │   ├── loop.go          # Agent 主循环
│   │   ├── state.go         # 对话状态（含 CompactState）
│   │   ├── compact.go       # 压缩核心引擎（新增）
│   │   └── transcripts.go   # 对话存档（新增）
│   ├── tools/
│   │   ├── tool.go
│   │   ├── executor.go
│   │   ├── bash.go
│   │   ├── read_file.go
│   │   ├── write_file.go
│   │   ├── edit_file.go
│   │   └── compact.go       # compact 工具（新增）
│   ├── config/
│   │   └── config.go
│   └── ui/
│       └── terminal.go

二、问题的根源：messages 是一个只增不减的雪球

上一篇说过，LLM 没有记忆，它的”记忆”就是每次传进去的 messages 数组。

这就带来了一个很现实的问题。

每完成一步操作，messages 就会追加几条：助手的 tool_use 请求、执行工具的 tool_result 返回。
一个稍微复杂点的任务，跑个十几轮下来，messages 就能轻松膨胀到几万个字符。

而 LLM 的上下文窗口是有限的。

超出了，轻则截断历史导致 LLM “忘事”，重则 API 直接报错。

graph LR
    A["第 1 轮\n2 条消息"] --> B["第 5 轮\n10 条消息"]
    B --> C["第 20 轮\n40+ 条消息"]
    C --> D["第 N 轮\n💥 Context Overflow"]

    style D fill:#ffcdd2

打个比方。

你让助理帮你做一个调研报告，他查了 20 个网站，每查一个网站就在笔记本上记一页。
结果笔记本只有 30 页。
还没调研完，笔记本就写满了。

前面记的东西要么被撕掉，要么再也找不到了。

这不是假设，这是任何跑长任务的 Agent 都必然会撞上的墙。

解决这个问题的方案，就叫上下文压缩（Context Compact）。

三、业界怎么做的

上下文压缩没有银弹。

不同的方案各有各的取舍，我大致梳理了四类。

3.1 滑动窗口（Sliding Window）

最简单粗暴的方案：直接丢弃最早的消息，保留最近的 N 条。

实现成本极低，一行代码搞定。

但它有个致命缺陷。

你最开始交代的任务目标，很可能就在最早的消息里。
丢掉了开头，Agent 就忘了自己在干什么。

graph LR
    A["消息 1: 任务目标 ❌丢弃"] 
    B["消息 2: 工具调用 ❌丢弃"]
    C["消息 3: 工具结果 ❌丢弃"]
    D["消息 4: 工具调用 ✅保留"]
    E["消息 5: 工具结果 ✅保留"]
    F["消息 6: 最新回答 ✅保留"]

这就好比你让一个人帮你搬家，搬着搬着他忘了目的地在哪了。
东西还在手上，但不知道往哪送了。

适合闲聊场景，不适合需要长期记住目标的 Agent。

3.2 LLM 摘要压缩（Summarization）

让 LLM 把旧的对话历史”读”一遍，浓缩成一段摘要，再把摘要作为新的”起点”注入到 messages 里。

这样既能大幅压缩 token 数量，又保留了关键信息。

代价是需要额外调用一次 LLM，有几秒的延迟和少量 token 开销。

但这个代价完全可以接受。

这也是目前主流 Agent 框架，比如 LangChain、Claude Code 等，普遍采用的方案。

sequenceDiagram
    participant AgentLoop as Agent Loop
    participant LLM as 摘要 LLM

    AgentLoop->>AgentLoop: 检测到 messages 过大
    AgentLoop->>LLM: 请帮我把这段对话压缩成摘要
    LLM-->>AgentLoop: [摘要文本]
    AgentLoop->>AgentLoop: messages = [摘要] （只剩一条）
    AgentLoop->>AgentLoop: 继续运行

3.3 工具结果占位符（Placeholder Compaction）

工具调用的结果往往是最占空间的——读一个大文件返回了几千行，执行一个命令输出了几百行。

但这些结果一旦被 LLM 处理过，后续几乎用不到了。

一个很轻量的方案是：把旧的工具结果内容替换成一句话的占位符，只保留最近几条完整结果。

几乎零成本，不需要调用 LLM，速度极快。

3.4 RAG 检索增强（Retrieval-Augmented Generation）

更重量级的方案：把历史消息存进向量数据库，每次 LLM 调用前，根据当前问题检索最相关的历史片段注入进去。

优点是灵活，理论上可以无限扩展历史。
缺点是架构复杂，需要维护向量库，检索结果也不一定精准。

对一般的 Agent 任务来说，属于过度设计了。
适合那种对话轮次极多、需要跨会话记忆的场景。

3.5 总结一下

graph TD
    A["上下文压缩方案"] --> B["滑动窗口\n✅ 零成本\n❌ 丢失目标"]
    A --> C["LLM 摘要\n✅ 保留关键信息\n⚠️ 需额外 LLM 调用"]
    A --> D["占位符替换\n✅ 极快无成本\n⚠️ 只处理工具结果"]
    A --> E["RAG 检索\n✅ 无限历史\n❌ 架构复杂"]

    style B fill:#fff9c4
    style C fill:#c8e6c9
    style D fill:#c8e6c9
    style E fill:#ffe0b2

没有哪个方案是万能的。

滑动窗口零成本但会丢目标，LLM 摘要效果最好但需要额外调用，占位符替换极快但只处理工具结果，RAG 能力最强但架构太重。

实际工程中，通常是几种策略分层组合使用。

先拿最便宜的手段挡一挡，挡不住了再上重武器。

这个思路其实也是 evo-agent 的设计思路。

四、evo-agent 的压缩设计

evo-agent 采用了三层压缩策略，按照成本从低到高依次触发。

graph TD
    A["每次 LLM 调用前"] --> B["第一层：MicroCompact\n替换旧工具结果为占位符\n成本：<1ms"]
    B --> C{"context size\n> 50,000 字符？"}
    C -- 否 --> D["正常调用 LLM"]
    C -- 是 --> E["第二层：CompactHistory\n调用 LLM 生成摘要\n成本：1~5s"]
    E --> D

    F["LLM 返回后"] --> G{"模型主动调用\ncompact 工具？"}
    G -- 是 --> H["手动 Compact\n附带 focus 提示\n成本：1~5s"]
    G -- 否 --> I["继续下一轮"]

就像三道防线。

第一道，能在内存里解决的，绝不动网络。
第二道，内存搞不定了，调 LLM 做摘要。
第三道，LLM 自己觉得不行了，主动喊暂停。

一层一层兜底。

第一层：MicroCompact（微压缩）

每次调用 LLM 之前，先扫一遍 messages，把较旧的工具结果替换成一行占位符：

[Earlier tool result compacted. Re-run the tool if you need full detail.]

只保留最近 3 条工具结果的完整内容，更早的全部折叠。

这个操作在内存里完成，耗时不到 1ms，没有任何网络请求。

这里有一个关键的保护逻辑：最后一批工具结果永远不会被压缩。

为什么？

因为 LLM 刚刚发起了工具调用，还没来得及”看”这批结果。
如果此时就把它们折叠掉，LLM 就会拿到空结果，行为会出错。

这就好比你刚派人去查资料，人还没回来呢，你就把他的工位清了。
回来了没地方汇报，这活就白干了。

第二层：CompactHistory（全量压缩）

微压缩之后，再测量一次 messages 的总体积。
如果仍然超过 50,000 字符，就触发全量压缩。

全量压缩的流程分三步。

第一步，存档。
先把当前完整的 messages 写入磁盘，存成 JSONL 格式的 transcript 文件。
这是压缩前的”存档”，日后可以用来调试和回溯。

第二步，摘要。
调用 LLM，让它把整段对话浓缩成一份结构化摘要。
要求保留五样东西：当前目标、重要发现与决策、读过和修改过的文件、剩余工作、用户约束。

第三步，替换。
用这条摘要替换掉所有 messages。
messages 从几十条，瞬间变成 1 条。

就像你写了 30 页的调研笔记，最后浓缩成一页纸的摘要。
笔记本清空了，但关键信息都在那一页纸上。

sequenceDiagram
    participant AgentLoop as loop.go
    participant Compact as compact.go
    participant Transcript as transcripts.go
    participant LLM as LLM API

    AgentLoop->>Compact: CompactHistory(messages)
    Compact->>Transcript: WriteTranscript(messages) → .evo_agent/transcripts/
    Compact->>LLM: "请压缩这段对话..."
    LLM-->>Compact: [摘要文本]
    Compact->>Compact: 追加 RecentFiles 到摘要
    Compact-->>AgentLoop: [新 messages：只含摘要]

第三层：手动 Compact 工具

除了自动触发，LLM 自己也可以主动要求压缩。

工具系统里注册了一个 compact 工具，LLM 可以调用它，还能传一个 focus 参数，告诉压缩引擎”这次特别要保留什么”：

// tools/compact.go
type CompactInput struct {
    Focus string `json:"focus,omitempty"`
}

比如 LLM 觉得自己快撑不住了，可以主动说：
compact(focus="当前正在重构的 loop.go 和相关接口")

摘要里会额外追加这段 focus 提示，确保下一轮不忘关键信息。

这个设计挺有意思的。

相当于 Agent 有了”自我管理记忆”的能力。
它不只是被动等着系统来压缩，它可以自己判断什么时候该”忘”一些东西，同时告诉系统”但这些别忘”。

五、CompactState：压缩也需要记忆

压缩这件事本身，也需要状态追踪。

不然你都不知道压缩发生过几次，上次摘要长什么样。

所以我把压缩相关的状态单独抽了出来，存在 CompactState 里：

// state.go
type CompactState struct {
    HasCompacted bool     // 是否已发生过压缩
    LastSummary  string   // 最后一次生成的摘要
    RecentFiles  []string // 最近访问的文件（FIFO，最多 5 个）
    CompactCount int      // 压缩次数计数
}

这里有一个细节设计，我觉得值得单独说一下——RecentFiles。

每次 LLM 调用了 read_file 工具，loop.go 都会把这个文件路径记进去，保持最近 5 个，先进先出。

压缩发生时，这份文件列表会附加到摘要末尾：

Recent files to reopen if needed:
- src/internal/agent/loop.go
- src/internal/agent/compact.go

为什么要这么做？

因为压缩之后，messages 里的旧内容都没了。
LLM 读完摘要，知道”上次我在看这几个文件”，可以快速重新打开，不用重新摸索。

就像你午睡醒了，桌上摆着你睡前打开的几份文件。
你一看就知道：”哦，我之前在做这个事”。
不用从头回忆。

CompactState 不随每次用户提问重置，而是在整个 REPL 会话中持久保持：

// loop.go - Run()
compactState := &CompactState{} // 整个会话只初始化一次

for { // REPL 循环
    state := &LoopState{
        Messages:     history,
        CompactState: compactState, // 每次查询复用同一个 state
    }
    a.Loop(state)
    compactState = state.CompactState // 同步回来
}

这样即使跨多次用户查询，压缩历史和文件追踪都不会丢失。

六、几个关键的数字

聊完了设计，再看看具体的参数配置。

CONTEXT_LIMIT = 50,000 字符，超过这个值就触发全量压缩。
KEEP_RECENT_RESULTS = 3，微压缩保留最近 3 条工具结果。
maxConversationBytes = 80,000，送给摘要 LLM 的最大对话长度。
max RecentFiles = 5，追踪最近 5 个文件。

各层操作的时间成本：

微压缩在内存里完成，不到 1ms。
全量压缩需要额外一次 LLM 调用，通常 1 到 5 秒。
Transcript 落盘是异步的，约 100ms。
文件追踪是纯内存操作，可以忽略不计。

全量压缩的效果：messages 从几十条压缩到 1 条，token 节省通常超过 90%。

这个数字还是很可观的。

七、总结

回过头来看，上下文压缩这件事，其实本质上就是在回答一个问题：

当一个只有短期记忆的 AI 要干长期的活，你怎么让它不失忆？

答案说起来也简单——该忘的忘，该记的记。

但”什么该忘、什么该记”，这里面的分寸拿捏，才是真正的工程活。

evo-agent 的策略是三层叠加：

占位符微压缩作为第一道防线——成本几乎为零，先把最占空间的工具结果折叠掉。

LLM 摘要作为第二道防线——防线要破了，花几秒钟让 LLM 自己做个总结，浓缩成一页纸。

手动 Compact 工具作为第三道防线——让 LLM 自己决定什么时候压缩、重点保留什么。

再加上 CompactState 在会话内持久追踪文件路径，让 Agent 在压缩之后也能快速找回上下文。

有了这套机制，理论上一个 Agent 可以无限续航，不再受 context window 限制。

这话说起来轻巧，但真正实现出来，需要的就是上面这些一层一层的工程细节。

下一篇，我们来看 Agent 的另一个核心话题。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号ID：tiankonguse-code

leetcode 周赛 501

2026-05-10T12:13:00+08:00

零、背景

这次比赛最后一题是全源最短路，看错数据范围了，错了两次。

本场题型概览如下。
A 题：翻转。
B 题：分割字符串。
C 题：因子分解。
D 题：全源最短路。

一、连接逆序数组

题意：给一个数组，求原数组与翻转数组拼接后的数组。

思路：按题意原数组与翻转数组相连即可。

二、有效单词计数

题意：给若干字符串，问这些字符串拼接到一起后，进行分词统计，问指定的单词分别出现几次。
单词定义：字母与连接符组成，连接符左右必须是字母。

思路：分割字符串

双层循环遍历字符串数组，把字符尝试追加到单词上。
如果得到新的单词，更新单词的频率。

四种情况算单词结束。

1）遇到空格 2）前缀单词为空，遇到连接符 3）前缀单词最后一个字符是连接符，再次遇到连接符 4) 输入结束

auto Add = [&](char c) {
  if (c == ' ') {
    Flush();
  } else if (c == '-') {
    if (!s.empty() && s.back() == '-') {
      s.push_back(c);
    } else {
      Flush();
    }
  } else {
    s.push_back(c);
  }
};

单词识别结束时，还需要判断有没有后缀连接符，有的话需要删除。

auto Flush = [&]() {
  if (!s.empty() && s.back() == '-') {
    s.pop_back();
  }
  if (!s.empty()) {
    cnt[s]++;
    s.clear();
  }
};

三、可整除替换后的数组最小元素和

题意：给一个数组，如果数组中存在一个数字是自己的因子，则自己可以使用因子进行替换。
问不断替换，最终可以得到的最小数组和。

思路：因数分解

显然，对于一个数组，使用数组中出现过的最小因子进行替换，才能得到最小数组和。
故，问题转化为找到数字在数组中出现的最小因子。

可以先对数组排序，从小到大处理，这样因子分解时，就知道因子是否出现过了。

因子分解可以使用根号算法 sqrt(n) 来做。
复杂度：O(n sqrt(n))

扩展：数据范围不大，除了进行质因数分解，还可以使用筛法。
即如果一个数字不存在更小的因子，则把这个数字所有的倍数都标记。
复杂度保持不变。

四、购买苹果的最低成本 II

题意：给两个完全一样的无向图 G1 和 G2，权值不一样。
问对于每个节点 a，通过图 G1 到达任意节点，再通过图 G2 返回到 a 的最小代价。
数据范围：点 1000 个，边 2000 条。

思路：Dijkstra 单源最短路

按题意构造两个图，分别求 n 次单源最短路，再枚举求最小答案即可。

PS：一开始看错题意了，看成点是 100，直接 floyd 超时了。

五、最后

这次比赛很简单，第二题解析字符串、第三题因数分解、第四题最短路，都基础题。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号 ID：tiankonguse-code

Agent 的记忆：系统提示词与对话历史

2026-05-09T12:00:00+08:00

前两篇文章分别讲了 Agent 的 Loop 和 Tools。
这篇讲 Agent 的 Prompts。

注意，这篇的重点，其实不只是”怎么写提示词”。
而是要回答一个更根本的问题：

LLM 是怎么知道它在干什么的？

不知道你是否知道，LLM 每次被调用，其实跟一个失忆的人一样。
上一秒说了什么，它不知道。
你之前跟它聊了三个小时，它也不知道。

那它是怎么”记住”对话的？

答案比你想的简单得多，也残酷得多。

一、项目进度回顾

先简单交代一下背景。

evo-agent 是我从零开始构建 Agent 的学习项目。
https://github.com/tiankonguse/evo-agent

第一篇，搭了骨架：接入 Anthropic API，实现 ReAct Loop（思考 → 行动 → 观察 → 循环），提供了第一个工具 bash。

第二篇，扩展了工具系统：新增 read_file、write_file、edit_file 三个文件操作工具，重构了工具注册机制。

这一篇，来聊 Agent 最底层的”语言层”——Prompts 和 Messages History。

当前项目的目录结构如下：

src/
├── main.go                    # 入口：交互式 REPL
├── internal/
│   ├── agent/
│   │   ├── loop.go            # Agent 主循环 + REPL
│   │   └── state.go           # 对话状态（Messages + TurnCount）
│   ├── tools/
│   │   ├── tool.go            # 工具注册表 & Dispatch
│   │   ├── executor.go        # 工具执行器
│   │   ├── bash.go
│   │   ├── read_file.go
│   │   ├── write_file.go
│   │   └── edit_file.go
│   ├── config/
│   │   └── config.go          # 配置加载（SystemMsg 在这里生成）
│   └── ui/
│       └── terminal.go        # 终端彩色输出

二、LLM 没有记忆

这是理解一切的前提。

LLM 没有记忆。

每次你调用 API，对它来说都是全新的开始。
上一轮说了什么，它完全不知道。
你不告诉它，它就不记得。

这和人完全不同。
你跟朋友聊天，昨天说的话今天还记得。
LLM 不行，每次调用，它的”记忆”都被清空了。

那问题来了。

ChatGPT 为什么看起来能”记住”上下文？

答案很简单——ChatGPT 在每次请求里，把整个对话历史都塞给了 LLM。
LLM 读完这些历史，才知道”哦，我们之前聊到这里了”。

本质上，LLM 的”记忆”，就是你塞给它的 messages 数组。

打个比方。
你跟一个彻底失忆的人聊天，每次开口之前，你都得把之前所有的聊天记录念给他听一遍。
他听完了，才知道”我们聊到哪了”。

LLM 就是这个失忆的人。

graph LR
    A["第 1 轮\nUser: 你好"] --> B["LLM\n只看到第 1 条"]
    B --> C["Assistant: 你好！"]

    D["第 2 轮\nUser: 你叫什么"] --> E["LLM\n看到第 1+2+3 条"]
    E --> F["Assistant: 我是 Claude"]

    style B fill:#ffe0b2
    style E fill:#ffe0b2

每一轮对话，messages 数组都在增长。
LLM 每次都要读完整个历史，才能知道”我们聊到哪了”。

就像滚雪球，越滚越大。

三、Messages 长什么样

在搞清楚 messages 的结构之前，先抛两个你可能有过的疑问。

疑问一：思考模式。
你用过 Claude 的扩展思维（Extended Thinking）吗？开启之后，LLM 会先输出一段”内心戏”，再给出最终答案。
那这段思考内容，是单独返回的，还是混在答案里的？它又是怎么存进 messages 的？

疑问二：工具调用。
LLM 想用工具，它怎么”告诉”我们它要用哪个工具、传什么参数？
我们执行完工具，又怎么把结果”喂回”给 LLM？

搞清楚 messages 的结构，这两个问题就迎刃而解了。

好，那 messages 数组里到底装了些什么？

Anthropic API 的 messages 是一个数组，每条消息有两个核心字段：

role：这条消息是谁说的。
只有两个值——user（用户）或 assistant（模型）。

content：消息的内容。
最简单就是一个字符串，但现代 LLM 支持了思考模式和工具调用之后，content 有时候是一个数组。

具体来说：

用户消息，普通对话直接用字符串就行。
只有在需要把工具执行结果返回给 LLM 时，content 才变成数组（tool_result 类型）。

助手消息，由于 LLM 可能同时输出思考过程、工具调用请求和普通文本，content 通常是一个数组，包含三种 block 类型：

thinking — 模型的内心戏（开启扩展思维时才有）
tool_use — “我要用这个工具”的请求，携带工具名、参数，以及一个唯一的 id
text — 最终的文本回答

这里有个关键细节：LLM 每次发起工具调用，都会给它分配一个唯一的 tool_use_id。

为什么需要这个 ID？

因为 LLM 可以在一次响应里同时请求多个工具。
我们执行完之后，要把结果一一对应地还回去——用 tool_use_id 做锚点，LLM 才知道哪个结果对应哪个请求。
就像你同时派出三个人去办事，每人手里拿一张编号的任务单，回来汇报时按编号核对。

用 JSON 来直观感受一下：

[
  {
    "role": "user",
    "content": "帮我找出最大的文件"
  },
  {
    "role": "assistant",
    "content": [
      { "type": "thinking", "thinking": "用户想找最大的文件，我应该用 du 命令..." },
      { "type": "tool_use", "id": "tool_abc123", "name": "bash", "input": { "command": "du -sh * | sort -rh | head -1" } }
    ]
  },
  {
    "role": "user",
    "content": [
      { "type": "tool_result", "tool_use_id": "tool_abc123", "content": "128M  evo_agent" }
    ]
  },
  {
    "role": "assistant",
    "content": [
      { "type": "text", "text": "最大的文件是 evo_agent，占用 128M。" }
    ]
  }
]

注意两个细节。

第一，tool_use_id 贯穿请求和结果。
LLM 发出 tool_use 时带上 id: "tool_abc123"，我们返回结果时用 tool_use_id: "tool_abc123" 对应回去。
ID 不匹配，LLM 就不知道这个结果是给谁的。

第二，工具调用的结果是以 user 角色发回去的。

为什么？

因为从 API 的视角看，工具结果就是我们的程序”说”给 LLM 的话。
执行工具的是我们的代码，不是 LLM 自己，所以自然是 user 角色。

这个设计很合理。
LLM 说”我想用 bash 执行这个命令”，我们的代码执行完了告诉它”结果是这个”——就像你让秘书去查个数据，秘书查完了回来跟你汇报。

四、System Prompt：Agent 的”底色”

如果你用 Agent 写过代码，一定见过”上下文压缩”这个提示。
对话太长了，Token 快撑不住了，Agent 会自动把历史消息压缩一遍。

你有没有想过一个问题：

上下文压缩，会不会把系统提示词也一起压掉？

如果压掉了，那些强加给 Agent 的规则——”不准删文件”、”只能操作这个目录”——是不是就悄悄失效了？

答案是：不会。

因为系统提示词根本就不在 messages 里。
它是一个独立的字段，压缩的是 messages 历史，System Prompt 每次调用都原封不动地带着。

这就是为什么它重要。

除了 messages 数组，还有一个独立的字段：system。

这就是系统提示词（System Prompt）。

它不在 messages 里，独立于对话历史之外。
每次调用 API 都会带上它，但它不会随着对话增长。

系统提示词的作用是什么？

给 Agent 设定身份和行为框架。

告诉它：”你是谁，你在哪，你应该怎么做事。”

打个比方。
你去面试，面试官坐下来第一件事，不是直接问你问题，而是先告诉你”我是技术面试官，今天考察后端能力，时间 40 分钟”。

这就是 System Prompt。
它定义了整个对话的基调。

在 evo-agent 里，系统提示词是在 config.go 里自动生成的：

// config.go
SystemMsg: fmt.Sprintf(
    "You are a coding agent at %s.",
    cwd,
),

非常简洁——你是一个代码助手，工作目录在这里。

为什么要把工作目录注入进去？

因为 LLM 在调用 bash、read_file 等工具时，需要知道相对路径从哪里算起。
告诉它”你在 /Users/tiankonguse/project/evo-agent“，它构造文件路径时就不会迷失方向。

在 loop.go 里，每次调用 API 时，系统提示词都会传进去：

// loop.go
resp, err := a.client.Messages.New(context.Background(), anthropic.MessageNewParams{
    Model: anthropic.Model(a.cfg.ModelID),
    System: []anthropic.TextBlockParam{
        {Text: a.cfg.SystemMsg},   // 系统提示词
    },
    Messages:  state.Messages,    // 对话历史
    Tools:     tools.Tools(),     // 工具列表
    MaxTokens: 8000,
})

五、System vs User：两种提示词的区别

有了 System Prompt，为什么还要有 User Prompt？
它们各管什么？

用一句话区分：

System Prompt 是角色设定，User Prompt 是任务指令。

还是用面试的比方。

System Prompt 就是”我是技术面试官，考察后端，40 分钟”——整场面试不会变。

User Prompt 就是每一道具体的面试题——”说说 Redis 的淘汰策略？”

System Prompt 定义了 Agent 的”底色”：你是什么、能干什么、有什么约束。
User Prompt 驱动 Agent 在当前这一轮做什么。

graph TD
    A["每次 API 调用"] --> B["System Prompt\n(每次都发，固定不变)\n'你是一个代码助手\n工作目录在 /path/to/project'"]
    A --> C["Messages\n(随对话增长)"]
    C --> D["User: '帮我找最大的文件'"]
    C --> E["Assistant: tool_use bash"]
    C --> F["User: tool_result ..."]
    C --> G["Assistant: '最大的文件是...'"]

    style B fill:#c8e6c9
    style C fill:#bbdefb

两者合在一起，就是 LLM 每次”看到”的完整世界。

六、对话历史的管理：两层循环

evo-agent 的对话历史管理有两层循环。
这个设计其实挺巧妙的。

外层循环：REPL 交互循环。

负责读取用户输入、驱动一次完整的 Agent 任务、打印最终回答。
history 在这一层跨多次用户查询累积——你问了第一个问题，LLM 的全部回答都会留在 history 里；你问第二个问题时，LLM 能看到第一轮的完整上下文。

// 外层：REPL 循环，每次读取一个用户问题
var history []anthropic.MessageParam

for { // 不断等待用户输入
    query := readUserInput()

    history = append(history, anthropic.NewUserMessage(query))
    state := &LoopState{Messages: history}

    a.Loop(state)          // 内层循环在这里运行

    history = state.Messages   // 把本轮所有对话（含工具调用）同步回来
    printFinalAnswer(history)
}

内层循环：ReAct 循环。

负责驱动一次任务里的多轮 LLM 调用。
每次 LLM 返回工具调用请求，就执行工具、把结果追加进 messages，再发起下一轮调用，直到 LLM 不再需要工具为止。

// 内层：ReAct 循环，每次调用一次 LLM
func (a *Agent) RunOneTurn(state *LoopState) bool {
    resp := callLLM(state.Messages)           // 调用 LLM

    state.Messages = append(state.Messages, resp.ToParam())   // 追加助手响应

    toolResults := tools.Execute(resp.Content)                // 执行工具
    if len(toolResults) == 0 {
        return false                          // 没有工具调用，结束循环
    }

    state.Messages = append(state.Messages,                   // 追加工具结果
        anthropic.NewUserMessage(toolResults...))
    return true                               // 继续下一轮
}

func (a *Agent) Loop(state *LoopState) {
    for a.RunOneTurn(state) {}
}

两层循环的关系怎么理解？

外层循环是”会话”，内层循环是”一次任务的思考过程”。

就像你跟助理说”帮我调研一下竞品”，这是外层的一个任务。
助理在执行这个任务时，可能要查好几个网站、比对好几份数据，这是内层的多次操作。

内层每轮都在往 messages 里追加新内容，外层循环结束时把整个膨胀后的 history 保留下来，供下一次用户提问继续使用。

整个过程就像滚雪球——messages 只会越来越长，LLM 每次能看到的上下文也越来越完整。

七、一次完整对话的消息流

从用户输入到最终回答，messages 数组是怎么演变的？

sequenceDiagram
    participant User as 用户
    participant REPL as REPL (Run)
    participant AgentLoop as Agent Loop
    participant LLM as LLM API

    User->>REPL: "帮我找最大的文件"
    REPL->>AgentLoop: history = [User: "帮我找最大的文件"]

    AgentLoop->>LLM: messages=[User msg] + system + tools
    LLM-->>AgentLoop: tool_use: bash("du -sh *")
    AgentLoop->>AgentLoop: history += [Assistant: tool_use]
    AgentLoop->>AgentLoop: 执行 bash，得到结果
    AgentLoop->>AgentLoop: history += [User: tool_result "128M evo_agent"]

    AgentLoop->>LLM: messages=[User, Assistant, User(tool_result)] + ...
    LLM-->>AgentLoop: "最大的文件是 evo_agent，128M"
    AgentLoop->>AgentLoop: history += [Assistant: "最大的文件是..."]

    AgentLoop->>REPL: 返回最终 history
    REPL->>User: 打印最终回答

看到了吧？

每次 LLM 调用，它看到的 messages 都比上一次多几条。
这就是为什么 LLM 能”记住”工具调用的结果——不是因为它有记忆，是因为我们把结果又喂回去了。

八、LoopState：状态快照

对话历史被包装在 LoopState 里传递：

// state.go
type LoopState struct {
    Messages         []anthropic.MessageParam
    TurnCount        int
    TransitionReason string
}

三个字段，各有各的用处。

Messages 是核心，就是前面说的 messages 数组。

TurnCount 记录当前 Loop 经历了多少轮 LLM 调用。
可以用来设置最大轮次限制——防止 Agent 陷入死循环，一直在那调工具停不下来。

TransitionReason 记录每轮结束的原因。
"tool_result" 表示因为有工具调用而继续，空字符串表示 LLM 选择结束。

这个字段对调试特别有用。
当 Agent 行为诡异的时候，你可以看看它到底是在哪一步”决定”停下来的。

九、Prompts 是写给 LLM 看的

最后聊一个容易被忽视的事。

evo-agent 目前的系统提示词很简单，只有一行：

You are a coding agent at /path/to/project.

现阶段够用。

但随着项目功能越来越多，这东西也得跟着演进。
一个成熟的 Agent 的 System Prompt，通常还要告诉 LLM：遇到不确定的情况怎么办、文件操作有什么禁区、回答用什么语言和风格。

这些不写进去，LLM 就只能靠猜。
猜错了，就是一次莫名其妙的行为。

等 evo-agent 功能足够完善之后，我会单独写一篇来深入聊系统提示词的设计。
现阶段先把骨架搭好。

另外还有一个经常被忽略的点——工具的描述也是 Prompt 的一部分。

每次调用 API 时，工具的 Schema 和描述都会发给 LLM。
LLM 靠这些描述来判断什么时候用哪个工具。

描述写得清晰，LLM 选择就更准确。
描述含糊，LLM 就容易用错工具。

所以写工具描述的时候，你的读者不是人类开发者，是 LLM 本身。

graph TD
    A["LLM 的完整输入"] --> B["System Prompt\n身份 + 行为约束 + 工作目录"]
    A --> C["Messages History\n完整对话记录"]
    A --> D["Tools Schema\n工具名称 + 描述 + 参数"]

    B --> E["LLM 的'世界观'"]
    C --> F["LLM 的'记忆'"]
    D --> G["LLM 的'工具箱'"]

    E & F & G --> H["LLM 的输出\n(思考 + 工具调用 + 文本)"]

    style B fill:#c8e6c9
    style C fill:#bbdefb
    style D fill:#ffe0b2

System Prompt、Messages History、Tools Schema。
三者合一，才是 LLM 每次”看到的世界”。

写 Prompt，本质上就是在构建 LLM 的世界观。
这件事，比写代码更接近”沟通”，而不是”编程”。

十、总结

回顾一下这篇的核心内容。

LLM 是无状态的。
它所知道的一切，都来自你每次传进去的 messages 数组。
没有 messages，它就是一个失忆的人。

System Prompt 是 Agent 的底色。
告诉 LLM “你是谁、你在哪、你该怎么做”，每次调用都发，但不会随对话增长。

Messages 是 Agent 的短期记忆。
对话历史随每轮 Loop 滚动累积，LLM 通过读这段历史来”记住”之前的事。

工具描述也是 Prompt。
写给 LLM 看的，不是写给人看的。
名字要直白，描述要具体。

到这里，evo-agent 的三个核心要素都讲完了。

Loop 驱动 Agent 不断行动。
Tools 让 Agent 能操作真实世界。
Prompts 和历史，则是 LLM 感知一切的唯一窗口。

它只能通过你传进去的文字来理解世界。
你不说的，它就不知道。
你说错的，它就信以为真。

下一篇，我们来看一个很实际的问题：当 messages 越滚越大，context window 撑不住了，怎么办？

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号ID：tiankonguse-code

Agent 的手脚：接入更多的工具

2026-05-07T12:13:00+08:00

Agent = LLM（大脑）+ Tools（手脚）+ Loop（神经反射弧）

上一篇Agent 的本质：一个 Loop 循环讲了 Loop。
这篇讲 Tools。

如果 Loop 是 Agent 的神经反射弧，那工具就是它的手脚。
没有工具，LLM 再聪明，也只是个嘴上功夫的大脑。
什么都说得出来，什么都做不了。

一、项目进度回顾

evo-agent 是一个从零开始构建 Agent 的学习项目。

之前，我们实现了 Agent 最核心的骨架：

接入 Anthropic API
实现 ReAct Loop（思考 → 行动 → 观察 → 循环）
提供第一个工具：bash（执行 Shell 命令）

这篇文章，我们扩展了工具系统：

新增 read_file：读取文件内容
新增 write_file：写入文件（自动创建目录）
新增 edit_file：精准替换文件片段
重构工具注册机制，支持工具自注册，方便后续扩展

当前项目目录结构如下：

src/
├── main.go                    # 入口：交互式 REPL
├── internal/
│   ├── agent/
│   │   ├── loop.go            # Agent 主循环
│   │   └── state.go           # 对话状态
│   ├── tools/
│   │   ├── tool.go            # 工具注册表 & Dispatch
│   │   ├── executor.go        # 工具执行器（解析 LLM 响应）
│   │   ├── bash.go            # bash 工具
│   │   ├── read_file.go       # read_file 工具
│   │   ├── write_file.go      # write_file 工具
│   │   └── edit_file.go       # edit_file 工具
│   ├── config/
│   │   └── config.go          # 配置加载（.env）
│   └── ui/
│       └── terminal.go        # 终端彩色输出

二、工具是什么？

在 Agent 的语境里，工具（Tool）就是一个 LLM 可以”主动调用”的函数。
注意这里的关键词是”主动”。
不是我们程序员硬编码去调，而是 LLM 自己判断”我现在需要用这个工具”，然后发起调用。

LLM 本身只能生成文本。
但如果我们事先告诉它：”你有这些工具，每个工具叫什么名字、接收什么参数、有什么用”。
那 LLM 在需要的时候，就会输出一段结构化的”工具调用请求”。

Agent 系统拦截这个请求，真正去执行工具，再把结果还给 LLM。
这个过程叫 Tool Use（工具调用）。

举个例子。
用户说：”帮我读取 config.json 的内容”。
LLM 不会傻乎乎地编一段文件内容出来，而是会说：”我要调用 read_file 工具，参数是 config.json”。
系统执行完，把真实的文件内容返回给 LLM，LLM 再基于真实内容回答用户。

整个过程长这样：

sequenceDiagram
    participant User as 用户
    participant Agent as Agent
    participant LLM as Claude (LLM)
    participant Tool as 具体工具

    User->>Agent: "帮我读取 config.json 的内容"
    Agent->>LLM: Messages + Tools Schema
    LLM->>Agent: tool_use: read_file({path: "config.json"})
    Agent->>Tool: 调用 read_file 处理函数
    Tool->>Agent: 返回文件内容
    Agent->>LLM: tool_result: "{...}"
    LLM->>User: "config.json 的内容是..."

而且工具调用不是一次性的。
LLM 可以连续调用多个工具，直到它认为信息足够了，才输出最终答案。
这就是上一篇讲的 Loop 的作用。

三、工具的数据结构

每一个工具，本质上就是两件东西的组合：

Schema（接口描述）：告诉 LLM 这个工具叫什么、接收什么参数。这是给 LLM 看的”说明书”。
Handler（执行逻辑）：真正的函数实现，这是给 Go 程序执行的。

一个给 LLM 看，一个给程序跑。

在代码里，我们用 ToolDef 把这两件事绑在一起：

// tool.go

// Handler 是每个工具必须实现的函数签名
type Handler func(input json.RawMessage) (string, error)

// ToolDef 把工具的 API schema 和 handler 绑定在一起
type ToolDef struct {
    Schema  anthropic.ToolParam
    Handler Handler
}

Schema 里包含工具名称、描述、参数的 JSON Schema，发给 Anthropic API
Handler 接收 LLM 传来的 JSON 参数，返回字符串结果（或错误）

四、自注册模式：让工具”自己报到”

一个常见的工程问题：工具越来越多，怎么管？

最朴素的方式是维护一个全局列表，每次新增工具都去改那个列表。
但这很容易出错，耦合度也高。
改着改着就乱了。

evo-agent 采用了 Go 的 init() 自注册模式。

核心思路：每个工具文件自己负责把自己注册到全局注册表。
main 包只需要 import 这些文件，注册就自动完成了。
谁也不用管谁。

// tool.go —— 全局注册表

var registry = map[string]ToolDef{}

// Register 向注册表添加一个工具
func Register(def ToolDef) {
    registry[def.Schema.Name] = def
}

// Tools 返回所有注册的工具 schema，用于发给 Anthropic API
func Tools() []anthropic.ToolUnionParam { ... }

// Dispatch 根据工具名找到 handler 并执行
func Dispatch(name string, input json.RawMessage) (string, error) { ... }

每个工具文件里，在 init() 里调用 Register：

// bash.go
func init() {
    Register(ToolDef{
        Schema: anthropic.ToolParam{
            Name:        "bash",
            Description: anthropic.String("Run a shell command in the current workspace."),
            InputSchema: GenerateSchema[BashInput](),
        },
        Handler: func(input json.RawMessage) (string, error) {
            var in BashInput
            json.Unmarshal(input, &in)
            return runBash(in.Command), nil
        },
    })
}

这样，添加一个新工具，只需要新建一个 .go 文件。
不需要修改任何已有代码。
完美的开闭原则。

graph TD
    A[程序启动] --> B[Go runtime 执行所有 init]
    B --> C[bash.go init 注册 bash]
    B --> D[read_file.go init 注册 read_file]
    B --> E[write_file.go init 注册 write_file]
    B --> F[edit_file.go init 注册 edit_file]
    C --> G[registry map]
    D --> G
    E --> G
    F --> G
    G --> H["Tools() 返回所有 schema"]
    G --> I[Dispatch 按名字路由]

五、Schema 自动生成

上面说了，每个工具都需要一份 JSON Schema，告诉 LLM 这个工具接收什么参数。
但这个 Schema 怎么来？

如果手写，read_file 的 Schema 大概长这样：

anthropic.ToolInputSchemaParam{
    Properties: map[string]interface{}{
        "path": map[string]interface{}{
            "type":        "string",
            "description": "The relative path of a file in the working directory.",
        },
        "limit": map[string]interface{}{
            "type":        "integer",
            "description": "Maximum number of lines to return (0 = no limit).",
        },
    },
}

这还只是两个字段。
如果工具有五六个参数，而且项目里有十几个工具，每个都这样手写……
不仅代码量爆炸，参数描述和实际的 Go 结构体还是两套东西。
改一个忘了改另一个，迟早出问题。

所以 evo-agent 用反射来自动生成 Schema：

// GenerateSchema 用反射从 Go 结构体生成工具的 InputSchema
func GenerateSchema[T any]() anthropic.ToolInputSchemaParam {
    reflector := jsonschema.Reflector{
        AllowAdditionalProperties: false,
        DoNotReference:            true,
    }
    var v T
    schema := reflector.Reflect(v)
    return anthropic.ToolInputSchemaParam{
        Properties: schema.Properties,
    }
}

只需要定义一个 Go 结构体，用 tag 写上字段描述，Schema 就自动生成了：

type BashInput struct {
    Command string `json:"command" jsonschema_description:"The shell command to run."`
}

type ReadFileInput struct {
    Path  string `json:"path"            jsonschema_description:"The relative path of a file."`
    Limit int    `json:"limit,omitempty" jsonschema_description:"Maximum lines to return (0 = no limit)."`
}

一石二鸟。
LLM 会读这份 Schema，知道该传什么参数。
Go 程序收到 LLM 的 JSON 后，json.Unmarshal 进对应的结构体，完成类型安全的参数解析。
定义一次，两边都用。

六、四个工具详解

6.1 bash：万能瑞士军刀

bash 是最灵活的工具。
只要是 Shell 能做的事，它都能做。

bash(command="ls -lh")
bash(command="git log --oneline -5")
bash(command="grep -r 'TODO' ./src")

但灵活也意味着需要更多防护。
实现上有几个关键设计：

用 exec.CommandContext 设置 120 秒超时，防止命令卡死
合并 stdout 和 stderr（CombinedOutput），让 LLM 能看到完整输出（包括错误）
输出截断到 50000 字符，避免 token 爆炸
空输出返回 "(no output)"，而不是空字符串，LLM 更容易理解

func runBash(command string) string {
    ctx, cancel := context.WithTimeout(context.Background(), 120*time.Second)
    defer cancel()

    cmd := exec.CommandContext(ctx, "bash", "-c", command)
    out, err := cmd.CombinedOutput()

    if ctx.Err() == context.DeadlineExceeded {
        return "Error: Timeout (120s)"
    }
    // ...
}

6.2 read_file：精准读取

bash 当然也能 cat 文件。
但专门的 read_file 工具更语义化，也更可控。

read_file(path="src/main.go")
read_file(path="large_log.txt", limit=50)   // 只读前 50 行

实现要点：

支持 limit 参数，读大文件时只取前 N 行，后面追加 "... (N more lines)"
同样做 50000 字符截断
不支持读目录（目录用 bash + ls 处理）

func runReadFile(path string, limit int) (string, error) {
    data, _ := os.ReadFile(path)
    text := string(data)
    if limit > 0 {
        lines := strings.Split(text, "\n")
        if limit < len(lines) {
            text = strings.Join(lines[:limit], "\n") +
                fmt.Sprintf("\n... (%d more lines)", len(lines)-limit)
        }
    }
    return text, nil
}

6.3 write_file：全量写入

write_file 用于创建新文件，或者完全覆盖一个文件。

write_file(path="output/result.txt", content="Hello, World!")
write_file(path="src/new_feature.go", content="package main\n...")

实现要点：

自动创建父目录（os.MkdirAll），不用先 mkdir -p
返回写入字节数，方便 LLM 确认写入成功

func runWriteFile(path, content string) (string, error) {
    os.MkdirAll(filepath.Dir(path), 0o755)
    os.WriteFile(path, []byte(content), 0o644)
    return fmt.Sprintf("Wrote %d bytes to %s", len(content), path), nil
}

6.4 edit_file：精准替换

这是最精妙的一个工具。

为什么需要它？
write_file 每次都要写整个文件。
如果只需要改一行代码，让 LLM 重写整个文件，效率很低，而且它容易”改着改着把其他内容搞丢了”。

edit_file 只替换文件中的一个片段。
传入旧内容 old_str 和新内容 new_str，只动这一处，其他地方纹丝不动。

edit_file(
  path="src/main.go",
  old_str="fmt.Println(\"hello\")",
  new_str="fmt.Println(\"hello, agent!\")"
)

实现要点：

old_str 必须在文件中唯一存在，避免误改
old_str 为空且文件不存在时，等价于创建新文件（复用 write_file 逻辑）
用 strings.Replace(..., 1) 只替换第一处匹配，作为额外的安全兜底

func runEditFile(path, oldStr, newStr string) (string, error) {
    data, err := os.ReadFile(path)
    if os.IsNotExist(err) && oldStr == "" {
        return runWriteFile(path, newStr)  // 文件不存在 + 空 old_str = 创建
    }

    content := string(data)
    if !strings.Contains(content, oldStr) {
        return "", fmt.Errorf("edit_file: old_str not found in %s", path)
    }

    newContent := strings.Replace(content, oldStr, newStr, 1)
    os.WriteFile(path, []byte(newContent), 0o644)
    return fmt.Sprintf("Edited %s", path), nil
}

七、工具执行器：连接 LLM 和工具

LLM 返回的响应是一个内容块列表（[]ContentBlockUnion），里面可能包含三种东西：

ThinkingBlock：模型的思考过程（扩展思维功能）
TextBlock：普通文本输出
ToolUseBlock：工具调用请求

executor.go 负责遍历这个列表，碰到 ToolUseBlock 就去执行：

func Execute(content []anthropic.ContentBlockUnion) []anthropic.ContentBlockParamUnion {
    var results []anthropic.ContentBlockParamUnion

    for _, block := range content {
        switch v := block.AsAny().(type) {
        case anthropic.ThinkingBlock:
            ui.PrintThinking(v.Thinking)

        case anthropic.TextBlock:
            ui.PrintText(v.Text)

        case anthropic.ToolUseBlock:
            ui.PrintToolCall(v.Name)                                         // 打印工具名
            ui.PrintCommand(fmt.Sprintf("%s(%s)", v.Name, v.Input.Raw()))   // 打印参数

            inputBytes, _ := json.Marshal(v.Input)
            output, err := Dispatch(v.Name, inputBytes)                      // 执行工具

            isError := err != nil
            results = append(results, anthropic.NewToolResultBlock(v.ID, output, isError))
        }
    }

    return results
}

执行结果会被打包成 ToolResultBlock，下一轮发给 LLM，让它继续思考。

整个数据流如下：

flowchart LR
    A["LLM 响应\n[]ContentBlockUnion"] --> B{块类型}
    B -->|ThinkingBlock| C[打印思考过程]
    B -->|TextBlock| D[打印文本]
    B -->|ToolUseBlock| E[Dispatch 工具]
    E --> F{工具注册表}
    F -->|bash| G[执行 Shell]
    F -->|read_file| H[读取文件]
    F -->|write_file| I[写入文件]
    F -->|edit_file| J[编辑文件]
    G & H & I & J --> K["ToolResultBlock\n(结果 or 错误)"]
    K --> L[追加到 Messages]
    L --> M[下一轮 LLM 调用]

八、Agent 主循环的完整视角

前面分别讲了 Loop 和 Tools。
现在把它们合在一起看，整个 Agent 的运作过程就一目了然了。

sequenceDiagram
    participant User as 用户
    participant AgentLoop as Agent Loop
    participant LLM as LLM API
    participant Exec as 工具执行器
    participant Tool as 工具 (bash/file...)

    User->>AgentLoop: 输入任务
    loop 直到 stop_reason = end_turn
        AgentLoop->>LLM: Messages + Tools Schema
        LLM-->>AgentLoop: "响应 (可能含 tool_use)"
        AgentLoop->>Exec: "Execute(response.Content)"
        Exec->>Tool: "Dispatch(name, input)"
        Tool-->>Exec: 执行结果
        Exec-->>AgentLoop: []ToolResultBlock
        AgentLoop->>AgentLoop: 追加 tool_result 到 Messages
    end
    AgentLoop->>User: 最终回答

核心代码（loop.go）非常简洁：

func (a *Agent) RunOneTurn(state *LoopState) bool {
    // 1. 调用 LLM
    resp, _ := a.client.Messages.New(ctx, anthropic.MessageNewParams{
        Messages: state.Messages,
        Tools:    tools.Tools(),  // 所有注册的工具
        // ...
    })

    // 2. 追加助手响应
    state.Messages = append(state.Messages, resp.ToParam())

    // 3. 执行工具
    toolResults := tools.Execute(resp.Content)

    // 4. 没有工具调用 → 结束
    if len(toolResults) == 0 {
        return false
    }

    // 5. 追加工具结果 → 继续下一轮
    state.Messages = append(state.Messages, anthropic.NewUserMessage(toolResults...))
    return true
}

func (a *Agent) Loop(state *LoopState) {
    for a.RunOneTurn(state) {}
}

你看，整个 Loop 的逻辑其实就一行：for a.RunOneTurn(state) {}。
简洁到有点过分。
但就是这一行，驱动了 Agent 的全部行为。

九、为什么要有多种文件工具？

有人可能会问：有了 bash，cat、echo、sed 什么都能干。
那为什么还要单独实现 read_file、write_file、edit_file？

原因有三。

第一，语义更清晰，LLM 选择更准确。
LLM 在选工具时，是根据工具描述来判断的。
read_file 的描述明确说”读文件内容”，比让 LLM 自己去猜该用什么 shell 命令更可靠，出错率更低。

第二，安全性和可控性更好。
bash 是万能的，但万能也意味着危险。
rm -rf / 也是合法的 bash 命令。
专用文件工具只做文件操作，边界清晰，日后加权限控制也方便。

第三，输出更结构化，便于处理。
用 bash 执行 cat 的输出可能有细微差别（比如某些情况下多了换行符）。
专用工具的输出就是干净的文件内容，LLM 处理起来更省心。

简单说就是：能用专用工具就别用万能工具。
能用确定性的方案，就别引入不确定性。

graph TD
    A[LLM 需要操作文件] --> B{选择工具}
    B --> C["bash\n万能但危险\n适合复杂操作"]
    B --> D["read_file\n安全只读\n适合查看内容"]
    B --> E["write_file\n全量覆盖\n适合创建新文件"]
    B --> F["edit_file\n精准替换\n适合修改已有文件"]

    style C fill:#ff9999
    style D fill:#99ff99
    style E fill:#99ccff
    style F fill:#ffcc99

十、总结

回顾一下这篇文章的几个要点：

1. 工具决定了 Agent 的能力边界。
你给它什么工具，它就能干什么活。
只有 bash 和有一整套文件操作工具，体验完全不一样。

2. init() 自注册，加工具不用改老代码。
新建一个文件就搞定，干净利落。

3. 能用专用工具就别用 bash。
语义更清晰，更安全，LLM 选错的概率也更低。

4. 工具描述写给 LLM 看，不是写给自己看。
名字要直白，描述要具体，参数要明确。
LLM 读不懂你的工具描述，它就不会用。

到这里，我们的 Agent 已经有了大脑（LLM）、神经反射弧（Loop）、和手脚（Tools）。
下一篇，我们继续完善这个 Agent，看看还能给它装上什么新能力。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号ID：tiankonguse-code

Agent 的本质：一个简单的循环 (Loop)

2026-05-07T12:13:00+08:00

最近跟不少朋友聊 Agent，发现大家对这个词的理解差异巨大。
有人觉得 Agent 就是更高级的 ChatGPT，有人觉得 Agent 是某种很玄乎的 AI 黑科技。

但其实，当你真正去拆解它的时候，你会发现一个事实：

Agent 的本质，就是一个 Loop（循环）。

没了。
就这么简单。

一、从 Chatbot 到 Agent

先说一个很多人搞混的事。

LLM 和 Agent，不是一个东西。

打个比方：

Chatbot（聊天机器人），就像一个坐在椅子上的教授。
你问他问题，他凭记忆给你答案。
但他不会站起来，不会帮你查资料，不会动手帮你干活。
他只负责”说”。

Agent（智能体），是给这个教授装上了手脚，还给他打了一针肾上腺素。
他不光能说，他还能动。
能查文件，能执行命令，能调接口，能自己验证自己的答案对不对。

那问题来了。

一个有手有脚的 AI，它怎么知道什么时候该动手，什么时候该停下来？

答案就是 Loop。

如果 LLM 是大脑，那 Loop 就是它的神经反射弧。
没有 Loop，LLM 就是一个瘫在轮椅上的天才。
有了 Loop，它才能站起来走路。

二、为什么 Agent 需要 Loop？

这事得从 LLM 的一个致命缺陷说起。

LLM 是一个一次性生成过程。
一旦它开始输出，就没办法在中途停下来，看看现实世界发生了什么，然后修正方向。

什么意思？

就好比你让一个人蒙着眼睛走迷宫。
他可能很聪明，能猜出大概的路线。
但他看不见墙在哪，看不见岔路口在哪，看不见自己有没有走偏。

而 Loop 的作用，就是每走一步，给他摘一下蒙眼布。
让他看一眼环境，调整方向，再继续走。

这个”走一步看一步”的模式，在学术界有个正式的名字，叫 ReAct（Reason + Act）。

核心流程长这样：

三、循环内部发生了什么？

每一次循环，其实就四件事。

第一步，Thought（思考）。
LLM 看看当前的情况，想一想接下来该干嘛。
比如：”用户让我找最大的文件，那我得先看看目录里有哪些文件。”

第二步，Action（行动）。
想好了就动手。
LLM 不再是吐出最终答案，而是发出一条”指令”，去调用一个外部工具。

第三步，Observation（观察）。
工具执行完了，把结果返回来。
LLM 拿到这个结果，看看发生了什么。

第四步，Loop（回到第一步）。
LLM 把观察到的结果塞进上下文，再次进入思考。
如此往复，直到它觉得信息够了，可以给出最终答案为止。

就这四步，不断循环。

没有 Loop，LLM 只能靠猜。
有了 Loop，LLM 能靠真实反馈来验证。

这就是本质区别。

四、来个具体例子

说个最简单的场景：让 Agent 找出目录下最大的文件。

第一轮循环：
Thought：我需要列出文件和大小。
Action：执行 ls -S -l。
Observation：拿到了文件列表。

第二轮循环：
Thought：看到了，最大的文件是 file_a。
Action：不需要再调工具了，直接出答案。
Final Answer：最大的文件是 file_a。

两轮就搞定了。

注意，Agent 不是一步到位”猜”出来的。
它是走了一步，看了一眼结果，确认没问题，才给出的答案。

这就是 Loop 的力量。
不靠猜测，靠验证。

五、Loop 是 Agent 的灵魂

为什么我说 Loop 是灵魂？

因为一个 Agent “聪明”不”聪明”，很多时候根本不取决于它用了多强的模型。
而是取决于它的 Loop 设计得好不好。

第一，容错。
命令报错了怎么办？
没有 Loop 的系统，直接趴窝。
有 Loop 的 Agent，看到报错，想想为什么错了，换个方式再来一遍。

第二，分解复杂任务。
一个大任务拆成一百个小步。
每一步都简单到不容易出错，串起来就能完成非常复杂的工作。
这就是 Loop 天然的分治能力。

第三，自主决策。
有了 Loop，Agent 不需要你手把手教每一步该干嘛。
它能根据环境反馈，自己判断下一步做什么。
这才是真正的”智能体”。

六、总结

学 Agent，第一天最重要的认知就一条：

不要想着写一个完美的 Prompt 一步到位。
而是要构建一个 Loop，让 AI 在跟环境的交互中，一步一步逼近正确答案。

一句话：

Agent = LLM（大脑）+ Tools（手脚）+ Loop（神经反射弧）。

有了大脑，它能想。
有了手脚，它能动。
有了 Loop，它才能像一个真正的人一样，边做边看，边看边调。

这就是 Agent。
没有什么玄乎的。

就是一个循环。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号ID：tiankonguse-code

leetcode 周赛 500

2026-05-05T12:13:00+08:00

零、背景

这次比赛时间在 5 月 3 号，我还在五一休假，故没参加比赛。
5 号有时间了，补做了一下比赛。

本场题型概览如下。
A 题：统计。
B 题：素数。
C 题：前缀和。
D 题：二维 LIS。

一、统计下标的相反奇偶性得分

题意：给一个数组，统计每个下标对应的值与后缀中值的奇偶性不同的个数。

思路：统计。

从后到前统计奇偶值的个数，即可得到每个下标的答案。

二、区间内的质数和

题意：给一个数字 a，反转得到数字 b，问 [a, b] 之间素数的个数。

思路：筛素数。

方法1：数据范围不大，逐个判断是否是素数即可。
方法2：前缀和预处理每个数字前缀素数的个数，两个前缀和求差即可。

三、在下标间移动的最小代价

题意：给一个严格递增的数组，有两类移动操作。
操作1：从下标 x 跳到下标 y，代价为 abs(nums[x] - nums[y])。
操作2：从下标 x 移动到最近的相邻位置，代价为 1。
有 q 个询问，问从下标 x 移动到 y 的最小代价。

最近相邻位置定义：左右最近的位置，如果距离相等，则下标小的为最近的位置。

思路：前缀和。

分析：由于数组严格递增，从下标 x 直接跳到下标 y，等价于沿这个方向逐个跳过去。
因此，如果某一跳刚好是最近的相邻位置，则可以贪心地使用操作2 来降低代价。

暴力模拟复杂度为 O(q * (y - x))。

优化：预处理第一个位置到任意一个位置的累计代价，通过前缀和求差，即可求出任意两个位置之间的代价。

注意事项：两个方向的代价不一样，前缀和与后缀和需要分别计算。

四、删除元素后最大固定点数目

题意：给一个数组，删除若干元素，问最多可以使多少个下标与值恰好相等。

思路：二维最长递增子序列。

删除元素后，后面的元素会左移，所以只有 nums[i] <= i 时，nums[i] 才可能通过左移与位置匹配。
另外，nums[i] 要到达下标 nums[i]，左边需要恰好删除 i - nums[i] 个元素。

假设预处理所有满足条件的数字对 (v, i-v)，如何才能保证两个数字的值都与位置匹配呢？

假设有两个数字 v1 和 v2，左移的偏移距离分别是 d1 和 d2。

如上图，显然 d1 需要小于等于 d2，d1 个数字在 v1 之前删除，d2-d1 个数字在 v1 到 v2 之间删除。
故只要满足 d1 <= d2 且 v1 < v2，就可以保证两个数字的值都与位置匹配。

由此，这道题转化为一个二维最长递增子序列问题：对于 d 需要满足非递减，对于 v 需要满足严格递增。

回顾一维 LIS 的 n log(n) 算法，利用的是 DP + 二分思想。
dp 状态 tail[i] 定义为长度为 i+1 的递增子序列中，结尾元素的最小值。

这样做的原因是：结尾越小，后面越容易接上更多数字。

对于一个新的数字 v，我们需要找到小于 v 的最大答案。
在 tail 中，值小于 v 的都是合法答案，最后一个就是最长的答案，故 v 可以放在其下一个位置。

auto it = upper_bound(dp.begin(), dp.end(), x);
if (it == dp.end()) {
  dp.push_back(x);
} else {
  *it = x;
}

对于二维，比较抽象，有两种做法。

做法1：第一维非递减，第二维严格递增，使用 lower_bound。
由于第二维要求严格递增，不能有等于，所以使用 lower_bound。

// 要求：第一维非递减，第二维递增
// 排序：默认，需要使用 lower_bound
int Lis2(vector<pair<int, int>>& pts) {
  sort(pts.begin(), pts.end());

  vector<int> tails;
  for (auto& [x, d] : pts) {
    auto it = lower_bound(tails.begin(), tails.end(), d);
    if (it == tails.end()) {
      tails.push_back(d);
    } else {
      *it = d;
    }
  }
  return tails.size();
}

做法2：第一维严格递增，第二维非递减，使用 upper_bound。
由于第二维允许重复，所以使用 upper_bound。

// 要求：第一维递增，第二维非递减
// 排序：第一维升序，第二维降序，使用 upper_bound
int Lis2(vector<pair<int, int>>& pts) {
  // x 升序；x 相同则 d 降序
  sort(pts.begin(), pts.end(), [](const auto& a, const auto& b) {
    if (a.first != b.first) return a.first < b.first;
    return a.second > b.second;
  });

  // 在 d 上求最长非递减子序列
  vector<int> tails;
  for (auto& [x, d] : pts) {
    auto it = upper_bound(tails.begin(), tails.end(), d);
    if (it == tails.end()) {
      tails.push_back(d);
    } else {
      *it = d;
    }
  }

  return tails.size();
}

不管哪种做法，二维 LIS 都比一维 LIS 更抽象一些。

五、最后

这次比赛最后一题是二维 LIS，属于比较抽象的模板题。
如果比赛时遇到这类问题，我会选择使用线段树或者树状数组来求区间最大值，从而降低理解难度。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号 ID：tiankonguse-code

leetcode 周赛 499

2026-04-26T12:13:00+08:00

零、背景

这次比赛其实不难，但是我写线段树被卡超时了，显示超出时间限制 947 / 958 个通过的测试用例。
最后各种尝试常数优化，不小心还 WA 一次，然后才通过。

本场题型概览如下。
A 题：前缀和。
B 题：统计排序。
C 题：贪心。
D 题：DP+滑动窗口+线段树。

一、数组中的有效元素

题意：如果一个元素严格大于左侧所有元素或者右侧所有元素，则称为有效元素。
要求按原顺序输出所有有效元素。

思路：前缀和

预处理出前缀最大值和后缀最大值，然后依次判断即可。

二、按频率对元音排序

题意：给一个字符串，要求对元音字符排序。
排序规则：优先按出现的频率排序，频率相同时按首次出现位置排序。

思路：统计排序

按题意，统计每个元音字符的频率和首次出现位置。
然后将 map 转化为数组并按题目要求排序，从而得到排序后的分组元音列表。
最后，遍历字符串，遇到元音，就从排序后的结果集中按顺序取一个元音。

小技巧：排序后对容器翻转，则把获取第一个元素变成获取最后一个元素，从而可以 O(1)删除元音。

三、使数组非递减需要的最小累计值

题意：给一个数组，每次操作可以对一个子数组都加上一个数字。
求怎么操作，才能使得数组非递减有序，且操作的数字之和最小。

思路：贪心

目标是让数组递增，显然，每次操作时选择一个中间子数组，肯定不如选择整个后缀更优。

证明：假设答案中某个操作不是后缀，则把这个操作的后缀都补齐，不影响最终答案。

有了这个推论，就可以推导出贪心算法：每次相邻位置值变小时，下个位置的值就应该加上差值，使得与上个位置的值相等。

四、距离至少为 K 的交替子序列的最大和

题意：给一个数组和正整数 K，如果选择的子序列下标位置差不小于 K 且子序列是严格交替变大变小的，则称为有效子序列。
求有效子序列中子序列元素值之和的最大和。
严格交替变大变小定义：任意相邻三个元素，中间的值要么大于两边的元素，要么小于两边的元素。

思路：动态规划+滑动窗口+线段树

首先很容易想到一个简单的动态规划方程。

状态定义：dp[i][dir] 第 i 个元素作为 dir 序结尾的最大有效子序列和。

状态转移方程：

dp[i][1] = nums[i] + max(dp[j][0]) && j <= i - k && nums[j] < nums[i];
dp[i][0] = nums[i] + max(dp[j][1]) && j <= i - k && nums[j] > nums[i];

方程分两部分。
1）自身就是最大值。
2）前面还有元素，但是交替变大变小的方向需要与当前的相反，且满足大小关系。

复杂度：O(n^2)

优化方向显然在 max(dp[j][dir])。

第一个优化：j 永远比 i 小 k，显然是滑动窗口，窗口外的才参与计算，由此消除 k。

此时，问题转化为了 max(dp[j][dir]) && nums[j] < nums[i]。
对于nums[j] < nums[i]，公式转化为文字就是，求值 nums[j] 小于 nums[i] 的所有位置里，最大的 dp[j][dir]。
对于nums[j] > nums[i]，含义是类似的，这里暂时不重复描述了。

如果把 nums[j] 当做下标，则问题转化为了，求区间 [1, nums[i]-1] 的最大值。
显然可以使用线段树来做。

正常情况下，是需要对 nums[j] 做离散化的。
不过这道题的 nums 值域不大，且都是正整数，可以直接用来当做下标。

由此，我们就可以通过线段树来解决一个维度小于指定值时另一个维度的最值问题。

注意事项：不要从线段树中求最终答案，应该从 max(dp) 中求最终答案。
因为滑动窗口内的答案还没有加入线段树，直接求就会少算一部分，从而导致答案错误。

五、最后

这次比赛最后一题算是稍微复杂一点的题，结合了动态规划、滑动窗口、线段树。
如果把值域设置的大一些，再引入离散化，这道题就完美了。

《完》。

-EOF-

本文公众号：天空的代码世界个人微信号：tiankonguse 公众号 ID：tiankonguse-code

leetcode 周赛 498

2026-04-19T12:13:00+08:00

零、背景

这次比赛比较简单，第三题BFS，第四题数位DP。

本场题型概览如下。
A 题：前缀和。
B 题：前缀和。
C 题：BFS。
D 题：数位DP。

一、最小稳定下标 I

题意：给一个数组，前缀最大值减去后缀最大值如果小于等于K，则称为稳定值，求稳定值的最小下标。

思路：前缀和

预处理出前缀和与后缀和，然后计算出稳定值。

二、最小稳定下标 II

与第一题一模一样。

三、多源洪水灌溉

题意：给一个矩阵，若干位置有颜色值，每一秒有颜色值的位置会朝上下左右的空位置染色。
如果同一个空位置同时被多个来源染色，则保留染色值最大的那一个。
问最终矩阵各个位置的颜色值。

思路：BFS

染色的过程是逐层进行的，所以需要使用 BFS。
数据结构：queue<pair<x,y>>

while (!q.empty()) {
  const auto [r, c] = q.front();
  q.pop();
  for (const auto& [dr, dc] : dirs) {
    const int nr = r + dr, nc = c + dc;
    if (nr < 0 || nr >= n || nc < 0 || nc >= m) continue;
    if (ans[nr][nc] == 0) {  // 没有被染色过
      ans[nr][nc] = ans[r][c];
      q.emplace(nr, nc);
    }
  }
}

同时染色时需要保留最大的那个。
故还需要记录一个层数，或者称为步长，或者称为时间戳。
数据结构：vector<vector<int>> steps;

对于层数相同的染色，不能重复入队，只需要更新染色值。

// 没有被染色过
if (ans[nr][nc] == 0) {  
  ans[nr][nc] = ans[r][c];
  steps[nr][nc] = steps[r][c] + 1;
  q.emplace(nr, nc);
}
 // 同一时间被染色，选择颜色较大的
if (steps[nr][nc] == steps[r][c] + 1) { 
  ans[nr][nc] = max(ans[nr][nc], ans[r][c]);
}

四、统计网格路径中好整数的数目

题意：一个不大于9*10^15的数字，组成一个带前导零的16位数组，然后从高位开始每 4 位一行，组成一个 4*4的矩阵。
然后告诉你三个向右与三个向下的方向，从而得到一个从左上角到右下角的路径。
如果路径上的数字序列是非递减的，则称这个数字是好数字。
问区间 [l,r] 内好数字的数量。

思路：数位DP

假设有一个函数 f(x) 可以求出 [0,x]的所有好数字。
则区间 [l,r] 内的好数字等价于 f(r) - f(l-1)。

题目中的路径是确定的，所以数字的位数也是确定的，且涉及 7 个位数，从高位到低位保持非递减。
路径外的数字不需要遵循非递减这个性质。

显然，可以从高位到低位枚举所有数字。
枚举的过程中，如果在路径上，需要保持非递减的性质，如果不在路径上，则可以任意选择。

下面是数位DP的模板。

string s;
ll cache[17][11][2];
ll Dfs(int pos, int preSelectVal, bool limit) {
  if (pos == 16) {
    return 1; // 出口
  }
  if (cache[pos][preSelectVal][limit] != -1) {
    return cache[pos][preSelectVal][limit];
  }
  int up = limit ? s[pos] - '0' : 9;
  ll ret = 0;
  for (int val = 0; val <= up; val++) {
    if (IsInpath[pos]) {
      // 路径上的点，必须大于等于前一个点的值
      if (val >= preSelectVal) {
        ret += Dfs(pos + 1, val, limit && val == up);
      }
    } else { 
      // 非路径上的点，都可以选择
      ret += Dfs(pos + 1, preSelectVal, limit && val == up);
    }
  }
  return cache[pos][preSelectVal][limit] = ret;
}

当然，上下界我们也可以一起实现。

string SL, SR;
ll cache[17][11][2][2];
ll Dfs(int pos, int preSelectVal, bool limitDown, bool limitUp) {
  if (pos == 16) {
    return 1;
  }
  if (cache[pos][preSelectVal][limitDown][limitUp] != -1) {
    return cache[pos][preSelectVal][limitDown][limitUp];
  }
  int down = limitDown ? SL[pos] - '0' : 0;
  int up = limitUp ? SR[pos] - '0' : 9;
  ll ret = 0;
  for (int val = down; val <= up; val++) {
    if (IsInpath[pos]) {
      if (val >= preSelectVal) {
        ret += Dfs(pos + 1, val, limitDown && val == down, limitUp && val == up);
      }
    } else {
      ret += Dfs(pos + 1, preSelectVal, limitDown && val == down, limitUp && val == up);
    }
  }
  return cache[pos][preSelectVal][limitDown][limitUp] = ret;
}
ll ans = Dfs(0, 0, true, true);

五、最后

这次比赛题目比较简单，排名只有 92 名了。
之前的比赛，每次我都是手动敲数位DP的。
这次比赛我整理了自己的数位DP模板，下次应该就可以直接复制过来使用了吧。

《完》。

-EOF-

本文公众号：天空的代码世界个人微信号：tiankonguse 公众号 ID：tiankonguse-code

vibe coding：放弃 Node，转 Go

2026-04-17T12:13:00+08:00

零、背景

上上周我在《2周消耗4亿tokens做8个项目》提到，我连续两周 vibe coding 写了不少项目。

上周我在《spec code 将被 agent 替代》中分享了我使用 OpenSpec 的经验，以及在《更强大的 spec-kit》中分享了 Spec-kit 的经验。

之前 vibe coding 写的代码全是前端代码，技术栈是 Node + JavaScript + SQLite。

这周继续 vibe coding，发现当需要大量计算数据时，Node 性能太差了，所以我开始转向生成 Go 代码。

回顾一下，这周 vibe coding 了 5 个工具：时钟误差检测工具、Redis 数据一致性监控系统、缓存中间件一致性监控系统、HTTP 代理系统、Union 压测系统。
另外，对于之前开发的热度值监控系统，我也使用 Go 进行了重构，重构后系统稳定多了。

接下来简单分析下这些系统工具。

一、热度值监控

热度值监控，是为了从用户视角监控每个剧集的热度值发生变化时，数据是否会回退。

虽然做了一版优化，监控数据显示，优化后依旧存在某些时刻会有数据回退的现象。

所以，需要分析是什么原因导致了数据回退。
为此，我开发了以下这些工具。

二、时钟误差检测工具

每个剧集的热度值，会在固定的时间统一刷新。
如果多个机器的时间存在差异，那自然就会有些机器刷新较慢，导致拉到旧数据。
基于此，我 vibe coding 了一个容器时钟偏差检测服务 Time Checker。

服务功能：一个基于 NTP 式四时间戳探测的中心化时钟偏差检测系统，用于检测多个容器之间的系统时钟是否一致。

系统架构如下：

实现原理很简单，通过两个机器之间互相发送一个数据包，各自记录发送时间与接收时间，从而能够解方程计算出时钟偏差，还能顺便计算出平均网络延迟。

NTP 式偏差计算原理如下：

跑完之后，发现各个机器之间的时间误差只有 1.5 毫秒，排除了时间误差这个方向。

三、Redis 热度值实时采集与监控系统

既然机器时钟没问题，那底层的存储是否有问题呢？
如果存储数据本身就存在来回跳变，那上游系统自然也会发生来回跳变。

需求：实现一个高性能的 Redis 热度值监控后台服务，使用 Golang 开发，每秒从 Redis 中批量拉取 10 个剧集 ID 对应的两个热度值，解析后写入 MySQL 表中，并定时清理超过 24 小时的历史数据。

选择 Go 的理由：性能优先；Go 的并发模型（goroutine + ticker）天然适合定时采集任务，内存占用低，编译为单一二进制部署简单。

技术栈

语言：Go 1.21+
Redis 客户端：github.com/redis/go-redis/v9（高性能，原生支持 Pipeline）
MySQL 客户端：github.com/go-sql-driver/mysql + database/sql（标准库连接池）
日志：Go 标准库 log/slog（Go 1.21+ 内置结构化日志）
配置管理：硬编码 config 结构体（项目简单，无需配置文件解析库）
部署环境：Linux（直接运行二进制，nohup 或 systemd 管理）
构建：Go Modules

架构设计

跑了半个小时，就再次遇到热度值波动。

分析这一分钟 Redis 的流水，发现 Redis 数据是正常的。

分析 Redis 实例，发现 Redis 开启了副本读，会不会是副本的数据比较旧呢？

于是我又改造这个服务，改成每秒读取 N 次，看是否存在数据不一致。
最后发现 Redis 数据依旧是一致的。

四、缓存一致性监控系统

由于热度值监控系统是通过外网页面接口抓取的，所以无法获取到数据是从哪个缓存节点读取的。

而这个缓存组件有一个 debug 开关，支持对指定来源流量，把链路的缓存节点信息也返回出去。

于是我便开发了一个缓存一致性监控系统，打开 debug 开关，把缓存节点信息和数据都当做流水存到 DB 中。

需求：一个 Golang 后台常驻程序，定时从 Union 接口拉取指定剧集 ID 的热度值数据，解析后存储到 MySQL 数据库，并自动清理过期数据。

系统架构：

数据流：

可以发现，这个系统和上面的 Redis 监控系统非常类似，区别在于把下游从 Redis 换成了缓存中间件，并且存储的数据多了缓存节点信息。

当热度值监控系统发现有不一致时，分析缓存一致性监控的流水，竟然没有发现数据跳变。

这时候，我就开始怀疑是不是热度值监控系统自身的问题了。
一个是 Go 系统，一个是 Node 系统，理论上结果应该是一致的，很奇怪。

五、HTTP 代理服务

上一小节提到，热度值监控系统因为使用外网接口，导致无法获取缓存节点调试信息。
那就有必要开发一个 HTTP 代理服务来代替外网接口，协议保持一致，从而可以返回调试信息。

需求：一个轻量级的 HTTP 网关服务，将 HTTP 请求转换为 UnionPlus 内部 RPC 调用，实现对视频/内容热度值数据的批量查询。

架构设计：

随后修改热度值监控系统，把返回的缓存节点信息也存下来。

当再次发生返回旧数据的 case 后，分析流水，发现返回旧数据的那个容器在数据变化后的这段时间里从来没被访问过。
也就是说，对于同一个容器，数据一旦变化，确实都返回新数据了。

那为什么偶尔一个节点在数据更新若干秒后，还会返回旧数据呢？
这时候，只有一个答案了：缓存节点确实返回了旧数据。

什么场景会发生呢？
其实，当确定缓存节点返回旧数据时我就想到答案了。

缓存系统在数据更新时，为了避免热 Key 的回源量太高，都会做一个 singleflight 功能。
singleflight 的含义是只让一个请求去回源。

对于其他请求，目前缓存中间件的策略是直接使用旧数据。
也正是这个策略，有概率使得访问量不大的剧集热度值返回旧数据。

六、Union 压测系统

上一小节提到，热度值返回旧数据的原因猜测是 singleflight 导致的。
触发场景是对应的剧集访问量太小，缓存节点持续很久都没有被访问，突然来的访问又存在并发，从而触发了 singleflight。

针对这个猜测，验证手段就是进行压测，看增加流量后是否还有这个问题。
于是，我又开发了一个 Union 压测系统。

功能：batch_union 是一个基于 tRPC-Go 框架的 Union 数据平台批量压测工具。
它按照指定的 QPS（每秒请求数）持续向 UnionPlus 服务发起批量查询请求，用于对 Union 读取链路进行压力测试和稳定性验证。

执行流程：

架构设计如下：

几分钟这个压测系统就写好了。
然后进行压测，发现热度值确实稳定多了。

这个是压测前的监控：

下面是压测后的监控，跳回旧数据的波动明显小了很多。

为何还是会偶尔有波动呢？
针对这些 case 去分析流水，发现是热度值统计错误。
在数据变化的时候，偶尔会丢失几秒的数据，从而导致系统误判为波动。

七、Go 重构 Node

上一小节提到，系统偶尔会丢失数据，从而导致误判波动值。

为啥会丢失数据呢？
那几秒 Node 刚好在定时压缩数据，负载跑得比较高。
看来跑数据还是不能使用 Node，使用高性能编程语言才是最优解。

需求：将 HotVal 热度值监控系统中的数据采集模块从 Node.js Server 提取出来，使用 Golang 重新实现为独立的数据服务。
该服务负责数据采集、变化检测、数据压缩、数据修复、统计计算以及剧集管理 API。
同时对 Node.js Server 进行瘦身，使其仅保留前端页面服务和只读数据库查询，写操作代理转发到 Go 数据服务。

架构演进：

系统架构：

优化效果：

优化后，问题出现的概率确实进一步降低了，但由于增大流量只是降低概率，还是偶尔会发生一次。

针对这个问题，我之前其实有相关的优化规划。

产生旧数据的原因是相同 Key 并发过期时，只有一个请求下去更新。
如果其他使用旧数据的请求还有其他字段也需要去下游拉取最新数据，那么这些请求在回包之前，对于命中 singleflight 的字段可以再读一次缓存，就有很大的概率读到最新的数据。

当然，这个优化也只是进一步降低概率，但再读一次共享缓存的成本非常低，为何不再读一次呢。

八、最后

这两周 vibe coding 又使用了几亿的 Tokens。
但是借助 vibe coding 确实大大提高了效率。

如果是以前，写一个工具，半天就过去了。
工具稍微复杂点，一天甚至两天就过去了。

而现在，有任何想法，马上就可以花十几分钟做出一个工具来，可以马上去验证想法了。

部分场景下，效率提升确实是几十倍。

《完》

-EOF-

本文公众号：天空的代码世界
个人微信号：tiankonguse
公众号ID：tiankonguse-code