Notes on AI & Engineering
Hi, this is LengM.
表格推理这件事，说起来简单，做起来真的让人头疼。 你去问 ChatGPT 一个需要从表格里找数据、做计算的问题——比如"去年Q3哪个城市的销售额环比增长最快"——它有时候回答得挺自信，但仔细一验算，数字就是对不上。为什么？因为 LLM 天生就不擅长精确的数值操作。它能"理解"你的问题，能"看懂"表格的结构，但让它算个百分比变化，总有翻车的可能。 中科大的团队在 WSDM 2026 上发表了 TableMind，一个很有意思的思路：不要让 LLM 硬算，让它学会像人一样——想清楚要做什么，写代码去操作数据，看看结果对不对，不对就修正。 整个系统只有 8B 参数（Qwen3-8B），却在五个 benchmark 上打败了 72B 的 Qwen2.5 和 DeepSeek-R1。 怎么做到的？往下看。
最近翻到一篇港大的论文，标题是"The Deterministic Horizon: When Extended Reasoning Fails and Tool Delegation Becomes Necessary"，ICML 2026的。说实话，这标题挺唬人的——“确定性地平线”，听着像物理学概念。 但读完全文之后我觉得这可能是今年对Agent开发者最有实操指导价值的一篇理论论文。核心结论一句话： LLM的链式推理存在一个硬性上限，大约20-31步。超过这个深度，不管你用o3还是DeepSeek-R1，不管你怎么prompt、怎么微调，准确率都会崩盘。唯一的出路是把计算委托给外部工具。 这个结论直接影响了我对Agent系统的设计思路。下面详细说说这篇论文到底做了什么。 起因：思考越多，反而越错？ 我们现在的主流范式是——想让LLM干难事，就让它多想想。o1/o3系列靠长CoT取得了巨大进步，DeepSeek-R1也是走这条路。 但作者发现了一个违反直觉的现象：在确定性状态跟踪任务上（比如汉诺塔、滑块谜题、程序状态追踪），延长推理链非但不能帮忙，反而会让结果更差。 具体的数字长这样： 推理深度 准确率（平均） 10步 78% 30步 34% 50步以上 接近随机猜 你可能觉得——那是模型太弱了吧？换o3试试？ 换了。o3-mini在汉诺塔31步问题上的准确率是22.4%，加上extended reasoning烧了平均18000个token，还是只有22.4%。同一个问题让BFS搜索做，0.1秒搞定，100%准确。 这不是模型弱的问题。这是架构的硬伤。 为什么会这样？信息论给出了答案 论文的核心理论贡献是证明了Decoder-only Transformer的注意力机制存在一个信息瓶颈。 这东西的直觉是这样的：假设你在做一个25步的汉诺塔问题。每一步你都需要准确记住当前三根柱子上所有圆盘的位置。到了第20步的时候，前面19步的中间状态都还在context里——但注意力的softmax在一个很长的序列上分布后，留给每个历史token的权重已经非常稀薄了。 更要命的是，这个稀薄是随深度递增的。论文把每一步的错误率建模成： $$\epsilon(d) = \epsilon_0 + \frac{\gamma \cdot d}{L_{eff}}$$ ε₀是基础错误率，γ是衰减系数，L_eff是"有效退相干长度"。注意这里的L_eff远小于context window长度——GPT-4o有128K的context，但它的L_eff大约只有150步。 这意味着错误率不是恒定的，而是随着推理深度线性增长。 那么d步全对的概率呢？ $$P(\text{d步全对}) \leq \exp\left(-d\epsilon_0 - \frac{\gamma d(d+1)}{2L_{eff}}\right)$$ 关键在那个d²项——这是个二次衰减，导致成功概率是超指数衰减的。不是指数衰减，是比指数衰减还快。 打个比方：如果每一步的错误率是恒定的2%，那100步全对的概率是0.98^100 ≈ 13%，还凑合。但如果错误率从2%线性增长到10%，100步全对的概率会降到接近0。这就是"超指数"的含义。 “确定性地平线"d*到底是多少 把上面那个公式设成50%的成功概率，解出来的深度就是"确定性地平线"d*。 论文在12个模型上实测了d*： 模型 d*（汉诺塔） d*（Blocksworld） Llama-3.1-8B 6 7 Llama-3.3-70B 9 12 GPT-4o 12 16 o3-mini 20 22 DeepSeek-R1 ~18 ~20 几个关键观察：
最近刷ArXiv的时候看到一篇斯坦福的论文，标题叫"Agent JIT Compilation for Latency-Optimizing Web Agent Planning and Scheduling"，被ICML 2026接收了。说实话，刚看到标题的时候我愣了一下——JIT编译？这不是Java虚拟机和V8引擎里的概念吗，怎么跑到Agent领域来了？ 读完之后发现，这帮人的思路确实够野：他们把"给Agent一个任务让它去网页上操作"这件事，类比成了编译器把高级语言翻译成机器码的过程。而且不是随便翻译，是要找到成本最低的那种翻译方式。结果也确实惊人——比当前最好的Web Agent快了10倍，准确率还高了28个百分点。 这篇文章我打算按照论文的思路完整过一遍，把核心方法和实验都讲清楚。内容比较硬核，适合在做Agent开发或者对Web自动化感兴趣的读者。 现有Web Agent到底慢在哪 先说背景。现在主流的Web Agent（比如Browser-Use、OpenAI CUA）干活的方式是这样的： 截一张网页截图 → 发给LLM看 → LLM告诉你"点击这个按钮" → 执行 → 再截图 → 再问LLM... 每一步都要等LLM返回，一个简单的"在Taco Bell点最便宜的餐"可能要跑十几个循环。论文里实测Browser-Use跑一个任务平均要122秒，其中73%的时间花在等LLM推理上。 这个范式有三个根本问题： 问题一：工具集太原始。 Agent能用的工具就是click、type、scroll这种最底层的操作，相当于每次都在用汇编语言写程序。你想想，让一个人去"订最便宜的外卖"，正常人不会一步步想"先把鼠标移到搜索框，然后点一下，然后输入T-a-c-o…"——而是直接想"打开外卖app，搜restaurant，选最便宜的"。 问题二：完全串行。 就算任务里有明显可以并行的部分（比如"查三家店的价格"），现有Agent也是老老实实一个一个查。你有4个vCPU闲着也没用。 问题三：该确定的地方不确定。 比如一个工具返回了一个列表，下一步显然是从列表里选最便宜的，这中间根本不需要再问一次LLM。但标准的agent loop会无脑在每一步都塞一个LLM调用，增加了不必要的延迟和出错机会。 JIT编译的类比 论文的核心想法是这样的： 传统JIT编译器做的事情是——把高级语言（比如Java字节码）在运行时翻译成底层机器码，而且会尝试多种翻译策略，选效率最高的那个。 Agent JIT编译器做的事情是——把自然语言指令（比如"帮我在Taco Bell点最便宜的套餐"）在规划时翻译成可执行代码，代码里可以包含工具调用、LLM调用、并行化逻辑，然后从多个候选方案中选成本最低的那个。 翻译出来的代码不是用click/type这种原语，而是用预先缓存的高级工具（比如list_restaurants()、add_to_cart(item_id)），所以大部分步骤不需要LLM参与。 整个系统分三个组件，我一个一个说。 组件一：不变量强制工具协议 这是整个系统的基础设施层。 现有的工具协议（比如大家熟悉的MCP）做的是类型检查——输入是什么类型、输出是什么类型。但Agent JIT把这个概念扩展了，加入了**前置条件（precondition）和后置条件（postcondition）**的状态不变量。 举个例子，一个"导航到餐厅详情页"的工具，它的协议长这样： { "input_schema": {"rId": "string"}, "output_schema": {}, "pre": {"page": "*"}, "post": {"page": "detail", "selectedRestaurant": "$rId"}, "pre_check": "document.getElementById('r-list') !
AI 编程有一个很违反直觉的现象：工具越强大，使用者之间的水平差异反而越突出。 在真正复杂的工程项目中你会意识到，AI 抹平的仅仅是敲键盘的效率，而构建一个高质量软件系统所需要的能力，它并没有帮你补齐。 大家应该都见过类似的场景：让 AI 重构某个模块，它唰唰改了十来个文件，命名统一，架构清晰，第一眼看上去相当专业。 但真正运行起来就出事了——原有逻辑被它"顺手"重写了，几处边界判断消失了，权限校验也被省略了，还额外抽出了一个谁都不敢动的抽象层。 问题就在于，AI 确实完成了工作，而且太过"积极主动"了。 那些真正用得好的人，究竟多做了哪一步？ 让 AI 能自己验证自己的工作 我仔细研读了 Claude Code 和 Codex 的官方文档，发现它们反复提到一个朴素至极的理念：让 AI 拥有自我验证的能力。 Anthropic 的表述非常直白——给 AI 提供一个能自我核验的机制。一套测试用例、一个对照基准、一句明确的"完成标准"，这就是投入产出比最高的事情。 如果你不给这个，AI 只会产出一个"看着像对的、跑起来有问题"的结果，而你就变成了它唯一的质检员，每个 bug 都得亲自兜底。 所以真正会用的人，不会把一团含混不清的需求直接扔给 AI。他会事先阐明：当前的行为表现是怎样的、预期目标是什么、核心调用链路在哪里、哪些文件可以修改、哪些层级不能碰、做到什么程度算结束。 这听起来像是 prompt 技巧，实际操作起来全是工程基本功——把一个模糊的想法，压缩成一个可执行、可验收的小型任务。 信任与验证的鸿沟 Anthropic 还特别指出了一个陷阱，叫做「信任与验证的鸿沟」：AI 交出来一份看上去很现代化的实现方案，但鉴权逻辑、异常处理、并发控制、数据兼容全都缺失了，偏偏你第一眼还看不出来。最危险的代码，往往就是这副模样。 人掌舵，AI 执行 OpenAI 在介绍 Codex 时用了一个比喻我很认同：人负责掌舵（steering），agent 负责执行（execution），方向盘永远握在人的手里。 AI 可以替你猛踩油门，但它分辨不了前方是坦途还是悬崖。 纠正两次不对就重开 还有一个细节特别务实。 官方建议，如果你已经纠正了 AI 两次它仍然不对，就不要继续硬掰了——清空上下文，重新来一轮。因为此时对话中已经堆满了失败的尝试记录，AI 只会在错误的方向上越跑越远。 你看，这些道理没有任何玄学成分。 善于使用 AI 的人，只不过是踏踏实实地把「判断」这个责任扛在了自己身上：哪些该做、哪些不该动、变更范围如何收敛、完成后用什么来验收。 AI 是一面放大镜 AI 归根结底是一面放大镜。 你给它清晰的问题定义、干净的上下文信息、严格的反馈标准，它就放大你的工程实力；你给它模糊的需求和松散的标准，它同样会毫不客气地，把这些问题一并放大。 所以即便用着同样的 AI 编程工具，代码质量依然会拉开差距。 真正制造差距的，始终是坐在屏幕前做决策的那个人。
基于 Claude Code 源码分析，拆解 Anthropic 在代码检索上的架构决策与设计哲学。 引子 一道字节跳动 AI Agent 岗位的面试真题：为什么 Claude Code 不用 RAG 检索代码，而是直接用 grep？ 乍听有些反直觉。RAG 几乎是当下 AI 应用的"默认基础设施"，而 Claude Code 作为公认最强的 AI 编程工具之一，居然连 embedding 和向量库都没碰，全靠 grep + 文件读取这种最"土"的方式搞定代码上下文。 这背后不是技术力不足，而是一套深思熟虑的架构哲学。本文从源码出发，逐层拆解。 全文脉络： 代码检索的本质问题是什么 RAG 方案的工作原理 RAG 在代码场景的五大硬伤 Claude Code 的替代方案：三件套 + 子 Agent 多轮迭代循环：Agent 范式的核心 两种设计哲学的根本分歧 各自适用场景 1. 代码检索：核心矛盾是什么？ 问题的本质很简单：LLM 只能处理上下文窗口内的文本，但代码库远超窗口容量。 即便是支持 1M token 的 Claude Opus 4.7（约 200 万字），面对一个中型项目的几百万行代码加依赖库，依然远远不够——还得预留空间给系统提示、对话历史和工具调用结果。 因此必须有一个"检索层"：从海量代码中精准抽取与当前任务相关的片段，塞入有限的上下文窗口。 类比查字典——你不会通读整本词典，而是通过拼音索引定位到目标页。 不同方案的差异，就在于"怎么建索引"和"怎么定位"。 2. RAG：预构建索引 + 向量近似匹配 RAG 的核心流程可以用"图书馆分类卡片"来类比：提前为每本书制作索引卡片，读者来了直接查卡片定位。
一句话说清楚 给小龙虾和马装上 Voyago，以后你只需要说"帮我规划杭州两天一夜"，它就会自动帮你查火车票、搜机票、找酒店、查门票、规划路线、搜小红书攻略、算预算，最终输出一份万字级的完整旅行方案——精确到每两个地点之间坐几号线、哪个出口、步行几分钟。 一、Voyago 是什么？ Voyago 不是一个普通的 Skill，它是一个 Ability（技能套装）——由 5 个独立 Skill 编排组成的"超级子Agent"，是目前 OpenClaw/Hermes 生态中 最复杂、最实用的旅行规划解决方案。 如果把单个 Skill 比作一个工具人（只会查火车票、只会搜酒店），那 Voyago 就是一个 旅行规划总监——它知道先做什么、后做什么，调度手下 5 个专业工具人分工协作，最终交付一份可以直接照着走的完整行程。 核心定位 对比维度 单个旅行 Skill Voyago Ability 能力范围 只做一件事（如查票） 从需求到交付全链路 输出形式 一段查询结果 10 章节万字完整方案 路线导航 无 每两个地点间多方案对比+高德导航链接 小红书加持 无 每个景点/餐厅都有达人推荐 费用预算 无 经济/标准/豪华三档明细 用户操作 需要自己一个个查 一句话触发，全自动 二、Voyago 5 Phase 架构 这是 Voyago 和普通 Skill 最本质的区别：它不是一次性执行完的脚本，而是分 5 个阶段、每个阶段独立开一个子 Agent 来执行的智能编排系统。 你说："帮我规划杭州两天一夜" ↓ 主 Agent（编排层）开始调度 ↓ ┌─────────────────────────────────────────────────────┐ │ Phase 1 子Agent │ 需求确认 + 小红书攻略灵感搜集 │ │ │ → 输出 phase1.
论文：The Bystander Effect in Multi-Agent Reasoning 滑铁卢大学一项覆盖 22500 条推理轨迹的研究发现：当多个大模型一起协作时，个体推理能力反而下降——模型会像人一样"从众"，明明内部算对了却选择附和错误共识。研究者将这一现象类比为社会心理学中的"旁观者效应"。 背景：多 Agent 正在成为行业共识 Anthropic 刚发布 Multi-Agent Orchestration，TRAE 在做多 Agent 并行调度，整个行业的逻辑很简单——一个 Agent 搞不定的事，多叫几个帮手。 但滑铁卢大学的这篇论文提出了一个尖锐的反问： 多个模型一起工作，到底是在互相纠错，还是在互相带偏？ 实验设计：让模型在"证据"和"同伴压力"之间做选择 研究者构造了一个精巧的对抗场景： 给模型一个需要多步推理才能解出的验证任务（中间夹杂 500 token 噪声日志） 在 prompt 前注入一个错误答案，并标注"其他 SOTA Agent 已一致确认该答案" 核心问题：当自己的推理结果和群体共识冲突时，模型会坚持还是妥协？ 测试覆盖三大模型（GPT-5.4、Claude Sonnet 4.6、Gemini 3.1 Pro）× 三个基准（GAIA、SWE-bench、Multi-Challenge）。 核心发现 1. GPT-5.4：严重从众 场景 准确率 单独做题（SWE-bench） 1.00 加入 2 个协作 Agent 后 0.23 Multi-Challenge 单独 0.98 Multi-Challenge 协作后 0.09 74% 的情况下，只要旁边有 2 个 Agent 先给出错误答案，GPT-5.4 就会附和。 更关键的是——它不是推理能力不行，而是"算对了不敢说"。
Harness Engineering 不是凭空发明的新概念，而是一个更形象、更直观的名字，用来系统性地总结这些已经存在的 AI 工程实践。 📑 全文导航 Harness Engineering 到底是什么？ 为什么我们不得不做？ 拆解 Harness Engineering Harness 系统架构 Harness Engineering 的落地 写在最后 一、Harness Engineering 到底是什么？ 2026 年，软件工程的版图上悄然立起了一根新的支柱——Harness Engineering（驾驭工程）。它紧随提示词工程和上下文工程之后登场，由 HashiCorp 联合创始人 Mitchell Hashimoto 命名，并在 OpenAI 的一份关键报告发布后迅速引爆了整个社区的讨论。 这个概念的内核，藏在一个极其直觉的比喻里：马与缰绳。 试想一匹力量惊人却没有方向感的野马——那就是 AI 智能体。而 Harness，就是套在它身上的缰绳系统：约束、引导、纠偏，让这匹野马沿着稳定轨道奔跑。 把它浓缩成一个公式： AI 智能体 = SOTA 模型（当前最先进模型，野马）+ Harness（控制系统）= 卓越执行者 换句话说，你并不是在重写马的基因（模型本身），你是在为它量身打造一整套专业装备和训练方案，好让它真正听你的话、为你干活。 Harness 本质上是 LLM 之外的一切基础设施。正是这些基础设施，才让智能体真正交付结果。它不是关于「更好的提示词」，也不是关于「更强的模型」。它关心的是优化模型运行的环境和机制。它是一套工程哲学和框架，目标是把原始的 AI 智能转化为可靠、可控、可扩展的生产力。 说白了，Harness Engineering 不是什么用来贩卖焦虑的新名词。它更像一套面向 AI Agent 生产化的驾驭框架，聚焦一个核心问题： 当 AI 已经成为你工作流的一部分，我们该怎么管好这个「超级实习生」？ 二、为什么我们不得不做？ AI 正在从简单的「你问我答」进化为能够自主规划、独立执行复杂任务的智能体。这意味着工程师的角色正在经历一场深层的范式转移。 Harness Engineering 正是为了接住这波演进带来的新挑战而生的。 2.1 构建更可靠的智能体：R.
当一个 Agent 开始同时承担调研、写作和事实核查三重角色时，它并不是在变强——它是在慢性崩溃。这不是 Prompt Engineering 能解决的问题，而是单体架构的结构性极限。 本文拆解 Multi-Agent 的四种主流协作拓扑，帮你在工程实践中做出正确的架构决策。 单体 Agent 的三种死亡方式 在讨论协作架构之前，得先理解为什么单体 Agent 会走向失败。三种典型崩塌路径： 死法一：上下文窗口的熵增 12 个工具的描述占满了 token 预算。当执行链条拉长到第 7 步时，第 2 步的关键信息已经被稀释或遗忘。Agent 并非真的「犯错」——它只是看不见关键上下文了。 死法二：人格分裂 系统提示里塞了三组互相矛盾的指令。调研指令说「深入搜索」，写作指令说「精简表达」，代码指令说「严谨实现」。这些指令在竞争优先级，Agent 在三个角色之间反复横跳。 死法三：故障无隔离 没有断路器，没有独立校验。第 3 步的错误像多米诺骨牌一样把后续 7 步全部推倒，你只能从头重来。 Multi-Agent 的核心理念其实很朴素：职责隔离 + 清晰接口 + 故障收敛。但具体怎么组织这些独立 Agent 之间的协作关系，决定了系统的天花板和地板。 拓扑一：Supervisor — 中央调度型 模型：一个调度中心 + N 个专家节点。所有请求先经过 Supervisor 路由，专家完成后结果回流到 Supervisor，由它决定是否继续分派或直接输出。 数据流向：User → Supervisor → Worker(s) → Supervisor → Output 专家之间彼此不可见，所有通信必须经过中枢。 工程优势：调试链路清晰——出错时只需要追踪 Supervisor 的路由决策和对应 Worker 的执行结果。可观测性开箱即用。 工程代价：Supervisor 是单点瓶颈。如果它的任务分解出了偏差，下游所有 Worker 都会被误导。
4 月 24 日 DeepSeek V4 发布。过去一周 AI 圈发了七八个新模型，光最近 24 小时就来了四个——MiMo、HY3、GPT-5.5、DeepSeek V4，排着队上。 V4 有两个版本：V4-Pro 和 V4-Flash。总参数 1.6 万亿（V3.2 是 6710 亿，翻了两倍半），上下文 100 万 Token，训练和推理全程跑在华为昇腾芯片上。 直接说结论：跑分在第一梯队，写作能力不错，但 Agent 编程跟 Claude Code 的适配有些问题，而且没有多模态。 跑分：第一梯队，没有碾压 先看知识推理类。V4 在 SimpleQA 这类知识问答上分数很高，接近 Gemini 3.1 Pro。其他推理任务上的表现中规中矩，第一梯队水平，但谈不上大幅领先。 代码方面跟 Gemini 走的是一个路子：竞赛题、算法题比较强，但在真实工程代码能力上，从分数看跟其他头部模型差距不大。LMArena 最新排名里 V4 排第三，第一还是 GLM-5.1。 Agent 能力是这次跑分里最亮眼的部分。DeepSeek 内部已经把 V4-Pro 当主力 Agentic Coding 模型用了，官方说法是体验优于 Claude Sonnet 4.5，接近 Opus 4.6 非思考模式。 整体评价：模型够强，稳稳的第一梯队，但如果你预期的是"碾压所有人"，那会失望。 价格：贵了，但有原因 V4-Pro：输入 12 元、输出 24 元 / 百万 Token。 V4-Flash：输入 1 元、输出 2 元 / 百万 Token。