老实说 Claude Code 的 Context Engineering 很复杂,而这几乎导致 Claude Code 自己搓出来的工具必然是坏的。
比如我举例子,后台任务完成了的通知用什么 LLM 消息 Role ?
System ? Tool Response ?
是 User。
Subagent 的返回用什么 Role ?
还是 User。
那么用户在 AskUserQuestion 里的回答是什么?
是 Tool Response。
你要每次都教给 Claude 吗?你要把这种东西写成 Skill 然后期待下一次 Claude 搓出来的临时小工具是对的吗?你要把这些细枝末节的东西塞进 CLAUDE.md 占用空间吗?你要期待着后面某一版 Claude Code 更新的时候把这些频繁改动且从未落进文档的细节大发慈悲地塞进 System Prompt 吗?
别挣扎了,因为我已经试过了——csift 就是踩遍了所有的坑,看遍了 Claude Code 的 minified 代码逻辑之后的工具。它有三个类型:user 、agent 、harness ,然后详细拆了这些分类:
user .message 发在输入框的那个
.answer AskUserQuestion 里的回答
.rejection 所有的有理由拒绝
agent .message Claude 做完之后说的那段总结,以及所有真说给用户的话
.thinking 打开 --verbose 之后重写的那个 reasoning ,不是 The question asks 起手的那个
.tool.use Function Tool 调用
.tool.result Function Tool 返回
.communication.inbox 别的 Claude 或者 Subagent 发来的消息
.communication.sent SendMessage 发出去的
.communication.signal 控制信号
harness .notification.workflow
.notification.monitor
.notification.subagent
.notification.background-command
.notification.task
.compaction.summary
.compaction.boundary
.command.invocation
.command.stdout
.interrupt.user
.interrupt.tool
.schedule.wakeup
.schedule.continuation
.meta.hook
.meta.loop