System Design

如果你正在用 LLM 做事实核查、内容审核或者知识问答系统，有一个问题你大概率回避不了：当多个模型对同一条声明给出判断时，它们的答案到底能不能互相印证？ 答案可能比你想象的更令人不安。 Lenz Research 在 2026 年 5 月发布了一份名为《Beyond Benchmarks: Frontier LLM Disagreement on Real-World Fact-Checks》的快照研究（Snapshot v1.0），用 1,000 条真实用户提交的事实声明，让五款顶级前沿 LLM 各自独立判断真假。结论很直白：67% 的声明，至少有一个模型的判断与多数派相左——要么没有形成多数共识，要么有模型直接唱反调。 这可不是 benchmark 刷分游戏。这些声明来自真实用户提交给 Lenz 事实核查平台的请求，涵盖健康、科学、政治、金融、法律、技术等领域。没有公开的答案库，没有排行榜可以 pattern-match。 研究设计：五个模型，一千条声明，强制四选一 测试对象是当前公认的五款顶级模型：GPT-5.4、Claude Opus 4.7、Gemini 3 Pro、Gemini 3 Pro + Search（带 Google 搜索增强）、Sonar Pro（Perplexity 的搜索增强模型）。 每条声明被提炼成一个中立的、可检验的命题（Lenz 称之为"framing step"——剥离情绪化表达和偏见，只保留核心事实主张），然后要求每个模型从四个选项中强制选择一个：True、Mostly True、Misleading、False。 注意两个关键设计决策： 强制选择，不允许弃权。没有"我不确定"这个选项。这保证了对称比较——如果允许 Abstain，搜索增强模型可能通过大量弃权来"提高准确率"，但那就不是同一场比赛了。 不做 ground truth 对比。研究的视角不是"哪个模型更准确"，而是"模型之间有多不一致"。多数派意见不等于正确答案，少数派也不等于错误——但分歧本身就是一个值得重视的信号。 核心发现：三分之二的声明，模型们吵起来了 数据很清晰： 67% 的声明（672/1,000，95% CI: 64–70%）存在至少一个模型与多数派分歧 34% 的声明（343/1,000）涉及 2 个以上桶位的实质性分歧——不是 True 和 Mostly True 之间的细微差异，而是 True 和 False 之间的根本对立 21% 的声明（211/1,000）出现极端对峙：一个模型说是 True，另一个说是 False 只有 33% 的声明达成五方一致 用 Krippendorff’s α（序数版）衡量五个评分者的一致性，得到 0.639——说白了就是"有结构，但远不够可靠"。如果你让五个实习生做同一批事实核查，交上来的结果差异这么大，你大概不会直接发布。 ...

如果你还在用“这张卡有多少 TFLOPS”来判断一套 LLM 推理系统值不值得买，我建议先停一下。 这不是说算力不重要。训练大模型、跑高吞吐推理，当然离不开矩阵乘法能力。但最近 Hacker News 上一篇 Epoch AI 的芯片成本拆解很值得看：他们估算，在 Nvidia、AMD、Google、Amazon 等 AI 芯片的组件成本里，高带宽内存 HBM 的占比已经从 2024 年一季度的 52% 上升到 2025 年四季度的 63%。 也就是说，今天一颗 AI 加速器越来越不像“纯算力商品”，反而更像一块被昂贵内存包围的计算核心。 这个变化对做应用的人也有直接影响。你在云上选 H100/H200，或者在本地纠结 4090、Mac Studio、工作站多卡，并不是在买一个抽象的“AI 能力”。你买的是：模型权重能不能放下，KV cache 能不能撑住上下文，batch size 能不能拉起来，以及 token 流水线会不会被内存带宽卡死。 说白了，LLM 推理的很多瓶颈，最后都会变成内存问题。 HBM 成本占比上升，说明了什么？ Epoch AI 这篇文章的核心数字很简单：HBM 在 AI 芯片组件成本中的占比，从 52% 增长到 63%；同时 logic dies 大约维持在 13%，先进封装和其他辅助组件占比下降。这个结论不是单一芯片报价，而是按生产量加权估算出来的行业平均值。 我不建议把这个数字理解成“GPU 厂商利润被内存厂吃掉了”这么简单。更有用的读法是：产业链正在用真金白银投票，承认 AI 工作负载对内存系统的饥渴程度越来越高。 为什么？因为 LLM 不是只做一次矩阵乘法就结束。 模型推理至少有两类阶段：prefill 和 decode。prefill 阶段要把提示词一次性喂进去，计算密度相对高；decode 阶段则是一个 token 一个 token 往外吐，每一步都要读模型权重，还要读写不断增长的 KV cache。上下文越长、并发越高，显存容量和带宽压力越明显。 ...

我越来越觉得，很多 AI Agent 的问题不在“模型还不够聪明”，而在我们把它们塞进了一个很别扭的接口里：一条聊天消息进来，一条聊天消息出去，中间所有思考、工具调用、观察结果、用户反馈，都被挤在同一条时间线上。 这件事平时不明显。你让模型改一段代码、总结一篇文章，它慢一点、啰嗦一点，问题不大。但一旦进入真正的 Agent 场景，比如浏览器操作、长时间代码修改、后台任务、多人协作，它就开始露馅：模型正在“思考”时没法同时接收新信息，正在“输出”时没法真正读环境变化，正在等工具结果时也没法继续做别的规划。 说白了就是：我们想要一个能并行工作的智能系统，却还在用单线程聊天窗口来驱动它。 最近 HN 上有一篇论文讨论的正是这个问题：Multi-Stream LLMs: Unblocking Language Models with Parallel Streams of Thoughts, Inputs and Outputs。它的分数不算特别夸张，但我觉得比很多“又一个 Agent 框架”更值得写。因为它不是在 prompt 外面再包一层流程图，而是在问一个更底层的问题：LLM 的交互格式，是否已经成为 Agent 能力的瓶颈？ HN 原帖标题也很直接：Multi-Stream LLMs: new paper on parallelizing/separating prompts, thinking, I/O。这不是一个已经成熟可用的工程框架，更像是一份架构提案。但它戳中了生产级 Agent 的一个痛点。 当前 Agent 最大的隐性假设：所有事情都必须排队 今天大多数 Agent 系统，本质上还是 ChatGPT 时代的消息协议： system message 定规则； user message 给任务； assistant message 生成回答或工具调用； tool message 把结果塞回上下文； assistant 再继续。 OpenAI 的 Agents SDK 已经把 handoff、guardrails、tracing、tool calling 封装得很清楚；Anthropic 的 Computer Use 也让 Claude 可以观察屏幕、点击、输入、等待环境变化；MCP 则通过 Model Context Protocol 把外部工具和数据源标准化成可连接的上下文。 ...

如果你用过 Claude Code、Codex CLI 或 Cursor 这类编程 Agent，大概率见过一种很烦人的失败模式：它明明已经读完文件，却又回头读一遍；明明应该先写测试，却开始大面积重构；明明只是修一个 20 行 bug，却顺手动了 6 个模块。最后 token 花了，diff 也出来了，但你不敢合并。 我越来越觉得，这不是“模型不够聪明”一个问题。 更准确地说，是我们把 Agent 放进了一个没有交通规则的城市：Read、Grep、Edit、Bash、Web、MCP 工具全都摊在它面前，然后指望一段系统提示词告诉它“请谨慎驾驶”。提示词当然有用，但它不是刹车，也不是红绿灯。 这也是 Statewright 最近在 HN 上引起我注意的原因。它的口号很硬：Agents are suggestions, states are laws. 用人话翻译：不要只靠模型“自觉”，把工作流拆成确定状态，在每个状态里只开放它该用的工具。 状态机不是新概念，但放在 Agent 上刚好戳中痛点 Statewright 做的事情并不神秘。它让你定义一个工作流，例如 planning → implementing → testing → completed。在 planning 状态里，Agent 只能读文件、搜索代码；进入 implementing 以后才允许 Edit/Write；到 testing 状态，Bash 可以用，但只能跑 pytest、cargo test、npm test 这类白名单命令。 项目 README 里的示例很直观：planning 只给 Read/Grep/Glob，implementing 允许 Read/Edit/Write 且限制 max_edit_lines、max_files_per_state，testing 才给 Bash，并且通过 guard 判断测试是否通过。官方的 workflow schema 也把这些字段明确写成结构化配置，而不是自然语言建议。 ...

引言：从「一个 prompt 打天下」说起 大多数团队搭建 LLM 工作流的方式至今仍然是：写一个超长的 system prompt，塞进所有工具描述，再接一段「请仔细思考后选择工具」，祈祷模型能正确路由。 当这条流水线出问题时，没有日志、没有断点、没有回归测试——只有翻看 provider 后台记录，然后反复修改 prompt 碰运气。 Gambit 试图解决这个问题。它将 LLM 工作流拆解为多个「牌组（Deck）」的组合，每个 Deck 有显式输入/输出类型定义和护栏（Guardrails），在本地即可运行、调试和测试。 本文从系统设计的角度，解析 Gambit 的核心架构与它对 AI 工程化的启示。 现状：LLM 工作流的四个结构性缺陷 Gambit 官方 README 开篇就列出了当前行业的四个痛点1： 缺陷 具体表现 单体 prompt 一个 prompt 绑定所有工具，路由依赖 prompt 工程的脆弱黑盒 上下文倾倒 每次调用把全部 RAG 结果或历史记录整块注入，成本高、幻觉多 无类型 I/O 输入输出都是字符串，Orchestration 逻辑无法静态检查 调试黑盒 只能看 provider 日志，本地无法复现和回归测试 这四个问题相互加剧：没有类型约束 → 无法做单元测试 → 只能靠 prompt 调优 → 调优结果无法回归。 核心概念：Deck 与 Card Deck：最小执行单元 Gambit 的 Deck 是整个框架的核心抽象。一个 Deck 约等于一个带有类型化输入输出定义的函数： ...

一个真实的安全事件 今年 2 月，安全研究员 Ilia Tishin 在自己的博客上记录了一次罕见的"攻击"经历1：有人利用 AI Agent 系统性地搜集他的个人信息，生成攻击性内容，并发布到公共平台上。整个过程不需要攻击者逐条干预每一个步骤——Agent 自主完成了从情报收集到内容分发的大部分工作。 这不是孤例。随着 AI Agent 框架（LangChain Agents、AutoGen、CrewAI、OpenClaw 等）的快速普及，越来越多的系统被赋予自主调用工具、读写文件、访问 API、甚至发布内容的能力。但这些能力的增加，也带来了前所未有的安全攻击面——而大多数开发者并非安全专家。 这是一个典型的安全供需错配：框架把能力给了开发者，却把安全责任也一并丢给了开发者。 最近在 GitHub 上出现了一个值得关注的项目——AgentArmor2，它尝试用一套系统化的 8 层安全框架来解决这个问题。本文就来拆解它的设计逻辑，以及这背后反映出的 Agent 安全现状。 为什么现有安全工具都是"点方案" 在 AgentArmor 之前，市面上的 AI 安全工具大多是单点出击： 输出过滤器：检测生成内容是否有毒 Prompt 注入扫描器：检测输入中是否有注入攻击 策略引擎：基于规则判断是否允许某操作 这些工具各有价值，但无法组合成一个完整的安全系统。原因是：Agent 的数据流是端到端的——数据从外部输入（Ingestion），进入 LLM 处理（Context），转变成行动计划（Planning），执行操作（Execution），输出结果（Output），并可能与其他 Agent 通信（Inter-Agent）。在每一个阶段，数据都有不同的脆弱性。 点方案只能覆盖一个阶段，攻击者只需要找到你没有覆盖的那个阶段就可以突破。 八层安全架构 AgentArmor 提出的核心思想是：为 Agent 的整个数据流设计 8 层纵深防御。 graph TD subgraph "AgentArmor 8-Layer Defense" L1["L1 Ingestion<br/>输入扫描：Prompt 注入检测"] L2["L2 Storage<br/>存储安全：AES-256-GCM 加密"] L3["L3 Context<br/>上下文隔离：指令-数据分离"] L4["L4 Planning<br/>行动计划：风险评分"] L5["L5 Execution<br/>执行控制：速率限制+人工审批"] L6["L6 Output<br/>输出过滤：PII 脱敏"] L7["L7 Inter-Agent<br/>多 Agent 通信：HMAC 认证"] L8["L8 Identity<br/>身份与权限：JIT 权限 + 凭证轮换"] end L1 --> L2 --> L3 --> L4 --> L5 --> L6 --> L7 --> L8 style L1 fill:#f59f00,color:#fff style L5 fill:#ef4444,color:#fff style L8 fill:#7c3aed,color:#fff 每一层都针对数据流中一个特定位置的特定威胁。 ...

大模型的本质：一只戴着数学面具的随机猴子 在深入 ERA 框架之前，需要先接受一个反直觉的事实：大语言模型本质上是一个极其复杂的"下一个词预测器"。它的工作原理，从信息论角度看，和一只在键盘上随机敲击的猴子没有本质区别——区别只在于，这只猴子敲的每一个键，都受到了前面所有键的概率分布约束。 当模型说"我认为答案是…"，它实际上是在说：“在看过 trillions 个token之后，根据我学到的语言统计规律，在当前位置的词表中，每个词作为下一个词出现的概率分别是…"。它不是"思考"后得出结论，而是穷举了所有可能路径的概率加权后坍缩到一个结果。 这个过程在信息论中有一个精确的量：熵（Entropy）。熵描述的是一个随机变量或过程的不确定性。LLM 的输出在没有任何约束的情况下，熵是极高的——模型几乎可以输出任何合理的词序列中的任何一个。这种高熵状态，就是我们通常说的"模型在胡说八道"或"幻觉”（hallucination）的本质：它不是在说谎，它只是在忠实地履行一个概率预测器的职责，只是这个职责恰好在某些边界情况下产生了我们不想要的结果。 熵减控制的本质：把"随机漫步"变成"有轨电车" ERA（Entropy-Reduction Architecture，熵减提示词架构）的核心命题是：如果我们把 LLM 的输出过程看作一个熵减过程——从高熵的不确定状态，经过一系列"约束过滤器"逐步压缩到低熵的确定输出——那么 prompt 工程就不再是一门玄学，而是一门可以系统化设计的控制理论。 把 LLM 放进一个需要高质量输出的业务流程时，我们实际上是在设计一个控制系统。系统的输入是用户模糊的、充满噪声的自然语言，系统的输出应该是具体的、确定的、符合业务需求的内容。 而这个控制系统的设计，本质上就是熵减过滤器的排列组合。 五层过滤器的工程拆解 ERA 提出了一个五层过滤模型，每一层负责移除特定类型的"熵增噪声"，最终把输出压缩到业务可接受的范围。 第一层：身份域（Identity Domain）——设定基础概率分布 这一层解决的问题是：“以什么身份、什么视角、什么基线概率来回答问题？” 很多人以为 prompt 的角色设定只是一个风格技巧，但 ERA 的视角完全不同。角色设定实际上是给模型的概率分布打了一个基底偏移（bias shift）。 没有身份设定时，模型对所有输出的预设是"面向普通互联网用户的通用助手"。加上"你是一个资深金融风控分析师，有 15 年信用评估经验"之后，模型的输出概率分布发生了根本性偏移——“杠杆收购"“债务覆盖率"“Z-Score"这类专业术语的出现概率急剧上升，而"太棒了！““让我帮你分析一下"这类口语化表达的出现概率急剧下降。 这就是为什么同样的问题，“让 ChatGPT 用小学生能听懂的话解释量子力学"和"让量子物理教授解释量子力学"会给出截然不同的答案。不是模型能力变了，是基底概率分布变了。 第二层：知识域（Knowledge Domain）——注入确定性事实输入 这一层解决的问题是：“在什么事实基础上回答？” LLM 的知识有两大缺陷：知识的截止日期性（不知道训练之后的最新信息）和知识的概率性（对模糊边界的记忆是权重分布，而不是精确事实）。 知识域的设计引入了 RAG（检索增强生成）或结构化上下文注入技术，本质上是在回答之前先把一批确定性的事实强制塞入模型的上下文，让模型在回答时以这些事实为条件，而不是以它自己模糊的权重记忆为条件。 金融场景中一个常见做法是：在系统 prompt 中明确注入"以下是今天的市场数据：USD/CNY = 7.23，BTC = 672,000…"——模型在这个上下文条件下回答时，不会再去依赖它训练时学到的、可能已经过时的汇率记忆，而是基于你注入的精确数据做推理。 第三层：算法域（Algorithm Domain）——规定处理逻辑的步进轨道 这一层解决的问题是：“用什么样的逻辑流程处理输入？” 大多数"prompt 不 work"的问题出在这一层——给模型一个模糊的目标（如"帮我分析一下这个产品”），然后期望它自动找到正确的分析路径。但模型在这种情况下会做随机游走，每次运行结果可能都不一样。 算法域的典型设计模式包括： Chain-of-Thought（CoT）：强制模型输出推理步骤，而不只是最终答案。本质上是把一个高熵的"直接输出"拆解成多个低熵的"步骤输出”，中间每一步都可以被校验 Tree-of-Thought（ToT）：在复杂问题空间允许模型探索多条推理路径，每条路径都是独立的低熵序列，最后通过某种评分机制选出最优路径 DSPy 框架的编译器思路：把 prompt 逻辑本身变成一个可以优化的程序，而不是固定的文本 第四层：边界域（Boundary Domain）——切断非法概率区间 这一层解决的问题是：“什么绝对不能说、不能做？” 边界域是大多数 prompt 教程中最忽视、但实际上最关键的一层。LLM 的输出空间是巨大的，在某些区域（涉及违法行为、敏感内容、专业建议边界等），即使其他所有层都设计得完美，只要模型在这些高风险区域内的概率不为零，实际运行时就有可能触发——特别是在对抗性输入或罕见 edge case 出现时。 ...

一个几乎每个团队都踩过的坑 去年年底，某中型技术团队上线了一套"AI 自动编程流水线"——基于 GPT-4 和代码仓库，每天自动完成 Issue 分解、代码编写和 PR 提交。前三天一切顺利，团队颇有成就感。 第四天早上，他们发现：Agent 在凌晨 3:17 因为一次 API 超时陷入死循环，在 Slack 群里疯狂刷屏了 400 多条错误日志，但没有任何机制让它停下来。值班工程师被叫醒后花了 2 小时才手动终止进程、清空状态、重置上下文。 这不是某家公司的个别故障。当我们把 LLM 放进一个需要长时间运行的自动化流水线时，几乎必然遇到三个结构性难题：LLM 无状态、任务周期远超单次调用时长、API 不稳定。而大多数团队用来解决这些问题的方案，要么过度依赖人工盯守，要么干脆祈祷 API 别出问题。 OpenClaw1 试图回答一个更根本的问题：如果把 AI Agent 当作一台计算机而不是聊天机器人来设计，这些问题是否可以被工程化地解决？ 为什么说"AI 编程助手"这个定位错了 在深入 OpenClaw 的架构之前，需要先纠正一个常见的理解偏差。 当我们用"AI 编程助手"来描述 Claude Code、Copilot Workspace 这类产品时，隐含的假设是：人类的每一次操作，都是一次独立的、完整的会话。用户给一个指令，AI 给一个回复，结束。 但一旦你开始构建自动化流水线，这个模型立刻崩塌——因为流水线的核心特征是：异步性（任务可能跨越数小时甚至数天）、容错性（中途可能有 API 超时、网络抖动、模型幻觉）和状态持久性（下一轮执行必须知道上一轮做到哪了）。 OpenClaw 的核心洞察是：LLM 本身是一个无状态的"CPU"，而不是一个有记忆的"服务器"。 因此，要构建长期运转的 AI 流水线，必须给它配上一块"硬盘"——也就是持久化的状态文件。 这就是 OpenClaw 的架构起点。 离散状态机：把连续任务切成互不干扰的阶段 OpenClaw 采用了离散状态机（Discrete State Machine）的设计思想。简单来说：它不要求 AI 在一次调用中完成整个复杂任务，而是把任务切分成多个阶段（Phase），每个阶段都有明确的输入文件、输出交付物和状态转移条件。 stateDiagram-v2 [*] --> Idle: 项目初始化 Idle --> Phase1_Architecting: 启动架构设计 Phase1_Architecting --> Phase1_Architecting: 执行中 Phase1_Architecting --> Waiting_HITL: 架构文档生成完毕 Phase1_Architecting --> SelfHeal: 超时/崩溃检测 Waiting_HITL --> Phase2_Coding: 人类批准 Waiting_HITL --> [*]: 人类拒绝 SelfHeal --> Phase1_Architecting: 重试 SelfHeal --> Phase1_Architecting: 跳过（已完成） Phase2_Coding --> Phase2_Coding: 执行中 Phase2_Coding --> Waiting_HITL: 危险操作需确认 Phase2_Coding --> Phase3_Testing: 编码完成 Phase3_Testing --> Phase3_Testing: 执行中 Phase3_Testing --> [*]: 测试通过/终止 每一轮调度（通常是 Cron 触发），Agent 醒来后第一件事不是"直接干活"，而是读取状态文件，确定自己处于哪个 Phase、上一轮完成了什么、接下来该做什么。 ...

一个让工程师失眠的 Bad Case 2025 年中，某金融科技公司在内部知识库问答系统中引入 RAG（检索增强生成）。系统上线后，用户反馈普遍不错——直到某天，一个风控团队的用户问：“我们有哪些客户曾经有过信用违约记录？” RAG 系统检索返回了三条"高相关"文档，AI 基于这些文档给出了自信满满的答案。风控经理看完后直接冷汗：系统返回的内容全是关于"信用良好客户"的正面案例，和用户的查询意图完全相反。 事后排查发现，问题出在向量检索阶段。用户的查询"信用违约记录"和文档中大量出现"信用"“违约"字眼的高频正面记录产生了极高的余弦相似度，而真正描述违约事件的文档因为语言表达更隐晦，反而相似度偏低，被 Top-N 过滤掉了。 这是一个典型的向量检索只看词不看语义关系的失败案例。1 向量检索的物理课：两个不相识的学生在各自考试 理解为什么向量检索会"看走眼”，需要先理解它的工作原理。 向量检索的核心是Bi-Encoder（双编码器）架构。当你把文档存入向量数据库时，每个文档都会通过一个 Encoder 被压缩成一个固定长度的向量——通常 768 维或 1024 维。这个过程发生在入库时，与用户未来的查询完全无关。 当用户发起查询时，查询文本同样通过 Encoder 生成一个查询向量。然后，数据库在高维空间中做最近邻搜索（通常用余弦相似度或内积），找出与查询向量"距离最近"的 N 个文档。 这个过程有一个非常关键的特征：Query 和 Document 的编码是独立完成的，它们从未"见面"。 斯坦福大学 NLP 组有一个很直观的比喻：就像两个学生分别在不同的考场同时参加考试，学生 A（Query 编码器）看了一眼题目后把答案写成压缩笔记，学生 B（Document 编码器）提前把教科书内容写成压缩笔记。考试结束后，系统只是比较这两份笔记的"形状"有多像，而不知道题目问的是什么。 这解释了为什么"信用违约记录"的查询会匹配到"信用良好客户"文档：两份文档都高频出现"信用"字眼，它们的向量在语义空间中距离很近，而模型根本不知道"违约"和"良好"是反义词。 重排模型：让 Query 和 Document 当面对质 Cross-Encoder（交叉编码器）采用了完全不同的策略。 它不做"独立压缩"，而是把**[Query + Document] 拼接成一段完整文本**，一次性通过一个深度神经网络（如 BERT）。在这个过程中，模型的注意力机制（Self-Attention）会在每一个 token 层级做交叉比对——当读到 Query 中的"违约"时，它会立刻去 Document 中寻找是否存在"违约"、是否存在语义矛盾、是否存在否定结构。 这种"当面对质"的方式，让 Cross-Encoder 能捕捉到 Bi-Encoder 完全无法处理的关系： 语义否定：Query “如何不用 Python” vs Document “Python 教程”——Bi-Encoder 会给高分，Cross-Encoder 能识别"不"的否定作用 长距离依赖：查询涉及某个条件组合，文档在开头提到条件A、结尾提到条件B，Cross-Encoder 的注意力能跨越全文找到同时满足两个条件的文档 细微差异：两份文档语意相近但立场相反（如上面的违约案例），Cross-Encoder 能识别出差异 用一个直观的对比表总结： ...