我最近看一圈 Agent 框架，最大的感受不是“选择太多”，而是很多项目一上来就把多 Agent 协作当成默认形态，结果问题还没解决，复杂度先翻倍了。所以我对 OpenAI Agents SDK 现在的判断是：它已经越来越像一个认真做工程的框架了，但个人开发者别把重点放在“怎么上多 Agent”，而是先想清楚一个 Agent 加几条明确 hando…

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

我现在越来越不太相信很多团队嘴里的“我们已经把经验沉淀成 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…

很多人第一次看到 Workspace Agents，会下意识把它理解成“企业版 GPTs”或者“能连更多工具的聊天机器人”。我觉得这个理解太浅了。真正值得开发者关注的，不是它把聊天做得更像助手，而是它开始把团队里原本散落在人脑、文档和口头传承里的流程，收敛成一个可以被共享、重复运行、持续改进的执行单元。 OpenAI 在 2026 年 4 月公布 …

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