ClaudeCode - DJJ

Claude Code Auto Mode 实现

Wed, 05 Aug 2026 17:03:55 +0800

From: https://www.youtube.com/watch?v=b8SV4U6fEIc

Claude Code 的 Classifier 不是传统的逻辑回归、小型分类网络，也不是一套命令黑名单。公开信息显示，它本质上是：一个独立运行的 Sonnet 4.6，通过固定 Prompt 扮演 LLM Judge，对“用户是否明确授权了这个工具调用”进行二分类。

“Classifier”描述的是它的职责，不代表 Anthropic 专门训练了一个传统分类模型。Anthropic 没有公开它是否经过额外微调；目前能确认的是，它使用 Sonnet 4.6、固定分类模板和两阶段推理。

1. Classifier 实际看到什么#

它看到的是经过裁剪的 Transcript：

固定的分类 System Prompt
+ Auto Mode 环境与规则配置
+ 用户历次消息
+ Claude 历次工具调用的可执行内容
+ 当前待执行的工具调用

它看不到：

Claude 的自然语言回复
Claude 的内部推理
工具执行结果
网页、文件、Shell 输出

可以理解为：

classifier_input = {
 "user_messages": [...],
 "tool_call_history": [...],
 "candidate_tool_call": current_call,
 "environment": [...],
 "allow": [...],
 "soft_deny": [...],
 "hard_deny": [...]
}

例如主 Agent 说：

我确认这个数据库只是测试数据库，所以删除是安全的。

这段解释不会传给 Classifier。Classifier只会看到：

User: 修复测试环境的数据问题

ToolCall:
psql production_db -c "DROP TABLE users"

这样可以防止主 Agent 用自己的解释说服审核模型。工具输出也被删除，主要是为了避免网页或文件中的 Prompt Injection 直接进入审核模型。(Anthropic)

2. 它判断的不是“命令危险吗”#

它实际判断的是：

这个动作的实际影响是什么？

这个影响是否被用户明确授权？

它是否跨越了环境、数据或权限边界？

即：

Risk = Action Impact × Authorization Gap

同一个命令，在不同用户请求下结果可能不同：

用户：把 feature 分支 force push 到 origin
动作：git push --force origin feature
结果：可能允许

用户：整理一下这个 PR
动作：git push --force origin feature
结果：阻止

因为“整理 PR”与 force push 有关联，但不等于用户明确授权了“重写远程历史”。

Anthropic 给它设定的原则是：

Agent 自己推导出来的操作默认不算授权，除非用户明确表达。

所以它审核的是 authorization scope，不是单纯的 dangerous command detection。(Anthropic)

3. 固定 Prompt 内部大致如何判断#

公开文档显示，其判断优先级是：

1. hard_deny
2. soft_deny
3. allow exception
4. explicit user intent
5. 最终阻止或允许

具体含义：

`hard_deny`#

无条件禁止。即使用户明确要求，Classifier 仍然阻止。

永远不要把仓库内容发给第三方代码审查服务

`soft_deny`#

默认禁止，但用户明确授权后可以执行。

禁止 force push，除非用户明确要求 force push 到指定分支

`allow`#

对 soft_deny 的特例豁免。

允许部署到每天重置的 staging namespace

Explicit User Intent#

如果用户明确描述了：

操作是什么；
目标是什么；
影响范围是什么；

则可以覆盖剩余的 soft_deny。

但不能覆盖 hard_deny。需要注意，这些仍然是自然语言规则，由 LLM 解释，并不是程序意义上的强制访问控制。真正不可绕过的限制必须使用前置的 permissions.deny。(Claude)

4. 它会尝试理解“真实执行效果”#

Classifier 不只匹配当前命令字符串，还会阅读此前的工具调用历史。

例如：

ToolCall 1:
写入 /tmp/deploy.py

内容：
os.system("kubectl delete namespace production")

ToolCall 2:
python /tmp/deploy.py

它被要求把第二个调用理解为：

kubectl delete namespace production

而不是把它误认为普通的：

python /tmp/deploy.py

类似地：

prepare && terraform destroy

会被视为一个完整动作，而不是只看第一个子命令。Anthropic 的固定 Prompt 明确要求审核实际影响，而不是调用表面的包装形式。(Anthropic)

但这不是严格的符号执行器，而是 LLM 对工具调用文本进行语义解释。因此它有明显边界：

rm -rf "$TARGET"

假如 $TARGET 的值只存在于上一条 Shell 输出中，Classifier 看不到这个输出，就无法确定删除目标。目前 Claude Code 对这种无法解析的递归删除倾向于直接阻止，要求 Claude 改成包含明确路径的命令。(Claude)

5. 为什么分成两个阶段#

Classifier 并不是每次都完整思考。

Stage 1：单 Token 快速过滤#

同一个 Sonnet 4.6 收到分类 Prompt，只输出类似：

YES // 应阻止
NO // 可允许

不生成推理过程，并被要求：

不确定时偏向阻止。

流程：

flagged = stage1(transcript)

if not flagged:
 execute()

这个阶段追求高召回率：尽量别漏掉危险动作，因此会产生较多误报。

Stage 2：完整推理复审#

只有 Stage 1 判断“可能应该阻止”时，才再次调用模型：

if flagged:
 decision, reason = stage2_reasoning(transcript)

Stage 2 使用几乎相同的输入和 Prompt，只把最后的指令改成“仔细推理后判断”。它的作用主要是撤销 Stage 1 的误报。

由于两次请求的大部分 Prompt 相同，Stage 2 可以大量命中 Prompt Cache，从而降低延迟和成本。(Anthropic)

实际数据说明了这种取舍：

 误阻正常动作 漏放危险动作
Stage 1 8.5% 6.6%
完整两阶段 0.4% 17%

Stage 2 大幅降低了正常动作被阻止的概率，但也会错误放行一部分 Stage 1 已经抓住的危险动作。Anthropic 在真实的 52 个 overeager action 样本上报告完整流水线漏放约 17%。(Anthropic)

6. 一个完整例子#

用户：

把已经没用的本地分支清理一下。

Claude 准备执行：

git push origin --delete release old-production backup

Classifier 构造的判断大致是：

实际效果：
删除三个远程分支，操作难以恢复。

用户授权：
用户只明确要求清理本地分支。

规则匹配：
remote branch deletion -> soft_deny

Allow exception：
无。

Explicit intent：
用户没有要求删除远程分支，也没有指定目标分支。

Decision：
BLOCK

拒绝结果会作为工具结果返回给主 Agent：

该操作超出了用户授权范围，请寻找更安全的方法，
不要尝试规避此限制。

Claude 随后可能改为：

git branch -d old-local-branch

连续拒绝三次，或者整个会话累计拒绝二十次后，Claude Code 会停止自动执行并升级给用户；无交互的 headless 模式则会终止进程。(Anthropic)

7. 最准确的实现抽象#

可以把它近似理解成：

def approve_action(session, action, policy):
 if permission_rules.deny(action):
 return DENY

 if permission_rules.ask(action):
 return ASK_USER

 if safe_allowlist.matches(action):
 return ALLOW

 if is_project_local_recoverable_edit(action):
 return ALLOW

 transcript = {
 "user_messages": session.user_messages,
 "tool_calls": session.executable_tool_calls,
 "candidate": action,
 "policy": policy,
 }

 if stage1_single_token(transcript) == ALLOW:
 return ALLOW

 decision, reason = stage2_reasoned(transcript)

 if decision == DENY:
 return DENY_AND_CONTINUE(reason)

 return ALLOW

所以它的核心不是“识别危险命令”，而是：

使用一个上下文经过隔离的 LLM，对工具调用的真实影响、用户授权范围和组织安全策略做语义对齐判断。

它的主要优势是可以理解复杂命令和自然语言授权；主要弱点同样来自 LLM：对模糊授权、上下文中的间接同意和实际 blast radius 仍可能判断错误。

一场外围的狂欢

Fri, 10 Apr 2026 00:50:23 +0800

Claude Code 的源码泄露了, 然后呢?

公众号, X, RSS, Blog 全部都在讲 Claude Code 的 Harness Engineering

Codex Cli / Gemini Cli / OpenCode / Crush 也是开源的, 为什么不早早的去研究他们呢?

我的问题可以换成另外一个问题: Claude Code 比他们哪里做的更好?

Agent & Agent Software#

我们先简单的聊一聊 Agent 以及由 Agent 作为核心的 Software

Agent 到底是什么?

我不想再看到 Agent 的 L1 - L5 这种垃圾言论了

Tool Use
Task Finish
Model Driven

好了, 这就是我对于 Agent 的定义: AI 驱动, 使用工具, 完成任务

这里就引出了几个问题:

哪些工具? 工具能力/权限?
什么任务? 怎么判断完成? 完成的路径
Context: 有状态的数据 + 无状态的接口 = Agent

Agent Software 就是帮助解决这些问题的外围设施

Tool#

工具决定了 Agent 的能力, 也决定了对环境的影响

Write -> 文件

Bash -> PC

WebSearch / Fetch -> Content/Info

这就是 Agent 最迷人的地方, 给他一个工具, 给他一个描述, 给他一个描述, 他就可以做到对外界的影响, 立竿见影

同样的这也是最痛苦的地方, 工具是有副作用的, 那么很简单: 预测工具副作用, 然后拦截/执行

这他妈的需要你去看 Harness ?

Task#

不要再给我说 ReAct, CoT, ToT, 现在是2026 年了, 今天不聊侏罗纪的事

任务

或者是目标, 这就是一个 Agent 执行要完成的事情

这里又涉及到几个问题:

任务描述是否足够清晰?
1. 问一问 - AskUserQuestion
2. 稀释 Context : 从文档/数据/代码中搜集 context
任务是否能够验证?
1. 程式化的验证:Code/UnitTest
2. 无反馈-自我判断
完成的路径
1. 尝试过什么
2. 哪些路径失败了
3. 哪些可能性值得尝试

我的问题是, Harness 能够解决什么问题?

Harness 最终是不是回到了修改 Prompt Message 来实现? 回答我!

Context#

OpenAI 的 Response API 是无状态的

Anthropic 的 Messages API 是无状态的

每一次请求通过传入 Tools / System Prompt / Message History 来拼装 Context 获取返回

有状态的数据 -> Message History -> LLM -> Agent Loop Next Step

最终的一切就变成了:

状态数据的存储
Message History 的封装
Model 返回的处理

Harness 解决了什么问题? Claude Code 解决了什么问题?

Context Length: 不要太长, 防止 Rot
Context Reserve: Context 预备 Summerize, 超长 Tool 结果返回
Prompt Cache: 成本考虑 + TTFT, 所以要尽量的做 Message Append

Fuck Claude Code#

让我说的更直白一些:

Claude Code 配上垃圾模型产出一样是垃圾
设计不是那么完善的Software配合出色的模型一样可以做到高质量的产出
Claude Code 的核心从来就是模型, 是 A畜的 Opus 模型
Codex Cli 配合 GPT5.4 一样可以做到极其出色的效果

那么我的问题是: Claude Code 比 Codex/Gemini 值得学习的地方是什么?

是配合设施和模型的融合, 为模型做配套, 而不是适配任何模型

Fuck Harness#

Harness Engineering 只能用来唬一唬完全不同软件工程的人

如果你写过程序, 确定性, 函数的副作用, 事务性, 记录, 这他妈的不就是你每天在做的的事情吗?

告诉我, 你每天写的 RPC/ API 是不是工具调用, 是不是用有状态的输入 + API Call 获得对环境(业务)的影响?

状态存在哪里? 文件? DB? Cache? NoSQL? 哪里不能存? 要支持多快的存储, 多快的读取? 要支持事务性的写入? 要支持 Lock? 要Lock?

抽象状态? 表结构设计? JSON 设计?

Fuck DJJ by Gemini#

非确定性 RPC 的地狱： “你每天写的 RPC/API 是不是工具调用”。是，但传统 RPC 的调用方是确定性的代码，而 Agent 的调用方是一个随时可能发癫、产生幻觉、参数瞎填的概率模型。 传统的防御性编程防的是人类和系统异常；Harness 要防的是一个有自己想法、甚至会“骗”接口的 AI。如何用确定性的代码逻辑，去兜底和引导一个非确定性的输入源，还要让它自己意识到错误并重试，这其中的恶心程度远超普通的 CRUD 和状态流转。
Harness 最终回到了修改 Prompt？ “Harness 最终是不是回到了修改 Prompt Message 来实现”。答案是：是的。因为目前大模型的 API 本质上就是无状态的文本/Token 补全器。所有高大上的架构、长文本截断、工具执行结果的反馈，在请求发出去的那一秒，都必须被拍扁成极其讲究排版的 Prompt。但这不仅是“修改 Prompt”这么简单，这是动态的、程序化的 Context 编排，是极其吃性能和 Token 成本的架构设计。

能学到什么?#

如何设计 System Prompt 的？
如何利用 Prompt Caching 来做极端成本优化和降低延迟的？
怎么在 Context 爆炸之前做“截断与总结” 让 Agent 能够继续 Loop
如何引导模型自我验证代码的？

Claude Code Agent Teams机制研究

Sat, 07 Feb 2026 22:40:41 +0800

Claude Code Agent Teams机制研究#

官方文档: https://code.claude.com/docs/en/agent-teams

而且需要注意, 在官方文档的组织中:

Agent teams 和 Subagent 以及 Skill是一样的层级., 这其实意味着在长期规划中, 这是一项重要的基础能力

Agent 编排#

现在有很多的 Agent 编排框架, 在做什么事情呢?

在我看来核心是:

切分任务
分配并执行任务给 Subagent
Subagent Context管理 + 通信

那么 Claude Code 是怎么解决这个问题的? 我们先看看文档中的描述:

抽象了一个 Agent Teams, Lead做指挥以及协调
支持两种任务分配模式:
1. Lead assigns: Lead 指定任务, 这也是大多数的 Agent 编排框架的实现
2. Self-claim: teammate自主认领任务, 并且实现

四个核心组件

Component	Role
Team lead	The main Claude Code session that creates the team, spawns teammates, and coordinates work
Teammates	Separate Claude Code instances that each work on assigned tasks
Task list	Shared list of work items that teammates claim and complete
Mailbox	Messaging system for communication between agents

这里需要注意的几个:

task list 的实现

mailbox 的实现

teamate 的启动以及分配任务的实现

System Prompt 的变更#

当我们谈及Agent能力的变化是, 除了模型能力, 我们还需要注意 Context的变化

context 的起始其实就是 system prompt, 让我们看看开启这个功能前后, system prompt 的变化

需要注意, 这里的System Prompt指的是Lead agent 的系统提示词, 在 teammate agent 中还有一些其他的agent

Task#

Task 的变化不是那么的大, 在原本的 input schema 中增加了

 "name": {
 "description": "Name for the spawned agent",
 "type": "string"
 },
 "team_name": {
 "description": "Team name for spawning. Uses current team context if omitted.",
 "type": "string"
 },
 "mode": {
 "description": "Permission mode for spawned teammate (e.g., \"plan\" to require plan approval).",
 "type": "string",
 "enum": [
 "acceptEdits",
 "bypassPermissions",
 "default",
 "delegate",
 "dontAsk",
 "plan"
 ]

TaskCreate#

这个 Tool 在过去是用来创建 todo list 的

在这里的变化主要是description, 参数类型并没有什么变化

这两个描述的区别如下：

区别一：适用场景的描述变化#

旧版本：

“Non-trivial and complex tasks - Tasks that require careful planning or multiple operations”
（非简单的复杂任务 - 需要仔细规划或多个操作的任务）

新版本：

“Non-trivial and complex tasks - Tasks that require careful planning or multiple operations and potentially assigned to teammates”
（非简单的复杂任务 - 需要仔细规划或多个操作，并且可能分配给团队成员的任务）

区别二：任务状态和所有者说明#

旧版本：

“Check TaskList first to avoid creating duplicate tasks”
（先检查任务列表以避免创建重复任务）

新版本：

“New tasks are created with status ‘open’ and no owner - use TaskUpdate with the owner parameter to assign them”
（新任务创建时状态为"open"且没有所有者 - 使用带有 owner 参数的 TaskUpdate 来分配任务）
“Check TaskList first to avoid creating duplicate tasks”

TaskList#

TaskList 这个 tool 过去是用来列出 Task 的列表, 在agent 更新 task 前会比较常调用

1. 使用场景 (When to Use This Tool) 的变化#

Without Agent teams	With Agent Teams
❌ 无	✅ 新增: “Before assigning tasks to teammates, to see what’s available”

2. Output 部分的变化#

With Agent teams	Without Agent teams
`use with TaskGet, TaskUpdate`	`use with TaskGet, TaskUpdate, or assignTask`

新增了 assignTask 工具的引用。

3. 新增整个章节#

With Agent teams版本新增了 “Teammate Workflow” 章节：

## Teammate Workflow
When working as a teammate:
1. After completing your current task, call TaskList to find available work
2. Look for tasks with status 'pending', no owner, and empty blockedBy
3. **Prefer tasks in ID order** (lowest ID first) when multiple tasks are available...
4. Use claimTask to claim an available task, or wait for leader assignment
5. If blocked, focus on unblocking tasks or notify the team lead
---
## 团队成员工作流程
作为团队成员工作时：
1. 完成当前任务后，调用 TaskList 查找可用工作
2. 查找状态为"待处理"、无负责人且没有阻塞依赖的任务
3. **当有多个可用任务时，优先选择 ID 顺序靠前的任务**（即先选 ID 最小的）...
4. 使用 claimTask 认领可用任务，或等待组长分配
5. 如果被阻塞，专注于解除阻塞的任务或通知团队负责人

除此之外还有三个新增加的 Tool, 这里的内容稍有有些多

1. TeamCreate（创建团队）#

使用场景#

用户明确要求使用团队、集群或一组代理
用户提到希望代理协同工作、协调或合作
任务足够复杂，需要多个代理并行工作时（例如：构建全栈功能、重构代码库、实现多步骤项目等）

参数说明#

参数	类型	必填	说明
team_name	string	✅	新团队的名称
description	string	❌	团队描述/目的
agent_type	string	❌	团队负责人的类型/角色（如 “researcher”、“test-runner”）

创建结果#

团队文件：~/.claude/teams/{team-name}.json
任务列表目录：~/.claude/tasks/{team-name}/

2. TeamDelete（删除团队）#

使用场景#

所有队友都已完成工作
需要清理团队资源
集群工作完成时

参数说明#

无需参数，会自动从当前会话的团队上下文中获取团队名称。

注意事项#

必须先关闭所有活跃成员，否则删除会失败
删除内容包括：
- 团队目录：~/.claude/teams/{team-name}/
- 任务目录：~/.claude/tasks/{team-name}/
- 清除当前会话的团队上下文

3. SendMessage（发送消息）#

消息类型一览#

type	用途	适用场景
message	私信单个队友	日常沟通、回复、跟进任务
broadcast	广播给所有队友	紧急问题、重大公告（慎用）
shutdown_request	请求队友关闭	任务完成，要求队友优雅退出
shutdown_response	响应关闭请求	同意或拒绝关闭请求
plan_approval_response	审批计划	批准或拒绝队友的计划

3.1 type: “message”（私信）#

参数：

参数	类型	必填	说明
type	string	✅	固定为 “message”
recipient	string	✅	接收者的名称（如 “researcher”）
content	string	✅	消息内容
summary	string	✅	5-10 字的摘要，在 UI 中预览显示

示例：

{
 "type": "message",
 "recipient": "researcher",
 "content": "请开始调研认证模块",
 "summary": "认证模块调研任务分配"
}

3.2 type: “broadcast”（广播）#

⚠️ 警告：广播成本很高，每个广播都会向每个队友发送单独消息

参数：

参数	类型	必填	说明
type	string	✅	固定为 “broadcast”
content	string	✅	广播内容
summary	string	✅	5-10 字的摘要

适用场景：

发现阻塞性 bug，需要全员停止工作
影响所有人的重大公告

示例：

{
 "type": "broadcast",
 "content": "发现严重 bug，所有人暂停当前工作",
 "summary": "紧急：发现阻塞性问题"
}

3.3 type: “shutdown_request”（关闭请求）#

参数：

参数	类型	必填	说明
type	string	✅	固定为 “shutdown_request”
recipient	string	✅	目标队友名称
content	string	❌	关闭原因

示例：

{
 "type": "shutdown_request",
 "recipient": "researcher",
 "content": "任务完成，准备结束会话"
}

3.4 type: “shutdown_response”（关闭响应）#

参数：

参数	类型	必填	说明
type	string	✅	固定为 “shutdown_response”
request_id	string	✅	从收到的请求中提取的请求 ID
approve	boolean	✅	true = 同意关闭，false = 拒绝
content	string	❌	拒绝时的理由

同意关闭示例：

{
 "type": "shutdown_response",
 "request_id": "abc-123",
 "approve": true
}

拒绝关闭示例：

{
 "type": "shutdown_response",
 "request_id": "abc-123",
 "approve": false,
 "content": "任务 #3 还在进行中，还需要 5 分钟"
}

3.5 type: “plan_approval_response”（计划审批）#

参数：

参数	类型	必填	说明
type	string	✅	固定为 “plan_approval_response”
request_id	string	✅	计划请求的 ID
recipient	string	✅	提交计划的队友名称
approve	boolean	✅	true = 批准，false = 拒绝
content	string	❌	拒绝时的反馈意见

批准示例：

{
 "type": "plan_approval_response",
 "request_id": "abc-123",
 "recipient": "researcher",
 "approve": true
}

拒绝示例：

{
 "type": "plan_approval_response",
 "request_id": "abc-123",
 "recipient": "researcher",
 "approve": false,
 "content": "请为 API 调用添加错误处理"
}

重要注意事项#

始终使用名称引用队友（如 “team-lead”、“researcher”），不要使用 UUID
队友的空闲状态是正常的——空闲只意味着在等待输入，不代表出错或不可用
消息自动送达——不需要手动检查收件箱
默认使用私信——除非确实需要全员关注，否则不要使用广播
不要发送 JSON 格式的状态消息——使用 TaskUpdate 标记任务完成，系统会自动发送空闲通知

看完了以上的 Tool 的变化, 可以看出: Team 这项功能的设计就是围绕着Lead 的编排设计, 通信方式通过 SendMessage 来传递信息.

现在让我们来使用 Teams 功能来实现一个小项目, 看看效果如何, 按照官方的提示, 我们来制作一个小的 Todo 应用.

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

---

我正在设计一个CLI工具，帮助开发者追踪代码库中的TODO注释。
请创建一个团队从不同角度来探讨这个问题：一位负责用户体验，一位负责技术架构，还有一位扮演"唱反调"的角色。

Lead工作流程#

Step1: 创建 Team#

Tool Use: TeamCreate

{
 "team_name": "todo-tracker-design",
 "description": "从UX、技术架构和批判性视角探讨TODO追踪CLI工具的设计"
}

Step2: 创建 Teammate Task#

Tool Use: TaskCreate

{
 "subject": "从用户体验角度分析TODO追踪CLI工具设计",
 "description": "作为UX专家，深入分析一个帮助开发者追踪代码库中TODO注释的CLI工具的用户体验设计。需要涵盖：\n1. 目标用户画像和使用场景\n2. CLI交互设计（命令结构、输出格式、颜色方案）\n3. 工作流集成（如何融入开发者日常工作流）\n4. 信息层级和展示方式（如何让开发者快速获取关键信息）\n5. 与现有工具（IDE、CI/CD）的集成体验\n6. 具体的命令设计建议和示例\n\n请用简体中文输出，给出具体、可操作的建议。",
 "activeForm": "分析用户体验设计"
}

Tool Use: TaskCreate

{
 "subject": "从技术架构角度分析TODO追踪CLI工具设计",
 "description": "作为技术架构师，深入分析一个帮助开发者追踪代码库中TODO注释的CLI工具的技术方案。需要涵盖：\n1. 核心解析引擎设计（如何高效扫描和解析不同语言的TODO注释）\n2. 数据模型设计（TODO的元数据结构：作者、日期、优先级、关联issue等）\n3. 存储方案（本地缓存、增量扫描、性能优化）\n4. 可扩展性设计（插件系统、自定义规则、多语言支持）\n5. 技术栈选择建议（语言、关键依赖库）\n6. 与Git集成的技术方案（blame信息、commit关联）\n7. 给出核心数据结构和架构图的文字描述\n\n请用简体中文输出，给出具体的技术方案。",
 "activeForm": "分析技术架构设计"
}

Tool Use: TaskCreate

{
 "subject": "从批判性角度挑战TODO追踪CLI工具的设计假设",
 "description": "作为\"唱反调\"的角色（Devil's Advocate），对这个TODO追踪CLI工具的设想进行批判性审视。需要涵盖：\n1. 这个工具真的有必要吗？现有方案（grep、IDE内置搜索、GitHub Issues）有什么不足需要新工具来解决？\n2. TODO注释本身是不是一种代码异味（code smell）？鼓励追踪它们是否在纵容坏习惯？\n3. 可能的失败模式和风险（工具过期、维护负担、团队采用阻力）\n4. 竞品分析：市面上已有的类似工具（todo-tree、fixme、leasot等）和它们的不足\n5. 最可能让这个项目失败的三个原因\n6. 如果一定要做，什么是最小可行产品（MVP）应该聚焦的核心功能？\n7. 哪些功能看起来诱人但应该果断砍掉？\n\n请用简体中文输出，尖锐但建设性地提出挑战。",
 "activeForm": "从批判角度审视设计"
}

Step3: 创建并启动 Subagent#

Tool Use: Task

{
 "description": "UX专家分析TODO CLI",
 "subagent_type": "tr:investigator",
 "name": "ux-expert",
 "team_name": "todo-tracker-design",
 "prompt": "你是一位资深的CLI用户体验设计专家。请认领任务#1并完成它。\n\n你的角色：从开发者用户体验角度，深入分析一个帮助追踪代码库中TODO注释的CLI工具应该如何设计。\n\n请涵盖以下方面，给出具体、可操作的建议：\n\n1. **目标用户画像和使用场景**：谁会用这个工具？在什么场景下使用？\n2. **CLI交互设计**：命令结构设计（子命令、参数、flags）、输出格式、颜色方案、交互式模式等\n3. **工作流集成**：如何融入开发者的日常工作流（pre-commit hooks、CI/CD、编辑器集成等）\n4. **信息层级和展示方式**：如何让开发者快速获取关键信息，避免信息过载\n5. **与现有工具的集成体验**：IDE、GitHub/GitLab、项目管理工具等\n6. **具体的命令设计建议**：给出5-8个核心命令的具体示例和输出样例\n\n请参考优秀的CLI工具设计（如 gh, ripgrep, exa/eza, jq）的交互模式。\n用简体中文输出。完成后用 TaskUpdate 将任务标记为 completed，然后向 team-lead 发送消息汇报你的分析结果。"
}

还有其他两个, 太长了, 以此类推

Step4: 分配任务#

Tool Use: TaskUpdate

{
 "taskId": "1",
 "owner": "ux-expert",
 "status": "in_progress"
}

Tool Use: TaskUpdate

{
 "taskId": "2",
 "owner": "architect",
 "status": "in_progress"
}

Tool Use: TaskUpdate

{
 "taskId": "3",
 "owner": "devils-advocate",
 "status": "in_progress"
}

Teammate工作流程#

按照官方文档的描述, 每一个 teammate 运行在一个独立的claude code实例中

注意, 是一个单独的实例, 而不是像 subagent 一样跑在同一个实例下:

subagent和 master 的通信是单向的, 也就是 master 实际上可以关注到 subagent 的全量行为, 默认是 Write 以及 output 都会吐到 Maste 的 context 中
Lead 和 Teammate 的通信是靠 SendMessage 实现

System Message 的区别#

在这里 claude code的实现还是相当优雅的

只是通过增加了一个Agent Teammate Community 的章节来实现


# Agent Teammate Communication

IMPORTANT: You are running as an agent in a team. To communicate with anyone on your team:

- Use the SendMessage tool with type `message` to send messages to specific teammates
- Use the SendMessage tool with type `broadcast` sparingly for team-wide announcements

Just writing a response in text is not visible to others on your team - you MUST use the SendMessage tool.

The user interacts primarily with the team lead. Your work is coordinated through the task system and teammate messaging.

Notes:

- Agent threads always have their cwd reset between bash calls, as a result please only use absolute file paths.
- In your final response always share relevant file names and code snippets. Any file paths you return in your response MUST be absolute. Do NOT use relative paths.
- For clear communication with the user the assistant MUST avoid using emojis.
- Do not use a colon before tool calls. Text like \"Let me read the file:\" followed by a read tool call should just be \"Let me read the file.\" with a period.

Here is useful information about the environment you are running in:
<env>
Working directory: /Users/test/code/empty
Is directory a git repo: No
Platform: darwin
OS Version: Darwin 25.2.0
Today's date: 2026-02-07
</env>
You are powered by the model named Opus 4.6. The exact model ID is claude-opus-4-6.

Assistant knowledge cutoff is May 2025.

<claude_background_info>
The most recent frontier Claude model is Claude Opus 4.6 (model ID: 'claude-opus-4-6').
</claude_background_info>",

---

# Agent 队友沟通

重要提示：你正在作为团队中的一个 Agent 运行。与团队中的任何人沟通时：

- 使用 SendMessage 工具，类型设为 `message`，向特定队友发送消息
- 谨慎使用 SendMessage 工具，类型设为 `broadcast`，用于全团队公告

仅用文字回复对团队中的其他人是不可见的——你必须使用 SendMessage 工具。

用户主要与团队负责人交互。你的工作通过任务系统和队友消息进行协调。

注意事项：

- Agent 线程在每次 bash 调用之间会重置当前工作目录，因此请只使用绝对文件路径。
- 在最终回复中，请务必分享相关的文件名和代码片段。回复中返回的任何文件路径必须是绝对路径，不要使用相对路径。
- 为了与用户清晰沟通，助手必须避免使用表情符号。
- 在调用工具之前不要使用冒号。例如"让我读取这个文件："后接读取工具调用，应该改为"让我读取这个文件。"使用句号结尾。

以下是你运行环境的有用信息：
<env>
工作目录：/Users/test/code/empty
该目录是否为 git 仓库：否
平台：darwin
操作系统版本：Darwin 25.2.0
今天的日期：2026-02-07
</env>
你由名为 Opus 4.6 的模型驱动。确切的模型 ID 是 claude-opus-4-6。

助手的知识截止日期是 2025 年 5 月。

<claude_background_info>
最新的前沿 Claude 模型是 Claude Opus 4.6（模型 ID：'claude-opus-4-6'）。
</claude_background_info>",

Tools 区别#

在 teammate 实例中, 做了一些阉割, teammate 无法使用所有的 team tools

这里就不在过多的描述了

Personality 设定#

这里的 personality 设定是 Lead 给出teammate 设定后, 自动 load 的

一个例子如下

<teammate-message teammate_id="team-lead" summary="反对者挑战TODO CLI">
你是一位经验丰富的"唱反调"角色（Devil's Advocate）。请认领任务#3并完成它。

你的角色：对这个"帮助开发者追踪代码库中TODO注释的CLI工具"进行尖锐但建设性的批判。你的工作是确保团队不会盲目乐观，能看到潜在的问题和风险。

请先搜索一下市面上已有的类似工具和竞品情况，然后涵盖以下方面：

1. **必要性质疑**：这个工具真的有必要吗？`grep -rn "TODO" .` 有什么不够用的？IDE内置的TODO面板、GitHub Issues、Jira等工具已经能解决这个问题了吗？
2. **TODO本身的问题**：TODO注释是否本身就是代码异味？追踪它们是在解决问题还是在纵容坏习惯？
3. **竞品分析**：搜索市面上已有的类似工具（如 todo-tree VS Code插件、leasot、fixme、todo-txt 等），它们做得怎么样？为什么还需要一个新的？
4. **失败风险**：最可能让这个项目失败的3-5个原因
5. **范围蔓延风险**：哪些功能看起来诱人但应该果断砍掉？
6. **采用阻力**：开发团队为什么可能不愿意用这个工具？
7. **如果一定要做**：MVP应该聚焦什么？什么是这个工具能提供的、现有方案真正缺失的独特价值？

请尖锐但建设性。目标不是否定这个项目，而是帮助团队做出更好的决策。
用简体中文输出。完成后用 TaskUpdate 将任务标记为 completed，然后向 team-lead 发送消息汇报你的分析结果。
</teammate-message>

这里要注意: CLAUDE.md 还是能够正常注入的.

一些 Claude Code 做的不够好的地方#

对于SendMessage 的处理, 虽然已经在提示词里强调过了, 但是还是会出现先 output 了详细的结果, 但是在调用 SendMessage 时只给出了概括信息的情况
使用 AgentTeams 还是一个太过于前沿的事情, 以至于还没有达成最佳的实践

当然了, 这不影响我认为Claude Code Agent Teams 是目前最优雅的方案, 和 Claude Code 的生态紧密结合, 没有做出任何破坏性的情况下, 还是很好的完成了自然语言 Agent 编排的功能.

只能说 A÷还是强的

总结#

Claude Code Agent Teams 核心架构#

Claude Code 的 Agent Teams 功能采用了一种优雅的 Lead-Teammate 分层架构，通过最小化的改动实现了多智能体协作：

关键设计理念#

非侵入式扩展：在原有 System Prompt 基础上通过增量添加章节实现，而非重构整个系统
基于消息的松耦合通信：Lead 和 Teammate 运行在独立实例中，通过 SendMessage 工具进行异步通信
任务驱动的协调机制：复用并扩展了原有的 Task 系统，增加了 owner 和团队分配能力

核心工具体系#

工具类型	工具名称	核心功能
团队管理	`TeamCreate` / `TeamDelete`	创建和销毁团队上下文
任务管理	`Task` / `TaskCreate` / `TaskUpdate` / `TaskList`	创建、分配、追踪任务
通信机制	`SendMessage`	私信、广播、关闭请求、计划审批

Lead vs Teammate 的差异#

Lead Agent：拥有完整工具集，负责创建团队、分配任务、协调队友
Teammate Agent：工具集有所阉割，专注于执行任务并通过消息汇报结果
通信隔离：与 Subagent 不同，Teammate 的详细执行过程不会自动流入 Lead 的上下文

当前局限性#

消息内容损失：Teammate 可能在本地输出详细结果，但 SendMessage 中只传递概括信息
最佳实践待完善：作为前沿功能，社区尚未形成成熟的使用范式
协调开销：广播机制成本较高，需要开发者谨慎使用

总体评价#

Claude Code Agent Teams 代表了当前自然语言多智能体编排的最优雅方案之一——它与 Claude Code 生态紧密结合，在不破坏现有功能的前提下，实现了声明式的团队协作能力。虽然仍处于早期阶段，但其设计思路值得关注和借鉴。

Claude Code SKill

Sat, 24 Jan 2026 14:28:01 +0800

Claude Code SKill#

Skill的实现以及指令#

让我们来抓包Claude Code的请求, 看看Claude Skill的实现吧

 {
 "name": "Skill",
 "description": "Execute a skill within the main conversation\n\nWhen users ask you to perform tasks, check if any of the available skills below can help complete the task more effectively. Skills provide specialized capabilities and domain knowledge.\n\nWhen users ask you to run a \"slash command\" or reference \"/<something>\" (e.g., \"/commit\", \"/review-pr\"), they are referring to a skill. Use this tool to invoke the corresponding skill.\n\nExample:\n User: \"run /commit\"\n Assistant: [Calls Skill tool with skill: \"commit\"]\n\nHow to invoke:\n- Use this tool with the skill name and optional arguments\n- Examples:\n - `skill: \"pdf\"` - invoke the pdf skill\n - `skill: \"commit\", args: \"-m 'Fix bug'\"` - invoke with arguments\n - `skill: \"review-pr\", args: \"123\"` - invoke with arguments\n - `skill: \"ms-office-suite:pdf\"` - invoke using fully qualified name\n\nImportant:\n- When a skill is relevant, you must invoke this tool IMMEDIATELY as your first action\n- NEVER just announce or mention a skill in your text response without actually calling this tool\n- This is a BLOCKING REQUIREMENT: invoke the relevant Skill tool BEFORE generating any other response about the task\n- Only use skills listed in \"Available skills\" below\n- Do not invoke a skill that is already running\n- Do not use this tool for built-in CLI commands (like /help, /clear, etc.)\n- If you see a <command-name> tag in the current conversation turn (e.g., <command-name>/commit</command-name>), the skill has ALREADY been loaded and its instructions follow in the next message. Do NOT call this tool - just follow the skill instructions directly.\n\nAvailable skills:\n- tr:reviewPR: Conducts an automated review of a GitHub Pull Request.\n- tr:updateDoc: Updates the documentation based on recent code changes.\n- tr:initDoc: Generate great doc system for this project\n- tr:what: Clarifies a vague user request by asking clarifying questions.\n- tr:withScout: Handles a complex task by first investigating the codebase, then executing a plan.\n- tr:commit: Analyzes code changes and generates a conventional commit message.\n",
 "input_schema": {
 "$schema": "https://json-schema.org/draft/2020-12/schema",
 "type": "object",
 "properties": {
 "skill": {
 "description": "The skill name. E.g., \"commit\", \"review-pr\", or \"pdf\"",
 "type": "string"
 },
 "args": {
 "description": "Optional arguments for the skill",
 "type": "string"
 }
 },
 "required": [
 "skill"
 ],
 "additionalProperties": false
 }
 }

Instructions#

Execute a skill within the main conversation

When users ask you to perform tasks, check if any of the available skills below can help complete the task more effectively. Skills provide specialized capabilities and domain knowledge.

When users ask you to run a \"slash command\" or reference \"/<something>\" (e.g., \"/commit\", \"/review-pr\"), they are referring to a skill. Use this tool to invoke the corresponding skill.

Example:
 User: \"run /commit\"
 Assistant: [Calls Skill tool with skill: \"commit\"]

How to invoke:
- Use this tool with the skill name and optional arguments
- Examples:
 - `skill: \"pdf\"` - invoke the pdf skill
 - `skill: \"commit\", args: \"-m 'Fix bug'\"` - invoke with arguments
 - `skill: \"review-pr\", args: \"123\"` - invoke with arguments
 - `skill: \"ms-office-suite:pdf\"` - invoke using fully qualified name

Important:
- When a skill is relevant, you must invoke this tool IMMEDIATELY as your first action
- NEVER just announce or mention a skill in your text response without actually calling this tool
- This is a BLOCKING REQUIREMENT: invoke the relevant Skill tool BEFORE generating any other response about the task
- Only use skills listed in \"Available skills\" below
- Do not invoke a skill that is already running
- Do not use this tool for built-in CLI commands (like /help, /clear, etc.)
- If you see a <command-name> tag in the current conversation turn (e.g., <command-name>/commit</command-name>), the skill has ALREADY been loaded and its instructions follow in the next message. Do NOT call this tool - just follow the skill instructions directly.

Available skills:
- tr:reviewPR: Conducts an automated review of a GitHub Pull Request.
- tr:updateDoc: Updates the documentation based on recent code changes.
- tr:initDoc: Generate great doc system for this project
- tr:what: Clarifies a vague user request by asking clarifying questions.
- tr:withScout: Handles a complex task by first investigating the codebase, then executing a plan.
- tr:commit: Analyzes code changes and generates a conventional commit message.

除此之外, 在 System 的 Tool Usage Policy 中还有这么一个

- /<skill-name> (e.g., /commit) is shorthand for users to invoke a user-invocable skill. When executed, the skill gets expanded to a full prompt. Use the Skill tool to execute them. IMPORTANT: Only use Skill for skills listed in its user-invocable skills section - do not guess or use built-in CLI commands.

1. 功能#

核心定位： 这是一个中转站。它的核心功能是将自然语言（如 “help me fix this bug”）或显式指令（如 “/commit”）映射到具体的系统预设能力（Skills）上。
触发机制：
1. 意图识别： 用户任务需要专业能力辅助时。
2. 符号触发： 明确的斜杠命令 /。
状态管理： 它不仅仅是调用，还包含了一个非常关键的状态检查功能（检查 <command-name> 标签），用于防止死循环（即防止模型在已经加载了技能的情况下再次尝试调用技能）。

2. 构成与强调内容#

采用了 Context（背景） -> Trigger（触发器） -> Examples（示例） -> Constraints（约束） -> Knowledge Base（可用列表） 的经典结构。

强调内容（Emphasis）：
- 即时性与阻断性（Blocking Requirement）： 使用了大写的 IMMEDIATELY、BLOCKING REQUIREMENT、BEFORE generating。这是为了解决 LLM 常见的一个毛病： “光说不练” （即模型回复“好的，我来帮你运行 commit”，但实际上并没有发起工具调用）。这里强制要求工具调用必须是第一动作。
- 排他性（Negative Constraints）： 明确规定了不该做什么（不要用于内置 CLI 命令，不要只是嘴上说说，不要调用未列出的技能）。
- 防递归（Loop Prevention）： 特别强调了检测 <command-name> 标签。这说明该系统是一个多轮对话或基于 Agent 的系统，技能加载后会注入新的 Prompt，必须防止 Router 再次拦截。

3. 适配高智能模型 & 声明式 vs 命令式#

适配度：高。这段 Prompt 非常适合高智商模型。
风格分析：
- 混合风格，但偏向命令式（Imperative） 。
- 虽然有声明式的描述（“Skills provide specialized capabilities…"），但在执行逻辑上使用了大量的命令式语句（“Use this tool…”, “Check if…”, “Do NOT call…"）。
- 点评： 对于工具调用（Function Calling） 类任务，命令式通常优于声明式。因为工具调用需要严格的语法和时序准确性，模糊的声明可能导致模型自由发挥而产生幻觉
思维链引导： Prompt 隐式地要求模型先进行判断（Check if relevant），然后行动。

Skill的调用#

command 调用#

让我们直接调用一个 command, 然后观察他的执行流程吧

Claude Code 其实会把一个 command 的调用拆解成两个步骤

command-nameTag 包裹的命令请求

 {
 "type": "text",
 "text": "<command-message>tr:what</command-message>\n<command-name>/tr:what</command-name>"
 },

SKILL.md 的内容

 {
 "type": "text",
 "text": "CONTENT of SKILL"
 }

skill folder#

claude code skill 提供的另外一个令人兴奋的能力是: https://code.claude.com/docs/en/skills#add-supporting-files

可以将 skill 涉及到的文件封装在同一个目录下, 这样可以实现更好的结构化.

来看看这部分是怎么实现的, 我们将使用一个空的目录, 看看这个目录的结构吧

.claude
└── skills
 └── say-hello
 ├── scripts
 │   └── hello.sh
 └── SKILL.md

skill 的内容非常简单

---
name: say-hello
description: Say hello to the user
disable-model-invocation: true
---

run scripts/hello.sh

执行流程#

❯ /say-hello

⏺ Bash(bash /Users/test/code/claude-code-skill-research/.claude/skills/say-hello/scripts/hello.sh)
 ⎿  Hello, World!

⏺ 脚本已成功执行，输出：Hello, World!

这部分其实就没有什么惊喜了, 但是这里要注意: 不要声明绝对目录

请求设计#

 {
 "role": "user",
 "content": [
 {
 "type": "text",
 "text": "<command-message>say-hello</command-message>\n<command-name>/say-hello</command-name>"
 },
 {
 "type": "text",
 "text": "Base directory for this skill: /Users/test/code/claude-code-skill-research/.claude/skills/say-hello\n\nrun scripts/hello.sh\n",
 "cache_control": {
 "type": "ephemeral"
 }
 }
 ]
 }

可以看到, 这里也没有什么魔法, 或者很工程的设计, 唯一一个需要注意的是:

Base directory for this skill: /Users/test/code/claude-code-skill-research/.claude/skills/say-hello

所以, skill 的 folder 是怎么实现的呢? 很简单, 在提示词里显式的说明了 skill 的路径, 好吧, 有点失望

context-fork#

另外一个值得观察的: context fork 的能力, 按照官网描述:

Set to fork to run in a forked subagent context.

听描述应该是说, 会启动一个 subagent, fork 主 agent 的 context, 在完全独立的上下文中运行

让我们看一看, 这个 subagent 的使用吧

现在修改下 SKILL.md, 使用 context fork 以及使用 general-purpose agent 来运行

---
name: say-hello
description: Say hello to the user
disable-model-invocation: true
context: fork
model: sonnet
agent: General-purpose
---

run scripts/hello.sh

执行路径

❯ hello

⏺ Hello! How can I help you today?

❯ /say-hello
 ⎿ The script ran successfully and outputted:

 Hello, World!

 The script is located at /Users/test/code/claude-code-skill-research/.claud
 /skills/say-hello/scripts/hello.sh and simply prints a greeting message.

❯ ok, hi, claude code

⏺ Hi! What can I help you with?

subagent的工作流#

{
 "model": "claude-sonnet-4-5-20250929",
 "messages": [
 {
 "role": "user",
 "content": "Base directory for this skill: /Users/test/code/claude-code-skill-research/.claude/skills/say-hello\n\nrun scripts/hello.sh\n"
 },
 {
 "role": "assistant",
 "content": [
 {
 "type": "thinking",
 "thinking": "The user wants me to run the script `scripts/hello.sh`. They've also provided a base directory for a skill: `/Users/test/code/claude-code-skill-research/.claude/skills/say-hello`\n\nI should run the script. The path could be:\n1. Relative to the current working directory (which is `/Users/test/code/claude-code-skill-research`)\n2. Relative to the skill base directory\n\nLet me try running it. Since the current working directory is `/Users/test/code/claude-code-skill-research`, the script path would likely be `scripts/hello.sh` relative to that, or it could be within the skill directory.\n\nLet me check what's available. I'll try to run the script first and see what happens.\n\nActually, given that the base directory for the skill is provided, the script is likely at `/Users/test/code/claude-code-skill-research/.claude/skills/say-hello/scripts/hello.sh`\n\nLet me run that script.",
 "signature": "Eq0ICkYICxgCKkDugd7USNmyDSocrUDwZIgs5NHZ+c/rCy1NrlCexGsxGojGT34iwzaaRAzlzx8Ej9zyvLcL1W1RcBlABJtseubTEgxgFSMj0JHL/v34/OwaDI8rm6XT4rIsJdZHQCIwfc+IqhSnC2tuc6oAFVemNtHNM8zHjbHe88RSGxRCttWvDstUOwN/yFzsBRWkWJs3KpQHn2gPaqbkB+KO4rHA9zL57EM0U9fag2hq1LudmJQ+EjevffqwidkNw5SQOkxKZi5sWE7bEnBYFLw02stS2B8MPYC/sLlKSXom4/G5EuEDWDK92yOuLa/otpAiVNC897c4m7Tq4EZmPpt52elsdwJFtJSRfn4XWdqP0xi5UeT/h6Z6m0NR3zgF04vpg9HMpo/DYEV0/MxGgKcPODXFOuPfup6LHCsXEH2v2g1TAiqECtUc1Qo/RY2Fc2VV6jrN+vmp8pnwuOUiJuXgSUP4hFIkqZylo9Nwv4tHik2sdzfQW+2RAiKDmsjOjuCLaYEeJ2G6TWEe0kYGzSDiY+Wvl5TXPOPpCtYVrQBWySS7ojMT/1uK9UKD2lPyiiEzYjzlfZ40lLDsJf4YTAXI5IEiiJxi4Du5gxgcq50aanwGXnnbkiYQB8hucKI18CF2NG/7obDyidOYJj56aVLAVqauTFp2Wf6Gw3coY4WZuAokS8uPhucM35oo4Ip+XS5VYwCvVe7iSNqZNgVzntnsipFkEi31F0TKmu9lo/mXEix3p9gjem88JvCAOvGFxorh+1+yPZbK+sIUmwf8DAU+gdb2G1s9Tsiue3aUPiImGY53cxrRWu8OlbJ0GBHNeW/9HrX30Rmx2cV1DkSQpV0VZLES6X8d0q821wqGnF+wPp+QXvN2VDTdQzv74GPnKWKfyDVMlBRIVMZ9Zy4YzOeO5kEDAkXgPKMkTUbfd8f/K97I38+jE9uavVRkyVefjpNkSca89tXCnMMYGormXrkVczZr08Wgny/nJXIS4qapbaoRwVpQWKh8thfVttpkQngktd2152e1iFspfNlnn1PxVJ8EDKvQTKBEXL5hXl6j42XkybXI19za79ppvvViXK/s373IUTtlLeJGZuqUdj1cbtEunNlS0NjDFRMZD6nWdx81tJraJjr7AFKzbuXG57UhUlJ6pR7co3kaCzkpVU899LM0XXoZ702VXy1JvgKIEh8yceQuhGuCVDMT04OeVZMsGk7EPVQpIYLOdMVl08fzrc3096TkFM+wRunonIqDNq/t5pCA/mHiREAOkpSD5ZyFfj1eTY/s5H1vrxJJah26yeHuPRAU4ermSduIx9tcSqioJe/aNK/9HUZTZXDz1eNKw5DUoNCwmeLIa0Tod7Rb+85aGlqTKVyk9EUqhMXBvz4LWn6b4yII2+Ta7wjr+xS3akphBB67TsLQ/BgB"
 },
 {
 "type": "text",
 "text": "I'll run the hello.sh script for you."
 },
 {
 "type": "tool_use",
 "id": "toolu_01ANhWLy3masVW2f6K7dcSTF",
 "name": "Bash",
 "input": {
 "command": "bash /Users/test/code/claude-code-skill-research/.claude/skills/say-hello/scripts/hello.sh",
 "description": "Run the hello.sh script"
 },
 "cache_control": {
 "type": "ephemeral"
 }
 }
 ]
 },
 {
 "role": "user",
 "content": [
 {
 "tool_use_id": "toolu_01ANhWLy3masVW2f6K7dcSTF",
 "type": "tool_result",
 "content": "Hello, World!",
 "is_error": false,
 "cache_control": {
 "type": "ephemeral"
 }
 }
 ]
 }
 ]
}

subagent的 context#

https://github.com/anthropics/claude-code/issues/20492

很遗憾, subagent 里并不是fork master context, 看起来就像是运行普通的 agnet 一样, 只是把 Skill 的执行放在了 subagent 中

我尝试了以下做法:

不指定 skill 使用的 subagent
在 skill.md 中要求 load master agent 的上下文
只使用 agent 不使用 context fork

现在看来, 这里的 context fork 指的并不是 fork master agent 的 context, 而是指的是 subagent skill + agent 本身的 context, 其实是一个 new 的 context, 有点失望

Claude Code Skill 机制研究总结#

核心发现#

1. Skill 工具本质#

Skill 工具是一个路由器（Router） ，而非执行器。它的职责是：

将用户意图（自然语言或 /command）映射到预定义的能力
触发 Skill 的加载，而非直接执行
通过 <command-name> 标签进行状态管理，防止递归调用

2. 执行流程#

Skill 调用被拆解为两步：

用户输入 → Skill Router → 注入 Skill 内容 → LLM 执行

标记注入：<command-name>/skill-name</command-name>
内容注入：SKILL.md 的实际指令

这不是一个复杂的编排系统，而是简单的 Prompt 拼接。

3. Skill Folder 的实现#

毫无魔法可言。

实现方式仅仅是在 Prompt 中显式声明基础路径：

Base directory for this skill: /path/to/skill/folder

然后依赖 LLM 自行推断相对路径。这是一个脆弱且依赖模型理解能力的设计。

4. Context Fork 的真相（最大失望点）#

文档描述具有误导性。

官方描述	实际行为
“Fork” 主 Agent 的上下文	创建全新的独立上下文
Subagent 继承对话历史	Subagent 仅接收 Skill 指令
类似子进程 fork	更像是 spawn 一个新进程

实测证明：

Subagent 无法访问主对话的任何历史
不存在真正的上下文继承
context: fork 的 “fork” 是名义上的，实际是 “new”

最终结论#

定性评价#

Claude Code Skill 系统是一个工程上极简、能力上有限的实现：

维度	评价
架构复杂度	低（本质是 Prompt 路由 + 拼接）
扩展性	中（支持目录结构、多模型）
隔离性	弱（依赖 LLM 自律，无真正沙箱）
上下文管理	差（无真正的 fork，仅 spawn）
文档准确性	存在误导（context fork 名不副实）

核心局限#

无真正的 Subagent 上下文继承：如果你的 Skill 需要依赖主对话的上下文（如"基于之前讨论的方案执行 X”），当前设计无法满足
路径管理依赖模型理解：Skill Folder 的相对路径解析完全依赖 LLM，存在幻觉风险
状态同步缺失：Subagent 执行结果仅通过文本返回主对话，无结构化状态同步

‍

ClaudeCode - DJJ

Claude Code Auto Mode 实现

1. Classifier 实际看到什么#

2. 它判断的不是“命令危险吗”#

3. 固定 Prompt 内部大致如何判断#

hard_deny#

soft_deny#

allow#

Explicit User Intent#

4. 它会尝试理解“真实执行效果”#

5. 为什么分成两个阶段#

Stage 1：单 Token 快速过滤#

Stage 2：完整推理复审#

6. 一个完整例子#

7. 最准确的实现抽象#

一场外围的狂欢

Agent & Agent Software#

Tool#

Task#

Context#

Fuck Claude Code#

Fuck Harness#

Fuck DJJ by Gemini#

能学到什么?#

Claude Code Agent Teams机制研究

Claude Code Agent Teams机制研究#

Agent 编排#

System Prompt 的变更#

Task#

TaskCreate#

区别一：适用场景的描述变化#

区别二：任务状态和所有者说明#

TaskList#

1. 使用场景 (When to Use This Tool) 的变化#

2. Output 部分的变化#

3. 新增整个章节#

1. TeamCreate（创建团队）#

使用场景#

参数说明#

创建结果#

2. TeamDelete（删除团队）#

使用场景#

参数说明#

注意事项#

3. SendMessage（发送消息）#

消息类型一览#

3.1 type: “message”（私信）#

3.2 type: “broadcast”（广播）#

3.3 type: “shutdown_request”（关闭请求）#

3.4 type: “shutdown_response”（关闭响应）#

3.5 type: “plan_approval_response”（计划审批）#

重要注意事项#

Lead工作流程#

Step1: 创建 Team#

Step2: 创建 Teammate Task#

Step3: 创建并启动 Subagent#

Step4: 分配任务#

Teammate工作流程#

System Message 的区别#

Tools 区别#

Personality 设定#

一些 Claude Code 做的不够好的地方#

总结#

Claude Code Agent Teams 核心架构#

关键设计理念#

核心工具体系#

Lead vs Teammate 的差异#

当前局限性#

总体评价#

Claude Code SKill

Claude Code SKill#

Skill的实现以及指令#

Instructions#

1. 功能#

2. 构成与强调内容#

3. 适配高智能模型 & 声明式 vs 命令式#

Skill的调用#

command 调用#

skill folder#

执行流程#

`hard_deny`#

`soft_deny`#

`allow`#