AI on Last Stand

AI Agent

Sat, 02 May 2026 22:32:27 +0800

ChatGPT能写文章、能回答问题，但你让它帮你订一张机票，它做不到。它能告诉你"你应该去携程搜一下"，但它没法真的打开网页、输入日期、比价、下单。

**AI Agent（智能体）**就是为了解决这个问题——让LLM不仅能"想"，还能"做"。Agent = LLM + 工具使用 + 自主规划 + 记忆。

一、从聊天机器人到智能体

1.1 纯LLM的局限

一个纯粹的LLM本质上是一个"无状态的文本生成器"：

graph LR
IN["输入文本"] --> LLM["LLM"]
LLM --> OUT["输出文本"]

它有几个根本性的限制：

限制	表现
无法执行动作	不能调API、不能操作文件、不能访问数据库
无持久记忆	每次对话结束后就"忘了"
知识过时	无法获取训练数据之后的信息
无法自主规划	不能将复杂任务分解并逐步执行
单轮思考	一次生成就结束，不能自我检查和修正

1.2 Agent的定义

AI Agent是一个以LLM为"大脑"的自主系统，能够：

感知：理解用户的意图和当前环境状态
规划：将复杂目标分解为可执行的步骤
行动：调用外部工具完成具体操作
观察：获取行动的结果
反思：根据结果调整策略

graph TD
USER["用户目标"] --> PERCEIVE["感知
理解意图"]
PERCEIVE --> PLAN["规划
分解任务"]
PLAN --> ACT["行动
调用工具"]
ACT --> OBSERVE["观察
获取结果"]
OBSERVE --> REFLECT["反思
是否完成？"]
REFLECT -->|未完成| PLAN
REFLECT -->|已完成| RESULT["返回结果"]

二、Agent的核心组件

2.1 架构总览

graph TB
subgraph Agent ["AI Agent"]
LLM["LLM（大脑）"]
PLAN["规划模块"]
MEM["记忆系统"]
TOOL["工具集"]
end
USER["用户"] --> LLM
LLM --> PLAN
PLAN --> LLM
LLM --> MEM
MEM --> LLM
LLM --> TOOL
TOOL --> LLM
LLM --> USER

2.2 LLM：Agent的大脑

LLM负责理解、推理和决策。作为Agent大脑的LLM需要具备：

AI编程工具

Sat, 02 May 2026 22:32:27 +0800

AI编程工具正在重塑软件开发的工作方式。从简单的代码补全到自主完成复杂任务的编程Agent，这个领域在短短两三年内经历了巨大的变化。本文梳理AI编程工具的核心概念、工作原理和实践方法。

一、AI编程工具的演进

1.1 三代AI编程工具

graph LR
G1["第一代
代码补全
Copilot (2021)"] --> G2["第二代
对话式编程
ChatGPT (2022)"]
G2 --> G3["第三代
编程Agent
Cursor/Devin (2024+)"]

代际	交互方式	能力范围	代表产品
第一代	行内补全，按Tab接受	单行/单函数级别	GitHub Copilot
第二代	对话框问答	代码片段级别	ChatGPT、Claude
第三代	Agent模式，自主执行	跨文件/跨系统级别	Cursor、Windsurf、Devin

1.2 当前主流工具对比

工具	类型	核心特点
GitHub Copilot	IDE插件	最早的AI编程助手，集成在VS Code/JetBrains等主流IDE中
Cursor	独立IDE	基于VS Code深度定制，Agent模式、多文件编辑
Windsurf	独立IDE	Codeium推出，强调"Flow"模式的流畅体验
Claude Code	CLI工具	终端中运行的编程Agent，适合命令行工作流
Devin	云端Agent	全自主编程Agent，自带开发环境
Amazon Q Developer	IDE插件	AWS深度集成，擅长云原生开发

二、AI编程工具的工作原理

2.1 代码补全的原理

代码补全是最基础的能力。以Copilot为例：

graph LR
CTX["上下文收集
当前文件内容
打开的相关文件
光标位置"] --> PROMPT["构造Prompt"]
PROMPT --> LLM["LLM
（Codex/GPT-4）"]
LLM --> SUGGEST["补全建议"]
SUGGEST --> USER["用户
Tab接受 / Esc拒绝"]

上下文收集是关键——模型看到的上下文越好，补全质量越高：

Claude Code 源码导读：Agent 设计详解

Sun, 21 Jun 2026 22:41:52 +0800

Claude Code 的 agent 到底是怎么被设计成一个能长时间工作、能分派子 agent、能记忆、能压缩上下文、也能可靠停下来的系统的？

Claude Code 最值得研究的地方，不是它“能调用工具”，而是它把模型、工具、记忆、上下文、后台任务、hook 和权限系统编成了一个稳定的 agent harness。

一句话概括：Claude Code 的 agent 不是一个模型循环，而是三层循环叠在一起：主 query 循环负责推理和工具回灌；工具循环负责受控执行和并发；任务循环负责子 agent、后台 agent、记忆整理和长任务生命周期。

flowchart TD
User["用户输入 / 队列消息"] --> Query["query.ts 主循环"]
Query --> Model["流式模型调用"]
Model -->|没有 tool_use| StopPath["停止路径
stop hooks / token budget / completed"]
Model -->|产生 tool_use| ToolLoop["工具执行循环"]
ToolLoop --> Attach["附件注入
记忆 / 变更文件 / 任务通知 / 技能"]
Attach --> Query
Query --> Compact["上下文治理
tool budget / microcompact / autocompact / reactive compact"]
Query --> Memory["记忆系统
CLAUDE.md / AutoMem / Session Memory"]
Query --> AgentTool["AgentTool"]
AgentTool --> SubAgent["runAgent 子循环"]
SubAgent --> LocalTask["LocalAgentTask
前台 / 后台 / 可恢复"]
LocalTask --> Attach

一、核心源码地图

先把关键文件放在桌面上：

FoundationModels

Sat, 02 May 2026 22:32:27 +0800

2025年WWDC上，Apple把Apple Intelligence背后的那个"设备端基础模型"第一次对开发者开放——这就是FoundationModels框架。过去要在App里接入LLM，基本只有两条路：调OpenAI/Claude这类云端API，或者自己在端上集成llama.cpp、MLC、Core ML等推理框架。前者有隐私和成本问题，后者有工程门槛和包体积问题。FoundationModels试图提供第三条路：一个系统级的、免费的、离线可用的、原生Swift的LLM API。

本文从框架定位开始，一路讲到Guided Generation、Tool Calling、Streaming、Adapter微调等细节，目标是让你在读完后能直接上手用它写出一个生产可用的功能。

一、FoundationModels是什么

1.1 一句话定义

FoundationModels是iOS 26 / macOS 26及之后的系统框架，提供对设备端Apple Intelligence语言模型的编程访问能力。模型本身约3B参数，经过4-bit量化，常驻系统，不计入App包体积，所有推理在设备上完成。

1.2 能做什么 / 不能做什么

能做	不能做
文本生成、摘要、分类、抽取、改写、翻译	世界知识问答（模型太小，不适合当"百科")
结构化输出（生成指定Swift类型）	图像生成 / 视频生成
工具调用（Function Calling）	嵌入向量生成（Embedding）
短对话、小规模推理	长上下文的复杂推理（窗口有限）
完全离线、无需联网	替代GPT-4这类前沿大模型

定位非常清楚：它是一个"端侧小而美"的模型，负责那些没必要上云、对延迟/隐私/成本敏感的任务。

1.3 为什么值得iOS开发者关注

零成本：不像调OpenAI API，每token都花钱。
零延迟网络层：首token延迟可以做到100ms级。
隐私合规：输入不出设备，符合医疗、金融、教育场景的合规要求。
离线可用：地铁、飞机、隧道里也能跑。
原生Swift DSL：宏驱动的@Generable、Tool协议，跟SwiftUI一样"声明式"。
与系统深度集成：可直接访问Apple Intelligence上下文（比如屏幕识别、个人数据等，受权限约束）。

二、整体架构

graph TB
subgraph APP ["应用层"]
UI["SwiftUI / UIKit"]
VM["ViewModel"]
end
subgraph FM ["FoundationModels Framework"]
SLM["SystemLanguageModel
模型句柄 + 可用性"]
SESSION["LanguageModelSession
会话对象 / 上下文"]
GEN["Generable宏
结构化输出"]
TOOL["Tool协议
工具调用"]
STREAM["ResponseStream
流式输出"]
GUARD["Guardrails
安全过滤"]
end
subgraph SYSTEM ["系统层"]
ANE["Apple Neural Engine"]
GPU["GPU"]
MODEL["On-device Foundation Model
≈3B params, 4-bit quant"]
ADAPTER["LoRA Adapters"]
end
UI --> VM
VM --> SESSION
SESSION --> SLM
SESSION --> GEN
SESSION --> TOOL
SESSION --> STREAM
SESSION --> GUARD
SLM --> MODEL
MODEL --> ANE
MODEL --> GPU
ADAPTER --> MODEL

几个关键抽象：

Function Calling与MCP

Sat, 02 May 2026 22:32:27 +0800

LLM很聪明，但它被困在一个"文本沙箱"里——它只能接收文本、输出文本。要让LLM调用API、查数据库、操作文件，就需要一个"桥梁"协议来连接LLM与外部世界。

Function Calling和**MCP（Model Context Protocol）**就是这样的桥梁。它们的目标相同——让LLM能调用外部工具——但设计理念和使用场景有很大不同。本文将详细对比这两种方案。

一、Function Calling：LLM原生的工具调用

1.1 基本原理

Function Calling是LLM提供商（OpenAI、Anthropic、Google等）在模型层面支持的工具调用能力。核心思路是：

你告诉LLM有哪些函数可用（函数名、参数定义、功能描述）
LLM根据用户的问题判断是否需要调用函数
如果需要，LLM输出一个结构化的函数调用请求（而不是自然语言）
你的代码执行这个函数，把结果返回给LLM
LLM基于结果生成最终回答

sequenceDiagram
participant U as 用户
participant App as 应用程序
participant LLM as LLM API
participant Tool as 外部工具/API
U->>App: "北京今天天气怎么样？"
App->>LLM: 用户消息 + 可用函数定义
LLM->>App: 函数调用请求
get_weather(city="北京")
App->>Tool: 调用天气API
Tool->>App: {"temp": 22, "weather": "晴"}
App->>LLM: 函数执行结果
LLM->>App: "北京今天天气晴朗，气温22°C"
App->>U: 最终回答

关键点：LLM自身并不执行函数，它只是生成"我想调用这个函数"的结构化指令，真正的执行由应用程序完成。

1.2 函数定义

以OpenAI的格式为例，开发者需要用JSON Schema描述每个可用的函数：

{
 "tools": [
 {
 "type": "function",
 "function": {
 "name": "get_weather",
 "description": "获取指定城市的当前天气信息",
 "parameters": {
 "type": "object",
 "properties": {
 "city": {
 "type": "string",
 "description": "城市名称，如'北京'、'上海'"
 },
 "unit": {
 "type": "string",
 "enum": ["celsius", "fahrenheit"],
 "description": "温度单位"
 }
 },
 "required": ["city"]
 }
 }
 }
 ]
}

LLM通过阅读这个定义来理解：这个函数叫什么、干什么用、需要什么参数。description字段的质量直接影响LLM能否正确选择和调用函数。

Harness Engineering 精读笔记

Sat, 02 May 2026 22:32:27 +0800

基于 2025.11 — 2026.03 期间 Anthropic、OpenAI、LangChain、Google DeepMind、Stanford 发布的九篇核心文章的精读整理。目标：理解 Harness Engineering 是什么，以及大公司和学术机构在实践中做了哪些探索。

一、什么是 Harness Engineering？

1.1 Harness 的定义

LangChain 给出了最清晰的公式化定义：

Agent = Model + Harness “If you’re not the model, you’re the harness.” “A harness is every piece of code, configuration, and execution logic that isn’t the model itself.”

具体来说，Harness 包括：

System Prompts — 系统提示词，定义 Agent 的行为边界
Tools / Skills / MCPs — 工具集及其描述（文件读写、代码执行、浏览器操作等）
Bundled Infrastructure — 捆绑基础设施（文件系统、沙箱、浏览器）
Orchestration Logic — 编排逻辑（子 Agent 派生、任务交接、模型路由）
Hooks / Middleware — 确定性执行逻辑（压缩、续行、lint 检查等）

Anthropic 不给 Harness 下抽象定义，而是通过实践来展示：他们用 “harness design” 和 “harnesses for long-running agents” 来描述围绕 Agent 执行循环的编排层。Anthropic 在博客中明确说：“harness design is key to performance at the frontier of agentic coding”。

LLM Wiki：Karpathy 提出的"后 RAG 时代"个人知识库范式

Sat, 02 May 2026 22:32:27 +0800

2026 年 4 月，Andrej Karpathy 在 GitHub Gist 上发布了一份名为 llm-wiki.md 的"想法文档"（idea file），短短几天收获了 5000+ 星和 5000+ fork。这篇文档篇幅不长，却被评价为"后 RAG 时代"个人知识管理的一个**分类定义性（category-defining）**框架。

原文地址：https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f

Karpathy 写这篇文档的风格非常有意思：它不是一份实现规范，而是一份"可以复制粘贴给你自己的 LLM Agent（Claude Code、Codex、OpenCode/Pi 等）“的模式描述。它告诉 Agent 模式的核心是什么，剩下的细节（目录结构、schema 约定、页面格式、工具链）交给用户和 Agent 一起协同演化。

本文将详细拆解这份文档的核心思想，并结合社区讨论（scale 极限、Zettelkasten 替代方案、反对派观点等）给出一个完整解读。

一、问题起点：RAG 的"每次从零开始”

大多数人今天使用 LLM 处理文档的方式是 RAG（检索增强生成）：

把一堆文档上传到系统
查询时 LLM 从原文中检索相关片段
基于片段合成答案

NotebookLM、ChatGPT 文件上传、绝大多数 RAG 系统都是这个模式。

1.1 RAG 的根本局限：没有累积

Karpathy 点出了 RAG 的一个关键问题：LLM 每次都在从零开始重新发现知识。

问一个需要综合 5 篇文档的微妙问题 → LLM 每次都要重新找出相关片段，重新拼接，重新推理
上一次你问过的关键问题的答案，下一次再问时不会被保留
跨源的矛盾、交叉引用、细微的关联 —— 每次都要重新建立

什么都没有被"沉淀"下来。 这就像每次考试都重新读一遍教科书，却从不做笔记、从不整理知识卡片、从不画思维导图。

1.2 LLM Wiki 的核心差异

LLM Wiki 提出了一个根本性的反转：

Prompt Engineering

Sat, 02 May 2026 22:32:27 +0800

大语言模型（LLM）的能力边界很大程度上取决于你怎么跟它说话。同样的模型，一个精心设计的Prompt可以得到专业级的回答，一个随意的Prompt可能只得到平庸甚至错误的结果。Prompt Engineering就是研究如何有效地与LLM沟通的技术。

一、Prompt的基本构成

1.1 一个Prompt的解剖

一个高质量的Prompt通常包含以下要素：

graph TD
P["完整的Prompt"] --> R["角色
Role"]
P --> C["上下文
Context"]
P --> I["指令
Instruction"]
P --> E["示例
Examples"]
P --> F["格式要求
Format"]
P --> CO["约束
Constraints"]

要素	作用	示例
角色	设定模型的身份和专业背景	“你是一位有10年经验的iOS架构师”
上下文	提供背景信息	“我们的项目使用MVVM架构，Swift语言”
指令	明确说明任务	“请review以下代码并指出问题”
示例	展示期望的输入输出格式	给出一个输入-输出样例
格式要求	指定输出的结构	“以Markdown表格形式输出”
约束	限制条件	“不超过500字"“只使用Swift标准库”

1.2 System Prompt vs User Prompt

在API调用中，消息分为不同的角色：

{
 "messages": [
 {
 "role": "system",
 "content": "你是一位资深iOS开发工程师，擅长性能优化。回答时给出具体的代码示例。"
 },
 {
 "role": "user",
 "content": "如何优化UITableView的滚动性能？"
 }
 ]
}

System Prompt：设定模型的整体行为、角色和约束，贯穿整个对话
User Prompt：具体的问题或指令
Assistant：模型的历史回复，提供对话上下文

二、核心Prompt技术

2.1 Zero-Shot Prompting

直接给指令，不提供任何示例：

RAG（检索增强生成）

Sat, 02 May 2026 22:32:27 +0800

大语言模型（LLM）能流畅地写文章、回答问题、编写代码，但它有一个根本性的局限：它的知识被冻结在训练数据截止的那一刻。问它昨天发生了什么新闻？不知道。问它你公司内部的技术文档？更不知道。

更棘手的是，LLM有时候会"一本正经地胡说八道"——这就是所谓的**幻觉（Hallucination）**问题。模型会自信满满地编造一个不存在的论文引用、一个错误的API参数、甚至一个虚构的历史事件。

**RAG（Retrieval-Augmented Generation，检索增强生成）**正是为解决这些问题而生。它的核心思想简单而有效：在让LLM回答之前，先从外部知识库中检索相关信息，把这些信息塞到提示词（Prompt）里，让LLM基于真实资料来回答。

一、RAG的核心思想

1.1 一个直觉的类比

想象你是一个闭卷考试的学生（这就是纯LLM）——只能靠记忆作答，记不清的地方就只能猜。

现在允许你带一本参考书（这就是RAG）——遇到不确定的问题，先翻书找到相关段落，然后基于书中的内容来组织答案。

显然，开卷考试的准确率会高得多。

1.2 RAG的核心价值

LLM的局限	RAG的解决方案
知识过期，无法获取训练截止后的信息	随时更新知识库，实时生效
幻觉问题，生成不存在的信息	基于真实文档生成，可追溯来源
垂直领域知识不足	接入专业知识库，提供领域专业回答
更新成本高，Fine-tuning代价大	只需更新知识库，成本低且灵活

1.3 RAG的基本流程

graph LR
Q["用户提问"] --> R["检索器
Retriever"]
KB["知识库"] --> R
R --> C["相关文档片段"]
C --> P["构造Prompt
问题 + 相关文档"]
P --> LLM["大语言模型"]
LLM --> A["生成回答"]

三个核心步骤：

检索（Retrieve）：根据用户的问题，从知识库中找到最相关的文档片段
增强（Augment）：将检索到的信息与原始问题一起构造成Prompt
生成（Generate）：LLM基于增强后的Prompt生成回答

二、从关键词到语义：检索方式的演进

2.1 传统关键词搜索的局限

最简单的检索方式是关键词匹配。比如用户问"如何购买商品？"，搜索引擎会提取关键词"购买"、“商品”，然后去匹配包含这些词的文档。

问题很明显：

文档中写的是"下单流程说明"——语义完全一致，但没有任何关键词重合
无法理解同义词：“购买"vs"下单"vs"采购"vs"买”
必须精确匹配关键词，用词不同就检索不到

我们需要一种理解语义的检索方式。

2.2 文本嵌入（Text Embedding）

文本嵌入模型（如OpenAI的text-embedding-3-small、BGE等）将文本转换为高维向量（通常512/768/1024/1536维），使得语义相近的文本在向量空间中距离相近：

"如何购买商品？" → [0.23, -0.15, 0.82, ...] (768维向量)
"下单流程说明" → [0.21, -0.12, 0.79, ...] ← 向量很近，语义匹配!
"今天天气真好" → [-0.65, 0.43, -0.21, ...] ← 向量很远

在高维向量空间中，每个维度代表不同的语义特征（如情感倾向、主题领域、动作类型等）。语义相似的文本会在空间中聚集在一起——“购买”、“下单”、“采购"形成一个语义簇，而"天气预报"则远离这个簇。

Transformer架构原理

Sat, 02 May 2026 22:32:27 +0800

ChatGPT、Claude、Gemini——这些模型的核心都是同一个架构：Transformer。它在2017年由Google的论文"Attention Is All You Need"提出，彻底改变了自然语言处理（NLP）领域，随后席卷了计算机视觉、语音、蛋白质折叠等几乎所有AI领域。

我们从最直觉的角度出发，一步步搞清楚Transformer到底在做什么。

一、从序列到序列：Transformer要解决什么问题

1.1 语言的本质是序列

一句话是一个词的序列：

"我 今天 很 开心" → [我, 今天, 很, 开心]

语言模型的核心任务是：给定前面的词，预测下一个词。

"我 今天 很" → ?（开心？难过？忙碌？）

但词与词之间的关系非常复杂。“它"指代谁？“银行"是河岸还是金融机构？这取决于上下文中其他词的信息。

1.2 RNN的困境

在Transformer之前，处理序列的主流方法是循环神经网络（RNN）。RNN像一个人从左到右逐词阅读，用一个"记忆状态"来记住看过的内容：

graph LR
X1["我"] --> H1["h₁"]
H1 --> H2["h₂"]
X2["今天"] --> H2
H2 --> H3["h₃"]
X3["很"] --> H3
H3 --> H4["h₄"]
X4["开心"] --> H4

问题在于：

长距离依赖困难：信息需要经过很多步才能从序列开头传到末尾，容易丢失
无法并行：必须逐步处理，前一步完成才能开始后一步，训练很慢

Transformer的核心洞察是：不需要逐步处理，让序列中的每个位置直接与所有其他位置交互。这就是"注意力（Attention）“机制。

二、词嵌入：给词语一个数学身份

2.1 从独热编码到词向量

计算机不认识"猫”、“狗"这样的文字。我们需要把词转换成数字。

最朴素的方式是独热编码（One-Hot Encoding）：假设词汇表有50,000个词，每个词用一个50,000维的向量表示，只有对应位置是1，其余全是0。

"猫" → [0, 0, ..., 1, ..., 0, 0] (第3721个位置是1)
"狗" → [0, 0, ..., 0, 1, ..., 0, 0] (第5042个位置是1)

问题：在这种表示下，“猫"和"狗"的距离与"猫"和"经济学"的距离一样远——完全丢失了语义信息。

iOS中AI Chat实战

Sat, 02 May 2026 22:32:27 +0800

做一个能跑的AI聊天Demo只需要几十行代码：拼一个HTTP请求、把模型返回的文本显示出来即可。但要做一个达到生产级体验的AI Chat，就会面对一堆并不"AI"的工程问题：字怎么一个个"蹦"出来？Markdown怎么边流边渲染？模型想让前端弹一个卡片甚至一个表单，该怎么办？用户点击卡片里的按钮怎么回传给模型？

本文以iOS为实现目标，系统梳理AI Chat的工程架构，重点讲清楚两件事：流式输出与A2UI（Agent to UI），同时覆盖工具调用、取消、多模态、端侧推理等常见高级能力。

一、整体架构

一个完整的iOS AI Chat客户端，通常可以拆成如下几层：

graph TB
subgraph UI ["展示层"]
LIST["消息列表
UICollectionView / List"]
CELL["消息Cell
文本 / Markdown / A2UI Surface"]
INPUT["输入区
文本 / 图片 / 语音"]
end
subgraph VM ["ViewModel层"]
STATE["会话状态机"]
STREAM["流式拼装器"]
TOOL["工具执行器"]
end
subgraph NET ["网络层"]
SSE["SSE / HTTP 分块"]
PARSER["协议解析
OpenAI / Claude / A2UI"]
end
subgraph DATA ["数据层"]
DB["消息持久化
GRDB / WCDB / CoreData"]
CTX["上下文裁剪
Token预算"]
end
INPUT --> STATE
STATE --> NET
NET --> PARSER
PARSER --> STREAM
STREAM --> CELL
STREAM --> TOOL
TOOL --> NET
STATE --> DB
DB --> CTX
CTX --> NET

几个关键特征：

反向传播算法

Sat, 02 May 2026 22:32:27 +0800

在上一篇文章中，我们构建了一个神经网络，了解了前向传播是如何产生预测的，也知道了损失函数可以衡量预测有多差。但我们遗留了最核心的问题：那13,002个参数到底该怎么调整，才能让网络变得更好？

这就是反向传播算法（Backpropagation）要回答的问题。它是神经网络学习的核心引擎，几乎所有现代深度学习的训练都建立在它之上。

一、梯度下降：从直觉开始

1.1 一个简单的类比

想象你站在一片浓雾中的山地上，看不到全貌，但你能感受到脚下地面的倾斜方向。你的目标是找到最低的山谷。最自然的策略是什么？

顺着脚下最陡的下坡方向走一小步。

这就是**梯度下降（Gradient Descent）**的核心思想。

1.2 数学表述

假设损失函数 $L$ 取决于所有参数 $\theta = (w_1, w_2, ..., w_n, b_1, b_2, ..., b_m)$。

梯度是一个向量，指向损失增长最快的方向：

$$\nabla L = \left(\frac{\partial L}{\partial w_1}, \frac{\partial L}{\partial w_2}, \cdots, \frac{\partial L}{\partial b_m}\right)$$

梯度的每个分量告诉我们：如果微微增大某个参数，损失会增加多少。

要降低损失，我们朝梯度的反方向迈步：

$$\theta_{\text{new}} = \theta_{\text{old}} - \eta \cdot \nabla L$$

其中 $\eta$ 是学习率（learning rate），控制每一步的步长。

1.3 学习率的微妙之处

学习率	下降行为	结果
太小	每步挪动极小，到达局部最小值后就停住了，无法跳出	收敛极慢，可能困在局部最小值
太大	一步跨过了最低点，又跨回来，反复来回	在最低点附近震荡，甚至发散
合适	每步大小适中，沿着曲面稳步走向谷底	稳步下降，逐渐逼近最优解

1.4 梯度下降的关键问题

现在整个问题归结为一件事：怎么高效地计算 $\nabla L$，即损失对每一个参数的偏导数？

你可能会想：对每个参数微微扰动一下，看看损失变化了多少。但如果有13,002个参数，每个参数都扰动一次，就需要做13,002次前向传播——太慢了。

神经网络原理

Sat, 02 May 2026 22:32:27 +0800

想象你手写了一个数字"3"，然后拿给计算机看——它是怎么"认出"这是3而不是8的？这个看似简单的问题，背后隐藏着整个深度学习的核心思想。让我们从最直觉的方式开始，一层一层揭开神经网络的面纱。

一、从像素到数字：问题的本质

1.1 手写数字识别

假设我们有一张28x28像素的灰度手写数字图片。每个像素是一个0到1之间的数字——0代表全黑，1代表全白。这意味着一张图片其实就是一个包含784个数字的列表。

图片 → [0.0, 0.0, 0.12, 0.85, 0.93, ..., 0.0] (784个数字)

我们的目标是设计一个函数，输入这784个数字，输出10个数字，分别代表这张图是0~9每个数字的概率：

f(784个像素值) → [P(0), P(1), P(2), ..., P(9)]

比如输入一张手写的"3"，我们期望输出类似：

[0.01, 0.02, 0.05, 0.89, 0.01, 0.01, 0.00, 0.01, 0.00, 0.00]
 ^^^^
 "3"的概率最高

这就是神经网络要解决的问题。但关键问题是：这个函数 f 长什么样？

1.2 为什么传统编程行不通

你可能会想：能不能写一堆if-else规则？比如"如果上方有一个圆弧，下方也有一个圆弧，那就是3"。

问题在于：人类写字的方式千变万化。同一个"3"，有人写得圆润，有人写得尖锐，有人偏左，有人偏右。你几乎不可能用明确的规则覆盖所有情况。

我们需要的是一种从数据中自动学习规则的方法——这就是神经网络。

二、神经网络的结构

2.1 神经元：最基本的单元

让我们从最简单的单元开始。一个神经元本质上就是一个持有数字的容器。这个数字叫做激活值（activation），取值范围通常在0到1之间。

你可以把它想象成一个灯泡：0表示完全熄灭，1表示完全点亮，中间的值表示不同亮度。

2.2 层：神经元的组织方式

神经网络把神经元组织成层（layer）：

graph LR
subgraph 输入层 [输入层 - 784个神经元]
I1[像素1]
I2[像素2]
I3[...]
I784[像素784]
end
subgraph 隐藏层1 [隐藏层1 - 16个神经元]
H1_1[h1]
H1_2[h2]
H1_3[...]
H1_16[h16]
end
subgraph 隐藏层2 [隐藏层2 - 16个神经元]
H2_1[h1]
H2_2[h2]
H2_3[...]
H2_16[h16]
end
subgraph 输出层 [输出层 - 10个神经元]
O0[0]
O1[1]
O2[...]
O9[9]
end
I1 --> H1_1
I1 --> H1_2
I784 --> H1_16
H1_1 --> H2_1
H1_16 --> H2_16
H2_1 --> O0
H2_16 --> O9

输入层：784个神经元，每个对应一个像素值
隐藏层：中间的层（这里用2层，每层16个神经元）
输出层：10个神经元，对应数字0~9

为什么叫"隐藏层"？因为在训练数据中，我们只知道输入（像素）和输出（标签），中间层在"学什么"我们并不直接指定——它们是被自动学出来的。

OpenClaw 源码导读（三）：Agent Harness — 为"每一家 LLM 都能兜住"而生的执行管线

Sat, 02 May 2026 22:32:27 +0800

系列第一篇把 OpenClaw 的架构地图摊开，第二篇深入 Gateway 控制平面。这一篇，我们钻进整个项目的心脏——src/agents/，看 OpenClaw 怎么处理最复杂的一件事：当 Gateway 接到一条用户消息之后，怎么把它变成一轮真正的 LLM turn + Tool 循环。

这一层代码的体量和复杂度非常惊人：

src/agents/pi-embedded-runner/run.ts 单文件 2160 行，是整个 agent 循环的驱动器。

src/agents/pi-embedded-runner/compact.ts 1148 行，专门处理上下文压缩。

整个 src/agents/ 目录有 830+ 个文件，光 anthropic-*.ts 就有近 20 个（为了 Messages API 的各种 edge case）。

同时支持 Anthropic、OpenAI、Google Gemini、Bedrock、Vertex、OpenRouter、Z.AI/GLM、MiniMax、Qwen、Ollama、Kilocode 等十多个 provider。

但这些"量"的背后，是一个只有一个接口的核心抽象：AgentHarness。本文就从这个抽象出发，一路看到 2160 行循环如何处置真实世界里十几类失败。

一、Harness 抽象：只有一个 `runAttempt`

1. 为什么不用 LangChain 风格的"Agent Framework"

读过 LangChain 或 CrewAI 的人第一眼会期望看到 AgentExecutor、AgentChain、Memory、Callback、Tool 这些类。OpenClaw 里一个都没有。

它的选择是：把整个 agent 循环当成一个黑盒，对外只暴露一个接口：

export type AgentHarness = {
 id: string;
 label: string;
 pluginId?: string;
 supports(ctx: AgentHarnessSupportContext): AgentHarnessSupport;
 runAttempt(params: AgentHarnessAttemptParams): Promise<AgentHarnessAttemptResult>;
 compact?(params: AgentHarnessCompactParams): Promise<AgentHarnessCompactResult | undefined>;
 reset?(params: AgentHarnessResetParams): Promise<void> | void;
 dispose?(): Promise<void> | void;
};

五个方法，其中三个可选：

OpenClaw 源码导读（四）：Channels、Nodes 与扩展生态

Sat, 02 May 2026 22:32:27 +0800

前三篇我们看清了 OpenClaw 的三副骨架：架构全景、Gateway 控制平面、Agent Harness 执行管线。这一篇是压轴篇，我们看它的"血肉"——channels/、node-host/、canvas-host/、plugins/、skills/、sandbox/。OpenClaw 真正"好用"的感觉，是从这一层来的：一条消息从 WhatsApp 进来、触发 iOS 上的摄像头、在 Android 上渲染一张 Canvas、最后把结果发回 Slack 线程——整个过程中 Gateway 本身一行代码都不需要改。

本文涵盖 118 个 channel/provider extension、53 个 skill、iOS/macOS/Android node 客户端、A2UI Canvas 协议、以及 Docker sandbox 的整套隔离模型。

一、Channels：118 个 extension 是怎么"插"进来的

1. ChannelPlugin 接口

OpenClaw 所有 channel（微信、Telegram、Slack、iMessage、IRC、Discord……）本质上都是实现同一个接口 ChannelPlugin：

export type ChannelPlugin<ResolvedAccount = any, Probe = unknown, Audit = unknown> = {
 id: ChannelId;
 meta: ChannelMeta;
 capabilities: ChannelCapabilities;
 defaults?: {
 queue?: {
 debounceMs?: number;
 };
 };
 reload?: { configPrefixes: string[]; noopPrefixes?: string[] };
 setupWizard?: ChannelPluginSetupWizard;
 config: ChannelConfigAdapter<ResolvedAccount>;
 configSchema?: ChannelConfigSchema;
 setup?: ChannelSetupAdapter;
 pairing?: ChannelPairingAdapter;
 security?: ChannelSecurityAdapter<ResolvedAccount>;
 groups?: ChannelGroupAdapter;
 mentions?: ChannelMentionAdapter;
 outbound?: ChannelOutboundAdapter;
 status?: ChannelStatusAdapter<ResolvedAccount, Probe, Audit>;
 gatewayMethods?: string[];
 gateway?: ChannelGatewayAdapter<ResolvedAccount>;
 auth?: ChannelAuthAdapter;
 approvalCapability?: ChannelApprovalCapability;
 elevated?: ChannelElevatedAdapter;
 commands?: ChannelCommandAdapter;
 lifecycle?: ChannelLifecycleAdapter;
 secrets?: ChannelSecretsAdapter;
 allowlist?: ChannelAllowlistAdapter;
 doctor?: ChannelDoctorAdapter;
 bindings?: ChannelConfiguredBindingProvider;
 conversationBindings?: ChannelConversationBindingSupport;
 streaming?: ChannelStreamingAdapter;
 threading?: ChannelThreadingAdapter;
 messaging?: ChannelMessagingAdapter;
 agentPrompt?: ChannelAgentPromptAdapter;
 directory?: ChannelDirectoryAdapter;
 resolver?: ChannelResolverAdapter;
 actions?: ChannelMessageActionAdapter;
 heartbeat?: ChannelHeartbeatAdapter;
 agentTools?: ChannelAgentToolFactory | ChannelAgentTool[];
};

这个接口一共有 40 多个可选的 adapter，每个对应一种能力：

OpenClaw 源码导读（二）：Gateway 控制平面 — 一条 WebSocket 连上所有人

Sat, 02 May 2026 22:32:27 +0800

在系列第一篇里我们看到，OpenClaw 的核心隐喻是 “Gateway 是控制平面”。它不存转储消息、不排队、不持久化事件流，而是一个长在 127.0.0.1:18789 上的状态化 RPC 服务器，所有客户端（CLI、macOS.app、iOS/Android Node、WebChat 浏览器、Canvas iframe）都靠一条 WebSocket 接入。

这一篇拆开控制平面的五个层面：

进程入口：CLI 怎么从 openclaw gateway 走到 Node 进程常驻

WebSocket 协议：握手帧、RPC 帧、Event 帧、状态快照与版本号

鉴权矩阵：Token / Password / Device Token / Bootstrap Token / Tailscale Whois / Trusted Proxy

Pairing：陌生客户端怎么合法加入（setup code、pairing store、allowFrom）

Session 模型：Session Key 组成规则、多 Agent 路由、Session ID 模糊匹配

注：下文所有 src/ 路径都指 openclaw/openclaw 仓库根下。

一、CLI 到 Gateway 的六段路径

第一篇概览过 src/entry.ts 和 src/cli/run-main.ts，这里按调用序重新画一遍，把每个关键函数在 graph 上标出来：

flowchart TD
A0["openclaw gateway --port 18789"] --> A1
A1["entry.ts
main guard + process.title"] --> A2
A2["normalizeEnv + enableCompileCache()"] --> A3
A3["ensureCliRespawnReady()
按需 spawn 子 Node"] --> A4
A4["parseCliContainerArgs
parseCliProfileArgs"] --> A5
A5["tryHandleRootVersionFastPath
tryHandleRootHelpFastPath"] -->|miss| A6
A6["runMainOrRootHelp → runCli(argv)"] --> B0
B0["run-main.ts
container? container in progress"] --> B1
B1["loadCliDotEnv (~/.openclaw/.env)"] --> B2
B2["assertSupportedRuntime (Node≥22.16)"] --> B3
B3["tryRouteCli（fast-path 子命令路由）"] -->|miss| B4
B4["buildProgram() + commander 注册"] --> B5
B5["installUnhandledRejectionHandler"] --> B6
B6["registerPluginCliCommandsFromValidatedConfig (lazy)"] --> B7
B7["program.parseAsync"] --> C0
C0["gateway 命令匹配 → gatewayCommandAction"] --> C1
C1["lock 文件 + 端口 acquire"] --> C2
C2["HTTP/WS server 启动"] --> C3
C3["channels/plugins/cron/canvas-host 启动"] --> C4["Ready"]

1. 为什么要自己 `spawn` 自己

ensureCliRespawnReady() 是 src/entry.ts 里最容易被忽视但非常重要的段落：

OpenClaw 源码导读（一）：架构总览 — 为"单个主人"而设计的 AI Gateway

Sat, 02 May 2026 22:32:27 +0800

2025 年 11 月，Peter Steinberger（PSPDFKit 创始人、前著名 iOS 社区人物）把自己折腾出来的个人 AI 助手 Molty 开源为 OpenClaw。短短几个月，仓库吃到 35 万+ star、93 个 release、360 多个 contributor，核心代码量在 TypeScript/Swift/Kotlin/Go/Python 之间横跨 40 多万行。它和 Claude Code、Codex CLI 乍看都是"跑在本地的 CLI Agent"，但设计哲学完全不同——Claude Code 是一个编程助手，OpenClaw 是一个长在你设备上的私人秘书：它挂在 WhatsApp/Telegram/iMessage/微信的 IM 客户端后面，能自己发消息、自己开浏览器、自己调用 iOS/Android 上的摄像头和麦克风。

本文是 OpenClaw 源码导读系列的第一篇，目标是把整个项目的"地图"摊开。先讲清楚它要解决什么问题、在怎样的信任模型下运行，再把仓库 100 多个顶层模块拎出来分类，最后给出后续系列文章的导航。

一、它到底是什么

1. 一句话定义

OpenClaw 官方给自己的定位是 “Personal AI Assistant. Any OS. Any Platform. The lobster way.” 翻译过来就是：一个在你自己设备上运行、从你自己现有的聊天工具里和你对话的个人 AI 助手。

这个定位里藏着三个关键差异：

Personal：它不是多租户 SaaS，也不是团队协作工具，而是单一主人的私人助手。整个信任模型就是为"只有一个 operator"优化的。
Any OS / Any Platform：Gateway 是 Node 进程，可以跑在 macOS/Linux/Windows(WSL2)、甚至 Fly.io/Docker/NAS 上；客户端包含 iOS/Android/macOS 原生 App，还有 Web Dashboard。
The lobster way：作者把它拟人化成一只太空龙虾 Molty，这是一个品牌/吉祥物层面的设计，但也反映了项目的"玩心"。

2. 和 Claude Code 对比：两个相似却完全不同的 CLI Agent

由于作者 Steipete 本身是 Claude Code 的重度用户和 Anthropic 的合作者，社区最常问的问题就是"和 Claude Code 有啥区别"。这里先画一张对比表：

AITools

Wed, 03 Jun 2026 09:03:11 +0800

Function Calling

2.1 要解决的问题

传统聊天大模型只会说话，没有工具调用能力，这使得大模型：

无法感知环境：无法与外部数据源交互，如通过 API 查询网页、查看用户本地文件、访问远程数据库等等
无法改变环境：无法帮用户实际执行任务，如跑代码、发邮件、上传作业等

2.2 如何解决问题

后端 + LLM 传统方案

工作流程

存在的问题

是否调用工具、调用什么工具由后端负责判断，逻辑复杂且容易误判。 AI 这么智能，为什么不让它来帮我判断？
调用工具的参数由后端负责构建，难度很大。 AI 这么智能，为什么不让它来帮我生成参数？

广义的 Function Calling 是指让大模型能够调用外部工具的一种技术实现：先向大模型提供可用函数的列表及说明，由大模型在对话过程中智能判断是否需要调用函数，并自动生成调用所需的参数，最终用文字返回符合约定格式的函数调用请求。

狭义的 Function Calling 特指大模型提供商在模型内部与 API 层面做了支持的一种能力，它最早由 OpenAI 引入：

在模型层面：模型提供商需对大模型进行特别优化，使其具备根据上下文正确选择合适函数、生成有效参数的能力（比如有监督微调、强化学习）。
在 API 层面：模型提供商需额外开放对 Function Calling 的支持（比如 GPT API 中提供了一个 functions 参数）。

Function Calling 方案

基于提示词的 Function Calling

工作流程

System Prompt 示例

System Prompt 示例
# 你的角色
你是一个函数调用助手，我将提供多个函数的定义信息，包括函数名称、作用、参数及参数类型。

# 你的任务
- 根据用户的输入，判断是否需要调用某个函数
- 如果需要，请**严格按照以下格式**输出函数调用指令：
json
{ "name": "函数名", "arguments": { "参数名": "参数值" } }

# 函数定义信息
1. **get_weather**
 - 作用：查询指定城市的天气情况
 - 参数：
 -`city`（string）：城市名称
2. **get_time**
 - 作用：查询指定城市的当前时间
 - 参数：
 - `city`（string）：城市名称

存在的问题

输出格式不稳定。如调用指令中存在多余自然语言。
容易出现幻觉。模型可能编造并不存在的函数名或参数。大模型提供商能否对模型进行微调、强化学习，提升大模型在这一方面的能力？
对开发者依赖度高。函数描述、调用指令格式、提示词逻辑完全由开发者设计。函数描述、调用指令格式能否由大模型提供商来指定？系统提示词中的"说明与规则"逻辑能否由大模型提供商来兜底？
上下文冗长，Token 消耗大。为确保调用逻辑正确，往往需要在 system prompt 中加入大量说明与规则。

AI on Last Stand

AI Agent

一、从聊天机器人到智能体

1.1 纯LLM的局限

1.2 Agent的定义

二、Agent的核心组件

2.1 架构总览

2.2 LLM：Agent的大脑

AI编程工具

一、AI编程工具的演进

1.1 三代AI编程工具

1.2 当前主流工具对比

二、AI编程工具的工作原理

2.1 代码补全的原理

Claude Code 源码导读：Agent 设计详解

一、核心源码地图

FoundationModels

一、FoundationModels是什么

1.1 一句话定义

1.2 能做什么 / 不能做什么

1.3 为什么值得iOS开发者关注

二、整体架构

Function Calling与MCP

一、Function Calling：LLM原生的工具调用

1.1 基本原理

1.2 函数定义

Harness Engineering 精读笔记

一、什么是 Harness Engineering？

1.1 Harness 的定义

LLM Wiki：Karpathy 提出的"后 RAG 时代"个人知识库范式

一、问题起点：RAG 的"每次从零开始”

1.1 RAG 的根本局限：没有累积

1.2 LLM Wiki 的核心差异

Prompt Engineering

一、Prompt的基本构成

1.1 一个Prompt的解剖

1.2 System Prompt vs User Prompt

二、核心Prompt技术

2.1 Zero-Shot Prompting

RAG（检索增强生成）

一、RAG的核心思想

1.1 一个直觉的类比

1.2 RAG的核心价值

1.3 RAG的基本流程

二、从关键词到语义：检索方式的演进

2.1 传统关键词搜索的局限

2.2 文本嵌入（Text Embedding）

Transformer架构原理

一、从序列到序列：Transformer要解决什么问题

1.1 语言的本质是序列

1.2 RNN的困境

二、词嵌入：给词语一个数学身份

2.1 从独热编码到词向量

iOS中AI Chat实战

一、整体架构

反向传播算法

一、梯度下降：从直觉开始

1.1 一个简单的类比

1.2 数学表述

1.3 学习率的微妙之处

1.4 梯度下降的关键问题

神经网络原理

一、从像素到数字：问题的本质

1.1 手写数字识别

1.2 为什么传统编程行不通

二、神经网络的结构

2.1 神经元：最基本的单元

2.2 层：神经元的组织方式

OpenClaw 源码导读（三）：Agent Harness — 为"每一家 LLM 都能兜住"而生的执行管线

一、Harness 抽象：只有一个 runAttempt

1. 为什么不用 LangChain 风格的"Agent Framework"

OpenClaw 源码导读（四）：Channels、Nodes 与扩展生态

一、Channels：118 个 extension 是怎么"插"进来的

1. ChannelPlugin 接口

OpenClaw 源码导读（二）：Gateway 控制平面 — 一条 WebSocket 连上所有人

一、CLI 到 Gateway 的六段路径

1. 为什么要自己 spawn 自己

OpenClaw 源码导读（一）：架构总览 — 为"单个主人"而设计的 AI Gateway

一、它到底是什么

1. 一句话定义

一、Harness 抽象：只有一个 `runAttempt`

1. 为什么要自己 `spawn` 自己