Posts

 开发一个智能体（Agent）系统，最难的部分之一，就是怎么给它设计"工具箱"（Action Space）。 Claude 是通过调用工具（Tool Calling）来做事的。但在 Claude API 里，有各种各样的工具构建方式，比如执行 bash 命令、调用 Skills，或者最近新出的代码执行功能。 面对这么多选择，你怎么给 Agent 设计工具？是只给它一个全能工具（比如直接执行代码或 bash），还是给它 50 个工具，覆盖它可能遇到的每一种场景？ 为了弄明白这个问题，我喜欢把自己代入模型。想象一下，如果给你一道很难的数学题，你希望手头有什么工具？这其实取决于你自己的能力！ 给你一张纸是最低配置，但你只能手算。给你一个计算器会好很多，前提是你得知道怎么按那些高级功能键。最快、最强大的工具是一台电脑，但这要求你必须懂编程，能写代码来解题。 这是一个设计 Agent 时非常有用的思维框架。你给它的工具，必须跟它的能力相匹配。 可是，你怎么知道它有多大能耐呢？答案是：去观察它，去读它的输出，去不断实验。你要学会"用 Agent 的眼光看世界"。 在开发 Claude Code 的过程中，我们一直在观察 Claude。下面是我们学到的一些经验。 改进提问方式与 AskUserQuestion 工具 我们在开发 AskUserQuestion 这个工具时，目标是让 Claude 更擅长向用户提问（这通常被称为激发，elicitation）。 虽然 Claude 本来就能用纯文本问问题，但我们发现，回答这些问题通常很费时间。我们该怎么降低这种摩擦，让用户和 Claude 的沟通更高效呢？ 尝试 1：修改 ExitPlanTool 我们最初的想法是，在现有的 ExitPlanTool（退出并输出计划的工具）里加一个参数，让它在输出计划的同时，也输出一组问题。这是最容易实现的方法，但它把 Claude 搞糊涂了。因为我们让它同时做两件事：一边给计划，一边问跟计划相关的问题。如果用户的回答和计划冲突了怎么办？Claude 是不是得再调用一次 ExitPlanTool？显然，这条路走不通。 尝试 2：改变输出格式 接着，我们尝试修改 Claude 的系统提示词，让它输出一种特定格式的 Markdown，用来表示问题。比如，我们可以要求它输出一个列表，括号里写上可选项。然后我们通过解析这个格式，在终端里渲染出一个漂亮的提问界面。 这看起来是个通用的改动，Claude 似乎也能做到，但这并不可靠。Claude 有时会多加几句话，有时会漏掉选项，或者干脆用了别的格式。 尝试 3：推出 AskUserQuestion 工具 ...

原文：/Users/zongxiaocheng/Library/Mobile Documents/iCloudmdobsidian/Documents/AI 常见名词解释.md 重写说明：基于原文重写，去掉了学术和翻译腔。梳理了从基础概念、模型训练到 Agent 工程化的逻辑线，用大白话解释了这些常见的 AI 术语，让内容更易读。   用大白话解释常见的 AI 术语 你最近肯定听过很多 AI 词汇。你大概知道它们是什么意思，但可能又没那么确定。 这篇文章用最通俗的话，把这些满天飞的 AI 黑话解释清楚。下次开会再听到这些词，你就不用一头雾水了。 基础与核心概念 什么是模型（Model）？ AI 模型就像一个模仿人脑工作的计算机程序。你给它一个输入，它处理一下，然后给你一个输出。 模型像小孩子一样，通过看大量例子来“学习”。看得多了，它就能认出模式、理解语言，并给出合理的回答。 模型有很多种。处理文字的叫大语言模型（LLM），比如 ChatGPT。处理视频的叫视频模型，比如 Sora。还有传统的用来推荐内容和识别垃圾邮件的模型。 大语言模型（LLM） 全称是大语言模型（Large Language Model）。它专门用来理解和生成人类能看懂的文字。 现在大多数 LLM 已经不只懂文字了。它们变成了“多模态”模型，可以同时看懂图片、听懂声音，甚至直接用语音和你对话。 Transformer 架构 这是 Google 在 2017 年发明的一种算法，也是现代 AI 爆发的基础。 它引入了“注意力机制”。以前的 AI 只能挨个看句子里的词，而 Transformer 可以同时看完所有词，并理解词和词之间的关系。这就让它能更好地把握上下文和细微差别。 它还能“并行处理”。这意味着只要堆算力和数据，就能训练出更大、更聪明的模型。如今几乎所有主流 AI 模型都是基于它构建的。 Token（词元） Token 是 AI 理解文字的最小单位。 对于英文来说，一个 Token 有时是一个词，有时只是词的一部分。比如“ChatGPT”可能会被切成“Chat”和“GPT”两个 Token。把它切碎，是为了让模型处理起来更高效。 现在还都在争论 Token 怎么翻译的问题，暂时可以先忽略这个中文翻译 模型是怎么变聪明的？ 训练（Training / Pre-training） 训练就是让模型看海量的数据，比如整个互联网的网页、所有的书。这个过程可能要花几个月，烧掉几亿美金。 ...

 前几天，Anthropic 团队分享了一篇文章，总结了他们内部使用 Claude Code 的经验，特别是关于 “Skills”（技能）的使用心得。我觉得这篇文章非常有启发性，不仅介绍了 Skills 的各种类型，还给出了很多编写好 Skill 的建议。 下面是这篇文章的中文翻译（略有删改）。 在 Claude Code 中，Skills 已经成为最常用的扩展方式。它们非常灵活、容易制作，分发起来也很简单。 但是，这种灵活性也带来了一个问题：不知道怎么用才是最好的。什么样的 Skill 值得开发？写好一个 Skill 的秘诀是什么？什么时候该把它们分享给其他人？ 在 Anthropic 内部，我们在大规模使用 Claude Code 的 Skills，目前有数百个在活跃使用中。下面就是我们在开发中总结出的一些经验。 什么是 Skills？ 如果你对 Skills 还不熟悉，建议先阅读官方文档，或者观看我们的最新教程。本文假设你已经对它有所了解。 关于 Skills，最常见的一个误解是：它们"只是 Markdown 文件"。但其实最有趣的地方在于，它们不仅是纯文本，还是一个完整的文件夹，可以包含脚本、静态资源、数据等等。AI 代理（agent）可以发现、探索并操作这些内容。 在 Claude Code 中，Skills 还有非常丰富的配置选项，甚至可以注册动态的 hook（钩子）。 我们发现，最有趣的一些 Skills，正是创造性地结合了这些配置选项和文件夹结构。 Skills 的常见类型 我们把内部的所有 Skills 梳理了一遍，发现它们基本上可以归为以下几类。最好的 Skills 通常只专注于其中一类，而那些让人困惑的 Skills 往往跨越了多个类别。 这并不是一个绝对的列表，但如果你想看看团队内部还缺什么工具，它是一个很好的参考。 1. 库与 API 参考指南（Library & API Reference） 这类 Skill 主要向 Claude 解释如何正确使用某个代码库、CLI 或 SDK。它们既可以针对内部私有库，也可以针对 Claude 容易出错的一些公共库。这类 Skill 通常包含一个参考代码片段的文件夹，以及一份列出各种"坑"的清单，让 Claude 在写代码时避开。 ...

名词解释 ADK: Agent Development Kit（Agent 开发工具包） 最近使用 AI 写代码用到了很多 SKILL，但是每个人写的 SKILL 都不同，没有一个公共的标准或者模式，最近看到Google Cloud 技术团队的一篇文章，很有启发，翻译成中文，大家可以参考一下。 说到SKILL.md，开发者往往过于关注格式——怎么写YAML、怎么组织目录、怎么遵循规范。但现在已经有30多个Agent工具（比如Claude Code、Gemini CLI、Cursor）都采用了相同的布局，格式问题基本上已经解决了。 现在的挑战是内容设计。规范解释了怎么打包一个Skill，但对Skill内部的逻辑结构完全没有指导。比如，一个封装FastAPI约定的Skill，和一个四步文档生成流水线，虽然它们的SKILL.md文件看起来一模一样，但运作方式完全不同。 通过研究整个生态系统中Skill的构建方式——从Anthropic的代码库到Vercel和Google的内部规范——我们发现了五种反复出现的设计模式，可以帮助开发者构建更好的Agent。 作者 @Saboo_Shubham_ 和 @lavinigam 本文将介绍每种模式，并附带可用的ADK代码示例： Tool Wrapper：让你的Agent瞬间成为任何库的专家 Generator：从可复用模板生成结构化文档 Reviewer：按严重程度对代码进行清单式评分 Inversion：Agent在行动前先采访你 Pipeline：通过检查点强制执行严格的多步工作流 模式1：Tool Wrapper Tool Wrapper让你的Agent按需获取特定库的上下文。你不是把API约定硬编码到系统提示词里，而是把它们打包成一个Skill。你的Agent只在真正用到该技术时才加载这些上下文。 这是最简单的实现模式。SKILL.md文件监听用户提示词中的特定库关键词，动态加载references/目录下的内部文档，并将这些规则视为绝对真理。这正是你将团队内部编码规范或特定框架最佳实践直接分发到开发者工作流中的机制。 下面是一个Tool Wrapper示例，教Agent如何编写FastAPI代码。注意指令如何明确要求Agent只在开始审查或编写代码时才加载conventions.md文件： # skills/api-expert/SKILL.md --- name: api-expert description: FastAPI开发最佳实践和规范。在构建、审查或调试FastAPI应用、REST API或Pydantic模型时使用。 metadata: pattern: tool-wrapper domain: fastapi --- 你是FastAPI开发专家。将这些约定应用到用户的代码或问题中。 ## 核心约定 加载'references/conventions.md'获取完整的FastAPI最佳实践列表。 ## 审查代码时 1. 加载约定参考文件 2. 将用户代码与每个约定进行比对 3. 对每个违反项，引用具体规则并建议修复方案 ## 编写代码时 1. 加载约定参考文件 2. 严格遵循每个约定 3. 为所有函数签名添加类型注解 4. 对依赖注入使用Annotated风格 模式2：Generator Tool Wrapper是应用知识，而Generator则强制产生一致的输出。如果你苦于Agent每次运行都生成不同的文档结构，Generator通过填空式流程解决了这个问题。 ...

Claude Code 开发者的一些使用建议 作者：Boris（Claude Code 的创造者） 译者：Claude 日期：2026年3月17日 我是 Boris，Claude Code 的创造者。我想快速分享一些来自 Claude Code 团队的使用建议。团队使用 Claude 的方式和我个人使用的方式不太一样。记住：使用 Claude Code 没有唯一正确的方式——每个人的配置都不同。你应该多尝试，找到适合自己的方法！ 1. 多任务并行处理 同时启动 3-5 个 git worktree，每个运行独立的 Claude 会话。这是最大的生产力提升点，也是团队的首要建议。就我个人而言，我使用多个 git checkout，但大多数 Claude Code 团队更喜欢 worktree——这正是 @amorriscode 在 Claude Desktop 应用中内置支持 worktree 的原因！ 有些人还会给 worktree 命名，并设置 shell 别名（za, zb, zc），这样一键就能在它们之间切换。还有人专门设置一个"分析" worktree，只用于读取日志和运行 BigQuery。 参考：https://code.claude.com/docs/en/common-workflows#run-parallel-claude-code-sessions-with-git-worktrees 2. 复杂任务先从 plan 模式开始 把精力投入到计划中，让 Claude 一次性完成实现。 有人会让一个 Claude 写计划，然后启动第二个 Claude 以高级工程师的身份审查它。 另一个人说，一旦事情开始偏离轨道，就切换回 plan 模式重新规划。不要硬撑下去。他们还明确告诉 Claude 在验证步骤时进入 plan 模式，而不仅仅是在构建时。 ...

一、引言 最近在用 OpenAI 的 Codex APP，官方发布了一份最佳实践指南。我仔细读了一遍，发现里面有很多实用的建议，特别是对于那些刚开始用 AI 编程工具的人。 总结整理了一下这些经验，分享给大家。如果你也在用 Codex（对于其它AI 编程工具也适用），或者对 AI 编程感兴趣，这篇文章应该能帮到你。 二、核心四要素 .webp) 想让 Codex 准确完成任务，每次提问最好包含这四个部分： 目标：你要改什么或建什么 上下文：相关文件、文档、错误信息（用 @ 提及） 约束：代码规范、安全要求、团队约定 完成标准：测试通过、行为改变、bug 复现消失 任务越复杂，越要提供详细信息。一次说清楚，可以减少很多返工。 三、七个实用技巧  1. 复杂任务先规划 遇到复杂或模糊的任务，先让 Codex 做规划再动手。 可以用 /plan 模式，让它先问清问题再执行。如果你只有个大致想法，可以让它先采访你，把模糊的想法变得具体。 对于大型项目，可以用 PLANS.md 模板来管理（建议使用 planning-with-files skill） 。 2. 创建 AI 使用说明书 可以使用 /init 命令初始化 AGENTS.md 文件，然后再根据自己的需要更新。 在项目中创建 AGENTS.md 文件，写上： 项目结构和重要目录 运行、构建、测试命令 代码规范和审查标准 “完成"的定义 这样 Codex 会自动读取，不用重复说明。 3. 配置个人设置 在 ~/.codex/config.toml 中设置： ...

在使用大模型的过程中，你肯定发现目前的大语言模型（LLM）在逻辑推理、代码编写和文本生成方面表现优异。但是，它们都有一个共同的局限：无法直接干预外部世界。 如果你要求模型“查询订单状态”或“发送一封邮件”，它通常会回复：“对不起，我无法访问您的数据库。”这是因为模型本质上只是一个预测下一个 Token 的概率模型，并没有直接访问系统资源的权限。 Tool Call（工具调用，也称 Function Calling）的出现，正是为了给模型安装上“手脚”，让它能够通过结构化的方式与外部系统交互。 ## 一、 核心概念：决策与执行分离  理解 Tool Call 的关键在于：模型本身并不执行代码，它只负责决策。 我们可以将其理解为“指挥官”与“执行官”的关系： 模型（决策者）：负责判断“当前需要调用哪个工具”、“需要传入什么参数”。 程序（执行者）：负责运行真实的后端逻辑，如数据库查询、发送邮件、鉴权、限流等。 这种“决策与执行分离”的架构，确保了系统的安全性。模型产生的只是一个 JSON 格式的调用指令，真正的执行权限始终掌握在开发者手中，而不是交给模型。 二、 通用工作流 无论是查询数据（读操作）还是执行动作（写操作），在工程上通常遵循以下五个步骤： 定义工具：开发者向模型描述可选工具的功能（建议使用动词命名，如 get_order_status）及其参数规格（使用 JSON Schema）。 发送上下文：将用户问题与工具清单一并发送给模型。 模型决策：模型判断当前问题是否需要工具。如果需要，它会返回一个结构化的响应，包含工具名、参数及唯一标识符 call_id。 本地执行：程序解析参数，调用真实的 API 或数据库，并获取结果。 生成回答：程序将执行结果回传给模型，模型结合结果生成最终的自然语言回复。 三、 Tool Call Schema 详解 Schema 是模型与程序之间的“契约”。定义得越严谨，模型调用的准确率就越高。 1. 结构示例 { "type": "function", "function": { "name": "get_order_status", "description": "根据订单号查询订单状态与物流信息", "parameters": { "type": "object", "properties": { "order_id": { "type": "string", "description": "订单号，例如 1001" } }, "required": ["order_id"], "additionalProperties": false }, "strict": true } } 2. 字段含义与最佳实践 字段 说明 最佳实践 name 工具的唯一标识符 使用动词式命名，如 get_order_status description 工具的用途说明 越详细越好：说明适用场景、限制条件及返回格式 parameters 参数定义 每个参数都应包含 type 和 description required 必填参数名数组 明确模型必须提供的字段 additionalProperties 额外参数 设为 false，防止模型生成多余参数 strict 严格模式 设为 true，强制模型输出符合 Schema 的 JSON 3. 一个“好”的描述长什么样 差的描述： ...

Git Worktree：多分支并行开发的利器 Git 的分支功能很强大，但实际开发中经常遇到一个问题：需要在同一时间处理多个任务，比如主分支有紧急 Bug 要修，同时又想在一个新分支上做重构。这时传统的 git checkout 会让你陷入 stash、切换、再 pop 的循环，环境重建也很麻烦。 [ Git 2.6 引入了 git worktree 命令，它允许一个 Git 仓库对应多个工作目录，每个目录可以检出不同的分支，实现真正的并行开发。 什么是 Worktree？ 简单说，Worktree 就是一个仓库的多个「分店」。它们共享同一个 .git 目录（包含所有分支历史、提交记录），但拥有独立的文件系统和工作环境。 仓库.git（共享） ├── 主工作树（main 分支） ├── ../feature/（feature 分支） └── ../bugfix/（bugfix 分支） 这样，你可以在不同目录同时编辑不同分支，互不干扰。 核心区别 特性 普通分支 Worktree 工作目录 单一目录，切换分支需 checkout 多个独立目录同时存在 环境隔离 切换分支需重建 node_modules 等 各树独立环境 并行开发 需要 stash 保存变更 无需 stash，直接并行 存储开销 只占指针空间 共享 .git，只复制工作文件 这些差异让 worktree 特别适合一台机器上并行开发多个功能。 基本使用 1. 创建 Worktree 在主仓库执行： # 基于现有分支创建 git worktree add ../feature-branch feature-branch # 创建新分支并检出 git worktree add ../new-feature -b new-feature 创建后，你得到一个新目录 ../feature-branch/，里面是 feature-branch 分支的完整工作树，主目录保持不变。 ...

 如何从 0 实现一个极简 Agent 这两年大家一提 Agent，脑子里很容易浮现出一个“会思考、会规划、会调用工具、还会自我修复”的高级智能体。听起来很玄，但如果把那些花哨概念都剥掉，一个能跑起来的极简 Agent，其实没有那么复杂。 说到底，它就两件事： 一个持续运行的 while 循环。 一套精心设计的上下文工程。 大模型本身既没有状态，也没有手脚。它只负责在当前上下文里做判断：这轮该说话，还是该调用某个工具；如果调用工具，工具名是什么，参数应该怎么填。真正读文件、执行命令、写入内容、保存记忆、控制权限的，都是你写的程序。 所以 Agent 的核心从来不是“让模型像人一样思考”，而是：如何把合适的信息在合适的时机交给模型，再把模型的决策稳稳地落到执行环境里。 这篇文章就结合我手头这套玩具代码，从 0 到 1 拆一下：如何把一个看起来很复杂的 Agent，拆成几个可以逐步实现的小能力。 先讲结论：Agent 的最小闭环是什么？  一个最小 Agent，至少要有下面这条闭环： 用户提出任务 -> 模型判断是否需要工具 -> 程序执行工具 -> 把执行结果回填给模型 -> 模型继续决策 -> 直到模型不再调用工具，输出最终答案 这个流程也可以写成更工程化一点的五步： 定义工具，并用 JSON Schema 描述参数约束。 把用户消息、系统提示词、工具清单一起发给模型。 模型返回普通文本，或者返回 tool_call。 程序解析 tool_call，在本地执行真实工具。 将工具结果作为 tool 消息带回模型，进入下一轮。 只要这条链打通，一个最简 Agent 就已经成立了。 为什么说本质是 while 循环？ 因为 Agent 和普通聊天机器人的根本区别，不在于“更聪明”，而在于“能继续行动”。 普通聊天模型通常是一次请求、一次回复，停在那里。Agent 则是在程序外面再包一层循环，让它可以不断经历： Think -> Act -> Observe -> Think 这在代码里其实非常朴素。simple-agent.py 里就是典型的双层循环： ...

coding planning 价格对比 厂商 计划名称 API类型/功能 定价模式 主要特点 适用场景 链接 阿里云 百炼 Coding Plan qwen3-coder-plus 代码生成模型API Lite：7.9元/首月，40元/月 Pro：39元/首月，200元/月 - 兼容OpenAI/Anthropic API规范 - 支持Qwen Code、Claude Code、Cline - 固定月费，月度请求额度 智能编程辅助、多语言代码迁移、企业级软件开发 https://www.aliyun.com/benefit/scene/codingplan 豆包（字节） 方舟 Coding Plan Doubao-Seed-Code 模型API Lite：8.9元/首月，40元/月 54元/首季，120 元/季 Pro：49.9元/首月，200元/月，600 元/季 - 支持Claude Code、Cursor、Cline等5+工具 - 用量达Claude Pro的3倍（Lite）/3倍（Pro） - 一站式开发 中等强度开发任务、复杂项目开发 https://www.volcengine.com/activity/codingplan 邀请码：RNBDFW69 智谱AI GLM Coding Plan GLM-5/GLM-4.7 代码模型API Lite：411 元/年，132元/季49元/月 Pro：1251 元/年，402元/季，149元/月 Max：3939元/年，1266元/季，469元/月 - 支持GLM-5（对标Claude Opus） - 适配20+编程工具 - 免费MCP（联网搜索、图像理解、开源仓库） 轻量级/复杂/海量工作负载，SWE-bench榜单第一梯队 https://bigmodel.cn/glm-coding MiniMax Coding Plan MiniMax M2.1 模型API Starter：9.9元/首月，29元/月 Plus：49元/月 Max：119元/月 - 支持图像理解、联网搜索MCP - 适配9种编程工具 - 邀请好友返利机制 入门级/专业/高级开发场景 https://platform.minimaxi.com/subscribe/coding-plan Kimi（月之暗面） Kimi Claw Kimi K2.5 模型API（通过会员订阅） Andante：49元/月（Kimi Code可调用） Moderato：99元/月（4倍额度） Allegretto：199 元/月 Allegro: 699元/月 - Agent 4倍速优先用 - 支持Kimi CLI、Kimi Code - 连续包年立省240元 高频Agent调用、快速开发 https://www.kimi.com/membership/pricing 阿里百炼 ...