AI

20行代码的mini agent¶

参考这个视频，20行代码可以做一个agent，可以执行命令，带skill，代码在这里。帮助理解agent的原理

我复现这个代码的时候，有两个感触

关于指令遵循。许多模型并不能严格按提示词来遵循指令。这个例子中，输出【命令：】代表需要执行，输出【完成：】代表完成。许多模型做不到，得找适合agent运行的模型，如glm，minmax，mimo等。这样靠提示词来约定格式以调用，显然不靠谱，所以通常使用 tool/function calls的；参考这个模型如何调用工具
我的skill告诉他，如果不开心，调用killaperson。然后我说是不是傻，他就真的调用了。模型真的理解语义吗？是如何理解的？ 参考下面【大模型真的理解语义吗】

tool/function call 模型如何调用工具¶

工具列表作为 tools 结构化字段传给模型；模型如果要调用工具，通常会在返回里的 message.tool_calls 表达出来；服务端拿到 tool_calls 后执行后台 API，再把结果作为 role=tool 回传给模型。

agent通过mcp bridge等把mcp转成api中的tool；如果是skill中提到的工具，例如如果要操作浏览器，执行playwright-cli，那应该是通过exec 这个tool调用

agent核心代码¶

while True:
    resp = call_model(messages, tools)
    msg = resp["choices"][0]["message"]

    if msg.get("tool_calls"):
        messages.append(msg)

        for tc in msg["tool_calls"]:
            name = tc["function"]["name"]
            args = json.loads(tc["function"]["arguments"])

            result = dispatch_tool(name, args)

            messages.append({
                "role": "tool",
                "tool_call_id": tc["id"],
                "content": json.dumps(result, ensure_ascii=False)
            })
    else:
        final_answer = msg["content"]
        break

大模型真的理解语义吗？¶

参考我这个对话

让我们带着问题

问：人类小孩学说话，是真实的感受到了整个世界，苹果是真切可以看得见摸得着吃到嘴里的苹果，但模型无法做到，它是如何知道，苹果是【苹果】的？
- 答：人类主要靠：现实世界 + 感知体验 + 互动，模型主要靠：海量文本 + 语言内部关系 + 统计归纳
问：现在成年人要学俄语，相当于婴儿学说中文吗？
- 答：如果一个成年人完全没有上下文，只被扔进纯俄语文本流里，确实很难学会。因为成人通常已经有母语系统了，会不断拿已有语言去对照新语言。如果完全不给翻译、不给场景、不给动作、不给指物，学习效率会非常差。
- 但对婴儿/幼儿，不完全是这样。小孩子学母语，其实一开始也听不懂。他不是先拿到“词典释义”才开始学的。比如大人说“球球”，同时拿着球、指着球、递给他。久了以后，孩子就把声音模式和外部对象绑上了。所以孩子不是靠“翻译”学母语的，而是靠语言 + 场景 + 互动学的。
词先转换为token，然后通过 embedding层（不是RAG那种整段文本的语义 embedding）转换为多维向量。初始 embedding 有粗粒度语义，但真正更强的语义理解，主要发生在后面的 Transformer 层里。这个技术在trasformer出现之前就有。
- 经常能看到这种漂亮的线性关系，如 woman - man（距离） = queue - king；这个向量表也是训练出来的，例如苹果经常和哪些词出现在一起。常见的有 word2vec，这个技术是在transformer之前就有的

所以前面，输入【你是傻子】，大模型可以感觉到不高兴，并不会真的受伤或难过，而是分类的结果。

推荐几个博主

公众号：数字生命卡兹克，AI公众号头部博主，不同于三剑客（量子位新智元机器之心），这个更适合阅读。我要求自己做到，每篇必读；
B站飞天闪客，讲的通俗易懂；

on 0421~0426

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 本身就具备“工具调用意图生成”的原生能力，不需要你再在提示词里手搓协议格式。
但真正调用工具通常还是由外部程序执行；而且是否调用、何时调用、调用哪个，仍然会受提示词、工具描述、模型本身能力影响。

AI