Bojie Li (李博杰)
2026-01-04
我跟 AI 聊了三个小时，写了两篇读书笔记（为了测试 AI 能力，我故意没有对 AI 生成的内容做任何修改）。
2025-12-21
评课社区本月遭遇了一次持续近两周的存储性能问题，导致服务响应缓慢、用户体验下降。本文记录了问题的发现、排查和解决过程，涉及 NFS 性能、ZFS 日志、Proxmox VE 虚拟化存储配置等多个层面。
2025-12-20
（本文整理自 AWS re:Invent 2025 大会期间 Anthropic 团队的演讲与深度交流）
查看演讲 Slides (HTML), 下载 PDF 版本（注意这个 slides 不是 Anthropic 官方的，是我根据照片、录音自己总结的）
本文内容
Claude 已经足够聪明了——智能不是瓶颈，上下文（Context）才是。每个组织都有独特的工作流程、规范和知识体系，而 Claude 并不天然了解这些。本文整理了来自 Anthropic 的 Context Engineering 最佳实践，涵盖 Skills、Agent SDK、MCP、评估体系等核心主题，帮助你构建更高效的 AI 应用。
- 01 | Skills 技能系统 - 让 Claude 掌握组织专属知识
- 02 | Context Engineering 框架 - 优化 token 效用的四大支柱
- 03 | Context Window 与 Context Rot - 理解上下文限制与退化问题
- 04 | 工具设计最佳实践 - 构建强大工具的要素
- 05 | Claude Agent SDK - 构建生产就绪 Agent 的框架
- 06 | 子 Agent 配置最佳实践 - 自动调用与权限管理
- 07 | MCP（Model Context Protocol） - 标准化的工具连接协议
- 08 | 评估（Evaluations） - 评估的重要性与最佳实践
- 09 | 构建 Coding Agent 的经验 - 从 Claude Code 中学到的
- 10 | 生态系统协同 - Prompts、MCP、Skills、Subagents 如何协作
2025-12-20
（本文是笔者在 2025 年 12 月 20 日的首届智能体网络与应用创新大会上的受邀报告）
摘要
当前 Agent 的人机交互以文本为核心，但这偏离了人类认知的自然模式。从第一性原理看，人类最擅长的输出模态是语音（说话速度是打字的三倍），最擅长的输入模态是视觉。视觉不是文字，而是直观的 UI。
第一步是实现实时语音交互。传统 VAD-ASR-LLM-TTS 串行架构的问题在于必须等待用户说完才能开始思考，在思考完成前无法输出。通过 Interactive ReAct 持续思考机制，Agent 可以边听边想边说：在用户说话时就开始思考，在自己说话时继续深入推理，充分利用所有时间间隙。
第二步是在实时语音基础上扩展观察空间和动作空间。通过扩展 Observation Space（从语音输入到 Computer Use 视觉感知）和 Action Space（从语音输出到 UI 生成与电脑操作），Agent 就能够一边打电话一边操作现有电脑/手机的 GUI 界面，并生成动态 UI 与用户交互。生成式 UI 的一种实现路径是生成前端代码，当前 Claude 4.5 Sonnet 已达到门槛。另一种实现路径是生成图片，当前 Nano Banana Pro 也已接近门槛。
这正是电影 Her 中 Samantha 的实现路径。Samantha 作为操作系统，需要具备五项核心能力：能够与用户实时语音对话，能够代替用户打电话办事，能够帮用户操作传统电脑和手机，能够打通用户现有设备和在线服务中的数据，拥有自己的生成式 UI 界面，有强大的用户长期记忆以实现个性化的主动服务。
2025-12-19
（本文是笔者在 AWS re:Invent 2025 Beijing Meetup 上的受邀报告）
感谢 AWS 的邀请，让我有机会参加 AWS re:Invent 2025。在这次美国之行中，我不仅参加了这场全球顶级的技术大会，更有幸与 OpenAI、Anthropic、Google DeepMind 等硅谷顶级 AI 公司的多位一线从业者进行了深入交流，其中大多数观点都得到了不同公司专家的交叉验证。
从 Las Vegas 的 re:Invent 会场，到 San Diego 的 NeurIPS，再到湾区的 AI 公司，十几天的密集交流让我学到了非常多。主要包括以下几个方面：
AI 辅助编程（Vibe Coding）的实践经验： 分析了不同场景下效率提升的差异，从创业公司的 3-5 倍提效，到大厂和研究机构效果有限的原因。
基座模型公司的组织与资源配置： 分析了 Google、OpenAI、xAI、Anthropic 等公司的优劣势，包括算力资源、薪酬结构，以及模型团队与应用团队的合作现状。
Scaling Law 的一线视角： 一线研究员普遍认为 Scaling Law 并没有结束，与 Ilya Sutskever、Richard Sutton 等顶级科学家的公开言论存在分歧。工程方法可以解决 Sampling Efficiency 和 Generalization 问题，基座模型还有很大进步空间。
科学化的应用开发方法论： 介绍了顶级 AI 应用公司普遍采用的 Rubric-based Evaluation 体系。
Context Engineering 的核心技术： 讨论了应对 Context Rot 的三大技巧：动态系统提示、动态加载 Prompts（Skills）、Sub-Agents 与上下文总结。以及文件系统作为 Agent 交互总线的设计模式。
创业公司的战略选择： 基于资源和人才的现实约束，分析了创业公司应该避开的领域（通用 Benchmark）和应该专注的方向（垂直领域 + Context Engineering）。
2025-12-18
在上一篇文章《搭建免安装客户端的 IKEv2 隧道，解决 Cursor 地区限制》中，我们介绍了如何使用 IKEv2 三层隧道来绕过 Cursor 等软件的地理位置限制。虽然 IKEv2 方案具有免安装客户端的优势，但三层隧道本身存在一些固有的性能问题。
本文将介绍一种更高效的替代方案：使用 Clash Verge 的 TUN 模式 配合 VLESS 协议，在保持对应用透明的同时，避免三层隧道带来的性能损耗。
三层隧道的性能陷阱
上一篇文章中的 IKEv2 + VLESS/WebSocket 架构存在三个主要的性能问题：
- TCP over TCP：应用层 TCP 被封装在隧道的 TCP（WebSocket）中传输，两层 TCP 状态机相互干扰
- Head-of-Line Blocking：多个应用连接复用同一条隧道，一个连接的丢包会阻塞所有连接
- 长连接 QoS 限制：单一长连接容易被网络中间设备限速
2025-11-14
【本文是笔者在 首届 FAISys’25 (The 1st Frontier AI Systems Workshop) 的受邀报告。】
【以下内容为根据英文 slides 自动生成的中文翻译，建议阅读原始 slides, 下载 PDF 版本】
大家好，非常荣幸在 首届 FAISys’25 做报告，今天我分享的主题是 Self-Evolving Real-Time Agents: Think While Listening, Speak While Thinking, Learn While Acting （自我进化的实时 Agent：边听边想，边想边说，边做边学）。
我是 Pine AI 的联合创始人和首席科学家。目前我们 Pine AI 的业务是通过 AI 打电话和操作电脑，帮助用户处理日常事务。比如帮助用户砍价、取消订阅、投诉维权、获取赔偿等。我们已经为用户节省了超过 300 万美元，成功率达到 93% ，平均为每位用户节省 270 分钟的时间。
从经验中学习，代表了机器学习的根本挑战。当前自主 AI Agent 在实际应用中面临两大核心挑战：与环境的实时交互，以及从经验中学习。今天我将介绍我们在这两方面的技术突破。
两大核心挑战
挑战一：实时交互的高延迟
实时语音 Agent 必须像人类一样在 1 秒内响应，但传统架构使用推理型 LLM 会引入 2-10 秒的延迟。
VAD（语音活动检测）的挑战：
- 必须等待 500-800ms 的持续静音才能确认用户说完
- “嗯哼”这样的回应词会被误判为打断
- 丢失了声学信息（情绪、环境音）
ASR（语音识别）的挑战：
- 没有上下文导致高错误率（邮箱、姓名、电话号码）
- 缺乏世界知识导致转写错误
LLM 的挑战：
- 被迫等待，无法边听边想
- 无法边想边说（5-10 秒的沉默）
- 说话时机（turn detection）判断差（何时该说话/保持沉默）
挑战二：从经验中学习
模型很聪明，但不熟练——就像顶尖毕业生缺乏实际工作经验。
固定模型无法学习：
- 无法从成功的轨迹中学习
- 无法从失败的轨迹中学习
- 部署后参数冻结
大世界假说（Big World Hypothesis）：
世界太大，无法预先编码所有知识：
- 业务流程是动态且非公开的
- 验证信息因公司而异
- 服务规则不断变化
- 预训练知识不足以支撑部署
2025-10-24
强化学习之父 Richard Sutton 说，当前的大语言模型是一条死路。
这听起来令人震惊。作为《The Bitter Lesson》的作者、2024 年图灵奖得主，Sutton 最相信”更多算力+通用方法必胜”，按理说他应该对 GPT-5、Claude、Gemini 这些大模型赞不绝口。但在最近的访谈中，Sutton 毫不客气地指出：LLM 只是模仿人说什么，而不是理解世界如何运转。
这场由播客主持人 Dwarkesh Patel 组织的访谈引发了激烈讨论。Andrej Karpathy 随后撰文回应，并在另一场访谈中展开了深入探讨。两位大师的争论揭示了当前 AI 发展中三个被忽视的根本问题：
第一，小世界假设的迷思：我们是否真的相信，一个足够大的模型能够掌握世界上所有重要知识，从此不需要学习？还是说，现实世界符合大世界假设——无论模型多大，在具体场景中仍需要不断学习？
第二，持续学习的缺失：当前的 model-free RL 方法（PPO、GRPO 等）只从稀疏的 reward 学习，无法利用环境给出的丰富反馈。这导致 Agent 在现实世界任务中样本效率极低，难以快速适应。
第三，Reasoner 与 Agent 的鸿沟：OpenAI 将 AI 能力分为五级，从 Chatbot 到 Reasoner 再到 Agent。但很多人误以为，把单轮 Reasoner 变成多轮就是 Agent。真正的 Agent 与 Reasoner 的核心区别在于：持续学习能力。
本文将系统梳理这两场访谈中的核心观点，并结合我们在 Pine AI 开发实时 Agent 的实践经验，探讨如何跨越这道鸿沟。
2025-10-16
本文内容
- 01 | 记忆的重要性与挑战 - 个性化价值 · 三层能力
- 02 | 记忆的表示 - Notes · JSON Cards
- 03 | 记忆的检索 - RAG · 上下文感知
- 04 | 记忆的评估 - Rubric · LLM Judge
- 05 | 前沿研究 - ReasoningBank
从个性化需求出发 → 理解记忆挑战 → 设计存储方案 → 实现智能检索 → 科学评估迭代
2025-09-28
Unified Bus 的协议文档终于发布了。协议最初的设计大多数是四五年前的工作了，我也有两年多没有继续做网络互联方面的工作，但今天读到这本 500 多页的文档，还是倍感亲切。
与大多数协议文档一样，UB 文档介绍了 Unified Bus 协议的大量细节，但很少涉及它设计背后的思考。作为曾在早期参与 UB 项目的一名小兵，介绍一些我个人的思考。今天产品化的 UB 可能与我们当年的设计有诸多不同，因此不要把本文作为权威指南。当成段子看就行了。
为什么要做 UB
要理解 Unified Bus (UB) 诞生的必然性，我们必须回到一个计算机体系结构中的根本性矛盾：总线（Bus）与网络（Network）的割裂。
长久以来，计算机世界被这两种截然不同的互联范式划分为一个个孤岛。
- 在孤岛内部（例如一台服务器或一个机箱内），我们使用总线技术，如 PCIe 或 NVLink。它们是为紧耦合系统设计的，设备间共享着统一的物理地址空间，通信延迟可以做到纳秒级，带宽极高。这是性能的天堂，但这个天堂的疆域极其有限——总线的物理距离和可连接的设备数量都受到严格限制。
- 在孤岛之间，我们则依赖网络技术，如以太网或 InfiniBand。它们为松耦合系统而生，擅长将成千上万的节点连接起来，具备超强的扩展性。但这种扩展性是有代价的：复杂的协议栈、额外的转发开销、微秒甚至毫秒级的延迟，都让网络的性能与总线相比，存在着数量级的鸿沟。
这种”内外有别”的架构，在很长一段时间里是行之有效的。然而，一个幽灵开始在计算机世界上空盘旋——Scaling Law。
大约 10 年前，深度学习领域的研究者们发现了一个惊人的规律：只要持续增大模型规模、数据量和计算量，模型的性能就会随之可预见地、持续地提升。这个发现彻底改变了游戏规则。曾经被认为是”足够用”的单机 8 卡配置，在动辄百亿、千亿参数的巨型模型面前，瞬间变得杯水车薪。
此时，一个清晰而迫切的需求摆在了所有系统架构师面前：我们能否推倒总线与网络之间的这堵墙？我们能否创造一种统一的互联，既拥有总线级的编程简易度和极致性能，又具备网络级的超大规模扩展能力？
这正是 UB 的核心使命。它不仅仅是对现有协议的修补或改良，而是一次彻底的重构。UB 的目标，是构建一个真正的”数据中心计算机”（Datacenter-scale Computer），将整个集群的异构算力、内存、存储无缝地连接成一个统一的、可编程的整体。在这个愿景中，访问一台远程服务器上的内存，应该像访问本地内存一样简单自然；上万个处理器协同计算，应该像在一块芯片上一样高效。