标签 渐进式披露 下的文章

时间过得真快,距离上次发话题已经过去几个月,成年人的时间真是不经用。马上过年了,想罢年前一定要发点东西出来的。预祝大家新年快乐。


老实说,我在使用 AI coding 时,最抓狂的不是它写不出代码,而是它 太喜欢 “一口闷” 了

场景通常是这样的:
我让 Claude Code 查一个 Bug,它二话不说读取了一个 5000 行的 server.log 或者把整个 utils.py 塞进上下文。结果就是:

  1. Token 燃烧:我的钱包在滴血。
  2. 上下文污染:关键信息被淹没在几千行无关代码里,它的智商瞬间掉线,开始胡言乱语。
  3. 响应变慢:处理大量 Token 需要时间。

这其实就是典型的 上下文过载(Context Overload。模型就像一个贪婪的读者,如果你不限制它,它会试图把整个图书馆搬回家,而不是只借那一本它需要的书。

最近我在研究 Anthropic 提倡的 渐进式披露(Progressive Disclosure),并折腾出了一套强制性的文件读取策略。今天分享给大家,亲测能让 Claude Code 的脑子清醒不少。

什么是 “渐进式披露”?

别被这个学术名词吓到。用人话说是:不要给 AI 看全图,除非它问你要。

这就好比你作为一个人类程序员接手新项目,你不会上来就把 10 万行代码从头读到尾。你会先看目录结构(ls),再搜关键字(grep),最后只打开相关的那几十行代码(read)。

Anthropic 的文档里一直强调这一点:让模型先通过搜索定位,再通过切片读取。

但在实际的 CLI 工具中,Claude 有时候很懒,或者说 “太勤快”,默认行为往往是直接 Read 全文。所以,我们需要给它装一个 “防呆开关”。

这个 Hook 是怎么工作的?

我写了一个 Python 脚本作为 PreToolUse 的 Hook(工具调用前拦截器),配合 CLAUDE.md 的提示词,搞了一套 软硬兼施 的组合拳。

核心逻辑

这个方案由两部分组成:

  1. “软” 规则(Prompt):在系统提示词里告诉它,读文件必须加 offset(起始行)和 limit(行数限制)。
  2. “硬” 拦截(Hook 脚本):这是关键。当 Claude Code 试图调用 Read 工具时,脚本会检查目标文件的大小。
  • 如果文件超过 1000 行,且 Claude Code 没有 指定 offset/limit
  • 拦截操作!返回 Exit Code 2。
  • 杀手锏:在 stderr 里返回一段精心设计的报错信息。这段报错不仅告诉它 “你错了”,还告诉它 “你应该怎么做”(比如:推荐你先用 Grep 搜一下,然后只读第 X 行附近的 50 行)。

为什么它非常 Work?

这利用了 LLM 的一个特性:它们非常听 “报错信息” 的话。

当 Tool Use 失败并返回一个明确的 “推荐路径” 时,Claude 会立刻在这个报错的 Context 下进行自我修正。

  • Claude: “我要读 app.log。” (未指定范围)
  • Hook: (拦截) “不行,文件太大了。你必须指定读取范围。建议先用 Grep 搜一下关键词。”
  • Claude: (收到报错) “噢,抱歉。那我们就先用 Grep 搜一下 ‘Error’ 关键字吧。”

看,这就强行把它拽回了 “渐进式披露” 的最佳实践路径上。

如何食用

你需要两个东西:一个是配置在项目根目录的规则文件,一个是实际执行拦截的 Python 脚本。

1. 提示词 (CLAUDE.md)

把这段加到你的项目提示词文件中。这相当于 “先礼后兵”,先告诉它规则。

中文版本

### 文件读取策略

** 强制规则 **:每次调用 Read 工具时 ** 必须 ** 指定 `offset``limit` 参数,禁止使用默认值。

#### 参数要求

| 参数   | 要求           | 说明                          |
| ------ | -------------- | ----------------------------- |
| `offset` | ** 必须指定 ** | 起始行号(从 0 开始)         |
| `limit`  | ** 必须指定 ** | 读取行数,单次不超过 500 行   |

#### 读取流程 1. ** 侦察 **:先用 Grep 了解文件结构,或定位目标关键词行号。
2. **
精准打击 **:使用 offset + limit 精确读取目标区域。
3. **
扩展 **:如果需要更多上下文,再调整 offset 继续读取。

**
目标 **:保持上下文精准、最小化。如果不遵守,工具调用将被 Hook 拦截。

English Version

### File Reading Strategy **MANDATORY RULE**: Every `Read` tool call **MUST** verify `offset` and `limit` parameters. Default full-file reads are prohibited for non-trivial files.

#### Parameter Requirements

| Param    | Requirement    | Description                   |
| -------- | -------------- | ----------------------------- |
| `offset` | **REQUIRED** | Start line number (0-indexed) |
| `limit`  | **REQUIRED** | Max lines to read (Max 500)   |

#### Workflow 1. **Recon**: Use `Grep` first to understand structure or locate keywords.
2. **Surgical Read**: Use `offset` + `limit` to read only the relevant section.
3. **Expand**: Adjust `offset` to read more context only if strictly necessary.

**Goal**: Keep context precise and minimal. Violations will be blocked by the PreToolUse hook.

2. The Hook (Python 脚本)

保存为 read_limit_hook.py,并在你的 Claude CLI 配置 hook(如果你不会可以直接把文件给 claude code 让它代劳)。

(这个脚本稍微有点长,但逻辑很简单:检查文件大小 → 检查参数 → 决定是放行、自动修正还是报错拦截)

#!/usr/bin/env python3 """
PreToolUse hook for Read tool - Enforce offset/limit and block large file reads.
"""
import json import sys import os from datetime import datetime # --- 配置区域 --- MAX_FILE_LINES = 1000 # 超过这个行数必须切片读 MAX_FILE_BYTES = 50 * 1024 MAX_SINGLE_READ_LINES = 500 # 一次最多读 500 行 MAX_SINGLE_READ_BYTES = 20 * 1024 # 跳过不需要检查的二进制文件 SKIP_EXTENSIONS = {'.png', '.jpg', '.jpeg', '.gif', '.pdf', '.exe', '.dll', '.so', '.dylib', '.zip', '.tar', '.gz'} # 日志文件(可选,帮你分析它浪费了多少次尝试) LOG_FILE = os.path.expandvars ("$USERPROFILE/.claude/hooks/read-stats.log") def get_file_stats (file_path): try: if not os.path.exists (file_path): return None, None size = os.path.getsize (file_path) with open (file_path, 'r', encoding='utf-8', errors='ignore') as f: lines = sum (1 for _ in f) return lines, size except: return None, None def format_bytes (size): if size >= 1024 * 1024: return f"{size / (1024 * 1024):.1f} MB" if size >= 1024: return f"{size / 1024:.1f} KB" return f"{size} B" def main (): try: input_data = json.load (sys.stdin) except: sys.exit (0) # 甚至不是 JSON,不管了 tool_name = input_data.get ("tool_name", "") tool_input = input_data.get ("tool_input", {}) # 只管 Read 工具 if tool_name != "Read": sys.exit (0) file_path = tool_input.get ("file_path", "") offset = tool_input.get ("offset") limit = tool_input.get ("limit") # 1. 扩展名检查 ext = os.path.splitext (file_path)[1].lower () if ext in SKIP_EXTENSIONS: sys.exit (0) lines, size = get_file_stats (file_path) if lines is None: sys.exit (0) # 读不到文件,让 Claude 自己处理错误 # 2. 检查是否是大文件 is_large_file = lines > MAX_FILE_LINES or size > MAX_FILE_BYTES if is_large_file: # 如果是大文件,且没有指定 offset 或 limit -> 拦截! if offset is None or limit is None: reason = f"{lines} lines / {format_bytes (size)}" error_msg = ( f"BLOCKED: File is too large ({reason}) for a full read.\n" f"You MUST use 'offset' and 'limit' to read specific sections.\n\n" f"Strategy:\n" f"1. Use`Grep`to find the line number of your function/variable.\n" f"2. Then`Read`with offset=LINE_NUM, limit=50.\n" f"DO NOT try to read the whole file again." ) print (error_msg, file=sys.stderr) sys.exit (2) # 2 通常表示操作被拒绝 # 3. 检查单次读取是否贪得无厌 if limit is not None and limit > MAX_SINGLE_READ_LINES: print (f"BLOCKED: Limit {limit} is too high. Max allowed is {MAX_SINGLE_READ_LINES}.", file=sys.stderr) sys.exit (2) # 4. 贴心的小功能:如果有 offset 没 limit,自动帮它补上 limit,防止它犯傻 if offset is not None and limit is None: output = { "hookSpecificOutput": { "permissionDecision": "allow", "updatedInput": { "limit": MAX_SINGLE_READ_LINES } } } print (json.dumps (output)) sys.exit (0) sys.exit (0) if __name__ == "__main__": main ()

效果

装上这一套之后,你会发现 Claude 的行为模式变了:

  • 以前:读取 main.c (3000 行) → 思考 → 修改。
  • 现在:尝试读取 main.c → 被拦截 → 思考 “哦,我应该先搜一下” → Grep main 函数 → 读取 main 函数周围 50 行 → 思考 → 修改。

虽然多了一步交互,但 上下文极其干净,Token 消耗量能降低 80% 以上,而且修改的准确率反而提高了。

试一下吧,让你的 Claude Code 甚至其他 Agent 学会渐进式的读取。


📌 转载信息
原作者:
cedricthecoder
转载时间:
2026/1/22 12:56:48

之前写了一篇关于 SKILL 设计最佳实践的话题,感受到佬们的热情

【SKILL 设计的最佳实践】什么是 SKILL?怎么快速写一个优秀的 SKILL? - 开发调优 - LINUX DO

也感觉好多佬们都对 SKILL 设计还蛮感兴趣的,加上最近一直在对自己的 SKILL 进行调优,研究跟看了不少官方文档以及实践示例,对 SKILL 的设计略有心得,所以就在之前的基础上,把最近关于 SKILL 的进阶设计模式简单分享一下自己的理解吧。

内容绝大多数参考了官方的最佳实践文档,然后也结合自身调优的一些体验。Claude 的文档写的还是不错的,有时间的佬友们还是蛮推荐读一读的,链接就放在下面了。

技能编写最佳实践 - Claude Docs — Skill authoring best practices - Claude Docs

还是一如既往的大纲 + 一图流,方便佬们快速了解文章的大致内容以及组织形式。

1. 引子

为了方便对 SKILL 还不太了解,或者没看过上期的佬们快速理解,我举一个例子再来说明一下什么是 SKILL。

假设你是一名喜欢到世界各地旅行,你需要准备很多装备 (对应 mcp tools) 以应对不同情况,例如:

  • 登山:登山包、山地靴、登山杖、…
  • 极地:防寒服、手套、护目镜、…
  • 雨林:驱虫喷雾、开山斧、…

那么对于特定场景我们将所需的东西都打包起来叫做 "登山套装" 或者 "极地套装"。这种为了应对特殊场景需求的工具套装,Claude 官方把他叫做 SKILL

SKILL 中还包含了一些工作流(workflow),也可以理解为在特殊场景的操作手册,告诉你在遇到突发情况时应该怎么处理。

所以通过安装 SKILL 的方式可以使得模型在特定场景发挥强大的作用,同时你也可以自己根据喜好重新安排对应的 SKILL 中工具或者进行工作流的微调。

2. 渐进式披露 & 二次披露

那么很自然的想法,SKILL 这种将现成工具打包起来的做法是不是多余的呢,为什么我们不能把所有工具跟手册都带上,那么就能处理所有情况呢?

很遗憾的是目前大模型的上下文是有限的,就像如果你带上所有的工具去旅行,那么不仅很笨重(有效上下文受限),而且遇到突发情况时,从一大堆工具中找到适合的工具的难度也上升了(上下文混淆)

所以 SKILL 的设计理念的核心在于 渐进式披露

  • 将所有的工具以及手册,先放到四次元口袋中,不随身携带(不加载上下文)
  • 但是为了能快速加载所需工具,使用目录来进行快速查找

这种记录可用工具套装的纸条(包含 name 以及 description),在遇到特定场景的时候就可以加载对应的工具(MCP tools、脚本)以及手册(项目文档、工作流规范)的模式就是 SKILL 的工作原理。

而这种目录结构加载资源的方式就称为 渐进式披露

“二次披露” 实在 渐进式披露 的基础上的进阶应用,可以进一步提高上下文的有效利用,避免宝贵的上下文资源浪费,为此 Claude 官方文档中提出三种模式来指导二次披露的使用

2.1. 模式一: 附参考资料的高级指南

同样以登山包为例,在一个 SKILL 中可以只包含基础工具以及新的索引,当基础工具不能应对情况的时候,可以再根据索引的信息加载高级工具来处理问题。

以官方示例为例:


---

name: pdf-processing

description: Extracts text and tables from PDF files, fills forms, and merges documents. Use when working with PDF files or when the user mentions PDFs, forms, or document extraction.

---

# PDF Processing ## Quick start

Extract text with pdfplumber:

```python

import pdfplumber

with pdfplumber.open("file.pdf") as pdf:

text = pdf.pages[0].extract_text()

```
## Advanced features **Form filling**: See [FORMS.md](FORMS.md) for complete guide **API reference**: See [REFERENCE.md](REFERENCE.md) for all methods **Examples**: See [EXAMPLES.md](EXAMPLES.md) for common patterns

这个示例中对于进阶的需求,并没有直接披露到 SKILL.md 的 body 中(就是 See xxx 这些内容),因此在 SKILL 调用的时候,这些额外的进阶内容并不会直接加载到上下文中挤占有限的上下文空间。

而当模型结合 SKILL 以及用户问题的时候,感知到可能需要 API reference 的时候,他也具备进一步读取 REFFERENCE.md 文档的能力,来补足上下文。这种二次披露的能力可以进一步使得 SKILL 的上下文得到更有效的利用。

在我的实践中还发现这种能力实际上可以诞生一种能力,我暂时将其称之为 sub-skill,具体的设计以及实现可以等之后发布了我的 SKILL 之后再详细介绍一下 嘻嘻

2.2. 模式二:领域特定组织的加载

官方文档的说法是涉及多个领域的技能,应按领域组织内容,避免加载无关的上下文。

例如,当用户询问销售指标时,Claude 只需要读取与销售相关的模式,而无需读取财务或市场营销数据。这样可以降低令牌使用量,并专注于上下文。
预先将相对独立的上下文进行分开存储,并且使用关键词来进行索引以及引导,当需要特定领域的上下文细节的时候 使用 grep 等工具实现上下文的全量加载

这实际上就是通过 文件组织 的形式,实现不同场景参考资料的分离,因此也是一种二次披露,每次只披露与使用者问题相关的场景上下文来补足信息。

与模式一不同的点在于:

  • 模式一是 根据功能 进行区分,
  • 模式二是根据 领域场景 进行区分

本质上都是对信息的有效整合以及分离调度,这里最需要学习的实际上是他参考资料的文件组织路径形式,将同类的参考进行归档,方便后续修改或者变更,也方便模型进行索引。

bigquery-skill/
├── SKILL.md (overview and navigation)
└── reference/
├── finance.md (revenue, billing metrics)
├── sales.md (opportunities, pipeline)
├── product.md (API usage, features)
└── marketing.md (campaigns, attribution)
# BigQuery Data Analysis ## Available datasets **Finance**: Revenue, ARR, billing → See [reference/finance.md](reference/finance.md) **Sales**: Opportunities, pipeline, accounts → See [reference/sales.md](reference/sales.md) **Product**: API usage, features, adoption → See [reference/product.md](reference/product.md) **Marketing**: Campaigns, attribution, email → See [reference/marketing.md](reference/marketing.md) ## Quick search Find specific metrics using grep: ```bash
grep -i "revenue" reference/finance.md
grep -i "pipeline" reference/sales.md
grep -i "api usage" reference/product.md
```

2.3. 模式三:条件细节

这一点就更好理解了,就是在引用资源前添加条件,类似通过使用 For xxx 或者是 if xxx, then xxx 的方式来让模型显示的知道何时该主动二次披露相关内容

# DOCX Processing ## Creating documents

Use docx-js for new documents. See [DOCX-JS.md](DOCX-JS.md).

## Editing documents

For simple edits, modify the XML directly.

**For tracked changes**: See [REDLINING.md](REDLINING.md)
**For OOXML details**: See [OOXML.md](OOXML.md)

2.4. 反模式:避免深度嵌套引用

既然有二次披露,那么三次四次甚至更多次披露是不是能更省上下文呢?

Claude 的回答是:不!

原因在于虽然 Claude 具备嵌套引用,但是本身对于嵌套引用采取了 额外的限制 ,例如只读取前 100 行的内容(head -100),因此嵌套引用可能会导致 信息缺失 以及 逻辑结构混乱 的现象。

官方推荐的做法是最好只调用到 二次披露 ,即只在 SKILL.md 中进行索引,不要在更深的文件结构下进行索引的创建以及链接。

注意事项:

  • 对于二次披露的参考文献应当限制长度(行数小于 100 行,因为 claude 可能只读前 100 行)
  • 如果超过 100 行,建立目录来让 claude 具备感知全文内容的能力
  • PS: 但如果目录超 100 行那就无话可说了 哈哈哈


文章正文就先写到这吧 哈哈哈(下面是一些自己的感悟以及碎碎念

总的来说 SKILL 并不是一个非常高深或者难的技术,甚至对计算机没有一点基础的小白也能迅速上手,但是更多的如果想要设计一个非常优秀的 SKILL 还是需要对这些底层的调用机制有一定了解的。

笔者在自己构建 SKILL 的过程中发现,虽然 skill-creator 这个官方工具能快速搭建一个大致框架,但是内容的详细程度还是没有想象的那么优秀,很多都还蛮简单的,而且设计模式并没有很好的贯彻最佳实践中的要点,特别是二次披露以及文件组织,常常因为获取的内容跟信息太少而没办法有效组织。

而在后续修改的过程中,如果设计者不了解最佳实践的基础原理,由于 Claude Code 谄媚的现象,往往会导致 SKILL 的后续修改反而脱离了最佳实践的要求,导致性能变差。

顺便预告一下,下次更新可能会介绍 SKILL 设计中 工作流以及反馈循环 怎么设计以及调优的相关内容。

佬们周中愉快 哈哈哈


📌 转载信息
原作者:
guanhuhao
转载时间:
2026/1/14 17:43:27

距离 Anthropic 发布 Skills 也过去将近两个月的时间了,其中 Anthropic 提到了一个术语渐进式披露 (Progressive Disclosure),这到底是什么东西?解决了什么问题?

其实在我的 Vibe Coding 流程中,我很少使用 MCP。因为我觉得 MCP 实现质量层次不齐,本质是上下文注入 (工具的本质也是上下文注入),我不确定别人写的提示词会不会影响到我的工作流,干脆直接不用。现在的 MCP 实现基本上就是把所有的功能全都包装成工具暴露给 Agent (一个功能包装成一个工具,给定详细的描述,告诉 agent 在什么时候进行调用,参数格式是什么),这就导致了现在的提示词爆炸。

直到 Anthropic 发布了 Skills,研究了一下发现本质仍然是提示词注入。如果说 MCP 是提供了一套注入工具的规范,那么 Skills 所提倡的则是 “离经叛道”。Skills 给了一个 Markdown 文档用于描述该 skill 的用途和最佳用法,附带提供了一些脚本 (与 MCP 不同)。


由于这些脚本直接在用户本地运行,存在极大的安全风险。如果用户不能对脚本代码进行 review,很容易造成数据泄露、感染病毒等严重安全性问题。相比于 MCP 提供一个标准化的接口,Skill 提供一系列的脚本文件,不同的 skill 可能拥有不同类型的脚本文件,比如有些脚本使用 node.js 实现,有些脚本使用 Python 实现,要使用这些脚本还需要用户安装对应的运行时和脚本所需要的依赖。这也是我说 “离经叛道” 的原因所在。

这真的是最佳实践吗?

关于渐进式披露,Anthropic 是这样描述的:

渐进式披露是使代理技能灵活且可扩展的核心设计原则。就像一本组织良好的手册,从目录开始,然后是具体章节,最后是详细的附录一样,技能允许 Claude 仅在需要时加载信息:


拥有文件系统和代码执行工具的智能体在执行特定任务时,无需将技能的全部内容读取到上下文窗口中。这意味着技能中可以包含的上下文信息量实际上是无限的。

下图是使用 Skill 的上下文窗口变化

我们真的需要这样去实现吗?

在我们平时使用 CLI 工具时,一般的 CLI 工具都会带有一个 --help 参数,用于查看该工具的用法和说明,这不就是该工具的使用手册吗?比如:

>npm --help
npm <command>

Usage:

npm install        install all the dependencies in your project
npm install <foo>  add the <foo> dependency to your project
npm test           run this project's tests
npm run <foo>      run the script named <foo>
npm <command> -h   quick help on <command>
npm -l             display usage info for all commands
npm help <term>    search for help on <term>
npm help npm       more involved overview

All commands:

    access, adduser, audit, bugs, cache, ci, completion,
    config, dedupe, deprecate, diff, dist-tag, docs, doctor,
    edit, exec, explain, explore, find-dupes, fund, get, help,
    help-search, hook, init, install, install-ci-test,
    install-test, link, ll, login, logout, ls, org, outdated,
    owner, pack, ping, pkg, prefix, profile, prune, publish,
    query, rebuild, repo, restart, root, run-script, sbom,
    search, set, shrinkwrap, star, stars, start, stop, team,
    test, token, uninstall, unpublish, unstar, update, version,
    view, whoami

Specify configs in the ini-formatted file:
    /Users/xxx/.npmrc
or on the command line via: npm <command> --key=value

More configuration info: npm help config
Configuration fields: npm help 7 config

这份手册也不会返回所有的命令所有的用法,它只会返回它有哪些命令可以实现什么功能,对于命令的具体用法你仍然可以通过 --help 参数获得:

>npm install --help
Install a package

Usage:
npm install [<package-spec> ...]

Options:
[-S|--save|--no-save|--save-prod|--save-dev|--save-optional|--save-peer|--save-bundle]
[-E|--save-exact] [-g|--global]
[--install-strategy <hoisted|nested|shallow|linked>] [--legacy-bundling]
[--global-style] [--omit <dev|optional|peer> [--omit <dev|optional|peer> ...]]
[--include <prod|dev|optional|peer> [--include <prod|dev|optional|peer> ...]]
[--strict-peer-deps] [--prefer-dedupe] [--no-package-lock] [--package-lock-only]
[--foreground-scripts] [--ignore-scripts] [--no-audit] [--no-bin-links]
[--no-fund] [--dry-run] [--cpu <cpu>] [--os <os>] [--libc <libc>]
[-w|--workspace <workspace-name> [-w|--workspace <workspace-name> ...]]
[-ws|--workspaces] [--include-workspace-root] [--install-links]

aliases: add, i, in, ins, inst, insta, instal, isnt, isnta, isntal, isntall

Run "npm help install" for more info

这是不是很像上面的渐进式披露的定义?

我们是不是可以按照这种风格去实现一个 MCP 来实现无需 skill 的工具渐进式披露?我使用 Codex 将官方的 PDF Skill 转换成了一个 MCP,只暴露一个工具:

{ "name": "mcp__pdf__pdf", "description": "Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale.You need to pass in the --help parameter to obtain the usage of this tool first.", "input_schema": { "type": "object", "properties": { "params": { "$ref": "#/$defs/PdfCommandInput" } }, "required": [ "params" ], "$defs": { "PdfCommandInput": { "additionalProperties": false, "properties": { "argv": { "description": "Command tokens excluding the leading 'pdf' executable name", "items": { "type": "string" }, "title": "Argv", "type": "array" }, "command": { "anyOf": [ { "type": "string" }, { "type": "null" } ], "default": null, "description": "Optional command string; if set, it will be split like a shell", "title": "Command" } }, "title": "PdfCommandInput", "type": "object" } }, "title": "pdfArguments" } } 

下面是使用该 MCP 的上下文窗口变化

User: Extract all the text from test.pdf and write it into result.txt
Agent: Tool(name="pdf", args=["--help"])
Tool: pdf - Comprehensive PDF manipulation toolkit for extracting text and tables, creating new PDFs, merging/splitting documents, and handling forms. When Claude needs to fill in a PDF form or programmatically process, generate, or analyze PDF documents at scale在使用之前你需要先传入--help参数以获取该工具的用法\n\nUsage:\n  pdf [--help] <domain> <command> [options]\n\nDomains:\n  forms      Fill, extract, and validate PDF form fields.\n  documents  Create, merge, and split PDFs.\n  text       Extract text content from PDFs.\n  tables     Extract tables (heuristic, whitespace-based).\n  images     Render PDF pages to PNG images.\n\nRun `pdf <domain> --help` for domain help.\nRun `pdf <domain> <command> --help` for command help.
Agent: Tool(name="pdf", args=["text", "--help"])
Tool: text - Extract text content from PDFs.\n\nUsage:\n  pdf text <command> [options]\n\nCommands:\n  extract  Extract text content from a PDF.\n\nRun `pdf text <command> --help` for details.
Agent: Tool(name="pdf", args=["text", "extract", "--help"])
Tool: usage: pdf text extract --pdf PDF_PATH [--pages PAGES] [--out OUTPUT_PATH]\n                        [--format {text,json}] [--overwrite]\n\nExtract text content from a PDF.\n\noptions:\n  --pdf PDF_PATH        Input PDF\n  --pages PAGES         Page selection like 1,3-5 or 'all' (default: all)\n  --out OUTPUT_PATH     Write extracted text to a file\n  --format {text,json}  Output format (default: text)\n  --overwrite           Overwrite output file if it exists\n
Agent: Tool(name="pdf", args=["text", "extract", "--pdf", "test.pdf", "--out", "result.txt", "--overwrite"])
Tool: {"result": {"stdout": "xx","data": {"pdf_path": "test.pdf","page_count": 6,"pages": [xxx],"format": "text","output_path": "result.txt"}}}
Agent: xxx

从上下文变化情况来看,完全实现了渐进式披露,该 MCP 代码开源 (代码完全由 codex 编写,只验证想法,未做任何审查): GitHub - musistudio/pdf-skill-mcp: pdf-skill-mcp

如果你有什么想法也欢迎与我进行交流


📌 转载信息
原作者:
musistudio
转载时间:
2026/1/11 08:44:31