密码学签名全景:从 HMAC 到数字签名的完整图谱
从一个困惑开始 你可能在不同场景见过这些词:HMAC-SHA256、RSA 签名、ECDSA、HS256、RS256、X.509 证书签名……它们都叫"签名",但到底有什么区别?什么时候该用哪个? 这篇文章一次性理清整个图谱。 签名家族的完整分类 先看全貌——所有"签名"机制可以按照是否使用密钥和密钥类型分为三层: graph TD subgraph "Layer 0: 无密钥" H["Hash 函数<br/>SHA-256 / SHA-3"] end subgraph "Layer 1: 对称密钥" MAC["MAC 消息认证码"] HMAC["HMAC<br/>HMAC-SHA256"] CMAC["CMAC<br/>AES-CMAC"] MAC --> HMAC ...
重读 Linux VM:给系统研究生的虚拟内存导读
Linux VM 容易读散。它表面上在讲 mmap、页表、缺页异常、匿名页、page cache、folio、LRU、swap、NUMA、huge page、slab、cgroup memory 和 OOM killer,读起来像一串彼此相邻但没有主线的内核机制;主线可以压成一句话: Linux VM 是一套把虚拟地址、物理页、文件、进程、CPU MMU 和 I/O 统一到同一个状态转移系统里的内核机制。 这句话一旦立住,虚拟内存就不再只是“地址翻译”或“把内存变大”。地址空间描述进程能够访问什么;页表描述 CPU 当前怎样翻译地址;物理页描述内核手里真实可调度的资源;page cache 把文件内容放进同一套页管理体系;缺页异常负责把尚未兑现的映射变成真实页面;页回收和 swap 则在内存压力下重新分配这些页面。 本系列以 Linux 6.x(主要参照 6.1–6.8)为基准。涉及版本敏感的机制时(如 maple tree 6.1 引入、per-VMA lock 6.4 稳定、Multi-Gen LRU 6.1 合入、folio 迁移 5.16–6.0 持续进行),各篇会标...
Self-Improving Agent 的边界:外部记忆能不能 shadow 模型权重?
2026 年讨论 self-improving agent 时,最容易混在一起的有三件事:模型权重会不会自己变强,agent 会不会从运行经验里积累结构,harness 会不会自动改造自己。 这三件事都可以被叫作"自我改进",但边界完全不同。第一种发生在 L1,也就是模型权重和训练管线里;第二种发生在 L3/L4,也就是外部记忆、skill、session search、user model 和可检索的外部世界里;第三种发生在 harness 本身,也就是工具、middleware、调度、回滚和验证结构里。 如果不先把层级分开,“Hermes 是不是 self-improving agent”、“OpenClaw 是不是第一个自进化 agent”、"外部记忆能不能替代动态权重"这几个问题都会变成口号战。 一、权重没有变,行为会变 一个冻结权重的模型不会因为昨天完成了一次任务,今天的参数就多出一个新神经回路。对主流商用 API 和开源推理栈来说,部署后的模型权重大体是静态的。所谓 self-improving agent,绝大多数不是在改...
AI Coding Agent 的上下文操作系统:组件、生命周期与阅读地图
AI Coding Agent 每次调用模型,都要临时拼出一份工作集。系统指令、用户需求、仓库规则、Skill、工具定义、检索结果、历史消息和外部记忆,经过筛选和排序后进入模型上下文。工具返回的新事实又会写回消息历史或外部状态,供下一轮使用。 这套机制分散在 Harness 的多个组件里,却承担着类似操作系统的职责:发现信息源,解析作用域和优先级,分配有限的 token 空间,调度外部能力,保存执行状态,在压缩或换会话后恢复工作集。 “上下文操作系统”是一个分析框架,不对应某个产品里的单一模块。它把 Coding Agent 中所有影响模型可见内容的机制放在同一张图上,便于讨论组件边界、运行时生命周期和故障位置。 上下文操作系统管理六类动作 上下文管理可以拆成六类相互独立的动作: 发现:扫描仓库指令、Skill、工具、插件和可检索的数据源。 裁决:按照来源、作用域和优先级解决指令冲突。 选择:从候选信息里挑出本轮需要的内容。 编排:把内容放进 system、tools、messages 或外部引用的合适位置。 改写:追加、截断、裁剪、压缩、外置或重放历史。 持久化:把任务状...
AI 不会吞掉软件,只会吞掉入口
“AI 会吞掉所有软件”这个说法很有传播力,但技术上不够准确。更可能发生的事情是:软件本体继续存在,软件入口被 AI 重写。 计算器、数据库、编译器、PDF 库、浏览器、CAD、CI、权限系统、ERP 不太会因为 LLM 出现而消失。它们处理的是确定性状态、格式、权限、计算和副作用。LLM 不适合直接替代这些系统,却很适合成为它们上方的意图入口。 从交互史看,GUI 的意义之一,是把人和计算机之间的操作鸿沟压低了。用户不必记住底层命令和数据结构,也能通过窗口、图标、菜单和指针操作复杂系统。Agent 时代出现的是另一道鸿沟:LLM 和传统软件之间的鸿沟。CLI、API、MCP 和 Skills 把这道鸿沟压低了,因为它们把软件能力变成模型能读、能调、能记录、能验证的文本接口。 确定性系统不会消失 裸模型不是确定性程序。它可以写出计算器代码,但不应该代替计算器执行财务计算;它可以解释 PDF 结构,但不应该靠想象修改 PDF 二进制;它可以生成 SQL,但实际执行、回滚、审计和加锁的仍然是数据库。 这不是模型能力不够强时的临时现象,而是范式边界。真实软件世界需要可复现、可审计、...
Agent Teams 为什么有效
多 Agent 不是把同一个模型多开几份,也不是给系统加几个“人格”。它有效的地方,是把一个会互相稀释的上下文问题,拆成几个更窄、更干净、更容易验证的工作单元。 复杂任务不是信息越多越好。一个 Agent 同时负责需求、架构、编码、测试、文档和发布,很容易在同一个窗口里把角色、证据和目标搅在一起。Agent Teams 的价值,是让每个工作单元只面对一个足够小的世界。 注意力需要降维 考虑一个频谱分析的类比:复杂任务像一段混合信号,包含多个频率分量叠加。单 Agent 试图同时处理所有频率,相当于用一个宽带滤波器——信噪比低,各分量互相干扰。多 Agent 相当于用一组窄带滤波器,每个只提取自己负责的频段,互不干扰,最后再合成输出。 模型的注意力也有这个问题。任务越大,上下文里越容易同时出现目标、反例、日志、旧方案、失败尝试、代码片段和用户补充。它们都在争夺同一个窗口里的注意力。多 Agent 的第一层收益,就是把同一团上下文切成几个局部上下文。 flowchart TB U[用户目标] --> O[Orchestrator: 保持全局目标] O --&...
环境可供性:智能的一半是取到正确数据
没有工具的模型,只能靠提示词获得额外信息。提示词工程在那个阶段几乎是唯一杠杆:把背景写清楚,把例子给够,把格式约束好,让模型在已有上下文里尽量选对路径。 一旦模型拥有主动提取外部数据的能力,问题就变了。智能不再只取决于模型内部能处理多少信息,也取决于它能不能从环境里拿到正确的信息。 Prompt 是喂信息,工具是取信息 prompt-only 系统的工作方式像开卷考试,但试卷、教材和草稿纸都必须提前塞进同一个信封。用户没塞进去的信息,模型默认看不见。它可以猜,可以泛化,可以从训练数据里补常识,但无法可靠知道当前项目、当前日志、当前数据库、当前 API 文档发生了什么。 工具调用改变了边界。ReAct 把 reasoning 和 acting 交织起来,让模型一边推理,一边对外部知识库或环境采取动作获取观察结果。Toolformer 进一步证明,语言模型可以学习在合适时机调用 API,并把结果纳入后续预测。SWE-agent 的核心贡献也不是“又写了一个 coding prompt”,而是强调 Agent-Computer Interface:给 agent 一个适合读文件、改...
Context Paging:Compact、外部化、恢复与 Memory 生命周期
长程 Agent 的限制不只来自 context window 大小。窗口里装了什么、旧材料怎样退出、compact 后哪些内容恢复、外部记忆何时失效,同样决定任务能否连续推进。 操作系统用 paging 把有限内存接到更大的外部存储。Agent 的上下文管理也在形成类似结构:当前窗口是工作集,文件、索引和 memory 是外部状态,compact 负责压缩历史,检索和恢复机制负责按需换入。Prompt cache 则位于另一条轴上,影响相同前缀的成本和延迟,却不减少它占用的 context window。 Context Paging 管理的是工作集 长窗口解决“能否放入”,没有保证“能否稳定使用”。《Lost in the Middle》显示,模型利用长上下文中的信息时会受到位置影响。Coding 会话还会积累失败命令、过时文件内容、被否决方案和大段日志。即使它们仍在窗口内,也未必属于当前任务需要的工作集。 Context paging 的目标不是保存所有历史,而是在每次推理前组织一个可执行工作集: 当前目标与完成条件; 仍然有效的约束; 关键证据及其来源; 修改状态与未...
裸模型为什么像抽卡
大模型写代码有一种很危险的爽感:同一个问题,上一轮胡说八道,下一轮突然给出一段漂亮实现。失败的时候像差一点,成功的时候像中奖了。 这种体验很像抽卡。不是因为使用 AI 等同于赌博,而是因为裸模型的反馈结构具备几个相似特征:结果有波动,高分样本偶尔出现,用户很难提前判断下一轮是不是高分,于是自然产生“再试一次”的冲动。 把这种冲动看清楚,比单纯争论模型聪不聪明更重要。很多 AI coding 的燃尽感,不来自模型太弱,而来自人把自己的注意力押在一次又一次低可见度的重试上。工程工作被悄悄改造成了抽卡循环。 flowchart LR A[一次任务] --> B[裸模型采样] B --> C{输出质量} C -->|低分| D[补 prompt / 换模型 / 重试] C -->|高分| E[强奖励: 这次出货了] D --> B E --> F[提高下一轮期望] F --> D D --> G[隐藏成本: review / 归因 / 修复 / 焦虑] ...
Harness 的本质:把随机模型锁进可验证的箱体
把大模型当成一个确定性函数,很容易高估它。更合适的工程抽象是:模型在当前上下文、参数和工具环境给出的概率空间里,采样出一个看起来最合适的结果。 这意味着同一个模型在同一类任务上的能力并不是一个点,而是一段分布。一个平均能做 70 分的模型,在某个具体任务上可能落到 50 分,也可能冲到 90 分。Harness Engineering 的价值,不是把 70 分模型魔法般变成 95 分模型,而是把它的行为压进一个更小、更可验证的区间,让低分尾部少出现,让高分路径更容易复现。 这个区间可以叫“箱体”。Spec、测试、工具、循环、权限、外部状态、子 Agent、hook,都是箱体的不同面。没有箱体时,模型在荒野里寻路;有箱体时,模型在一条被标出边界和检查点的路线上前进。 flowchart TB A[用户目标] --> B[Spec: 目标 / 非目标 / 边界] B --> C[Plan / Tasks] C --> D[模型生成候选方案] D --> E[确定性工具: 编译 / 测试 / schema / 日志] ...





