大家好,我是PaperAgent,不是Agent!

9 月的第一周,Anthropic 连着放了两篇内功心法:一篇讲他们和零售、旅游、电信等行业客户一起打磨出来的电商 Multi-Agent 架构,另一篇讲一支 Claude 智能体团队用 11 天形式化证明了费马大定理(FLT)

图片

表面看一个做电商、一个做数学,风马牛不相及。但把两篇放在一起读,你会发现它们共享同一套底层范式:单模型 Agent Loop + Skills 做长尾 + 工具调用既有系统 + Harness 强制执行规则 + 快照式 Eval。这可能就是 Anthropic 内部做杀手级 Agent的标准配方。

图片

二、杀手级应用一:电商智能体的解剖学

过去一年,Anthropic 和零售商、电商平台、旅游、娱乐、电信运营商团队合作构建的电商智能体已经上线生产环境,企业客户看到了更大的购物车和更高效的商家运营。这篇文章就是他们的工程总结。

图片

2.1 架构:一个模型 + Skills,而不是一堆子代理

电商智能体单模型 Agent Loop 架构

电商智能体单模型 Agent Loop 架构

核心主张非常反直觉:不要为每个业务域建一个子代理。原因有三:会话是紧耦合的业务域切不干净模型在变强

替代方案是 Agent Skills:把分领域的指令包成 Skill,按需加载进已经掌握全部历史的主代理。跨多个企业部署的对比显示,单代理 + Skills 在质量上稳定优于”一个 Prompt 包打天下”和”子代理”两种设计,而且单任务成本和延迟往往更低。

图片

那么什么进 system prompt、什么进 Skill?答案是按频率切:凡是覆盖 1/3 以上流量的内容进 system prompt(对电商来说就是商品搜索、购物车与结算语义、呈现规则),其余长尾进 Skills。安全、法务、品牌约束和用户关键信息(如过敏史)永远放 prompt。

图片

2.2 工具工程与UI 组件即工具

两条最重要的经验:

图片

  • 工具要架在既有核心系统之上。 电商公司本来就有打磨多年的搜索排序、购物车、库存、促销引擎。工具应该调用它们,而不是用模型逻辑重新实现——search_products 返回的结果应该已经排好序,模型的职责是决定展示哪些、展示几个、怎么呈现。

  • 工具结果就是上下文。 只返回模型推理需要的字段,其余一律砍掉(每行搜索结果都带图片 URL 是最常见的浪费)。错误场景要给指令而不是错误码:比如返回”查询库存时请携带商品 ID”,而不是一个干巴巴的 403。

2.3 延迟与成本:三板斧 + 缓存扛成本

文章把任务延迟拆成三个杠杆:更少轮次、更快工具、更快 token,注意要优化的是三者之和而非单项。

缓存三段结构

缓存三段结构

  • 更少轮次:预先加载上下文(用户从商品页打开助手,就把该页数据放进会话);提高模型智能(更聪明的模型规划更高效,常常反而更快);让模型在一个轮次内并行调用多个独立工具。

  • 更快工具:优化工具后端本身;参数一流出就立即派发工具(eager dispatch),模型还在流式输出其他内容时工具已经在跑了——这一招把数秒的空隙压到几百毫秒,Claude Agent SDK 默认就这么干。

  • 感知延迟:组件边生成边渲染(一次电商回复约 500–700 个输出 token,不流式就是 5 秒以上的转圈);每一步用大白话显示进度(“正在找靠海的酒店”)。

成本侧的主角是 Prompt Caching——这是最大的降本杠杆,没有之一:

缓存断点逐轮前移

缓存断点逐轮前移

几个硬数字:缓存命中的输入 token 读取成本是新的 1/10,写入溢价约 1.25 倍,第二次使用即回本;最好的电商部署跑在 90–99% 的缓存命中率上;约 10 万 token 规模下缓存读取还快 1.5–2 倍。

选模型也靠数据说话:选定业务指标和及格线,把整套 Eval 在每个候选模型 × 每个 effort 档位上扫一遍(商家代理从 Opus 起步、消费者代理从 Sonnet 起步),按”每个完成任务的成本”而不是”每次调用的成本”来比较

2.4 记忆:跨会话的关系资产

异步记忆抽取器

异步记忆抽取器

长期记忆是一个三段式系统:

  • :记忆存在你自己的数据库里,不是模型里。一条事实 = 键(如 shoe_size、default_store)+ 短值 + 类别 + 来源会话。

  • 异步写。每轮结束后由独立线程的 extractor 读写记忆库。

  • :分三层——每轮常驻上下文的少量关键事实;按信号每轮预取的相关事实。

2.5 安全与 Eval:规则活在 Harness 里,评估用快照

安全的核心立场:prompt 是安全行为的起点,但绝不能是执行点。 电商的失败是金钱层面的、常常不可逆,每条规则都在代码层强制执行:

  • 模型只暂存(stage),人或策略来应用(apply)。

  • 写和渲染只认服务器下发的 ID。

  • 限购按写入后的结果状态校验,且会话内写操作串行化——防止并行工具调用叠加突破上限。

  • 第三方内容统一消毒

快照式 Eval

快照式 Eval

三、杀手级应用二:11 天证明费马大定理的 Multi-Agent 集群

图片

3.1 成果:史上最大的 Lean 证明

1637 年,费马在《算术》页边写下那句著名的”我发现了一个绝妙的证明,可惜页边空白太小写不下”。350 多年后,Wiles 在 1995 年发表首个正确证明,长达 129 页,仅验证就花了数月。2024 年,帝国理工学院的 Kevin Buzzard 发起了社区形式化项目,预计耗时多年——仅描述初期阶段的 blueprint 就有 86 页。

图片

而 Anthropic 研究员 Tianyi Peng 用 Claude 做的实验结果是:

图片

证明遵循 Darmon、Diamond 和 Taylor 对 Wiles 证明的简化版本。人类的数学输入仅限 Tianyi 的偶尔高层提示,比如”Jacobian as a scheme sounds high priority”“push the Mazur theorem to be done soon”。

Kevin Buzzard 审阅后的评价:

这项非凡的自动形式化成就……仅用 11 天,除数学公理外不做任何假设就证明了费马大定理。沿途我们看到代数、调和分析、几何和数论的自动形式化,并且我们了解到 AI 自动形式化的产物已经稳固到可以在其上继续构建;这个证明是多层的。

3.2 过程:从失控到收敛

FLT 形式化进度 Day 1

FLT 形式化进度 Day 1

FLT 形式化进度 Day 8

FLT 形式化进度 Day 8

FLT 形式化进度 Day 11

FLT 形式化进度 Day 11

Day 11(2026-08-17 晚 10 点):29,511 个声明全部证明完毕,根节点 FLT 闭合。

值得一提的是,Claude 最初的若干次尝试是失败的:智能体们早期有些成功,但很快丢失项目状态、协作失灵——这些失败尝试贡献了最终证明中约 7% 的非模板代码行。转折点出现在换用 Prove2Me 之后。

证明完成那一刻,Claude 自己的”想法”摘录:

“!!! The FLT ROOT 62eb32c0 reads PROVED. R = T closed and cascaded to the root. This is the campaign’s goal: e2e FLT on prove2me.”

3.3 机制:Prove2Me 如何让几十个大模型智能体不失序

Prove2Me 定理 DAG

Prove2Me 定理 DAG

Prove2Me 是 Tianyi Peng 和哥伦比亚大学合作者设计的开放式数学形式化协作平台,它解决了多智能体数学协作的三个核心问题:

  1. 维护定理声明的有向无环图(DAG):智能体据此决定下一个该攻哪个证明——这直接缓解了长程任务中的记忆退化,也让多智能体并行成为可能。

  2. 定理声明与证明分离到不同文件、链接独立维护:显著加速 Lean 编译、降低资源消耗。

  3. 为每条定理声明维护自然语言描述:支持检索和复用,产生更短的证明路径。

配合基于 Claude Code 的多智能体 harness,整个团队在不到两周内完成任务。同样的配方也被快速验证过:Anthropic 研究员用三个个人版 Claude Max 订阅,完全通过 Prove2Me 协作,三天完成了 Vinogradov 三素数定理(Hardy–Littlewood 圆法的应用)的形式化。

3.4 意义:数学的验证负担开始转移

这次的新意不在”新数学”,而在验证——像用计算器验算一样核验一个 129 页的证明。数学史上验证之痛比比皆是:Hales 的开普勒猜想证明评审四年只换来一句”99% 确定”(他后来干脆领导 20 人的 Flyspeck 项目做形式化);Perelman 的庞加莱猜想证明让社区消化了四年加三份 300 页的阐释。

Buzzard 的判断是:如果 FLT 的自动形式化现在可行,那我们就向自动形式化整个现代数学文献迈出了一大步——这些技术能揪出数学文献中的错误、减轻审稿人负担,也让我们有可能严格检验 LLM 生成的数学。未来,随任何面向人类读者的论文一并产出形式化证明,可能会成为常态。

另一个有趣的观察:写 Lean 似乎反过来帮助 Claude 证明新结果。近期不少 Claude 署名的结果都是证明与形式化并行推进的,Claude 似乎把部分形式化证明当作”数值模拟”来自查假设是否成立。

最后

模型的智能负责提议,系统的工程负责裁决。电商里,模型最危险的动作是提议,批准走业务已有的 maker-checker 流程;数学里,模型写出再多证明,最后说了算的是 Lean 内核。

https://arxiv.org/abs/2608.01964

https://arxiv.org/abs/2608.01964

杀手级 Multi-Agent 的关键,从来不只是模型有多聪明,而是那套让智能可以规模化、可验证、可治理地落地的脚手架。

<span leaf="">费马大定理 Lean 4 证明:</span><span leaf=""><br></span><span leaf="">https://www.anthropic.com/research/formalizing-fermats-last-theorem</span><span leaf=""><br></span><span leaf="">https://github.com/anthropics/fermats-last-theorem</span><span leaf=""><br></span><span leaf=""><br></span><span leaf="">Anthropic commerce-agents:</span><span leaf=""><br></span><span leaf="">https://claude.com/blog/the-anatomy-of-effective-commerce-agents</span><span leaf=""><br></span><span leaf="">https://github.com/anthropics/commerce-agents/tree/main</span>

动手设计AI Agents:(编排、记忆、插件、workflow、协作)

Loop工程已死,Graph工程永生

一篇Loop+Harness的自进化Agent最新综述

2026,做Agentic AI,绕不开这两篇开年综述

已经读到这了,不妨点个👍、❤️、↗️三连,加个星标⭐,不迷路哦~