2026 年 4 月，MBZUAI（穆罕默德·本·扎耶德人工智能大学）VILA Lab 的 Liu、Zhao、Shang、Shen 四位研究者发表了一篇 46 页的论文——对 Claude Code 公开的 TypeScript 源码做了一次系统的"逆向架构考古"。这是第一次有学术团队认真读完 Anthropic 这款 agentic coding 工具的源码，并把它的设计哲学完整拆解。研究识别出 5 个人类价值观（决策权、安全、可靠执行、能力放大、上下文适应）→ 13 个设计原则 → 具体实现选择的清晰链条。核心发现震撼——真正"AI 决策逻辑"只占代码的 1.6%，剩下 98.4% 都是围绕一个简单的 while 循环构建的权限系统、5 层压缩管道、4 种扩展机制、子代理委托、append-only 持久化。本文是这篇论文的中文精校版——读完你就理解了"AI 代理软件工程"今天和未来的全貌。
2026 年 4 月，MBZUAI（穆罕默德·本·扎耶德人工智能大学，阿联酋阿布扎比的顶级 AI 研究机构）的 VILA Lab 四位研究者，做了一件之前没人系统做过的事——读完 Claude Code v2.1.88 公开的 TypeScript 源代码，把它的架构设计哲学完整反向工程出来。论文不在 NeurIPS 不在 ICML——在 arXiv，编号 2604.14228v1。但对今天每一个想理解 AI Agent 系统的工程师来说，它可能比那些会议论文都重要。Anthropic 自己有面向用户的文档，但没有架构级文档——MBZUAI 团队把这个空白填上了。
2026 年 4 月 14 日，Jiacheng Liu、Xiaohan Zhao、Xinyi Shang、Zhiqiang Shen 四位研究者（前三位在 MBZUAI VILA Lab，第三位同时在 UCL）在 arXiv 上传了一篇 46 页的论文——《Dive into Claude Code: The Design Space of Today's and Future AI Agent Systems》。
论文的目的非常明确——
Claude Code 是一个 agentic coding tool——
能代表用户运行 shell 命令、编辑文件、调用外部服务。
本研究通过分析公开的 TypeScript 源代码，
描述其全面的架构——
并和 OpenClaw（一个独立开源 AI agent 系统）对比，
展示同样的设计问题在不同部署语境下产生不同的架构答案。
这项工作做了两件以前没人做过的事——
第一——用源码级证据说明 Anthropic 的架构选择，而不是从产品描述推断。Anthropic 自己有面向用户的文档（code.claude.com/docs），但没有公开的架构文档。
第二——把 Claude Code 跟 OpenClaw（一个多通道个人助理网关）做架构对比——展示同样的设计问题在不同部署语境下产生不同答案——商业 vs 开源、CLI vs 网关、per-action 安全 vs 边界访问控制。
论文里有一个让我读完后停了很久的数字——
社区对提取源码的分析估算——
只有大约 1.6% 的 Claude Code 代码库构成"AI 决策逻辑"，
剩下 98.4% 是运营基础设施——
这个比例说明核心 agent 推理层多薄。
这件事让我想了一下——"我们一直以为 AI Agent 是 AI"——但事实是 98.4% 是软件工程。Claude Code 的强大不在于"决策逻辑写得多巧妙"——在于围绕一个简单 while 循环构建的极其复杂的工程脚手架——权限、压缩、扩展、委托、持久化。
论文还引用了 Anthropic 内部对 132 个工程师和研究员的调查（Huang et al., 2025）——发现大约 27% 的 Claude Code 辅助任务是"没有这个工具就不会被尝试的工作"。这说明 Claude Code 的架构使能了质的新工作流——而不只是加速已有的。
论文承接的"运行示例"很简单——把"Fix the failing test in auth.test.ts"这一个用户请求从第 3 节追到第 9 节——看它如何激活多个架构层。这种"追踪"式的写作让 46 页变得非常具体。
MBZUAI 团队的论文写法非常人本——"production coding agents are built by humans, for humans"——架构决策反映创造者认为什么重要。Anthropic 在 "Safe Agent Framework" 里写下核心张力——"Agent 必须能自主工作；其独立运作正是它有价值的原因。但人类应保留对'目标如何被追求'的控制"。Claude 的宪法不是用刚性决策程序解决这个张力，而是培养"可以情境化应用的良好判断和健全价值观"。论文识别 5 个塑造架构的人类价值观——Authority、Safety、Reliability、Capability、Adaptability。
论文第 2 节是整篇论文的灵魂——它不直接讲技术，而是先把"为什么这样设计"讲清楚。这是一种非常少见的论文写法——从价值观开始。
这 5 个价值观不是论文虚构的——而是论文从Anthropic 的公开文档、Claude 宪法、内部研究里抽离出来。最有意思的——论文还加了一个"评价之镜"，作为第 6 个非设计驱动的关注点——长期人类能力保留。Anthropic 的研究发现"supervision paradox"——过度依赖 AI 风险萎缩监督 AI 的技能。独立研究发现 AI 辅助下开发者理解测试得分低 17%。这件事不是 Anthropic 的设计驱动——但论文坚持把它作为跨切关注点来评价。
论文把 5 个价值观"操作化"成 13 个设计原则——每一个都回答一个 production coding agent 必须解决的反复出现的问题。最关键的几个——Deny-first + 人类升级（不识别的动作被拒/问，而不是允许）；渐进信任谱系（不是固定权限，而是用户随时间走的频谱）；分层防御（不是单一安全边界，而是多重重叠机制）；外部化可编程策略（不硬编码，而是配置 + 生命周期 hooks）；把 context 当作稀缺资源 + 渐进管理（不是一次性截断，而是分级管道）；append-only 持久状态（不可变 + 可审计）；最小脚手架 + 最大运营 harness（不投资规划器，投资基础设施）；价值观高于规则（不刚性程序，而是情境判断 + 确定性 guardrail）。
论文用一张表把 13 个原则、它们服务的价值观、它们回答的设计问题列出来。我挑几个最关键的——
论文把这套原则放到三大对手设计家族里对比——
第一——rule-based orchestration（如 LangGraph）——把决策逻辑编码为显式状态图 + 类型化边——选 scaffolding 而非 minimal harness。
第二——container-isolated execution（如 SWE-Agent、OpenHands）——依赖 Docker 隔离而非分层策略执行。
第三——version-control-as-safety（如 Aider）——用 Git rollback 作为主要安全机制而非 deny-first 评估。
Claude Code 的原则集独特之处——"minimal decision scaffolding + 分层策略执行 + values-based 判断 + deny-first defaults + 渐进 context 管理 + 可组合 extensibility"的组合。每一项单独都不新，组合起来是独特的"设计点"。
论文给出两个层次的架构图。高层 7 组件——User → Interfaces → Agent Loop → Permission System → Tools → State & Persistence → Execution Environment。所有交互入口（交互 CLI、headless CLI claude -p、Agent SDK、IDE）汇聚到同一个 agent loop——只有渲染层不同。5 层子系统——Surface（入口和渲染）+ Core（agent loop + 压缩管道）+ Safety/Action（权限 + hooks + 扩展 + 工具 + sandbox + subagent）+ State（context assembly + session persistence + CLAUDE.md）+ Backend（执行后端 + 外部资源）。重要的"安全 by default"通过 7 层独立保护实现——工具 pre-filter、deny-first rule、permission mode、auto-mode classifier、shell sandbox、不在 resume 时恢复 permission、hook 拦截。任一层都能阻断请求。
论文给出两层架构图。先是高层 7 组件——
claude -p）、Agent SDK、IDE/Desktop/Browser。所有 surface 都汇聚到同一个 agent loop。query.ts 里的 queryLoop() async generatorpermissions.ts）、auto-mode ML classifier、hook 拦截assembleToolPool() 组装sessionStorage.ts）、global prompt history、subagent sidechain 文件注意——所有交互入口都汇聚到同一个 agent loop，只有渲染和用户交互层不同。这是 Claude Code 架构最优雅的地方——"a single queryLoop() function executes regardless of whether the user is interacting through an interactive terminal, a headless CLI, the Agent SDK, or an IDE integration"。
论文接着展开5 层子系统架构——
· Surface 层——入口点 + 渲染。src/entrypoints/ 启动路径 + src/screens/ 全屏布局 + src/components/ 基于 ink 框架的终端 UI
· Core 层——queryLoop() async generator + 5 层压缩管道
· Safety/Action 层——权限系统（7 模式 + auto-mode classifier）+ hook 管道（27 个事件类型，其中 5 个安全相关，22 个生命周期/编排）+ 扩展子系统 + 工具池 + shell sandbox + subagent spawn
· State 层——context assembly + 运行时状态 + session persistence + CLAUDE.md + sidechain
· Backend 层——执行后端（BashTool、PowerShellTool）+ 远程执行（src/remote/）+ MCP 多种传输（stdio、SSE、HTTP、WebSocket、SDK、IDE 适配器）+ 42 个工具子目录
"safety-by-default"通过 7 层独立保护实现——请求必须通过所有适用层，任一层能阻断——
整个 Claude Code 的核心算法极其简单——一个 queryLoop() async generator 实现的 while-true 循环——每一轮做"设置解析 → 状态初始化 → context 组装 → 5 个 pre-model shapers → 模型调用 → 工具派发 → 权限检查 → 工具执行 → 收集结果 → 停止判断"。论文说——"The reactive design trades search completeness for simplicity and latency: each turn commits to one action sequence without backtracking"——这个反应式设计用搜索完备性换取简单性和低延迟——每一轮只承诺一个动作序列，不回溯。这是 ReAct 模式的工业化实现。工具调度可并行执行只读工具，串行执行状态修改工具。
论文用"Fix the failing test in auth.test.ts"这个任务追踪——它进入反应式循环——一个 production coding agent 可选的多种编排模式之一。
论文写下整个 query pipeline 每一轮的固定 9 步——
1. Settings resolution——queryLoop() 解构不可变参数——system prompt、user context、permission callback、model config
2. Mutable state initialization——单个 State 对象存所有可变状态——messages、tool context、compaction tracking、recovery counters。循环的 7 个 continue site（"continue sites"）每个都整体覆盖此对象而非逐字段修改
3. Context assembly——getMessagesAfterCompactBoundary() 从最后 compact boundary 向前取消息，确保压缩内容由 summary 代表而非原始消息
4. Pre-model context shapers——5 个 shapers 顺序执行（第 7 章详述）
5. Model call——for await 流式接收响应——包括 thinking 配置、可用工具集、abort signal、模型规格、fast-mode 设置、effort 值、fallback model
6. Tool-use dispatch——如果响应包含 tool_use blocks，流到工具编排层
7. Permission gate——每个工具请求过权限系统
8. Tool execution + result collection——工具结果作为 tool_result 加到对话
9. Stop condition——响应不含 tool_use（仅文本），turn 结束
这就是整个 Claude Code 的"决策大脑"。看起来太简单——但论文指出——
反应式设计用搜索完备性换取简单性和低延迟——
每一轮承诺一个动作序列，
不回溯。
Claude Code 遵循 ReAct pattern（Yao 2022）——模型生成推理和工具调用，harness 执行动作，结果喂下一轮。不像 LangGraph 用显式状态图，不像 LATS 用树搜索探索多条轨迹。
工具派发有两条路径——StreamingToolExecutor 和 runTools()。两者都分类"concurrent-safe"和"exclusive"——只读操作可并行，状态修改操作（如 shell）被串行化。
StreamingToolExecutor 有两个协调机制——
· Sibling abort controller——任何 Bash 工具出错时立即终止其他正在跑的子进程
· Progress-available signal——新输出就绪时唤醒 getRemainingResults() 消费者
结果buffer + 按工具接收顺序 emit——哪怕并行执行，输出顺序也保证不变。这是"concurrent-read, serial-write"执行模型——介于完全串行和激进推测之间。
论文还提到5 类恢复机制——max output tokens escalation、reactive compaction、prompt-too-long handling、streaming fallback、fallback model——和5 个 stop 条件——no tool use、max turns、context overflow、hook intervention、explicit abort。都是工程上的细节但每一个都关乎"长任务的鲁棒性"。
当 Claude 决定执行工具（比如运行 npm test 通过 BashTool 复现 auth 测试失败）——请求进入权限管道。每一次工具调用都过权限系统，默认行为是拒绝或问，而不是静默允许。Anthropic 内部数据显示——用户对 93% 的 permission 提示都批准——这暗示simple per-action approval 失效。Claude Code 的回应是"deny-first + 渐进信任"——deny 规则覆盖 allow，auto-mode classifier 让"已建立信任的"自动批准。7 种权限模式从 manual 到 auto——配合 auto-mode threat model（针对 overeager、honest mistake、prompt injection、misalignment 四类风险）。
当 Claude 决定执行工具——请求进入权限管道。每一次工具调用都过权限系统。Anthropic 的"93% 自动批准率"现象意义重大——
当 Anthropic 发现用户批准 93% 的权限提示时——
反应不是加更多警告，
而是重构问题——
定义边界（sandboxing、auto-mode classifier）
让 agent 能在边界内自由工作——
而不是 per-action 批准——
因为用户被习惯后会停止审视。
这背后是很深的人因工程洞察——"approval fatigue"是真实的。Claude Code 的7 种权限模式从严到宽——
· Manual——所有需问
· Approve once / always——批准这次/这类
· Allow list——预定义允许列表
· Plan mode——先规划再执行
· Auto-mode——分类器自动批准
· YOLO——全部自动（极少推荐）
· 还有内部 bubble 和 feature-gated auto
Auto-mode 的核心是 yoloClassifier.ts——一个 ML-based 的两阶段评估器——fast filter 快速判断 + chain-of-thought 评估慢但准。它针对的auto-mode 威胁模型有 4 类——
· Overeager behavior——agent 过度积极做超出意图的事
· Honest mistakes——agent 误解请求
· Prompt injection——外部内容里的恶意指令
· Model misalignment——模型不对齐
论文还指出一个关键原则——"reversibility-weighted risk"——可逆动作监督轻，不可逆动作监督重。例如读文件无须批准、写文件需要批准、删除文件需要双重确认。
关键设计——session-scoped 权限不在 resume 时恢复。论文写：这是"故意的安全选择"——避免遗留权限被复用。即使你昨天对 rm -rf node_modules 说了 "always allow"，今天 resume session 后还得重新批准。
论文最让我兴奋的一节。Claude Code 把 context window（老模型 200K、Claude 4.6 系列 1M）当作"the binding resource constraint"——每次模型调用前执行5 个 context-reduction strategy。5 层压缩管道——(1) Budget reduction 单 tool 输出超 size 限制时替换为内容引用；(2) Snip 去除老的历史段落；(3) Microcompact 细粒度压缩（time-based + 可选 cache-aware）；(4) Context collapse 长历史的读时投影；(5) Auto-compact 最后手段——调模型生成完整 summary。每层"成本-收益"不同，早的便宜先跑，贵的最后。这套设计反驳了"单次截断"方案——它承认不同上下文压力需要不同 strategy。
Context window 是 Claude Code 架构里被反复回到的稀缺资源。200K → 1M（Claude 4.6）看起来很大——但 agent 任务（多文件读、多工具调用、长对话）能很快撑爆。论文说——
5 层管道存在是因为——
没有单一压缩策略能解决所有类型的 context 压力。
· Budget reduction 针对单个 tool 输出溢出 size 限制
· Snip 处理"时间深度"
· Microcompact 对应 cache overhead
· Context collapse 管理非常长的历史
· Auto-compact 作为最后手段做语义压缩
每一层不同的成本-收益权衡——早、便宜的层先跑，贵的层后跑。
具体每一层做什么——
applyToolResultBudget()——强制 per-message 大小限制，超大的 tool 输出替换为"content reference"。豁免工具（maxResultSizeChars 不有限）保留全输出。替换被持久化，能在 resume 时重建。snipCompactIfNeeded()——轻量级修剪，去除老的历史段落。返回 {messages, tokensFreed, boundaryMessage}。tokensFreed 必须显式 plumb 给 auto-compact——因为主 token 计数从最近 assistant 消息的 usage 字段衍生，那个消息带着 pre-snip 的 input_tokens，snip 的节省对 counter 不可见。CACHED_MICROCOMPACT gated）。cache 路径开时，boundary message 延迟到 API 响应后，能用真实的 cache_deleted_input_tokens而非估算。messagesForQuery 数组上替换为投影。模型看到压缩版，full history 仍可用于重建。论文还提到 context 压力之外的几个工程决定——
· CLAUDE.md lazy loading——基本 CLAUDE.md 启动时加载，嵌套目录的指令文件只在 agent 读那些目录的文件时才加载
· Deferred tool schemas——ToolSearch 开启时，部分工具只把名字放在初始 context，full schema 按需加载（就是你正在用的工具！）
· Subagent summary-only return——subagent 只返回 summary 文本给 parent，不返回完整对话历史
· Per-tool-result budget——单个工具结果上限防止 verbose 输出消耗不成比例的 context
Claude Code 不用单一统一的扩展 API——而是4 个不同 context-cost 层级的扩展机制——MCP（外部工具协议，最重）、Plugins（可重用包，间接通过 MCP 和 skill/command registry）、Skills（按需触发的能力包）、Hooks（生命周期钩子，最轻）。这是"composable multi-mechanism extensibility"原则的体现——不同任务用不同 cost 的工具。MCP 现已捐给 Linux Foundation 的 Agentic AI Foundation，成为de facto 标准。Hook 系统覆盖 27 个事件——其中 5 个安全相关、22 个生命周期/编排。CLAUDE.md 有四层指令层级——从 managed settings 到 directory-specific 文件——加上 auto-memory（Claude 在对话中自己写的）。
Claude Code 的扩展架构是论文最有趣的部分之一。它没有"一个 unified extension API"——而是4 种不同 cost 层级的机制——
stdio、SSE、HTTP、WebSocket、SDK、IDE 适配器。Hou et al. 2025 把 MCP 服务器编目成 4 个攻击类别 + 16 个场景——Claude Code 的 deny-rule 和 pre-filter 步骤就是这个安全研究指出的"运行时缓解"。这套"layered mechanisms at different context costs"设计的好处——简单事用便宜机制（hook 或 skill），复杂事用 MCP 全协议。论文称之为"composable multi-mechanism extensibility"原则——"layered mechanisms at different context costs"。
更让我注意的是 CLAUDE.md 体系——
· 四层指令层级——managed settings → 全局 user CLAUDE.md → 项目 CLAUDE.md → 目录-specific CLAUDE.md。
· Auto-memory entries——Claude 在对话中自己写入的记忆（claudemd.ts）。
论文强调一个原则——"transparent file-based configuration and memory"——不是 opaque 数据库、不是 embedding-based 检索，而是用户可见、可版本控制的文件。这是 Claude Code 跟很多"AI memory startup"截然不同的取向——把 memory 暴露给人，而不是藏在向量数据库里。
Claude Code 通过 AgentTool（AgentTool.tsx、runAgent.ts）派生 subagent——跟其他所有工具一样通过 buildTool() factory。这是"isolated subagent boundaries"原则——subagent 不共享父的 context 和权限，重新进入 queryLoop() 跑独立的子任务，只把 summary 返回给 parent。Subagent 的 sidechain 转录存到单独的文件，不污染 parent 的 context。持久化方面——append-only JSONL session 转录（sessionStorage.ts）、global prompt history（history.jsonl）、subagent sidechain 文件。Resume/fork 通过 conversationRecovery.ts 重建。session-scoped 权限故意不在 resume 时恢复——这是"safety choice"。
Subagent 是 Claude Code 的核心扩展手段——当主 agent 觉得任务可以委托（"orchestrator-workers 模式"），它通过 AgentTool 派生子代理。
关键设计——subagent 被像其他所有工具一样通过 buildTool() factory 创建——统一的接口。新派的 subagent 重新进入 queryLoop()——但带"isolated context window"——它看不到 parent 的对话历史。任务完成后——只把 summary 文本返回 parent——不返回完整对话——避免 parent context 被 subagent 噪音污染。
这就是"isolated subagent boundaries"原则——服务Reliability、Safety、Capability三个价值观。它的 trade-off——subagent 之间无法直接通信——只能通过 parent 协调。如果 parent context 不够，subagent 之间会重复工作。
持久化——论文称之为"append-oriented session storage"——
sessionStorage.ts），存到 project-specific 路径。每一轮新消息追加，不改写。例外情况是 cleanup rewrite——但这是明确的例外。history.jsonl——跨所有 session 的提示历史。conversationRecovery.ts 从转录重建 session 状态。但session-scoped 权限不在 resume 时恢复——这是"deliberate safety choice"。"append-only durable state"原则的好处——auditable history + 可重现 + 不丢失。坏处——session 文件会一直增长。Claude Code 通过压缩管道（第 7 章）应对这个问题——历史在内存里被压缩，但磁盘上的转录保持完整。
论文的"reversibility-weighted risk"原则在持久化里也体现——"resume 不恢复权限"是选了"安全方面错"而非"方便方面错"。
论文第 12 节梳理 6 个开放方向——(1) 静默失败和 observability-evaluation gap；(2) 跨 session 持久化（CLAUDE.md 和 session 转录之间的"持久状态"中间层）；(3) Harness boundary 演化（where、when、what、with whom——VLA、多 agent 辩论、proactive agent 等）；(4) Horizon scaling（从 session 到"science program"——多天、多周的自主研究）；(5) 治理和监督的规模化（EU AI Act 2026 年 8 月生效，外部审计要求）；(6) 长期人类能力之问（"sustainability gap" 是否能成为first-class 设计问题）。最后一节论文留下的"长期人类能力"之问——是给所有 AI Agent 工程师的沉重邀请。
第 12 节是论文真正的"未来工作"——但论文不像普通"future work"那样空洞。每一个方向都有具体的文献支撑。
(1) Observability-Evaluation Gap——14 类失败模式（Cemri 2025）、anomaly detection benchmark（Pathak 2025）、pass@k 一致性 gap（Yao 2024）。论文留下的问题——Rajasekaran 2026 提倡的"generator-evaluator 分离 + sprint contract + post-hoc check"该放在 harness 内（作为新 hook 事件）还是 harness 外（作为独立评估层）？
(2) 跨 session 持久化——目前架构里——CLAUDE.md 是"静态指令"，session 转录是"单 session 历史"。中间什么都没有。论文引 Packer 2023（LLM as OS with paged memory）、Chhikara 2025（production memory store that survives restarts）、Wang 2023（自我累积的 skill library）——但"单一 substrate 能否同时承载用户个人指令层级和共享组织上下文，同时保持 file-based 透明性"是未解的设计问题。
(3) Harness boundary 演化——Rajasekaran 2026 说："interesting harness combinations 的空间不会随着模型改进而缩小——它在移动"。论文按where、when、what、with whom四个轴梳理——
· Where——Martin 2026 的 Managed Agents 把 session、harness、sandbox 虚拟化为独立可替换接口
· When——proactive agent 设计——Chen 2025 报告 12-18% 任务通过率提升，但"高频 Persistent Suggest"变体偏好得分大跌（47% vs 80-90%）——主动性是一把双刃剑
· What——VLA（vision-language-action）模型已能执行物理动作——把 harness 推到非文本动作——但"reversibility-weighted risk"原则在非文本动作上的成本不对称没量化
· With whom——多 agent 辩论（Du 2024、Liang 2024）、图结构工作流（Zhuge 2024）——探索parent/subagent 之外的协调模式
(4) Horizon scaling——从 session 到"科学项目"。Lu 2024 端到端自主研究管道；Gottweis 2025 多 agent 假说生成系统跑多天而非多轮；Novikov 2025 算法发现跑之前人类专家需要数周的时间尺度。METR 测量"50% reliability 时长"——agent 能可靠完成的任务时长——每一代模型推进。当 session 组合成多 session 项目时——Claude Code 的第 7 章压缩管道、第 8 章 last-assistant-text 返回策略、第 9 章 append-only 持久化是否仍足够是开放问题。
(5) 治理和监督——EU AI Act 在 2026 年 8 月全面适用；MIT AI Agent Index、International AI Safety Report 都推动外部审计。论文指出 Claude Code 当前架构里"deny-first evaluation 是内部可审计的"（通过 session 转录）——但不是外部可审计的方式（GPAI Code of Practice 设想的形式）。
(6) 长期人类能力——这是论文最有思想性的部分。论文引 Becker 2025（16 个开发者 RCT）、Shen-Tamkin 2026（理解测试得分低 17%）、Kosmyna 2025（EEG 研究）、He 2025（807 个仓库因果分析）、Liu 2026（30 万 commit 审计）、Rak 2025（招聘下降时间序列）——所有这些证据都指向一件事——AI 辅助带来短期生产力提升的同时，可能伴随长期人类能力的萎缩。
未来的系统可以把"可持续性 gap"当作
一等设计问题来处理——
而不是事后评估指标。
这是这篇论文留给所有 AI Agent 工程师的最重要的邀请。
读完这 46 页，我有几个感受想分享——
第一——1.6% vs 98.4% 这个数字会反复回到我脑海。我们总以为 AI Agent 是 AI——但 98.4% 是软件工程。这意味着"做一个好的 AI Agent"需要的大部分是工程师能力，不是 ML 能力。这跟硅谷叙事完全相反。
第二——Claude Code 的优雅在于"统一的 queryLoop"。CLI、Headless、SDK、IDE——同一个循环。这是"少即是多"哲学的工业级体现。
第三——"deny-first + 7 层独立安全 + reversibility-weighted risk" 这套组合展示了 Anthropic 的"安全文化是真的"。这不是营销——是架构里写出来的。
第四——MBZUAI 这种"读人家源码写综述"的研究值得被鼓励。Anthropic 的源码本来就是公开的——但有人愿意花 46 页认真读，这是研究社区健康的标志。
第五——论文最后那个"长期人类能力"之问，让我想起 Dario 在《技术的青春期》里写的"supervision paradox"——AI 越能干，监督 AI 所需的人类能力越关键，也越容易萎缩。这两篇论文从完全不同的角度都指向同一个 open problem。这是我们这一代都需要思考的问题。