很多人看 Responses API，第一反应是“又多了几个内置工具”。但我现在越来越觉得，它真正有价值的地方不在功能表，而在于它把工具调用、上下文延续、多步推理放进了同一个回路里。这件事对做 Agent 的开发者很重要。因为过去最烦的不是调用某个工具本身，而是你得自己在应用层补一大堆胶水：保存中间状态、决定何时继续、把工具结果再塞回模型、处理多轮…

很多人用 AI 写代码，第一反应是直接把需求丢进去，然后期待它吐出一个能跑的结果。我自己试得越多，越觉得这种方式在小 demo 里很好，在真实项目里却很容易把返工提前透支掉。这也是我现在更看重 spec-driven development 的原因：它看起来慢，但它其实是在把那些原本会在 review、联调、回归阶段爆出来的问题，提前拉到最前面。它…

我现在越来越愿意把背景编码 Agent 当成一个能消化 backlog 的工具，但我仍然不建议把核心架构改造、跨模块重构、关键业务规则迁移直接扔给它。原因不是它完全做不好，而是这类任务真正难的部分往往不在“写代码”，而在判断隐含约束、识别历史包袱、控制改动半径。这些地方，今天的 Agent 还远没有宣传里那么稳。为什么这个话题现在值得写过去一年里，…

我一开始以为 MCP 最大的问题是协议本身不够成熟，后来发现真正麻烦的不是“能不能连上”，而是权限、状态和失败边界到底归谁管。这也是我现在不建议个人开发者把 MCP 当成“万能插件接口”的原因。它当然值得学，但更适合把它看成 Agent 世界里的工具接线层，而不是业务系统里的稳定扩展层。我为什么会关注它MCP 近一年的热度非常高，因为它确实在试图统…

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

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

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

我现在越来越觉得，很多 Agent 项目最后能不能上线，关键根本不在模型。模型当然重要，但它通常不是第一个把项目卡死的地方。更常见的现实是：团队刚把原型跑起来，接下来就被一连串更难回答的问题绊住——谁来审计？谁来兜底？错误动作怎么算？权限怎么切？出事后能不能还原发生了什么？ OpenAI 在 2026 年发布的《Building Governed …

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

我现在越来越不相信“这个编码代理看起来还不错”这种判断了。因为它通常只意味着两件事：要么演示做得顺，要么你刚好让它撞上了一个适合发挥的样例。真正进入工程环境之后，问题不是它能不能偶尔写出一段对的代码，而是它在重复任务里能不能稳定地走对流程、少犯同一类错、让审阅成本真的下降。 OpenAI 在 2026 年初公开的《Testing Agent Ski…