阅读周刊（第 10 期）

1. 文章

1.1 Coding Agent 有个甜蜜点，多数人直接跳过了 | 宝玉的分享

AI 总结本文聚焦“Coding Agent 的甜蜜点”及其核心做法：通过给 AI 明确参照物、建立自动化验证、遵循架构蓝图并实现人机协同的设计闭环，使大语言模型在编码任务中高效产出符合期望的结果；并通过 Simon Willison 的 JustHTML 重写与 Cloudflare 的 vinext 案例，展示在可参考的标准、测试驱动和分步实现的条件下，AI 助力下的高产与高质量并行提升。

先看看有没有参考项目/代码再动手。
给 Agent 配上自动验证的能力。
先设计后实现。
建立反馈闭环。
知道什么时候 Agent 不行。

1.2 国产模型春节、来自开发者的一线复盘

mp.weixin.qq.com

AI 总结本文是拾象Best Ideas社群组织的国产模型春节大考闭门讨论会实录，来自MiniMax、智谱、字节Seedance等团队的一线研究者分享了2026年初国产大模型的技术突破、商业化路径与出海策略，核心围绕模型能力跃迁、视频生成革命、Agent落地与Token经济展开。

AI Coding 至少是一个千亿美金的市场，而 AI 视频的市场空间不一定比 coding 小，因为十几亿普通用户已经每天在抖音 / TikTok 上消耗 2-3 小时了，在 AI 视频能力进化后，这 2-3 小时带来的意义价值可能还会更大。
软件工程的工作性质已经发生了实质性的变化。现在硅谷一线 AI startup 里，一个程序员已经可以一整天不亲手写一行代码，而只是通过聊天来驱动 Coding Agent 完成实打实的工程构建。
Kimi 2.5 甚至是通过 RL，把类似 “一个 Orchestrator + 一堆 Sub-Agent” 的编排思路直接写进了模型的内生能力里。
OpenClaw 创始人 Peter Steinberger 在 Claude 账号被封后改用 Minimax 模型一定程度上也验证了 Minimax 在 Performance、cost、speed 上找到了一个很好的平衡点。
Anthropic 最值得学习的经验是“Dogfooding”。MiniMax 全公司都在用 Agent Native 的组织方式工作，即优先让 Agent 自己解决问题，如果解决不了，就把它定义成下一个版本的 Benchmark
Fal.ai ：可以简单理解为视频模型的 OpenRouter，估值已经达到 45 亿美金，平台上的核心模型很多都是中国的（可灵、海螺、Seedance…）
Fireworks：通过优化部署中国开源模型（如 DeepSeek、千问等）同样在海外市场赚取了丰厚利润。
长期看 ToB 赚取的是辛苦钱，ToC 赚取的才是生态位。
长期看，中国厂商的优势不在于直接卖 API，而在于产品出海。拼创意、拼迭代速度，以及拼中国特有的电力成本优势。
出海的重心不必绑定美国市场。考虑到地缘政治因素，美国市场可能难以切入，但除此之外的全球市场机会相当广阔。

1.3 AI 工程化落地实践：推翻"完美架构"，回归提示词本质

mp.weixin.qq.com

AI 总结本文通过反思 AI 工程化落地的实践，提出“推翻完美架构、回归提示词本质”的核心观点：简单的输入组织和文本化规范（如 AGENTS.md、Markdown 规范、context/experience 等）比复杂的多层 Agent 架构更高效、易落地；强调三大落地原则（文档即记忆、先跑起来、自然演进），以及将知识与流程以文本化形式嵌入工作流中，实现单仓库、无状态大模型的高效协作，从而把 AI 转化为团队的共享能力与长期资产。

NotebookLM 的设计逻辑是什么？

PLAINTEXT

输出 = f(来源, 输出格式)

其中：
- 来源：你丢进去的材料
- 输出格式：播客、报告、思维导图...
- f：LLM 的理解和生成能力

点击展开查看更多

最好的工具是你不知道它存在的工具。
LLM 本身就是最好的解释器，它不需要复杂的"协议"
NotebookLM 直接读 PDF 和网页。Claude Code 直接操作文件系统。它们都没有中间层的"意图识别"或"路由调度"。
关键：不要一开始就设计完美的知识结构。遇到什么记什么，自然演进。
技巧 1：用 XML 标签隔离不同类型的指令

PLAINTEXT

<coding_style>
    <dos>
        - 错误处理必须包装：fmt.Errorf("failed to x: %w", err)
        - 日志必须带 traceId
    </dos>
    <donts>
        - 禁止使用 panic
        - 禁止在循环中调用数据库
    </donts>
</coding_style>

点击展开查看更多

技巧 2：写决策逻辑而不是散乱的规则

PLAINTEXT

## 遇到不确定的业务逻辑时
1. 先搜索 context/business/ 下的相关文档
2. 如果文档没写，搜索相关代码实现
3. 如果代码也不明确，再问我

点击展开查看更多

技巧 3：记录 AI 容易犯的错

PLAINTEXT

## AI 注意事项
- 【重要】修改 config 后要重启服务才能生效
- 【重要】用户表的 status 字段：0=未激活，1=正常，2=封禁（不是布尔值！）

点击展开查看更多

我们的方案：直接给 AI 赋予 grep、find、ls 能力。它能像资深工程师一样，通过文件结构和关键词自己找到答案。
知识路由表

决策口诀：
1. 是整体计划？→ plan.md
2. 是当前进度？→ process.txt
3. 是长期知识？
  - 所有人都得知道？→ AGENTS.md
  - 特定领域？→ context/ 目录

落地三原则：
- 文档即记忆 —— AGENTS.md 是人机共用的入职手册
- 先跑起来 —— 从最简单的提示词开始
- 自然演进 —— 观察使用模式，让需求驱动演进

1.4 AI Agent系列｜深入解析Function Calling、MCP和Skills的本质差异与最佳实践

mp.weixin.qq.com

AI 总结本文系统阐述 AI Agent 的工具能力核心：Function Calling、MCP 与 Skills 的本质差异与最佳实践。核心观点包括：Function Calling 是将非结构化需求转换为结构化工具调用的基础；MCP 提供统一的 JSON+HTTP 接口以便快速接入现有系统；Skills 通过文字定义指令、脚本与资源，将复杂流程以文档化形式注入上下文，提升任务执行的灵活性与环境适应性，同时也与 MCP 存在竞争关系。作者还通过 Lynxe 的实践经验，指出当前方案在需求描述结构化与系统接驳方面仍需改进，并提出“所有能力皆以函数暴露”为设计原则，以实现更高的结构化输入输出和系统集成。

一句话总结
- Function Calling：AI Agent 调用工具的基础能力，也是后面两个能够存在的基础。
- MCP (Model Context Protocol)：由 Anthropic 推动的开放标准，为 LLM 应用提供标准化接口以连接和交互外部数据源和工具，现已捐赠给linux基金会。
- Skills：Anthropic Claude的一个新的尝试，可以允许用户更细致的用文字定义指令、脚本和资源，跟MCP有竞合关系，我们后面会从不同角度来阐述这个竞合关系（虽然很多人认为是互补，但实际上，这两个是竞争关系更大一些）。
Function Calling确实解决了核心问题：让LLM能够稳定地输出结构化的工具调用请求，实现了"非结构化→结构化"的转换。这是AI Agent工具能力的基础。
MCP的核心其实还是基于Function Calling的。它做的事情很简单：把Function Calling的调用，在客户端转换成一套JSON+HTTP的请求。然后提供一套Server来响应这个JSON+HTTP请求，这样就能实现各类应用都可以被LLM使用的效果。
Skills的核心其实也是基于Function Calling的。它做的事情很巧妙：通过一个固化的函数和参数，让模型去查找和加载固定的skills文档。这里的关键是，Skills完全依赖于Function Calling这个基础能力。如果没有Function Calling，Skills就无法工作。Skills只是在Function Calling之上的一个巧妙应用：把"加载文档"这个操作封装成一个函数，然后让Claude在需要时自动调用。
Skill工作流程：
- 初始化阶段：用户用文字定义指令、脚本和资源，打包成Skills（包含SKILL.md和可选的脚本、参考资料等）。Claude在启动时会读取所有Skills的元数据（名称和描述），这些元数据被加载到模型的上下文中（每个约100 token）。
- 发现阶段：当用户发起请求时，Claude会根据请求内容，对比已加载的Skills元数据，判断是否需要使用某个Skill。这个判断过程本质上就是LLM根据上下文做决策，跟Function Calling中判断是否需要调用工具是一样的。
- 加载阶段（Function Calling）：如果Claude判断需要某个Skill，它会通过Function Calling机制调用一个专门的加载函数（类似load_skill(skill_name)），将对应的SKILL.md文档内容读取并加载到当前上下文中。这一步完全依赖Function Calling的能力。
- 执行阶段（继续使用Function Calling）：SKILL.md的内容（包含指令、流程、示例等）被加入到上下文后，Claude按照文档中定义的指令执行任务。如果SKILL.md中定义了需要执行脚本（比如scripts/rotate_pdf.py），Claude还是会通过Function Calling调用执行脚本的函数。如果需要加载参考资料，同样是通过Function Calling调用读取文件的函数。
Skills并没有创造新的能力，它只是把Function Calling这个基础能力组织成了一个更易用的形式：让用户可以用文字定义流程，让Claude自动发现和加载相关知识。从本质来说，他替代的是mcp 调用的函数里面，过去可能会用代码写的一套串接各种API的逻辑流程，用这种方式，可以增强流程的适应性
Agent将决策权完全下放给了 Agent 和 Prompt，能够解决原有写程序不能解决的问题——比如处理不确定性、动态调整策略、理解自然语言意图等。

PLAINTEXT

Claude 判断是否需调用某 Skill（基于请求内容匹配已加载的 skill_name 与 description）
↓
若需要，则通过 Function Calling 调用 load_skill(skill_name)
↓
将对应 SKILL.md 的内容注入当前上下文，作为执行指令依据
↓
Claude 依照 SKILL.md 中定义的流程执行任务
↓
在执行过程中，按需通过 Function Calling：
  • 调用 bash 执行附带脚本
  • 调用 read_file 读取所需资源文件
↓
整合执行结果

点击展开查看更多

MCP的核心是解决与既有系统的接驳问题：实际上，与外部系统接驳的方法并不只有MCP这一种——我们完全可以用curl、bash等传统方式来与程序接驳。MCP的价值在于它提供了一套标准化的接驳协议，让不同的工具和数据源能够以统一的方式被LLM使用。
Skills则实际上是一个sub-agent的包装：它让用户可以用文字来写流程，替代了过去在MCP调用的函数里用代码写的一套串接各种API的逻辑流程。这种方式可以增强流程的环境适应性——因为模型可以根据实际情况动态调整策略，处理不确定性，理解自然语言意图。
Agent将决策权完全下放给了模型和Prompt，能够解决原有写程序不能解决的问题。但代价就是不可能100%准确，因为模型的行为存在不确定性，无法像传统代码那样保证完全可预测的执行结果。
虽然很多人认为MCP和Skills是互补关系，但实际上，这两者更多是竞争关系。这种竞争主要体现在它们解决的是同一个问题：如何整合多个既有系统，实现复杂的多步骤任务。
LLM要实现工具调用，实际上最需要的内容只有：函数名、参数要求，以及一个description。基于这个前提，我们来看看MCP和Skills的不同解决思路：
- MCP的解决思路：通过标准化的协议和Server架构，引入了一个新的协议转换Server（这个Server可以用Node.js、Python或其他语言来实现）。但这个协议转换层往往也只是先做了函数调用的协议转换，然后再增加一个description，打包，发布。这个流程是非常薄的——它本质上只是在Function Calling的基础上，增加了一层JSON-RPC协议转换。
- Skills的解决思路：选择了更简单的办法，可以不需要这层协议转发Server，直接用bash以参数形式调用，结果其实是一样的，还更省事。换句话说，MCP的JSON-RPC可以被直接替换为命令行脚本或curl远程调用，在本地直接调用。这样甚至都不需要额外做MCP封装了。而且在这个基础上，Skills还能支持更复杂的流程定义——通过SKILL.md文档告知LLM如何组合多个接口调用，所以长流程任务的成功率会更高。
这就是为什么说它们是竞争关系：当用户选择使用Skills时，他们就不需要在MCP Server的函数中编写复杂的串接代码了；反之，如果选择在MCP Server中实现完整逻辑，Skills的价值就会降低。
- 协议转换Server+代码型流程定义 vs 直接命令行调用+文字化流程定义
三者的总结性对比表