xiaohack's Blog - 上下文管理
type: channel
link: https://blog.xiaohack.org/tag/ed2d6a6c/
items: AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术
items: Skills 与延迟加载工具定义的 MCP，目前哪个更高效、稳定和可控？
items: 了解你的 AI 编码伙伴：Coding Agent核心机制解析
items: 分享一下我的 ClaudeCode 工作流：Kitty + Zed + superpowers，可以减少和 AI 的反复拉扯，一次做对
items: 批量商品分类审核与上下文管理 - 实战 Subagent

AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术
type: item
date: 2026-01-27T14:38:18+08:00
description: 一、开发痛点：为什么我们需要AI编程辅助？核心发现： AI编程工具正在重塑开发流程，但真正的价值不在于替代开发者，而在于构建人机协作的新型开发范式。Claude Code通过精准对话流设计、模块化任务分解和专业化子代理协作，在提升开发效率的同时，也面临着上下文管理、协作边界和质量控制等实际挑战。作为一线开发者，我们每天都在与复杂的业务逻辑和不断迭代的技术栈打交道。不知道你是否也遇到过这些场景：刚理清一个复杂业务流程，被打断后又得重新梳理思路；接手一个老项目，花了半天还没搞懂其中某个模块的设计思路；或者在不同项目间切换时，总要重新适应不同的编码规范和架构风格。日常开发的三个"拦路虎"：上下文切换成本高： 需求理解→技术选型→代码实现→质量验证的切换过程中，每次都要重新构建认知框架。知识传递效率低： 项目规范、架构经验分散在文档和个人经验中，新成员上手或跨模块开发时处处碰壁。开发流程割裂： 需求→设计→编码→审查各环节串行传递，信息易失真且反馈滞后。这些问题不是简单的"加人"或"加班"能解决的。我们需要的是一种新的开发范式，而Claude Code这类AI编程工具正是在这样的背景下进入了我们的视野。它的价值不在于替我们写代码，而在于成为我们的"认知放大器"和"流程协作者"。二、Claude Code核心功能解析：从工具到方法论Claude Code构建了一套完整的AI辅助开发方法论。接下来将结合团队实际使用经验，从功能特性、使用场景和设计初衷三个维度，详细介绍其核心功能：精准对话流设计：控制AI思考的艺术第一次用Claude Code时，就像面对一个热情但经验不足的实习生——如果不明确告诉他要做什么、怎么做、有什么要求，他很可能会给你一个"惊喜"。对话流设计就是解决这个问题的关键。设计初衷： 对话流设计的本质是将人类的编程思维模式转化为AI可理解的结构化交互方式，通过明确的上下文管理和约束条件设置，引导AI生成符合预期的代码结果。核心功能对话流设计通过三个关键机制控制AI的思考过程：上下文聚焦： 要求单次对话仅处理一个功能模块，避免多任务混合导致的AI注意力分散。我们曾经试过在一个对话里同时让AI处理多个模块，结果它把两个模块的错误处理逻辑混在了一起。约束明确化： 通过具体指令减少AI的自由度，比如"仅修改X包下文件"、"必须复用Y工具类"。这些约束要尽可能具体，比如不说"遵循项目规范"，而是说"使用ResultDTO作为统一返回格式，错误码规则参考ErrorCodeEnum"。增量式提问： 采用"先框架后细节"的提问策略，先让AI生成接口定义和整体框架，待确认后再逐步深入实现细节。这种方式很像我们带新人时"先搭骨架再填肉"的指导方法。使用心法启动新功能开发时，我们会创建专用对话线程，并在初始prompt中明确四件事：当前任务的功能边界和目标（做什么，不做什么。）必须遵守的技术约束和规范（用什么技术栈，遵循什么标准。）期望的输出格式和交付物（要代码？要文档？还是两者都要？）分阶段的实现计划（先设计接口，再实现逻辑，最后写测试。）真实踩坑经验处理跨模块依赖时，我们发现AI很容易"忘记"之前设定的约束。后来我们总结出一个技巧：每开始一个新的实现阶段，就简要回顾一下关键约束。比如："现在我们要处理任务交接流程，请记得：1. 使用Redis分布式锁；2. 需要修改商运关系和新商成长任务；3. 异常处理要符合规范。"Plan模式：复杂任务的系统化分解面对"实现一个完整的拜访任务系统"这样的复杂需求，直接让AI生成代码就像让一个刚入行的开发者独立负责整个项目——结果往往是逻辑混乱、漏洞百出。Plan模式就是解决这个问题的"项目管理工具"。现状与问题：我们早期使用Claude Code时，经常犯一个错误：把一个复杂需求一股脑丢给AI，然后期待它给出完美解决方案。结果通常是：实现逻辑不完整，有些边界情况根本没考虑到。模块间接口设计不一致，调用起来磕磕绊绊。技术选型不合理，用了个"看起来很酷但项目中并不适用"的方案。这其实不能怪AI，人在面对过于复杂的问题时也会手足无措。我们需要一种方法把大问题拆分成小问题，而Plan模式正是借鉴了项目管理中的WBS（工作分解结构）思想。我们的解决方案：Plan模式使用三步法分解需求：需求分析与模块划分：把整体需求分解为独立的功能模块。技术方案设计：为每个模块确定实现思路和技术选型。任务优先级排序：根据依赖关系和重要性确定实现顺序。实际操作示例：拜访任务需求拜访任务是一个简单的企业内部任务需求，在实现"拜访任务需求"时，我们通过Plan模式生成的任务清单是这样的：--- 拜访任务线上化 - 模块清单 M1: 任务创建模块 - 功能: 创建拜访任务,包含基本信息、拜访对象、参与人员 - 复杂度: Medium (需要…

Skills 与延迟加载工具定义的 MCP，目前哪个更高效、稳定和可控？
type: item
date: 2026-01-23T08:29:15+08:00
description: 编者按： 我们今天为大家带来的这篇文章，作者的核心观点是：相较于依赖复杂且高成本的动态 MCP 工具加载机制，以 Skills 为核心的能力摘要与自维护模式，在当前阶段反而更加高效、稳定且可控。文章系统梳理了延迟工具加载（deferred tool loading）的工程现实与限制，指出即便工具可以延后注入，对话级别的工具集合仍然是静态的，且发现机制高度依赖正则匹配，收益并不如预期。作者进一步深入分析了 MCP 在上下文占用、API 稳定性、缓存失效与推理轨迹丢失等方面带来的隐性成本，并结合 Sentry MCP、Playwright 等实践案例，说明为何将 MCP 转换为 Skills，反而能让 Agent 更好地发挥既有工具的能力。文章最后还探讨了 MCP 是否可能完全转化为 Skills 的可行性，并坦率指出当前协议与生态在稳定性与摘要机制上的不足。作者 | Armin Ronacher(作者为 Flask、Jinja2 等开源项目的创建者)编译 | 岳扬我正把所有的 MCP 都迁移到 Skills 上，包括之前还在使用的最后一个：Sentry MCP（译者注：Sentry 是流行的应用监控与错误追踪平台）。早前我就已经完全弃用 Playwright（译者注：由 Microsoft 开发的现代 Web 自动化测试和浏览器自动化框架），转向使用 Playwright Skill。过去一个月左右，关于使用“动态工具配置（dynamic tool loadouts）[1]”来推迟工具定义的加载的讨论一直不少。Anthropic 也在探索通过代码来串联 MCP 调用的思路，这一点我也尝试过[2]。我想分享一下自己在这方面的最新心得，以及为什么 Anthropic 提出的“延迟工具加载方案（deferred tool loading）”并未改变我对 MCP 的看法。或许这些内容对他人会有所帮助。01 什么是工具（Tool）？当 Agent 通过强化学习或其他方式接触到工具定义时，它会被鼓励在遇到适合使用该工具的场景时，通过特殊的 token 输出工具调用。实际上，工具定义只能出现在系统提示词（system prompt）中特定的工具定义 token 之间。从历史经验来看，这意味着我们无法在对话状态的中途动态发出新的工具定义。因此，唯一的现实选择是在对话开始时就将工具加载好。在智能体应用场景中，我们当然可以随时压缩对话状态，或更改系统消息中的工具定义。但这样做的后果是，我们会丢失推理轨迹（reasoning traces）以及缓存（cache）。以 Anthropic 为例，这将大幅增加对话成本：基本上就是从头开始，相比于缓存读取，需要支付完整的 token 费用，外加缓存写入成本。Anthropic 最近的一项创新是“延迟工具加载”（deferred tool loading）。我们仍然需要提前在系统提示词（system message）中声明工具，但这些工具不会在系统提示词发出时就注入到对话中，而是会稍后才出现。不过据我所知，这些工具定义在整个对话过程中仍必须是静态的 —— 也就是说，哪些工具可能存在，是在对话开始时就确定好的。 Anthropic 发现这些工具的方式，纯粹是通过正则表达式（regex）搜索实现的。02 与 Skills 的对比尽管带延迟加载的 MCP 感觉上应该表现更优，实际上却需要在 LLM API 端做不少工程化工作。而 Skills 系统完全不需要这些，至少从我的经验来看，其表现依然更胜一筹。Skills 实质上只是对现有能力及其说明文件位置的简短摘要。这些信息会被主动加载到上下文中。 因此，智能体能在系统上下文里（或上下文的其他位置）知晓自己具备哪些能力，并获知如何使用这些能力的“手册链接”。关键在于，Skills 并不会真正把工具定义加载到上下文中。 可用工具保持不变：bash 以及智能体已有的其他工具。Skills 所能提供的，只是如何更高效使用这些工具的技巧和方法。由于 Skills 主要教的是如何使用其他命令行工具和类似实用程序，因此组合与协调这些工具的基本方式其实并未改变。让 Claude 系列模型成为优秀工具调用者的强化学习机制，恰好能帮助处理这些新发现的工具。03 MCP 能否转换为 Skills？这自然引出了一个问题：既然 Skills 效果这么好，我能不能把 MCP 完全移出上下文，转而像 Anthropic 提议的那样，通过 CLI 来调用它？答案是：可以，但效果并不好。Peter Steinberger 的 mcporter[3] 就是其中一种方案。简单来说，它会读取 .mcp.json 文件，并将背后的 MCP 暴露为可调用的工具：npx mcporter call 'linea…

了解你的 AI 编码伙伴：Coding Agent核心机制解析
type: item
date: 2026-01-21T10:17:06+08:00
description: 导读AI 编码工具正在从"智能补全"演进为能自主完成复杂任务的 Coding Agent。本文基于开源项目源码研究与实践经验，系统性地拆解 Coding Agent 的工作原理。旨在帮助开发者在了解Coding Agent后，与AI伙伴更好的协作配合，更高效的提问和拿到有效结果。01 背景AI 编码工具的发展速度快得有点"离谱"。从开始使用 GitHub Copilot 的代码补全，到使用Claude Code、Cursor、Comate IDE等完成复杂编程任务，AI 不再只是个「智能补全工具」，它能读懂你的代码库、执行终端命令、甚至帮你调试问题，成为你的“编码伙伴”。我自己在团队里推 AI 编码工具的时候，发现一个很有意思的现象：大家都在用，但很少有人真正理解它是怎么工作的。有人觉得它"很神奇"，有人吐槽它"经常乱来"，还有人担心"会不会把代码搞乱"。这些困惑的背后,其实都指向同一个问题：我们对这个"伙伴"还不够了解。就像你不会无脑信任一个新来的同事一样，要和 AI 编码伙伴配合好，你得知道它的工作方式、能力边界、以及怎么"沟通"才更有效。在经过多次的实践尝试后，我尝试探索它的底层原理，并写下了这篇文章记录，主要围绕了这些内容展开：Coding Agent 的核心工作机制，包括身份定义、工具调用、环境感知等基础组成。从零实现一个最小化 Coding Agent 的完整过程，以建立对 Agent 工作流程的直观理解。上下文管理、成本控制、冲突管控等生产环境中的关键技术问题及其解决方案。Rule、MCP、Skill 等能力扩展机制的原理与应用场景。在了解原理后，我和伙伴的协作更佳顺畅，让伙伴更清晰的了解我的意图，我拿到有效的回答。02 概念2.1 从Workflow到Agent取一个实际的例子：休假申请。如果我们的需求非常简单：一键申请明天的休假。这个需求可以被简化为一个固定的工作流：打开网页。填写起始时间。填写结束时间。填写休假原因。提交表单。全过程没有任何模糊的输入，使用程序化即可完成，是最原始的工作流形态。如果需求再模糊一些：申请后天开始3天休假。这个需求的特点是没有明确的起始和截止时间，需要从语义上分析出来：起始时间：后天。休假时长：3天。转换日期：10.14 - 10.16。执行申请：提交表单。这是一个工作流中使用大模型提取部分参数的典型案例，是模型与工作流的结合。如果需求更加模糊：国庆后休假连上下个周末。这样的需求几乎没有任何直接确定日期的信息，同时由于年份、休假安排等动态因素，大模型不具备直接提取参数的能力。将它进一步分解，需要一个动态决策、逐步分析的过程：知道当前年份。知道对应年份的国庆休假和调休安排。知道国庆后第一天是星期几。国庆后第一天到下个周末设为休假日期。额外补充调休的日期。填写并提交表单。可以看出来，其中1-5步都是用来最终确定休假日期的，且需要外部信息输入，单独的大模型无法直接完成工作。这是一个典型的Agent流程，通过大模型的智能与工具访问外部信息结合实现用户需求。2.2 什么是AgentAgent是以大模型为核心，为满足用户的需求，使用一个或多个工具，自动进行多轮模型推理，最终得到结果的工作机制。2.3 什么是Coding Agent在Agent的基本定义的基础上，通过提示词、上下文、工具等元素强化“编码”这一目的，所制作的特化的Agent即为Coding Agent。Coding Agent的最大特征是在工具的选取上，模拟工程师进行代码编写的环境，提供一套完整的编码能力，包括：阅读和查询代码：读取文件，对应 cat 命令。查看目录结构，对应 tree 命令。通配符查找，对应 ls命令（如 **/*.test.ts 、src/components/**/use*.ts）。正则查找，对应grep 命令（如function print\(.+\) 可以找函数定义）。LSP（Language Server Protocol），用于提供查找定义、查找引用、检查代码错误等能力。编写或修改代码：写入文件。局部编辑文件。删除文件。执行或交互命令：执行终端命令。查看终端命令stdout输出。向终端命令stdin 输入内容。除此之外，通常Coding Agent还具备一些强化效果而设定的工具，通常表现为与Agent自身或外部环境进行交互，例如经常能见到的TODO、MCP、Subagent等等。03 内部组成3.1 上下文结构3.2 身份定义一个Agent首先会将模型定义成一个具体的身份（红色与橙色部分），例如在社区里常见的这样的说法：You are a Senior Front-End Developer and an Expert in React, Nexts, JavaScript, TypeScript,…

分享一下我的 ClaudeCode 工作流：Kitty + Zed + superpowers，可以减少和 AI 的反复拉扯，一次做对
type: item
date: 2026-01-15T14:15:02+08:00
description: 我的工作流是一个围绕 superpowers 插件 的 Loop，superpowers 的理念是：先思考再动手。当你提出一个需求，不会急于写代码，而是先退一步问你"你真正想要实现什么"，通过对话梳理出完整的设计方案，再分步执行。核心设计是 master 和 worker 分离。脑暴会话 (master)：专注于思考和设计，输出高质量的设计文档和执行计划执行会话 (worker)：专注于代码实现，执行详细的计划1、需求录入 - 首先我会在 Zed 上进行需求录入，采用 md 格式。这一步非常重要，我大概有 30% 的时间花在需求录入上，我会把能想到的关于此需求的背景、最终目标、可行的技术方案、风险点、外部 API 文档等等一切资源，都在需求文档中说明。对于需求文档，我不会太在意格式，会有比较多口语化的表达。2、脑暴阶段 - 把需求 MD 喂给 Claude，调用 /superpowers:brainstorm 和 claude 进行思维碰撞。这个阶段不写任何代码，只讨论设计方案和实现细节，最终输出 design.md 和 implement.md，保证最终的实现方案是完美符合我的预期的。3、 执行阶段 - 这里我会选择新起一个 ClaudeCode 会话，而不是在脑暴会话中进行代码实现。新会话的好处：一、原先脑暴会话已经经过多轮对话了，一般情况下上下文会比较满，新会话响应更快，并且不会“犯傻”；二、implement.md 足够详细，无需额外上下文4、 CodeReview - 在 Zed 中进行代码审查和功能验收。关于代码审查，对于一些代码细节和实现原理，这里我会使用 zed-agent 来辅助我进行代码 review，当然，你也可以在终端新建一个 ClaudeCode 会话或者使用 Zed 的 Claude Agent。原则是尽量不在脑暴和执行会话中引入太多不必要的问题，保持这两个会话的「干净」。发现问题后，将改进项写入新的需求 MD5、 LOOP - 改进项 MD 喂回脑暴会话，开始下一轮脑暴迭代非常简单，但是效果超群。充分的前期设计可以提升 AI 的效率和质量，避免多次的来回拉扯。举个真实案例：我用这套工作流将个人博客从 Quarz 框架迁移到 Astro 框架。脑暴阶段确认好设计方案后，我让 Claude 执行计划，然后就去睡午觉了。醒来发现 Claude Code 已经完美完成任务——中间零中断，一次成功，共计 5000+ 行代码变更。

批量商品分类审核与上下文管理 - 实战 Subagent
type: item
date: 2026-01-10T18:59:59+08:00
description: 本文通过一个真实的商品分类审核场景，详细讲解 Claude Code Subagent 的创建、调用，以及大规模数据处理时的上下文管理技巧。背景我需要维护一份商品标准化分类体系表。随着业务发展，商品清单不断增加，我需要定期检查：哪些商品还没有被现有分类覆盖？手上有两个文件：goods.txt：商品清单，一行一个商品名，约 5000 个标准化分类体系表.md：现有的分类表，markdown 表格格式目标很简单：找出所有未被覆盖的商品，并给出分类建议。解决方案对比面对这个需求，我尝试了三种方案：方案 1：直接 Prompt 让 AI 处理最直接的想法：把 goods.txt 和 标准化分类体系表.md 都丢给 Claude，让它一次性处理。核心问题：上下文溢出：5000 个商品 + 分类表 + 审核结果，轻松超出上下文限制输出不稳定：AI 处理到第 3000 个商品时，可能 "忘记" 前面的判断标准无法并行：只能串行处理，5000 个商品要等很久结果难以解析：AI 输出格式不一致，后续脚本难以处理方案 2：使用 Skills把审核逻辑封装成一个 Skill，让主 Agent 调用。改进点：Skill 可以复用，审核逻辑标准化可以分批处理，降低单次上下文压力依然存在的问题：上下文累积：每批的输入输出仍然留在主对话中无法真正隔离：所有 Skill 调用共享主 Agent 的上下文并发受限：Skill 仍是串行执行，无法并行加速方案 3：使用 Subagent（本文方案）为审核任务创建独立的 Subagent，每个 Subagent 处理一批商品。核心优势：上下文隔离：每个 Subagent 拥有独立的上下文，互不干扰可并行处理：多批审核可以同时进行（理论上）输出标准化：Subagent 严格按照定义的 JSON 格式输出主 Agent 轻量：主 Agent 只做调度，不接触数据内容Subagent 方案传统方案📦 5000 商品挤在一个上下文❌ AI 输出格式不稳定⏳ 串行处理，效率低🤖 主 Agent 直接处理数据📦 每批 30 个，独立上下文✅ 严格 JSON 格式输出🚀 可批次并行处理🎯 主 Agent 只做调度什么是 Subagent？简单来说，Subagent 就是一个可以被主 Agent 调用的 "专家助手"。你可以把它理解为：函数：定义好输入输出，主 Agent 调用时传参独立进程：拥有自己的上下文，不污染主 Agent专业顾问：每个 Subagent 可以有自己的专业领域和工具集不过，不要太纠结概念。接下来通过实战，你会直观理解 Subagent 是怎么工作的。为什么选择 Subagent？最初我想直接让 Claude Code 处理，但很快发现问题：上下文爆炸：5000 个商品 + 分类表 + 审核结果，轻松超出上下文限制串行处理慢：逐个商品判断，效率太低结果混乱：长对话中，Claude 容易 "忘记" 之前的判断标准Subagent 天然解决这些问题： 痛点Subagent 方案 上下文爆炸每个 Subagent 独立上下文，互不干扰处理效率批次并行处理结果一致性每批独立审核，标准统一 实战开始第一步：设计 Subagent在 .claude/agents/ 目录下创建 category-reviewer.md：--- name: category-reviewer description: 商品分类覆盖审核专家。当需要批量检查商品是否被现有分类表覆盖时使用。 tools: Read, Write model: sonnet --- 你是商品分类覆盖审核专家。 ## 输入说明 调用时会提供： - batch_id: 批次编号 - input_file: 商品列表文件路径 - output_file: 结果输出文件路径 ## 执行步骤 1. 使用 Read 读取 input_file，获取商品列表 2. 使用 Read 读取 `doc/goodscategoryreview/标准化分类体系表.md` 3. 逐一判断每个商品的分类覆盖情况 4. 将结果 JSON 写入 output_file 5. 回复确认信息 ## 判断标准 - **covered**：商品名称能够明确归入现有某个分类 - **uncovered**：商品无法归入任何现有分类 ## 输出格式 写入 output_file 的 JSON： { "batch_id": "xxx", "results": [ {"name": "商品A", "status": "covered", "matched_category": "匹配的分类"}, {"name": "商品B", "status": "uncovered", "reason": "原因", "su…