yan5xu

统计数据

23

文章

0

粉丝

0

获赞

117

阅读

5天前

强烈推荐读一下这篇文章我自己做了些整理作者是北大 Linian Wang。文章讲的是把 Kimi K2 适配到 vLLM 的过程中，遇到一个很反直觉的现象：同一个模型，在官方 API 上 tool calling 几乎不出错，但换到 vLLM 上就一塌糊涂。然后作者一步步定位原因、推动修复。我觉得它最值得看的点，其实不是“Kimi/K2/vLLM”上，而是通过这个过程可以把大模型 API 的底层逻辑理解清楚：大模型 API 的本质：把请求“展开成 Prompt（Token 序列）”，然后做补全（completion）。所谓 chatbot、tool calling / function calling，本质都是在这个过程上做工程封装。一切都可以拆回成：Render → Completion → Parse 现在 Chat Completions（以及 function call / tool calling）看起来是这种“结构化请求”： - messages：system/user/assistant 多轮（也包含 tool_calls 与 tool 的返回） - tools / functions：工具定义 - tool calling 的模式/约束：tool_choice、parallel tool calls 等 - 采样/停止参数：temperature、stop、max_tokens… 但在模型真正开始预测下一个 token 之前，这些东西都会被系统按照下面的过程处理： (A) 展开（render）→ 得到最终 Prompt（文本/Token 序列） (B) 补全（completion）→ 模型续写下一段 Token (C) 解析（parse）→ 把续写还原成 assistant 文本 / tool_calls 等结构化结果所以其实可以这么理解： - Chat Completions ≈ Completions +（A：自动把 messages 渲染成 prompt）+（C：把输出再解释回消息结构） - Chat + tool calling ≈ Chat +（C：把“特定格式的补全”解析成 tool_calls，并做 schema 校验/护栏）重点：Chat / Function Call 不是模型多了一种全新能力，而是服务端把 prompt 构造与输出解析自动化了；模型层面依旧是在做下一段 token 的补全。文章里出现的 bug 基本都发生在 A（render）或 C（parse），而不是“模型本身能力不行”。文章里一个非常实用的排障方法： - 不直接用 /v1/chat/completions - 而是在外部手动 apply_chat_template 得到最终 prompt - 再把这个 prompt 丢给更底层的 /v1/completions 这么做的好处是：你能“看到真相”： - 你能检查最终 Prompt 到底长什么样（当然也可以用 echo 回显出来） - 你还能看到模型最原始的补全文本（协议 token 没被上层 parser 二次加工/丢弃）后面很多结论，都靠这一步才定位出来：问题不在“模型不会调工具”，而在 prompt 展开和输出解析存在不兼容或边界问题。三个问题，用更直白的话讲清楚就是展开和解析上出了问题 1) Prompt 末尾少了“现在轮到 assistant 开始输出”的自动补全后缀本来应该用户问一句 → 模型应该立刻按 tool call 的格式进行补全。但因为一个参数没有传递到位，导致实际喂给模型的 prompt 末尾缺了关键的 assistant 回合起始标记 / generation prompt（可以理解为少了一个重要的协议尾巴，相当于没明确告诉模型“轮到你回答了”）。结果就是模型仍然会补全 token，但完全不知道“接下来该干嘛” - 有时像在续写历史对话（没进入回答态） - 有时输出自然语言闲聊 - 有时输出半截结构化但不成形 1) 空内容被错误渲染成，直接把 prompt 污染成噪声某条历史消息 content: '' 就是“空”，本来在 Prompt 也应该就是🈚️啥也不出现。结果实际渲染链路，框架内部为了统一数据结构，把 '' 标准化成类似 [{type: "text", text: ""}] 这样的 list（多模态/富文本体系里很常见）塞到 Prompt 里面。结果就是模型是在对“被污染的上下文”做补全。导致 tool calling 的效果劣化。 3) 模型其实已经“写出了工具调用”，但解析器太严格，把它当异常丢掉了模型已经生成了“看起来就是工具调用”的片段，但是解析器太严格了，当做异常处理掉了。（这里面还有上下文污染导致模型生成格式不对的原因）读完这篇文章最大的收获 1) 一切要还原到“Prompt 补全”这个本质上来理解。虽然这篇文章，是围绕 tool calling 展开的，但它的结论其实适用于所有大模型 API 场景（chat、completion、structured generation……）。不管你是用 chat 还是 function call，本质上都是在做“Prompt 补全”。所以当遇到问题，第一步都要还原到“最终 prompt 是什么样子？”要拿到实际喂给模型的 prompt，甚至不用像文章中这样，拿到协议层的，只用看到你的 API 请求就能判断对不对。另外很多 API 的报错，也可以从“Prompt 补全”这个角度去分析。 2) Tool calling 本质是“强约束 Schema 输出”（甚至可以当 JSON 限定器/结构化生成器用）。从工程角度看，tool calling 更像：让模型按一个强约束的输出协议（schema）去生成结构化片段，然后由服务端解析并执行。一旦你把它理解其本质是“强 schema 生成”，你会发现 tool calling 还能干一件很实用的事： - 你不一定真的要“调用工具”，也可以把它当作 JSON/DSL 的限定器，让模型稳定地产出符合 schema 的结构化结果，再交给下游系统处理。对“强约束生成 / constrained decoding”这个方向感兴趣的话，也推荐顺手看： - XGrammar：偏“把语法/约束编译成高效的 token 级约束”，让解码阶段就不可能走出非法分支 - LLGuidance：偏“用 guidance/约束驱动生成”，把结构化正确性前置到解码过程，而不是生成完再靠 parser 猜测。

4周前

LangChain Blog 系统性总结了 "Scratchpad" 和 "Reference" 等文件系统交互模式。 Manus 创始人 Yichao "Peak" Ji 的深度复盘，首次提出 "Filesystem is the Ultimate Context" 这一核心论断。 Anthropic Agent Skills 官方详解 Skills 机制：通过 `` (YAML+Markdown) 将领域知识封装为文件，让 Agent 动态加载。这是最标准的“母语化”工具设计案例。 CodeAct 论证了为什么“写代码”比“调 JSON 工具”更符合 LLM 的直觉（Action-as-Code）

Claude Skills系统发布引发AI行业新变革· 66 条信息

#LangChain #Scratchpad #Filesystem #Agent Skills #Action-as-Code

1个月前

anthropic 真的是一环扣一环有理论有实践在发 skills 的时候，针对工具膨胀浪费 token 提出了， Prompt 分层加载/复用，用代码执行&串联api/mcp（manus 把这个叫做上下文卸载）两个方法前天发 opus 的同时，把这两个方法固定到了推理 API 层面，Tool Search Tool，解决工具的发现&懒加载，Programmatic Tool Calling 实现代码执行工具。感觉以后anthropic api协议😂大有替代 openai 的可能

Claude Skills系统发布引发AI行业新变革· 66 条信息

#Anthropic #Opus #Tool Search Tool #Programmatic Tool Calling #API

1个月前

claude skills 有个没怎么被看到的点，就是信息分层设计。首先用元信息替代完整信息，离当前任务距离越远，展示的细节越少。其次是按需加载，skills 基于 markdown+grep，就搭建出一套简单但非常有用的按需加载层。真的是非常优雅。

Claude Skills系统发布引发AI行业新变革· 66 条信息

#Claude #信息分层设计 #按需加载 #Markdown #优雅

2个月前

cursor 如果这次把产品到模型的飞轮走通并且在市场上完成验证很有可能是后 agent 时代的新范式的开始期待他们成功和后续的分享

#产品到模型飞轮 #Agent时代 #新范式 #市场验证 #期待成功

2个月前

全文太长了，一万三千多字，所以发在公众号

#标签1 #标签2 #标签3

2个月前

最近两个月和非常多团队交流之后有一个强烈感受。很多人因为 agentic 循环过程的体感缺失和理解，这里存在非常大的认知差距。有人认为存在某种神迹让 Agent 有超越模型智力的表现；有人觉得无非多调用几次 API，哪有那么神奇；这种差距导致大家很多时候说话都不在一个频道。所以有了这篇长文，希望能够帮大家构成一个统一的上下文，“当我们在聊 agentic 的时候，我们在说什么”

#Agentic循环 #认知差距 #模型智力 #API调用 #统一上下文

3个月前

我认为，当下的人才观必须从“四处挖人”转变成“种庄稼”。很多人还迷信字节那套“只筛选、不培养”，却忽略了他们打的是移动互联网下半场，人才是市场上的“成品”，可以直接花钱买。但现在AI刚开局，哪有那么多“成品”？人才价格被炒到两亿美元，这真的是fair price吗？所以，当团队里已经有一两个核心人才时，更重要的任务是：赶紧梳理出一套培养体系和方法论。这可能会让产品慢上几个月。但现在本就是产品试错期，用时间换人才，换来一支能打硬仗的AI原生团队。这笔账，怎么算都值。甚至，足以让团队后发先至。

#人才培养 #AI人才 #长期主义 #人才体系 #后发先至

3个月前

前天听一个朋友说，他们为了加速开发一个人配了三台电脑😂

#加速开发 #三台电脑 #程序员 #工作强度 #效率

3个月前

两天时间 vibe coding 了一个中文版 Wispr Flow - 蛐蛐，阿里达摩院的 FunASR+ 通义千问3 30B改写，便宜好用，中文效果嘎嘎好，已开源！求体验！求喷！

#Vibe Coding #中文版 Wispr Flow - 蛐蛐 #阿里达摩院 FunASR #通义千问3 30B #开源

3个月前

原来很多人不知道gemini cli是一个很好的 agent 原型工具。system prompt 可以完全覆盖，通过mcp添加tool，甚至可以替换模型。快速出个原型完全足够了。

Google Gemini 2.5发布引发AI模型性价比热议· 475 条信息

OpenAI新德里发布会：ChatGPT语音翻译功能引发热议· 869 条信息

#Gemini CLI #agent原型工具 #system prompt #MCP #原型开发

4个月前

LLM 优化，常用技巧是压缩，有两个相反操作路径。 1, 对输入进行压缩，常见于旗舰级模型，用概念替代大段描述；李继刚“神级 prompt”是典范，"Oscar Wilde" "鲁迅" "林语堂"替代行文风格；难度在于对概念的抽象理解和积累，并且需要反复尝试，跨模型适配差； 2. 对输出进行压缩，适用于所有模型，尤见于 agentic 产品，用精准封装的 tools 替代agent 完整执行任务；难度在于 tools 尺度的选择，太少没效果，太多又会占据注意力，导致效果劣化，考验设计哲学；

#LLM优化 #压缩技术 #输入压缩 #输出压缩 #tools

4个月前

感谢 nano banana，终于能给 linkedin 换一个正经点的头像了。也不管像不像了，反正看我 linkedin 的人肯定也没见过我🤪

#LinkedIn #头像 #nano banana #社交 #幽默

4个月前

离职这段时间，在招聘市场荡了一圈。发现AI的核心或者主力研发是挖不到的但凡能被人看到的，都是有很强自驱力，被验证过实力的人。这个时间，都想自己做点事情。企业方，与其花精力挖人，不如给空间，让内部有想法的人去实践，总能拔出一批来。其实对未知的恐惧才是AI最大的门槛

#AI人才 #招聘市场 #人才自驱力 #企业内部培养 #未知恐惧

4个月前

说个暴论，现在是AI 产品的垃圾时间。模型进化降速，产品形态停滞，资本吵闹，创新乏力。我们正好回顾过去： 24 年初 Chatbot&套壳已现疲态；GPT-4o 宣告了数字游戏(3/3.5/4)的终结，也打碎了 LLM 无限进化的狂热。直到八月，Cursor 在 Claude 3.5 Sonnet 发布的两个月后，才在 Coding 这一垂直领域证明了 LLM 的应用深度，打破僵局。而市场，旋即回归平静。 25 年初，以 Deepseek 为代表的开源模型虽让市场再度火热，但这只是开源策略的胜利，但没有带来新的产品叙事。三个月后 manus 的登场，才真正拉开了 agent 的大幕；而现在，正处在又一个垃圾时间。Agent 是不是已经端不出新的菜？能讲出下一个故事的，又会是谁呢～

#AI产品 #垃圾时间 #模型进化降速 #产品形态停滞 #agent

4个月前

最近和很多团队交流的时候，我都会说，面对llm/agent这样一个新技术，它的边界，可行性，远景还未形成大众共识时，如何能指望产品经理提出一个可靠的产品方向呢。新技术落地的草莽阶段，一定是从技术人员里选拔培养产品出来。还停留在移动互联网时代组织架构的团队，只会是产品很茫然，技术很无力，大量成本都浪费在沟通上。

#LLM #agent #产品经理 #技术人员 #组织架构

4个月前

说一个在前司的观察：搞应用的，天天手动拼 prompt、管理上下文，去提高prompt cache 命中率，都快卷的没招了，实际就是在模拟“状态”。这全赖底层的推理 API 还是最原始的 stateless 形态。所以我有一个强烈的预感：下个能掀起波澜的 AI 产品，会是一个深度结合推理和应用层的怪物，把状态管理、KV Cache 复用做到极致，当别人还在为优化 10% 的 prompt 成本而沾沾自喜时，它在推理层通过“降维打击”的方式，用更少的成本获得了 10 倍的性能。从此之后再也不会有人认为 AI 应用是简单的套壳了

#AI产品 #推理API #状态管理 #kv cache #降维打击

4个月前

才知道openrouter 相比原厂有5%的溢价，加上和厂商谈的折扣，or两头吃啊😅

#AI掘金：知识付费新机，流量为王时代· 244 条信息

#Openrouter #溢价 #折扣 #两头吃 #负面

5个月前

五月份发到即刻上的一个随想。昨天回家路上突然想到一个让Agent自我成长的框架：大部分工作都能梳理成SOP → SOP变成workflow → workflow打包成tool → tool又能成为新workflow的节点... 受《思考，快与慢》启发，这个框架天然就有两套系统：慢系统：像人深度思考，注重逻辑推演。用最贵最聪明的大模型分析和梳理工作流程快系统：像人的直觉，着重快速反应。用低成本模型/自动化工具执行慢系统主动梳理工作流程，提炼成SOP，沉淀到快系统变成固定workflow。原本需要昂贵大模型一步步推理的任务，现在用便宜的工具就能快速执行！就像公司里的牛人专门做SOP梳理一样，Agent也能主动优化自己。现在LLM已经足够聪明，还能通过写代码自我拓展。Agent也需真的可以像人一样持续进化了！

#Agent自我成长 #SOP流程 #快慢系统 #LLM #自动化工具

5个月前

这篇文章其实在脑子里酝酿相当长一段时间。因为记忆碎片完美地把llm agent给具像化，不再更新的世界知识，有限的上下文窗口，如何构建外部记忆系统，以及来自信息的投毒，这几乎就是agent入门的完美教程。

#多智能体之争：Anthropic生态VS单智能体· 81 条信息

#LLM Agent #外部记忆系统 #信息投毒 #上下文窗口限制

5个月前

全文在公众号，文末有一段关于 kv cache 原理的科普强烈推荐读一读，对理解 llm 推理有帮助

#kv cache #LLM #推理 #原理科普

9个月前

摊牌了，manus 大量招人。我这里主要收两个方向。computer/browser use 以及常规golang后端。base不限，目前北京/武汉已设点。其他岗位大家可以关注蝴蝶效应招聘。我也可以帮忙内推。

#招聘 #golang #蝴蝶效应 #Beijing #专场招聘

11个月前

再分享一个驯服 Code Agent 的实用技巧！在用 Cline/Cursor/Windsurf 处理大型需求时，与 AI 的多轮对话会遇到两个问题： - 上下文积累导致： - AI 效果变差 - token 用量暴涨，费用激增 💸 - 历史错误内容污染后续对话经过实践，我总结了一套"双文档"方案： 1. 准备两个文档（直接让 AI 生成）： - 任务文档：记录需求和整体规划 - 进度文档：追踪已完成的内容 2. 工作流程： - 每轮对话都携带这两个文档 - 当 token 接近上限时，让 AI 更新进度文档 - 启动新对话，带着最新文档继续 - 循环以上步骤直到完成整个开发 - 完成后删除这两个临时文档这样做的效果： - 文档作为记忆，解决上下文丢失 - 新对话避免了历史错误的影响 - 压缩历史内容，大幅节省 token 费用用了一段时间，效果不错，分享给大家参考。

#code Agent #AI多轮对话 #双文档方案 #token费用 #上下文管理