我现在越来越不太相信很多团队嘴里的“我们已经把经验沉淀成 Skill 了”。不少时候，他们做的事情其实很简单：把原来聊天框里那段已经很长的 system prompt，挪进一个叫 SKILL.md、agent.md、workflow.md 的文件里，然后继续往里面堆规则、堆例外、堆工具说明、堆输出格式，最后给自己一种“我们已经工程化了”的幻觉。 这…

我一开始也觉得，Skill 这套说法多少有点重新发明 prompt。你给模型一段更长的说明，附几份文档，再绑几个工具，不就差不多了吗？后来我看了一圈现在主流产品和文档，发现这件事确实有营销包装，但也不能简单归成“换个名字继续卖提示词”。真正被单独拿出来讲的，不是那一段自然语言本身，而是把一段可重复的做事方法，封装成可调用、可共享、可版本化、可维护的…

每次看到 Agent 工具调用能力增强，大家第一反应通常都是兴奋：能查网页了，能并行调工具了，能自动编排代码了，终于更像“会做事”的系统了。这个方向当然对，但我最近越来越强烈的感受是，很多系统不是先败在模型不够强，而是先败在工具调用把复杂度和成本一起放大。 Anthropic 在 2025 年底公开过 advanced tool use，提到 pr…

很多人提到 Agent 记忆，第一反应还是“让它记住用户偏好”或者“跨会话别忘事”。这当然有用，但我现在越来越觉得，这个理解已经不够了。真正决定 Agent 能不能长时间稳定工作、能不能跨多步任务继续推进的，不只是有没有记忆，而是你有没有把记忆和压缩当成一层基础设施来设计。 OpenAI 最新的 Cookbook 已经把 memory 和 comp…

我原本以为，2026 年 Agent 这一波继续往前走，最值得追的是模型升级。后来越看越觉得不对。模型当然还在进步，但真正开始决定系统能不能长时间稳定工作的，越来越像是另一个层：上下文工程，以及围绕它长出来的技能层。 Anthropic 在 2025 年专门写了 Effective context engineering for AI agents…

我一开始以为，所谓云端编码代理，只是把 IDE 里的补全和对话面板搬到浏览器里。后来越看越觉得不是这么回事。真正的变化不在“能不能写代码”，而在它开始接管一整段原本需要人类持续盯着的工程流程：拉代码、看上下文、跑命令、修失败、继续尝试、最后给出可审阅结果。 这件事为什么值得单独写？因为它意味着开发者工具正在从“交互式助手”变成“可持续运行的任务执行…

这两年只要模型上下文一变长，市场上就会周期性出现一种说法：RAG 要死了。现在上下文都到 1M 甚至更高了，文档直接全塞进去不就行了吗？这个说法听起来很顺，但工程上其实站不住。我的判断是：超长上下文会改变知识接入层的设计，但不会替代 RAG，它真正改变的是“接入成本曲线”而不是“信息检索的基本规律”。 这不是抬杠，而是很多团队正在真实面对的架构问题…

MCP 这半年很火，火到很多人已经默认它会成为 Agent 世界的“USB-C”。这个比喻传播很快，因为它足够顺口：统一接口、统一协议、统一生态，模型终于可以不再为每个工具写一套私有集成。问题是，工程世界里所有“万能插头”的故事，都有一个后半段：统一连接方式会降低接入成本，也会同步放大同一类设计缺陷的传播速度。最近安全研究团队公开披露的 MCP 相…

这两个月我越来越确定一件事：Agent 赛道真正拉开差距的地方，已经不是“模型会不会写代码”，而是你怎么把模型放进一个能持续工作的执行框架里。很多人到现在还把长任务 Agent 理解成“更长的 Prompt + 更多工具”。这个理解在做 demo 时还能凑合，一旦任务跨文件、跨步骤、跨小时，问题就会立刻暴露：上下文变脏、任务跑偏、自评失真、失败后无…

Anthropic 刚发布 Claude Opus 4.7，官方把重点放在软件工程、长时复杂任务和更好的视觉能力上。很多人看到这类发布，第一反应还是去比参数、比榜单、比“谁更强”。但说实话，到了 2026 年这个阶段，只把模型升级理解成一次性能刷新，已经有点落后了。我认为 Opus 4.7 真正值得看的，不是它把“回答”做得更漂亮，而是它继续强化了…