Agent 原理、记忆与上下文工程
如果把 Claude Code、OpenClaw、Codex 这些工具拆开看，底层其实都在回答同一组问题：agent loop 怎么跑、记忆怎么存、上下文怎么压、Harness 怎么兜底。新增资料把这一层讲得比之前清楚得多，同时从 Loop 工程精细化、任务原子化、状态机基础设施、数学优化等新维度扩展了 Agent 系统的底层理解。 [[raw/2026-04-28/侑夕/你不知道的 Agent：原理、架构与工程实践.md|来源: 你不知道的 Agent：原理、架构与工程实践.md]] [[raw/2026-04-27/小傅哥/《从零理解智能体（+八股）》第1篇，认识智能体，从过去到现在.md|来源: 《从零理解智能体（+八股）》第1篇，认识智能体，从过去到现在.md]]
Agent loop 是共识起点
- Agent 不只是”多轮对话”，而是围绕目标、工具调用、观察反馈、循环推进展开的执行体。理解这点，才能明白为什么子 agent、记忆、harness 都是必要件。 [[raw/2026-04-28/侑夕/你不知道的 Agent：原理、架构与工程实践.md|来源: 你不知道的 Agent：原理、架构与工程实践.md]] [[raw/2026-04-27/小傅哥/《从零理解智能体（+八股）》第1篇，认识智能体，从过去到现在.md|来源: 《从零理解智能体（+八股）》第1篇，认识智能体，从过去到现在.md]]
Agent Loop 五阶段模型 (2026-06 新增)
AllenTang 将 Agent Loop 精确定义为五个阶段的内部循环：Perceive → Reason → Plan → Act → Observe。区别于”思考-行动-观察”的粗略划分，五阶段模型明确把 Plan 从 Reason 中分离出来——Reason 是分析现状，Plan 是制定行动序列。每个完整的 loop 周期结束后，模型根据 Observe 阶段的反馈决定继续下一轮循环还是停止。 [[raw/2026-06-20/AllenTang/一文搞懂Loop工程、Harness工程、FDE——Agentic Engineering的三个层次.md|来源: Loop五阶段]]
停止条件是 Agent 最被忽视的工程问题：停太早（任务没完成）、停不下来（无限循环）、停在错误的地方（偏航后继续执行）。生产级 Agent 必须将停止条件作为一等工程约束，而非依赖模型的”感觉差不多”。这与基咯咯的”stop_reason 必须是结构化的”判断一致。 [[raw/2026-06-20/AllenTang/一文搞懂Loop工程、Harness工程、FDE——Agentic Engineering的三个层次.md|来源: 停止条件]]
Harness vs Loop 的分工边界：Loop 管推理→工具→观察→再推理的内部循环；Harness 管外部的生命周期——循环开始前的上下文/工具准备、中途的验证/预算监控、结束后的状态持久化、出错时的重试/熔断。Agent = Model + Harness；仅改 Harness 不改模型可实现 10 倍性能提升。 [[raw/2026-06-20/AllenTang/一文搞懂Loop工程、Harness工程、FDE——Agentic Engineering的三个层次.md|来源: Harness vs Loop]]
FDE（Forward Deployed Engineer） 是同时具备 Loop 工程 + Harness 工程 + Eval 工程 + 业务判断能力的角色。这不是一个技术头衔，而是一种融合了工程、评估和业务洞察的新型岗位能力要求，与飞樰”通过工程化手段构建确定性”的方法论互补。 [[raw/2026-06-20/AllenTang/一文搞懂Loop工程、Harness工程、FDE——Agentic Engineering的三个层次.md|来源: FDE定义]]
案例：Karpathy AutoResearch——630 行 Python，21K stars，是 Loop+Harness 设计的干净案例。Harness 层负责搜索查询混合策略、退火阈值、去重逻辑等确定性策略，Loop 层负责推理→工具→再推理的弹性循环。 [[raw/2026-06-20/AllenTang/一文搞懂Loop工程、Harness工程、FDE——Agentic Engineering的三个层次.md|来源: AutoResearch]]
17种Agent架构演进（来自 腾讯技术工程）
- 本质是”控制流设计史”：Reflection→Tool Use→ReAct→Planning→PEV→Multi-Agent→Blackboard→记忆系统→搜索/模拟/涌现→安全边界
- agno框架四个核心抽象：Agent、Workflow、Router、Loop
- 终极判断：真正高级的agent不是更敢做事，而是更知道什么时候不该做
- Evaluator不是附属品而是核心，“没有evaluator的agent大概率只是会循环的prompt”
- 来源：[[raw/2026-05-18/腾讯技术工程/从0开发大模型的17种Agent架构演进详细拆解.md|来源: 17种Agent架构]]
LangGraph：Agent 即状态机 (2026-06 新增)
LangGraph 将 LLM 调用从线性链转换为状态机，是理解 Agent 执行引擎底层机制的关键。核心三个抽象：State（数据快照）、Node（执行动作）、Edge（下一个节点的路由规则）。[[raw/2026-06-20/Jameszyh/LangGraph底层原理：它是怎么把LLM变成一台状态机的.md|来源: LangGraph状态机]]
Reducer 机制是关键创新：节点不返回完整新状态，而是返回部分状态更新。Reducer 将旧状态与更新合并，State 始终不可变（从而支持 checkpoint 机制）。调度器是一个事件循环：执行 node → 应用 reducer → 检查 edges（条件或普通路由）→ 入队下一个 node。条件 Edge 是实现 ReAct 模式的基石——LLM 决定是调用工具还是直接响应。 [[raw/2026-06-20/Jameszyh/LangGraph底层原理：它是怎么把LLM变成一台状态机的.md|来源: Reducer与调度]]
编译（compile()） 验证图结构完整性、预计算邻接表、初始化通道，返回包含 invoke/stream/getState 接口的 CompiledGraph。stream() 按节点粒度产出结果，支持实时 UI。Fan-out/Fan-in 支持并行执行：多条出边触发并发节点，merge 节点等待所有前驱完成后合并。 [[raw/2026-06-20/Jameszyh/LangGraph底层原理：它是怎么把LLM变成一台状态机的.md|来源: 编译与并行]]
Agent 系统的状态机映射：State = LLM 上下文 + 中间产出，Node = LLM 调用或工具执行，Edge = 条件路由（LLM 决定下一步或确定性逻辑分发）。这套映射将 Agent 执行流从”黑盒推理”变为可调试、可 checkpoint、可流式的工程结构——与 HuggingFace 术语表中 Harness/Scaffolding 的区分互补：LangGraph 是 Harness 层的具体实现框架，定义了”让 Agent 跑起来”的底层执行机制。 [[raw/2026-06-20/Jameszyh/LangGraph底层原理：它是怎么把LLM变成一台状态机的.md|来源: 系统映射]]
Agent 技术范式的四阶段演化
飞樰从时间维度梳理了 Agent 核心技术概念的四阶段演进，与上述 17 种架构的”控制流”视角互补——一个讲”怎么演化”，一个讲”怎么设计”： [[raw/2026-05-22/飞樰/Agent核心技术概念与范式发生了哪些演变以及背后的思考.md|来源: 飞樰 - Agent 范式演变]]
| 阶段 | 时间 | 特征 | 核心局限 |
|---|---|---|---|
| 被动式 ReAct | 2023 | 思考-行动-观察循环，单轮推理 | 无长期目标，容易循环退化 |
| 工作流 Agent | 2024 | 预定义流程编排，多步骤串联 | 刚性，无法应对意外情况 |
| 自主 Agent | 2025 | 目标驱动，自主拆解+动态路由 | 可靠性不足，需要大量护栏 |
| 自进化 Agent | 2026 | 从执行反馈中自动优化自身行为与知识 | 仍在早期，需要靶子机制和人工监督 |
六大模块的范式级演化
| 模块 | 旧范式 | 新范式 |
|---|---|---|
| Prompt | 深耦合单体，所有指令塞一起 | 渐进式加载，按需分层注入 |
| Planning | 线性 CoT 逐步推理 | 结构化分解 + 子 Agent 动态构建 |
| Memory | 纯向量检索，embedding 搜一切 | 文件系统化 + 向量混合，热/冷分层 |
| Tools | Function Call JSON Schema | CLI 原生化 + Script，节省巨额 token |
| Workflow | 刚性 DAG 编排 | Skill 为主 + Workflow 兜底 |
| Environment | 无状态，每次重建 | 隔离 Runtime，持久化状态复用 |
核心方法论与 CLI 定位
飞樰的核心方法论与 Harness Engineering 的共识完全一致：“通过工程化手段构建确定性，以承载模型不确定性。”
关于 CLI 作为 Agent 时代”天然工具”的判断：Linux 命令在预训练语料中出现了几十亿条，Agent 对其理解是”先天知识”而非”后天学习”。对人类不友好（需要记忆大量参数和管道语法）但对 Agent 是最高效的交互方式——节省巨大的 token 和调试成本。这与来新璐”Bash is all you need”的观点一致。 [[raw/2026-05-22/飞樰/Agent核心技术概念与范式发生了哪些演变以及背后的思考.md|来源: 飞樰 - Agent 范式演变]]
记忆、压缩与生命周期治理
Agent 记忆不只是“多存点历史”，而是工作记忆、会话记忆、长期事实、结构化压缩、checkpoint 和运行协议共同组成的生命周期治理问题。相关内容已拆到 [[wiki/concepts/Agent 记忆、压缩与生命周期治理]]，本页只保留 Agent 原理总览和跨主题入口。
Harness 是把能力变成系统的那层壳
- 白家杰把 AI 编程划成 Prompt、Context、Harness 三个时代，核心判断是：只有把多 agent 协作、回归验证、流程控制沉到 harness 里，系统才会稳定。 [[raw/2026-04-28/白家杰/Harness Engineering实践心得：如何高效驾驭AI？.md|来源: Harness Engineering实践心得：如何高效驾驭AI？.md]]
- 张碧泉的上下文隔离子智能体、凤聆的评测平台，以及李泽宇的长时项目实践，都在给这层判断补证据。 [[raw/2026-04-29/张碧泉/深入浅出Harness Engineerring之核心模式与理念.md|来源: 深入浅出Harness Engineerring之核心模式与理念.md]] [[raw/2026-04-29/凤聆/Harness Engineering实践，做了一个平台让AI一晚上自动评测和优化你的系统.md|来源: Harness Engineering实践，做了一个平台让AI一晚上自动评测和优化你的系统.md]] [[raw/2026-04-29/李泽宇的AI实验室/300 亿 Token，30 万行代码，30万字烧出来的Harness实践，我开源了.md|来源: 300 亿 Token，30 万行代码，30万字烧出来的Harness实践，我开源了.md]]
Agent 的四种失败模式
- Anthropic 归纳 agent 最常见的四类失败：One-shot Syndrome（一次生成就想完工，不迭代）、Premature Victory Declaration（过早宣布成功，实际没验证）、Premature Feature Completion（过早认为功能完成，缺边界处理）、Cold Start Problem（新会话无历史上下文，表现大幅下降）。根因一针见血：“Agents 无法准确评估自己的产出质量。” [[raw/2026-05-07/新安/Harness Engineering：耗时一周，我是如何将应用的AI Coding率提升至90%的.md|来源: 新安 四种失败模式]]
AI 的经验缺失与判断边界 (2026-06 新增)
云舒的实践总结提出了一个根本性区分：逻辑上可行 vs 现实中能走。AI 缺乏”搬过家所以知道要提前收拾”式的具身经验——它拥有的是”人类的各种合集”，逻辑可行的路线和现实中能走的路线可能完全无关。AI 可以给出无数个选项，但无法判断哪个是对的。 [[raw/2026-06-17/云舒的AI实践笔记/AI 用的越多，越觉得人的判断重要.md|来源: AI经验缺失]]
编码任务的分界线
- 可全自动化托管：需求复杂度不高的简单编码任务（如加 Token 消耗统计、定时任务）
- 必须人类先决策：架构设计、高吞吐量数据库设计、提示词设计、高并发场景——AI 可以提供方案选项，但人必须基于真实经验做选择
写作场景的局限
公众号写作无法全自动化的根因不在于上下文不足，而在于选题依赖个人真实经历和阶段性思考。AI 无法通过外部语料补充”经验”，也无法生成由亲身经历驱动的选题判断。最佳角色是润色和标题参考，不能替代人类的选题能力。 [[raw/2026-06-17/云舒的AI实践笔记/AI 用的越多，越觉得人的判断重要.md|来源: 写作局限]]
矛盾：通过充分的上文工程和任务拆解，Agent 可以完成大部分编码任务 vs 云舒认为复杂架构设计和高吞吐量数据库设计必须人先想清楚，“AI 没有真正的经验”是根本原因。同样，AI 生成内容的瓶颈是否在于上下文不足也存在分歧——补充足够上下文即可 vs 根本原因不在上下文不足，而在于 AI 没有真实的个人经验。 [[raw/2026-06-17/云舒的AI实践笔记/AI 用的越多，越觉得人的判断重要.md]]
7条生产原则（来自 基咯咯）
- Agent vs 聊天机器人：Agent不是一问一答，而是持续推进的循环(输入→判断→调工具→观察→再判断→继续或结束)
- stop_reason必须是结构化的，不能靠自然语言——“看起来像结束了”是最大假象
- 7原则：定义目标→工具少且边界硬→错误处理是主流程→权限程序级gate→复杂任务拆分→坏输入测试→全链路可观测
- 来源：[[raw/2026-05-16/基咯咯/如何构建真正能上线的 AI Agent：7 条生产原则.md|来源: 7条生产原则]]
任务原子化：上下文预算的一等工程约束 (2026-06 新增)
Jameszyh 提出 LLM 上下文的三个固有矛盾驱动了任务原子化的必要性：广度 vs 深度（上下文窗口有限，塞的内容越多每个主题的注意力越稀）、长任务 vs 注意力衰减（长上下文中间区域被模型遗忘）、并行 vs 串行（不拆分就只能串行，效率受限于推理延迟）。这些是 AI 编程质量退化的根本原因——不是模型能力不够，而是上下文管理方式不对。 [[raw/2026-06-20/Jameszyh/核心原理（三）：任务原子化为可独立执行的单元.md|来源: 任务原子化]]
三条核心标准
- 上下文占用 < 50%：30% 留给推理，20% 留给输出生成。超过 50% 意味着上下文窗口被过度占用，后续步骤没有可用空间。
- 显式依赖封闭：任务的输入（文件、知识）必须完全可知，不隐含”模型应该知道”的假设。
- 二值完成标准：完成条件必须是可直接验证的真/假判断，不能是”看起来完成了”。
四大反模式
- 伪原子任务：表面拆了但运行时依赖仍在（共享全局知识不检索，靠模型推理上下文补齐）
- 上下文不隔离：子任务之间上下文互相污染
- 并行无共识源：多个子 Agent 并行执行但结果无法合并——因为没有统一的 truth source（唯一代码仓库、唯一 commit 记录）
- 忽略任务依赖：B 依赖 A 的输出但先跑了 B，错误的前提导入错误的结果
微服务同构类比
任务原子化与微服务架构存在结构性同构：任务边界 = 服务边界，API = 文件系统（FUSE 挂载），任务调度 = K8s 编排，上下文隔离 = 容器隔离，依赖管理 = 服务编排。这套类比将 AI 编程从”单核”转换为”多核”，理论上可实现线性扩展。 [[raw/2026-06-20/Jameszyh/核心原理（三）：任务原子化为可独立执行的单元.md|来源: 微服务同构]]
SDD 框架的原子化批评
矛盾：SDD frameworks（OpenSpec、Spec-Kit）提供了完整的 Harness 覆盖用于任务分解和执行 vs Jameszyh 认为这些框架的原子化存在根本弱点——它们聚焦于 spec 结构优化，但缺乏执行隔离和上下文预算管理，不结合上下文工程框架（如 GSD）是不完整的。[[raw/2026-06-20/Jameszyh/核心原理（三）：任务原子化为可独立执行的单元.md|来源: SDD批评]]
Agent 时代的生产力悖论
- “当协作本身成为最大的瓶颈”——Agent 生产力的真正瓶颈不在 agent 能力，而在于组织结构仍沿用工业时代的分工模式。解法：All-In-Code + 版本一切 + agent 作为一等公民（agent-as-citizen），从组织设计上适配 agent 时代。 [[raw/2026-05-08/向邦宇/Agent 时代的生产力悖论：当协作本身成为最大的瓶颈.md|来源: 向邦宇 生产力悖论]]
Codex 进 Chrome
- Codex 现已能操作 Chrome 浏览器，且保留登录态。这意味着 agent 可以直接操控需要身份认证的 Web 服务，不再局限于无状态网页抓取。 [[raw/2026-05-08/AI兴观点/Codex 杀进 Chrome：操作你的浏览器，登录态可用.md|来源: Codex Chrome]]
Agent 术语统一参考：HuggingFace 官方术语表（2026-06 新增）
HuggingFace 发布了 AI Agent 官方术语表，为长期术语混乱的领域提供了权威定义。这份术语表的核心贡献是将 Agent 系统拆解为三层明确分工： Model（模型）→ Scaffolding（脚手架）→ Harness（执行框架）——并澄清了几个最容易被混淆的概念：
Model vs Agent：模型是”文本进文本出”，两次调用之间无记忆、无循环。模型可以表达”我想调用某个工具”的意图，但真正执行需要 harness。模型 + scaffolding + harness = Agent。[[raw/2026-06-01/ChallengeHub/HuggingFace 发了份 AI Agent 词汇表，专治术语混乱.md|来源: HuggingFace 术语表]]
Scaffolding vs Harness（最容易混淆的一对）：
- Scaffolding：围绕模型定义行为的那一层——系统提示词、工具说明、输出解析方式、多步骤间的上下文管理。它塑造了模型如何看待世界、如何在其中行动。
- Harness：Agent 内部的执行层——调用模型、处理工具调用、决定何时停下。Harness 是”让 Agent 跑起来的东西”，scaffolding 是”模型据以工作的依据”。
- Claude Code 自家文档说”Claude Code 充当的是围绕 Claude 的 Agent harness”——这是宽泛用法，指代除了模型之外的一切。区分两者在训练流水线中最关键。[[raw/2026-06-01/ChallengeHub/HuggingFace 发了份 AI Agent 词汇表，专治术语混乱.md|来源: HuggingFace Scaffolding vs Harness]]
Key Terms 精确定义：
- Context Engineering：设计往 Agent 上下文窗口里塞什么——系统提示词、工具说明、对话历史、检索来的知识。训练时搞错要重新训练，推理时搞错改个提示词就行。
- Policy：Agent 在给定情境下采取每个可能动作的概率。一部分被学进模型权重，一部分由 scaffolding 和 harness 决定。策略 ≠ Agent——策略定义行为，Agent 是采取行动的完整系统。
- Tool Use：Agent 伸手够到自身之外的方式（API、代码解释器、数据库等）。模型以结构化格式表达”我要用这个工具”的意图，harness 路由到对应函数。
- Skill：可复用、结构化的知识包，让多步骤任务得以完成。与 tool 的区别：一个 tool 是”一个动作”，一个 skill 打包的是”达成某个目标所需的全部东西”。
- Sub-agent：由另一个 Agent 调用的独立 Agent，有自己的模型和 scaffold，独立推理后返回结果。与 tool（一次函数调用）或 skill（打包好的知识）的本质区别：sub-agent 自己就能推理、调用工具、甚至再去调用更多 sub-agent。[[raw/2026-06-01/ChallengeHub/HuggingFace 发了份 AI Agent 词汇表，专治术语混乱.md|来源: HuggingFace 术语精确定义]]
RL Training 术语：RL Environment（接收动作返回观察的有状态对象）→ Trainer（跑 episode、打分、更新权重的训练器）→ Rollout（Agent 完整跑一遍的轨迹，RL 算法学习的原始数据）→ Reward（告诉训练算法”模型是不是在变好”的分数：可验证/习得，稀疏/稠密）。Rubrics 将奖励拆成若干带权重的明确维度而非单一数字。
MCP 的定位：MCP 是一套标准化协议，“让 Tool Use 到 Harness 之间的连接变得更干净、更具互操作性。” 术语表讲的是 Agent 们”做什么”，MCP 讲的是它们如何跨厂商可靠地把工具调用”做好”。 [[raw/2026-06-01/ChallengeHub/HuggingFace 发了份 AI Agent 词汇表，专治术语混乱.md|来源: HuggingFace MCP定位]]
这份术语表能作为本 wiki 中 Agent 相关术语的权威引用基准。与现有内容对比：Scaffolding vs Harness 的区分填补了此前宽泛混用的缺口；Sub-agent 与 tool/skill 的区别明确了概念边界；RL 训练术语补充了此前缺失的训练侧概念。
Hermes Agent 实践：规则资产化与三层门控 (2026-06 新增)
得物数据仓库团队基于 Hermes Agent 构建的 AI 工程实践，提供了两个 wiki 中此前未覆盖的关键机制——规则资产化和三层生产门控。与 jilolo 的 Hermes 四层记忆系统互补（一个讲架构，一个讲治理）。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: Hermes Agent实践]]
规则资产化：基于可复用性的记忆治理
Hermes 的记忆层不仅存储知识，还建立了一套决定”什么值得记住”的决策机制：临时信息留在当前会话、可重复模式沉淀为规则包、治理内容进入长期记忆。当下次相似请求到来时自动触发证据收集和风险提醒。这与此前记忆系统的容量/检索维度不同——规则资产化解决的是记忆系统的写入质量控制：不是”能不能记住”，而是”该不该记住”。这套机制与尼恩的”记忆准入”治理互为印证，但更偏业务语义层面的复用判断。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 规则资产化]]
三层生产门控（HITL 设计）
Hermes 在每个生产操作上设置了三道门：
- 事实来源门（fact source gate）：证据必须可溯源，不能是”模型说的”
- 预演门（rehearsal gate）：系统模拟通过，确认操作结果符合预期
- 责任门（responsibility gate）：人工最终确认——任何一道门未通过就阻止生产写入
这套”三道门”不是事后审计，而是写入路径上的强制检查点。与 AgentTeams 的 L0-L4 权限分级、扶苏的”30 分钟规则”形成互补——都是将 HITL 作为 Agent 系统的头等建筑构件而非事后补丁。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 三层门控]]
单 Agent + 能力模块的刻意选择
Hermes 团队有意选择单 Agent 编排 + 多个能力模块 + 看板确认点的架构，刻意不走多 Agent 集群（swarm）路线。设计考量是数据仓库场景下业务流程的可控性和可审计性优先于并行度，与当前 wiki 中多 Agent 方案的正面论述形成对比。
矛盾：OpenClaw 被定位为多 Agent 编排的主流平台 vs 得物团队选择 Hermes 而非 OpenClaw 的核心理由正是 OpenClaw 缺乏持久记忆——“Close the window and it forgets” 在需要重复历史回溯的数仓场景下不可接受。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: Hermes vs OpenClaw]]
状态机看板工作流
Hermes 将通过看板实现的状态机嵌入工作流：enter → design → rehearsal → review → deliver，每个阶段关联明确的人工责任。结构化工具接口将生产操作（查询、绑定、发布、验证）包装为参数化、可审计、可预览的命令，而非页面级别的交互。 [[raw/2026-06-17/小诘、博温/从埋点需求到规则资产：Hermes Agent 重构得物数仓工作流.md|来源: 看板工作流]]
Claude Code 上下文注入七种机制详解（2026-06 新增）
Anthropic 官方及多个独立来源系统地梳理了 Claude Code 的七种定制机制，从加载时机、压缩行为、权重三个维度揭示了它们的本质差异。这是理解”上下文工程”在 Claude Code 中具象实现的核心框架。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: Anthropic 七种方法]] [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: 金色传说大聪明]] [[raw/2026-06-20/邵猛/驾驭 Claude Code：CLAUDE.md 配置文件、Skills、Hooks、Rules、Subagents 等 7 种指令全解析.md|来源: 邵猛解析]]
七种机制三维对比
| 机制 | 加载时机 | 压缩后行为 | 权重 | 成本 | 最佳场景 |
|---|---|---|---|---|---|
| 根目录 CLAUDE.md | 会话开始，全程保留 | 重新读取，缓存刷新 | 高 | 最高（全程占 token） | 构建命令、编码规范、团队约定 |
| 子目录 CLAUDE.md | 按需，访问该目录时触发 | 丢失，直到再次访问 | 中 | 低 | 特定子目录规范 |
| Rules | 会话开始（无 paths），或匹配 paths 时 | 重新注入 | 中 | 中 | 路径限定的局部约束 |
| Skills | 仅名称+描述启动时加载，调用时加载全文 | 已调用的重新注入，共享预算 FIFO | 低 | 低 | 流程化工作（部署、发布检查） |
| Subagents | 调用时在独立上下文运行 | 仅最终摘要回主会话 | 极低 | 极低 | 隔离/并行任务（深度搜索、日志分析） |
| Hooks | 确定性执行，绕过上下文窗口 | 不受压缩影响 | 最高 | 极低 | 硬约束（自动 lint、危险操作拦截） |
| Output Styles | 直接注入系统提示 | 永不压缩 | 最高 | 低 | 角色定位、输出格式定制 |
[[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: 七种方法一览]] [[raw/2026-06-20/邵猛/驾驭 Claude Code：CLAUDE.md 配置文件、Skills、Hooks、Rules、Subagents 等 7 种指令全解析.md|来源: 邵猛七种指令]]
“提示词说服” vs “代码执行”的根本区分
这是理解 CC 配置体系的关键认识框架。CLAUDE.md、Rules、Skills 走的是”提示词说服”路径——依赖模型理解和遵从，在长会话、模糊情况或遭遇提示词注入时可能失效。Hooks + 权限控制走的是”代码执行”路径——完全绕过上下文窗口，由 harness 在外部确定性执行，不受提示词注入干扰。“告诉 AI 应该怎么做”和”让某件事确定性地发生”是两件本质不同的事。 [[raw/2026-06-20/邵猛/驾驭 Claude Code：CLAUDE.md 配置文件、Skills、Hooks、Rules、Subagents 等 7 种指令全解析.md|来源: 邵猛 总结]]
Hooks 八种事件
Hooks 支持注册在 Claude 生命周期特定事件上确定性执行：PreToolUse、PostToolUse、PermissionRequest、SessionStart、PreCompact、Stop、SubagentStop、UserPromptSubmit。一个 PreToolUse Hook 可以拦截任何工具调用，以 exit code 2 阻止执行——这是实现”永远不要做某事”硬约束的正确方式，而非写在 CLAUDE.md 里。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: Hooks 八种事件]] [[raw/2026-06-20/邵猛/驾驭 Claude Code：CLAUDE.md 配置文件、Skills、Hooks、Rules、Subagents 等 7 种指令全解析.md|来源: 邵猛 Hooks]]
Output Styles 的严重警告
Output Styles 直接注入系统提示且永不压缩，权威性最高。但代价是自定义 Output Style 默认会替换掉 Claude Code 的内置输出风格，包括”如何界定改动范围、何时添加注释、如何处理安全问题、声称完成前是否运行测试”等关键编程默认指令——使 Claude Code 退化为通用助理。官方建议先看内置风格（Proactive/Explanatory/Learning），覆盖大多数需求，无需自行维护文件。 [[raw/2026-06-20/邵猛/驾驭 Claude Code：CLAUDE.md 配置文件、Skills、Hooks、Rules、Subagents 等 7 种指令全解析.md|来源: 邵猛 Output Styles]]
机制选择决策框架共识
多来源独立提炼出一致的决策原则：[[raw/2026-06-20/邵猛/驾驭 Claude Code：CLAUDE.md 配置文件、Skills、Hooks、Rules、Subagents 等 7 种指令全解析.md|来源: 决策原则]] [[raw/2026-06-20/扶苏/Claude Code 深度定制指南：CLAUDE.md、Commands、Skills 与Subagents.md|来源: 扶苏深度定制]]
| 需求 | 错误做法 | 正确做法 |
|---|---|---|
| 每次编辑后自动跑 linter | 写进 CLAUDE.md | PostToolUse Hook |
| 禁止某类危险操作 | ”Never do this” 写 CLAUDE.md | PreToolUse Hook + exit code 2 |
| 30 行部署流程 | 塞进 CLAUDE.md | .claude/skills/ |
| 只对 API 目录生效的规则 | 无 paths 限定的 Rule | 用 paths: 字段作用域限定 |
| 个人习惯偏好 | 项目级 CLAUDE.md | 用户级配置（~/.claude/） |
| 全局性事实性指令 | subagent 或 skill | 根目录 CLAUDE.md |
Subagents：保持上下文清洁的关键
扶苏通过同一问题（Dexie.js 文档抓取）用四种方式实现的实践对比，核心结论是 Subagents 是保持主上下文清洁的关键——另起独立上下文窗口运行，中间结果完全不污染主会话。同时支持 Async Agents（异步智能体，Ctrl+B 后台运行，完成后回来查看），这是 Plan Mode 中 Explore 类型 subagent 的典型应用。 [[raw/2026-06-20/扶苏/Claude Code 深度定制指南：CLAUDE.md、Commands、Skills 与Subagents.md|来源: 扶苏 Subagents]]
Slash Commands vs Skills 的区别
两者核心区别在 UX 和封装形式：Slash Commands 是单文件入口、支持 / 自动补全，可直接在单条消息中并行启动多个 Subagents 做多渠道研究；Skills 是多文件目录结构（SKILL.md + scripts + references + assets），可包含辅助资源，由 Claude 自动发现调用。Slash Commands 可显式编排复杂行为——在单条消息中并行启动多个 Subagents 做多渠道研究。 [[raw/2026-06-20/扶苏/Claude Code 深度定制指南：CLAUDE.md、Commands、Skills 与Subagents.md|来源: 扶苏 Commands vs Skills]]
Plugin 打包共享机制
Skills、Subagents、Hooks、Output Styles 可以打包成 Plugin 在团队和项目间共享。这是 Anthropic 推动的从个人效率到团队协作的关键机制。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: Plugin 共享]]
CLAUDE.md 治理共识（2026-06 新增）
本次摄入最成熟的跨源主题——所有源文件一致指出 CLAUDE.md 会自然膨胀导致 token 浪费和指令遵循率下降。 [[raw/2026-06-19/吴师兄/面试官皱眉：-Claude Code 你用了半年，CLAUDE.md 多少行了？-我说两千多，他：那今天就到这吧.md|来源: 吴师兄 CLAUDE.md治理]] [[raw/2026-06-20/邵猛/驾驭 Claude Code：CLAUDE.md 配置文件、Skills、Hooks、Rules、Subagents 等 7 种指令全解析.md|来源: 邵猛治理]]
核心数字
- 200 行上限：Anthropic 官方建议 CLAUDE.md 控制在 200 行以内。超过此限制，注意力稀释和 token 浪费开始非线性增长。
- 每行都是常驻成本：CLAUDE.md 每一行在每轮对话都重复加载。两千行约两万多 token，一次会话三四十轮光重读就能滚到七八十万 token。更隐蔽的代价是注意力被稀释——高频硬约束被噪声淹没。 [[raw/2026-06-19/吴师兄/面试官皱眉：-Claude Code 你用了半年，CLAUDE.md 多少行了？-我说两千多，他：那今天就到这吧.md|来源: 常驻成本]]
- 指定 owner：CLAUDE.md 必须指定负责人，否则像无人负责的配置文件一样各团队不断追加从不删减。
- 像审代码一样审变更：CLAUDE.md 的每次改动都应经过与代码变更同等级的审查。
分层治理原则
- 全局级（
~/.claude/）：个人习惯偏好，对所有仓库生效 - 项目级（
./CLAUDE.md）：项目范围的事実性指令、构建命令、编码规范 - 子目录级：特定目录的局部规范，按需加载
- Skill 级：流程化工作，渐进式按需加载
放错层会导致个人偏好污染团队共享配置。核心能力不是写多好而是判断什么该删、什么该下沉为 skill、什么该上提到全局层——CLAUDE.md 是维护出来的不是写出来的。 [[raw/2026-06-19/吴师兄/面试官皱眉：-Claude Code 你用了半年，CLAUDE.md 多少行了？-我说两千多，他：那今天就到这吧.md|来源: 分层治理]]
claudeMdExcludes 配置项
开发者可通过此项跳过不相关团队的子目录 CLAUDE.md 文件，避免无关指令污染上下文。 [[raw/2026-06-19/Anthropic/调教 Claude Code 的七种方法.md|来源: claudeMdExcludes]]
Dynamic Workflows：上下文工程向编排的延伸（2026-06 新增）
金色传说大聪明引入的 Dynamic Workflows 能力，推动上下文工程从单线对话向多 Agent 并行编排升级。核心解决三个问题：Agentic laziness（偷懒）、Self-preferential bias（自我偏好）、Goal drift（目标漂移）。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: Dynamic Workflows]]
六个编排模式：Classify-and-act、Fan-out-and-synthesize、Adversarial verification、Tournament、Generate-and-filter、Loop until done。
三个核心函数：Agent(prompt, opts?)、parallel([fns])、pipeline(items, ...)。
与上下文工程的关系：Dynamic Workflows 本质上是上下文预算的编排层——通过分配子任务到独立上下文窗口来控制主会话的上下文膨胀，属于上下文工程的更高阶应用。可通过 ultracode 触发词或要求 Claude “用一个 workflow”来激活。
Skill 的深层本质：程序性记忆与工业级设计（2026-06 新增)
Skill 不是提示词
多个来源独立验证了 Skill 的深层本质：Skill 是文件夹不是文件，是程序性记忆（procedural memory）而非一次性指令。Skill 的核心结构是目录（SKILL.md + scripts + references + assets），批处理文件按约定结构打包改后缀（.skll）。描述它是”提示词”是错误的理解——Skill 封装的是”达成某个目标所需的全部东西”：触发条件、执行流程、参考资源、辅助脚本。 [[raw/2026-06-20/金色传说大聪明/深入理解 Claude Code：从 CLAUDE.md 到 Hooks、Skills、Subagents…md|来源: Skill本质]] [[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？ 一个工业级 技能 Infra 底座如何设计？.md|来源: 尼恩 Skill]] [[raw/2026-06-20/Unknown/如何写出工业级 AI Agent Skill.md|来源: Unknown Skill]]
渐进式披露
所有来源一致认同：Skill 启动时只加载名称和描述（L0），完整目录/摘要（L1）和全文（L2）在需要时按需展开。不在启动时全量加载是不变的底线。
工业级 Skill 四层自进化 Infra
尼恩提出的四层架构代表了 Skill 系统设计的最高完整度：[[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？ 一个工业级 技能 Infra 底座如何设计？.md|来源: 工业级四层架构]]
- 轨迹感知层：脏计数器（按有效工具调用次数而非对话轮数触发复盘）+ 影子 Agent 舱壁隔离（记忆隔离/递归防护/工具白名单/危险命令自动拒绝/前端输出隔离/日志隔离六个维度）+ 缓存继承（约 26% 端到端算力成本降低）
- 技能蒸馏层：从执行轨迹中提取可复用模式
- 技能进化层（GEPA）：Generate-Evaluate-Patch-Audit 闭环——执行后评估，评估后补丁，补丁后回归验证
- 技能治理层：注册中心三层校验（Schema/安全扫描/冲突检测）、四层召回机制、L0-L1-L2 渐进式加载
矛盾：Matt Pocock 主张用户手动触发 Skill、AI 保持最小自主性，认为全自动流程剥夺控制权难以排查错误 vs 尼恩主张工业级 Skill 系统应四层召回+Harness 统一管控注入，通过置信度分层实现自动化（>0.85 自动加载），追求自进化闭环减少人工干预。这个张力在 [[wiki/syntheses/矛盾与视角差异]] 中有更完整的记录。
六组件概念边界
| 组件 | Core 定位 | 解决问题 | 边界特征 |
|---|---|---|---|
| Tool | 能做 | 单一动作执行 | 一个函数/API 调用 |
| Skill | 会做 | 多步骤任务达成 | 目录结构 + 程序性知识 |
| Harness | 不出事 | Agent 运行治理 | 调用模型、处理工具调用、决定何时停下 |
| MCP | 远程工具互联 | 跨厂商工具标准化 | 协议层，与 Harness 配合 |
| Memory | 笔记本 | 跨会话知识持久化 | 上下文之外的文件系统 |
| Prompt | 临时便签 | 单次指令 | 不跨会话，不封装逻辑 |
[[raw/2026-06-20/技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？ 一个工业级 技能 Infra 底座如何设计？.md|来源: 六组件边界]]
验证闭环是最高 ROI 投入
多个来源的实践反复验证：AI 自称的”完成”不可信，独立的验证手段是 Skill 从”看起来能用”到真正可靠的分水岭。常见问题→修改方向对照：触发失败改描述、流程漏步改工作流、输出不稳定加模板、确定性操作不稳定写脚本。 [[raw/2026-06-20/Unknown/如何写出工业级 AI Agent Skill.md|来源: 验证闭环]]
大模型 Infra 数学优化底层原理 (2026-06 新增)
此部分与此前所有 Agent/Harness 内容的维度不同——它深入 LLM 推理的数学与硬件优化层，揭示 Agent 系统底层的计算约束和优化逻辑。大模型本质上是实验科学，Infra 优化就是用数学等价变换或精度妥协换取硬件利用率和推理速度。 [[raw/2026-06-17/腾讯程序员(binnnliu)/拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md|来源: 数学与Infra优化]] [[raw/2026-06-18/腾讯程序员（binnnliu）/拆解大模型核心操作背后的数学与 Infra 优化逻辑.md|来源: 数学与Infra优化2]]
RMSNorm：去掉均值
RMSNorm 从 LayerNorm 中去掉了均值计算，只保留方差归一化。经验结论是缩放（除以标准差）就足够，减均值没必要。这消除了完整一轮逐元素减法，减少了寄存器/SRAM 压力。当前主流大模型不仅 RMSNorm 去掉了 beta，几乎所有 Linear 层去掉了 Bias。 [[raw/2026-06-17/腾讯程序员(binnnliu)/拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md|来源: RMSNorm]]
Softmax 优化链条
- Safe Softmax（-M 技巧）：减去最大值再算 exp 防上溢 NaN
- sqrt(d_k) 缩放：Var(qk) 与 d_k 线性增长，除以 sqrt(d_k) 防止方差膨胀导致的梯度消失
- Online Softmax：维持 running max (m) 和 running sum (l)，通过动态重新缩放打破全局数据依赖——将 3-Pass HBM 访问降为 1-Pass 流式处理
[[raw/2026-06-17/腾讯程序员(binnnliu)/拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md|来源: Softmax优化]]
FlashAttention 演进
- FA1：外循环 K/V，内循环 Q，HBM 多次写回
- FA2：外循环 Q，内循环 K/V，寄存器累积到底——但 L2 cache 命中率依赖硬件黑盒调度，从 99% 命中率退化到 80% 以下会导致实测性能拐点
- FA3/FA4：Persistent Kernel + TMA（Tensor Memory Accelerator）multicast，TMA 将 L2 cache 命中率从”期望”升级为”合约”
FA4 的 SFU/ALU 混合计算：75-90% 的 exp 计算走硬件 SFU（Special Function Unit）原生指令，10-25% 走 ALU FMA 多项式逼近。原因是 Blackwell Tensor Core 算力翻倍但 SFU 没同比例扩展——Hopper/Blackwell 每个 SM 仅有 16 个 SFU 对比 128 个 FP32 单元，导致 Softmax 的 exp 运算成为计算瓶颈（SFU 是非线性运算 exp/sqrt/sin/cos 的专用硬件）。 [[raw/2026-06-18/腾讯程序员（binnnliu）/拆解大模型核心操作背后的数学与 Infra 优化逻辑.md|来源: FA4 SFU]]
Gumbel-Max Trick
将串行多项采样（multinomial sampling from logits）转换为并行 argmax 操作：q.exponential_() → probs.div_(q).argmax()。vLLM 用此方法统一了贪心解码和随机采样的代码执行流。额外收益：跨卡通信时只需一次 All-Reduce(MAX with index) 即可拿到全局采样结果，通信量从 O(V) 降到 O(world_size)。 [[raw/2026-06-17/腾讯程序员(binnnliu)/拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md|来源: Gumbel-Max]]
Pre-Norm vs Post-Norm
Pre-Norm 牺牲前向质量换取反向传播稳定性（使 100+ 层网络可训练），Post-Norm 需要 warm-up 补偿梯度不平衡。但 Pre-Norm 存在表征坍塌（Representation Collapse）——越深层主干 x 累加越大而 f(Norm(x)) 基本不变，导致强行剪掉最后几层模型性能下降不明显。从 Post-Norm 到 Pre-Norm 的演进本质上是 NLP 把 CV 领域 ResNet-v1 到 ResNet-v2 的路又走了一遍。 [[raw/2026-06-17/腾讯程序员(binnnliu)/拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md|来源: Pre-Norm]]
LSE 压缩
LSE（Log-Sum-Exp）将 FlashAttention 中的 (m, l) pair 压缩为单个 FP32 标量，支撑三大机制：反向传播时 P 矩阵重算、Split-K 归约合并、下游算子复用。 [[raw/2026-06-18/腾讯程序员（binnnliu）/拆解大模型核心操作背后的数学与 Infra 优化逻辑.md|来源: LSE压缩]]
相关页面
- [[wiki/entities/Claude Code]]
- [[wiki/concepts/上下文管理与 Harness Engineering]]
- [[wiki/concepts/Agent 记忆、压缩与生命周期治理]]
- [[wiki/entities/OpenClaw 与多 Agent 编排]]
- [[wiki/concepts/Superpowers 与编程治理框架]]