它不是让 Agent 变得“更会说”，而是让 Agent 的能力开始有了工程化封装的形态。开放出来，里面包含技能示例、规范、模板，以及文档处理相关的复杂 Skill 参考实现。这样做的好处是，团队原来的测试经验不会丢，而是变成了 Agent 可以复用的能力。更重要的是，能不能把测试经验封装成标准化、可复用、可验证的 Agent 能力。这样一来，Agent 就不只是“辅助写东西”，而是可以参与完整的

而且很多断言长得都差不多——assert response.json()[“code”] == 200，assert response.json()[“data”][“status”] == “SUCCESS”——写的时候手指头都麻了。上个月就有这么一回，一个优惠券接口返回了错误的面额，但因为脚本里只断言了状态码，没断言金额字段，这bug愣是混到预发环境才被发现。我甚至想，如果团队能建一个“断言知

过去几年，大模型竞争的核心逻辑是“参数越大越强”。如果 35B 在数据过滤、样本质量、RL 策略上明显优化，那么能力反超是合理的。同时发布的 Flash 版本默认支持百万级长文本，上下文能力进一步拉升。Flash 版本默认支持百万级上下文，这是工程层面更值得关注的一点。这不是小幅优化，而是“体量更小，效果更强”。当“调校能力”提升，小模型的效率会被放大。当这些因素提升，小模型也能具备强竞争力。参数

它具备完整的工程属性： 常驻项目目录、读写文件、执行命令、维护长期上下文、调用外部工具。它并不是网页版 Claude 的增强版本，也不是“更擅长写代码的聊天机器人”。一个常见失败模式是： 让一个 Agent 什么都干，结果什么都不稳定。IDE 的价值并不只是“更方便”，而是把 Agent 的输出沉淀为。Agent 强不强，不取决于模型有多大，而取决于你接入了多少系统。把 Agent 从“概念演示”

Anthropic 在文档中提出了三个核心理念。Skills 不就是 Prompt 模板吗？Anthropic 总结了五种常见设计模式。Skill 不会一次性加载全部内容。如果只是这么理解，那就低估它了。验证 Skill 是否正确触发。都可以嵌入 Skill 中。

更糟糕的是，像 Claude Code 这样，客户端可以单方面改变缓存策略，用户完全不知情。你看不到真实的思考深度（被 redact 了），看不到缓存是否命中（被静默降级了），看不到工具结果是否被截断（截断了也不告诉你）。当 Anthropic 在“追求极致体验”与“沉重推理成本”之间剧烈挣扎时，开发者需要的不是一个替自己做决策的黑盒，而是一个透明、可预测的杠杆。当 AI 工具开始在用户看不见的地

官方把 agent 放进 controlled workspace，把执行层做进 sandbox，把 harness 作为编排层独立出来，目标不是“再多一个接口”，而是让 agent 能在文件、工具、命令和长链路任务中安全地工作。它可能要先读资料，再拆任务，再进工作区，再装依赖，再执行命令，再开浏览器，再写文件，再产出报告，必要时还要停下来等人工审核，审核通过后继续往下跑。现在很多团队面对的，已经

多位技术负责人直言，在依赖大量工具调用和复杂第三方API链路的场景中，V4的稳定性还不完全可靠，部分情况仍需在Harness层补足工具调用的稳定性和幻觉率控制。V4在数学、STEM、竞赛代码这类结构清晰的任务上跑出顶级闭源竞品的水平，但工具调用的稳定性和低幻觉率仍未完全解决——甚至在它的内部报告里也没有遮掩这一点。在1.6T总参数的规模下，激活参数控制在49B，本质上把原本“一个人做所有事”的思路

给模型真实 GitHub Issue，让模型修复代码并生成 patch，通过测试验证修复是否成功，从而衡量模型在真实工程场景中的代码能力。OpenAI 弃用 SWE-bench Verified，并推荐使用更严格的 Pro 版本，本质上是一次评估体系升级。在抽查任务中发现，相当比例的失败案例，并不是模型无法修复问题，而是测试本身存在不合理设计。这条资讯对测试工程师的价值，不在于模型排名变化，而在于

最近，Anthropic 发布了一份 30 多页的 Skill 创建指南，系统讲解如何为 Claude 构建自定义能力模块。当 Skill 混乱时，调度逻辑会指数级膨胀。第一，能力沉淀成为可能。重复逻辑不再写 Prompt，而是封装成 Skill。第一，Skill 是模型能力的结构化延伸。这不是简单的 API 更新说明，而是一份偏工程体系化的能力设计手册。Skill 的定位，恰好在 Tool 与