fanfei's blog

Pi的bash timeout，为什么常常让Agent卡一整晚

Tue, 27 Oct 2026 16:00:00 +0800

昨天晚上睡觉前，我写了一份长长的 plan，让 Agent 照着实现。今天早上起来验收，发现它被一个有 bug 的脚本卡了六个多小时……

这已经不是第一次了。最近几个月，这个问题一直阴魂不散。我经常不得不手动打断 Agent，然后教育它：“你要把超时时间设短一点！这样是要等到什么时候？”我甚至写了一个让长命令自动转入后台的插件 pi-bg，拦截设置了较长 timeout 的调用，把任务放到后台运行。

可模型还是动不动就设一个超大的 timeout，然后在那里傻等。

和同事聊起这件事，大家觉得，可能是模型对物理世界里的时间没什么概念吧。

让英雄查英雄，让好汉查好汉

真是这样吗？它到底为什么要设这么久？

上午到公司之后，我决定直接问问模型。结果它给了我一个挺意外的解释。

它很可能把一个以毫秒计的数值，填进了一个按秒解释的参数里。

Claude Code 的 Bash timeout 单位是毫秒，Pi 的则是秒。60000 在前者是一分钟，到了后者就成了约 16.7 小时。即使 Pi 在 tool schema 里明确写了 seconds，模型有时还是会传入一个只有按毫秒理解才合理的大数。Claude Code 的超时配置、Pi 的 bash 实现

这和模型怎样学会用工具写代码有关。在后训练阶段，一种做法是让模型在沙箱里完成编程任务：读取仓库、修改代码、调用终端跑测试，再根据执行结果继续修改。训练系统用测试是否通过等反馈评价表现，通过强化学习更新模型。Qwen3-Coder 就公开介绍过这类多轮工具交互训练。Qwen3-Coder 的后训练介绍

模型在这个过程中学到的，也可能包括具体工具的使用习惯。如果它熟悉的环境按毫秒计时，换到 Pi 之后，就可能沿用那套数值。具体模型用了多少 Claude Code 相关训练数据，外部很难确认；但这种单位习惯的迁移，确实能解释日志里那些看起来离谱的 timeout。

有点像开惯了左舵车的人，突然换成右舵车。规则知道了，手上的习惯却未必马上改得过来。

不要跟模型较劲

Pi 社区早就有人遇到过类似问题。我翻了 Issue 区，#9785 直接讨论了秒与毫秒混淆，#1335 则建议增加默认超时，目前都已关闭。维护者在后者的回复里表示，很难为所有任务选一个合适的默认值，应该由 Agent 自己设置，也可以通过 AGENTS.md 引导它。

这个理由回答了“默认超时该设多少”，但单位误用还是会发生。我担心后来的人还会继续踩坑。顺便吐槽一句：新贡献者提的 Issue 默认会被自动关闭，再由维护者筛选是否重开，这套流程确实给我一种“高攀不起”的感觉。

这让我开始重新考虑 Agent 里工具接口的设计。

如果让你设计 DNS

Sat, 17 Oct 2026 10:00:00 +0800

假设你和几位同事搭起了一个小网络，你们的计算机之间能够通信，但是你们还没有自己的DNS服务器。

你们有一台机器，专门用来保存各种文件，这台机器的IP地址是 192.0.2.10。

每次有人想要下载文件，都需要手动输入192.0.2.10这个地址，可是大家真正想找的是“文件服务器”，并不想记住它的那串数字。

那就给这个文件服务器起一个容易记住的名字吧。

每台计算机都要保存所有地址吗？

我们把文件服务器叫作 files，邮件服务器叫作 mail，开发机器叫作 dev，再把对应关系保存到一个文件中：

192.0.2.10  files
192.0.2.20  mail
192.0.2.30  dev

有了这个文件，计算机去查询这个文件，把名字替换成对应的IP地址，这样我们就不用再记那些IP地址了。

这是 hosts 文件的基本思路。

给十台电脑各复制一份，大家就能使用相同的名字。

但如果这个网络里有一万台计算机呢？

如果文件服务器的IP地址从 192.0.2.10 换到了 192.0.2.40，谁来通知所有人？如果有人没来得及更新自己的hosts文件，那么他就访问不了files服务器了。

于是我们想到，我们可以指定一个服务器，让它来统一存放这张表，其他计算器定期从它那里下载。

早期互联网确实这样做过：由网络信息中心 NIC 集中维护 HOSTS.TXT，各主机取得副本使用。

但是随着主机增多，文件分发和集中更新逐渐成为负担。¹

我只想知道一台机器的地址，为什么必须下载整张表？

Computer A 想连接 files，先向查询服务器询问files服务器的地址，得到 192.0.2.40 后，再去请求文件服务器。

先查地址，再连接目标；查询服务器不转发文件。图中省略了握手和文件传输的具体报文。

“通过名字寻找对应信息”的过程，叫作名字解析（name resolution）。它解决了找地址的问题，但不保证目标一定能连上：服务器关机、网络不通，都可能让后面的连接失败。

查询服务器自己也需要一个入口。我们先把它的 IP，例如 192.0.2.53，写进客户端配置。

电脑仍需保存地址，但只需知道查询服务器的IP地址，而不必掌握整张通讯录。

下载全表的问题解决了，但是hosts文件的管理却仍集中在一台服务器上。

每所学校、每家公司修改自己的机器，都要访问同一台服务器。

增加查询服务器可以分担这台服务器的请求，但我们还可以进一步分散数据的管理。

全世界的名字，谁来管理？

我们可以让学校维护学校的记录，公司维护公司的记录，各自安排服务器，修改自己的数据。

不过，学校和公司都把文件服务器叫作 files，跨组织查询时该找哪一台？

把“属于谁”也放进名字就行。用两个虚构组织举例：²

files.school.example   → 192.0.2.40
files.company.example  → 192.0.2.80

局部名字都叫 files，完整名字却不同。

只要 school.example 和 company.example 的分配已经协调好，它们就能各自决定下面叫什么，不必为了新增一台机器再检查全世界的名字。

We need to forget — not Jev, not summaries

Sun, 20 Sep 2026 22:50:00 +0800

The past was a lie; memory has no return; every spring gone by could never be recovered.

— Gabriel García Márquez, One Hundred Years of Solitude

Intro

Jev is hot right now. fast-jev-compaction uses it for context compaction: instead of asking an LLM for a summary, it asks Jev to judge every tool call and its result — keep or drop. The repo got an official shout-out and nearly 5k stars in days. I liked the idea and wrote pi-jev to try this in pi.

We need to forget, not Jev or summary

Sun, 20 Sep 2026 22:50:00 +0800

过去都是假的，回忆是一条没有归途的路，以往的一切春天都无法复原，唯有孤独永恒。

—— 加西亚·马尔克斯，《百年孤独》

引子

最近 Jev 很火。fast-jev-compaction 拿它做上下文压缩：不是调用LLM做summary，而是让 Jev 对每个 tool call 和它的 result 做判断，判断"该保留还是丢弃"，这个项目还得了官方点赞，最近几天在github狂揽接近5k star。我觉得这个思路比较新颖，于是写了个插件 pi-jev，想在 pi 里试试这种新的压缩算法。

刚用的时候确实很爽，几乎在我敲下 /compact 的瞬间就完成了压缩，终于不用再等了。但用了一阵儿之后有点担心，这种压缩会不会丢掉什么重要的信息？我去翻了翻 fast-jev-compaction，没找到任何对压缩效果的评测，单元测试用的是假 Jev，唯一的量化输出是体积缩减率，它只关心压得够不够狠，但压得对不对，有没有把重要信息遗漏，没人关心。于是这个周末下午，我用本地近 2000 个 pi session，自己测了一把。

先说结论

用 Jev 做上下文压缩，约等于无脑丢弃所有 tool result，而后者还不用花钱。Jev 在默认阈值(0.5)下，9471 个tool result它一个不留；把阈值调低，它确实保留了一些，但是效果不比随机保留更好，甚至还更差；把tool result内容和最近几条user prompt作为state信息喂给它，效果也没有变化。
Jev 没有错，其实我们没有必要保留 tool result。约 800 万 token 的工具输出里，之后真正会用到的只有大概 3.6% 到 7.5%，可以简单地全部丢弃，模型在需要的时候重新执行一次 tool call，问题也不大。
我们让 LLM 做 summary，一边在浪费时间，一边在浪费 token。压缩这件事不需要动用 LLM：把工具输出丢掉、调用记录留着，不花一分钱，瞬间完成。模型拿着这样压缩出来的上下文接着干活，表现和用 LLM 写的摘要几乎没差别。

一、Jev compaction 好快我好爱，但是……它把所有的 tool result 都丢弃了？！

Jev 是 TypeSafe 提供的模型 API。它不是聊天模型，是个决策接口：发过去一个 state 和一组 questions，返回一组 answers。问题有三种类型：noul 对一个陈述返回 0 到 1 的概率，choice 多选一，score 按等级打分。

如何在空气墙上打一个口子——网络隧道技术

Tue, 25 Aug 2026 18:23:00 +0800

背景

我想基于 Managed Agents 做一个 MR review 的 agent，整体流程大致如下：

git push 触发 GitLab CI Runner 运行一个 job；
job 向内网的 code review service 发送一个 POST 请求；
code review service 收到请求后，调用 Managed Agents API 拉起一个公网沙箱，在沙箱中运行 code review agent；
code review agent 拉取代码，进行 review。

问题出在第 4 步：沙箱在公网环境，无法访问企业内网的 GitLab，代码拉不下来。

我又一次撞上了网络这堵空气墙。

Managed Agents API 提供的能力我都评估过，但没有一个能很好地解决这个问题：

方案	说明	为什么不行
Files API	把文件上传到对象存储，对象存储会直接挂载到沙箱上	每次都要把整个 repo 上传一遍，不优雅
Custom Tools	订阅 event stream 监听 custom tool call，调用内部服务后把结果回传给 agent	没办法把整个 repo 塞进上下文
MCP Tunnel	把内网 MCP Server 通过 Cloudflare Tunnel 连到 Anthropic 的 VPC，避免暴露到公网	GitLab 的 MCP 服务器没有一个方法能方便地 clone 整个 repo

MCP Tunnel 给了我一个思路：利用反向隧道，把内网的特定服务定向暴露给沙箱。

编码往事：从 ASCII 到 Tokenizer

Tue, 21 Apr 2026 10:38:06 +0800

“通信的根本问题是：在一点上精确或近似地复现在另一点上所选取的消息。”

— Claude Shannon, A Mathematical Theory of Communication (1948)

为什么需要编码？

你正在屏幕上阅读这篇文章。这些汉字、标点、空格——它们是怎么出现在屏幕上的？

这是一个细想就会觉得不可思议的事情：计算机根本不认识"字"。在计算机的世界里，没有横竖撇捺，没有 ABCD，只有两样东西——0 和 1。每一块内存、每一块硬盘、每一根网线里流淌的，都是密密麻麻的电信号：高电平是 1，低电平是 0。

但我们每天用计算机做的事情——写文档、发消息、刷网页——全都离不开文字和符号。那么问题来了：

怎么把人类的符号，塞进只有 0 和 1 的世界里？

答案就是：编码。

从符号到数字，从数字到二进制

编码做的事情，可以拆成两步：

给每个符号编一个号码：比如 A 是 65，B 是 66，“中” 是 20154。这一步建立了符号到数字的映射。
把数字转成二进制：65 变成 01000001，20154 变成 0100111000111010。这一步让数字能在计算机里存储和传输。

用一个表格来感受一下：

符号	编号（十进制）	编号（二进制）
A	65	01000001
Z	90	01011010
中	20154	0100111000111010
😂	128514	00000001 11110110 00000010

所以，当你打出一个"中"字的时候，真正在计算机里发生的事情是：键盘输入 → 查编码表找到编号 20154 → 转成二进制 0100111000111010 → 存进内存。读取的时候反过来：从内存读到二进制 → 转回编号 20154 → 查编码表 → 在屏幕上渲染出"中"字。

ADAS: Automated Design of Agentic Systems

Wed, 15 Apr 2026 00:00:00 +0000

自动化智能体系统设计（ADAS）是一个新兴研究领域，旨在自动发现和设计强大的智能体系统，包括发明新的构建块和/或以新的方式组合它们。本文提出的 Meta Agent Search 算法通过在代码空间中搜索，让元智能体迭代编程出更好的智能体。

来源: arXiv:2408.08435 — Hu, Lu, Clune (UBC/Vector Institute), ICLR 2025

核心思想

机器学习的历史表明，手工设计的解决方案最终会被学习到的解决方案取代（如 HOG → CNN，手工损失函数 → 学习损失函数）。ADAS 将这一规律延伸到智能体系统：手工设计的 prompt、工作流和工具组合应该被自动搜索发现的方案取代。

ADAS 三要素

组件	说明
搜索空间	定义哪些智能体系统可以被表示和发现（如仅 prompt、图结构、代码）
搜索算法	定义如何探索搜索空间（如 RL、迭代生成、进化）
评估函数	定义如何评估候选智能体（性能、成本、延迟、安全性）

代码空间搜索的关键优势

图灵完备：理论上可以发现任何可能的智能体系统
可解释性：代码比权重或图结构更易审计
利用现有生态：可直接搜索 LangChain 等框架中的组件
FM 擅长编码：搜索空间与 FM 能力高度对齐

Meta Agent Search 算法

用基线智能体（CoT、Self-Refine 等）初始化档案库
元智能体基于档案库生成新想法并实现代码
通过两次 self-reflection 确保新颖性
在验证集上评估，出错则 self-refine 修正（最多 5 次）
将新智能体加入档案库，循环继续

实验结果

任务	关键结果
ARC 逻辑谜题	渐进发现超越手写基线的智能体
DROP 阅读理解	F1 提升 13.6/100
MGSM 数学	准确率提升 14.4%
跨域迁移	从数学迁移到阅读理解仍超越基线
跨模型迁移	GPT-3.5 发现的智能体在 Claude Sonnet 上达到 48.3% ARC 准确率

重要发现

发现的智能体具有强迁移性：在跨域、跨模型时仍保持优越性能
搜索过程中出现了垫脚石效应：早期的突破不一定立即提高性能，但为后续发现提供了基础
超越了仅优化 prompt 的方法（如 OPRO），证明学习所有组件的重要性

Timeline

2024-08: 论文发表 arXiv:2408.08435
2025: 在 ICLR 2025 正式发表
2026-04-13: 整理进 KB

Claude Managed Agents

Wed, 15 Apr 2026 00:00:00 +0000

Anthropic 官方推出的托管 Agent 平台（Beta），提供完整的 Agent 运行基础设施：云端容器、工具执行、会话状态管理和 Agent 编排，让开发者只需定义 Agent 行为，无需自己搭建 Agent loop 和 sandbox。

Compiled Truth

核心定位

Claude Managed Agents 是 Agent-as-a-Service。与 Messages API（直接调用模型、自己管理 loop）相比，它把整个 Agent 运行时托管出去：

	Messages API	Claude Managed Agents
适合	自定义 Agent loop、精细控制	长任务、异步工作
你负责	一切	只定义 Agent 配置
基础设施	自建	Anthropic 托管

这与 pi（本地 harness）、Hermes 等框架的思路一脉相承，区别在于这是云端托管版本，不需要在本地运行任何 harness 代码。

四个核心概念

概念	是什么
Agent	可复用的配置：模型 + 系统提示 + 工具 + MCP + Skills。创建一次，通过 ID 跨会话引用。支持版本管理。
Environment	云端容器模板：预装软件包、网络访问控制。多个 Session 可共享同一 Environment。
Session	一次具体的运行实例：Agent + Environment + 任务。有独立的容器和对话历史。
Events	双向事件流（SSE）：你发送 user events，收到 agent/session events。历史持久化在服务器端。

工作流

定义 Agent (一次) → 创建 Environment (一次) → 启动 Session
    → POST /sessions/:id/events  (发指令)
    → GET  /sessions/:id/stream  (收 SSE)
    → 中途可 interrupt / 追加消息
    → session.status_idle = 任务完成

内置工具（agent_toolset_20260401）

工具	能力
`bash`	在容器内执行 shell 命令
`read` / `write` / `edit`	文件读写编辑
`glob` / `grep`	文件搜索
`web_fetch`	抓取 URL 内容
`web_search`	网络搜索

可以通过 configs 数组精细控制每个工具的开关和权限策略（always_allow / always_ask）。

GLab — GitLab CLI

Wed, 15 Apr 2026 00:00:00 +0000

GLab (glab) is the official open-source command-line tool for GitLab, bringing GitLab workflows (issues, merge requests, CI/CD pipelines, releases, and more) directly to the terminal. It supports GitLab.com, GitLab Self-Managed, and GitLab Dedicated, with multi-instance authentication and automatic remote detection.

Key Capabilities

Merge Requests & Issues: Create, list, review, and manage MRs and issues from the CLI. Examples: glab mr list --assignee=@me, glab issue create -t "Title" --label bug
CI/CD: View, trace, and retry pipelines and jobs. glab ci view, glab ci trace
Releases & Changelogs: Create releases and interact with the changelog API
GitLab Duo: Ask AI questions about git via glab duo ask
MCP Server: Experimental Model Context Protocol support via glab mcp
Stacked Diffs: Create and manage stacked diffs with glab stack
Repo Management: Clone repos, manage deploy keys, SSH keys, GPG keys, variables, tokens

Installation

brew install glab    # macOS / Linux / WSL
brew upgrade glab    # update

Binaries also available on the releases page. Requires GitLab 16.0+.

Hermes Context Files

Wed, 15 Apr 2026 00:00:00 +0000

Hermes Agent 自动发现和加载上下文文件来塑造其行为。核心文件包括 AGENTS.md（项目指令）、SOUL.md（全局人格）和 .cursorrules（Cursor IDE 兼容），通过优先级系统和渐进式子目录发现来管理。

支持的上下文文件

文件	用途	发现方式
`.hermes.md` / `HERMES.md`	项目指令（最高优先级）	向上遍历到 git root
`AGENTS.md`	项目指令、约定、架构	CWD + 渐进式子目录发现
`CLAUDE.md`	Claude Code 上下文文件	CWD + 渐进式子目录发现
`SOUL.md`	全局人格和语气	仅从 `HERMES_HOME`
`.cursorrules`	Cursor IDE 编码约定	仅 CWD

优先级

同一会话中只加载一种项目上下文（首次匹配优先）：.hermes.md → AGENTS.md → CLAUDE.md → .cursorrules。SOUL.md 独立加载，始终作为 agent 身份。

AGENTS.md

渐进式子目录发现

启动时加载 CWD 的 AGENTS.md。Agent 在会话中浏览到子目录时，渐进式发现该目录的上下文文件并注入对话：

my-project/
├── AGENTS.md              ← 启动时加载
├── frontend/
│   └── AGENTS.md          ← Agent 读取 frontend/ 文件时发现
├── backend/
│   └── AGENTS.md          ← Agent 读取 backend/ 文件时发现

优势：

Hermes Context References

Wed, 15 Apr 2026 00:00:00 +0000

Hermes Agent 的上下文引用功能允许用户在消息中使用 @ 语法直接注入文件内容、目录结构、Git 差异和网页内容，作为 --- Attached Context --- 附加到消息中。

支持的引用语法

语法	说明
`@file:path/to/file.py`	注入文件内容
`@file:path/to/file.py:10-25`	注入指定行范围（1-indexed，闭区间）
`@folder:path/to/dir`	注入目录树列表和文件元数据
`@diff`	注入 `git diff`（未暂存的工作区变更）
`@staged`	注入 `git diff --staged`（已暂存的变更）
`@git:5`	注入最近 N 条提交及其 patch（最多 10）
`@url:https://example.com`	抓取并注入网页内容

容量限制

阈值	值	行为
软限制	上下文长度的 25%	追加警告，继续展开
硬限制	上下文长度的 50%	拒绝展开
文件夹条目	最多 200 文件	超出部分替换为 `- ...`
Git 提交	最多 10 条	超出自动截断

安全机制

敏感路径阻止

以下路径始终被阻止，防止凭证暴露：

SSH 密钥和配置（~/.ssh/id_rsa 等）
Shell 配置文件（~/.bashrc, ~/.zshrc 等）
凭证文件（~/.netrc, ~/.pgpass 等）
Hermes 环境文件（$HERMES_HOME/.env）

以下目录完全阻止：~/.ssh/, ~/.aws/, ~/.gnupg/, ~/.kube/, $HERMES_HOME/skills/.hub/

Hermes Persistent Memory

Wed, 15 Apr 2026 00:00:00 +0000

Hermes Agent 的持久化记忆系统由 MEMORY.md 和 USER.md 两个文件组成，容量有界且由 agent 自行管理。记忆在会话开始时注入系统提示，跨会话持久保存。

记忆架构

文件	用途	字符限制
MEMORY.md	Agent 个人笔记——环境事实、约定、经验教训	2,200 字符 (~800 tokens)
USER.md	用户画像——偏好、沟通风格、期望	1,375 字符 (~500 tokens)

存储位置：~/.hermes/memories/

工作机制

冻结快照模式：记忆在会话开始时作为冻结块注入系统提示，会话内不变
即时持久化：Agent 在会话中修改记忆时立即写入磁盘，但下次会话才在系统提示中生效
容量管理：超过 80% 容量时，Agent 应合并/精简条目后再添加新条目

记忆工具操作

add — 添加新条目
replace — 替换现有条目（通过子串匹配）
remove — 移除不再相关的条目

无 read 操作——记忆内容自动注入系统提示。

应该记住 vs 应该跳过

✅ 主动保存

用户偏好（“偏好 TypeScript”）
环境事实（“服务器运行 Debian 12”）
纠正（“不要用 sudo 运行 Docker”）
项目约定（“项目用 tabs, 120 字符行宽”）
已完成的工作记录
显式请求（“记住我的 API key 每月轮换”）

❌ 不保存

显而易见的信息
可轻松重查的事实
大段数据/代码/日志
会话级临时信息
已在上下文文件中的内容

会话搜索

除持久化记忆外，Hermes 还提供 session_search 工具：

Hermes Personality & SOUL.md

Wed, 15 Apr 2026 00:00:00 +0000

Hermes Agent 的人格系统由 SOUL.md 定义，它占据系统提示的第一个位置（slot #1），是 agent 的核心身份。SOUL.md 是跨项目、跨会话的持久人格，而 /personality 命令提供会话级的临时人格覆盖。

SOUL.md 的核心地位

位置：~/.hermes/SOUL.md（或 $HERMES_HOME/SOUL.md）
加载时机：会话开始时作为 slot #1 注入系统提示
作用范围：全局，不属于任何项目
优先级：最高，是 agent 的基础身份

设计理念

SOUL.md 仅从 HERMES_HOME 加载（不从工作目录加载），确保人格可预测——不会因为你切换项目而意外改变。

SOUL.md vs AGENTS.md

	SOUL.md	AGENTS.md
内容	身份、语气、风格、沟通方式	项目架构、编码约定、工具偏好
作用域	跨项目，跟随 agent 实例	项目级，跟随工作目录
持久性	稳定不变	随项目演进

简单规则：如果应该到处跟随你 → SOUL.md；如果属于某个项目 → AGENTS.md。

SOUL.md 内容建议

✅ 应该包含

语气和沟通风格
直接程度
默认交互方式
需要避免的风格特征
处理不确定性、分歧、歧义的方式

❌ 不应包含

一次性项目指令
文件路径
仓库约定
临时工作流细节

示例 SOUL.md

# Personality
You are a pragmatic senior engineer with strong taste.
You optimize for truth, clarity, and usefulness over politeness theater.

## Style
- Be direct without being cold
- Prefer substance over filler
- Push back when something is a bad idea
- Admit uncertainty plainly

内置人格

Hermes 提供 14 种内置人格可供切换：helpful、concise、technical、creative、teacher、kawaii、catgirl、pirate、shakespeare、surfer、noir、uwu、philosopher、hype。

Hermes Skills System

Wed, 15 Apr 2026 00:00:00 +0000

Hermes Agent 的技能系统是一套按需加载的知识文档系统，采用渐进式披露（progressive disclosure）模式以最小化 token 消耗。技能存放在 ~/.hermes/skills/，兼容 agentskills.io 开放标准。

渐进式披露

层级	调用	返回内容	Token 消耗
Level 0	`skills_list()`	名称、描述、分类	~3K
Level 1	`skill_view(name)`	完整内容 + 元数据	可变
Level 2	`skill_view(name, path)`	特定引用文件	可变

Agent 仅在实际需要时才加载完整技能内容。

SKILL.md 格式

每个技能由一个 SKILL.md 文件定义，包含 YAML front matter 和 Markdown 正文：

name / description / version：基本元数据
platforms：可选，限制在特定 OS 上加载
conditional activation：可选，根据可用工具自动显示/隐藏
required_environment_variables：可选，声明所需环境变量
config：可选，声明配置项（存储在 config.yaml）

条件激活

技能可以根据当前会话中可用的工具自动显示或隐藏：

fallback_for_toolsets：当指定工具集不可用时才显示（作为后备）
requires_toolsets：当指定工具集可用时才显示
例如：内置的 duckduckgo-search 技能在有 Firecrawl API key 时自动隐藏

Agent 自管理技能

Agent 可以通过 skill_manage 工具创建、更新和删除自己的技能，作为程序性记忆：

Meta-Harness: End-to-End Optimization of Model Harnesses

Wed, 15 Apr 2026 00:00:00 +0000

Meta-Harness 是一个外循环系统，通过让 coding agent 自由访问文件系统中的完整历史（源代码、分数、执行轨迹），自动搜索和优化 LLM 应用的 harness 代码。相比仅使用压缩反馈的文本优化器，Meta-Harness 能实现更深层的因果推理和更高效的搜索。

来源: arXiv:2603.28052 — Lee, Nair, Zhang, Lee, Khattab, Finn (Stanford/MIT/KRAFTON), 2026

核心问题

LLM 系统的性能不仅取决于模型权重，还取决于其 harness——决定存储、检索和呈现什么信息给模型的代码。然而现有文本优化器（OPRO、TextGrad、AlphaEvolve、GEPA 等）对反馈压缩过于激进。Meta-Harness 的核心洞察是：更丰富的历史访问可以支持更好的 harness 工程。

关键设计：文件系统作为反馈通道

每个被评估的 harness 贡献一个目录，包含：

源代码
评估分数
执行轨迹（prompts、工具调用、模型输出、状态更新）

Proposer 通过 grep、cat 等终端工具选择性检查历史，而非将所有信息打包进单个 prompt。

与其他方法的对比

方法	历史访问	反馈内容	每迭代 MTok
OPRO	窗口	(解, 分数) 对	0.002
TextGrad	最后一个	当前工件的文本反馈	0.015
AlphaEvolve	窗口	程序数据库 + 分数	0.022
GEPA	摘要	反思反馈	0.008
Meta-Harness	完整	所有日志和分数	10.0

实验结果

在线文本分类

准确率比 ACE 提升 7.7 点，同时使用 4× 更少 的上下文 token
仅需 4 次评估即达到 OpenEvolve/TTT-Discover 的最终性能

检索增强数学推理

在 200 道 IMO 级别题目上，单个发现的 harness 在 5 个 held-out 模型上平均提升 4.7 点

Agentic Coding (TerminalBench-2)

Opus 4.6 上达到 76.4%，超越手写的 Terminus-KIRA (74.7%)
Haiku 4.5 上达到 37.6%，排名 #1

消融实验

条件	中位准确率	最佳准确率
仅分数	34.6	41.3
分数 + 摘要	34.9	38.7
Meta-Harness (完整)	50.0	56.7

关键发现：对原始执行轨迹的访问是最重要的因素，摘要无法恢复丢失的诊断信号。

OpenAI Codex Harness Engineering: Agent-First 软件开发实验

Wed, 15 Apr 2026 00:00:00 +0000

OpenAI 团队在 5 个月内用 0 行手写代码构建了一个百万行级别的内部产品，3 名工程师驱动 Codex 完成约 1,500 个 PR（3.5 PR/人/天）。这个实验揭示了当 agent 成为主要的代码生产者时，工程工作的本质如何从"写代码"转变为"设计环境、制定意图和构建反馈循环"。

来源: OpenAI Engineering Blog — Ryan Lopopolo, 2026-02-11

Compiled Truth (可重写)

核心数据

指标	数值
代码行数	~1,000,000
手写代码行数	0
PR 数量	~1,500
初始工程师数	3（后增至 7）
吞吐量	3.5 PR/人/天（且随团队扩大而增加）
开发时间	约 1/10 手写时间
单次 Codex 运行时长	最长 6+ 小时

关键设计决策

1. AGENTS.md 作为目录，而非百科全书

“一个巨大的 AGENTS.md” 方案失败了，原因：

上下文是稀缺资源：巨大的指令文件挤占了任务、代码和文档的空间
太多指导等于无指导：当一切都是"重要"的，agent 开始局部模式匹配
立即腐烂：单体手册变成过时规则的墓地
难以验证：单个 blob 不支持机械检查

替代方案：短 AGENTS.md（~100 行）作为目录，结构化 docs/ 目录作为知识库。

智能体上下文工程：设计模式与实践

Wed, 15 Apr 2026 00:00:00 +0000

上下文工程（Context Engineering）是决定 LLM 系统中存储、检索和呈现什么信息给模型的实践。从学术研究（Meta-Harness）到工业实践（Hermes Agent），涌现出一套共通的设计模式。

什么是上下文工程

LLM 系统的性能往往取决于模型周围的 harness——决定上下文的代码——而非仅取决于模型权重本身。Meta-Harness 论文显示，仅改变 harness 就能在同一基准测试上产生 6× 性能差距。

设计模式谱系

1. 静态上下文（最基础）

直接将指令、示例注入 prompt。如 Hermes 的 AGENTS.md 和 SOUL.md。

2. 渐进式披露（按需加载）

只在需要时加载上下文，避免 prompt 膨胀。

Hermes Skills：Level 0（列表）→ Level 1（完整内容）→ Level 2（引用文件）
Hermes 子目录发现：启动时加载根 AGENTS.md，进入子目录时才加载子目录上下文
Meta-Harness：Proposer 通过 grep/cat 选择性检查文件系统

核心原则：上下文应按需自适应访问，而非一次性打包进 prompt。

3. 持久化记忆（跨会话）

将有界、精选的记忆跨会话保存。

系统	记忆机制	容量	管理
Hermes MEMORY.md	Agent 个人笔记	2,200 字符	Agent 自行增删改
Hermes USER.md	用户画像	1,375 字符	Agent 自行管理
Hermes Session Search	全文搜索历史会话	无限	自动存储
Meta-Harness 文件系统	完整代码+轨迹+分数	无限	每迭代写入

关键权衡：容量 vs 质量——记忆应该精炼，而非堆砌。

自动化智能体优化的演进

Wed, 15 Apr 2026 00:00:00 +0000

从 ADAS 到 Meta-Harness，自动化智能体系统优化经历了从"搜索 agent 设计"到"搜索 harness 代码"的演进。两者共享代码空间搜索的核心思想，但在反馈粒度和搜索机制上有显著差异。

发展脉络

第一代：ADAS / Meta Agent Search (2024)

ADAS 提出了一个开创性的研究方向：自动设计智能体系统。Meta Agent Search 是其代表性算法：

搜索对象：整个 agent 的 forward 函数（Python 代码）
搜索空间：图灵完备的代码空间
反馈机制：档案库（archive）存储先前发现的代码和分数
Proposer：FM（GPT-4）作为元智能体
搜索模式：迭代生成，强调新颖性和有趣性

局限性：

档案库信息相对压缩（主要是代码和分数）
元智能体无法查看详细执行轨迹
依赖 LLM 直接生成，而非 coding agent

第二代：Meta-Harness (2026)

Meta-Harness 专注优化 LLM 系统中的 harness（外围代码），在 ADAS 的基础上做了关键改进：

搜索对象：harness 代码（提示构建、检索、状态更新策略）
反馈机制：完整文件系统访问——源代码、分数、执行轨迹
Proposer：Coding agent（Claude Code）而非原始 LLM
搜索模式：自由探索文件系统，无固定父代选择规则

关键差异对比

维度	ADAS / Meta Agent Search	Meta-Harness
搜索目标	完整 agent 设计	Harness（LLM 外围代码）
反馈粒度	代码 + 分数	代码 + 分数 + 执行轨迹
每迭代上下文	数千 tokens	高达 10M tokens
Proposer	LLM 直接生成	Coding agent（有工具）
信息访问	档案库（结构化）	文件系统（自由探索）
因果推理	有限	深层因果推理（识别混淆因素）
搜索效率	需 30 次迭代	4 次评估匹配基线

核心洞察的演变

代码空间搜索是可行的（ADAS 证明）→ 代码空间搜索可以更高效（Meta-Harness 证明）
压缩反馈会丢失关键信号：ADAS 的档案库受限于 LLM 上下文窗口，Meta-Harness 通过文件系统突破了这一限制
Coding agent > 原始 LLM：Claude Code 可以用 grep、cat 等工具主动探索历史，而非被动接收固定 prompt
执行轨迹是关键：消融实验表明，摘要无法替代原始轨迹的诊断价值

对未来的启示

自适应访问外部上下文是趋势（RAG → 渐进式记忆 → 文件系统访问）
随着编码 agent 能力提升，最小化搜索结构可能是更好的策略
从"搜索 agent 设计"到"搜索上下文管理策略"，优化粒度在细化
未来方向：co-evolve harness 和模型权重

Timeline

2024-08: ADAS 论文发表，奠定代码空间搜索的基础
2026-03: Meta-Harness 论文发表，展示完整历史访问的威力
2026-04-13: 整理进 KB，梳理演进脉络

中国过去10年通胀率（2015-2024）

Tue, 14 Apr 2026 00:00:00 +0000

回答

官方 CPI 年均通胀率（复合）：约 1.58%，10年累计通胀约 17%。

按实际货币贬值感受估算，可能更接近 3%-5%。

年度数据

年份	CPI 通胀率
2015	1.44%
2016	2.00%
2017	1.59%
2018	2.07%
2019	2.90%
2020	2.42%
2021	0.98%
2022	1.97%
2023	0.23%
2024	0.22%

算术平均：1.58%
几何平均（复合年均通胀率）：1.58%
10年累计通胀：16.95%
即：10年前的 100 元，现在需要约 117 元才有同等购买力

两种口径

口径一：官方 CPI → 约 1.6%/年

数据来源：中国国家统计局，经快易理财网（kylc.com）整理。

口径二：实际感受 → 约 3%-5%/年

官方 CPI 存在低估，原因：

CPI 不包含房价 — 房价是过去10年涨幅最大的品类之一
CPI 权重偏向食品等必需品 — 对教育、医疗等涨幅更大的服务类覆盖不足
更合理的估算方法：M2（广义货币）增速 - GDP增速，过去10年约 3%-5%

投资启示

来自指数基金投资指南的相关洞察：

联接基金 vs QDII 基金概念辨析

Tue, 14 Apr 2026 00:00:00 +0000

回答

联接基金和 QDII 是两个完全不同的概念。

联接基金（ETF 联接基金）

本质：场外买场内 ETF 的桥梁。

ETF 基金在股票交易所里买卖，需要开股票账户，操作麻烦，没有自动定投功能。基金公司为此开发了联接基金，让普通投资者在场外（支付宝、天天基金等）就能间接买入对应的 ETF。

你 → 买联接基金（场外）→ 联接基金 → 买对应的ETF（场内）→ ETF持有一篮子股票

费率跟对应的 ETF 一样，不会双重收费
本质是给懒得开股票账户的人一个方便的入口

QDII 基金

本质：用人民币买境外资产的"代购"。

QDII = 合格境内机构投资者（Qualified Domestic Institutional Investor）

拿人民币合法投资港股、美股、德股等境外市场
可在一定程度上分散人民币汇率风险
买 QDII 基金不占用个人每年5万美元的外汇额度
风险：基金公司外汇额度用完时可能暂停申购

对比

	联接基金	QDII 基金
本质	场外买场内ETF的桥梁	用人民币买境外资产的"代购"
投资对象	对应的ETF基金	港股、美股等境外市场
解决什么问题	不用开股票账户就能买ETF	不用换外汇就能投资海外
在哪里买	支付宝、天天基金等场外平台	场内场外都有
费率	与对应ETF相同	略高于普通基金
额外风险	无	外汇额度不足暂停申购、汇率波动

基金代码常见标识

后缀	含义
ETF	交易型开放式指数基金（场内）
LOF	上市型开放式基金（场内场外都能交易）
QDII	投资境外市场的基金
A / C	A类前端收费 / C类按日计提销售费
联接	ETF联接基金

两者可以同时存在，例如"恒生ETF联接QDII"就是既帮你在场外买ETF，又投资的是港股。

karpathy: LLM Kb

Mon, 13 Apr 2026 10:06:13 +0800

@karpathy

最近我发现一个特别有用的方法：利用 LLMs 为各种研究兴趣主题构建个人知识库。这样一来，我近期的 token 消耗中，很大一部分不再用于处理代码，而是更多地用于处理知识（以 markdown 和图片形式存储）。最新的 LLMs 在这方面表现得相当出色。所以：

数据导入：我将源文档（文章、论文、代码库、数据集、图片等）索引到 raw/ 目录中，然后使用 LLM 逐步“编译”一个wiki，这其实就是目录结构中的一系列 .md 文件集合。该wiki包含 raw/ 中所有数据的摘要、反向链接，并将数据分类为概念，为它们撰写文章并建立链接。为了将网页文章转换为 .md 文件，我喜欢使用 Obsidian Web Clipper 扩展，同时还会用快捷键将所有相关图片下载到本地，以便我的 LLM 能轻松引用它们。

集成开发环境：我将 Obsidian 用作 IDE 的“前端”，在这里可以查看原始数据、编译后的wiki以及衍生的可视化图表。重要的是，LLM 负责编写和维护wiki的所有数据，我很少直接操作。我还尝试过一些 Obsidian 插件，以其他方式渲染和查看数据（例如用 Marp 制作幻灯片）。

问答：有趣的是，一旦你的知识库足够庞大（比如我最近研究的某个主题已有约 100 篇文章、40 万字左右），你就可以向你的 LLM 智能体提出各种复杂问题，让它基于知识库进行研究并给出答案。我原以为需要借助复杂的 RAG 技术，但 LLM 在自动维护索引文件和所有文档的简要摘要方面表现相当出色，在这个“小规模”场景下，它能相当轻松地读取所有重要的相关数据。

输出：相较于在文本或终端中获取答案，我更倾向于让它为我生成 Markdown 文件、幻灯片（Marp 格式）或 matplotlib 图像，这些我随后都会在 Obsidian 中再次查看。根据查询内容，你还可以设想出许多其他视觉输出格式。通常，我会将这些输出“归档”回知识库中，以增强其内容，便于后续查询。因此，我个人的探索与查询总是在知识库中不断“累积”。

代码检查：我对wiki进行了一些 LLM“健康检查”，例如查找不一致的数据、填补缺失数据（借助网络搜索）、为新的文章候选寻找有趣的关联等，以逐步清理wiki并提升其整体数据完整性。LLM 在提出进一步需要探讨和调查的问题方面表现得相当出色。

额外工具：我发现自己正在开发额外的工具来处理数据，比如我凭感觉编写了一个简单的小型wiki搜索引擎，我既会直接使用它（通过网页界面），但更多时候，我更倾向于通过命令行将其交给 LLM，作为处理更复杂查询的工具。

进一步探索：随着代码库的扩展，很自然地会考虑结合合成数据生成与微调，让 LLM 将数据“内化”到权重中，而非仅依赖上下文窗口。

当前 KB vs GBrain：个人知识管理系统对比

Mon, 13 Apr 2026 00:00:00 +0000

核心差异

维度	本 KB（pi + markdown）	GBrain（Postgres + Agent）
规模	~20 个文件	10,000+ 页面
搜索	grep / find（全文扫描）	向量 + 关键词 RRF 融合
知识模型	compiled truth + timeline（刚引入）	compiled truth + timeline（原生）
结构	3 子目录分类（agents/research/concepts）	MECE 实体目录（people/companies/deals）
链接	typed relations（frontmatter）	有向类型化图谱 + 图遍历
采集	手动 URL → firecrawl 抓取	7 种自动化集成（邮件/日历/推特/语音）
Agent 循环	规则定义了，但靠 Agent 自觉遵守	深度集成（skillpack 定义了每一步行为）

已采纳的改进

从 GBrain 学来并已落地的 5 个设计：

Compiled Truth + Timeline — wiki 文件分双层，知识不再覆盖丢失
类型化链接 — frontmatter 里的 related + relation 字段
MECE 目录结构 — wiki/agents、wiki/research、wiki/concepts
元数据规范化 — 所有 raw 文件有完整 frontmatter
知识复利循环规则 — AGENTS.md 里定义了 Read-Before-Respond 和 Auto-Propose

暂不采纳的

特性	原因
Postgres + pgvector	当前 ~20 个文件，grep 完全够用。等 500+ 文件时再考虑
自动化集成（邮件/推特/日历）	本 KB 聚焦 AI agent 研究，不需要实时数据流
Dream Cycle（夜间维护）	维护量还不需要自动化，手动 review 就够
MCP server 暴露工具	当前不需要多设备/多 Agent 访问

未来演进路径

当 KB 增长到以下规模时的触发点：

Openai Harness Engineering

Fri, 10 Apr 2026 14:35:50 +0800

过去五个月，我们团队一直在进行一项实验：构建并发布一款软件产品的内部测试版，全程未编写一行手动代码

该产品拥有内部日常用户和外部测试人员。它经历发布、部署、故障与修复的全过程。独特之处在于，每一行代码——包括应用逻辑、测试用例、持续集成配置、技术文档、可观测性系统及内部工具——均由 Codex 生成。我们估算，这种开发方式所需时间仅为手工编写代码的十分之一。

人类掌舵，智能体执行。

我们刻意选择这一约束条件，旨在构建能实现工程效率数量级提升的必要体系。在数周时间内，我们完成了百万行代码的交付。为此，我们必须重新思考：当软件工程团队的核心职责从编写代码转变为设计环境、明确意图、构建反馈闭环，以保障 Codex 智能体可靠工作时，工程范式将发生何种根本性变革。

本文将通过我们与智能体团队共同打造全新产品的实践，揭示系统崩溃的诱因、效能叠加的规律，并探讨如何最大化利用人类最宝贵的稀缺资源——时间与专注力。

从一个空的 git 仓库开始

首次提交到这个空仓库是在 2025 年 8 月下旬完成的。

初始的脚手架——包括仓库结构、CI 配置、格式化规则、包管理器设置和应用框架——都是由 Codex CLI 使用 GPT‑5 生成的，并参考了一小部分现有模板。甚至指导智能体如何在仓库中工作的初始 AGENTS.md 文件本身也是由 Codex 编写的。

系统中不存在预先编写的人类代码作为基础。从一开始，这个仓库就是由智能体塑造的。

五个月后，该代码库已包含约百万行代码，涵盖应用逻辑、基础设施、工具链、文档及内部开发者工具。在此期间，仅由三名工程师组成的小团队驱动 Codex 完成了约 1500 个拉取请求的创建与合并。这意味着每位工程师平均每日处理 3.5 个拉取请求，而随着团队扩展至七名工程师，这一处理效率仍在持续提升。尤为关键的是，这种产出并非盲目追求数量：该产品已被数百名内部用户使用，其中包括每日高频使用的内部核心用户。

在整个开发过程中，人类从未直接贡献任何代码。这已成为团队的核心准则：不编写人工代码。

重新定义工程师的角色

人类不再亲自动手编码，催生了另一种工程实践——聚焦于系统架构、开发框架与效能杠杆。

早期的进展比我们预期的要慢，不是因为 Codex 能力不足，而是因为环境定义不够明确。智能体缺乏实现高层次目标所需的工具、抽象概念和内部结构。我们工程团队的主要任务变成了让智能体能够完成有用的工作。

在实践中，这意味着采用深度优先的工作方式：将更大的目标分解为更小的构建模块（设计、编码、审查、测试等），引导智能体构建这些模块，并利用它们来解锁更复杂的任务。当某个环节失败时，解决方法几乎从来不是“再努力一点”。因为取得进展的唯一途径是让 Codex 来完成工作，所以人类工程师总是会介入任务并提出问题：“缺少什么能力？我们如何让智能体既能理解又能执行这种能力？”

人类几乎完全通过提示与系统交互：工程师描述任务，运行代理，并允许其开启拉取请求。为了推动拉取请求完成，我们指示 Codex 在本地审查其自身的更改，在本地和云端请求额外的特定代理审查，回应任何人类或代理给出的反馈，并在循环中迭代，直到所有代理审查者都满意为止（这本质上是一个拉尔夫·维格姆循环⁠）。Codex 直接使用我们的标准开发工具（gh、本地脚本和仓库嵌入技能）来收集上下文，无需人类在命令行界面中复制粘贴。

人类可能会审查拉取请求，但并非必须如此。随着时间的推移，我们已将几乎所有的审查工作推向了由代理之间自行处理。

提升应用程序可读性

随着代码吞吐量的增加，我们的瓶颈变成了人工质量保证能力。由于固定的限制一直是人类的时间和注意力，我们努力通过使应用程序用户界面、日志和应用指标本身对 Codex 直接可读，来为代理增加更多功能。

例如，我们将应用程序设计为可按 git 工作树启动，这样 Codex 就能为每个变更启动并驱动一个实例。我们还将 Chrome DevTools 协议接入代理运行时，并创建了处理 DOM 快照、屏幕截图和导航的技能。这使得 Codex 能够直接复现错误、验证修复方案，并推理用户界面行为。

Langchain Continual Learning for Ai Agents

Fri, 10 Apr 2026 11:55:39 +0800

关于人工智能持续学习的大多数讨论都聚焦于一件事：更新模型权重。但对于 AI 智能体而言，学习可以发生在三个不同的层面：模型层、控制层和上下文层。理解这些差异将彻底改变你构建持续进化系统的思维方式。

智能体系统的三个主要层面包括：

模型层：即模型权重本身。
控制层：指驱动所有智能体实例的模型外围框架。这包括驱动智能体的核心代码，以及始终作为框架组成部分的指令或工具集。
上下文：存在于框架之外、可用于配置框架的额外上下文（指令、技能）。

示例 #1：将其映射到像 Claude Code 这样的编码代理：

模型：claude-sonnet 等
Harness: Claude Code
上下文：CLAUDE.md、/skills、mcp.json

示例 #2：将其映射到 OpenClaw：

模型：多种
Harness：Pi + 其他辅助工具
上下文：SOUL.md，来自 clawhub 的技能

当我们谈论持续学习时，大多数人会立刻想到模型。但实际上，一个 AI 系统可以在以下三个层面进行学习。

模型层的持续学习

当大多数人谈论持续学习时，他们最常指的就是这个：更新模型权重。

更新技术包括监督微调（SFT）、强化学习（例如 GRPO）等。

这里的核心挑战是灾难性遗忘——当模型基于新数据或任务进行更新时，它往往会在之前掌握的内容上表现下降。这是一个开放的研究问题。

当人们为特定的智能体系统训练模型时（例如，你可以将 OpenAI 的 Codex 模型视为为其 Codex 智能体而训练），他们大多是为整个智能体系统进行训练。理论上，你可以在更细粒度的层面上进行（例如，为每个用户使用一个 LoRA），但在实践中，这主要在智能体层面进行。

在控制层进行持续学习

如前所述，harness 指的是驱动智能体的代码，以及始终作为 harness 组成部分的任何指令或工具。

随着harness这个概念日益普及，多篇论文开始探讨如何优化harness设计。

最近的一个是Meta-Harness：模型harness的端到端优化。

核心思想是让智能体在循环中运行。首先让它执行一系列任务，然后进行评估。接着将所有日志存储到文件系统中。最后运行一个编码智能体来查看这些执行轨迹，并提出对框架代码的修改建议。

与模型的持续学习类似，这通常在智能体层面进行。理论上，你可以在更细粒度的层面实现这一点（例如，为每个用户学习不同的代码框架）。

上下文层的持续学习

“上下文”位于系统框架之外，可用于配置框架。上下文包含指令、技能甚至工具等元素。这通常也被称为记忆。

这种上下文类型同样存在于框架内部（例如，框架可能包含基础系统提示、技能等）。区别在于它是框架的一部分还是配置的一部分。

学习上下文可以在多个不同层面进行。

学习上下文可以在智能体层面进行——智能体拥有持久的“记忆”，并随时间更新自身配置。一个很好的例子是 OpenClaw，它拥有随时间更新的 SOUL.md 文件。

学习上下文通常在租户层面（用户、组织、团队等）进行。在这种情况下，每个租户都有自己随时间更新的上下文。例如，Hex 的 Context Studio、Decagon 的 Duet、Sierra 的 Explorer。

Anthropic: Project Glasswing

Wed, 08 Apr 2026 14:01:11 +0800

引言

今天我们宣布启动"玻璃翼项目（Project Glasswing）" ，这是一项汇集了亚马逊网络服务、Anthropic、苹果、博通、思科、CrowdStrike、谷歌、摩根大通、Linux 基金会、微软、英伟达和帕洛阿尔托网络等机构的联合倡议，旨在保障全球最关键软件的安全。

我们组建"玻璃翼项目"的动因，源于我们在 Anthropic 训练的一款前沿模型中所观察到的能力——我们相信这种能力将重塑网络安全格局。Claude Mythos预览版作为一款通用型、尚未发布的前沿模型，揭示了一个严峻事实：人工智能模型已达到的编码能力水平，使其在发现和利用软件漏洞方面能够超越除最顶尖专家外的所有人类。

Mythos Preview 已发现数千个高危漏洞，涵盖所有主流操作系统和网络浏览器。鉴于人工智能的发展速度，此类能力很快将广泛扩散，甚至可能被非安全部署方所掌握。这对经济、公共安全和国家安全的潜在冲击可能极为严重。Project Glasswing 正是为了将这些能力紧急应用于防御目的而启动的举措。

作为 Project Glasswing 计划的一部分，上述合作方将在防御性安全工作中运用 Mythos Preview；Anthropic 将分享研究成果，使整个行业受益。我们还向 40 余家关键软件基础设施的构建或维护机构开放了访问权限，使其能够运用该模型扫描并加固自有系统及开源系统。Anthropic 将为这些工作提供价值 1 亿美元的 Mythos Preview 使用额度，并向开源安全组织直接捐赠 400 万美元。

“玻璃翼项目"只是一个起点。没有任何单一组织能够独自解决这些网络安全问题：前沿 AI 开发者、其他软件公司、安全研究人员、开源维护者以及全球各国政府都扮演着不可或缺的角色。守护全球网络基础设施的工作可能需要数年时间；而前沿 AI 能力很可能在未来几个月内就取得重大进展。为了让网络防御者抢占先机，我们必须立即行动。

人工智能时代的网络安全

我们日常依赖的各类软件——无论是运行银行系统、存储医疗记录、连接物流网络、维持电网运转，还是其他众多关键功能——始终存在着程序漏洞。其中许多问题微不足道，但有些却是严重的安全缺陷，一旦被网络攻击者发现，就可能被用来劫持系统、中断运营或窃取数据。

我们已经目睹了网络攻击对全球重要企业网络、医疗系统、能源基础设施、交通枢纽以及政府机构信息安全造成的严重后果。在国际舞台上，来自中国、伊朗、朝鲜和俄罗斯等国家支持的行为者发起的攻击，威胁着支撑民用生活和军事准备的基础设施。即使是规模较小的攻击，例如针对个别医院或学校的攻击，仍可能造成巨大的经济损失，暴露敏感数据，甚至危及生命。目前全球网络犯罪的财务成本难以估算，但可能每年高达 5000 亿美元。

软件中的许多漏洞多年来未被察觉，因为发现和利用它们需要只有少数熟练安全专家掌握的专业知识。随着最新前沿 AI 模型的出现，发现和利用软件漏洞所需的成本、精力和专业知识水平都大幅下降。在过去一年中，AI 模型在阅读和理解代码方面变得越来越有效——特别是，它们在发现漏洞和找出利用方法方面表现出惊人的能力。Claude Mythos Preview 展示了这些网络安全技能的飞跃——它发现的漏洞在某些情况下已经经受了几十年的人工审查和数百万次自动化安全测试，而它开发的利用方法也越来越复杂。

在首届 DARPA 网络大挑战过去十年后，前沿人工智能模型如今在发现和利用漏洞方面已能与顶尖人类专家匹敌。若缺乏必要的防护措施，这些强大的网络能力可能被用于攻击全球最关键软件中现存的诸多缺陷。这可能导致各类网络攻击更加频繁且更具破坏性，并增强美国及其对手的实力。因此，解决这些问题已成为民主国家重要的安全优先事项。

尽管人工智能增强的网络攻击风险严峻，但我们有理由保持乐观：那些使 AI 模型在恶意使用者手中变得危险的能力，恰恰使其在发现和修复重要软件漏洞方面具有无可估量的价值——并能开发出安全缺陷大幅减少的新软件。Glasswing 项目是朝着让防御者在即将到来的人工智能驱动网络安全时代获得持久优势迈出的重要一步。

利用Claude Mythos Preview识别漏洞与攻击手段

过去几周，我们利用 Claude Mythos 预览版在各大主流操作系统、主流网页浏览器以及其他一系列重要软件中，发现了数千个零日漏洞（即软件开发者先前未知的缺陷），其中许多属于高危漏洞。

在我们前沿红队博客的一篇文章中，我们提供了部分已修复漏洞的技术细节，以及在某些情况下 Mythos Preview 发现的利用这些漏洞的方法。它能够完全自主地识别出几乎所有这些漏洞，并开发出许多相关的利用程序，无需任何人工指导。以下是三个示例：

Mythos Preview 在 OpenBSD 中发现了一个存在 27 年的漏洞——该系统以全球最安全加固的操作系统之一而闻名，常用于运行防火墙及其他关键基础设施。该漏洞允许攻击者仅通过连接至运行该系统的机器，即可远程使其崩溃；
它还发现了一个存在于 FFmpeg 中长达 16 年的漏洞——该软件被无数程序用于视频编解码——而自动化测试工具曾对这段问题代码执行过五百万次测试，却始终未能发现该缺陷
该模型自主发现并串联了 Linux 内核中的多个漏洞——Linux 内核是运行全球大多数服务器的软件——使得攻击者能够从普通用户权限提升至完全控制机器。

我们已向相关软件的维护者报告了上述漏洞，目前所有漏洞均已修复。对于其他许多漏洞，我们今日将提供详细信息的加密哈希值（参见红队博客），待修复完成后我们将公布具体细节。

Anthropic: 高级工具使用功能

Tue, 07 Apr 2026 11:18:20 +0800

AI 智能体的未来，是模型能够无缝协同数百乃至数千种工具。一个集成 Git 操作、文件管理、包管理器、测试框架和部署管道的 IDE 助手。一个同时连接 Slack、GitHub、Google Drive、Jira、公司数据库以及数十个 MCP 服务器的运维协调器。

要构建高效的智能体，它们需要能够处理无限的工具库，而不是将所有定义预先塞入上下文。我们关于在 MCP 中使用代码执行的博客文章曾讨论过，在智能体读取请求之前，工具结果和定义有时会消耗超过 5 万个标记。智能体应当按需发现和加载工具，仅保留与当前任务相关的内容。

智能体还需要具备从代码调用工具的能力。使用自然语言工具调用时，每次调用都需要完整的推理过程，无论中间结果是否有用都会堆积在上下文中。代码天然适合编排逻辑，例如循环、条件判断和数据转换。智能体需要根据当前任务灵活选择代码执行与推理调用。

智能体还需要从示例中学习正确的工具使用方法，而不仅仅是依赖模式定义。JSON 模式定义了结构上的有效性，但无法表达使用模式：何时包含可选参数、哪些组合具有实际意义，或者您的 API 期望遵循何种约定。

今天，我们发布三项功能来实现这一目标：

工具搜索工具，使 Claude 能够使用搜索工具访问数千种工具，同时不会占用其上下文窗口
程序化工具调用，允许 Claude 在代码执行环境中调用工具，从而减少对模型上下文窗口的影响
工具使用示例，为展示如何有效使用特定工具提供了通用标准

在内部测试中，我们发现这些功能帮助我们构建了传统工具使用模式无法实现的项目。例如，Claude for Excel 利用程序化工具调用功能，能够读取和修改包含数千行数据的电子表格，同时不会超出模型的上下文窗口容量。

根据我们的经验，我们相信这些功能为您利用 Claude 构建应用开启了新的可能性。

工具搜索工具

挑战

MCP 工具定义提供了重要的上下文，但随着连接的服务端增多，这些令牌会不断累积。以五个服务端的设置为例：

GitHub：35 个工具（约 26K token）
Slack：11 个工具（约 21K token）
Sentry：5 个工具（约 3K token）
Grafana：5 个工具（约 3K token）
Splunk：2 个工具（约 2K token）

这意味着在对话开始前，就有 58 个工具消耗了约 5.5 万个token。如果再添加像 Jira 这样的服务器（仅它自己就使用了约 1.7 万个token），你很快就会接近超过 10 万个token的开销。在 Anthropic，我们曾观察到工具定义在优化前消耗了 13.4 万个token。

AgentSession 源码解析：pi 的对话调度核心

Wed, 25 Mar 2026 16:17:50 +0800

pi 是一个开源的 AI coding agent。对于用户而言，它表现为一个能持续对话、自动使用工具、处理错误的命令行助手；对于代码而言，这一切都由 AgentSession 这个类统一调度。

本文通过阅读 AgentSession 的源码，拆解它的四个核心机制：

prompt() 处理流程：用户输入如何经过多层预处理后抵达 LLM
消息事件处理链路：LLM streaming 期间事件如何流转、驱动上层组件
自动重试机制：临时性 LLM 错误如何被透明地重试
上下文压缩（Compaction）：长会话如何在不中断的前提下腾出 context 空间

`prompt()` 函数处理流程

prompt() 是 AgentSession 的核心入口，负责把用户输入经过一系列处理后发送给 LLM。

主流程：

  flowchart TD
    A([prompt]) --> B["① Extension Command 拦截<br/>/xxx → 执行后返回"]
    B -- 未命中或跳过 --> C["② Extension input 事件<br/>可拦截或变换输入"]
    C -- handled 返回 --> Z1([返回])
    C -- 继续 --> D["③ Skill / Template 展开<br/>/skill:name、/template"]
    D --> E{agent 正在 streaming？}
    E -- 是 --> F["④ 排队：steer 或 followUp"]
    F --> Z2([返回])
    E -- 否 --> G["⑤ 校验 model + API key"]
    G -- 失败 --> Z3([抛出错误])
    G -- 通过 --> H["⑥ Compaction 检查"]
    H --> I["⑦ 构建 messages<br/>user + images + pendingNextTurn"]
    I --> J["⑧ Extension before_agent_start 事件<br/>注入 custom messages / 修改 system prompt"]
    J --> K["⑨ agent.prompt + waitForRetry"]
    K --> Z4([返回])

阶段 1：Extension Command 拦截 输入以 / 开头时，优先在 extension runner 里查找注册的命令并执行。Extension command 通过 ctx（即 sendUserMessage()）自行决定是否与 LLM 交互，执行完直接返回，不走后续流程。

Pi Session Manager 源码解析

Wed, 25 Mar 2026 14:08:44 +0800

Pi 的 SessionManager 负责管理 AI 对话的完整生命周期——从创建、持久化、恢复，到分支与压缩。每一次对话都以 append-only 的 .jsonl 文件保存在磁盘上，session 内部以树状结构组织，支持从任意历史节点分叉出新的对话分支。

本文从源码角度，依次梳理 SessionManager 的创建方式、文件格式、entry 类型、写入机制、上下文构建，以及分支和历史树导航的完整流程。

SessionManager 的创建方式

SessionManager 的 constructor 是 private 的，外部只能通过静态工厂方法创建实例，每个方法对应一种 CLI 使用场景：

方法	对应 CLI 场景	说明
`SessionManager.create(cwd)`	默认（新 session）	`sessionFile=undefined`，按时间戳 + UUID 生成新文件名，懒创建
`SessionManager.open(path)`	`--session <id>`	加载指定文件，从 header 读取 cwd
`SessionManager.continueRecent(cwd)`	`--continue`	找最近修改的 `.jsonl` 文件打开，找不到则新建
`SessionManager.inMemory()`	`--no-session`	`persist=false`，不写磁盘
`SessionManager.forkFrom(src, cwd)`	`--fork <id>`	复制源文件所有 entry 到新文件，`parentSession` 记录来源

constructor 内部做两件事：若需要持久化则创建目录；若传入了 sessionFile 则加载已有文件（含版本迁移），否则调 newSession() 初始化一个空 session。

Session 文件格式

每个 session 是一个 .jsonl 文件，每行一个 JSON 对象。第一行是 SessionHeader，后续每行是一个 SessionEntry。

Pi Coding Agent

Tue, 24 Mar 2026 14:10:16 +0800

@mariozechner/pi-coding-agent

Pi 是一个极简的终端编程框架。让 pi 适应你的工作流程，而不是反过来，无需 fork 和修改 pi 内部代码。使用 TypeScript 扩展、技能、提示词模板和主题来扩展它。将你的扩展、技能、提示词模板和主题放入 Pi 包中，通过 npm 或 git 与他人分享。

Pi 自带强大的默认配置，但跳过了子代理和计划模式等功能。相反，你可以让 pi 构建你想要的功能，或者安装符合你工作流程的第三方 pi 包。

Pi 以四种模式运行：交互模式、打印或 JSON 模式、用于进程集成的 RPC 模式，以及用于嵌入你自己应用的 SDK 模式。参见 openclaw/openclaw 了解真实世界的 SDK 集成案例。

Quick Start

npm install -g @mariozechner/pi-coding-agent

使用 API 密钥进行认证：

export ANTHROPIC_API_KEY=sk-ant-...
pi

或使用你现有的订阅：

pi
/login  # 然后选择提供商

然后就可以与 pi 对话了。默认情况下，pi 为模型提供四个工具：read、write、edit 和 bash。模型使用这些工具来满足你的请求。通过技能、提示词模板、扩展或 pi 包添加功能。

供应商与模型

对于每个内置提供商，pi 维护一个支持工具调用的模型列表，每次发布都会更新。通过订阅（/login）或 API 密钥认证，然后通过 /model（或 Ctrl+L）从该提供商选择任意模型。

订阅：

Anthropic Claude Pro/Max
OpenAI ChatGPT Plus/Pro (Codex)
GitHub Copilot
Google Gemini CLI
Google Antigravity

API 密钥：

[Pi-Mono Internals] Part 2:The loop layer — Agent

Mon, 23 Mar 2026 15:58:41 +0800

@mariozechner/pi-agent-core

支持工具执行和事件流的有状态 Agent。基于 @mariozechner/pi-ai 构建。

Quick Start

import { Agent } from "@mariozechner/pi-agent-core";
import { getModel } from "@mariozechner/pi-ai";

const agent = new Agent({
  initialState: {
    systemPrompt: "You are a helpful assistant.",
    model: getModel("anthropic", "claude-sonnet-4-20250514"),
  },
});

agent.subscribe((event) => {
  if (event.type === "message_update" && event.assistantMessageEvent.type === "text_delta") {
    // 只流式输出新的文本块
    process.stdout.write(event.assistantMessageEvent.delta);
  }
});

await agent.prompt("Hello!");

核心概念

AgentMessage 与 LLM 消息

Agent 使用 AgentMessage，这是一种灵活的类型，可以包括：

标准 LLM 消息（user、assistant、toolResult）
通过声明合并的自定义应用特定消息类型

LLM 只理解 user、assistant 和 toolResult。convertToLlm 函数通过在每次 LLM 调用前过滤和转换消息来弥合这一差距。

消息流

AgentMessage[] → transformContext() → AgentMessage[] → convertToLlm() → Message[] → LLM
                     (可选)                                (必需)

transformContext：修剪旧消息，注入外部上下文
convertToLlm：过滤仅用于 UI 的消息，将自定义类型转换为 LLM 格式

事件流

Agent 发出事件以更新 UI。理解事件序列有助于构建响应式界面。

About

Fri, 20 Mar 2026 18:47:42 +0800

Hi，我是 Fanfei Gao。目前为止的人生轨迹：

2015–2019西北工业大学 · 本科

📷 待补图片
2019–2022北京大学 · 硕士

📷 待补图片
2022–2024阿里云 PolarDB-X · CDC 开发

Change Data Capture——让数据在系统之间流动。

[Pi-Mono Internals] Part 1:The Intelligence Layer — AI

Fri, 20 Mar 2026 18:35:25 +0800

@mariozechner/pi-ai

统一的 LLM API，支持自动模型发现、提供商配置、Token 和成本追踪，以及简单的上下文持久化和会话中途切换到其他模型。

注意：本库仅包含支持工具调用（函数调用）的模型，因为这对智能体工作流至关重要。

Quick Start

Step1: 选择供应商和模型，定义Tool，构造模型对话上下文。

import { Type, getModel, stream, complete, Context, Tool, StringEnum } from '@mariozechner/pi-ai';

// 完全类型化，支持提供商和模型的自动补全
const model = getModel('openai', 'gpt-4o-mini');

// 使用 TypeBox schema 定义工具，实现类型安全和验证
const tools: Tool[] = [{
  name: 'get_time',
  description: 'Get the current time',
  parameters: Type.Object({
    timezone: Type.Optional(Type.String({ description: 'Optional timezone (e.g., America/New_York)' }))
  })
}];

// 构建对话上下文（易于序列化，可在模型间传递）
const context: Context = {
  systemPrompt: 'You are a helpful assistant.',
  messages: [{ role: 'user', content: 'What time is it?' }],
  tools
};

Step2-1：流式输出

// 方式 1：流式传输，包含所有事件类型
const s = stream(model, context);

for await (const event of s) {
  switch (event.type) {
    case 'start':
      console.log(`Starting with ${event.partial.model}`);
      break;
    case 'text_start':
      console.log('\n[Text started]');
      break;
    case 'text_delta':
      process.stdout.write(event.delta);
      break;
    case 'text_end':
      console.log('\n[Text ended]');
      break;
    case 'thinking_start':
      console.log('[Model is thinking...]');
      break;
    case 'thinking_delta':
      process.stdout.write(event.delta);
      break;
    case 'thinking_end':
      console.log('[Thinking complete]');
      break;
    case 'toolcall_start':
      console.log(`\n[Tool call started: index ${event.contentIndex}]`);
      break;
    case 'toolcall_delta':
      // Partial tool arguments are being streamed
      const partialCall = event.partial.content[event.contentIndex];
      if (partialCall.type === 'toolCall') {
        console.log(`[Streaming args for ${partialCall.name}]`);
      }
      break;
    case 'toolcall_end':
      console.log(`\nTool called: ${event.toolCall.name}`);
      console.log(`Arguments: ${JSON.stringify(event.toolCall.arguments)}`);
      break;
    case 'done':
      console.log(`\nFinished: ${event.reason}`);
      break;
    case 'error':
      console.error(`Error: ${event.error}`);
      break;
  }
}

// 获取流式传输后的最终消息，添加到上下文中
const finalMessage = await s.result();
context.messages.push(finalMessage);

Step2-2：非流式输出