跳转至

AI

langchain -> workflow -> skill -> agent

都可以已实现工作流，越来越灵活， - langchain纯编程实现工作流 - workflow是低代码拖拽形式，变更更方便些 - Skill是智能体自行控制 - agent自由发挥

Spec ——睡前设计，醒来验收

  • Vibe模式：小修小补bugfix
  • Plan模式：中等Feature任务，
  • Spec模式：系统级复杂功能
  • 用数十分钟打磨核心Spec，换取Agent彻夜的高效自治运行

CLI vs MCP

  • MCP的初衷，是为了让厂商一次实现，就可以被多个AI客户端调用；是为了厂商和生态方柏霓，减少重复开发和标准化接口。
    • 大模型是不需要MCP协议的，它只要知道怎么调用就行了。只要语义清楚，模型就能执行。 （可见MCP名字起的不好）
    • 它的本质，是为了远程交互，是为了让高德、github这种服务提供工具被Agent使用；
  • 所以，所有本地执行的工具，都不应该做成mcp，这是对的mcp误用，mcp的核心意义在于和远端交互。如果之和本地打交道，那最好用cli，

这里对比下远端工具时cli和mcp

  • cli更省token，mcp要求把所有工具定义参数等一次性提供给模型（这点在优化，如tool_search功能）；github mcp server 需要55000 token，而gh --help需要200-500 token
  • 模型本身就会使用cli，cli对人类也友好，而mcp只面向agent；
  • cli 透明度好，调试成本低，强大的组合管道深入人心
  • 目前绝大多数场景，cli + skill 可以替换mcp
  • MCP优势是企业治理、权限控制、跨客户端复用

claude.md agent.md 别误用

  • 有篇论文，开发者手写该文件仅微增性能（+4%），AI生成文件却致性能暴跌（-3%）并推高运算成本20%以上。实测中，移除此类文件后，AI模型在代码库导航效率显著提升，避免过时风险与误导向
  • 他很接近system prompt，而不是user prompt，这比你对话中的提示词优先级更高。
  • 你希望每次对话都需要的系统提示词，才需要写进去，否则它会分散注意力
  • 随着模型越来越聪明，里面需要放的越来越少了

Temperature & Top-p 大模型的创造力开关

  • 大模型是根据问题和前面输出的词，输出下一个词。按概率随机采样
  • temperature，温度（很形象，分子更活跃）。 增大会缩小候选词的差距，输出会更加多样化
  • top-p，最高累加概率。如0.9，候选词概率排序，凑够90%概率后，剩下的长尾垃圾词不要了

Claude Code

一些技巧

  • /rewind /task /resume
  • /hook 例如write之后跟一个格式化的命令
  • /skill-name 用户可以指定skill
  • skill 和 subagent有相同点，区别就在于前者会共享当前上下文，而subagent显然不会
  • /plugin 是一个skill subagent hook mcp的集合，claude code自带应用商店
  • !ls 可以执行命令

Skill

  • 大模型是大脑，工具是手和脚。这个Skill能就是技能包，是一份说明文档，一张“遇到这种任务时该怎么干”的操作卡片。

大模型的大脑 + Skill 的专项能力 + 工具的执行手脚

  • 里面的文档可以按需加载到上下文，里面可以指定工具也可以按需调用
  • 元数据层：名称和描述，始终加载
  • 指令层：skill.md中名称和描述之外的内容。按需加载，类似MCP
  • 资源层：reference和script，渐进式披露
  • skill 中也能调用工具，但只适合跑一些轻量脚本
  • 这个确实有可替 代mcp的功能，可以看 Playwright MCP，官方推荐使用 cli skills 了，可以看到skill.md 就是描述如何使用的命令方式操作浏览器的

MCP

定义了一种规范：工具的注册与使用，这个交互是mcp server与client (mcp client) 的交互。

  • 每个mcp server可能提供多个工具tool，提供工具描述和参数说明，让模型知道何时及如何使用此工具。
  • 这是一份交互协议，安装mcp的时候client和server进行多轮交互，获取到工具列表以及传参类型。python的fastmcp框架做了这些工作，我们只需关注tool实现。
  • 对话的时候，把所有工具带过去。如果需要，大模型会告诉客户端去调用哪个；客户端把调用结果在返给模型。但工具太多会占用太多token显然不合理，工程角度需要处理，可能先用小模型判断对话是否需要工具。
  • 通信方式三种
  • stdio适合本地工具，server需要本地启动，按需启用，和客户端一对一；类似一个bash命令就是一个server
  • sse，以及升级版Streamable HTTP；web服务，例如高德，stack推送服务等
  • 这里有个例子分别代理了mcp和模型接口，可以看到agent与他们交互细节，视频
  • mcp除了tool (model-controlled)，还有prompt (user-controlled)，resources (application control) 等类型，用的比较少
  • 开发调试工具 mcp inspector
  • 想看mcpserver的交互注册和交互过程，可以代理mcpserver并打印日志，参考。

RAG（检索增强生成）

  • 常备用于做私有知识库。
  • 一开始可以把知识库全塞到上下文中，但显然知识库可以很大，会塞不下，浪费token，浪费注意力。所以需要先把相关的知识搜出来，然后塞到上下文，类似【联网】工具
  • 两个阶段
  • 数据准备阶段：数据提取——>文本分割——>向量化（embedding）——>数据入库
  • 应用阶段：用户提问——>数据检索（召回）——>（重排再筛选） ——> 注入Prompt——>LLM生成答案
  • embedding也是一种专有模型，在LLM热潮早很多。他把离散对象（词、句子、文档等）映射成向量，用向量距离表示语义相似度
  • 向量数据库可以存储向量，可以进行相似度搜索

Agent

  • 比喻：给聪明的大脑，加上手和脚，示例
  • 通过system prompt约定大模型严格按照输出格式，并把工具列表给他，把思考方式告诉他。
  • 客户端就可以解析返回值，来运行指定工具，结果问大模型，循环，直到大模型觉得结果满意【ReAct模式/思想，客户端和大模型交互协议】
  • 工具太多，经常使用小模型先问下相关工具有哪些，避免所有工具直接塞给模型，占用太多上下文
所有步骤请严格使用以下 XML 标签格式输出：
- <question> 用户问题
- <thought> 思考
- <action> 采取的工具操作
- <observation> 工具或环境返回的结果
- <final_answer> 最终答案
你首先会收到一个用户问题<question>，然后你需要讲问题拆解成多个步骤。
每个步骤你首先要使用<thought>思考接下来的行动
然后把需要调用的工具和参数放到<action>中
然后你会收到工具调用的返回结果，放到<observation>中
持续上述循环，直到你认为已经获得了足够的信息，并把你的最终答案放到<answer>中
  • 除了ReAct 还有Plan and exectute模式，先规划后执行（现在模型这么强了，普遍已经不需要强制模型思考了，他们自己使用think思考）
  • 想看Agent的提示词，如cline、kilo code等，可以弄一个起代理，带日志的那种，配在agent上，就可以请求的提示词。

ReAct

三个词：思考，行动，观察（thought/action/observation） Reasoning and acting 姚顺雨论文

Token

  • Tokenizer = 预处理规则 + 词表(vocab) + 切分算法
  • 预处理规则，如空格规则，Unicode处理等
  • 切分算法，常见BPE（Byte Pair Encoding），Unigram
  • 词表是词对应tokenId，输入和输出大模型都是id
  • Tokenizer 不是词法分析，是基于统计频率的子词压缩算法
  • 经常出现的词合并成一个token，例如喜欢，是一个token。一句话，模型的输入会更少，训练和推理效率就会更高
  • BEP不光包括词表，还有merge规则，即merge 是有顺序的，不是贪心最长匹配。如【研究生命起源】，可能会把【研究生】切分，这取决于merge规则顺序，这个和词表大量预料得来的；
  • 如 GPT-2 tokenizer，词表约 50k，merge rules \~50k 条，推理时，字节切分，按 5万条 merge 规则逐步合并，时间复杂度非常低。
  • 而Unigram通过概率/DP选择一定程度可以避免这种歧义。Unigram 可能计算出：P(研究)*P(生命)*P(起源) > P(研究生)*P(命)*P(起源)
  • tokenizer 的目标其实不是“语言学正确”，tokenizer 的目标是稳定编码。token 数量尽量少token 越少：推理成本越低。因为 Transformer 复杂度：O(n²)。
  • LLM 并不依赖“正确分词”。即使 tokenizer 切成：研究生 / 命 / 起源；仍不影响训练。Transformer 会在更高层建模。

deepseek r1 的意义

以前很多人默认，最强 reasoning 模型这件事，只有少数美国闭源实验室能做，而且要靠巨额算力、海量人工标注、封闭数据和不透明配方。R1 之后，这个判断被冲击了。因为它同时证明了几件事：

  • 中国可以做出顶级的reasoning model，当时媲美o1。reasoning 训练范式的创新
  • 开源：把关键成果以 open weights / MIT license 的方式放出来
  • 成本：能在受限算力条件下把效率做到很高（当时16元/1M，后来8元，3元...）

说明：中国团队已经不只是跟随做 chatbot，而是在 reasoning 训练范式、开源影响力、成本效率这三个维度，能直接参与定义行业方向了。

所以当时有句话，中国也在AI的牌桌上了

function calling

  • agent和大模型之间约定的工具调用格式。（这好像更应该叫模型上下文协议哈，mcp反而是agent和mcp server的工具调用协议）
  • 一些模型/API 本身就具备“工具调用意图生成”的原生能力，不需要你再在提示词里手搓协议格式。
  • 但真正调用工具通常还是由外部程序执行；而且是否调用、何时调用、调用哪个，仍然会受提示词、工具描述、模型本身能力影响。