Skip to content
Figo Blogs
Go back

Anthropic Claude Code 泄露视频学习笔记:Agent 缺失的 12 个关键部件

Contents

Table of contents

Open Table of contents

1. 背景与问题

这段视频试图回答的问题不是“Anthropic 泄露了什么”,而是:

  1. 这次 Claude Code 泄露,暴露出来的真正可迁移价值是什么?
  2. 一个能跑到生产级、企业级、长期任务级别的 Agent Harness,底层究竟缺哪些“经常被忽视”的部件?
  3. 如果我们自己在做 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” 相关的公开可访问资产泄露。换言之,视频把这次事件放到“开发速度是否超过运营纪律”的视角下看,是有现实背景的。


2. 核心概念

2.1 术语速览

术语本视频中的含义应如何理解
Claude CodeAnthropic 的代码 agent 产品一个能读代码、改代码、跑命令、调用工具的 agentic coding tool
Agent Harness承载 agent 运行的工程骨架不只是 prompt,而是 tools、permissions、state、logs、verification 等整套运行机制
Tool Registry能力注册表用结构化元数据声明“系统有什么能力”,而不是把工具逻辑散落在 orchestration 代码里
Permission System权限与风险分级层不同工具、不同动作、不同上下文对应不同审批、拒绝和记录策略
Session Persistence会话持久化agent 崩溃、断连或关闭后,仍能恢复上下文和运行状态
Workflow State工作流状态不只是“聊到哪了”,而是“任务做到哪一步、哪些副作用已发生、能否安全重试”
Token Budgetingtoken 预算控制在长任务中控制上下文成本、停止条件与预算边界
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” 高度同向,只是公开文档不会展开到泄露代码里的内部细节级别。


3. 主体内容

3.1 视频给出的整体框架:12 个关键部件,3 个层级

Tip

视频说“12 categories, three tiers”,但没有在字幕中给出三个 tier 的正式命名。 下方 tier 名称是按内容逻辑整理后的编辑性命名,便于学习与复盘。


3.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 产品设计的重要原则。

3.2.2 Permission System:没有权限层,就只有 demo,没有产品

视频对权限的态度很强硬:能执行现实动作的 agent,如果没有权限层,就不是产品,只是 demo。

作者强调的重点包括:

  • 不同工具风险不同,必须分级
  • 权限不是单一布尔值
  • 对高风险工具要有更细的安全模块
  • 每次允许/拒绝都要带上下文记录下来

可迁移设计:

  • 先做动作分类:只读 / 可修改 / 可能破坏
  • 对危险动作做预分类、模式识别和前置告警
  • 对权限决策做日志化与可重放
  • 不要把“人类审批”当作唯一权限策略;还要有模式、上下文、角色、会话状态等维度

📡 扩展
Claude Code 的 quickstart 文档公开写明:在修改文件前,Claude Code 会先展示变更并请求用户批准。Hooks 文档还公开了更细的生命周期事件,包括 PreToolUse、PermissionRequest、PermissionDenied、PostToolUse 等节点,说明权限不是一个模糊概念,而是运行时生命周期中的明确阶段。设置文档也表明,权限、hooks、MCP servers 等内容可在不同作用域配置。
这与视频中的核心观点一致:权限应该被设计成系统级机制,而不是临时补丁。

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 预算视为“运行底座”的观点,与官方产品设计并不冲突。


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 改动”

视频最值得记的一点之一,是把验证分成两层:

  1. 执行级验证:本轮 agent 任务是否做对了
  2. 系统级验证:你刚改了 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 不是“单纯聊天 + 工具调用”这么简单,而是明显建立在结构化事件流与生命周期管理之上。


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”这一能力,不会对内部类型系统做完全披露。


4. 实践案例

4.1 把视频内容落成一个“最小可用 coding agent”

如果你不是 Anthropic,也不打算一开始就做复杂的 Multi-Agent System,那这段视频最实用的落地方式其实是:

优先级必做项为什么
P0Tool Registry没有它,能力不可管理、不可过滤、不可解释
P0Permission System没有它,高风险动作不可控
P0Session Persistence没有它,崩溃就回到原点
P0Workflow State没有它,任务恢复会重复副作用
P0Token Budgeting没有它,长任务容易失控
P1Structured Streaming没有它,用户看不到 agent 在做什么
P1System Event Logging没有它,问题难以复盘和审计
P1Verification没有它,系统演进时会逐步退化
P2Transcript Compaction长任务成本和上下文会膨胀
P2Tool Pool Assembly工具太多时容易误调、低效
P2Permission Audit Trail难以支撑企业治理和责任追踪
P2Agent Type System多角色场景会越来越乱

4.2 一个更合理的建设顺序

4.3 视频里隐含的方法论

这段视频本质上在传达一种工程方法论:

  1. 先把 agent 当成一个系统,而不是一个 prompt
  2. 先做失败路径,再谈 happy path
  3. 先让系统可恢复、可观察、可审计,再追求花哨功能
  4. 先做单 agent 的稳态,再决定是否需要多 agent
  5. 尽量用类型约束、权限约束、工具约束代替“模型自己会理解”

这个思路和很多“先堆多 agent、先做复杂协作、先追求 autonomous wow effect” 的路线正好相反。


5. 核心结论

5.1 这段视频最值得记住的 5 句话

  1. 生产级 agent 的护城河,更多来自 plumbing,而不是 feature list。
  2. 恢复聊天记录,不等于恢复任务执行。
  3. 权限不是布尔开关,而应是系统级可审计对象。
  4. streaming 不只是 UX,它也是运行状态的可视化。
  5. 不要随机生成 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. 相关资料

官方文档

公开报道


8. 关联笔记

  • Anthropic Claude Code 泄露视频清洗稿(语义去重版)

Share this post:

Previous Post
Claude Code 泄露背后的真正信号:从代码泄露到常驻代理平台
Next Post
从 API 调用看清楚:MCP、Skill、Function Calling、Tools 三者什么关系