Skill、MCP 等等 AI 外围工具，本质是 markdown 小作文吗

恭喜你发现了 AI 的本质：写小作文和当复读机

cursor 的回答，看起来大差不差。

1. 一堆 Markdown + 「描述每个干啥」+ AI 挑着读？
对，就是这么设计的。

Cursor：.cursor/rules/ 里每个规则是 markdown （或 .mdc ），用 YAML frontmatter 写：
globs：匹配哪些文件时这条规则生效
description：这条规则在什么情况下有用
alwaysApply：是否每次都带
客户端/Agent 根据「当前对话涉及的文件 + 描述」决定哪些规则被加入本次请求，相当于「按需挑着读」。

Claude Code：.claude/rules/ 里也是多份 markdown ，可以用 frontmatter 的 paths 做路径匹配，只有命中当前工作文件时才加载对应规则，同样是「按需」。

所以：有结构的 markdown 组合 + 用 frontmatter/描述说明「每条干啥、何时用」+ 由客户端/Agent 根据当前上下文决定带哪几条，这个理解是对的。

2. JSON 是干啥的？给 AI 读还是给代码读？
两种都有：

给人/给 AI 的说明：很多项目里会有 README 、CONTRIBUTING.md 、AGENTS.md 等，是自然语言 + 一点约定格式（比如「## 规则」「## 命令」），主要给 AI 当说明读。

给程序读的配置：
Cursor 的规则列表/索引可能用配置（不一定是裸 JSON ，也可能是 YAML ）记录「规则文件路径、glob 、描述」等，客户端代码读这些配置，决定本次请求要附上哪些规则、以什么顺序。
Claude Code 的 .claude/settings.json 是结构化配置，给 Claude Code 客户端读，不是给模型当「正文」读的。

所以：JSON/配置 = 给客户端程序做「规则调度、匹配、优先级」； markdown = 给模型当「可读的规则/说明」。模型主要吃的是 markdown 内容，不是 JSON 结构本身。

3. Markdown 里是「没特定结构的自然语言」吗？
不完全是。通常会有约定俗成的结构，但不是严格 schema：

常见区块：项目概述、常用命令、目录结构、命名/代码风格、禁止事项、示例等。

仍然是自然语言句子 + 列表 + 代码块，没有强制「必须有哪些 key 」的 JSON 式结构。

有的客户端会约定简单 frontmatter （如 globs 、description 、paths ），其余正文自由写。

所以：半结构：有惯用区块 + 自然语言描述规则/规范，不是完全无结构，也不是完全像 API schema 那样死板。

4. 目录结构：.claude 、.cursor 、AGENTS.md 等
是的，各客户端有自己约定的目录/文件：

Cursor：.cursor/rules/（多条规则）、历史上有 .cursorrules 单文件。

Claude Code：.claude/（如 settings.json ）、.claude/rules/、根目录 CLAUDE.md 。

通用/多客户端：很多项目会放 AGENTS.md 或 README 里写「给 AI 的说明」，谁支持谁就读。

所以：是的，大家会把「给 AI 用的东西」按各客户端的约定放到特定文件夹（如 .cursor 、.claude ）或根目录固定文件名（如 AGENTS.md ），不同客户端各读各的。

5. 调外部能力：HTTP 还是 stdio ？谁发请求？能力谁提供？
两种都有，而且「谁发请求」要分清：

MCP （ Model Context Protocol ）里常见两种传输：
stdio：和本地进程用标准输入输出通信（例如本地 MCP server 、本地后端）。
HTTP：和本地或远程 HTTP 服务通信。

谁真正发请求：
模型只做决策：「我要调某个 tool （例如 get_hitokoto ）」。
真正发 HTTP 、读文件、执行命令的，是 AI 客户端（ Cursor/Claude Code 等）或 MCP 客户端。
客户端根据「当前可用的 tool 列表 + 模型选的 tool + 参数」去执行：发请求、调 MCP 、跑 shell 等。

Markdown 里写啥：若你自己写一个 MCP server 或 HTTP API （比如「一言」），一般会在规则/文档里写：请求地址、方法、入参/出参长什么样，这样 AI 在「工具描述」或上下文中看到后，才知道该选哪个 tool 、传什么参数。工具本身的 schema （名字、参数、描述）往往由 MCP server 或客户端配置提供，markdown 更多是补充说明、示例、注意事项。

所以：通信方式 = HTTP 或 stdio 都常见；发请求/读写文件/执行命令 = 客户端或 MCP 客户端自带或通过 MCP 获得； markdown 里写请求地址、入参出参是为了让 AI 正确选择并填写参数。

6. 和 AI API 发请求时传啥？「按需传」怎么实现？
传的是「一串」多段内容，但不会无脑全塞：

发给模型的大致组成：
系统提示（含「你是什么、默认行为」）；
被选中的规则/文档（上面说的「挑出来的」 markdown 等）；
对话历史（可能截断或摘要）；
当前用户消息；
有时还有「当前打开/选中的文件」等。
这些在客户端里会拼成一条或几条消息（例如 system + user/assistant 轮次），本质上就是字符串（ token 序列），再加上校验、会话 id 、模型参数等 API 元数据。

「不能一股脑都传」怎么办：
规则/文档：用 globs / paths / description 做匹配，只把「和当前编辑文件、当前问题相关的」规则附进本次请求；
代码库：用语义检索（ embeddings + 向量相似度）或路径/符号索引，只取「和当前问题最相关的片段」放进上下文；
对话历史：超过一定长度就截断、摘要或滑动窗口，保证不超模型 context 上限。

所以：和 API 交互时，除了鉴权、会话、模型参数，主要就是在传「选好的规则 + 选好的上下文 + 对话」组成的字符串；按需传 = 客户端用匹配规则 + 检索/索引 + 历史裁剪，只把「用得上的」塞进这次请求，而不是把整个仓库和所有规则都塞进去。

@povsister 怎么说呢，好像也没有比这更好的设计了 大模型 API 好像有个通用的 oneAPI 来着，看消息格式也是老熟悉的 schema 呀

那感觉要是团队协作的话，能搞个类似 git 的工具呀，记录每个人产生的 AI 改动及对应的对话啥的，然后每次对话结束都让 AI 自己总结这个项目注意的点，AI 对话时容易出错的地方等等到一个 markdown 里，不断迭代，这个项目就越来越被 AI 熟悉了？就是感觉久了之后仓库大小会爆炸。。。。

本质是 string | (args) => string | Promise<string>，静态文本或者生成动态文本的副作用函数

MCP 不是

宇宙的本质是小作文

@capgrey 嗯，抓包看了下，mcp 是 schema fc ，skill 也放在 tools 里，看起来就是预设提示词，很灵活，大模型要了之后才把对应的 skill.md 读给大模型，神 token 啊

Agent 两大本质：工具调用（这个是主要的，MCP 也是工具调用）、提示词管理（ Markdown 小作文）

豆包/千问帮用户点外卖是工具调用； Agent 弹出个表单或者选择框让用户选择，也是工具调用； Agent 列出一个 Todo 清单，也是工具调用； Manus 的 Agent 可以读写文件沙箱、可以在沙箱里运行 Shell 命令，也是工具调用； Claude Code 在本地 ls 列出代码、grep 查询代码，也是工具调用。

但是，把上面每一个工具注册给 Agent ，都需要一个配套的 Markdown 小作文。

把 Skills 注册给 Agent 也要小作文；规范工具的调用方式，例如 Todo 清单只允许从上往下 done ，不允许修改已 done 的项，这也需要小作文，不然这个 Todo 会跳着执行或者突然被改掉了；很多 Agent 提供的例如 “深度研究”，其实也是提供一个 Markdown 小作文给 Agent ，让它的输出更高大上。

聪明的程序运行像个人