Table of contents
Open Table of contents
1. 背景与问题
这段视频试图回答的问题不是“Anthropic 泄露了什么”,而是:
- 这次 Claude Code 泄露,暴露出来的真正可迁移价值是什么?
- 一个能跑到生产级、企业级、长期任务级别的 Agent Harness,底层究竟缺哪些“经常被忽视”的部件?
- 如果我们自己在做 Coding Agent、Workflow Agent 或 Multi-Agent System,应该优先补哪些工程基础设施?
视频作者的核心立场很明确:
- 不要只盯着 feature flags 和未发布路线图
- 更值得研究的是 Anthropic 如何把一个 agent 系统做成“可恢复、可审计、可控、可扩展、可运营”的产品
- 所谓“生产级 agent 的护城河”,往往不是模型有多炫,而是这些不性感但决定生死的基础设施
📡 扩展
公开资料确认,Claude Code 目前被 Anthropic 定义为一个 agentic coding tool,可读代码库、编辑文件、运行命令,并集成到终端、IDE、桌面端和浏览器中。Anthropic 还公开了 Claude Agent SDK,明确表示 SDK 提供“与 Claude Code 相同的 tools、agent loop 与 context management”。这意味着视频作者把焦点放在“底层 agent 运行机制”上,是有公开产品依据的,而不只是对泄露事件的八卦式解读。
另外,2026-03-31 的公开报道确认,Anthropic 确实因打包/发布流程问题泄露了 Claude Code 相关源码;更早在 2026-03-27,Fortune 还报道过与 “Claude Mythos” 相关的公开可访问资产泄露。换言之,视频把这次事件放到“开发速度是否超过运营纪律”的视角下看,是有现实背景的。
- Claude Code overview: https://code.claude.com/docs
- Claude Agent SDK overview: https://platform.claude.com/docs/en/agent-sdk/overview
- Axios 报道(2026-03-31): https://www.axios.com/2026/03/31/anthropic-leaked-source-code-ai
- Fortune 报道(2026-03-27): https://fortune.com/2026/03/27/anthropic-leaked-ai-mythos-cybersecurity-risk/
2. 核心概念
2.1 术语速览
| 术语 | 本视频中的含义 | 应如何理解 |
|---|---|---|
| Claude Code | Anthropic 的代码 agent 产品 | 一个能读代码、改代码、跑命令、调用工具的 agentic coding tool |
| Agent Harness | 承载 agent 运行的工程骨架 | 不只是 prompt,而是 tools、permissions、state、logs、verification 等整套运行机制 |
| Tool Registry | 能力注册表 | 用结构化元数据声明“系统有什么能力”,而不是把工具逻辑散落在 orchestration 代码里 |
| Permission System | 权限与风险分级层 | 不同工具、不同动作、不同上下文对应不同审批、拒绝和记录策略 |
| Session Persistence | 会话持久化 | agent 崩溃、断连或关闭后,仍能恢复上下文和运行状态 |
| Workflow State | 工作流状态 | 不只是“聊到哪了”,而是“任务做到哪一步、哪些副作用已发生、能否安全重试” |
| Token Budgeting | token 预算控制 | 在长任务中控制上下文成本、停止条件与预算边界 |
| Structured Streaming | 结构化流式事件 | 让用户不仅看到文字,还能看到 agent 当前正在做什么 |
| System Event Logging | 系统事件日志 | 单独记录 agent 做过什么、触发了哪些系统级行为、发生了哪些错误 |
| Verification | 验证机制 | 既验证 agent 的单次执行,也验证对 harness 本身的改动是否破坏安全与稳定性 |
| Tool Pool Assembly | 动态工具池装配 | 不是每次把所有工具都暴露给 agent,而是按任务和权限动态组装 |
| Transcript Compaction | 转录压缩 | 在长会话里压缩历史,以节省上下文与 token |
| Permission Audit Trail | 权限审计轨迹 | 权限不是简单 yes/no,而应是可查询、可重放、可追溯的对象 |
| Agent Type System | 代理类型系统 | 把 agent 角色类型化、约束化,而不是随意生成一堆“泛化 worker” |
2.2 与公开文档的对齐关系
| 视频观点 | 公开资料能否对齐 | 备注 |
|---|---|---|
| Claude Code 是生产级 agent 产品 | 能 | 官方明确如此描述 |
| 工具调用是 agentic loop 核心 | 能 | 官方 Tool Use 文档明确描述 |
| 会话连续性、事件历史、上下文管理很重要 | 能 | Agent SDK、Managed Agents、Hooks 文档都支持这一方向 |
| 公开文档会给出内部 registry 精确数量 | 不能 | 这类数字来自泄露代码/视频分析,不是官方规格 |
| 存在角色化 subagent / agent type | 部分能 | 官方公开有 custom subagents,但未公开视频中那组内建类型的完整规格 |
| 长会话需要上下文压缩 / 成本治理 | 能 | 官方文档公开提到 context management、cost tracking、token usage、PreCompact/PostCompact 生命周期 |
📡 扩展
Anthropic 的公开文档把 Claude 的开发面向能力分成几个大块:工具、工具基础设施、上下文管理、文件与资产等。对这次视频最 relevant 的不是单一模型能力,而是“tool infrastructure + context management + stateful agent runtime” 这一整组能力。
同时,Anthropic 公开的 Claude Managed Agents 页面已经直接使用了 “stateful sessions with persistent event history” 这样的表述,这和视频强调的“会话持久化 + 事件历史 + crash recovery” 高度同向,只是公开文档不会展开到泄露代码里的内部细节级别。
- Features overview: https://platform.claude.com/docs/en/docs/build-with-claude/overview
- Claude Managed Agents: https://platform.claude.com/docs/en/home
3. 主体内容
3.1 视频给出的整体框架:12 个关键部件,3 个层级
视频说“12 categories, three tiers”,但没有在字幕中给出三个 tier 的正式命名。 下方 tier 名称是按内容逻辑整理后的编辑性命名,便于学习与复盘。
flowchart TD
A([起点<br>从泄露代码反推生产级 Agent]) --> B[基础底座<br>1 工具注册表<br>2 权限体系<br>3 会话持久化<br>4 工作流状态<br>5 Token 预算]
B --> C[可观察性与可信执行<br>6 结构化流式事件<br>7 系统事件日志<br>8 双层验证]
C --> D[运行成熟度<br>9 动态工具池<br>10 转录压缩<br>11 权限审计轨迹<br>12 代理类型系统]
D ==> E([结论<br>生产级 Agent = 模型 + 大量工程 Plumbing])
style A fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
style B fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style C fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style D fill:#fce4ec,stroke:#d81b60,stroke-width:2px
style E fill:#e8f5e9,stroke:#43a047,stroke-width:3px3.2 第一层:基础底座
3.2.1 Tool Registry:先定义能力,再写实现
视频强调的第一原则非常朴素:先把 agent 有哪些能力定义成数据结构,再写执行实现。
也就是:
- 系统应先回答“有哪些工具 / 命令 / 技能”
- 再回答“这些能力如何被调用”
- 而不是把“能做什么”藏在 orchestration 代码的 if/else 或 prompt 里
作者从泄露代码中观察到的具体形态是:
- 面向用户的 command registry
- 面向模型的 tool registry
- 每个 entry 至少包含名字、来源提示、职责描述
- registry 是 source of truth,具体实现按需加载
可迁移的设计原则:
- 用结构化元数据定义能力
- 支持运行时过滤
- 支持 introspection,而不是必须执行才能知道系统会做什么
- 新增工具不应强耦合到总控逻辑里
📡 扩展
官方 Tool Use 文档明确写到:Claude 可以根据用户请求和 tool description 决定何时调用工具,并返回结构化调用;执行可以发生在客户端工具或 Anthropic 提供的服务端工具侧。这和“先把工具能力结构化描述清楚,再进入 agentic loop”是同一设计方向。
另外,Claude Code 的 skills 文档也说明:skills 本质上是可被 Claude 动态装载的能力扩展,只有在用到时才加载正文内容,这进一步说明“能力描述与运行时装载”本身就是 Anthropic 产品设计的重要原则。
- Tool use overview: https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
- Skills: https://code.claude.com/docs/en/skills
3.2.2 Permission System:没有权限层,就只有 demo,没有产品
视频对权限的态度很强硬:能执行现实动作的 agent,如果没有权限层,就不是产品,只是 demo。
作者强调的重点包括:
- 不同工具风险不同,必须分级
- 权限不是单一布尔值
- 对高风险工具要有更细的安全模块
- 每次允许/拒绝都要带上下文记录下来
可迁移设计:
- 先做动作分类:只读 / 可修改 / 可能破坏
- 对危险动作做预分类、模式识别和前置告警
- 对权限决策做日志化与可重放
- 不要把“人类审批”当作唯一权限策略;还要有模式、上下文、角色、会话状态等维度
📡 扩展
Claude Code 的 quickstart 文档公开写明:在修改文件前,Claude Code 会先展示变更并请求用户批准。Hooks 文档还公开了更细的生命周期事件,包括PreToolUse、PermissionRequest、PermissionDenied、PostToolUse等节点,说明权限不是一个模糊概念,而是运行时生命周期中的明确阶段。设置文档也表明,权限、hooks、MCP servers 等内容可在不同作用域配置。
这与视频中的核心观点一致:权限应该被设计成系统级机制,而不是临时补丁。
- Quickstart: https://code.claude.com/docs/en/quickstart
- Hooks reference: https://code.claude.com/docs/en/hooks
- Settings: https://code.claude.com/docs/en/settings
3.2.3 Session Persistence:会话恢复不是“顺手保存聊天记录”
视频把 Session Persistence 讲得很清楚:
- 会话状态不只是聊天记录
- 还包括 token 使用、权限决策、配置、上下文等
- 恢复会话不是“把旧消息再喂一遍”,而是把整个可运行状态恢复回来
这背后的工程含义是:
- agent 一定会崩
- 浏览器会关、连接会断、进程会挂
- 如果不能恢复完整运行状态,用户体验就会退化成“每次都要从头再来”
3.2.4 Workflow State:恢复“对话”不等于恢复“任务”
这是视频里一个非常值得单独记的点:
- Session Persistence 解决“上下文还能不能接着聊”
- Workflow State 解决“任务究竟做到哪一步了”
这两个问题不能混为一谈。
如果你只有会话恢复,没有任务状态:
- 工具调用可能重复执行
- 消息可能被重复发送
- 副作用型操作可能被重复写入
- 外部等待态、审批态、回调态都会丢失
视频建议把长任务拆成显式状态,例如:
- planned
- awaiting approval
- executing
- waiting on external party
- completed
- failed
这实际上是在把 agent 从“聊天应用”推进到“工作流系统”。
3.2.5 Token Budgeting:预算不是优化项,是生存项
视频认为 token budget 不是后期优化,而是 day-one non-negotiable。
原因很直接:
- 长任务天然会消耗上下文
- 多轮对话和多工具调用会快速放大成本
- 如果没有预算和硬停止条件,就容易进入 runaway loop
值得记住的设计要点:
- 记录 input / output token
- 预估下一轮 projected usage
- 在真正发出 API 请求前做预算判断
- 超预算时给结构化 stop reason,而不是让系统无意义地继续烧钱
📡 扩展
官方文档已经把成本和上下文管理公开成一等能力:Claude Code 文档专门提供/cost、/stats、team spend limits、context management、extended thinking settings 等内容;Features overview 也把 context management 直接列为 Claude API 的核心能力域之一。
换句话说,视频把 token 预算视为“运行底座”的观点,与官方产品设计并不冲突。
- Manage costs effectively: https://code.claude.com/docs/en/costs
- Features overview: https://platform.claude.com/docs/en/docs/build-with-claude/overview
3.3 第二层:可观察性与可信执行
3.3.1 Structured Streaming:流式输出不只是“边生成边显示文字”
视频提出一个很实用的判断:
用户看到的 streaming,本质上应该是 agent 的运行状态投影。
也就是说,流式事件应该能告诉用户:
- 模型正在思考什么阶段
- 可能要调用什么工具
- 预算用了多少
- 当前是在执行、等待还是收尾
- 如果异常中断,最后一个事件为什么失败
这让 streaming 不再只是 UX,而是控制面板的一部分。
3.3.2 System Event Logging:conversation 记录“说了什么”,system log 记录“做了什么”
视频把 streaming 和 event logging 分得很清:
- streaming 更接近“运行中可视状态”
- system log 更接近“运行后可审计证据”
一个成熟系统需要把以下内容单独记账:
- 加载了哪些上下文
- 初始化了哪些 registry
- 做了什么路由决策
- 触发了哪些权限允许/拒绝
- 工具调用了几次
- 哪些异常出现过
这是一条非常典型的“从 chat 转向 enterprise runtime”的分界线。
3.3.3 Verification:要同时验证“agent 结果”与“harness 改动”
视频最值得记的一点之一,是把验证分成两层:
- 执行级验证:本轮 agent 任务是否做对了
- 系统级验证:你刚改了 harness,这个改动会不会破坏未来所有任务的安全性、稳定性和边界条件
第二层往往更容易被忽视,但它才是系统长期可维护的前提。
因此,视频建议保留一类稳定的验证测试:
- 危险工具是否仍需审批
- 超预算时是否优雅停止
- 崩溃后是否仍可恢复
- 新加工具是否绕过旧权限体系
- 日志和审计链是否还完整
📡 扩展
官方 streaming 文档明确支持 streaming request with tool use,并提供 fine-grained streaming;Hooks 文档公开的生命周期图则进一步说明 Claude Code 会在 session、turn、tool-call 等不同粒度触发事件,包括Stop、StopFailure、PreCompact、PostCompact、SubagentStart、TaskCompleted等。
这些公开资料至少说明一件事:Anthropic 的 agent runtime 不是“单纯聊天 + 工具调用”这么简单,而是明显建立在结构化事件流与生命周期管理之上。
- Streaming: https://platform.claude.com/docs/en/build-with-claude/streaming
- Hooks reference: https://code.claude.com/docs/en/hooks
sequenceDiagram
participant U as User
participant A as Agent
participant R as Tool Registry
participant P as Permission Layer
participant T as Tool Runtime
participant L as Event Log
participant V as Verifier
U->>A: 提交任务
A->>R: 查询可用能力
R-->>A: 返回候选工具与元数据
A->>P: 请求执行许可
P-->>A: 批准 / 拒绝 / 升级审批
A->>L: 写入流式状态与系统事件
A->>T: 调用工具
T-->>A: 返回结果 / 错误
A->>V: 验证执行结果
V-->>A: 通过 / 失败
A->>L: 记录最终状态
A-->>U: 返回结果与可见状态3.4 第三层:运行成熟度
3.4.1 Tool Pool Assembly:不要每次都把所有工具直接塞给 agent
视频在这里给出的启发是:
- 一个通用 agent 背后可能有很多工具
- 但每次 run 真正应该看到的,只是一个按上下文筛过的工具子集
- 这个子集应根据 mode flags、权限上下文、deny lists、任务目标动态生成
这背后有三个现实收益:
- 缩小选择空间
- 降低误调用风险
- 提高模型在当前任务上的决策效率
3.4.2 Transcript Compaction:长会话必须“压缩旧历史”
视频把 compaction 单独拿出来,是因为它跟 token 预算不同:
- token budget 是边界
- transcript compaction 是手段
关键问题不是“压不压缩”,而是:
- 何时压缩
- 保留什么
- 丢弃什么
- 如何确保压缩后仍保留任务必要上下文
- 压缩前是否已持久化,避免数据丢失
3.4.3 Permission Audit Trail:权限状态应成为一等对象
视频认为权限系统成熟之后,不应只给出 yes/no 结果,而应支持:
- 查询
- 追踪
- 分角色处理
- 跨不同 agent 角色复用不同 handler
这意味着权限本身要被对象化、状态化,而不是埋在某次工具调用里的局部逻辑。
3.4.4 Agent Type System:不要随机生 agent,要约束 agent 角色
视频最后一个关键部件,是把 agent 做成明确的“类型系统”,而不是随意复制 worker。
其核心价值在于:
- 角色职责边界清晰
- 每类 agent 绑定固定 prompt
- 每类 agent 绑定固定工具集
- 每类 agent 绑定固定行为约束
- 更容易治理成本、权限、可靠性与 population growth
这和公开文档里的 Subagent 思路是同向的:任务可以下放给更窄职责、更独立上下文的 worker,而不是让主 agent 一把抓。
📡 扩展
官方 subagents 文档明确说明:subagents 是“specialized AI assistants”,适合处理特定类型任务;每个 subagent 运行在自己的 context window 中,拥有自定义 system prompt、特定 tool access 和独立 permissions。
这与视频对 Agent Type System 的强调非常接近。差异在于:视频里提到的“六种内建 agent type”属于泄露代码分析层面的信息,而官方当前公开的是“你可以创建 specialized subagents”这一能力,不会对内部类型系统做完全披露。
- Subagents: https://code.claude.com/docs/en/sub-agents
- Agent SDK reference: https://platform.claude.com/docs/en/agent-sdk/python
flowchart TD
A([收到任务]) --> B{是否需要全部工具}
B -- "否" --> C[按任务 角色 权限 装配工具池]
B -- "是" --> D[保留广泛工具集]
C --> E[运行任务]
D --> E
E --> F{上下文是否过大}
F -- "是" --> G[压缩转录并持久化]
F -- "否" --> H[继续执行]
G --> H
H --> I{是否涉及高风险动作}
I -- "是" --> J[进入权限审计与审批]
I -- "否" --> K[继续执行]
J --> K
K --> L{是否需要角色分工}
L -- "是" --> M[分配到特定 Agent Type 或 Subagent]
L -- "否" --> N[主 Agent 继续]
M --> O([输出结果并记录可追踪状态])
N --> O
style A fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
style B fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style C fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style D fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style E fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style F fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style G fill:#fce4ec,stroke:#d81b60,stroke-width:2px
style H fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style I fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style J fill:#fce4ec,stroke:#d81b60,stroke-width:2px
style K fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style L fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style M fill:#e8f5e9,stroke:#43a047,stroke-width:2px
style N fill:#e8f5e9,stroke:#43a047,stroke-width:2px
style O fill:#e8f5e9,stroke:#43a047,stroke-width:3px4. 实践案例
4.1 把视频内容落成一个“最小可用 coding agent”
如果你不是 Anthropic,也不打算一开始就做复杂的 Multi-Agent System,那这段视频最实用的落地方式其实是:
| 优先级 | 必做项 | 为什么 |
|---|---|---|
| P0 | Tool Registry | 没有它,能力不可管理、不可过滤、不可解释 |
| P0 | Permission System | 没有它,高风险动作不可控 |
| P0 | Session Persistence | 没有它,崩溃就回到原点 |
| P0 | Workflow State | 没有它,任务恢复会重复副作用 |
| P0 | Token Budgeting | 没有它,长任务容易失控 |
| P1 | Structured Streaming | 没有它,用户看不到 agent 在做什么 |
| P1 | System Event Logging | 没有它,问题难以复盘和审计 |
| P1 | Verification | 没有它,系统演进时会逐步退化 |
| P2 | Transcript Compaction | 长任务成本和上下文会膨胀 |
| P2 | Tool Pool Assembly | 工具太多时容易误调、低效 |
| P2 | Permission Audit Trail | 难以支撑企业治理和责任追踪 |
| P2 | Agent Type System | 多角色场景会越来越乱 |
4.2 一个更合理的建设顺序
flowchart TD
A([开始做 Agent]) --> B[先建 Tool Registry]
B --> C[补 Permission System]
C --> D[补 Session Persistence]
D --> E[补 Workflow State]
E --> F[补 Token Budgeting]
F ==> G[得到可基本运行的单 Agent 系统]
G --> H[增加 Structured Streaming]
H --> I[增加 System Event Logging]
I --> J[增加 Verification]
J ==> K[得到可观察 可恢复 可控的运行时]
K --> L[增加 Transcript Compaction]
L --> M[增加 Tool Pool Assembly]
M --> N[增加 Permission Audit Trail]
N --> O[增加 Agent Type System 或 Subagent]
O ==> P([进入成熟化与扩展阶段])
style A fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
style B fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style C fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style D fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style E fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style F fill:#fff3e0,stroke:#fb8c00,stroke-width:2px
style G fill:#e8f5e9,stroke:#43a047,stroke-width:3px
style H fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style I fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style J fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
style K fill:#e8f5e9,stroke:#43a047,stroke-width:3px
style L fill:#fce4ec,stroke:#d81b60,stroke-width:2px
style M fill:#fce4ec,stroke:#d81b60,stroke-width:2px
style N fill:#fce4ec,stroke:#d81b60,stroke-width:2px
style O fill:#fce4ec,stroke:#d81b60,stroke-width:2px
style P fill:#e8f5e9,stroke:#43a047,stroke-width:3px4.3 视频里隐含的方法论
这段视频本质上在传达一种工程方法论:
- 先把 agent 当成一个系统,而不是一个 prompt
- 先做失败路径,再谈 happy path
- 先让系统可恢复、可观察、可审计,再追求花哨功能
- 先做单 agent 的稳态,再决定是否需要多 agent
- 尽量用类型约束、权限约束、工具约束代替“模型自己会理解”
这个思路和很多“先堆多 agent、先做复杂协作、先追求 autonomous wow effect” 的路线正好相反。
5. 核心结论
5.1 这段视频最值得记住的 5 句话
- 生产级 agent 的护城河,更多来自 plumbing,而不是 feature list。
- 恢复聊天记录,不等于恢复任务执行。
- 权限不是布尔开关,而应是系统级可审计对象。
- streaming 不只是 UX,它也是运行状态的可视化。
- 不要随机生成 worker;要把 agent 角色化、类型化、约束化。
5.2 对实际做 agent 的建议
对个人开发者
- 先做单 agent
- 先做权限、持久化、预算、日志
- 没有这些前,不要急着做复杂 multi-agent
对团队
- 把会话状态、工作流状态、事件日志分开建模
- 把权限决策和工具调用做成可追踪事件
- 给 harness 变更写验证测试,不要只测 agent 最终输出
对产品负责人
- 评估 agent 成熟度时,不要只问“模型会不会做”
- 还要问“失败时会怎样、崩溃后怎么办、权限能不能收口、日志能不能审计、成本能不能控”
5.3 一句话总结
真正让一个 agent 变成“产品”的,不是它能不能跑通一次,而是它在失败、恢复、审计、扩展、治理这些场景下,是否仍然成立。
6. 适合继续拆成独立笔记的双链节点
- Claude Code
- Agent Harness
- Tool Registry
- Permission System
- Session Persistence
- Workflow State
- Token Budgeting
- Structured Streaming
- System Event Logging
- Verification
- Transcript Compaction
- Tool Pool Assembly
- Permission Audit Trail
- Agent Type System
- Subagent
- Claude Managed Agents
- Claude Agent SDK
7. 相关资料
官方文档
- Claude Code overview
- Tool use with Claude
- Streaming
- Claude Managed Agents
- Claude Agent SDK
- Claude Code Quickstart
- Claude Code Hooks
- Claude Code Settings
- Claude Code Skills
- Claude Code Subagents
- Claude Code Costs
公开报道
- Axios: Anthropic leaked 500,000 lines of its own source code
- Fortune: Anthropic accidentally leaked details of a new AI model
8. 关联笔记
- Anthropic Claude Code 泄露视频清洗稿(语义去重版)