本笔记基于费曼学习法对话整理，从 JSON Schema 出发，逐层拆解到 Agent Loop 的工程本质。

一、整体认知链路

二、核心概念：LLM 只是 Token Generator

关键认知（必须刻进 DNA）

LLM 本质上只是一个 token generator，它能做的只有"吐字"。它没有网络访问、没有文件系统、没有执行环境。

由此推出的工程结论

1. 模型可以 hallucinate 不存在的工具名 —— Runtime 必须做合法性校验。

2. 模型不知道执行成功还是失败 —— 它对世界的认知完全来自下一轮塞给它的 tool_result。

3. 模型不知道时间过去了多久 —— tool 跑了 30 秒还是 30 毫秒，对它没区别。

4. "Function Calling 能力"训练的本质 —— fine-tune 模型让它在合适时机输出符合 schema 的 JSON。

Anthropic 官方用 "tool use" 这个词，比 "function calling" 中性，没暗示"模型在调用"。OpenAI 起的 "function calling" 这个名字带偏了一代开发者的心智模型。

三、JSON Schema 的角色

给谁看 + 干什么

在哪个阶段起作用

Schema 能解决什么，不能解决什么

Schema 只管类型 / 结构 / 必填字段这种"语法层"的事，管不了"语义对不对"。语义对错本质上靠模型自己的理解能力 + description 写得好不好。

四、Self-Correction 机制

反馈闭环

关键认知

模型本身没有任何"自我纠错"的内在动力，所谓 self-correction 完全是 runtime 编排出来的幻觉。

• 模型生成错误的那一刻，它不觉得自己错了（只是 next token prediction）

• Runtime 不"主动通知"模型 —— 而是被动地准备好材料，等下一次模型推理时被读到

• LLM 是 pull-based / stateless 的，每次 inference 都是冷启动

Self-correction 可行性判据（核心公式）

可纠正 = ∃ 某一层 L，使得 L 能识别错误 ∧ L 能产生错误反馈 ∧ 反馈能进 contextsilent failure = 上述条件都不成立

错误分类示例

对抗 Silent Failure 的手段

工程结论：如果想让 Agent 对某类错误"自动纠错"，工作不是教模型"更聪明"，而是想办法在链路里植入一层能产生错误信号的 "L"。

五、Training vs Inference

核心对比

类比

Training = 学生在上学，做错题大脑神经连接会重塑（参数更新） Inference = 学生毕业进考场，大脑被锁死，无论答得对错神经连接一动不动

"冷启动"的真正含义

三个工程事实

1. Memory 系统的本质：模型参数永远不变，所有"记忆"都是 runtime 在每次 inference 前临时拼装的 context。
• In-context memory：完整塞入对话历史
• Summarization memory：用 LLM call 压缩历史
• Retrieval-based memory（RAG）：vector DB 检索 + 拼进 prompt

2. Fine-tuning 属于 Training：fine-tuning 是"再训练"，发生在部署之前，产出新 weights。一旦上线，weights 又冻结。

90% 的"让模型更好"的需求都不需要 fine-tuning，而是靠 prompt engineering + tool design + context engineering 解决。

3. Temperature 控制采样随机性：

Temperature	行为
T = 0	永远选概率最高的（greedy decoding）
T = 0.7（默认）	按概率采样，偏向高分
T = 1.5	分布被"压平"，低分 token 也有机会

Agent 工程里，对精度敏感的任务通常 T=0（tool_call、结构化输出），创意任务才用高 T。

六、Runtime 是什么

关键认知（破除翻译陷阱）

"运行时"这个中文翻译害了一代人。Runtime 在工程语境里指的是「执行者」，不是「时间段」，也不是「动作集合」。

精确定义

Agent Runtime = 你（开发者）自己写的、负责编排整个 Agent 工作流的那段程序。

1. "你自己写的" —— Runtime 不是 LLM 自带的，是你作为工程师亲手写的代码

2. "编排" —— 它的核心动作是"指挥"，告诉每一步该干什么

3. "程序" —— 它是一段实实在在的代码，不是抽象概念

Runtime vs LLM 的分工

破除"Agent 很聪明"的幻觉

LLM 那一侧只会做一件事：text in → text out 其他所有"智能"行为，全是 Runtime 在后台编排出来的：

• "会调工具" → 是 Runtime 解析 tool_call 然后真去调的

• "会循环" → 是 Runtime 写了个 while 循环

• "会纠错" → 是 Runtime 把错误信号塞回 context

• "有记忆" → 是 Runtime 在每轮请求前重新拼装历史

七、Agent Loop 完整骨架

标准流程（订机票场景）

循环结构（ReAct 的工程实现）

这个循环结构就是 ReAct (Reasoning + Acting) 的工程实现。Hermes-agent、Cursor、Claude Code、LangGraph，全是这个骨架的工业级变种。

八、System Prompt vs Tool Schema（重要区分）

关键直觉的修正

两种写法对比

为什么必须分两个通道？

Anthropic/OpenAI 后端会按官方训练时见过的格式把 schema 拼进 prompt。这个格式经过 fine-tune，模型对它极度熟悉。

• 写法 A：模型返回一段 text，里面"藏着"JSON，你得自己挖

• 写法 B：模型在专门的 tool_use 字段输出结构化对象，Runtime 直接用

用写法 B，厂商保证 tool_use 字段里的 JSON 是合法的（合 schema 的）。用写法 A，全凭模型当时心情。

对比表

类比

想象你给秘书发指令：

• System Prompt = 说明信："你是我的秘书，请专业、礼貌"

• Tool Schema = 操作手册："打印机用法、订餐流程、报销表格在哪"

• User Message = 具体请求："帮我订明天的午餐"

这三样都是纸，但秘书拿到时分门别类放在不同抽屉，处理方式完全不同。

九、关键认知速查（要背的几句）

1. LLM 只是 token generator —— 它从来没有真的"调用"过任何函数。

2. Function Calling 是整套机制的名字，不是其中某一步。它包括：声明阶段、输出阶段、执行阶段（Runtime 阶段）。

3. LLM 是无状态的（stateless） —— 每次 inference 都是冷启动。所谓"记忆"全是 Runtime 制造的幻觉。

4. Self-correction 依赖"错误信号能进 context" —— 不能产生信号的错误就是 silent failure。

5. Runtime 是"执行者"，不是"时间段" —— 它是你写的那段编排代码。

6. Agent 的"智能"是 LLM + Runtime 的合奏 —— 单独把模型拎出来，它什么也做不了。

7. Tool Schema 走独立的 tools 字段 —— 不要自己拼到 system prompt 里。

十、待深入的话题（后续讨论）