最新资讯
reddit.com OpenAI 称 Astra 仅满足 10% 安全任务标准 dev.to FreeToken:在自有 GPU 上运行前沿 MoE 模型及其内存需求 dev.to 当 AI Agent 说“完成”时,究竟完成了什么? dev.to 部署 Underdog Bark 3.0 Pro:逐字转写、自定义后端与分块设置 dev.to 为艰难对话构建 AI:五个 Agent、一条安全正则与一位盲评监督者 techcrunch.com Palo Alto Networks 洽谈以 5 亿美元收购 AI Agent 安全初创公司 Clutch theinformation.com 黄仁勋被要求就涉华间谍指控向国会作简报 www.infoq.com Edera 推出 Object Capability Bounded Authority,试图将凭证与 AI Agent 工作负载隔离 wechat 这波杀疯了!旗舰级模型不限量、1个月视频额度免费领 bloomberg.com AI 抛售蔓延至信用市场,软银领跌亚洲美元债 dev.to 如何在专用 GPU 服务器上用 OpenAI 兼容 API 部署 LLM dev.to 审计 153 份 Claude Code 与 Codex 会话记录:User-Agent 与 URL 中的邮箱泄露
多元动态
登录 注册
AI编码 dev.to · @Lisandro Reinoso

一个技能的解构:Claude Code 内置 deep-research 技能剖析

原文 我的收藏

作者运行 Claude Code 自带的 deep-research 技能,一次运行即产出包含 27 个来源、123 条声明(25 条验证、18 条确认、7 条被驳斥)的报告。作者随后拆解该技能,发现它不在常规技能目录中,而是以 349 行 JavaScript 编译进 Claude Code 二进制,代码注释显示其源自 bughunter 架构,内部包含三个结构相同的提示词。

AI推荐理由 作者拆解 Claude Code 内置 deep-research 技能,发现其以 349 行 JavaScript 编译进二进制,包含三个同构提示词,代码注释显示源自 bughunter 架构。提供了对 Agent 技能实现细节的一手分析,对理解 Agent 工作流设计有参考价值。

65

正文

This started with a surprise, not with a plan. I needed a survey of the state of the art on a topic I was considering working on, so I ran deep-research, a skill that ships with Claude Code, and it came back with a report I didn't expect from a single run —27 sources, 123 claims extracted, 25 verified, and of those 18 confirmed and 7 refuted— with an executive summary, caveats, and open questions. What struck me wasn't the volume (I already covered the 109 agents in the previous post) but that all of it came out of a single skill. I wanted to see how it was built. It wasn't easy to find: it doesn't live in .claude/skills/ or in ~/.claude. It's compiled into the Claude Code binary as a bundled workflow, and a comment in the code tells its origin: "Ported from bughunter architecture". It's 349 lines of JavaScript. Reading them was the research. How a prompt is written Inside there are three prompts, and all three follow the same shape: a role in the title, the context (the original question plus the specific input), a task as a numbered checklist, an explicit decision criterion, and the output format. The verifier is the clearest one: const VERIFY_PROMPT = (claim, v) => "## Adversarial Claim Verifier (voter " + (v + 1) + "/3)\n\n" + "Be SKEPTICAL. Try to REFUTE this claim. ≥2/3 refutations kill it.\n\n" + "## Claim under review\n\"" + claim.claim + "\"\n" + "**Supporting quote:** \"" + claim.quote + "\"\n\n" + "## Checklist\n" + "1. Is the claim actually supported by the quote, or is it an overreach?\n" + "2. WebSearch for contradicting evidence.\n" + "3. Is the source quality sufficient for the claim's strength?\n" + "4. Is the claim outdated?\n" + "5. Is this a marketing claim / cherry-picked benchmark / forum speculation?\n\n" + "**refuted=false** ONLY if: well-supported, current, and source quality matches claim strength.\n" + "Default to refuted=true if uncertain.\n\nStructured output only. Evidence MUST be specific." Enter fullscreen mode Exit fullscreen mode It's exactly the framework I use when I review one of my own prompts —role, context, task, format, constraints— but with two details I don't usually include: the decision criterion is written as a rule (refuted=false only if…) and ties resolve by default toward the conservative side ("Default to refuted=true if uncertain"). A prompt that doesn't say what to do when in doubt leaves that decision to the model, and that's where the tidy-but-unfounded answers show up. How a skill is built A skill is more than a long prompt. What I saw in the file falls into six pieces: 1. Trigger metadata. The meta declares the name, the description, and the five phases, but the key is whenToUse: it's what the model reads to decide whether to invoke the skill, and it includes a prior instruction —if the question is underspecified, ask two or three clarifying questions before starting. 2. Tuning constants at the top. No magic numbers buried in the code: const VOTES_PER_CLAIM = 3 const REFUTATIONS_REQUIRED = 2 const MAX_FETCH = 15 const MAX_VERIFY_CLAIMS = 25 Enter fullscreen mode Exit fullscreen mode 3. One schema per agent. Each of the five agent types returns JSON validated against a schema. That's what makes the pipeline composable: one agent's output is the next one's typed input. 4. Prompts as functions. SEARCH_PROMPT(angle), FETCH_PROMPT(source, angle), VERIFY_PROMPT(claim, v): they take the input and return the text. The prompt isn't copied, it's instantiated. 5. Explicit orchestration. Search and fetch go through pipeline(): each angle moves on to fetching its sources as soon as it's done, without waiting for the others. Before verification there's a barrier —and the comment says so: "Barrier here is intentional"— because the pool of claims has to be complete before it can be ranked. Then, nested parallel(): 25 claims × 3 votes. 6. Defensive design. Every early exit (no claims, everything refuted, failed synthesis) returns a useful result with stats instead of throwing. A null vote counts as an abstention, not as a free pass: const survives = valid.length >= REFUTATIONS_REQUIRED && refuted < REFUTATIONS_REQUIRED Enter fullscreen mode Exit fullscreen mode And the final result carries agentCalls: the skill computes its own cost (1 + angles + sources + claims × 3 + 1). That's where the 109 came from. Trimming the pattern The proof that I understood the pattern was reusing it. A couple of later runs on that same topic got cut off by the session limit before verification, and instead of repeating them in full I wrote reverify-linea-c: same meta, same constants, same verdict schema, and the same three-vote verifier, but with no Scope, Search, or Fetch —those phases were replaced by an array of 22 already-extracted claims. The whole skeleton inherited, one array of my own. All 22 came back confirmed. What I take away: a good skill isn't a long prompt, it's a short, well-formed prompt, instantiated many times by an orchestration that knows where to wait and where not to, and that measures what it spends. And it reads in an afternoon.

来源报道 · 1 篇 · 以下链接均前往原始媒体

← 返回精选动态 原文

更多内容