DJJ

AI 工作流 V4

Sat, 09 May 2026 00:03:13 +0800

AI 工作流 V4

从 24 年开始,工作流写了三版:

但是时代变化太快了, 太快了, 快到我完全想不到的程度, 回看上一篇就像是看类人猿

而且已经不能再写程序员的 AI 工作流, 因为我认为职业边界将进入彻底模糊的时代, 不会再有程序员了

Coding

推荐且仅推荐 claude code 以及 codex cli

Claude Code

Claude Code , 沟槽的 A÷, 但是架不住模型确实屌, 工具确实全面

开箱即用, 推荐, subagent 以及 agent teams 是很好的特性, plugin 生态也非常全面, 强烈推荐

Codex Cli

功能上来说是低配版的 Claude Code, 但是模型非常强劲, 5.5 是我心中的最佳编程模型

除了上下文只有 258K, ☺️

并行工作

这里要特别强调并行工作的重要性, 某种意义上也是 agent 编排的起点

superset.sh

链接

自动开启 worktree, 自动的 setup 环境, 一个窗口多开 claude code, codex

这使得并行 10 个任务不是梦

conductor

链接

坦白说, superset 抄的 conductor, 但是功能相差无几的情况下, 我更喜欢开源项目

Agent Tool

生产力 agent tool

llmdoc

链接

☺️ 排在第一, 就是屌, doc for agent, 立刻安装

superpowers

链接

现在有些臃肿了, 但是好用, 立刻安装

happy code

链接

远程也能操作 claude code / codex , 好用, 建议安装

trellis

链接

大型项目推荐使用, 但是侵入性很强

llmdoc + superpower 的结合体

pencil.dev

链接

做 UI 蛮好的, 起码能看的过去了

mcporter

链接

强烈推荐!

装几个 mcp 可能带来 100 个 tools, 太臃肿了

放在 cli 里吧, cli 天生就是渐进式披露的, 你悟到了吗?

自主 Agent

这里只写两个, 部署一个吧, 提升幸福感

以后你会看到漫天的自主 agent 的

openclaw

hermes-agent

Agent 编排

我认为 Agent 的编排现在还不够成熟，原因主要有以下几点：

使用体验非常奇怪
目前的编排工具要么需要一大堆极其琐碎的配置，要么就会出现各种乱七八糟的问题。比如 Agent 核心会突然断联，而断联后的恢复运行又是一个巨大的挑战，频繁的中断让人非常头疼。
缺乏合理的任务拆解
我实际上认为，如果你需要用到 Agent 编排，那大概率是因为你面对的是一个巨大的任务。这种情况下，必须先进行充分且合理的任务拆解，在拆解逻辑成立的前提下，才谈得上编排。
验证机制缺失
接下来是推进到 Agent 的验证，坦白讲，目前对于代码或程序产物的验证部分并没有被很好地解决。直到现在，AI 验证程序这件事依然众说纷纭，没有统一的标准或结果，甚至连生成一个基础的测试环境都非常麻烦。

所以在目前基础设施还不成熟的环境下，想要做好 Agent 的编排有点天方夜谭。

Cloud Code 的 Agent Team 实际上在解决 Agent 之间的通信问题，但是，Agent 的通信和 Agent 的编排完全是两码事。

所以这里就先简单放一个项目：

ruflo

链接

自己看吧, 一两句话说不明白

坦白说，从2024年7月到2025年7月，再到2026年的5月，我认为这个时代变化的速度太快了。快到我已经记不起来一两个月前的工作是什么样子，手写代码的能力下降得非常快。

我现在去考察一些候选人，做技术面试的时候，我已经完全放开了：

我允许你使用 AI。
我甚至鼓励你使用 AI 去解决一些开放性的问题，比如解决一个 GitHub issue 这样的问题。
我认为抗拒使用 AI 的人是不行的。

一定要拥抱这种变化。只有这样，你才能够不成为原始人，不成为类人猿，不成为那种古老的东西。我觉得拥抱变化是一个人是否年轻的标志，不拥抱变化就会死亡。

context-mode 的分析与批评 by GPT5.5

Thu, 07 May 2026 11:22:37 +0800

context-mode 的分析与批评 by GPT5.5

repo

Context Mode 实现方式与生产化评估

摘要

Context Mode 的核心价值不是“把所有信息压缩成指针”，而是尽量避免大体量原始数据直接进入主 Agent 的上下文窗口。

它更适合解决这类问题：

原始数据很大，但真正需要交给主 Agent 的结论很小。

例如日志分析、测试失败、构建错误、网页快照、文档检索、API 响应检查等场景。它的典型路径是：先把大输出留在外部环境里，再通过代码执行、索引检索或摘要提取，只把小规模结果返回给模型。

但它并不是通用的上下文压缩方案。如果一个任务最终仍然需要主 Agent 读取完整材料，那么 Context Mode 只能延迟成本，不能真正消除成本。这个边界在生产环境里非常重要。

当前方案的基本思路

Context Mode 可以理解成一层运行在 Agent 和外部工具之间的“上下文保护层”。

它主要做三件事：

拦截或提示那些容易产生大量输出的工具调用。
把大输出保存在沙盒、文件或数据库里，而不是直接放进模型上下文。
只把摘要、命中片段、统计结果或后续检索入口返回给主 Agent。

这种设计并不会要求用户修改项目里的所有 shell 脚本，也不会替换系统里的原生命令。它主要影响的是 Agent 使用工具的方式。

在支持 hooks 的平台上，它会通过工具调用前的钩子来引导 Agent：小输出和文件修改类命令可以继续走原生工具，而日志、测试、构建、网页抓取、长文档读取等容易爆上下文的操作，则会被引导到 Context Mode 提供的工具中执行。

降低上下文占用的几个机制

1. 让模型写代码分析，而不是直接阅读大输出

这是最有效的一类优化。

传统方式是：

执行命令
  -> 大量 stdout/stderr 进入上下文
  -> 模型阅读并分析

Context Mode 更推荐：

执行命令或读取数据
  -> 在沙盒里运行分析代码
  -> 只打印关键结论
  -> 主 Agent 只看到结论

例如，让脚本统计日志中最常见的错误、提取失败测试、解析 JSON 中异常字段、聚合访问日志状态码。这种情况下，原始数据不需要进入主 Agent 上下文，收益非常明显。

这类机制的本质是：

用程序计算替代模型阅读。

2. 文件内容在外部加载，只返回处理结果

对于日志、CSV、JSON、构建输出、浏览器快照等大文件，Context Mode 会让文件在外部环境中被读取和处理。模型不直接看到完整文件，只看到处理代码输出的摘要或结论。

这对“分析文件”很有用，但不适合“编辑文件”的场景。如果 Agent 要修改代码，它仍然需要读取相关代码内容，否则无法安全编辑。

3. 大输出转成可检索资料，而不是直接返回全文

当某次命令或工具调用产生很大的输出时，Context Mode 会把它保存并切分成多个片段，然后建立全文检索索引。

返回给主 Agent 的通常不是原始全文，而是类似这样的信息：

内容已索引，共包含若干片段。
如需细节，请使用指定查询继续检索。

如果调用时已经给出了明确意图，它也可能直接返回少量命中片段，例如和“TypeScript 错误”“失败测试”“HTTP 500”相关的部分。

这种方式能减少初始上下文占用，但它不是无成本的。如果 Agent 后续为了理解问题反复检索很多次，最终返回的片段总量仍然可能变大。

4. 批量执行和批量检索

Context Mode 也提供了批量执行能力：一次运行多条命令、统一保存输出、建立索引，并一次性用多个查询提取结果。

这可以减少多轮工具调用，避免 Agent 一次查一个问题、反复进出工具的低效模式。

不过，这仍然依赖 Agent 能提出相对合理的查询。如果 Agent 不知道该找什么，批量检索也可能漏掉真正重要的信息。

5. 会话恢复和历史信息检索

在长会话中，模型上下文可能被压缩或清理。Context Mode 会把一部分会话事件保存在外部，并在恢复时只注入必要提示。

详细历史不一次性塞回上下文，而是通过检索按需找回。

这对保持长任务连续性有帮助，但同样依赖检索质量和事件记录质量。

真实价值在哪里

Context Mode 最有效的场景是“大数据，小答案”。

例如：

从大量日志中找出错误类型和示例。
从测试输出中提取失败用例和关键栈。
从构建输出中找出真正导致失败的错误。
从大型 JSON 或 API 响应中提取异常记录。
从浏览器快照中提取表单、按钮、链接等结构化信息。
从文档中检索少量相关代码示例。

这些任务的共同点是：原始材料很大，但最终给主 Agent 的信息可以很小。

如果能够在外部用确定性程序完成统计、过滤和提取，Context Mode 的收益会非常明显。

主要问题和边界

1. 指针不等于压缩

把大输出变成索引入口或引用，并不天然减少总信息量。

如果主 Agent 最终还是需要读取完整内容，那么这些内容迟早还是要进入上下文。此时 Context Mode 只是把一次大读取变成多次小读取，甚至可能增加工具调用成本。

因此，它的收益取决于一个前提：

任务不需要主 Agent 阅读完整原文，只需要少量关键证据或结论。

2. 搜索不能替代理解

当前的检索更接近增强版全文搜索，而不是完整语义理解。

它擅长匹配明确的错误码、文件名、函数名、关键词、日志级别、命令输出中的固定格式。但当 Agent 不知道该搜什么，或者问题隐藏在跨段落、跨时间线、跨多个片段的模式里，纯搜索就可能失效。

例如：

关键问题不是某个错误词，而是一组事件的顺序。
真正原因出现在日志前面，报错出现在日志后面。
输出里没有明显关键词，但异常模式需要归纳。
搜索词选错，导致命中片段看起来相关但不是根因。

这就是生产环境里最需要警惕的地方。

3. 反复检索可能抵消收益

如果 Agent 反复进行多次搜索，每次返回若干片段，最终累计上下文和工具调用成本可能并不低。

这种情况下，使用一个便宜的长上下文模型或 Sub-agent 先做整体摘要，可能更快，也可能质量更好。

换句话说：

检索适合已知目标。
摘要适合未知目标。

4. 切块会损失全局结构

把 Markdown、日志或命令输出切成多个片段有利于检索，但也会带来上下文断裂。

一些问题需要跨片段理解：

错误栈和根因分布在不同位置。
测试失败摘要和详细断言不在同一块。
日志需要按时间线关联。
文档的解释需要多个章节连起来看。

因此，切块索引适合做证据定位，不应该被视为完整分析能力。

5. 系统复杂度较高

Context Mode 引入了额外组件：

MCP 服务。
hooks 规则。
沙盒执行。
外部存储。
全文索引。
缓存和失效判断。
会话恢复。
安全策略。

这些复杂度是否值得，取决于实际工作负载。如果团队主要处理大日志、大测试输出、大文档和长会话，它可能很有价值。如果任务大多是小规模代码编辑，它的收益会比较有限。

更适合生产环境的改进方向

1. 先过滤，再搜索

对日志、测试输出、构建输出、CI 输出来说，第一步不应该总是全文检索，而应该先做确定性过滤和解析。

更合理的流程是：

原始输出
  -> 识别输出类型
  -> 使用专门规则解析
  -> 提取结构化错误和告警
  -> 必要时再检索原文证据

例如，一个构建输出可以先被解析成：

{
  "summary": "构建失败：发现 3 个 TypeScript 错误和 1 个缺失模块错误。",
  "findings": [
    {
      "severity": "error",
      "kind": "typescript",
      "message": "Cannot find module '@/lib/db'",
      "location": "相关模块的导入位置",
      "evidence": "构建输出中的对应片段"
    }
  ],
  "stats": {
    "errors": 3,
    "warnings": 12
  }
}

这种结构化结果通常比搜索片段更适合 Agent 使用，因为 Agent 不需要猜关键词，也不需要先判断哪段日志值得看。

2. 建立专用解析器

日志和构建输出往往有稳定格式，适合用硬编码规则先抽取高价值信息。

优先级较高的解析对象包括：

TypeScript 编译错误。
ESLint 输出。
Jest 或 Vitest 测试失败。
Python traceback。
Java stack trace。
通用异常栈。
Docker 构建失败。
Kubernetes Pod 状态和事件。
HTTP access log。

每个解析器应尽量返回：

严重级别。
错误类别。
错误消息。
文件和行号。
去重后的错误分组。
原始证据位置。
置信度。

这样可以让主 Agent 优先看到最重要的信息，而不是从大量片段中自行判断。

3. 在检索层之上加入便宜模型或 Sub-agent

对于无法靠规则稳定解析的输出，可以让便宜的长上下文模型或 Sub-agent 做一层外部摘要。

推荐职责划分：

Context Mode：数据层
便宜模型或 Sub-agent：分析层
主 Agent：决策和执行层

数据层负责保存原文、建立索引、提供证据定位。

分析层负责阅读过滤后的材料或必要的原文窗口，判断哪些信息重要，归纳根因，输出结构化结论。

主 Agent 只消费最终摘要和关键证据，在需要确认时再回查原文。

这种方式比让主 Agent 多轮搜索更稳定，因为第一轮处理是“判断信息价值”，而不是“关键词召回”。

4. 让搜索退居为证据回查机制

在更成熟的架构里，搜索不应该承担全部分析责任。

更好的定位是：

先过滤。
再摘要。
最后按需回查证据。

也就是说：

先用规则或程序找出明显问题。
再用便宜模型或 Sub-agent 判断重要性和可能根因。
最后用搜索按需拉取精确原文证据。

这样既保留了 Context Mode 防止上下文爆炸的优势，也减少了反复搜索带来的低效。

5. 调整评估指标

不能只看“返回给主 Agent 的字节数减少了多少”。生产环境更关心整体效果。

应该同时评估：

主 Agent 上下文是否减少。
总工具调用次数是否增加。
总耗时是否变长。
总 token 成本是否下降。
是否漏掉关键错误。
摘要是否忠实。
证据是否可追溯。
多轮检索是否变成瓶颈。
对真实修复任务是否有帮助。

只有这些指标一起改善，才能说明方案在生产环境中真正有效。

结论

Context Mode 在生产环境中有价值，但它更像底层数据管道，而不是完整的智能分析方案。

它最适合负责：

隔离大输出。
保存原始证据。
提供按需检索。
支持会话连续性。
防止主 Agent 上下文被 stdout、stderr、日志和网页快照淹没。

它不擅长单独解决：

判断哪些日志最重要。
在未知目标下发现根因。
跨大量片段做全局语义归纳。
替代便宜模型或 Sub-agent 的摘要能力。

因此，更合理的方向不是让主 Agent 反复搜索所有索引内容，而是把 Context Mode 作为数据层，在它之上叠加过滤器、专用解析器、便宜模型摘要或 Sub-agent 分析。

最终目标应该是：

大数据留在外部。
确定性规则先过滤。
便宜模型负责摘要。
主 Agent 只处理决策和修复。
需要证据时再回查原文。

一场外围的狂欢

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
如何引导模型自我验证代码的？

E2B & FireCracker by GPT5.4

Fri, 03 Apr 2026 00:17:48 +0800

E2B & FireCracker by GPT5.4

如果你第一次接触 Firecracker，很容易陷入一种混乱：

KVM 是不是虚拟机？
QEMU 和 KVM 到底是什么关系？
Firecracker 是不是“替代了” QEMU？
如果我要自己做一个 mini Firecracker，最小需要做什么？

我最近就是沿着这个问题一路往下挖，最后发现：
这几个东西其实不是同一层的概念。

它们的关系，如果一句话概括，就是：

KVM：内核里的硬件虚拟化执行后端
QEMU：用户态的通用 VMM / 设备模拟器
Firecracker：用户态的极简 VMM，建立在 KVM 之上

也就是说：

QEMU 和 Firecracker 都可以用 KVM。
它们真正的区别，不在“有没有 KVM”，而在于：谁来做 VMM，以及这个 VMM 做得多大、多复杂。

这篇文章我想把这件事彻底讲清楚。

一、问题的起点：为什么 Firecracker 会存在？

Firecracker 不是凭空出现的，它解决的是一个非常现实的问题：

在云计算场景里，比如 AWS Lambda、Fargate、Serverless 平台，一台物理机上往往要同时运行大量来自不同用户的代码。

这里有一个经典矛盾：

容器很轻，但隔离不够强

Docker、containerd 这条路线有明显优势：

启动快
资源开销小
编排成熟

但容器共享宿主内核。
这意味着：

容器的隔离边界，本质上不是硬件级别的。

只要内核、namespace、cgroup、runtime 某一层出了问题，就可能导致跨容器突破。

传统虚拟机隔离强，但太重

另一边是传统 VM：

有自己的内核
隔离边界更强
更接近“真正的一台独立机器”

但问题也很明显：

启动慢
内存开销大
设备模型复杂
历史兼容包袱重

如果你只是想跑一个很小的函数，或者一个短生命周期任务，传统 VM 往往过重。

Firecracker 的目标

Firecracker 的目标可以理解为：

用尽量小的开销，换取 VM 级别的隔离。

不是追求“模拟一台完整 PC”，而是追求：

少设备
少功能
少攻击面
快启动
小内存占用

所以它本质上是一个：

建立在 KVM 之上的极简 microVM VMM。

二、先把关系讲清楚：KVM、QEMU、Firecracker 各自是什么？

这是最容易混的地方。

1. KVM 是什么？

KVM，Kernel-based Virtual Machine，是 Linux 内核里的一套虚拟化能力。

它不是完整虚拟机，也不是设备模拟器。
它的核心职责很简单：

创建 VM
创建 vCPU
让 guest 指令直接在物理 CPU 上运行
当 guest 发生 VM Exit 时，把控制权还给用户态 VMM

所以可以把 KVM 理解成：

内核提供的“虚拟 CPU 执行引擎”。

它解决的是：

“guest 代码怎么高效运行在硬件上？”

2. QEMU 是什么？

QEMU 是用户态的 VMM / 模拟器。

它做的事情是：

加载 kernel / initrd / BIOS
布置 guest memory
模拟磁盘、网卡、串口、时钟等设备
处理 guest 的 I/O 行为
提供完整的启动流程

如果不配 KVM，QEMU 也能跑，但那是纯软件模拟，会很慢。
如果配 KVM：

qemu-system-x86_64 -accel kvm ...

那么就是：

QEMU 管机器
KVM 管 CPU 执行

所以：

QEMU 不是 KVM 的替代品，而是 KVM 上层最常见的 VMM。

3. Firecracker 是什么？

Firecracker 也是用户态 VMM，但和 QEMU 的理念完全不同。

QEMU 的目标是：

通用
兼容很多硬件
能模拟一大堆设备
覆盖各种历史负担

Firecracker 的目标是：

只做 microVM 需要的最小集合
设备尽量少
启动路径尽量短
安全面尽量小

所以 Firecracker 不是“没有 KVM 的另一个东西”，而是：

Firecracker = 更小的 VMM + KVM

三、最关键的一句话：它们的边界在哪里？

如果把一台虚拟机拆开看，可以粗暴分成两层：

下层：让 guest CPU 跑起来

这是 KVM 解决的。

上层：让它看起来像一台机器

这是 QEMU / Firecracker 解决的。

也就是说：

KVM 管“执行”
VMM 管“机器行为”

所以你可以记一句很有用的话：

KVM 管 CPU，VMM 管设备和启动流程。

四、Firecracker 每一层到底在解决什么问题？

如果从工程视角看，Firecracker 不是“一个大黑盒”，而是一层一层在解决问题。

1. Jailer：先把 VMM 自己关进笼子

问题是：

即使 guest 被 KVM 隔离了，Firecracker 进程自己仍然运行在 host 上。

如果 VMM 本身有 bug，被打穿，它依旧可能伤害宿主机。

所以 Firecracker 在启动前先用 Jailer 做一层外部隔离：

namespace
cgroup
chroot
降权
最小文件可见性

它解决的是：

“谁来限制 VMM 自己？”

2. KVM 初始化：让 guest 能真正跑起来

问题是：

你需要一种方式，让 guest 不靠软件模拟，而是尽量直接使用硬件。

KVM 提供的核心对象一般是三个 fd：

KVM fd
VM fd
vCPU fd

然后用户态 VMM 负责：

配 guest 内存
创建 vCPU
设寄存器
调 KVM_RUN

它解决的是：

“guest 指令到底怎么执行？”

3. 内存映射：guest 看到的物理内存从哪来？

Guest 以为自己有一块连续物理内存。
实际上，这通常只是 host 上的一段 mmap 区域。

KVM 帮你把：

guest physical address
映射到 host 内存

它解决的是：

“guest 看到的 RAM 是怎么伪造出来的？”

4. vCPU 线程：guest CPU 怎么持续运行？

每个 vCPU 一般对应一个 host 线程。
VMM 的典型主循环是：

调 KVM_RUN
guest 执行
遇到 VM Exit
VMM 处理退出原因
再次进入 guest

它解决的是：

“guest 怎么在 host 上持续执行，同时还能被暂停、恢复和管理？”

5. 设备模拟：guest 怎么做 I/O？

Guest 不可能直接摸宿主机硬件。
所以 VMM 需要提供设备。

Firecracker 采取的是最小设备集：

virtio-net
virtio-blk
serial
rng
vsock
balloon
等少量必需设备

这里关键点是：Firecracker 更喜欢 VirtIO，而不是模拟传统 PC 硬件。
因为 VirtIO 更简单、更快、攻击面更小。

它解决的是：

“guest 如何访问网络、磁盘、串口这些外设？”

6. API Server：外部怎么控制 microVM？

平台不可能手动敲命令控制 VM。
需要一个控制接口。

Firecracker 提供的是 Unix Socket 上的 API，分为：

preboot 配置
runtime 操作

比如：

设置 kernel
挂 drive
设置网卡
start
pause
snapshot
restore

它解决的是：

“平台控制面如何管理 VM 生命周期？”

7. MMDS：guest 如何拿到自己的 metadata？

在云环境里，guest 常常要知道：

自己是谁
配置是什么
应该拿什么 token / credential

Firecracker 提供 MMDS，模仿云平台元数据服务。

它解决的是：

“guest 如何拿到属于自己的配置元数据？”

8. Seccomp：最后一层防线

即使已经有：

Jailer
KVM

仍然还要防止 Firecracker 进程乱调用系统调用。

所以不同线程会被挂上不同的 seccomp 白名单。

它解决的是：

“如果 VMM 出问题，如何进一步限制伤害范围？”

9. Snapshot / Restore：解决冷启动

这是 Firecracker 在 Serverless 场景非常关键的一环。

不是每次都从：

启 kernel
启 OS
启 runtime
加载应用

而是先启动一次，再保存快照，后续直接恢复。

它解决的是：

“如何把冷启动延迟压到毫秒级别？”

10. Event Loop：怎么把 API、设备、定时器、vCPU 串起来？

VMM 要同时处理很多事件：

API 请求
设备 I/O
中断
定时器
guest 退出

Firecracker 用基于 epoll 的事件循环来组织这些事情。

它解决的是：

“如何高效协调整个 VMM 内部的事件流？”

五、如果我只是想做一个 mini 版 Firecracker，最小需要什么？

这个问题比“Firecracker 全量实现”更有意义。

因为大多数人第一次做 microVM runtime，不应该一上来就做：

jailer
seccomp
snapshot
mmds
virtio-blk
多 vCPU
热插拔

你会直接淹死在复杂度里。

一个真正“最小可运行”的目标应该是什么？

比如下面这个闭环就很好：

本地启动 N 个 microVM
每个 guest 能联网
每个 guest 启动后访问 host API
host API 收到请求后 count + 1

如果以这个目标倒推，最小需要：

Linux host + /dev/kvm
1 个 vCPU
guest memory
kernel
initramfs
串口
virtio-net
tap / bridge
host counter API
一个简单 launcher

最重要的简化：先不要磁盘

第一版最值得做的简化是：

不要 root disk，不要 virtio-blk，直接用 initramfs。

因为这样 guest 启动后直接执行 /init，你把最小用户态程序打进 initramfs 就行。

guest 的 /init 做三件事：

配网
调 http://host/incr
打日志然后关机

这样能少掉非常多复杂度。

六、为什么我一开始选择了 “QEMU + KVM” 而不是直接手搓 VMM？

因为如果你的目标是先跑通业务闭环，QEMU 非常适合作为过渡层。

比如你只想验证：

guest 能起来
guest 能通过 virtio-net 出网
guest 能请求 host API
host count 能变成 N

那一开始直接上自研 VMM，你会立刻被这些问题包围：

Linux boot protocol
guest memory 布局
vCPU 初始化
serial 模拟
virtio-net
TAP 转发
VM Exit 处理

这些全都是对的，但不该同时做。

所以我当时的工程判断是：

先用 QEMU 作为 VMM，把 control plane、network、guest workload 跑通。
然后再逐步把 QEMU 替换掉。

这条路线的好处是：

验证闭环先成立
排障基准先稳定
以后替换 backend 时，CLI 和业务验收标准不变

七、QEMU 和 KVM 的关系，最容易被误解的一点

很多人会说：

“我都用 QEMU 了，那还跟 KVM 有什么关系？”

答案是：关系非常大。

如果你运行的是：

qemu-system-x86_64 -accel kvm ...

那么你的 guest CPU 其实就是跑在 KVM 上的。
只是你没有自己写 /dev/kvm 的 ioctl，而是让 QEMU 帮你做了。

所以准确说：

QEMU without KVM：软件模拟，慢
QEMU + KVM：QEMU 管机器，KVM 管执行
Firecracker + KVM：Firecracker 管机器，KVM 管执行

换句话说：

Firecracker 和 QEMU 真正不同的，是 VMM 层，而不是 KVM 层。

八、如果要从 QEMU 逐步走向“自研 Firecracker 风格 VMM”，应该怎么走？

这是我现在觉得最靠谱的一条工程路线。

第一步：把外部体验先做稳

在你真正替换 backend 之前，先把这些做稳：

配置文件
启动命令
环境诊断
日志
运行时目录
错误提示

比如我们后来补了：

doctor
minivm.toml
交互式 init 向导
backend abstraction

这类改动表面看和 KVM 没关系，但其实非常关键。
因为它们决定了你以后调试新 backend 时，外部世界是不是稳定的。

第二步：把 backend seam 抽出来

如果 launcher 直接依赖 QEMU 命令行，那后面会很难换。

所以需要有一个明确的 backend 边界：

launcher 管 orchestration
backend 管 guest runtime

这样之后：

qemu backend 继续可用
kvm backend 可以逐步补

第三步：做 boot-only KVM backend

真正自研 VMM 的第一步，不应该是网络。
而应该是：

只让 guest kernel 跑起来，并且能输出串口。

因为一旦串口稳定，你就有了最基础的调试手段。

目标应该是：

创建 VM
分配内存
创建 1 个 vCPU
加载 kernel/initramfs
guest 串口打印
guest halt

第四步：再接 virtio-net

等 boot 和串口稳定后，再做网络。

这样你只是在已有可观测 boot path 上增加一个设备，而不是同时调试整个世界。

九、我对 Firecracker 最大的理解转变

以前我总以为：

“Firecracker 是一个特别厉害的虚拟机软件。”

后来我才意识到，这个理解太模糊了。

更准确的理解应该是：

Firecracker 不是在发明新的 CPU 虚拟化原理，它是在 KVM 之上做了一次非常克制、非常工程化的 VMM 裁剪。

它厉害的地方在于：

知道什么必须有
知道什么可以砍
知道什么必须延后
知道如何用多层隔离把风险压低
知道如何把启动路径缩短到适合云场景

所以如果你自己也想做一个 mini Firecracker，真正重要的不只是“会不会调 KVM ioctl”，而是：

你有没有能力把问题拆成一条最短闭环。

十、结语

如果把这篇文章压缩成一句话，那就是：

KVM 解决的是“guest 怎么高效运行”，QEMU 和 Firecracker 解决的是“guest 作为一台机器怎么存在”。

而 Firecracker 的核心价值，不在于“替代 KVM”，而在于：

在 KVM 之上，把 VMM 做到了极简、快速、可控、安全。

对我来说，真正的收获不是背下了这些名词，而是终于看清了这条演进路线：

先用 QEMU + KVM 跑通业务闭环
再抽出 backend 边界
再逐步替换成自研 KVM boot path
最后才是 virtio-net、快照、安全隔离这些更复杂的能力

VAST小记

Wed, 25 Feb 2026 14:06:24 +0800

VAST小记

2.25是在 VAST 的最后一天, 办公室也只回了一半的人

转眼一年半过去了

24年接到 Alice 的 Offer Call 的时候, 我正在沂河边上钓鱼, 风吹着我有些听不清她的话

鱼漂轻轻的抖动, 马上要中鱼了

嘟囔了几句之后, 我说OK

刀削面确实好吃, 但是也架不住要每天吃

我推荐你去吃汉堡王

山西帮被谋朝篡位数次, 最终变成了勾帮

我也变成了鱼勾

我热爱我的工作, 我也为它付出了我的心血

我没有什么后悔的, 为此感到骄傲

别人的烟确实更好抽, 星哥的烟更是好抽中的好抽

但是最后我还是还了他一条, 希望星哥身体健康

一起按过摩才是真兄弟, 勾帮的兄弟们没几个好东西, 更不用提淫柱了

哦, 还有一个干人事的

天下没有不散的筵席, 一顿饭到了结尾总是寡言少语的沉默

这不是一个容易的决定, 是的, 这不是一个容易的决定

我希望所有人都能开心, 希望你们一切都好

从dolt到Prolly-Tree

Sat, 21 Feb 2026 15:19:47 +0800

从dolt到Prolly-Tree

起因是看到了一个 repo: https://github.com/dolthub/dolt

非常有意思的一个特点是: 能够像使用git一样, 对数据库做版本管理/Diff

单就版本管理倒不是什么新鲜的事情, 一个让我很好奇的地方是: 是怎么做到快速的 Diff 呢?

Merkle Tree

https://yeasy.gitbook.io/blockchain_guide/05_crypto/merkle_trie

Prolly Tree (by Gemini)

Prolly Tree

Prolly Tree

Prolly Tree（Probabilistic B-Tree 的缩写）是一种混合数据结构，它完美结合了 B-Tree（适合数据库的高效有序读写与自平衡）和 Merkle Tree（基于内容寻址、支持快速校验）的特性。

想要理解它为什么能做到快速 Diff，需要对比来看：

为什么传统的 B-Tree 做不到快速 Diff？
B-Tree 的节点分裂和树的最终形态高度依赖于数据的插入顺序。即使两个数据库包含完全一模一样的数据，只要写入顺序不同，它们底层的 B-Tree 结构就会截然不同。如果两棵树形状不一样，Diff 时就只能做全量扫描，效率极低。
为什么单纯的 Merkle Tree 也不够？
传统的 Merkle Tree 虽然能通过哈希快速比对，但在应对数据库高频的随机插入和删除时，很难像 B-Tree 那样维持动态的自平衡和高效的区间查询。

Prolly Tree：

概率性分块 (Probabilistic Chunking) ：
Prolly Tree 放弃了 B-Tree 那种“节点写满就分裂”的固定规则，而是对写入的数据应用滚动哈希（Rolling Hash） 。当某条数据的哈希值满足特定概率条件（例如二进制末尾连续出现 N 个 0）时，就在这里强行划定一个节点边界（Chunk Boundary）。
历史无关性 / 结构确定性 (History Independence) ：
因为节点的边界完全是由数据内容本身计算出来的，与插入的时间和顺序毫无关系。这就带来了一个极为震撼的特性：只要两个数据库里的数据集合相同，无论它们是怎么一步步修改成现在的样子的，最终生成的 Prolly Tree 结构和所有节点的哈希值都完全一模一样。
O(差异量) 的极速 Diff：
由于具备了“历史无关性”，Diff 操作变得极其简单。比较两个版本的数据库时，只需要自顶向下比对树的哈希值：
1. 根节点哈希相同？说明数据完全一致，Diff 瞬间结束。
2. 根节点不同？继续比对子节点，只顺着哈希值不同的分支往下找。
3. 那些没有被修改的数据块，它们的哈希和物理结构在两个版本间是完全共享的（Structural Sharing），直接跳过。

这就使得数据库的 Diff 速度只与被修改的数据量成正比，哪怕在 TB 级别的数据量下，只要只改了几行数据，也能在毫秒级内完成比对！

可视化学习(by Claude Code)

Repo: https://github.com/Disdjj/prolly-tree-learn

在线查看: https://disdjj.github.io/prolly-tree-learn/

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 生态紧密结合，在不破坏现有功能的前提下，实现了声明式的团队协作能力。虽然仍处于早期阶段，但其设计思路值得关注和借鉴。

llmdoc viewer

Mon, 26 Jan 2026 23:39:44 +0800

在之前的一个帖子以及博客中, 已经比较系统的讲述了llmdoc的诞生以及设计思路

也收到了很多人的支持和鼓励, 让我觉得我的工作很有价值

今天再给大家介绍下, 一个适配的工具, 把llmdoc直接转为可读的文档系统

llmdoc viewer

repo地址: https://github.com/Disdjj/llmdoc-viewer

在线访问: https://llmdoc.tokenroll.ai/

示例: https://llmdoc.tokenroll.ai/Disdjj/llmdoc-viewer

目的

启动这个项目实在比较久之前了, 当时的目的是发现llmdoc虽然是给llm看的, 但是在llmdoc的设计之处, 是非常强调文档架构的合理性以及可读性

所以, 后面会发现, 如果把llmdoc拿出来作为文档系统也远超 90% 开源项目的文档建设

这也是一个比较惊喜的发现: 至少在2026年, 人能够非常好理解的结构, 对于AI来说是更好理解的

实现

完全没有服务端存储, 部署在cloud flare pages上
项目代码完全公开, 任何人都可以贡献
目前只能获取开源项目的llmdoc

使用方式

你可以自部署或者使用我已经部署的pages

访问主页

https://llmdoc.tokenroll.ai/

输入repo链接

例如:

Disdjj/llmdoc-viewer

https://github.com/Disdjj/llmdoc-viewer

然后就可以开始愉快的看文档了

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 执行结果仅通过文本返回主对话，无结构化状态同步

‍

llmdoc: 解决AI Coding的最后100米

Sat, 24 Jan 2026 02:44:29 +0800

llmdoc: 解决AI Coding的最后100米

在过去一年半的时间里, 我的工作流有了巨大的变化, 也亲眼见证了 AI Coding从兴起到现在的全面铺开, 个人工作模式已经被彻底颠覆了

当我们回顾 2025 年的变化, 从年初的 gemini 2.5 到 sonnet 4.5, gpt-5-codex, opus 4.5, gemini 3, gpt-5.2-codex.

我们应该认为: 模型的能力进步速度没有变得缓慢, 而且Cursor / Claude Code / OpenCode这类Coding Agent 的兴起, ToD 的应用也以令人难以预料的速度推进.

随之而来的有另一个问题: Context, 是的上下文构建, 而且我想要说的是在严肃的面向生产的环境中的 Context, 这不是 chatbot 中用personality 这种可以糊弄过去的, 代码更新留下了遗漏是真的会出现线上故障的.

让我们再看一下现在的这些Coding Agent 提供的能力吧:

AGENTS.md / CLAUDE.md: 注入到 User Message 满足 Context定制化的需求
SubAgent / Fork-Context: 通过增加并行度实现 Task 的更快解决
Skill / Command / Workflow: 虽然都在鼓吹 Skill 的渐进式披露, 但是我认为对于编程这种极度明确的场景太多的 Skill只会让你的模型编程笨蛋

但是, 还差了一些东西, Agent 实际上并不了解你的仓库, 我这里的了解指的是 Agent 实际上是通过Claude.md + 大量阅读代码文件才感知到了当前的环境.

这是正常的工作模式, 我们也习惯于这一点, 但是这不是一个好的路径, 如果使用 codex-cli 的人对此应该深有感触: 不断的不断的阅读代码文件, 甚至是完全不需要阅读的代码文件, 在 Context 足够解决问题的时候, 才开始解决问题.

Context Floor

我个人会把 “满足 Agent 解决需求的 context 的丰富度” 称之为: Context Floor

调用了多少工具
占用了多少 Token
关键信息的密度

现在让我们回过头来看, 一些经典的解决方案:

LSP MCP: 通过提升关键Symbol密度 + 大量的工具调用实现快速到达context floor
ACE / RAG: 通过少量的工具调用 + 稀疏的关键信息密度, 很难保证信息的关联性和有效性
Agentic RAG: 让 Agent 做一次信息的搜集, 提供一份概要, 一般使用 SubAgent, 在 claude code 中的explorer就是承担了类似的作用, 虽然 subagent 执行任务可以保证 master agent 上下文足够干净, token 占用量也不高, 关键信息密度也很高, 但是耗时太久了 TTCR (Time to Context Floor)实在是难以忍受

那么, 有没有一个解决方案足够快, 信息密度足够高, 主Agent的Token 占用足够少, 信息和任务存在强关联而且有效呢?

我的解决方案

https://github.com/TokenRollAI/cc-plugin

调试了一个月, 在公司内验证了3 个月之后,我觉得在现在时间节点的 SOTA 模型的加持下, 这套方案足够满足需求了

llmdoc + subagnet RAG

过去我有几个帖子说名字他的诞生的思考过程, 这里就不在详细的介绍

llmdoc

一个在设计之处就用来解决AI 快速获取高密度信息 + 人类可读性的文档系统

脱胎于 diataxis, 做了些微不足道的改动

利用 Agent 能够快速批量 Read的能力, 文档中保留最关键的文件路径+负责的模块说明
项目概览 + 架构 + 通过主题串联的 guides + refrence

以上作为基础, 在代码库中插入一个 llmdoc, 满足人类可读性 + Agent 可读性

示例: https://github.com/TokenRollAI/minicc/tree/main/llmdoc

subagent RAG

为了解决并行度的问题, 必须要引入 subagent, 但是 subagent 用来做什么呢?

主要是两件事情:

调研: 基于 llmdoc + 现有的代码文件, 调研拆解后的任务作为前置条件
记录: 在完成了编码任务之后, 自动的更新维护 llmdoc

问题

效果当然非常好, 或者说, 自从有了这一套解决方案之后我没有再使用过其他乱七八糟的 plugin

但是有一个问题: 贵

而且不是有点贵, 大概是用1.5倍的价钱完成了从 85 分 -> 90 分的效果, 在一些简单的项目中, 效果一般, 但是越复杂的项目收益越好.

效果

在我们公司的线上业务中, 后端代码仓库大概有 10W 行代码, 这套系统工作出色, 在几乎所有的情况下, 都能够准确的完成需求.

在建立了 llmdoc 的基础上, 根据需求的大小, 需求完成的成本大概在 1 - 5 刀, 而且最关键的是: 人类介入的次数大大降低, 只需要 Review 代码, 以及执行少量的修改后, 就能够放心交付.

现在也在我们的前端团队内开始推进, 效果依然出色.

我推荐大家使用 cc-plugin, 强烈推荐!

‍

2025 of DJJ

Sun, 11 Jan 2026 12:50:59 +0800

工作

工作要分为两部分, 上半年忙碌充实, 下半年迷茫懒惰

“迷茫懒惰” 是伴随我一生的诅咒, 一旦失去挑战, 失去兴趣, 我就会迷茫, 就会懒惰

对待爱情, 对待工作都是一样的, 这可能是我跳槽频率这么高的一种解释

我接受不了做平庸的无聊的事情

可是, 一个问题是: 如果每一次对自己的工作评价都是平庸无聊, 真的是这个工作本身的问题吗?

不完全是, 我觉得有几个主要的原因:

能力不足, 无法承担最核心最具有挑战性的事情, 在职业生涯的早期尤为明显, 野心太大, 但是能力不足以支撑, 而且缺少耐心
自我总结, 对于失败的总结不够彻底, 对于工作的总结不够, 自我反省缺失, 如果不知道自己为什么失败就永远不能成功
岗位职责, 在第一线会有很好的嗅觉, 但是如果一直在第一线实际上会导致自己对于行业更高级信息的缺失

Github

从2024年起, 一个很大的变化是, 我开始大量的阅读源码, 然后大量的写代码, 写自己想要做的项目, 来发泄自己的精力.

我觉得做的还不错, 至少在下班之后我终于可以充分的释放自己的精力了

https://github.com/Disdjj

AI

我悲观的认为两年之后, 传统的程序员就消失掉了

Anthropic的ToD策略非常的成功, 几乎所有的模型厂家都想要抓住这个市场

我认为一定会出现一个串联全部开发流程的产品, 有着极高的自定义程度以及可以连接产品从0-1的所有平台的"工具"

然后彻底干掉程序员, 干掉那些懒惰的不愿意改变的人

时代变了, 现在这个时代是: 不改变, 不追求改变, 那就会被迅速的淘汰掉. 而且我悲观的认为, 一旦被淘汰掉, 就会彻底被淘汰掉

产品的更迭速度会变的更快, 而且会越来越快

在这种情况下, 我认为现在全世界都缺少的两种人:

运营, 高效的和社区建立联系, 及时的收集用户反馈, 在社交媒体, KOL联系, 广告投放, SEO, GEO都了解的人, 不一定是人, 但是一定要能够用最高的效率把这些事情全部建立起来的人
Productive Dev, 能够敏锐发觉需求, 并且能够快速的构建demo, 以及最快速的验证, 我认为这可能比做出产品更加重要

我认为我后续最重要的几个工作:

对AI驱动的社区运营, 社媒运营, SEO以及GEO的了解和实践
更多的使用AI产品, 以及在现在的基础上获取更多的信息, 并且充分的使用这些信息和经验

我认为在LLM Coding的帮助下, 我已经完成了所有技术上的准备.

自大的说, 在过去一年的实践里, 我确认了自己的技术能力边界, 我可以实现我想做的任何事情, 可能很粗糙, 可能不够健壮. 但是足够了.

是时候去往下一个阶段了, 不管是不是准备好了, 必须要出发了

代洪全之死

Tue, 30 Dec 2025 15:41:20 +0800

代洪全之死

代洪全做了几十年的祗客(也说是纸客), 这是一个美化的说法. 其实就是在白事中主持仪式, 安抚亡人的角色.

再更早的时间里, 这不是一个光彩的角色, 最近十几年带着一些神秘的色彩, 反而愈发敬重他了.

但是毕竟做了几十年, 家家户户也都有些人情往来.

出殡的早晨, 行人情的人把十字路口堵满了, 他们也确实留下了几滴真切的眼泪.

我其实做过了心理建设, 一个88岁, 罹患癌症, 肺炎每年都要得两次的老年人. 料想也不会活的太久.

但是, 活着就比总比死了强

活着我回家还能逗逗你, 死了我就只能和坟头说话

他的生死观念是极为奔放的: 一把火昂了, 你们姊妹也不用为我难受, 这个年纪是好死

我也把这个混账话给我爸说了: “等你死了, 我也一把火昂了, 哭两天”

代洪全一生养育了五个女儿, 一个儿子

她们健康成长, 渡过了贫困的童年, 有一技之长, 现在都不会为生活而难过

代洪全死前所有的子女都在身边, 他最后在镇静剂的帮助下, 安详的走了

代洪全是我的爷爷, 他死在了2025年12月26日

他塑造了我性格和精神的底色, 我是他在新世纪的投射

痛苦是来自于爱, 我爱你, 我也痛苦着

我永远爱你, 我也会永远痛苦.

我草这个世界

Mon, 15 Dec 2025 03:04:51 +0800

我草这个世界, 我草我自己

我做了非常傻逼的事情, 把自己的apikey暴露到了github上, 然后被爽蹬50刀

暴露的文件

其实被蹬了50刀也不是什么大不了的事情, 确实是做了傻逼事情, 我也认了

但是这个畜生, 蹬了我50刀也没给我star

我草这个世界, 这个世界上还有好人吗

😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡😡

最近在做啥 (2025.11 - 2025.12)

Tue, 09 Dec 2025 09:35:52 +0800

#最近在做啥#

today-3d: 今日3D, 结合当下最强的AI技术: gemini3 , nano banana , tripo 3.0 制作每日最有趣的内容

神的孩子们: 沉浸式体验山上彻也的人生

minicc: 实现一个最简单版本的Cloud Code

agent-gear: 超高性能的agent basic tools

webhooker: 转发连接任意IM Webhook

curl-resume: 一个炫酷的终端动画项目 curl -N me.pdjjq.org

Claude Code CR: 基于 Claude Code 的自动化 PR 代码审查的Github action 模版

‍

agent-gear: LLM Tools 开发的瑞士军刀

Sun, 30 Nov 2025 01:32:15 +0800

agent-gear: LLM Tools 开发的瑞士军刀

#LLM# #Agent# #AI# #Rust# #Python#

Repo

agent-gear在线文档

背景

最近在开发minicc , 在为minicc提供tools时, 发现一件怪事. 整个项目的有效代码 2千行, tools的实现竟然占了快一半.

为什么? 有一半的代码是在处理 filesystem

今天在查看deepagents的源码, 实现的也相当丑陋. 大量的使用了 os / shutil / glob这些标准库. 总给人一种裸奔的感觉.

直觉上觉得: 现在需要一个成熟的包库, 用来给Agnet System提供基本能力. 而不是让每个Agent系统都要手动写一遍tools, 这简直是一种折磨.

Tools

LLM 或者说 Agent, 至少要有哪些工具?

TODO
AskUserQuestions
SubAgent
Net: WebSearch / WebFetch
FileSystem: Read / Write / Edit / Search(Grep) / Glob / List
…

先列到这里, 这里我觉得应该能够看出来, 对于一个Agent, 或者说对于一个典型的Coding Agent系统来说.

FileSystem是最基本而且最重要的操作, 那我们就从这里开始

架构

如果追求简单, 我们可以直接放在一个python中, 糊上500行代码, 然后直接push pypi就好了

但是既然做这件事情, 不如做的出色一点, 比如说把性能做的好一些.

怎么把性能做的好呢? 别烧脑了, 问问gemini吧

最后我的解决思路是:

Pyo3 + Maturin: Rust 写核心代码, python封装
内存文件树 + FS Notify: 把list/glob操作变成纯内存查找, 不经过OS
ripgrep + globset: 直接使用性能出色稳定的三方库
Batch: 提供batch操作, 少次多量的获取文件.

思路非常棒, 唯一的问题是: 我不会写Rust, 上一次写还是3年前, WTF?!

但是不要紧, 我们有伟大的Vibe Coding!

实现

在Plan模式下, 把完整的需求发给Claude Code, 生成一份计划书.
Review Plan: 不错
开始写: 撒泡尿, 回来review代码 (你又看不懂你Review你🐴呢)
到Context限制了, 保存下进度, 保留TODO, 已实现的内容. 记录到llmdoc
/clear, 继续写
Claude code写完了, 写单元测试, 开始改bug
bug改完, 写benchmark, 开始提升性能
性能不错, 找codex + gemini 开始review实现, 然后狂改
好, 提交到Pypi, 配置CICD
CI改了他妈的10轮, 终于跑通了, 我草这个世界.
完成

最后性能平均只是提升了 2 -3 倍左右, 感觉有点低于预期, 不是说用Rust之后就秒天秒地吗? 我觉得至少应该有个数量级的提升吧. ☺️

python标准库的实现性能相当可以, 而且考虑到LLM的特性, Filesystem的交互并不是性能瓶颈, 但是无所谓, 写都已经写完了

一共用了多久呢? 写代码只用了30分钟, 调试/Debug/Perf 用来1个小时, 修复傻逼的github CI 用了一个半小时!

总结

最底层的包库写完了, 接下来给minicc来个瘦身计划, 把tools的实现用agent-gear改一遍 , minicc的核心功能实现已经OK了, 接下里把边角料的 slash command / file import / TUI 美化这些功能实现, 一个教学用的claude code基本就差不多了
已经到了这样一个时代了: 你有点子, 那就意味着你实现了它, 想象力和视野可能是最重要的事情
优化最核心的性能, 而不是优化边缘的性能, 除了带来虚假的满足感之外, 没有解决任何问题.

BLOG迁移: 从Halo + CF Tunnel 到 Hugo + github + Cloudflare page

Tue, 25 Nov 2025 01:03:22 +0800

BLOG迁移: 从Halo + CF Tunnel 到 Hugo + github + Cloudflare page

背景

前一段时间, 我的blog数据丢了

其实算不上彻底丢了, 原始的blog内容还存储在思源笔记上, 甚至发布记录都有, 所以本质上的数据确实没有丢

过去blog是用docker部署在我的ubuntu小主机上, 用cf tunnel暴露服务到公网. 但是那天晚上, 我失心疯一样想要重装系统.

于是, 所有的磁盘数据都清掉了.

等我反应过来在这个主机上还有没迁移完的数据的时候, 新版本的ubuntu在冲我笑.

Halo + CF Tunnel

halo是一个好东西, 开箱即用, 功能丰富

但是太笨重了, 而且过去是部署在我的迷你主机 + cloudflare tunnel 暴露服务

好处是, 确实很方便

坏处是: 偶尔停一次电就无法访问了, cf tunnel 访问起来确实不够快.

在频繁的被提醒blog宕机之后, 我厌倦了重启halo + cf tunnel

Hugo + Github + CF Page

我要用一个最简单的方式实现blog的部署

这一套方案应该是最简单的方案了.

在思源里写笔记, 持久化存储, 然后通过部署插件推送commit到github, CF中配置github连接, master改动自动打包部署, 渲染使用hugo + 主题插件.

当然了, 也会有很多人好奇: 这是不是不够先进?

坦白说, 确实. hugo确实是个老东西了. 但是我觉得无所谓.

因为够简单, 没有什么大的bug, 打包结果全部是静态资源扔在cf上

主题是基于hugo-texify3 用gemini + claude code 魔改的

目前移植过来运行了大概2周, 运行很稳定, 我还比较满意.

gemini3.0 以及 antigravity

Wed, 19 Nov 2025 15:00:43 +0800

Antigravity

Coding流程的思路很好, 专门做了一个review模式, 在完成plan之后, 可以comment , 继续修改plan, 在完成walkthrouth之后, 同样也会review. 非常有价值.
browser use 做的非常出色, 能够直接和浏览器交互, debug / 调整UI更加方便, 非常有价值
交互做的非常粗糙, 各种意想不到的UI元素, 奇怪的不统一的配色
负载压力巨大, 莫名其妙的就限量了, 然后回退到使用sonnet 4.5, 想不到为什么要这么做
内置的rules的遵循能力差, 还不确定在提示词的组合方式, 但是现在肯定是有问题的

Gemini 3.0 Pro

审美很好, 小段代码能力很好
很懒, 如果不十分强调输出完整性的话, 非常容易漏东西, 怀疑其长文本输出的能力
聪明, 本质上是聪明的, 但是没有表现出如跑分一样断档的聪明

一些关于AI Coding的经验

Sun, 02 Nov 2025 21:56:06 +0800

在线查看: https://ai-coding-showcase.pdjjq.org/

Attention

“写代码"的门槛非常低, 收益非常的可观 Anthropic是怎么使用Claude Code
写代码 != 产出高质量软件
需求的实现成本/难度下降?
不要为LLM的发展焦虑, 但不要做 coding义和团^{（指本质正义, 工具落后, 顽固守旧的人）}

基座模型

至少到2025年年底, 我们应该认识到: 基础模型进步带来的收益时最大的

在任何生产力场景下, 应该总是选择SOTA模型

基本性能要求

一行代码约 10 Token Token 计算器

上下文: 128K+ (最好能够到200K) Token
- 成本
- 输出的速度/质量
输出速度: 60 Token/s
智力水平: SWE-Bench 70% (With Thinking) 60% (Low Think / No Think)
其他特性:
- ToolUse / Function Call
- Prompt Cache
- Reasoning

主流的模型

美国: Anthropic / OpenAI / Google Gemini / ~~Grok~~

中国: Qwen / GLM / Kimi / MiniMax / DeepSeek

Anthropic (地域黑/权限狗)

对中国用户不友好 , 挂VPN也能封号, 策略最严格之 «封号斗罗»

目前最强的Agent Model:

***旗舰 Opus*** : 主要使用的Coding模型
次旗舰 Sonnet: 在很长的一段时间内, sonnet都是一个全能的模型
狗屎 Haiku

OpenAI (CloseAI)

gpt-5.2-codex : 修改准确, 调查充分, 但是耗时过长, 非常适合修复BUG

Gemini (Google大善人)

Gemini 3.0 pro: 史上最佳的对话模型

Gemin 3.0 Flash: 我们到现在都不知道Google是怎么做到的

Qwen (真正的OpenAI)

qwen3 Max : 中国特色gemini

qwen3 coder plus : 狗都不用, 但是必要的时候可以当狗

GLM Kimi MiniMax (整挺好)

glm4.6 : 能力很好, Coding Plan也很好, 但是最近在降智

Minimax-M2

Kimi K2

DeepSeek (我卡呢?)

大家举起双手把力量借给DeepSeek 👐👐👐

DeepSeek-V3.2

主流的AI Coding工具

我们可以按照交互的形式主要分为三类

VsCode-Fork: GUI Local, Fork VsCode 的发行版 , 使用 OpenVSX 作为插件来源 , 集成AI能力增强代码编写体验
CLI: 在命令行中与Agent进行交互, 对运行环境有最好的支持, 一般能够轻易的在CICD 中集成, 配合前后端分离的架构可以配合VSCode插件使用
Web/Remote Agent: 提供最开箱即用的能力, 开发环境完全托管远程, 控制能力较弱, 价格较贵

VsCode-Fork

赞美VsCode, 你是IDE的终点, 你是AIDE的起点. GUI > CLI !!!

V门

大部分耳熟能详的AI IDE都是基于VsCode来做, 包括但不限于:

***Cursor*** : 最流行的AI Coding工具, 开箱即用, 最好的complete功能, 定价变化大
***Antigravity*** : Google出品, 目前提供的额度比较高, 原生连接Chrome, Agent pannel
Windsurf: 无功无过
Trae: 字节出品, 做的不错, 重新设计过UI, 有SOLO模式, 创新不大
Qoder: 阿里出品
CodeBuddy: 腾讯出品
开源: Void(不再维护了)
开源Coding插件: Cline / Roo Code / Kilo Code / continue.dev

最大的优势是: 用户习惯迁移非常方便

缺点是: 同质化非常严重

Auto Complete

快速自动补全是所有的AI IDE的最基本功能之一, 由此演变来的功能一般还有:

当然了, 有开源的项目提供了类似的能力, 一般支持FIM的小模型都能够顾胜任此工作

Commit Message

根据代码变更自动生成Commit Message

Coding Agent

这部分的实现和交互和CLI Agent比较类似, 会在下一个大节详细描述

CLI

CLI交互天生就有一种严肃性, 同时CLI也有最广泛的适用性

Cluade Code : 目前最强大特性最丰富普适性最强的的Coding工具
Codex CLI : 功能非常简陋, 纯靠模型能力硬顶
***OpenCode*** : 拥有目前最出色的Plugin设计, 我会逐渐的迁移到OpenCode
***iflow*** : 国产CC
gemini cli : 做的也很简陋, 但是更新迭代速度比较快
auggie / cursor cli: 狗屎

Web/Remote Agnt

非专业开发人员的福音:

几乎没有环境依赖

一般配有在线预览 + 快速部署的功能

非常适合做DEMO验证

个人使用经验

提升AI Coding质量的最有效方法:

提供高质量高相关度的上下文, 至少是包含相关的上下文

合理的划分任务, 每次专注于一个任务

CLAUDE.md / AGENTS.md

CLAUDE.md 和 AGENTS.md本质上都是注入到Context里的提示词, 在claude code的实现中, 会将 User / Project 的CLAUDE.md 都插入到Context中.

实现原理

<system-reminder>
As you answer the user's questions, you can use the following context:
# claudeMd
Codebase and user instructions are shown below. Be sure to adhere to these instructions. IMPORTANT: These instructions OVERRIDE any default behavior and you MUST follow them exactly as written.

...

</system-reminder>

如何使用?

使用 /init初始化Claude.md
使用 # content添加到Claude.md

记录什么东西

DO NOT xxx, because xxx
Always use xxx to do xxx

{项目概况: 名称/技术栈/架构}

## 核心技术栈

## 项目架构

## 开发命令

## 关键配置

## 开发注意事项

Chat more before coding

这是最简单的最推荐的提升AI Coding质量的方法, 多聊几轮

如果有Plan模式, 那么先使用Plan模式, 直到AI能够彻底理解你的需求, 并且给出了合理的方案

或者说并不是 “Chat More” 而是 “先调查, 再规划, 再写代码”

SOP Coding

重复自己是最无聊的事情

如果在堆积业务代码, 非常推荐整理出一个SOP, 后续再开发的时候让AI Follow 这个SOP进行编程.

有两种办法:

在commit之前, 让AI总结操作步骤, 并且写入到项目的文档目录中, 做持久化管理
使用recorder 自动记录你的操作行为成日志, 生成操作文档

Option Coding

在Claude Code的 2.0.21的更新中, 引入了一个新的功能: interactive question tool

简单来说: AI可以主动向你发文, 你可以做选项回复.

对于懒得打字的朋友们来说, 简直是福音.

做选择题, 总是要比做填空题爽是不是?

一般来说在plan模式下, 会更加主动的调用AskUserQuestion这个工具, 来让用户进行选择.

所以, Enjoy yourself

llmdoc

文档系统在AI Coding中只会越来越重要.

LLM没有长期记忆, 全部依赖于Context, 文档系统本质上就是外挂了一个持久化数据层.

帮助AI快速获取充分的信息.

我这里以我们后端系统的文档建设举例.

当然了, 全部都是AI生成的, by cc-plugin

MCP

寻找MCP

现在几乎所有主流的AI SaaS服务都有提供MCP, 如果你感兴趣可以在这里主流的平台中寻找MCP:

常用MCP

chrome-devtools-mcp: Browser use, 谷歌出品, 调用浏览器, 获取Console/网络请求日志
***figma*** : 尽管我几乎不使用figma, 但是由于figma巨大的影响力, 还是加上, 防止有些人竟然不知道
K8S: 注意要使用 readonly模式%20(default%20%22table%22)-,%2D%2Dread%2Donly,-If%20set%2C%20the)
github: 和Github交互 (虽然我认为使用 gh cli + Bash Tool 是更好的解决方案)
context7: 虽然我认为用处不大, 但是推荐尝试
ref: 提供准确的文档, Better than context7 贵的东西的缺点只有贵 :(

不要使用的MCP

serena: 太多的重复功能, 不稳定的LSP, 你不会需要这个的.
所有超过10个tools的MCP, 只会让你的Coding Agent变成笨蛋

不要使用MCP

使用Tools是有代价的, Tools并不是LLM天生就会的事情.

从ReAct开始, 工具调用能力被认为是提升Agent解决问题的能力重要组成部分, 在2025年, 号称是 “?Agent元年”, 几乎所有的模型都在强调工具调用能力, 就像是人使用手一样

MCP带来的最重要的进步: 一个更容易接入,实现更自由的, 平台框架解耦的Function Call / Tools

但是MCP是有代价的, 而且是昂贵的代价, 每一个MCP Tools都占用一个昂贵的Tool的位置, Claude Code为了能够强化其ToolUse的能力, 在System提示词中做了巨大的强调 (530 Token, 约25%)

# Tool usage policy
- When doing file search, prefer to use the Task tool in order to reduce context usage.
- You should proactively use the Task tool with specialized agents when the task at hand matches the agent's description.
- A custom slash command is a user-defined operation that starts with /, like /commit. When executed, the slash command gets expanded to a full prompt. Use the Skill tool to execute them. IMPORTANT: Only use Skill for commands listed in its Available Commands section - do not guess or use built-in CLI commands.
- When WebFetch returns a message about a redirect to a different host, you should immediately make a new WebFetch request with the redirect URL provided in the response.
- You can call multiple tools in a single response. If you intend to call multiple tools and there are no dependencies between them, make all independent tool calls in parallel. Maximize use of parallel tool calls where possible to increase efficiency. However, if some tool calls depend on previous calls to inform dependent values, do NOT call these tools in parallel and instead call them sequentially. For instance, if one operation must complete before another starts, run these operations sequentially instead. Never use placeholders or guess missing parameters in tool calls.
- If the user specifies that they want you to run tools \"in parallel\", you MUST send a single message with multiple tool use content blocks. For example, if you need to launch multiple agents in parallel, send a single message with multiple Task tool calls.
- Use specialized tools instead of bash commands when possible, as this provides a better user experience. For file operations, use dedicated tools: Read for reading files instead of cat/head/tail, Edit for editing instead of sed/awk, and Write for creating files instead of cat with heredoc or echo redirection. Reserve bash tools exclusively for actual system commands and terminal operations that require shell execution. NEVER use bash echo or other command-line tools to communicate thoughts, explanations, or instructions to the user. Output all communication directly in your response text instead.
- VERY IMPORTANT: When exploring the codebase to gather context or to answer a question that is not a needle query for a specific file/class/function, it is CRITICAL that you use the Task tool with subagent_type=Explore instead of running search commands directly.
<example>
user: Where are errors from the client handled?
assistant: [Uses the Task tool with subagent_type=Explore to find the files that handle client errors instead of using Glob or Grep directly]
</example>
<example>
user: What is the codebase structure?
assistant: [Uses the Task tool with subagent_type=Explore]
</example>

又是policy, 又是few shot, 然后一个 mcp add 引入了20个额外的tools + 巨大的无聊的Description , 完全没有经过设计的Response, context 已经完全不够用了!!!!

我建议你只使用0-2个MCP, 在不需要的时候及时关掉

唯一推荐的使用方式是, 在支持多Agent的工具中, 为每个Agent开启一个MCP, 例如Claude Code Subagent.

下图为我在CherryStudio中使用MCP, 尽量让一个Agent做一件事情, 专注于使用一类工具.

MCP是灾难, 调休也是.

我还使用哪些AI工具

***Cherry Studio*** : 桌面AI工具, 好用, 强烈推荐
***Gemini*** : 我是Gemini的付费Pro会员, 强烈推荐
***AIHubMix*** : AI代理提供商, 提供几乎所有的主流模型, 强烈推荐
***notebooklm*** : Google出品, 我一般用来做知识库使用, 强烈推荐
Dify: 懒得写代码的时候我会直接用Dify接一些简单的功能, 比如说简单的Chat之类的工作. 比如说这里的面试官小工具
zread / deepwiki: LLM帮你分析开源repo

上下文工程

这里要讲的东西有点太多了, 根本说不完.

这里给出我认为非常适合学习的材料, 感兴趣的可以自行阅读

结构化提示词 : 一个入门教程

AI代理的上下文工程：构建Manus的经验教训 : Agent必吃榜第一

Manus AI Agent 分享PPT : Agent必吃榜第二

Context Rot: More Input, More Stupid

评估LLM的上下文能力: 1M上下文是童话故事

一些暴论

Get Hands Dirty , 动手做比什么都重要
想象力 > 行动力 > 编程能力^{（一切都建立在有软件工程的基本素质）}
领域的融合, 狭窄深邃不再是无法克服的问题

Agent之殇

Tue, 14 Oct 2025 23:21:31 +0800

Agent之殇

速度, 效果, 成本这三者不可能同时达成.

速度

增加任务并发度
使用更小的模型

效果

使用超量的上下文
使用紧凑高密度的上下文
使用超量的SubAgent
使用更好的模型

成本

少的上下文
少的模型调用次数
廉价的模型

Cheap Context and Expensive Context

Tue, 14 Oct 2025 22:37:45 +0800

Cheap Context and Expensive Context

Repo

Cheap Context

SubAgent的Context是廉价的而且是一次性的

或者可以称之为 intern context 像实习生一样非常的廉价, 执行一次性任务, 而且受限于传入上下文的限制, 显得有些笨

在这种执行环境受限的情况下, 应该用: 明确的任务划分+明确的输出 + 廉价的上下文(廉价模型)

Expensive Context

主Agent的Context是昂贵的:

一旦压缩一定会出现执行漂移.
高性能大模型昂贵的价格

主Agent

负责调度的Agent
负责任务解决的Agent
负责核心输出的Agent

体验一下

在claude中

# 添加 TokenRoll 插件市场
/plugin marketplace add https://github.com/TokenRollAI/cc-plugin

# 下载tr插件
/plugin install tr@cc-plugin


# 强调使用bg-worker
# Always consider use bg-worker to solve simple task

Solution

在cc-plugin的bg-worker中, 解决方案十分粗暴, 毫无技术含量.

SubAgent + 明确的任务划分+明确的输出 + 廉价的上下文来换取主Agent上下文的紧凑 + 总成本的降低

效果

使用的Repo: https://github.com/zeromicro/go-zero
需求: 告诉我这个项目的结构如何?

省流

Context 和 Cost 节省效果明显

normal:    27.4k    $0.1304
bg-worker: 16.2k    $0.0867

发展方向

并发的使用廉价模型SubAgent 为主Agent提供紧凑高密度上下文
主Agent的作用: 任务划分/总结/判断 + 核心内容输出

实验对比

1. 不使用bg-worker


 ▐▛███▜▌   Claude Code v2.0.14
▝▜█████▛▘  Sonnet 4.5 · API Usage Billing
  ▘▘ ▝▝    /home/djj/code/go-zero

> 告诉我这个项目的结构如何? do not use bg-worker / scout agent

● 我来帮你分析这个项目的结构。让我先查看项目的根目录结构。

● Bash(ls -la /home/djj/code/go-zero)
  ⎿  total 156
     drwxr-xr-x 12 djj djj  4096 Oct 13 22:19 .
     drwxr-xr-x 17 djj djj  4096 Oct 13 21:17 ..
     … +22 lines (ctrl+o to expand)

● Bash(find /home/djj/code/go-zero -maxdepth 1 -type d | head -20)
  ⎿  /home/djj/code/go-zero
     /home/djj/code/go-zero/gateway
     /home/djj/code/go-zero/internal
     … +8 lines (ctrl+o to expand)

● Read(README.md)
  ⎿  Error reading file

● Read(readme.md)
  ⎿  Read 253 lines

● Bash(ls -la /home/djj/code/go-zero/core)
  ⎿  total 192
     drwxr-xr-x 48 djj djj 4096 Oct 13 21:17 .
     drwxr-xr-x 12 djj djj 4096 Oct 13 22:19 ..
     … +46 lines (ctrl+o to expand)

● Bash(ls -la /home/djj/code/go-zero/rest)
  ⎿  total 124
     drwxr-xr-x 12 djj djj  4096 Oct 14 02:11 .
     drwxr-xr-x 12 djj djj  4096 Oct 13 22:19 ..
     … +18 lines (ctrl+o to expand)

● Bash(ls -la /home/djj/code/go-zero/zrpc)
  ⎿  total 60
     drwxr-xr-x  4 djj djj 4096 Oct 13 21:17 .
     drwxr-xr-x 12 djj djj 4096 Oct 13 22:19 ..
     … +10 lines (ctrl+o to expand)

● Bash(ls -la /home/djj/code/go-zero/tools)
  ⎿  total 12
     drwxr-xr-x  3 djj djj 4096 Oct 13 21:17 .
     drwxr-xr-x 12 djj djj 4096 Oct 13 22:19 ..
     drwxr-xr-x 25 djj djj 4096 Oct 13 21:17 goctl

● Bash(ls -la /home/djj/code/go-zero/gateway)
  ⎿  total 44
     drwxr-xr-x  3 djj djj 4096 Oct 13 21:17 .
     drwxr-xr-x 12 djj djj 4096 Oct 13 22:19 ..
     … +5 lines (ctrl+o to expand)

● Read(go.mod)
  ⎿  Read 125 lines

● 根据我的分析,这是 go-zero 项目的结构概述:

  项目简介

  go-zero 是一个集成了各种工程实践的 Go 语言 web 和 rpc 框架,被 CNCF 云原生生态收录。它专注于高并发服务的稳定性,具有弹性设计理念。

  核心目录结构

  1. core/ - 核心功能库(48个子模块)

  这是框架的核心,包含各种基础工具和组件:
  - conf - 配置管理
  - breaker - 熔断器
  - limit - 限流器
  - load - 负载均衡/自适应降载
  - bloom - 布隆过滤器
  - collection - 集合工具
  - stores - 数据存储(redis/sql/mongo等)
  - logx - 日志系统
  - trace - 链路追踪
  - metric/prometheus - 监控指标
  - mr - MapReduce并发工具
  - threading/syncx - 并发控制
  - service - 服务基础组件
  - discov - 服务发现
  - 其他 - hash、queue、codec、fx、executors等工具

  2. rest/ - REST API框架

  HTTP服务相关功能:
  - engine.go/server.go - HTTP服务引擎
  - router/ - 路由管理
  - handler/ - 请求处理器
  - httpx/ - HTTP工具
  - httpc/ - HTTP客户端
  - middleware/ - 中间件
  - chain/ - 中间件链
  - pathvar/ - 路径参数
  - token/ - Token处理

  3. zrpc/ - RPC框架

  gRPC服务相关功能:
  - client.go/server.go - RPC客户端和服务端
  - config.go - RPC配置
  - resolver/ - 服务解析
  - internal/ - 内部实现

  4. tools/goctl/ - 代码生成工具

  命令行工具,用于从 .api 文件生成代码:
  - 支持生成 Go、Java、TypeScript、Dart、JavaScript 等多种语言代码
  - 自动生成项目骨架
  - API 语法定义和解析

  5. gateway/ - API 网关

  HTTP API 网关功能:
  - server.go - 网关服务器
  - config.go - 网关配置
  - internal/ - 内部实现

  6. internal/ - 内部实现

  框架的私有实现细节

  7. mcp/ - MCP相关功能

  技术栈特点

  - Go 1.21+
  - 支持 etcd 服务发现
  - 集成 Prometheus 监控
  - OpenTelemetry 链路追踪(Jaeger/Zipkin)
  - 支持 Redis、MySQL、PostgreSQL、MongoDB
  - Kubernetes 集成

  核心特性

  1. 高可用性 - 熔断器、限流、负载均衡、自适应降载
  2. 微服务治理 - 服务发现、链路追踪、监控指标
  3. 并发控制 - 内置并发控制、超时控制
  4. 代码生成 - 通过 goctl 工具自动生成代码
  5. 容错设计 - 面向失败的编程理念

  这是一个典型的微服务框架项目结构,分层清晰:底层核心库(core) + HTTP框架(rest) + RPC框架(zrpc) + 代码生成工具(goctl) + API网关(gateway)。

> /cost
  ⎿  Total cost:            $0.1304
     Total duration (API):  1m 5s
     Total duration (wall): 14m 59s
     Total code changes:    0 lines added, 0 lines removed
     Usage by model:
         claude-3-5-haiku:  5.9k input, 251 output, 0 cache read, 0 cache write ($0.0058)
            claude-sonnet:  3.2k input, 1.8k output, 60.9k cache read, 18.6k cache write ($0.1246)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
> 
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   Model: Sonnet 4.5  Ctx: 27.4k  Ctx: 13.7%  ⎇ master  (+146,-12)  Cost: $0.13

2. 使用bg-worker


 ▐▛███▜▌   Claude Code v2.0.14
▝▜█████▛▘  Sonnet 4.5 · API Usage Billing
  ▘▘ ▝▝    /home/djj/code/go-zero

> use bg-worker to 告诉我这个项目的结构如何?

● 我会使用 bg-worker agent 来分析这个项目的结构。

● tr:bg-worker(分析 go-zero 项目结构)
  ⎿  Done (5 tool uses · 18.8k tokens · 40.8s)

● 根据分析，这是 go-zero 项目的结构概览：

  📁 主要目录结构

  核心组件

  1. core/ - 框架核心功能库
    - 包含 timex, conf, iox, naming, netx, mathx, collection 等工具包
    - 提供并发控制、配置处理、网络工具等基础设施
  2. rest/ - RESTful API 服务
    - 中间件(middleware)、路由(router)、处理器(handler)
    - 支持完整的 HTTP 服务功能
  3. zrpc/ - RPC 服务组件
    - 基于 gRPC 的 RPC 服务实现
    - 包含解析器和内部实现
  4. tools/goctl/ - 代码生成工具
    - 快速生成微服务代码的 CLI 工具
    - 支持多语言客户端代码生成
  5. gateway/ - API 网关服务
  6. internal/ - 内部工具组件
    - 编码、mock、性能分析等功能

  🛠️ 技术栈

  - 语言: Go 1.21+
  - 服务发现: etcd
  - 监控追踪: Prometheus, OpenTelemetry
  - 数据存储: MySQL, Redis, MongoDB
  - 认证: JWT
  - 容器编排: Kubernetes

  🏗️ 架构特点

  - ✅ 微服务架构设计
  - ✅ 高性能、高并发
  - ✅ 内置熔断、限流等弹性设计
  - ✅ 自动代码生成 (goctl)
  - ✅ 丰富的中间件支持
  - ✅ 分布式链路追踪
  - ✅ 自动参数验证

  总结: go-zero 是一个生产级的 Go 微服务框架，专注于工程实践和开箱即用的企业级特性。

> /cost
  ⎿  Total cost:            $0.0867
     Total duration (API):  1m 18s
     Total duration (wall): 11m 47s
     Total code changes:    0 lines added, 0 lines removed
     Usage by model:
         claude-3-5-haiku:  10.0k input, 1.2k output, 50.3k cache read, 10.5k cache write ($0.0272)
            claude-sonnet:  8 input, 920 output, 20.9k cache read, 10.5k cache write ($0.0595)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
> 
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   Model: Sonnet 4.5  Ctx: 16.2k  Ctx: 8.1%  ⎇ master  (+146,-12)  Cost: $0.09 
  ⏵⏵ accept edits on (shift+tab to cycle)

使用multi bg-worker

> use multi bg-worker to 告诉我这个项目的结构如何?

● 我将使用多个 bg-worker 代理并行分析这个项目的结构。

● tr:bg-worker(分析项目根目录结构)
  ⎿  Done (3 tool uses · 16.1k tokens · 16.1s)

● tr:bg-worker(分析主要代码目录)
  ⎿  Done (5 tool uses · 9.2k tokens · 34.4s)

● tr:bg-worker(分析核心包结构)
  ⎿  Done (4 tool uses · 10.7k tokens · 25.2s)

● tr:bg-worker(分析工具和命令)
  ⎿  Done (6 tool uses · 10.0k tokens · 27.5s)

● tr:bg-worker(分析测试和文档)
  ⎿  Done (3 tool uses · 8.7k tokens · 14.4s)

● 根据多个 bg-worker 代理的并行分析，这个项目的结构如下：

  📋 项目概述

  项目名称: go-zero模块: github.com/zeromicro/go-zero类型: Go 语言微服务框架Go 版本: 1.21+

  🏗️ 目录结构

  1. core/ - 核心基础库（最重要的部分）

  包含 30+ 个子模块，提供微服务开发的基础设施：

  系统工具类:
  - utils, lang, stringx, mathx, timex, codec, hash

  并发与系统:
  - threading, syncx, proc, executors, contextx

  网络与服务:
  - netx, naming, service, discov, configcenter

  存储与数据:
  - stores, collection, queue

  日志与监控:
  - logx, logc, metric, prometheus, trace

  稳定性保障:
  - limit(限流), breaker(熔断), rescue(异常恢复)

  其他工具:
  - bloom, jsonx, mapping, validation 等

  2. tools/goctl/ - 代码生成工具

  强大的命令行工具，支持：
  - API 代码生成（Go, Java, Dart, TypeScript 等）
  - RPC 服务生成
  - 数据模型生成（SQL, MongoDB）
  - Docker/Kubernetes 配置生成
  - 项目迁移和环境管理

  3. internal/ - 内部实现

  包含 encoding, mock, profiling, trace, health 等内部模块

  4. gateway/ - 网关相关功能

  5. rest/ - REST API 框架

  （从 git status 看到有 rest/middleware/ 未提交文件）

  📊 项目规模

  - 测试文件: 373 个 *_test.go 文件
  - 文档文件: 25 个 Markdown 文件
  - 核心代码: 约 467 个 Go 文件（仅 core 目录）

  🎯 核心特性

  1. 微服务架构: 完整的微服务解决方案
  2. 服务治理: 服务发现、负载均衡、熔断、限流
  3. 可观测性: 集成 OpenTelemetry、Prometheus 监控
  4. 多存储支持: Redis、MySQL、MongoDB
  5. 代码生成: 通过 goctl 快速生成项目脚手架
  6. 高性能: 适合高并发场景

  📝 架构特点

  - 模块化设计: 每个目录职责明确
  - 库项目: 主要作为框架库使用，而非独立应用
  - 完善的测试: 大量单元测试覆盖
  - 文档分布式: 各模块都有独立的 README

  这是一个成熟的、生产级别的 Go 微服务框架，提供了从基础工具到服务治理的完整解决方案。

> /cost
  ⎿  Total cost:            $0.1845
     Total duration (API):  3m 8s
     Total duration (wall): 3m 27s
     Total code changes:    0 lines added, 0 lines removed
     Usage by model:
         claude-3-5-haiku:  20.6k input, 4.9k output, 171.0k cache read, 52.5k cache write ($0.1024)
            claude-sonnet:  8 input, 1.9k output, 20.9k cache read, 12.7k cache write ($0.0820)

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
> 
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   Model: Sonnet 4.5  Ctx: 18.4k  Ctx: 9.2%  ⎇ master  (+146,-12)  Cost: $0.18 
  ⏵⏵ accept edits on (shift+tab to cycle)

缺陷

真的有如同看起来这么美妙吗?

NO! NO! NO!

至少目前看有这么几个问题:

如果使用并发模式来调用bg-worker的话, 如果认为划分的过于简单, 会出现主Agent的输出 + 读取成本高于bg-worker的运行节省的成本, 尽管还是可以节省主Agent的Token, 但是不再具备成本优势
bg-worker执行的任务越复杂,越具备成本优势,执行效果越差.

DJJ

AI 工作流 V4

AI 工作流 V4

Coding

Claude Code

Codex Cli

并行工作

superset.sh

conductor

Agent Tool

llmdoc

superpowers

happy code

trellis

pencil.dev

mcporter

自主 Agent

Agent 编排

ruflo

context-mode 的分析与批评 by GPT5.5

context-mode 的分析与批评 by GPT5.5

Context Mode 实现方式与生产化评估

摘要

当前方案的基本思路

降低上下文占用的几个机制

1. 让模型写代码分析，而不是直接阅读大输出

2. 文件内容在外部加载，只返回处理结果

3. 大输出转成可检索资料，而不是直接返回全文

4. 批量执行和批量检索

5. 会话恢复和历史信息检索

真实价值在哪里

主要问题和边界

1. 指针不等于压缩

2. 搜索不能替代理解

3. 反复检索可能抵消收益

4. 切块会损失全局结构

5. 系统复杂度较高

更适合生产环境的改进方向

1. 先过滤，再搜索

2. 建立专用解析器

3. 在检索层之上加入便宜模型或 Sub-agent

4. 让搜索退居为证据回查机制

5. 调整评估指标

推荐的混合架构

结论

一场外围的狂欢

一场外围的狂欢

Agent & Agent Software

Tool

Task

Context

Fuck Claude Code

Fuck Harness

Fuck DJJ by Gemini

能学到什么?

E2B & FireCracker by GPT5.4

E2B & FireCracker by GPT5.4

一、问题的起点：为什么 Firecracker 会存在？

容器很轻，但隔离不够强

传统虚拟机隔离强，但太重

Firecracker 的目标

二、先把关系讲清楚：KVM、QEMU、Firecracker 各自是什么？

1. KVM 是什么？

2. QEMU 是什么？

3. Firecracker 是什么？

三、最关键的一句话：它们的边界在哪里？

下层：让 guest CPU 跑起来

上层：让它看起来像一台机器

四、Firecracker 每一层到底在解决什么问题？

1. Jailer：先把 VMM 自己关进笼子

2. KVM 初始化：让 guest 能真正跑起来

3. 内存映射：guest 看到的物理内存从哪来？

4. vCPU 线程：guest CPU 怎么持续运行？

5. 设备模拟：guest 怎么做 I/O？

6. API Server：外部怎么控制 microVM？

7. MMDS：guest 如何拿到自己的 metadata？

8. Seccomp：最后一层防线

9. Snapshot / Restore：解决冷启动

10. Event Loop：怎么把 API、设备、定时器、vCPU 串起来？

五、如果我只是想做一个 mini 版 Firecracker，最小需要什么？