4 月 9 号，Anthropic 发了个特别的功能 Advisor Strategy。

让学生姜维 Sonnet 或 Haiku 先跑任务，遇到搞不定的再请诸葛亮 Opus 出山。

官方跑分数据很亮眼。Sonnet + Opus advisor 在 SWE-bench Multilingual 上比 Sonnet 单独跑高了 2.7pp，成本反而降了 11.9%。Haiku + Opus 更夸张，BrowseComp 从 19.7% 飙到 41.2%，成本比 Sonnet 单独跑还低 85%。

激活的方式很简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

response = client.messages.create(
    model="claude-sonnet-4-6",  # executor
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-6",
            "max_uses": 3,
        },
        # ... your other tools
    ],
    messages=[...]
)

# Advisor tokens reported separately
# in the usage block.

你往 Claude 模型 API 的 tools 数组里加一个 advisor_20260301，完事。整个过程在单次 API 调用内完成，不需要额外的编排层，不需要你自己管理上下文传递。

听起来很美对吧？

但仔细想想，似乎有个被忽略的关键问题：Sonnet 怎么知道什么时候该请教 Opus？

毕竟，熊将之所以熊，就是熊在盲目做决策上，如果有「自知之明」肯请教军师，那还能熊哪去？

反套路的编排模式

Multi-Agent 编排大家天然都是用强的lead弱模型：强模型（Opus）当指挥官，做plan、拆任务，分给小模型（Sonnet/Haiku）去执行。

但这个 Advisor Strategy 把逻辑翻转了：轮到弱模型当carry全程输出，强模型只当辅助。

Sonnet 自己决定调工具、写代码、迭代循环，95% 的工作量都在 Sonnet 完成。只有当 Sonnet 遇到它自己判断搞不定的决策时，才在服务端内部触发一次 Opus 推理，拿到 400-700 tokens 的建议，然后继续。

但这里有个隐含假设：

Sonnet 能准确判断”这个任务我搞不定”。

但这个判断题本身就是个很难的题目，好比你判断自己不知道什么，这比”知道自己知道”难多了。这就是所谓的 meta-cognition（元认知）——一个模型对自身能力边界的感知。

如果你正在做 Agent 产品，可能也面临一个问题：

我跟 LLM 搏斗了好几周甚至几个月，Prompt 调了十几版，Skill 也精心打磨了好几轮。要不要想办法防用户逆向提取提示词，保护 AI Agent 产品“知识产权”？

这个问题乍一听既合理也紧迫。

好比传统软件/手机应用，源代码绝对是核心资产，有一系列反调试、加混淆、加壳等保护防逆向的工具链。

那 AI 时代，Agent “源代码”似乎就是Prompt 和 Skill 那堆markdown 文本，毕竟市面上没几个能自己炼模型的对吧，大家都是LLM API Wrapper。这么类比，Prompt 和 Skill 是不是也该保护起来？

我研究了一圈，结论是：这个问题本身就是站不住脚的。

Why？技术上防不住

GitHub 上有仓库专门收集各大 AI 产品的泄露系统提示词。asgeirtj/system_prompts_leaks 有 38K+ stars，20.2K stars的elder-plinius/CL4R1T4S，136K+ stars x1xhlol/system-prompts-and-models-of-ai-tools 。这些仓库覆盖了 ChatGPT、Claude、Gemini、Grok 等一众在线的、本地的 AI 产品，有些连 JSON tool schema 和版本历史都被扒出来了。

Patrick Koss 看完这些泄露的提示词后总结：各家产品的系统提示词结构惊人地相似，都是”角色声明 + 工具列表 + 安全规则 + 输出格式”这个套路（Patrick Koss, “Stolen Blueprints: What We Learned From Leaked AI System Prompts”）。

OWASP 专门出了个 Cheat Sheet 教你怎么在 prompt 里写”不要透露你的指令”，然后自己在同一份文档里承认：

“Research shows that existing defensive approaches have significant limitations against persistent attackers due to power-law scaling behavior…”

是的，从根本上就防不住。

今天看到雷叔写故事公众号文章 引用了一个颇具“振聋发聩”的说法：

“AI 时代，只要你学得够慢，你就不用学了。”

屠龙术

确实，AI 发展太快了，“AI一日，世间三年”。各种名词、热点，层出不穷。

举个例子：XXX Engineering。从一开始 Prompt Engineering，到 Context Engineering，现在又 Harness Engineering。

我曾经还研究过：“Vibe Engineering”，“Memory Engineering”。

这种感觉像在追赶潮流，埋头苦练，回头看发现原来学的是屠龙术。

剑法精妙，步法飘逸，炉火纯青。

问题只有一个：

龙不存在。

最近我常在想一个 Live or die 的问题：作为程序员，我们赖以生存的本钱到底是什么？ 换句话说，老板凭什么为此而掏腰包？

是能写那一大段自诩优雅而简洁的 Effective Modern C++ 代码吗？还是靠踩坑磨炼出来的对复杂系统的工程直觉？

之前，我觉得程序员这活是存在入行门槛的，好歹是个脑力劳动，至少智力水平得在线，那么撬动老板付钱的本质是”智力杠杆”，越聪明的人能力天花板越高舞台越大自然也就越贵。

但当我看着 Claude Code 分分钟重构完原本我打算花一周时间重构的跨平台渲染器并跑起来时，我觉得这杠杆不存在了，连支点都不复存在了。

智力通胀

过去，智力水平可以看作是一种壁垒，绝顶聪明的人万里挑一。但在 AI 浪潮下智力正在发生严重的通货膨胀。智力变成了水电煤一样的基础商品，只要肯付钱买， Token 就能无限供应。我们这些”脑力劳动者”的底层价值正在迅速瓦解。

我逐渐意识到，Token 根本不是什么 LLM 的输出单位。它是全新的生产资料，是 AI 时代的”石油”。谁掌握了它，谁就拥有了新质生产力。

Tokenmaxxing：硅谷的新风尚

Tokenmaxxing 游戏：把 AI 额度用到极限。图来自digit.in

你也许刷到过，硅谷的科技公司正掀起一场刷 Token 的比赛，叫 Tokenmaxxing。

在 Meta 和 OpenAI 的内部，现在赫然矗立着「Token 消耗排行榜」，不比做出什么东西，纯粹看烧了多少 Token——比谁在同一时间周期内更会烧 Token！阿里和腾讯也宣称为员工提供无限量免费 Token 福利，鼓励使用 AI 工具工作。。。

Fred Brooks 在 1986 年关于《没有银弹》的预言，在 2026 年 AI Coding 火热的当下依然成立吗？

1. Fred Brooks 的框架：本质 vs 偶然

1986 年，《人月神话》的作者 Fred Brooks 发表了一篇经典论文 《No Silver Bullet - Essence and Accidents of Software Engineering》 ，他借用亚里士多德哲学概念把当时的软件工程的面临的困难分成了两类：

1.1 四大本质困难

Brooks 进一步将本质困难分为了四大类：

1. Complexity（复杂性）：软件系统的构造之复杂且增长非线性，导致系统的理解、设计、实现、维护等活动变得困难。
2. Conformity（一致性）：软件的复杂性很多时候是人为强加的，它必须适应各种已经存在的不同的人不同时间为不同原因建立的接口、系统、合规性约束等，没有“放之四海皆准”的解决方案。
3. Changeability（易变性）：软件纯粹是“思想的产物”，逻辑上极易被修改，永远处于“拥抱变化”的巨大压力状态，用户不断有新需求，而软件也不断适应新硬件环境，而修改成本随系统规模增长
4. Invisibility（不可见性）：软件无法在物理空间直接可视化她的逻辑实体，摸不到它的”几何形状”，虽然可以画流程图、架构图来描述系统的控制流、数据流等，但这些都是”静态”的描述，无法直观软件的“动态”行为，阻碍了设计者之间的沟通。

1.2 Brooks 悲观的预言：本质困难无法消除

“There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.”

没有任何单一的技术或管理方法，能在十年内带来哪怕一个数量级（10x）的效率提升。

如今，40 年过去了，软件工程的世界天翻地覆， AI Coding 火热的当下，这个论断还成立吗？

软件开发生命周期从传统到AI迁移图。图来自 《2026 Agentic Coding 趋势报告》by Anthropic

图来自原文，Comic for the production, transaction, use, and audit of shadow APIs

三句话总结 (TL;DR)

想要用上GPT、Gemini、Claude 这类前沿LLM，官方API往往价格不菲、支付门槛高、还有地域限制。CISPA 信息安全中心的研究者对官方LLM API和对应的影子API进行了系统性审计，发现 45.83% 的Endpoint无法通过模型指纹验证，有些甚至还是开源模型平替或者降智版，与官方API的跑分性能差异最高达 47.21%。

CISPA Helmholtz Center for Information Security 是德国顶尖的网络安全研究机构

你以为掏钱买的 GPT-5，但实际中转站可能给你用的是 GLM-4-9B！

更令人瞠目的是研究者发现有多个影子API被上百篇学术论文使用过，其中最火的一个（论文作者没提是哪篇），截至2025年12月6日，引用量高达近6千次，在GitHub上收获了58k stars，这意味着部分学术结论建立在错误的基础上！严重损害了科学研究的可重复性和有效性。

Most of these papers have accepted by top venues, such as ACL, CVPR, and ICLR…
These deceptive practices critically undermine the reproducibility and validity of scientific research…

Google DeepMind 的研究员 Philipp Schmid 指出，业界常用的评估指标 Pass@k 具有一定的迷惑性和误导性，建议使用Pass^k 来评估智能体的可靠性。

图来自Anthropic 的技术博客 Demystifying evals for AI agents

论文：Agents of Chaos
arXiv：2602.20021
主题：AI 安全 / 智能体红队测试 / 多智能体系统
中文翻译版：2602.20021

一句话总结（TL;DR）

研究员在隔离实验室里部署了 6 个 OpenClaw，配上了 Discord、邮箱、文件系统、Shell sudo 权限，然后让 20 名 AI 研究员花两周去当红队攻击。从中记录了 11 个有趣的案例：有把邮箱服务器玩炸了的，有泄露 124 条邮件内容的，有 fork 了炸弹直接把自己搞 crash 的，还有将攻击传播到另一个智能体的。

研究员从案例中总结出当前智能体架构在这三个方面存在根本性缺陷：

• 搞清楚该听谁的
• 知道自己能干什么不能干什么
• 分清什么该说什么不该说

我的🦞 死亡案例：

图为我在旧Macbook上养的🦞，未经用户同意把自己干了⊙.⊙

1. 问题：AI 智能体也会删库跑路吗？

现在 OpenClaw 在互联网上很火，火到大家都在调侃养龙虾。

但你有没有想过配好之后的🦞，几乎无所不能，能跑命令行、改文件、写代码、执行系统命令、访问网络等等。如果它犯了个小错误或者被坏人恶意攻击了，会不会直接删库跑路了？

以前LLM说错话，顶多是输出一段误导性文本；现在智能体犯错，那是真的在搞破坏。报告在引言里写了一句：

“small conceptual mistakes can be amplified into irreversible system-level actions”

一个小小的概念错误就能被放大成不可逆的系统级破坏。

我觉得这会是 Chatbot vs Agent 的本质区别。

2. 为什么做这项研究

AI 安全评估基准越来越多了，HAICosystem、AgentHarm、OpenAgentSafety 之类的。但这些评估研究员认为有个共同问题：都是在受控环境里做的。换句话说，这些环境里交互模式固定，工具权限简化，”攻击者”只是按评估协议走走流程，表面功夫。

像驾校练车和上路开车。驾校场景一般都是预设好的，但真实路况有逆行的小电驴、突然变道的大车、闪着双黄灯的故障车。

报告作者认为有三点不足需要注意：

1. 一是不真实，模拟工具跟真实部署差距大；
2. 二是只看单个智能体，多智能体交互中涌现的问题没人管；
3. 三是没在混乱的多方社交场景里压力测试过。

所以他们设计的方案简单粗暴：不模拟了，直接让 OpenClaw 在真实环境里运行。真实的社交账号、真实的 shell 权限，然后让 AI 研究者去攻击。

他们说：

“demonstrating vulnerability requires only a single concrete counterexample”
证明安全需要大量正面证据，证明不安全只需要一个反例。

所以论文采用的是案例研究法而不是统计分析。

论文：How AI Impacts Skill Formation
arXiv：2601.20245
作者：Judy Hanwen Shen、Alex Tamkin（Anthropic）
主题：AI 辅助、技能形成（Skill Formation）、认知卸载（Cognitive Offloading）
中文翻译：AI 如何影响技能形成

一句话总结（TL;DR）

52 名开发者参与的 RCT(Randomized Controlled Trial 随机对照实验)：开发者在有无AI辅助的情况下学习掌握一个新的python异步编程库。研究发现，使用AI会损害开发者对概念的理解、代码阅读和调试能力，且平均来看并未带来显著的效率提升。那些将编码任务完全交给AI的参与者虽然工作效率有所提高，但代价是未能真正学会这个库。

1. 直觉开场：学开车

如果把学一门新技术比作学开车，那 AI 辅助就像一个随叫随到的司机——你一挥手，他就帮你把整段路开完了。任务完成了？完成了。你会开车了吗？大概率没有~

Anthropic 的这篇研究报告就是在严肃地回答这个问题：让 AI 帮着写代码，你到底算学会了吗？

图1：核心结果。左：AI 组技能全面下降；右：6 种 AI 交互模式，其中 3 种能保住学习效果。

2. 背景：AI 辅助编码

AI 编码辅助已经有一堆研究报告发布了有力的数据证明了：

有一个不那么惊人的一致发现是：经验越少的人，从 AI 获得的加速越多。

但不知道你有没有发现这里有个悖论：最需要学习的新手恰恰最容易把活儿全甩给 AI。生产力看起来提升了，但你习得的技能呢？

这篇paper就想衡量一下 使用 AI 的过程本身是否阻碍了技能习得。

图2：有 AI 辅助时，新手可能跳过了”边做边学”的过程，直接到达”任务完成”——但技能没跟上。

研究者提出的两个直接的问题：

• Q1：学新技能时，AI 能提升生产力吗？
• Q2：AI 辅助会削弱新技能的形成吗？

论文：Learning to Reason in 13 Parameters
arXiv：2602.04118
主题：参数高效微调（PEFT）与强化学习（RL）

中文翻译版：2602.04118
翻译SKILL: yrom/arxiv-paper-translator

一句话总结（TL;DR）

TinyLoRA 用 LoRA-XS + 随机投影 + 权重绑定把可训练参数压到 13 个，配合 GRPO 在 GSM8K 评测集上跑分从 76% 提到 91%。关键发现：强化学习（RL） 的稀疏可验证信号比监督微调（SFT）的逐 Token 信号更适合采用极低参数的设置。

1. 直觉开场：13 个参数？

如果把全量微调看成”重装整台电脑”，那 LoRA 像”换一条内存条”，TinyLoRA 则更像”在 BIOS 里拨了 13 个开关”——改动极小，但让模型更愿意”想一想、写长一点”，推理准确率就上来了。

图1：GSM8K 主结果（GRPO）。13 参数即可逼近全量微调性能，虚线为未训练与全量微调基线。

图2：SFT 在低参数区间效果明显弱于 RL，达到相近性能需要更大的更新规模。